From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 00:08: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 D3FDD16A41C for ; Sun, 17 Jul 2005 00:08:52 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D6D43D46 for ; Sun, 17 Jul 2005 00:08:50 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr1so.prod.shaw.ca (pd4mr1so-qfe3.prod.shaw.ca [10.0.141.212]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IJQ00810WEP1290@l-daemon> for freebsd-current@freebsd.org; Sat, 16 Jul 2005 18:08:49 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd4mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IJQ00093WEPX1C0@pd4mr1so.prod.shaw.ca> for freebsd-current@freebsd.org; Sat, 16 Jul 2005 18:08:49 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IJQ00F5TWEP79@l-daemon> for freebsd-current@freebsd.org; Sat, 16 Jul 2005 18:08:49 -0600 (MDT) Date: Sat, 16 Jul 2005 17:08:48 -0700 From: Colin Percival In-reply-to: <200507170157.04718.imachine@toya.net.pl> To: Mateusz Jedrasik Message-id: <42D9A190.5060401@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <200507170157.04718.imachine@toya.net.pl> User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050714) Cc: freebsd-current@freebsd.org Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 00:08:52 -0000 Mateusz Jedrasik wrote: > Also, I dont want to sound "linuxy" here, but it could be nice with a way that > ata bus drivers could inform userland programs somehow when the tray of a > cd/dvd has closed - so it would be possible to automount stuff like cd's upon > closure of tray, and perhaphs upon the pressing of the eject button, > automatic unmounts if the medium is not currently used by any process. There is already a mechanism available for doing this: devd. I don't know if the ata drivers send the necessary messages, and I'm pretty sure that there isn't anything in userland which listens for those messages; but all of the infrastructure is there. Colin Percival From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 00:36: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 6610716A41C for ; Sun, 17 Jul 2005 00:36:20 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC03F43D48 for ; Sun, 17 Jul 2005 00:36:19 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id j6H0ZLeW003118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jul 2005 02:35:21 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j6H0ZLCV003117 for freebsd-current@freebsd.org; Sun, 17 Jul 2005 02:35:21 +0200 (CEST) (envelope-from csaba) Date: Sun, 17 Jul 2005 02:35:21 +0200 From: Csaba Henk To: freebsd-current@freebsd.org Message-ID: <20050717003521.GG73367@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: early panic and dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 00:36:20 -0000 Hi! I tried to install both RELENG-6 and CURRENT, and both kernels behaved the same way: panicked quite early (before init) with a page fault. Has anyone met with this phenomena? I'd like to show you some fancy backtracks, but as it all happened before starting init, rc.conf settings won't help me in getting the dump. What I've read: "the dump device can be hard-coded via the dump clause in the config(5) line of a kernel configuration file." But putting dump /dev/ad0s4 into the config file is considered a syntax error, and the man page of config doesn't contain anything about dumping. Another thing which I found on the net suggests setting the dumpdev variable in the loader(8). I can do that, but it doesn't make a difference, and again, the man page doesn't mention dumping. How to get that wacky dump these days? TIA. Cheers, Csaba From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 00:40: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 A6DB316A41C; Sun, 17 Jul 2005 00:40:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B4F043D46; Sun, 17 Jul 2005 00:40:09 +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 j6H0c8TV023070; Sat, 16 Jul 2005 18:38:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 18:38:51 -0600 (MDT) Message-Id: <20050716.183851.56563544.imp@bsdimp.com> To: cperciva@freebsd.org From: "M. Warner Losh" In-Reply-To: <42D9A190.5060401@freebsd.org> References: <200507170157.04718.imachine@toya.net.pl> <42D9A190.5060401@freebsd.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, imachine@toya.net.pl Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 00:40:09 -0000 In message: <42D9A190.5060401@freebsd.org> Colin Percival writes: : Mateusz Jedrasik wrote: : > Also, I dont want to sound "linuxy" here, but it could be nice with a way that : > ata bus drivers could inform userland programs somehow when the tray of a : > cd/dvd has closed - so it would be possible to automount stuff like cd's upon : > closure of tray, and perhaphs upon the pressing of the eject button, : > automatic unmounts if the medium is not currently used by any process. : : There is already a mechanism available for doing this: devd. I don't know if : the ata drivers send the necessary messages, and I'm pretty sure that there : isn't anything in userland which listens for those messages; but all of the : infrastructure is there. Except that there's no way to know when the tray is closed, except polling... Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 00:43: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 0535016A41C for ; Sun, 17 Jul 2005 00:43:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C3443D49 for ; Sun, 17 Jul 2005 00:43:00 +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 j6H0eb40023094; Sat, 16 Jul 2005 18:40:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 18:41:20 -0600 (MDT) Message-Id: <20050716.184120.61267598.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <20050716.112411.52164710.imp@bsdimp.com> References: <20050716.105849.112624020.imp@bsdimp.com> <200507161914.23682.thierry@herbelot.com> <20050716.112411.52164710.imp@bsdimp.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: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 00:43:01 -0000 In message: <20050716.112411.52164710.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <200507161914.23682.thierry@herbelot.com> : Thierry Herbelot writes: : : > Also, do you have ed compiled into the kernel : : > or are you using a module? : : : : it's in the kernel : a straight, simple GENERIC. : : OK. I always use modules. I'll see if something is broken with : generic. OK. ed(4) is fine. Works great for me. However, there appears to be some issues with the Ricoh RF5C47x class of bridge chips. I have an old VAIO that exhibits similar problems to what you describe. I believe it is the difference between how the TI automatically powers up the card, and how the Ricoh requires an additional manual step that we're not doing right now. I'll try to find that step as soon as my system updates... Its a Pentium 300, so even an installworld takes a while (esp when you forget to enable soft updates...). Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 02:09: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 2829C16A41C for ; Sun, 17 Jul 2005 02:09:46 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A6443D46 for ; Sun, 17 Jul 2005 02:09:45 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (rwcrmhc12) with ESMTP id <200507170209450140032cqre>; Sun, 17 Jul 2005 02:09:45 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6H29k1X042325 for ; Sat, 16 Jul 2005 22:09:46 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6H29kbU042324 for freebsd-current@freebsd.org; Sat, 16 Jul 2005 22:09:46 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 16 Jul 2005 22:09:46 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050717020946.GA42304@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: Problem compiling sched_ule.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, 17 Jul 2005 02:09:46 -0000 Hi, After the recent changes to the macros to atomic.h, I am getting compilation warnings in sched_ule.c. /usr/src/sys/kern/sched_ule.c: In function `kseq_assign': /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 2 of `atomic_cmpset_int' makes integer from pointer without a cast /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 3 of `atomic_cmpset_int' makes integer from pointer without a cast /usr/src/sys/kern/sched_ule.c: In function `kseq_notify': /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 2 of `atomic_cmpset_int' makes integer from pointer without a cast /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 3 of `atomic_cmpset_int' makes integer from pointer without a cast *** Error code 1 Is this the correct way to fix this: --- /usr/src/sys/kern/sched_ule.c.orig Sat Jul 16 21:42:07 2005 +++ /usr/src/sys/kern/sched_ule.c Sat Jul 16 22:09:00 2005 @@ -651,7 +651,8 @@ do { *(volatile struct kse **)&ke = kseq->ksq_assigned; - } while(!atomic_cmpset_ptr(&kseq->ksq_assigned, ke, NULL)); + } while(!atomic_cmpset_ptr((uintptr_t *)&kseq->ksq_assigned, + (uintptr_t)ke, (uintptr_t)NULL)); for (; ke != NULL; ke = nke) { nke = ke->ke_assign; kseq->ksq_group->ksg_load--; @@ -688,7 +689,8 @@ */ do { *(volatile struct kse **)&ke->ke_assign = kseq->ksq_assigned; - } while(!atomic_cmpset_ptr(&kseq->ksq_assigned, ke->ke_assign, ke)); + } while(!atomic_cmpset_ptr((uintptr_t *)&kseq->ksq_assigned, + (uintptr_t)ke->ke_assign, (uintptr_t)ke)); /* * Without sched_lock we could lose a race where we set NEEDRESCHED * on a thread that is switched out before the IPI is delivered. This -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 04:14: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 B7C1B16A41F for ; Sun, 17 Jul 2005 04:14:59 +0000 (GMT) (envelope-from nate@root.org) Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.4.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7933C43D46 for ; Sun, 17 Jul 2005 04:14:57 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.107] (ool-44c2c69b.dyn.optonline.net [68.194.198.155]) by mta9.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0IJR00H7C7SWYCY5@mta9.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Sun, 17 Jul 2005 00:14:56 -0400 (EDT) Date: Sat, 16 Jul 2005 21:06:49 -0700 From: Nate Lawson To: FreeBSD Current Message-id: <42D9D959.5030304@root.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) Subject: unnecessary savecore warnings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 04:14:59 -0000 I noticed that in the past few months, savecore has begun complaining if the bounds file in /var/crash doesn't exist. Can we add it to /usr/src/etc/Makefile like the corresponding entry for minfree? Also, I noticed that /etc/rc.d/savecore has started complaining early in boot if you have dumpdev="AUTO", giving the message "kenv: unable to get dumpdev". Of course, it works just fine and detects the slice with "swap" in /etc/fstab. So the warning is spurious and should be silenced. -- Nate From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 04: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 5D55516A484; Sun, 17 Jul 2005 04:18:12 +0000 (GMT) (envelope-from nate@root.org) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4469843D4C; Sun, 17 Jul 2005 04:18:11 +0000 (GMT) (envelope-from nate@root.org) Received: from [192.168.1.107] (ool-44c2c69b.dyn.optonline.net [68.194.198.155]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0IJR00GKN7XOWI04@mta1.srv.hcvlny.cv.net>; Sun, 17 Jul 2005 00:17:48 -0400 (EDT) Date: Sat, 16 Jul 2005 21:09:41 -0700 From: Nate Lawson In-reply-to: <20050716.131701.124866666.imp@bsdimp.com> To: "M. Warner Losh" Message-id: <42D9DA05.1020806@root.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.125824.48530425.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) Cc: freebsd-current@freebsd.org, harrycoin@qconline.com Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Sun, 17 Jul 2005 04:18:13 -0000 M. Warner Losh wrote: > > Nate writes: > >>I really think the driver is broken and the API is fine for this. I >>don't like the hack of returning a random CID for checks against the >>HID. Drivers down the road may come to rely on this and then every BIOS >>that has a different order for CIDs becomes a potential breakage point. > > > They alredy do rely on this. When they support pnp, they call the > ISA_PNP_PROBE routine. When they don't then your observation doesn't > matter because the order of the IDs doesn't matter: their non-zeroness > does. > > >>Drivers should not rely on isa_get_logicalid() to determine a boolean >>"is PNP?" > > > Actually, that's the interface. We have to follow it, even if you > think it is stupid. It is how we do things. When we don't have a > logicalid, we return 0. When drivers don't support pnp devices, it > uses the existance of a non-zero pnpid to know the device isn't for > them. It has been this way since 3.0. > > Warner Rather than John's addition of returning an arbitrary CID, can we return ~0 or some other obviously invalid HID so that drivers don't start depending on the order of CIDs? -- Nate From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 04:53:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A08316A41C for ; Sun, 17 Jul 2005 04:53:29 +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 70E4943D46 for ; Sun, 17 Jul 2005 04:53: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 j6H4rRww070335 for ; Sat, 16 Jul 2005 21:53:27 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j6H4rRmu070334 for freebsd-current@freebsd.org; Sat, 16 Jul 2005 21:53:27 -0700 (PDT) (envelope-from obrien) Date: Sat, 16 Jul 2005 21:53:27 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20050717045327.GB69544@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Subject: [PANIC] VOP_STRATEGY failed bp=0xcb9c3970 vp=0xc25d2770 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, 17 Jul 2005 04:53:29 -0000 $ uname -a FreeBSD 6.0-CURRENT #9: Thu Jul 7 17:03:15 PDT 2005 rootk@kieu.nuxi.com:/usr/src/sys/i386/compile/DEO panic: VOP_STRATEGY failed bp=0xcb9c3970 vp=0xc25d2770 cpuid = 0 KDB: stack backtrace: kdb_backtrace(c092a42d,0,c090e2fb,d60fd91c,c44d9600) at 0xc06ae0ee = kdb_backtrace+0x2e panic(c090e2fb,cb9c3970,c25d2770,c09b1f00,c25d2770) at 0xc0691138 = panic+0x128 bufstrategy(c25d2830,cb9c3970,cb9c39d0,cb904ec8,cb9c3970) at 0xc06e734f = bufstrategy+0x7f nfs_writebp(cb9c3970,1,c44d9600,d60fda28,c079761e) at 0xc0797a1f = nfs_writebp+0x12f nfs_bwrite(cb9c3970,0,c0918bfc,b17,c212b180) at 0xc0797d43 = nfs_bwrite+0x23 nfs_flush(c25d2770,1,c44d9600,1,d60fda58) at 0xc079761e = nfs_flush+0x82e nfs_fsync(d60fda68,3b4,c090f2c2,0,d60fda78) at 0xc0796dea = nfs_fsync+0x2a VOP_FSYNC_APV(c0979380,d60fda68,c09b1b80,c25d2770,1) at 0xc08b142e = VOP_FSYNC_APV+0x9e bufsync(c25d2830,1,c44d9600,3b4,c25d2770) at 0xc06e72c4 = bufsync+0x34 bufobj_invalbuf(c25d2830,1,c44d9600,100,0) at 0xc06f25ea = bufobj_invalbuf+0xfa vinvalbuf(c25d2770,1,c44d9600,100,0) at 0xc06f2952 = vinvalbuf+0x32 nfs_vinvalbuf(c25d2770,1,c44d9600,1,d60fdb3c) at 0xc0788b80 = nfs_vinvalbuf+0xe0 nfs_setattr(d60fdb74,d60fdb74,0,0,c25d2770) at 0xc0791565 = nfs_setattr+0x205 VOP_SETATTR_APV(c0979380,d60fdb74,68,0,c1bc6000) at 0xc08b0c2e = VOP_SETATTR_APV+0x9e setutimes(c44d9600,c25d2770,d60fdc9c,2,0) at 0xc06fca2e = setutimes+0x1be kern_utimes(c44d9600,bfbfe952,0,bfbfe510,0) at 0xc06fcb70 = kern_utimes+0xb0 utimes(c44d9600,d60fdd04,8,421,2) at 0xc06fcab1 = utimes+0x31 syscall(3b,3b,3b,804f000,1000) at 0xc089e6f2 = syscall+0x2a2 Xint0x80_syscall() at 0xc08882cf = Xint0x80_syscall+0x1f --- syscall (138, FreeBSD ELF32, utimes), eip = 0x28212b2f, esp = 0xbfbfe4bc, ebp = 0xbfbfe678 --- Uptime: 9d2h52m33s Dumping 494 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 494MB (126448 pages) 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok Dump complete -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 06:10: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 0B16F16A41C for ; Sun, 17 Jul 2005 06:10:11 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F52B43D48 for ; Sun, 17 Jul 2005 06:10:10 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so862698wri for ; Sat, 16 Jul 2005 23:10:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RmcByl6C08hRPyRKc4QQyzCIq01aPybGhsgG7YaA3ENMHvSAw8wHTMd8peMIgaF8RxtB00bkrcH0rvliyMUg/aiYHXHVE0OE/y+5UtDeNtxCvapsVPTiA1K/X7lAol2Z4xznYgCtNixU0vrhs4lNFwIUT6zn0x7Veyzq+iCgUi4= Received: by 10.54.24.31 with SMTP id 31mr27478wrx; Sat, 16 Jul 2005 23:10:10 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Sat, 16 Jul 2005 23:10:09 -0700 (PDT) Message-ID: Date: Sun, 17 Jul 2005 01:10:09 -0500 From: Sam Pierson To: FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: UDF broken? thought it was fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 06:10:11 -0000 Hello all, Attempting to upgrade from 5.3-release to 6.0. Everything is fine until I boot into the newly created kernel/world and it tries to mount the root file system. It says: "panic: lockmgr: locking against myself". =20 and forces me to reboot. I believe there was a similar problem around the 12th of July, so this should have been fixed already. I cvsup'd to get the source from cvs1.us.freebsd.org and it appears that it has been all been updated, although I haven't checked the udf files yet. From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 06:52: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 5927816A41C for ; Sun, 17 Jul 2005 06:52:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9862143D46 for ; Sun, 17 Jul 2005 06:52:27 +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 j6H6nIie025333; Sun, 17 Jul 2005 00:49:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Jul 2005 00:50:01 -0600 (MDT) Message-Id: <20050717.005001.38197608.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <42D9DA05.1020806@root.org> References: <20050716.125824.48530425.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.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, harrycoin@qconline.com Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Sun, 17 Jul 2005 06:52:28 -0000 In message: <42D9DA05.1020806@root.org> Nate Lawson writes: : M. Warner Losh wrote: : > : > Nate writes: : > : >>I really think the driver is broken and the API is fine for this. I : >>don't like the hack of returning a random CID for checks against the : >>HID. Drivers down the road may come to rely on this and then every BIOS : >>that has a different order for CIDs becomes a potential breakage point. : > : > : > They alredy do rely on this. When they support pnp, they call the : > ISA_PNP_PROBE routine. When they don't then your observation doesn't : > matter because the order of the IDs doesn't matter: their non-zeroness : > does. : > : > : >>Drivers should not rely on isa_get_logicalid() to determine a boolean : >>"is PNP?" : > : > : > Actually, that's the interface. We have to follow it, even if you : > think it is stupid. It is how we do things. When we don't have a : > logicalid, we return 0. When drivers don't support pnp devices, it : > uses the existance of a non-zero pnpid to know the device isn't for : > them. It has been this way since 3.0. : > : > Warner : : Rather than John's addition of returning an arbitrary CID, can we return : ~0 or some other obviously invalid HID so that drivers don't start : depending on the order of CIDs? That might not be a bad idea. I'm not sure the right thing to do is. I know this would break at least one sound driver, but I believe that sound driver is broken anyway. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 08:39: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 8929916A41C; Sun, 17 Jul 2005 08:39:40 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2BB343D46; Sun, 17 Jul 2005 08:39:39 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 382508C264; Sun, 17 Jul 2005 10:39:38 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 16429-05; Sun, 17 Jul 2005 10:39:35 +0200 (CEST) Received: from [192.168.0.4] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 7F8CA8C24B; Sun, 17 Jul 2005 10:39:36 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: "M. Warner Losh" Date: Sun, 17 Jul 2005 10:41:37 +0200 User-Agent: KMail/1.8.1 References: <200507170157.04718.imachine@toya.net.pl> <42D9A190.5060401@freebsd.org> <20050716.183851.56563544.imp@bsdimp.com> In-Reply-To: <20050716.183851.56563544.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200507171041.37737.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Cc: freebsd-current@freebsd.org, cperciva@freebsd.org Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 08:39:40 -0000 Dnia niedziela 17 lipca 2005 02:38, M. Warner Losh napisa=C5=82: > In message: <42D9A190.5060401@freebsd.org> > > Colin Percival writes: > : Mateusz Jedrasik wrote: > : > Also, I dont want to sound "linuxy" here, but it could be nice with a > : > way that ata bus drivers could inform userland programs somehow when > : > the tray of a cd/dvd has closed - so it would be possible to automount > : > stuff like cd's upon closure of tray, and perhaphs upon the pressing = of > : > the eject button, automatic unmounts if the medium is not currently > : > used by any process. > : > : There is already a mechanism available for doing this: devd. I don't > : know if the ata drivers send the necessary messages, and I'm pretty sure > : that there isn't anything in userland which listens for those messages; > : but all of the infrastructure is there. > > Except that there's no way to know when the tray is closed, except > polling... > > Warner Ok, what about the rest of the stuff? I have now located also a powerd error, (bug?) mainly the frequencies picke= d=20 off by acpi are unavailable - this is a p4 1.6Ghz and it seems uncapable of= =20 clocking itself down to 1200Mhz. The levels said to be supported are: dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/22000 1400/19250 1200/9800 1050/8575 1000/13750= =20 900/7350 800/11000 750/6125 600/8250 450/3675 400/5500 300/2450 200/2750=20 150/1225 The ones actually supported are 1400, 1000, 800, 600, 400, 200. The other ones do not work, whether booting from A/C and then switching to= =20 battery, or whether starting on A/C or starting on battery. ttyp1 10:38 # sysctl dev.cpu.0.freq=3D450 dev.cpu.0.freq: 1600 sysctl: dev.cpu.0.freq: Device not configured and in messages: acpi_perf0: Px transition to 1200 failed acpi_perf0: set freq failed, err 6 Any ideas, good people? :-) Cheers, /m. From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 09:11: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 7CAC116A41C for ; Sun, 17 Jul 2005 09:11:54 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE17C43D45 for ; Sun, 17 Jul 2005 09:11:53 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-1.free.fr (Postfix) with ESMTP id 5CB221734D9 for ; Sun, 17 Jul 2005 11:11:52 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6H9BbNd023440; Sun, 17 Jul 2005 11:11:42 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sun, 17 Jul 2005 11:11:28 +0200 User-Agent: KMail/1.8.1 References: <20050716.105849.112624020.imp@bsdimp.com> <20050716.112411.52164710.imp@bsdimp.com> <20050716.184120.61267598.imp@bsdimp.com> In-Reply-To: <20050716.184120.61267598.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507171111.30149.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 09:11:54 -0000 Le Sunday 17 July 2005 02:41, M. Warner Losh a écrit : > > OK. ed(4) is fine. Works great for me. However, there appears to be > some issues with the Ricoh RF5C47x class of bridge chips. I have an > old VAIO that exhibits similar problems to what you describe. I > believe it is the difference between how the TI automatically powers > up the card, and how the Ricoh requires an additional manual step that > we're not doing right now. I'll try to find that step as soon as my > system updates... Its a Pentium 300, so even an installworld takes a > while (esp when you forget to enable soft updates...). Hello, I have rebooted the machine with : hw.cbb.debug="1" in /boot/loader.conf (and also in /etc/sysctl.conf ?) full verbose boot message at : http://herbelot.tfh.free.fr/no_ed/dmesg.noed-cbb.verbose selected diffs from the "working" boot messages : 292a293,295 > cbb0: Found memory at 80000000 > cbb0: Secondary bus is 0 > cbb0: Secondary bus set to 2 subbus 3 316a320,322 > cbb1: Found memory at 80001000 > cbb1: Secondary bus is 0 > cbb1: Secondary bus set to 4 subbus 5 436a443,448 > Status is 0x30000006 > Status is 0x30000410 > cbb1: card inserted: event=0x00000000, state=30000410 > cbb_pcic_socket_enable: > cbb1: cbb_power: 5V As the card was not detected at boot-up, I have extracted, then replugged it : edited /var/log/messages at : http://herbelot.tfh.free.fr/no_ed/messages cbb1: Power not on? pccard1: Card has no functions! cbb1: PC Card card activation failed Status is 0x30000416 cbb_pcic_socket_disable Status is 0x30000410 cbb1: card inserted: event=0x00000006, state=30000410 cbb_pcic_socket_enable: cbb1: cbb_power: 5V Interrupt storm detected on "irq9: cbb0 cbb1+++"; throttling interrupt source pccard1: CIS version PCCARD 2.0 or 2.1 pccard1: CIS info: CNet, CN40BC Ethernet, D, NE2000 pccard1: Manufacturer code 0xffffffff, product 0xffffffff pccard1: function 0: network adapter, ccr addr 3f8 mask 3 pccard1: function 0, config table entry 32: I/O card; irq mask ffff; iomask 5, iospace 0-1f; mwait_required io8 io16 irqlevel cbb_pcic_socket_enable: ed1: at port 0x100-0x11f irq 9 function 0 config 32 on pccard1 ed1: [GIANT-LOCKED] ed1: CIS MAC 00:00:00:00:00:00 ed1: ROM mac 00:80:ad:8e:82:60 ed1: bpf attached ed1: Ethernet address: 00:80:ad:8e:82:60 ed1: if_start running deferred for Giant ed1: type NE2000 (16 bit) Now, the card is working "normally" > > Warner TfH From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 10: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 34A8C16A41F for ; Sun, 17 Jul 2005 10:30:22 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2748C43D46 for ; Sun, 17 Jul 2005 10:30:20 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Du6PR-0002y2-1C for freebsd-current@freebsd.org; Sun, 17 Jul 2005 12:30:09 +0200 Received: from wd197.bfl19.vectant.ne.jp ([210.131.181.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 12:30:09 +0200 Received: from davidsmith by wd197.bfl19.vectant.ne.jp with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 12:30:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: davidsmith@acm.org (David D. Smith) Date: Sun, 17 Jul 2005 19:04:34 +0900 Organization: Only myself Lines: 645 Message-ID: <87ackliw99.fsf@exponent.dds.no-ip.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: wd197.bfl19.vectant.ne.jp X-GPG-Fingerprint: CE01 474D B8C6 CDE5 FA32 6DC9 1091 8EB9 E651 1C7E Mail-Followup-To: Mail-Copies-To: nobody Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEUVFBE0KB9aRDRvRDSERTqcXE2KZlOytLFZATVYAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1AESFxQCW8JBsQAAAdFJREFUeNp11MFyozAMAFCRw+41dmbSazFTci4C9gOw8wEbm3uToF63PSS/X4kQbJJZ5aYXydaAgOs9vpUy1xgw54FDP8OYB1g9wfoGsH2ArykP2ecSXmfYLuBy7wSgdil8JbBNIVcSI6xVAheVjaK4UGW7CNyJs5WuBLOXCB8CxaFAjUU+HQLTEVpjwNB4rJROoUAMwYUQPKagVB3ugUp9RtAJ5P+D9xTSVu86BZzSByyq9FaZQN+HQ65VtfkTJ9eIBQ581/aMpt6noNGgsygx9DOcuKJDdB5l1OHvDL5CzDWD77DuhtjqfJIzrPOua0LXtDMMh9rXNjhv5cZv8VaXfhyQKwSaCNcg4LnCCewSkAE5a53j4RMY0AXvrbfWO6quKfDR1ra1dQ2V6QuHNRcE4jloAdcjHaSPxT3RLoUL0Zn/TPWeji+LNShpsHuytqePX4u3fUMDT2E7oleIT5D3aUVDsNYSVQC/I/yDVXmSEftTPu0bTIu2MmaQx1uZHLIIAMboMvR0Usasx0NmqIzm6+baHG+9bm+JVEjkXHCUTRxhXMBNizcbAWAH02KuuA9xui3vCzx9EqBkaPl3hIcYS0gGf4xyzD8VyGdE8vPC/wD2qUwW+F1N3QAAAABJRU5ErkJggg== Emacs: resistance is futile; you will be assimilated and byte-compiled. User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) Cancel-Lock: sha1:N3gn1S3pEqgTgCqa632m7XNMYos= Sender: news Subject: Improving uscanner X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 10:30:22 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Transfer-Encoding: quoted-printable Hello! I'm new to FreeBSD but eager to work and read! I want to get my Epson PX-A550 (CX-4600 outside of Japan) device working as both a printer and a scanner at the same time, so I started working on uscanner.c taking the advice from a few threads on -current talking about the existing problem. Those threads are: http://thread.gmane.org/gmane.os.freebsd.current/69777 http://thread.gmane.org/gmane.os.freebsd.current/52610 http://thread.gmane.org/gmane.os.freebsd.current/33890 I modified uscanner's USB_ATTACH and USB_MATCH to be more like ulpt's. My patch for these is the first attachment to this mail. This seems to work well as I can now plug-in the device and see both devices created successfully, but if I attempt to write to the ulpt device, I inevitably get a panic. I've been trying to debug the panic; backtrace along with log of my kgdb session is the second attachment. AFAICS the crash is because of the sc_iface being incomplete, particularly sc_iface->device being set to NULL, but I can't tell how this situation is coming about and I don't have a second machine to step through the running kernel and retrieve better information. I also have quite a bit of debugging output from the USB layer captured but nothing seems anymore helpful than the backtrace, yet I will happily provide that info if anyone is interested. M. Warner Losh claimed to be working on this problem on 2005/05/31. Could you tell me how you were going about this problem? I have been trying to dig through the heart of the USB code to find the reason the simple patch to uscanner does not suffice but without a debugger it is taking me a very long time to do alone. Thanks, =2D-=20 David D. Smith A man without doubt is a monster. --=-=-= Content-Disposition: attachment Content-Description: uscanner.c.patch cd /tmp/ diff -Naur /tmp/uscanner.c.orig /tmp/uscanner.c --- /tmp/uscanner.c.orig Sun Jul 17 18:27:28 2005 +++ /tmp/uscanner.c Sun Jul 17 18:31:11 2005 @@ -78,6 +78,8 @@ #include "usbdevs.h" +#define USCANNER_CLASS_SCANJET 0x10 + #ifdef USB_DEBUG #define DPRINTF(x) if (uscannerdebug) logprintf x #define DPRINTFN(n,x) if (uscannerdebug>(n)) logprintf x @@ -205,6 +207,7 @@ {{ USB_VENDOR_EPSON, USB_PRODUCT_EPSON_3200 }, USC_KEEP_OPEN }, {{ USB_VENDOR_EPSON, USB_PRODUCT_EPSON_GT9700F }, USC_KEEP_OPEN }, {{ USB_VENDOR_EPSON, USB_PRODUCT_EPSON_GT9300UF }, 0 }, + {{ USB_VENDOR_EPSON, USB_PRODUCT_EPSON_CX4600 }, 0 }, /* UMAX */ {{ USB_VENDOR_UMAX, USB_PRODUCT_UMAX_ASTRA1220U }, 0 }, @@ -298,12 +301,20 @@ USB_MATCH(uscanner) { USB_MATCH_START(uscanner, uaa); - - if (uaa->iface != NULL) + usb_interface_descripor_t *id; + + if (uaa->iface == NULL) return UMATCH_NONE; - return (uscanner_lookup(uaa->vendor, uaa->product) != NULL ? - UMATCH_VENDOR_PRODUCT : UMATCH_NONE); + id = usbd_get_interface_descriptor(uaa->iface); + if (id != NULL && + (id->bInterfaceClass == UICLASS_VENDOR || + id->bInterfaceClass == UICLASS_UNSPEC || + id->bInterfaceClass == UICLASS_CDC_DATA || + id->bInterfaceClass == USCANNER_CLASS_SCANJET)) + return (uscanner_lookup(uaa->vendor, uaa->product) != NULL ? + UMATCH_VENDOR_PRODUCT : UMATCH_NONE); + return UMATCH_NONE; } USB_ATTACH(uscanner) Diff finished at Sun Jul 17 18:31:14 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable Content-Description: vmcore.17.gdb.log Current directory is /usr/src/sys/i386/compile/EXPONENT/ [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] 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 condition= s. 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:159 (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc067b7ee in boot (howto=3D260) at ../../../kern/kern_shutdown.c:410 #2 0xc067baf5 in panic (fmt=3D0xc08e84c0 "%s") at ../../../kern/kern_shutd= own.c:566 #3 0xc089929d in trap_fatal (frame=3D0xd068f940, eva=3D0) at ../../../i386/i386/trap.c:817 #4 0xc0898fc0 in trap_pfault (frame=3D0xd068f940, usermode=3D0, eva=3D4) at ../../../i386/i386/trap.c:735 #5 0xc0898b8c in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 4, tf_esi =3D -= 1048176128, tf_ebp =3D -798426708, tf_isp =3D -798426772, tf_ebx =3D 0, tf_= edx =3D -1046252836, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err = =3D 0, tf_eip =3D -1067432071, tf_cs =3D 8, tf_eflags =3D 66178, tf_esp =3D= 0, tf_ss =3D 5000}) at ../../../i386/i386/trap.c:425 #6 0xc088a17a in calltrap () at ../../../i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0x00000004 in ?? () #11 0xc1861a00 in ?? () #12 0xd068f9ac in ?? () #13 0xd068f96c in ?? () #14 0x00000000 in ?? () #15 0xc1a372dc in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 #25 0xc06ea1a9 in vn_open_cred (ndp=3D0xd068fbd8, flagp=3D0xd068fcd8, cmode= =3D0,=20 cred=3D0xc1861400, fdidx=3D0) at vnode_if.h:228 #26 0xc06e9d5b in vn_open (ndp=3D0x0, flagp=3D0x0, cmode=3D0, fdidx=3D0) at ../../../kern/vfs_vnops.c:91 #27 0xc06e2c4b in kern_open (td=3D0xc181d600, path=3D0x0, pathseg=3DUIO_USE= RSPACE,=20 flags=3D2051, mode=3D0) at ../../../kern/vfs_syscalls.c:957 #28 0xc06e2b3a in open (td=3D0x0, uap=3D0x0) at ../../../kern/vfs_syscalls.= c:926 #29 0xc0899649 in syscall (frame=3D {tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 134518742, tf_e= si =3D -1077940767, tf_ebp =3D -1077952088, tf_isp =3D -798425740, tf_ebx = =3D 134523168, tf_edx =3D -1077943808, tf_ecx =3D 0, tf_eax =3D 5, tf_trapn= o =3D 12, tf_err =3D 2, tf_eip =3D 672102075, tf_cs =3D 31, tf_eflags =3D 6= 42, tf_esp =3D -1077952132, tf_ss =3D 47}) at ../../../i386/i386/trap.c:1009 #30 0xc088a1cf in Xint0x80_syscall () at ../../../i386/i386/exception.s:201 #31 0x0000002f in ?? () #32 0x0000002f in ?? () #33 0x0000002f in ?? () #34 0x080497d6 in ?? () #35 0xbfbfede1 in ?? () #36 0xbfbfc1a8 in ?? () #37 0xd068fd74 in ?? () #38 0x0804a920 in ?? () #39 0xbfbfe200 in ?? () #40 0x00000000 in ?? () #41 0x00000005 in ?? () #42 0x0000000c in ?? () #43 0x00000002 in ?? () #44 0x280f76bb in ?? () #45 0x0000001f in ?? () #46 0x00000282 in ?? () #47 0xbfbfc17c in ?? () #48 0x0000002f in ?? () #49 0x00000000 in ?? () #50 0x00000000 in ?? () #51 0x00000000 in ?? () #52 0x00000000 in ?? () #53 0x04d72000 in ?? () #54 0xc181c388 in ?? () #55 0xc181d600 in ?? () #56 0xd068f53c in ?? () #57 0xd068f524 in ?? () #58 0xc12c2d80 in ?? () #59 0xc068e326 in sched_switch (td=3D0xbfbfede1, newtd=3D0x804a920, flags= =3DCannot access memory at address 0xbfbfc1b8 ) at ../../../kern/sched_4bsd.c:881 Previous frame inner to this frame (corrupt stack?) #1 0xc067b7ee in boot (howto=3D260) at ../../../kern/kern_shutdown.c:410 #2 0xc067baf5 in panic (fmt=3D0xc08e84c0 "%s") at ../../../kern/kern_shutd= own.c:566 #3 0xc089929d in trap_fatal (frame=3D0xd068f940, eva=3D0) at ../../../i386/i386/trap.c:817 #2 0xc067baf5 in panic (fmt=3D0xc08e84c0 "%s") at ../../../kern/kern_shutd= own.c:566 #3 0xc089929d in trap_fatal (frame=3D0xd068f940, eva=3D0) at ../../../i386/i386/trap.c:817 #4 0xc0898fc0 in trap_pfault (frame=3D0xd068f940, usermode=3D0, eva=3D4) at ../../../i386/i386/trap.c:735 #5 0xc0898b8c in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 4, tf_esi =3D -= 1048176128, tf_ebp =3D -798426708, tf_isp =3D -798426772, tf_ebx =3D 0, tf_= edx =3D -1046252836, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err = =3D 0, tf_eip =3D -1067432071, tf_cs =3D 8, tf_eflags =3D 66178, tf_esp =3D= 0, tf_ss =3D 5000}) at ../../../i386/i386/trap.c:425 #6 0xc088a17a in calltrap () at ../../../i386/i386/exception.s:140 Current language: auto; currently asm #7 0x00000018 in ?? () #8 0x00000010 in ?? () (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc067b7ee in boot (howto=3D260) at ../../../kern/kern_shutdown.c:410 #2 0xc067baf5 in panic (fmt=3D0xc08e84c0 "%s") at ../../../kern/kern_shutd= own.c:566 #3 0xc089929d in trap_fatal (frame=3D0xd068f940, eva=3D0) at ../../../i386/i386/trap.c:817 #4 0xc0898fc0 in trap_pfault (frame=3D0xd068f940, usermode=3D0, eva=3D4) at ../../../i386/i386/trap.c:735 #5 0xc0898b8c in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 4, tf_esi =3D -= 1048176128, tf_ebp =3D -798426708, tf_isp =3D -798426772, tf_ebx =3D 0, tf_= edx =3D -1046252836, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err = =3D 0, tf_eip =3D -1067432071, tf_cs =3D 8, tf_eflags =3D 66178, tf_esp =3D= 0, tf_ss =3D 5000}) at ../../../i386/i386/trap.c:425 #6 0xc088a17a in calltrap () at ../../../i386/i386/exception.s:140 #7 0x00000018 in ?? () #8 0x00000010 in ?? () #9 0x00000010 in ?? () #10 0x00000004 in ?? () #11 0xc1861a00 in ?? () #12 0xd068f9ac in ?? () #13 0xd068f96c in ?? () #14 0x00000000 in ?? () #15 0xc1a372dc in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x0000000c in ?? () #19 0x00000000 in ?? () #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 #25 0xc06ea1a9 in vn_open_cred (ndp=3D0xd068fbd8, flagp=3D0xd068fcd8, cmode= =3D0,=20 cred=3D0xc1861400, fdidx=3D0) at vnode_if.h:228 #26 0xc06e9d5b in vn_open (ndp=3D0x0, flagp=3D0x0, cmode=3D0, fdidx=3D0) at ../../../kern/vfs_vnops.c:91 #27 0xc06e2c4b in kern_open (td=3D0xc181d600, path=3D0x0, pathseg=3DUIO_USE= RSPACE,=20 flags=3D2051, mode=3D0) at ../../../kern/vfs_syscalls.c:957 #28 0xc06e2b3a in open (td=3D0x0, uap=3D0x0) at ../../../kern/vfs_syscalls.= c:926 #29 0xc0899649 in syscall (frame=3D {tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 134518742, tf_e= si =3D -1077940767, tf_ebp =3D -1077952088, tf_isp =3D -798425740, tf_ebx = =3D 134523168, tf_edx =3D -1077943808, tf_ecx =3D 0, tf_eax =3D 5, tf_trapn= o =3D 12, tf_err =3D 2, tf_eip =3D 672102075, tf_cs =3D 31, tf_eflags =3D 6= 42, tf_esp =3D -1077952132, tf_ss =3D 47}) at ../../../i386/i386/trap.c:1009 #30 0xc088a1cf in Xint0x80_syscall () at ../../../i386/i386/exception.s:201 #31 0x0000002f in ?? () #32 0x0000002f in ?? () #33 0x0000002f in ?? () #34 0x080497d6 in ?? () #35 0xbfbfede1 in ?? () #36 0xbfbfc1a8 in ?? () #37 0xd068fd74 in ?? () #38 0x0804a920 in ?? () #39 0xbfbfe200 in ?? () #40 0x00000000 in ?? () #41 0x00000005 in ?? () #42 0x0000000c in ?? () #43 0x00000002 in ?? () #44 0x280f76bb in ?? () #45 0x0000001f in ?? () #46 0x00000282 in ?? () #47 0xbfbfc17c in ?? () #48 0x0000002f in ?? () #49 0x00000000 in ?? () #50 0x00000000 in ?? () #51 0x00000000 in ?? () #52 0x00000000 in ?? () #53 0x04d72000 in ?? () #54 0xc181c388 in ?? () #55 0xc181d600 in ?? () #56 0xd068f53c in ?? () #57 0xd068f524 in ?? () #58 0xc12c2d80 in ?? () #59 0xc068e326 in sched_switch (td=3D0xbfbfede1, newtd=3D0x804a920, flags= =3DCannot access memory at address 0xbfbfc1b8 ) at ../../../kern/sched_4bsd.c:881 (kgdb) up #9 0x00000010 in ?? () (kgdb) up #10 0x00000004 in ?? () (kgdb) up #11 0xc1861a00 in ?? () (kgdb) up #12 0xd068f9ac in ?? () (kgdb) up #13 0xd068f96c in ?? () (kgdb) up #14 0x00000000 in ?? () (kgdb) up #15 0xc1a372dc in ?? () (kgdb) up #16 0x00000000 in ?? () (kgdb) up #17 0x00000000 in ?? () (kgdb) up #18 0x0000000c in ?? () (kgdb) up #19 0x00000000 in ?? () (kgdb) up #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 Current language: auto; currently c (kgdb) up #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 (kgdb) up #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) up #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 (kgdb) up #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 (kgdb) up #25 0xc06ea1a9 in vn_open_cred (ndp=3D0xd068fbd8, flagp=3D0xd068fcd8, cmode= =3D0,=20 cred=3D0xc1861400, fdidx=3D0) at vnode_if.h:228 (kgdb) up #26 0xc06e9d5b in vn_open (ndp=3D0x0, flagp=3D0x0, cmode=3D0, fdidx=3D0) at ../../../kern/vfs_vnops.c:91 (kgdb) up #27 0xc06e2c4b in kern_open (td=3D0xc181d600, path=3D0x0, pathseg=3DUIO_USE= RSPACE,=20 flags=3D2051, mode=3D0) at ../../../kern/vfs_syscalls.c:957 #26 0xc06e9d5b in vn_open (ndp=3D0x0, flagp=3D0x0, cmode=3D0, fdidx=3D0) at ../../../kern/vfs_vnops.c:91 #25 0xc06ea1a9 in vn_open_cred (ndp=3D0xd068fbd8, flagp=3D0xd068fcd8, cmode= =3D0,=20 cred=3D0xc1861400, fdidx=3D0) at vnode_if.h:228 #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 #25 0xc06ea1a9 in vn_open_cred (ndp=3D0xd068fbd8, flagp=3D0xd068fcd8, cmode= =3D0,=20 cred=3D0xc1861400, fdidx=3D0) at vnode_if.h:228 #24 0xc0634a8c in spec_vnoperate (ap=3D0x0) at ../../../fs/specfs/spec_vnop= s.c:118 #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 A syntax error in expression, near `'. Attempt to use a type name as an expression No symbol "ulpt_softc" in current context. $1 =3D 0xc1a372dc $2 =3D 0xc1a372dc (kgdb) print sc_iface No symbol "sc_iface" in current context. (kgdb) print sc->sc_out $3 =3D 4 (kgdb) p sc->sc_dying $4 =3D 0 '\0' (kgdb) p sc->sc_state $5 =3D 4 '\004' (kgdb) p ulpt_status(sc) You can't do that without a process to debug. (kgdb) p flags=20 $6 =3D 0 '\0' (kgdb) p sc->sc_refcnt $7 =3D 1 (kgdb) p sc->sc_flags $8 =3D 0 '\0' (kgdb) p sc->sc_state $9 =3D 4 '\004' (kgdb) p sc->sc_iface $10 =3D 0xc1a372dc (kgdb) p sc->sc_out $11 =3D 4 (kgdb) p sc->sc_out_pipe $12 =3D 0x0 (kgdb) p sc->sc_iface->index $13 =3D 0 (kgdb) p sc->sc_iface->altindex $14 =3D 0 (kgdb) p sc->sc_iface->pipes $15 =3D {lh_first =3D 0x0} (kgdb) p sc->sc_iface->device $16 =3D (struct usbd_device *) 0x0 (kgdb) p dev $17 =3D (struct cdev *) 0x0 (kgdb) p flag $18 =3D 2051 (kgdb) p dev $19 =3D (struct cdev *) 0x0 (kgdb) p (dev =3D=3D NULL) No symbol "NULL" in current context. (kgdb) p (dev =3D=3D 0) $20 =3D 1 (kgdb) p sc $21 =3D (struct ulpt_softc *) 0xc1861a00 (kgdb) p minor(dv) No symbol "dv" in current context. (kgdb) p minor(dev) You can't do that without a process to debug. (kgdb) p unit No symbol "unit" in current context. (kgdb) p cd_ndevs No symbol "cd_ndevs" in current context. (kgdb) p ulpt_cd.cd_ndevs No symbol "ulpt_cd" in current context. (kgdb) p ulpt_cd No symbol "ulpt_cd" in current context. (kgdb) p sc $22 =3D (struct ulpt_softc *) 0xc1861a00 (kgdb) p sc->sc_iface $23 =3D 0xc1a372dc (kgdb) p sc->sc_iface->device $24 =3D (struct usbd_device *) 0x0 (kgdb) p sc->sc_iface->endpoints $25 =3D (struct usbd_endpoint *) 0xc145bb70 (kgdb) p sc->sc_iface->device->cdesc Cannot access memory at address 0x4c (kgdb) p &sc->sc_iface->device $26 =3D (struct usbd_device **) 0xc1a372dc (kgdb) p *sc->sc_iface->device Cannot access memory at address 0x0 (kgdb) p sc->sc_iface->device->ifaces Cannot access memory at address 0x34 (kgdb) p sc->sc_iface->device->cdesc Cannot access memory at address 0x4c (kgdb) p sc->sc_iface->idesc $27 =3D (usb_interface_descriptor_t *) 0x0 (kgdb) p sc->sc_iface->ifaceidx There is no member named ifaceidx. (kgdb) p sc->sc_iface->index $28 =3D 0 (kgdb) p sc->sc_iface->endpoints $29 =3D (struct usbd_endpoint *) 0xc145bb70 (kgdb) p *sc->sc_iface->endpoints $30 =3D {edesc =3D 0x61007768, refcnt =3D 6910051} (kgdb) p sc->sc_iface->endpoints->edesc $31 =3D (usb_endpoint_descriptor_t *) 0x61007768 (kgdb) p *sc->sc_iface->endpoints->edesc Cannot access memory at address 0x61007768 (kgdb) p sc->sc_iface->device->speed Cannot access memory at address 0xb (kgdb) p sc->sc_iface->idesc $32 =3D (usb_interface_descriptor_t *) 0x0 (kgdb) p *sc->sc_iface->idesc Cannot access memory at address 0x0 (kgdb) p *sc->sc_in Cannot access memory at address 0x83 (kgdb) p sc->sc_in $33 =3D 131 (kgdb) p sc->sc_out $34 =3D 4 (kgdb) p sc->sc_ifaceno $35 =3D 1 (kgdb) p sc->sc_udev $36 =3D 0xc185ed00 (kgdb) p *sc->sc_udev $37 =3D {bus =3D 0xc13ea000, default_pipe =3D 0xc1860380, address =3D 2 '\0= 02',=20 config =3D 1 '\001', depth =3D 1 '\001', speed =3D 2 '\002', self_powered= =3D 1 '\001',=20 power =3D 2, langid =3D 1033, cookie =3D {cookie =3D 6}, powersrc =3D 0xc= 1403044,=20 myhub =3D 0xc13d9a80, myhsport =3D 0x0, def_ep =3D {edesc =3D 0xc185ed2c,= refcnt =3D 1},=20 def_ep_desc =3D {bLength =3D 7 '\a', bDescriptorType =3D 5 '\005',=20 bEndpointAddress =3D 0 '\0', bmAttributes =3D 0 '\0', wMaxPacketSize = =3D "\b",=20 bInterval =3D 0 '\0'}, ifaces =3D 0xc1a36b00, ddesc =3D {bLength =3D 18= '\022',=20 bDescriptorType =3D 1 '\001', bcdUSB =3D "\020\001", bDeviceClass =3D 0= '\0',=20 bDeviceSubClass =3D 0 '\0', bDeviceProtocol =3D 0 '\0', bMaxPacketSize = =3D 8 '\b',=20 idVendor =3D "=C2=B8\004", idProduct =3D "\016\b", bcdDevice =3D "\000\= 001",=20 iManufacturer =3D 1 '\001', iProduct =3D 2 '\002', iSerialNumber =3D 3 = '\003',=20 bNumConfigurations =3D 1 '\001'}, cdesc =3D 0xc1a36b80, quirks =3D 0xc0= 8be8f8,=20 hub =3D 0x0, subdevs =3D 0xc145b0d0, ifacenums =3D 0xc14d7270 ""} (kgdb) p *sc->sc_udev->subdevs $38 =3D 0xc1860400 (kgdb) p sc->sc_udev->subdevs $39 =3D (device_t *) 0xc145b0d0 (kgdb) p *sc->sc_udev->subdevs $40 =3D 0xc1860400 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 (kgdb) p iface $41 =3D 0xc1a372dc (kgdb) p iface->idesc $42 =3D (usb_interface_descriptor_t *) 0x0 #19 0x00000000 in ?? () #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 (kgdb) p iface $43 =3D 0x0 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) p sc->sc_iface $44 =3D 0xc1a372dc (kgdb) p *sc->sc_iface $45 =3D {device =3D 0x0, idesc =3D 0x0, index =3D 0, altindex =3D 0, endpoi= nts =3D 0xc145bb70,=20 priv =3D 0x0, pipes =3D {lh_first =3D 0x0}} #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #20 0xc0604779 in usbd_open_pipe_ival (iface=3D0xc1a372dc, address=3D4 '\00= 4',=20 flags=3D0 '\0', pipe=3D0x0, ival=3D0) at ../../../dev/usb/usbdi.c:199 #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) p up No symbol "up" in current context. (kgdb) up #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 (kgdb) down #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) down #21 0xc0604758 in usbd_open_pipe (iface=3D0x0, address=3D4 '\004', flags=3D= 0 '\0',=20 pipe=3D0x0) at ../../../dev/usb/usbdi.c:183 (kgdb) up #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) up #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 (kgdb) down #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) up #23 0xc0634db2 in spec_open (ap=3D0xd068fa6c) at ../../../fs/specfs/spec_vn= ops.c:207 (kgdb) down #22 0xc05fbbca in ulptopen (dev=3D0x0, flag=3D2051, mode=3D8192, p=3D0xc181= d600) at ../../../dev/usb/ulpt.c:568 (kgdb) p sc->sc_iface $46 =3D 0xc1a372dc (kgdb) p sc->sc_iface->device $47 =3D (struct usbd_device *) 0x0 (kgdb) p sc->sc_iface->pipes $48 =3D {lh_first =3D 0x0} (kgdb) quit Debugger finished --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBC2i0yEJGOueZRHH4RAiYmAKCl3ha6cLqd2H5bC3MVYcCnWIQbpwCfVVPL jk2FWVvm+sqX/nxPqu8Mvxw= =GCDG -----END PGP SIGNATURE----- --==-=-=-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 20:23: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 9340416A41C; Sat, 16 Jul 2005 20:23:24 +0000 (GMT) (envelope-from qemu-l@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0467443D4C; Sat, 16 Jul 2005 20:23:22 +0000 (GMT) (envelope-from qemu-l@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j6GKN8On012001; Sat, 16 Jul 2005 22:23:08 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j6GKN8K5011999; Sat, 16 Jul 2005 22:23:08 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.11.4/8.8.5) id j6GKLNE37316; Sat, 16 Jul 2005 22:21:23 +0200 (CEST) From: Juergen Lock Date: Sat, 16 Jul 2005 22:21:23 +0200 To: Norikatsu Shigemura Message-ID: <20050716222122.A36832@saturn.kn-bremen.de> References: <20050704010715.A36404@saturn.kn-bremen.de> <200507040037.j640bg0v085158@gate.bitblocks.com> <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200507100439.j6A4dlMK074874@sakura.ninth-nine.com> X-Mailman-Approved-At: Sun, 17 Jul 2005 11:41:46 +0000 Cc: Craig Boston , jhb@FreeBSD.org, jeff@FreeBSD.org, qemu-devel@nongnu.org, alc@FreeBSD.org, freebsd-current@FreeBSD.org, Bakul Shah , Juergen Lock Subject: Re: [Qemu-devel] kqemu freebsd host smp problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 20:23:24 -0000 On Sun, Jul 10, 2005 at 01:39:47PM +0900, Norikatsu Shigemura wrote: > On Sun, 03 Jul 2005 17:37:42 -0700 > Bakul Shah wrote: > > Lock writes: > > > Is kqemu and the freebsd wrapper smp aware? I just saw this panic > > > report again, > > > http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050161.html > > > and noticed it apparently happened with an smp kernel. > > My guess is > > .d_flags = D_NEEDGIANT, > > needs to be added to the initializer of kqemu_cdevsw for the > > freebsd-current case. AFAIK this flag ensures only one > > thread can be in this driver at a time (but caveat emptor: I > > don't play in the kernel these days). > > I confirmed that qemu on latest FreeBSD 6-current got more > stability!!, but more little slowly:-( and a panic:-( too. > > > Now I'm testing improved qemu port: > http://tmp.ninth-nine.com/qemu/qemu.20050708-2.port.tar.bz2 > > 1. Merge /dev/kqemu cloning support to kmod_bsd.c. > Obtained from: http://lists.gnu.org/archive/html/qemu-devel/2005-06/msg00135.html > Submitted by: Craig Boston > > > $ fstat /dev/kqemu* > > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME > > nork qemu 33805 5 /dev 168 crw-rw---- #C:0:0x0 rw /dev/kqemu1 > > root qemu 20779 6 /dev 152 crw-rw---- #C:0:0x0 rw /dev/kqemu0 > In this time, I'm installing Windows XP SP2 and FreeBSD 5.4-R. > > 2. Giant-lock kqemu.ko. > Obtained from: http://lists.gnu.org/archive/html/qemu-devel/2005-07/msg00070.html > Suggested by: Bakul Shah > > 3. Add experimental IDE WDMA support. > Obtained from: I forgot:-( Juergen Keil, iirc > Submitted by(AFAIK): Juergen Lock But as i said this patch has problems with FreeBSD guests with atapicam in the kernel, for example FreeSBIE 1.1 misdetects cd0 as da0 and panics with a zero divide fault. > > 4. Utilize BSDMakefile to compile kqemu.ko, and cosmetic change. > Yeah you could do that... > > I contacted a panic. Please check following message. >... Well, I'll leave that to the kernel hackers :) Juergen From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 11:53: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 4136916A41C for ; Sun, 17 Jul 2005 11:53:26 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6F0843D45 for ; Sun, 17 Jul 2005 11:53:25 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so861297wra for ; Sun, 17 Jul 2005 04:53:25 -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=PqtetzeFNB8jmToRjrVrQbyY/qVh5E/j5AJBwClkNouLuZtip8iCWA/2iXynYRVjuFUp1oFijCjTNymfcm/oQvb+d6IBJ6dJRLHzSin71OsqkQJbY7IHP1T/WUuNo2GsbcDYV963zOMJl4KjRyeapA0Z3X1rTbTOdEQ/A1DZFgM= Received: by 10.54.124.3 with SMTP id w3mr74601wrc; Sun, 17 Jul 2005 04:53:25 -0700 (PDT) Received: by 10.54.80.4 with HTTP; Sun, 17 Jul 2005 04:53:25 -0700 (PDT) Message-ID: <4cf221cc050717045319c1f3cf@mail.gmail.com> Date: Sun, 17 Jul 2005 13:53:25 +0200 From: Erik Winge 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: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erik Winge List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 11:53:26 -0000 Hi, After upgrading to 6.0-BETA1 I have started using an Asus ural-bases wireless card. Besides lower performance than with Windows, this driver seems to have some stability issues. I keep getting "Corrupted MAC on input"-messages from scp when copying files. The files I have been testing with are about 5MB in size, and the problem interrupts every one of 4-5 upload attempts. Erik Winge From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 12:46:59 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 0490A16A429 for ; Sun, 17 Jul 2005 12:46:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A657143D49 for ; Sun, 17 Jul 2005 12:46:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id E17C646B7B for ; Sun, 17 Jul 2005 08:46:57 -0400 (EDT) Date: Sun, 17 Jul 2005 13:47:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050717130356.T19319@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Malloc(9) and uma(9) naming consistency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 12:46:59 -0000 Now that libmemstat(3) allows the mechanical retrieval of memory information from the kernel, I will start adapting tools that currently do this monitoring in ad hoc ways to use libmemstat(3) instead. For example, I have patches that caus netstat -mb to use libmemstat(3) instead of separate frobs for retrieving mbuf allocator information. In general, memory types are recognized, found, etc, by name. In the case of uma(9) zones, it is the zone name passed to uma_zcreate(9). In the case of malloc(9), it is the "short description" passed to MALLOC_DEFINE(9). There are several reasons why improved name consistency is desirable -- here are the ones I came up with off-hand: (1) Currently, the output of vmstat -m and vmstat -z is not consistently parseable using scripts. Names contain spaces, may not fit in the available space, etc. (2) As programs begin to look up information "by name", the stability of those names becomes important, as the tools won't be able to find their memory type information if the names are changed. (3) Names sometimes collide, as they're used in multiple places to refer to different memory types. There's at least one instance of this in the NFS code, where a type is used by the client and server code under the same name. (4) Names are sometimes un-informative, not even identifying the kernel subsystem they might be used by. So now is a good time to do a sweep through the kernel and fix these. Here's what I'd specifically like to do: - Convert all spaces to "_"s, or remove them in some cases for consistency with related memory types. This is specifically aimed at addressing (1). - Shorten any long names so that they are 24 characters or less. Maybe 16. This will easy rendering in monitoring interfaces designed for terminals, where every space counts. - Convert all names to use only lower case letters. This is the convention in almost all other system name spaces, and I think it makes sense to do it here. - Generally, limit the characters used in names to alphabet + '_', again in the name of making it easier to parse, render, process, and so on. - Disambiguate colliding names. This requires touching several hundred kernel files, so I'd like to do it in one pass. If there are any specific improvements on these changes that you can think of ("solve this other problem while you're at it!"), please let me know. I'll touch everything but the contrib tree, I think. The target branches for these changes are 6.x and 7.x, although they could be merged to 5.x if there's sufficient interest. I've already had one inquiry about back-porting libmemstat(3) to 5.x, and will investigate it. A hand might be appreciated. :-) Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 12:51: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 E9BA216A41C for ; Sun, 17 Jul 2005 12:51:22 +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 A5D5043D48 for ; Sun, 17 Jul 2005 12:51:22 +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 55B1446B3D; Sun, 17 Jul 2005 08:51:22 -0400 (EDT) Date: Sun, 17 Jul 2005 13:51:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nate Lawson In-Reply-To: <42D9D959.5030304@root.org> Message-ID: <20050717135014.E19319@fledge.watson.org> References: <42D9D959.5030304@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: unnecessary savecore warnings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 12:51:23 -0000 On Sat, 16 Jul 2005, Nate Lawson wrote: > I noticed that in the past few months, savecore has begun complaining if > the bounds file in /var/crash doesn't exist. Can we add it to > /usr/src/etc/Makefile like the corresponding entry for minfree? > > Also, I noticed that /etc/rc.d/savecore has started complaining early in > boot if you have dumpdev="AUTO", giving the message "kenv: unable to get > dumpdev". Of course, it works just fine and detects the slice with > "swap" in /etc/fstab. So the warning is spurious and should be > silenced. I've noticed this also, and see if on my NanoBSD Soekris box. Given that the machine doesn't have a partition set up for dumping, and I don't want its dumps, I'd rather it didn't complain, as that will just cause unnecessary worry and questions. This is similar to the devfs-at-shutdown error. An error message that is a result of a harmless "problem" results in significant concern for end-users, which results in more bug reports, less happy users, etc. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 12:56: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 08FCF16A41C for ; Sun, 17 Jul 2005 12:56:15 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4BB943D45 for ; Sun, 17 Jul 2005 12:56:14 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from [83.237.229.115] (port=38586 helo=[192.168.0.8]) by mx3.mail.ru with esmtp id 1Du8gn-00008j-00; Sun, 17 Jul 2005 16:56:13 +0400 In-Reply-To: <42D6CF2A.7080704@nerdshack.com> References: <42D6CF2A.7080704@nerdshack.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C030FC3-616E-45F3-86D2-6F629E3DBEB2@mail.ru> Content-Transfer-Encoding: 7bit From: Artem Ignatiev Date: Sun, 17 Jul 2005 16:56:07 +0400 To: nj18 X-Mailer: Apple Mail (2.733) Cc: FreeBSD Current Subject: Re: Strange message: Text file busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 12:56:15 -0000 On 15.07.2005, at 0:46, nj18 wrote: > I guess it's a problem about "echo". I am going to compare > /usr/src/bin/echo/echo.c in FreeBSD 5.4. and FreeBSD 4.6. You may wish to consider tcsh/sh sources, since echo is builtin command in most shells. Or try using /bin/echo instead of just echo. From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 14: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 99FBE16A41C; Sun, 17 Jul 2005 14:19:07 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CCB243D49; Sun, 17 Jul 2005 14:19:06 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id B713AB83F; Sun, 17 Jul 2005 16:19:04 +0200 (CEST) Date: Sun, 17 Jul 2005 16:18:37 +0200 From: Dimitry Andric X-Mailer: The Bat! (v3.51.4) Professional X-Priority: 3 (Normal) Message-ID: <9216049.20050717161837@andric.com> To: Roman Neuhauser In-Reply-To: <20050715191122.GA1194@isis.sigpipe.cz> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <20050714191832.GA7462@nowhere> <20050715191122.GA1194@isis.sigpipe.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------10533FB3D1802C9" Cc: Craig Boston , freebsd-current@freebsd.org, Robert Watson Subject: Re: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dimitry Andric List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 14:19:07 -0000 ------------10533FB3D1802C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2005-07-15 at 21:11:23 Roman Neuhauser wrote: >> There's nothing more annoying (to me) than unplugging a Windows 2000 >> machine for half a second to reroute or swap a network cable, then >> finding that all the open connections were terminated because it briefly >> lost its IP address. > The suggestion above got me quite agitated as this behavior of > windows is one of the things I abhor in the software, because it > (the behavior) cuts down usability of the software. Pull the wrong > cable from a switch after you've downloaded most of an iso image, > and you'll see how useful this behavior is. Check this MS KB article for a workaround (WFM, YMMV :) http://support.microsoft.com/kb/q239924/ ------------10533FB3D1802C9 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFC2mi9sF6jCi4glqMRAkK5AKC4Z58MtMf18DBmE2OTFs0EocihJwCg3Cxi cXw7NJAGeZsn0b+TpKhmUYA= =sScd -----END PGP MESSAGE----- ------------10533FB3D1802C9-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 15:39: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 AD4E016A41C for ; Sun, 17 Jul 2005 15:39:50 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D72143D45 for ; Sun, 17 Jul 2005 15:39:49 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <2005071715393801300rhukpe>; Sun, 17 Jul 2005 15:39:49 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6HFdakc002311; Sun, 17 Jul 2005 11:39:36 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6HFdaXw002308; Sun, 17 Jul 2005 11:39:36 -0400 (EDT) (envelope-from rodrigc) Date: Sun, 17 Jul 2005 11:39:36 -0400 From: Craig Rodrigues To: "Wojciech A. Koszek" Message-ID: <20050717153936.GA2218@crodrigues.org> References: <20050716224442.GA87607@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050716224442.GA87607@freebsd.czest.pl> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: [LOR] 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: Sun, 17 Jul 2005 15:39:50 -0000 On Sat, Jul 16, 2005 at 10:44:43PM +0000, Wojciech A. Koszek wrote: > http://FreeBSD.czest.pl/dunstan/kqueuetest.c > > Compile: > [1] gcc kqueuetest.c -o kqueuetest > Run with shell's PID: > [2] ./kqueuetest $$ > [3] Suspend execution with CTRL^Z and move task to > background: bg %1 I can reproduce this LOR: 13 0xc066291c in _mtx_assert (m=0xc1bff600, what=0, file=0xc0878298 "/usr/src/sys/kern/kern_event.c", line=1039) at /usr/src/sys/kern/kern_mutex.c:751 #14 0xc065180e in kqueue_expand (kq=0xc1bff600, fops=0x0, ident=3014, waitok=0) at /usr/src/sys/kern/kern_event.c:1039 #15 0xc0651261 in kqueue_register (kq=0xc1bff600, kev=0xd15f0c40, td=0x0, waitok=0) at /usr/src/sys/kern/kern_event.c:828 #16 0xc065068e in filt_proc (kn=0xc18af6e8, hint=0) at /usr/src/sys/kern/kern_event.c:413 #17 0xc0652644 in knote (list=0xc1b071b4, hint=1073744838, islocked=1) at /usr/src/sys/kern/kern_event.c:1548 #18 0xc0656c24 in fork1 (td=0xc1b034b0, flags=20, pages=0, procp=0xd15f0cd4) at /usr/src/sys/kern/kern_fork.c:696 #19 0xc0655bd8 in fork (td=0xc1b034b0, uap=0xd15f0d04) at /usr/src/sys/kern/kern_fork.c:96 It looks like on line 1545 of kern_event.c, we have a KQ_LOCK(kq);, and then on line 1039, the KQ_NOTOWNED(kq); assertion fails, because the lock is never released. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 16:32: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 32A4516A41C for ; Sun, 17 Jul 2005 16:32:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8F5943D45 for ; Sun, 17 Jul 2005 16:32:33 +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 j6HGSdBZ037388; Sun, 17 Jul 2005 10:28:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Jul 2005 10:29:21 -0600 (MDT) Message-Id: <20050717.102921.08025084.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200507171111.30149.thierry@herbelot.com> References: <20050716.112411.52164710.imp@bsdimp.com> <20050716.184120.61267598.imp@bsdimp.com> <200507171111.30149.thierry@herbelot.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: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 16:32:34 -0000 Thierry, Thanks for the traces and such. I'm happy to report that I've recreated the problem here and I committed what I hope is a fix last night. It fixes me mostly (there's still some interrupt storm messages, however). I need to find some way to get rid of those, or at least discover where they are coming from. I think it is a power up issue related to the card asserting its interrupt line prematurely. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 16:59: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 1FB7E16A41C for ; Sun, 17 Jul 2005 16:59:49 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B440843D49 for ; Sun, 17 Jul 2005 16:59:48 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <2005071716594701300rk85ae>; Sun, 17 Jul 2005 16:59:47 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6HGxjYr001028; Sun, 17 Jul 2005 12:59:46 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6HGxjXU001027; Sun, 17 Jul 2005 12:59:45 -0400 (EDT) (envelope-from rodrigc) Date: Sun, 17 Jul 2005 12:59:45 -0400 From: Craig Rodrigues To: "Wojciech A. Koszek" Message-ID: <20050717165945.GA1017@crodrigues.org> References: <20050716224442.GA87607@freebsd.czest.pl> <20050717153936.GA2218@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717153936.GA2218@crodrigues.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: [LOR] 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: Sun, 17 Jul 2005 16:59:49 -0000 On Sun, Jul 17, 2005 at 11:39:36AM -0400, Craig Rodrigues wrote: > On Sat, Jul 16, 2005 at 10:44:43PM +0000, Wojciech A. Koszek wrote: > > http://FreeBSD.czest.pl/dunstan/kqueuetest.c > > I can reproduce this LOR: > > It looks like on line 1545 of kern_event.c, we have a KQ_LOCK(kq);, > and then on line 1039, the KQ_NOTOWNED(kq); assertion fails, because > the lock is never released. Can you try this patch: --- /usr/src/sys/kern/kern_event.c.orig Sun Jul 17 12:32:58 2005 +++ /usr/src/sys/kern/kern_event.c Sun Jul 17 12:41:54 2005 @@ -410,7 +410,15 @@ kev.fflags = kn->kn_sfflags; kev.data = kn->kn_id; /* parent */ kev.udata = kn->kn_kevent.udata; /* preserve udata */ + + if (kn->kn_status & KN_HASKQLOCK) + KQ_UNLOCK(kn->kn_kq); + error = kqueue_register(kn->kn_kq, &kev, NULL, 0); + + if (kn->kn_status & KN_HASKQLOCK) + KQ_LOCK(kn->kn_kq); + if (error) kn->kn_fflags |= NOTE_TRACKERR; } I don't get the crash any more, but sometimes I get this LOR in dmesg: lock order reversal 1st 0xc1b0aaa4 process lock (process lock) @ /usr/src/sys/kern/kern_fork.c:690 2nd 0xc092dba0 allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:229 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0943620,c0943710,c08eb0ac) at kdb_backtrace+0x29 witness_checkorder(c092dba0,1,c087a870,e5) at witness_checkorder+0x564 _sx_slock(c092dba0,c087a870,e5,c18af2a8,c18af220) at _sx_slock+0x50 pfind(36c,c18af2a8,d15d4c50,c18af24c,d15d4c24) at pfind+0x1c filt_procattach(c18af220,0,fffffffb,0,0) at filt_procattach+0x16 kqueue_register(c1b14900,d15d4c3c,0,0,36c) at kqueue_register+0x5c3 filt_proc(c18af2a8,4000036c) at filt_proc+0xcc knote(c1b0abf0,4000036c,1,d15d4cc0,d15d4cb0) at knote+0x98 fork1(c18cec80,14,0,d15d4cd4,d15d4d30) at fork1+0xed4 fork(c18cec80,d15d4d04,0,a,246) at fork+0x18 syscall(3b,3b,3b,bfbfea00,14) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 17: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 13AB716A41C for ; Sun, 17 Jul 2005 17:19:16 +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 C824743D45 for ; Sun, 17 Jul 2005 17:19:15 +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 j6HHJEms012552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jul 2005 10:19:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DA9332.2030200@errno.com> Date: Sun, 17 Jul 2005 10:19:46 -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: Erik Winge References: <4cf221cc050717045319c1f3cf@mail.gmail.com> In-Reply-To: <4cf221cc050717045319c1f3cf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 17:19:16 -0000 Erik Winge wrote: > Hi, > > After upgrading to 6.0-BETA1 I have started using an Asus ural-bases > wireless card. > > Besides lower performance than with Windows, this driver seems to have > some stability issues. I keep getting "Corrupted MAC on > input"-messages from scp when copying files. The files I have been > testing with are about 5MB in size, and the problem interrupts every > one of 4-5 upload attempts. The driver has no tx rate control support and defaults to 1Mb/s so you must explicitly set the tx rate to get any reasonable performance. However even when locked to 54M on an 11g channel I never saw tcp netperf performance much more than ~15Mb/s with a strong signal. I never saw data corruption but mostly was testing wpa. In general I wasn't impressed with the device and the driver definitely needs work. Hard to recommend it. Sam From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 18:06: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 1710016A41C for ; Sun, 17 Jul 2005 18:06:37 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF0843D45 for ; Sun, 17 Jul 2005 18:06:35 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j6HIK0GW094438; Sun, 17 Jul 2005 18:20:00 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j6HIJx5P094434; Sun, 17 Jul 2005 18:19:59 GMT (envelope-from dunstan) Date: Sun, 17 Jul 2005 18:19:58 +0000 From: "Wojciech A. Koszek" To: Craig Rodrigues , freebsd-current@freebsd.org Message-ID: <20050717181957.GA94415@freebsd.czest.pl> References: <20050716224442.GA87607@freebsd.czest.pl> <20050717153936.GA2218@crodrigues.org> <20050717165945.GA1017@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717165945.GA1017@crodrigues.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: [LOR] 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: Sun, 17 Jul 2005 18:06:37 -0000 On Sun, Jul 17, 2005 at 12:59:45PM -0400, Craig Rodrigues wrote: > On Sun, Jul 17, 2005 at 11:39:36AM -0400, Craig Rodrigues wrote: > > On Sat, Jul 16, 2005 at 10:44:43PM +0000, Wojciech A. Koszek wrote: > > > http://FreeBSD.czest.pl/dunstan/kqueuetest.c Hi, > Can you try this patch: [..] > > I don't get the crash any more, but sometimes I get this LOR > in dmesg: > Neither panic nor your LOR seems to be repeatable with your patch. Do use use my code to get this message in dmesg? For me, patch fixed the problem. -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 18:20: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 D43F316A41C for ; Sun, 17 Jul 2005 18:20:59 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BDFA43D45 for ; Sun, 17 Jul 2005 18:20:59 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-114-143.hsd1.ma.comcast.net ([66.30.114.143]) by comcast.net (sccrmhc14) with ESMTP id <2005071718204301400mgkcpe>; Sun, 17 Jul 2005 18:20:58 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j6HIKg8b001711; Sun, 17 Jul 2005 14:20:42 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j6HIKfR4001710; Sun, 17 Jul 2005 14:20:41 -0400 (EDT) (envelope-from rodrigc) Date: Sun, 17 Jul 2005 14:20:41 -0400 From: Craig Rodrigues To: "Wojciech A. Koszek" Message-ID: <20050717182041.GA1689@crodrigues.org> References: <20050716224442.GA87607@freebsd.czest.pl> <20050717153936.GA2218@crodrigues.org> <20050717165945.GA1017@crodrigues.org> <20050717181957.GA94415@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717181957.GA94415@freebsd.czest.pl> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: [LOR] 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: Sun, 17 Jul 2005 18:20:59 -0000 On Sun, Jul 17, 2005 at 06:19:58PM +0000, Wojciech A. Koszek wrote: > Neither panic nor your LOR seems to be repeatable with your patch. > Do use use my code to get this message in dmesg? > > For me, patch fixed the problem. Yes, I tried your sample testcase (thanks!). The crash goes away for me too. I only got the LOR once though. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 18:28: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 01D3F16A41C for ; Sun, 17 Jul 2005 18:28:20 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D90F43D49 for ; Sun, 17 Jul 2005 18:28:19 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j6HIftGW094549; Sun, 17 Jul 2005 18:41:55 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j6HIftCp094548; Sun, 17 Jul 2005 18:41:55 GMT (envelope-from dunstan) Date: Sun, 17 Jul 2005 18:41:54 +0000 From: "Wojciech A. Koszek" To: Craig Rodrigues , freebsd-current@freebsd.org Message-ID: <20050717184153.GA94525@freebsd.czest.pl> References: <20050716224442.GA87607@freebsd.czest.pl> <20050717153936.GA2218@crodrigues.org> <20050717165945.GA1017@crodrigues.org> <20050717181957.GA94415@freebsd.czest.pl> <20050717182041.GA1689@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717182041.GA1689@crodrigues.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: [LOR] 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: Sun, 17 Jul 2005 18:28:20 -0000 On Sun, Jul 17, 2005 at 02:20:41PM -0400, Craig Rodrigues wrote: > On Sun, Jul 17, 2005 at 06:19:58PM +0000, Wojciech A. Koszek wrote: > > Neither panic nor your LOR seems to be repeatable with your patch. > > Do use use my code to get this message in dmesg? > > > > For me, patch fixed the problem. > > Yes, I tried your sample testcase (thanks!). No problem. Do you think we could have this fix commited? > The crash goes away for me too. I only got the LOR once though. > Hm.. I'll play with it once again and let you know, if I find something interesting. -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 18:57: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 15E2916A41C for ; Sun, 17 Jul 2005 18:57:56 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D1E43D45 for ; Sun, 17 Jul 2005 18:57:55 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id j6HIuvuU014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jul 2005 20:56:57 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j6HIuuhi014971 for freebsd-current@freebsd.org; Sun, 17 Jul 2005 20:56:56 +0200 (CEST) (envelope-from csaba) Date: Sun, 17 Jul 2005 20:56:56 +0200 From: Csaba Henk To: freebsd-current@freebsd.org Message-ID: <20050717185656.GK73367@beastie.creo.hu> References: <20050717003521.GG73367@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717003521.GG73367@beastie.creo.hu> User-Agent: Mutt/1.5.9i Subject: Re: early panic and dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 18:57:56 -0000 On Sun, Jul 17, 2005 at 02:35:21AM +0200, Csaba Henk wrote: > I tried to install both RELENG-6 and CURRENT, and both kernels behaved > the same way: panicked quite early (before init) with a page fault. Has > anyone met with this phenomena? > > I'd like to show you some fancy backtracks, but as it all happened before > starting init, rc.conf settings won't help me in getting the dump. Well, I still don't know how to get a crash dump in this case. What I could do then is to take a photo of the crash. See http://creo.hu/~csaba/imgp0947-800x600.jpg Maybe someone will find it informative. Cheers, Csaba From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 20:13: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 823C716A41C for ; Sun, 17 Jul 2005 20:13:51 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F01F43D49 for ; Sun, 17 Jul 2005 20:13:50 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id i7so901728wra for ; Sun, 17 Jul 2005 13:13:50 -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=G9vn5dQ+b0s62rPIlQ+bdzs8Zk2K71AXVLVOXnA5L+EhaQU1Y6b3lLP/KiAbymHNzzgKVw0cafeYDbuGyMFMLrc7TusCxwUPfOIaJH8Yirv8fQwxnWv2x8OgPdR3VGBPXgaA0Crh16fz0N0SANhRRASnZbCLwr2yDPJUSj+T9NI= Received: by 10.54.39.74 with SMTP id m74mr161272wrm; Sun, 17 Jul 2005 13:13:49 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Sun, 17 Jul 2005 13:13:49 -0700 (PDT) Message-ID: <47d0403c05071713131a0689ee@mail.gmail.com> Date: Sun, 17 Jul 2005 20:13:49 +0000 From: Ben Kaduk 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: curiousities in 6.0beta1 dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 20:13:51 -0000 Hi all, I recently upgraded to: bash-2.05b$ uname -a FreeBSD prolepsis.math.uiuc.edu 6.0-BETA1 FreeBSD 6.0-BETA1 #2: Sat Jul 16 21:34:06 UTC 2005 =20 kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 from 5.4-Release using a source upgrade, and I noticed a few things in the = dmesg whilst it was booting that struck me as a bit odd. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #2: Sat Jul 16 21:34:06 UTC 2005 kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.50GHz (2492.65-MHz 686-class CP= U) Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 Features=3D0xbfebf9ff Features2=3D0x4400> real memory =3D 1073405952 (1023 MB) avail memory =3D 1037340672 (989 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 [ pci_link1 seems to have an irq here. . . ] pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: on acpi0 pci_link5: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci_link1: Unable to choose an IRQ [ so why does it need to choose an irq here? ] agp0: mem 0xe8000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xfc000000-0xfcffffff,0xf0000000-0xf3ffffff irq 11 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] uhci0: port 0xbf80-0xbf9f irq 11 at dev ice 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 dev ice 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 dev ice 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 0 .0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0b:db:99:e8:c7 cbb0: at device 1.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 1.1 on pci2 fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 46:4f:c0:00:1d:2f:1c:61 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci2: at device 3.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem 0xf4fff800-0xf4ff f9ff,0xf4fff400-0xf4fff4ff irq 9 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acp= i0 sio0: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2492653340 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 sio4: at port 0x3f8-0x3ff irq 11 function 0 config 32 on p ccard0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode acd0: CDRW at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s3a Loading configuration files. kenv: unable to get dumpdev [ if kenv can't get a dumpdev, why do I have kernel dumps on /dev/ad0s2b? ] kernel dumps on /dev/ad0s2b Entropy harvesting: interrupts ethernet point_to_point kickstart . swapon: adding /dev/ad0s2b as swap device Starting file system checks: /dev/ad0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3a: clean, 94930 free (794 frags, 11767 blocks, 0.6% fragmentation= ) /dev/ad0s3e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3e: clean, 126221 free (37 frags, 15773 blocks, 0.0% fragmentation= ) /dev/ad0s3f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3f: clean, 6425441 free (54425 frags, 796377 blocks, 0.7% fragmentation) /dev/ad0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3d: clean, 96590 free (206 frags, 12048 blocks, 0.2% fragmentation= ) Setting hostname: prolepsis.math.uiuc.edu. [ here, on the console I got (but can't find in the logs): ] bfe0: link state changed to UP bfe0: link state changed to DOWN DHCPDISCOVER on bfe0 to 255.255.255.255 port 67 interval 6 [ again, on the console, but not in dmesg -a or the logs ] bfe0: link state changed to UP DHCPOFFER from 130.126.110.10 DHCPREQUEST on bfe0 to 255.255.255.255 port 67 DHCPACK from 130.126.110.10 bound to 130.126.111.24 -- renewal in 1800 seconds. bfe0: flags=3D8843 mtu 1500 options=3D8 inet6 fe80::20b:dbff:fe99:e8c7%bfe0 prefixlen 64 scopeid 0x1 inet 130.126.111.24 netmask 0xfffffc00 ether 00:0b:db:99:e8:c7 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 Additional routing options: . Starting devd. Starting ums0 moused: . hw.acpi.cpu.cx_lowest: C1 -> C1 dhclient bfe0: already running? dhclient bfe0: already running? [ is this related to the console messages above? Presumably I'm double-sta= rting dhclient because it's automatically started somewhere else now that it's not ISC ] Mounting NFS file systems: . Creating and/or trimming log files: . Starting syslogd. Checking for core dump on /dev/ad0s2b... savecore: unable to open bounds file, using 0 savecore: no dumps found ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib /usr /local/lib/compat/pkg a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting usbd. Starting local daemons: . Updating motd . Configuring syscons: blanktime screensaver . Starting sshd. Initial i386 initialization: . Additional ABI support: linux . Starting cron. Local package initialization: . Additional TCP options: . Starting default moused: . Starting background file system checks in 60 seconds. Sun Jul 17 18:52:16 UTC 2005 So I'm confused about the pci_link1 messages and the dhclient stuff. Here's the output of pciconf -lv agp0@pci0:0:0: class=3D0x060000 card=3D0x00000000 chip=3D0x1a308086 rev=3D= 0x04 hdr=3D0 x00 vendor =3D 'Intel Corporation' device =3D '82845/E/MP/MZ Brookdale CPU to I/O Bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0x1a318086 rev=3D= 0x04 hdr=3D0 x01 vendor =3D 'Intel Corporation' device =3D '82845/E/MP/MZ Brookdale CPU to AGP Bridge' class =3D bridge subclass =3D PCI-PCI uhci0@pci0:29:0: class=3D0x0c0300 card=3D0x45418086 chip=3D0x24c2808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller = #1' class =3D serial bus subclass =3D USB uhci1@pci0:29:1: class=3D0x0c0300 card=3D0x45418086 chip=3D0x24c4808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller = #2' class =3D serial bus subclass =3D USB uhci2@pci0:29:2: class=3D0x0c0300 card=3D0x45418086 chip=3D0x24c7808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller = #3' class =3D serial bus subclass =3D USB ehci0@pci0:29:7: class=3D0x0c0320 card=3D0x013e1028 chip=3D0x24cd808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI Control= ler' class =3D serial bus subclass =3D USB pcib2@pci0:30:0: class=3D0x060400 card=3D0x00000000 chip=3D0x2448808= 6 rev=3D0x 83 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Br= idge ' class =3D bridge subclass =3D PCI-PCI isab0@pci0:31:0: class=3D0x060100 card=3D0x00000000 chip=3D0x24cc808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DBM (ICH4-M) LPC Interface Bridge' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:31:1: class=3D0x01018a card=3D0x45418086 chip=3D0x24ca808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DBM (ICH4-M) UltraATA/100 EIDE Controller' class =3D mass storage subclass =3D ATA pcm0@pci0:31:5: class=3D0x040100 card=3D0x013e1028 chip=3D0x24c58086 rev=3D= 0x03 hdr=3D0 x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controll= er' class =3D multimedia subclass =3D audio none0@pci0:31:6: class=3D0x070300 card=3D0x4c21134d chip=3D0x24c6808= 6 rev=3D0x 03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controll= er' class =3D simple comms subclass =3D generic modem nvidia0@pci1:0:0: class=3D0x030000 card=3D0x01791028 chip=3D0x028610d= e rev=3D0x a1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'GeForce4 Ti 4200 Go AGP 8x [NV28]' class =3D display subclass =3D VGA bfe0@pci2:0:0: class=3D0x020000 card=3D0x81271028 chip=3D0x440114e4 rev=3D= 0x01 hdr=3D0 x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM4401 10/100 Integrated Ethernet Controller' class =3D network subclass =3D ethernet cbb0@pci2:1:0: class=3D0x060700 card=3D0x013e1028 chip=3D0xac44104c rev=3D= 0x02 hdr=3D0 x02 vendor =3D 'Texas Instruments (TI)' device =3D 'PCI4510SDFSDFSD PC Card Controller SDFSDAFSADFSDAFSDAF' class =3D bridge subclass =3D PCI-CardBus fwohci0@pci2:1:1: class=3D0x0c0010 card=3D0x013e1028 chip=3D0x8029104= c rev=3D0x 00 hdr=3D0x00 vendor =3D 'Texas Instruments (TI)' device =3D '??? OHCI Compliant IEEE-1394 FireWire Controller' class =3D serial bus subclass =3D FireWire none1@pci2:3:0: class=3D0x028000 card=3D0x00011028 chip=3D0x432414e4 rev=3D= 0x02 hdr=3D0 x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM4309 802.11a/b/g Wireless LAN Controller' class =3D network Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 22:16: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 361A216A41C for ; Sun, 17 Jul 2005 22:16:24 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B6FF43D45 for ; Sun, 17 Jul 2005 22:16:23 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j6HMEqmH069614 for ; Mon, 18 Jul 2005 00:14:52 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j6HMEpCf069611 for ; Mon, 18 Jul 2005 00:14:51 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Mon, 18 Jul 2005 00:14:51 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: current@freebsd.org Message-ID: <20050718000738.F69475@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 22:16:24 -0000 I think the errno(i.e. intro(2)) page needs to be updated. There is some information that doesn't "feel" current: - for EFBIG (#27) - I hope the limit is > 2.1E9 on ufs2 :) - for EMFILE - is the limit on open files really 64 per process? Maybe there are others, but I only spotted these. (And of course, tuning(7) also has some historical figures) -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 22:37: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 A218E16A41C for ; Sun, 17 Jul 2005 22:37:37 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id E264043D46 for ; Sun, 17 Jul 2005 22:37:36 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-a098.otenet.gr [212.205.215.98]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j6HMbUrg012719; Mon, 18 Jul 2005 01:37:31 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j6HMbTKn001597; Mon, 18 Jul 2005 01:37:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j6HMbTot001596; Mon, 18 Jul 2005 01:37:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 18 Jul 2005 01:37:29 +0300 From: Giorgos Keramidas To: Ivan Voras Message-ID: <20050717223729.GD1291@gothmog.gr> References: <20050718000738.F69475@geri.cc.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050718000738.F69475@geri.cc.fer.hr> Cc: freebsd-current@freebsd.org Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 22:37:37 -0000 On 2005-07-18 00:14, Ivan Voras wrote: > I think the errno(i.e. intro(2)) page needs to be updated. There is > some information that doesn't "feel" current: > > - for EFBIG (#27) - I hope the limit is > 2.1E9 on ufs2 :) The maximum file size is probably a property of the underlying filesystem, so I don't think it should be explicitly defined as a value like 2.1E9; especially since this value is inaccurate, because it isn't equal to the value 2^31, which is probably what was meant. I think that instead of trying to guess a value that would be correct for many filesystems, but obviously wrong for others, we should just remove the explicit size. > - for EMFILE - is the limit on open files really 64 per process? Not necessarily. It's what kern.maxfilesperproc says. On my CURRENT system that is a little lower than kern.maxfiles: # gothmog:/home/giorgos$ sysctl -a | grep files # kern.maxfiles: 8072 # kern.maxfilesperproc: 7264 > (And of course, tuning(7) also has some historical figures) Can you help us identify them? - Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 23:16: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 DA7B316A41C; Sun, 17 Jul 2005 23:16:11 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4735643D45; Sun, 17 Jul 2005 23:16:11 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j6HNEdHL070411; Mon, 18 Jul 2005 01:14:39 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j6HNEdtb070408; Mon, 18 Jul 2005 01:14:39 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Mon, 18 Jul 2005 01:14:39 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: Giorgos Keramidas In-Reply-To: <20050717223729.GD1291@gothmog.gr> Message-ID: <20050718004649.U70085@geri.cc.fer.hr> References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223729.GD1291@gothmog.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 23:16:12 -0000 On Mon, 18 Jul 2005, Giorgos Keramidas wrote: > On 2005-07-18 00:14, Ivan Voras wrote: >> I think the errno(i.e. intro(2)) page needs to be updated. There is >> some information that doesn't "feel" current: >> >> - for EFBIG (#27) - I hope the limit is > 2.1E9 on ufs2 :) > > I think that instead of trying to guess a value that would be correct for > many filesystems, but obviously wrong for others, we should just remove the > explicit size. Agreed, but since UFS2 is The Filesystem for FreeBSD for the forseeable future, it makes sense to state something like "the limit is X on UFS2, and can vary from filesystem to filesystem". > >> - for EMFILE - is the limit on open files really 64 per process? > system that is a little lower than kern.maxfiles: Yes, that's what I was aiming at :) Maybe the sysctl deserves to be mentioned in the man page? >> (And of course, tuning(7) also has some historical figures) > > Can you help us identify them? I remember this discussed some time ago so I assumed it's fixed, but here are some suggestions: - the default partition sizes at the start of the page are a bit low (but nothing serious) - maybe just double the sizes for root & /var. - About the swap size: """The kernel's VM paging algorithms are tuned to perform best when there is at least 2x swap versus main memory. Configuring too little swap can lead to inefficiencies in the VM""" - AFAIK this is not really true? - also, with 64bit computers becoming as common as 32bit, maybe a note should be added about the differences (also AFAIK: there's no point in having RAM+swap > 4GB on 32bit machines?) - maybe a note should be added about the need for large amounts of memory for running fsck on TB-sized filesystems? - I don't know if information in kern.maxusers and kern.ipc.nmbclusters sysctls is correct, but I seem to recall some discusstions where they ended up higher than the recommended maximums in the man pages. Actually, there aren't many errors, sorry for the false alarm :) -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 23:29: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 86E2316A41C; Sun, 17 Jul 2005 23:29:45 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from vomit.ugcs.caltech.edu (vomit.ugcs.caltech.edu [131.215.176.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D92A43D45; Sun, 17 Jul 2005 23:29:45 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by vomit.ugcs.caltech.edu (Postfix, from userid 3640) id 151B1E816; Sun, 17 Jul 2005 16:29:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vomit.ugcs.caltech.edu (Postfix) with ESMTP id 03C1AE815; Sun, 17 Jul 2005 16:29:45 -0700 (PDT) Date: Sun, 17 Jul 2005 16:29:44 -0700 (PDT) From: Jon Dama To: Ivan Voras In-Reply-To: <20050718004649.U70085@geri.cc.fer.hr> Message-ID: References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223729.GD1291@gothmog.gr> <20050718004649.U70085@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 23:29:45 -0000 > becoming as common as 32bit, maybe a note should be added about the > differences (also AFAIK: there's no point in having RAM+swap > 4GB on > 32bit machines?) This is patently untrue. In theory the maximum swap you can configure (and use) on i386 is 2TB * 4 swap devices... however, certain limits (see 1) make this ~32GB per swap device * 4 swap devices. And in practice this number is further limited by the size of kva (see, Matt Dillon's comment in note 2). He estimates 16GB out of the box and 60GB with KVA tuning as the limit of swap on i386. swap space != address space. note 1: http://lists.freebsd.org/pipermail/freebsd-amd64/2005-May/004700.html * though this explicitly refers to amd64, the comment applies equally to i386 note 2: http://kerneltrap.org/node/323 If anything, there should be notation reminding people that RAM + SWAP is not constrained by 4GBs on i386. -Jon From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 02:14: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 8F55716A41C for ; Mon, 18 Jul 2005 02:14:56 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27C5743D45 for ; Mon, 18 Jul 2005 02:14:56 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id for ; Sun, 17 Jul 2005 21:15:41 -0500 Message-Id: <4.3.2.7.2.20050717205531.01f2bf30@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Jul 2005 21:14:49 -0500 To: freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <20050717120016.99E4716A41C@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: kern_environment.c routine KENV_SET setenv writes past kenvp, kernel mem without limit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 02:14:56 -0000 See kern_environment.c, note that the various routines that add to the kernel environment wind up calling setenv. There is a define at the top showing the kernel environment array has a fixed 512 entries. That define is used once, when the array is initialized. There is, apparently, no overflow check. Calling setenv, which it appears one can do from the user space, appears to plow right past the end of the array in kernel space. I don't think it is a security hole, as the values written are always from a malloc, but I can it crash the system? Am I missing something? Suggested patch below. P.S. I noticed this as I think the authors of sound card drivers have a much better idea of what good default mixer volume / gain values are (0db gain) and also mono speaker audio routing, etc. than the rather lame defaults in mixer.c. Better sound chips and even older sound chips fully implemented just so exceed the roster of pre-canned mixer device names. The idea of using device hints seems specific only to 'pcm' and not to the driver. One size does not fit all. So I'm trying to have the driver's mixer init routine add device hints for default volumes but only if none are present prior. It does not go well. Harry (whole routine at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_environment.c?rev=1.39&content-type=text/x-cvsweb-markup&only_with_tag=MAIN ) int setenv(const char *name, const char *value) { char *buf, *cp, *oldenv; int namelen, vallen, i; KENV_CHECK; namelen = strlen(name) + 1; if (namelen > KENV_MNAMELEN) return (-1); vallen = strlen(value) + 1; if (vallen > KENV_MVALLEN) return (-1); buf = malloc(namelen + vallen, M_KENV, M_WAITOK); sprintf(buf, "%s=%s", name, value); sx_xlock(&kenv_lock); cp = _getenv_dynamic(name, &i); if (cp != NULL) { oldenv = kenvp[i]; kenvp[i] = buf; sx_xunlock(&kenv_lock); free(oldenv, M_KENV); } else { /* We add the option if it wasn't found */ for (i = 0; (cp = kenvp[i]) != NULL; i++) ; suggest : if (i>=KENV_SIZE-1) { sx_xunlock(&kenv_lock); free(buf,M_KENV); return -1; } kenvp[i] = buf; kenvp[i + 1] = NULL; sx_xunlock(&kenv_lock); } return (0); } From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 04:41: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 CE98616A41C for ; Mon, 18 Jul 2005 04:41:20 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6507343D46 for ; Mon, 18 Jul 2005 04:41:20 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id 75A98C028 for ; Mon, 18 Jul 2005 06:41:19 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6I4exJ3014494; Mon, 18 Jul 2005 06:41:04 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Mon, 18 Jul 2005 06:40:50 +0200 User-Agent: KMail/1.8.1 References: <20050716.112411.52164710.imp@bsdimp.com> <200507171111.30149.thierry@herbelot.com> <20050717.102921.08025084.imp@bsdimp.com> In-Reply-To: <20050717.102921.08025084.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507180640.52579.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: loss of PCMCIA ed(4) interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 04:41:20 -0000 Le Sunday 17 July 2005 18:29, M. Warner Losh a écrit : > Thierry, > > Thanks for the traces and such. I'm happy to report that I've > recreated the problem here and I committed what I hope is a fix last > night. It fixes me mostly (there's still some interrupt storm > messages, however). I need to find some way to get rid of those, or > at least discover where they are coming from. I think it is a power > up issue related to the card asserting its interrupt line > prematurely. Hello, I'm reporting that the latest kernel works as expected : thanks *a lot* for the quick resolution of the issue. > Warner TfH PS : extract from the non-verbose, debug messages ... cbb0: at device 12.0 on pci0 cbb0: Found memory at 80000000 cbb0: Secondary bus is 0 cbb0: Secondary bus set to 2 subbus 3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 12.1 on pci0 cbb1: Found memory at 80001000 cbb1: Secondary bus is 0 cbb1: Secondary bus set to 4 subbus 5 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 ... Status is 0x30000006 Status is 0x30000410 cbb1: card inserted: event=0x00000000, state=30000410 cbb_pcic_socket_enable: cbb1: cbb_power: 5V cbb_pcic_socket_enable: ... ed1: at port 0x100-0x11f irq 9 function 0 config 32 on pccard1 ed1: [GIANT-LOCKED] ed1: Ethernet address: 00:80:ad:8e:82:60 ed1: if_start running deferred for Giant ed1: type NE2000 (16 bit) From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 05:15:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E975F16A41C for ; Mon, 18 Jul 2005 05:15:45 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A1943D45 for ; Mon, 18 Jul 2005 05:15:45 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j6I5EaMY033379 for ; Sun, 17 Jul 2005 22:14:37 -0700 (PDT) Date: Mon, 18 Jul 2005 14:14:38 +0900 Message-ID: From: gnn@freebsd.org To: 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.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Cross References on the web... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 05:15:46 -0000 Howdy, I have updated the pages to point to the 4 currently available cross references: http://www.codespelunking.org/pages/cs_publicxref.html These are for FreeBSD, OpenBSD, DragonFlyBSD, and FreeBSD Current with Kame Current placed over it. I am still trying to fix my NetBSD stuff. I often use these to work out whether a bug has been fixed in another BSD when I'm working on FreeBSD. Share and enjoy, George From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 06:19: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 45F5216A41C for ; Mon, 18 Jul 2005 06:19:39 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF75443D53 for ; Mon, 18 Jul 2005 06:19:38 +0000 (GMT) (envelope-from drosih@rpi.edu) 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 j6I6JbiI017386 for ; Mon, 18 Jul 2005 02:19:37 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 18 Jul 2005 02:19:36 -0400 To: freebsd-current@FreeBSD.org From: Garance A Drosihn 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: Failure in installworld with new 6.x-branch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 06:19:39 -0000 I have a power-PC system which has been following HEAD, where it has been running HEAD for awhile. Now that an official 6.0-branch has been created, I moved aside /usr/src and checked out a new src with -r RELENG_6. I copied over a few minor changes (like the same kernel config I had been using), and started a rebuild. buildworld, buildkernel, and installkernel went fine. After I rebooted into single-user mode, the installworld failed early, at: -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; /usr/bin/make -f Makefile.inc1 install ===> share/info (install) ===> include (install) creating osreldate.h from newvers.sh touch: not found *** Error code 127 The quick-fix that I did was to add 'touch' to the rule in /usr/src/Makefile.inc1 which does: distributeworld installworld: installcheck mkdir -p ${INSTALLTMP} for prog in [ awk cap_mkdb cat chflags chmod chown \ date echo egrep find grep install-info \ ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl \ test true uname wc zic; do \ cp `which $$prog` ${INSTALLTMP}; \ done The installworld worked after that. The 'touch' that installworld tripped over seems to be the one in /usr/src/sys/conf/newvers.sh I was upgrading two machines in the same fashion (switching from HEAD to RELENG_6) at about the same time. The i386 machine did not get this error, but the ppc machine did. It is possible that I forgot to do the 'make cleanworld' on the ppc machine. Everything seems to be working okay on both machines, once I got past the installworld issue and rebooted. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 07:48: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 0392716A41C for ; Mon, 18 Jul 2005 07:48:39 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70FF843D48 for ; Mon, 18 Jul 2005 07:48:38 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.13.4/8.13.4) with ESMTP id j6I7mXr3000991 for ; Mon, 18 Jul 2005 16:48:33 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Mon, 18 Jul 2005 16:48:33 +0900 (JST) Message-Id: <20050718.164833.730550203.ken@tydfam.jp> To: freebsd-current@freebsd.org From: Yamada Ken Takeshi X-Mailer: Mew version 3.3 on XEmacs 21.4.14 (Reasonable Discussion) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=8.0 tests=CONTENT_TYPE_PRESENT, X_MAILER_PRESENT autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on daemon.sub.tydfam.jp Subject: Q) Adaptec ATA RAID StorageManager @ -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, 18 Jul 2005 07:48:39 -0000 Is not there any mean to use Adaptec's Storage Manager on FreeBSD-current? I am running 2410SA on -current without any problems. And I want to monitor RAID using Storage Manager provided by Adaptec. It is written in Java, and looks working OK on FreeBSD - StorMan.sh, StorAgnt.sh, just it cannot find controllers. I am not sure if I am wrong using provided software by Adaptec, or it does not work on FreeBSD.... From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 08:28: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 47B8016A41C for ; Mon, 18 Jul 2005 08:28:48 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id E746C43D48 for ; Mon, 18 Jul 2005 08:28:47 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DuQzV-0000kk-00; Mon, 18 Jul 2005 10:28:45 +0200 Date: Mon, 18 Jul 2005 10:28:45 +0200 To: Mateusz J??drasik Message-ID: <20050718082845.GC2715@poupinou.org> References: <200507170157.04718.imachine@toya.net.pl> <42D9A190.5060401@freebsd.org> <20050716.183851.56563544.imp@bsdimp.com> <200507171041.37737.imachine@toya.net.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507171041.37737.imachine@toya.net.pl> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-current@freebsd.org Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 08:28:48 -0000 On Sun, Jul 17, 2005 at 10:41:37AM +0200, Mateusz J??drasik wrote: > I have now located also a powerd error, (bug?) mainly the frequencies picked > off by acpi are unavailable - this is a p4 1.6Ghz and it seems uncapable of > clocking itself down to 1200Mhz. Do you have an intel southbridge (an ich family)? If yes, you can try booting with hint.acpi_perf.0.disabled="1" so that the ichst driver will take precedence over acpi_perf for the exact same functionality. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 10:53: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 F042416A41C for ; Mon, 18 Jul 2005 10:53:43 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8871E43D46 for ; Mon, 18 Jul 2005 10:53:43 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so985905wra for ; Mon, 18 Jul 2005 03:53:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VPndeXS3mL27wWPJ7RtZBoQNvviJcVNzP4sYHSO9eAh8KByPiAfXT3BUdMctURlQ3ctLBx6zjC+A0uYRV/XfQeiPFXelXVxra06TDfJfRr3C7YL/wG+xwns33XvftolRemZX5FgfYeGww148GwFcpbziWTwpWQP4qUx1VCcO6hg= Received: by 10.54.2.57 with SMTP id 57mr327199wrb; Mon, 18 Jul 2005 03:53:42 -0700 (PDT) Received: by 10.54.80.4 with HTTP; Mon, 18 Jul 2005 03:53:42 -0700 (PDT) Message-ID: <4cf221cc050718035328cfb071@mail.gmail.com> Date: Mon, 18 Jul 2005 12:53:42 +0200 From: Erik Winge To: freebsd-current@freebsd.org In-Reply-To: <42DA9332.2030200@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4cf221cc050717045319c1f3cf@mail.gmail.com> <42DA9332.2030200@errno.com> Subject: Re: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erik Winge List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 10:53:44 -0000 On 7/17/05, Sam Leffler wrote: > Erik Winge wrote: > > Hi, > > > > After upgrading to 6.0-BETA1 I have started using an Asus ural-bases > > wireless card. > > > > Besides lower performance than with Windows, this driver seems to have > > some stability issues. I keep getting "Corrupted MAC on > > input"-messages from scp when copying files. The files I have been > > testing with are about 5MB in size, and the problem interrupts every > > one of 4-5 upload attempts. >=20 > The driver has no tx rate control support and defaults to 1Mb/s so you > must explicitly set the tx rate to get any reasonable performance. > However even when locked to 54M on an 11g channel I never saw tcp > netperf performance much more than ~15Mb/s with a strong signal. I > never saw data corruption but mostly was testing wpa. >=20 > In general I wasn't impressed with the device and the driver definitely > needs work. Hard to recommend it. I experience more weirdness. It seems the card will disassociate from the ap if there is no network activity for some time. If I use the network, for instance streaming audio or having a mailprogram check mail regularly, everything works fine. However if I close all programs, and leave the computer alone for some minutes, it will lose the network connection. ifconfig then reports status:no carrier I have tried running "wpa_cli reassociate", but it doesn't find my ap, and I have to kill wpa_supplicant and restart it to reconnect. Is this a driver problem, or could it possibly be wpa_supplicant? Erik Winge From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 10:54: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 C3D6D16A41C; Mon, 18 Jul 2005 10:54:11 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3043F43D46; Mon, 18 Jul 2005 10:54:10 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j6IAqWBu078791; Mon, 18 Jul 2005 12:52:32 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j6IAqWmM078788; Mon, 18 Jul 2005 12:52:32 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Mon, 18 Jul 2005 12:52:32 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: Jon Dama In-Reply-To: Message-ID: <20050718125110.E78756@geri.cc.fer.hr> References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223729.GD1291@gothmog.gr> <20050718004649.U70085@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 10:54:11 -0000 On Sun, 17 Jul 2005, Jon Dama wrote: > swap space != address space. > > note 2: http://kerneltrap.org/node/323 Thanks for the links - they were very interesting! > If anything, there should be notation reminding people that RAM + SWAP is > not constrained by 4GBs on i386. I'll agree with that :) -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11:05: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 F34D916A41F for ; Mon, 18 Jul 2005 11:05:10 +0000 (GMT) (envelope-from adam@nhh.hu) Received: from hif.hu (fd.hif.hu [193.68.33.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A41F43D73 for ; Mon, 18 Jul 2005 11:04:41 +0000 (GMT) (envelope-from adam@nhh.hu) Received: by fd.hif.hu id <118130>; Mon, 18 Jul 2005 13:04:34 +0200 In-Reply-To: <4cf221cc050718035328cfb071@mail.gmail.com> To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-Id: <05Jul18.130434cest.118130@fd.hif.hu> From: "=?ISO-8859-2?Q?=C1d=E1m_Szilveszter_dr=2E?=" Date: Mon, 18 Jul 2005 13:04:28 +0200 X-MIMETrack: Serialize by Router on MainDomino/HIF(Release 6.5.4|March 27, 2005) at 07/18/2005 13:04:30, Serialize complete at 07/18/2005 13:04:30 Content-Type: text/plain; charset="US-ASCII" Subject: Re: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 11:05:11 -0000 Hello, Erik Winge wrote on 2005.07.18 12:53:42: > I experience more weirdness. It seems the card will disassociate from > the ap if there is no network activity for some time. > > If I use the network, for instance streaming audio or having a > mailprogram check mail regularly, everything works fine. However if I > close all programs, and leave the computer alone for some minutes, it > will lose the network connection. ifconfig then reports status:no > carrier > > I have tried running "wpa_cli reassociate", but it doesn't find my ap, > and I have to kill wpa_supplicant and restart it to reconnect. Is > this a driver problem, or could it possibly be wpa_supplicant? Unfortunately, I see similar symptoms with two ral(4) based cards ( Conceptronic C54RC) in two laptops, one running 6.0-BETA, the other 7.0-CURRENT, both from 16th July. I have not yet been able to determine under what conditions the random dissassociations occur, but no network traffic is one way to more reliably trigger it. After the disassociation occurs, wpa_supplicant starts scanning, even finds the AP a couple of times, but fails to reassociate until killed and restarted. The AP is a Linksys WRT54G with original Linksys firmware, and I am using a WPA-PSK-based setup. Regards: Szilveszter ADAM Budapest, Hungary From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11: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 23ADC16A41C for ; Mon, 18 Jul 2005 11:16:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD1F343D46 for ; Mon, 18 Jul 2005 11:16:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24660 invoked from network); 18 Jul 2005 11:16:11 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Jul 2005 11:16:10 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j6IBG6UH035576; Mon, 18 Jul 2005 07:16:06 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Mon, 18 Jul 2005 07:15:40 -0400 User-Agent: KMail/1.8 References: <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> In-Reply-To: <42D9DA05.1020806@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200507180715.41974.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 11:16:12 -0000 On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: > M. Warner Losh wrote: > > > > > > Nate writes: > >>I really think the driver is broken and the API is fine for this. I > >>don't like the hack of returning a random CID for checks against the > >>HID. Drivers down the road may come to rely on this and then every BIOS > >>that has a different order for CIDs becomes a potential breakage point. > > > > They alredy do rely on this. When they support pnp, they call the > > ISA_PNP_PROBE routine. When they don't then your observation doesn't > > matter because the order of the IDs doesn't matter: their non-zeroness > > does. > > > >>Drivers should not rely on isa_get_logicalid() to determine a boolean > >>"is PNP?" > > > > Actually, that's the interface. We have to follow it, even if you > > think it is stupid. It is how we do things. When we don't have a > > logicalid, we return 0. When drivers don't support pnp devices, it > > uses the existance of a non-zero pnpid to know the device isn't for > > them. It has been this way since 3.0. > > > > Warner > > Rather than John's addition of returning an arbitrary CID, can we return > ~0 or some other obviously invalid HID so that drivers don't start > depending on the order of CIDs? Actually, drivers also use isa_get_logicalid() to get real actual PnP ID as= =20 well (see usage in the pnpmss driver in the same file). I think that any=20 drivers that actually need to interface with ACPI do need to just use=20 ISA_PNP_PROBE(). I think that drivers that don't implement devices ACPI=20 enumerates should stop attaching to ACPI as well. Finally, it may be that= =20 ISA_PNP_PROBE() needs to return a string version of the PNP ID that was=20 actually probed so that drivers can do extra tests. First though, we shoul= d=20 go through removing extra acpi attachments for drivers for ISA PNP cards=20 since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11:16: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 AFAB816A41C for ; Mon, 18 Jul 2005 11:16:15 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [84.234.16.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF1143D49 for ; Mon, 18 Jul 2005 11:16:15 +0000 (GMT) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.51 (FreeBSD)) id 1DuTbT-000EyQ-Nl; Mon, 18 Jul 2005 12:16:07 +0100 Date: Mon, 18 Jul 2005 12:16:07 +0100 From: Tim Bishop To: Kris Kennaway Message-ID: <20050718111607.GA57445@carrick.bishnet.net> References: <20050716172507.GA38651@carrick.bishnet.net> <20050716173956.GB29355@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050716173956.GB29355@xor.obsecurity.org> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.9i X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.899, required 5, autolearn=not spam, ALL_TRUSTED -3.30, BAYES_00 -2.60) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net Cc: freebsd-current@freebsd.org Subject: Re: Panic on RELENG_6 (in 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: Mon, 18 Jul 2005 11:16:15 -0000 On Sat, Jul 16, 2005 at 01:39:56PM -0400, Kris Kennaway wrote: > On Sat, Jul 16, 2005 at 06:25:07PM +0100, Tim Bishop wrote: > > Had a crash on RELENG_6: > > > > Memory modified after free 0xc1db0800(1020) val=c22af3ac @ 0xc1db0b04 > > panic: Most recently used by kqueue > > Configure DEBUG_MEMGUARD with the M_KQUEUE malloc type and it will > panic when the error occurs, not some time later when it is difficult > to diagnose. Kris, Done - thanks. Now just have to wait for it to die again... ;) Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11: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 9EBEA16A41C for ; Mon, 18 Jul 2005 11:31:30 +0000 (GMT) (envelope-from john@veidit.net) Received: from willow.veidit.net (willow.veidit.net [81.93.138.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A4743D46 for ; Mon, 18 Jul 2005 11:31:29 +0000 (GMT) (envelope-from john@veidit.net) Received: from [146.82.48.2] ([146.82.48.2]) (authenticated bits=0) by willow.veidit.net (8.12.10/8.12.10) with ESMTP id j6IBVPfW037088 for ; Mon, 18 Jul 2005 13:31:26 +0200 (CEST) Message-ID: <42DB9300.3050104@veidit.net> Date: Mon, 18 Jul 2005 13:31:12 +0200 From: John Angelmo User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Booting with Promise FastTrak S150 SX4-M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 11:31:30 -0000 I'm booting with the latest 6.0 bootable CD but there seem to be some issues with my FastTrak S150 SX4-M. I get errors like this: ad6: FAILURE - SETFEATURES SET TRANSFER MODE timed out ad6: FAILURE - SETFEATURES ENABLE RCACHE timed out ad6: FAILURE - SETFEATURES ENABLE WCACHE timed out ad6: FAILURE - SET_MULTI timed out ad6: 190782MB at ata3-master SATA150 ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=0 it continues like this on and on, is it possible to get the S150 SX4-M working with FreeBSD (stable or current) /John From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 22:36: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 39EF516A41C for ; Sun, 17 Jul 2005 22:36:25 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EB143D48 for ; Sun, 17 Jul 2005 22:36:24 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id E71E01704D; Mon, 18 Jul 2005 00:36:22 +0200 (CEST) Date: Mon, 18 Jul 2005 00:36:22 +0200 From: Ed Schouten To: Ivan Voras Message-ID: <20050717223622.GD65475@hoeg.nl> References: <20050718000738.F69475@geri.cc.fer.hr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/3yNEOqWowh/8j+e" Content-Disposition: inline In-Reply-To: <20050718000738.F69475@geri.cc.fer.hr> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Mon, 18 Jul 2005 11:53:49 +0000 Cc: current@freebsd.org Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2005 22:36:25 -0000 --/3yNEOqWowh/8j+e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ivan Voras wrote: > - for EFBIG (#27) - I hope the limit is > 2.1E9 on ufs2 :) I mailed about this some time ago. Somebody supplied a patch but it never got commited. NetBSD and OpenBSD both have the correct values as far as I can remember. Yours, --=20 Ed Schouten --/3yNEOqWowh/8j+e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC2t1mmVI4SHXwmhERApRjAJ9ODd4oqSEwA/87GjdUr39KfvracgCfXWFZ afKsTsqE7vDZyZtTEx3WgYA= =al/p -----END PGP SIGNATURE----- --/3yNEOqWowh/8j+e-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 12:06: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 B111616A41C for ; Mon, 18 Jul 2005 12:06:21 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx01.interbgc.com [217.9.224.225]) by mx1.FreeBSD.org (Postfix) with SMTP id A75B943D45 for ; Mon, 18 Jul 2005 12:06:20 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 9102 invoked from network); 18 Jul 2005 12:06:19 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-2.6/8.0):. Processed in 3.923562 secs); 18 Jul 2005 12:06:19 -0000 X-Spam-Status: No, hits=-2.6 required=8.0 Received: from 213-240-205-57.1697748.ddns.cablebg.net (HELO tormentor.totalterror.net) (213.240.205.57) by mx01.interbgc.com with SMTP; 18 Jul 2005 12:06:15 -0000 Received: (qmail 28883 invoked from network); 18 Jul 2005 12:06:14 -0000 Received: from qmail by qscan (mail filter); 18 Jul 2005 12:06:14 +0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 18 Jul 2005 12:06:14 -0000 Message-ID: <42DB9B45.9010305@cytexbg.com> Date: Mon, 18 Jul 2005 15:06:29 +0300 From: Niki Denev User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Winge References: <4cf221cc050717045319c1f3cf@mail.gmail.com> <42DA9332.2030200@errno.com> <4cf221cc050718035328cfb071@mail.gmail.com> In-Reply-To: <4cf221cc050718035328cfb071@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 12:06:21 -0000 Erik Winge wrote: > On 7/17/05, Sam Leffler wrote: > >>Erik Winge wrote: >> >>>Hi, >>> >>>After upgrading to 6.0-BETA1 I have started using an Asus ural-bases >>>wireless card. >>> >>>Besides lower performance than with Windows, this driver seems to have >>>some stability issues. I keep getting "Corrupted MAC on >>>input"-messages from scp when copying files. The files I have been >>>testing with are about 5MB in size, and the problem interrupts every >>>one of 4-5 upload attempts. >> >>The driver has no tx rate control support and defaults to 1Mb/s so you >>must explicitly set the tx rate to get any reasonable performance. >>However even when locked to 54M on an 11g channel I never saw tcp >>netperf performance much more than ~15Mb/s with a strong signal. I >>never saw data corruption but mostly was testing wpa. >> >>In general I wasn't impressed with the device and the driver definitely >>needs work. Hard to recommend it. > > > I experience more weirdness. It seems the card will disassociate from > the ap if there is no network activity for some time. > > If I use the network, for instance streaming audio or having a > mailprogram check mail regularly, everything works fine. However if I > close all programs, and leave the computer alone for some minutes, it > will lose the network connection. ifconfig then reports status:no > carrier > > I have tried running "wpa_cli reassociate", but it doesn't find my ap, > and I have to kill wpa_supplicant and restart it to reconnect. Is > this a driver problem, or could it possibly be wpa_supplicant? > > Erik Winge I'm not really sure, so this is just a guess, but can this be caused by the power management of the card? Does it dissociate when its configured with '-powersave' flag? --niki From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 12:29: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 C0BF016A41C for ; Mon, 18 Jul 2005 12:29:31 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E45043D48 for ; Mon, 18 Jul 2005 12:29:31 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-2.free.fr (Postfix) with ESMTP id 326DD322284 for ; Mon, 18 Jul 2005 14:29:29 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6ICTPm4005217 for ; Mon, 18 Jul 2005 14:29:28 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Mon, 18 Jul 2005 14:29:16 +0200 User-Agent: KMail/1.8.1 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507181429.18078.thierry@herbelot.com> Subject: panic in vfs_subr.c / ffs_inode.c / ufs_inode.c / ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 12:29:32 -0000 Hello, With a recent i386 GENERIC -current running on an SMP machine, I get this panic : bp 0xc2f038a8 wrong b_bufobj 0xc14972e0 should be 0xc1ec7500 I was rebuilding the world when the machine panic'ed. TfH PS : on http://herbelot.tfh.free.fr/panic_vfs/ MD5 : md5 sums of the other 3 files kernel.debug.gz (10M) : compressed debug kernel sys.tbz (16M) : compressed archive of the source used for the kernel vmcore.156.gz (23M) : compressed memory dump PS2 : Here follows a log : 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 7.0-CURRENT #724: Mon Jul 18 08:01:16 CEST 2005 XXX@YYY:/usr/obj_ini/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 100663296 (96 MB) avail memory = 88854528 (84 MB) ... panic: bp 0xc2f038a8 wrong b_bufobj 0xc14972e0 should be 0xc1ec7500 cpuid = 1 KDB: enter: panic [thread pid 50 tid 100038 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 50 tid 100038 td 0xc12aaa80 kdb_enter(c0855ca9) at kdb_enter+0x2b panic(c085d895,c2f038a8,c14972e0,c1ec7500,23) at panic+0x127 flushbuflist(c1ec7504,4,c1ec7500,0,0) at flushbuflist+0x10d bufobj_invalbuf(c1ec7500,4,c12aaa80,0,0) at bufobj_invalbuf+0x111 vinvalbuf(c1ec7440,4,c12aaa80,0,0,c167a738,0,0,800) at vinvalbuf+0x1d ffs_truncate(c1ec7440,0,0,c00,0) at ffs_truncate+0x56a ufs_inactive(c722bc10) at ufs_inactive+0x99 VOP_INACTIVE_APV(c08f45e0,c722bc10) at VOP_INACTIVE_APV+0x7e vinactive(c1ec7440,c12aaa80) at vinactive+0x72 vput(c1ec7440,c097a6e0,0,c086d7fe,d4c) at vput+0x154 handle_workitem_remove(c18e92c0,0) at handle_workitem_remove+0x10b process_worklist_item(0,0) at process_worklist_item+0x181 softdep_process_worklist(0) at softdep_process_worklist+0xf4 sched_sync(0,c722bd38,0,c0684b80,0) at sched_sync+0x25e fork_exit(c0684b80,0,c722bd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc722bd6c, ebp = 0 --- db> call doadump Dumping 95 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 95MB (24320 pages) 80 64 48 32 16 ... ok Dump complete = 0xf db> -------------------- # kgdb kernel.debug /files3/tmp/vmcore.156 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc0468e93 in db_fncall (dummy1=0, dummy2=0, dummy3=-1067147741, dummy4=0xc722b7c4 "ø·\"Ç") at /usr/src/sys/ddb/db_command.c:489 #2 0xc0468c98 in db_command (last_cmdp=0xc0903e64, cmd_table=0x0, aux_cmd_tablep=0xc0881314, aux_cmd_tablep_end=0xc0881330) at /usr/src/sys/ddb/db_command.c:349 #3 0xc0468d60 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc046a901 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc064a0bc in kdb_trap (type=3, code=0, tf=0xc722b908) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc07ed490 in trap (frame= {tf_fs = -954073080, tf_es = -1067188184, tf_ds = -1065025496, tf_edi = -1064970091, tf_esi = 1, tf_ebp = -954025656, tf_isp = -954025676, tf_ebx = -954025612, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067147741, tf_cs = 32, tf_eflags = 646, tf_esp = -954025624, tf_ss = -1067245029}) at /usr/src/sys/i386/i386/trap.c:601 #7 0xc07daf4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xc7220008 in ?? () #9 0xc0640028 in link_elf_init (arg=0xc0855ca9) at /usr/src/sys/kern/link_elf.c:284 #10 0xc063221b in panic (fmt=0x286
) at /usr/src/sys/kern/kern_shutdown.c:537 #11 0xc0683e41 in flushbuflist (bufv=0x0, flags=4, bo=0xc1ec7500, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1057 #12 0xc0683b31 in bufobj_invalbuf (bo=0xc1ec7500, flags=4, td=0xc12aaa80, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:966 #13 0xc0683d31 in vinvalbuf (vp=0xc1ec7440, flags=4, td=0xc12aaa80, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1024 #14 0xc075c0de in ffs_truncate (vp=0xc1ec7440, length=0, flags=3072, cred=0x0, td=0xc12aaa80) at /usr/src/sys/ufs/ffs/ffs_inode.c:279 ---Type to continue, or q to quit--- #15 0xc0773959 in ufs_inactive (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:95 #16 0xc07fda86 in VOP_INACTIVE_APV (vop=0x0, a=0xc722bc10) at vnode_if.c:1535 #17 0xc068581e in vinactive (vp=0xc1ec7440, td=0x0) at vnode_if.h:795 #18 0xc0685680 in vput (vp=0xc1ec7440) at /usr/src/sys/kern/vfs_subr.c:2047 #19 0xc076716f in handle_workitem_remove (dirrem=0xc18e92c0, xp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3405 #20 0xc07631c1 in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:825 #21 0xc0762f28 in softdep_process_worklist (matchmnt=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:700 #22 0xc0684dde in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1621 #23 0xc061eea4 in fork_exit (callout=0xc0684b80 , arg=0x0, frame=0xc722bd38) at /usr/src/sys/kern/kern_fork.c:789 #24 0xc07dafac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) frame 11 #11 0xc0683e41 in flushbuflist (bufv=0x0, flags=4, bo=0xc1ec7500, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1057 1057 KASSERT(bp->b_bufobj == bo, (kgdb) list 1052 "flushbuf", slpflag, slptimeo); 1053 if (error) { 1054 BO_LOCK(bo); 1055 return (error != ENOLCK ? error : EAGAIN); 1056 } 1057 KASSERT(bp->b_bufobj == bo, 1058 ("bp %p wrong b_bufobj %p should be %p", 1059 bp, bp->b_bufobj, bo)); 1060 if (bp->b_bufobj != bo) { /* XXX: necessary ? */ 1061 BUF_UNLOCK(bp); (kgdb) print *bp $1 = {b_bufobj = 0xc14972e0, b_bcount = 4096, b_caller1 = 0x0, b_data = 0xc399d000 "ÌK", b_error = 0, b_iocmd = 1 '\001', b_ioflags = 0 '\0', b_iooffset = 3853975552, b_resid = 0, b_iodone = 0, b_blkno = 0, b_offset = 0, b_bobufs = {tqe_next = 0x0, tqe_prev = 0xc14972e4}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = {tqe_next = 0x0, tqe_prev = 0xc2eea934}, b_qindex = 1, b_flags = 536870944, b_xflags = 2 '\002', b_lock = { lk_interlock = 0xc091e11c, lk_flags = 262144, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc085ee56 "flushbuf", lk_timo = 0, lk_lockholder = 0xc12aaa80, lk_newlock = 0x0}, b_bufsize = 4096, b_runningbufspace = 0, b_kvabase = 0xc399d000 "ÌK", b_kvasize = 16384, b_lblkno = 0, b_vp = 0xc1497220, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xc399d000, b_pager = {pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0xc2f1ff80, tqh_last = 0xc2eea9a0}, cluster_entry = {tqe_next = 0xc2f1ff80, tqe_prev = 0xc2eea9a0}}, b_pages = {0xc114cc90, 0x0 }, b_npages = 1, b_dep = {lh_first = 0x0}} (kgdb)frame 14 #14 0xc075c0de in ffs_truncate (vp=0xc1ec7440, length=0, flags=3072, cred=0x0, td=0xc12aaa80) at /usr/src/sys/ufs/ffs/ffs_inode.c:279 279 vinvalbuf(vp, needextclean ? 0 : V_NORMAL, td, 0, 0); (kgdb) list 274 (void) chkdq(ip, -datablocks, NOCRED, 0); 275 #endif 276 softdep_setup_freeblocks(ip, length, needextclean ? 277 IO_EXT | IO_NORMAL : IO_NORMAL); 278 ASSERT_VOP_LOCKED(vp, "ffs_truncate1"); 279 vinvalbuf(vp, needextclean ? 0 : V_NORMAL, td, 0, 0); 280 vnode_pager_setsize(vp, 0); 281 ip->i_flag |= IN_CHANGE | IN_UPDATE; 282 return (ffs_update(vp, 0)); 283 } (kgdb) print *vp $2 = {v_type = VREG, v_tag = 0xc085cc57 "ufs", v_op = 0xc08f45e0, v_data = 0xc167a738, v_mount = 0xc1452000, v_nmntvnodes = {tqe_next = 0xc199b330, tqe_prev = 0xc14f2784}, v_un = { vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { le_next = 0xc1e89990, le_prev = 0xc13d70c4}, v_hash = 13602, v_cache_src = { lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xc1ec7470}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc091ed34, lk_flags = 262208, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc085cc57 "ufs", lk_timo = 51, lk_lockholder = 0xc12aaa80, lk_newlock = 0x0}, v_interlock = {mtx_object = {lo_class = 0xc08ba7c4, lo_name = 0xc0859545 "vnode interlock", lo_type = 0xc0859545 "vnode interlock", lo_flags = 196608, lo_list = {tqe_next = 0xc14f218c, tqe_prev = 0xc14f27fc}, lo_witness = 0xc092fec8}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc1ec7498, v_holdcnt = 20, v_usecount = 0, v_iflag = 2048, v_vflag = 0, v_writecount = 0, v_freelist = { tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = 0xc1ec74bc, bo_clean = {bv_hd = { tqh_first = 0xc2f1ff80, tqh_last = 0xc2ed8128}, bv_root = 0xc2ef0528, bv_cnt = 18}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xc1ec7514}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc08c1564, bo_bsize = 16384, bo_object = 0xc1e8e7bc, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xc1ec7440, __bo_vnode = 0xc1ec7440}, v_pollinfo = 0x0, v_label = 0x0} (kgdb) -------------------- # ident kernel.debug | grep vfs_subr.c $FreeBSD: src/sys/kern/vfs_subr.c,v 1.635 2005/07/05 15:57:55 pjd Exp $ # ident kernel.debug | grep ffs_inode.c $FreeBSD: src/sys/ufs/ffs/ffs_inode.c,v 1.106 2005/04/05 08:49:41 jeff Exp $ # ident kernel.debug | grep ufs_inode.c $FreeBSD: src/sys/ufs/ufs/ufs_inode.c,v 1.63 2005/03/17 11:58:43 jeff Exp $ # ident kernel.debug | grep ffs_softdep.c $FreeBSD: src/sys/ufs/ffs/ffs_softdep.c,v 1.181 2005/05/03 11:03:29 jeff Exp $ # ident kernel.debug | grep kern_fork.c $FreeBSD: src/sys/kern/kern_fork.c,v 1.252 2005/07/01 16:28:30 ssouhlal Exp $ -------------------- /etc/fstab : # Device Mountpoint FStype Options Dump Pass# /dev/ad0s2b none swap sw 0 0 /dev/ad8s2b none swap sw 0 0 /dev/ad10s2b none swap sw 0 0 # partitions on an ad8/ad10 geom mirror /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1d /tmp ufs rw 2 2 /dev/mirror/gm0s1f /usr ufs rw 2 2 /dev/mirror/gm0s1e /var ufs rw 2 2 From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 13:05: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 4C51016A41C for ; Mon, 18 Jul 2005 13:05:43 +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 6D14D43D45 for ; Mon, 18 Jul 2005 13:05:42 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from beatrix.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 j6ID5caC021475; Mon, 18 Jul 2005 16:05:38 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j6ID5cfh008945; Mon, 18 Jul 2005 16:05:38 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j6ID5c5G008944; Mon, 18 Jul 2005 16:05:38 +0300 (EEST) X-Authentication-Warning: beatrix.daedalusnetworks.priv: keramida set sender to keramida@freebsd.org using -f Date: Mon, 18 Jul 2005 16:05:38 +0300 From: Giorgos Keramidas To: Ed Schouten Message-ID: <20050718130538.GA8938@beatrix.daedalusnetworks.priv> References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223622.GD65475@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717223622.GD65475@hoeg.nl> Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 13:05:43 -0000 On 2005-07-18 00:36, Ed Schouten wrote: > * Ivan Voras wrote: > > - for EFBIG (#27) - I hope the limit is > 2.1E9 on ufs2 :) > > I mailed about this some time ago. Somebody supplied a patch but it > never got commited. NetBSD and OpenBSD both have the correct values as > far as I can remember. What are the correct values? Hint: they are probably very different for UFS1, UFS2, ext2fs and/or msdosfs :-) From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 15:00: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 2B90516A41C for ; Mon, 18 Jul 2005 15:00:10 +0000 (GMT) (envelope-from chad@shire.net) Received: from hobbiton.shire.net (hobbiton.shire.net [166.70.252.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A8843D45 for ; Mon, 18 Jul 2005 15:00:09 +0000 (GMT) (envelope-from chad@shire.net) Received: from [67.161.222.227] (helo=[192.168.99.68]) by hobbiton.shire.net with esmtpa (Exim 4.51) id 1DuX6F-000JCQ-Ro; Mon, 18 Jul 2005 09:00:08 -0600 In-Reply-To: <20050718.164833.730550203.ken@tydfam.jp> References: <20050718.164833.730550203.ken@tydfam.jp> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A1B8B76-9AF2-4510-9DE8-3EC1C4655BE9@shire.net> Content-Transfer-Encoding: 7bit From: "Chad Leigh -- Shire.Net LLC" Date: Mon, 18 Jul 2005 09:00:05 -0600 To: Yamada Ken Takeshi X-Mailer: Apple Mail (2.733) X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 67.161.222.227 X-SA-Exim-Mail-From: chad@shire.net X-SA-Exim-Scanned: No (on hobbiton.shire.net); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org Subject: Re: Q) Adaptec ATA RAID StorageManager @ -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, 18 Jul 2005 15:00:10 -0000 On Jul 18, 2005, at 1:48 AM, Yamada Ken Takeshi wrote: > Is not there any mean to use Adaptec's Storage > Manager on FreeBSD-current? > > I am running 2410SA on -current without any > problems. And I want to monitor RAID using Storage > Manager provided by Adaptec. It is written in Java, > and looks working OK on FreeBSD - StorMan.sh, > StorAgnt.sh, just it cannot find controllers. I use the aaccli (on 5.3) command line program (Linux version). Try installing the linux_aac module (kernel module) and seeing if that helps you Chad > > I am not sure if I am wrong using provided software > by Adaptec, or it does not work on FreeBSD.... > > _______________________________________________ > 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" > --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad@shire.net From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 15:11: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 6049D16A41C; Mon, 18 Jul 2005 15:11:39 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id F362343D45; Mon, 18 Jul 2005 15:11:38 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id ; Mon, 18 Jul 2005 10:12:24 -0500 Message-Id: <4.3.2.7.2.20050718100924.036bffa8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jul 2005 10:11:29 -0500 To: John Baldwin ,Nate Lawson From: Harry Coin In-Reply-To: <200507180715.41974.jhb@FreeBSD.org> References: <42D9DA05.1020806@root.org> <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@FreeBSD.org, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 15:11:39 -0000 At 07:15 AM 7/18/2005 -0400, John Baldwin wrote: >Finally, it may be that >ISA_PNP_PROBE() needs to return a string version of the PNP ID that was >actually probed so that drivers can do extra tests. I support this because chip vendors put chip revision levels, OEM ID's and other stuff in those strings. In the case of the CS4236B you have to write another driver to support another 'control' multifunction device to get access to some of it otherwise. Harry From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 15:19: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 21D7F16A41C; Mon, 18 Jul 2005 15:19:28 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CB7643D48; Mon, 18 Jul 2005 15:19:27 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j6IFJPjb036854; Mon, 18 Jul 2005 19:19:25 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j6IFJO23036848; Mon, 18 Jul 2005 19:19:24 +0400 (MSD) (envelope-from yar) Date: Mon, 18 Jul 2005 19:19:24 +0400 From: Yar Tikhiy To: current@freebsd.org Message-ID: <20050718151924.GF26849@comp.chem.msu.su> References: <20050714101507.GA82562@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714101507.GA82562@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: peter@freebsd.org Subject: Re: Build failure in procfs 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: Mon, 18 Jul 2005 15:19:28 -0000 On Thu, Jul 14, 2005 at 02:15:07PM +0400, Yar Tikhiy wrote: > Hi folks, > > I ran into a problem that might be triggered by Peter's recent > changes to procfs. Namely, the buildworld procedure would fail in > the procfs module if MODULES_WITH_WORLD were set. I noticed it > first in CURRENT and then tested it in a clean environment by > building a freshly CVSup'd RELENG_6 on a freshly installed 5.4-RELEASE, > with MODULES_WITH_WORLD set. I think it's a route of upgrading > quite a few people will follow. > > Here's the diagnostics: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > ===> sys/modules/procfs (depend) > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/obj/usr/src/tmp/usr/include /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ctl.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_dbregs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_fpregs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ioctl.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_map.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_mem.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_note.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_regs.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_rlimit.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_status.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs_type.c /usr/src/sys/modules/procfs/../../fs/procfs/procfs.c > /usr/src/sys/modules/procfs/../../fs/procfs/procfs_dbregs.c:46:24: opt_compat.h: No such file or directory > /usr/src/sys/modules/procfs/../../fs/procfs/procfs_fpregs.c:40:24: opt_compat.h: No such file or directory > /usr/src/sys/modules/procfs/../../fs/procfs/procfs_ioctl.c:31:24: opt_compat.h: No such file or directory > /usr/src/sys/modules/procfs/../../fs/procfs/procfs_map.c:38:24: opt_compat.h: No such file or directory > /usr/src/sys/modules/procfs/../../fs/procfs/procfs_regs.c:40:24: opt_compat.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/src/sys/modules/procfs. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The problem appears to have to do with Peter's changes to procfs: The procfs source files now include opt_compat.h, which is not available by default when building with MODULES_WITH_WORLD set. The attached patch seems to fix the problem in the conventional way. However, I'm unsure which COMPAT_* options are really needed to the procfs module. COMPAT_43 should be enough according to my quick examining /sys/fs/procfs. -- Yar Index: Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/procfs/Makefile,v retrieving revision 1.28 diff -u -r1.28 Makefile --- Makefile 26 Oct 2002 14:38:22 -0000 1.28 +++ Makefile 18 Jul 2005 15:07:44 -0000 @@ -3,7 +3,7 @@ .PATH: ${.CURDIR}/../../fs/procfs KMOD= procfs -SRCS= +SRCS= opt_compat.h SRCS+= vnode_if.h SRCS+= procfs_ctl.c SRCS+= procfs_dbregs.c @@ -26,4 +26,7 @@ EXPORT_SYMS+= procfs_doprocmem EXPORT_SYMS+= procfs_notsystem +opt_compat.h: + echo "#define COMPAT_43 1" > ${.TARGET} + .include From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 15:24: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 C6E1416A41C for ; Mon, 18 Jul 2005 15:24:13 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E6A043D45 for ; Mon, 18 Jul 2005 15:24:11 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 717598BCB2; Mon, 18 Jul 2005 17:24:08 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 08423-05; Mon, 18 Jul 2005 17:24:07 +0200 (CEST) Received: from [192.168.0.4] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 379C08BC93; Mon, 18 Jul 2005 17:24:06 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: freebsd-current@freebsd.org, Bruno Ducrot Date: Mon, 18 Jul 2005 17:26:04 +0200 User-Agent: KMail/1.8.1 References: <200507170157.04718.imachine@toya.net.pl> <200507171041.37737.imachine@toya.net.pl> <20050718082845.GC2715@poupinou.org> In-Reply-To: <20050718082845.GC2715@poupinou.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1196690.KUtpNPeqaX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507181726.10148.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Cc: Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 15:24:13 -0000 --nextPart1196690.KUtpNPeqaX Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dnia poniedzia=C5=82ek 18 lipca 2005 10:28, Bruno Ducrot napisa=C5=82: > On Sun, Jul 17, 2005 at 10:41:37AM +0200, Mateusz J??drasik wrote: > > I have now located also a powerd error, (bug?) mainly the frequencies > > picked off by acpi are unavailable - this is a p4 1.6Ghz and it seems > > uncapable of clocking itself down to 1200Mhz. > > Do you have an intel southbridge (an ich family)? > If yes, you can try booting with > > hint.acpi_perf.0.disabled=3D"1" > so that the ichst driver will take precedence over acpi_perf for the > exact same functionality. Well, it works fine now, as in error-free. However, powerd still doesnt work correctly. It sets the cpu speed, and in a second it goes back to 1600Mhz. I would believe the acpi_toshiba could be a suspect, since it also=20 incorporates some cpu speed control, through hw.acpi.toshiba.cpu_speed Also, in the bios there are some settings for the toshiba cpu, and setting= =20 them to for example 'Cpu Speed Low/High'=3DLow hardcodes the=20 hw.acpi.toshiba.cpu_speed, makes the pc work really slow, and still shows t= he=20 1600Mhz through dev.cpu.0.freq. That wasnt however yet tested with the abov= e=20 hint, so I will take a look as soon as I remove acpi_toshiba from the kerne= l.=20 Or perhaphs there is some hint to disable it too? I like the video backligh= t=20 control :-) Cheers, /m. =2D-=20 Mateusz J. J=C4=99drasik --nextPart1196690.KUtpNPeqaX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC28oS0hJvqP+IH6IRAiMIAKDYpD2TYhZ9ss0HP9uEp9jQWtpeKQCg45v1 UwC+B0+p0/iWKzMcDHoSW1k= =DjJ9 -----END PGP SIGNATURE----- --nextPart1196690.KUtpNPeqaX-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 15:49: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 2CAA716A41C for ; Mon, 18 Jul 2005 15:49:47 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4F043D45 for ; Mon, 18 Jul 2005 15:49:46 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-1.free.fr (Postfix) with ESMTP id C88E41734C1 for ; Mon, 18 Jul 2005 17:49:45 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6IFnd2Q010122 for ; Mon, 18 Jul 2005 17:49:42 +0200 (CEST) From: Thierry Herbelot Date: Mon, 18 Jul 2005 17:49:31 +0200 User-Agent: KMail/1.8.1 References: <200507181429.18078.thierry@herbelot.com> In-Reply-To: <200507181429.18078.thierry@herbelot.com> Cc: freebsd-current@freebsd.org X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline To: "Undisclosed.Recipients": ; Message-Id: <200507181749.32281.thierry@herbelot.com> Subject: Re: panic in vfs_subr.c / ffs_inode.c / ufs_inode.c / ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 15:49:47 -0000 Hello, As a follow-up : the panic occurred while "portupgrade"-ing in parallel to a "make -j2 buildworld" All partitions are UFS2 ; all (even /) are mounted with soft-updates enabled. Other partitions exist on the machine, apart from the ones mirrored via geom. They are not used (leftovers from a previous "jail" experiment), except for savecore. TfH From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 16:06: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 7443516A41C for ; Mon, 18 Jul 2005 16:06:57 +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 229FB43D45 for ; Mon, 18 Jul 2005 16:06: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 j6IG6ur3010712; Mon, 18 Jul 2005 09:06:56 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6IG6u79010711; Mon, 18 Jul 2005 09:06:56 -0700 Date: Mon, 18 Jul 2005 09:06:56 -0700 From: Brooks Davis To: sledgehammer@revier.net Message-ID: <20050718160656.GC8822@odin.ac.hmc.edu> References: <20050716091735.53D4C16A428@hub.freebsd.org> <33051.82.141.44.113.1121525238.squirrel@webmail.kamp-dsl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <33051.82.141.44.113.1121525238.squirrel@webmail.kamp-dsl.de> 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: re Problems with dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 16:06:57 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2005 at 04:47:18PM +0200, sledgehammer@revier.net wrote: > Hi. >=20 > I'm having the same problems here in FreeBSD 7.0 current....wired > connection only going to a Draytek Vigor 2600 DSL router...I just tried to > transfer a couple of GB over my LAN via SSH from my PC running FreeBSD 7.0 > to my Mac Mini running Mac OS X 10.4.2 and the connection got lost all of > a sudden...FreeBSD wasn't able to connect to the internet either for a > while while the Mac had no such problems..here's the part from the log for > my SSH transfer: >=20 > Jul 16 16:28:43 lepus kernel: rl0: discard oversize frame (ether type ffff > flags 3 len 5628 > max 1514) >=20 > When I run a dmesg I get this: >=20 > I had never seen that in 5.4 >=20 > $ dmesg | grep rl > rl0: port 0x9800-0x98ff mem > 0xd7eff800-0xd7eff8ff irq 17 at device 9.0 on pci1 > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:11:d8:05:10:ae > rl0: discard oversize frame (ether type ffff flags 3 len 5628 > max 1514) > rl0: discard oversize frame (ether type f427 flags 3 len 11428 > max 1514) > rl0: discard oversize frame (ether type e467 flags 3 len 57295 > max 1514) > rl0: discard oversize frame (ether type 80a flags 3 len 20975 > max 1514) >=20 > $ uname -psr > FreeBSD 7.0-CURRENT i386 It's hightly unlikely this has anything to do with dhclient. It appears your nic or the driver is totally foobar. You're getting major undeteted packet corruption which is generally a bad sign and way below the level of dhclient. -- 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 --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC29OfXY6L6fI4GtQRAu53AJ9ili3YJgYbLiwWCNYyAbPw9MHyyACdHibK 8MBb+YCKNkuD7NjM5apPhV4= =ScbH -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 16:55: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 64DCB16A4B3 for ; Mon, 18 Jul 2005 16:55:50 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BC0F43D55 for ; Mon, 18 Jul 2005 16:55:49 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 18 Jul 2005 09:55:48 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BE5DF5D07; Mon, 18 Jul 2005 09:55:48 -0700 (PDT) To: Mateusz =?utf-8?q?J=C4=99drasik?= In-reply-to: Your message of "Mon, 18 Jul 2005 17:26:04 +0200." <200507181726.10148.imachine@toya.net.pl> Date: Mon, 18 Jul 2005 09:55:48 -0700 From: "Kevin Oberman" Message-Id: <20050718165548.BE5DF5D07@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 16:55:51 -0000 > From: Mateusz =?utf-8?q?J=C4=99drasik?= > Date: Mon, 18 Jul 2005 17:26:04 +0200 > Sender: owner-freebsd-current@freebsd.org > > Well, it works fine now, as in error-free. > > However, powerd still doesnt work correctly. > > It sets the cpu speed, and in a second it goes back to 1600Mhz. > > I would believe the acpi_toshiba could be a suspect, since it also > incorporates some cpu speed control, through hw.acpi.toshiba.cpu_speed > > Also, in the bios there are some settings for the toshiba cpu, and setting> > them to for example 'Cpu Speed Low/High'=Low hardcodes the > hw.acpi.toshiba.cpu_speed, makes the pc work really slow, and still shows t> he > 1600Mhz through dev.cpu.0.freq. That wasnt however yet tested with the abov> e > hint, so I will take a look as soon as I remove acpi_toshiba from the kerne> l. > Or perhaphs there is some hint to disable it too? I like the video backligh> t > control :-) Take a look in the archives. phk posted a patch to powerd to change this behavior. (I have my own set which does the same thing, but phk's were better written.) This will fix the problem with the speed always bouncing back up to maximum. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 17:09: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 1842416A41C for ; Mon, 18 Jul 2005 17:09:11 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6C0143D49 for ; Mon, 18 Jul 2005 17:09:10 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 06D5CBC89; Mon, 18 Jul 2005 17:09:06 +0000 (UTC) To: "Kevin Oberman" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 18 Jul 2005 09:55:48 PDT." <20050718165548.BE5DF5D07@ptavv.es.net> Date: Mon, 18 Jul 2005 19:09:05 +0200 Message-ID: <1208.1121706545@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-current@freebsd.org, Mateusz =?utf-8?q?J=C4=99drasik?= Subject: Re: Requests for information/possible donation endpoint. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 17:09:11 -0000 In message <20050718165548.BE5DF5D07@ptavv.es.net>, "Kevin Oberman" writes: >Take a look in the archives. phk posted a patch to powerd to change this >behavior. (I have my own set which does the same thing, but phk's were >better written.) This will fix the problem with the speed always >bouncing back up to maximum. I'm seriously considering committing it, but havn't quite found a good name yet. -- 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 Mon Jul 18 17:17: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 8F10316A41C; Mon, 18 Jul 2005 17:17:30 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9A543D45; Mon, 18 Jul 2005 17:17:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6IHHOo5030765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 10:17:25 -0700 Message-ID: <42DBE22D.8020308@root.org> Date: Mon, 18 Jul 2005 10:09:01 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> <200507180715.41974.jhb@FreeBSD.org> In-Reply-To: <200507180715.41974.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 17:17:30 -0000 John Baldwin wrote: > On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: >>Rather than John's addition of returning an arbitrary CID, can we return >>~0 or some other obviously invalid HID so that drivers don't start >>depending on the order of CIDs? > > > Actually, drivers also use isa_get_logicalid() to get real actual PnP ID as > well (see usage in the pnpmss driver in the same file). I think that any > drivers that actually need to interface with ACPI do need to just use > ISA_PNP_PROBE(). Yes, there is no way for a driver to work correctly using just isa_get_logicalid() on all systems. The problem with this is that CID is a list of IDs, some private that will never match a driver like mss. For example, using bogus IDs: System1 _HID: none _CID: IBM008, PNP0C02, PNP0C01 If you just return the first CID in isa_get_logicalid() like your patch does, the device won't probe correctly since IBM008 is not matched by mss. However, on System2: System2 _HID: none _CID: PNP0C02, IBM008, PNP0C01 It works! Thus if a developer of mss only used System2 with your patch, there would be no problem until someone tried on System1. Using ISA_PNP_PROBE() solves this, like you say. To prevent this, should we even issue a warning if acpi_isa_get_logicalid() did not find a _HID but a _CID exists? > I think that drivers that don't implement devices ACPI > enumerates should stop attaching to ACPI as well. Finally, it may be that > ISA_PNP_PROBE() needs to return a string version of the PNP ID that was > actually probed so that drivers can do extra tests. First though, we should > go through removing extra acpi attachments for drivers for ISA PNP cards > since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. This sounds good. -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 17:27: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 4535A16A41C; Mon, 18 Jul 2005 17:27:58 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC9143D46; Mon, 18 Jul 2005 17:27:57 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6IHRuo5030900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 10:27:56 -0700 Message-ID: <42DBE4AA.3010708@root.org> Date: Mon, 18 Jul 2005 10:19:38 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Coin References: <42D9DA05.1020806@root.org> <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org> <4.3.2.7.2.20050718100924.036bffa8@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050718100924.036bffa8@mail.qconline.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "M. Warner Losh" , John Baldwin Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 17:27:58 -0000 Harry Coin wrote: > At 07:15 AM 7/18/2005 -0400, John Baldwin wrote: > >> Finally, it may be that >> ISA_PNP_PROBE() needs to return a string version of the PNP ID that was >> actually probed so that drivers can do extra tests. > > > I support this because chip vendors put chip revision levels, OEM ID's > and other stuff in those strings. In the case of the CS4236B you have > to write another driver to support another 'control' multifunction > device to get access to some of it otherwise. > > Harry The ACPI_PNP_PROBE method already returns the string of the ID that matched since strings like ACPI0002 can't be encoded in the EISA PNPID format. However, I didn't think that would be necessary for ISA devices. -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 17:52: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 329AA16A41C for ; Mon, 18 Jul 2005 17:52:01 +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 BCE5A43D48 for ; Mon, 18 Jul 2005 17:52:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 18 Jul 2005 14:05:33 -0400 From: John Baldwin To: Nate Lawson Date: Mon, 18 Jul 2005 13:51:35 -0400 User-Agent: KMail/1.8 References: <20050716.113059.82101301.imp@bsdimp.com> <200507180715.41974.jhb@FreeBSD.org> <42DBE22D.8020308@root.org> In-Reply-To: <42DBE22D.8020308@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507181351.36749.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 17:52:01 -0000 On Monday 18 July 2005 01:09 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: > >>Rather than John's addition of returning an arbitrary CID, can we return > >>~0 or some other obviously invalid HID so that drivers don't start > >>depending on the order of CIDs? > > > > Actually, drivers also use isa_get_logicalid() to get real actual PnP ID > > as well (see usage in the pnpmss driver in the same file). I think that > > any drivers that actually need to interface with ACPI do need to just use > > ISA_PNP_PROBE(). > > Yes, there is no way for a driver to work correctly using just > isa_get_logicalid() on all systems. The problem with this is that CID > is a list of IDs, some private that will never match a driver like mss. > For example, using bogus IDs: > > System1 > _HID: none > _CID: IBM008, PNP0C02, PNP0C01 > > If you just return the first CID in isa_get_logicalid() like your patch > does, the device won't probe correctly since IBM008 is not matched by > mss. However, on System2: Note that my patch did _not_ just return the first CID, I'm pretty sure it returned the first CID that matched the prefix 'PNP' to match the behavior of acpi_isa_pnp_probe(), and thus it would actually have been very deterministic. > System2 > _HID: none > _CID: PNP0C02, IBM008, PNP0C01 > > It works! Thus if a developer of mss only used System2 with your patch, > there would be no problem until someone tried on System1. Using > ISA_PNP_PROBE() solves this, like you say. You missed the fact that I've already chucked out that local patch and have just committed the one-line change to mss.c. > To prevent this, should we even issue a warning if > acpi_isa_get_logicalid() did not find a _HID but a _CID exists? > > > I think that drivers that don't implement devices ACPI > > enumerates should stop attaching to ACPI as well. Finally, it may be > > that ISA_PNP_PROBE() needs to return a string version of the PNP ID that > > was actually probed so that drivers can do extra tests. First though, we > > should go through removing extra acpi attachments for drivers for ISA PNP > > cards since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. > > This sounds good. This is the direction I want to take for any devices that have an acpi attachment. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 19:06: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 8ADB616A41C for ; Mon, 18 Jul 2005 19:06:03 +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 3CE4043D45 for ; Mon, 18 Jul 2005 19:06:03 +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 j6IJ60ms018493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2005 12:06:02 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DBFEC8.4050504@errno.com> Date: Mon, 18 Jul 2005 12:11:04 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22=C1d=E1m_Szilveszter_dr=2E=22?= References: <05Jul18.130434cest.118130@fd.hif.hu> In-Reply-To: <05Jul18.130434cest.118130@fd.hif.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: if_ural in 6.0-BETA1 [really ral problem, NOT ural] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 19:06:03 -0000 Ádám Szilveszter dr. wrote: > Hello, > > Erik Winge wrote on 2005.07.18 12:53:42: > > >>I experience more weirdness. It seems the card will disassociate from >>the ap if there is no network activity for some time. >> >>If I use the network, for instance streaming audio or having a >>mailprogram check mail regularly, everything works fine. However if I >>close all programs, and leave the computer alone for some minutes, it >>will lose the network connection. ifconfig then reports status:no >>carrier >> >>I have tried running "wpa_cli reassociate", but it doesn't find my ap, >>and I have to kill wpa_supplicant and restart it to reconnect. Is >>this a driver problem, or could it possibly be wpa_supplicant? > > > Unfortunately, I see similar symptoms with two ral(4) based cards ( > Conceptronic C54RC) in two laptops, one running 6.0-BETA, the other > 7.0-CURRENT, both from 16th July. I have not yet been able to determine > under what conditions the random dissassociations occur, but no network > traffic is one way to more reliably trigger it. After the disassociation > occurs, wpa_supplicant starts scanning, even finds the AP a couple of > times, but fails to reassociate until killed and restarted. The AP is a > Linksys WRT54G with original Linksys firmware, and I am using a > WPA-PSK-based setup. None of my ral cards work at all in 11g station mode. They authenticate but cannot associate. My ap's reject the associate request with error status 6. I believe the problem is mis-setting of IFS paramters. I've had no time to look carefully. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 19:29: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 639B516A41C for ; Mon, 18 Jul 2005 19:29:45 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A1743D45 for ; Mon, 18 Jul 2005 19:29:44 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com (Vircom SMTPRS 3.1.302.0) with ESMTP id for ; Mon, 18 Jul 2005 14:30:30 -0500 Message-Id: <4.3.2.7.2.20050718142506.01ef94f8@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jul 2005 14:29:37 -0500 To: freebsd-current@freebsd.org From: Harry Coin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: resource_xxx lookups fail to find dyanmic kernel environment changes due to subr_hints bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 19:29:45 -0000 When the kernel environment goes to dynamic from static hints mode, the a bug in the resource_xxx lookup routines prevent them from using the dynamic environment. So they only report as of the static environment, while the kenv related routines report what's in the new environment. This can lead to very messy symptoms. The subr_hints.c file tries to detect when the kernel environment changes state. But there's a bug in that. Update below has been tested. --- /usr/src/sys/kern/subr_hints.c Sun Mar 13 12:05:26 2005 +++ /mnt/server1/usr/src/sys/kern/subr_hints.c Mon Jul 18 13:53:02 2005 @@ -61,6 +61,7 @@ char *p; if (checkmethod) { + hintp=NULL; switch (hintmode) { case 0: /* loader hints in environment only */ break; Harry From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 20:06: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 DDFD616A41C for ; Mon, 18 Jul 2005 20:06:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74CAB43D45 for ; Mon, 18 Jul 2005 20:06:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 18 Jul 2005 13:06:45 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id AD5BF5D07; Mon, 18 Jul 2005 13:06:45 -0700 (PDT) To: Sam Leffler In-reply-to: Your message of "Fri, 15 Jul 2005 08:23:18 PDT." <42D7D4E6.3020105@errno.com> Date: Mon, 18 Jul 2005 13:06:45 -0700 From: "Kevin Oberman" Message-Id: <20050718200645.AD5BF5D07@ptavv.es.net> Cc: Randy Bush , freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 20:06:48 -0000 > Date: Fri, 15 Jul 2005 08:23:18 -0700 > From: Sam Leffler > > Randy Bush wrote: > >>>More serious is that I can't roam. When I move between APs, dhclient > >>>exits and I need to manually re-start it. I lose my SSH sessions. Ugh! > >> > >>This should not be happening; dhclient should get a disassociate event, > >>drop the lease, then get an associate when you join the new ap and > >>immediately grab a new lease. > > > > > > aiii! this was merely a layer-2 re-association, no change at layer-3. > > I mis-spoke; dhclient trys to re-acquire the current lease. This is > exactly what happened before except it should now happen _immediately_ > on being notified of a re-association to the same ap or an association > to a new ap. Actually I could check for a re-association and not > re-aquire the lease to reduce the overhead but regardless this should be > ok (so far as I understand the protocols). > > The previous code polled for these events. This made it prone to > missing fast re-associations (instead falling back to various timeouts) > and slow to respond when roaming. The new code had been working > correctly; something has clearly changed and I'll fix it asap. I'm in Vancouver at a conference and my dhclient has been dying every few minutes. The room has 4 APs and I suspect the association is moving between them periodically. That is just a guess, though. In any case, several times an hour my IP address changes to 0.0.0.0 and then disappears completely. I still see the NIC associated with the same SSID and the signal quality is consistently excellent. Executing 'dhclient wi0' gets my connection back with the same IP address, so my SSH session survive as long as I restart the client fairly promptly when it goes away, but I have to watch closely. I'm now running 80211watch and I only see: Mon Jul 18 12:11:29 RTM_IEEE80211: disassociate Mon Jul 18 12:12:17 RTM_IEEE80211: disassociate Mon Jul 18 12:49:17 RTM_IEEE80211: disassociate Mon Jul 18 12:49:52 RTM_IEEE80211: disassociate These are interesting in that the first message occurs at some unknown time. The second seems to occur when dhclient is re-started. I don't understand why I never see an associate or reassociate event. Seems odd. In any case, this is a very annoying problem and I'd be happy th help as much as I can, but I'm trying to keep involved with the program at the same time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 20:19: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 4DEA316A41C for ; Mon, 18 Jul 2005 20:19:48 +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 D3A8543D48 for ; Mon, 18 Jul 2005 20:19:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 18 Jul 2005 16:34:01 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 18 Jul 2005 16:14:04 -0400 User-Agent: KMail/1.8 References: <200507152021.47403.nb_root@videotron.ca> <200507161103.27053.nb_root@videotron.ca> In-Reply-To: <200507161103.27053.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507181614.05286.jhb@FreeBSD.org> Cc: Nicolas Blais Subject: Re: FIXED: Latest cvsup to 7.0 causes mplayer to crash my system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 20:19:48 -0000 On Saturday 16 July 2005 11:03 am, Nicolas Blais wrote: > On July 15, 2005 08:21 pm, Nicolas Blais wrote: > > Hi, > > > > Today I've buildworld on latest cvsup (from -CURRENT@july 8th) and now > > whenever i try to play a movie with mplayer, my system crashes with : > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x1c > > fault code = supervisor write, page not present > > instruction pointer = 0x20:0xc06a0bc3 > > stack pointer = 0x28:0xe502fc88 > > frame pointer = 0x28:0xe502fcc8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 28 (swi4: clock sio) > > trap number = 12 > > panic: page fault > > Uptime: 7m49s > > Dumping 1023 MB (2 chunks) > > chunk 0: 1MB (159 pages) ... ok > > chunk 1: 1023MB (261808 pages) 1007 991 (CTRL-C to abort) > > > > and a 1gb dump. That same system was fine on 6-CURRENT from July 8th so > > something in between breaks it. The crash message is always the same. I > > tried recompiling mplayer which did no good. > > > > Please help, > > Nicolas. > > I found a fix for my problem ! > > I had HZ=1160 in my kernel and WITH_RTC enabled in mplayer. > > For some reason, latest kernel code doesn't like the option and panics. I > removed both HZ=1160 and WITH_RTC and now mplayer works like a charm. > > So either mplayer (or rtc-2004.02.24.1_4) doesn't like something added in > the kernel between july 8th and today, or the kernel doesn't like the way > mplayer (or rtc) syncs up with the clock. Can you figure out which one causes the panic? I think HZ=1160 should still work as an option, so try adding that one back first and see if your system is ok. Your traceback from ddb showed that the mutex pointer passed to mtx_unlock_flags() was NULL, so it might be an easy thing to fix if you can find out what callout from rtc(4) was firing. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 20:19:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A720216A41C for ; Mon, 18 Jul 2005 20:19:49 +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 E4F5143D49 for ; Mon, 18 Jul 2005 20:19:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 18 Jul 2005 16:34:02 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 18 Jul 2005 16:19:29 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.125824.48530425.imp@bsdimp.com> In-Reply-To: <20050716.125824.48530425.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507181619.31189.jhb@FreeBSD.org> Cc: harrycoin@qconline.com, "M. Warner Losh" , nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 20:19:49 -0000 On Saturday 16 July 2005 02:58 pm, M. Warner Losh wrote: > : dmesg excerpt ... > : mss_probe: bus acpi0 is probing device pcm0 > : mss_probe: isa_get_logicalid() returned 0! > > This is the problem. It shouldn't be probing there. It doesn't in > current. Chances are John beat me to it and we're arguing over > something that's been fixed... I removed that probe in current. The problem is that ACPI has HID values that are strings like "ACPI0003" that don't fit the EISAID model, so for devices like ACPI thermal zones that only have an ACPI HID, there's no PNP-compatible HID or CID to return to the ISA drivers. I think the proper solution is that drivers that don't support ACPI-enumerate devices (recall that ACPI enumerates PNPBIOS devices) need to stop having acpi attachments, and that drivers that do need to use ISA_PNP_PROBE(). I think that the only embedded sound controllers are PCI, so that probably all of the ISA PNP sound drivers don't need acpi attachments but I could be wrong. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 20:25: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 1E21016A41C; Mon, 18 Jul 2005 20:25:03 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA5DF43D45; Mon, 18 Jul 2005 20:25:02 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6IKP0o5000919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 13:25:01 -0700 Message-ID: <42DC0E2A.9030706@root.org> Date: Mon, 18 Jul 2005 13:16:42 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.125824.48530425.imp@bsdimp.com> <200507181619.31189.jhb@FreeBSD.org> In-Reply-To: <200507181619.31189.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 20:25:03 -0000 John Baldwin wrote: > On Saturday 16 July 2005 02:58 pm, M. Warner Losh wrote: > >>: dmesg excerpt ... >>: mss_probe: bus acpi0 is probing device pcm0 >>: mss_probe: isa_get_logicalid() returned 0! >> >>This is the problem. It shouldn't be probing there. It doesn't in >>current. Chances are John beat me to it and we're arguing over >>something that's been fixed... > > > I removed that probe in current. The problem is that ACPI has HID values that > are strings like "ACPI0003" that don't fit the EISAID model, so for devices > like ACPI thermal zones that only have an ACPI HID, there's no PNP-compatible > HID or CID to return to the ISA drivers. I think the proper solution is that > drivers that don't support ACPI-enumerate devices (recall that ACPI > enumerates PNPBIOS devices) need to stop having acpi attachments, and that > drivers that do need to use ISA_PNP_PROBE(). I think that the only embedded > sound controllers are PCI, so that probably all of the ISA PNP sound drivers > don't need acpi attachments but I could be wrong. You can have a sound controller present in a dock. Most of those are across a pci-pci bridge but some docks export the LPC bus lines directly to a duplicate super I/O. I agree with you though that it is very unlikely someone used such a design for the sound controller. -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 21:35: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 A7BEC16A41C; Mon, 18 Jul 2005 21:35:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40DA543D46; Mon, 18 Jul 2005 21:35:27 +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 j6ILYJrY085511; Mon, 18 Jul 2005 15:34:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 18 Jul 2005 15:35:04 -0600 (MDT) Message-Id: <20050718.153504.32720462.imp@bsdimp.com> To: jhb@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <200507181619.31189.jhb@FreeBSD.org> References: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> <20050716.125824.48530425.imp@bsdimp.com> <200507181619.31189.jhb@FreeBSD.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, harrycoin@qconline.com, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and 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: Mon, 18 Jul 2005 21:35:27 -0000 In message: <200507181619.31189.jhb@FreeBSD.org> John Baldwin writes: : On Saturday 16 July 2005 02:58 pm, M. Warner Losh wrote: : > : dmesg excerpt ... : > : mss_probe: bus acpi0 is probing device pcm0 : > : mss_probe: isa_get_logicalid() returned 0! : > : > This is the problem. It shouldn't be probing there. It doesn't in : > current. Chances are John beat me to it and we're arguing over : > something that's been fixed... : : I removed that probe in current. The problem is that ACPI has HID values that : are strings like "ACPI0003" that don't fit the EISAID model, so for devices : like ACPI thermal zones that only have an ACPI HID, there's no PNP-compatible : HID or CID to return to the ISA drivers. I think the proper solution is that : drivers that don't support ACPI-enumerate devices (recall that ACPI : enumerates PNPBIOS devices) need to stop having acpi attachments, and that : drivers that do need to use ISA_PNP_PROBE(). I think that the only embedded : sound controllers are PCI, so that probably all of the ISA PNP sound drivers : don't need acpi attachments but I could be wrong. If we're going to return the string that we found, maybe it would be better to return a pointer isa_pnp_id entry, and also pass in in the length of the table entry so that drivers can store extra info for each card. PC Card already does this for its lookup routines, for example, that that has worked out very well. That way there isn't the weird trip to a string, then a lookup based on that string. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 22:18: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 AA82416A41C for ; Mon, 18 Jul 2005 22:18:39 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 465B143D48 for ; Mon, 18 Jul 2005 22:18:39 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j6IMIQVg026876; Mon, 18 Jul 2005 15:18:26 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j6IMINWh026875; Mon, 18 Jul 2005 15:18:23 -0700 (PDT) (envelope-from jmg) Date: Mon, 18 Jul 2005 15:18:23 -0700 From: John-Mark Gurney To: Craig Rodrigues Message-ID: <20050718221822.GB97979@funkthat.com> Mail-Followup-To: Craig Rodrigues , "Wojciech A. Koszek" , freebsd-current@freebsd.org References: <20050716224442.GA87607@freebsd.czest.pl> <20050717153936.GA2218@crodrigues.org> <20050717165945.GA1017@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717165945.GA1017@crodrigues.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: "Wojciech A. Koszek" , freebsd-current@freebsd.org Subject: Re: [LOR] kqueue() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 22:18:39 -0000 Craig Rodrigues wrote this message on Sun, Jul 17, 2005 at 12:59 -0400: > On Sun, Jul 17, 2005 at 11:39:36AM -0400, Craig Rodrigues wrote: > > On Sat, Jul 16, 2005 at 10:44:43PM +0000, Wojciech A. Koszek wrote: > > > http://FreeBSD.czest.pl/dunstan/kqueuetest.c > > > > I can reproduce this LOR: > > > > It looks like on line 1545 of kern_event.c, we have a KQ_LOCK(kq);, > > and then on line 1039, the KQ_NOTOWNED(kq); assertion fails, because > > the lock is never released. > > Can you try this patch: > > --- /usr/src/sys/kern/kern_event.c.orig Sun Jul 17 12:32:58 2005 > +++ /usr/src/sys/kern/kern_event.c Sun Jul 17 12:41:54 2005 > @@ -410,7 +410,15 @@ > kev.fflags = kn->kn_sfflags; > kev.data = kn->kn_id; /* parent */ > kev.udata = kn->kn_kevent.udata; /* preserve udata */ > + > + if (kn->kn_status & KN_HASKQLOCK) > + KQ_UNLOCK(kn->kn_kq); > + > error = kqueue_register(kn->kn_kq, &kev, NULL, 0); > + > + if (kn->kn_status & KN_HASKQLOCK) > + KQ_LOCK(kn->kn_kq); > + > if (error) > kn->kn_fflags |= NOTE_TRACKERR; > } This is not a correct fix.. This will cause the error message to go away, but will open a race... You can only unlock the kq while holding a reference to the knote when the knote is INFLUX.... If it's not INFLUX, the knote could disappear out from under you by another thread deleting it and you'd have a pointer to stale memory.... It maybe possible to exploit the fact that the knote has the KN_HASKQLOCK set in it's kn_status, but looking at kqueue_register, this would be difficult, since we might sleep and need to unlock the kqueue... the most correct solution would be to attach a work item to the process and then have another thread (possibly even the kqueue thread) process the event add request out of band where we won't have a problem with the locks... The only issue with this is that there may not be the ability to immediately note the error if the knote is unable to be attached.... > I don't get the crash any more, but sometimes I get this LOR > in dmesg: > > lock order reversal > 1st 0xc1b0aaa4 process lock (process lock) @ /usr/src/sys/kern/kern_fork.c:690 > 2nd 0xc092dba0 allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:229 Which is another race opened by the patch that can get you into trouble... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 22:20: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 4F0F616A41C for ; Mon, 18 Jul 2005 22:20:25 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABE843D45 for ; Mon, 18 Jul 2005 22:20:24 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id B65235E3 for ; Tue, 19 Jul 2005 00:20:22 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91606-02-5 for ; Tue, 19 Jul 2005 00:20:21 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id 19FFB1FB for ; Mon, 18 Jul 2005 17:01:52 +0200 (CEST) Message-ID: <42DBC456.7060205@datacomm.ch> Date: Mon, 18 Jul 2005 17:01:42 +0200 From: Benjamin Lutz 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.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE96B2ADB955E4A38C71421BB" X-Virus-Scanned: by amavisd-new at maxlor.mine.nu Cc: Subject: ACPI: clock stops while sleeping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 22:20:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE96B2ADB955E4A38C71421BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I've installed FreeBSD-6.0-BETA1 on my Athlon64 (in amd64 mode), and I must say, the new power management features are impressive. I've noticed a slight hitch though: When I send the CPU to sleep with acpiconf -s 1, the clock will stop, resulting in the system time being wrong after wakeup. Is there something I can do to fix this, other than run ntpdate? (How to solve this without a network connection?) Cheers Benjamin --------------enigE96B2ADB955E4A38C71421BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFC28RZgShs4qbRdeQRAgVYAJ0beDVcwbkrcJKcYTe/VNiEZq5ucwCeLoIL 79NMjfros0PGsQeLmwoZads= =cDN+ -----END PGP SIGNATURE----- --------------enigE96B2ADB955E4A38C71421BB-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 22:47: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 7F19B16A41C for ; Mon, 18 Jul 2005 22:47:13 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7D7843D46 for ; Mon, 18 Jul 2005 22:47:12 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6IMlBHJ050642; Tue, 19 Jul 2005 01:47:11 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 93956-04; Tue, 19 Jul 2005 01:47:10 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6IMlA79050639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 01:47:10 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j6IMl3eg031181; Tue, 19 Jul 2005 01:47:03 +0300 (EEST) (envelope-from ru) Date: Tue, 19 Jul 2005 01:47:03 +0300 From: Ruslan Ermilov To: Garance A Drosihn Message-ID: <20050718224703.GC6039@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@FreeBSD.org Subject: Re: Failure in installworld with new 6.x-branch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 22:47:13 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2005 at 02:19:36AM -0400, Garance A Drosihn wrote: > I have a power-PC system which has been following HEAD, where > it has been running HEAD for awhile. Now that an official > 6.0-branch has been created, I moved aside /usr/src and checked > out a new src with -r RELENG_6. I copied over a few minor changes > (like the same kernel config I had been using), and started a > rebuild. >=20 > buildworld, buildkernel, and installkernel went fine. After I > rebooted into single-user mode, the installworld failed early, at: >=20 > -------------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; /usr/bin/make -f Makefile.inc1 install > =3D=3D=3D> share/info (install) > =3D=3D=3D> include (install) > creating osreldate.h from newvers.sh > touch: not found > *** Error code 127 >=20 > The quick-fix that I did was to add 'touch' to the rule in > /usr/src/Makefile.inc1 which does: >=20 > distributeworld installworld: installcheck > mkdir -p ${INSTALLTMP} > for prog in [ awk cap_mkdb cat chflags chmod chown \ > date echo egrep find grep install-info \ > ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl \ > test true uname wc zic; do \ > cp `which $$prog` ${INSTALLTMP}; \ > done >=20 > The installworld worked after that. The 'touch' that installworld > tripped over seems to be the one in /usr/src/sys/conf/newvers.sh >=20 > I was upgrading two machines in the same fashion (switching from > HEAD to RELENG_6) at about the same time. The i386 machine did not > get this error, but the ppc machine did. It is possible that I > forgot to do the 'make cleanworld' on the ppc machine. Everything > seems to be working okay on both machines, once I got past the > installworld issue and rebooted. >=20 Any chance the time was set incorrectly after booting into single-user mode, like running adjkerntz(8)? Anyway, this usually pops up on the mailing lists either due to time being set incorrectly, or other pilot errors. And no, touch isn't needed during the normal installworld, and we specifically limit a set of install tools to a minimum for reasons that are out of scope of this email (hint: to survive live upgrades). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3DFnqRfpzJluFF4RAivyAJ4mNXM0Z6AKYSbL+Ijbt2k7CZIstACfeTOS uEPmzyAeRbq/zGaf22xuBUE= =Tc8D -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 23:21: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 2263116A41C; Mon, 18 Jul 2005 23:21:35 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5830B43D55; Mon, 18 Jul 2005 23:21:33 +0000 (GMT) (envelope-from drosih@rpi.edu) 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 j6INLWfM014345; Mon, 18 Jul 2005 19:21:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050718224703.GC6039@ip.net.ua> References: <20050718224703.GC6039@ip.net.ua> Date: Mon, 18 Jul 2005 19:21:30 -0400 To: Ruslan Ermilov From: Garance A Drosihn 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 Subject: Re: Failure in installworld with new 6.x-branch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 23:21:35 -0000 At 1:47 AM +0300 7/19/05, Ruslan Ermilov wrote: >On Mon, Jul 18, 2005, Garance A Drosihn wrote: > > > > I was upgrading two machines in the same fashion (switching > > from HEAD to RELENG_6) at about the same time. The i386 > > machine did not get this error, but the ppc machine did. It > > is possible that I forgot to do the 'make cleanworld' on the > > ppc machine. > >Any chance the time was set incorrectly after booting into >single-user mode, like running adjkerntz(8)? Anyway, this >usually pops up on the mailing lists either due to time >being set incorrectly, or other pilot errors. Ah, yeah, my powerPC machine *always* claims that it needs to correct the time on a standard bootup -- even if it had just rebooted. It generally claims to be off by around 360 seconds. I can't say for sure, since that line from ntpdate doesn't seem to get saved anywhere, but for the last few reboots (which I just did) it's been around 366-367 seconds. I have been meaning to check what the story is with that time-warp. It figures that the first time this time-warp would cause a problem for me would be after switching to a new branch-tag... This failure didn't pop up the other 20+ times I've rebuilt my powerPC system! Okay, that is probably the issue. Thanks. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 06:45: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 E70C716A41C for ; Tue, 19 Jul 2005 06:45:58 +0000 (GMT) (envelope-from opal@mmu.edu.my) Received: from mailstaff.cyber.mmu.edu.my (mailstaff.mmu.edu.my [203.106.62.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22D7943D45 for ; Tue, 19 Jul 2005 06:45:54 +0000 (GMT) (envelope-from opal@mmu.edu.my) Received: from kav.cyber.mmu.edu.my (localhost [127.0.0.1]) by mailstaff.cyber.mmu.edu.my (Postfix) with ESMTP id C82C031895 for ; Tue, 19 Jul 2005 14:45:52 +0800 (MYT) Received: from kav.cyber.mmu.edu.my (unknown [127.0.0.1]) by kav.cyber.mmu.edu.my (Postfix) with SMTP id A873895C20 for ; Tue, 19 Jul 2005 14:45:52 +0800 (MYT) Received: from opal (mailstaff.cyber.mmu.edu.my [10.100.3.1]) by kav.cyber.mmu.edu.my (Postfix) with ESMTP id 4D75395C1F for ; Tue, 19 Jul 2005 14:45:52 +0800 (MYT) From: Nawfal bin Mohmad Rouyan To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="=-5XruhllFx3o82seJgM/W" Organization: Multimedia University Date: Tue, 19 Jul 2005 14:45:52 +0800 Message-Id: <1121755552.66019.17.camel@opal> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: Kernel Compile Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 06:45:59 -0000 --=-5XruhllFx3o82seJgM/W Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi All,m I'm having problem compiling today's RELENG_6 kernel with the error below. This is using my own kernel config file WIKI. But I don't get the error if I use the GENERIC config file. Attach is my WIKI config file. May I know why I get this error? Thanks ===> xl (all) cc -O2 -pipe -march=pentium4 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/WIKI/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/WIKI -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 /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o if_xl.kld if_xl.o touch export_syms awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-common -o if_xl.ko if_xl.kld objcopy --strip-debug if_xl.ko 1 error *** Error code 2 1 error *** Error code 2 1 error -- Nawfal bin Mohmad Rouyan Multimedia University "Perfection is not in exhibitions of miraculous powers, but perfection is to sit among people, sell and buy, marry and have children; and yet never leave the presence of Allah even for one moment." --=-5XruhllFx3o82seJgM/W Content-Disposition: attachment; filename=WIKI Content-Type: text/plain; name=WIKI; charset=us-ascii Content-Transfer-Encoding: 7bit # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429 2005/05/24 16:48:07 damien Exp $ machine i386 cpu I686_CPU ident WIKI # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners --=-5XruhllFx3o82seJgM/W-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 07:57:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03B3516A41C for ; Tue, 19 Jul 2005 07:57:25 +0000 (GMT) (envelope-from adam@nhh.hu) Received: from hif.hu (fd.hif.hu [193.68.33.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9770E43D48 for ; Tue, 19 Jul 2005 07:57:22 +0000 (GMT) (envelope-from adam@nhh.hu) Received: by fd.hif.hu id <118146>; Tue, 19 Jul 2005 09:57:18 +0200 In-Reply-To: <42DBFEC8.4050504@errno.com> To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-Id: <05Jul19.095718cest.118146@fd.hif.hu> From: "=?ISO-8859-2?Q?=C1d=E1m_Szilveszter_dr=2E?=" Date: Tue, 19 Jul 2005 09:57:16 +0200 X-MIMETrack: Serialize by Router on MainDomino/HIF(Release 6.5.4|March 27, 2005) at 07/19/2005 09:57:17, Serialize complete at 07/19/2005 09:57:17 Content-Type: text/plain; charset="US-ASCII" Subject: Re: if_ural in 6.0-BETA1 [really ral problem, NOT ural] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 07:57:25 -0000 Sam Leffler wrote on 2005.07.18 21:11:04: > None of my ral cards work at all in 11g station mode. They authenticate > but cannot associate. My ap's reject the associate request with error > status 6. I believe the problem is mis-setting of IFS paramters. I've > had no time to look carefully. Hm. Mine associate just fine, and mostly work ok in g mode. The random disassociate events I mentioned usually happen after several hours of use. Regards, Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 08:25: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 A994D16A41C for ; Tue, 19 Jul 2005 08:25:09 +0000 (GMT) (envelope-from opal@mmu.edu.my) Received: from mailstaff.cyber.mmu.edu.my (mailstaff.mmu.edu.my [203.106.62.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A0243D46 for ; Tue, 19 Jul 2005 08:25:08 +0000 (GMT) (envelope-from opal@mmu.edu.my) Received: from kav.cyber.mmu.edu.my (localhost [127.0.0.1]) by mailstaff.cyber.mmu.edu.my (Postfix) with ESMTP id AFBEC318A0; Tue, 19 Jul 2005 16:24:56 +0800 (MYT) Received: from kav.cyber.mmu.edu.my (unknown [127.0.0.1]) by kav.cyber.mmu.edu.my (Postfix) with SMTP id 9A49E95C54; Tue, 19 Jul 2005 16:24:56 +0800 (MYT) Received: from opal (mailstaff.cyber.mmu.edu.my [10.100.3.1]) by kav.cyber.mmu.edu.my (Postfix) with ESMTP id 7515195C53; Tue, 19 Jul 2005 16:24:56 +0800 (MYT) From: Nawfal bin Mohmad Rouyan To: Joseph Koshy In-Reply-To: <84dead72050718234954080359@mail.gmail.com> References: <1121755552.66019.17.camel@opal> <84dead72050718234954080359@mail.gmail.com> Content-Type: text/plain Organization: Multimedia University Date: Tue, 19 Jul 2005 16:24:56 +0800 Message-Id: <1121761496.66019.26.camel@opal> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel Compile Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 08:25:09 -0000 On Tue, 2005-07-19 at 12:19 +0530, Joseph Koshy wrote: > > export_syms | xargs -J% objcopy % if_xl.kld > > ld -Bshareable -d -warn-common -o if_xl.ko if_xl.kld > > objcopy --strip-debug if_xl.ko > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > The real error was somewhere earlier on. Retry the build > without a -jN option? > Without -jN option, the compile stopped below: cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/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 /usr/src/sys/i386/isa/clock.c /usr/src/sys/i386/isa/clock.c: In function `rtcin': /usr/src/sys/i386/isa/clock.c:424: error: `IO_RTC' undeclared (first use in this function) /usr/src/sys/i386/isa/clock.c:424: error: (Each undeclared identifier is reported only once /usr/src/sys/i386/isa/clock.c:424: error: for each function it appears in.) /usr/src/sys/i386/isa/clock.c: In function `writertc': /usr/src/sys/i386/isa/clock.c:438: error: `IO_RTC' undeclared (first use in this function) *** Error code 1 Stop in /usr/obj/usr/src/sys/WIKI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 08:54: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 93E0316A41C for ; Tue, 19 Jul 2005 08:54:56 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E2F43D45 for ; Tue, 19 Jul 2005 08:54:56 +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 2299046B2E for ; Tue, 19 Jul 2005 04:54:55 -0400 (EDT) Date: Tue, 19 Jul 2005 09:55:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050719094905.F15510@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 08:54:56 -0000 I fairly regularly use 802.11 adhoc with WEP to communicate between my 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac OS X Tiger. A few days ago, when I updated from a June to a July HEAD revision, this became quite "fragile". Specifically, I often find that the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes it will give an error when I ask it to re-connect to the ad hoc network. I find that if I ifconfig down/up if_wi, and likewise turn off and on the wireless on the PowerBook, it seems to recover. I've not had a chance to really try and diagnose this at all -- i.e., does tcpdump show packets on either end, 802.11 state machine, etc. I was wondering if anyone else has seen this problem, though. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 09:22: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 723BD16A41C for ; Tue, 19 Jul 2005 09:22:04 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 41C5F43D49 for ; Tue, 19 Jul 2005 09:22:02 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 78985 invoked from network); 19 Jul 2005 09:22:00 -0000 Received: from unknown (HELO ?192.168.2.5?) (192.168.2.5) by andxor.it with SMTP; 19 Jul 2005 09:22:00 -0000 Message-ID: <42DCC637.2050103@FreeBSD.org> Date: Tue, 19 Jul 2005 11:21:59 +0200 From: Alex Dupre User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050719094905.F15510@fledge.watson.org> In-Reply-To: <20050719094905.F15510@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 09:22:04 -0000 Robert Watson wrote: > I fairly regularly use 802.11 adhoc with WEP to communicate between my > 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > OS X Tiger. A few days ago, when I updated from a June to a July HEAD > revision, this became quite "fragile". > I was wondering if anyone else has seen this problem, though. I have a (not so) similar problem with my atheros based D-Link DWL-G650 card with late CURRENTs. The problem is very strange: I can connect stablily to my neighbor's 11g wireless network (even if the signal is lower than my D-Link DI-624 AP) and I hardly can connect to my AP. When it happens, the connection goes down after few seconds (no carrier) and I cannot reconnect anymore. This used to work with older current (about a month ago). I though the AP was broken, but I have a 11b device (voip phone) that can connect without problems (yes, I tried to connect the card in 11b mode, w/ & w/o wep, but it's the same). Anyone seeing this? -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 10: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 2A91C16A41C for ; Tue, 19 Jul 2005 10:15:33 +0000 (GMT) (envelope-from jhugo@icomtek.csir.co.za) Received: from marge.icomtek.csir.co.za (marge.icomtek.csir.co.za [146.64.28.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0614343D48 for ; Tue, 19 Jul 2005 10:12:56 +0000 (GMT) (envelope-from jhugo@icomtek.csir.co.za) Received: from [3ffe:2900:fffa:3:211:43ff:feba:aff1] (unknown [IPv6:3ffe:2900:fffa:3:211:43ff:feba:aff1]) by marge.icomtek.csir.co.za (Postfix) with ESMTP id 820548FC5B for ; Tue, 19 Jul 2005 12:12:36 +0200 (SAST) From: Johann Hugo To: freebsd-current@freebsd.org Date: Tue, 19 Jul 2005 12:12:35 +0200 User-Agent: KMail/1.8 References: <20050719094905.F15510@fledge.watson.org> <42DCC637.2050103@FreeBSD.org> In-Reply-To: <42DCC637.2050103@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507191212.36044.jhugo@icomtek.csir.co.za> Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 10:15:33 -0000 On Tuesday 19 July 2005 11:21, Alex Dupre wrote: > Robert Watson wrote: > > I fairly regularly use 802.11 adhoc with WEP to communicate between my > > 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > > OS X Tiger. A few days ago, when I updated from a June to a July HEAD > > revision, this became quite "fragile". > > I was wondering if anyone else has seen this problem, though. > > I have a (not so) similar problem with my atheros based D-Link DWL-G650 > card with late CURRENTs. The problem is very strange: I can connect > stablily to my neighbor's 11g wireless network (even if the signal is > lower than my D-Link DI-624 AP) and I hardly can connect to my AP. When > it happens, the connection goes down after few seconds (no carrier) and > I cannot reconnect anymore. This used to work with older current (about > a month ago). I though the AP was broken, but I have a 11b device (voip > phone) that can connect without problems (yes, I tried to connect the > card in 11b mode, w/ & w/o wep, but it's the same). > Anyone seeing this? I am also getting problems with my atheros cards. When the connection goes down I'm seeing a lot of "rx failed 'cuz of PHY err" and "CCK timing" errors. lab3# athstats 8894 tx management frames 5 tx frames discarded prior to association 887 tx failed 'cuz too many retries 13077 long on-chip tx retries 7 tx frames with no ack marked 9969 rx failed 'cuz of bad CRC 138910 rx failed 'cuz of PHY err 138888 CCK timing 22 CCK restart 1 beacons transmitted 39 periodic calibrations 1180 rate control checks 25 rate control dropped xmit rate rssi of last ack: 15 avg recv rssi: 44 1 switched default/rx antenna Antenna profile: [1] tx 7720 rx 29817 [2] tx 292 rx 37 With tcpdump -y IEEE802_11 I can see the packets, but without -y IEEE802_11 there is nothing. Johann Hugo From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 10:41: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 2157F16A41C for ; Tue, 19 Jul 2005 10:41:34 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A361D43D45 for ; Tue, 19 Jul 2005 10:41:33 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so755635rne for ; Tue, 19 Jul 2005 03:41:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MHCDACvhHWizmky7atKErM09JHYVfmqpOmEpyATT/BtwkcN3iAYg75EjBrJs6//d9i/5yMrqoIdeHWfSDyeeooBAqEg2fNsJgjZcw0QxN6iCZEyHf3YOfjf6btW6VcLNn2E+Bfcv3H67Vj8YbIeGZr2JKtwzinwSvBnWhylaqkA= Received: by 10.38.74.33 with SMTP id w33mr2660081rna; Tue, 19 Jul 2005 03:41:32 -0700 (PDT) Received: by 10.38.13.79 with HTTP; Tue, 19 Jul 2005 03:41:32 -0700 (PDT) Message-ID: <84dead72050719034168f8b040@mail.gmail.com> Date: Tue, 19 Jul 2005 16:11:32 +0530 From: Joseph Koshy To: Nawfal bin Mohmad Rouyan In-Reply-To: <1121761496.66019.26.camel@opal> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1121755552.66019.17.camel@opal> <84dead72050718234954080359@mail.gmail.com> <1121761496.66019.26.camel@opal> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Compile Error 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: Tue, 19 Jul 2005 10:41:34 -0000 > /usr/src/sys/i386/isa/clock.c: In function `writertc': > /usr/src/sys/i386/isa/clock.c:438: error: `IO_RTC' undeclared (first use > in this function) You might want to try the build without removing "device isa" from your config file. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 11:23:09 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 A344D16A41C for ; Tue, 19 Jul 2005 11:23:09 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E67A43D46 for ; Tue, 19 Jul 2005 11:23:08 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6JBN6dG090665; Tue, 19 Jul 2005 14:23:06 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 26225-06; Tue, 19 Jul 2005 14:23:05 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6JBN5UZ090658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 14:23:05 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j6JBMwCb018536; Tue, 19 Jul 2005 14:22:58 +0300 (EEST) (envelope-from ru) Date: Tue, 19 Jul 2005 14:22:58 +0300 From: Ruslan Ermilov To: Poul-Henning Kamp Message-ID: <20050719112258.GF17751@ip.net.ua> References: <17725.1121505394@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8JPrznbw0YAQ/KXy" Content-Disposition: inline In-Reply-To: <17725.1121505394@phk.freebsd.dk> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@FreeBSD.org Subject: Re: modules/acpi/acpi fails in make universe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 11:23:09 -0000 --8JPrznbw0YAQ/KXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2005 at 11:16:34AM +0200, Poul-Henning Kamp wrote: >=20 > When building i386/LINT in "make universe", the acpi/acpi module > fails to build: >=20 > =3D=3D=3D> acpi/acpi (depend) > Warning: Object directory not changed from original /usr/obj/bang/src0/sr= c/sys/L > INT > cc -O2 -fno-strict-aliasing -pipe -I. -I@ -c /bang/src0/src/sys/i386/ac= pica/ac > pi_wakecode.S > /bang/src0/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such fi= le or d > irectory > /bang/src0/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: > /bang/src0/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or oper= ands in > valid for `ljmp' > *** Error code 1 > 1 error > *** Error code 2 > @ -> /bang/src0/src/sys >=20 >=20 > Ad far as I can tell, this bit of sys/modules/acpi/acpi/Makefile > is the offending stuff, but I can't tell what's wrong: >=20 > acpi_wakecode.h: acpi_wakecode.S assym.s > ${MAKE} -f ${.CURDIR}/../../../${MACHINE_ARCH}/acpica/Makefile \ > MAKESRCPATH=3D${.CURDIR}/../../../${MACHINE_ARCH}/acpica >=20 Can you reproduce this just building a LINT kernel? I cannot, and I fail to see how this could be a problem. The failed "cc" command is run from ${.CURDIR}/../../../${MACHINE_ARCH}/acpica/Makefile and it only runs after assym.s was created. But I have found a problem building assym.s manually which needs fixed kmod.mk: %%% Index: kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/kmod.mk,v retrieving revision 1.192 diff -u -r1.192 kmod.mk --- kmod.mk 22 Apr 2005 17:39:58 -0000 1.192 +++ kmod.mk 19 Jul 2005 10:55:55 -0000 @@ -408,7 +408,10 @@ assym.s: @/kern/genassym.sh .endif sh @/kern/genassym.sh genassym.o > ${.TARGET} -genassym.o: @/${MACHINE_ARCH}/${MACHINE_ARCH}/genassym.c @ machine +.if exists(@) +genassym.o: @/${MACHINE_ARCH}/${MACHINE_ARCH}/genassym.c +.endif +genassym.o: @ machine ${SRCS:Mopt_*.h} ${CC} -c ${CFLAGS:N-fno-common} \ @/${MACHINE_ARCH}/${MACHINE_ARCH}/genassym.c .endif %%% If you can reproduce the breakage, please put the complete combined stdout+stderr output from a failed i386 LINT build available somewhere for download. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8JPrznbw0YAQ/KXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3OKSqRfpzJluFF4RAhZpAKCa+bjys3xo1EHxzG9WEvVsANxIaQCfZwQQ wunM4hy6OqEL+imNTH4HXts= =SJr9 -----END PGP SIGNATURE----- --8JPrznbw0YAQ/KXy-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 13:45: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 17A6016A41C; Mon, 18 Jul 2005 13:45:21 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id B189443D45; Mon, 18 Jul 2005 13:45:20 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DCA841704D; Mon, 18 Jul 2005 15:45:19 +0200 (CEST) Date: Mon, 18 Jul 2005 15:45:19 +0200 From: Ed Schouten To: Giorgos Keramidas Message-ID: <20050718134519.GH65475@hoeg.nl> References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223622.GD65475@hoeg.nl> <20050718130538.GA8938@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhtSGe8h3+lMyY1M" Content-Disposition: inline In-Reply-To: <20050718130538.GA8938@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Tue, 19 Jul 2005 12:08:41 +0000 Cc: FreeBSD Current , Ivan Voras Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 13:45:21 -0000 --zhtSGe8h3+lMyY1M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Giorgos Keramidas wrote: > What are the correct values? Hint: they are probably very different for > UFS1, UFS2, ext2fs and/or msdosfs :-) According to http://man.netbsd.se/?find=3Derrno+2+202: | 27 EFBIG File too large. The size of a file exceeded the maximum. (The | system-wide maximum file size is 2**63 bytes. Each file system | may impose a lower limit for files contained within it). Yours, --=20 Ed Schouten --zhtSGe8h3+lMyY1M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC27JvmVI4SHXwmhERAhdBAJ4iS8Rzi8AfmRCfJiIVKcnfFzGWGACfenpB OdaKDNXvvnqIhlTCqEzY5Ng= =E8zo -----END PGP SIGNATURE----- --zhtSGe8h3+lMyY1M-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 16:21: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 C8E1016A41C; Mon, 18 Jul 2005 16:21: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 6B9FF43D68; Mon, 18 Jul 2005 16:21:31 +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 j6IGLS5E063941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 18 Jul 2005 12:21:30 -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 j6IGLSxZ063938; Mon, 18 Jul 2005 12:21:28 -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: <17115.55047.913858.988219@khavrinen.csail.mit.edu> Date: Mon, 18 Jul 2005 12:21:27 -0400 To: Giorgos Keramidas In-Reply-To: <20050717223729.GD1291@gothmog.gr> References: <20050718000738.F69475@geri.cc.fer.hr> <20050717223729.GD1291@gothmog.gr> 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]); Mon, 18 Jul 2005 12:21:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.86.1/982/Sun Jul 17 08:45:12 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: Tue, 19 Jul 2005 12:08:41 +0000 Cc: freebsd-current@FreeBSD.ORG Subject: Re: Errno man page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2005 16:21:48 -0000 < said: > I think that instead of trying to guess a value that would be correct for > many filesystems, but obviously wrong for others, we should just remove the > explicit size. But tell people how to use pathconf(3)/getconf(1) to find out what it is. >> - for EMFILE - is the limit on open files really 64 per process? > Not necessarily. It's what kern.maxfilesperproc says. On my CURRENT > system that is a little lower than kern.maxfiles: This, too, should probably be documented under the portable interface(s) in addition to the FreeBSD-private one. -GAWollman From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 03:21: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 8041A16A41C for ; Tue, 19 Jul 2005 03:21:38 +0000 (GMT) (envelope-from julian@vicor.com) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFB9243D49 for ; Tue, 19 Jul 2005 03:21:37 +0000 (GMT) (envelope-from julian@vicor.com) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 1B48D4CEA05 for ; Mon, 18 Jul 2005 20:21:37 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70781-10 for ; Mon, 18 Jul 2005 20:21:36 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id DC3B94CE9FE for ; Mon, 18 Jul 2005 20:21:36 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id C9CDD7A403 for ; Mon, 18 Jul 2005 20:21:36 -0700 (PDT) Message-ID: <42DC71C0.6010801@vicor.com> Date: Mon, 18 Jul 2005 20:21:36 -0700 From: Julian Elischer Organization: VICOR User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com X-Mailman-Approved-At: Tue, 19 Jul 2005 12:08:41 +0000 Subject: fun with old/new jails and xdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 03:21:38 -0000 Running a 4.x based jail on a 6 or 5 based system. The following ammusing (well not really) event happens if you try to run an xdm in a 4.x jail under 5.x or 6.x to control a remote xterminal using the 5.x supplied devfs in the jail. * Xdm shows a login window on the remote xterminal. (so far so good) * User logs in. * Xdm fires up a xterm etc. (whatever the user has in his .Xsession). * Xterm immediatly quits because there is no /dev/tty in the jail because the xterm has no controlling terminal having been started by xdm which is a daemon. * Session aborts. I'm guessing that xterm in 5.x was fixed to not require the existence of /dev/tty.. Was that fix made by someone here? does anyone know if it wasmajor? If you run it all by hand it works fine because you have a controlling terminal and thus a 'tty' shows up in devfs. As an aside note.. in my older devfs 'tty' always existed but it would return ENXIO for I/O if you didn't have a controlling terminal.. more like happened before.. Anyone have any good suggestions as to how to get around this other than to fix all the x clients..?. From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 06:43: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 6565516A41C for ; Tue, 19 Jul 2005 06:43:48 +0000 (GMT) (envelope-from nawfal@mmu.edu.my) Received: from mailstaff.cyber.mmu.edu.my (mailstaff.mmu.edu.my [203.106.62.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E5E43D46 for ; Tue, 19 Jul 2005 06:43:47 +0000 (GMT) (envelope-from nawfal@mmu.edu.my) Received: from kav.cyber.mmu.edu.my (localhost [127.0.0.1]) by mailstaff.cyber.mmu.edu.my (Postfix) with ESMTP id 0975731897 for ; Tue, 19 Jul 2005 14:43:44 +0800 (MYT) Received: from kav.cyber.mmu.edu.my (unknown [127.0.0.1]) by kav.cyber.mmu.edu.my (Postfix) with SMTP id DD41595C11 for ; Tue, 19 Jul 2005 14:43:43 +0800 (MYT) Received: from opal (mailstaff.cyber.mmu.edu.my [10.100.3.1]) by kav.cyber.mmu.edu.my (Postfix) with ESMTP id 86E0595C10 for ; Tue, 19 Jul 2005 14:43:43 +0800 (MYT) From: Nawfal bin Mohmad Rouyan To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="=-8PkkbkKzL3EFLKmvfhxM" Organization: Multimedia University Date: Tue, 19 Jul 2005 14:43:43 +0800 Message-Id: <1121755423.66019.16.camel@opal> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port X-Mailman-Approved-At: Tue, 19 Jul 2005 12:08:41 +0000 Subject: Kernel Compile Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 06:43:48 -0000 --=-8PkkbkKzL3EFLKmvfhxM Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi All,m I'm having problem compiling today's RELENG_6 kernel with the error below. This is using my own kernel config file WIKI. But I don't get the error if I use the GENERIC config file. Attach is my WIKI config file. May I know why I get this error? Thanks ===> xl (all) cc -O2 -pipe -march=pentium4 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/WIKI/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/WIKI -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 /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o if_xl.kld if_xl.o touch export_syms awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-common -o if_xl.ko if_xl.kld objcopy --strip-debug if_xl.ko 1 error *** Error code 2 1 error *** Error code 2 1 error -- Nawfal bin Mohmad Rouyan Multimedia University "Perfection is not in exhibitions of miraculous powers, but perfection is to sit among people, sell and buy, marry and have children; and yet never leave the presence of Allah even for one moment." --=-8PkkbkKzL3EFLKmvfhxM Content-Disposition: attachment; filename=WIKI Content-Type: text/plain; name=WIKI; charset=us-ascii Content-Transfer-Encoding: 7bit # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429 2005/05/24 16:48:07 damien Exp $ machine i386 cpu I686_CPU ident WIKI # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners --=-8PkkbkKzL3EFLKmvfhxM-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 11: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 7A52616A41C; Tue, 19 Jul 2005 11:05:56 +0000 (GMT) (envelope-from michal.mertl@i.cz) Received: from vidle.i.cz (vidle.i.cz [193.179.36.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1421A43D45; Tue, 19 Jul 2005 11:05:55 +0000 (GMT) (envelope-from michal.mertl@i.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 34ED02E00C; Tue, 19 Jul 2005 13:05:54 +0200 (CEST) Received: from localhost (localhost.i.cz [127.0.0.1]) by ns.i.cz (Postfix) with SMTP id 16FDBF4B04; Tue, 19 Jul 2005 13:05:54 +0200 (CEST) X-AV-Checked: Tue Jul 19 13:05:54 2005 ns.i.cz Received: from genius1.i.cz (genius1.i.cz [192.168.17.49]) by ns.i.cz (Postfix) with ESMTP id 0F568F4B03; Tue, 19 Jul 2005 13:05:54 +0200 (CEST) From: Michal Mertl To: Robert Watson In-Reply-To: <20050719094905.F15510@fledge.watson.org> References: <20050719094905.F15510@fledge.watson.org> Content-Type: text/plain Date: Tue, 19 Jul 2005 13:05:51 +0200 Message-Id: <1121771151.764.42.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Jul 2005 12:08:41 +0000 Cc: current@FreeBSD.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 11:05:56 -0000 Robert Watson wrote: > I fairly regularly use 802.11 adhoc with WEP to communicate between my > 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > OS X Tiger. A few days ago, when I updated from a June to a July HEAD > revision, this became quite "fragile". Specifically, I often find that > the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes > it will give an error when I ask it to re-connect to the ad hoc network. > I find that if I ifconfig down/up if_wi, and likewise turn off and on the > wireless on the PowerBook, it seems to recover. I've not had a chance to > really try and diagnose this at all -- i.e., does tcpdump show packets on > either end, 802.11 state machine, etc. I was wondering if anyone else has > seen this problem, though. Yes, I'm also experiencing similar problems. The problems seem to happen also with different wireless cards and without wep. They were reported by Johann Hugo on 14th in an email titled "ath hostap - clients assosiated, but no comms" too. Another problem with WiFi which Johann reported long time ago is that bridging on atheros (only?) AP works really bad. I get very varying ping response (50 - inf. ms). Sometimes it seems the packets get queued somewhere - after some time I receive several replies at once. I tried to debug it a little but didn't get anywhere. I will try some more. Michal From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 12:31: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 8046416A41F for ; Tue, 19 Jul 2005 12:31:47 +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 BD52543D45 for ; Tue, 19 Jul 2005 12:31:46 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 19 Jul 2005 12:31:45 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp030) with SMTP; 19 Jul 2005 14:31:45 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Tue, 19 Jul 2005 14:31:34 +0200 User-Agent: KMail/1.8.1 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="nextPart1515998.c90WdP7tVJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507191431.43004@harrymail> X-Y-GMX-Trusted: 0 Subject: PANIC: ggatec destroy (6-Beta1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 12:31:47 -0000 --nextPart1515998.c90WdP7tVJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I got the following panic whil playing with ggate: test3:/#39: ggatec destroy -u 1 GEOM_GATE: Device ggate1 destroyed. =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0xdeadc0de fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc05e9a48 stack pointer =3D 0x28:0xd6f64ae4 frame pointer =3D 0x28:0xd6f64ae4 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 537 (ggatec) [thread pid 537 tid 100084 ] Stopped at strlen+0x8: cmpb $0,0(%edx) db> where Tracing pid 537 tid 100084 td 0xc1f45d80 strlen(deadc0de,d6f64bd0,c1ffa10c,c1f45d80,c058b1b5) at strlen+0x8 kvprintf(c07597b4,c0595d70,d6f64bd0,a,d6f64c18) at kvprintf+0x679 vsnprintf(c07c1b00,100,c07597b4,d6f64c14,100) at vsnprintf+0x3c panic(c07597b4,deadc0de,c0751bdc,21d,c054910a) at panic+0x61 _mtx_lock_flags(c1f51038,0,c0751bdc,21d,0) at _mtx_lock_flags+0x69 g_gate_ioctl(c19aee00,c0286d03,c1fecd00,3,c1f45d80) at g_gate_ioctl+0x440 devfs_ioctl_f(c1d5e708,c0286d03,c1fecd00,c1fbbc00,c1f45d80) at=20 devfs_ioctl_f+0x105 ioctl(c1f45d80,d6f64d04,c,421,3) at ioctl+0x45d syscall(3b,3b,3b,0,0) at syscall+0x290 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x2811786f, esp =3D 0xbfb= de31c,=20 ebp =3D 0xbfbde338 --- source from today, just ask if I can provide more info! =2DHarry --nextPart1515998.c90WdP7tVJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC3PKuBylq0S4AzzwRAh+mAKCRv2HSZIDDxMIghpYBlzpBEYm8RQCeI1Kv G+bO5bqghwwdR0Asdb95DkQ= =FeBB -----END PGP SIGNATURE----- --nextPart1515998.c90WdP7tVJ-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 14:43: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 290E516A41F for ; Tue, 19 Jul 2005 14:43:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C688C43D48 for ; Tue, 19 Jul 2005 14:43:18 +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 0117E46B3D for ; Tue, 19 Jul 2005 10:43:18 -0400 (EDT) Date: Tue, 19 Jul 2005 15:43:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050719153930.F15510@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: netstat(1) -mb changes to support libmemstat(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 14:43:19 -0000 With the below-referenced change, netstat(1) now uses libmemstat(3) for its "-mb" statistics display. This moves netstat to using a higher consistency statistics set from UMA, rather than low consistency statistics from the mbuf allocator (which will eventually be removed, once libmemstat(3) also supports kvm so can read statistics from kernel cores). There are also several new statistics available, including the number of cached (free) mbufs in the per-cpu caches and zone cache. However! This involved a substantial rearrangement of statistics gathering, attempting to handle statistics management between several zones, kegs, etc, in UMA, and so on. There are likely a few bugs in this, and I'd like to shake them out sooner rather than later. To use the new netstat, you need a recent kernel and libmemstat, as well as the below changes. Any checkout and build as of July 19 should contain the necessary changes. If you run into a problem, such as rediculously high amounts of memory (probably negative wrapped to unsigned), it would be helpful if you could e-mail me the complete output of vmstat -z, the new netstat, and an older netstat binary (just back out the changed below to mbuf.c and you'll be back where you started, as all the old stats are still exported by the kernel). I've had one report so far of a nit that appears to have to do with free mbufs in the packet zone, whose clusters aren't properly accounted for. I'm investigating that today. Robert N M Watson ---------- Forwarded message ---------- Date: Mon, 18 Jul 2005 08:34:15 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/usr.bin/netstat Makefile mbuf.c rwatson 2005-07-18 08:34:15 UTC FreeBSD src repository Modified files: usr.bin/netstat Makefile mbuf.c Log: Modify "netstat -mb" to use libmemstat(3) when acting on a live system, with a number of positive benefits: - Start using UMA(9) statistics for mbufs and clusters, which avoids using the mbuf allocator statistics which suffer from races under load on SMP. This should eliminate "negative" mbuf counts in netstat -mb. - We are now able to track cached (free) mbufs and clusters and count it towards memory allocated by the network stack. - We are now also able to track memory allocated to mbuf tags since libmemstat(3) can also query malloc(9). We don't print this except as part of the total (for now - #if 0). - We are now able to track mbuf/cluster/packet allocation failures, although they are not currently printed (#if 0). - Don't print out sfbuf statistics when running on a kernel core, as currently that code is able only to query sysctl for statistics. MFC after: 1 week Revision Changes Path 1.27 +2 -2 src/usr.bin/netstat/Makefile 1.43 +195 -34 src/usr.bin/netstat/mbuf.c From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 14:44: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 A6FDA16A41F for ; Tue, 19 Jul 2005 14:44:04 +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 271D743D48 for ; Tue, 19 Jul 2005 14:44:03 +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 j6JEi0Sc016340; Tue, 19 Jul 2005 09:44:00 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42DD11AF.6010006@centtech.com> Date: Tue, 19 Jul 2005 09:43:59 -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: Darren Pilgrim References: <003c01c588ba$0ad14a70$642a15ac@SMILEY> In-Reply-To: <003c01c588ba$0ad14a70$642a15ac@SMILEY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/984/Tue Jul 19 04:16:09 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 14:44:04 -0000 Darren Pilgrim wrote: > From: Eric Anderson > >>Here's what I think would work well in most situations: >> >> If another interface (B) is currently down, that has >>dhclient running >>on it, then when interface (A) comes up with a valid ip, it should >>remove the ip info from interface (B). > > > This is a very bad idea. Unless the interfaces have been bonded or > configured as redundant for each other, they're independent by design. > If I'm using the wired port to do any of the many useful things one can > do with multiple interfaces (diagnostics, configuring new devices > without loss of internet access, etc.), I don't want the unavoidable > link-state changes on that interface to result in my wireless connection > going down. I think something was lost in the mix somewhere here. What I said shouldn't cause your wireless connection to go down. One of us is not understanding the other :) >>If an interface (A) changes from down->up has conflicting IP >>information >>with an interface (B) that is down, that dhclient manages, it should >>remove the IP setup from interface (B), and set routes >>according to the >>newly upped interface. >> >>If an interface (A) changes from down->up, and there is another >>interface (B) that is up that dhclient manages, then >>configure interface >>(A) only if it will not conflict with the other interface's >>(B) network. >> This could be an rc.conf option - to force newly brought up >>interfaces >>to override currently up interfaces. > > > No. Multiple interfaces with addresses in the same subnet (or even the > same address) is a routing issue. Dhclient is not the correct tool to > solve routing issues. Well, it is a routing issue, but it is one that dhclient needs to be able to gracefully deal with. It should do *something* obviously, so what is it you propose for it to do? > A dhclient program needs to do only one thing: negotiate a lease for the > interface specified. Ok - so if that's all it does, then what sets up the interfaces with the new lease? What decides when to set up the interface and when not to? Are there any checks done, or does it blindly set up interfaces at will? I think the question that needs to be answered here apparently is do we want FreeBSD to handle link change events in a default user-friendly manner without user interaction, or do we want it to just wait for the user to handle all events? 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 Tue Jul 19 15:38:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698DB16A41F for ; Tue, 19 Jul 2005 15:38:45 +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 141AD43D46 for ; Tue, 19 Jul 2005 15:38:45 +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 53E1F3188FA; Tue, 19 Jul 2005 17:38:41 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id B8146405B; Tue, 19 Jul 2005 17:38:32 +0200 (CEST) Date: Tue, 19 Jul 2005 17:38:32 +0200 From: Jeremie Le Hen To: Jens Rehsack Message-ID: <20050719153832.GM39292@obiwan.tataz.chchile.org> References: <42D96DCC.9020803@liwing.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D96DCC.9020803@liwing.de> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: Help needed: Problems get Acer 4401LMi running perfect ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 15:38:45 -0000 Hi Jens, > - The ATI Radeon X700 PCI Express is not detected (not supported?) > I've compiled drm and radeondrm into the kernel, but it seems not > recognized. ATI provides a binary Linux driver for this and there is no FreeBSD version. These chips seems to belong to a newer familly than older Radeon that is not supported by the FreeBSD radeondrm driver. > - The video-mode in X can't be set to 1400x1050 Didn't tried with X, but I can't use this mode with vidcontrol(1). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 18:31: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 36CFA16A41F for ; Tue, 19 Jul 2005 18:31:41 +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 691A143D58 for ; Tue, 19 Jul 2005 18:31: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 j6JIVcI4006915 for ; Tue, 19 Jul 2005 14:31:38 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id j6JIVbkk006913 for freebsd-current@freebsd.org; Tue, 19 Jul 2005 14:31:37 -0400 (EDT) Date: Tue, 19 Jul 2005 14:31:37 -0400 From: Thomas Dickey To: freebsd-current@freebsd.org Message-ID: <20050719183137.GA4337@saltmine.radix.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Subject: Re: fun with old/new jails and xdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 18:31:41 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 08:10:52PM +0800, Julian Elischer wrote: > Running a 4.x based jail on a 6 or 5 based system. >=20 > The following ammusing (well not really) event happens if you > try to run an xdm in a 4.x jail under 5.x or 6.x to control > a remote xterminal using the 5.x supplied devfs in the jail. >=20 > * Xdm shows a login window on the remote xterminal. (so far so good) > * User logs in. > * Xdm fires up a xterm etc. (whatever the user has in his .Xsession). > * Xterm immediatly quits because there is no /dev/tty in the jail > because the xterm has no controlling terminal having been started by > xdm which is a daemon. > * Session aborts. >=20 > I'm guessing that xterm in 5.x was fixed to not require the existence > of /dev/tty.. Was that fix made by someone here? does anyone know if > it wasmajor? It might have been a change outside xterm (I don't recall a change with this symptom in xterm). A quick way to check would be to compile xterm from source and test that. ftp://invisible-island.net/xterm/ (at least that's what I would do ;-) =20 > If you run it all by hand it works fine because you have a controlling=20 > terminal and thus a 'tty' shows up in devfs. >=20 > As an aside note.. in my older devfs 'tty' always existed but it would > return ENXIO for I/O if you didn't have a controlling terminal.. more > like happened before.. >=20 > Anyone have any good suggestions as to how to get around this other > than to fix all the x clients..?. not all of them care about the controlling terminal --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --envbJBWh7q8WU6mo 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 iD8DBQFC3UYDtIqByHxlDocRApuUAJ0aKyuiaC6cBWvuhxyqpR3IFuIHCgCfZyoa c7tqJo/B9wCEttwENZmglFI= =OQaz -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 20:16:42 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 CEC6316A41F for ; Tue, 19 Jul 2005 20:16:42 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id E4D6943D5C for ; Tue, 19 Jul 2005 20:16:39 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 2628 invoked by uid 0); 19 Jul 2005 16:58:30 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4538. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.410948 secs); 19 Jul 2005 19:58:30 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 19 Jul 2005 16:58:30 -0300 Message-ID: <42DD5B61.2060107@freebsdbrasil.com.br> Date: Tue, 19 Jul 2005 16:58:25 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: wlan_acl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 20:16:42 -0000 How can I test wlan_acl(4)? I just read about it but could not find where to set 0, 1 or 2 to the acl policy or where to add MAC addresses to... -- Patrick Tracanelli From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 20:38: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 1CFA516A41F for ; Tue, 19 Jul 2005 20:38:06 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8712E43D45 for ; Tue, 19 Jul 2005 20:38:05 +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 j6JKc4pA003020 for ; Tue, 19 Jul 2005 15:38:04 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42DD64AB.3000605@centtech.com> Date: Tue, 19 Jul 2005 15:38:03 -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 Subject: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 20:38:06 -0000 Last week, I tried making a snapshot of one of my NFS servers' partitions. I've done this one other machines before, with smaller barely used partitions, and it has always been relatively snappy. This time, when I ran mksnap_ffs, the command took nearly 5 minutes, in which time all NFS traffic was suspended, as well as all disk access on the machine. After reading in the FreeBSD Implementation book (McKusick), it claims it should be very very fast. Anyone know why it should take so long to do this snapshot? Is this expected normal behaviour, or should I expect faster snapshots? Here's some info on the filesystem: Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/da1s1d 406234604 91799154 281936682 25% 1300303 51197103 2% /scr03 /dev/da1s1d on /scr03 (ufs, NFS exported, local, soft-updates) 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 Tue Jul 19 23:17: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 4C1D516A41F for ; Tue, 19 Jul 2005 23:17:49 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B156343D46 for ; Tue, 19 Jul 2005 23:17:48 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.13.4/8.13.4) with ESMTP id j6JNHiDK043467; Wed, 20 Jul 2005 08:17:44 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Wed, 20 Jul 2005 08:17:43 +0900 (JST) Message-Id: <20050720.081743.730559556.ken@tydfam.jp> To: chad@shire.net From: Yamada Ken Takeshi In-Reply-To: <0A1B8B76-9AF2-4510-9DE8-3EC1C4655BE9@shire.net> References: <20050718.164833.730550203.ken@tydfam.jp> <0A1B8B76-9AF2-4510-9DE8-3EC1C4655BE9@shire.net> X-Mailer: Mew version 3.3 on XEmacs 21.4.14 (Reasonable Discussion) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=8.0 tests=CONTENT_TYPE_PRESENT, X_MAILER_PRESENT autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org Subject: Re: Q) Adaptec ATA RAID StorageManager @ -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, 19 Jul 2005 23:17:49 -0000 From: "Chad Leigh -- Shire.Net LLC" > I use the aaccli (on 5.3) command line program (Linux version). Try > installing the linux_aac module (kernel module) and seeing if that > helps you > > Chad Thank you Chad. I'll try it and report the result, though my system is too adventurous - -current @ amd64 x 2. From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 23: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 5182816A41F for ; Tue, 19 Jul 2005 23:42:29 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD4D443D4C for ; Tue, 19 Jul 2005 23:42:28 +0000 (GMT) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.13.4/8.13.4) with ESMTP id j6JNgMhw043527 for ; Wed, 20 Jul 2005 08:42:24 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Wed, 20 Jul 2005 08:42:22 +0900 (JST) Message-Id: <20050720.084222.846946475.ken@tydfam.jp> To: freebsd-current@freebsd.org From: Yamada Ken Takeshi X-Mailer: Mew version 3.3 on XEmacs 21.4.14 (Reasonable Discussion) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=8.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1, TOOLONGSTR,X_MAILER_PRESENT autolearn=no version=3.0.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on daemon.sub.tydfam.jp Subject: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 23:42:29 -0000 I have the following error for three days. Quick fixes are appreciated. ===> xl (all) cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/TYD3/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/TYD3 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o if_xl.kld if_xl.o touch export_syms awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-common -o if_xl.ko if_xl.kld objcopy --strip-debug if_xl.ko 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 23:50: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 522A216A41F for ; Tue, 19 Jul 2005 23:50:07 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2938443D58 for ; Tue, 19 Jul 2005 23:50:01 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C9C9.dip.t-dialin.net [84.163.201.201] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1Dv1qZ1wvg-0003nl; Wed, 20 Jul 2005 01:49:59 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Wed, 20 Jul 2005 01:49:46 +0200 User-Agent: KMail/1.8 References: <20050720.084222.846946475.ken@tydfam.jp> In-Reply-To: <20050720.084222.846946475.ken@tydfam.jp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10892148.iedv84TyXy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507200149.52721.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2005 23:50:07 -0000 --nextPart10892148.iedv84TyXy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 20 July 2005 01:42, Yamada Ken Takeshi wrote: > I have the following error for three days. > Quick fixes are appreciated. > > =3D=3D=3D> xl (all) > cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc > -I- -include /usr/obj/usr/src/sys/TYD3/opt_global.h -I. -I@ > -I@/contrib/altq -I@/../include -finline-limit=3D8000 -fno-common=20 > -I/usr/obj/usr/src/sys/TYD3 -mno-align-long-strings > -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=3Dc99 -c > /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o > if_xl.kld if_xl.o > touch export_syms > awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld=20 > export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-comm= on > -o if_xl.ko if_xl.kld > objcopy --strip-debug if_xl.ko > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error Looks like you are building with "-jN" where N>=3D2, can you lose that swit= ch so=20 that we can see the real error at the end of the output? =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 --nextPart10892148.iedv84TyXy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC3ZGgXyyEoT62BG0RAo4OAJ4ybN7tvawvGPw5xbdepFjhorQ61wCdHB6q TJ+arhevb8kUKgLBJgerbYU= =N5lF -----END PGP SIGNATURE----- --nextPart10892148.iedv84TyXy-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 01:04: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 947A116A41F for ; Wed, 20 Jul 2005 01:04: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 52B7043D46 for ; Wed, 20 Jul 2005 01:04: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 C193719F3B; Tue, 19 Jul 2005 18:07:11 -0700 (PDT) From: "Darren Pilgrim" To: "'Eric Anderson'" Date: Tue, 19 Jul 2005 18:04:45 -0700 Message-ID: <001701c58cc7$0571c5d0$642a15ac@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: <42DD11AF.6010006@centtech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: freebsd-current@freebsd.org Subject: RE: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 01:04:47 -0000 From: Eric Anderson [mailto:anderson@centtech.com]=20 > Darren Pilgrim wrote: > > No. Multiple interfaces with addresses in the same subnet (or even=20 > > the same address) is a routing issue. Dhclient is not the correct=20 > > tool to solve routing issues. >=20 > Well, it is a routing issue, but it is one that dhclient needs to be=20 > able to gracefully deal with. It should do *something* obviously, so > what is it you propose for it to do? Nothing. If the underlying OS tells dhclient that the address isn't valid for the interface in question, then dhclient should handle that and probably do something graceful like try to get another IP address or at least fail cleanly. It shouldn't be guessing at whether or not the requested action is reasonable. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 01:42: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 1296B16A41F for ; Wed, 20 Jul 2005 01:42:42 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4D6043D58 for ; Wed, 20 Jul 2005 01:42:40 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j6K1gcUe012778; Tue, 19 Jul 2005 20:42:38 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42DDAC0C.605@centtech.com> Date: Tue, 19 Jul 2005 20:42:36 -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: Darren Pilgrim References: <001701c58cc7$0571c5d0$642a15ac@SMILEY> In-Reply-To: <001701c58cc7$0571c5d0$642a15ac@SMILEY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 01:42:42 -0000 Darren Pilgrim wrote: > From: Eric Anderson [mailto:anderson@centtech.com] > >>Darren Pilgrim wrote: >> >>>No. Multiple interfaces with addresses in the same subnet (or even >>>the same address) is a routing issue. Dhclient is not the correct >>>tool to solve routing issues. >> >>Well, it is a routing issue, but it is one that dhclient needs to be >>able to gracefully deal with. It should do *something* obviously, so > > >>what is it you propose for it to do? > > > Nothing. If the underlying OS tells dhclient that the address isn't > valid for the interface in question, then dhclient should handle that > and probably do something graceful like try to get another IP address or > at least fail cleanly. It shouldn't be guessing at whether or not the > requested action is reasonable. Ok, well, that was the edge case which (I believe) I mentioned could be optional as an rc.conf setting maybe. Anyway, I was merely attempting a rough draft proposal of scenarios that FreeBSD needs to handle, with some suggestions to handling them. Thanks for the input. Unfortunately, this thread will probably die a slow death into the depths of the archives.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 03:48: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 B997516A41F; Wed, 20 Jul 2005 03:48:00 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B088E43D46; Wed, 20 Jul 2005 03:47:58 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1Dv5rh-0005uA-L6; Wed, 20 Jul 2005 13:07:25 +0900 Message-Id: <6.2.1.2.2.20050720124426.046af060@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 12:47:50 +0900 To: freebsd-current@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tegge@freebsd.org Subject: linuxthreads compile error in latest 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 03:48:00 -0000 Hi, I have FreeBSD 6.0 beta1 and I couldn't compile linuxthreads from ports. How can I compile it successfully? thanks in advance, Ganbold daemon# uname -an FreeBSD daemon.ub.mng.net 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Tue Jul 19 14:50:06 ULAST 2005 tsgan@daemon.ub.mng.net:/usr/obj/usr/src/sys/DAEMON i386 daemon# cc -O2 -fno-strict-aliasing -pipe -D_PTHREADS -I../ -I../sysdeps/i386 -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -fexceptions -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DFINE_GRAINED_LIBRARIES -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -c /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c In file included from ../sysdeps/pthread/pthread.h:27, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h:43, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr.h:83, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:42: ../sysdeps/pthread/bits/pthreadtypes.h:51: error: conflicting types for 'pthread_attr_t' /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_attr_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:59: error: conflicting types for 'pthread_cond_t' /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_cond_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:66: error: conflicting types for 'pthread_condattr_t' /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_condattr_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:69: error: conflicting types for 'pthread_key_t' /usr/include/sys/_pthreadtypes.h:70: error: previous declaration of 'pthread_key_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:82: error: conflicting types for 'pthread_mutex_t' /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of 'pthread_mutex_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:89: error: conflicting types for 'pthread_mutexattr_t' /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of 'pthread_mutexattr_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:93: error: conflicting types for 'pthread_once_t' /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_once_t' was here ../sysdeps/pthread/bits/pthreadtypes.h:139: error: conflicting types for 'pthread_t' /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of 'pthread_t' was here *** Error code 1 Stop in /usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_16/libgcc_r. *** Error code 1 Stop in /usr/ports/devel/linuxthreads. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:03:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5FCC16A41F for ; Wed, 20 Jul 2005 04:03:41 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B877C43D4C for ; Wed, 20 Jul 2005 04:03:40 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (localhost [127.0.0.1]) by quark.cs.earlham.edu (8.13.4/8.13.3) with ESMTP id j6K43aKL069335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2005 23:03:36 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Received: (from skylar@localhost) by quark.cs.earlham.edu (8.13.4/8.13.3/Submit) id j6K43aHC069334 for freebsd-current@freebsd.org; Tue, 19 Jul 2005 23:03:36 -0500 (EST) (envelope-from skylar@cs.earlham.edu) X-Authentication-Warning: quark.cs.earlham.edu: skylar set sender to skylar@quark.cs.earlham.edu using -f Date: Tue, 19 Jul 2005 23:03:36 -0500 From: Skylar Thompson To: FreeBSD Current Message-ID: <20050720040336.GA69292@quark.cs.earlham.edu> Mail-Followup-To: FreeBSD Current References: <42DD64AB.3000605@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <42DD64AB.3000605@centtech.com> User-Agent: Mutt/1.4.2.1i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es SMTP-Mailing-Host: quark.cs.earlham.edu X-Operating-System: FreeBSD 5.4-RELEASE-p1 X-Uptime: 11:01PM up 3 days, 23 hrs, 15 users, load averages: 0.06, 0.05, 0.02 X-Editor: VIM - Vi IMproved 6.3 (2004 June 7, compiled May 14 2005 15:15:17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [127.0.0.1]); Tue, 19 Jul 2005 23:03:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.86.1/984/Tue Jul 19 04:16:09 2005 on quark.cs.earlham.edu X-Virus-Status: Clean X-Sanitizer: This message has passed the MIMEDefang sanitizer. X-Sanitizer-URL: http://www.cs.earlham.edu/applied-groups/admin/ X-Sanitizer-Version: MIMEDefang/ECSanitizer $Revision: 1.18 $ X-Sanitizer-Config-Version: $Revision: 1.180 $ X-Scanned-By: milter-bcc/0.8.72 (localhost [127.0.0.1]); Tue, 19 Jul 2005 23:03:39 -0500 X-Scanned-By: MIMEDefang 2.51 on 192.168.0.3 X-Spam-Status: No, score=-2.8 required=8.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on quark.cs.earlham.edu Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Skylar Thompson List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 04:03:41 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 03:38:03PM -0500, Eric Anderson wrote: > Last week, I tried making a snapshot of one of my NFS servers'=20 > partitions. I've done this one other machines before, with smaller=20 > barely used partitions, and it has always been relatively snappy. >=20 > This time, when I ran mksnap_ffs, the command took nearly 5 minutes, in= =20 > which time all NFS traffic was suspended, as well as all disk access on= =20 > the machine. After reading in the FreeBSD Implementation book=20 > (McKusick), it claims it should be very very fast. >=20 > Anyone know why it should take so long to do this snapshot? Is this=20 > expected normal behaviour, or should I expect faster snapshots? >=20 > Here's some info on the filesystem: > Filesystem 1K-blocks Used Avail Capacity iused ifree=20 > %iused Mounted on > /dev/da1s1d 406234604 91799154 281936682 25% 1300303 51197103=20 > 2% /scr03 >=20 > /dev/da1s1d on /scr03 (ufs, NFS exported, local, soft-updates) Does that filesystem have a lot of open files? I believe all busy inodes have to be copied in the snapshot process. --=20 -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3c0Ysc4yyULgN4YRAv1pAJ9dpYB9F7MYQJmou8u+YtkLeJEbTwCbBx8x vZbCjmJh71bPh/iTgFRP4hg= =nBPW -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:36: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 48F9B16A41F; Wed, 20 Jul 2005 04:36:08 +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 EE90B43D45; Wed, 20 Jul 2005 04:36:07 +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 j6K4a7ms027092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 21:36:07 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDD4D7.8010602@errno.com> Date: Tue, 19 Jul 2005 21:36:39 -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: Alex Dupre References: <20050719094905.F15510@fledge.watson.org> <42DCC637.2050103@FreeBSD.org> In-Reply-To: <42DCC637.2050103@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 04:36:08 -0000 Alex Dupre wrote: > Robert Watson wrote: > >> I fairly regularly use 802.11 adhoc with WEP to communicate between my >> 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running >> Mac OS X Tiger. A few days ago, when I updated from a June to a July >> HEAD revision, this became quite "fragile". >> I was wondering if anyone else has seen this problem, though. > > > I have a (not so) similar problem with my atheros based D-Link DWL-G650 > card with late CURRENTs. The problem is very strange: I can connect > stablily to my neighbor's 11g wireless network (even if the signal is > lower than my D-Link DI-624 AP) and I hardly can connect to my AP. When > it happens, the connection goes down after few seconds (no carrier) and > I cannot reconnect anymore. This used to work with older current (about > a month ago). I though the AP was broken, but I have a 11b device (voip > phone) that can connect without problems (yes, I tried to connect the > card in 11b mode, w/ & w/o wep, but it's the same). > Anyone seeing this? wi != ath ap mode (really sta mode) != adhoc mode You haven't provided any details of the setup that fails. Have you tried setting up your ath card in 11b? Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:39: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 4C07C16A41F for ; Wed, 20 Jul 2005 04:39:08 +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 CE0B343D45 for ; Wed, 20 Jul 2005 04:39:07 +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 j6K4cVms027099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 21:38:47 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDD568.4030706@errno.com> Date: Tue, 19 Jul 2005 21:39:04 -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: Johann Hugo References: <20050719094905.F15510@fledge.watson.org> <42DCC637.2050103@FreeBSD.org> <200507191212.36044.jhugo@icomtek.csir.co.za> In-Reply-To: <200507191212.36044.jhugo@icomtek.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 04:39:08 -0000 Johann Hugo wrote: > On Tuesday 19 July 2005 11:21, Alex Dupre wrote: > >>Robert Watson wrote: >> >>>I fairly regularly use 802.11 adhoc with WEP to communicate between my >>>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac >>>OS X Tiger. A few days ago, when I updated from a June to a July HEAD >>>revision, this became quite "fragile". >>>I was wondering if anyone else has seen this problem, though. >> >>I have a (not so) similar problem with my atheros based D-Link DWL-G650 >>card with late CURRENTs. The problem is very strange: I can connect >>stablily to my neighbor's 11g wireless network (even if the signal is >>lower than my D-Link DI-624 AP) and I hardly can connect to my AP. When >>it happens, the connection goes down after few seconds (no carrier) and >>I cannot reconnect anymore. This used to work with older current (about >>a month ago). I though the AP was broken, but I have a 11b device (voip >>phone) that can connect without problems (yes, I tried to connect the >>card in 11b mode, w/ & w/o wep, but it's the same). >>Anyone seeing this? > > > I am also getting problems with my atheros cards. When the connection goes > down I'm seeing a lot of "rx failed 'cuz of PHY err" and "CCK timing" errors. wi != ath I cannot tell if you're operating in adhoc mode as you've provided no details. Last note I recall from you regarded ap mode operation. > > lab3# athstats > 8894 tx management frames > 5 tx frames discarded prior to association > 887 tx failed 'cuz too many retries > 13077 long on-chip tx retries > 7 tx frames with no ack marked > 9969 rx failed 'cuz of bad CRC > 138910 rx failed 'cuz of PHY err > 138888 CCK timing > 22 CCK restart > 1 beacons transmitted > 39 periodic calibrations > 1180 rate control checks > 25 rate control dropped xmit rate > rssi of last ack: 15 > avg recv rssi: 44 > 1 switched default/rx antenna > Antenna profile: > [1] tx 7720 rx 29817 > [2] tx 292 rx 37 > > With tcpdump -y IEEE802_11 I can see the packets, but without -y IEEE802_11 > there is nothing. "1 beacons transmitted" is very odd. Is your athstats out of sync w/ the driver? Try providing basic info if you want help. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:42:43 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 2C20216A41F; Wed, 20 Jul 2005 04:42: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 C72EF43D46; Wed, 20 Jul 2005 04:42:42 +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 j6K4ggms027120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 21:42:42 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDD662.6050501@errno.com> Date: Tue, 19 Jul 2005 21:43:14 -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: Robert Watson References: <20050719094905.F15510@fledge.watson.org> In-Reply-To: <20050719094905.F15510@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 04:42:43 -0000 Robert Watson wrote: > > I fairly regularly use 802.11 adhoc with WEP to communicate between my > 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > OS X Tiger. A few days ago, when I updated from a June to a July HEAD > revision, this became quite "fragile". Specifically, I often find that > the Mac can't send to the FreeBSD box (ARP fails, etc), and that > sometimes it will give an error when I ask it to re-connect to the ad > hoc network. I find that if I ifconfig down/up if_wi, and likewise turn > off and on the wireless on the PowerBook, it seems to recover. I've not > had a chance to really try and diagnose this at all -- i.e., does > tcpdump show packets on either end, 802.11 state machine, etc. I was > wondering if anyone else has seen this problem, though. You didn't provide any config info. I recently noticed the wi driver isn't hooked up properly to the net80211 layer causing link state events to not be done properly (it appears disassoc events were being generated but not assoc/reassoc events). If you're using dhclient+adhoc mode then this might be related. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:45: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 514CF16A41F; Wed, 20 Jul 2005 04:45:41 +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 E81A343D64; Wed, 20 Jul 2005 04:45:38 +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 j6K4jZms027142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 21:45:37 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDD710.4030503@errno.com> Date: Tue, 19 Jul 2005 21:46:08 -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: Michal Mertl References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> In-Reply-To: <1121771151.764.42.camel@genius1.i.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 04:45:41 -0000 Michal Mertl wrote: > Robert Watson wrote: > >>I fairly regularly use 802.11 adhoc with WEP to communicate between my >>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac >>OS X Tiger. A few days ago, when I updated from a June to a July HEAD >>revision, this became quite "fragile". Specifically, I often find that >>the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes >>it will give an error when I ask it to re-connect to the ad hoc network. >>I find that if I ifconfig down/up if_wi, and likewise turn off and on the >>wireless on the PowerBook, it seems to recover. I've not had a chance to >>really try and diagnose this at all -- i.e., does tcpdump show packets on >>either end, 802.11 state machine, etc. I was wondering if anyone else has >>seen this problem, though. > > > Yes, I'm also experiencing similar problems. The problems seem to happen > also with different wireless cards and without wep. They were reported > by Johann Hugo on 14th in an email titled "ath hostap - clients > assosiated, but no comms" too. > > Another problem with WiFi which Johann reported long time ago is that > bridging on atheros (only?) AP works really bad. I get very varying ping > response (50 - inf. ms). Sometimes it seems the packets get queued > somewhere - after some time I receive several replies at once. I routinely bridge ath cards (a wide variety) with bge using bridge and see no problems. I get ~36 Mb/s in 11a w/ superg features and ~28 Mb/s w/ basic stuff (what you find in RELENG_6). ping times are what you'd expect (<1ms). Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:46: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 E1AC816A41F for ; Wed, 20 Jul 2005 04:46:28 +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 8922543D46 for ; Wed, 20 Jul 2005 04:46:28 +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 j6K4kRms027145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 21:46:28 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDD741.5030107@errno.com> Date: Tue, 19 Jul 2005 21:46:57 -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: Patrick Tracanelli References: <42DD5B61.2060107@freebsdbrasil.com.br> In-Reply-To: <42DD5B61.2060107@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: wlan_acl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 04:46:29 -0000 Patrick Tracanelli wrote: > > How can I test wlan_acl(4)? I just read about it but could not find > where to set 0, 1 or 2 to the acl policy or where to add MAC addresses > to... > If it's not in man ifconfig then we need to fix the man page. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 04:49: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 98D8B16A41F for ; Wed, 20 Jul 2005 04:49:08 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C84B43D49 for ; Wed, 20 Jul 2005 04:49:08 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 10CE42B4E8; Tue, 19 Jul 2005 23:49:08 -0500 (CDT) Date: Tue, 19 Jul 2005 23:49:05 -0500 From: Craig Boston To: freebsd-current@freebsd.org Message-ID: <20050720044904.GA59111@nowhere> Mail-Followup-To: Craig Boston , freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: wi(4) IEEE_80211_S_SCAN 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: Wed, 20 Jul 2005 04:49:08 -0000 Hi everyone, Okay, only after banging my head against the wall for a couple hours trying to figure out why wpa_supplicant doesn't like my old prism2 card (I'm pretty sure it can't do WPA but I just want to auto-assign WEP keys...), I think it's because the wi driver just doesn't implement the IEEE_80211_S_SCAN state. It wasn't until discovering that "ifconfig wi0 scan" just sits there doing nothing that I began to suspect the new wlan infrastructure. So, is anybody working on the wi driver currently? I'm game for taking a stab at implementing those but I don't want to duplicate any effort that's already underway. I also wanted to check because maybe there are some gotchas that resulted in it not being implemented in the first place :) Craig From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 05:03: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 1F75416A41F for ; Wed, 20 Jul 2005 05:03:15 +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 C6A5243D45 for ; Wed, 20 Jul 2005 05:03: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 j6K53Dms027203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 22:03:14 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDDB32.1080402@errno.com> Date: Tue, 19 Jul 2005 22:03:46 -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: Craig Boston References: <20050720044904.GA59111@nowhere> In-Reply-To: <20050720044904.GA59111@nowhere> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wi(4) IEEE_80211_S_SCAN 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: Wed, 20 Jul 2005 05:03:15 -0000 Craig Boston wrote: > Hi everyone, > > Okay, only after banging my head against the wall for a couple hours > trying to figure out why wpa_supplicant doesn't like my old prism2 card > (I'm pretty sure it can't do WPA but I just want to auto-assign WEP > keys...), I think it's because the wi driver just doesn't implement the > IEEE_80211_S_SCAN state. > > It wasn't until discovering that "ifconfig wi0 scan" just sits there > doing nothing that I began to suspect the new wlan infrastructure. > > So, is anybody working on the wi driver currently? I'm game for taking > a stab at implementing those but I don't want to duplicate any effort > that's already underway. > > I also wanted to check because maybe there are some gotchas that > resulted in it not being implemented in the first place :) When I brought in the new net80211 code many months ago a certain person promised he would take care of any/all wi problems. He vapourized and noone else has stepped up. If you can take a crack at fixing wi I will help you as best I can (my time is very short these days). Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 05:22: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 2AB1316A41F for ; Wed, 20 Jul 2005 05:22:28 +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 CF45643D49 for ; Wed, 20 Jul 2005 05:22:27 +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 j6K5MQms027268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 22:22:27 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DDE0C2.2070302@errno.com> Date: Tue, 19 Jul 2005 22:27:30 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Tracanelli References: <42DD5B61.2060107@freebsdbrasil.com.br> <42DDD741.5030107@errno.com> In-Reply-To: <42DDD741.5030107@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: wlan_acl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 05:22:28 -0000 Sam Leffler wrote: > Patrick Tracanelli wrote: > >> >> How can I test wlan_acl(4)? I just read about it but could not find >> where to set 0, 1 or 2 to the acl policy or where to add MAC addresses >> to... >> > If it's not in man ifconfig then we need to fix the man page. I just checked man and it's missing the info. You should UTSL but a quick glance indicates the commands are: ifconfig ath0 mac:open ifconfig ath0 mac:allow ifconfig ath0 mac:deny ifconfig ath0 mac:flush ifconfig ath0 mac:detach ifconfig ath0 mac:add ifconfig ath0 mac:del It doesn't appear I did any status code (yet). I haven't tested the acl stuff forever but it should work w/ any card that is properly integrated with the net80211 layer (in this case the assoc-req frame must go through net80211 so the acl can be applied). Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 06:12: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 5860A16A41F for ; Wed, 20 Jul 2005 06:12:31 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 2279143D46 for ; Wed, 20 Jul 2005 06:12:29 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 89778 invoked from network); 20 Jul 2005 06:12:27 -0000 Received: from unknown (HELO ?192.168.0.101?) (a.premoli@andxor.it@81.174.31.42) by andxor.it with SMTP; 20 Jul 2005 06:12:27 -0000 Message-ID: <42DDEB35.7080509@FreeBSD.org> Date: Wed, 20 Jul 2005 08:12:05 +0200 From: Alex Dupre User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <20050719094905.F15510@fledge.watson.org> <42DCC637.2050103@FreeBSD.org> <42DDD4D7.8010602@errno.com> In-Reply-To: <42DDD4D7.8010602@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 06:12:31 -0000 Sam Leffler wrote: >> I have a (not so) similar problem with my atheros based D-Link >> DWL-G650 card with late CURRENTs. The problem is very strange: I can >> connect stablily to my neighbor's 11g wireless network (even if the >> signal is lower than my D-Link DI-624 AP) and I hardly can connect to >> my AP. When it happens, the connection goes down after few seconds (no >> carrier) and I cannot reconnect anymore. This used to work with older >> current (about a month ago). I though the AP was broken, but I have a >> 11b device (voip phone) that can connect without problems (yes, I >> tried to connect the card in 11b mode, w/ & w/o wep, but it's the same). >> Anyone seeing this? > > wi != ath > ap mode (really sta mode) != adhoc mode Yup, I said *not so* similar, but always related to 802.11 networks. I just wanted to know if other people had this issue. > You haven't provided any details of the setup that fails. Have you > tried setting up your ath card in 11b? As I said in the last phrase, yes, I tried. I tried changing channels, modes, wep encryption, AP distance, but without success. I can run the debug tests you want, just tell me what output you need, so that I'll not overflow you with useless information. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 06:22: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 0677816A420 for ; Wed, 20 Jul 2005 06:22:21 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: from relay.xtra-net.org (cable-195-162-200-89.customer.tvd.be [195.162.200.89]) by mx1.FreeBSD.org (Postfix) with SMTP id 10C0E43D45 for ; Wed, 20 Jul 2005 06:22:16 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 26956 invoked from network); 20 Jul 2005 06:22:15 -0000 Received: from sbegfxab.xtra-net.org (HELO mail.xtra-net.org) (192.168.1.19) by 0 with SMTP; 20 Jul 2005 06:22:15 -0000 Received: from 192.168.1.25 (proxying for 193.178.209.193) (SquirrelMail authenticated user jlang); by mail.xtra-net.org with HTTP; Wed, 20 Jul 2005 08:22:15 +0200 (CEST) Message-ID: <8268.192.168.1.25.1121840535.squirrel@192.168.1.25> In-Reply-To: <6.2.1.2.2.20050720124426.046af060@202.179.0.80> References: <6.2.1.2.2.20050720124426.046af060@202.179.0.80> Date: Wed, 20 Jul 2005 08:22:15 +0200 (CEST) From: "Vincent Blondel" 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 Cc: tegge@freebsd.org Subject: Re: linuxthreads compile error in latest 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 06:22:21 -0000 As you can see it we got the same problem. I don't have found any solution for it. This mailing list suggested to me to take contact with the responsible of this port but I don't have the time yet to do it. Now, this is done with this port and I am waiting for a response ... Regards Vincent. > Hi, > > I have FreeBSD 6.0 beta1 and I couldn't compile linuxthreads from ports. > How can I compile it successfully? > > thanks in advance, > > Ganbold > > daemon# uname -an > FreeBSD daemon.ub.mng.net 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Tue Jul 19 > 14:50:06 ULAST > 2005 tsgan@daemon.ub.mng.net:/usr/obj/usr/src/sys/DAEMON i386 > daemon# > > cc -O2 -fno-strict-aliasing -pipe -D_PTHREADS -I../ -I../sysdeps/i386 > -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -fexceptions -DIN_GCC > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DFINE_GRAINED_LIBRARIES > -D_PTHREADS > -DGTHREAD_USE_WEAK > -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -c > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > In file included from ../sysdeps/pthread/pthread.h:27, > from > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h:43, > from > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr.h:83, > from > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:42: > ../sysdeps/pthread/bits/pthreadtypes.h:51: error: conflicting types for > 'pthread_attr_t' > /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of > 'pthread_attr_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:59: error: conflicting types for > 'pthread_cond_t' > /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of > 'pthread_cond_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:66: error: conflicting types for > 'pthread_condattr_t' > /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of > 'pthread_condattr_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:69: error: conflicting types for > 'pthread_key_t' > /usr/include/sys/_pthreadtypes.h:70: error: previous declaration of > 'pthread_key_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:82: error: conflicting types for > 'pthread_mutex_t' > /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of > 'pthread_mutex_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:89: error: conflicting types for > 'pthread_mutexattr_t' > /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of > 'pthread_mutexattr_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:93: error: conflicting types for > 'pthread_once_t' > /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of > 'pthread_once_t' was here > ../sysdeps/pthread/bits/pthreadtypes.h:139: error: conflicting types for > 'pthread_t' > /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of > 'pthread_t' was here > *** Error code 1 > > Stop in /usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_16/libgcc_r. > *** Error code 1 > > Stop in /usr/ports/devel/linuxthreads. > > _______________________________________________ > 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" > -- Vincent Blondel homepage : http://jlang.dyndns.org registered LFS user : 7485 http://www.linuxfromscratch.org maintainer : http://oryx.xtra-net.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 07:17: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 7D28E16A41F for ; Wed, 20 Jul 2005 07:17:07 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ADBE43D58 for ; Wed, 20 Jul 2005 07:17:06 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1Dv97k-000AFu-Sk; Wed, 20 Jul 2005 16:36:13 +0900 Message-Id: <6.2.1.2.2.20050720161133.046a8880@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 16:16:33 +0900 To: "Vincent Blondel" From: Ganbold In-Reply-To: <8268.192.168.1.25.1121840535.squirrel@192.168.1.25> References: <6.2.1.2.2.20050720124426.046af060@202.179.0.80> <8268.192.168.1.25.1121840535.squirrel@192.168.1.25> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: linuxthreads compile error in latest 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 07:17:07 -0000 Vincent, I installed linuxthreads from ports on another FreeBSD 5.4 machine. Then I created package from it using "pkg_create -b linuxthreads-2.2.3_16" command. Afterwards I copied new binary package to my FreeBSD 6.0 beta1 machine and installed it using "pkg_add -v linuxthreads-2.2.3_16.tgz". Maybe this is wrong workaround and yet I didn't test it yet. I needed linuxthreads in order to install flash player plugin. Flash plugin works fine in firefox at least. hth, Ganbold At 03:22 PM 7/20/2005, you wrote: >As you can see it we got the same problem. > >I don't have found any solution for it. This mailing list suggested to me >to take contact with the responsible of this port but I don't have the >time yet to do it. > >Now, this is done with this port and I am waiting for a response ... > >Regards >Vincent. > > > Hi, > > > > I have FreeBSD 6.0 beta1 and I couldn't compile linuxthreads from ports_ > > How can I compile it successfully? > > > > thanks in advance, > > > > Ganbold > > > > daemon# uname -an > > FreeBSD daemon.ub.mng.net 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Tue Jul 19 > > 14:50:06 ULAST > > 2005 tsgan@daemon.ub.mng.net:/usr/obj/usr/src/sys/DAEMON i386 > > daemon# > > > > cc -O2 -fno-strict-aliasing -pipe -D_PTHREADS -I../ -I../sysdeps/i386 > > -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -fexceptions -DIN_GCC > > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DFINE_GRAINED_LIBRARIES > > -D_PTHREADS > > -DGTHREAD_USE_WEAK > > -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools > > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config > > -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -c > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > > In file included from ../sysdeps/pthread/pthread.h:27, > > from > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h:43, > > from > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr.h:83, > > from > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:42: > > ../sysdeps/pthread/bits/pthreadtypes.h:51: error: conflicting types for > > 'pthread_attr_t' > > /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of > > 'pthread_attr_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:59: error: conflicting types for > > 'pthread_cond_t' > > /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of > > 'pthread_cond_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:66: error: conflicting types for > > 'pthread_condattr_t' > > /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of > > 'pthread_condattr_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:69: error: conflicting types for > > 'pthread_key_t' > > /usr/include/sys/_pthreadtypes.h:70: error: previous declaration of > > 'pthread_key_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:82: error: conflicting types for > > 'pthread_mutex_t' > > /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of > > 'pthread_mutex_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:89: error: conflicting types for > > 'pthread_mutexattr_t' > > /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of > > 'pthread_mutexattr_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:93: error: conflicting types for > > 'pthread_once_t' > > /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of > > 'pthread_once_t' was here > > ../sysdeps/pthread/bits/pthreadtypes.h:139: error: conflicting types for > > 'pthread_t' > > /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of > > 'pthread_t' was here > > *** Error code 1 > > > > Stop in /usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_16/libgcc_r. > > *** Error code 1 > > > > Stop in /usr/ports/devel/linuxthreads. > > > > _______________________________________________ > > 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" > > > > >-- >Vincent Blondel >homepage : http://jlang.dyndns.org >registered LFS user : 7485 http://www.linuxfromscratch.org >maintainer : http://oryx.xtra-net.org > >_______________________________________________ >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 Wed Jul 20 07:33:55 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 B42BE16A41F for ; Wed, 20 Jul 2005 07:33:55 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BA7643D48 for ; Wed, 20 Jul 2005 07:33:55 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1Dv95V-00031V-00; Wed, 20 Jul 2005 09:33:53 +0200 Date: Wed, 20 Jul 2005 09:33:53 +0200 To: Benjamin Lutz Message-ID: <20050720073353.GI2715@poupinou.org> References: <42DBC456.7060205@datacomm.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DBC456.7060205@datacomm.ch> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: current@freebsd.org Subject: Re: ACPI: clock stops while sleeping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 07:33:55 -0000 On Mon, Jul 18, 2005 at 05:01:42PM +0200, Benjamin Lutz wrote: > Hello, > > I've installed FreeBSD-6.0-BETA1 on my Athlon64 (in amd64 mode), and I > must say, the new power management features are impressive. I've noticed > a slight hitch though: When I send the CPU to sleep with acpiconf -s 1, > the clock will stop, resulting in the system time being wrong after > wakeup. Is there something I can do to fix this, other than run ntpdate? > (How to solve this without a network connection?) The pmtimer device is not yet ported to the amd64 architecture it seems. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 08:10: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 DBA8B16A41F for ; Wed, 20 Jul 2005 08:10:06 +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 66BD043D48 for ; Wed, 20 Jul 2005 08:10:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id E217F46B29; Wed, 20 Jul 2005 04:10:03 -0400 (EDT) Date: Wed, 20 Jul 2005 09:10:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Leffler In-Reply-To: <42DDD662.6050501@errno.com> Message-ID: <20050720090428.B50372@fledge.watson.org> References: <20050719094905.F15510@fledge.watson.org> <42DDD662.6050501@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 08:10:07 -0000 On Tue, 19 Jul 2005, Sam Leffler wrote: >> I fairly regularly use 802.11 adhoc with WEP to communicate between my >> 6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running >> Mac OS X Tiger. A few days ago, when I updated from a June to a July >> HEAD revision, this became quite "fragile". Specifically, I often find >> that the Mac can't send to the FreeBSD box (ARP fails, etc), and that >> sometimes it will give an error when I ask it to re-connect to the ad >> hoc network. I find that if I ifconfig down/up if_wi, and likewise turn >> off and on the wireless on the PowerBook, it seems to recover. I've >> not had a chance to really try and diagnose this at all -- i.e., does >> tcpdump show packets on either end, 802.11 state machine, etc. I was >> wondering if anyone else has seen this problem, though. > > You didn't provide any config info. I recently noticed the wi driver > isn't hooked up properly to the net80211 layer causing link state events > to not be done properly (it appears disassoc events were being generated > but not assoc/reassoc events). If you're using dhclient+adhoc mode then > this might be related. It's an entirely manual configuration job: #!/bin/sh ifconfig wi0 ssid network wepmode on weptxkey 1 \ wepkey 1:0xaaaaaaaaaaaaaaaaaaaaaaaaaa ifconfig wi0 mediaopt adhoc ifconfig wi0 inet 192.168.11.1 ifconfig wi0 up ipfw delete 5005 ipfw add 5005 allow tcp from any to any via wi0 Previously, this worked without a hitch, and I'll normally transfer several gigabytes of data. Now it works for some period, then appears to wedge. It will then recover after a few minutes, usually 5-10 minutes. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 08:32: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 AFA2F16A41F for ; Wed, 20 Jul 2005 08:32:45 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from mail.blastwave.org (mail.blastwave.org [147.87.98.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31F2043D46 for ; Wed, 20 Jul 2005 08:32:44 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from localhost (localhost [127.0.0.1]) by mail.blastwave.org (Postfix) with ESMTP id 2868FF896 for ; Wed, 20 Jul 2005 10:32:43 +0200 (MEST) Received: from mail.blastwave.org ([127.0.0.1]) by localhost (enterprise [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26156-04-2 for ; Wed, 20 Jul 2005 10:32:39 +0200 (MEST) Received: from defiant.dogan.ch (defiant.dogan.ch [213.144.141.146]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.blastwave.org (Postfix) with ESMTP id 6B902F892 for ; Wed, 20 Jul 2005 10:32:39 +0200 (MEST) Received: by defiant.dogan.ch (Postfix, from userid 1000) id 512F3179AC; Wed, 20 Jul 2005 10:32:38 +0200 (CEST) Date: Wed, 20 Jul 2005 10:32:38 +0200 From: Ihsan Dogan To: freebsd-current@freebsd.org Message-ID: <20050720083238.GA2195@dogan.ch> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD/i386 1.6.2 X-Uptime: 10:27AM up 360 days, 22:52, 8 users, load averages: 0.70, 0.83, 0.87 X-Binford: 6100 (more power) X-Editor: Vim-603 http://www.vim.org X-Virus-Scanned: amavisd-new at blastwave.org Subject: 6.0-BETA1 on Thinkpad T42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 08:32:45 -0000 Hello, I've upgraded my T42 from 5.4 to 6.0-BETA1. With 6.0-BETA1, a wake-up after a suspend doesn't work. If X is running, the machine is freezed. If X isn't running, the machine is responding very slowly and it's unusable. The second problem is, that under X applications (like xterm) are dieing with signal 11. Are these known issues? Ihsan... -- Swiss Unix User Group: http://www.suug.ch/ Software Packages for Solaris: http://www.blastwave.org/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 08:42: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 E00EA16A41F for ; Wed, 20 Jul 2005 08:42:20 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3455D43D4C for ; Wed, 20 Jul 2005 08:42:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:H4cgQF4m0ZfyiaBruK5IvZnm0az2fS9XHqT9GbKMnvI+YYgAbAeRJNc/CKLbMyJj@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j6K8fs2H067207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2005 17:41:55 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 20 Jul 2005 17:41:54 +0900 Message-ID: From: Hajimu UMEMOTO To: Ihsan Dogan In-Reply-To: <20050720083238.GA2195@dogan.ch> References: <20050720083238.GA2195@dogan.ch> User-Agent: xcite1.38> 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) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:::1]); Wed, 20 Jul 2005 17:41:55 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: freebsd-current@freebsd.org Subject: Re: 6.0-BETA1 on Thinkpad T42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 08:42:21 -0000 Hi, >>>>> On Wed, 20 Jul 2005 10:32:38 +0200 >>>>> Ihsan Dogan said: ihsan> I've upgraded my T42 from 5.4 to 6.0-BETA1. With 6.0-BETA1, a ihsan> wake-up after a suspend doesn't work. If X is running, the ihsan> machine is freezed. If X isn't running, the machine is responding ihsan> very slowly and it's unusable. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222&r2=1.222.2.1 should solve your problem. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 09:25: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 A2F4C16A41F for ; Wed, 20 Jul 2005 09:25:51 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from mail.blastwave.org (mail.blastwave.org [147.87.98.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2370F43D4C for ; Wed, 20 Jul 2005 09:25:50 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from localhost (localhost [127.0.0.1]) by mail.blastwave.org (Postfix) with ESMTP id 04C58F89E for ; Wed, 20 Jul 2005 11:25:50 +0200 (MEST) Received: from mail.blastwave.org ([127.0.0.1]) by localhost (enterprise [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28620-02-2 for ; Wed, 20 Jul 2005 11:25:45 +0200 (MEST) Received: from defiant.dogan.ch (defiant.dogan.ch [213.144.141.146]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.blastwave.org (Postfix) with ESMTP id 30480F896 for ; Wed, 20 Jul 2005 11:25:45 +0200 (MEST) Received: by defiant.dogan.ch (Postfix, from userid 1000) id 318CE179AA; Wed, 20 Jul 2005 11:25:44 +0200 (CEST) Date: Wed, 20 Jul 2005 11:25:44 +0200 From: Ihsan Dogan To: freebsd-current@freebsd.org Message-ID: <20050720092544.GA3563@dogan.ch> Mail-Followup-To: freebsd-current@freebsd.org References: <20050720083238.GA2195@dogan.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD/i386 1.6.2 X-Uptime: 11:11AM up 360 days, 23:37, 11 users, load averages: 1.55, 1.12, 1.01 X-Binford: 6100 (more power) X-Editor: Vim-603 http://www.vim.org X-Virus-Scanned: amavisd-new at blastwave.org Subject: Re: 6.0-BETA1 on Thinkpad T42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 09:25:51 -0000 Hello, On Wednesday, 20 Jul 2005 17:41 +0900, Hajimu UMEMOTO wrote: > >>>>> On Wed, 20 Jul 2005 10:32:38 +0200 > >>>>> Ihsan Dogan said: > > ihsan> I've upgraded my T42 from 5.4 to 6.0-BETA1. With 6.0-BETA1, a > ihsan> wake-up after a suspend doesn't work. If X is running, the > ihsan> machine is freezed. If X isn't running, the machine is responding > ihsan> very slowly and it's unusable. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222&r2=1.222.2.1 > should solve your problem. Thank you for the hint, it's much better now, but still not perfect. - If X is running, the screen looks sometimes weird. After I switched to the console and then back to X, it's fine again. - After a wake-up, the system is hanging every few minutes for about 5-10 seconds. I've got also this in /var/log/messages: Jul 20 11:08:17 makar kernel: wakeup from sleeping state (slept 00:00:30) Jul 20 11:08:20 makar kernel: can't re-use a leaf (directional_scrolls)! Jul 20 11:08:20 makar kernel: can't re-use a leaf (low_speed_threshold)! Jul 20 11:08:20 makar kernel: can't re-use a leaf (min_movement)! Jul 20 11:08:20 makar kernel: can't re-use a leaf (squelch_level)! Ihsan... -- Swiss Unix User Group: http://www.suug.ch/ Software Packages for Solaris: http://www.blastwave.org/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 09:48: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 7F22616A41F; Wed, 20 Jul 2005 09:48:46 +0000 (GMT) (envelope-from riggs@rrr.de) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0943E43D46; Wed, 20 Jul 2005 09:48:45 +0000 (GMT) (envelope-from riggs@rrr.de) Received: from mail.m-online.net (svr20.m-online.net [192.168.3.148]) by mail-out.m-online.net (Postfix) with ESMTP id 61C91FB1B; Wed, 20 Jul 2005 11:48:44 +0200 (CEST) Received: from marvin.riggiland.au (ppp-62-245-162-72.mnet-online.de [62.245.162.72]) by mail.m-online.net (Postfix) with ESMTP id 197E9C6600; Wed, 20 Jul 2005 11:48:42 +0200 (CEST) Received: from marvin.riggiland.au (localhost [127.0.0.1]) by marvin.riggiland.au (8.13.3/8.13.3) with ESMTP id j6K9mW0t065237; Wed, 20 Jul 2005 11:48:32 +0200 (CEST) (envelope-from riggs@marvin.riggiland.au) Received: (from riggs@localhost) by marvin.riggiland.au (8.13.3/8.13.3/Submit) id j6K9mVrd065236; Wed, 20 Jul 2005 11:48:31 +0200 (CEST) (envelope-from riggs) Date: Wed, 20 Jul 2005 11:48:30 +0200 From: "Thomas E. Zander" To: freebsd-current@freebsd.org Message-ID: <20050720094830.GR782@marvin.riggiland.au> References: <42DD64AB.3000605@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <42DD64AB.3000605@centtech.com> Organization: Chaotic X-PGP-KeyID: 0xC85996CD X-PGP-URI: http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xC85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-Mailer: Marvin Mail (Build 1121849089) X-Operating-System: FreeBSD 5.4-STABLE Cc: freebsd-fs@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 09:48:46 -0000 Hi, On Tue, 19. Jul 2005, at 15:38 -0500, Eric Anderson wrote according to [mksnap_ffs takes 4-5 minutes?]: > This time, when I ran mksnap_ffs, the command took nearly 5 minutes [...] > Filesystem 1K-blocks Used Avail Capacity iused ifree > /dev/da1s1d 406234604 91799154 281936682 25% 1300303 51197103 I have a fs here with similar (but smaller size) parameters concerning inode density and usage: Filesystem 1K-blocks Used Avail Capacity iused ifree /dev/ad1s1d 113390248 92926924 18195520 84% 248434 14424460 time mksnap_ffs'ing gives the following result: 0.007u 1.902s 1:51.94 1.6% 5+217k 4493+8646io 0pf+0w It takes almost 2 minutes which seem to perform similarly to your 5 minutes. (There was not a single file opened when snapping.) I'd expect snapping to speed up by reducing the inode number when doing newfs, but I haven't verified this right now. Riggs (f'up to freebsd-fs) -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. ---- "It committed suicide." said Marvin. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 10:07: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 82FD816A41F for ; Wed, 20 Jul 2005 10:07:27 +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 2731643D49 for ; Wed, 20 Jul 2005 10:07:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 656D0C004; Wed, 20 Jul 2005 12:07:25 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 26CF2405B; Wed, 20 Jul 2005 12:07:15 +0200 (CEST) Date: Wed, 20 Jul 2005 12:07:15 +0200 From: Jeremie Le Hen To: Max Laier Message-ID: <20050720100715.GS39292@obiwan.tataz.chchile.org> References: <20050720.084222.846946475.ken@tydfam.jp> <200507200149.52721.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507200149.52721.max@love2party.net> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 10:07:27 -0000 Hi, > > I have the following error for three days. > > Quick fixes are appreciated. > > > > ===> xl (all) > > cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc > > -I- -include /usr/obj/usr/src/sys/TYD3/opt_global.h -I. -I@ > > -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common > > -I/usr/obj/usr/src/sys/TYD3 -mno-align-long-strings > > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > > -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -fformat-extensions -std=c99 -c > > /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o > > if_xl.kld if_xl.o > > touch export_syms > > awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld > > export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-common > > -o if_xl.ko if_xl.kld > > objcopy --strip-debug if_xl.ko > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > Looks like you are building with "-jN" where N>=2, can you lose that switch so > that we can see the real error at the end of the output? I think this has already been answered yesterday. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=322121+0+current/freebsd-current Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 10:38:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 259BC16A41F; Wed, 20 Jul 2005 10:38:21 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BEC543D46; Wed, 20 Jul 2005 10:38:20 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j6KAc45C052977; Wed, 20 Jul 2005 12:38:05 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Sam Leffler In-Reply-To: <42DDD710.4030503@errno.com> References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> Content-Type: text/plain Date: Wed, 20 Jul 2005 12:38:04 +0200 Message-Id: <1121855884.796.8.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 10:38:21 -0000 Sam Leffler wrote: > Michal Mertl wrote: > > Robert Watson wrote: > > > >>I fairly regularly use 802.11 adhoc with WEP to communicate between my > >>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > >>OS X Tiger. A few days ago, when I updated from a June to a July HEAD > >>revision, this became quite "fragile". Specifically, I often find that > >>the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes > >>it will give an error when I ask it to re-connect to the ad hoc network. > >>I find that if I ifconfig down/up if_wi, and likewise turn off and on the > >>wireless on the PowerBook, it seems to recover. I've not had a chance to > >>really try and diagnose this at all -- i.e., does tcpdump show packets on > >>either end, 802.11 state machine, etc. I was wondering if anyone else has > >>seen this problem, though. > > > > > > Yes, I'm also experiencing similar problems. The problems seem to happen > > also with different wireless cards and without wep. They were reported > > by Johann Hugo on 14th in an email titled "ath hostap - clients > > assosiated, but no comms" too. > > > > Another problem with WiFi which Johann reported long time ago is that > > bridging on atheros (only?) AP works really bad. I get very varying ping > > response (50 - inf. ms). Sometimes it seems the packets get queued > > somewhere - after some time I receive several replies at once. > > I routinely bridge ath cards (a wide variety) with bge using bridge and > see no problems. I get ~36 Mb/s in 11a w/ superg features and ~28 Mb/s > w/ basic stuff (what you find in RELENG_6). ping times are what you'd > expect (<1ms). I'm sorry, I was too brief in the description of the problem. It's the bridging on the card which works slow. I run an ath card in hostap mode and several wireless clients connect to it and are on the same IP network. The ping from one client to another is slow yet both ping the AP fine. I think that in this situation the bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. Michal From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:29: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 9F3A916A41F for ; Wed, 20 Jul 2005 11:29:53 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33B6C43D46 for ; Wed, 20 Jul 2005 11:29:53 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so1507077wra for ; Wed, 20 Jul 2005 04:29: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gKpfGYjNpdlJfLFfe/Au+zg7CEN5FrQDaowJxjF+MKGDfgV3RoLgXwIeBmdVAoByndFo5EtdwvhZouCjyNP89jyIv2iXOBiNx3iC8AAU2YBSVOubZ5HfFledS0QljL9Svbj3PHwZgAM1ro859hee0KitFacgRVTMrF1PICBRNGU= Received: by 10.54.34.61 with SMTP id h61mr34589wrh; Wed, 20 Jul 2005 04:29:02 -0700 (PDT) Received: by 10.54.80.4 with HTTP; Wed, 20 Jul 2005 04:29:02 -0700 (PDT) Message-ID: <4cf221cc05072004295dbdfd3d@mail.gmail.com> Date: Wed, 20 Jul 2005 13:29:02 +0200 From: Erik Winge To: freebsd-current@freebsd.org In-Reply-To: <42DB9B45.9010305@cytexbg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4cf221cc050717045319c1f3cf@mail.gmail.com> <42DA9332.2030200@errno.com> <4cf221cc050718035328cfb071@mail.gmail.com> <42DB9B45.9010305@cytexbg.com> Subject: Re: if_ural in 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erik Winge List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 11:29:53 -0000 On 7/18/05, Niki Denev wrote: >=20 > I'm not really sure, so this is just a guess, but can this be caused by > the power management of the card? > Does it dissociate when its configured with '-powersave' flag? No, that doesn't seem to help. Since this is a desktop system, I wouldn't expect it to have any power management at all? Erik Winge From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:43: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 DC5D216A41F for ; Wed, 20 Jul 2005 11:43:22 +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 7A51843D48 for ; Wed, 20 Jul 2005 11:43:21 +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 j6KBhHp9054000; Wed, 20 Jul 2005 06:43:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42DE38D3.8010606@centtech.com> Date: Wed, 20 Jul 2005 06:43:15 -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: Skylar Thompson References: <42DD64AB.3000605@centtech.com> <20050720040336.GA69292@quark.cs.earlham.edu> In-Reply-To: <20050720040336.GA69292@quark.cs.earlham.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/984/Tue Jul 19 04:16:09 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 11:43:23 -0000 Skylar Thompson wrote: > On Tue, Jul 19, 2005 at 03:38:03PM -0500, Eric Anderson wrote: > >>Last week, I tried making a snapshot of one of my NFS servers' >>partitions. I've done this one other machines before, with smaller >>barely used partitions, and it has always been relatively snappy. >> >>This time, when I ran mksnap_ffs, the command took nearly 5 minutes, in >>which time all NFS traffic was suspended, as well as all disk access on >>the machine. After reading in the FreeBSD Implementation book >>(McKusick), it claims it should be very very fast. >> >>Anyone know why it should take so long to do this snapshot? Is this >>expected normal behaviour, or should I expect faster snapshots? >> >>Here's some info on the filesystem: >>Filesystem 1K-blocks Used Avail Capacity iused ifree >>%iused Mounted on >>/dev/da1s1d 406234604 91799154 281936682 25% 1300303 51197103 >> 2% /scr03 >> >>/dev/da1s1d on /scr03 (ufs, NFS exported, local, soft-updates) > > > Does that filesystem have a lot of open files? I believe all busy inodes > have to be copied in the snapshot process. > It probably did, however I ran the same test on a filesystem even larger (15million used inodes, 229million inodes free), that took 30minutes, with no open files! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:43: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 3C29416A462 for ; Wed, 20 Jul 2005 11:43:33 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (pipa.profix.cz [213.151.89.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8991043D45 for ; Wed, 20 Jul 2005 11:43:32 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id C42334E705 for ; Wed, 20 Jul 2005 13:43:31 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17873-02 for ; Wed, 20 Jul 2005 13:43:31 +0200 (CEST) Received: from gandalf (105.121.95.80.ip.b26.cz [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 868A64E704 for ; Wed, 20 Jul 2005 13:43:31 +0200 (CEST) From: =?US-ASCII?Q?Daniel_Dvorak?= To: Date: Wed, 20 Jul 2005 13:43:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200507200149.52721.max@love2party.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 thread-index: AcWMvKwodOJBKcFsQemVHvJf8HjejAAWF+/w Message-Id: <20050720114331.868A64E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Subject: RE: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 11:43:33 -0000 Yes, I can confirm this bug, when one use make buildworld with -jN. If you build the code without -jN, it is all right. -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Max Laier Sent: Wednesday, July 20, 2005 1:50 AM To: freebsd-current@freebsd.org Subject: Re: -current kernel can't be complied for 3 days On Wednesday 20 July 2005 01:42, Yamada Ken Takeshi wrote: > I have the following error for three days. > Quick fixes are appreciated. > > ===> xl (all) > cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc > -I- -include /usr/obj/usr/src/sys/TYD3/opt_global.h -I. -I@ > -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common > -I/usr/obj/usr/src/sys/TYD3 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -c > /usr/src/sys/modules/xl/../../pci/if_xl.c ld -d -warn-common -r -d -o > if_xl.kld if_xl.o > touch export_syms > awk -f /usr/src/sys/modules/xl/../../conf/kmod_syms.awk if_xl.kld > export_syms | xargs -J% objcopy % if_xl.kld ld -Bshareable -d -warn-common > -o if_xl.ko if_xl.kld > objcopy --strip-debug if_xl.ko > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error Looks like you are building with "-jN" where N>=2, can you lose that switch so that we can see the real error at the end of the output? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:57: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 8353616A41F; Wed, 20 Jul 2005 11:57:26 +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 1E4C543D45; Wed, 20 Jul 2005 11:57:25 +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 j6KBvL43054377; Wed, 20 Jul 2005 06:57:25 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42DE3C1F.9070704@centtech.com> Date: Wed, 20 Jul 2005 06:57:19 -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: "Thomas E. Zander" References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> In-Reply-To: <20050720094830.GR782@marvin.riggiland.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/984/Tue Jul 19 04:16:09 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 11:57:26 -0000 Thomas E. Zander wrote: > Hi, > > On Tue, 19. Jul 2005, at 15:38 -0500, Eric Anderson wrote > according to [mksnap_ffs takes 4-5 minutes?]: > > >>This time, when I ran mksnap_ffs, the command took nearly 5 minutes > > > [...] > > >>Filesystem 1K-blocks Used Avail Capacity iused ifree >>/dev/da1s1d 406234604 91799154 281936682 25% 1300303 51197103 > > > I have a fs here with similar (but smaller size) parameters concerning > inode density and usage: > > Filesystem 1K-blocks Used Avail Capacity iused ifree > /dev/ad1s1d 113390248 92926924 18195520 84% 248434 14424460 > > time mksnap_ffs'ing gives the following result: > 0.007u 1.902s 1:51.94 1.6% 5+217k 4493+8646io 0pf+0w > > It takes almost 2 minutes which seem to perform similarly to your 5 > minutes. > (There was not a single file opened when snapping.) > > I'd expect snapping to speed up by reducing the inode number when doing > newfs, but I haven't verified this right now. A 2tb filesystem with the standard newfs options takes about 30 minutes to mksnap.. That's unusable really, because the filesystem is suspended for so long. Even empty 2tb filesystems take forever, so it's related to the amount of inodes. How can we make this snappier? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 12:19: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 5028C16A41F for ; Wed, 20 Jul 2005 12:19:34 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA7043D4C for ; Wed, 20 Jul 2005 12:19:32 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 77377 invoked by uid 1005); 20 Jul 2005 12:19:31 -0000 Received: from rainer@ultra-secure.de by bsd.ultra-secure.de by uid 89 with qmail-scanner-1.22 (clamdscan: 0.85. spamassassin: 2.64. Clear:RC:1(213.196.191.65):. Processed in 0.181407 secs); 20 Jul 2005 12:19:31 -0000 Received: from unknown (HELO ?192.168.100.235?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Jul 2005 12:19:30 -0000 Message-ID: <42DE414C.3070905@ultra-secure.de> Date: Wed, 20 Jul 2005 14:19:24 +0200 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050701) X-Accept-Language: en-us, en MIME-Version: 1.0 To: amp References: <42D92471.20408@ultra-secure.de><98702c705071723143943b2a6@mail.gmail.com> <42DCB6C8.8080201@ultra-secure.de> <008201c58c48$1ce830c0$b001a8c0@nasioncom.com.my> In-Reply-To: <008201c58c48$1ce830c0$b001a8c0@nasioncom.com.my> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: FreeBSD6, FSC Lifebook E8010, Xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 12:19:34 -0000 amp wrote: > You can try by issuing: > > shell# kldload agp > > (check your ttyv0 console or /var/log/messages for some info) > > If it OK, you can use the agp module by putting *agp_load="YES"* on > /boot/loader.conf > or recompile the kernel back by inserting *device agp* on your kernel > configuration. > > OK, as I said, I tried both agp in the config-file and in loader.conf - but no change. As you can see from the following, it doesn't detect my i855 integrated graphics controller, which I assume it should. this is the kernel-configuration: machine i386 cpu I686_CPU ident LBE options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directoriesoptions MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS)options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device isa device pci device fdc device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device atapicam device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device npx device pmtimer device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus device sio # 8250, 16[45]50 based serial ports device ppc device ppbus # Parallel port bus (required) device lpt # Printer device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device iwi device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) That's my loader.conf: lbe# cat /boot/loader.conf agp_load="YES" snd_ich_load="YES" acpi_fujitsu_load="YES" cpufreq_load="YES" acpi_video_load="YES" smbus_load="YES" iicsmb_load="YES" bktr_load="YES" That's what I get from a dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #2: Wed Jul 20 13:49:44 CEST 2005 root@lbe.example.org:/usr/obj/usr/src/sys/LBE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.60GHz (1600.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 527368192 (502 MB) avail memory = 506732544 (483 MB) bktr_mem: memory holder loaded npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 11 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfc08-0xfc0b on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) acpi_video0: port 0x1800-0x1807 mem 0xd8000000-0xdfffffff,0xd0000000-0xd007ffff irq 11 at device 2.0 on pci0 pci0: at device 2.1 (no driver attached) uhci0: port 0x1820-0x183f 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 0x1840-0x185f 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 0x1860-0x187f 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 0xd0100000-0xd01003ff 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 pcib1: at device 30.0 on pci0 pci1: on pcib1 cbb0: irq 11 at device 10.0 on pci1 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 10.1 on pci1 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci1: at device 10.2 (no driver attached) cbb2: at device 10.3 on pci1 cardbus2: on cbb2 pccard2: <16-bit PCCard bus> on cbb2 bge0: mem 0xd0200000-0xd020ffff irq 11 at device 12.0 on pci1 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:0b:5d:4c:4e:b9 iwi0: mem 0xd0215000-0xd0215fff irq 11 at device 13.0 on pci1 iwi0: Ethernet address: 00:0e:35:28:4e:18 fwohci0: mem 0xd0216000-0xd02167ff,0xd0210000-0xd0213fff irq 11 at device 14.0 on pci1 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:02:90:a7:76 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 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) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xd0100c00-0xd0100dff,0xd0100800-0xd01008ff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1 port 0x2e8-0x2ef,0x400-0x43f irq 3 drq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port acpi_fujitsu0: on acpi0 acpi_fujitsu0: Couldn't query volume level acpi_fujitsu0: Couldn't init button states acpi_fujitsu0: Couldn't initialize button states! pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff 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 Timecounter "TSC" frequency 1600062995 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38154MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 ATA PseudoRAID loaded cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a acpi_fujitsu0: Couldn't query method acpi_fujitsu0: Couldn't query method acpi_fujitsu0: Couldn't query method acpi_fujitsu0: Couldn't query method And that's what pciconf -lv says: hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Host-Hub Interface Bridge' class = bridge subclass = HOST-PCI none0@pci0:0:1: class=0x088000 card=0x11d510cf chip=0x35848086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara System Memory Controller' class = base peripheral none1@pci0:0:3: class=0x088000 card=0x11d510cf chip=0x35858086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Configuration Process' class = base peripheral acpi_video0@pci0:2:0: class=0x030000 card=0x128110cf chip=0x35828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device' class = display subclass = VGA none2@pci0:2:1: class=0x038000 card=0x128110cf chip=0x35828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device' class = display uhci0@pci0:29:0: class=0x0c0300 card=0x11ab10cf chip=0x24c28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x11ab10cf chip=0x24c48086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x11ab10cf chip=0x24c78086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x11ab10cf chip=0x24cd8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI Controller' class = serial bus subclass = USB pcib1@pci0:30:0: class=0x060400 card=0x00000000 chip=0x24488086 rev=0x83 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24cc8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DBM (ICH4-M) LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x11ab10cf chip=0x24ca8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DBM (ICH4-M) UltraATA/100 EIDE Controller' class = mass storage subclass = ATA none3@pci0:31:3: class=0x0c0500 card=0x11ab10cf chip=0x24c38086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller' class = serial bus subclass = SMBus pcm0@pci0:31:5: class=0x040100 card=0x127d10cf chip=0x24c58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller' class = multimedia subclass = audio none4@pci0:31:6: class=0x070300 card=0x10d110cf chip=0x24c68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller' class = simple comms subclass = generic modem cbb0@pci1:10:0: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' class = bridge subclass = PCI-CardBus cbb1@pci1:10:1: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' class = bridge subclass = PCI-CardBus none5@pci1:10:2: class=0x088000 card=0x11c410cf chip=0x71101217 rev=0x00 hdr=0x00 vendor = 'O2 Micro Inc' device = 'OZ711Mx MemoryCardBus Accelerator' class = base peripheral cbb2@pci1:10:3: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' class = bridge subclass = PCI-CardBus bge0@pci1:12:0: class=0x020000 card=0x127910cf chip=0x165e14e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5705MA2 NetXtreme Gigabit Ethernet' class = network subclass = ethernet iwi0@pci1:13:0: class=0x028000 card=0x27028086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network fwohci0@pci1:14:0: class=0x0c0010 card=0x116210cf chip=0x8026104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB21 1394a-2000 OHCI PHY/link-layer Controller' class = serial bus subclass = FireWire From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 13:05: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 DBBF416A41F; Wed, 20 Jul 2005 13:05:49 +0000 (GMT) (envelope-from riggs@rrr.de) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4947743D4C; Wed, 20 Jul 2005 13:05:34 +0000 (GMT) (envelope-from riggs@rrr.de) Received: from mail.m-online.net (svr20.m-online.net [192.168.3.148]) by mail-out.m-online.net (Postfix) with ESMTP id EA25EFCB1; Wed, 20 Jul 2005 15:05:32 +0200 (CEST) Received: from marvin.riggiland.au (ppp-62-245-162-72.mnet-online.de [62.245.162.72]) by mail.m-online.net (Postfix) with ESMTP id 5C936C6C83; Wed, 20 Jul 2005 15:05:31 +0200 (CEST) Received: from marvin.riggiland.au (localhost [127.0.0.1]) by marvin.riggiland.au (8.13.3/8.13.3) with ESMTP id j6KD5R1D066474; Wed, 20 Jul 2005 15:05:28 +0200 (CEST) (envelope-from riggs@marvin.riggiland.au) Received: (from riggs@localhost) by marvin.riggiland.au (8.13.3/8.13.3/Submit) id j6KD5PSX066473; Wed, 20 Jul 2005 15:05:25 +0200 (CEST) (envelope-from riggs) Date: Wed, 20 Jul 2005 15:05:23 +0200 From: "Thomas E. Zander" To: Eric Anderson Message-ID: <20050720130523.GT782@marvin.riggiland.au> References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> <42DE3C1F.9070704@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <42DE3C1F.9070704@centtech.com> Organization: Chaotic X-PGP-KeyID: 0xC85996CD X-PGP-URI: http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xC85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-Mailer: Marvin Mail (Build 1121863362) X-Operating-System: FreeBSD 5.4-STABLE Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 13:05:50 -0000 Hi, On Wed, 20. Jul 2005, at 6:57 -0500, Eric Anderson wrote according to [Re: mksnap_ffs takes 4-5 minutes?]: > A 2tb filesystem with the standard newfs options takes about 30 minutes > to mksnap.. That's unusable really, because the filesystem is suspended > for so long. Even empty 2tb filesystems take forever, so it's related > to the amount of inodes. > > How can we make this snappier? For the moment we can workaround by setting inode density appropriately when creating the fs. However this is only feasible if you know what your users are going to do with the fs; it also doesn't help when you *need* a large fs containing many small files. In the long run, dynamic inode (de)allocation would be nice to have. Also...what about the 'preparation' time for snapping? IIRC McKusick said that the lion's share of snapping time is used to delay pending transactions before actually doing the snap. There are quite some scenarios in which you can be certain that there is no file opened for writing, so a snap could be taken immediately. Would it be feasible to implement this feature? Or am I completely wrong? Riggs -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. ---- "It committed suicide." said Marvin. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 14:44: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 1A3FD16A420; Wed, 20 Jul 2005 14:44:46 +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 BE68B43D5C; Wed, 20 Jul 2005 14:44:44 +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 j6KEigms030105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2005 07:44:44 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42DE648B.1060402@errno.com> Date: Wed, 20 Jul 2005 07:49:47 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Mertl References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> <1121855884.796.8.camel@genius1.i.cz> In-Reply-To: <1121855884.796.8.camel@genius1.i.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 14:44:46 -0000 Michal Mertl wrote: > Sam Leffler wrote: > >>Michal Mertl wrote: >> >>>Robert Watson wrote: >>> >>> >>>>I fairly regularly use 802.11 adhoc with WEP to communicate between my >>>>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac >>>>OS X Tiger. A few days ago, when I updated from a June to a July HEAD >>>>revision, this became quite "fragile". Specifically, I often find that >>>>the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes >>>>it will give an error when I ask it to re-connect to the ad hoc network. >>>>I find that if I ifconfig down/up if_wi, and likewise turn off and on the >>>>wireless on the PowerBook, it seems to recover. I've not had a chance to >>>>really try and diagnose this at all -- i.e., does tcpdump show packets on >>>>either end, 802.11 state machine, etc. I was wondering if anyone else has >>>>seen this problem, though. >>> >>> >>>Yes, I'm also experiencing similar problems. The problems seem to happen >>>also with different wireless cards and without wep. They were reported >>>by Johann Hugo on 14th in an email titled "ath hostap - clients >>>assosiated, but no comms" too. >>> >>>Another problem with WiFi which Johann reported long time ago is that >>>bridging on atheros (only?) AP works really bad. I get very varying ping >>>response (50 - inf. ms). Sometimes it seems the packets get queued >>>somewhere - after some time I receive several replies at once. >> >>I routinely bridge ath cards (a wide variety) with bge using bridge and >>see no problems. I get ~36 Mb/s in 11a w/ superg features and ~28 Mb/s >>w/ basic stuff (what you find in RELENG_6). ping times are what you'd >>expect (<1ms). > > > I'm sorry, I was too brief in the description of the problem. It's the > bridging on the card which works slow. > > I run an ath card in hostap mode and several wireless clients connect to > it and are on the same IP network. The ping from one client to another > is slow yet both ping the AP fine. I think that in this situation the > bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. The bridging is done in the net80211 layer, not "in the card". I will test, thank you. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 15:39: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 4015816A41F for ; Wed, 20 Jul 2005 15:39:44 +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 1299A43D48 for ; Wed, 20 Jul 2005 15:39:43 +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 j6KFdgCq035343; Wed, 20 Jul 2005 08:39:42 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6KFdgLF035342; Wed, 20 Jul 2005 08:39:42 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Jul 2005 08:39:42 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20050720083942.A35046@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: TAILQ_* ambiguity in sys/sys/bio.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: Wed, 20 Jul 2005 15:39:44 -0000 forgive me if i am wrong, but there appears to be a source of ambiguity in the use of TAILQ* macros in sys/sys/bio.h We have struct bio_queue_head { TAILQ_HEAD(bio_queue, bio) queue; off_t last_offset; struct bio *insert_point; }; where the "bio_queue" name refers to a name of an internally declared structure whose only instance is 'queue', and then we have struct bio { ... TAILQ_ENTRY(bio) bio_queue; /* Disksort queue. */ ... } where bio_queue is a field name. An example where the confusion is evident is this line in kern/subr_disk.c::bioq_remove() head->insert_point = TAILQ_PREV(bp, bio_queue, bio_queue); where the former 'bio_queue' is a type name, and the second a field name. Any objection to remove the ambiguity by renaming the type name in struct bio_queue_head to something else ? (ideally i'd rather not use a name at all, but apparently some of the TAILQ_ macros do require a name for this struct even though it's unambiguous once you know it's a TAILQ). cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 15:50: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 2941716A420 for ; Wed, 20 Jul 2005 15:50:04 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9046C43D53 for ; Wed, 20 Jul 2005 15:50:00 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 7E1FABC89; Wed, 20 Jul 2005 15:49:57 +0000 (UTC) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 20 Jul 2005 08:39:42 PDT." <20050720083942.A35046@xorpc.icir.org> Date: Wed, 20 Jul 2005 17:49:57 +0200 Message-ID: <7457.1121874597@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: current@freebsd.org Subject: Re: TAILQ_* ambiguity in sys/sys/bio.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: Wed, 20 Jul 2005 15:50:04 -0000 In message <20050720083942.A35046@xorpc.icir.org>, Luigi Rizzo writes: >forgive me if i am wrong, but there appears to be a source of >ambiguity in the use of TAILQ* macros in sys/sys/bio.h Make sure to do a make universe before sending me the patch for review. -- 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 Wed Jul 20 16:23: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 AB3B116A41F for ; Wed, 20 Jul 2005 16:23:37 +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 29F6D43D48 for ; Wed, 20 Jul 2005 16:23:37 +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 j6KGNaJc035829; Wed, 20 Jul 2005 09:23:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6KGNam7035828; Wed, 20 Jul 2005 09:23:36 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Jul 2005 09:23:36 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20050720092336.A35394@xorpc.icir.org> References: <20050720083942.A35046@xorpc.icir.org> <7457.1121874597@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <7457.1121874597@phk.freebsd.dk>; from phk@haven.freebsd.dk on Wed, Jul 20, 2005 at 05:49:57PM +0200 Cc: current@freebsd.org Subject: Re: TAILQ_* ambiguity in sys/sys/bio.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: Wed, 20 Jul 2005 16:23:37 -0000 On Wed, Jul 20, 2005 at 05:49:57PM +0200, Poul-Henning Kamp wrote: > In message <20050720083942.A35046@xorpc.icir.org>, Luigi Rizzo writes: > >forgive me if i am wrong, but there appears to be a source of > >ambiguity in the use of TAILQ* macros in sys/sys/bio.h > > Make sure to do a make universe before sending me the patch > for review. yup. Just in case someone wants to try, the field to rename is in sys/bio.h --- sys/bio.h 31 Jan 2005 23:26:55 -0000 1.139.2.4 +++ sys/bio.h 20 Jul 2005 17:42:31 -0000 @@ -103,18 +103,62 @@ struct devstat; struct bio_queue_head { - TAILQ_HEAD(bio_queue, bio) queue; + TAILQ_HEAD(_1, bio) queue; off_t last_offset; struct bio *insert_point; struct bio *switch_point; and there seems to be only one offending instance in HEAD/RELENG_6 kern/subr_disk.c:163: - bq = TAILQ_LAST(&bioq->queue, bio_queue); + bq = TAILQ_LAST(&bioq->queue, _1); and two more in RELENG_5, also in kern/subr_disk.c in bioq_remove() - head->insert_point = TAILQ_PREV(bp, bio_queue, bio_queue); + head->insert_point = TAILQ_PREV(bp, _1, bio_queue); @@ -199,7 +203,7 @@ } else { if (bioq->switch_point != NULL) be = TAILQ_PREV(bioq->switch_point, - bio_queue, bio_queue); + _1, bio_queue); /* * If we lie between last_offset and bq, * insert before bq. The offending macros are TAILQ_LAST() and TAILQ_PREV() and their users TAILQ_FOREACH_REVERSE TAILQ_FOREACH_REVERSE_SAFE cheers luigi > -- > 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 Wed Jul 20 19:55: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 6485D16A41F; Wed, 20 Jul 2005 19:55:47 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id F00A243D46; Wed, 20 Jul 2005 19:55:45 +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 j6KJteb3001188; Wed, 20 Jul 2005 21:55:40 +0200 (CEST) (envelope-from lists@yazzy.org) Date: Wed, 20 Jul 2005 21:55:40 +0200 From: Marcin Jessa To: Rainer Duffner Message-Id: <20050720215540.61d74707.lists@yazzy.org> In-Reply-To: <42DE414C.3070905@ultra-secure.de> References: <42D92471.20408@ultra-secure.de> <98702c705071723143943b2a6@mail.gmail.com> <42DCB6C8.8080201@ultra-secure.de> <008201c58c48$1ce830c0$b001a8c0@nasioncom.com.my> <42DE414C.3070905@ultra-secure.de> 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, freebsd-mobile@freebsd.org Subject: Re: FreeBSD6, FSC Lifebook E8010, Xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 19:55:47 -0000 Hi Rainer, guys. I have the same problem on my Thinkpad R50e where they used exactly the same graphic card. X-video does not work since it cannot detect my card as agp device. I tried the module, tried to compile it into the kernel on both 6.0 and 7.0 with no luck... Cheers, Marcin Jessa On Wed, 20 Jul 2005 14:19:24 +0200 Rainer Duffner wrote: > amp wrote: > > > You can try by issuing: > > > > shell# kldload agp > > > > (check your ttyv0 console or /var/log/messages for some info) > > > > If it OK, you can use the agp module by putting *agp_load="YES"* on > > /boot/loader.conf > > or recompile the kernel back by inserting *device agp* on your kernel > > configuration. > > > > > > > OK, > > as I said, I tried both agp in the config-file and in loader.conf - but > no change. > > As you can see from the following, it doesn't detect my i855 integrated > graphics controller, which I assume it should. > > > this is the kernel-configuration: > > machine i386 > cpu I686_CPU > ident LBE > options SCHED_4BSD # 4BSD scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big > directoriesoptions MD_ROOT # MD is a potential > root device > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > options NFS_ROOT # NFS usable as /, requires > NFSCLIENT > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires > PSEUDOFS)options PSEUDOFS # Pseudo-filesystem > framework > options GEOM_GPT # GUID Partition Tables. > options COMPAT_43 # Compatible with BSD 4.3 [KEEP > THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options AHC_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~128k to driver. > options AHD_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~215k to driver. > options ADAPTIVE_GIANT # Giant mutex is adaptive. > device isa > device pci > device fdc > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > device atapicam > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > device vga # VGA video card driver > device splash # Splash screen and screen saver support > device sc > device npx > device pmtimer > device cbb # cardbus (yenta) bridge > device pccard # PC Card (16-bit) bus > device cardbus # CardBus (32-bit) bus > device sio # 8250, 16[45]50 based serial ports > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device miibus # MII bus support > device bge # Broadcom BCM570xx Gigabit Ethernet > device wlan # 802.11 support > device an # Aironet 4500/4800 802.11 wireless NICs. > device awi # BayStack 660 and others > device ral # Ralink Technology RT2500 wireless NICs. > device wi # WaveLAN/Intersil/Symbol 802.11 > wireless NICs. > device iwi > device loop # Network loopback > device mem # Memory and kernel memory devices > device io # I/O device > device random # Entropy device > device ether # Ethernet support > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device bpf # Berkeley packet filter > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse > device ural # Ralink Technology RT2500USB wireless NICs > device urio # Diamond Rio 500 MP3 player > device uscanner # Scanners > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and da) > > > That's my loader.conf: > lbe# cat /boot/loader.conf > agp_load="YES" > snd_ich_load="YES" > acpi_fujitsu_load="YES" > cpufreq_load="YES" > acpi_video_load="YES" > smbus_load="YES" > iicsmb_load="YES" > bktr_load="YES" > > > That's what I get from a dmesg: > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-BETA1 #2: Wed Jul 20 13:49:44 CEST 2005 > root@lbe.example.org:/usr/obj/usr/src/sys/LBE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) M processor 1.60GHz (1600.06-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 > > Features=0xafe9f9bf > Features2=0x180 > real memory = 527368192 (502 MB) > avail memory = 506732544 (483 MB) > bktr_mem: memory holder loaded > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > pci_link0: irq 11 on acpi0 > pci_link1: irq 11 on acpi0 > pci_link2: irq 11 on acpi0 > pci_link3: irq 11 on acpi0 > pci_link4: irq 11 on acpi0 > pci_link5: irq 11 on acpi0 > pci_link6: irq 0 on acpi0 > pci_link7: irq 11 on acpi0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfc08-0xfc0b on acpi0 > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 0.3 (no driver attached) > acpi_video0: port 0x1800-0x1807 mem > 0xd8000000-0xdfffffff,0xd0000000-0xd007ffff irq 11 at device 2.0 on pci0 > pci0: at device 2.1 (no driver attached) > uhci0: port 0x1820-0x183f > 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 0x1840-0x185f > 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 0x1860-0x187f > 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 > 0xd0100000-0xd01003ff 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 > pcib1: at device 30.0 on pci0 > pci1: on pcib1 > cbb0: irq 11 at device 10.0 on pci1 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb1: irq 11 at device 10.1 on pci1 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > pci1: at device 10.2 (no driver attached) > cbb2: at device 10.3 on pci1 > cardbus2: on cbb2 > pccard2: <16-bit PCCard bus> on cbb2 > bge0: mem > 0xd0200000-0xd020ffff irq 11 at device 12.0 on pci1 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:0b:5d:4c:4e:b9 > iwi0: mem 0xd0215000-0xd0215fff irq 11 at > device 13.0 on pci1 > iwi0: Ethernet address: 00:0e:35:28:4e:18 > fwohci0: mem > 0xd0216000-0xd02167ff,0xd0210000-0xd0213fff irq 11 at device 14.0 on pci1 > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:00:0e:10:02:90:a7:76 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > sbp0: on firewire0 > 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) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 31.3 (no driver attached) > pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem > 0xd0100c00-0xd0100dff,0xd0100800-0xd01008ff irq 11 at device 31.5 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: > pci0: at device 31.6 (no driver attached) > acpi_button0: on acpi0 > acpi_lid0: on acpi0 > acpi_acad0: on acpi0 > acpi_cmbat0: on acpi0 > acpi_cmbat1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio1 port 0x2e8-0x2ef,0x400-0x43f irq 3 drq 3 on acpi0 > sio1: type 16550A > ppc0: port 0x378-0x37f,0x778-0x77b irq > 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > acpi_fujitsu0: on acpi0 > acpi_fujitsu0: Couldn't query volume level > acpi_fujitsu0: Couldn't init button states > acpi_fujitsu0: Couldn't initialize button states! > pmtimer0 on isa0 > orm0: at iomem 0xdc000-0xdffff 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 > Timecounter "TSC" frequency 1600062995 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 38154MB at ata0-master UDMA100 > acd0: CDRW at ata1-master UDMA33 > ATA PseudoRAID loaded > cd0 at ata1 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > Trying to mount root from ufs:/dev/ad0s1a > acpi_fujitsu0: Couldn't query method > acpi_fujitsu0: Couldn't query method > acpi_fujitsu0: Couldn't query method > acpi_fujitsu0: Couldn't query method > > > And that's what pciconf -lv says: > hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82852GM/GME/GMV/PM, 855GM/GME Montara Host-Hub Interface > Bridge' class = bridge > subclass = HOST-PCI > none0@pci0:0:1: class=0x088000 card=0x11d510cf chip=0x35848086 rev=0x02 > hdr=0x00 vendor = 'Intel Corporation' > device = '82852GM/GME/GMV/PM, 855GM/GME Montara System Memory > Controller' > class = base peripheral > none1@pci0:0:3: class=0x088000 card=0x11d510cf chip=0x35858086 rev=0x02 > hdr=0x00 vendor = 'Intel Corporation' > device = '82852GM/GME/GMV/PM, 855GM/GME Montara Configuration Process' > class = base peripheral > acpi_video0@pci0:2:0: class=0x030000 card=0x128110cf chip=0x35828086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated > Graphics Device' > class = display > subclass = VGA > none2@pci0:2:1: class=0x038000 card=0x128110cf chip=0x35828086 rev=0x02 > hdr=0x00 vendor = 'Intel Corporation' > device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated > Graphics Device' > class = display > uhci0@pci0:29:0: class=0x0c0300 card=0x11ab10cf chip=0x24c28086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1' > class = serial bus > subclass = USB > uhci1@pci0:29:1: class=0x0c0300 card=0x11ab10cf chip=0x24c48086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2' > class = serial bus > subclass = USB > uhci2@pci0:29:2: class=0x0c0300 card=0x11ab10cf chip=0x24c78086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3' > class = serial bus > subclass = USB > ehci0@pci0:29:7: class=0x0c0320 card=0x11ab10cf chip=0x24cd8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI > Controller' > class = serial bus > subclass = USB > pcib1@pci0:30:0: class=0x060400 card=0x00000000 chip=0x24488086 > rev=0x83 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI > Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24cc8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DBM (ICH4-M) LPC Interface Bridge' > class = bridge > subclass = PCI-ISA > atapci0@pci0:31:1: class=0x01018a card=0x11ab10cf chip=0x24ca8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DBM (ICH4-M) UltraATA/100 EIDE Controller' > class = mass storage > subclass = ATA > none3@pci0:31:3: class=0x0c0500 card=0x11ab10cf chip=0x24c38086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller' > class = serial bus > subclass = SMBus > pcm0@pci0:31:5: class=0x040100 card=0x127d10cf chip=0x24c58086 rev=0x03 > hdr=0x00 vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller' > class = multimedia > subclass = audio > none4@pci0:31:6: class=0x070300 card=0x10d110cf chip=0x24c68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller' > class = simple comms > subclass = generic modem > cbb0@pci1:10:0: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 > hdr=0x02 vendor = 'O2 Micro Inc' > device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' > class = bridge > subclass = PCI-CardBus > cbb1@pci1:10:1: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 > hdr=0x02 vendor = 'O2 Micro Inc' > device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' > class = bridge > subclass = PCI-CardBus > none5@pci1:10:2: class=0x088000 card=0x11c410cf chip=0x71101217 > rev=0x00 hdr=0x00 > vendor = 'O2 Micro Inc' > device = 'OZ711Mx MemoryCardBus Accelerator' > class = base peripheral > cbb2@pci1:10:3: class=0x060700 card=0x11c410cf chip=0x72231217 rev=0x00 > hdr=0x02 vendor = 'O2 Micro Inc' > device = 'OZ711M3 SmartCardBus MultiMediaBay Controller' > class = bridge > subclass = PCI-CardBus > bge0@pci1:12:0: class=0x020000 card=0x127910cf chip=0x165e14e4 rev=0x03 > hdr=0x00 vendor = 'Broadcom Corporation' > device = 'BCM5705MA2 NetXtreme Gigabit Ethernet' > class = network > subclass = ethernet > iwi0@pci1:13:0: class=0x028000 card=0x27028086 chip=0x42208086 rev=0x05 > hdr=0x00 vendor = 'Intel Corporation' > device = 'PRO/Wireless 2200BG Network Connection' > class = network > fwohci0@pci1:14:0: class=0x0c0010 card=0x116210cf chip=0x8026104c > rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'TSB43AB21 1394a-2000 OHCI PHY/link-layer Controller' > class = serial bus > subclass = FireWire > > _______________________________________________ > 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 Wed Jul 20 20:41: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 C825316A41F; Wed, 20 Jul 2005 20:41:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3F443D46; Wed, 20 Jul 2005 20:41:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6KKf9dq062818; Wed, 20 Jul 2005 16:41:09 -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 j6KKf8WP014727; Wed, 20 Jul 2005 16:41:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C73957302F; Wed, 20 Jul 2005 16:41:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050720204108.C73957302F@freebsd-current.sentex.ca> Date: Wed, 20 Jul 2005 16:41:08 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [current tinderbox] failure on i386/i386 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: Wed, 20 Jul 2005 20:41:11 -0000 TB --- 2005-07-20 18:50:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-20 18:50:02 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-07-20 18:50:02 - cleaning the object tree TB --- 2005-07-20 18:50:38 - checking out the source tree TB --- 2005-07-20 18:50:38 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-07-20 18:50:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-20 18:57:08 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-20 18:57:08 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-07-20 18:57:08 - /usr/bin/make -B buildworld >>> 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-07-20 20:04:50 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-20 20:04:50 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-07-20 20:04:50 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Jul 20 20:04:50 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 Wed Jul 20 20:25:37 UTC 2005 TB --- 2005-07-20 20:25:37 - generating LINT kernel config TB --- 2005-07-20 20:25:37 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-07-20 20:25:37 - /usr/bin/make -B LINT TB --- 2005-07-20 20:25:38 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-20 20:25:38 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-07-20 20:25:38 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 20:25:39 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 [...] In file included from /tinderbox/CURRENT/i386/i386/src/sys/i386/bios/smapi_bios.S:4: ./machine/asmacros.h:108:1: "ALTENTRY" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/i386/bios/smapi_bios.S:1: ./machine/asm.h:87:1: this is the location of the previous definition In file included from /tinderbox/CURRENT/i386/i386/src/sys/i386/bios/smapi_bios.S:4: ./machine/asmacros.h:113:1: "ENTRY" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/i386/bios/smapi_bios.S:1: ./machine/asm.h:88:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-07-20 20:41:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-20 20:41:08 - ERROR: failed to build lint kernel TB --- 2005-07-20 20:41:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:55: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 A2FA516A41F for ; Wed, 20 Jul 2005 20:55:03 +0000 (GMT) (envelope-from mark@reidel.info) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E30CF43D45 for ; Wed, 20 Jul 2005 20:55:02 +0000 (GMT) (envelope-from mark@reidel.info) Received: (qmail 5752 invoked from network); 20 Jul 2005 20:55:00 -0000 Received: from unknown (HELO raffi.reidel.info) (793055@[62.216.164.29]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 20 Jul 2005 20:55:00 -0000 Received: (qmail 30021 invoked by uid 0); 20 Jul 2005 20:55:01 -0000 Received: from unknown (HELO ?62.216.166.115?) (62.216.166.115) by karm.dyndns.org with SMTP; 20 Jul 2005 20:55:01 -0000 Message-ID: <42DED645.5020602@reidel.info> Date: Wed, 20 Jul 2005 22:55:01 +0000 From: Mark Daniel Reidel User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Two FreeBSD slices, 32bit and 64bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2005 20:55:03 -0000 Hello, I bought an athlon64 processor recently and everything went just fine using my old installation of FreeBSD in 32bit mode. Then I decided to give amd64 a try, deleted some unneeded linux-slices and created a new FreeBSD slice with a single partition. The current layout looks like this: Device Boot Start End Blocks Id System /dev/ad2s1 * 1 7 56196 6 FAT16 /dev/ad2s2 8 20 104422+ 83 Linux /dev/ad2s3 21 3668 29302560 a5 FreeBSD /dev/ad2s4 3669 14593 87755062+ 5 Extended /dev/ad2s5 3669 9812 49351648+ a5 FreeBSD /dev/ad2s6 9813 14592 38395318+ 7 HPFS/NTFS My 32bit installation is on ad2s3, my experimental 64bit on ad2s5. The partitions are: # /dev/ad2s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 57605104 16 4.2BSD 2048 16384 28552 b: 1000000 57605120 swap c: 58605120 0 unused 0 0 # /dev/ad2s5: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 98703281 16 4.2BSD 2048 16384 28552 c: 98703297 0 unused 0 0 To make things even funnier, I use grub installed on ad2s2 as my bootmanager, booting my 32bit FreeBSD on ad2s3 with: rootnoverify (hd0,2) chainloader +1 boot After installing the amd64 version of FreeBSD 6-BETA1 via cross-compiling on ad2d5a, I ran a "bsdlabel -B ad2s5". Now, when I try to boot ad2s5 via grub using rootnoverify (hd0,4) chainloader +1 boot the boot loader gives an error about an invalid slice and hangs. It looks like this: BTX halted Invalid slice >> FreeBSD/i386 BOOT Default: 0:ad(0,i) <-- why i? boot: Booting ad2s3, unloading the kernel, loading the 64bit kernel and then booting works, this is what I'm doing now. But this can't be the right way :-/ Anyone has any ideas why the boot loader is trying to access partition i? Any help how to fix things appreciated, I'm really clueless here :o( -- Fortune cookie of the hour: Politicians are the same all over. They promise to build a bridge even where there is no river. -- Nikita Khrushchev From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 00:01: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 A912616A41F for ; Thu, 21 Jul 2005 00:01:25 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BA02E43D67 for ; Thu, 21 Jul 2005 00:01:14 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 21 Jul 2005 00:01:09 -0000 Received: from p5090F065.dip.t-dialin.net (EHLO klotz.local) [80.144.240.101] by mail.gmx.net (mp023) with SMTP; 21 Jul 2005 02:01:09 +0200 X-Authenticated: #989277 Received: from [192.168.0.2] (booky.local [192.168.0.2]) by klotz.local (8.13.3/8.13.3) with ESMTP id j6L00mZ8001107; Thu, 21 Jul 2005 02:00:49 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42DEE5BE.7080706@nurfuerspam.de> Date: Thu, 21 Jul 2005 02:01:02 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: sam@errno.com Subject: ath(4) hostap problems (still) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 00:01:25 -0000 Hi, when running ath(4) on -CURRENT/-RELENG_6 as client and hostap on FreeBSD-5 on another box, you will notice that the box locks up (it's stuck in a busy loop inside the kernel somewhere, if I'm lucky I can get enough cpu-time to press the reboot-kombo). I've described this problem already in my earlier mails. Today I tried to run the hostap box on FreeBSD-6. The problem still exists, but the client seems to recover from the lock after a few seconds and I can get some information out of it. The connection cannot be established once after the short lock has happened and any try to ifconfig down/up, will lock up the client for another few seconds. I could start athstats after the client recovered from the lock-situation: 3 beacon miss interrupts 22 mib overflow interrupts 62 tx management frames 180 tx frames discarded prior to association 6 tx failed 'cuz too many retries 69 long on-chip tx retries 55 tx frames with no ack marked 96 tx frames with short preamble 3 periodic calibrations avg recv rssi: 30 1 switched default/rx antenna Antenna profile: [1] tx 101 rx 0 [2] tx 0 rx 70 The value of "tx frames discarded prior to association" several times a minute. The antenna profiles change sometimes, but everything else does not change, if you run athstats multiple times. I hope it helps to investigate the problem. Client: Thinkpad R40 with Netgear WG511T PCMCIA. HostAP: Sempron 2200+, Asrock K7VT4A+, Netgear WG311T PCI. Martin From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 01:38: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 9867416A41F for ; Thu, 21 Jul 2005 01:38:09 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [202.0.58.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2687C43D75 for ; Thu, 21 Jul 2005 01:37:56 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-1.paradise.net.nz (smtp-1b.paradise.net.nz [202.0.32.210]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IJY00IXLF77DN@linda-3.paradise.net.nz> for freebsd-current@freebsd.org; Thu, 21 Jul 2005 13:37:55 +1200 (NZST) Received: from [192.168.1.11] (218-101-45-48.paradise.net.nz [218.101.45.48]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id 281228287A for ; Thu, 21 Jul 2005 13:37:55 +1200 (NZST) Date: Thu, 21 Jul 2005 13:37:53 +1200 From: Mark Kirkwood To: freebsd-current@freebsd.org Message-id: <42DEFC71.8030803@paradise.net.nz> MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------020307030900010209070209 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050511) Subject: umount of /dev failed (BUSY) at shutdown 6.0 Beta1 ISO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 01:38:09 -0000 This is a multi-part message in MIME format. --------------020307030900010209070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am seeing this message at shutdown: umount of /dev failed (BUSY) Everything seems to come up cleanly tho. I am running a kernel which is GENERIC with the debugging, WITNESS and INVARIANTS commented out (tho I believe the umount still fails using GENERIC) The drives are all attached to a Promise TX2000 - but I still get the failure using the OSB4 onboard ATA (but I don't want to keep using that as it has the well know issue with DMA transfer corruption). dmesg attached. Cheers Mark --------------020307030900010209070209 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #0: Thu Jul 21 08:44:24 NZST 2005 postgres@istral.markir.net:/usr/obj/usr/src/sys/STANDARD Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (996.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 2147483648 (2048 MB) avail memory = 2096631808 (1999 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 16 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: at device 1.0 (no driver attached) fxp0: port 0xd400-0xd43f mem 0xfeafe000-0xfeafefff,0xfe900000-0xfe9fffff irq 20 at device 4.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:02:4c:6a fxp1: port 0xd000-0xd03f mem 0xfeafd000-0xfeafdfff,0xfe700000-0xfe7fffff irq 21 at device 5.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:e0:81:02:4c:6b isab0: port 0x580-0x58f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xfffff000-0xffffffff at device 15.2 on pci0 pcib0: unable to route slot 15 INTA ohci0: Could not allocate irq device_attach: ohci0 attach returned 6 pcib1: pcibus 1 on motherboard pci1: on pcib1 atapci1: port 0xefe0-0xefe7,0xefac-0xefaf,0xefa0-0xefa7,0xefa8-0xefab,0xef90-0xef9f mem 0xfebf0000-0xfebfffff irq 27 at device 2.0 on pci1 ata2: on atapci1 ata3: on atapci1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xd17ff,0xd1800-0xd27ff,0xd2800-0xd37ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 1.000 msec acd0: CDRW at ata0-master PIO4 ad4: 38166MB at ata2-master UDMA100 ad6: 39205MB at ata3-master UDMA133 ad7: 39205MB at ata3-slave UDMA133 ATA PseudoRAID loaded ar0: 38166MB status: READY ar0: disk0 READY using ad4 at ata2-master ar1: 78411MB status: READY ar1: disk0 READY using ad6 at ata3-master ar1: disk1 READY using ad7 at ata3-slave SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ar0s1a --------------020307030900010209070209-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 01:44: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 0144E16A448 for ; Thu, 21 Jul 2005 01:44:16 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D2943D98 for ; Thu, 21 Jul 2005 01:44:08 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id s18so23709nze for ; Wed, 20 Jul 2005 18:44:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=c1M7hSyAbE+j/zdDlJYxJJlVYBzE2duieJOopbqttlc+mGE0phyKxY0oUtXaz1grCACUYUAYqUzHypaGbIbqi5iF1lV1735YKvtrystStJL7DekZq7svZWk/+At4zP5aYf+uFLUpopVm1CamOYs34sUm4IC0WPT7fZWZglgQ+Z4= Received: by 10.36.60.18 with SMTP id i18mr641914nza; Wed, 20 Jul 2005 18:43:41 -0700 (PDT) Received: from ?192.168.15.103? ([68.190.230.198]) by mx.gmail.com with ESMTP id 15sm64420nzn.2005.07.20.18.43.40; Wed, 20 Jul 2005 18:43:41 -0700 (PDT) From: Pascal Hofstee To: Mark Kirkwood In-Reply-To: <42DEFC71.8030803@paradise.net.nz> References: <42DEFC71.8030803@paradise.net.nz> Content-Type: text/plain Date: Wed, 20 Jul 2005 18:43:38 -0700 Message-Id: <1121910218.76611.14.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.5.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: umount of /dev failed (BUSY) at shutdown 6.0 Beta1 ISO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 01:44:16 -0000 On Thu, 2005-07-21 at 13:37 +1200, Mark Kirkwood wrote: > I am seeing this message at shutdown: > > umount of /dev failed (BUSY) > > Everything seems to come up cleanly tho. This is a known issue ... which in itself is harmless .. but eventually should be fixed indeed (and i believe is being worked on). -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 03:20: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 D0EB216A41F for ; Thu, 21 Jul 2005 03:20:16 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [202.0.58.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F5843D46 for ; Thu, 21 Jul 2005 03:20:16 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-3.paradise.net.nz (smtp-3a.paradise.net.nz [202.0.32.196]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IJY005NWJXLQC@linda-2.paradise.net.nz> for freebsd-current@freebsd.org; Thu, 21 Jul 2005 15:20:12 +1200 (NZST) Received: from [192.168.1.11] (218-101-45-48.paradise.net.nz [218.101.45.48]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id 48229AE3CC for ; Thu, 21 Jul 2005 15:20:09 +1200 (NZST) Date: Thu, 21 Jul 2005 15:20:07 +1200 From: Mark Kirkwood To: freebsd-current@freebsd.org Message-id: <42DF1467.5000900@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050511) Subject: atacontrol create/status give confusing feedback 6.0 Beta 1 ISO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 03:20:17 -0000 I just noticed this: # dmesg ... ar0: 38166MB status: READY ar0: disk0 READY using ad4 at ata2-master ar1: 78411MB status: READY ar1: disk0 READY using ad6 at ata3-master ar1: disk1 READY using ad7 at ata3-slave # atacontrol status ar0 ar0: ATA SPAN subdisks: ad4 status: READY # atacontrol status ar1 ar0: ATA SPAN subdisks: ad4 status: READY [what is going on here, I asked for ar1? It gets worse]: # atacontrol delete ar1 # atacontrol create RAID0 512 ad6 ad7 ar0 created [disconcerting - has it destroyed my ar0?]: # atacontrol status ar0 ar0: ATA SPAN subdisks: ad4 status: READY # atacontrol status ar1 ar0: ATA SPAN subdisks: ad4 status: READY [guess not] It seems that the commands are working ok, but the feedback messages are wrong as the console output lists ar1 are being created : ar1: 78411MB status: READY ar1: disk0 READY using ad6 at ata3-master ar1: disk1 READY using ad7 at ata3-slave regards Mark From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 04:23: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 5F95916A428 for ; Thu, 21 Jul 2005 04:23:26 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12F6343DAA for ; Thu, 21 Jul 2005 04:22:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L4MhNV015693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 00:22:43 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L4Me6T012420; Thu, 21 Jul 2005 00:22:42 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B4C22513BC; Wed, 20 Jul 2005 16:13:15 -0400 (EDT) Date: Wed, 20 Jul 2005 16:13:15 -0400 From: Kris Kennaway To: dandee@volny.cz Message-ID: <20050720201315.GA73278@xor.obsecurity.org> References: <200507200149.52721.max@love2party.net> <20050720114331.868A64E704@pipa.profix.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20050720114331.868A64E704@pipa.profix.cz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 04:23:26 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 20, 2005 at 01:43:27PM +0200, Daniel Dvorak wrote: > Yes, I can confirm this bug, when one use make buildworld with -jN. > If you build the code without -jN, it is all right. That's not what was suggested, though. If you think -j is *causing* the error, as opposed to just obscuring the output of the error message, log the entire -j build and search for the real error, which will be further back in the output. Kris --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3rBbWry0BWjoQKURAmAwAKDikRSGC/pDyXLE60H5qgPuSi2KfQCfRmFJ nZybhAAReMH5YntFXGDYQ64= =U3E5 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 04:28: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 7CBEB16A422 for ; Thu, 21 Jul 2005 04:28:37 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D637743D49 for ; Thu, 21 Jul 2005 04:28:36 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so80522wri for ; Wed, 20 Jul 2005 21:28: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=JCRthLuTzjpqnooMir8F/rKncL1s2Qw3dHe/mh42B4OHtIzUdCwkyvXIaJNlaGqARhBlKaL0yr2S1IwunlqUg7Lwqkc5Mip26DXrXMo/BRx8GBCqpqkXl4chtYy58GqjqBHI9Z0g2En/Ox2CAkFrhfTfrMMdK2DviJcYe/IsJ0k= Received: by 10.54.3.6 with SMTP id 6mr380184wrc; Wed, 20 Jul 2005 21:28:05 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Wed, 20 Jul 2005 21:28:05 -0700 (PDT) Message-ID: <47d0403c050720212836f77a5c@mail.gmail.com> Date: Wed, 20 Jul 2005 23:28:05 -0500 From: Ben Kaduk 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: 6.0-release beta1 breaks ndis for dell truemobile 1400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:28:37 -0000 Hi All, I have not extensively used the ndis driver since I am not often around wireless networks, but after installing 5.4-release I compiled the driver using=20 cd /usr/src/sys/modules/ndis make install cd /usr/src/sys/modules/if_ndis ndiscvt -i bcmwl5a.inf -s bcmwl5.sys -o ndis_driver_data.h make && make install as recommended, with the bcmwl* files being the ones here: http://netfiles.uiuc.edu/kaduk/www/* The self-extracting driver (for windows) also generated a bcmwl5.inf (not 'a'), but ndiscvt produced an error whilst trying to read this file, so I used the 'a' version, and ndiscvt finished successfully; if_ndis was produced with no errors, and I was able to kldload if_ndis.ko and ndis.ko. Upon doing this, console messages were produced recognizing my Dell TrueMobile 1400 (broadcom bcm4324 chipset), but i didn't have a wireless network to use then. Since then, I have performed a source upgrade to 6.0-release beta1 (cvsup last saturday; can't be more precise since I must boot windows to use wireless :( ). I just today had occasion to use the wireless card, and kldload()-ing if_ndis resulted in a panic(). I didn't save the message for two reasons: (1), I thought it was just that if_ndis.ko had not been rebuild with world, and (2) I'm using my laptop at a friend's appartment with no serial console. After performing several iterations of cleaning for ndis, if_ndis, and wlan, and rebuilding/installing, I produced if_ndis.ko, ndis.ko, and wlan.ko that I could successfully kldload() with no panic. However, there were no console messages that appeared indicating that the system had found my hardward, leading to the statement in the subject that the beta breaks ndis for this card. I have already posted a pciconf -lv to the list in this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D116619+0+current/freebsd-cur= rent What steps can I take to help debug this regression? Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 04:48: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 56FD016A41F; Thu, 21 Jul 2005 04:48:28 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4E0E43D45; Thu, 21 Jul 2005 04:48:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L4mNNV018520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 00:48:26 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L4mL6P014838; Thu, 21 Jul 2005 00:48:21 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 520F151222; Thu, 21 Jul 2005 00:48:21 -0400 (EDT) Date: Thu, 21 Jul 2005 00:48:21 -0400 From: Kris Kennaway To: Ganbold , freebsd-current@freebsd.org, tegge@freebsd.org Message-ID: <20050721044821.GD22430@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2R+TDOstMAPx/aG/" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: linuxthreads compile error in latest 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 04:48:28 -0000 --2R+TDOstMAPx/aG/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 12:47:50PM +0900, Ganbold wrote: > Hi, >=20 > I have FreeBSD 6.0 beta1 and I couldn't compile linuxthreads from ports. > How can I compile it successfully? You can't, it's currently broken. Kris --2R+TDOstMAPx/aG/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3ykUWry0BWjoQKURAh9KAJwOnWFTjZE/yez7kQLb+IcjVkfUVwCffGae BoDV7obs8w3d9NnQWIyoMUo= =AEPF -----END PGP SIGNATURE----- --2R+TDOstMAPx/aG/-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 04:50: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 9ED2F16A41F for ; Thu, 21 Jul 2005 04:50:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36A2D43D48 for ; Thu, 21 Jul 2005 04:50:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L4oBNV018706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 00:50:11 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L4oA6P015001; Thu, 21 Jul 2005 00:50:10 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5E4775132C; Thu, 21 Jul 2005 00:50:10 -0400 (EDT) Date: Thu, 21 Jul 2005 00:50:10 -0400 From: Kris Kennaway To: Thierry Herbelot , freebsd-current@freebsd.org Message-ID: <20050721045010.GI22430@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yq2ad9TzNXzcxitU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: panic in vfs_subr.c / ffs_inode.c / ufs_inode.c / ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:50:12 -0000 --yq2ad9TzNXzcxitU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2005 at 02:29:16PM +0200, Thierry Herbelot wrote: > Hello, >=20 > With a recent i386 GENERIC -current running on an SMP machine, I get this= =20 > panic : bp 0xc2f038a8 wrong b_bufobj 0xc14972e0 should be 0xc1ec7500 >=20 > I was rebuilding the world when the machine panic'ed. This is a known problem that Jeff will hopefully have a fix for soon. Kris --yq2ad9TzNXzcxitU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3ymBWry0BWjoQKURAg/OAJ42QfNof6fbLzc+lQEGomF5az0BigCg8Dzv XyDFPR/w32KDjm0oPWmSnMw= =bBGJ -----END PGP SIGNATURE----- --yq2ad9TzNXzcxitU-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 04:51: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 7270C16A41F for ; Thu, 21 Jul 2005 04:51:34 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DF643D45 for ; Thu, 21 Jul 2005 04:51:31 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id 9C6D1C006 for ; Thu, 21 Jul 2005 06:51:30 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6L4pJFb015270; Thu, 21 Jul 2005 06:51:23 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 21 Jul 2005 06:51:09 +0200 User-Agent: KMail/1.8.1 References: <42DED645.5020602@reidel.info> In-Reply-To: <42DED645.5020602@reidel.info> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507210651.12163.thierry@herbelot.com> Cc: Subject: Re: Two FreeBSD slices, 32bit and 64bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 21 Jul 2005 04:51:34 -0000 Le Thursday 21 July 2005 00:55, Mark Daniel Reidel a écrit : > Hello, > > I bought an athlon64 processor recently and everything went just fine > using my old installation of FreeBSD in 32bit mode. > Then I decided to give amd64 a try, deleted some unneeded linux-slices > and created a new FreeBSD slice with a single partition. The current > layout looks like this: > > Device Boot Start End Blocks Id System > /dev/ad2s1 * 1 7 56196 6 FAT16 > /dev/ad2s2 8 20 104422+ 83 Linux > /dev/ad2s3 21 3668 29302560 a5 FreeBSD > /dev/ad2s4 3669 14593 87755062+ 5 Extended > /dev/ad2s5 3669 9812 49351648+ a5 FreeBSD > /dev/ad2s6 9813 14592 38395318+ 7 HPFS/NTFS > Hello, I don't think booting FreeBSD from an /extended/ partition is really supported : FreeBSD must boot from a primary partition. You could create more partitions in ad2s3 (ad2s3d, for example) and install 64-bit FreeBSD in ad2s3d, then use grub to select the FreeBSD version : title FreeBSD 32bits root (hd1,2,a) kernel /boot/loader title FreeBSD 64bits root (hd1,2,d) kernel /boot/loader Just use the tools are they are meant to be ;-) Cheers TfH PS : this post does not really belong in -current - you may have better luck on -questions. From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 05:12: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 9834816A41F for ; Thu, 21 Jul 2005 05:12:20 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0B6A43D48 for ; Thu, 21 Jul 2005 05:12:19 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-2.free.fr (Postfix) with ESMTP id 174FC32337A for ; Thu, 21 Jul 2005 07:12:19 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j6L5CGth026475 for ; Thu, 21 Jul 2005 07:12:18 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 21 Jul 2005 07:12:07 +0200 User-Agent: KMail/1.8.1 References: <20050721045010.GI22430@xor.obsecurity.org> In-Reply-To: <20050721045010.GI22430@xor.obsecurity.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507210712.09161.thierry@herbelot.com> Subject: Re: panic in vfs_subr.c / ffs_inode.c / ufs_inode.c / ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 21 Jul 2005 05:12:20 -0000 Le Thursday 21 July 2005 06:50, Kris Kennaway a écrit : > On Mon, Jul 18, 2005 at 02:29:16PM +0200, Thierry Herbelot wrote: > > Hello, > > > > With a recent i386 GENERIC -current running on an SMP machine, I get this > > panic : bp 0xc2f038a8 wrong b_bufobj 0xc14972e0 should be 0xc1ec7500 > > > > I was rebuilding the world when the machine panic'ed. > > This is a known problem that Jeff will hopefully have a fix for soon. Fine ; I also had a private answer from Peter Holm > > Kris TfH From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 06:33: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 079C916A41F for ; Thu, 21 Jul 2005 06:33:47 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8962D43D45 for ; Thu, 21 Jul 2005 06:33:46 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j6L6Y7fM017538 for ; Thu, 21 Jul 2005 02:34:07 -0400 X-ORBL: [64.171.187.230] Received: from [10.0.0.115] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j6L6XbAQ492216; Thu, 21 Jul 2005 02:33:38 -0400 Message-ID: <42DF419C.90203@root.org> Date: Wed, 20 Jul 2005 23:33:00 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: dhclient started twice on recent 7-current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 06:33:47 -0000 When booting, dhclient is started just after "hostname". However, once devd starts, it tries to start dhclient again which fails with a message saying dhclient is already running. Here are the relevant sections from rc.conf: removable_interfaces="an0" ifconfig_fxp0="DHCP" ifconfig_an0="DHCP" hostname="mrspecial" devd_enable="YES" Ideas? -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:03: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 8133A16A41F for ; Thu, 21 Jul 2005 07:03:46 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (glewis.dsl.xmission.com [166.70.56.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB1D843D4C for ; Thu, 21 Jul 2005 07:03:45 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.3/8.13.3) with ESMTP id j6L73hEB068684 for ; Thu, 21 Jul 2005 01:03:44 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.3/8.13.3/Submit) id j6L73hD3068683 for freebsd-current@FreeBSD.org; Thu, 21 Jul 2005 01:03:43 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Thu, 21 Jul 2005 01:03:42 -0600 From: Greg Lewis To: freebsd-current@FreeBSD.org Message-ID: <20050721070342.GA68601@misty.eyesbeyond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Panic using networked swap with 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 07:03:46 -0000 Hi, No response on freebsd-sparc, plus I think this may be MI, so I'm sending it to freebsd-current too. I have a Ultra 10 which I network boot in a diskless configuration to run FreeBSD. This weekend I downloaded 6.0-BETA1 and got that set up. I've gotten the following panic reproduceably while trying to compile the lang/perl5.8 port when the machine starts to swap. Note that this is typed in from looking at the console (I'd need to set up a serial console) so apologies for any typos. panic: bstrategy: no bufobj bp=0xc3dee258 cpuid = 0 KDB: enter: panic [thread pid 7 tid 100027 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> trace Tracing pid 7 tid 100027 td 0xfffff80017df84c0 panic() at panic+0x16c swapdev_strategy() at swapdev_strategy+0x70 swp_pager_strategy() at swp_page_strategy+0x8c swap_pager_putpages() at swap_pager_putpages+0x3e8 default_pager_putpages() at default_pager_putpages+0x1c vm_pageout_flush() at vm_pageout_flush+0x14c vm_pageout_clean() at vm_pageout_clean+0x334 vm_pageout_scan() at vm_pageout_scan+0x738 vm_pageout() at vm_pageout+0x3e8 fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 db> Please let me know if you want anything else examined from the debugger. The server is an x86 box running FreeBSD 4.11-STABLE: FreeBSD misty.eyesbeyond.com 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Apr 7 10:51:05 MDT 2005 glewis@misty.eyesbeyond.com:/usr/src/sys/compile/MISTY i386 I created the swap file on the server as follows: dd if=/dev/zero of=swap bs=4k count=128k The fstab entry looks like: /swap none swap sw 0 0 I downloaded 5.4 and tried it tonight and network swap works without any problems, so the behaviour in 6.0-BETA1 appears to definitely be a regression. In addition, I tried a similar trick on my Alpha with 6.0-BETA1 tonight and received a similar panic: panic: bstrategy: no bufobj bp=0xfffffe0003358010 cpuid = 0 KDB: enter: panic [thread pid 8 tid 100025 ] Stopped at kdb_enter+0x48: or zero,zero,zero db> trace Tracing pid 8 tid 100025 td 0xfffffc0007bbed20 kdb_enter() at kdb_enter+0x48 panic() at panic+0x210 swapdev_strategy() at swapdev_strategy+0xb8 swp_pager_strategy() at swp_pager_strategy+0xac swap_pager_putpages() at swap_pager_putpages+0x4c4 default_pager_putpages() at default_pager_putpages+0x1c vm_pageout_flush() at vm_pageout_flush+0x1d8 db> I haven't tried it under 5.4 on the Alpha yet, but networked swap definitely worked under 5.2 on the Alpha. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:53:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D63116A41F for ; Thu, 21 Jul 2005 07:53:20 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A044043D62 for ; Thu, 21 Jul 2005 07:53:19 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id EA5D71FFACD; Thu, 21 Jul 2005 09:53:16 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 906081FFACA; Thu, 21 Jul 2005 09:53:14 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id BF8AE157EE; Thu, 21 Jul 2005 07:51:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id BD3BB15329; Thu, 21 Jul 2005 07:51:05 +0000 (UTC) Date: Thu, 21 Jul 2005 07:51:05 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Jia-Shiun Li In-Reply-To: <1d6d20bc050703113864394536@mail.gmail.com> Message-ID: References: <1d6d20bc050703113864394536@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: Attempting to make sk(4) work on Marvell 88E5053 (advise needed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 07:53:20 -0000 On Mon, 4 Jul 2005, Jia-Shiun Li wrote: Hi, > My (and probably many of yours) motherboard Asus P5GD1 PRO has Marvell > 88E5053 on board, but currently there is no working driver for it, so > I tried to modify sk(4) to make it work. > > I took a brief look at the syskonnect Linux driver v8.16, there seems > no much differences among PCI and PCI-express chips, so I tried to > fill missing identifiers to see if I am lucky enough. But the answer > is no. :p there are more differences than you'd expect. It's on TODO of some people to write the new driver but mostly ENOSPECS and ENOTIME problems. > Attached is my attempt, and the result message is below. Looks like > 300+ KB jumbo frame buffer is too much to allocate. That's another problem with more drivers. I guess it'll succeed if driver gets attached during boot. > It would be very > appreciated if any one can give some advises. poke Marvell for the _specs_ so we can write a BSD licensed driver. http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048265.html -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 10: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 80D7C16A44C for ; Thu, 21 Jul 2005 10:40:33 +0000 (GMT) (envelope-from pczanik@fang.fa.gau.hu) Received: from gate.gau.hu (gate.gau.hu [192.188.242.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 944C643D94 for ; Thu, 21 Jul 2005 10:40:22 +0000 (GMT) (envelope-from pczanik@fang.fa.gau.hu) Received: from localhost (localhost [127.0.0.1]) by gate.gau.hu (Postfix) with ESMTP id 3E692588B0 for ; Thu, 21 Jul 2005 12:40:17 +0200 (MEST) Received: from gate.gau.hu ([127.0.0.1]) by localhost (gate.gau.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08520-04 for ; Thu, 21 Jul 2005 12:40:14 +0200 (MEST) Received: from spike.fa.gau.hu (spike.fa.gau.hu [192.188.243.132]) by gate.gau.hu (Postfix) with ESMTP id 43A4A588E4 for ; Thu, 21 Jul 2005 12:40:13 +0200 (MEST) Received: from [192.188.243.16] (beech.fa.gau.hu [192.188.243.16]) by spike.fa.gau.hu (8.13.3/8.13.1) with ESMTP id j6LAeEAL091290 for ; Thu, 21 Jul 2005 12:40:14 +0200 (CEST) (envelope-from pczanik@fang.fa.gau.hu) Message-ID: <42DF7B8C.7090604@fang.fa.gau.hu> Date: Thu, 21 Jul 2005 12:40:12 +0200 From: Peter Czanik User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Jul 2005 12:08:13 +0000 Subject: ahd problems on 5.4-STABLE and 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 10:40:34 -0000 Hello, I sent it to the STABLE list, but belongs here as well... -------- Original Message -------- Hello, It seems to me, that the 'ahd' driver got some problems on both 5.4-STABLE and 6.0-BETA1. My hardware is a HP Workstation 6000, with an on-board Adaptec SCSI controller, which is disabled in BIOS, as I only have IDE CD- and harddrives. I start with 6.0-BETA1, as it's the easier one: when I boot the install CD, it finds the controller, writes "Unable to read SEEPROM", it waits a few seconds, writes another 20 lines of error messages on screen, then reboots the computer, so there isn't time to read the rest of messages and can't install the beta. 5.4-STABLE: simptoms are the same on my installed 5.4-STABLE machine, I can read "Unable to read SEEPROM", it waits, prints some more messages, and reboots. When I boot an older kernel (from the 29th of June), the kernel finds the controller, and works fine. Compiling a kernel without ahd support (commenting out: '#device ahd') solves the problem as well, and the machine boots fine. This is part of dmesg from the old kernel: Jul 20 13:48:02 beech kernel: ahd0: at device 12.0 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Jul 20 13:48:02 beech kernel: ahd1: at device 12.1 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Bye, Peter From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 13:30: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 4EA8D16A420 for ; Thu, 21 Jul 2005 13:30:20 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB6743D76 for ; Thu, 21 Jul 2005 13:29:55 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j6LDTsLt069073 for ; Thu, 21 Jul 2005 09:29:54 -0400 (EDT) From: Ken Smith To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-28Xeu1RhdHnCInXzAT/J" Organization: U. Buffalo CSE Department Date: Thu, 21 Jul 2005 09:29:54 -0400 Message-Id: <1121952594.68685.27.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Subject: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 13:30:20 -0000 --=-28Xeu1RhdHnCInXzAT/J Content-Type: text/plain Content-Transfer-Encoding: quoted-printable To help with making the compat library support a bit less of a headache we have decided to bump the shared library version number for all of the shared libraries that make up the base system as part of doing a new release branch. This means that once we reach a "steady state" roughly a month after a new release branch is created we will bump the shared library version numbers up by one in HEAD. Using the *next* release branch as an example, that means about a month after RELENG_7 gets created we will bump the shared library versions up by one in HEAD. That way as time goes on from that point packages-8-current (what portmgr builds to support HEAD) will have what we expect the shared library versions to be for RELENG_8. And we hope waiting a month after the branch occurs before doing the version bump we will be less disruptive to people developing and testing the new release. Since support for this is new, what needs to be done now will be worse than what we will be doing down the road. Tomorrow we will bump the shared library version numbers in both RELENG_6 and HEAD by one so that they differ from the version numbers currently in RELENG_5. Then some time a bit after the 6.0-RELEASE is finished we will bump all the version numbers in HEAD again. It will take a while for the fallout from this version bump to propagate. People who cvsup/rebuild existing systems should not be impacted immediately - you will still have the older library versions present on your systems. However it will take time for the pre-built packages provided by the portmgr folks to be rebuilt, loaded onto the FTP servers, and propagate out to the mirrors. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-28Xeu1RhdHnCInXzAT/J 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) iD8DBQBC36NS/G14VSmup/YRAnfNAKCEyUazsOpouCtHjXFYRKlI5KgYZgCfbaJ7 H1+KDUasads2HiDSiH7fRYw= =konT -----END PGP SIGNATURE----- --=-28Xeu1RhdHnCInXzAT/J-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 13:48: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 6358C16A41F for ; Thu, 21 Jul 2005 13:48:33 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0605643D93 for ; Thu, 21 Jul 2005 13:48:18 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6LDmHiX008627; Thu, 21 Jul 2005 17:48:17 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6LDmHKf008626; Thu, 21 Jul 2005 17:48:17 +0400 (MSD) (envelope-from ache) Date: Thu, 21 Jul 2005 17:48:17 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20050721134816.GA8550@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, wpaul@ctr.columbia.ed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: wpaul@ctr.columbia.ed Subject: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 13:48:33 -0000 I got silent (without panic) reboots approx. every 4 hours running rl(4) driver. When I turn off mpsafenet with debug.mpsafenet=0 reboots are stopped. I have KASSERTS on, but none of them are triggered, just silent hardware reboots. Plain UP machine. No netgraph, ipfw, etc. Any ideas? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 14:25: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 68B7D16A41F; Thu, 21 Jul 2005 14:25:19 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FC543D82; Thu, 21 Jul 2005 14:24:46 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 72394A3051; Thu, 21 Jul 2005 16:24:45 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 5135566D0; Thu, 21 Jul 2005 16:24:45 +0200 (CEST) Date: Thu, 21 Jul 2005 16:24:45 +0200 From: Marc Olzheim To: Andrey Chernov , current@freebsd.org, wpaul@ctr.columbia.ed Message-ID: <20050721142445.GA77847@stack.nl> References: <20050721134816.GA8550@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20050721134816.GA8550@nagual.pp.ru> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 14:25:19 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 05:48:17PM +0400, Andrey Chernov wrote: > I got silent (without panic) reboots approx. every 4 hours running rl(4)= =20 > driver. When I turn off mpsafenet with > debug.mpsafenet=3D0 > reboots are stopped. I have KASSERTS on, but none of them are triggered,= =20 > just silent hardware reboots. Plain UP machine. No netgraph, ipfw, etc. > Any ideas? I thought rl cards were inherently MP unsafe because of design flaws. Does anyone know it they can be used safely nowadays anyway ? Marc --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC37AtezjnobFOgrERAkQmAKCJxbLqhWGhTrX4eeYPvurUYgI0GQCgmQAw TBy2teW91CEkZAvZApAIzzE= =EqCH -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 14:34: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 9242316A41F for ; Thu, 21 Jul 2005 14:34:52 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A9CE43D7E for ; Thu, 21 Jul 2005 14:34:47 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6LEYiL9010128; Thu, 21 Jul 2005 18:34:44 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6LEYhT4010127; Thu, 21 Jul 2005 18:34:43 +0400 (MSD) (envelope-from ache) Date: Thu, 21 Jul 2005 18:34:43 +0400 From: Andrey Chernov To: Marc Olzheim Message-ID: <20050721143443.GB10010@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Marc Olzheim , current@FreeBSD.ORG, wpaul@ctr.columbia.edu References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20050721142445.GA77847@stack.nl> User-Agent: Mutt/1.5.9i Cc: wpaul@ctr.columbia.edu, current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 14:34:52 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 04:24:45PM +0200, Marc Olzheim wrote: > I thought rl cards were inherently MP unsafe because of design > flaws. Does anyone know it they can be used safely nowadays anyway ? This is not something about MP exactly, but about internal logic flaws. As= =20 I wrote, I have _UP_ machine. --=20 http://ache.pp.ru/ --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQt+yg+JgpPLZnQjrAQKf+QP9HudE+2grpuN5rO9dx2lsN7BR02NChVyQ jdt7XjAauVQfdafT/hmMe4F2WtKc1f8f2/Nks8PvyJoyoqk/1mtPlClnTeLEYYWe HSzSW+/WqDdam9QcNK6DWitm+14ZYBmsJOnER3O25OoVm+qhd5paEqhmevjr66c7 VckKIxSvYfM= =IdoG -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 14:59: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 488AC16A420; Thu, 21 Jul 2005 14:59:37 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F8143D5C; Thu, 21 Jul 2005 14:59:35 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 1809BA2FCA; Thu, 21 Jul 2005 16:59:31 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id EB5BB66D0; Thu, 21 Jul 2005 16:59:30 +0200 (CEST) Date: Thu, 21 Jul 2005 16:59:30 +0200 From: Marc Olzheim To: Andrey Chernov , Marc Olzheim , current@FreeBSD.ORG, wpaul@ctr.columbia.edu Message-ID: <20050721145930.GC77847@stack.nl> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: <20050721143443.GB10010@nagual.pp.ru> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 14:59:37 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 06:34:43PM +0400, Andrey Chernov wrote: > > I thought rl cards were inherently MP unsafe because of design > > flaws. Does anyone know it they can be used safely nowadays anyway ? >=20 > This is not something about MP exactly, but about internal logic flaws. A= s=20 > I wrote, I have _UP_ machine. That doesn't seem to matter. :-/ Could you hook up a comconsole ? I wonder whether you see the "Consider adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=3D0" message before the crash. I assume you have DDB the kernel ? Marc --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC37hSezjnobFOgrERAq6LAJ0TShMfilWv3H/jFPJoyEhbNwnK6wCfQq7c lBjz3mMzk/QfzxcSw7rAWYo= =7xRn -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:11: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 92A1516A41F for ; Thu, 21 Jul 2005 15:11:08 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id B91B443D49 for ; Thu, 21 Jul 2005 15:11:07 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6LFB61q011163; Thu, 21 Jul 2005 19:11:06 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6LFB4hx011162; Thu, 21 Jul 2005 19:11:04 +0400 (MSD) (envelope-from ache) Date: Thu, 21 Jul 2005 19:11:04 +0400 From: Andrey Chernov To: Marc Olzheim Message-ID: <20050721151104.GA11072@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Marc Olzheim , current@FreeBSD.ORG, wpaul@windriver.com References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721145930.GC77847@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20050721145930.GC77847@stack.nl> User-Agent: Mutt/1.5.9i Cc: wpaul@windriver.com, current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:11:08 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 04:59:30PM +0200, Marc Olzheim wrote: > Could you hook up a comconsole ? I wonder whether you see the "Consider > adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=3D0" message > before the crash. >=20 > I assume you have DDB the kernel ? Yes, but no _any_ messages before crash, it looks like hardware reset. --=20 http://ache.pp.ru/ --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQt+7COJgpPLZnQjrAQI1+gP+LV0him6jgq8DLSrOy+3OL6Hs6jM0IAlc 55L40X3ak0Gxt8k3MFV8nugWnXjeJ/VCc4H2mzmvaNax3bJqynR5XVDEtf0nkvMp d7QBa+Yo/2M8giS5cpJK55+mizVJ7sGsuv/XQNRKjxk7aNekjuUOeDpNF6yXYrWC oCDsU35czgA= =IyMe -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:14: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 B454B16A41F for ; Thu, 21 Jul 2005 15:14:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE4043D46 for ; Thu, 21 Jul 2005 15:14:55 +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 j6LFDwHE085784; Thu, 21 Jul 2005 09:13:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 21 Jul 2005 09:14:47 -0600 (MDT) Message-Id: <20050721.091447.73268890.imp@bsdimp.com> To: ihsan@dogan.ch From: "M. Warner Losh" In-Reply-To: <20050720092544.GA3563@dogan.ch> References: <20050720083238.GA2195@dogan.ch> <20050720092544.GA3563@dogan.ch> 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-BETA1 on Thinkpad T42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:14:56 -0000 In message: <20050720092544.GA3563@dogan.ch> Ihsan Dogan writes: : Hello, : : On Wednesday, 20 Jul 2005 17:41 +0900, Hajimu UMEMOTO wrote: : : > >>>>> On Wed, 20 Jul 2005 10:32:38 +0200 : > >>>>> Ihsan Dogan said: : > : > ihsan> I've upgraded my T42 from 5.4 to 6.0-BETA1. With 6.0-BETA1, a : > ihsan> wake-up after a suspend doesn't work. If X is running, the : > ihsan> machine is freezed. If X isn't running, the machine is responding : > ihsan> very slowly and it's unusable. : > : > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222&r2=1.222.2.1 : > should solve your problem. : : Thank you for the hint, it's much better now, but still not : perfect. : : - If X is running, the screen looks sometimes weird. After I : switched to the console and then back to X, it's fine again. : : - After a wake-up, the system is hanging every few minutes for : about 5-10 seconds. : : I've got also this in /var/log/messages: : : Jul 20 11:08:17 makar kernel: wakeup from sleeping state (slept 00:00:30) : Jul 20 11:08:20 makar kernel: can't re-use a leaf (directional_scrolls)! : Jul 20 11:08:20 makar kernel: can't re-use a leaf (low_speed_threshold)! : Jul 20 11:08:20 makar kernel: can't re-use a leaf (min_movement)! : Jul 20 11:08:20 makar kernel: can't re-use a leaf (squelch_level)! These are from ndis and mean that your driver is trying to register multiple nodes of the same name. ndis is the only one that I know that does this repeatably. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:15: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 7DA8616A440 for ; Thu, 21 Jul 2005 15:15:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1F8443D45 for ; Thu, 21 Jul 2005 15:15:03 +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 j6LFCi2S085783; Thu, 21 Jul 2005 09:12:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 21 Jul 2005 09:13:33 -0600 (MDT) Message-Id: <20050721.091333.117435715.imp@bsdimp.com> To: ducrot@poupinou.org From: "M. Warner Losh" In-Reply-To: <20050720073353.GI2715@poupinou.org> References: <42DBC456.7060205@datacomm.ch> <20050720073353.GI2715@poupinou.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: benlutz@datacomm.ch, current@freebsd.org Subject: Re: ACPI: clock stops while sleeping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:15:04 -0000 In message: <20050720073353.GI2715@poupinou.org> Bruno Ducrot writes: : On Mon, Jul 18, 2005 at 05:01:42PM +0200, Benjamin Lutz wrote: : > I've installed FreeBSD-6.0-BETA1 on my Athlon64 (in amd64 mode), and I : > must say, the new power management features are impressive. I've noticed : > a slight hitch though: When I send the CPU to sleep with acpiconf -s 1, : > the clock will stop, resulting in the system time being wrong after : > wakeup. Is there something I can do to fix this, other than run ntpdate? : > (How to solve this without a network connection?) : : The pmtimer device is not yet ported to the amd64 architecture it seems. I believe that's true. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:21: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 DBEDA16A420; Thu, 21 Jul 2005 15:21:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D58EA43D81; Thu, 21 Jul 2005 15:20:46 +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 j6LFHtth085819; Thu, 21 Jul 2005 09:17:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 21 Jul 2005 09:18:44 -0600 (MDT) Message-Id: <20050721.091844.10574798.imp@bsdimp.com> To: ache@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20050721143443.GB10010@nagual.pp.ru> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> 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: marcolz@stack.nl, wpaul@ctr.columbia.edu, current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:21:05 -0000 In message: <20050721143443.GB10010@nagual.pp.ru> Andrey Chernov writes: : On Thu, Jul 21, 2005 at 04:24:45PM +0200, Marc Olzheim wrote: : > I thought rl cards were inherently MP unsafe because of design : > flaws. Does anyone know it they can be used safely nowadays anyway ? : : This is not something about MP exactly, but about internal logic flaws. As : I wrote, I have _UP_ machine. The problem isn't that they are inherently MP unsafe (that's a *DRIVER* concept, not a hardware one in this context). The problem with REV C and earlier is that their performance sucks because the DMA engine used in the cards was LAME. Realtec fixed this in newer revisions of the chip, and the re driver is able to take advantage of that (as well as support the newer gige chips). Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:30: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 DBA3B16A41F for ; Thu, 21 Jul 2005 15:30:06 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F8FB43D6E for ; Thu, 21 Jul 2005 15:29:50 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6LFTlYV011711; Thu, 21 Jul 2005 19:29:47 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6LFTkGb011709; Thu, 21 Jul 2005 19:29:46 +0400 (MSD) (envelope-from ache) Date: Thu, 21 Jul 2005 19:29:46 +0400 From: Andrey Chernov To: "M. Warner Losh" Message-ID: <20050721152946.GA11578@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "M. Warner Losh" , marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721.091844.10574798.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:30:07 -0000 On Thu, Jul 21, 2005 at 09:18:44AM -0600, M. Warner Losh wrote: > *DRIVER* concept, not a hardware one in this context). The problem > with REV C and earlier is that their performance sucks because the DMA > engine used in the cards was LAME. Realtec fixed this in newer > revisions of the chip, and the re driver is able to take advantage of > that (as well as support the newer gige chips). The problem is that it is on-board embedded chip I try to use. Looks like I need to buy some external card like "Intel PRO/100+ PCI" and turn this one off... The question remains: why rl(4) driver pretend to be mpsafenet itself? Other drivers with problems, like de(4), are GIANT-locked by default. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:30: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 EAF6516A42D for ; Thu, 21 Jul 2005 15:30:53 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (mailtest.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2777E43D88 for ; Thu, 21 Jul 2005 15:30:19 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id E5D428A0036 for ; Thu, 21 Jul 2005 08:30:19 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 94670-01-6 for ; Thu, 21 Jul 2005 08:30:15 -0700 (PDT) Received: from imap.sd73.bc.ca (smtp.sd73.bc.ca [10.10.10.15]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 22D2A8A0479 for ; Thu, 21 Jul 2005 08:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id E32A918CC57 for ; Thu, 21 Jul 2005 08:30:07 -0700 (PDT) Received: from imap.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74176-16-2 for ; Thu, 21 Jul 2005 08:30:05 -0700 (PDT) Received: by imap.sd73.bc.ca (Postfix, from userid 80) id 3A14018CC56; Thu, 21 Jul 2005 08:30:05 -0700 (PDT) Received: from 142.24.8.163 (SquirrelMail authenticated user fcash) by imap.sd73.bc.ca with HTTP; Thu, 21 Jul 2005 08:30:05 -0700 (PDT) Message-ID: <38563.142.24.8.163.1121959805.squirrel@imap.sd73.bc.ca> In-Reply-To: <20050721142445.GA77847@stack.nl> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> Date: Thu, 21 Jul 2005 08:30:05 -0700 (PDT) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fcash@ocis.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, 21 Jul 2005 15:30:54 -0000 > On Thu, Jul 21, 2005 at 05:48:17PM +0400, Andrey Chernov wrote: >> I got silent (without panic) reboots approx. every 4 hours running >> rl(4) driver. When I turn off mpsafenet with debug.mpsafenet=0 >> reboots are stopped. I have KASSERTS on, but none of them are >> triggered, just silent hardware reboots. Plain UP machine. No >> netgraph, ipfw, etc. Any ideas? > I thought rl cards were inherently MP unsafe because of design > flaws. Does anyone know it they can be used safely nowadays anyway ? I've been using rl(4) on 6-CURRENT for about a year now without problems. I've had it working with/without polling, and with/without all the mpsafe* sysctls enabled. The only problems I've had with it were the odd oversized frame being dropped requiring a reset of the interface. This is on a Toshiba A60 laptop with an onboard RealTek 8139C NIC. Haven't tried with an SMP system (those all have 3Com or Intel NICs). -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash@sd73.bc.ca helpdesk@sd73.bc.ca From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:38: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 180A616A41F; Thu, 21 Jul 2005 15:38:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A10D43D5C; Thu, 21 Jul 2005 15:38:50 +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 j6LFbJ9h086023; Thu, 21 Jul 2005 09:37:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 21 Jul 2005 09:38:08 -0600 (MDT) Message-Id: <20050721.093808.96975931.imp@bsdimp.com> To: ache@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20050721152946.GA11578@nagual.pp.ru> References: <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> 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: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:38:51 -0000 In message: <20050721152946.GA11578@nagual.pp.ru> Andrey Chernov writes: : The question remains: why rl(4) driver pretend to be mpsafenet itself? Software has bugs. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:40: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 6BC8716A41F; Thu, 21 Jul 2005 15:40:41 +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 7842143D90; Thu, 21 Jul 2005 15:40:21 +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 j6LFdojn043693; Thu, 21 Jul 2005 11:39:51 -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 j6LFeKhO091478; Thu, 21 Jul 2005 11:40:20 -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 j6LFeFVs029428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 11:40:18 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050721112003.07dfcec0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 11:42:13 -0400 To: John Baldwin From: Mike Tancsa In-Reply-To: <200507131409.39988.jhb@FreeBSD.org> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507121628.40539.jhb@FreeBSD.org> <6.2.1.2.0.20050713093748.067b8a88@64.7.153.2> <200507131409.39988.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 15:40:41 -0000 At 02:09 PM 13/07/2005, John Baldwin wrote: >On Wednesday 13 July 2005 09:38 am, Mike Tancsa wrote: > > At 04:28 PM 12/07/2005, John Baldwin wrote: > > >That does sort of help. Can you try commenting out the call to > > >ioapic_setup_mixed_mode() in the sys/i386/i386/mptable.c file and try > > > booting with ACPI disabled (but APIC on) and see if it still works ok? > > > > Yup, > > Still boots just fine. > >Ok. Back on 6, can you try editing sys/i386/i386/io_apic.c and in the >function ioapic_set_extint(), change the line that reads: > > io->io_pins[pin].io_masked = 1; > >to set the masked variable to 0 instead? Yes, it works with and without ACPI!! OK unload OK load /boot/kernel/kernel6 /boot/kernel/kernel6 text=0x2d7e4c data=0x32e00+0x33140 syms=[0x4+0x405e0+0x4+0x50a8b] OK set hint.acpi.0.disabled=1 OK boot KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #0: Thu Jul 21 10:43:52 EDT 2005 mdtancsa@shale1.sentex.ca:/usr/src/sys/i386/compile/test Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2100953088 (2003 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 4 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard cpu2 on motherboard cpu3 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) piix0: port 0x850-0x85f irq 9 at device 2.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: pcibus 2 on motherboard pci2: on pcib2 pcib3: pcibus 3 on motherboard pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to accept, logging limited to 3100 packets/entryt amrd0: on amr0 amrd0: 34732MB (71131136 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/amrd0s1a Pre-seeding PRNG: kickstart. sysctl: unknown oid 'kern.bootp_cookie' Interface IP-Address Broadcast Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/amrd0s1b as swap device Starting file system checks: /dev/amrd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1a: clean, 216177 free (641 frags, 26942 blocks, 0.3% fragmentation) /dev/amrd0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1e: clean, 506479 free (47 frags, 63304 blocks, 0.0% fragmentation) /dev/amrd0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1f: clean, 11181111 free (38615 frags, 1392812 blocks, 0.3% fragmentation) /dev/amrd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1d: clean, 2528737 free (377 frags, 316045 blocks, 0.0% fragmentation) Setting hostname: hippo.sentex.ca. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 Starting dhclient. em0: link state changed to UP em0: flags=8843 mtu 1500 options=b inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:0e:0c:5d:f8:ca media: Ethernet autoselect status: no carrier Additional routing options: IP gateway=YES. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Recovering vi editor sessions:. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Thu Jul 21 11:14:12 EDT 2005 FreeBSD/i386 (hippo.sentex.ca) (ttyd0) login: OK load /boot/kernel/kernel6 /boot/kernel/kernel6 text=0x2d7e4c data=0x32e00+0x33140 syms=[0x4+0x405e0+0x4+0x50a8b] OK load /boot/kernel/acpi.ko /boot/kernel/acpi.ko text=0x40b30 data=0x20e0+0x10b0 syms=[0x4+0x76b0+0x4+0x9e56] OK boot KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1 #0: Thu Jul 21 10:43:52 EDT 2005 mdtancsa@shale1.sentex.ca:/usr/src/sys/i386/compile/test ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (500.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbff real memory = 2147475456 (2047 MB) avail memory = 2096738304 (1999 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: irq 11 on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: irq 14 on acpi0 pci_link9: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) intpm0: port 0x850-0x85f irq 9 at device 2.3 on pci0 intpm0: I/O mapped 850 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus1: on intsmb0 smb0: on smbus1 intpm0: PM I/O mapped 800 pci0: at device 4.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 amr0: mem 0xfe000000-0xfe3fffff irq 14 at device 8.1 on pci0 amr0: Firmware GH6D, BIOS 1.43, 32MB RAM pcib2: on acpi0 pci2: on pcib2 pcib3: on acpi0 pci3: on pcib3 em0: port 0xfcc0-0xfcff mem 0xfeb20000-0xfeb3ffff,0xfeb00000-0xfeb1ffff irq3 em0: Ethernet address: 00:0e:0c:5d:f8:ca em0: Speed:N/A Duplex:N/A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 1 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to accept, logging limited to 3100 packets/entryt amrd0: on amr0 amrd0: 34732MB (71131136 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/amrd0s1a Pre-seeding PRNG: kickstart. sysctl: unknown oid 'kern.bootp_cookie' Interface IP-Address Broadcast Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/amrd0s1b as swap device Starting file system checks: /dev/amrd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1a: clean, 216177 free (641 frags, 26942 blocks, 0.3% fragmentation) /dev/amrd0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1e: clean, 506479 free (47 frags, 63304 blocks, 0.0% fragmentation) /dev/amrd0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1f: clean, 11181111 free (38615 frags, 1392812 blocks, 0.3% fragmentation) /dev/amrd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/amrd0s1d: clean, 2528725 free (381 frags, 316043 blocks, 0.0% fragmentation) Setting hostname: hippo.sentex.ca. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 Starting dhclient. em0: link state changed to UP em0: flags=8843 mtu 1500 options=b inet 192.168.5.107 netmask 0xffffff00 broadcast 192.168.5.255 ether 00:0e:0c:5d:f8:ca media: Ethernet autoselect status: no carrier Additional routing options: IP gateway=YES. Starting devd. Mounting NFS file systems:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Recovering vi editor sessions:. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Thu Jul 21 11:37:20 EDT 2005 FreeBSD/i386 (hippo.sentex.ca) (ttyd0) From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 16:14: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 2731716A41F for ; Thu, 21 Jul 2005 16:14:03 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF3A343D68 for ; Thu, 21 Jul 2005 16:13:55 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 48778ACAF4; Thu, 21 Jul 2005 18:13:53 +0200 (CEST) Date: Thu, 21 Jul 2005 18:13:53 +0200 From: Pawel Jakub Dawidek To: Emanuel Strobl Message-ID: <20050721161353.GX46538@darkness.comp.waw.pl> References: <200507191431.43004@harrymail> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DH1DRkmIQ+dOt2yx" Content-Disposition: inline In-Reply-To: <200507191431.43004@harrymail> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Cc: freebsd-current@freebsd.org Subject: Re: PANIC: ggatec destroy (6-Beta1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 16:14:03 -0000 --DH1DRkmIQ+dOt2yx Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 02:31:34PM +0200, Emanuel Strobl wrote: +> Hello, +>=20 +> I got the following panic whil playing with ggate: +> test3:/#39: ggatec destroy -u 1 +> GEOM_GATE: Device ggate1 destroyed. Could you fill PR and send me its number, so I'll not lose it? +> source from today, just ask if I can provide more info! Was it busy with I/O requests when you destroyed it or something? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DH1DRkmIQ+dOt2yx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFC38nBForvXbEpPzQRAvq1AJ9ULtNCoQD4z8u0Ru1Kt+72c0rZTQCg9/Xi ZfjVvul0ixv8MvHn7rUT0iI= =p10c -----END PGP SIGNATURE----- --DH1DRkmIQ+dOt2yx-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 17:29: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 13CCA16A41F for ; Thu, 21 Jul 2005 17:29:31 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4950643D46 for ; Thu, 21 Jul 2005 17:29:29 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 31820 invoked from network); 21 Jul 2005 17:29:28 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[83.129.64.130]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 21 Jul 2005 17:29:28 -0000 Date: Thu, 21 Jul 2005 19:29:41 +0200 From: Fabian Keil To: Ben Kaduk Message-ID: <20050721192941.74e673fa@localhost> In-Reply-To: <47d0403c050720212836f77a5c@mail.gmail.com> References: <47d0403c050720212836f77a5c@mail.gmail.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Signature_Thu__21_Jul_2005_19_29_41_+0200_+zWKmP0GdiRLNbSD; protocol="application/pgp-signature"; micalg=pgp-sha1 Cc: freebsd-current@freebsd.org Subject: Re: 6.0-release beta1 breaks ndis for dell truemobile 1400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 17:29:31 -0000 --Signature_Thu__21_Jul_2005_19_29_41_+0200_+zWKmP0GdiRLNbSD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ben Kaduk wrote: > I have not extensively used the ndis driver since I am not often > around wireless networks, but > after installing 5.4-release I compiled the driver using=20 > cd /usr/src/sys/modules/ndis > make install > cd /usr/src/sys/modules/if_ndis > ndiscvt -i bcmwl5a.inf -s bcmwl5.sys -o ndis_driver_data.h > make && make install >=20 > as recommended, with the bcmwl* files being the ones here: > http://netfiles.uiuc.edu/kaduk/www/* >=20 > The self-extracting driver (for windows) also generated a bcmwl5.inf > (not 'a'), but ndiscvt > produced an error whilst trying to read this file, so I used the 'a' > version, and ndiscvt finished > successfully; if_ndis was produced with no errors, and I was able to > kldload if_ndis.ko and ndis.ko. Upon doing this, console messages > were produced recognizing my Dell TrueMobile 1400 (broadcom bcm4324 > chipset), but i didn't have a wireless network to use then. > Since then, I have performed a source upgrade to 6.0-release beta1 > (cvsup last saturday; can't be more precise since I must boot windows > to use wireless :( ). > I just today had occasion to use the wireless card, and kldload()-ing > if_ndis resulted in a panic(). I didn't save the message for two > reasons: (1), I thought it was just that if_ndis.ko had not been > rebuild with world, and (2) I'm using my laptop at a friend's > appartment with no serial console. After performing several > iterations of cleaning for ndis, if_ndis, and wlan, and > rebuilding/installing, I produced if_ndis.ko, ndis.ko, and wlan.ko > that I could successfully kldload() with no panic. However, there > were no console messages that appeared indicating that the system had > found my hardward, leading to the statement in the subject that the > beta breaks ndis for this card. I have already posted a pciconf -lv > to the list in this thread: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D116619+0+current/freebsd-c= urrent >=20 > What steps can I take to help debug this regression? At first you should try to build ndis the right way, which was changed a while ago. Now /usr/sbin/ndisgen is used to put the firmware in a separate module.=20 Fabian --=20 http://www.fabiankeil.de/ --Signature_Thu__21_Jul_2005_19_29_41_+0200_+zWKmP0GdiRLNbSD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFC39uQoomUOj0wp30RAk/hAJ9RFZO5XNxkp5QhBXo6jCvr1jNaoACdFQ0c 1O/3qCpWoIxWDg3FOf156ng= =K1iZ -----END PGP SIGNATURE----- --Signature_Thu__21_Jul_2005_19_29_41_+0200_+zWKmP0GdiRLNbSD-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 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 30FDF16A41F for ; Thu, 21 Jul 2005 18:03:26 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3482543D58 for ; Thu, 21 Jul 2005 18:03:14 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 50F5C3BE80 for ; Thu, 21 Jul 2005 13:03:13 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30665-01-48 for ; Thu, 21 Jul 2005 13:03:13 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id AC0893BF6B for ; Thu, 21 Jul 2005 13:03:12 -0500 (CDT) Received: from s228130hz1ew171.apptix-01.savvis.net ([10.146.4.29]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 13:03:21 -0500 Received: from [10.254.186.111] ([64.14.1.106]) by s228130hz1ew171.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 13:03:17 -0500 Message-ID: <42DFE35B.5090503@savvis.net> Date: Thu, 21 Jul 2005 11:03:07 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) 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 X-OriginalArrivalTime: 21 Jul 2005 18:03:17.0782 (UTC) FILETIME=[78DCB360:01C58E1E] X-Virus-Scanned: amavisd-new at savvis.net Subject: HEADSUP: kbdmux(4) is in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 18:03:26 -0000 Dear Hackers, this is just a quick headsup on kbdmux(4). as of now it has been committed to both HEAD and RELENG_6 (much thanks to re@ for turning this around quickly). kbdcontrol(1) utility was enhanced and now knows how to add/remove keyboards to/from kbdmux(4). kbdmux(4) was _not_ made the default yet. there are still a few unsolved issues: 1) using kbdmux(4) with atkbd(4) and psm(4) mouse sometimes locks up my system (Dell laptop). so far i was not able to track it down. for now i just use ums(4) mouse. 2) using kbdmux(4) with atkbd(4) and ukbd(4) sometimes lead to keyboard state corruption. the easiest way to reproduce this is to hit keys on both keyboards really fast in xterm. switching between X/console fixes the keyboard state. 3) kbdmux(4) fails The Warner test. Press control on kbd0 Press control on kbd1 C should produce ^C Release control on kbd0 D should produce ^D release control on kbd1 E should produce E. i will try to track these issues down and fix them. in the mean time please give kbdmux(4) a try (if you have interest/time/hardware). thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 18:09: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 AFC9716A42A for ; Thu, 21 Jul 2005 18:09:08 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F99143D9D for ; Thu, 21 Jul 2005 18:08:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6LI8vNV013596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 14:08:57 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6LI8v6P030657; Thu, 21 Jul 2005 14:08:57 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C91785119A; Thu, 21 Jul 2005 14:08:56 -0400 (EDT) Date: Thu, 21 Jul 2005 14:08:55 -0400 From: Kris Kennaway To: Ken Smith Message-ID: <20050721180855.GA52930@xor.obsecurity.org> References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <1121952594.68685.27.camel@opus.cse.buffalo.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 18:09:08 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 09:29:54AM -0400, Ken Smith wrote: > Since support for this is new, what needs to be done now will be worse > than what we will be doing down the road. Tomorrow we will bump the > shared library version numbers in both RELENG_6 and HEAD by one so that > they differ from the version numbers currently in RELENG_5. Then some > time a bit after the 6.0-RELEASE is finished we will bump all the > version numbers in HEAD again. >=20 > It will take a while for the fallout from this version bump to > propagate. People who cvsup/rebuild existing systems should not be > impacted immediately - you will still have the older library versions > present on your systems. However it will take time for the pre-built > packages provided by the portmgr folks to be rebuilt, loaded onto the > FTP servers, and propagate out to the mirrors. Based on this I'm going to hold off on uploading the packages-7-current/ packages since they'd have to be replaced ASAP anyway. In the meantime, people can use packages on HEAD by setting PACKAGESITE to use the packages-6-current/ packages, which should almost all work fine on HEAD. Kris --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3+S3Wry0BWjoQKURAod7AJ4yrBXtbKqP9JVQsLx4nwBIgyy/HQCg35gM xlNFFHzzF3F+OP2fymqaFjE= =fXUN -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 18:38: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 A492E16A420 for ; Thu, 21 Jul 2005 18:38:56 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6426843D69 for ; Thu, 21 Jul 2005 18:38:53 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Thu, 21 Jul 2005 11:38:52 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 074415D07 for ; Thu, 21 Jul 2005 11:38:52 -0700 (PDT) To: freebsd-current@freebsd.org Date: Thu, 21 Jul 2005 11:38:52 -0700 From: "Kevin Oberman" Message-Id: <20050721183852.074415D07@ptavv.es.net> Subject: More wi odd behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 18:38:56 -0000 This seems to be my week for wireless problems, but they are starting to get really weird, now. I was running with tcpdump monitoring the TCP stream between my laptop her in Vancouver and my desktop system in California to try to figure out why I was seeing performance problems. I suspect that the packet capture triggered something as the problems were MUCH worse while I had tcpdump running in promiscuous mode. In any case, my stream locked up and I saw the following: # ifconfig wi0 wi0: flags=8943 mtu 1500 inet6 fe80::205:3cff:fe03:86b9%wi0 prefixlen 64 scopeid 0x3 inet 142.231.19.178 netmask 0xfffffe00 broadcast 142.231.19.255 ether 00:05:3c:03:86:b9 # wicontrol wicontrol: SIOCGWAVELAN: Operation not supported by device # dhclient wi0 ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device wi0: not found exiting. ???? I unloaded if_wi and reloaded it and restarted dhclient and everything was fine. My ssh connections even survived. Any idea what the heck is happening here? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 19:36: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 225C116A422 for ; Thu, 21 Jul 2005 19:36:27 +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 2964643D97 for ; Thu, 21 Jul 2005 19:36:18 +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 j6LJaHx7025607; Thu, 21 Jul 2005 12:36:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6LJaH6Q025606; Thu, 21 Jul 2005 12:36:17 -0700 Date: Thu, 21 Jul 2005 12:36:17 -0700 From: Brooks Davis To: Nate Lawson Message-ID: <20050721193617.GD17516@odin.ac.hmc.edu> References: <42DF419C.90203@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q9KOos5vDmpwPx9o" Content-Disposition: inline In-Reply-To: <42DF419C.90203@root.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: FreeBSD Current Subject: Re: dhclient started twice on recent 7-current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:36:27 -0000 --q9KOos5vDmpwPx9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 11:33:00PM -0700, Nate Lawson wrote: > When booting, dhclient is started just after "hostname". However, once= =20 > devd starts, it tries to start dhclient again which fails with a message= =20 > saying dhclient is already running. >=20 > Here are the relevant sections from rc.conf: > removable_interfaces=3D"an0" > ifconfig_fxp0=3D"DHCP" > ifconfig_an0=3D"DHCP" > hostname=3D"mrspecial" > devd_enable=3D"YES" That's more or less by design. Dhclient needs to start when the link comes up in order to work since it dies when the link goes down. It also needs to start at startup because too many applications (sendmail being the classic culprit) depend having an IP address configured. -- 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 --q9KOos5vDmpwPx9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC3/kvXY6L6fI4GtQRArQdAKDgNG+twpkjh24Yh/AvReCKZRq6qQCffCZP 4652/fBF3E323nnri1FrqXo= =BSzE -----END PGP SIGNATURE----- --q9KOos5vDmpwPx9o-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 19:45: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 2CA0016A41F for ; Thu, 21 Jul 2005 19:45:52 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87E8143DA0 for ; Thu, 21 Jul 2005 19:45:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6LJjio5031933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jul 2005 12:45:46 -0700 Message-ID: <42DFFB67.4020602@root.org> Date: Thu, 21 Jul 2005 12:45:43 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <42DF419C.90203@root.org> <20050721193617.GD17516@odin.ac.hmc.edu> In-Reply-To: <20050721193617.GD17516@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: dhclient started twice on recent 7-current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:45:52 -0000 Brooks Davis wrote: > On Wed, Jul 20, 2005 at 11:33:00PM -0700, Nate Lawson wrote: > >>When booting, dhclient is started just after "hostname". However, once >>devd starts, it tries to start dhclient again which fails with a message >>saying dhclient is already running. >> >>Here are the relevant sections from rc.conf: >>removable_interfaces="an0" >>ifconfig_fxp0="DHCP" >>ifconfig_an0="DHCP" >>hostname="mrspecial" >>devd_enable="YES" > > That's more or less by design. Dhclient needs to start when the link > comes up in order to work since it dies when the link goes down. It > also needs to start at startup because too many applications (sendmail > being the classic culprit) depend having an IP address configured. Any way to silence the "already running" error in the script run by devd? -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 20:19: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 D682216A44F for ; Thu, 21 Jul 2005 20:19:15 +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 6CC8243D45 for ; Thu, 21 Jul 2005 20:19:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 21 Jul 2005 16:33:20 -0400 From: John Baldwin To: Mike Tancsa Date: Thu, 21 Jul 2005 12:57:20 -0400 User-Agent: KMail/1.8 References: <70e8236f05070208212e36c375@mail.gmail.com> <200507131409.39988.jhb@FreeBSD.org> <6.2.1.2.0.20050721112003.07dfcec0@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050721112003.07dfcec0@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211257.21730.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 20:19:16 -0000 On Thursday 21 July 2005 11:42 am, Mike Tancsa wrote: > At 02:09 PM 13/07/2005, John Baldwin wrote: > >On Wednesday 13 July 2005 09:38 am, Mike Tancsa wrote: > > > At 04:28 PM 12/07/2005, John Baldwin wrote: > > > >That does sort of help. Can you try commenting out the call to > > > >ioapic_setup_mixed_mode() in the sys/i386/i386/mptable.c file and try > > > > booting with ACPI disabled (but APIC on) and see if it still works > > > > ok? > > > > > > Yup, > > > Still boots just fine. > > > >Ok. Back on 6, can you try editing sys/i386/i386/io_apic.c and in the > >function ioapic_set_extint(), change the line that reads: > > > > io->io_pins[pin].io_masked = 1; > > > >to set the masked variable to 0 instead? > > Yes, it works with and without ACPI!! Ok. That change directly violates the ACPI standard. :( I need to think about this. At the very least I can add a tunable for this. -- 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 Jul 21 20:30: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 91A8016A41F for ; Thu, 21 Jul 2005 20:30:37 +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 3F27143D46 for ; Thu, 21 Jul 2005 20:30:37 +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 j6LKUaiA000366; Thu, 21 Jul 2005 13:30:36 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6LKUaST000365; Thu, 21 Jul 2005 13:30:36 -0700 Date: Thu, 21 Jul 2005 13:30:36 -0700 From: Brooks Davis To: Nate Lawson Message-ID: <20050721203036.GG17516@odin.ac.hmc.edu> References: <42DF419C.90203@root.org> <20050721193617.GD17516@odin.ac.hmc.edu> <42DFFB67.4020602@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Iq5ULCa7nGtWwZS" Content-Disposition: inline In-Reply-To: <42DFFB67.4020602@root.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: FreeBSD Current Subject: Re: dhclient started twice on recent 7-current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:30:37 -0000 --9Iq5ULCa7nGtWwZS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 12:45:43PM -0700, Nate Lawson wrote: > Brooks Davis wrote: > >On Wed, Jul 20, 2005 at 11:33:00PM -0700, Nate Lawson wrote: > > > >>When booting, dhclient is started just after "hostname". However, once= =20 > >>devd starts, it tries to start dhclient again which fails with a messag= e=20 > >>saying dhclient is already running. > >> > >>Here are the relevant sections from rc.conf: > >>removable_interfaces=3D"an0" > >>ifconfig_fxp0=3D"DHCP" > >>ifconfig_an0=3D"DHCP" > >>hostname=3D"mrspecial" > >>devd_enable=3D"YES" > > > >That's more or less by design. Dhclient needs to start when the link > >comes up in order to work since it dies when the link goes down. It > >also needs to start at startup because too many applications (sendmail > >being the classic culprit) depend having an IP address configured. >=20 > Any way to silence the "already running" error in the script run by devd? The following patch should do it. I can't decide if it's something I should commit or not. -- Brooks Index: dhclient =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/etc/rc.d/dhclient,v retrieving revision 1.20 diff -u -p -r1.20 dhclient --- dhclient 30 Jun 2005 17:50:34 -0000 1.20 +++ dhclient 21 Jul 2005 20:28:10 -0000 @@ -23,7 +23,6 @@ dhclient_start() if [ -x /usr/bin/pgrep ]; then pids=3D`/usr/bin/pgrep -f "dhclient: $ifn(\$| .*)"` if [ -n "$pids" ]; then - echo "${name} ${ifn}: already running?" exit 0 fi fi --=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 --9Iq5ULCa7nGtWwZS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC4AXrXY6L6fI4GtQRAkUsAJ9hsUo2/vuIvEfgyvvJAyTpXgFR4ACgsA9K H8Ug/G9p+1WSU+UjKPZpMdE= =7fr0 -----END PGP SIGNATURE----- --9Iq5ULCa7nGtWwZS-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 20:40: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 93CB916A41F for ; Thu, 21 Jul 2005 20:40:47 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FB3143D46 for ; Thu, 21 Jul 2005 20:40:46 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so94395wri for ; Thu, 21 Jul 2005 13:40:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tz5lV/+NysePe7ehWiU3Kgi7wkLpVEi0dka4q5epcT2fb+WgnfOraCe474IDcG1gFp7hnQKIARJ/sV5Kk1LE0CBnW26UUoO8e2A1HFY0tMxttHQuvFIZwLIwnLjrqlmt1YtNFmie2Jn/zS1fU9T5nEtNWTdX1Rp3aKmsi3heLhw= Received: by 10.54.53.74 with SMTP id b74mr720218wra; Thu, 21 Jul 2005 13:40:26 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Thu, 21 Jul 2005 13:40:26 -0700 (PDT) Message-ID: <47d0403c050721134069ae027c@mail.gmail.com> Date: Thu, 21 Jul 2005 20:40:26 +0000 From: Ben Kaduk To: freebsd-current@freebsd.org In-Reply-To: <20050721192941.74e673fa@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47d0403c050720212836f77a5c@mail.gmail.com> <20050721192941.74e673fa@localhost> Cc: Fabian Keil Subject: Re: 6.0-release beta1 breaks ndis for dell truemobile 1400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:40:47 -0000 On 7/21/05, Fabian Keil wrote: > Ben Kaduk wrote: >=20 > > I have not extensively used the ndis driver since I am not often > > around wireless networks, but > > after installing 5.4-release I compiled the driver using > > cd /usr/src/sys/modules/ndis > > make install > > cd /usr/src/sys/modules/if_ndis > > ndiscvt -i bcmwl5a.inf -s bcmwl5.sys -o ndis_driver_data.h > > make && make install > > > > as recommended, with the bcmwl* files being the ones here: > > http://netfiles.uiuc.edu/kaduk/www/* > > > > The self-extracting driver (for windows) also generated a bcmwl5.inf > > (not 'a'), but ndiscvt > > produced an error whilst trying to read this file, so I used the 'a' > > version, and ndiscvt finished > > successfully; if_ndis was produced with no errors, and I was able to > > kldload if_ndis.ko and ndis.ko. Upon doing this, console messages > > were produced recognizing my Dell TrueMobile 1400 (broadcom bcm4324 > > chipset), but i didn't have a wireless network to use then. > > Since then, I have performed a source upgrade to 6.0-release beta1 > > (cvsup last saturday; can't be more precise since I must boot windows > > to use wireless :( ). > > I just today had occasion to use the wireless card, and kldload()-ing > > if_ndis resulted in a panic(). I didn't save the message for two > > reasons: (1), I thought it was just that if_ndis.ko had not been > > rebuild with world, and (2) I'm using my laptop at a friend's > > appartment with no serial console. After performing several > > iterations of cleaning for ndis, if_ndis, and wlan, and > > rebuilding/installing, I produced if_ndis.ko, ndis.ko, and wlan.ko > > that I could successfully kldload() with no panic. However, there > > were no console messages that appeared indicating that the system had > > found my hardward, leading to the statement in the subject that the > > beta breaks ndis for this card. I have already posted a pciconf -lv > > to the list in this thread: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D116619+0+current/freebsd= -current > > > > What steps can I take to help debug this regression? >=20 > At first you should try to build ndis the right way, which > was changed a while ago. Now /usr/sbin/ndisgen is used to put the > firmware in a separate module. >=20 > >=20 >=20 > Fabian > -- > http://www.fabiankeil.de/ >=20 >=20 >=20 Is there anyone working on updating the handbook and generating an ndisgen() manpage, or should I whip something together? Ben From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 23:15: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 DCD2A16A43D for ; Thu, 21 Jul 2005 23:15:04 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F6B43D78 for ; Thu, 21 Jul 2005 23:14:58 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j6LNEmPC041385; Fri, 22 Jul 2005 01:14:48 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current@freebsd.org, Sam Leffler In-Reply-To: <1121881805.929.38.camel@genius1.i.cz> References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> <1121855884.796.8.camel@genius1.i.cz> <42DE648B.1060402@errno.com> <1121881805.929.38.camel@genius1.i.cz> Content-Type: text/plain Date: Fri, 22 Jul 2005 01:14:45 +0200 Message-Id: <1121987685.61017.31.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2005 23:15:05 -0000 Michal Mertl wrote: > Sam Leffler wrote: > > Michal Mertl wrote: > > > > > > I run an ath card in hostap mode and several wireless clients connect to > > > it and are on the same IP network. The ping from one client to another > > > is slow yet both ping the AP fine. I think that in this situation the > > > bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. > > > > The bridging is done in the net80211 layer, not "in the card". I will > > test, thank you. > > Thanks for the correction. > > And thank you for looking into it. Some new findings: I can confirm that the atheros based client really connects much worse than an IPW based one. When I restart the atheros AP, the ipw card connects immediately after the AP is back but the atheros client either never connects or it will take long time (I didn't wait long enough). It connects immediately after I issue ifconfig down/up on it. More interesting finding that I have is about the bridging issue. I wasn't able to find which debug setting (via dev.ath.0.debug or net.wlan.0.debug) will show me any usefull information. Anyways it now seems to me that I was wrong saying that it works at all. The AP bridges the packets only when there is another IP communication between the AP host and one of the clients. It seems to me that the bridged packets are queued somewhere and sent only when there are some non bridged. Test conditions - I have 192.168.1.1 on the AP, .2 on the IPW notebook and .3 on the atheros client. The settings of ath0 on AP are: "mode 11b mediaopt hostap channel 1 ssid test_ap_xx". The settings on clients are almost the same except there I don't issue any mediaopt. I hope I'm not doing anything extra stupid :-). The nodes are just several centimeters apart from each other and I only have tiny antennas. When the only IP communication is the ping from 192.168.1.2 to .3 (between the clients) I don't get any answer. When I ping at the same time from between any of the clients and the AP it works. When I let the first ping run for several seconds and then start the second one I get all the answers at the same time. This is probably complete nonsense but I think that what I'm experiencing looks as if the bridged packets weren't generating interrupts or something. I've got serial consoles hooked to the machines and am able to sprinkle some debug prints somewhere if required. Michal From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:17: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 A7A7316A42F; Fri, 22 Jul 2005 00:17: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 D83D843DA4; Fri, 22 Jul 2005 00:17:21 +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 EEC0F46B03; Thu, 21 Jul 2005 20:17:20 -0400 (EDT) Date: Fri, 22 Jul 2005 01:17:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20050721134816.GA8550@nagual.pp.ru> Message-ID: <20050722011556.T16902@fledge.watson.org> References: <20050721134816.GA8550@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: wpaul@ctr.columbia.edu, current@freebsd.org Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:17:35 -0000 On Thu, 21 Jul 2005, Andrey Chernov wrote: > I got silent (without panic) reboots approx. every 4 hours running rl(4) > driver. When I turn off mpsafenet with debug.mpsafenet=0 reboots are > stopped. I have KASSERTS on, but none of them are triggered, just silent > hardware reboots. Plain UP machine. No netgraph, ipfw, etc. Any ideas? I can't speak to the specifics of the driver, as I neither use it nor have any if_rl hardware. However, you should know that because debug.mpsafenet=0 also changes quite a bit of timing, not just lock coverage, it's not necessarily a locking problem. Out of curiousity, if you take "options PREEMPTION" out, but leave debug.mpsafenet=1, do things change? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:20: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 86E5C16A420; Fri, 22 Jul 2005 00:20:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F38843D80; Fri, 22 Jul 2005 00:20:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 9A82446B03; Thu, 21 Jul 2005 20:20:14 -0400 (EDT) Date: Fri, 22 Jul 2005 01:20:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20050721152946.GA11578@nagual.pp.ru> Message-ID: <20050722011804.O16902@fledge.watson.org> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:20:30 -0000 On Thu, 21 Jul 2005, Andrey Chernov wrote: > On Thu, Jul 21, 2005 at 09:18:44AM -0600, M. Warner Losh wrote: >> *DRIVER* concept, not a hardware one in this context). The problem >> with REV C and earlier is that their performance sucks because the DMA >> engine used in the cards was LAME. Realtec fixed this in newer >> revisions of the chip, and the re driver is able to take advantage of >> that (as well as support the newer gige chips). > > The problem is that it is on-board embedded chip I try to use. Looks > like I need to buy some external card like "Intel PRO/100+ PCI" and turn > this one off... > > The question remains: why rl(4) driver pretend to be mpsafenet itself? > Other drivers with problems, like de(4), are GIANT-locked by default. Given that this is the first report of such a feature that I've seen, it's likely that it's marked as MPSAFE because it appeared to the author to be MPSAFE. You'll notice that if_de is marked as requiring Giant because it doesn't have any locking. Although actually, John Baldwin spent the last day or so fixing if_de, so presumably that will go into the tree shortly and that will cease to be the case. FYI, most locking bugs in network interfaces that I've seen don't result in a spontaneous reboot, and that's a somewhat worrying symptom. Is this something you can easily reproduce in a short period of time, or in particular, using a particular program or system call? Is there any chance your box has firewire and you can use a firewire debugger to inspect memory? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:22: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 4FC9216A41F for ; Fri, 22 Jul 2005 00:22:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA2B43D79 for ; Fri, 22 Jul 2005 00:21:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6851A46B2A; Thu, 21 Jul 2005 20:21:52 -0400 (EDT) Date: Fri, 22 Jul 2005 01:22:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kevin Oberman In-Reply-To: <20050721183852.074415D07@ptavv.es.net> Message-ID: <20050722012111.P16902@fledge.watson.org> References: <20050721183852.074415D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: More wi odd behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:22:14 -0000 On Thu, 21 Jul 2005, Kevin Oberman wrote: > # ifconfig wi0 > wi0: flags=8943 mtu 1500 > inet6 fe80::205:3cff:fe03:86b9%wi0 prefixlen 64 scopeid 0x3 > inet 142.231.19.178 netmask 0xfffffe00 broadcast 142.231.19.255 > ether 00:05:3c:03:86:b9 > # wicontrol > wicontrol: SIOCGWAVELAN: Operation not supported by device > # dhclient wi0 > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device > wi0: not found If you dmesg, is there a partial driver detach? I saw that problem fairly frequently when I was using WEP a few months ago, but haven't seen it recently. At some point it seemed like the driver got upset and basically detatched or partially detached. Ejecting and re-inserting "fixed" the problem. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:37:15 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 329B816A421; Fri, 22 Jul 2005 00:37:15 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05FE643D62; Fri, 22 Jul 2005 00:37:02 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6M0awKs001456; Fri, 22 Jul 2005 04:36:58 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6M0ava4001455; Fri, 22 Jul 2005 04:36:58 +0400 (MSD) (envelope-from ache) Date: Fri, 22 Jul 2005 04:36:57 +0400 From: Andrey Chernov To: Robert Watson Message-ID: <20050722003657.GA1415@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , "M. Warner Losh" , marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> <20050722011804.O16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722011804.O16902@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:37:15 -0000 On Fri, Jul 22, 2005 at 01:20:46AM +0100, Robert Watson wrote: > FYI, most locking bugs in network interfaces that I've seen don't result > in a spontaneous reboot, and that's a somewhat worrying symptom. Is this > something you can easily reproduce in a short period of time, or in > particular, using a particular program or system call? Is there any > chance your box has firewire and you can use a firewire debugger to > inspect memory? I can't reproduce it, it happens after few hours running. Perhaps the problem is not in rl(4) and making it GIANT only mask the problem. I have spare hardware to swith to and experiment and I'll see what happens. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:40: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 364E416A44C; Fri, 22 Jul 2005 00:40:37 +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 3F85643E1D; Fri, 22 Jul 2005 00:39:56 +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 B6F7846B06; Thu, 21 Jul 2005 20:39:35 -0400 (EDT) Date: Fri, 22 Jul 2005 01:40:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20050722003657.GA1415@nagual.pp.ru> Message-ID: <20050722013938.H16902@fledge.watson.org> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> <20050722011804.O16902@fledge.watson.org> <20050722003657.GA1415@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:40:37 -0000 On Fri, 22 Jul 2005, Andrey Chernov wrote: > On Fri, Jul 22, 2005 at 01:20:46AM +0100, Robert Watson wrote: >> FYI, most locking bugs in network interfaces that I've seen don't result >> in a spontaneous reboot, and that's a somewhat worrying symptom. Is this >> something you can easily reproduce in a short period of time, or in >> particular, using a particular program or system call? Is there any >> chance your box has firewire and you can use a firewire debugger to >> inspect memory? > > I can't reproduce it, it happens after few hours running. Perhaps the > problem is not in rl(4) and making it GIANT only mask the problem. I > have spare hardware to swith to and experiment and I'll see what > happens. If the same problem occurs using a different adapter but identical software configuration otherwise, that would be very helpful to know. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:40:39 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 9B2EC16A48C; Fri, 22 Jul 2005 00:40:39 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 524F343D80; Fri, 22 Jul 2005 00:40:22 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6M0eLMb001491; Fri, 22 Jul 2005 04:40:21 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6M0eL88001490; Fri, 22 Jul 2005 04:40:21 +0400 (MSD) (envelope-from ache) Date: Fri, 22 Jul 2005 04:40:21 +0400 From: Andrey Chernov To: Robert Watson Message-ID: <20050722004021.GB1415@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.ORG References: <20050721134816.GA8550@nagual.pp.ru> <20050722011556.T16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722011556.T16902@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:40:39 -0000 On Fri, Jul 22, 2005 at 01:17:52AM +0100, Robert Watson wrote: > coverage, it's not necessarily a locking problem. Out of curiousity, if > you take "options PREEMPTION" out, but leave debug.mpsafenet=1, do things > change? I don't have "options PREEMPTION". Is it good to have? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 00:46:42 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 D9DE016A41F; Fri, 22 Jul 2005 00:46:42 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7763743D55; Fri, 22 Jul 2005 00:46:06 +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 E825946B3C; Thu, 21 Jul 2005 20:46:05 -0400 (EDT) Date: Fri, 22 Jul 2005 01:46:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20050722004021.GB1415@nagual.pp.ru> Message-ID: <20050722014551.G16902@fledge.watson.org> References: <20050721134816.GA8550@nagual.pp.ru> <20050722011556.T16902@fledge.watson.org> <20050722004021.GB1415@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.ORG Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 00:46:43 -0000 On Fri, 22 Jul 2005, Andrey Chernov wrote: > On Fri, Jul 22, 2005 at 01:17:52AM +0100, Robert Watson wrote: >> coverage, it's not necessarily a locking problem. Out of curiousity, >> if you take "options PREEMPTION" out, but leave debug.mpsafenet=1, do >> things change? > > I don't have "options PREEMPTION". Is it good to have? It's in GENERIC, so I assumed you were running with it unless you otherwise documented it as part of your bug report. PREEMPTION is good to have, as it dramatically lowers the latency in processing interrupts when running kernel-intensive workloads. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 04:57: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 DA2AB16A42A; Fri, 22 Jul 2005 04:57:24 +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 5B7D543D6B; Fri, 22 Jul 2005 04:57:07 +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 j6M4v4ms040194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 21:57:06 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E07DE8.9000804@errno.com> Date: Thu, 21 Jul 2005 22:02:32 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Mertl References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> <1121855884.796.8.camel@genius1.i.cz> In-Reply-To: <1121855884.796.8.camel@genius1.i.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 04:57:25 -0000 Michal Mertl wrote: > Sam Leffler wrote: > >>Michal Mertl wrote: >> >>>Robert Watson wrote: >>> >>> >>>>I fairly regularly use 802.11 adhoc with WEP to communicate between my >>>>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac >>>>OS X Tiger. A few days ago, when I updated from a June to a July HEAD >>>>revision, this became quite "fragile". Specifically, I often find that >>>>the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes >>>>it will give an error when I ask it to re-connect to the ad hoc network. >>>>I find that if I ifconfig down/up if_wi, and likewise turn off and on the >>>>wireless on the PowerBook, it seems to recover. I've not had a chance to >>>>really try and diagnose this at all -- i.e., does tcpdump show packets on >>>>either end, 802.11 state machine, etc. I was wondering if anyone else has >>>>seen this problem, though. >>> >>> >>>Yes, I'm also experiencing similar problems. The problems seem to happen >>>also with different wireless cards and without wep. They were reported >>>by Johann Hugo on 14th in an email titled "ath hostap - clients >>>assosiated, but no comms" too. >>> >>>Another problem with WiFi which Johann reported long time ago is that >>>bridging on atheros (only?) AP works really bad. I get very varying ping >>>response (50 - inf. ms). Sometimes it seems the packets get queued >>>somewhere - after some time I receive several replies at once. >> >>I routinely bridge ath cards (a wide variety) with bge using bridge and >>see no problems. I get ~36 Mb/s in 11a w/ superg features and ~28 Mb/s >>w/ basic stuff (what you find in RELENG_6). ping times are what you'd >>expect (<1ms). > > > I'm sorry, I was too brief in the description of the problem. It's the > bridging on the card which works slow. > > I run an ath card in hostap mode and several wireless clients connect to > it and are on the same IP network. The ping from one client to another > is slow yet both ping the AP fine. I think that in this situation the > bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. Should be fixed by ieee80211_input.c rev 1.63. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 07:45: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 7017F16A41F for ; Fri, 22 Jul 2005 07:45:28 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from mail.blastwave.org (mail.blastwave.org [147.87.98.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA62743D58 for ; Fri, 22 Jul 2005 07:44:53 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from localhost (localhost [127.0.0.1]) by mail.blastwave.org (Postfix) with ESMTP id C3F2DF8A8 for ; Fri, 22 Jul 2005 09:44:51 +0200 (MEST) Received: from mail.blastwave.org ([127.0.0.1]) by localhost (enterprise [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23213-03 for ; Fri, 22 Jul 2005 09:44:40 +0200 (MEST) Received: from defiant.dogan.ch (defiant.dogan.ch [213.144.141.146]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.blastwave.org (Postfix) with ESMTP id B3A8BF8A7 for ; Fri, 22 Jul 2005 09:44:39 +0200 (MEST) Received: by defiant.dogan.ch (Postfix, from userid 1000) id 6F9BA179AC; Fri, 22 Jul 2005 09:44:38 +0200 (CEST) Date: Fri, 22 Jul 2005 09:44:38 +0200 From: Ihsan Dogan To: freebsd-current@freebsd.org Message-ID: <20050722074438.GA8666@dogan.ch> Mail-Followup-To: freebsd-current@freebsd.org References: <20050720083238.GA2195@dogan.ch> <20050720092544.GA3563@dogan.ch> <20050721.091447.73268890.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20050721.091447.73268890.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD/i386 1.6.2 X-Uptime: 9:42AM up 362 days, 22:07, 10 users, load averages: 0.87, 1.09, 0.98 X-Binford: 6100 (more power) X-Editor: Vim-603 http://www.vim.org X-Virus-Scanned: amavisd-new at blastwave.org Subject: Re: 6.0-BETA1 on Thinkpad T42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 07:45:28 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Good morning, On Thursday, 21 Jul 2005 09:14 -0600, M. Warner Losh wrote: > : Jul 20 11:08:17 makar kernel: wakeup from sleeping state (slept 00:00:30) > : Jul 20 11:08:20 makar kernel: can't re-use a leaf (directional_scrolls)! > : Jul 20 11:08:20 makar kernel: can't re-use a leaf (low_speed_threshold)! > : Jul 20 11:08:20 makar kernel: can't re-use a leaf (min_movement)! > : Jul 20 11:08:20 makar kernel: can't re-use a leaf (squelch_level)! > > These are from ndis and mean that your driver is trying to register > multiple nodes of the same name. ndis is the only one that I know > that does this repeatably. Hmm, I do not use ndis. Ihsan... -- ihsan@dogan.ch http://ihsan.dogan.ch/ --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; 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-BETA1 #17: Tue Jul 19 16:07:08 CEST 2005 root@makar:/usr/obj/usr/src/sys/MAKAR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.80GHz (1794.18-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 1073086464 (1023 MB) avail memory = 1041207296 (992 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f 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 0x1820-0x183f 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 0x1840-0x185f 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 0xc0000000-0xc00003ff 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 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 em0: port 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Ethernet address: 00:11:25:12:89:cb em0: Speed:N/A Duplex:N/A ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:05:4e:4e:02:01 ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x6000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding ppc0: port 0x3bc-0x3be irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1794184942 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:17: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 1D55D16A41F for ; Fri, 22 Jul 2005 10:17:39 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B30043D5D for ; Fri, 22 Jul 2005 10:17:27 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Dvuaq-0004sJ-Vk for freebsd-current@freebsd.org; Fri, 22 Jul 2005 13:17:24 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jul 2005 13:17:24 +0300 From: Danny Braniss Message-ID: Subject: 6.0-BETA1/serial-console X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 10:17:39 -0000 this problem is not unique to 6.0, but since changes are happening with tty/kb etc, i thougth it good idea to mention the problem: if BIOS has serial port DISBABLED and /etc/ttys has ttyd0 on, this will HANG the system as soon as init goes multiuser. the hang is solid, so that BREAK/esc-to-debugger does not works. danny From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:28: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 8AC9216A421; Fri, 22 Jul 2005 10:28:35 +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 F409F43D60; Fri, 22 Jul 2005 10:28:20 +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 j6MASJfB096806; Fri, 22 Jul 2005 03:28:19 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6MASJS5096805; Fri, 22 Jul 2005 03:28:19 -0700 (PDT) (envelope-from rizzo) Date: Fri, 22 Jul 2005 03:28:19 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20050722032819.G95489@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: which lock protects sysctl instances ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 10:28:35 -0000 hi, is there any protection in RELENG_5 and above for multiple sysctl handlers ? In other words, assume i have SYSCTL_PROC(_kern, OID_AUTO, foo, CTLTYPE_STRING|CTLFLAG_RW, 0, 0, sysctl_foo_handler, "A", "bla bla bla"); do i have to worry about multiple instances of sysctl_foo_handler() running in parallel, or they run under Giant, or some other lock ? thanks luigi From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:35: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 46D3A16A423; Fri, 22 Jul 2005 10:35:03 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94FDC43D45; Fri, 22 Jul 2005 10:35:02 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j6MAYoV5058562; Fri, 22 Jul 2005 12:34:50 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Sam Leffler In-Reply-To: <42E07DE8.9000804@errno.com> References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> <1121855884.796.8.camel@genius1.i.cz> <42E07DE8.9000804@errno.com> Content-Type: text/plain; charset=ISO-8859-2 Date: Fri, 22 Jul 2005 12:34:48 +0200 Message-Id: <1122028488.1260.0.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Robert Watson , current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 10:35:03 -0000 Sam Leffler pí¹e v èt 21. 07. 2005 v 22:02 -0700: > Michal Mertl wrote: > > Sam Leffler wrote: > > > >>Michal Mertl wrote: > >> > >>>Robert Watson wrote: > >>> > >>> > >>>>I fairly regularly use 802.11 adhoc with WEP to communicate between my > >>>>6.x/7.x FreeBSD notebook using if_wi, and my Apple PowerBook running Mac > >>>>OS X Tiger. A few days ago, when I updated from a June to a July HEAD > >>>>revision, this became quite "fragile". Specifically, I often find that > >>>>the Mac can't send to the FreeBSD box (ARP fails, etc), and that sometimes > >>>>it will give an error when I ask it to re-connect to the ad hoc network. > >>>>I find that if I ifconfig down/up if_wi, and likewise turn off and on the > >>>>wireless on the PowerBook, it seems to recover. I've not had a chance to > >>>>really try and diagnose this at all -- i.e., does tcpdump show packets on > >>>>either end, 802.11 state machine, etc. I was wondering if anyone else has > >>>>seen this problem, though. > >>> > >>> > >>>Yes, I'm also experiencing similar problems. The problems seem to happen > >>>also with different wireless cards and without wep. They were reported > >>>by Johann Hugo on 14th in an email titled "ath hostap - clients > >>>assosiated, but no comms" too. > >>> > >>>Another problem with WiFi which Johann reported long time ago is that > >>>bridging on atheros (only?) AP works really bad. I get very varying ping > >>>response (50 - inf. ms). Sometimes it seems the packets get queued > >>>somewhere - after some time I receive several replies at once. > >> > >>I routinely bridge ath cards (a wide variety) with bge using bridge and > >>see no problems. I get ~36 Mb/s in 11a w/ superg features and ~28 Mb/s > >>w/ basic stuff (what you find in RELENG_6). ping times are what you'd > >>expect (<1ms). > > > > > > I'm sorry, I was too brief in the description of the problem. It's the > > bridging on the card which works slow. > > > > I run an ath card in hostap mode and several wireless clients connect to > > it and are on the same IP network. The ping from one client to another > > is slow yet both ping the AP fine. I think that in this situation the > > bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. > > Should be fixed by ieee80211_input.c rev 1.63. > > Sam Yes, the (ap)bridging works now. Thank you so much. Michal From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:36: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 0C67316A428 for ; Fri, 22 Jul 2005 10:36:26 +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 8996443D7F for ; Fri, 22 Jul 2005 10:35:30 +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 07AC146B81; Fri, 22 Jul 2005 06:35:30 -0400 (EDT) Date: Fri, 22 Jul 2005 11:36:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20050722032819.G95489@xorpc.icir.org> Message-ID: <20050722113157.H16902@fledge.watson.org> References: <20050722032819.G95489@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: which lock protects sysctl instances ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 10:36:26 -0000 On Fri, 22 Jul 2005, Luigi Rizzo wrote: > is there any protection in RELENG_5 and above for multiple sysctl > handlers ? > > In other words, assume i have SYSCTL_PROC(_kern, OID_AUTO, foo, > CTLTYPE_STRING|CTLFLAG_RW, > 0, 0, sysctl_foo_handler, "A", "bla bla bla"); > > do i have to worry about multiple instances of sysctl_foo_handler() > running in parallel, or they run under Giant, or some other lock ? Right now, all sysctl handlers are run with Giant. In addition to giant, there are sleep locks in sysctl to protect the sysctl infrastructure. Any further synchronization has to be done by the handler itself. So, for example, you'll see that the process-related handlers all acquire the necessary process locks to operate successfully; likewise network monitoring sysctls, and so on. Right now many sysctl handlers assume that Giant will be held on entry; this is an assumption that we should be reducing or gradually removing. As a general rule, if your sysctl handler interacts with an MPSAFE part of the system, it will need to acquire locks anyway, because those parts of the system well be running in another thread on another CPU but without Giant, so unimpeded. I think we need someone to pick up sysctl again as an owner and start to fix this up -- it's not pressing since it's hardly a performance-critical path for most systems, but it's an area where cleanliness is a good thing. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 10:45: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 1A61D16A4D7; Fri, 22 Jul 2005 10:45:50 +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 BEB4943D78; Fri, 22 Jul 2005 10:45:20 +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 1Dvv19-0004Ub-Nx; Fri, 22 Jul 2005 12:44:36 +0200 Date: Fri, 22 Jul 2005 12:44:49 +0200 From: Marcin Jessa To: FreeBSD-Current , FreeBSD-net Message-Id: <20050722124449.33f23cb9.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0beta6 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: Subject: issue with atheros and channel selection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 10:45:50 -0000 Hi guys. When you ifconfig athX channel XX it works fine But when you then want to change that to ifconfig athX channel any (or '-' or '0') the old channel number does not change. The number then can be changed only to a different numeric value. Cheers, Marcin Jessa From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 11:04: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 0B01216A433; Fri, 22 Jul 2005 11:04:48 +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 438B643D91; Fri, 22 Jul 2005 11:04:38 +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 62B0B60FE; Fri, 22 Jul 2005 13:04:33 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 449A360F1; Fri, 22 Jul 2005 13:04:33 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 205A533CE6; Fri, 22 Jul 2005 13:04:33 +0200 (CEST) To: Robert Watson References: <20050721134816.GA8550@nagual.pp.ru> <20050722011556.T16902@fledge.watson.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 22 Jul 2005 13:04:33 +0200 In-Reply-To: <20050722011556.T16902@fledge.watson.org> (Robert Watson's message of "Fri, 22 Jul 2005 01:17:52 +0100 (BST)") Message-ID: <861x5rqeym.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-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: wpaul@ctr.columbia.edu, current@freebsd.org Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 11:04:48 -0000 Robert Watson writes: > I can't speak to the specifics of the driver, as I neither use it nor > have any if_rl hardware. However, you should know that because > debug.mpsafenet=3D0 also changes quite a bit of timing, not just lock > coverage, it's not necessarily a locking problem. Out of curiousity, > if you take "options PREEMPTION" out, but leave debug.mpsafenet=3D1, do > things change? I have a box with rl hardware and mpsafenet enabled. No problems so far, but it's not under heavy load. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 11:16: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 7B25916A439 for ; Fri, 22 Jul 2005 11:16:30 +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 AD48E43D82 for ; Fri, 22 Jul 2005 11:16:11 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd18.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1DvvVh-0005R0-01; Fri, 22 Jul 2005 13:16:09 +0200 Received: from Andro-Beta.Leidinger.net (JbQYZcZlre73lTOMckeadOTcgEKC2mqYLqF1tiTWNVDJu3heorg46M@[84.165.254.175]) by fwd18.sul.t-online.de with esmtp id 1DvvVO-1EvqLY0; Fri, 22 Jul 2005 13:15:50 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6MBFmZp055910; Fri, 22 Jul 2005 13:15:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.31 ([141.113.101.31]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Fri, 22 Jul 2005 13:15:47 +0200 Message-ID: <20050722131547.ky38qvl340osc04c@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 22 Jul 2005 13:15:47 +0200 From: Alexander Leidinger To: Kevin Oberman References: <20050721183852.074415D07@ptavv.es.net> In-Reply-To: <20050721183852.074415D07@ptavv.es.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: JbQYZcZlre73lTOMckeadOTcgEKC2mqYLqF1tiTWNVDJu3heorg46M@t-dialin.net X-TOI-MSGID: ed1f9f36-6f8c-43bf-90e0-fd3f9862ad6b Cc: freebsd-current@freebsd.org Subject: Re: More wi odd behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 11:16:30 -0000 Kevin Oberman wrote: > In any case, my stream locked up and I saw the following: > # ifconfig wi0 > wi0: flags=8943 mtu 1500 > inet6 fe80::205:3cff:fe03:86b9%wi0 prefixlen 64 scopeid 0x3 > inet 142.231.19.178 netmask 0xfffffe00 broadcast 142.231.19.255 > ether 00:05:3c:03:86:b9 > # wicontrol > wicontrol: SIOCGWAVELAN: Operation not supported by device > # dhclient wi0 > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device > wi0: not found > exiting. I've seen the same some (~ 2-3) weeks ago. But without a PROMISC setting. I was only transfering a 150MB file with scp. It wasn't successfully transfered. I switched to rsync and after some attempts I had the file on my laptop. I hadn't time to look at it further. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 In charity there is no excess. -- Francis Bacon From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:10: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 1D0A416A43D for ; Fri, 22 Jul 2005 12:10:53 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BABC743D6E for ; Fri, 22 Jul 2005 12:10:39 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail invoked by alias); 22 Jul 2005 12:10:37 -0000 Received: from unknown (EHLO klamath) [212.204.44.203] by mail.gmx.net (mp015) with SMTP; 22 Jul 2005 14:10:37 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rJUE0b8oRrFc2pXH4Hs3" Date: Fri, 22 Jul 2005 14:10:30 +0200 Message-Id: <1122034231.973.7.camel@klamath.syndrom23.de> Mime-Version: 1.0 X-Mailer: Evolution 2.3.5.1 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 Subject: kmem_map too small panic in kmem_malloc, related to ACLs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 12:10:53 -0000 --=-rJUE0b8oRrFc2pXH4Hs3 Content-Type: multipart/mixed; boundary="=-inI4g/3K4fiOkeUMf+AC" --=-inI4g/3K4fiOkeUMf+AC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I got a reproducible panic=20 panic: kmem_malloc(943013888): kmem_map too small: xxxx total allocated (943... is constant, xxx varies) when doing a rm -f * in /tmp as user. Looking at the backtraces, it looks like this may be related to ACLs active on /tmp.=20 /dev/vol/tmp on /tmp (ufs, local, soft-updates, acls) Also interesting to note: both panics referred to the same file in=20 kern_unlink, so I tried to do ls -al oracle1.jpg...and it panicked again. I don't have the dump for this one, my /var/crash was full. The system is FreeBSD klamath.syndrom23.de 7.0-CURRENT FreeBSD 7.0-CURRENT #11: Wed Jul 20 20:13:51 CEST 2005 root@klamath.syndrom23.de:/usr/obj/usr/src/sys/KLAMATH i386 Kernel config contains SCHED_ULE, PREEMPTION, no INVARIANTS/WITNESS, and is= =20 attached. Backtraces from the first rm -f attempts are attached, please let me know if you would like me to retrieve any additional information. Best regards, Andreas --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=-inI4g/3K4fiOkeUMf+AC Content-Disposition: inline; filename=crash-tmp-acl-1 Content-Type: application/octet-stream; name=crash-tmp-acl-1 Content-Transfer-Encoding: base64 IzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE2NQoJaW4gcGNwdS5oCihrZ2RiKSAjMCAgZG9hZHVt cCAoKSBhdCBwY3B1Lmg6MTY1Ck5vIGxvY2Fscy4KIzEgIDB4YzA1MjhiMzYgaW4gYm9vdCAoaG93 dG89MjYwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6Mzk3CglmaXJzdF9i dWZfcHJpbnRmID0gMQojMiAgMHhjMDUyOTE0ZiBpbiBwYW5pYyAoCiAgICBmbXQ9MHhjMDcxNzdi YSAia21lbV9tYWxsb2MoJWxkKToga21lbV9tYXAgdG9vIHNtYWxsOiAlbGQgdG90YWwgYWxsb2Nh dGVkIikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NTMKCWJvb3Rv cHQgPSAyNjAKCW5ld3BhbmljID0gMAoJYnVmID0gImttZW1fbWFsbG9jKDk0MzAxMzg4OCk6IGtt ZW1fbWFwIHRvbyBzbWFsbDogNDU0NDEwMjQgdG90YWwgYWxsb2NhdGVkIiwgJ1wwJyA8cmVwZWF0 cyAxODcgdGltZXM+CiMzICAweGMwNjhlY2FlIGluIGttZW1fbWFsbG9jIChtYXA9MHhjMTQ0MzBj MCwgc2l6ZT05NDMwMTM4ODgsIGZsYWdzPTIpCiAgICBhdCAvdXNyL3NyYy9zeXMvdm0vdm1fa2Vy bi5jOjI5OQoJb2Zmc2V0ID0gMzMwMTQ5MTg3MgoJaSA9IDk0MzAxMzg4OAoJZW50cnkgPSAweGMx NDRlMGEwCglhZGRyID0gMzI1NjY4MDQ0OAoJbSA9IDB4YzJlMGJiNDAKCXBmbGFncyA9IC0xMDUy NDUzMDQ4CiM0ICAweGMwNjg2ZGI3IGluIHVtYV9sYXJnZV9tYWxsb2MgKHNpemU9OTQzMDEzODg4 LCB3YWl0PTIpCiAgICBhdCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjk4CgltZW0gPSAo dm9pZCAqKSAweDIKCXNsYWIgPSAweGMyZTBiYjQwCglmbGFncyA9IDIgJ1wwMDInCiM1ICAweGMw NTFiYmZkIGluIG1hbGxvYyAoc2l6ZT0wLCBtdHA9MHhjMDczNDFjMCwgZmxhZ3M9MikKICAgIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbWFsbG9jLmM6MzI0CglpbmR4ID0gOTQzMDEzODg4Cgl2 YSA9IDB4ZTY0YzI4ZDAgIqBCdcBcMjAwXDIzMFHEXDAwMiIKCXpvbmUgPSAweDAKCWtlZyA9IDB4 MAojNiAgMHhjMDY3MTg5NSBpbiBmZnNfb3Blbl9lYSAodnA9MHhjNDUxOTg4MCwgY3JlZD0weDAs IHRkPTB4MCkKICAgIGF0IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192bm9wcy5jOjExMzcKCWx1 aW8gPSB7dWlvX2lvdiA9IDB4YzA3MTYyY2QsIHVpb19pb3ZjbnQgPSAxLCB1aW9fb2Zmc2V0ID0g MCwgCiAgdWlvX3Jlc2lkID0gMTgsIHVpb19zZWdmbGcgPSBVSU9fU1lTU1BBQ0UsIHVpb19ydyA9 IFVJT19SRUFELCAKICB1aW9fdGQgPSAweGMyOWQ0YzgwfQoJbGlvdmVjID0ge2lvdl9iYXNlID0g MHhlNjRjMjg2OCwgaW92X2xlbiA9IDMyMjc5ODE2NzN9CgllYXNpemUgPSA5NDMwMTA2MTAKCWVh ZSA9ICh1X2NoYXIgKikgMHhjNGM4YzRhMCAiIgoJaXAgPSAoc3RydWN0IGlub2RlICopIDB4YzMx Zjg0MjAKCWRwID0gKHN0cnVjdCB1ZnMyX2Rpbm9kZSAqKSAweGMzNmQ3MjAwCiM3ICAweGMwNjcy NjM1IGluIGZmc19nZXRleHRhdHRyIChhcD0weGU2NGMyOGQwKQogICAgYXQgL3Vzci9zcmMvc3lz L3Vmcy9mZnMvZmZzX3Zub3BzLmM6MTQyMwoJaXAgPSAoc3RydWN0IGlub2RlICopIDB4YzMxZjg0 MjAKCXAgPSAodV9jaGFyICopIDB4YzA1OWVkNGQgIlwyMDXAXDIxMcF1XDAxNlwyMDC+rCIKCWVh c2l6ZSA9IDAKCWVycm9yID0gNDA5NgoJZWFsZW4gPSAwCglzdGFuZF9hbG9uZSA9IDAKIzggIDB4 YzA2ZThmNmEgaW4gVk9QX0dFVEVYVEFUVFJfQVBWICh2b3A9MHgwLCBhPTB4MCkgYXQgdm5vZGVf aWYuYzoyNDMxCglyYyA9IDAKIzkgIDB4YzA1YTBkYTggaW4gdm5fZXh0YXR0cl9nZXQgKHZwPTB4 YzQ1MTk4ODAsIGlvZmxnPTAsIGF0dHJuYW1lc3BhY2U9MCwgCiAgICBhdHRybmFtZT0weDAsIGJ1 Zmxlbj0weGU2NGMyOTQwLCBidWY9MHgwLCB0ZD0weGMyOWQ0YzgwKSBhdCB2bm9kZV9pZi5oOjEy ODIKCWF1aW8gPSB7dWlvX2lvdiA9IDB4ZTY0YzI4YjgsIHVpb19pb3ZjbnQgPSAxLCB1aW9fb2Zm c2V0ID0gMCwgCiAgdWlvX3Jlc2lkID0gMzg4LCB1aW9fc2VnZmxnID0gVUlPX1NZU1NQQUNFLCB1 aW9fcncgPSBVSU9fUkVBRCwgCiAgdWlvX3RkID0gMHhjMjlkNGM4MH0KCWlvdiA9IHtpb3ZfYmFz ZSA9IDB4YzQ3Y2I4MDAsIGlvdl9sZW4gPSAzODh9CgllcnJvciA9IDQwOTYKIzEwIDB4YzA2NzJk OWEgaW4gdWZzX2dldGFjbCAoYXA9MHhlNjRjMjk4OCkKICAgIGF0IC91c3Ivc3JjL3N5cy91ZnMv dWZzL3Vmc19hY2wuYzoxODMKCWlwID0gKHN0cnVjdCBpbm9kZSAqKSAweGMzMWY4NDIwCgllcnJv ciA9IDQwOTYKCWxlbiA9IDM4OAojMTEgMHhjMDZlOGRlYSBpbiBWT1BfR0VUQUNMX0FQViAodm9w PTB4MCwgYT0weDApIGF0IHZub2RlX2lmLmM6MjIxOAoJcmMgPSAwCiMxMiAweGMwNjdhN2FlIGlu IHVmc19hY2Nlc3MgKGFwPTB4ZTY0YzJhNDQpIGF0IHZub2RlX2lmLmg6MTE1MQoJYSA9IHthX2dl biA9IHthX2Rlc2MgPSAweGMwNzU0M2EwfSwgYV92cCA9IDB4YzQ1MTk4ODAsIGFfdHlwZSA9IDAs IAogIGFfYWNscCA9IDB4YzQ3Y2I4MDAsIGFfY3JlZCA9IDB4YzI1ZDgyMDAsIGFfdGQgPSAweGMy OWQ0YzgwfQoJdnAgPSAoc3RydWN0IHZub2RlICopIDB4YzQ1MTk4ODAKCWlwID0gKHN0cnVjdCBp bm9kZSAqKSAweGMzMWY4NDIwCgltb2RlID0gNDA5NgoJZXJyb3IgPSA0MDk2CglhY2wgPSAoc3Ry dWN0IGFjbCAqKSAweGM0N2NiODAwCiMxMyAweGMwNmU4NmQ2IGluIFZPUF9BQ0NFU1NfQVBWICh2 b3A9MHgwLCBhPTB4MCkgYXQgdm5vZGVfaWYuYzo0ODAKCXJjID0gMAojMTQgMHhjMDY3NzRkYSBp biB1ZnNfbG9va3VwIChhcD0weGU2NGMyYWQ4KSBhdCB2bm9kZV9pZi5oOjI1NgoJdmRwID0gKHN0 cnVjdCB2bm9kZSAqKSAweGMyNTI3NTUwCglkcCA9IChzdHJ1Y3QgaW5vZGUgKikgMHhjMjRiY2I1 OAoJYnAgPSAoc3RydWN0IGJ1ZiAqKSAweGQxYWE0NzAwCgllcCA9IChzdHJ1Y3QgZGlyZWN0ICop IDB4ZDQyOGVjZDQKCWVudHJ5b2Zmc2V0aW5ibG9jayA9IDAKCXNsb3RzdGF0dXMgPSBGT1VORAoJ c2xvdG9mZnNldCA9IC0xCglzbG90c2l6ZSA9IDAKCXNsb3RmcmVlc3BhY2UgPSAwCglzbG90bmVl ZGVkID0gMAoJbnVtZGlycGFzc2VzID0gMQoJZW5kc2VhcmNoID0gMAoJcHJldm9mZiA9IDMyNjQK CXRkcCA9IChzdHJ1Y3Qgdm5vZGUgKikgMHhjNDUxOTg4MAoJZW5kdXNlZnVsID0gNTUyOTYKCWJt YXNrID0gMTYzODMKCW5hbWxlbiA9IDAKCWVycm9yID0gLTczNTUxNTQzNgoJdnBwID0gKHN0cnVj dCB2bm9kZSAqKikgMHhlNjRjMmM3MAoJY25wID0gKHN0cnVjdCBjb21wb25lbnRuYW1lICopIDB4 ZTY0YzJjODQKCWNyZWQgPSAoc3RydWN0IHVjcmVkICopIDB4YzI1ZDgyMDAKCWZsYWdzID0gMTY4 MDk5OTYKCW5hbWVpb3AgPSAyCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzI5ZDRjODAKIzE1 IDB4YzA2ZTg1OTYgaW4gVk9QX0NBQ0hFRExPT0tVUF9BUFYgKHZvcD0weDAsIGE9MHgwKSBhdCB2 bm9kZV9pZi5jOjE1MAoJcmMgPSAwCiMxNiAweGMwNTgzYTlkIGluIHZmc19jYWNoZV9sb29rdXAg KGFwPTB4MCkgYXQgdm5vZGVfaWYuaDo4MgoJZHZwID0gKHN0cnVjdCB2bm9kZSAqKSAweGMyNTI3 NTUwCgllcnJvciA9IDAKCXZwcCA9IChzdHJ1Y3Qgdm5vZGUgKiopIDB4ZTY0YzJjNzAKCWNucCA9 IChzdHJ1Y3QgY29tcG9uZW50bmFtZSAqKSAweGU2NGMyYzg0CgljcmVkID0gKHN0cnVjdCB1Y3Jl ZCAqKSAweGMyNWQ4MjAwCglmbGFncyA9IDAKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjlk NGM4MAojMTcgMHhjMDZlOTFjYiBpbiBWT1BfTE9PS1VQX0FQViAodm9wPTB4YzA3NDcyZTAsIGE9 MHhlNjRjMmI4NCkKICAgIGF0IHZub2RlX2lmLmM6OTkKCXJjID0gLTEwNjYxMTAyNDAKIzE4IDB4 YzA1ODg0NWEgaW4gbG9va3VwIChuZHA9MHhlNjRjMmM1YykgYXQgdm5vZGVfaWYuaDo1NgoJX2xv Y2tlZCA9IDAKCWNwID0gMHhjMjQ4ZjQwYiAiIgoJZHAgPSAoc3RydWN0IHZub2RlICopIDB4YzI1 Mjc1NTAKCXRkcCA9IChzdHJ1Y3Qgdm5vZGUgKikgMHhjMDU4ZjkwYwoJbXAgPSAoc3RydWN0IG1v dW50ICopIDB4YzI1Mjc1NTAKCWRvY2FjaGUgPSAwCgl3YW50cGFyZW50ID0gOAoJcmRvbmx5ID0g MAoJdHJhaWxpbmdfc2xhc2ggPSAwCgllcnJvciA9IC00MzEyMTU1MjQKCWRwdW5sb2NrZWQgPSAw CgljbnAgPSAoc3RydWN0IGNvbXBvbmVudG5hbWUgKikgMHhlNjRjMmM4NAoJdGQgPSAoc3RydWN0 IHRocmVhZCAqKSAweGMyOWQ0YzgwCgl2ZnNsb2NrZWQgPSAwCgl0dmZzbG9ja2VkID0gLTQzMTIx NTUyNAojMTkgMHhjMDU4OGYwZiBpbiBuYW1laSAobmRwPTB4ZTY0YzJjNWMpIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19sb29rdXAuYzoyMDEKCV9sb2NrZWQgPSAwCglmZHAgPSAoc3RydWN0IGZp bGVkZXNjICopIDB4MAoJY3AgPSAweDAKCWRwID0gKHN0cnVjdCB2bm9kZSAqKSAweGMyNTI3NTUw CglhaW92ID0ge2lvdl9iYXNlID0gMHhjMmI1MjQwMCwgaW92X2xlbiA9IDMyNjY2NTExMzZ9Cglh dWlvID0ge3Vpb19pb3YgPSAweDFmOSwgdWlvX2lvdmNudCA9IDk4NzI0LCB1aW9fb2Zmc2V0ID0g MTAwMSwgCiAgdWlvX3Jlc2lkID0gNDU1MTIsIHVpb19zZWdmbGcgPSAxMTE1MDUxOTYzLCB1aW9f cncgPSBVSU9fUkVBRCwgCiAgdWlvX3RkID0gMHg0MDY4ODllZn0KCWVycm9yID0gLTEwMzQ3ODM0 MDgKCWxpbmtsZW4gPSAtMTAzNDc4MzQwOAoJY25wID0gKHN0cnVjdCBjb21wb25lbnRuYW1lICop IDB4ZTY0YzJjODQKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjlkNGM4MAoJcCA9IChzdHJ1 Y3QgcHJvYyAqKSAweDAKCXZmc2xvY2tlZCA9IDAKIzIwIDB4YzA1OTg3MzkgaW4ga2Vybl91bmxp bmsgKHRkPTB4YzI5ZDRjODAsIAogICAgcGF0aD0weGJmYmZlMzJmIDxBZGRyZXNzIDB4YmZiZmUz MmYgb3V0IG9mIGJvdW5kcz4sIHBhdGhzZWc9VUlPX1VTRVJTUEFDRSkKICAgIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjE2MzcKCW1wID0gKHN0cnVjdCBtb3VudCAqKSAweDAK CXZwID0gKHN0cnVjdCB2bm9kZSAqKSAweGJmYmZjOTUwCgllcnJvciA9IC0xMDI4NzUwODM2Cglu ZCA9IHtuaV9kaXJwID0gMHhiZmJmZTMyZiA8QWRkcmVzcyAweGJmYmZlMzJmIG91dCBvZiBib3Vu ZHM+LCAKICBuaV9zZWdmbGcgPSBVSU9fVVNFUlNQQUNFLCBuaV9zdGFydGRpciA9IDB4MCwgbmlf cm9vdGRpciA9IDB4YzI0OGRiYjAsIAogIG5pX3RvcGRpciA9IDB4MCwgbmlfdnAgPSAweDAsIG5p X2R2cCA9IDB4YzI1Mjc1NTAsIG5pX3BhdGhsZW4gPSAxLCAKICBuaV9uZXh0ID0gMHhjMjQ4ZjQw YiAiIiwgbmlfbG9vcGNudCA9IDAsIG5pX2NuZCA9IHtjbl9uYW1laW9wID0gMiwgCiAgICBjbl9m bGFncyA9IDE2ODA5OTk2LCBjbl90aHJlYWQgPSAweGMyOWQ0YzgwLCBjbl9jcmVkID0gMHhjMjVk ODIwMCwgCiAgICBjbl9sa2ZsYWdzID0gMiwgY25fcG5idWYgPSAweGMyNDhmNDAwICJvcmFjbGUx LmpwZyIsIAogICAgY25fbmFtZXB0ciA9IDB4YzI0OGY0MDAgIm9yYWNsZTEuanBnIiwgY25fbmFt ZWxlbiA9IDExLCBjbl9jb25zdW1lID0gMH19Cgl2ZnNsb2NrZWQgPSAtMTAyOTg3ODY1NgojMjEg MHhjMDU5ODkyMiBpbiB1bmxpbmsgKHRkPTB4MCwgdWFwPTB4MCkKICAgIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19zeXNjYWxscy5jOjE2MjEKCWVycm9yID0gMAojMjIgMHhjMDZkNzEyMCBpbiBz eXNjYWxsIChmcmFtZT0KICAgICAge3RmX2ZzID0gNTksIHRmX2VzID0gNTksIHRmX2RzID0gNTks IHRmX2VkaSA9IC0xMDc3OTQ4NTA0LCB0Zl9lc2kgPSAwLCB0Zl9lYnAgPSAtMTA3Nzk0OTk5Miwg dGZfaXNwID0gLTQzMTIxNTI2MCwgdGZfZWJ4ID0gLTEwNzc5NDM1MDUsIHRmX2VkeCA9IDk4NzI0 LCB0Zl9lY3ggPSAxMCwgdGZfZWF4ID0gMTAsIHRmX3RyYXBubyA9IDAsIHRmX2VyciA9IDIsIHRm X2VpcCA9IDEzNDY5NzM1MSwgdGZfY3MgPSA1MSwgdGZfZWZsYWdzID0gNTgyLCB0Zl9lc3AgPSAt MTA3Nzk1MDEzMiwgdGZfc3MgPSA1OX0pCiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3Ry YXAuYzo5ODYKCXBhcmFtcyA9IDB4YmZiZmM5NTAgPEFkZHJlc3MgMHhiZmJmYzk1MCBvdXQgb2Yg Ym91bmRzPgoJY2FsbHAgPSAoc3RydWN0IHN5c2VudCAqKSAweGMwNzMxMTE4CglwID0gKHN0cnVj dCBwcm9jICopIDB4YzJhZTgyMGMKCW9yaWdfdGZfZWZsYWdzID0gNTgyCglzdGlja3MgPSAxCgll cnJvciA9IDAKCW5hcmcgPSAxCglhcmdzID0gey0xMDc3OTQzNTA1LCAtMTA3Nzk1MDExMiwgMSwg LTQzMTIxNTMxNiwgLTEwNjY1NTg2NDYsIAogIC0xMDY2MDYzOTA0LCAtNDMxMjE1MzA4LCAxMzQ5 NjM4MTV9Cgljb2RlID0gMTAKIzIzIDB4YzA2YzdjY2YgaW4gWGludDB4ODBfc3lzY2FsbCAoKSBh dCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjIwMApObyBsb2NhbHMuCiMyNCAw eDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI1IDB4 MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjYgMHgw MDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNyAweGJm YmZjZmE4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI4IDB4MDAw MDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjkgMHhiZmJm YzlkOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMCAweGU2NGMy ZDY0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMxIDB4YmZiZmUz MmYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzIgMHgwMDAxODFh NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMyAweDAwMDAwMDBh IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM0IDB4MDAwMDAwMGEg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzUgMHgwMDAwMDAwMCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNiAweDAwMDAwMDAyIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM3IDB4MDgwNzUxODcgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzggMHgwMDAwMDAzMyBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOSAweDAwMDAwMjQ2IGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQwIDB4YmZiZmM5NGMgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDEgMHgwMDAwMDAzYiBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MiAweDczMjA3NDZmIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQzIDB4MjA3MDZmNzQgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDQgMHg2YzY5NjE2YSBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0NSAweDVmODE4MjIwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQ2IDB4MWU2NTMwMDAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDcgMHhjMjlkNGRkNCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0OCAweGMyNjBjMzIwIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQ5IDB4ZTY0YzJhNzAgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNTAgMHhlNjRjMmE1OCBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM1MSAweGMyOWQ0YzgwIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzUyIDB4YzA1M2UwODggaW4gc2NoZWRfc3dpdGNoICh0 ZD0weGJmYmZlMzJmLCBuZXd0ZD0weDAsIGZsYWdzPSkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjEzNzcKCWtlID0gKHN0cnVjdCB0ZF9zY2hlZCAqKSAweGJmYmZjZmE4Cihr Z2RiKSA= --=-inI4g/3K4fiOkeUMf+AC Content-Disposition: inline; filename=crash-tmp-acl-2 Content-Type: application/octet-stream; name=crash-tmp-acl-2 Content-Transfer-Encoding: base64 IzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE2NQoJaW4gcGNwdS5oCihrZ2RiKSAjMCAgZG9hZHVt cCAoKSBhdCBwY3B1Lmg6MTY1Ck5vIGxvY2Fscy4KIzEgIDB4YzA1MjhiMzYgaW4gYm9vdCAoaG93 dG89MjYwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6Mzk3CglmaXJzdF9i dWZfcHJpbnRmID0gMQojMiAgMHhjMDUyOTE0ZiBpbiBwYW5pYyAoCiAgICBmbXQ9MHhjMDcxNzdi YSAia21lbV9tYWxsb2MoJWxkKToga21lbV9tYXAgdG9vIHNtYWxsOiAlbGQgdG90YWwgYWxsb2Nh dGVkIikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NTMKCWJvb3Rv cHQgPSAyNjAKCW5ld3BhbmljID0gMAoJYnVmID0gImttZW1fbWFsbG9jKDk0MzAxMzg4OCk6IGtt ZW1fbWFwIHRvbyBzbWFsbDogMTk0OTI4NjQgdG90YWwgYWxsb2NhdGVkIiwgJ1wwJyA8cmVwZWF0 cyAxODcgdGltZXM+CiMzICAweGMwNjhlY2FlIGluIGttZW1fbWFsbG9jIChtYXA9MHhjMTQ0MzBj MCwgc2l6ZT05NDMwMTM4ODgsIGZsYWdzPTIpCiAgICBhdCAvdXNyL3NyYy9zeXMvdm0vdm1fa2Vy bi5jOjI5OQoJb2Zmc2V0ID0gMzI1OTQwNjgwMAoJaSA9IDk0MzAxMzg4OAoJZW50cnkgPSAweGMx NDRlMGEwCglhZGRyID0gMzI1NjY4MDQ0OAoJbSA9IDB4YzI0ZDYwNDAKCXBmbGFncyA9IC0xMDUy NDUzMDQ4CiM0ICAweGMwNjg2ZGI3IGluIHVtYV9sYXJnZV9tYWxsb2MgKHNpemU9OTQzMDEzODg4 LCB3YWl0PTIpCiAgICBhdCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjk4CgltZW0gPSAo dm9pZCAqKSAweDIKCXNsYWIgPSAweGMyNGQ2MDQwCglmbGFncyA9IDIgJ1wwMDInCiM1ICAweGMw NTFiYmZkIGluIG1hbGxvYyAoc2l6ZT0wLCBtdHA9MHhjMDczNDFjMCwgZmxhZ3M9MikKICAgIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbWFsbG9jLmM6MzI0CglpbmR4ID0gOTQzMDEzODg4Cgl2 YSA9IDB4ZTY1Mjk4ZDAgIqBCdcBQVdnCXDAwMiIKCXpvbmUgPSAweDAKCWtlZyA9IDB4MAojNiAg MHhjMDY3MTg5NSBpbiBmZnNfb3Blbl9lYSAodnA9MHhjMmQ5NTU1MCwgY3JlZD0weDAsIHRkPTB4 MCkKICAgIGF0IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192bm9wcy5jOjExMzcKCWx1aW8gPSB7 dWlvX2lvdiA9IDB4YzA3MTYyY2QsIHVpb19pb3ZjbnQgPSAxLCB1aW9fb2Zmc2V0ID0gMCwgCiAg dWlvX3Jlc2lkID0gMTgsIHVpb19zZWdmbGcgPSBVSU9fU1lTU1BBQ0UsIHVpb19ydyA9IFVJT19S RUFELCAKICB1aW9fdGQgPSAweGMyMWVkYzgwfQoJbGlvdmVjID0ge2lvdl9iYXNlID0gMHhlNjUy OTg2OCwgaW92X2xlbiA9IDMyMjc5ODE2NzN9CgllYXNpemUgPSA5NDMwMTA2MTAKCWVhZSA9ICh1 X2NoYXIgKikgMHhjMjQ2OTlkMCAiXDIxMPRcMDAxIgoJaXAgPSAoc3RydWN0IGlub2RlICopIDB4 YzJkYmIzOWMKCWRwID0gKHN0cnVjdCB1ZnMyX2Rpbm9kZSAqKSAweGMyZGJjOTAwCiM3ICAweGMw NjcyNjM1IGluIGZmc19nZXRleHRhdHRyIChhcD0weGU2NTI5OGQwKQogICAgYXQgL3Vzci9zcmMv c3lzL3Vmcy9mZnMvZmZzX3Zub3BzLmM6MTQyMwoJaXAgPSAoc3RydWN0IGlub2RlICopIDB4YzJk YmIzOWMKCXAgPSAodV9jaGFyICopIDB4YzA1OWVkNGQgIlwyMDXAXDIxMcF1XDAxNlwyMDC+rCIK CWVhc2l6ZSA9IDAKCWVycm9yID0gNDA5NgoJZWFsZW4gPSAwCglzdGFuZF9hbG9uZSA9IDAKIzgg IDB4YzA2ZThmNmEgaW4gVk9QX0dFVEVYVEFUVFJfQVBWICh2b3A9MHgwLCBhPTB4MCkgYXQgdm5v ZGVfaWYuYzoyNDMxCglyYyA9IDAKIzkgIDB4YzA1YTBkYTggaW4gdm5fZXh0YXR0cl9nZXQgKHZw PTB4YzJkOTU1NTAsIGlvZmxnPTAsIGF0dHJuYW1lc3BhY2U9MCwgCiAgICBhdHRybmFtZT0weDAs IGJ1Zmxlbj0weGU2NTI5OTQwLCBidWY9MHgwLCB0ZD0weGMyMWVkYzgwKSBhdCB2bm9kZV9pZi5o OjEyODIKCWF1aW8gPSB7dWlvX2lvdiA9IDB4ZTY1Mjk4YjgsIHVpb19pb3ZjbnQgPSAxLCB1aW9f b2Zmc2V0ID0gMCwgCiAgdWlvX3Jlc2lkID0gMzg4LCB1aW9fc2VnZmxnID0gVUlPX1NZU1NQQUNF LCB1aW9fcncgPSBVSU9fUkVBRCwgCiAgdWlvX3RkID0gMHhjMjFlZGM4MH0KCWlvdiA9IHtpb3Zf YmFzZSA9IDB4YzMwZTc0MDAsIGlvdl9sZW4gPSAzODh9CgllcnJvciA9IDQwOTYKIzEwIDB4YzA2 NzJkOWEgaW4gdWZzX2dldGFjbCAoYXA9MHhlNjUyOTk4OCkKICAgIGF0IC91c3Ivc3JjL3N5cy91 ZnMvdWZzL3Vmc19hY2wuYzoxODMKCWlwID0gKHN0cnVjdCBpbm9kZSAqKSAweGMyZGJiMzljCgll cnJvciA9IDQwOTYKCWxlbiA9IDM4OAojMTEgMHhjMDZlOGRlYSBpbiBWT1BfR0VUQUNMX0FQViAo dm9wPTB4MCwgYT0weDApIGF0IHZub2RlX2lmLmM6MjIxOAoJcmMgPSAwCiMxMiAweGMwNjdhN2Fl IGluIHVmc19hY2Nlc3MgKGFwPTB4ZTY1MjlhNDQpIGF0IHZub2RlX2lmLmg6MTE1MQoJYSA9IHth X2dlbiA9IHthX2Rlc2MgPSAweGMwNzU0M2EwfSwgYV92cCA9IDB4YzJkOTU1NTAsIGFfdHlwZSA9 IDAsIAogIGFfYWNscCA9IDB4YzMwZTc0MDAsIGFfY3JlZCA9IDB4YzI1ZGEyODAsIGFfdGQgPSAw eGMyMWVkYzgwfQoJdnAgPSAoc3RydWN0IHZub2RlICopIDB4YzJkOTU1NTAKCWlwID0gKHN0cnVj dCBpbm9kZSAqKSAweGMyZGJiMzljCgltb2RlID0gNDA5NgoJZXJyb3IgPSA0MDk2CglhY2wgPSAo c3RydWN0IGFjbCAqKSAweGMzMGU3NDAwCiMxMyAweGMwNmU4NmQ2IGluIFZPUF9BQ0NFU1NfQVBW ICh2b3A9MHgwLCBhPTB4MCkgYXQgdm5vZGVfaWYuYzo0ODAKCXJjID0gMAojMTQgMHhjMDY3NzRk YSBpbiB1ZnNfbG9va3VwIChhcD0weGU2NTI5YWQ4KSBhdCB2bm9kZV9pZi5oOjI1NgoJdmRwID0g KHN0cnVjdCB2bm9kZSAqKSAweGMyNTI1NTUwCglkcCA9IChzdHJ1Y3QgaW5vZGUgKikgMHhjMjRi Y2I1OAoJYnAgPSAoc3RydWN0IGJ1ZiAqKSAweGQxYjNkNjMwCgllcCA9IChzdHJ1Y3QgZGlyZWN0 ICopIDB4ZDYwNjZjZDQKCWVudHJ5b2Zmc2V0aW5ibG9jayA9IDAKCXNsb3RzdGF0dXMgPSBGT1VO RAoJc2xvdG9mZnNldCA9IC0xCglzbG90c2l6ZSA9IDAKCXNsb3RmcmVlc3BhY2UgPSAwCglzbG90 bmVlZGVkID0gMAoJbnVtZGlycGFzc2VzID0gMQoJZW5kc2VhcmNoID0gMAoJcHJldm9mZiA9IDMy NjQKCXRkcCA9IChzdHJ1Y3Qgdm5vZGUgKikgMHhjMmQ5NTU1MAoJZW5kdXNlZnVsID0gNTUyOTYK CWJtYXNrID0gMTYzODMKCW5hbWxlbiA9IDAKCWVycm9yID0gLTcwNDIyMTk5NgoJdnBwID0gKHN0 cnVjdCB2bm9kZSAqKikgMHhlNjUyOWM3MAoJY25wID0gKHN0cnVjdCBjb21wb25lbnRuYW1lICop IDB4ZTY1MjljODQKCWNyZWQgPSAoc3RydWN0IHVjcmVkICopIDB4YzI1ZGEyODAKCWZsYWdzID0g MTY4MDk5OTYKCW5hbWVpb3AgPSAyCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIxZWRjODAK IzE1IDB4YzA2ZTg1OTYgaW4gVk9QX0NBQ0hFRExPT0tVUF9BUFYgKHZvcD0weDAsIGE9MHgwKSBh dCB2bm9kZV9pZi5jOjE1MAoJcmMgPSAwCiMxNiAweGMwNTgzYTlkIGluIHZmc19jYWNoZV9sb29r dXAgKGFwPTB4MCkgYXQgdm5vZGVfaWYuaDo4MgoJZHZwID0gKHN0cnVjdCB2bm9kZSAqKSAweGMy NTI1NTUwCgllcnJvciA9IDAKCXZwcCA9IChzdHJ1Y3Qgdm5vZGUgKiopIDB4ZTY1MjljNzAKCWNu cCA9IChzdHJ1Y3QgY29tcG9uZW50bmFtZSAqKSAweGU2NTI5Yzg0CgljcmVkID0gKHN0cnVjdCB1 Y3JlZCAqKSAweGMyNWRhMjgwCglmbGFncyA9IDAKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhj MjFlZGM4MAojMTcgMHhjMDZlOTFjYiBpbiBWT1BfTE9PS1VQX0FQViAodm9wPTB4YzA3NDcyZTAs IGE9MHhlNjUyOWI4NCkKICAgIGF0IHZub2RlX2lmLmM6OTkKCXJjID0gLTEwNjYxMTAyNDAKIzE4 IDB4YzA1ODg0NWEgaW4gbG9va3VwIChuZHA9MHhlNjUyOWM1YykgYXQgdm5vZGVfaWYuaDo1NgoJ X2xvY2tlZCA9IDAKCWNwID0gMHhjMjdiNWMwYiAiIgoJZHAgPSAoc3RydWN0IHZub2RlICopIDB4 YzI1MjU1NTAKCXRkcCA9IChzdHJ1Y3Qgdm5vZGUgKikgMHhjMDU4ZjkwYwoJbXAgPSAoc3RydWN0 IG1vdW50ICopIDB4YzI1MjU1NTAKCWRvY2FjaGUgPSAwCgl3YW50cGFyZW50ID0gOAoJcmRvbmx5 ID0gMAoJdHJhaWxpbmdfc2xhc2ggPSAwCgllcnJvciA9IC00MzA3OTM2MzYKCWRwdW5sb2NrZWQg PSAwCgljbnAgPSAoc3RydWN0IGNvbXBvbmVudG5hbWUgKikgMHhlNjUyOWM4NAoJdGQgPSAoc3Ry dWN0IHRocmVhZCAqKSAweGMyMWVkYzgwCgl2ZnNsb2NrZWQgPSAwCgl0dmZzbG9ja2VkID0gLTQz MDc5MzYzNgojMTkgMHhjMDU4OGYwZiBpbiBuYW1laSAobmRwPTB4ZTY1MjljNWMpIGF0IC91c3Iv c3JjL3N5cy9rZXJuL3Zmc19sb29rdXAuYzoyMDEKCV9sb2NrZWQgPSAwCglmZHAgPSAoc3RydWN0 IGZpbGVkZXNjICopIDB4MAoJY3AgPSAweDAKCWRwID0gKHN0cnVjdCB2bm9kZSAqKSAweGMyNTI1 NTUwCglhaW92ID0ge2lvdl9iYXNlID0gMHhjMjQ4ZjAwMCwgaW92X2xlbiA9IDMyNTk1NTk5MzZ9 CglhdWlvID0ge3Vpb19pb3YgPSAweDFmOSwgdWlvX2lvdmNudCA9IDk4NzI0LCB1aW9fb2Zmc2V0 ID0gMTAwMSwgCiAgdWlvX3Jlc2lkID0gNDU1MTIsIHVpb19zZWdmbGcgPSAxMTE1MDUxOTYzLCB1 aW9fcncgPSBVSU9fUkVBRCwgCiAgdWlvX3RkID0gMHg0MDY4ODllZn0KCWVycm9yID0gLTEwMzQ3 OTE2MDAKCWxpbmtsZW4gPSAtMTAzNDc5MTYwMAoJY25wID0gKHN0cnVjdCBjb21wb25lbnRuYW1l ICopIDB4ZTY1MjljODQKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjFlZGM4MAoJcCA9IChz dHJ1Y3QgcHJvYyAqKSAweDAKCXZmc2xvY2tlZCA9IDAKIzIwIDB4YzA1OTg3MzkgaW4ga2Vybl91 bmxpbmsgKHRkPTB4YzIxZWRjODAsIAogICAgcGF0aD0weGJmYmZlMzFlIDxBZGRyZXNzIDB4YmZi ZmUzMWUgb3V0IG9mIGJvdW5kcz4sIHBhdGhzZWc9VUlPX1VTRVJTUEFDRSkKICAgIGF0IC91c3Iv c3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjE2MzcKCW1wID0gKHN0cnVjdCBtb3VudCAqKSAw eDAKCXZwID0gKHN0cnVjdCB2bm9kZSAqKSAweGJmYmZjYjUwCgllcnJvciA9IC0xMDI0MDMwMTQ4 CgluZCA9IHtuaV9kaXJwID0gMHhiZmJmZTMxZSA8QWRkcmVzcyAweGJmYmZlMzFlIG91dCBvZiBi b3VuZHM+LCAKICBuaV9zZWdmbGcgPSBVSU9fVVNFUlNQQUNFLCBuaV9zdGFydGRpciA9IDB4MCwg bmlfcm9vdGRpciA9IDB4YzI0OGRiYjAsIAogIG5pX3RvcGRpciA9IDB4MCwgbmlfdnAgPSAweDAs IG5pX2R2cCA9IDB4YzI1MjU1NTAsIG5pX3BhdGhsZW4gPSAxLCAKICBuaV9uZXh0ID0gMHhjMjdi NWMwYiAiIiwgbmlfbG9vcGNudCA9IDAsIG5pX2NuZCA9IHtjbl9uYW1laW9wID0gMiwgCiAgICBj bl9mbGFncyA9IDE2ODA5OTk2LCBjbl90aHJlYWQgPSAweGMyMWVkYzgwLCBjbl9jcmVkID0gMHhj MjVkYTI4MCwgCiAgICBjbl9sa2ZsYWdzID0gMiwgY25fcG5idWYgPSAweGMyN2I1YzAwICJvcmFj bGUxLmpwZyIsIAogICAgY25fbmFtZXB0ciA9IDB4YzI3YjVjMDAgIm9yYWNsZTEuanBnIiwgY25f bmFtZWxlbiA9IDExLCBjbl9jb25zdW1lID0gMH19Cgl2ZnNsb2NrZWQgPSAtMTAzODE2NDg2NAoj MjEgMHhjMDU5ODkyMiBpbiB1bmxpbmsgKHRkPTB4MCwgdWFwPTB4MCkKICAgIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjE2MjEKCWVycm9yID0gMAojMjIgMHhjMDZkNzEyMCBp biBzeXNjYWxsIChmcmFtZT0KICAgICAge3RmX2ZzID0gNTksIHRmX2VzID0gNTksIHRmX2RzID0g NTksIHRmX2VkaSA9IC0xMDc3OTQ4MTE2LCB0Zl9lc2kgPSAwLCB0Zl9lYnAgPSAtMTA3Nzk0OTQ4 MCwgdGZfaXNwID0gLTQzMDc5MzM3MiwgdGZfZWJ4ID0gLTEwNzc5NDM1MjIsIHRmX2VkeCA9IDk4 NzI0LCB0Zl9lY3ggPSAxMCwgdGZfZWF4ID0gMTAsIHRmX3RyYXBubyA9IDAsIHRmX2VyciA9IDIs IHRmX2VpcCA9IDEzNDY5NzM1MSwgdGZfY3MgPSA1MSwgdGZfZWZsYWdzID0gNTgyLCB0Zl9lc3Ag PSAtMTA3Nzk0OTYyMCwgdGZfc3MgPSA1OX0pCiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2 L3RyYXAuYzo5ODYKCXBhcmFtcyA9IDB4YmZiZmNiNTAgPEFkZHJlc3MgMHhiZmJmY2I1MCBvdXQg b2YgYm91bmRzPgoJY2FsbHAgPSAoc3RydWN0IHN5c2VudCAqKSAweGMwNzMxMTE4CglwID0gKHN0 cnVjdCBwcm9jICopIDB4YzJmNjhhM2MKCW9yaWdfdGZfZWZsYWdzID0gNTgyCglzdGlja3MgPSAw CgllcnJvciA9IDAKCW5hcmcgPSAxCglhcmdzID0gey0xMDc3OTQzNTIyLCAtMTA3Nzk0OTYwMCwg MSwgLTQzMDc5MzQyOCwgLTEwNjY1NTg2NDYsIAogIC0xMDY2MDYzOTA0LCAtNDMwNzkzNDIwLCA0 fQoJY29kZSA9IDEwCiMyMyAweGMwNmM3Y2NmIGluIFhpbnQweDgwX3N5c2NhbGwgKCkgYXQgL3Vz ci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoyMDAKTm8gbG9jYWxzLgojMjQgMHgwMDAw MDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNSAweDAwMDAw MDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI2IDB4MDAwMDAw M2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjcgMHhiZmJmZDEy YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOCAweDAwMDAwMDAw IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI5IDB4YmZiZmNiZDgg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzAgMHhlNjUyOWQ2NCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMSAweGJmYmZlMzFlIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMyIDB4MDAwMTgxYTQgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzMgMHgwMDAwMDAwYSBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNCAweDAwMDAwMDBhIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM1IDB4MDAwMDAwMDAgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzYgMHgwMDAwMDAwMiBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNyAweDA4MDc1MTg3IGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM4IDB4MDAwMDAwMzMgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzkgMHgwMDAwMDI0NiBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MCAweGJmYmZjYjRjIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQxIDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDIgMHgwMDAwMDA2MCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MyAweDAwMDAwMDYxIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQ0IDB4MDAwMDAwNjIgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDUgMHgwMDAwMDA2MyBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0NiAweDI5N2ExMDAwIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQ3IDB4YzIxZWRkZDQgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDggMHhjMjIwZjE5MCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiM0OSAweGU2NTI5OWQ0IGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzUwIDB4ZTY1Mjk5YmMgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojNTEgMHhjMjFlZGM4MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiM1MiAweGMwNTNlMDg4IGluIHNjaGVkX3N3aXRjaCAodGQ9MHhi ZmJmZTMxZSwgbmV3dGQ9MHgwLCBmbGFncz0pCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hl ZF91bGUuYzoxMzc3CglrZSA9IChzdHJ1Y3QgdGRfc2NoZWQgKikgMHhiZmJmZDEyYwooa2dkYikg Cg== --=-inI4g/3K4fiOkeUMf+AC Content-Disposition: attachment; filename=KLAMATH Content-Transfer-Encoding: base64 Content-Type: text/plain; name=KLAMATH; charset=UTF-8 bWFjaGluZQkJaTM4Ng0KY3B1CQlJNjg2X0NQVQ0KaWRlbnQJCUtMQU1BVEgNCg0KI1RvIHN0YXRp Y2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhp bnRzDQojaGludHMJCSJHRU5FUklDLmhpbnRzIgkJI0RlZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9y IGRldmljZXMuDQoNCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjQnVpbGQga2VybmVsIHdpdGggZ2Ri KDEpIGRlYnVnIHN5bWJvbHMNCg0KI29wdGlvbnMgCVNDSEVEXzRCU0QJCSM0QlNEIHNjaGVkdWxl cg0Kb3B0aW9ucwkJU0NIRURfVUxFCQkjVUxFIHNjaGVkdWxlcg0Kb3B0aW9ucyAJSU5FVAkJCSNJ bnRlck5FVHdvcmtpbmcNCm9wdGlvbnMgCUlORVQ2CQkJI0lQdjYgY29tbXVuaWNhdGlvbnMgcHJv dG9jb2xzDQpvcHRpb25zIAlGRlMJCQkjQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtDQpvcHRpb25z IAlTT0ZUVVBEQVRFUwkJI0VuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQNCm9wdGlvbnMg CVVGU19BQ0wJCQkjU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMNCm9wdGlvbnMgCVVG U19ESVJIQVNICQkjSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMNCm9wdGlv bnMgCU1EX1JPT1QJCQkjTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UNCm9wdGlvbnMgCU5G U0NMSUVOVAkJI05ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQNCm9wdGlvbnMgCU5GU1NFUlZFUgkJ I05ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXINCm9wdGlvbnMgCU5GU19ST09UCQkjTkZTIHVzYWJs ZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQNCm9wdGlvbnMgCU1TRE9TRlMJCQkjTVNET1MgRmls ZXN5c3RlbQ0Kb3B0aW9ucyAJQ0Q5NjYwCQkJI0lTTyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlvbnMg CVBST0NGUwkJCSNQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQ0Kb3B0aW9u cyAJUFNFVURPRlMJCSNQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsNCm9wdGlvbnMgCUNPTVBB VF80MwkJI0NvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0Kb3B0aW9ucyAJQ09N UEFUX0ZSRUVCU0Q0CQkjQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0DQpvcHRpb25zIAlTQ1NJX0RF TEFZPTIwMDAgCSNEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kNCm9wdGlvbnMgCUtU UkFDRQkJCSNrdHJhY2UoMSkgc3VwcG9ydA0Kb3B0aW9ucyAJU1lTVlNITQkJCSNTWVNWLXN0eWxl IHNoYXJlZCBtZW1vcnkNCm9wdGlvbnMgCVNZU1ZNU0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1 ZXVlcw0Kb3B0aW9ucyAJU1lTVlNFTQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMNCm9wdGlvbnMg CV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjUG9zaXggUDEwMDNfMUIgcmVhbC10aW1lIGV4 dGVuc2lvbnMNCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBlbnRy eSBpbiAvZGV2DQpvcHRpb25zIAlBSENfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVy IGJpdGZpZWxkcyBpbiBkZWJ1Zw0KCQkJCQkjIG91dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVy Lg0Kb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVs ZHMgaW4gZGVidWcNCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRvIGRyaXZlci4NCmRldmlj ZQkJaXNhDQpkZXZpY2UJCWVpc2ENCmRldmljZQkJcGNpDQoNCiMgQVRBIGFuZCBBVEFQSSBkZXZp Y2VzDQpkZXZpY2UJCWF0YQ0KZGV2aWNlCQlhdGFkaXNrCQkJIyBBVEEgZGlzayBkcml2ZXMNCmRl dmljZQkJYXRhcGljZAkJCSMgQVRBUEkgQ0RST00gZHJpdmVzDQpvcHRpb25zIAlBVEFfU1RBVElD X0lECQkjU3RhdGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJIENvbnRyb2xsZXJzDQpkZXZp Y2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQ0KZGV2aWNlCQl0cm0JCSMg VGVrcmFtIERDMzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycw0KDQojIFNDU0kgcGVyaXBoZXJhbHMN CmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkIGZvciBTQ1NJKQ0KZGV2aWNlCQlk YQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykNCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nl c3MgKHRhcGUgZXRjKQ0KZGV2aWNlCQljZAkJIyBDRA0KZGV2aWNlCQlwYXNzCQkjIFBhc3N0aHJv dWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQ0KDQojIGF0a2JkYzAgY29udHJvbHMgYm90 aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlDQpkZXZpY2UJCWF0a2JkYwkJIyBBVCBr ZXlib2FyZCBjb250cm9sbGVyDQpkZXZpY2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkDQojZGV2aWNl CQlwc20JCSMgUFMvMiBtb3VzZQ0KDQpkZXZpY2UJCXZnYQkJIyBWR0EgdmlkZW8gY2FyZCBkcml2 ZXINCg0KZGV2aWNlCQlzcGxhc2gJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1 cHBvcnQNCg0KIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJs aW5nIGFuIFNDTyBjb25zb2xlDQpkZXZpY2UJCXNjDQoNCmRldmljZQkJYWdwCQkjIHN1cHBvcnQg c2V2ZXJhbCBBR1AgY2hpcHNldHMNCg0KIyBGbG9hdGluZyBwb2ludCBzdXBwb3J0IC0gZG8gbm90 IGRpc2FibGUuDQpkZXZpY2UJCW5weA0KDQojIEFkZCBzdXNwZW5kL3Jlc3VtZSBzdXBwb3J0IGZv ciB0aGUgaTgyNTQuDQpkZXZpY2UJCXBtdGltZXINCg0KIyBTZXJpYWwgKENPTSkgcG9ydHMNCmRl dmljZQkJc2lvCQkjIDgyNTAsIDE2WzQ1XTUwIGJhc2VkIHNlcmlhbCBwb3J0cw0KDQojIFBhcmFs bGVsIHBvcnQNCmRldmljZQkJcHBjDQpkZXZpY2UJCXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVz IChyZXF1aXJlZCkNCmRldmljZQkJbHB0CQkjIFByaW50ZXINCmRldmljZQkJcGxpcAkJIyBUQ1Av SVAgb3ZlciBwYXJhbGxlbA0KZGV2aWNlCQlwcGkJCSMgUGFyYWxsZWwgcG9ydCBpbnRlcmZhY2Ug ZGV2aWNlDQojZGV2aWNlCQl2cG8JCSMgUmVxdWlyZXMgc2NidXMgYW5kIGRhDQoNCg0KIyBQQ0kg RXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxlciBjb2Rl Lg0KIyBOT1RFOiBCZSBzdXJlIHRvIGtlZXAgdGhlICdkZXZpY2UgbWlpYnVzJyBsaW5lIGluIG9y ZGVyIHRvIHVzZSB0aGVzZSBOSUNzIQ0KZGV2aWNlCQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0 DQpkZXZpY2UJCXJsCQkjIFJlYWxUZWsgODEyOS84MTM5DQpkZXZpY2UJCXZyCQkjIFZJQSBSaGlu ZSwgUmhpbmUgSUkNCg0KIyBQc2V1ZG8gZGV2aWNlcyAtIHRoZSBudW1iZXIgaW5kaWNhdGVzIGhv dyBtYW55IHVuaXRzIHRvIGFsbG9jYXRlLg0KZGV2aWNlCQlyYW5kb20JCSMgRW50cm9weSBkZXZp Y2UNCmRldmljZQkJbG9vcAkJIyBOZXR3b3JrIGxvb3BiYWNrDQpkZXZpY2UJCWV0aGVyCQkjIEV0 aGVybmV0IHN1cHBvcnQNCmRldmljZQkJdHVuCQkjIFBhY2tldCB0dW5uZWwuDQpkZXZpY2UJCXB0 eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykNCmRldmljZQkJbWQJCSMgTWVtb3J5ICJkaXNr cyINCmRldmljZQkJZ2lmCQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nDQpkZXZpY2UJCWZhaXRo CQkjIElQdjYtdG8tSVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pDQoNCiMgVGhlIGBicGYnIGRl dmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLg0KIyBCZSBhd2FyZSBvZiB0 aGUgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhDQpkZXZpY2UJ CWJwZgkJIyBCZXJrZWxleSBwYWNrZXQgZmlsdGVyDQoNCiMgVVNCIHN1cHBvcnQNCmRldmljZQkJ dWhjaQkJIyBVSENJIFBDSS0+VVNCIDEueCBpbnRlcmZhY2UNCmRldmljZQkJZWhjaQkJIyBFSENJ IFBDSS0+VVNCIDIuMCBpbnRlcmZhY2UNCmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVk KQ0KI2RldmljZQkJdWRicAkJIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2VzDQpkZXZpY2UJ CXVnZW4JCSMgR2VuZXJpYw0KZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNl cyINCiMga2VlcCB1bWFzcyBhcyBtb2R1bGUsIHNvIGFkZGluZyBxdWlya3MgaXMgZWFzaWVyDQoj ZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQg ZGENCmRldmljZQkJdW1zCQkjIE1vdXNlDQoNCmRldmljZQkJc291bmQNCg0Kb3B0aW9ucwkJSVBG SVJFV0FMTA0Kb3B0aW9ucwkJSVBGSVJFV0FMTF9WRVJCT1NFDQpvcHRpb25zCQlJUERJVkVSVA0K DQpkZXZpY2UJCWlpY2J1cw0KZGV2aWNlCQlpaWNiYg0KZGV2aWNlCQlzbWJ1cw0KDQpkZXZpY2UJ CWJrdHINCg0Kb3B0aW9ucwkJQlJPT0tUUkVFX1NZU1RFTV9ERUZBVUxUPUJST09LVFJFRV9QQUwN Cm9wdGlvbnMJCUJST09LVFJFRV9BTExPQ19QQUdFUz01MTIgIyBkZWZhdWx0OiAyMTYqNGsgPSA4 NjRrLCBpbmNyZWFzaW5nDQoJCQkJCSAgIyBtYXkgaGVscCB3aXRoIDI0Yml0IG1vZGUNCg0KZGV2 aWNlCQlhdGFwaWNhbQ0KDQpvcHRpb25zCQlJTkNMVURFX0NPTkZJR19GSUxFCSMgSW5jbHVkZSB0 aGlzIGNvbmZpZ3VyYXRpb24gZmlsZSBpbiB0aGUgDQoJCQkJCSMga2VybmVsIGltYWdlLg0KDQoj b3B0aW9ucwkJSVBTRUMNCiNvcHRpb25zCQlJUFNFQ19FU1ANCiNvcHRpb25zCQlJUFNFQ19ERUJV Rw0KDQpkZXZpY2UJCWlvDQpkZXZpY2UJCW1lbQ0KZGV2aWNlCQljcHVmcmVxDQoNCiNkZXZpY2UJ CWJyaWRnZV9uZw0KDQojb3B0aW9ucwkJQ09EQQ0KI2RldmljZQkJdmNvZGENCiNvcHRpb25zCUNP REFfQ09NUEFUXzUgIyBuYWFhLCBkb24ndCB3YW50IGNvZGEgNS54IGNvbXBhdCwgNi54IGlzIGJl dHRlciBhbmQgcmVhbG1zIGF3YXJlDQoNCm9wdGlvbnMJCVNDX1BJWEVMX01PREUNCm9wdGlvbnMJ CVBSRUVNUFRJT04NCiNvcHRpb25zCUZVTExfUFJFRU1QVElPTg0K --=-inI4g/3K4fiOkeUMf+AC-- --=-rJUE0b8oRrFc2pXH4Hs3 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) iD8DBQBC4OI2Yucd7Ow1ygwRAvc6AJ497LTM5sVgZIAOosmFyRkm87N8tgCgk9zt wqdvgWvVnh3GwQeBRJgjpoU= =jVr7 -----END PGP SIGNATURE----- --=-rJUE0b8oRrFc2pXH4Hs3-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:16: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 04A9316A433; Fri, 22 Jul 2005 12:16:57 +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 6290043D78; Fri, 22 Jul 2005 12:16:34 +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 j6MCGVtT089947; Fri, 22 Jul 2005 07:16:33 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42E0E39E.8020009@centtech.com> Date: Fri, 22 Jul 2005 07:16:30 -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: "Thomas E. Zander" References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> <42DE3C1F.9070704@centtech.com> <20050720130523.GT782@marvin.riggiland.au> In-Reply-To: <20050720130523.GT782@marvin.riggiland.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 12:16:57 -0000 Thomas E. Zander wrote: > Hi, > > On Wed, 20. Jul 2005, at 6:57 -0500, Eric Anderson wrote > according to [Re: mksnap_ffs takes 4-5 minutes?]: > > >>A 2tb filesystem with the standard newfs options takes about 30 minutes >>to mksnap.. That's unusable really, because the filesystem is suspended >>for so long. Even empty 2tb filesystems take forever, so it's related >>to the amount of inodes. >> >>How can we make this snappier? > > > For the moment we can workaround by setting inode density appropriately > when creating the fs. However this is only feasible if you know what > your users are going to do with the fs; it also doesn't help when you > *need* a large fs containing many small files. > In the long run, dynamic inode (de)allocation would be nice to have. It doesn't seem to make a difference on how much of the filesystem is actually used. It seems to be dependent on how many inodes there are, or maybe more appropriately, how many cylinder groups. > Also...what about the 'preparation' time for snapping? IIRC McKusick > said that the lion's share of snapping time is used to delay pending > transactions before actually doing the snap. > There are quite some scenarios in which you can be certain that there > is no file opened for writing, so a snap could be taken immediately. > Would it be feasible to implement this feature? Or am I completely > wrong? The snap seemed to suspend the filesystem nearly immediately, and kept it suspended for quite some time - I would say probably more than half the time. In order for snapshots to be very useful, it must work on large filesystems (100GB+) in a reasonable amount of time (a few seconds would be ok). I know for certain that one test filesystem (2Tb) had nothing on it, no processess using the filesystem at all, and it took well over an hour to run mksnap on it. Maybe mksnap is broken somehow? 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 Jul 22 12:16: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 7CB0016A420; Fri, 22 Jul 2005 12:16:56 +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 6BEEA43D48; Fri, 22 Jul 2005 12:16:28 +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 j6MCFuFG005395; Fri, 22 Jul 2005 08:15:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6MCGRDH047283; Fri, 22 Jul 2005 08:16:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DB23D7304D; Fri, 22 Jul 2005 08:16:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050722121626.DB23D7304D@freebsd-current.sentex.ca> Date: Fri, 22 Jul 2005 08:16:26 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Fri, 22 Jul 2005 12:16:57 -0000 TB --- 2005-07-22 10:19:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-22 10:19:08 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-07-22 10:19:08 - cleaning the object tree TB --- 2005-07-22 10:19:08 - checking out the source tree TB --- 2005-07-22 10:19:08 - cd /home/tinderbox/HEAD/amd64/amd64 TB --- 2005-07-22 10:19:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-22 10:24:33 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-22 10:24:33 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-22 10:24:33 - /usr/bin/make -B buildworld >>> 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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-07-22 11:55:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-22 11:55:42 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-22 11:55:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jul 22 11:55:42 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 Fri Jul 22 12:10:53 UTC 2005 TB --- 2005-07-22 12:10:53 - generating LINT kernel config TB --- 2005-07-22 12:10:53 - cd /home/tinderbox/HEAD/amd64/amd64/src/sys/amd64/conf TB --- 2005-07-22 12:10:53 - /usr/bin/make -B LINT TB --- 2005-07-22 12:10:53 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-22 12:10:53 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-22 12:10:53 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 22 12:10:53 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 [...] /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previous implicit declaration of 'kvtop' was here /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:1011: warning: nested extern declaration of `kvtop' /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: redundant redeclaration of 'kvtop' /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previous implicit declaration of 'kvtop' was here /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c: In function `lnc_start': /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:1306: warning: nested extern declaration of `kvtop' /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: redundant redeclaration of 'kvtop' /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previous implicit declaration of 'kvtop' was here *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/obj/amd64/tinderbox/HEAD/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. TB --- 2005-07-22 12:16:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-22 12:16:26 - ERROR: failed to build lint kernel TB --- 2005-07-22 12:16:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:17: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 53F4616A433 for ; Fri, 22 Jul 2005 12:17:33 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A1443D75 for ; Fri, 22 Jul 2005 12:17:25 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from pulse (pulse.behrens [192.168.20.31]) by pinky.frank-behrens.de (8.13.4/8.13.4) with ESMTP id j6MCHMK7002907 for ; Fri, 22 Jul 2005 14:17:23 +0200 (CEST) (envelope-from frank@pinky.sax.de) Message-Id: <200507221217.j6MCHMK7002907@pinky.frank-behrens.de> From: "Frank Behrens" To: freebsd-current@freebsd.org Date: Fri, 22 Jul 2005 14:17:21 +0200 MIME-Version: 1.0 Priority: normal X-PGP-Fingerprint: 4C 2F B2 77 57 22 65 4D 55 9E A6 D6 64 5F 51 5A X-PGP-Fingerprint: 4C 2F B2 77 57 22 65 4D 55 9E A6 D6 64 5F 51 5A X-mailer: Pegasus Mail for Windows (4.21c, DE v4.21c R1) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Content-description: Mail message body Subject: FreeBSD-SA-05:09.htt in FreeBSD-6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 12:17:33 -0000 Yesterday I made an update (cvsup) from my FreeBSD 5.4 to RELENG_6 - no big problems so far. Then I searched the knob to switch on hyperthreading on my P4. I was surprised, that it was already active, although I had ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:09.htt.asc in my mind. Now I see two possibilities: 1. The described problem does not affect the current 6.0/7.0 codebase. In that case sorry for disturbing you. 2. In 6.0/7.0 hyperthreading was left on, because it was a development branch only. In that case somebody should set the default switch to off before the 6.0-RELEASE (better before the next BETA version) and write a note in UPDATING. Gruß, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13:06: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 D8FBE16A422 for ; Fri, 22 Jul 2005 13:06:23 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F25E43DAD for ; Fri, 22 Jul 2005 13:05: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 2D2AE323333; Fri, 22 Jul 2005 15:05:43 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 5C1D3407E; Fri, 22 Jul 2005 15:05:30 +0200 (CEST) Date: Fri, 22 Jul 2005 15:05:30 +0200 From: Jeremie Le Hen To: Frank Behrens Message-ID: <20050722130530.GO39292@obiwan.tataz.chchile.org> References: <200507221217.j6MCHMK7002907@pinky.frank-behrens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507221217.j6MCHMK7002907@pinky.frank-behrens.de> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-05:09.htt in FreeBSD-6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 13:06:24 -0000 Hi Frank, > Yesterday I made an update (cvsup) from my FreeBSD 5.4 to RELENG_6 - > no big problems so far. > > Then I searched the knob to switch on hyperthreading on my P4. I was > surprised, that it was already active, although I had > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:09.htt.asc > in my mind. > > Now I see two possibilities: > > 1. The described problem does not affect the current 6.0/7.0 > codebase. In that case sorry for disturbing you. > > 2. In 6.0/7.0 hyperthreading was left on, because it was a > development branch only. In that case somebody should set the default > switch to off before the 6.0-RELEASE (better before the next BETA > version) and write a note in UPDATING. This is a good point ! :-) I this this was either forgotten or this will happen later in the release process. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13:37: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 559A616A479 for ; Fri, 22 Jul 2005 13:37:11 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from shim1.irt.drexel.edu (shim1.irt.drexel.edu [144.118.29.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1FB343DC5 for ; Fri, 22 Jul 2005 13:36:41 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from conversion-daemon.shim1.irt.drexel.edu by shim1.irt.drexel.edu (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0IK100K0172PS7@shim1.irt.drexel.edu> for freebsd-current@freebsd.org; Fri, 22 Jul 2005 09:36:17 -0400 (EDT) Received: from vorpal.math.drexel.edu (vorpal.math.drexel.edu [129.25.6.250]) by shim1.irt.drexel.edu (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0IK100LJ07468E@shim1.irt.drexel.edu> for freebsd-current@freebsd.org; Fri, 22 Jul 2005 09:36:06 -0400 (EDT) Received: from [IPv6:::1] (vorpal.math.drexel.edu [129.25.6.250]) by vorpal.math.drexel.edu (8.13.3/8.12.10) with ESMTP id j6MDWfme021929 for ; Fri, 22 Jul 2005 09:32:41 -0400 (EDT envelope-from jsmith@drexel.edu) Date: Fri, 22 Jul 2005 09:36:05 -0400 From: "Justin R. Smith" To: freebsd-current@freebsd.org Message-id: <42E0F645.407@drexel.edu> Organization: Drexel University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050721) Subject: How stable is current, now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 13:37:12 -0000 Hi all! I'm running FreeBSD jsmith.org 5.4-STABLE FreeBSD 5.4-STABLE #0: Thu Jul 14 12:35:12 EDT 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 now and considering upgrading to 6.0. Is this system fairly usable now? From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13:48: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 6F25316A4C0 for ; Fri, 22 Jul 2005 13:48:01 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from mail.starlofashions.com (mail.starlofashions.com [12.44.50.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F25E43D69 for ; Fri, 22 Jul 2005 13:47:50 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from nyserve3.starlofashions.com ([192.0.0.230]) by mail.starlofashions.com (8.9.3/8.9.3) with ESMTP id JAA25671 for ; Fri, 22 Jul 2005 09:47:13 -0400 Received: from uws1.starlofashions.com (uws1.starlofashions.com [192.168.8.230]) by nyserve3.starlofashions.com (Postfix) with SMTP id D836860E1 for ; Fri, 22 Jul 2005 09:47:13 -0400 (EDT) Received: by uws1.starlofashions.com (sSMTP sendmail emulation); Fri, 22 Jul 2005 09:47:13 -0400 Date: Fri, 22 Jul 2005 09:47:13 -0400 From: Scott Robbins To: freebsd-current@freebsd.org Message-ID: <20050722134713.GB60396@uws1.starlofashions.com> Mail-Followup-To: freebsd-current@freebsd.org References: <42E0F645.407@drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <42E0F645.407@drexel.edu> User-Agent: mutt-ng devel (FreeBSD) Subject: Re: How stable is current, now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 13:48:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jul 22, 2005 at 09:36:05AM -0400, Justin R. Smith wrote: > Hi all! > > I'm running > > FreeBSD jsmith.org 5.4-STABLE FreeBSD 5.4-STABLE #0: Thu Jul 14 12:35:12 EDT > 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 > > > now and considering upgrading to 6.0. Is this system fairly usable now? Well, remember it's beta, but I've been running it on my workstation with no issues. I'm holding off putting it on the servers though. :) - -- Scott GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willow: I mean, please. Does Angel come up to Faith's standards for a guy? Let's see, is he breathing? Buffy: Actually, no. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4Pjh+lTVdes0Z9YRAvLpAKCb+zl9GUNFP0OtqdKY+kexlRTsWwCfW88J RQdjIkgNrKFPG08srBWJBpw= =teIW -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13:48: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 EB37716A4FF for ; Fri, 22 Jul 2005 13:48:05 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C60243D64 for ; Fri, 22 Jul 2005 13:47:49 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j6ME15GW085877 for ; Fri, 22 Jul 2005 14:01:06 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j6ME159f085876 for freebsd-current@FreeBSD.org; Fri, 22 Jul 2005 14:01:05 GMT (envelope-from dunstan) Date: Fri, 22 Jul 2005 14:01:05 +0000 From: "Wojciech A. Koszek" To: freebsd-current@FreeBSD.org Message-ID: <20050722140104.GB85763@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: [Panic] mutex Giant not owned at sys/security/mac/mac_inet.c:217 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 13:48:06 -0000 Hello, While playing with rpcbind/mountd/nfsd I got: #0 doadump () at pcpu.h:165 #1 0xc04b0acb in boot (howto=0x104) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc04b0dcb in panic (fmt=0xc05fa8c8 "mutex %s not owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc04a90b8 in _mtx_assert (m=0xc0660aa0, what=0x0, file=0xc060d0ad "/usr/src/sys/security/mac/mac_inet.c", line=0xd9) at /usr/src/sys/kern/kern_mutex.c:738 #4 0xc055274b in mac_create_mbuf_from_inpcb (inp=0xc2ee2e58, m=0xc2e39b00) at /usr/src/sys/security/mac/mac_inet.c:217 #5 0xc053bc1c in udp_output (inp=0xc2ee2e58, m=0xc2e39b00, addr=0x0, control=0x0, td=0xc2baf600) at /usr/src/sys/netinet/udp_usrreq.c:765 #6 0xc053c4c2 in udp_send (so=0x0, flags=0x0, m=0xc2e39b00, addr=0x0, control=0x0, td=0xc2baf600) at /usr/src/sys/netinet/udp_usrreq.c:1051 #7 0xc2ae8bc1 in ?? () nfsserver support was present as KLD. This problem doesn't seem to be easily repeatable. Curretly, I'm not able to reproduce it. $FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.175 2005/06/01 11:24:00 rwatson Exp $ $FreeBSD: src/sys/security/mac/mac_inet.c,v 1.1 2004/02/26 03:51:04 rwatson Exp $ -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13: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 0551F16A45C; Fri, 22 Jul 2005 13:53:34 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5D8C43DB0; Fri, 22 Jul 2005 13:53:28 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 431254F3E8; Fri, 22 Jul 2005 15:53:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 80CFAC675; Fri, 22 Jul 2005 15:53:43 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58715-04; Fri, 22 Jul 2005 15:53:39 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 1206FC667; Fri, 22 Jul 2005 15:53:39 +0200 (CEST) To: Eric Anderson From: Eric Masson In-Reply-To: <42E0E39E.8020009@centtech.com> (Eric Anderson's message of "Fri, 22 Jul 2005 07:16:30 -0500") References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> <42DE3C1F.9070704@centtech.com> <20050720130523.GT782@marvin.riggiland.au> <42E0E39E.8020009@centtech.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Fri, 22 Jul 2005 15:53:39 +0200 Message-ID: <86irz32bh8.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-fs@freebsd.org, "Thomas E. Zander" , freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 13:53:34 -0000 Eric Anderson writes: Hi, > I know for certain that one test filesystem (2Tb) had nothing on it, > no processess using the filesystem at all, and it took well over an > hour to run mksnap on it. I made some tests on a Dell PowerVault 725N with à 5.2 about a year and a half ago. Snapshots on a 700GB filesystem were taking roughly half an hour. > Maybe mksnap is broken somehow? Don't think broken is the right term, but it surely lacks optimization on huge filesystems when compared to snapshots on a netapp filer (5 seconds on a terabyte volume for example). For medium size fs like the 80B I'm using here on my desktop box, approximately 30 seconds seems reasonable to me. Shorter time would be welcome, sure ;) Éric Masson -- Contresens. Le contenu de la signature doit respecter la charte du NG sur *tous* les sujets. Aussi bien la pub que la Netiquette. C'est pas une zone de non-droit, les 4 lignes de signature. -+- Lapin in : Oui-Oui casque bleu à Neuneuland -+- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 13:55: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 E555E16A446; Fri, 22 Jul 2005 13:55: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 3958743DA2; Fri, 22 Jul 2005 13:55:00 +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 j6MDsSCZ012515; Fri, 22 Jul 2005 09:54:28 -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 j6MDsxnB092973; Fri, 22 Jul 2005 09:54:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C8CD37304D; Fri, 22 Jul 2005 09:54:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050722135458.C8CD37304D@freebsd-current.sentex.ca> Date: Fri, 22 Jul 2005 09:54:58 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 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: Fri, 22 Jul 2005 13:55:36 -0000 TB --- 2005-07-22 12:16:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-22 12:16:26 - starting HEAD tinderbox run for i386/i386 TB --- 2005-07-22 12:16:26 - cleaning the object tree TB --- 2005-07-22 12:16:26 - checking out the source tree TB --- 2005-07-22 12:16:26 - cd /home/tinderbox/HEAD/i386/i386 TB --- 2005-07-22 12:16:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-22 12:21:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-22 12:21:46 - cd /home/tinderbox/HEAD/i386/i386/src TB --- 2005-07-22 12:21:46 - /usr/bin/make -B buildworld >>> 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-07-22 13:25:00 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-22 13:25:00 - cd /home/tinderbox/HEAD/i386/i386/src TB --- 2005-07-22 13:25:00 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jul 22 13:25:00 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 Fri Jul 22 13:41:50 UTC 2005 TB --- 2005-07-22 13:41:50 - generating LINT kernel config TB --- 2005-07-22 13:41:50 - cd /home/tinderbox/HEAD/i386/i386/src/sys/i386/conf TB --- 2005-07-22 13:41:50 - /usr/bin/make -B LINT TB --- 2005-07-22 13:41:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-22 13:41:50 - cd /home/tinderbox/HEAD/i386/i386/src TB --- 2005-07-22 13:41:50 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 22 13:41:51 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 [...] In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_bios.S:4: ./machine/asmacros.h:108:1: "ALTENTRY" redefined In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_bios.S:1: ./machine/asm.h:87:1: this is the location of the previous definition In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_bios.S:4: ./machine/asmacros.h:113:1: "ENTRY" redefined In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_bios.S:1: ./machine/asm.h:88:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/HEAD/i386/i386/obj/tinderbox/HEAD/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/HEAD/i386/i386/src. *** Error code 1 Stop in /tinderbox/HEAD/i386/i386/src. TB --- 2005-07-22 13:54:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-22 13:54:58 - ERROR: failed to build lint kernel TB --- 2005-07-22 13:54:58 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 14:22: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 B4D1016A421 for ; Fri, 22 Jul 2005 14:22:11 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD4B43D5D for ; Fri, 22 Jul 2005 14:21:55 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr7so.prod.shaw.ca (pd2mr7so-qfe3.prod.shaw.ca [10.0.141.10]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IK10039898IUWF0@l-daemon> for freebsd-current@freebsd.org; Fri, 22 Jul 2005 08:21:54 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd2mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IK1007CD98IDFF0@pd2mr7so.prod.shaw.ca> for freebsd-current@freebsd.org; Fri, 22 Jul 2005 08:21:54 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IK100M0N98IS4@l-daemon> for freebsd-current@freebsd.org; Fri, 22 Jul 2005 08:21:54 -0600 (MDT) Date: Fri, 22 Jul 2005 07:21:53 -0700 From: Colin Percival In-reply-to: <200507221217.j6MCHMK7002907@pinky.frank-behrens.de> To: Frank Behrens Message-id: <42E10101.2030304@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <200507221217.j6MCHMK7002907@pinky.frank-behrens.de> User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050714) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-05:09.htt in FreeBSD-6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 14:22:11 -0000 Frank Behrens wrote: > Yesterday I made an update (cvsup) from my FreeBSD 5.4 to RELENG_6 - > no big problems so far. > > 2. In 6.0/7.0 hyperthreading was left on, because it was a > development branch only. In that case somebody should set the default > switch to off before the 6.0-RELEASE (better before the next BETA > version) and write a note in UPDATING. Yes. This needs to be taken care of at some point -- likely at the same time as some of the debugging options with large performance costs are turned off. Colin Percival From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 14:55: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 B266116A439 for ; Fri, 22 Jul 2005 14:55:40 +0000 (GMT) (envelope-from jr@jrssite.com) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.173.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A0543DAA for ; Fri, 22 Jul 2005 14:55:36 +0000 (GMT) (envelope-from jr@jrssite.com) Received: from [192.168.0.7] (66-230-83-192-cdsl-rb1.fai.acsalaska.net [66.230.83.192]) by hob.acsalaska.net (8.13.4/8.13.4) with ESMTP id j6MEtUSf000561 for ; Fri, 22 Jul 2005 06:55:35 -0800 (AKDT) (envelope-from jr@jrssite.com) Message-ID: <42E108F2.7000000@jrssite.com> Date: Fri, 22 Jul 2005 06:55:46 -0800 From: JR Dalrymple User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <42E0F645.407@drexel.edu> In-Reply-To: <42E0F645.407@drexel.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.51; SA 3.0.3; spamdefang 1.113 Subject: Re: How stable is current, now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 14:55:40 -0000 Justin R. Smith wrote: > Hi all! > > I'm running > > FreeBSD jsmith.org 5.4-STABLE FreeBSD 5.4-STABLE #0: Thu Jul 14 > 12:35:12 EDT 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL > i386 > > > now and considering upgrading to 6.0. Is this system fairly usable now? > _______________________________________________ > 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" It was a simple fix to an SMP problem I was having on 5.3 (a stability problem no less). I've got it on that machine in production. It had a timer issue that they said has since been resolved. I have yet to rebuild to fix that and am just running timed on it to keep it synced with the rest of the world. Otherwise, no issues. -JR From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 15:47: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 48BC916A420; Fri, 22 Jul 2005 15:47:33 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B96A43D7E; Fri, 22 Jul 2005 15:47:11 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6MFl8CX048605; Fri, 22 Jul 2005 18:47:08 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 01032-07; Fri, 22 Jul 2005 18:47:08 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6MFl7Sa048602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2005 18:47:08 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j6MFl22Q063591; Fri, 22 Jul 2005 18:47:02 +0300 (EEST) (envelope-from ru) Date: Fri, 22 Jul 2005 18:47:02 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox Message-ID: <20050722154702.GD62408@ip.net.ua> References: <20050722135458.C8CD37304D@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pZs/OQEoSSbxGlYw" Content-Disposition: inline In-Reply-To: <20050722135458.C8CD37304D@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 15:47:33 -0000 --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2005 at 09:54:58AM -0400, FreeBSD Tinderbox wrote: > [...] > In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_b= ios.S:4: > ./machine/asmacros.h:108:1: "ALTENTRY" redefined > In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_b= ios.S:1: > ./machine/asm.h:87:1: this is the location of the previous definition > In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_b= ios.S:4: > ./machine/asmacros.h:113:1: "ENTRY" redefined > In file included from /tinderbox/HEAD/i386/i386/src/sys/i386/bios/smapi_b= ios.S:1: > ./machine/asm.h:88:1: this is the location of the previous definition > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/i386/i386/obj/tinderbox/HEAD/i386/i386/src/sys/LI= NT. > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/i386/i386/src. > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/i386/i386/src. > TB --- 2005-07-22 13:54:58 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2005-07-22 13:54:58 - ERROR: failed to build lint kernel > TB --- 2005-07-22 13:54:58 - tinderbox aborted >=20 This should be fixed. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4RT2qRfpzJluFF4RAuypAJ0cZtg8YAfrJF6HnJhc2kJ7ohrapQCfXq1Z XiAQP4KXtNIOc7hQfzKLhmY= =z6/2 -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 15:59: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 9073616A420 for ; Fri, 22 Jul 2005 15:59:33 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from soapbox.yandex.ru (soapbox.yandex.ru [213.180.200.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEA7043D60 for ; Fri, 22 Jul 2005 15:59:31 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (soapbox.yandex.ru) by mail.yandex.ru id ; Fri, 22 Jul 2005 19:59:14 +0400 Date: Fri, 22 Jul 2005 19:59:14 +0400 (MSD) From: "Alexander Polakov" Sender: polachok@narod.ru Message-Id: <42E117D2.000001.30495@soapbox.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.14.46 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: splash_bmp (Feature request) 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: Fri, 22 Jul 2005 15:59:33 -0000 Why splash_bmp kernel module cannot be used to show images not only in boot time, but later, on running system? I don't think it will be a big rewrite, but an interesting feature. -- Alexander Polakov From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 16:03:59 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 C99CA16A4E5; Fri, 22 Jul 2005 16:03:59 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A58443DCD; Fri, 22 Jul 2005 16:03:34 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6MG3YlR049636; Fri, 22 Jul 2005 19:03:34 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 01741-01; Fri, 22 Jul 2005 19:03:33 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j6MG3Xuu049633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2005 19:03:33 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j6MG3RIO063680; Fri, 22 Jul 2005 19:03:27 +0300 (EEST) (envelope-from ru) Date: Fri, 22 Jul 2005 19:03:27 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox Message-ID: <20050722160327.GF62408@ip.net.ua> References: <20050722121626.DB23D7304D@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b8GWCKCLzrXbuNet" Content-Disposition: inline In-Reply-To: <20050722121626.DB23D7304D@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 16:04:00 -0000 --b8GWCKCLzrXbuNet Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2005 at 08:16:26AM -0400, FreeBSD Tinderbox wrote: > [...] > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previo= us implicit declaration of 'kvtop' was here > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:1011: warning: neste= d extern declaration of `kvtop' > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: redund= ant redeclaration of 'kvtop' > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previo= us implicit declaration of 'kvtop' was here > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c: In function `lnc_st= art': > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:1306: warning: neste= d extern declaration of `kvtop' > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: redund= ant redeclaration of 'kvtop' > /tinderbox/HEAD/amd64/amd64/src/sys/dev/lnc/if_lnc.c:311: warning: previo= us implicit declaration of 'kvtop' was here > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/amd64/amd64/obj/amd64/tinderbox/HEAD/amd64/amd64/= src/sys/LINT. > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/amd64/amd64/src. > *** Error code 1 >=20 > Stop in /tinderbox/HEAD/amd64/amd64/src. > TB --- 2005-07-22 12:16:26 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2005-07-22 12:16:26 - ERROR: failed to build lint kernel > TB --- 2005-07-22 12:16:26 - tinderbox aborted >=20 This should be fixed (by diking lnc out from the amd64 build). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --b8GWCKCLzrXbuNet Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4RjPqRfpzJluFF4RApImAJ45/en8zl9CdoMvi++Q/bmOA5+DSACdHTqG tXJ8K+hY74Pp2kOi1h7TVow= =JVCw -----END PGP SIGNATURE----- --b8GWCKCLzrXbuNet-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 17:48: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 9970216A41F for ; Fri, 22 Jul 2005 17:48:17 +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 C5ABB44E8B for ; Fri, 22 Jul 2005 17:48:16 +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 B9CDF323433; Fri, 22 Jul 2005 19:48:15 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 17176407E; Fri, 22 Jul 2005 19:48:03 +0200 (CEST) Date: Fri, 22 Jul 2005 19:48:02 +0200 From: Jeremie Le Hen To: Ken Smith Message-ID: <20050722174802.GS39292@obiwan.tataz.chchile.org> References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1121952594.68685.27.camel@opus.cse.buffalo.edu> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 17:48:17 -0000 Hi Ken, hi all, > It will take a while for the fallout from this version bump to > propagate. People who cvsup/rebuild existing systems should not be > impacted immediately - you will still have the older library versions > present on your systems. However it will take time for the pre-built > packages provided by the portmgr folks to be rebuilt, loaded onto the > FTP servers, and propagate out to the mirrors. I know that FreeBSD is still lacking a solution to remove old librairies, but I would like to know the actual recommended way to remove old libraries. I'm not asking for a solution as NetBSD's /etc/postinstall, just a simple and neat one. I can think of number of such solutions, like searching for libraries dating before the last world, parsing Makefiles from src/ to deduce which libs are obsolete, ldd on each binary ... But I would like to hear what others do to achieve this. In short, I'm looking for a neat solution. Note that I'm conscious that I should not remove old libraries while I have not recompiled all ports. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 17:54: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 2980516A587; Fri, 22 Jul 2005 17:54:29 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55BA343D6E; Fri, 22 Jul 2005 17:22:04 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6MHLxmN013898; Fri, 22 Jul 2005 21:21:59 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6MHLroN013897; Fri, 22 Jul 2005 21:21:53 +0400 (MSD) (envelope-from ache) Date: Fri, 22 Jul 2005 21:21:52 +0400 From: Andrey Chernov To: Robert Watson Message-ID: <20050722172152.GA13853@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , "M. Warner Losh" , marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> <20050722011804.O16902@fledge.watson.org> <20050722003657.GA1415@nagual.pp.ru> <20050722013938.H16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722013938.H16902@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 17:54:35 -0000 On Fri, Jul 22, 2005 at 01:40:07AM +0100, Robert Watson wrote: > If the same problem occurs using a different adapter but identical > software configuration otherwise, that would be very helpful to know. I change all excepting rl(4) and problem is gone. I must admit that problem was somewhere else, probably in hardware, and setting mpsafenet only masks the bug, sorry for noise I produce. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 18:38: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 41C7C16A41F; Fri, 22 Jul 2005 18:38:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A63B444D96; Fri, 22 Jul 2005 18:04:41 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id BB73D46B04; Fri, 22 Jul 2005 14:04:40 -0400 (EDT) Date: Fri, 22 Jul 2005 19:05:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20050722172152.GA13853@nagual.pp.ru> Message-ID: <20050722190441.B40216@fledge.watson.org> References: <20050721134816.GA8550@nagual.pp.ru> <20050721142445.GA77847@stack.nl> <20050721143443.GB10010@nagual.pp.ru> <20050721.091844.10574798.imp@bsdimp.com> <20050721152946.GA11578@nagual.pp.ru> <20050722011804.O16902@fledge.watson.org> <20050722003657.GA1415@nagual.pp.ru> <20050722013938.H16902@fledge.watson.org> <20050722172152.GA13853@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marcolz@stack.nl, wpaul@windriver.com, current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: rl(4) is not ready for mpsafenet net enough? (silent reboots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 18:38:51 -0000 On Fri, 22 Jul 2005, Andrey Chernov wrote: > On Fri, Jul 22, 2005 at 01:40:07AM +0100, Robert Watson wrote: >> If the same problem occurs using a different adapter but identical >> software configuration otherwise, that would be very helpful to know. > > I change all excepting rl(4) and problem is gone. I must admit that > problem was somewhere else, probably in hardware, and setting mpsafenet > only masks the bug, sorry for noise I produce. Well, I wouldn't preclude it being a driver problem, or maybe a problem with the card. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 18:41: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 4A76716A425 for ; Fri, 22 Jul 2005 18:41:53 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0821C44B6F for ; Fri, 22 Jul 2005 17:13:39 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 2793 invoked by uid 89); 22 Jul 2005 17:13:37 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Jul 2005 17:13:37 -0000 Date: Fri, 22 Jul 2005 19:13:37 +0200 From: Oliver Lehmann To: dandee@volny.cz Message-Id: <20050722191337.269d965b.lehmann@ans-netz.de> In-Reply-To: <20050720114331.868A64E704@pipa.profix.cz> References: <200507200149.52721.max@love2party.net> <20050720114331.868A64E704@pipa.profix.cz> X-Mailer: Sylpheed version 2.0.0rc (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 18:41:53 -0000 Daniel Dvorak wrote: > Yes, I can confirm this bug, when one use make buildworld with -jN. > If you build the code without -jN, it is all right. I've -j[2-9][0-9]* buildworld problems too. Tried it twice, once with -j16, once with -j4 - and everytime it fails on different locations. -c /usr/src/lib/libc/i386/string/strrchr.S -o strrchr.So cc: Internal error: Abort trap (program cc1) Please submit a full bug report. Is the last copy&paste output I have -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 18:41:59 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 3124916A43D; Fri, 22 Jul 2005 18:41:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0292344EBE; Fri, 22 Jul 2005 18:06:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6MIGMU1047133; Fri, 22 Jul 2005 12:16:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E135AE.4090207@samsco.org> Date: Fri, 22 Jul 2005 12:06:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Content-Type: multipart/mixed; boundary="------------080004040504090205090707" X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED,DOMAIN_4U2 autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Subject: FreeBSD Status Report Second Quarter 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 18:41:59 -0000 This is a multi-part message in MIME format. --------------080004040504090205090707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------080004040504090205090707 Content-Type: text/plain; name="report.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="report.txt" March-June 2005 Status Report Introduction The second quarter of 2005 has again been very exciting. The BSDCan and MeetBSD conferences were both very interesting and and the sources of very good times. I highly recommend attending them again next year. The Google Summer of Code project has also generated quite a bit of excitement. FreeBSD has been granted 18 funded mentorship spots, the fourth most of all of participating organizations. Projects being worked on range from UFS Journalling to porting the new BSDInstaller to redesigning the venerable www.FreeBSD.org website. We are quite pleased to be working with so many talented students, and eagerly await the results of their work. More information and status can be found at the Wiki site at http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005. The FreeBSD 6.0 release cycle is also starting up. The purpose of quickly jumping from 5.x to 6.0 is to reduce the amount of transition pain that most users and developers felt when switching from 4-STABLE to 5.x. 6.0 will feature improved performance and stability over 5.x, experimental PowerPC support, and many new WiFi/802.11 features. The 5.x series will continue for at least one more release this fall, and will then be supported by the security team for at least 2 years after that. We encourage everyone to give the 6.0-BETA snapshots a try and help us make it ready for production. We hope to release FreeBSD 6.0 by the end of August. Thanks again to everyone who submitted reports, and thanks to Max Laier for running the show and putting the reports together. Enjoy reading! _________________________________________________________________ Google summer of code * FreeBSD Summer of Code * FreeBSD website improvements * FreeSBIE toolkit integration * gjournal * gvinum 'move', 'rename' * Improve libalias * Integrate the BSD Installer into FreeBSD * launchd(8) for FreeBSD * Network Interface API Cleanup * Nsswitch / Caching daemon * SEBSD * UFSJ -- Journaling for UFS Projects * Fundraising - TCP & IP Routing Optimization * GEOM Gate rewrite * TODO list for volunteers * VFS SMP Documentation * The FreeBSD Dutch Documentation Project Kernel * Autotuning of the page queue coloring algorithm * CPU Cache Prefetching * libmemstat(3), UMA(9) and malloc(9) statistics * Low-overhead performance monitoring for FreeBSD * Removable interface improvements * SMP Network Stack * Transparent support for superpages in the FreeBSD Kernel * TrustedBSD Audit Network infrastructure * Dingo * if_bridge * IPv6 Support for IPFW * Move ARP out of routing table * TCP Reassembly Rewrite and Optimization * TTCPv2: Transactional TCP version 2 * Wireless Networking Support Userland programs * OpenBSD dhclient import. * Removing of old basesystem files and directories Architectures * PowerPC Port Ports * FreshPorts * Porting v9 of Intels C/C++ Compiler * Update of the Linux userland infrastructure Vendor / 3rd Party Software * OpenBSD packet filter - pf Miscellaneous * BSDCan * EuroBSDCon 2005 - Basel * FreeBSD Security Officer and Security Team * TrustedBSD SEBSD _________________________________________________________________ Autotuning of the page queue coloring algorithm URL: http://www.Leidinger.net/FreeBSD/current-patches/pq.diff Contact: Alexander Leidinger The VM subsystem has code to reduce the amount of cache collisions of VM pages. Currently this code needs to be tuned with a kernel option. I have a patch which changes this to auto-tuning at boot time. The auto-tuning is MI, the cache size detection is MD. Cache size detection is currently available for x86/amd64 (on other systems it uses default values). Open tasks: 1. Add cache-detection code for other arches too (Marius told me how to do this for sparc64). 2. Analyze why the cache detection on Athlons doesn't work (no problems on a P4, but it uses a different code-path). _________________________________________________________________ BSDCan URL: http://www.bsdcan.org/2005/ Contact: Dan Langille The second annual BSDCan conference was well presented, well attended, and everyone went away with good stories to tell. If you know anything that attended, get them to tell you what they did, who they met with, and talks they listened to. We had 197 people from 15 different countries. That's a strong turnout by any definition. We'll be adding more people to the program committee for BSDCan 2006. This job involves prodding and poking people from your respective projects. You get them to submit papers. There are a lot of very interesting projects out there and not all of them submit a paper. If you know someone doing interesting work, please let me know and urge them to start thinking about BSDCan 2006. _________________________________________________________________ CPU Cache Prefetching URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass+prefetch-20041216.patch Contact: Andre Oppermann Modern CPU's can only perform to their maximum if their working code is in fast L1-3 cache memory instead of the bulk main memory. All of today's CPU's support certain L1-3 cache prefetching instructions which cause data to be retrieved from main memory to the cache ahead of the time that it is already in place when it is eventually accessed by the CPU. CPU Cache Prefetching however is not a silver bullet and has to be used with extreme care and only in very specific places to be beneficial. Incorrect usage can lead to massive cache pollution and a drop in effective performance. Correct and very carefully usage on the other can lead to drastic performance increases in common operations. In the linked patch CPU cache prefetching has been used to prefetch the packet header (OSI layer 2 to 4) into the CPU caches right after entering into the network stack. This avoids a complete CPU stall on the first access to the packet header because packets get DMA'd into main memory and thus never are already pre-cache in the CPU caches. A second use in the patch is in the TCP input code to prefetch the entire struct tcpcb which is very large and used with a very high probability. Use in both of these places show a very significant performance gain but not yet fully quantified. The final patch will include documentation and a guide to evaluate and assess the use of CPU cache prefetch instructions in the kernel. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ Dingo URL: http://www.freebsd.org/projects/dingo/ Contact: Several <> Currently trying to restart bits of the project. Cleaning up the p4 branch. Recently more people have volunteered to help as well. Brooks Davis has completed removing the ifnet from the softc. Open tasks: 1. See the web page. _________________________________________________________________ EuroBSDCon 2005 - Basel URL: http://www.eurobsdcon.org/ URL: http://www.eurobsdcon.org/cfp.php Contact: Information The fourth European BSD conference in Basel, Switzerland is a great opportunity to present new ideas to the community and to meet some of the developers behind the different BSDs. The two day conference program (Nov 26 and 27) will be complemented by a tutorial day preceeding the conference (Nov 25). The program committee is looking for tutorial and paper submissions. For details, please see: The call for papers online. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/st= aff-listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In May 2005, Remko Lodder joined the FreeBSD Security Team, followed by Christian S.J. Peron in July 2005. In the same time period, Gregory Shapiro and Josef El-Rayes resigned from the team in order to devote their time to other projects. The current Security Team membership is published on the web site. In the time since the last FreeBSD status report, twelve security advisories have been issued concerning problems in the base system of FreeBSD; of these, six problems were in "contributed" code, while five problems were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and the Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 97 new entries have been added, bringing the total up to 519. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.10, FreeBSD 4.11, FreeBSD 5.3, and FreeBSD 5.4. Their respective End of Life dates are listed on the web site. _________________________________________________________________ FreeBSD Summer of Code URL: http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005 Contact: Summer of Code Mentors Google has generously funded 18 students to spend the summer working on FreeBSD related projects. Each student is working with one or more mentors to learn about how open source software development is done with FreeBSD. This development work is happening in the Perforce repository as //depot/projects/soc2005. This tree will soon be exported via CVSup -- check the Wiki for more information. _________________________________________________________________ FreeBSD website improvements Contact: Emily Boyd As part of the Google Summer of Code, I'm working on improvements to the FreeBSD website (including a proposed website redesign). My mentor for this project is Murray Stokely. _________________________________________________________________ FreeSBIE toolkit integration URL: http://www.freesbie.org URL: http://wikitest.freebsd.org/moin.cgi/DarioFreni Contact: Dario Freni My Summer of Code project is reengineering and rewrite of FreeSBIE toolkit, in order to include it in the source tree. Let's call it FreeSBIE 2 Before being accepted, I worked hard on the FreeSBIE 1 toolkit to make it more flexible. It now supports amd64 and powerpc architecture. The built filesystem can now boot from almost every media, from dvd to compact flash or hard disk. Also on i386 is possible to include the BSD Installer on the livefs. We've received reports that our toolkit is successfully used for install cd of pfSense and PC-BSD projects. My future goals are to make the toolkit even more flexible, capable to build embedded images (like nanoBSD) or big Live-DVD systems, depending on user's choice, to support all the architectures supported by FreeBSD and to write a set of tools for making a netboot server with a FreeSBIE image. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille The following new features have been added to FreshPorts: * Deprecated Ports * Expired Ports * Ports Set To Expire * Display relevent entries from ports/UPDATING on your watch list Open tasks: 1. I've noticed that FreshPorts is incorrectly reporting vulnerabilities under a ver y specific situation . The fix is sitting in BETA, waiting to be moved to production. 2. I've been working on added Last-Modified to the headers. At present, there are none. Most of the pages on the BETA website have been completed. I need to move this to production soon. 3. Customized news feeds are in the works. You'll be able to create a news feed for each of your watch lists This work is contingent upon finishing the Last-Modified headers. _________________________________________________________________ Fundraising - TCP & IP Routing Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html Contact: Andre Oppermann The TCP code in FreeBSD has evolved significantly since the fork from 4.4BSD-Lite2 in 1994 primarily due to new features and refinements of the TCP specifications. The TCP code now needs a general overhaul, streamlining and cleanup to make it easily comprehensible, maintainable and extensible again. In addition there are many little optimizations that can be done during such an operation, propelling FreeBSD back at the top of the best performing TCP/IP stacks again, a position it has held for the longest time in the 90's. This overhaul is a very involved and delicate matter and needs extensive formal and actual testing to ensure no regressions compared to the current code. The effort needed for this work is about three man-month of fully focused and dedicated time. To get it done I need funding to take time off my day job and to dedicate me to FreeBSD work much the way PHK did with his buffer cache and vnode rework projects. I've got the opportunity to work up to three man-month exclusively full-time on FreeBSD during the second half of 2005. That means up to 720 hours of full-steam coding (at 60 hours/week)! I will work as much time as the fundraise provides. I need to raise enough money for each month from donations from the FreeBSD community to cover my fixed cost of living, office and associated overhead. These fixed cost amount to US$6,300/month (EUR5,200 or CHF8,000). Yes, Switzerland is not the cheapest place to live. :) A detailed description of the tasks involved and the code I will write is on my FreeBSD website; Follow the link above. Open tasks: 1. Raise enough money to get all the almost finished TCP and IP code into the tree. _________________________________________________________________ GEOM Gate rewrite URL: http://cvsweb.freebsd.org/src/sys/geom/gate/ URL: http://cvsweb.freebsd.org/src/sbin/ggate/ Contact: Pawel Jakub Dawidek GGATE is a machinism for exporting storage devices over the network. It was reimplemented to be much faster and to handle network failures better. The ggatec uses two threads now: sendtd, which takes I/O request from the kernel and sends it to ggated; recvtd, which receives finished requests and forwards them to the kernel. The ggated uses three threads: recvtd, which receives I/O requests from ggatec; disktd, which executes I/O requests (reads or writes data); sendtd, which sends finished requests to ggatec. The new ggate has been committed to 6.x. The work was sponsored by Wheel Sp. z o.o. _________________________________________________________________ gjournal URL: http://wikitest.freebsd.org/moin.cgi/gjournal Contact: Ivan Voras The schedule (as stated on the wiki page) is honoured, which means that the development has started, but there's not enough code for testing. Many details have been thought-out and the development is ongoing. _________________________________________________________________ gvinum 'move', 'rename' URL: http://wikitest.freebsd.org/moin.cgi/GvinumMoveRename Contact: Chris Jones With the releases of FreeBSD 5.3 and 5.4, FreeBSD has been moving away from "old-style" vinum towards GEOM-enabled gvinum for logical volume management. While gvinum is a mostly feature-complete replacement for vinum, it does not implement the 'move' or 'rename' verbs which are rather useful when reorganizing one's volume layout, the alternative being a tedious process of deleting and recreating subdisks, plexes, or volumes. Additionally, gvinum is nearly completely undocumented, which contributes to the perception of gvinum as an unfinished project. I'm working on implementing 'move' (being able to move a subdisk from one drive to another) and 'rename' (being able to rename an subdisk, plex, volume, or drive), as well as on documentation for gvinum. So far, I've come up with a plan of attack with le@ and phk@, and implemented the bulk of the userland code for gvinum 'move' and 'rename'. Still to come are the kernel-side code and documentation. Open tasks: 1. 'move' and 'rename' userland implementation 2. 'move' and 'rename' kernel-side implementation 3. Outline new handbook section and man page 4. Implement new handbook section and man page _________________________________________________________________ if_bridge Contact: Andrew Thompson This was committed to current on 5 Jun 2005 and will first appear in the 6.0 release, thanks to everyone who tested. Recent improvements include: * IPFW layer2 filtering * DUMMYNET support * IP header alignment checking There is ongoing work to bring in some of the advanced features from OpenBSD such as IPSec bridging. People are encouraged to use if_bridge and report any problems to the mailing lists. _________________________________________________________________ Improve libalias URL: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Contact: Paolo Pisati My SoC project is about improving libalias and integrating it with ipfw2, adding nat support into the firewall. Till now i ported libalias (as a kld) and ng_nat to 4.x and 5.x branches, and i've already a first working patchset that adds 'nat' action into ipfw. Next step will be to add a complete syntax to ipfw that will let us manipulate libalias operations, much like we already do with queue and pipes for dummynet. In the end the entire work will compile and work out of the box for 4.x, 5.x and 6.x. More details about the project and its status are available on wiki page. _________________________________________________________________ Integrate the BSD Installer into FreeBSD URL: http://www.bsdinstaller.org URL: http://wikitest.freebsd.org/moin.cgi/BSDInstaller URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects /soc2005/bsdinstaller Contact: Andrew Turner Progress towards integrating the BSD Installer for Google's Summer of Code is coming along nicely. The installation CD will boot to multi-user mode and run both the front and back ends. It can then partition a hard drive, install the base distribution and make the disk bootable. Open tasks: 1. Test in non-i386 2. Investigate installing from other media 3. Many more tasks _________________________________________________________________ IPv6 Support for IPFW Contact: Max Laier Contact: Brooks Davis At the developer summit before BSDCan it was decided to remove IP6FW from the tree as it has a couple of problems. The most pressing one is the lack of synchronization and thus the need for debug.mpsafenet=0. As a replacement Brooks Davis has imported patches to teach the existing and well-locked IPFW2 code about IPv6. Since the initial import I have added some features required to manage IPv4 and IPv6 in a single ruleset. I have also extended existing opcodes to work with IPv6. There are, however, still some opcodes that do not work with IPv6 and most of the more exotic ones haven't been tested. As long as IPFW2+v6 does not provide enough functionality and stability to work as a drop-in replacement for IP6FW, we won't remove IP6FW. In order to get the new code to that point we really need more testers with real world IPv6 deployment and interest in IPFW+v6. The lack thereof (I haven't received a single answer on my requests to various FreeBSD mailing lists) has made it hard to progress. Open tasks: 1. Properly implement O_REJECT for IPv6 2. Maybe implement O_LOG 3. Test new(er) IPFW2 opcodes with IPv6 4. Test 5. Test 6. Test _________________________________________________________________ launchd(8) for FreeBSD URL: http://wikitest.freebsd.org/moin.cgi/launchd URL: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man 8/launchd.8.html Contact: R. Tyler Ballance So far progress has been slow, the autoconf build system has been removed from all of the launchd(8) code, and launchctl(1) is building and semi-functional on FreeBSD-CURRENT (i.e. CoreFoundation hooks have been removed) I'm currently working on porting "liblaunch" which is the core backend to both launchd(8) (the actual daemon) and launchctl(1), there are some mach/xnu specific hooks and calls that need to be remove and either reimplemented or worked around. We're also waiting on a response from Apple on a possible BSD-licensed version of the code (it's currently under the APSL) Progress is slow, but steady. _________________________________________________________________ libmemstat(3), UMA(9) and malloc(9) statistics URL: http://www.watson.org/~robert/freebsd/libmemstat/ Contact: Robert Watson libmemstat(3) provides a user space library API to monitor kernel memory allocators, currently uma(9) and malloc(9), with the following benefits: * ABI-robust interface making use of accessor functions, in order to divorce monitoring applications from kernel/user ABI changes. * Allocator-independent interfaces, allowing monitoring of multiple allocators using the same interface. * CPU-cache awareness, allowing tracking of memory use across multiple CPUs for allocators aware of caches. Unlike previous interfaces, libmemstat(3) coalesces per-CPU stats in user space rather than kernel, and exposes per-CPU stats to interested applications. * Ability to track memory types over multiple queries, and update existing structures, allowing easy tracking of statistics over time. libmemstat(3) and the the appropriate allocator changes for uma(9) and malloc(9) are currently in HEAD (7-CURRENT), and MFC has been approved to RELENG_6 for inclusion in 6.0-RELEASE. These changes may also be backported to 5.x. Sample applications include memstat(8), an allocator-independent statistics viewing tool, memtop(8), which provides a top(1)-like interface for monitoring kernel memory use and active memory types. None of these are "pretty". netstat -mb has also been updated to use libmemstat(3) to track network memory use using uma(9), rather than the less reliable mbuf allocator statistics interface. As a result, the statistics are now more reliable on SMP systems (this corrects the bug in which mbuf statistics sometimes "leaked", even though memory didn't), and more informative (cache information is now displayed, as well as mbuf tag information). Open tasks: 1. Teach libmemstat(3) to speak libkvm(3) in order to allow tools linked -lmemstat to interogate kernel core dumps. 2. Teach libmemstat(3) to interface with user space malloc and track malloc allocations for user space applications. 3. Update vmstat(8) -m and -z implementations to use libmemstat(3) instead of the old monitoring interfaces. Code to do this exists in the sample libmemstat(3) applications. 4. Identify how to make streams or the library endian-aware so that streams dumped from a kernel of alternative endian could be processed using libmemstat(3) on another system. 5. Identify any remaining caching allocators in the kernel, such as the sfbuf allocator, and teach libmemstat(3) how to interface with them. _________________________________________________________________ Low-overhead performance monitoring for FreeBSD URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement Contact: Joseph Koshy Modern CPUs have on-chip performance monitoring counters (PMCs) that may be used to count low-level hardware events like instruction retirals, branch mispredictions, and cache misses. PMC architectures and capabilities vary between CPU vendors and between CPU generations from the same vendor, making the creation of portable applications difficult. This project implements a cross-platform PMC management API for applications, and implements the infrastructure to "virtualize" and manage these PMCs. The creation of performance analysis tools that use this infrastructure is also part of the project's goals. Work since the last status report: * Sampling mode support for P4 and AMD64 PMCs has been implemented. * A pmclog(3) API for parsing hwpmc(4) log files has been added. * A number of bugs in libpmc(3), hwpmc(4) and pmcstat(8) have been fixed. Future work: * Creating user documentation showing a few real-world uses of the currently available tools. * Testing, improving the stability of the code, and characterizing its overheads. * Implementing P5 PMC support. _________________________________________________________________ Move ARP out of routing table URL: http://people.freebsd.org/~qingli/ Contact: Qing Li I've sent the patch to jinmei@isl.rdc.toshiba.co.jp @KAME for review. I'm still waiting for feedback from Andre. There hasn't been any major change since the last report. I've kept the code in sync with CURRENT. Gleb has created a separate P4 branch and has been helping out on the locking side. Gleb is also helping out on the testing front. Open tasks: 1. I'm waiting for review feedback from my mentor Andre on the overall design and code. I'm waiting for feedback from Andre on Gleb's suggested modification. _________________________________________________________________ Network Interface API Cleanup URL: http://wikitest.freebsd.org/moin.cgi/CleanupOfNetworkIterfaceApis Contact: Anders Persson The goal of this project is to review the network interface API and try to remove references to kernel-only data structures by removing the use of libkvm and instead rely on other interfaces to provide information. If there are no adequate interfaces, they would be created. Currently netstat is being reviewed and parts of it have been modified to use sysctl rather than libkvm to provide the information. A big thank you to Brooks Davis for mentoring :-) _________________________________________________________________ Nsswitch / Caching daemon URL: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetail s URL: http://wikitest.freebsd.org/moin.cgi/MichaelBushkov Contact: Michael Bushkov The nsswitch / caching daemon project is being developed within the Google's Summer Of Code program. The first goal of this project is to implement a set of patches to extend the use of nsswitch subsystem. The second goal is the development of the caching library and daemon to add the caching ability to the nsswitch. Currently services, protocols, rpc and openssh patches are finished. Support for services, services_compat, rpc, protocols, and ssh_host_keys databases is added with 'files', 'nis' and 'compat' (for services) sources possible. The nsswitch-friendly openssh port is amlost completed. Open tasks: 1. Implement set of patches to make nsswitch support globus grid security files , MAC and audit related configuration files databases. 2. Implement the caching library and the caching daemon and patch nsdispatch function to support caching. _________________________________________________________________ OpenBSD dhclient import. Contact: Brooks Davis Contact: Sam Leffler The OpenBSD rewrite of dhclient has been imported, replacing the ISC dhclient. The OpenBSD client provides better support for roaming on wireless networks and a simpler model of operation. Instead of a single dhclient process per system, there is on per network interface. This instance automatically goes away in the even of link loss and is restarted via devd when link is reacquired. To support this change, many aspects of the network interface configuration process were overhauled. The current code works well in most circumstances, but more testing and polishing is needed. _________________________________________________________________ OpenBSD packet filter - pf Contact: Max Laier We will have pf as of OpenBSD 3.7 for RELENG_6. Import has been completed in early May and FreeBSD release 6.0 will ship with it. A few serious issues with pfsync on SMP have been discovered since CARP is around and more and more people use it on big iron. Everything that has been discovered is fixed in HEAD and (if applicable) MFCed back to RELENG_5. Some functional changes are undergoing testing right now and will be MFCed in the coming days. With the import of if_bridge from Net/OpenBSD we finally have a bridge implementation that allows for stateful filtering as well as IPv6 filtering. Please see the respective report. Open tasks: 1. Shared lock implementation? _________________________________________________________________ Porting v9 of Intels C/C++ Compiler Contact: Alexander Leidinger Intel released version 9 of its C/C++ compiler. Work to port the x86 version to FreeBSD is in progress as time permits. Porting the EM64T (amd64) version is on the TODO list too, but is subject to enough free time and access to appropriate hardware. _________________________________________________________________ PowerPC Port URL: http://www.freebsd.org/platforms/ppc.html Contact: Peter Grehan Florent Thoumie has updated the massively out-of-date platform page. Work continues to creating a 6.0 release of the PowerPC port. _________________________________________________________________ Removable interface improvements URL: http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/ URL: http://www.freebsd.org/projects/dingo/ Contact: Brooks Davis This project is an attempt to clean up handling of network interfaces in order to allow interfaces to be removed reliably. Current problems include panics if Dummynet is delaying packets to an interface when it is removed. I have removed struct ifnet's and layer two common structures from device driver structures. This will eventually allow them to be managed properly upon device removal. This code has been committed and will appear in 6.0. Popular drivers have generally been fixed, but more testing is needed. _________________________________________________________________ Removing of old basesystem files and directories URL: http://www.Leidinger.net/FreeBSD/current-patches/obsolete_removal.diff Contact: Alexander Leidinger FreeBSD lacks a way to remove old/outdated files and directories in the basesystem. I have a patch which removes obsolete files in a safe way (interactively, since only the administrator really knows if there's a need to keed an old file or not; there's a switch for batch-processing). This feature may or may not be available for 6.0-RELEASE, depending on the decission from the Release Engineering team. Open tasks: 1. Respect the NO_* switches and remove those files too. This is easy to do with the current implementation, but isn't needed to commit the removal of obsolete files feature. _________________________________________________________________ SEBSD URL: http://wikitest.freebsd.org/moin.cgi/YanjunWu Contact: Yanjun Wu 1. Setup a local P4 workspace of sebsd source and Setup lxr for TrustedBSD source for studying source code. 2. Test a simple policy configuration for vsftpd. 3. Writing a HOWTO document Getting Started with SEBSD HOWTO by deriving the existing Getting Started with SELinux HOWTO . Thanks Robert Watson and Scott Long for their kind help. Open tasks: 1. When writing the document, try to figure out the sebsd userland utils that need to be ported. 2. Test and edit more policies for BSD environment. _________________________________________________________________ SMP Network Stack URL: http://www.FreeBSD.org/projects/netperf/ Contact: Robert Watson Significant work has occurred over the last few months relating to the SMP network stack work. A few of the highlights are covered here at a high level: * The UMA(9) per-CPU caches have been modified to use critical sections instead of mutexes. Recent critical section optimizations make this a performance win for both UP and SMP systems. This results in a several percent improvement in a number of user space benchmarks, and larger improvement for kernel-only network forwarding and processing benchmarks. * The malloc(9) allocator has been modified to store statistics per-CPU instead of using a cross-CPU statistics pool, with each per-CPU pool now using critical sections to synchronize access. This results in a measurable performance win, especially on SMP systems * The netnatm ATM code is now MPSAFE. * netipx MPSAFEty has been merged to RELENG_5. * The netperf cluster has now been expanded to include two additional quad-CPU systems (one dual dual-core AMD system, one quad-CPU PIII system). * libmemsetat(3) (see separate report) now corrects SMP-related races in the measuring of mbuf allocator statistics, as well as substantially improving kernel memory monitoring capabilities and tools. * A range of locking bug fixes, and general network stack bug fixes. * Significant updates to the SMPng web page (still more to do!). * Identification of all non-MPSAFE network device drivers, with ultimatum issued, on freebsd-arch. Quite a bit of new driver locking work as a result (if_ed, if_de, ...). * Lots of other stuff. In most cases, these changes will appear in FreeBSD 6.0-RELEASE; some have been, or will be, merged to FreeBSD 5.x. On-going tasks include: * Review and improvement of ifnet locking, such as address lists and flags. * Optimization of interface start hand-off. * Prototyping of queue-oriented packet hand-off in the stack. * Performance measurement and analysis. * Prototype rewrite and simplification of socket locking. _________________________________________________________________ TCP Reassembly Rewrite and Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch URL: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/005918.ht ml Contact: Andre Oppermann Currently TCP segment reassembly is implemented as a linked list of segments. With today's high bandwidth links and large bandwidth*delay products this doesn't scale and perform well. The rewrite optimizes a large number of operational aspects of the segments reassembly process. For example it is very likely that the just arrived segment attaches to the end of the reassembly queue, so we check that first. Second we check if it is the missing segment or alternatively attaches to the start of the reassembly queue. Third consecutive segments are merged together (logically) and are skipped over in one jump for linear searches instead of each segment at a time. Further optimizations prototyped merge consecutive segments on the mbuf level instead of only logically. This is expected to give another significant performance gain. The new reassembly queue is tracking all holes in the queue and it may be beneficial to integrate this with the scratch pad of SACK in the future. Andrew Gallatin was able to get 3.7Gb/sec TCP performance on dual-2Gbit Myrinet cards with severe packet reordering (due to a firmware bug) with the new TCP reassembly code. See second link. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/doc/nl/books/handbook URL: http://www.evilcoder.org/content/section/6/39/ URL: http://www.evilcoder.org/freebsd_html/ URL: http://www.evilcoder.org/freebsd/flyer.pdf Contact: Remko Lodder Contact: Siebrand Mazeland Contact: Rene Ladan The FreeBSD Dutch Documentation Project is a ongoing project in translating the english documentation to the Dutch language. Currently we are almost done with the FreeBSD Handbook. Finishing the Handbook is our first priority, and we could use your help. Please contact Siebrand or myself if you want to helpout. After the handbook we will focus on other documents as well, so feel free to help us there as well Open tasks: 1. FreeBSD Handbook translation. Finish the translation from English to Dutch 2. FreeBSD Handbook review. Finish the review of the translated documents 3. FreeBSD Articles. Start translating the articles from English to the Dutch Language 4. FreeBSD www. Start translating the website from English to the Dutch Language 5. The rest of the FreeBSD Documents. Start translating them from English to the Dutch Language. _________________________________________________________________ TODO list for volunteers Contact: Alexander Leidinger Since Google's "Summer of Code" resulted in a lot of interest in open projects, I'm in the process of compiling a list of nice projects for volunteers. Unlike Google's SoC those projects aren't backed with money (but this doesn't means nobody is allowed to sponsor one of those projects), so we can only guarantee the social aspects (some "Thank you!" and "That's great!" messages). So far the list has several entries where the difficulty ranges from "someone just has to sit down and spend some time on it" up to "we need a guru for this". Open tasks: 1. Merging untaken entries from the SoC list as soon as the official participants/tasks in the SoC are announced. 2. Sending the document to some doc people for review. 3. Commit the list. _________________________________________________________________ Transparent support for superpages in the FreeBSD Kernel Contact: Alan L. Cox Contact: Olivier Crameri We are currently working on an updated implementation of Juan Navarro's transparent support for superpages in FreeBSD The idea is to take advantage of the architectural support for big memory pages (superpages) by using a reservation mechanism allowing us to transparently promote groups of base pages into superpages and demote superpages into several smaller superpages or base pages. The advantage of using superpages vs. base pages is to significantly improve the TLB coverage of the physical memory, thus improving the peformance by reducing the number of TLB misses. The modification of the FreeBSD kernel that we are working on involves the replacement of the current list based page allocation mechanism with a system using a buddy allocator to reserve groups of pages for a memory object. The promotion and demotion of the pages occur directly within the pmap module. The former implementation was supporting the alpha and IA64 architectures. We are adding the support for amd64. We currently have an almost complete implementation. Once completed we will make a performance study with a particular emphasis on TLB and cache misses. _________________________________________________________________ TrustedBSD Audit URL: http://www.trustedbsd.org/components.html#audit Contact: Robert Watson Contact: Wayne Salamon Contact: In the past few months, significant work has been done relating to the TrustedBSD audit implementation, including preparatory work to merge audit into the FreeBSD CVS repository for FreeBSD 6.x. In particular: * The user space components, such as libbsm, include files, and command line utilities have been broken out into an OpenBSM distribution in Perforce. Improvements in OpenBSM will be made available separately for use by projects such as Darwin, and imported into the contrib area of FreeBSD. * The system call table format has been updated to include an audit event identifier for each system call across all hardware platforms and ABIs (merged), and all system calls have been assigned event identifiers (not yet merged). * The audit management daemon has been rewritten to run on FreeBSD (originally derived from Darwin) using /dev/audit to track kernel events. * Many system calls now properly audit their arguments. * The TrustedBSD audit3 branch has been updated to a recent 6.x-CURRENT. * Significant work has gone into synchronizing the audit event tables between FreeBSD, Darwin, and OpenSolaris to make sure file formats and events are portable. * OpenBSM has been adapted to consume and generate endian-independent event streams. * OpenBSM documentation has been created. The hope is still to provide audit as "experimental" in 6.0; the primary blocking factor is our awaiting relicensing of the last remaining audit files from Apple's APSL license to BSDL so that they can be included in the FreeBSD kernel. This is anticipated to complete in the near future. Once this is done, the changes can be merged to CVS, and then MFC'd to RELENG_6. If this is not complete by 6.0-RELEASE, the work will be merged shortly after the release, as all ABI-sensitive data structures have been updated as needed. _________________________________________________________________ TrustedBSD SEBSD URL: http://www.TrustedBSD.org/sebsd.html Contact: Robert Watson The TrustedBSD Project has released a new snapshot of "SEBSD", a port of NSA's SELinux FLASK and Type Enforcement implementation to FreeBSD based on a late 2005 FreeBSD 6.x snapshot. The SEBSD distribution has now been updated in Perforce to a recent 6.x snapshot, and a new distribution will be made available in the near future. Work has been performed to merge additional dependencies for SEBSD back into the base FreeBSD tree, including most recently, changes to devfs, and System V and POSIX IPC. Open tasks: 1. Update to new NSA FLASK implementation, which has improved MLS support. 2. Merge remaining kernel changes to support SEBSD back to the base FreeBSD CVS repository, including file descriptor labeling and access control (in contrast to file labeling and access control), and categorization of kernel privileges. _________________________________________________________________ TTCPv2: Transactional TCP version 2 URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://lists.freebsd.org/pipermail/cvs-all/2004-November/089939.html Contact: Andre Oppermann The old TTCP according to RFC1644 was insecure, intrusive, complicated and has been removed from FreeBSD >= 5.3. Although the idea and semantics behind it are still sound and valid. The rewrite uses a much easier and more secure system with 24bit long client and server cookies which are transported in the TCP options. Client cookies protect against various kinds of blind injection attacks and can be used as well to generally secure TCP sessions (for BGP for example). Server cookies are only exchanged during the SYN-SYN/ACK phase and allow a server to ensure that it has communicated with this particular client before. The first connection is always performing a 3WHS and assigning a server cookie to a client. Subsequent connections can send the cookie back to the server and short-cut the 3WHS to SYN->OPEN on the server. TTCPv2 is fully configurable per-socket via the setsockopt() system call. Clients and server not capable of TTCPv2 remain fully compatible and just continue using the normal 3WHS without any delay or other complications. Work on implementing TTCPv2 is done to 90% and expected to be available by early February 2005. Writing the implementation specification (RFC Draft) has just started. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ UFSJ -- Journaling for UFS Contact: Brian Wilson Contact: Scott Long filesystem. Journaling helps ensure the filesystem's integrity should the system crash. Journaling eliminates the need for fsck'ing a filesystem, as the filesystem is never in an inconsistent state (barring hardware failure). This implementation is inspired by Darwin's HFS+ filesystem and the SGI XFS filesystem. This is a Summer of Code project, with Scott Long as the mentor and Brian Wilson as the developer/mentee. Currently this project is still in the early stages, but will be in a usable state by September 1 (the Google Summer of Code completion date). Open tasks: 1. Finish making the file system log metadata updates. 2. Add facilities to replay the log on dirty file systems. 3. Make snapshots work with journaling. _________________________________________________________________ Update of the Linux userland infrastructure Contact: Alexander Leidinger Contact: Emulation Mailinglist The cleanup/streamlining and the possibility of overriding the default Linux base as reported in the last report happened without major problems. Work on the open tasks hasn't started yet, but is scheduled to start "soon". If a volunteer wants to spend some hours on one of the open tasks, he should tell it on the emulation mailinglist. Open tasks: 1. Refactoring the common RPM code in x11-toolkits/linux-gtk/Makefile into bsd.rpm.mk. 2. Determining which up-to-date Linux distribution to use as the next default Linux base. Important criteria: + RPM based (to be able to use the existing infrastructure) + good track record regarding availability of security fixes + packages available from several mirror sites + available for several hardware architectures (e.g. i386, amd64, sparc64; Note: not all architectures have a working linuxolator for their native bit with, but as long as there are no userland bits available, no motivation regarding writing the kernel bits will arise) 3. Moving the linuxolator userland to an up-to-date version (see above). _________________________________________________________________ VFS SMP Contact: Jeff Roberson FreeBSD's VFS layer has been fine grain locked along with the FFS filesystem for the FreeBSD 6.0 release. The locking has been underway for several years, with the project really picking up over the last 6 months thanks largely to sponsorship provided by Isilon Systems, Inc. a leading vendor of clustered storage systems. The project has entered a stabilization phase, with a few bugs being reported in extreme circumstances while the majority of users have seen no problems. Tests on a 8 and 16 way machines yield reasonable parallelization, however, it will be beneficial to do lock contention analysis once things are fully stable. For those interested in technical details, there have been a few relatively significant changes with vnode life-cycle management. Vnode reference counting and recycling is now no longer an ad-hoc process involving a variety of flags, a use count and the hold count. A single hold count is used to track all vnode references and a destroyed vnode is freed in the context of the caller when the last ref is lost. The old system would never reclaim memory used by vnodes and also had pathlogical behavior with unreferenced vnode caching under pressure. The new system is much simpler than the old one, however, callers are now required to vhold a vnode that they lock directly without going through vget to prevent it from being recycled while they are waiting on a lock. Relying on 'location stable storage', which is a more strict version of 'type stable storage' is no longer a valid approach. Some other side effects include a much simpler and faster nullfs implementation, an improved buf daemon flushing algorithm which eliminated high latency that caused audio skipping, and a lots of minor cleanups and debugging aids. _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler A lot of bugs were fixed in preparation for the 6.0 release. 6.0 will be the first release to include full WPA support (both supplicant and authenticator). A presentation on the forthcoming multi-bss support was given at BSDCan 2005. The slides from the talk are available at http://www.freebsd.org/~sam/BSDCan2005.pdf . The plan is to commit this work to HEAD after 6.0 is released which means the first release that will have it is 7.0. Open tasks: 1. hostapd needs work to support the IAPP and 802.11i preauthentication protocols (these are simple conversions of existing Linux code). _________________________________________________________________ --------------080004040504090205090707-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 18:58: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 E658216A45D for ; Fri, 22 Jul 2005 18:58:23 +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 81E7A43D5E for ; Fri, 22 Jul 2005 18:58:18 +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 8C4AB46B3F; Fri, 22 Jul 2005 14:58:17 -0400 (EDT) Date: Fri, 22 Jul 2005 19:58:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Robbins In-Reply-To: <20050722134713.GB60396@uws1.starlofashions.com> Message-ID: <20050722195724.P40216@fledge.watson.org> References: <42E0F645.407@drexel.edu> <20050722134713.GB60396@uws1.starlofashions.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: How stable is current, now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 18:58:24 -0000 On Fri, 22 Jul 2005, Scott Robbins wrote: > On Fri, Jul 22, 2005 at 09:36:05AM -0400, Justin R. Smith wrote: >> Hi all! >> >> FreeBSD jsmith.org 5.4-STABLE FreeBSD 5.4-STABLE #0: Thu Jul 14 12:35:12 EDT >> 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 >> >> now and considering upgrading to 6.0. Is this system fairly usable now? > > Well, remember it's beta, but I've been running it on my workstation > with no issues. I'm holding off putting it on the servers though. :) I moved my personal web/shell server to 6.x last week with the advent of the beta. It seems to be working quite well, and the server does quite a bit of work. The one caution I'd have is that the library versions are all in the throes of changing, and since there aren't compat5x packages yet, you'll want to do an incremental update from 5.x to 6.x so that the old 5.x libraries are still available to run older applications against. This will be fixed with the next beta, but it sounded like David won't get to that until after the weekend. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 19:14: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 82D4616A41F for ; Fri, 22 Jul 2005 19:14:26 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0594F43D46 for ; Fri, 22 Jul 2005 19:14:25 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j6MJEItj019814; Fri, 22 Jul 2005 15:14:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050722174802.GS39292@obiwan.tataz.chchile.org> References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> <20050722174802.GS39292@obiwan.tataz.chchile.org> Date: Fri, 22 Jul 2005 15:14:17 -0400 To: Jeremie Le Hen , Ken Smith From: Garance A Drosihn 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.3 Cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 19:14:26 -0000 At 7:48 PM +0200 7/22/05, Jeremie Le Hen wrote: >Hi Ken, hi all, > >> It will take a while for the fallout from this version bump to > > propagate. People who cvsup/rebuild existing systems should not > > be impacted immediately - you will still have the older library > > versions present on your systems. However it will take time for > > the pre-built packages provided by the portmgr folks to be rebuilt, > > loaded onto the FTP servers, and propagate out to the mirrors. > >I know that FreeBSD is still lacking a solution to remove old ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >librairies, but I would like to know the actual recommended way >to remove old libraries. ... But I would like to hear what >others do to achieve this. In short, I'm looking for a >neat solution. ^^^^^^^^^^^^^^^ If someone *had* a neat solution, one which everyone agreed was a neat, workable, reliable solution, then FreeBSD would not be lacking a solution... :-) I have my own way of dealing with this, and I am comfortable with it, but I would not call it neat. It works "well enough" for me, but might not work for others. I only have four or five machines I have to worry about, so I can get by with a messy solution. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 19:25: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 E0CFB16A41F; Fri, 22 Jul 2005 19:25:20 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E48C43D49; Fri, 22 Jul 2005 19:25:20 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6MJPJo5016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jul 2005 12:25:20 -0700 Message-ID: <42E1481F.5040306@root.org> Date: Fri, 22 Jul 2005 12:25:19 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: acpi battery rework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 19:25:21 -0000 I have completed a rework of the battery subsystem and would like testing of the patch. I'd like this to go into 6.0. It should have no effect for people with working batteries and fixes some bugs for those who don't. It also makes it possible to import support for smart batteries (not in this patch). API changes: apm compatibility device: no change sysctl: no change kernel function call: API reduced. ioctl: API reduced. kernel function access: Access individual batteries via devclass_find("battery"). Methods are ACPI_BATT_GET_STATUS (for _BST-formatted data) and ACPI_BATT_GET_INFO (for _BIF-formatted data). The helper function acpi_battery_get_battinfo() has been changed to take a device_t instead of unit # argument. If dev is NULL, this signifies all batteries. ioctl access: The ACPIIO_BATT_GET_TYPE and ACPIIO_BATT_GET_BATTDESC ioctls have been removed. Since there is no mapping between "virtual" unit and actual unit, just specify the unit directly and skip the old translation steps. For instance, in the future if you have two smart batteries and two control-method batteries, they'll be battery0-3. Patch can be found here: http://root.org/~nate/freebsd/batt-rework.diff.gz Please test to be sure your battery status works as usual, along with any apps. Since most apps (xbatt, gnome, etc.) use the apm compat layer, they should work as before with no recompilation needed. -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 19:38: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 2837316A41F for ; Fri, 22 Jul 2005 19:38:27 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01ECE43D4C for ; Fri, 22 Jul 2005 19:38:25 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:XGdl+HrW3O7dq3zk6T6wU6StKBuJNbu4SATXF0EJeZvTedzjWcp0J/93vNNfoNWB@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j6MJcKi2087726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Jul 2005 04:38:20 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 23 Jul 2005 04:38:03 +0900 Message-ID: From: Hajimu UMEMOTO To: current@FreeBSD.org References: <200507221821.j6MILSbp028681@repoman.freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.0-CURRENT X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_Jul_23_04:38:02_2005-1" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 23 Jul 2005 04:38:20 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: Subject: HEADS-UP: ABI compatibility of getaddrinfo(3) was lost. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 19:38:27 -0000 --Multipart_Sat_Jul_23_04:38:02_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, I've nuked the padding for ai_addrlen member of struct addrinfo. It broke ABI compatibility of getaddrinfo(3) on 64 bit architecture. You have to recompile userland programs that use getaddrinfo(3) on 64 bit architecture. Sincerely, --Multipart_Sat_Jul_23_04:38:02_2005-1 Content-Type: message/rfc822 X-Sieve: CMU Sieve 2.2 Delivered-To: ume@freebsd.org X-Original-To: src-committers@FreeBSD.org Delivered-To: src-committers@FreeBSD.org Message-Id: <200507221821.j6MILSbp028681@repoman.freebsd.org> From: Hajimu UMEMOTO Date: Fri, 22 Jul 2005 18:21:28 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/include netdb.h src/lib/libc/net getaddrinfo.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [218.45.22.175]); Sat, 23 Jul 2005 03:36:26 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org ume 2005-07-22 18:21:28 UTC FreeBSD src repository Modified files: include netdb.h lib/libc/net getaddrinfo.c Log: Remove padding for ABI compatibility of ai_addrlen member from struct addrinfo. This change break ABI compatibility on 64 bit arch. Revision Changes Path 1.39 +0 -19 src/include/netdb.h 1.70 +0 -3 src/lib/libc/net/getaddrinfo.c --Multipart_Sat_Jul_23_04:38:02_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_Jul_23_04:38:02_2005-1-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 19:41: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 4C01916A41F for ; Fri, 22 Jul 2005 19:41:02 +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 B7C7643D49 for ; Fri, 22 Jul 2005 19:41:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 22 Jul 2005 15:55:16 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 22 Jul 2005 15:39:54 -0400 User-Agent: KMail/1.8 References: <20050717020946.GA42304@crodrigues.org> In-Reply-To: <20050717020946.GA42304@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507221539.55166.jhb@FreeBSD.org> Cc: Craig Rodrigues Subject: Re: Problem compiling sched_ule.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: Fri, 22 Jul 2005 19:41:02 -0000 On Saturday 16 July 2005 10:09 pm, Craig Rodrigues wrote: > Hi, > > After the recent changes to the macros to atomic.h, I am getting > compilation warnings in sched_ule.c. > > /usr/src/sys/kern/sched_ule.c: In function `kseq_assign': > /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 1 of > `atomic_cmpset_int' from incompatible pointer type > /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 2 of > `atomic_cmpset_int' makes integer from pointer without a cast > /usr/src/sys/kern/sched_ule.c:654: warning: passing arg 3 of > `atomic_cmpset_int' makes integer from pointer without a cast > /usr/src/sys/kern/sched_ule.c: In function `kseq_notify': > /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 1 of > `atomic_cmpset_int' from incompatible pointer type > /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 2 of > `atomic_cmpset_int' makes integer from pointer without a cast > /usr/src/sys/kern/sched_ule.c:691: warning: passing arg 3 of > `atomic_cmpset_int' makes integer from pointer without a cast *** Error > code 1 > > > Is this the correct way to fix this: > > > --- /usr/src/sys/kern/sched_ule.c.orig Sat Jul 16 21:42:07 2005 > +++ /usr/src/sys/kern/sched_ule.c Sat Jul 16 22:09:00 2005 > @@ -651,7 +651,8 @@ > > do { > *(volatile struct kse **)&ke = kseq->ksq_assigned; > - } while(!atomic_cmpset_ptr(&kseq->ksq_assigned, ke, NULL)); > + } while(!atomic_cmpset_ptr((uintptr_t *)&kseq->ksq_assigned, > + (uintptr_t)ke, (uintptr_t)NULL)); > for (; ke != NULL; ke = nke) { > nke = ke->ke_assign; > kseq->ksq_group->ksg_load--; > @@ -688,7 +689,8 @@ > */ > do { > *(volatile struct kse **)&ke->ke_assign = kseq->ksq_assigned; > - } while(!atomic_cmpset_ptr(&kseq->ksq_assigned, ke->ke_assign, ke)); > + } while(!atomic_cmpset_ptr((uintptr_t *)&kseq->ksq_assigned, > + (uintptr_t)ke->ke_assign, (uintptr_t)ke)); > /* > * Without sched_lock we could lose a race where we set NEEDRESCHED > * on a thread that is switched out before the IPI is delivered. This Yes. -- 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 Jul 22 20: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 E325D16A41F for ; Fri, 22 Jul 2005 20:09:45 +0000 (GMT) (envelope-from pinhead@delicious.stderror.at) Received: from stdin.stderror.at (stdin.stderror.at [83.65.196.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 127CC43D46 for ; Fri, 22 Jul 2005 20:09:44 +0000 (GMT) (envelope-from pinhead@delicious.stderror.at) Received: from bluebook.stderror.at (83-65-196-92.work.xdsl-line.inode.at [83.65.196.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stdin.stderror.at (Postfix) with ESMTP id EACBDA181 for ; Fri, 22 Jul 2005 22:09:40 +0200 (CEST) Received: from bluebook.stderror.at (localhost [127.0.0.1]) by bluebook.stderror.at (8.13.3/8.13.3) with ESMTP id j6MK9m1A000740 for ; Fri, 22 Jul 2005 22:09:49 +0200 (CEST) (envelope-from pinhead@delicious.stderror.at) Received: (from pinhead@localhost) by bluebook.stderror.at (8.13.3/8.13.3/Submit) id j6MK9mEo000739 for freebsd-current@freebsd.org; Fri, 22 Jul 2005 22:09:48 +0200 (CEST) (envelope-from pinhead) Date: Fri, 22 Jul 2005 22:09:48 +0200 From: Toni Schmidbauer To: freebsd-current@freebsd.org Message-ID: <20050722200948.GA636@stderror.at> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Phone: +43 664 3502198 X-WWW-Home-Page: http://stderror.at X-PGP-Fingerprint: 53F2 28AE 8070 83E0 AFEC 0ABC BBF9 A34A 3ED1 3287 X-Operating-System: FreeBSD User-Agent: mutt-ng devel (FreeBSD) Subject: 6.0 BETA1 if_ath problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: toni@stderror.at List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 20:09:46 -0000 hi, i'm using an ibm x40 with a built in ath card (5212). problem is, i can associate with my ap, but pinging the ap or another notebook in my wlan doesn't work. when i try to ping the x40 from a powerbook in the same wlan, tcpdump -y IEEE802_11 show's the following: 21:42:31.738373 Beacon () [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 6, PRIVACY 21:42:31.741746 Data IV:f56aa6 Pad 0 KeyID 0 21:42:31.743005 Data IV:285d95 Pad 3 KeyID 1 21:42:31.744328 Data IV:285d95 Pad 3 KeyID 1 21:42:31.745938 Data IV:285d95 Pad 3 KeyID 1 21:42:31.747294 Data IV:285d95 Pad 3 KeyID 1 21:42:31.748760 Data IV:285d95 Pad 3 KeyID 1 21:42:31.753347 Data IV:285d95 Pad 3 KeyID 1 21:42:31.755550 Data IV:285d95 Pad 3 KeyID 1 21:42:31.840772 Beacon () [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 6, PRIVACY 21:42:31.841604 arp who-has 192.168.170.37 tell 192.168.170.36 21:42:31.841660 arp reply 192.168.170.37 is-at 00:0e:9b:c6:8a:79 (oui Unknown) 192.168.170.37 is the x40 192.168.170.36 is the powerbook the x40 sends an arp reply, which never reaches the powerbook. pinging the ap from the powerbook works and i can see the echo-request and reply packets via tcpdump on the x40. here's my ifconfig ath0 output: ath0: flags=8843 mtu 1500 inet 192.168.170.37 netmask 0xfffffff8 broadcast 192.168.170.39 inet6 fe80::20e:9bff:fec6:8a79%ath0 prefixlen 64 scopeid 0x3 ether 00:0e:9b:c6:8a:79 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid stderror channel 6 bssid 00:0f:66:c7:82:66 authmode OPEN privacy ON deftxkey UNDEF wepkey 1:104-bit <11111111111111111111111111> txpowmax 50 protmode CTS bintval 100 dmesg: ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:0e:9b:c6:8a:79 ath0: mac 5.9 phy 4.3 radio 3.6 i already reported problems with ath under 5.4, http://lists.freebsd.org/pipermail/freebsd-mobile/2005-July/006742.html so it seems things are getting better under 6.0. thanks for your time + help regards toni -- Wer es einmal so weit gebracht hat, dass er nicht | toni at stderror dot at mehr irrt, der hat auch zu arbeiten aufgehoert | Toni Schmidbauer -- Max Planck | From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 20:15: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 D231E16A41F for ; Fri, 22 Jul 2005 20:15:08 +0000 (GMT) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx2.synetsystems.com (mx2.synetsystems.com [216.226.140.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CBE143D45 for ; Fri, 22 Jul 2005 20:15:08 +0000 (GMT) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id BF517237; Fri, 22 Jul 2005 16:15:06 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.51 (FreeBSD)) id 1Dw3eI-000EMs-Lx for freebsd-current@freebsd.org; Fri, 22 Jul 2005 14:57:34 -0500 To: freebsd-current@freebsd.org References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> <20050722174802.GS39292@obiwan.tataz.chchile.org> From: Richard Todd Date: Fri, 22 Jul 2005 14:57:34 -0500 In-Reply-To: (Jeremie Le Hen's message of "Fri, 22 Jul 2005 19:48:02 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 20:15:08 -0000 Jeremie Le Hen writes: > I know that FreeBSD is still lacking a solution to remove old > librairies, but I would like to know the actual recommended way > to remove old libraries. I'm not asking for a solution as NetBSD's > /etc/postinstall, just a simple and neat one. I can think of number > of such solutions, like searching for libraries dating before the > last world, parsing Makefiles from src/ to deduce which libs are > obsolete, ldd on each binary ... But I would like to hear what others > do to achieve this. In short, I'm looking for a neat solution. libchk (/usr/ports/sysutils/libchk) is a nice Python script that automates the "ldd on each binary" bit and gives you a list of .sos that aren't being used by anything. You do have to eyeball the list before doing a mass purge of any unreferenced .sos, as there are some apps (Mozilla/Firefox is one IIRC) which have .so files which are loaded by the program as needed but which don't show up as fixed dependencies via ldd. Still, the libchk list ought to at least give you a starting point. From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 20: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 7C32216A41F for ; Fri, 22 Jul 2005 20:49:17 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3D7543D45 for ; Fri, 22 Jul 2005 20:49:16 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd23.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1Dw4SI-00018m-00; Fri, 22 Jul 2005 22:49:14 +0200 Received: from Andro-Beta.Leidinger.net (XNxp12ZEYeiRYmgOs7cq4iJmPYJfxl+8bz--TF63Iy8-W3VodVybc8@[84.165.254.175]) by fwd23.sul.t-online.de with esmtp id 1Dw4S4-1nfVOC0; Fri, 22 Jul 2005 22:49:00 +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 j6MKmx3e037591; Fri, 22 Jul 2005 22:49:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Fri, 22 Jul 2005 22:48:59 +0200 From: Alexander Leidinger To: Jeremie Le Hen Message-ID: <20050722224859.5bd68ff7@Magellan.Leidinger.net> In-Reply-To: <20050722174802.GS39292@obiwan.tataz.chchile.org> References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> <20050722174802.GS39292@obiwan.tataz.chchile.org> X-Mailer: Sylpheed-Claws 1.9.12 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: XNxp12ZEYeiRYmgOs7cq4iJmPYJfxl+8bz--TF63Iy8-W3VodVybc8@t-dialin.net X-TOI-MSGID: b31d38ad-70cc-41a8-9f9b-352438ca896b Cc: Ken Smith , freebsd-current@freebsd.org Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 20:49:17 -0000 On Fri, 22 Jul 2005 19:48:02 +0200 Jeremie Le Hen wrote: > Hi Ken, hi all, > > > It will take a while for the fallout from this version bump to > > propagate. People who cvsup/rebuild existing systems should not be > > impacted immediately - you will still have the older library versions > > present on your systems. However it will take time for the pre-built > > packages provided by the portmgr folks to be rebuilt, loaded onto the > > FTP servers, and propagate out to the mirrors. > > I know that FreeBSD is still lacking a solution to remove old > librairies, but I would like to know the actual recommended way > to remove old libraries. I'm not asking for a solution as NetBSD's > /etc/postinstall, just a simple and neat one. The patch at http://www.Leidinger.net/FreeBSD/current-patches/obsolete_removal.diff is scheduled to be committed at Saturday or Sunday. I've the approval of my mentor since some weeks but the code freeze for 6.0 jumped into my way. re@ had some issues with it, I've changed some things, and now I have time and no freeze in my way. :-) The patch provides update UPDATING instructions and documentation in the build(7) man-page. In short: "make delete-old delete-old-libs" in /usr/src. Nothing gets deleted without your approval (except you read the docs and provide the right magic spell)! Notes: * The list of files/libs/dirs is static and I hadn't time to add the "new old libs". I will build a new world tomorrow and add those libs before I commit the patch. * Everyone who wants to come up with a different way of storing the list of files or adopting the NetBSD way (mtree): forget about it, I had this discussion several times and the commit log will contain the reasons why the current implementation is better. 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 Jul 22 21:35: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 680B616A41F for ; Fri, 22 Jul 2005 21:35:37 +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 33371440C7 for ; Fri, 22 Jul 2005 21:16:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 22 Jul 2005 17:30:32 -0400 From: John Baldwin To: freebsd-current@freebsd.org, Ben Kaduk Date: Fri, 22 Jul 2005 15:44:34 -0400 User-Agent: KMail/1.8 References: <47d0403c05071713131a0689ee@mail.gmail.com> In-Reply-To: <47d0403c05071713131a0689ee@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507221544.35384.jhb@FreeBSD.org> Cc: Subject: Re: curiousities in 6.0beta1 dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 21:35:37 -0000 On Sunday 17 July 2005 04:13 pm, Ben Kaduk wrote: > Hi all, > > I recently upgraded to: > bash-2.05b$ uname -a > FreeBSD prolepsis.math.uiuc.edu 6.0-BETA1 FreeBSD 6.0-BETA1 #2: Sat > Jul 16 21:34:06 UTC 2005 > kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 > > from 5.4-Release using a source upgrade, and I noticed a few things in the > dmesg whilst it was booting that struck me as a bit odd. > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-BETA1 #2: Sat Jul 16 21:34:06 UTC 2005 > kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.50GHz (2492.65-MHz 686-class > CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebf9ffV,PAT, PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x4400> > real memory = 1073405952 (1023 MB) > avail memory = 1037340672 (989 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pci_link0: irq 11 on acpi0 > pci_link1: irq 11 on acpi0 > > > [ pci_link1 seems to have an irq here. . . ] > > > pci_link2: irq 11 on acpi0 > pci_link3: irq 11 on acpi0 > pci_link4: on acpi0 > pci_link5: irq 11 on acpi0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > acpi_acad0: on acpi0 > acpi_cmbat0: on acpi0 > acpi_cmbat1: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci_link1: Unable to choose an IRQ > > > [ so why does it need to choose an irq here? ] It's not quite that simple. :( It may be that the link says that irq 11 is not valid. Can you provide a verbose dmesg? -- 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 Jul 22 22:17: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 9A56D16A41F for ; Fri, 22 Jul 2005 22:17:19 +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 390C543D46 for ; Fri, 22 Jul 2005 22:17:19 +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 E492FC016; Sat, 23 Jul 2005 00:17:17 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 678224080; Sat, 23 Jul 2005 00:17:03 +0200 (CEST) Date: Sat, 23 Jul 2005 00:17:03 +0200 From: Jeremie Le Hen To: Alexander Leidinger Message-ID: <20050722221703.GU39292@obiwan.tataz.chchile.org> References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> <20050722174802.GS39292@obiwan.tataz.chchile.org> <20050722224859.5bd68ff7@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722224859.5bd68ff7@Magellan.Leidinger.net> User-Agent: Mutt/1.5.9i Cc: Ken Smith , Jeremie Le Hen , freebsd-current@freebsd.org Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 22:17:19 -0000 Hi Alexander, > The patch at > http://www.Leidinger.net/FreeBSD/current-patches/obsolete_removal.diff > is scheduled to be committed at Saturday or Sunday. I've the approval > of my mentor since some weeks but the code freeze for 6.0 jumped into > my way. re@ had some issues with it, I've changed some things, and now > I have time and no freeze in my way. :-) > > The patch provides update UPDATING instructions and documentation in > the build(7) man-page. In short: "make delete-old delete-old-libs" > in /usr/src. Nothing gets deleted without your approval (except you > read the docs and provide the right magic spell)! > > Notes: > * The list of files/libs/dirs is static and I hadn't time to add > the "new old libs". I will build a new world tomorrow and add those > libs before I commit the patch. This is really great work !! Thank you. This is the neat solution I was looking for. I'm going to wait for Ken to bump libraries versions in RELENG_6 and for you to MFC this before upgrading my RELENG_5. > * Everyone who wants to come up with a different way of storing the > list of files or adopting the NetBSD way (mtree): forget about it, I > had this discussion several times and the commit log will contain the > reasons why the current implementation is better. I'm not sure to follow you here. I saw that current library names are contained in /etc/mtree/set.base, but I don't see where it is used OTOH, I check /etc/postinstall too, especially the obsolete_libs() function, it appears that it returns the name of all .so except the one with the greatest version number. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 22:50: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 21BA616A41F for ; Fri, 22 Jul 2005 22:50:29 +0000 (GMT) (envelope-from brian@aljex.com) Received: from s1tank.virtdom.com (s1tank.virtdom.com [216.240.101.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 7DB3A43D4C for ; Fri, 22 Jul 2005 22:50:28 +0000 (GMT) (envelope-from brian@aljex.com) Received: (qmail 85674 invoked by uid 89); 22 Jul 2005 23:06:40 -0000 Received: from ool-43552092.dyn.optonline.net (HELO venti) (brian@aljex.com@67.85.32.146) by s1tank.virtdom.com with SMTP; 22 Jul 2005 23:06:40 -0000 Message-ID: <01cf01c58f0f$bf330340$6b00000a@venti> From: "Brian K. White" To: References: <42E117D2.000001.30495@soapbox.yandex.ru> Date: Fri, 22 Jul 2005 18:49:57 -0400 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: splash_bmp (Feature request) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 22:50:29 -0000 ----- Original Message ----- From: "Alexander Polakov" To: Sent: Friday, July 22, 2005 11:59 AM Subject: splash_bmp (Feature request) > Why splash_bmp kernel module cannot be used to show images not only in > boot time, but later, on running system? I don't think it will be a big > rewrite, but an interesting feature. It does. One of the console screen savers displays the boot splash and gradually fades it to black. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 22:53: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 6B24A16A41F for ; Fri, 22 Jul 2005 22:53:46 +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 1A35743D45 for ; Fri, 22 Jul 2005 22:53:46 +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 EB5BA322CF7 for ; Sat, 23 Jul 2005 00:53:44 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 7AEA0407E; Sat, 23 Jul 2005 00:53:32 +0200 (CEST) Date: Sat, 23 Jul 2005 00:53:32 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20050722225332.GV39292@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: Dingo project: acx(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: Fri, 22 Jul 2005 22:53:46 -0000 Hi all, I'm not sure this is the right list to send this, but this is a kind of fallback. While reading the FreeBSD status report, the Dingo part, I decided to have a look at Dingo's goals to freshen up my memory. I saw that it is planned to import the pff(4) driver. I would like to point to developpers that Darron Broad coded the acx(4) driver for the chip which has the same name. The driver is an interpretation of the corresponding Linux driver. It works for most card for what I heard, except for those based on ACX111. I would like to know if it is an option to include his driver in the source tree given that it's working well (the lastest version support the new 80211 framework), and that it would be a pity if this driver was forgotten and never really exploited, IMHO. http://wlan.kewl.org/ Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 22:58: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 6EBF416A41F for ; Fri, 22 Jul 2005 22:58:48 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn.tucs-beachin-obx-house.com [204.107.90.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01D9643D45 for ; Fri, 22 Jul 2005 22:58:47 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (ool-44c511d8.dyn.optonline.net [68.197.17.216]) (authenticated bits=128) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id j6MMwkSH047148 for ; Fri, 22 Jul 2005 18:58:47 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.12.10) with ESMTP id j6MMwe4H042820 for ; Fri, 22 Jul 2005 18:58:41 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.13.1/Submit) id j6MMwemi042819 for freebsd-current@freebsd.org; Fri, 22 Jul 2005 18:58:40 -0400 (EDT) (envelope-from tbohml) From: Tuc at T-B-O-H Message-Id: <200507222258.j6MMwemi042819@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-current@freebsd.org Date: Fri, 22 Jul 2005 18:58:40 -0400 (EDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Syslog not logging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 22:58:48 -0000 Hi, I'm trying to get syslog to log output from a 7 machines and 4 routers, all in the same subnet. My syslog is started as such : 301 ?? Ss 0:19.82 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -a 192.168.3.0/24 my syslog.conf has : *.debug /var/log/spool For all the servers, everything is perfect. Its the routers that are a problem. When I TCPDUMP it, I get : 18:50:56.736979 IP 192.136.64.2.8888 > 192.136.64.108.514: UDP, length: 125 0x0000: 4500 0099 fe35 4000 4011 3a9f c088 4002 E....5@.@.:...@. 0x0010: c088 406c 22b8 0202 0085 b42b 3c31 343e ..@l"......+<14> 0x0020: 6634 3830 3270 2d32 2e74 2d62 2d6f 2d68 f4802p-2.t-b-o-h 0x0030: 2e6e 6574 2c20 5353 4820 6163 6365 7373 .net,.SSH.access 0x0040: 2062 7920 7573 6572 2047 4947 474c 4520 .by.user.GIGGLE. 0x0050: 6672 6f6d 2073 7263 2049 5020 3638 2e31 from.src.IP.68.1 0x0060: 3937 2e31 372e 3231 362c 2073 7263 204d 97.17.216,.src.M 0x0070: 4143 2030 3065 302e 3830 3265 2e37 3130 AC.00e0.802e.710 0x0080: 3020 7265 6a65 6374 6564 2c20 3120 6174 0.rejected,.1.at 0x0090: 7465 6d70 7428 7329 20 tempt(s). So it should be alright.... But why isn't it making it onto my /var/log/spool file?? Thanks, Tuc From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 23:00: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 9155A16A420 for ; Fri, 22 Jul 2005 23:00:39 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id E606F43D46 for ; Fri, 22 Jul 2005 23:00:38 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so14044rna for ; Fri, 22 Jul 2005 16:00:38 -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=YX0oN85wHWpMvZL1KKQaYu2hAsJ0VD1j4/ZVQzhBeXw9Cq8l9EMYg3+M98A2kkvDS9M6GYAn4YnGwtchbPFnwpC5VoubSWeloaeqTabpxX6shXbKn4ZyDiVxMoDQxWh65sDRfS0xrhf3F05Pol7e/B6OK1gHaVJ0hwRxeSaUIg4= Received: by 10.38.12.76 with SMTP id 76mr187711rnl; Fri, 22 Jul 2005 15:01:53 -0700 (PDT) Received: from ?192.168.1.200? ([213.64.231.30]) by mx.gmail.com with ESMTP id k22sm2333131rnb.2005.07.22.15.01.53; Fri, 22 Jul 2005 15:01:53 -0700 (PDT) Message-ID: <42E16CC5.8070700@gmail.com> Date: Sat, 23 Jul 2005 00:01:41 +0200 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0+ (X11/20050722) MIME-Version: 1.0 To: toni@stderror.at References: <20050722200948.GA636@stderror.at> In-Reply-To: <20050722200948.GA636@stderror.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 6.0 BETA1 if_ath problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 23:00:39 -0000 Toni Schmidbauer wrote: > ath0: flags=8843 mtu 1500 > inet 192.168.170.37 netmask 0xfffffff8 broadcast 192.168.170.39 > inet6 fe80::20e:9bff:fec6:8a79%ath0 prefixlen 64 scopeid 0x3 > ether 00:0e:9b:c6:8a:79 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) > status: associated > ssid stderror channel 6 bssid 00:0f:66:c7:82:66 > authmode OPEN privacy ON deftxkey UNDEF ^^^^^ I had problems when deftxkey/weptxkey was not set, try adding 'weptxkey 1' to your ifconfig command line or let wpa_supplicant do the WEP stuff. > wepkey 1:104-bit <11111111111111111111111111> > txpowmax 50 protmode CTS bintval 100 > -- Pawel From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 23:06: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 76D2E16A420 for ; Fri, 22 Jul 2005 23:06:22 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB71E43D45 for ; Fri, 22 Jul 2005 23:06:21 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Fri, 22 Jul 2005 18:06:21 -0500 id 00095803.42E17BED.0000A825 Received: from dsl-201-144-87-77.prod-infinitum.com.mx (dsl-201-144-87-77.prod-infinitum.com.mx [201.144.87.77]) by mail.bafirst.com (Horde MIME library) with HTTP; Fri, 22 Jul 2005 18:06:21 -0500 Message-ID: <20050722180621.qj8w6e47i8gkwk88@mail.bafirst.com> Date: Fri, 22 Jul 2005 18:06:21 -0500 From: eculp@bafirst.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.1-cvs Cc: Subject: I just installed pf on a new server w/current and nat doesn't seem to work. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 23:06:22 -0000 My major problem is that I am over 2500 miles from the server and in another country. I have configured a current box with the idea of stoping at 6.0 but that is another issue. It would seem that pf nat isn't working. The machines on the lan pickup there configuration from dhcpd and can ping their gateway 192.168.1.1 (em0 on the server) and 65.81.102.2 (em1 on the server) but cannot ping 65.81.102.1 the server's gateway. It would seem that there are issues with either ip forwarding or pf nat. when I do a pfctl -vv -s Interfaces I get all zeros even though I am creating traffic on the server. That doesn't seem to be right. My configurations follow. I would sure appreciate any suggestions because I'm afraid that I've missed something. That is usually the case with problems like this. # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 /etc/pf.conf: int_if = "em0" ext_if = "em1" udp_services = "{ 53 }" tcp_services = "{ 22, 25, 53, 80, 110, 113, 123, 143, 389, 3128 }" icmp_types = "echoreq" priv_nets = "{ 0.0.0.0/8, 20.20.20.0/24, 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 224.0.0.0/3 }" # options set block-policy return set loginterface $ext_if # scrub scrub in all # nat/rdr nat on $ext_if from $int_if:network to any -> ($ext_if) rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128 # filter rules block all pass quick on lo0 all block drop in quick on $ext_if from $priv_nets to any block drop out quick on $ext_if from any to $priv_nets pass in on $ext_if inet proto udp from any to ($ext_if) port $udp_services keep state pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services flags S/SA keep state pass in on $int_if inet proto tcp from any to 127.0.0.1 port 3128 keep state pass out on $ext_if inet proto tcp from any to any port www keep state pass in inet proto icmp all icmp-type $icmp_types keep state pass in on $int_if from $int_if:network to any keep state pass out on $int_if from any to $int_if:network keep state pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state rc.conf: ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0" ifconfig_em1="inet 65.81.102.2 netmask 255.255.255.248" defaultrouter="65.81.102.1" gateway_enable="YES" pf_enable="YES" pf_rules="/etc/pf.conf" pf_program="/sbin/pfctl" pf_flags="" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_program="/sbin/pflogd" pflog_flags="" # PF Kernel Config device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ Where else could it be? I have several other machines that have very similar configurations and with no problems, of course they are all within a 2 hour drive ;) Thanks for any help or suggestions. ed From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 00:54: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 C66AA16A41F for ; Sat, 23 Jul 2005 00:54:09 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F9DC43D48 for ; Sat, 23 Jul 2005 00:54:08 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so547038wri for ; Fri, 22 Jul 2005 17:54: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:cc:in-reply-to:mime-version:content-type:references; b=W5Z1SWPwa8ze4+dgLQNqOjIDAC49Hsm1sMPnmJYFgA2m116qBTVxZ4nfCP1pyf4h3CtE9u88eVwDcUs/wH3vu++aE2KPAN54jZn88oH1bKo5l5hPXF+VSvEXymQ+yS4+w4LlitRboeXEYSF5J72WoK4Axd++49tsYFhaN5WxfqM= Received: by 10.54.39.42 with SMTP id m42mr1494447wrm; Fri, 22 Jul 2005 17:54:07 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Fri, 22 Jul 2005 17:54:07 -0700 (PDT) Message-ID: <47d0403c0507221754dceab60@mail.gmail.com> Date: Sat, 23 Jul 2005 00:54:07 +0000 From: Ben Kaduk To: John Baldwin In-Reply-To: <200507221544.35384.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_599_26350432.1122080047536" References: <47d0403c05071713131a0689ee@mail.gmail.com> <200507221544.35384.jhb@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: curiousities in 6.0beta1 dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 00:54:10 -0000 ------=_Part_599_26350432.1122080047536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 7/22/05, John Baldwin wrote: > On Sunday 17 July 2005 04:13 pm, Ben Kaduk wrote: > > Hi all, > > > > I recently upgraded to: > > bash-2.05b$ uname -a > > FreeBSD prolepsis.math.uiuc.edu 6.0-BETA1 FreeBSD 6.0-BETA1 #2: Sat > > Jul 16 21:34:06 UTC 2005 > > kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 > > > > from 5.4-Release using a source upgrade, and I noticed a few things in = the > > dmesg whilst it was booting that struck me as a bit odd. > > Copyright (c) 1992-2005 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > > The Regents of the University of California. All rights reserve= d. > > FreeBSD 6.0-BETA1 #2: Sat Jul 16 21:34:06 UTC 2005 > > kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.50GHz (2492.65-MHz 686-clas= s > > CPU) Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 > > > > Features=3D0xbfebf9ff >V,PAT, PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=3D0x4400> > > real memory =3D 1073405952 (1023 MB) > > avail memory =3D 1037340672 (989 MB) > > npx0: [FAST] > > npx0: on motherboard > > npx0: INT 16 interface > > acpi0: on motherboard > > pci_link0: irq 11 on acpi0 > > pci_link1: irq 11 on acpi0 > > > > > > [ pci_link1 seems to have an irq here. . . ] > > > > > > pci_link2: irq 11 on acpi0 > > pci_link3: irq 11 on acpi0 > > pci_link4: on acpi0 > > pci_link5: irq 11 on acpi0 > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > cpu0: on acpi0 > > acpi_throttle0: on cpu0 > > acpi_acad0: on acpi0 > > acpi_cmbat0: on acpi0 > > acpi_cmbat1: on acpi0 > > acpi_lid0: on acpi0 > > acpi_button0: on acpi0 > > acpi_button1: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pci_link1: Unable to choose an IRQ > > > > > > [ so why does it need to choose an irq here? ] >=20 > It's not quite that simple. :( It may be that the link says that irq 11 = is > not valid. Can you provide a verbose dmesg? >=20 > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org >=20 John, Thanks for the insight. Not only can i provide a verbose dmesg, but I can do so for both the beta and for HEAD prolepsis# uname -a FreeBSD prolepsis.math.uiuc.edu 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Fri Jul 22 23:53:40 UTC 2005 =20 kaduk@prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 as well as a regular dmesg from HEAD, since there are even more curiousities, namely, in the verbose boots, pci_link1 is assigned an IRQ, but apparently not in the regular boots. I hope the attached dmesgs are meaningful, Ben Kaduk ------=_Part_599_26350432.1122080047536 Content-Type: application/octet-stream; name="dmesg.beta.verbose" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.beta.verbose" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1CRVRBMSAjMjogU2F0IEp1bCAxNiAyMTozNDowNiBV VEMgMjAwNQogICAga2FkdWtAcHJvbGVwc2lzLm1hdGgudWl1Yy5lZHU6L3Vzci9vYmovdXNyL3Ny Yy9zeXMvUFJPTEVQU0lTClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVs IiBhdCAweGMwYzBjMDAwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2xpbnV4 LmtvIiBhdCAweGMwYzBjMTU4LgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3QvbW9kdWxlcy9u dmlkaWEua28iIGF0IDB4YzBjMGMyMDQuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJu ZWwvYWNwaS5rbyIgYXQgMHhjMGMwYzJiMC4KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4uIGk4MjU0 IGNsb2NrOiAxMTkzMTk4IEh6CkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmll ZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5 IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2Nr OiAyNDkyNjU0NzA2IEh6CkNQVTogTW9iaWxlIEludGVsKFIpIFBlbnRpdW0oUikgNCAtIE0gQ1BV IDIuNTBHSHogKDI0OTIuNjUtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJ bnRlbCIgIElkID0gMHhmMjkgIFN0ZXBwaW5nID0gOQogIEZlYXR1cmVzPTB4YmZlYmY5ZmY8RlBV LFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4K ICBGZWF0dXJlczI9MHg0NDAwPENOVFgtSUQsPGIxND4+CnJlYWwgbWVtb3J5ICA9IDEwNzM0MDU5 NTIgKDEwMjMgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAw IC0gMHgwMDAwMDAwMDAwMDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykKMHgwMDAwMDAw MDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMp CjB4MDAwMDAwMDAwMTAyNTAwMCAtIDB4MDAwMDAwMDAzZWQ3NmZmZiwgMTAzNzM3NzUzNiBieXRl cyAoMjUzMjY2IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAxMDM3MzQwNjcyICg5ODkgTUIpCmJpb3Mz MjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGZmZTgwCmJp b3MzMjogRW50cnkgPSAweGZmZTkwIChjMDBmZmU5MCkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlv czogUENJIEJJT1MgZW50cnkgYXQgMHhmMDAwMCsweGM5NmUKcG5wYmlvczogRm91bmQgUG5QIEJJ T1MgZGF0YSBhdCAweGMwMGZlMmQwCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6ZTJmNCAgUmV2ID0g MS4wCnBucGJpb3M6IEV2ZW50IGZsYWcgYXQgNGI0Ck90aGVyIEJJT1Mgc2lnbmF0dXJlcyBmb3Vu ZDoKcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm1lbTogPG1lbW9y eT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKaW86IDxJL08+Cm51bGw6IDxudWxs IGRldmljZSwgemVybyBkZXZpY2U+Cm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+ IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxERUxMIENQaSBS ICA+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAxIGFk ZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDBlYWM0CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4 MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAw XSBbaGRyPTAwXSBpcyB0aGVyZSAoaWQ9MWEzMDgwODYpCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAy LjEwCkZvdW5kICRQSVIgdGFibGUsIDkgZW50cmllcyBhdCAweGMwMGZjNTgwClBDSS1Pbmx5IElu dGVycnVwdHM6IG5vbmUKTG9jYXRpb24gIEJ1cyBEZXZpY2UgUGluICBMaW5rICBJUlFzCmVtYmVk ZGVkICAgIDAgICAyOSAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1i ZWRkZWQgICAgMCAgIDI5ICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpl bWJlZGRlZCAgICAwICAgMjkgICAgQyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 CmVtYmVkZGVkICAgIDAgICAyOSAgICBEICAgMHg2YiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUKZW1iZWRkZWQgICAgMCAgIDMwICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAx NCAxNQplbWJlZGRlZCAgICAwICAgMzAgICAgQiAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMCAgICBDICAgMHg2MiAgMyA0IDUgNiA3IDkgMTAgMTEg MTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgIDMwICAgIEQgICAweDYzICAzIDQgNSA2IDcgOSAxMCAx MSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgMzEgICAgQSAgIDB4NjIgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBCICAgMHg2MSAgMyA0IDUgNiA3IDkg MTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMSAgICAwICAgIEEgICAweDYwICAzIDQgNSA2IDcg OSAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAyICAgIDAgICAgQSAgIDB4NjIgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDIgICAgMSAgICBBICAgMHg2MyAgMyA0IDUg NiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMiAgICAxICAgIEIgICAweDYzICBub25l CmVtYmVkZGVkICAgIDIgICAgMyAgICBBICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUKZW1iZWRkZWQgICAgMiAgICAzICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAx NCAxNQplbWJlZGRlZCAgICA4ICAgIDAgICAgQSAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1CmVtYmVkZGVkICAgIDggICAgMCAgICBCICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEg MTIgMTQgMTUKZW1iZWRkZWQgICAgOCAgICAxICAgIEEgICAweDYxICAzIDQgNSA2IDcgOSAxMCAx MSAxMiAxNCAxNQplbWJlZGRlZCAgICA4ICAgIDEgICAgQiAgIDB4NjMgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3Vt aW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaV9idXNfbnVt YmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDog YnVzIDAgZGV2IDMxIGZ1bmMgMAphdHBpYzogUHJvZ3JhbW1pbmcgSVJROSBhcyBsZXZlbC9sb3cK cGNpX2xpbmswOiA8QUNQSSBQQ0kgTGluayBMTktBPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xpbmsw OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgIDExICAgTiAgICAgMCAgOSAxMCAxMQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4g ICAgIDAgIDkgMTAgMTEKcGNpX2xpbmswOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgOSAxMCAxMQpwY2lfbGluazE6 IDxBQ1BJIFBDSSBMaW5rIExOS0I+IGlycSAxMSBvbiBhY3BpMApwY2lfbGluazE6IExpbmtzIGFm dGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTEg ICBOICAgICAwICA1IDcKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcKcGNp X2xpbmsxOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3CnBjaV9saW5rMjogPEFDUEkgUENJIExpbmsgTE5LQz4g aXJxIDExIG9uIGFjcGkwCnBjaV9saW5rMjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4gICAgIDAgIDkgMTAgMTEKcGNp X2xpbmsyOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAgMTEgICBOICAgICAwICA5IDEwIDExCnBjaV9saW5rMjogTGlua3Mg YWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDkgMTAgMTEKcGNpX2xpbmszOiA8QUNQSSBQQ0kgTGluayBMTktEPiBpcnEgMTEgb24g YWNwaTAKcGNpX2xpbmszOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTAgMTEKcGNpX2xpbmsz OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgICAwICAgMTEgICBOICAgICAwICA1IDcgOSAxMCAxMQpwY2lfbGluazM6IExpbmtzIGFm dGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICA1IDcgOSAxMCAxMQpwY2lfbGluazQ6IDxBQ1BJIFBDSSBMaW5rIExOS0U+IG9uIGFjcGkw CnBjaV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 CnBjaV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUK cGNpX2xpbms1OiA8QUNQSSBQQ0kgTGluayBMTktIPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xpbms1 OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1 OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lf bGluazU6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpBQ1BJIHRpbWVy OiAwLzEwIDAvMTAgMC8xMCAwLzEwIDAvMTAgMC8xMCAwLzEwIDAvMTAgMC8xMCAwLzEwIC0+IDAK VGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAw CmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4 ODBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxB Q1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmFjcGlfdGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBf QkxLIDB4OGUwCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMAphY3BpX2NtYmF0MDog PENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfY21iYXQxOiA8Q29udHJvbCBN ZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3 aXRjaD4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3Bp X2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgx YTMwLCByZXZpZD0weDA0CglidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGU4 MDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MWEz MSwgcmV2aWQ9MHgwNAoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRy dHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDBjICgzMDAw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRj MiwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgNCwg cmFuZ2UgMzIsIGJhc2UgMDAwMGJmODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMjkuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxOS0E6MCkKcGNpYjA6IHNsb3Qg MjkgSU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTktBCmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4MjRjNCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9 MQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9 MTEKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGJmNDAsIHNpemUgIDUsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQiAoc3JjIFxcX1NCXy5QQ0kw LkxOS0Q6MCkKcGNpYjA6IHNsb3QgMjkgSU5UQiByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8u UENJMC5MTktECmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNywgcmV2aWQ9MHgwMwoJ YnVzPTAsIHNsb3Q9MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1jLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2Ug MDAwMGJmMjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjku SU5UQyAoc3JjIFxcX1NCXy5QQ0kwLkxOS0M6MCkKcGNpYjA6IHNsb3QgMjkgSU5UQyByb3V0ZWQg dG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTktDCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjZCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMt MjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwg YmFzZSBmNGZmZmMwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4yOS5JTlREIChzcmMgXFxfU0JfLlBDSTAuTE5LSDowKQpwY2liMDogc2xvdCAyOSBJTlREIHJv dXRlZCB0byBpcnEgMTEgdmlhIFxcX1NCXy5QQ0kwLkxOS0gKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyNDQ4LCByZXZpZD0weDgzCglidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4 ODA4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI0Y2MsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTA2 LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMGYsIHN0YXRyZWc9MHgw MjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjYSwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MQoJY2xhc3M9MDEtMDEt OGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MjU1CgltYXBbMjBdOiB0 eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiZmEwLCBzaXplICA0LCBlbmFibGVkCgltYXBbMjRd OiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDAwMDAwMDAwLCBzaXplIDEwLCBtZW1vcnkgZGlzYWJs ZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM1LCByZXZpZD0weDAzCglidXM9MCwg c2xvdD0zMSwgZnVuYz01CgljbGFzcz0wNC0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ aW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw CgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiODAwLCBzaXplICA4LCBlbmFi bGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiYzQwLCBzaXplICA2LCBl bmFibGVkCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmODAwLCBzaXplICA5 LCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmNDAwLCBzaXpl ICA4LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9T Ql8uUENJMC5MTktCOjApCnBjaV9saW5rMTogUGlja2VkIElSUSA5IHdpdGggd2VpZ2h0IDAKcGNp YjA6IHNsb3QgMzEgSU5UQiByb3V0ZWQgdG8gaXJxIDkgdmlhIFxcX1NCXy5QQ0kwLkxOS0IKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM2LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0z MSwgZnVuYz02CgljbGFzcz0wNy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9 MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBb MTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiNDAwLCBzaXplICA4LCBlbmFibGVkCglt YXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiMDgwLCBzaXplICA3LCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTktC OjApCnBjaWIwOiBzbG90IDMxIElOVEIgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uUENJMC5M TktCCmFncDA6IDxJbnRlbCA4Mjg0NSBob3N0IHRvIEFHUCBicmlkZ2U+IG1lbSAweGU4MDAwMDAw LTB4ZWZmZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kwCmFncDA6IFJlc2VydmVkIDB4ODAwMDAw MCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTgwMDAwMDAKYWdwMDogYWxsb2NhdGlu ZyBHQVRUIGZvciBhcGVydHVyZSBvZiBzaXplIDEyOE0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpw Y2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 YzAwMC0weGNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmYzAwMDAwMC0weGZkZmZm ZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZjAwMDAwMDAtMHhmM2ZmZmZmZgpwY2kx OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAyODYsIHJldmlkPTB4YTEKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAyNywg c3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAg bnMpLCBtaW5nbnQ9MHgwNSAoMTI1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglpbnRwaW49 YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsx MF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmMwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNp YjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmMwMDAwMDAtMHhmY2ZmZmZmZjog Z29vZAoJbWFwWzE0XTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSBmMDAwMDAwMCwgc2l6ZSAyNiwg ZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmMDAwMDAwMC0w eGYzZmZmZmZmOiBnb29kCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5UQSAoc3JjIFxc X1NCXy5QQ0kwLkxOS0E6MCkKcGNpYjE6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTEgdmlh IFxcX1NCXy5QQ0kwLkxOS0EKbnZpZGlhMDogPEdlRm9yY2U0IDQyMDAgR28+IG1lbSAweGZjMDAw MDAwLTB4ZmNmZmZmZmYsMHhmMDAwMDAwMC0weGYzZmZmZmZmIGlycSAxMSBhdCBkZXZpY2UgMC4w IG9uIHBjaTEKbnZpZGlhMDogUmVzZXJ2ZWQgMHgxMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0 eXBlIDMgYXQgMHhmYzAwMDAwMApudmlkaWEwOiBSZXNlcnZlZCAweDQwMDAwMDAgYnl0ZXMgZm9y IHJpZCAweDE0IHR5cGUgMyBhdCAweGYwMDAwMDAwCm52aWRpYTA6IFtHSUFOVC1MT0NLRURdCnVo Y2kwOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhi ZjgwLTB4YmY5ZiBpcnEgMTEgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMDogUmVzZXJ2ZWQg MHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YmY4MAp1aGNpMDogW0dJQU5ULUxP Q0tFRF0KdXNiMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBv biB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBJbnRlbCBVSENJIHJvb3QgaHVi LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMDogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTE6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0Ig Y29udHJvbGxlciBVU0ItQj4gcG9ydCAweGJmNDAtMHhiZjVmIGlycSAxMSBhdCBkZXZpY2UgMjku MSBvbiBwY2kwCnVoY2kxOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHhiZjQwCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiA8SW50ZWwgODI4MDFEQiAoSUNI NCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAK dWh1YjE6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjog PEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4YmYyMC0w eGJmM2YgaXJxIDExIGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTI6IFJlc2VydmVkIDB4MjAg Ynl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGJmMjAKdWhjaTI6IFtHSUFOVC1MT0NLRURd CnVzYjI6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQz4gb24gdWhj aTIKdXNiMjogVVNCIHJldmlzaW9uIDEuMAp1aHViMjogSW50ZWwgVUhDSSByb290IGh1YiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8SW50ZWwgODI4MDFEQi9EQkwvREJNIChJQ0g0KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGY0ZmZmYzAwLTB4ZjRmZmZmZmYgaXJxIDExIGF0IGRl dmljZSAyOS43IG9uIHBjaTAKZWhjaTA6IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhmNGZmZmMwMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMzogRUhDSSB2 ZXJzaW9uIDEuMAp1c2IzOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNi MCB1c2IxIHVzYjIKdXNiMzogPEludGVsIDgyODAxREIvREJML0RCTSAoSUNINCkgVVNCIDIuMCBj b250cm9sbGVyPiBvbiBlaGNpMAp1c2IzOiBVU0IgcmV2aXNpb24gMi4wCnVodWIzOiBJbnRlbCBF SENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQp1aHViMzogNiBw b3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAg IDIKcGNpYjI6ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAg ICAweGQwMDAtMHhlZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjYwMDAwMDAtMHhm YmZmZmZmZgpwY2liMjogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNp YjI6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KcGNpMjogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjIKcGNpMjogcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9 MHg0NDAxLCByZXZpZD0weDAxCglidXM9Miwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5n ZSAzMiwgYmFzZSBmYWZmZTAwMCwgc2l6ZSAxMywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHhmYWZmZTAwMC0weGZhZmZmZmZmOiBnb29kCnBjaWIyOiBtYXRj aGVkIGVudHJ5IGZvciAyLjAuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxOS0M6MCkKcGNpYjI6IHNs b3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTEgdmlhIFxcX1NCXy5QQ0kwLkxOS0MKZm91bmQtPgl2 ZW5kb3I9MHgxMDRjLCBkZXY9MHhhYzQ0LCByZXZpZD0weDAyCglidXM9Miwgc2xvdD0xLCBmdW5j PTAKCWNsYXNzPTA2LTA3LTAwLCBoZHJ0eXBlPTB4MDIsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAs IHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYw IG5zKSwgbWluZ250PTB4NDAgKDE2MDAwIG5zKSwgbWF4bGF0PTB4MDcgKDE3NTAgbnMpCglpbnRw aW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50 IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDAwMDAwMDAwLCBzaXplIDEyLCBt ZW1vcnkgZGlzYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDI5LCByZXZpZD0w eDAwCglidXM9Miwgc2xvdD0xLCBmdW5jPTEKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTEKCWNtZHJlZz0weDAxMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdv cmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxh dD0weDA0ICgxMDAwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNl IGZhZmZkODAwLCBzaXplIDExLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGZhZmZkODAwLTB4ZmFmZmRmZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgZmFmZjgwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmFmZjgwMDAtMHhmYWZmYmZmZjogZ29vZApwY2liMjogbWF0 Y2hlZCBlbnRyeSBmb3IgMi4xLklOVEEgKHNyYyBcXF9TQl8uUENJMC5MTktEOjApCnBjaWIyOiBz bG90IDEgSU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTktECmZvdW5kLT4J dmVuZG9yPTB4MTRlNCwgZGV2PTB4NDMyNCwgcmV2aWQ9MHgwMgoJYnVzPTIsIHNsb3Q9MywgZnVu Yz0wCgljbGFzcz0wMi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2 LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2 MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1h cFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmFmZjYwMDAsIHNpemUgMTMsIGVuYWJsZWQK cGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmFmZjYwMDAtMHhmYWZmN2Zm ZjogZ29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4zLklOVEEgKHNyYyBcXF9TQl8uUENJ MC5MTktCOjApCnBjaWIyOiBzbG90IDMgSU5UQSByb3V0ZWQgdG8gaXJxIDkgdmlhIFxcX1NCXy5Q Q0kwLkxOS0IKYmZlMDogPEJyb2FkY29tIEJDTTQ0MDEgRmFzdCBFdGhlcm5ldD4gbWVtIDB4ZmFm ZmUwMDAtMHhmYWZmZmZmZiBpcnEgMTEgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCmJmZTA6IFJlc2Vy dmVkIDB4MjAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmFmZmUwMDAKbWlpYnVz MDogPE1JSSBidXM+IG9uIGJmZTAKYm10cGh5MDogPEJDTTQ0MDEgMTAvMTAwYmFzZVRYIFBIWT4g b24gbWlpYnVzMApibXRwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgYXV0bwpiZmUwOiBicGYgYXR0YWNoZWQKYmZlMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MGI6ZGI6OTk6ZTg6YzcKYmZlMDogW01QU0FGRV0KY2JiMDogPFRJNDUxMCBQQ0ktQ2Fy ZEJ1cyBCcmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMgpwY2liMjogY2JiMCByZXF1ZXN0ZWQg bWVtb3J5IHJhbmdlIDB4ZjYwMDAwMDAtMHhmYmZmZmZmZjogZ29vZApjYmIwOiBMYXp5IGFsbG9j YXRpb24gb2YgMHgxMDAwIGJ5dGVzIHJpZCAweDEwIHR5cGUgMyBhdCAweGY2MDAwMDAwCmNhcmRi dXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBv biBjYmIwCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjEuSU5UQSAoc3JjIFxcX1NCXy5QQ0kw LkxOS0Q6MCkKcGNpYjI6IHNsb3QgMSBJTlRBIHJvdXRlZCB0byBpcnEgMTEgdmlhIFxcX1NCXy5Q Q0kwLkxOS0QKY2JiMDogW01QU0FGRV0KY2JiMDogUENJIENvbmZpZ3VyYXRpb24gc3BhY2U6CiAg MHgwMDogMHhhYzQ0MTA0YyAweDAyMTAwMDA3IDB4MDYwNzAwMDIgMHgwMDgyMjAwOCAKICAweDEw OiAweGY2MDAwMDAwIDB4MDIwMDAwYTAgMHgyMDA0MDMwMiAweGZmZmZmMDAwIAogIDB4MjA6IDB4 MDAwMDAwMDAgMHhmZmZmZjAwMCAweDAwMDAwMDAwIDB4ZmZmZmZmZmMgCiAgMHgzMDogMHgwMDAw MDAwMCAweGZmZmZmZmZjIDB4MDAwMDAwMDAgMHgwNzQwMDEwYiAKICAweDQwOiAweDAxM2UxMDI4 IDB4MDAwMDAwMDEgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NTA6IDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg2MDogMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDcwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ODA6IDB4Mjg0MDcwNjEgMHgwMDAwMDAwMCAweDAw MWYwMDAwIDB4MDEyYzEyMDIgCiAgMHg5MDogMHg2MDY0ODNjMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgMHgwMDAwMDAwMCAKICAweGEwOiAweGZlMTIwMDAxIDB4MDBjMDAwMDAgMHgwMDAwMDAwMCAw eDAwMDAwMDAwIAogIDB4YjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgCiAgMHhjMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAKICAweGQwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAog IDB4ZTA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhm MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKZndvaGNpMDog dmVuZG9yPTEwNGMsIGRldj04MDI5CmZ3b2hjaTA6IHZlbmRvcj0xMDRjLCBkZXY9ODAyOQpmd29o Y2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2U+IG1lbSAweGZhZmZkODAw LTB4ZmFmZmRmZmYsMHhmYWZmODAwMC0weGZhZmZiZmZmIGlycSAxMSBhdCBkZXZpY2UgMS4xIG9u IHBjaTIKZndvaGNpMDogUmVzZXJ2ZWQgMHg4MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBh dCAweGZhZmZkODAwCmZ3b2hjaTA6IFtNUFNBRkVdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEw IChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDQuCmZ3b2hj aTA6IEVVSTY0IDQ2OjRmOmMwOjAwOjFkOjJmOjFjOjYxCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFp bGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0 ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKc2JwMDog PFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwCmZ3b2hjaTA6IEluaXRpYXRl IGJ1cyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RF UiBtb2RlCmZpcmV3aXJlMDogMSBub2RlcywgbWF4aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1l KQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1lKQpwY2kyOiA8bmV0d29yaz4gYXQgZGV2aWNl IDMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kyOjM6MDogVHJhbnNpdGlvbiBmcm9tIEQwIHRv IEQzCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDog PElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0g0IFVETUExMDAgY29udHJvbGxl cj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGJmYTAtMHhiZmFm IGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3Ig cmlkIDB4MjAgdHlwZSA0IGF0IDB4YmZhMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNp MAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFm MAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNm NgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTA6IHN0YXQw PTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogc3RhdDE9MHgwMCBlcnI9MHgw MSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2 aWNlcz0weDE8QVRBX01BU1RFUj4KYXRhMDogW01QU0FGRV0KYXRhMTogPEFUQSBjaGFubmVsIDE+ IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBl IDQgYXQgMHgxNzAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBl IDQgYXQgMHgzNzYKYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT0wMAph dGExOiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTE6IHN0YXQxPTB4 MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0 YXQxPTAwIGRldmljZXM9MHhjPEFUQVBJX1NMQVZFLEFUQVBJX01BU1RFUj4KYXRhMTogW01QU0FG RV0KcGNtMDogPEludGVsIElDSDQgKDgyODAxREIpPiBwb3J0IDB4YjgwMC0weGI4ZmYsMHhiYzQw LTB4YmM3ZiBtZW0gMHhmNGZmZjgwMC0weGY0ZmZmOWZmLDB4ZjRmZmY0MDAtMHhmNGZmZjRmZiBp cnEgOSBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwCnBjbTA6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZv ciByaWQgMHgxMCB0eXBlIDQgYXQgMHhiODAwCnBjbTA6IFJlc2VydmVkIDB4NDAgYnl0ZXMgZm9y IHJpZCAweDE0IHR5cGUgNCBhdCAweGJjNDAKcGNtMDogW0dJQU5ULUxPQ0tFRF0KcGNtMDogPFNp Z21hVGVsIFNUQUM5NzUwLzUxIEFDOTcgQ29kZWMgKGlkID0gMHg4Mzg0NzY1MCk+CnBjbTA6IENv ZGVjIGZlYXR1cmVzIGhlYWRwaG9uZSwgMjAgYml0IERBQywgMjAgYml0IEFEQywgNSBiaXQgbWFz dGVyIHZvbHVtZSwgU2lnbWFUZWwgM0QgRW5oYW5jZW1lbnQKcGNtMDogUHJpbWFyeSBjb2RlYyBl eHRlbmRlZCBmZWF0dXJlcyB2YXJpYWJsZSByYXRlIFBDTSwgcmVzZXJ2ZWQgMSwgQU1BUCwgcmVz ZXJ2ZWQgNApwY20wOiBzbmRidWZfc2V0bWFwIDNlNzIzMDAwLCA0MDAwOyAweGVkNjdmMDAwIC0+ IDNlNzIzMDAwCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgM2U3MWMwMDAsIDQwMDA7IDB4ZWQ2ODMwMDAg LT4gM2U3MWMwMDAKcGNpMDogPHNpbXBsZSBjb21tcywgZ2VuZXJpYyBtb2RlbT4gYXQgZGV2aWNl IDMxLjYgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDozMTo2OiBUcmFuc2l0aW9uIGZyb20gRDAg dG8gRDMKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCnBzbWNwbnAwOiA8UFMvMiBt b3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9h cmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNv bW1hbmQgYnl0ZSAwMDY1CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRr YmQwCmtiZDA6IGF0a2JkMCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2Qw MDAwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogY3VycmVudCBjb21tYW5kIGJ5dGU6MDA2 NQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tF RF0KcHNtMDogbW9kZWwgR2xpZGVQb2ludCwgZGV2aWNlIElEIDAtMDAsIDIgYnV0dG9ucwpwc20w OiBjb25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTozCnBzbTA6IHN5 bmNtYXNrOmMwLCBzeW5jYml0czowMApzaW8wOiBpcnEgbWFwczogMHhhMDEgMHhhMDkgMHhhMDEg MHhhMDEKc2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKcHBjMDogdXNpbmcg ZXh0ZW5kZWQgSS9PIHBvcnQgcmFuZ2UKcHBjMDogRUNQIFNQUCBFQ1ArRVBQIFNQUApwcGMwOiA8 RUNQIHBhcmFsbGVsIHByaW50ZXIgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiwweDc3OC0weDc3YiBp cnEgNyBkcnEgMSBvbiBhY3BpMApwcGMwOiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9O SUJCTEUpIGluIENPTVBBVElCTEUgbW9kZQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0 aHJlc2hvbGQKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKbHB0MDogPFByaW50 ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVs IEkvTz4gb24gcHBidXMwCmF0YTogYXRhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRh OiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdGtiZGM6IGF0a2JkYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnBwYzogcHBjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2lvOiBzaW8wIGFscmVhZHkg ZXhpc3RzOyBza2lwcGluZyBpdAp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0 CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjgz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQz CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKaXNhX3Byb2JlX2NoaWxk cmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5v bi1QblAgZGV2aWNlcwpwbXRpbWVyMCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjZjdmZiwweGNmODAwLTB4Y2ZmZmYgb24gaXNhMApzYzA6IDxTeXN0 ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBj b25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBlbXVsYXRvcjog c2MgKHN5c2NvbnMgdGVybWluYWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgz YzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYWR2MDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQg cG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZlMDogbm90IHByb2Jl ZCAoZGlzYWJsZWQpCmllMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmxuYzA6IG5vdCBwcm9iZWQg KGRpc2FibGVkKQpzaW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4IGlycSAzIG9uIGlz YTAKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpp c2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKdW1zMDogTG9naXRlY2ggT3B0 aWNhbCBVU0IgTW91c2UsIHJldiAyLjAwLzMuNDAsIGFkZHIgMiwgaWNsYXNzIDMvMQp1bXMwOiAz IGJ1dHRvbnMgYW5kIFogZGlyLgpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI0OTI2NTQ3MDYgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50 ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpMaW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3RhbGxl ZApsbzA6IGJwZiBhdHRhY2hlZAphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gc3Rh cnQKYWNwaV9hY2FkMDogT24gTGluZQphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24g ZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2NtYmF0MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBz dGFydAphY3BpX2NtYmF0MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRp bWVzCmFjcGlfY21iYXQxOiBiYXR0ZXJ5IGluaXRpYWxpemF0aW9uIHN0YXJ0CmF0YTAtbWFzdGVy OiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEwMCBjYWJsZT04MCB3aXJlCmFkMDogc2V0 dGluZyBQSU80IG9uIEludGVsIElDSDQgY2hpcAphZDA6IHNldHRpbmcgVURNQTEwMCBvbiBJbnRl bCBJQ0g0IGNoaXAKYWQwOiA3NjMxOU1CIDxJQzI1TjA4MEFUTVIwNCAwIE1PNE9BRDBBPiBhdCBh dGEwLW1hc3RlciBVRE1BMTAwCmFkMDogMTU2MzAxNDg4IHNlY3RvcnMgWzE1NTA2MUMvMTZILzYz U10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDAK cGNpYjI6IHBjY2FyZDAgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY2MDAwMDAwLTB4ZmJmZmZm ZmY6IGdvb2QKcGNjYXJkMDogQ0lTIHZlcnNpb24gUEMgQ2FyZCBTdGFuZGFyZCA1LjAKcGNjYXJk MDogQ0lTIGluZm86IElCTSwgNTZLIERhdGEtRmF4IE1vZGVtCnBjY2FyZDA6IE1hbnVmYWN0dXJl ciBjb2RlIDB4ODksIHByb2R1Y3QgMHg0NwpwY2NhcmQwOiBmdW5jdGlvbiAwOiBzZXJpYWwgcG9y dCwgY2NyIGFkZHIgMzAwIG1hc2sgMwpwY2NhcmQwOiBmdW5jdGlvbiAwLCBjb25maWcgdGFibGUg ZW50cnkgMzI6IEkvTyBjYXJkOyBpcnEgbWFzayBmZmZmOyBpb21hc2sgYSwgaW9zcGFjZSAzZjgt M2ZmOyByZHlic3lfYWN0aXZlIGlvOCBpcnFsZXZlbCBwb3dlcmRvd24gYXVkaW8KcGNjYXJkMDog ZnVuY3Rpb24gMCwgY29uZmlnIHRhYmxlIGVudHJ5IDMzOiBJL08gY2FyZDsgaXJxIG1hc2sgZmZm ZjsgaW9tYXNrIGEsIGlvc3BhY2UgMmY4LTJmZjsgcmR5YnN5X2FjdGl2ZSBpbzggaXJxbGV2ZWwg cG93ZXJkb3duIGF1ZGlvCnBjY2FyZDA6IGZ1bmN0aW9uIDAsIGNvbmZpZyB0YWJsZSBlbnRyeSAz NDogSS9PIGNhcmQ7IGlycSBtYXNrIGZmZmY7IGlvbWFzayBhLCBpb3NwYWNlIDNlOC0zZWY7IHJk eWJzeV9hY3RpdmUgaW84IGlycWxldmVsIHBvd2VyZG93biBhdWRpbwpwY2NhcmQwOiBmdW5jdGlv biAwLCBjb25maWcgdGFibGUgZW50cnkgMzU6IEkvTyBjYXJkOyBpcnEgbWFzayBmZmZmOyBpb21h c2sgYSwgaW9zcGFjZSAyZTgtMmVmOyByZHlic3lfYWN0aXZlIGlvOCBpcnFsZXZlbCBwb3dlcmRv d24gYXVkaW8KcGNpYjI6IHBjY2FyZDAgcmVxdWVzdGVkIEkvTyByYW5nZSAweDNmOC0weDNmZjog aW4gcmFuZ2UKcGNpYjI6IHBjY2FyZDAgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY2MDAwMDAw LTB4ZmJmZmZmZmY6IGdvb2QKc2lvNDogPElCTSA1NksgRGF0YS1GYXggTW9kZW0+IGF0IHBvcnQg MHgzZjgtMHgzZmYgaXJxIDExIGZ1bmN0aW9uIDAgY29uZmlnIDMyIG9uIHBjY2FyZDAKc2lvNDog dHlwZSAxNjU1MEEKc2lvNDogdW5hYmxlIHRvIGFjdGl2YXRlIGludGVycnVwdCBpbiBmYXN0IG1v ZGUgLSB1c2luZyBub3JtYWwgbW9kZQphdGExOiByZWluaXRpbmcgY2hhbm5lbCAuLgphdGExOiBy ZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9MDAgb3N0YXQxPTAwCmF0YTE6IHN0YXQwPTB4MDAgZXJy PTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgx NCBtc2I9MHhlYgphdGExOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weGM8 QVRBUElfU0xBVkUsQVRBUElfTUFTVEVSPgphdGExOiByZWluaXQgZG9uZSAuLgphdGExOiByZWlu aXRpbmcgY2hhbm5lbCAuLgphdGExOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9MDAgb3N0YXQx PTAwCmF0YTE6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogc3Rh dDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExOiByZXNldCB0cDIgc3RhdDA9 MDAgc3RhdDE9MDAgZGV2aWNlcz0weGM8QVRBUElfU0xBVkUsQVRBUElfTUFTVEVSPgphdGExOiBy ZWluaXQgZG9uZSAuLgphdGExLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEz MyBjYWJsZT00MCB3aXJlCmFjZDA6IHNldHRpbmcgUElPNCBvbiBJbnRlbCBJQ0g0IGNoaXAKYWNk MDogc2V0dGluZyBVRE1BMzMgb24gSW50ZWwgSUNINCBjaGlwCmFjZDA6IDxNQVRTSElUQSBDRC1S Vy9EVkQtUk9NIFVKREE3NDAvMS4wMz4gQ0RSVyBkcml2ZSBhdCBhdGExIGFzIG1hc3RlcgphY2Qw OiByZWFkIDQxMzRLQi9zICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMjA0 OEtCIGJ1ZmZlciwgVURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBE VkRST00sIERWRFIsIERWRFJBTSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCB0ZXN0 IHdyaXRlLCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXksIDI1NiB2b2x1bWUgbGV2ZWxzCmFj ZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCmFjZDA6IE1lZGl1bTogQ0Qt Uk9NIDEyMG1tIGRhdGEgZGlzYwpwY20wOiBtZWFzdXJlZCBhYzk3IGxpbmsgcmF0ZSBhdCA0Nzk5 MSBIeiwgd2lsbCB1c2UgNDgwMDAgSHoKKHByb2JlMDpzYnAwOjA6MDowKTogZXJyb3IgMjIKKHBy b2JlMDpzYnAwOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTpzYnAwOjA6MTowKTog ZXJyb3IgMjIKKHByb2JlMTpzYnAwOjA6MTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjpz YnAwOjA6MjowKTogZXJyb3IgMjIKKHByb2JlMjpzYnAwOjA6MjowKTogVW5yZXRyeWFibGUgRXJy b3IKKHByb2JlMzpzYnAwOjA6MzowKTogZXJyb3IgMjIKKHByb2JlMzpzYnAwOjA6MzowKTogVW5y ZXRyeWFibGUgRXJyb3IKKHByb2JlNDpzYnAwOjA6NDowKTogZXJyb3IgMjIKKHByb2JlNDpzYnAw OjA6NDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNTpzYnAwOjA6NTowKTogZXJyb3IgMjIK KHByb2JlNTpzYnAwOjA6NTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNjpzYnAwOjA6Njow KTogZXJyb3IgMjIKKHByb2JlNjpzYnAwOjA6NjowKTogVW5yZXRyeWFibGUgRXJyb3IKVHJ5aW5n IHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzM2EKc3RhcnRfaW5pdDogdHJ5aW5nIC9z YmluL2luaXQKTG9hZGluZyBjb25maWd1cmF0aW9uIGZpbGVzLgprZW52OiAKdW5hYmxlIHRvIGdl dCBkdW1wZGV2CgprZXJuZWwgZHVtcHMgb24gL2Rldi9hZDBzMmIKRW50cm9weSBoYXJ2ZXN0aW5n OgogaW50ZXJydXB0cwogZXRoZXJuZXQKIHBvaW50X3RvX3BvaW50CiBraWNrc3RhcnQKLgpzd2Fw b246IGFkZGluZyAvZGV2L2FkMHMyYiBhcyBzd2FwIGRldmljZQpTdGFydGluZyBmaWxlIHN5c3Rl bSBjaGVja3M6Ci9kZXYvYWQwczNhOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tT Ci9kZXYvYWQwczNhOiBjbGVhbiwgOTQyMzUgZnJlZSAoNzk1IGZyYWdzLCAxMTY4MCBibG9ja3Ms IDAuNiUgZnJhZ21lbnRhdGlvbikKL2Rldi9hZDBzM2U6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQ UElORyBDSEVDS1MKL2Rldi9hZDBzM2U6IGNsZWFuLCAxMjIzNjIgZnJlZSAoNDIgZnJhZ3MsIDE1 MjkwIGJsb2NrcywgMC4wJSBmcmFnbWVudGF0aW9uKQovZGV2L2FkMHMzZjogRklMRSBTWVNURU0g Q0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkMHMzZjogY2xlYW4sIDY0MjI1NTkgZnJlZSAo NjQyMTUgZnJhZ3MsIDc5NDc5MyBibG9ja3MsIDAuOCUgZnJhZ21lbnRhdGlvbikKL2Rldi9hZDBz M2Q6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZDBzM2Q6IGNsZWFu LCA5MzI3NCBmcmVlICgyMjYgZnJhZ3MsIDExNjMxIGJsb2NrcywgMC4yJSBmcmFnbWVudGF0aW9u KQpTZXR0aW5nIGhvc3RuYW1lOiBwcm9sZXBzaXMubWF0aC51aXVjLmVkdS4KREhDUFJFUVVFU1Qg b24gYmZlMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NwoKREhDUEFDSyBmcm9tIDEzMC4xMjYu MTEwLjEwCgpib3VuZCB0byAxMzAuMTI2LjExMS4yNCAtLSByZW5ld2FsIGluIDE4MDAgc2Vjb25k cy4KCmJmZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNB U1Q+IG10dSAxNTAwCglvcHRpb25zPTg8VkxBTl9NVFU+CglpbmV0NiBmZTgwOjoyMGI6ZGJmZjpm ZTk5OmU4YzclYmZlMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDEgCglpbmV0IDEzMC4xMjYuMTEx LjI0IG5ldG1hc2sgMHhmZmZmZmMwMCAKCWV0aGVyIDAwOjBiOmRiOjk5OmU4OmM3CgltZWRpYTog RXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwYmFzZVRYIDxmdWxsLWR1cGxleD4pCglzdGF0dXM6IGFj dGl2ZQpsbzA6IGZsYWdzPTgwNDk8VVAsTE9PUEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+IG10dSAx NjM4NAoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAwIAoJaW5ldDYgOjoxIHByZWZp eGxlbiAxMjggCglpbmV0NiBmZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDIgCkFk ZGl0aW9uYWwgcm91dGluZyBvcHRpb25zOgouClN0YXJ0aW5nIGRldmQuClN0YXJ0aW5nIHVtczAg bW91c2VkOgouCmh3LmFjcGkuY3B1LmN4X2xvd2VzdDogCkMxCiAtPiAKQzEKCmRoY2xpZW50IGJm ZTA6IGFscmVhZHkgcnVubmluZz8KZGhjbGllbnQgYmZlMDogYWxyZWFkeSBydW5uaW5nPwpNb3Vu dGluZyBORlMgZmlsZSBzeXN0ZW1zOgouCkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBsb2cgZmls ZXM6Ci4KU3RhcnRpbmcgc3lzbG9nZC4KQ2hlY2tpbmcgZm9yIGNvcmUgZHVtcCBvbiAvZGV2L2Fk MHMyYi4uLgpzYXZlY29yZTogdW5hYmxlIHRvIG9wZW4gYm91bmRzIGZpbGUsIHVzaW5nIDAKc2F2 ZWNvcmU6IG5vIGR1bXBzIGZvdW5kCkVMRiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91 c3IvbGliL2NvbXBhdCAvdXNyL1gxMVI2L2xpYiAvdXNyL2xvY2FsL2xpYiAvdXNyL2xvY2FsL2xp Yi9jb21wYXQvcGtnCmEub3V0IGxkY29uZmlnIHBhdGg6IC91c3IvbGliL2FvdXQgL3Vzci9saWIv Y29tcGF0L2FvdXQgL3Vzci9YMTFSNi9saWIvYW91dApTdGFydGluZyB1c2JkLgpTdGFydGluZyBs b2NhbCBkYWVtb25zOgouClVwZGF0aW5nIG1vdGQKLgpDb25maWd1cmluZyBzeXNjb25zOgogYmxh bmt0aW1lCiBzY3JlZW5zYXZlcgpzcGxhc2g6IGltYWdlIGRlY29kZXIgZm91bmQ6IGJsYW5rX3Nh dmVyCi4KU3RhcnRpbmcgc3NoZC4KSW5pdGlhbCBpMzg2IGluaXRpYWxpemF0aW9uOgouCkFkZGl0 aW9uYWwgQUJJIHN1cHBvcnQ6CiBsaW51eAouClN0YXJ0aW5nIGNyb24uCkxvY2FsIHBhY2thZ2Ug aW5pdGlhbGl6YXRpb246Ci4KQWRkaXRpb25hbCBUQ1Agb3B0aW9uczoKLgpTdGFydGluZyBkZWZh dWx0IG1vdXNlZDoKLgpTdGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2 MCBzZWNvbmRzLgoKU2F0IEp1bCAyMyAwMDoyMzoyMSBVVEMgMjAwNQpKdWwgMjMgMDA6MjM6Mjcg cHJvbGVwc2lzIGxvZ2luOiBST09UIExPR0lOIChyb290KSBPTiB0dHl2MAo= ------=_Part_599_26350432.1122080047536 Content-Type: application/octet-stream; name="dmesg.head" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.head" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICM0OiBGcmkgSnVsIDIyIDIzOjUzOjQw IFVUQyAyMDA1CiAgICBrYWR1a0Bwcm9sZXBzaXMubWF0aC51aXVjLmVkdTovdXNyL29iai91c3Iv c3JjL3N5cy9QUk9MRVBTSVMKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDAKQ1BVOiBNb2JpbGUgSW50ZWwoUikgUGVudGl1bShSKSA0IC0gTSBDUFUgMi41 MEdIeiAoMjQ5Mi42NS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVs IiAgSWQgPSAweGYyOSAgU3RlcHBpbmcgPSA5CiAgRmVhdHVyZXM9MHhiZmViZjlmZjxGUFUsVk1F LERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNF MzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZl YXR1cmVzMj0weDQ0MDA8Q05UWC1JRCw8YjE0Pj4KcmVhbCBtZW1vcnkgID0gMTA3MzQwNTk1MiAo MTAyMyBNQikKYXZhaWwgbWVtb3J5ID0gMTA0MTUyNjc4NCAoOTkzIE1CKQpucHgwOiBbRkFTVF0K bnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZApucHgwOiBJTlQgMTYgaW50ZXJm YWNlCmFjcGkwOiA8REVMTCBDUGkgUiAgPiBvbiBtb3RoZXJib2FyZApwY2lfbGluazA6IDxBQ1BJ IFBDSSBMaW5rIExOS0E+IGlycSAxMSBvbiBhY3BpMApwY2lfbGluazE6IDxBQ1BJIFBDSSBMaW5r IExOS0I+IGlycSAxMSBvbiBhY3BpMApwY2lfbGluazI6IDxBQ1BJIFBDSSBMaW5rIExOS0M+IGly cSAxMSBvbiBhY3BpMApwY2lfbGluazM6IDxBQ1BJIFBDSSBMaW5rIExOS0Q+IGlycSAxMSBvbiBh Y3BpMApwY2lfbGluazQ6IDxBQ1BJIFBDSSBMaW5rIExOS0U+IG9uIGFjcGkwCnBjaV9saW5rNTog PEFDUEkgUENJIExpbmsgTE5LSD4gaXJxIDExIG9uIGFjcGkwClRpbWVjb3VudGVyICJBQ1BJLXNh ZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmFjcGlfdGhyb3R0bGUwOiA8QUNQSSBDUFUgVGhyb3R0bGluZz4g b24gY3B1MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYWNwaV9jbWJhdDA6IDxD b250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2NtYmF0MTogPENvbnRyb2wgTWV0 aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0 Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9i dXR0b24xOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJp ZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIwCnBjaV9saW5rMTogVW5hYmxlIHRvIGNob29zZSBhbiBJUlEKYWdwMDogPEludGVsIDgyODQ1 IGhvc3QgdG8gQUdQIGJyaWRnZT4gbWVtIDB4ZTgwMDAwMDAtMHhlZmZmZmZmZiBhdCBkZXZpY2Ug MC4wIG9uIHBjaTAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9u IHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPGRpc3BsYXksIFZHQT4g YXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQp1aGNpMDogPEludGVsIDgyODAxREIg KElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4YmY4MC0weGJmOWYgaXJxIDExIGF0 IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4 MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJl dmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVoY2kxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBv cnQgMHhiZjQwLTB4YmY1ZiBpcnEgMTEgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMTogW0dJ QU5ULUxPQ0tFRF0KdXNiMTogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVT Qi1CPiBvbiB1aGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiBJbnRlbCBVSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMTogMiBwb3J0cyB3 aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTI6IDxJbnRlbCA4MjgwMURCIChJQ0g0 KSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweGJmMjAtMHhiZjNmIGlycSAxMSBhdCBkZXZp Y2UgMjkuMiBvbiBwY2kwCnVoY2kyOiBbR0lBTlQtTE9DS0VEXQp1c2IyOiA8SW50ZWwgODI4MDFE QiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lv biAxLjAKdWh1YjI6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApl aGNpMDogPEludGVsIDgyODAxREIvREJML0RCTSAoSUNINCkgVVNCIDIuMCBjb250cm9sbGVyPiBt ZW0gMHhmNGZmZmMwMC0weGY0ZmZmZmZmIGlycSAxMSBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVo Y2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IzOiBFSENJIHZlcnNpb24gMS4wCnVzYjM6IGNvbXBhbmlv biBjb250cm9sbGVycywgMiBwb3J0cyBlYWNoOiB1c2IwIHVzYjEgdXNiMgp1c2IzOiA8SW50ZWwg ODI4MDFEQi9EQkwvREJNIChJQ0g0KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjM6 IFVTQiByZXZpc2lvbiAyLjAKdWh1YjM6IEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAxCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZApwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9u IHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKYmZlMDogPEJyb2FkY29tIEJDTTQ0 MDEgRmFzdCBFdGhlcm5ldD4gbWVtIDB4ZmFmZmUwMDAtMHhmYWZmZmZmZiBpcnEgMTEgYXQgZGV2 aWNlIDAuMCBvbiBwY2kyCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZmUwCmJtdHBoeTA6IDxCQ000 NDAxIDEwLzEwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKYm10cGh5MDogIDEwYmFzZVQsIDEwYmFz ZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KYmZlMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MGI6ZGI6OTk6ZTg6YzcKY2JiMDogPFRJNDUxMCBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMgpjYXJkYnVzMDogPENhcmRCdXMgYnVzPiBvbiBjYmIwCnBj Y2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMApmd29oY2kwOiA8MTM5NCBPcGVuIEhv c3QgQ29udHJvbGxlciBJbnRlcmZhY2U+IG1lbSAweGZhZmZkODAwLTB4ZmFmZmRmZmYsMHhmYWZm ODAwMC0weGZhZmZiZmZmIGlycSAxMSBhdCBkZXZpY2UgMS4xIG9uIHBjaTIKZndvaGNpMDogT0hD SSB2ZXJzaW9uIDEuMTAgKFJPTT0wKQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5l bHMgaXMgNC4KZndvaGNpMDogRVVJNjQgNDY6NGY6YzA6MDA6MWQ6MmY6MWM6NjEKZndvaGNpMDog UGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAyIHBvcnRzLgpmd29oY2kwOiBMaW5rIFM0MDAsIG1h eF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24g ZndvaGNpMApzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndv aGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IG5vZGVfaWQ9MHhjODAwZmZjMCwgZ2Vu PTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2Fi bGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCnBjaTI6IDxuZXR3 b3JrPiBhdCBkZXZpY2UgMy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBi cmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0 YXBjaTA6IDxJbnRlbCBJQ0g0IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNyww eDNmNiwweDE3MC0weDE3NywweDM3NiwweGJmYTAtMHhiZmFmIGF0IGRldmljZSAzMS4xIG9uIHBj aTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMTogPEFUQSBjaGFubmVsIDE+ IG9uIGF0YXBjaTAKcGNtMDogPEludGVsIElDSDQgKDgyODAxREIpPiBwb3J0IDB4YjgwMC0weGI4 ZmYsMHhiYzQwLTB4YmM3ZiBtZW0gMHhmNGZmZjgwMC0weGY0ZmZmOWZmLDB4ZjRmZmY0MDAtMHhm NGZmZjRmZiBpcnEgOSBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwCnBjbTA6IFtHSUFOVC1MT0NLRURd CnBjbTA6IDxTaWdtYVRlbCBTVEFDOTc1MC81MSBBQzk3IENvZGVjPgpwY2kwOiA8c2ltcGxlIGNv bW1zLCBnZW5lcmljIG1vZGVtPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQph Y3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQg S2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQt TE9DS0VEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5U LUxPQ0tFRF0KcHNtMDogbW9kZWwgR2xpZGVQb2ludCwgZGV2aWNlIElEIDAKc2lvMDogPDE2NTUw QS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIGZsYWdzIDB4MTAg b24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBv cnQ+IHBvcnQgMHgzNzgtMHgzN2YsMHg3NzgtMHg3N2IgaXJxIDcgZHJxIDEgb24gYWNwaTAKcHBj MDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1v ZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFs bGVsIHBvcnQgYnVzPiBvbiBwcGMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50 ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApwbXRpbWVy MCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjZjdm ZiwweGNmODAwLTB4Y2ZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTAKdW1zMDogTG9naXRlY2ggT3B0aWNhbCBVU0IgTW91c2UsIHJldiAy LjAwLzMuNDAsIGFkZHIgMiwgaWNsYXNzIDMvMQp1bXMwOiAzIGJ1dHRvbnMgYW5kIFogZGlyLgpU aW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjQ5MjY1MTUzNiBIeiBxdWFsaXR5IDgwMApUaW1l Y291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmFkMDogNzYzMTlNQiA8SUMyNU4wODBBVE1S MDQgMCBNTzRPQUQwQT4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMApzaW80OiA8SUJNIDU2SyBEYXRh LUZheCBNb2RlbT4gYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgMTEgZnVuY3Rpb24gMCBjb25maWcg MzIgb24gcGNjYXJkMApzaW80OiB0eXBlIDE2NTUwQQpzaW80OiB1bmFibGUgdG8gYWN0aXZhdGUg aW50ZXJydXB0IGluIGZhc3QgbW9kZSAtIHVzaW5nIG5vcm1hbCBtb2RlCmFjZDA6IENEUlcgPE1B VFNISVRBIENELVJXL0RWRC1ST00gVUpEQTc0MC8xLjAzPiBhdCBhdGExLW1hc3RlciBVRE1BMzMK VHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzM2EKTG9hZGluZyBjb25maWd1 cmF0aW9uIGZpbGVzLgprZW52OiAKdW5hYmxlIHRvIGdldCBkdW1wZGV2CgprZXJuZWwgZHVtcHMg b24gL2Rldi9hZDBzMmIKRW50cm9weSBoYXJ2ZXN0aW5nOgogaW50ZXJydXB0cwogZXRoZXJuZXQK IHBvaW50X3RvX3BvaW50CiBraWNrc3RhcnQKLgpzd2Fwb246IGFkZGluZyAvZGV2L2FkMHMyYiBh cyBzd2FwIGRldmljZQpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Ci9kZXYvYWQwczNhOiBG SUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQwczNhOiBjbGVhbiwgOTM1 ODYgZnJlZSAoODI2IGZyYWdzLCAxMTU5NSBibG9ja3MsIDAuNyUgZnJhZ21lbnRhdGlvbikKL2Rl di9hZDBzM2U6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZDBzM2U6 IGNsZWFuLCAxMjIzNjIgZnJlZSAoNDIgZnJhZ3MsIDE1MjkwIGJsb2NrcywgMC4wJSBmcmFnbWVu dGF0aW9uKQovZGV2L2FkMHMzZjogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwov ZGV2L2FkMHMzZjogY2xlYW4sIDY0MjI1NTkgZnJlZSAoNjQyMTUgZnJhZ3MsIDc5NDc5MyBibG9j a3MsIDAuOCUgZnJhZ21lbnRhdGlvbikKL2Rldi9hZDBzM2Q6IEZJTEUgU1lTVEVNIENMRUFOOyBT S0lQUElORyBDSEVDS1MKL2Rldi9hZDBzM2Q6IGNsZWFuLCA5MzI0NyBmcmVlICgyMTUgZnJhZ3Ms IDExNjI5IGJsb2NrcywgMC4yJSBmcmFnbWVudGF0aW9uKQpTZXR0aW5nIGhvc3RuYW1lOiBwcm9s ZXBzaXMubWF0aC51aXVjLmVkdS4KREhDUFJFUVVFU1Qgb24gYmZlMCB0byAyNTUuMjU1LjI1NS4y NTUgcG9ydCA2NwoKREhDUEFDSyBmcm9tIDEzMC4xMjYuMTEwLjEwCgpib3VuZCB0byAxMzAuMTI2 LjExMS4yNCAtLSByZW5ld2FsIGluIDE4MDAgc2Vjb25kcy4KCmJmZTA6IGZsYWdzPTg4NDM8VVAs QlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG10dSAxNTAwCglvcHRpb25zPTg8 VkxBTl9NVFU+CglpbmV0NiBmZTgwOjoyMGI6ZGJmZjpmZTk5OmU4YzclYmZlMCBwcmVmaXhsZW4g NjQgc2NvcGVpZCAweDEgCglpbmV0IDEzMC4xMjYuMTExLjI0IG5ldG1hc2sgMHhmZmZmZmMwMCAK CWV0aGVyIDAwOjBiOmRiOjk5OmU4OmM3CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAw YmFzZVRYIDxmdWxsLWR1cGxleD4pCglzdGF0dXM6IGFjdGl2ZQpsbzA6IGZsYWdzPTgwNDk8VVAs TE9PUEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+IG10dSAxNjM4NAoJaW5ldCAxMjcuMC4wLjEgbmV0 bWFzayAweGZmMDAwMDAwIAoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgwOjox JWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDIgCkFkZGl0aW9uYWwgcm91dGluZyBvcHRpb25z OgouClN0YXJ0aW5nIGRldmQuClN0YXJ0aW5nIHVtczAgbW91c2VkOgouCmh3LmFjcGkuY3B1LmN4 X2xvd2VzdDogCkMxCiAtPiAKQzEKCmRoY2xpZW50IGJmZTA6IGFscmVhZHkgcnVubmluZz8KZGhj bGllbnQgYmZlMDogYWxyZWFkeSBydW5uaW5nPwpNb3VudGluZyBORlMgZmlsZSBzeXN0ZW1zOgou CkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBsb2cgZmlsZXM6Ci4KU3RhcnRpbmcgc3lzbG9nZC4K Q2hlY2tpbmcgZm9yIGNvcmUgZHVtcCBvbiAvZGV2L2FkMHMyYi4uLgpzYXZlY29yZTogdW5hYmxl IHRvIG9wZW4gYm91bmRzIGZpbGUsIHVzaW5nIDAKc2F2ZWNvcmU6IG5vIGR1bXBzIGZvdW5kCkVM RiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNyL1gxMVI2 L2xpYiAvdXNyL2xvY2FsL2xpYiAvdXNyL2xvY2FsL2xpYi9jb21wYXQvcGtnCmEub3V0IGxkY29u ZmlnIHBhdGg6IC91c3IvbGliL2FvdXQgL3Vzci9saWIvY29tcGF0L2FvdXQgL3Vzci9YMTFSNi9s aWIvYW91dApTdGFydGluZyB1c2JkLgpTdGFydGluZyBsb2NhbCBkYWVtb25zOgouClVwZGF0aW5n IG1vdGQKLgpDb25maWd1cmluZyBzeXNjb25zOgogYmxhbmt0aW1lCiBzY3JlZW5zYXZlcgouClN0 YXJ0aW5nIHNzaGQuCkluaXRpYWwgaTM4NiBpbml0aWFsaXphdGlvbjoKLgpBZGRpdGlvbmFsIEFC SSBzdXBwb3J0OgogbGludXgKLgpTdGFydGluZyBjcm9uLgpMb2NhbCBwYWNrYWdlIGluaXRpYWxp emF0aW9uOgouCkFkZGl0aW9uYWwgVENQIG9wdGlvbnM6Ci4KU3RhcnRpbmcgZGVmYXVsdCBtb3Vz ZWQ6Ci4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25k cy4KClNhdCBKdWwgMjMgMDA6MzE6MTUgVVRDIDIwMDUKSnVsIDIzIDAwOjMxOjE5IHByb2xlcHNp cyBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04gdHR5djAK ------=_Part_599_26350432.1122080047536 Content-Type: application/octet-stream; name="dmesg.head.verbose" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.head.verbose" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICM0OiBGcmkgSnVsIDIyIDIzOjUzOjQw IFVUQyAyMDA1CiAgICBrYWR1a0Bwcm9sZXBzaXMubWF0aC51aXVjLmVkdTovdXNyL29iai91c3Iv c3JjL3N5cy9QUk9MRVBTSVMKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJu ZWwiIGF0IDB4YzA4NGQwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbGlu dXgua28iIGF0IDB4YzA4NGQxNTguClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwv YWNwaS5rbyIgYXQgMHhjMDg0ZDIwNC4KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4uIGk4MjU0IGNs b2NrOiAxMTkzMTcyIEh6CkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmllZCAt IHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAy NDkyNjUzMDMyIEh6CkNQVTogTW9iaWxlIEludGVsKFIpIFBlbnRpdW0oUikgNCAtIE0gQ1BVIDIu NTBHSHogKDI0OTIuNjUtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRl bCIgIElkID0gMHhmMjkgIFN0ZXBwaW5nID0gOQogIEZlYXR1cmVzPTB4YmZlYmY5ZmY8RlBVLFZN RSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBT RTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBG ZWF0dXJlczI9MHg0NDAwPENOVFgtSUQsPGIxND4+CnJlYWwgbWVtb3J5ICA9IDEwNzM0MDU5NTIg KDEwMjMgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0g MHgwMDAwMDAwMDAwMDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykKMHgwMDAwMDAwMDAw MTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpCjB4 MDAwMDAwMDAwMGMyNTAwMCAtIDB4MDAwMDAwMDAzZWQ3NmZmZiwgMTA0MTU3MTg0MCBieXRlcyAo MjU0MjkwIHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAxMDQxNTI2Nzg0ICg5OTMgTUIpCmJpb3MzMjog Rm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGZmZTgwCmJpb3Mz MjogRW50cnkgPSAweGZmZTkwIChjMDBmZmU5MCkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlvczog UENJIEJJT1MgZW50cnkgYXQgMHhmMDAwMCsweGM5NmUKcG5wYmlvczogRm91bmQgUG5QIEJJT1Mg ZGF0YSBhdCAweGMwMGZlMmQwCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6ZTJmNCAgUmV2ID0gMS4w CnBucGJpb3M6IEV2ZW50IGZsYWcgYXQgNGI0Ck90aGVyIEJJT1Mgc2lnbmF0dXJlcyBmb3VuZDoK cmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm1lbTogPG1lbW9yeT4K UGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKaW86IDxJL08+Cm51bGw6IDxudWxsIGRl dmljZSwgemVybyBkZXZpY2U+Cm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9u IG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxERUxMIENQaSBSICA+ IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAxIGFkZHIg cG9ydCAoMHgwY2Y4KSBpcyAweDgwMDBlYWM0CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAw MDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBb aGRyPTAwXSBpcyB0aGVyZSAoaWQ9MWEzMDgwODYpCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEw CkZvdW5kICRQSVIgdGFibGUsIDkgZW50cmllcyBhdCAweGMwMGZjNTgwClBDSS1Pbmx5IEludGVy cnVwdHM6IG5vbmUKTG9jYXRpb24gIEJ1cyBEZXZpY2UgUGluICBMaW5rICBJUlFzCmVtYmVkZGVk ICAgIDAgICAyOSAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRk ZWQgICAgMCAgIDI5ICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJl ZGRlZCAgICAwICAgMjkgICAgQyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVt YmVkZGVkICAgIDAgICAyOSAgICBEICAgMHg2YiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUK ZW1iZWRkZWQgICAgMCAgIDMwICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAx NQplbWJlZGRlZCAgICAwICAgMzAgICAgQiAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1CmVtYmVkZGVkICAgIDAgICAzMCAgICBDICAgMHg2MiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKZW1iZWRkZWQgICAgMCAgIDMwICAgIEQgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAx MiAxNCAxNQplbWJlZGRlZCAgICAwICAgMzEgICAgQSAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDEx IDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBCICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAg MTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMSAgICAwICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAyICAgIDAgICAgQSAgIDB4NjIgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDIgICAgMSAgICBBICAgMHg2MyAgMyA0IDUgNiA3 IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMiAgICAxICAgIEIgICAweDYzICBub25lCmVt YmVkZGVkICAgIDIgICAgMyAgICBBICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUK ZW1iZWRkZWQgICAgMiAgICAzICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAx NQplbWJlZGRlZCAgICA4ICAgIDAgICAgQSAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1CmVtYmVkZGVkICAgIDggICAgMCAgICBCICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKZW1iZWRkZWQgICAgOCAgICAxICAgIEEgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAx MiAxNCAxNQplbWJlZGRlZCAgICA4ICAgIDEgICAgQiAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDEx IDEyIDE0IDE1CmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5n IDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaV9idXNfbnVtYmVy OiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVz IDAgZGV2IDMxIGZ1bmMgMAphdHBpYzogUHJvZ3JhbW1pbmcgSVJROSBhcyBsZXZlbC9sb3cKcGNp X2xpbmswOiA8QUNQSSBQQ0kgTGluayBMTktBPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xpbmswOiBM aW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgIDExICAgTiAgICAgMCAgOSAxMCAxMQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwg dmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4gICAg IDAgIDkgMTAgMTEKcGNpX2xpbmswOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgOSAxMCAxMQpwY2lfbGluazE6IDxB Q1BJIFBDSSBMaW5rIExOS0I+IGlycSAxMSBvbiBhY3BpMApwY2lfbGluazE6IExpbmtzIGFmdGVy IGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTEgICBO ICAgICAwICA1IDcKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246Cklu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcKcGNpX2xp bmsxOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3CnBjaV9saW5rMjogPEFDUEkgUENJIExpbmsgTE5LQz4gaXJx IDExIG9uIGFjcGkwCnBjaV9saW5rMjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4gICAgIDAgIDkgMTAgMTEKcGNpX2xp bmsyOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgICAwICAgMTEgICBOICAgICAwICA5IDEwIDExCnBjaV9saW5rMjogTGlua3MgYWZ0 ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDkgMTAgMTEKcGNpX2xpbmszOiA8QUNQSSBQQ0kgTGluayBMTktEPiBpcnEgMTEgb24gYWNw aTAKcGNpX2xpbmszOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTAgMTEKcGNpX2xpbmszOiBM aW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAgMTEgICBOICAgICAwICA1IDcgOSAxMCAxMQpwY2lfbGluazM6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICA1IDcgOSAxMCAxMQpwY2lfbGluazQ6IDxBQ1BJIFBDSSBMaW5rIExOS0U+IG9uIGFjcGkwCnBj aV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBj aV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNp X2xpbms1OiA8QUNQSSBQQ0kgTGluayBMTktIPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xpbms1OiBM aW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiBM aW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGlu azU6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpBQ1BJIHRpbWVyOiAw LzEwIDAvMTAgMC8xMCAwLzEwIDAvMTAgMC8xMCAwLzEwIDAvMTAgMC8xMCAwLzEwIC0+IDAKVGlt ZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFj cGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBi IG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJ IENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmFjcGlfdGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBfQkxL IDB4OGUwCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMAphY3BpX2NtYmF0MDogPENv bnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfY21iYXQxOiA8Q29udHJvbCBNZXRo b2QgQmF0dGVyeT4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRj aD4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX2J1 dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlk Z2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgxYTMw LCByZXZpZD0weDA0CglidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGU4MDAw MDAwLCBzaXplIDI3LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MWEzMSwg cmV2aWQ9MHgwNAoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDBjICgzMDAwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjMiwg cmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgNCwgcmFu Z2UgMzIsIGJhc2UgMDAwMGJmODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMjkuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxOS0E6MCkKcGNpYjA6IHNsb3QgMjkg SU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTktBCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MjRjNCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJ Y2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3Rh dHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTEK CW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGJmNDAsIHNpemUgIDUsIGVuYWJs ZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkxO S0Q6MCkKcGNpYjA6IHNsb3QgMjkgSU5UQiByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJ MC5MTktECmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNywgcmV2aWQ9MHgwMwoJYnVz PTAsIHNsb3Q9MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1jLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAw MGJmMjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5U QyAoc3JjIFxcX1NCXy5QQ0kwLkxOS0M6MCkKcGNpYjA6IHNsb3QgMjkgSU5UQyByb3V0ZWQgdG8g aXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTktDCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjRjZCwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFz ZSBmNGZmZmMwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y OS5JTlREIChzcmMgXFxfU0JfLlBDSTAuTE5LSDowKQpwY2liMDogc2xvdCAyOSBJTlREIHJvdXRl ZCB0byBpcnEgMTEgdmlhIFxcX1NCXy5QQ0kwLkxOS0gKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNDQ4LCByZXZpZD0weDgzCglidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0wNi0w NC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4ODA4 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw NCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDI0Y2MsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTA2LTAx LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMGYsIHN0YXRyZWc9MHgwMjgw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjRjYSwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtOGEs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MjU1CgltYXBbMjBdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiZmEwLCBzaXplICA0LCBlbmFibGVkCgltYXBbMjRdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDAwMDAwMDAwLCBzaXplIDEwLCBtZW1vcnkgZGlzYWJsZWQK Zm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM1LCByZXZpZD0weDAzCglidXM9MCwgc2xv dD0zMSwgZnVuYz01CgljbGFzcz0wNC0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50 cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglt YXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiODAwLCBzaXplICA4LCBlbmFibGVk CgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiYzQwLCBzaXplICA2LCBlbmFi bGVkCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmODAwLCBzaXplICA5LCBl bmFibGVkCgltYXBbMWNdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmNDAwLCBzaXplICA4 LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9TQl8u UENJMC5MTktCOjApCnBjaV9saW5rMTogUGlja2VkIElSUSA5IHdpdGggd2VpZ2h0IDAKcGNpYjA6 IHNsb3QgMzEgSU5UQiByb3V0ZWQgdG8gaXJxIDkgdmlhIFxcX1NCXy5QQ0kwLkxOS0IKZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM2LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0zMSwg ZnVuYz02CgljbGFzcz0wNy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIs IGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBd OiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiNDAwLCBzaXplICA4LCBlbmFibGVkCgltYXBb MTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiMDgwLCBzaXplICA3LCBlbmFibGVkCnBj aWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTktCOjAp CnBjaWIwOiBzbG90IDMxIElOVEIgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uUENJMC5MTktC CmFncDA6IDxJbnRlbCA4Mjg0NSBob3N0IHRvIEFHUCBicmlkZ2U+IG1lbSAweGU4MDAwMDAwLTB4 ZWZmZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kwCmFncDA6IFJlc2VydmVkIDB4ODAwMDAwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTgwMDAwMDAKYWdwMDogYWxsb2NhdGluZyBH QVRUIGZvciBhcGVydHVyZSBvZiBzaXplIDEyOE0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2li MTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4YzAw MC0weGNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmYzAwMDAwMC0weGZkZmZmZmZm CnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZjAwMDAwMDAtMHhmM2ZmZmZmZgpwY2kxOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDAyODYsIHJldmlkPTB4YTEKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MAoJ Y2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAyNywgc3Rh dHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMp LCBtaW5nbnQ9MHgwNSAoMTI1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglpbnRwaW49YSwg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmMwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjE6 IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmMwMDAwMDAtMHhmY2ZmZmZmZjogZ29v ZAoJbWFwWzE0XTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSBmMDAwMDAwMCwgc2l6ZSAyNiwgZW5h YmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmMDAwMDAwMC0weGYz ZmZmZmZmOiBnb29kCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5UQSAoc3JjIFxcX1NC Xy5QQ0kwLkxOS0E6MCkKcGNpYjE6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTEgdmlhIFxc X1NCXy5QQ0kwLkxOS0EKcGNpMTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8gZHJp dmVyIGF0dGFjaGVkKQp1aGNpMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVy IFVTQi1BPiBwb3J0IDB4YmY4MC0weGJmOWYgaXJxIDExIGF0IGRldmljZSAyOS4wIG9uIHBjaTAK dWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGJmODAK dWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29u dHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50 ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8SW50ZWwgODI4 MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhiZjQwLTB4YmY1ZiBpcnEg MTEgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3Ig cmlkIDB4MjAgdHlwZSA0IGF0IDB4YmY0MAp1aGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNiMTogPElu dGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2IxOiBV U0IgcmV2aXNpb24gMS4wCnVodWIxOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdWhjaTI6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0It Qz4gcG9ydCAweGJmMjAtMHhiZjNmIGlycSAxMSBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2ky OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhiZjIwCnVoY2ky OiBbR0lBTlQtTE9DS0VEXQp1c2IyOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xs ZXIgVVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IEludGVsIFVI Q0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIyOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEludGVsIDgyODAxREIv REJML0RCTSAoSUNINCkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmNGZmZmMwMC0weGY0ZmZm ZmZmIGlycSAxMSBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDQwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjRmZmZjMDAKZWhjaTA6IFtHSUFOVC1MT0NL RURdCnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAy IHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVzYjM6IDxJbnRlbCA4MjgwMURCL0RCTC9EQk0g KElDSDQpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMzogVVNCIHJldmlzaW9uIDIu MAp1aHViMzogSW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBh ZGRyIDEKdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaWIy OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2liMjogICBz ZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjI6ICAg SS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZWZmZgpwY2liMjogICBtZW1vcnkgZGVjb2RlICAg ICAweGY2MDAwMDAwLTB4ZmJmZmZmZmYKcGNpYjI6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYw MDAwMC0weGZmZmZmCnBjaWIyOiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTI6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTI6IHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVu ZG9yPTB4MTRlNCwgZGV2PTB4NDQwMSwgcmV2aWQ9MHgwMQoJYnVzPTIsIHNsb3Q9MCwgZnVuYz0w CgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsx MF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmFmZmUwMDAsIHNpemUgMTMsIGVuYWJsZWQKcGNp YjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmFmZmUwMDAtMHhmYWZmZmZmZjog Z29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEgKHNyYyBcXF9TQl8uUENJMC5M TktDOjApCnBjaWIyOiBzbG90IDAgSU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJ MC5MTktDCmZvdW5kLT4JdmVuZG9yPTB4MTA0YywgZGV2PTB4YWM0NCwgcmV2aWQ9MHgwMgoJYnVz PTIsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNy0wMCwgaGRydHlwZT0weDAyLCBtZmRldj0x CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxh dHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDQwICgxNjAwMCBucyksIG1heGxhdD0weDA3 ICgxNzUwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSAwMDAw MDAwMCwgc2l6ZSAxMiwgbWVtb3J5IGRpc2FibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTA0YywgZGV2 PTB4ODAyOSwgcmV2aWQ9MHgwMAoJYnVzPTIsIHNsb3Q9MSwgZnVuYz0xCgljbGFzcz0wYy0wMC0x MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTE2LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAy ICg1MDAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAx LCByYW5nZSAzMiwgYmFzZSBmYWZmZDgwMCwgc2l6ZSAxMSwgZW5hYmxlZApwY2liMjogKG51bGwp IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYWZmZDgwMC0weGZhZmZkZmZmOiBnb29kCgltYXBb MTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZhZmY4MDAwLCBzaXplIDE0LCBlbmFibGVkCnBj aWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZhZmY4MDAwLTB4ZmFmZmJmZmY6 IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMS5JTlRBIChzcmMgXFxfU0JfLlBDSTAu TE5LRDowKQpwY2liMjogc2xvdCAxIElOVEEgcm91dGVkIHRvIGlycSAxMSB2aWEgXFxfU0JfLlBD STAuTE5LRApmb3VuZC0+CXZlbmRvcj0weDE0ZTQsIGRldj0weDQzMjQsIHJldmlkPTB4MDIKCWJ1 cz0yLCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MDItODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQz ICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZhZmY2MDAwLCBz aXplIDEzLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZh ZmY2MDAwLTB4ZmFmZjdmZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMy5JTlRB IChzcmMgXFxfU0JfLlBDSTAuTE5LQjowKQpwY2liMjogc2xvdCAzIElOVEEgcm91dGVkIHRvIGly cSA5IHZpYSBcXF9TQl8uUENJMC5MTktCCmJmZTA6IDxCcm9hZGNvbSBCQ000NDAxIEZhc3QgRXRo ZXJuZXQ+IG1lbSAweGZhZmZlMDAwLTB4ZmFmZmZmZmYgaXJxIDExIGF0IGRldmljZSAwLjAgb24g cGNpMgpiZmUwOiBSZXNlcnZlZCAweDIwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAw eGZhZmZlMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZmUwCmJtdHBoeTA6IDxCQ000NDAxIDEw LzEwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKYm10cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KYmZlMDogYnBmIGF0dGFjaGVkCmJmZTA6 IEV0aGVybmV0IGFkZHJlc3M6IDAwOjBiOmRiOjk5OmU4OmM3CmJmZTA6IFtNUFNBRkVdCmNiYjA6 IDxUSTQ1MTAgUENJLUNhcmRCdXMgQnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTIKcGNpYjI6 IGNiYjAgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY2MDAwMDAwLTB4ZmJmZmZmZmY6IGdvb2QK Y2JiMDogTGF6eSBhbGxvY2F0aW9uIG9mIDB4MTAwMCBieXRlcyByaWQgMHgxMCB0eXBlIDMgYXQg MHhmNjAwMDAwMApjYXJkYnVzMDogPENhcmRCdXMgYnVzPiBvbiBjYmIwCnBjY2FyZDA6IDwxNi1i aXQgUENDYXJkIGJ1cz4gb24gY2JiMApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4xLklOVEEg KHNyYyBcXF9TQl8uUENJMC5MTktEOjApCnBjaWIyOiBzbG90IDEgSU5UQSByb3V0ZWQgdG8gaXJx IDExIHZpYSBcXF9TQl8uUENJMC5MTktECmNiYjA6IFtNUFNBRkVdCmNiYjA6IFBDSSBDb25maWd1 cmF0aW9uIHNwYWNlOgogIDB4MDA6IDB4YWM0NDEwNGMgMHgwMjEwMDAwNyAweDA2MDcwMDAyIDB4 MDA4MjIwMDggCiAgMHgxMDogMHhmNjAwMDAwMCAweDAyMDAwMGEwIDB4MjAwNDAzMDIgMHhmZmZm ZjAwMCAKICAweDIwOiAweDAwMDAwMDAwIDB4ZmZmZmYwMDAgMHgwMDAwMDAwMCAweGZmZmZmZmZj IAogIDB4MzA6IDB4MDAwMDAwMDAgMHhmZmZmZmZmYyAweDAwMDAwMDAwIDB4MDc0MDAxMGIgCiAg MHg0MDogMHgwMTNlMTAyOCAweDAwMDAwMDAxIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUw OiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4 MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAw MDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDgwOiAweDI4NDA3MDYx IDB4MDAwMDAwMDAgMHgwMDFmMDAwMCAweDAxMmMxMjAyIAogIDB4OTA6IDB4NjA2NDgzYzAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhhMDogMHhmZTEyMDAwMSAweDAwYzAw MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGIwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhkMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgMHgwMDAwMDAwMCAKICAweGUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAw eDAwMDAwMDAwIAogIDB4ZjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgCmZ3b2hjaTA6IHZlbmRvcj0xMDRjLCBkZXY9ODAyOQpmd29oY2kwOiB2ZW5kb3I9MTA0 YywgZGV2PTgwMjkKZndvaGNpMDogPDEzOTQgT3BlbiBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNl PiBtZW0gMHhmYWZmZDgwMC0weGZhZmZkZmZmLDB4ZmFmZjgwMDAtMHhmYWZmYmZmZiBpcnEgMTEg YXQgZGV2aWNlIDEuMSBvbiBwY2kyCmZ3b2hjaTA6IFJlc2VydmVkIDB4ODAwIGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDMgYXQgMHhmYWZmZDgwMApmd29oY2kwOiBbTVBTQUZFXQpmd29oY2kwOiBP SENJIHZlcnNpb24gMS4xMCAoUk9NPTApCmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFu bmVscyBpcyA0Lgpmd29oY2kwOiBFVUk2NCA0Njo0ZjpjMDowMDoxZDoyZjoxYzo2MQpmd29oY2kw OiBQaHkgMTM5NGEgYXZhaWxhYmxlIFM0MDAsIDIgcG9ydHMuCmZ3b2hjaTA6IExpbmsgUzQwMCwg bWF4X3JlYyAyMDQ4IGJ5dGVzLgpmaXJld2lyZTA6IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBv biBmd29oY2kwCnNicDA6IDxTQlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApm d29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQKZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBn ZW49MSwgQ1lDTEVNQVNURVIgbW9kZQpmaXJld2lyZTA6IDEgbm9kZXMsIG1heGhvcCA8PSAwLCBj YWJsZSBJUk0gPSAwIChtZSkKZmlyZXdpcmUwOiBidXMgbWFuYWdlciAwIChtZSkKcGNpMjogPG5l dHdvcms+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMjozOjA6IFRyYW5z aXRpb24gZnJvbSBEMCB0byBEMwppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEu MCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgSUNINCBV RE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgz NzYsMHhiZmEwLTB4YmZhZiBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YXBjaTA6IFJlc2VydmVk IDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGJmYTAKYXRhMDogPEFUQSBjaGFu bmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0 MT0wMAphdGEwOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHN0 YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogcmVzZXQgdHAyIHN0YXQw PTUwIHN0YXQxPTAwIGRldmljZXM9MHgxPEFUQV9NQVNURVI+CmF0YTA6IFtNUFNBRkVdCmF0YTE6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBm b3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBm b3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0 MD01MCBvc3RhdDE9MDAKYXRhMTogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhl YgphdGExOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTE6IHJlc2V0 IHRwMiBzdGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4YzxBVEFQSV9TTEFWRSxBVEFQSV9NQVNU RVI+CmF0YTE6IFtNUFNBRkVdCnBjbTA6IDxJbnRlbCBJQ0g0ICg4MjgwMURCKT4gcG9ydCAweGI4 MDAtMHhiOGZmLDB4YmM0MC0weGJjN2YgbWVtIDB4ZjRmZmY4MDAtMHhmNGZmZjlmZiwweGY0ZmZm NDAwLTB4ZjRmZmY0ZmYgaXJxIDkgYXQgZGV2aWNlIDMxLjUgb24gcGNpMApwY20wOiBSZXNlcnZl ZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4YjgwMApwY20wOiBSZXNlcnZl ZCAweDQwIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhiYzQwCnBjbTA6IFtHSUFOVC1M T0NLRURdCnBjbTA6IDxTaWdtYVRlbCBTVEFDOTc1MC81MSBBQzk3IENvZGVjIChpZCA9IDB4ODM4 NDc2NTApPgpwY20wOiBDb2RlYyBmZWF0dXJlcyBoZWFkcGhvbmUsIDIwIGJpdCBEQUMsIDIwIGJp dCBBREMsIDUgYml0IG1hc3RlciB2b2x1bWUsIFNpZ21hVGVsIDNEIEVuaGFuY2VtZW50CnBjbTA6 IFByaW1hcnkgY29kZWMgZXh0ZW5kZWQgZmVhdHVyZXMgdmFyaWFibGUgcmF0ZSBQQ00sIHJlc2Vy dmVkIDEsIEFNQVAsIHJlc2VydmVkIDQKcGNtMDogc25kYnVmX3NldG1hcCAzZTc1ZDAwMCwgNDAw MDsgMHhlZDJlYjAwMCAtPiAzZTc1ZDAwMApwY20wOiBzbmRidWZfc2V0bWFwIDNlNzU5MDAwLCA0 MDAwOyAweGVkMmVmMDAwIC0+IDNlNzU5MDAwCnBjaTA6IDxzaW1wbGUgY29tbXMsIGdlbmVyaWMg bW9kZW0+IGF0IGRldmljZSAzMS42IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6MzE6NjogVHJh bnNpdGlvbiBmcm9tIEQwIHRvIEQzCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApw c21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCmF0a2JkYzA6IDxLZXli b2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBr YmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA2NQphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFi ICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6 MHgwLCBmbGFnczoweDNkMDAwMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IGN1cnJlbnQg Y29tbWFuZCBieXRlOjAwNjUKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBz bTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEdsaWRlUG9pbnQsIGRldmljZSBJRCAwLTAw LCAyIGJ1dHRvbnMKcHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwOCwgcGFja2V0 IHNpemU6Mwpwc20wOiBzeW5jbWFzazpjMCwgc3luY2JpdHM6MDAKc2lvMDogaXJxIG1hcHM6IDB4 YTAxIDB4YTA5IDB4YTAxIDB4YTAxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4g cG9ydCAweDJmOC0weDJmZiBpcnEgMyBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1 NTBBCnBwYzA6IHVzaW5nIGV4dGVuZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVDUCBTUFAgRUNQ K0VQUCBTUFAKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+IHBvcnQgMHgzNzgtMHgz N2YsMHg3NzgtMHg3N2IgaXJxIDcgZHJxIDEgb24gYWNwaTAKcHBjMDogU01DLWxpa2UgY2hpcHNl dCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRo IDE2LzE2LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBw cGMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0 CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7 IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRrYmRj OiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwcGM6IHBwYzAgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNp bzogc2lvMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhp c3RzOyBza2lwcGluZyBpdApwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRl CmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzCmlzYV9wcm9iZV9jaGls ZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKcG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNB IE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2Y3ZmYsMHhjZjgwMC0weGNmZmZmIG9u IGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMCwgdGVy bWluYWwgZW11bGF0b3I6IHNjIChzeXNjb25zIHRlcm1pbmFsKQp2Z2EwOiA8R2VuZXJpYyBJU0Eg VkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmFk djA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaGEwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWlj MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmJ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmNzMDog bm90IHByb2JlZCAoZGlzYWJsZWQpCmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmZkYzAgZmFp bGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNh MApmZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQps bmMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lvMSBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAw eDJmOCBpcnEgMyBvbiBpc2EwCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzaW8zOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdnQwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnVt czA6IExvZ2l0ZWNoIE9wdGljYWwgVVNCIE1vdXNlLCByZXYgMi4wMC8zLjQwLCBhZGRyIDIsIGlj bGFzcyAzLzEKdW1zMDogMyBidXR0b25zIGFuZCBaIGRpci4KRGV2aWNlIGNvbmZpZ3VyYXRpb24g ZmluaXNoZWQuClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyNDkyNjUzMDMyIEh6IHF1YWxp dHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKTGludXggRUxGIGV4ZWMg aGFuZGxlciBpbnN0YWxsZWQKbG8wOiBicGYgYXR0YWNoZWQKYWNwaV9hY2FkMDogYWNsaW5lIGlu aXRpYWxpemF0aW9uIHN0YXJ0CmFjcGlfYWNhZDA6IE9uIExpbmUKYWNwaV9hY2FkMDogYWNsaW5l IGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKYWNwaV9jbWJhdDA6IGJhdHRlcnkg aW5pdGlhbGl6YXRpb24gc3RhcnQKYWNwaV9jbWJhdDA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24g ZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2NtYmF0MTogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBz dGFydAphdGEwLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9 ODAgd2lyZQphZDA6IHNldHRpbmcgUElPNCBvbiBJbnRlbCBJQ0g0IGNoaXAKYWQwOiBzZXR0aW5n IFVETUExMDAgb24gSW50ZWwgSUNINCBjaGlwCmFkMDogNzYzMTlNQiA8SUMyNU4wODBBVE1SMDQg MCBNTzRPQUQwQT4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMAphZDA6IDE1NjMwMTQ4OCBzZWN0b3Jz IFsxNTUwNjFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VP TTogbmV3IGRpc2sgYWQwCnBjaWIyOiBwY2NhcmQwIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhm NjAwMDAwMC0weGZiZmZmZmZmOiBnb29kCnBjY2FyZDA6IENJUyB2ZXJzaW9uIFBDIENhcmQgU3Rh bmRhcmQgNS4wCnBjY2FyZDA6IENJUyBpbmZvOiBJQk0sIDU2SyBEYXRhLUZheCBNb2RlbQpwY2Nh cmQwOiBNYW51ZmFjdHVyZXIgY29kZSAweDg5LCBwcm9kdWN0IDB4NDcKcGNjYXJkMDogZnVuY3Rp b24gMDogc2VyaWFsIHBvcnQsIGNjciBhZGRyIDMwMCBtYXNrIDMKcGNjYXJkMDogZnVuY3Rpb24g MCwgY29uZmlnIHRhYmxlIGVudHJ5IDMyOiBJL08gY2FyZDsgaXJxIG1hc2sgZmZmZjsgaW9tYXNr IGEsIGlvc3BhY2UgM2Y4LTNmZjsgcmR5YnN5X2FjdGl2ZSBpbzggaXJxbGV2ZWwgcG93ZXJkb3du IGF1ZGlvCnBjY2FyZDA6IGZ1bmN0aW9uIDAsIGNvbmZpZyB0YWJsZSBlbnRyeSAzMzogSS9PIGNh cmQ7IGlycSBtYXNrIGZmZmY7IGlvbWFzayBhLCBpb3NwYWNlIDJmOC0yZmY7IHJkeWJzeV9hY3Rp dmUgaW84IGlycWxldmVsIHBvd2VyZG93biBhdWRpbwpwY2NhcmQwOiBmdW5jdGlvbiAwLCBjb25m aWcgdGFibGUgZW50cnkgMzQ6IEkvTyBjYXJkOyBpcnEgbWFzayBmZmZmOyBpb21hc2sgYSwgaW9z cGFjZSAzZTgtM2VmOyByZHlic3lfYWN0aXZlIGlvOCBpcnFsZXZlbCBwb3dlcmRvd24gYXVkaW8K cGNjYXJkMDogZnVuY3Rpb24gMCwgY29uZmlnIHRhYmxlIGVudHJ5IDM1OiBJL08gY2FyZDsgaXJx IG1hc2sgZmZmZjsgaW9tYXNrIGEsIGlvc3BhY2UgMmU4LTJlZjsgcmR5YnN5X2FjdGl2ZSBpbzgg aXJxbGV2ZWwgcG93ZXJkb3duIGF1ZGlvCnBjaWIyOiBwY2NhcmQwIHJlcXVlc3RlZCBJL08gcmFu Z2UgMHgzZjgtMHgzZmY6IGluIHJhbmdlCnBjaWIyOiBwY2NhcmQwIHJlcXVlc3RlZCBtZW1vcnkg cmFuZ2UgMHhmNjAwMDAwMC0weGZiZmZmZmZmOiBnb29kCnNpbzQ6IDxJQk0gNTZLIERhdGEtRmF4 IE1vZGVtPiBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSAxMSBmdW5jdGlvbiAwIGNvbmZpZyAzMiBv biBwY2NhcmQwCnNpbzQ6IHR5cGUgMTY1NTBBCnNpbzQ6IHVuYWJsZSB0byBhY3RpdmF0ZSBpbnRl cnJ1cHQgaW4gZmFzdCBtb2RlIC0gdXNpbmcgbm9ybWFsIG1vZGUKYXRhMTogcmVpbml0aW5nIGNo YW5uZWwgLi4KYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTAwIG9zdGF0MT0wMAphdGEx OiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTE6IHN0YXQxPTB4MDAg ZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQx PTAwIGRldmljZXM9MHhjPEFUQVBJX1NMQVZFLEFUQVBJX01BU1RFUj4KYXRhMTogcmVpbml0IGRv bmUgLi4KYXRhMTogcmVpbml0aW5nIGNoYW5uZWwgLi4KYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMg b3N0YXQwPTAwIG9zdGF0MT0wMAphdGExOiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1z Yj0weGViCmF0YTE6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTog cmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHhjPEFUQVBJX1NMQVZFLEFUQVBJ X01BU1RFUj4KYXRhMTogcmVpbml0IGRvbmUgLi4KYXRhMS1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9 V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQphY2QwOiBzZXR0aW5nIFBJTzQgb24gSW50 ZWwgSUNINCBjaGlwCmFjZDA6IHNldHRpbmcgVURNQTMzIG9uIEludGVsIElDSDQgY2hpcAphY2Qw OiA8TUFUU0hJVEEgQ0QtUlcvRFZELVJPTSBVSkRBNzQwLzEuMDM+IENEUlcgZHJpdmUgYXQgYXRh MSBhcyBtYXN0ZXIKYWNkMDogcmVhZCA0MTM0S0IvcyAoNDEzNEtCL3MpIHdyaXRlIDQxMzRLQi9z ICg0MTM0S0IvcyksIDIwNDhLQiBidWZmZXIsIFVETUEzMwphY2QwOiBSZWFkczogQ0RSLCBDRFJX LCBDRERBIHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6 IENEUiwgQ0RSVywgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYg dm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAph Y2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKcGNtMDogbWVhc3VyZWQgYWM5NyBsaW5rIHJhdGUg YXQgNDgwMTIgSHosIHdpbGwgdXNlIDQ4MDAwIEh6Cihwcm9iZTA6c2JwMDowOjA6MCk6IGVycm9y IDIyCihwcm9iZTA6c2JwMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6c2JwMDow OjE6MCk6IGVycm9yIDIyCihwcm9iZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihw cm9iZTI6c2JwMDowOjI6MCk6IGVycm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6IFVucmV0cnlh YmxlIEVycm9yCihwcm9iZTM6c2JwMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6c2JwMDowOjM6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9yIDIyCihwcm9i ZTQ6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTU6c2JwMDowOjU6MCk6IGVy cm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTY6c2Jw MDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjY6MCk6IFVucmV0cnlhYmxlIEVycm9y ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczNhCnN0YXJ0X2luaXQ6IHRy eWluZyAvc2Jpbi9pbml0CkxvYWRpbmcgY29uZmlndXJhdGlvbiBmaWxlcy4Ka2VudjogCnVuYWJs ZSB0byBnZXQgZHVtcGRldgoKa2VybmVsIGR1bXBzIG9uIC9kZXYvYWQwczJiCkVudHJvcHkgaGFy dmVzdGluZzoKIGludGVycnVwdHMKIGV0aGVybmV0CiBwb2ludF90b19wb2ludAoga2lja3N0YXJ0 Ci4Kc3dhcG9uOiBhZGRpbmcgL2Rldi9hZDBzMmIgYXMgc3dhcCBkZXZpY2UKU3RhcnRpbmcgZmls ZSBzeXN0ZW0gY2hlY2tzOgovZGV2L2FkMHMzYTogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5H IENIRUNLUwovZGV2L2FkMHMzYTogY2xlYW4sIDkzNTgxIGZyZWUgKDgyOSBmcmFncywgMTE1OTQg YmxvY2tzLCAwLjclIGZyYWdtZW50YXRpb24pCi9kZXYvYWQwczNlOiBGSUxFIFNZU1RFTSBDTEVB TjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQwczNlOiBjbGVhbiwgMTIyMzYyIGZyZWUgKDQyIGZy YWdzLCAxNTI5MCBibG9ja3MsIDAuMCUgZnJhZ21lbnRhdGlvbikKL2Rldi9hZDBzM2Y6IEZJTEUg U1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZDBzM2Y6IGNsZWFuLCA2NDIyNTU5 IGZyZWUgKDY0MjE1IGZyYWdzLCA3OTQ3OTMgYmxvY2tzLCAwLjglIGZyYWdtZW50YXRpb24pCi9k ZXYvYWQwczNkOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQwczNk OiBjbGVhbiwgOTMyNDEgZnJlZSAoMjA5IGZyYWdzLCAxMTYyOSBibG9ja3MsIDAuMiUgZnJhZ21l bnRhdGlvbikKU2V0dGluZyBob3N0bmFtZTogcHJvbGVwc2lzLm1hdGgudWl1Yy5lZHUuCkRIQ1BS RVFVRVNUIG9uIGJmZTAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcKCkRIQ1BBQ0sgZnJvbSAx MzAuMTI2LjExMC4xMAoKYm91bmQgdG8gMTMwLjEyNi4xMTEuMjQgLS0gcmVuZXdhbCBpbiAxODAw IHNlY29uZHMuCgpiZmUwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgs TVVMVElDQVNUPiBtdHUgMTUwMAoJb3B0aW9ucz04PFZMQU5fTVRVPgoJaW5ldDYgZmU4MDo6MjBi OmRiZmY6ZmU5OTplOGM3JWJmZTAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHgxIAoJaW5ldCAxMzAu MTI2LjExMS4yNCBuZXRtYXNrIDB4ZmZmZmZjMDAgCglldGhlciAwMDowYjpkYjo5OTplODpjNwoJ bWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMGJhc2VUWCA8ZnVsbC1kdXBsZXg+KQoJc3Rh dHVzOiBhY3RpdmUKbG8wOiBmbGFncz04MDQ5PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNU PiBtdHUgMTYzODQKCWluZXQgMTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKCWluZXQ2IDo6 MSBwcmVmaXhsZW4gMTI4IAoJaW5ldDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQg MHgyIApBZGRpdGlvbmFsIHJvdXRpbmcgb3B0aW9uczoKLgpTdGFydGluZyBkZXZkLgpTdGFydGlu ZyB1bXMwIG1vdXNlZDoKLgpody5hY3BpLmNwdS5jeF9sb3dlc3Q6IApDMQogLT4gCkMxCgpkaGNs aWVudCBiZmUwOiBhbHJlYWR5IHJ1bm5pbmc/CmRoY2xpZW50IGJmZTA6IGFscmVhZHkgcnVubmlu Zz8KTW91bnRpbmcgTkZTIGZpbGUgc3lzdGVtczoKLgpDcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcg bG9nIGZpbGVzOgouClN0YXJ0aW5nIHN5c2xvZ2QuCkNoZWNraW5nIGZvciBjb3JlIGR1bXAgb24g L2Rldi9hZDBzMmIuLi4Kc2F2ZWNvcmU6IHVuYWJsZSB0byBvcGVuIGJvdW5kcyBmaWxlLCB1c2lu ZyAwCnNhdmVjb3JlOiBubyBkdW1wcyBmb3VuZApFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNy L2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9YMTFSNi9saWIgL3Vzci9sb2NhbC9saWIgL3Vzci9s b2NhbC9saWIvY29tcGF0L3BrZwphLm91dCBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYi9hb3V0IC91 c3IvbGliL2NvbXBhdC9hb3V0IC91c3IvWDExUjYvbGliL2FvdXQKU3RhcnRpbmcgdXNiZC4KU3Rh cnRpbmcgbG9jYWwgZGFlbW9uczoKLgpVcGRhdGluZyBtb3RkCi4KQ29uZmlndXJpbmcgc3lzY29u czoKIGJsYW5rdGltZQogc2NyZWVuc2F2ZXIKc3BsYXNoOiBpbWFnZSBkZWNvZGVyIGZvdW5kOiBi bGFua19zYXZlcgouClN0YXJ0aW5nIHNzaGQuCkluaXRpYWwgaTM4NiBpbml0aWFsaXphdGlvbjoK LgpBZGRpdGlvbmFsIEFCSSBzdXBwb3J0OgogbGludXgKLgpTdGFydGluZyBjcm9uLgpMb2NhbCBw YWNrYWdlIGluaXRpYWxpemF0aW9uOgouCkFkZGl0aW9uYWwgVENQIG9wdGlvbnM6Ci4KU3RhcnRp bmcgZGVmYXVsdCBtb3VzZWQ6Ci4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVj a3MgaW4gNjAgc2Vjb25kcy4KClNhdCBKdWwgMjMgMDA6MzI6NTMgVVRDIDIwMDUKSnVsIDIzIDAw OjMyOjU5IHByb2xlcHNpcyBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04gdHR5djAK ------=_Part_599_26350432.1122080047536-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 01:09: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 45F4F16A41F for ; Sat, 23 Jul 2005 01:09:38 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A72E43D48 for ; Sat, 23 Jul 2005 01:09:37 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so571643wri for ; Fri, 22 Jul 2005 18:09: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=bAVZbNLx3MryCsup0M2REUtPaKBAe8Dc4zD5BTczJZgzIY0CA7tm6BBwNMa+jHbsWXJwPNYigELPCda1IDGm2zWsg2AHQH2UMQJDdfj4Jnk16UTU598C7KPvh9lXYNYSJv+fchacW7p0K210plynSlvBuZMdj1LaP+62y2iKY3s= Received: by 10.54.4.65 with SMTP id 65mr1482878wrd; Fri, 22 Jul 2005 18:09:36 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Fri, 22 Jul 2005 18:09:36 -0700 (PDT) Message-ID: <47d0403c05072218091264a990@mail.gmail.com> Date: Sat, 23 Jul 2005 01:09:36 +0000 From: Ben Kaduk To: Jung-uk Kim In-Reply-To: <200507220549.j6M5nfhO059858@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507220549.j6M5nfhO059858@repoman.freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/ndiscvt ndisgen.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 01:09:38 -0000 On 7/22/05, Jung-uk Kim wrote: > jkim 2005-07-22 05:49:41 UTC >=20 > FreeBSD src repository >=20 > Modified files: > usr.sbin/ndiscvt ndisgen.sh > Log: > Fix ndisgen(8) for amd64 >=20 > - file(1) does not recognize UTF-16 encoded .INF file: >=20 > netbc564.inf: MPEG ADTS, layer I, v1, 96 kBits, 32 kHz, Stereo >=20 > Use egrep(1) to match two strings, i. e., `Signature' and `Class=3DNet'= . >=20 > - Fix linking failure. Generate a temporary Makefile to emluate > official kernel module build process. >=20 > - Some minor typo/style fixes. >=20 > Reviewed by: obrien >=20 > Revision Changes Path > 1.2 +116 -72 src/usr.sbin/ndiscvt/ndisgen.sh > _______________________________________________ > cvs-src@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-src > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" >=20 I think this commit broke ndisgen for my broadcom bcm4324 chipset (dell truemobile 1400 mini-pci), since the only other commit since my last working version (6.0-Release Beta 1) claimed to be grammatical fixes. ndisgen fails to recognize my .inf file, which the old version recognized: ---------begin ndisgen output ---------- A .INF file is most often provided as an ASCII file, however files with multilanguage support are provided in Unicode format. Please type in the path to your .INF file now. > /usr/src/sys/modules/if_ndis/bcmwl5a.inf I don't recognize this file format. It may not be a valid .INF file= . --------- end ndisgen output -------- the driver files that worked are here: https://netfiles.uiuc.edu/kaduk/www/bcmwl5a.inf https://netfiles.uiuc.edu/kaduk/www/bcmwl5.sys I tried removing the ^M's from the ends of lines, but this made no difference. Any thoughts to explain this behaviour? Thanks Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 01: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 285C216A41F for ; Sat, 23 Jul 2005 01:49:36 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F9743D46 for ; Sat, 23 Jul 2005 01:49:35 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so556813wri for ; Fri, 22 Jul 2005 18:49: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aXNbvDL+iNWegHE61KmxoKwp3Zy/rrFGsCueeERK4OK4zinsgIgkeJuGk3178pomXJzc+RAzi3IwIa5/TVFU6l5eS3m8VaRNXaisP4Sh7hyZsvnA85FJi6dFRJgThMfwWQWG3IZF1yomgwgObSN3ZJ3LTvgDsgNlB+baM1yPqSM= Received: by 10.54.49.52 with SMTP id w52mr1510214wrw; Fri, 22 Jul 2005 18:49:34 -0700 (PDT) Received: by 10.54.44.33 with HTTP; Fri, 22 Jul 2005 18:49:34 -0700 (PDT) Message-ID: <47d0403c05072218491c78e2e9@mail.gmail.com> Date: Sat, 23 Jul 2005 01:49:34 +0000 From: Ben Kaduk To: Jung-uk Kim In-Reply-To: <47d0403c05072218091264a990@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507220549.j6M5nfhO059858@repoman.freebsd.org> <47d0403c05072218091264a990@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/usr.sbin/ndiscvt ndisgen.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 01:49:39 -0000 On 7/23/05, Ben Kaduk wrote: > On 7/22/05, Jung-uk Kim wrote: > > jkim 2005-07-22 05:49:41 UTC > > > > FreeBSD src repository > > > > Modified files: > > usr.sbin/ndiscvt ndisgen.sh > > Log: > > Fix ndisgen(8) for amd64 > > > > - file(1) does not recognize UTF-16 encoded .INF file: > > > > netbc564.inf: MPEG ADTS, layer I, v1, 96 kBits, 32 kHz, Ster= eo > > > > Use egrep(1) to match two strings, i. e., `Signature' and `Class=3DNe= t'. > > > > - Fix linking failure. Generate a temporary Makefile to emluate > > official kernel module build process. > > > > - Some minor typo/style fixes. > > > > Reviewed by: obrien > > > > Revision Changes Path > > 1.2 +116 -72 src/usr.sbin/ndiscvt/ndisgen.sh > > _______________________________________________ > > cvs-src@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/cvs-src > > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > > >=20 > I think this commit broke ndisgen for my broadcom bcm4324 chipset > (dell truemobile 1400 mini-pci), since the only other commit since my > last > working version (6.0-Release Beta 1) claimed to be grammatical fixes. > ndisgen fails to recognize my .inf file, which the old version recognized= : >=20 > ---------begin ndisgen output ---------- >=20 > A .INF file is most often provided as an ASCII file, however > files with multilanguage support are provided in Unicode format. > Please type in the path to your .INF file now. >=20 > > /usr/src/sys/modules/if_ndis/bcmwl5a.inf >=20 > I don't recognize this file format. It may not be a valid .INF fi= le. >=20 > --------- end ndisgen output -------- > the driver files that worked are here: > https://netfiles.uiuc.edu/kaduk/www/bcmwl5a.inf > https://netfiles.uiuc.edu/kaduk/www/bcmwl5.sys >=20 > I tried removing the ^M's from the ends of lines, but this made no > difference. Any thoughts to explain this behaviour? >=20 > Thanks >=20 > Ben Kaduk >=20 I know it's bad form to reply to myself, but this patch seems to allow ndisgen to recognize my .inf file: prolepsis# diff -u /usr/sbin/ndisgen /root/ndisgen.old --- /usr/sbin/ndisgen Sat Jul 23 01:47:31 2005 +++ /root/ndisgen.old Sat Jul 23 01:39:50 2005 @@ -196,7 +196,7 @@ echo -n " > " read INFPATH if [ ${INFPATH} ] && [ -e ${INFPATH} ]; then - INFTYPE=3D`${EGREP} -i -c "Signature|^.S.i.g.n.a.t.u.r.e" ${INFPATH= }` + INFTYPE=3D`${EGREP} -i -c "^Signature|^.S.i.g.n.a.t.u.r.e" ${INFPAT= H}` if [ ${INFTYPE} -le 0 ]; then echo "" echo " I don't recognize this file format. It may not be a valid .INF file." @@ -207,7 +207,7 @@ return fi - INFTYPE=3D`${EGREP} -i -c "Class.*=3D.*Net" ${INFPATH}` + INFTYPE=3D`${EGREP} -i -c "^Class.*=3D.*Net" ${INFPATH}` if [ ${INFTYPE} -gt 0 ]; then echo "" echo " This .INF file appears to be ASCII." Apparently egrep isn't recognizing "^" as the beginning of a line. Hope this helps, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:07: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 BD48716A41F for ; Sat, 23 Jul 2005 03:07:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78B7343D45 for ; Sat, 23 Jul 2005 03:07:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 1AD504CE7B7 for ; Fri, 22 Jul 2005 20:07:00 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95378-10 for ; Fri, 22 Jul 2005 20:06:59 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id A84504CE7B5 for ; Fri, 22 Jul 2005 20:06:59 -0700 (PDT) Message-ID: <42E1B453.9080704@elischer.org> Date: Fri, 22 Jul 2005 20:06:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Subject: whither went libcipher? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:07:01 -0000 I have to port some code from 4.x to 6.x that used libcypher. the setkey(3) function and friends have disappeared (not just moved to another library) and their man pages have gone with them. The CVS logs of the removal suggest that there is simlar functionality elsewhere now but don't actually say what it is... how do I replace setkey(3)? From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:09: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 694FD16A41F for ; Sat, 23 Jul 2005 03:09:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 215E443D46 for ; Sat, 23 Jul 2005 03:09:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id DFB564CE7B7; Fri, 22 Jul 2005 20:09:11 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95483-01; Fri, 22 Jul 2005 20:09:11 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 59F774CE7B5; Fri, 22 Jul 2005 20:09:11 -0700 (PDT) Message-ID: <42E1B4D6.6030607@elischer.org> Date: Fri, 22 Jul 2005 20:09:10 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <42E1B453.9080704@elischer.org> In-Reply-To: <42E1B453.9080704@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: FreeBSD Current Subject: Re: whither went libcipher? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:09:12 -0000 Julian Elischer wrote: > I have to port some code from 4.x to 6.x that used libcypher. that would of course be libcipher. > > the setkey(3) function and friends have disappeared (not just moved > to another library) and their man pages have gone with them. > > The CVS logs of the removal suggest that there is simlar functionality > elsewhere now but don't actually say what it is... > > how do I replace setkey(3)? > > _______________________________________________ > 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 Jul 23 03:30: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 EC29816A41F for ; Sat, 23 Jul 2005 03:30:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAB43D48 for ; Sat, 23 Jul 2005 03:30:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 4F3C44CE9B5 for ; Wed, 20 Jul 2005 20:09:20 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89296-04 for ; Wed, 20 Jul 2005 20:09:19 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id E95E44CE91B for ; Wed, 20 Jul 2005 20:09:19 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id DA7207A403 for ; Wed, 20 Jul 2005 20:09:19 -0700 (PDT) Message-ID: <42DF11DF.4070405@elischer.org> Date: Wed, 20 Jul 2005 20:09:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: Subject: whither libcipher? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:30:05 -0000 since setkey(3) has now gone away so thoroughly that there is not even a man page sying how to replace it, I need to port some code that uses it.. What is the suggested replacement? of course it is still on linux.. apparently in libcrypt. but that doesn't help me keep this code on BSD.. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:30: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 CC55616A420; Sat, 23 Jul 2005 03:30:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE41F43D45; Sat, 23 Jul 2005 03:30:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id B40424CE923; Thu, 21 Jul 2005 17:04:34 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39496-10; Thu, 21 Jul 2005 17:04:34 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 51D924CE95E; Thu, 21 Jul 2005 17:04:34 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 43A347A41E; Thu, 21 Jul 2005 17:04:34 -0700 (PDT) Message-ID: <42E03812.4090801@elischer.org> Date: Thu, 21 Jul 2005 17:04:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org, Mark Murray Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: Subject: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:30:06 -0000 I have snet this mail 3 times and each time it never appeared on the list (that I saw.. I think it got eaten by a spam filtrer somewhere..) trying again. Since setkey(3) has now gone away so thoroughly that there is not even a manual page saying how to replace it, I need to port some code that uses it.. What is the suggested replacement? Of course it is still on linux.. apparently in libcrypt. but that doesn't help me keep this code on BSD.. julian From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:30:07 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 61CBA16A41F for ; Sat, 23 Jul 2005 03:30:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A2C043D58 for ; Sat, 23 Jul 2005 03:30:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 144DC4CEA34 for ; Wed, 20 Jul 2005 18:02:29 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85691-04 for ; Wed, 20 Jul 2005 18:02:28 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id A883F4CEA2A for ; Wed, 20 Jul 2005 18:02:28 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 9BACC7A403 for ; Wed, 20 Jul 2005 18:02:28 -0700 (PDT) Message-ID: <42DEF424.4070607@elischer.org> Date: Wed, 20 Jul 2005 18:02:28 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: Subject: whither libcipher? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:30:07 -0000 since setkey(3) has now gone away so thoroughly that there is not even a man page sying how to replace it, I need to port some code that uses it.. What is the suggested replacement? of course it is still on linux.. apparently in libcrypt. but that doesn't help me keep this code on BSD.. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:30: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 9432616A41F; Sat, 23 Jul 2005 03:30:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AC3A43D4C; Sat, 23 Jul 2005 03:30:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id D55A94CE82E; Thu, 21 Jul 2005 22:39:37 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48769-03; Thu, 21 Jul 2005 22:39:37 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 80F524CE7FC; Thu, 21 Jul 2005 22:39:37 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 6F6E47A403; Thu, 21 Jul 2005 22:39:37 -0700 (PDT) Message-ID: <42E08699.1040302@elischer.org> Date: Thu, 21 Jul 2005 22:39:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current , Mark Murray Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: Subject: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:30:08 -0000 I've tried 4 times to send this mail to -current but I have still not seen it come though. if everyone else has, someone please let me know! what do we replace setkey(3) from libcipher with? julian From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:30:07 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 89D5616A420 for ; Sat, 23 Jul 2005 03:30:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAA7C43D49 for ; Sat, 23 Jul 2005 03:30:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 674F14CE93F for ; Thu, 21 Jul 2005 16:10:35 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36998-09 for ; Thu, 21 Jul 2005 16:10:35 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 0D9EE4CE93E for ; Thu, 21 Jul 2005 16:10:35 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 00CA37A423 for ; Thu, 21 Jul 2005 16:10:35 -0700 (PDT) Message-ID: <42E02B6A.9060500@elischer.org> Date: Thu, 21 Jul 2005 16:10:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: Subject: whither libcipher? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:30:08 -0000 since setkey(3) has now gone away so thoroughly that there is not even a man page sying how to replace it, I need to port some code that uses it.. What is the suggested replacement? of course it is still on linux.. apparently in libcrypt. but that doesn't help me keep this code on BSD.. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:33:09 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 C231516A41F; Sat, 23 Jul 2005 03:33:09 +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 AE7A443D7F; Sat, 23 Jul 2005 03:32:58 +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 j6N3Wph1045583; Fri, 22 Jul 2005 20:32: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 j6N3WplB045582; Fri, 22 Jul 2005 20:32:51 -0700 (PDT) (envelope-from sgk) Date: Fri, 22 Jul 2005 20:32:51 -0700 From: Steve Kargl To: Julian Elischer Message-ID: <20050723033251.GB45516@troutmask.apl.washington.edu> References: <42E03812.4090801@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E03812.4090801@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:33:09 -0000 On Thu, Jul 21, 2005 at 05:04:34PM -0700, Julian Elischer wrote: > I have snet this mail 3 times and each time it never appeared on the list > (that I saw.. I think it got eaten by a spam filtrer somewhere..) > > trying again. > > Since setkey(3) has now gone away so thoroughly that there is not even > a manual page saying how to replace it, > I need to port some code that uses it.. > > What is the suggested replacement? > > Of course it is still on linux.. apparently in libcrypt. > but that doesn't help me keep this code on BSD.. > I've seen each of your previous post. Perhaps, you need to adjust your local mail filtering. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:34: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 1264116A41F for ; Sat, 23 Jul 2005 03:34:48 +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 B8AEA43D48 for ; Sat, 23 Jul 2005 03:34:47 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from tirun (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 0DE247A for ; Fri, 22 Jul 2005 23:34:46 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: freebsd-current@freebsd.org In-Reply-To: <20050723033251.GB45516@troutmask.apl.washington.edu> References: <42E03812.4090801@elischer.org> <20050723033251.GB45516@troutmask.apl.washington.edu> Content-Type: text/plain Date: Fri, 22 Jul 2005 23:34:44 -0400 Message-Id: <1122089684.12033.0.camel@tirun> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:34:48 -0000 On Fri, 2005-07-22 at 20:32 -0700, Steve Kargl wrote: > On Thu, Jul 21, 2005 at 05:04:34PM -0700, Julian Elischer wrote: > > I have snet this mail 3 times and each time it never appeared on the list > > (that I saw.. I think it got eaten by a spam filtrer somewhere..) > > > > trying again. > > > > Since setkey(3) has now gone away so thoroughly that there is not even > > a manual page saying how to replace it, > > I need to port some code that uses it.. > > > > What is the suggested replacement? > > > > Of course it is still on linux.. apparently in libcrypt. > > but that doesn't help me keep this code on BSD.. > > > > I've seen each of your previous post. Perhaps, you need > to adjust your local mail filtering. Likewise. As to answers, I strongly suspect the openssl in base is the approved replacement. -- 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 Sat Jul 23 03:46: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 3250316A41F; Sat, 23 Jul 2005 03:46:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE0D543D45; Sat, 23 Jul 2005 03:46:56 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id AE6094CE7B7; Fri, 22 Jul 2005 20:46:56 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96194-07; Fri, 22 Jul 2005 20:46:56 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 354BC4CE7B5; Fri, 22 Jul 2005 20:46:56 -0700 (PDT) Message-ID: <42E1BDAF.7040704@elischer.org> Date: Fri, 22 Jul 2005 20:46:55 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Steve Kargl References: <42E03812.4090801@elischer.org> <20050723033251.GB45516@troutmask.apl.washington.edu> In-Reply-To: <20050723033251.GB45516@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: current@freebsd.org Subject: Re: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:46:57 -0000 if you just saw this 4 times now then it's because the logjam was just released. sorry for the duplicates.. Our mail system was screwed up by the fact that our ISP screwed up our reverse DNS and we didn't notice for a day and a half. now it's fixed its all flowing out.. Steve Kargl wrote: >On Thu, Jul 21, 2005 at 05:04:34PM -0700, Julian Elischer wrote: > > >>I have snet this mail 3 times and each time it never appeared on the list >>(that I saw.. I think it got eaten by a spam filtrer somewhere..) >> >>trying again. >> >>Since setkey(3) has now gone away so thoroughly that there is not even >>a manual page saying how to replace it, >>I need to port some code that uses it.. >> >>What is the suggested replacement? >> >>Of course it is still on linux.. apparently in libcrypt. >>but that doesn't help me keep this code on BSD.. >> >> >> > >I've seen each of your previous post. Perhaps, you need >to adjust your local mail filtering. > > > From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 03:52: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 2B8EE16A41F for ; Sat, 23 Jul 2005 03:52:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4FE443D4C for ; Sat, 23 Jul 2005 03:52:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 99B4D4CE7B7; Fri, 22 Jul 2005 20:52:14 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96444-06; Fri, 22 Jul 2005 20:52:14 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 0D5464CE7B5; Fri, 22 Jul 2005 20:52:14 -0700 (PDT) Message-ID: <42E1BEED.90003@elischer.org> Date: Fri, 22 Jul 2005 20:52:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Brandon S. Allbery KF8NH" References: <42E03812.4090801@elischer.org> <20050723033251.GB45516@troutmask.apl.washington.edu> <1122089684.12033.0.camel@tirun> In-Reply-To: <1122089684.12033.0.camel@tirun> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd-current@freebsd.org Subject: Re: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 03:52:15 -0000 Brandon S. Allbery KF8NH wrote: >On Fri, 2005-07-22 at 20:32 -0700, Steve Kargl wrote: > > >>On Thu, Jul 21, 2005 at 05:04:34PM -0700, Julian Elischer wrote: >> >> >>>I have snet this mail 3 times and each time it never appeared on the list >>>(that I saw.. I think it got eaten by a spam filtrer somewhere..) >>> >>>trying again. >>> >>>Since setkey(3) has now gone away so thoroughly that there is not even >>>a manual page saying how to replace it, >>>I need to port some code that uses it.. >>> >>>What is the suggested replacement? >>> >>>Of course it is still on linux.. apparently in libcrypt. >>>but that doesn't help me keep this code on BSD.. >>> >>> >>> >>I've seen each of your previous post. Perhaps, you need >>to adjust your local mail filtering. >> >> yeah sorry about this.. may mail was apparently going into a black hole so I resent. then it all suddenly came out to haunt me.. > >Likewise. > >As to answers, I strongly suspect the openssl in base is the approved >replacement. > > so does openssl have setkey(3)? When the setkey() man page was removed it would have been nice to replace it with one explaining how to replace it with whatever is in ssl that does the same thing. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 04:20: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 6FCCC16A41F; Sat, 23 Jul 2005 04:20:01 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D753D43D45; Sat, 23 Jul 2005 04:20:00 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j6N4JvFK084226; Fri, 22 Jul 2005 23:19:57 -0500 (CDT) (envelope-from dan) Date: Fri, 22 Jul 2005 23:19:57 -0500 From: Dan Nelson To: Julian Elischer Message-ID: <20050723041957.GD27856@dan.emsphone.com> References: <42E03812.4090801@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E03812.4090801@elischer.org> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: libcipher replacement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 04:20:01 -0000 In the last episode (Jul 21), Julian Elischer said: > I have snet this mail 3 times and each time it never appeared on the list > (that I saw.. I think it got eaten by a spam filtrer somewhere..) > > trying again. > > Since setkey(3) has now gone away so thoroughly that there is not even > a manual page saying how to replace it, > I need to port some code that uses it.. > > What is the suggested replacement? Try DES_set_key() ; the des(2) manpage also lists all the other DES_* openssl functions. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 04: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 0525116A41F for ; Sat, 23 Jul 2005 04:51:54 +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 2127343D45 for ; Sat, 23 Jul 2005 04:51:50 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp221-241.lns3.adl2.internode.on.net [203.122.221.241]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6N4pbF5091701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 23 Jul 2005 14:21:43 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 23 Jul 2005 14:21:27 +0930 User-Agent: KMail/1.8.1 References: <1121952594.68685.27.camel@opus.cse.buffalo.edu> <20050722174802.GS39292@obiwan.tataz.chchile.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1462241.DMoyO6ND7Y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507231421.28210.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Richard Todd Subject: Re: HEADS-UP: New shared library versions coming soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 04:51:54 -0000 --nextPart1462241.DMoyO6ND7Y Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 23 July 2005 05:27, Richard Todd wrote: > libchk (/usr/ports/sysutils/libchk) is a nice Python script that automates > the "ldd on each binary" bit and gives you a list of .sos that aren't bei= ng > used by anything. You do have to eyeball the list before doing a mass > purge of any unreferenced .sos, as there are some apps (Mozilla/Firefox is > one IIRC) which have .so files which are loaded by the program as needed > but which don't show up as fixed dependencies via ldd. Still, the libchk > list ought to at least give you a starting point. You could probably extend it to use /var/db/pkg/*/+CONTENTS to exclude stuf= f=20 like that (ie things explicitly referenced by a port). No, I don't have a patch to make it do this :) =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 --nextPart1462241.DMoyO6ND7Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4czQ5ZPcIHs/zowRAnYVAJ98j6V1mu0R/ziyK1DCdejpbm8NvACdGxwr +Glwx84aPwrFi2q6D3yrvgM= =xt0L -----END PGP SIGNATURE----- --nextPart1462241.DMoyO6ND7Y-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 06:12: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 C776C16A41F for ; Sat, 23 Jul 2005 06:12:34 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id D58D743D49 for ; Sat, 23 Jul 2005 06:12:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 57077 invoked by uid 399); 23 Jul 2005 06:12:32 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 06:12:32 -0000 Received: (qmail 38865 invoked by uid 399); 23 Jul 2005 06:12:32 -0000 Received: from unknown (HELO ?192.168.15.101?) (dougb@dougbarton.net@67.20.70.103) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 06:12:32 -0000 Message-ID: <42E1DFCE.6090506@FreeBSD.org> Date: Fri, 22 Jul 2005 23:12:30 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg 'groggy' Lehey References: <200507230146.j6N1koqL061690@repoman.freebsd.org> <20050723015517.GA28428@nagual.pp.ru> <20050723020120.GV842@wantadilla.lemis.com> In-Reply-To: <20050723020120.GV842@wantadilla.lemis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 06:12:34 -0000 Changing venue to -current, since these kinds of protracted discussions don't belong on the commit mailing lists. Greg 'groggy' Lehey wrote: > But for whatever reasons, many systems seem to have incorrect > random(4) initialization. I don't think it has anything to do with /dev/random initialization, I think that there is an error somewhere in the fortune code that is causing this problem. I have seen the same problem Greg has for a long time now, but for me it's the fortune with the CVS $FreeBSD$ tag that comes up about 8 times out of 10. This is still true even on a system that has been up and running for hours, and has kern.random.sys.seeded: 1 I can't tell if it's a problem with how the files are randomized in the first place, or how they get played back, but I haven't looked at this very hard yet. > You'll recall the debate about removing Rush Limbaugh fortunes recently I didn't see this debate as I've had e-mail "issues" for the last couple of days, what list was it on? In any case, I would not be at all happy if these fortunes were removed. I agreed to add them to the "offensive" fortune database because the rule there is that you don't add -o or -a to your command line unless you are willing to run the risk of being offended. If every committer gets to go through the fortune database and remove every fortune that they find offensive, it's going to be a mighty small file. The obvious alternative is to make their removal a local hack if you feel that strongly about it. > This is the only place > where it seems to make any difference, so it's easier to use a > different seed. Since my thesis is that this is not a /dev/random initialization problem, I tend to agree with you. Just to be on the safe side, I have bumped up both the size and number of my /var/db/entropy files, and I'll gladly be proven wrong on this one. However, I sincerely doubt that this is actually a problem with /dev/random. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 06:44:52 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CEFF16A41F; Sat, 23 Jul 2005 06:44:52 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38C3743D45; Sat, 23 Jul 2005 06:44:51 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 94ACC86DDA; Sat, 23 Jul 2005 16:14:49 +0930 (CST) Date: Sat, 23 Jul 2005 16:14:49 +0930 From: Greg 'groggy' Lehey To: Doug Barton Message-ID: <20050723064449.GZ842@wantadilla.lemis.com> References: <200507230146.j6N1koqL061690@repoman.freebsd.org> <20050723015517.GA28428@nagual.pp.ru> <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XilfshMFnlxBucLf" Content-Disposition: inline In-Reply-To: <42E1DFCE.6090506@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current@FreeBSD.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 06:44:52 -0000 --XilfshMFnlxBucLf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Friday, 22 July 2005 at 23:12:30 -0700, Doug Barton wrote: > Changing venue to -current, since these kinds of protracted discussions > don't belong on the commit mailing lists. > > Greg 'groggy' Lehey wrote: > >> But for whatever reasons, many systems seem to have incorrect >> random(4) initialization. > > I don't think it has anything to do with /dev/random initialization, I > think that there is an error somewhere in the fortune code that is causing > this problem. You should take a look at what I committed. It simply uses the microsecond value returned by getlocaltime() for the automatic seeding by srandomdev(). It fixes the problem. I can see only two explanations: 1. srandomdev(), random(4) or friends are broken. 2. random(4) has been initialized incorrectly. Currently I'm guessing (2), but I don't care much either way. > I have seen the same problem Greg has for a long time now, > but for me it's the fortune with the CVS $FreeBSD$ tag that comes up about > 8 times out of 10. This is still true even on a system that has been up a= nd > running for hours, and has kern.random.sys.seeded: 1 > > I can't tell if it's a problem with how the files are randomized in the > first place, or how they get played back, but I haven't looked at this ve= ry > hard yet. The obvious thing is to try this patch and see what happens. >> You'll recall the debate about removing Rush Limbaugh fortunes recently > > I didn't see this debate as I've had e-mail "issues" for the last couple = of > days, what list was it on?=20 This was early 2004, it seems. I've told you the details on IRC (and I've dropped the buffer from Emacs, so I've forgotten the details; sorry to the rest of you, but ISTR it was a message from Stephen Mckay to -chat on 4 January 2004). > In any case, I would not be at all happy if these fortunes were > removed. I agreed to add them to the "offensive" fortune database > because the rule there is that you don't add -o or -a to your > command line unless you are willing to run the risk of being > offended. If every committer gets to go through the fortune > database and remove every fortune that they find offensive, it's > going to be a mighty small file. There was no discussion of that. If you go back to the thread I mentioned, you'll see that, though I don't like them, I found it inappropriate to remove them. >> This is the only place where it seems to make any difference, so >> it's easier to use a different seed. > > Since my thesis is that this is not a /dev/random initialization > problem, I tend to agree with you. Just to be on the safe side, I > have bumped up both the size and number of my /var/db/entropy files, > and I'll gladly be proven wrong on this one. However, I sincerely > doubt that this is actually a problem with /dev/random. It's certainly worth following up on. From the PoV of fortune, it's really not worth worrying about the most perfect random number generator; I suspect that the microsecond seed will satisfy everybody except possibly the purists. That doesn't mean that we should forget the potential issues with random(4). Greg -- The virus once contained in this message has lost interest in life, shrivelled up and died. LEMIS anti-virus has given it an appropriate burial. For further details see http://www.lemis.com/grog/lemis-virus.html Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --XilfshMFnlxBucLf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4edhIubykFB6QiMRAiNZAJ90Ax8+5/E9JIHp/Gz+6nYorsC5rgCdHlm6 9hh+LYGgoKypKGgjeiLlLpw= =0gXs -----END PGP SIGNATURE----- --XilfshMFnlxBucLf-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 06:59:49 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 CDC8D16A41F for ; Sat, 23 Jul 2005 06:59:49 +0000 (GMT) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D4D743D46 for ; Sat, 23 Jul 2005 06:59:49 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 90253 invoked from network); 23 Jul 2005 06:59:48 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 23 Jul 2005 06:59:48 -0000 X-pair-Authenticated: 80.161.118.233 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j6N6xlew046775 for ; Sat, 23 Jul 2005 08:59:47 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j6N6xlVn046774 for current@freebsd.org; Sat, 23 Jul 2005 08:59:47 +0200 (CEST) (envelope-from pho) Date: Sat, 23 Jul 2005 08:59:47 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20050723065947.GA46744@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Livelocks in GENERIC 6.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 06:59:49 -0000 I've seen more than three similar livelocks, where the "looping" process seems to have a very high priority (-8). I can't really tell if this is the cause of the livelock, or just a side effect. http://people.freebsd.org/~pho/stress/log/cons146.html PS I've added a RSS feed to http://people.freebsd.org/~pho/stress/log/ -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 08:16: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 7B3DF16A41F; Sat, 23 Jul 2005 08:16:34 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B2543D49; Sat, 23 Jul 2005 08:16:33 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6N8GW7D033720; Sat, 23 Jul 2005 12:16:32 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6N8GWI6033719; Sat, 23 Jul 2005 12:16:32 +0400 (MSD) (envelope-from ache) Date: Sat, 23 Jul 2005 12:16:32 +0400 From: Andrey Chernov To: "Greg 'groggy' Lehey" Message-ID: <20050723081631.GA33648@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Greg 'groggy' Lehey , Doug Barton , freebsd-current@FreeBSD.ORG References: <200507230146.j6N1koqL061690@repoman.freebsd.org> <20050723015517.GA28428@nagual.pp.ru> <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <20050723064449.GZ842@wantadilla.lemis.com> User-Agent: Mutt/1.5.9i Cc: Doug Barton , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 08:16:34 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 23, 2005 at 04:14:49PM +0930, Greg 'groggy' Lehey wrote: > On Friday, 22 July 2005 at 23:12:30 -0700, Doug Barton wrote: > > Changing venue to -current, since these kinds of protracted discussions > > don't belong on the commit mailing lists. > > > > Greg 'groggy' Lehey wrote: > > > >> But for whatever reasons, many systems seem to have incorrect > >> random(4) initialization. > > > > I don't think it has anything to do with /dev/random initialization, I > > think that there is an error somewhere in the fortune code that is caus= ing > > this problem. >=20 > You should take a look at what I committed. It simply uses the > microsecond value returned by getlocaltime() for the automatic seeding > by srandomdev(). It fixes the problem. I can see only two > explanations: Well, I am not advocate /dev/random initialization bug in preference of=20 fortune bug. But your "fix" not fix _anything_ in _either_ case, for=20 fortune bug or for /dev/random bug. Better back it out and seek true bug.= =20 For fortune bug you can turn on DPRINTF at least and see what really=20 happens. Since I can't reproduce it, I can't help, only people who can=20 reproduce. --=20 http://ache.pp.ru/ --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQuH83+JgpPLZnQjrAQLDegQAiF/q7LWByUNOUg+penS2WJz5s+u6feuT FrKP8xf/1YOJwmwf0z3wkMxIHA6diVHEEUPkDQhHTryA+IquI8xbPDexmPyl/PfV Gxg9ajdGdVqadljmDx90mPEa+LP6E3fzOsWNSIHjZDMbc6+3KuWiHCBrAnfF6dor mvFdfpSyokg= =Vc2W -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 08:18: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 BA41B16A420; Sat, 23 Jul 2005 08:18:26 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAA5C43D49; Sat, 23 Jul 2005 08:18:25 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6N8IOZt033771; Sat, 23 Jul 2005 12:18:24 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6N8IOcg033770; Sat, 23 Jul 2005 12:18:24 +0400 (MSD) (envelope-from ache) Date: Sat, 23 Jul 2005 12:18:24 +0400 From: Andrey Chernov To: "Greg 'groggy' Lehey" , Doug Barton , freebsd-current@FreeBSD.ORG Message-ID: <20050723081824.GA33739@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Greg 'groggy' Lehey , Doug Barton , freebsd-current@FreeBSD.ORG References: <200507230146.j6N1koqL061690@repoman.freebsd.org> <20050723015517.GA28428@nagual.pp.ru> <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.com> <20050723081631.GA33648@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20050723081631.GA33648@nagual.pp.ru> User-Agent: Mutt/1.5.9i Cc: Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 08:18:26 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 23, 2005 at 12:16:32PM +0400, Andrey Chernov wrote: > For fortune bug you can turn on DPRINTF at least and see what really=20 > happens. Since I can't reproduce it, I can't help, only people who can=20 > reproduce. BTW, it can help to detect /dev/random initialization bug too, if you see= =20 repeated values in DPRINTF. --=20 http://ache.pp.ru/ --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQuH9UOJgpPLZnQjrAQJyGQQAzDxlUUtC72eBtj64qVf2T20tLI8jRen4 77TU2AOXAJj3idVMQSurMM76jbQ0Rc1rterbVe5526e5UIE5QPGXfkrNoxaTID1E qHb8dtucsYsB33cMYCK5yx5gWabwuGDmcrzurJZPomKZbtpnsJ+pOtIXfyS2jwfj gJC4+e2Kcj8= =YImg -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 08:37: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 93FF016A41F for ; Sat, 23 Jul 2005 08:37:42 +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 41E4743D46 for ; Sat, 23 Jul 2005 08:37:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 171F42214; Sat, 23 Jul 2005 04:39:45 -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 D871390; Sat, 23 Jul 2005 04:39:43 -0400 (EDT) Received: from lists by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1DwFX1-0000DQ-RC; Sat, 23 Jul 2005 09:38:51 +0100 Date: Sat, 23 Jul 2005 09:38:51 +0100 From: Brian Candler To: Tuc at T-B-O-H Message-ID: <20050723083851.GC760@uk.tiscali.com> References: <200507222258.j6MMwemi042819@himinbjorg.tucs-beachin-obx-house.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507222258.j6MMwemi042819@himinbjorg.tucs-beachin-obx-house.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Syslog not logging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 08:37:42 -0000 On Fri, Jul 22, 2005 at 06:58:40PM -0400, Tuc at T-B-O-H wrote: > I'm trying to get syslog to log output from a 7 machines and 4 > routers, all in the same subnet. My syslog is started as such : > > 301 ?? Ss 0:19.82 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -a 192.168.3.0/24 > > > my syslog.conf has : > > *.debug /var/log/spool > > > For all the servers, everything is perfect. Its the routers that > are a problem. When I TCPDUMP it, I get : > > 18:50:56.736979 IP 192.136.64.2.8888 > 192.136.64.108.514: UDP, ... ^^^^ syslogd by default only accepts packets with source port 514. If the routers use the same static port then "-a 192.168.3.0/24:8888" will allow it; otherwise "-a 192.168.3.0/24:*" will allow from all ports. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 10:00: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 09A2C16A420 for ; Sat, 23 Jul 2005 10:00:02 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22CFA43D55 for ; Sat, 23 Jul 2005 10:00:01 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so122581rne for ; Sat, 23 Jul 2005 03:00: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h5XgYNMwWfx/vtMFxXC8UQeCRLj9xmkCmHnduJ5gZ9BOqEenaGZCud45VLqwp2nzch/m9OH1MUGz5pL9+CtavnYbDy3p/CD8asdrsFETjwY6qVo5mOkFjlGOMt6fWaQ9Wm6SojxnEWWT5mICYJrPFk4/13yNyZ85AxiXc2OeJj4= Received: by 10.38.89.29 with SMTP id m29mr419609rnb; Sat, 23 Jul 2005 03:00:01 -0700 (PDT) Received: by 10.38.101.41 with HTTP; Sat, 23 Jul 2005 03:00:01 -0700 (PDT) Message-ID: Date: Sat, 23 Jul 2005 19:00:01 +0900 From: Eric Kjeldergaard To: Nate Lawson In-Reply-To: <42E1481F.5040306@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42E1481F.5040306@root.org> Cc: acpi@freebsd.org, FreeBSD Current Subject: Re: acpi battery rework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Kjeldergaard List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 10:00:03 -0000 On 7/23/05, Nate Lawson wrote: > I have completed a rework of the battery subsystem and would like=20 > testing of the patch. I'd like this to go into 6.0. It should have no= =20 > effect for people with working batteries and fixes some bugs for those=20 > who don't. It also makes it possible to import support for smart=20 > batteries (not in this patch). >=20 > API changes: > apm compatibility device: no change > sysctl: no change > kernel function call: API reduced. > ioctl: API reduced. >=20 > kernel function access: > Access individual batteries via devclass_find("battery"). Methods are=20 > ACPI_BATT_GET_STATUS (for _BST-formatted data) and ACPI_BATT_GET_INFO=20 > (for _BIF-formatted data). The helper function=20 > acpi_battery_get_battinfo() has been changed to take a device_t instead= =20 > of unit # argument. If dev is NULL, this signifies all batteries. >=20 > ioctl access: > The ACPIIO_BATT_GET_TYPE and ACPIIO_BATT_GET_BATTDESC ioctls have been=20 > removed. Since there is no mapping between "virtual" unit and actual=20 > unit, just specify the unit directly and skip the old translation steps.= =20 > For instance, in the future if you have two smart batteries and two=20 > control-method batteries, they'll be battery0-3. >=20 > Patch can be found here: > http://root.org/~nate/freebsd/batt-rework.diff.gz >=20 > Please test to be sure your battery status works as usual, along with=20 > any apps. Since most apps (xbatt, gnome, etc.) use the apm compat=20 > layer, they should work as before with no recompilation needed. >=20 > --=20 > Nate > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >=20 -CURRENT as of 23/07/2005, does not compile. cc -O2 -fno-strict-aliasing -pipe -pipe -march=3Dpentium4m -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I-=20 -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -include /usr/obj/usr/src/sys/UNINFECTABLE/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=3D8000 -fno-common=20 -I/usr/obj/usr/src/sys/UNINFECTABLE -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c In file included from /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:59: @/dev/acpica/acpivar.h:397: warning: "struct acpi_bst" declared inside parameter list @/dev/acpica/acpivar.h:397: warning: its scope is only this definition or declaration, which is probably not what you want @/dev/acpica/acpivar.h:398: warning: "struct acpi_bif" declared inside parameter list *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. *** Error code 1 Stop in /usr/src/sys/modules/acpi. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/UNINFECTABLE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --=20 If I write a signature, my emails will appear more personalised. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 11:07: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 F2E8216A41F for ; Sat, 23 Jul 2005 11:07:31 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 969F243D45 for ; Sat, 23 Jul 2005 11:07:31 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Sat, 23 Jul 2005 06:07:31 -0500 id 00095803.42E224F3.00008E71 Received: from dsl-201-144-87-77.prod-infinitum.com.mx (dsl-201-144-87-77.prod-infinitum.com.mx [201.144.87.77]) by mail.bafirst.com (Horde MIME library) with HTTP; Sat, 23 Jul 2005 06:07:30 -0500 Message-ID: <20050723060730.3u9qtdrdogkcwog4@mail.bafirst.com> Date: Sat, 23 Jul 2005 06:07:30 -0500 From: eculp@bafirst.com To: freebsd-current@freebsd.org References: <20050722180621.qj8w6e47i8gkwk88@mail.bafirst.com> In-Reply-To: <20050722180621.qj8w6e47i8gkwk88@mail.bafirst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.1-cvs Subject: Re: I just installed pf on a new server w/current and nat doesn't seem to work. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 11:07:32 -0000 Problem fixed. Thanks ed Quoting eculp@bafirst.com: > My major problem is that I am over 2500 miles from the server and in > another country. I have configured a current box with the idea of > stoping at 6.0 but that is another issue. > > It would seem that pf nat isn't working. The machines on the lan > pickup there configuration from dhcpd and can ping their gateway > 192.168.1.1 (em0 on the server) and 65.81.102.2 (em1 on the server) > but cannot ping 65.81.102.1 the server's gateway. It would seem that > there are issues with either ip forwarding or pf nat. when I do a > pfctl -vv -s Interfaces I get all zeros even though I am creating > traffic on the server. That doesn't seem to be right. > > My configurations follow. I would sure appreciate any suggestions > because I'm afraid that I've missed something. That is usually the > case with problems like this. > > # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > > /etc/pf.conf: > > int_if = "em0" > ext_if = "em1" > > udp_services = "{ 53 }" > tcp_services = "{ 22, 25, 53, 80, 110, 113, 123, 143, 389, 3128 }" > icmp_types = "echoreq" > priv_nets = "{ 0.0.0.0/8, 20.20.20.0/24, 169.254.0.0/16, 127.0.0.0/8, > 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 224.0.0.0/3 }" > > # options > set block-policy return > set loginterface $ext_if > > # scrub > scrub in all > > # nat/rdr > nat on $ext_if from $int_if:network to any -> ($ext_if) > rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128 > > # filter rules > block all > pass quick on lo0 all > block drop in quick on $ext_if from $priv_nets to any > block drop out quick on $ext_if from any to $priv_nets > pass in on $ext_if inet proto udp from any to ($ext_if) port > $udp_services keep state > pass in on $ext_if inet proto tcp from any to ($ext_if) port > $tcp_services flags S/SA keep state > pass in on $int_if inet proto tcp from any to 127.0.0.1 port 3128 keep state > pass out on $ext_if inet proto tcp from any to any port www keep state > pass in inet proto icmp all icmp-type $icmp_types keep state > pass in on $int_if from $int_if:network to any keep state > pass out on $int_if from any to $int_if:network keep state > pass out on $ext_if proto tcp all modulate state flags S/SA > pass out on $ext_if proto { udp, icmp } all keep state > > rc.conf: > ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0" > ifconfig_em1="inet 65.81.102.2 netmask 255.255.255.248" > defaultrouter="65.81.102.1" gateway_enable="YES" pf_enable="YES" > pf_rules="/etc/pf.conf" > pf_program="/sbin/pfctl" > pf_flags="" > pflog_enable="YES" > pflog_logfile="/var/log/pflog" > pflog_program="/sbin/pflogd" > pflog_flags="" > > > # PF Kernel Config > > device pf > device pflog > device pfsync > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_CDNR > options ALTQ_PRIQ > > Where else could it be? I have several other machines that have very > similar configurations and with no problems, of course they are all > within a 2 hour drive ;) > > Thanks for any help or suggestions. > > ed > > _______________________________________________ > 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 Jul 23 11:12: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 712C316A41F for ; Sat, 23 Jul 2005 11:12:56 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from sev.net.ua (www.sev.net.ua [213.227.237.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E538743D45 for ; Sat, 23 Jul 2005 11:12:53 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from sev.net.ua (localhost [127.0.0.1]) by sev.net.ua (Postfix) with ESMTP id A720E28431; Sat, 23 Jul 2005 14:13:24 +0300 (EEST) Received: from berloga.shadowland (unknown [172.16.185.254]) by sev.net.ua (Postfix) with ESMTP id 805BD28430; Sat, 23 Jul 2005 14:13:24 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1] (may be forged)) by berloga.shadowland (8.12.11/8.12.11) with ESMTP id j6NB9T31004896; Sat, 23 Jul 2005 14:09:29 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11/8.12.11/Submit) id j6NB9SF2004894; Sat, 23 Jul 2005 14:09:28 +0300 From: Alex Lyashkov To: freebsd-current@FreeBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1122116967.4884.4.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Sat, 23 Jul 2005 14:09:28 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Nate Lawson Subject: [panic] 6.0 Beta1 can`t boot - acpi_pci_link_add_reference: apparently invalid index 27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 11:12:56 -0000 With lastes RELENG_6 i can`t boot SMP box with Intell SAI2 motherboard. This log from an install CD created via make release at RELENG_5 box. ------------------- KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000e4c00 len=000000000001b400 SMAP type=01 base=0000000000100000 len=000000001fef0000 SMAP type=03 base=000000001fff0000 len=000000000000fc00 SMAP type=04 base=000000001ffffc00 len=0000000000000400 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff80000 len=0000000000080000 Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-BETA1-20050723-SNAP #0: Sat Jul 23 07:36:52 UTC 2005 root@vpn.sevcity:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0f0e000. Preloaded mfs_root "/boot/mfsroot" at 0xc0f0e198. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0f0e1dc. MP Configuration Table version 1.4 found at 0xc009fd70 Table 'FACP' at 0x1ffffafa Table 'APIC' at 0x1ffffb6e MADT: Found table at 0x1ffffb6e APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 3 ACPI ID 0: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193056 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1263447795 Hz CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1263.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000001f6b7fff, 510197760 bytes (124560 pages) avail memory = 511713280 (488 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 3, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 bios32: Found BIOS32 Service Directory header at 0xc00f6ef0 bios32: Entry = 0xfd8d0 (c00fd8d0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd8d0+0x120 pnpbios: Found PnP BIOS data at 0xc00f6f40 pnpbios: Entry = f0000:a154 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 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) MADT: Found IO APIC ID 2, Interrupt 16 at 0xfec01000 ioapic1: intpin 0 -> PCI IRQ 16 (level, low) ioapic1: intpin 1 -> PCI IRQ 17 (level, low) ioapic1: intpin 2 -> PCI IRQ 18 (level, low) ioapic1: intpin 3 -> PCI IRQ 19 (level, low) ioapic1: intpin 4 -> PCI IRQ 20 (level, low) ioapic1: intpin 5 -> PCI IRQ 21 (level, low) ioapic1: intpin 6 -> PCI IRQ 22 (level, low) ioapic1: intpin 7 -> PCI IRQ 23 (level, low) ioapic1: intpin 8 -> PCI IRQ 24 (level, low) ioapic1: intpin 9 -> PCI IRQ 25 (level, low) ioapic1: intpin 10 -> PCI IRQ 26 (level, low) ioapic1: intpin 11 -> PCI IRQ 27 (level, low) ioapic1: intpin 12 -> PCI IRQ 28 (level, low) ioapic1: intpin 13 -> PCI IRQ 29 (level, low) ioapic1: intpin 14 -> PCI IRQ 30 (level, low) ioapic1: intpin 15 -> PCI IRQ 31 (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 lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard cpu0 BSP: ID: 0x03000000 VER: 0x00040011 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> random: nfslock: pseudo-device io:
mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80007864 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00091166) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fdf10 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 6 A 0x1b 3 4 5 6 7 9 10 11 12 slot 1 0 6 B 0x1c 3 4 5 6 7 9 10 11 12 slot 1 0 6 C 0x1d 3 4 5 6 7 9 10 11 12 slot 1 0 6 D 0x1e 3 4 5 6 7 9 10 11 12 slot 2 0 7 A 0x18 3 4 5 6 7 9 10 11 12 slot 2 0 7 B 0x1c 3 4 5 6 7 9 10 11 12 slot 2 0 7 C 0x1d 3 4 5 6 7 9 10 11 12 slot 2 0 7 D 0x0a 3 4 5 6 7 9 10 11 12 slot 5 0 8 A 0x19 3 4 5 6 7 9 10 11 12 slot 5 0 8 B 0x1e 3 4 5 6 7 9 10 11 12 slot 5 0 8 C 0x1c 3 4 5 6 7 9 10 11 12 slot 5 0 8 D 0x1d 3 4 5 6 7 9 10 11 12 slot 6 0 9 A 0x1a 3 4 5 6 7 9 10 11 12 slot 6 0 9 B 0x1d 3 4 5 6 7 9 10 11 12 slot 6 0 9 C 0x1e 3 4 5 6 7 9 10 11 12 slot 6 0 9 D 0x1c 3 4 5 6 7 9 10 11 12 embedded 0 3 A 0x13 3 4 5 6 7 9 10 11 12 embedded 0 2 A 0x14 3 4 5 6 7 9 10 11 12 slot 3 1 10 A 0x15 3 4 5 6 7 9 10 11 12 slot 3 1 10 B 0x1c 3 4 5 6 7 9 10 11 12 slot 3 1 10 C 0x1d 3 4 5 6 7 9 10 11 12 slot 3 1 10 D 0x1e 3 4 5 6 7 9 10 11 12 slot 4 1 11 A 0x16 3 4 5 6 7 9 10 11 12 slot 4 1 11 B 0x1e 3 4 5 6 7 9 10 11 12 slot 4 1 11 C 0x1c 3 4 5 6 7 9 10 11 12 slot 4 1 11 D 0x1d 3 4 5 6 7 9 10 11 12 embedded 0 15 A 0x02 3 4 5 6 7 9 10 11 12 14 15 embedded 0 15 B 0x02 3 4 5 6 7 9 10 11 12 14 15 embedded 0 15 C 0x02 3 4 5 6 7 9 10 11 12 14 15 embedded 0 15 D 0x02 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 15 func 0 acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 1 pci_link0: on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 5 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 5 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 10 11 pci_link1: irq 14 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 14 N 0 14 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 14 N 0 14 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 14 pci_link2: irq 15 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 15 N 0 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 15 N 0 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 15 pci_link3: irq 18 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 18 N 0 18 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 18 N 0 18 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link4: irq 19 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 19 N 0 19 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 19 N 0 19 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link5: irq 20 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 20 N 0 20 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 20 N 0 20 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 pci_link6: irq 21 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 21 N 0 21 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 21 N 0 21 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 21 pci_link7: irq 23 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 23 N 0 23 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 23 N 0 23 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 23 pci_link8: irq 24 on acpi0 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 24 N 0 24 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 24 N 0 24 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 24 pci_link9: irq 25 on acpi0 pci_link9: Links after initial probe: Index IRQ Rtd Ref IRQs 0 25 N 0 25 pci_link9: Links after initial validation: Index IRQ Rtd Ref IRQs 0 25 N 0 25 pci_link9: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 25 pci_link10: irq 26 on acpi0 pci_link10: Links after initial probe: Index IRQ Rtd Ref IRQs 0 26 N 0 26 pci_link10: Links after initial validation: Index IRQ Rtd Ref IRQs 0 26 N 0 26 pci_link10: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 26 pci_link11: irq 27 on acpi0 pci_link11: Links after initial probe: Index IRQ Rtd Ref IRQs 0 27 N 0 27 pci_link11: Links after initial validation: Index IRQ Rtd Ref IRQs 0 27 N 0 27 pci_link11: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 27 pci_link12: irq 28 on acpi0 pci_link12: Links after initial probe: Index IRQ Rtd Ref IRQs 0 28 N 0 28 pci_link12: Links after initial validation: Index IRQ Rtd Ref IRQs 0 28 N 0 28 pci_link12: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 28 pci_link13: irq 29 on acpi0 pci_link13: Links after initial probe: Index IRQ Rtd Ref IRQs 0 29 N 0 29 pci_link13: Links after initial validation: Index IRQ Rtd Ref IRQs 0 29 N 0 29 pci_link13: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 29 ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 panic: acpi_pci_link_add_reference: apparently invalid index 27 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 0 tid 0 td 0xc091be80 kdb_enter(c0854ce4) at kdb_enter+0x2b panic(c0ef4d5b,c0ef0bb3,1b,c1eeb480,c1eeb480) at panic+0x127 acpi_pci_link_add_reference(c1eeb480,1b,c1e40180,6,1) at acpi_pci_link_add_refe3 prt_attach_devices(c1db3268,c1e40180,c1e40980,0,c1e40180) at prt_attach_devicesb prt_walk_table(c1e40180,0,c1db70e0,c1dfe300,0) at prt_walk_table+0x26 acpi_pcib_attach(c1e40180,c1dfe314,0,c1020c58,c0649d9c) at acpi_pcib_attach+0x1a acpi_pcib_acpi_attach(c1e40180) at acpi_pcib_acpi_attach+0xcf device_attach(c1e40180,c1020ca0,c1e40180,c1e40900,c1e40980) at device_attach+0x8 device_probe_and_attach(c1e40180) at device_probe_and_attach+0xe0 bus_generic_attach(c1e40980,c0ef83e8,c08b44b8,c08b44b8,c1e40980) at bus_generic6 acpi_attach(c1e40980) at acpi_attach+0x631 device_attach(c1e40980,0,c1e40980,c1e41180,0) at device_attach+0x58 device_probe_and_attach(c1e40980) at device_probe_and_attach+0xe0 bus_generic_attach(c1e41180,c1e41180,c1e41180,c1020d40,c0646208) at bus_generic6 nexus_attach(c1e41180) at nexus_attach+0x13 device_attach(c1e41180,c062945a,c1e41180,c08f3f30,1028000) at device_attach+0x58 device_probe_and_attach(c1e41180) at device_probe_and_attach+0xe0 root_bus_configure(c1020d88,c060ae26,0,101ec00,101e000) at root_bus_configure+06 configure(0,101ec00,101e000,0,c0445405) at configure+0x9 mi_startup() at mi_startup+0x96 begin() at begin+0x2c -- FreeVPS Developers Team http://www.freevps.com Positive Software http://www.psoft.net From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 11:38: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 141FD16A41F; Sat, 23 Jul 2005 11:38:27 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCB843D4C; Sat, 23 Jul 2005 11:38:25 +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 j6NBcK8B000878; Sat, 23 Jul 2005 13:38:20 +0200 (CEST) (envelope-from lists@yazzy.org) Date: Sat, 23 Jul 2005 13:38:19 +0200 From: Marcin Jessa To: Eric Kjeldergaard Message-Id: <20050723133819.36efb537.lists@yazzy.org> In-Reply-To: References: <42E1481F.5040306@root.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: acpi@freebsd.org, freebsd-current@freebsd.org, nate@root.org Subject: Re: acpi battery rework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 11:38:27 -0000 On Sat, 23 Jul 2005 19:00:01 +0900 Eric Kjeldergaard wrote: > On 7/23/05, Nate Lawson wrote: > > I have completed a rework of the battery subsystem and would like > > testing of the patch. I'd like this to go into 6.0. It should have no > > effect for people with working batteries and fixes some bugs for those > > who don't. It also makes it possible to import support for smart > > batteries (not in this patch). > > > > API changes: > > apm compatibility device: no change > > sysctl: no change > > kernel function call: API reduced. > > ioctl: API reduced. > > > > kernel function access: > > Access individual batteries via devclass_find("battery"). Methods are > > ACPI_BATT_GET_STATUS (for _BST-formatted data) and ACPI_BATT_GET_INFO > > (for _BIF-formatted data). The helper function > > acpi_battery_get_battinfo() has been changed to take a device_t instead > > of unit # argument. If dev is NULL, this signifies all batteries. > > > > ioctl access: > > The ACPIIO_BATT_GET_TYPE and ACPIIO_BATT_GET_BATTDESC ioctls have been > > removed. Since there is no mapping between "virtual" unit and actual > > unit, just specify the unit directly and skip the old translation steps. > > For instance, in the future if you have two smart batteries and two > > control-method batteries, they'll be battery0-3. > > > > Patch can be found here: > > http://root.org/~nate/freebsd/batt-rework.diff.gz > > > > Please test to be sure your battery status works as usual, along with > > any apps. Since most apps (xbatt, gnome, etc.) use the apm compat > > layer, they should work as before with no recompilation needed. > > > > -- > -CURRENT as of 23/07/2005, does not compile. Prolly because it's for 6.0, not 7.0 From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 23:12: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 4DC2916A41F for ; Fri, 22 Jul 2005 23:12:10 +0000 (GMT) (envelope-from lramos3@satx.rr.com) Received: from ms-smtp-05-eri0.texas.rr.com (ms-smtp-05.texas.rr.com [24.93.47.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0166F43D46 for ; Fri, 22 Jul 2005 23:12:09 +0000 (GMT) (envelope-from lramos3@satx.rr.com) Received: from [192.168.1.2] (cpe-66-69-40-1.satx.res.rr.com [66.69.40.1]) by ms-smtp-05-eri0.texas.rr.com (8.12.10/8.12.7) with ESMTP id j6MNC5Rh006263 for ; Fri, 22 Jul 2005 18:12:07 -0500 (CDT) Message-ID: <42E17D45.7090804@satx.rr.com> Date: Fri, 22 Jul 2005 18:12:05 -0500 From: luis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041016 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 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Mailman-Approved-At: Sat, 23 Jul 2005 11:56:15 +0000 Subject: FreeBSD 5.4 + DELL CERC SATA 1.5/6ch PCI card (Adaptec) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2005 23:12:10 -0000 I'm trying to install anything on my Dell SC 1420: 512 MB, SATA 40GB, with SATA 0 and PATA-2 both enabled and RAID off. Attempting FreeBSD 5.4 and 5.3 installation, both stop at "Waiting 15 secs for SCSI drives to settle". Just prior to this message is "ad4: 38146MB ,WDC WD400BD-75JM......... at ata2-master SATA150", and the only If I escape into loader prompt, type "load aac", followed by lsmod I will see at the end "modules: aac.1". I then type boot and very early see barely a quick glimpse of a message about aac not registering, the number 17, and then the boot process stops at the same "Waiting 15secs for SCSI drives to settle". What else do I need to do in order to figure out what is going on with this computer? By the way, the man page for the aac driver states "This driver is not compatible with Dell controllers that have version 1.x firmware. The firmware version is the same as the kernel version printed in the BIOS POST and driver attach messages." During boot process a message states "BIOS Revision A02". Last bit of information: when trying to install in verbose mode there are messages about the ATA-2 master controller and information about ad4 drive, then "ar FreeBSD check1 failed". At the same time, I have tried to install Mandrake 10 and the process stops when it the attempts to install disk drivers. Any suggestions on how to solve this problem will be greatly appreciated. Thanks. Luis From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 04:18: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 1295916A422 for ; Sat, 23 Jul 2005 04:18:27 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from forrie.com (forrie.hsd1.ma.comcast.net [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id F036843D60 for ; Sat, 23 Jul 2005 04:18:23 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [192.168.1.99] (i-99.forrie.net. [192.168.1.99]) (authenticated bits=0) by forrie.com with ESMTP id j6N4IJIT007371 for ; Sat, 23 Jul 2005 00:18:19 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <42E1C50A.1000202@forrie.com> Date: Sat, 23 Jul 2005 00:18:18 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050719) 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 X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.hsd1.ma.comcast.net) X-MailScanner-LocalNet: Found to be clean X-Mailman-Approved-At: Sat, 23 Jul 2005 11:56:15 +0000 Subject: NOINFO is deprecated in favor of NO_INFO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 04:18:27 -0000 Just updated a system to FreeBSD-6.x (RELENG_6) - noting a copious amount of these errors in all builds (including ports): "/usr/share/mk/bsd.compat.mk", line 36: warning: NOINFO is deprecated in favor of NO_INFO "/usr/share/mk/bsd.compat.mk", line 36: warning: NOPROFILE is deprecated in favor of NO_PROFILE (along with others). I didn't see mention of a correction in UPDATING. Is this dependent upon other ports/items updating their build process or is there a more general fix for it. Thanks. From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 00:47: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 3173316A41F for ; Sat, 23 Jul 2005 00:47:44 +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 BA18943D45 for ; Sat, 23 Jul 2005 00:47:43 +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 j6N0lg2U009517 for ; Fri, 22 Jul 2005 20:47:42 -0400 (EDT) Received: (from www@localhost) by siwenna.cc.gatech.edu (8.12.10/8.12.8) id j6N0lgoK021155; Fri, 22 Jul 2005 20:47:42 -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; Fri, 22 Jul 2005 20:47:42 +0100 (EDT) Message-ID: <33208.24.27.59.14.1122079662.squirrel@webmail.cc.gatech.edu> Date: Fri, 22 Jul 2005 20:47:42 +0100 (EDT) From: "Jason Harmening" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 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: Sat, 23 Jul 2005 12:01:26 +0000 Subject: 6.0-BETA1 atapicam and acpi problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 00:47:44 -0000 Hi all, I just upgraded from FreeBSD 5.4-STABLE to 6.0-BETA1 on an amd64 desktop and an i386 laptop (ThinkPad A31). I've generally been very impressed with its performance and stability, but I've noticed a couple of problems: 1. On the desktop, I have an old Fujitsu DynaMO 2.3G ATAPI MO drive, and I've always had to use atapicam with it because there's no native ATA driver. The drive is genuinely capable of UDMA33, and I have hw.ata.atapi_dma turned on. In the past the SCSI device listing that comes from atapicam has always shown the full transfer rate, as follows: da0 at ata0 bus 0 target 0 lun 0 da0: Removable Optical SCSI-4 device da0: 33.000MB/s transfers But now with the upgrade to 6.0, it doesn't look as if UDMA is being enabled: da0 at ata0 bus 0 target 0 lun 0 da0: Removable Optical SCSI-4 device da0: 3.300MB/s transfers My UDMA33 CD burner still shows 33 MB/s in its atapicam SCSI listing, so I know UDMA transfers aren't completely broken with atapicam. And I can't seem to use atacontrol to change the mode, because atacontrol has changed and requires an actual ata device file rather than a channel number. But I can still use the drive, and its performance doesn't seem to have been hurt, for small files at least. 2. The laptop has ACPI issues--it worked fine with 5.4, but with 6.0 if I suspend and resume with the X server running, the screen will become garbled--I have to reboot via ssh. If I shut down X before suspending, it will resume fine, but if I then try to restart X, the screen will again become garbled. The machine will still be responsive--I can issue commands via ssh--but if I try to issue a reboot or shutdown command, it will hang and I'll have to do a hard reboot. I don't have debugging turned on in either kernel, so let me know if you want traces and I'll turn it back on. Otherwise, everything is working fine. Thanks in advance for any help you may be able to offer. Jason Harmening From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 12:06: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 DE53F16A41F for ; Sat, 23 Jul 2005 12:06:38 +0000 (GMT) (envelope-from scottro@scottro.net) Received: from ms-smtp-02.rdc-nyc.rr.com (ms-smtp-02-smtplb.rdc-nyc.rr.com [24.29.109.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8020143D49 for ; Sat, 23 Jul 2005 12:06:38 +0000 (GMT) (envelope-from scottro@scottro.net) Received: from mail.scottro.net (cpe-68-175-68-211.nyc.res.rr.com [68.175.68.211]) by ms-smtp-02.rdc-nyc.rr.com (8.12.10/8.12.7) with ESMTP id j6NC6Zhv004993 for ; Sat, 23 Jul 2005 08:06:35 -0400 (EDT) Received: by mail.scottro.net (Postfix, from userid 1001) id 2628A41FC; Sat, 23 Jul 2005 08:06:35 -0400 (EDT) Date: Sat, 23 Jul 2005 08:06:35 -0400 From: Scott Robbins To: freebsd-current@freebsd.org Message-ID: <20050723120635.GA15956@mail.scottro.net> Mail-Followup-To: freebsd-current@freebsd.org References: <42E1C50A.1000202@forrie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <42E1C50A.1000202@forrie.com> User-Agent: mutt-ng devel (FreeBSD) X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: NOINFO is deprecated in favor of NO_INFO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 12:06:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Jul 23, 2005 at 12:18:18AM -0400, Forrest Aldrich wrote: > Just updated a system to FreeBSD-6.x (RELENG_6) - noting a copious amount of these errors in all > builds (including ports): > > "/usr/share/mk/bsd.compat.mk", line 36: warning: NOINFO is deprecated in favor of NO_INFO > "/usr/share/mk/bsd.compat.mk", line 36: warning: NOPROFILE is deprecated in favor of NO_PROFILE > > (along with others). > > I didn't see mention of a correction in UPDATING. It's there. less /usr/src/UPDATING Do a search for NO_FOO :) > > Is this dependent upon other ports/items updating their build process or is there a more general > fix for it. > It's deprecated but won't break anything as far as I know. - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Spike: So when do we destroy the world, already? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4jLL+lTVdes0Z9YRAoYIAJ9TpvCEo/na9UZjIVeHJrAvCO6fmQCfRcnp mIlNBzIcJZ38b3XXfojDRRw= =O8eG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 12:12: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 1B30416A41F for ; Sat, 23 Jul 2005 12:12:25 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4247643D46 for ; Sat, 23 Jul 2005 12:12:23 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail invoked by alias); 23 Jul 2005 12:12:22 -0000 Received: from unknown (EHLO klamath) [212.204.44.203] by mail.gmx.net (mp003) with SMTP; 23 Jul 2005 14:12:22 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: Forrest Aldrich In-Reply-To: <42E1C50A.1000202@forrie.com> References: <42E1C50A.1000202@forrie.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IwTwCKYIWT4691VMWxM5" Date: Sat, 23 Jul 2005 14:12:20 +0200 Message-Id: <1122120740.978.4.camel@klamath.syndrom23.de> Mime-Version: 1.0 X-Mailer: Evolution 2.3.5.1 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: NOINFO is deprecated in favor of NO_INFO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 12:12:25 -0000 --=-IwTwCKYIWT4691VMWxM5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, On Sat, 2005-07-23 at 00:18 -0400, Forrest Aldrich wrote: > Just updated a system to FreeBSD-6.x (RELENG_6) - noting a copious=20 > amount of these errors in all builds (including ports): >=20 > "/usr/share/mk/bsd.compat.mk", line 36: warning: NOINFO is deprecated in=20 > favor of NO_INFO > "/usr/share/mk/bsd.compat.mk", line 36: warning: NOPROFILE is deprecated=20 > in favor of NO_PROFILE >=20 > (along with others). >=20 > I didn't see mention of a correction in UPDATING. >=20 > Is this dependent upon other ports/items updating their build process or=20 > is there a more general fix for it. Do you have NOINFO, NOPROFILE et al. in your /etc/make.conf? If so, just change those into NO_INFO and NO_PROFILE.=20 Regards, Andreas --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=-IwTwCKYIWT4691VMWxM5 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) iD8DBQBC4jQkYucd7Ow1ygwRArRJAJ9jEwZfUlfF9RTvF/zfZhjHjsI5awCcCb76 2bg+tzaMDy4rHzuY3qy+ibQ= =9rVv -----END PGP SIGNATURE----- --=-IwTwCKYIWT4691VMWxM5-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 12:49: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 DEA0C16A41F for ; Sat, 23 Jul 2005 12:49:50 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn.tucs-beachin-obx-house.com [204.107.90.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B5243D5C for ; Sat, 23 Jul 2005 12:49:49 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (ool-44c511d8.dyn.optonline.net [68.197.17.216]) (authenticated bits=128) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id j6NCnmSa061336; Sat, 23 Jul 2005 08:49:48 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.12.10) with ESMTP id j6NCngKL064057; Sat, 23 Jul 2005 08:49:42 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.13.1/Submit) id j6NCnfqp064055; Sat, 23 Jul 2005 08:49:41 -0400 (EDT) (envelope-from tbohml) From: Tuc at T-B-O-H Message-Id: <200507231249.j6NCnfqp064055@himinbjorg.tucs-beachin-obx-house.com> To: B.Candler@pobox.com (Brian Candler) Date: Sat, 23 Jul 2005 08:49:41 -0400 (EDT) In-Reply-To: <20050723083851.GC760@uk.tiscali.com> from "Brian Candler" at Jul 23, 2005 09:38:51 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Tuc at T-B-O-H Subject: Re: Syslog not logging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 12:49:51 -0000 > > 18:50:56.736979 IP 192.136.64.2.8888 > 192.136.64.108.514: UDP, ... > ^^^^ > > syslogd by default only accepts packets with source port 514. If the routers > use the same static port then "-a 192.168.3.0/24:8888" will allow it; > otherwise "-a 192.168.3.0/24:*" will allow from all ports. > Hi, Thanks, this was what I needed to do. Never ran into needing to do that before. Thanks, Tuc From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 14:16: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 5B6DB16A41F for ; Sat, 23 Jul 2005 14:16:04 +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 5C33443D49 for ; Sat, 23 Jul 2005 14:16:02 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 23 Jul 2005 14:16:00 -0000 Received: from p5090CFF4.dip.t-dialin.net (EHLO klotz.local) [80.144.207.244] by mail.gmx.net (mp021) with SMTP; 23 Jul 2005 16:16:00 +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 j6NEFsX5004487 for ; Sat, 23 Jul 2005 16:15:56 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42E2511A.5030106@nurfuerspam.de> Date: Sat, 23 Jul 2005 16:15:54 +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: bktr(4) on -RELENG_6 and -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, 23 Jul 2005 14:16:04 -0000 Hi, something is wrong with the bktr(4) driver on -RELENG_6 and -CURRENT. Whatever kernel and/or Xorg settings I try I get the same result. About every second line is being drawn. There are black gaps between them with occasional exceptions. This exceptionally drawn lines (which appear mostly in the right half of the TV screen) make it impossible to watch TV when you switch to fullscreen mode. In small windowed mode (xawtv default), everything seems to be ok. Last thing I did was to try the same kernel settings as on my -STABLE version. But I still get the same result. Kernel settings: device bktr options OVERRIDE_CARD=2 options OVERRIDE_MSP=2 options BROOKTREE_SYSTEM_DEFAULT=BROOKTREE_PAL options BKTR_GPIO_ACCESS options BKTR_SIS_VIA_MODE I'm using the nvidia driver. When using nv there is the same effect for a short time until the system freezes completely. In my opinion nv is totally broken, btw. Martin From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 14:55: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 F2AE316A41F; Sat, 23 Jul 2005 14:55:19 +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 4B5A343D45; Sat, 23 Jul 2005 14:55:18 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd33.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1DwLPJ-0006yc-00; Sat, 23 Jul 2005 16:55:17 +0200 Received: from Andro-Beta.Leidinger.net (Xd7Y92ZDZes9dYH4g3mh81igGRmwSlDDc9E4YgnTlZQYIyyyxKdHk+@[84.165.227.115]) by fwd33.sul.t-online.de with esmtp id 1DwLPD-1ECCEC0; Sat, 23 Jul 2005 16:55:11 +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 j6NEtA1j045554; Sat, 23 Jul 2005 16:55:10 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sat, 23 Jul 2005 16:55:10 +0200 From: Alexander Leidinger To: current@freebsd.org Message-ID: <20050723165510.0ba168d0@Magellan.Leidinger.net> In-Reply-To: <200507231423.j6NENULF017447@repoman.freebsd.org> References: <200507231423.j6NENULF017447@repoman.freebsd.org> X-Mailer: Sylpheed-Claws 1.9.12 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Xd7Y92ZDZes9dYH4g3mh81igGRmwSlDDc9E4YgnTlZQYIyyyxKdHk+@t-dialin.net X-TOI-MSGID: 2a8b0516-879a-4937-bff9-6631cf8ee743 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: HEADS-UP: new feature: removing of obsolete files (was: Re: cvs commit: src Makefile Makefile.inc1 ObsoleteFiles.inc UPDATING src/share/man/man7 build.7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 14:55:20 -0000 On Sat, 23 Jul 2005 14:23:30 +0000 (UTC) Alexander Leidinger wrote: I covered nearly 6 years of obsolete files in this commit, but I may have missed some. I also tried to add a short comment why a files was removed. So in case you find a wrong comment or a file which isn't covered by this commit feel free to send a patch or commit it on our own. I haven't specified a MFC time in this commit, since I only have commit access at the weekends ATM. And at the weekends my spare time is shared with other (maybe more important) things. If someone wants to MFC this on his own: please run "make check-old" on a virgin RELENG_6 system to make sure no files show up as obsolete. Bye, Alexander. > netchild 2005-07-23 14:23:30 UTC > > FreeBSD src repository > > Modified files: > . Makefile Makefile.inc1 UPDATING > share/man/man7 build.7 > Added files: > . ObsoleteFiles.inc > Log: > Add delete-old and delete-old-libs targets: > - removes obsolete files/dirs or libraries. > - works in interactive (default) and batch mode > - respects DISTDIR > - documented in UPDATING and build(7) > > The head of the file ObsoleteFiles.inc contains instructions how to add > obsolete files/dirs/libs to the list. Obviously one should add obsolete > files to this list, when he removes a file/dir/lib from the basesystem. [...] Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 16:14: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 81C5216A41F for ; Sat, 23 Jul 2005 16:14:46 +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 AC03843D48 for ; Sat, 23 Jul 2005 16:14:45 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp221-241.lns3.adl2.internode.on.net [203.122.221.241]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6NGEXaP096508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 24 Jul 2005 01:44:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 24 Jul 2005 01:44:27 +0930 User-Agent: KMail/1.8.1 References: <42E2511A.5030106@nurfuerspam.de> In-Reply-To: <42E2511A.5030106@nurfuerspam.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1902993.nDIZlSt7xD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507240144.27687.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Martin Subject: Re: bktr(4) on -RELENG_6 and -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, 23 Jul 2005 16:14:46 -0000 --nextPart1902993.nDIZlSt7xD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 23 July 2005 23:45, Martin wrote: > I'm using the nvidia driver. When using nv there is the same effect > for a short time until the system freezes completely. In my opinion > nv is totally broken, btw. If I use nvidia my PC locks up if I run fxtv (although the TV is displayed= =20 nicely..) =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 --nextPart1902993.nDIZlSt7xD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4mzj5ZPcIHs/zowRAjtbAJ0QYUGSwihQvX+jf3AFarZgxDb/lgCfX9HA 5V1Xcfd08+CcD0TepkWJVjc= =6jYk -----END PGP SIGNATURE----- --nextPart1902993.nDIZlSt7xD-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 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 C4DBC16A41F for ; Sat, 23 Jul 2005 16:28:13 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5939143D46 for ; Sat, 23 Jul 2005 16:28:12 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id EEE78CC249C for ; Sat, 23 Jul 2005 12:28:10 -0400 (EDT) X-Sasl-enc: pdqv0aCH8BRLqioP51fZQoXU2S91u9iWcisryDr0kGmA 1122136091 Received: from [192.168.1.134] (unknown [207.160.231.2]) by frontend3.messagingengine.com (Postfix) with ESMTP id E3E4F1DC for ; Sat, 23 Jul 2005 12:28:10 -0400 (EDT) Message-ID: <42E26FFB.4070405@fastmail.fm> Date: Sat, 23 Jul 2005 11:27:39 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050515 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Debug output when wi0 pcccard removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 16:28:13 -0000 Reposted from stable mailing list... Hello, All; I recently CVSUP'd from 5.4 to 6.0BETA1. I used the instructions in UPDATING to build/install world and used GENERIC unmodified to build the kernel. The whole procedure went without a single hitch. My question concerns the meaning of a debug message which appears when I remove my Wi-Fi card (which by the way works fine...I'm using it to send this mail). Here's the output from "dmesg" when I insert the card (just for reference); wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:04:e2:80:34:be When I remove the card I get the following; taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex wi0 (network driver) r = 0 (0xc2416afc) locked @ /usr/src/sys/dev/wi/if_wi.c:845 KDB: stack backtrace: kdb_backtrace(1,c1af9250,c1af9000,c1989b80,d44bfc2c) at kdb_backtrace+0x29 witness_warn(5,0,c0854d21,c1af9000,c1af9000) at witness_warn+0x18e taskqueue_drain(c1989b80,c1af9250,c1af9000,c1af9000,c1af9000) at taskqueue_drain+0x1a if_detach(c1af9000,c1af9000) at if_detach+0x1a ether_ifdetach(c1af9000,0,c2416000,d44bfc94,c05debfc) at ether_ifdetach+0x28 ieee80211_ifdetach(c2416004,c1af9000,c1af9000,0,c1c51880) at ieee80211_ifdetach+0x50 wi_detach(c1c51880) at wi_detach+0x64 device_detach(c1c51880) at device_detach+0x70 pccard_detach_card(c1aaa600) at pccard_detach_card+0x41 exca_removal(c1a6e804) at exca_removal+0x46 cbb_removal(c1a6e800) at cbb_removal+0x2c cbb_event_thread(c1a6e800,d44bfd38,c1a6e800,c0579df0,0) at cbb_event_thread+0x9a fork_exit(c0579df0,c1a6e800,d44bfd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd44bfd6c, ebp = 0 --- wi0: detached I don't read debug messages yet (just got some tutorials), and am wondering if this is a problem, is it just because WITNESS and INVARIANTS are enabled, or if it's normal but never seen in a non-debug kernel. I get a similar message when I shutdown, having to do mostly with ACPI, but since that's been buggy on this machine (Dell Latitude C600), I almost expected that. Thanks in advance-- Patrick Bowen _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 16:40: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 3A66E16A41F for ; Sat, 23 Jul 2005 16:40:44 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1ED543D48 for ; Sat, 23 Jul 2005 16:40:43 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 94636CC25DC for ; Sat, 23 Jul 2005 12:40:42 -0400 (EDT) X-Sasl-enc: H9HYJ7HRU+eMCyWUMojjN5zBlfafryOQHZw2rs8nqj/6 1122136841 Received: from [192.168.1.134] (unknown [207.160.231.2]) by frontend2.messagingengine.com (Postfix) with ESMTP id A6FB257035A for ; Sat, 23 Jul 2005 12:40:41 -0400 (EDT) Message-ID: <42E272F0.8070507@fastmail.fm> Date: Sat, 23 Jul 2005 11:40:16 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050515 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------080004070203090802010004" Cc: Subject: CD-RW not recognized at 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: Sat, 23 Jul 2005 16:40:44 -0000 This is a multi-part message in MIME format. --------------080004070203090802010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear list; Upgrading from 5.4 to 6.0BETA1 , I get the following on boot. The kernel is not recognizing my CD-RW. ad0: 19077MB at ata0-master UDMA33 unknown: timeout waiting for read DRQunknown: timeout waiting for read DRQATA PseudoRAID loaded Comparable boot msg from 5.4 is; ad0: 19077MB [38760/16/63] at ata0-master UDMA33 acd0: DVDROM at ata1-master PIO4 The machine is a Dell latitude C600. I also have a DVD which *is* recognized. Is support for this particular CD-RW lost in the mists of time, or is there something I can check for? /boot/device.hints has the correct hints for this drive when compared to the 5.4 hints. Dmesg attached. Any assistance appreciated. Patrick Bowen --------------080004070203090802010004 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Fri Jul 22 18:50:32 CDT 2005 pbowen@sg1.sgc.org:/usr/obj/usr/src/sys/LAPTOP-MINIMAL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (601.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 536719360 (511 MB) avail memory = 515534848 (491 MB) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x860-0x86f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pcm0: port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ffffff irq 5 at device 8.0 on pci0 pcm0: failed: rid 0x10 is ioport, requested 3 pcm0: xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffd800-0xf3ffd87f,0xf3ffdc00-0xf3ffdc7f irq 11 at device 16.0 on pci0 miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:48:c7:b2 pci0: at device 16.1 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xcffff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 601366134 Hz quality 800 Timecounters tick every 10.000 msec ad0: 19077MB [38760/16/63] at ata0-master UDMA33 acd0: DVDROM at ata1-master PIO4 wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:04:e2:80:34:be wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a --------------080004070203090802010004-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 16:50: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 5239616A41F for ; Sat, 23 Jul 2005 16:50:21 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F97943D45 for ; Sat, 23 Jul 2005 16:50:20 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 23 Jul 2005 16:50:16 -0000 Received: from p5090CFF4.dip.t-dialin.net (EHLO klotz.local) [80.144.207.244] by mail.gmx.net (mp016) with SMTP; 23 Jul 2005 18:50:16 +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 j6NGnliY005101; Sat, 23 Jul 2005 18:49:53 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42E2752B.5070908@nurfuerspam.de> Date: Sat, 23 Jul 2005 18:49:47 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <42E2511A.5030106@nurfuerspam.de> <200507240144.27687.doconnor@gsoft.com.au> In-Reply-To: <200507240144.27687.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: bktr(4) on -RELENG_6 and -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, 23 Jul 2005 16:50:21 -0000 Daniel O'Connor wrote: > If I use nvidia my PC locks up if I run fxtv (although the TV is displayed > nicely..) Happened to me too a few times, but it was my own fault. I forgot to update nvidia-driver after updating the kernel. Sometimes the nvidia.ko module does not work with a fresh kernel and you have to recompile it. Martin From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 18:06: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 07AF516A41F for ; Sat, 23 Jul 2005 18:06:25 +0000 (GMT) (envelope-from steve.tell@crashmail.de) Received: from hydra.crashmail.de (hydra.crashmail.de [217.146.142.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F80743D62 for ; Sat, 23 Jul 2005 18:06:17 +0000 (GMT) (envelope-from steve.tell@crashmail.de) Received: from localhost (localhost.crashmail.de [127.0.0.1]) by hydra.crashmail.de (Postfix) with ESMTP id 156FE2EF56; Sat, 23 Jul 2005 20:05:34 +0200 (CEST) Received: from hydra.crashmail.de ([127.0.0.1]) by localhost (hydra.crashmail.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19825-01; Sat, 23 Jul 2005 20:05:21 +0200 (CEST) Received: from zeus.crashmail.de (dsl-084-059-203-079.arcor-ip.net [84.59.203.79]) by hydra.crashmail.de (Postfix) with ESMTP id 418442EE1F; Sat, 23 Jul 2005 20:05:20 +0200 (CEST) Received: from localhost (zeus.crashmail.de [192.168.1.100]) by zeus.crashmail.de (Postfix) with ESMTP id 0EA975566; Sat, 23 Jul 2005 20:05:59 +0200 (CEST) Received: from zeus.crashmail.de ([127.0.0.1]) by localhost (zeus.crashmail.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34161-06; Sat, 23 Jul 2005 20:05:57 +0200 (CEST) Received: from pandora.crashmail.de (pandora.crashmail.de [192.168.1.20]) by zeus.crashmail.de (Postfix) with ESMTP id C5A2354FD; Sat, 23 Jul 2005 20:05:56 +0200 (CEST) From: Stefan 'Steve' Tell To: "Daniel O'Connor" In-Reply-To: <200507240144.27687.doconnor@gsoft.com.au> (Daniel O'Connor's message of "Sun, 24 Jul 2005 01:44:27 +0930") Organization: The Third Place References: <42E2511A.5030106@nurfuerspam.de> <200507240144.27687.doconnor@gsoft.com.au> X-Face: .KSo,m`RE@]&5>cJ8vw<`1x?R(?,Q]b@qeq; P\.fK\}i>U^v9f; /~+rKfXKOJ$jD@Foy7MtnIpnk+6]/](%q@*/|+M<4.q@SO3+)u X-PGP-Key: 0x9B6C7E15 X-PGP-Fingerprint: 0A21 6C88 552E 54AE 3FB5 4732 25EE 6ABE 9B6C 7E15 X-BSD-Version: FreeBSD pandora.crashmail.de 7.0-CURRENT FreeBSD 7.0-CURRENT #12: Sat Jul 23 17:12:21 CEST 2005 stell@pandora.crashmail.de:/usr/obj/usr/src/sys/PANDORA i386 Date: Sat, 23 Jul 2005 20:05:52 +0200 Message-ID: <87ek9p9z3z.fsf@zeus.crashmail.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Virus-Scanned: amavisd-new at zeus.crashmail.de X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at crashmail.de Cc: freebsd-current@freebsd.org, Martin Subject: Re: bktr(4) on -RELENG_6 and -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, 23 Jul 2005 18:06:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable * "Daniel O'Connor" wrote: > On Saturday 23 July 2005 23:45, Martin wrote: >> I'm using the nvidia driver. When using nv there is the same effect >> for a short time until the system freezes completely. In my opinion >> nv is totally broken, btw. > If I use nvidia my PC locks up if I run fxtv (although the TV is displaye= d=20 > nicely..) Similar problems here: http://lists.freebsd.org/pipermail/freebsd-current/2005-January/045817.html (still there on FreeBSD 7.0-CURRENT) =2D-=20 By(t)e, Steve /\ http://www.crashmail.de GnuPG/PGP: 0X9B6C7E15, encrypted mail prefered, see header --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) Comment: GPG/PGP [DH/DSS): 4096bit KeyID: 0x9B6C7E15 iD8DBQFC4ocEJe5qvptsfhURAgrqAJ4pBWBv7Rs7YUeVvCQbHboEgBRp0ACdH2G9 KTCgN6JwM9MiAtVFyntLHq4= =akig -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 18: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 0F0D216A41F; Sat, 23 Jul 2005 18:30:22 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D04B43D45; Sat, 23 Jul 2005 18:30:20 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j6NIUJpA044092; Sat, 23 Jul 2005 22:30:19 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j6NIUJ30044091; Sat, 23 Jul 2005 22:30:19 +0400 (MSD) (envelope-from ache) Date: Sat, 23 Jul 2005 22:30:19 +0400 From: Andrey Chernov To: "Greg 'groggy' Lehey" , Doug Barton , freebsd-current@FreeBSD.ORG Message-ID: <20050723183019.GA43895@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Greg 'groggy' Lehey , Doug Barton , freebsd-current@FreeBSD.ORG References: <200507230146.j6N1koqL061690@repoman.freebsd.org> <20050723015517.GA28428@nagual.pp.ru> <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.com> <20050723081631.GA33648@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20050723081631.GA33648@nagual.pp.ru> User-Agent: Mutt/1.5.9i Cc: Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 18:30:22 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 23, 2005 at 12:16:32PM +0400, Andrey Chernov wrote: > Well, I am not advocate /dev/random initialization bug in preference of= =20 > fortune bug. But your "fix" not fix _anything_ in _either_ case, for=20 > fortune bug or for /dev/random bug. Better back it out and seek true bug.= =20 Well, I have some time today, so I back it out by myself. Please read commit log message for the detailed explanation. --=20 http://ache.pp.ru/ --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQuKMuuJgpPLZnQjrAQIyEwQAqf94VoeG5slSoXKr+ia5dthf67LHLBSF +PL2Tz5SXrw9oveVzJAjgRIUrQiRD9R6wiGY3yd0YAA8zvVu2MFZY70Drz2c/pj3 DK2bCxx9AtdOiZp8b622lKRI9avHaMN81sU1f99qJfsHYnUOrmlbjGLQiygd2Qea PEMF39ju9oc= =9B24 -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 18:30: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 62E9F16A42F; Sat, 23 Jul 2005 18:30:26 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18A0D43D45; Sat, 23 Jul 2005 18:30:26 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id EF67C2A8DA; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 48471E2B3; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.1) with ESMTP id j6NIUOSc069370; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6NIUO7O069367; Sat, 23 Jul 2005 11:30:24 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Sat, 23 Jul 2005 11:30:24 -0700 User-Agent: KMail/1.8.1 References: <200507221821.j6MILSbp028681@repoman.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507231130.24493.peter@wemm.org> Cc: Hajimu UMEMOTO , current@freebsd.org Subject: Re: HEADS-UP: ABI compatibility of getaddrinfo(3) was lost. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 18:30:26 -0000 On Friday 22 July 2005 12:38 pm, Hajimu UMEMOTO wrote: > Hi, > > I've nuked the padding for ai_addrlen member of struct addrinfo. It > broke ABI compatibility of getaddrinfo(3) on 64 bit architecture. > You have to recompile userland programs that use getaddrinfo(3) on 64 > bit architecture. Please note that you'll need to recompile ports with shared libraries that reference this too. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 18:30: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 62E9F16A42F; Sat, 23 Jul 2005 18:30:26 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18A0D43D45; Sat, 23 Jul 2005 18:30:26 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id EF67C2A8DA; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 48471E2B3; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.1) with ESMTP id j6NIUOSc069370; Sat, 23 Jul 2005 11:30:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6NIUO7O069367; Sat, 23 Jul 2005 11:30:24 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Sat, 23 Jul 2005 11:30:24 -0700 User-Agent: KMail/1.8.1 References: <200507221821.j6MILSbp028681@repoman.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507231130.24493.peter@wemm.org> Cc: Hajimu UMEMOTO , current@freebsd.org Subject: Re: HEADS-UP: ABI compatibility of getaddrinfo(3) was lost. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 18:30:26 -0000 On Friday 22 July 2005 12:38 pm, Hajimu UMEMOTO wrote: > Hi, > > I've nuked the padding for ai_addrlen member of struct addrinfo. It > broke ABI compatibility of getaddrinfo(3) on 64 bit architecture. > You have to recompile userland programs that use getaddrinfo(3) on 64 > bit architecture. Please note that you'll need to recompile ports with shared libraries that reference this too. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 18:50: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 AA33F16A41F for ; Sat, 23 Jul 2005 18:50:07 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 162ED43D46 for ; Sat, 23 Jul 2005 18:50:06 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 65530 invoked by uid 399); 23 Jul 2005 18:50:06 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 18:50:06 -0000 Received: (qmail 61681 invoked by uid 399); 23 Jul 2005 18:50:01 -0000 Received: from unknown (HELO ?192.168.15.101?) (dougb@dougbarton.net@67.20.70.103) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 18:50:01 -0000 Message-ID: <42E29157.3090908@FreeBSD.org> Date: Sat, 23 Jul 2005 11:49:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Kaduk References: <200507220549.j6M5nfhO059858@repoman.freebsd.org> <47d0403c05072218091264a990@mail.gmail.com> <47d0403c05072218491c78e2e9@mail.gmail.com> In-Reply-To: <47d0403c05072218491c78e2e9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: cvs commit: src/usr.sbin/ndiscvt ndisgen.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 18:50:07 -0000 Ben Kaduk wrote: > I know it's bad form to reply to myself, It's not actually, that's a myth that needs to be busted. :) This is especially true when you have found the right answer, and can save others time investigating the problem. > but this patch seems to allow > ndisgen to recognize my .inf file: Thanks! I noticed a similar problem with my own INF file, and in my case it turned out that the various lines it was searching for did not occur in the first column, but were indented. Removing the ^ in all places it occurred fixed this for me, so I've committed the fix. Good hunting, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:00: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 2E92B16A420; Sat, 23 Jul 2005 19:00:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B82C143D45; Sat, 23 Jul 2005 19:00: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 j6NIxSaZ021599; Sat, 23 Jul 2005 12:59:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jul 2005 13:00:21 -0600 (MDT) Message-Id: <20050723.130021.96602120.imp@bsdimp.com> To: Alexander@Leidinger.net From: "M. Warner Losh" In-Reply-To: <20050723165510.0ba168d0@Magellan.Leidinger.net> References: <200507231423.j6NENULF017447@repoman.freebsd.org> <20050723165510.0ba168d0@Magellan.Leidinger.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: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: HEADS-UP: new feature: removing of obsolete files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:00:44 -0000 In message: <20050723165510.0ba168d0@Magellan.Leidinger.net> Alexander Leidinger writes: : I covered nearly 6 years of obsolete files in this commit, but I may : have missed some. I also tried to add a short comment why a files was : removed. So in case you find a wrong comment or a file which isn't : covered by this commit feel free to send a patch or commit it on our : own. Bravo! I have lists of FreeBSD trees going back to 1.0, but haven't had time to write the script to find those files no longer in current. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:06: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 BB07016A41F for ; Sat, 23 Jul 2005 19:06:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62AE443D45 for ; Sat, 23 Jul 2005 19:06:36 +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 j6NJ3j8E021671; Sat, 23 Jul 2005 13:03:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jul 2005 13:04:38 -0600 (MDT) Message-Id: <20050723.130438.81409618.imp@bsdimp.com> To: lehmann@ans-netz.de From: "M. Warner Losh" In-Reply-To: <20050722191337.269d965b.lehmann@ans-netz.de> References: <200507200149.52721.max@love2party.net> <20050720114331.868A64E704@pipa.profix.cz> <20050722191337.269d965b.lehmann@ans-netz.de> 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, dandee@volny.cz Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:06:36 -0000 In message: <20050722191337.269d965b.lehmann@ans-netz.de> Oliver Lehmann writes: : Daniel Dvorak wrote: : : > Yes, I can confirm this bug, when one use make buildworld with -jN. : > If you build the code without -jN, it is all right. : : I've -j[2-9][0-9]* buildworld problems too. Tried it twice, once with : -j16, once with -j4 - and everytime it fails on different locations. : : -c /usr/src/lib/libc/i386/string/strrchr.S -o strrchr.So : cc: Internal error: Abort trap (program cc1) : Please submit a full bug report. : : Is the last copy&paste output I have Chances are you are running out of memory. Can you try the build w/o -jN? Large values of N can easily run a body out of swap space, yeilding a build failure when the tree is perfectly fine. Persoanally, I never do a -j larger then 4 or 8. top shows that the system that I have is giant bound when I do, so why add more people to the list of Giant waiters? Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:09: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 5707116A41F; Sat, 23 Jul 2005 19:09:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 033E043D45; Sat, 23 Jul 2005 19:09:37 +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 j6NJ8mIR021678; Sat, 23 Jul 2005 13:08:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jul 2005 13:09:41 -0600 (MDT) Message-Id: <20050723.130941.93453281.imp@bsdimp.com> To: grog@freebsd.org From: "M. Warner Losh" In-Reply-To: <20050723064449.GZ842@wantadilla.lemis.com> References: <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.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: dougb@freebsd.org, freebsd-current@freebsd.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 19:09:38 -0000 In message: <20050723064449.GZ842@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : You should take a look at what I committed. It simply uses the : microsecond value returned by getlocaltime() for the automatic seeding : by srandomdev(). It fixes the problem. I can see only two : explanations: : : 1. srandomdev(), random(4) or friends are broken. : 2. random(4) has been initialized incorrectly. : : Currently I'm guessing (2), but I don't care much either way. When sradnomdev() is broken, *DO*NOT* kludge around them by committing half-baked "fixes" like you did. It is broken. We need to find out the *REAL* cause of the problem. If Rush gets more quotes than normal, and that annoys people to find the real problem, we shouldn't mask it. It is a really bad choice from a security point of view. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:12: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 DF56216A41F for ; Sat, 23 Jul 2005 19:12:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90FB443D46 for ; Sat, 23 Jul 2005 19:12:49 +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 j6NJ9aOD021687; Sat, 23 Jul 2005 13:09:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jul 2005 13:10:29 -0600 (MDT) Message-Id: <20050723.131029.11927918.imp@bsdimp.com> To: forrie@forrie.com From: "M. Warner Losh" In-Reply-To: <42E1C50A.1000202@forrie.com> References: <42E1C50A.1000202@forrie.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: NOINFO is deprecated in favor of NO_INFO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:12:50 -0000 In message: <42E1C50A.1000202@forrie.com> Forrest Aldrich writes: : Just updated a system to FreeBSD-6.x (RELENG_6) - noting a copious : amount of these errors in all builds (including ports): : : "/usr/share/mk/bsd.compat.mk", line 36: warning: NOINFO is deprecated in : favor of NO_INFO : "/usr/share/mk/bsd.compat.mk", line 36: warning: NOPROFILE is deprecated : in favor of NO_PROFILE : : (along with others). : : I didn't see mention of a correction in UPDATING. 20041221: By a popular demand, a lot of NOFOO options were renamed to NO_FOO (see bsd.compat.mk for a full list). The old spellings are still supported, but will cause annoying warnings on stderr. Make sure you upgrade properly (see the COMMON ITEMS: section later in this file). From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19: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 C688A16A41F for ; Sat, 23 Jul 2005 19:13:53 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7DE543D45 for ; Sat, 23 Jul 2005 19:13:52 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 49503 invoked by uid 89); 23 Jul 2005 19:13:48 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 23 Jul 2005 19:13:48 -0000 Date: Sat, 23 Jul 2005 21:13:49 +0200 From: Oliver Lehmann To: "M. Warner Losh" Message-Id: <20050723211349.269cd3b7.lehmann@ans-netz.de> In-Reply-To: <20050723.130438.81409618.imp@bsdimp.com> References: <200507200149.52721.max@love2party.net> <20050720114331.868A64E704@pipa.profix.cz> <20050722191337.269d965b.lehmann@ans-netz.de> <20050723.130438.81409618.imp@bsdimp.com> X-Mailer: Sylpheed version 2.0.0rc (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, dandee@volny.cz Subject: Re: -current kernel can't be complied for 3 days X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:13:53 -0000 M. Warner Losh wrote: > Chances are you are running out of memory. Can you try the build w/o > -jN? Large values of N can easily run a body out of swap space, > yeilding a build failure when the tree is perfectly fine. > > Persoanally, I never do a -j larger then 4 or 8. top shows that the > system that I have is giant bound when I do, so why add more people to > the list of Giant waiters? Hi Warner, I don't think that i ran out of memory. At least swapper didn't sayed sth. like that. Back in Dec 2001 I even had a -j100 running (for fun) and it build successfully. This was on a dual PII 333 with 320MB of memoty compiling a 4.XX on a 4.XX. Why shouldn't a -j16 on a dual PIII 850 with 640MB of memory compiling a 6.0 on a 5.4 doesn't work then? I know there are many differences between 4.X and 5.X but why got it worse? A -j4 worked btw (at least the one time I tried it) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:28: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 F013716A41F for ; Sat, 23 Jul 2005 19:28:06 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 346D643D48 for ; Sat, 23 Jul 2005 19:28:06 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 3924 invoked by uid 399); 23 Jul 2005 19:28:05 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 19:28:05 -0000 Received: (qmail 69336 invoked by uid 399); 23 Jul 2005 19:28:03 -0000 Received: from unknown (HELO ?192.168.15.101?) (dougb@dougbarton.net@67.20.70.103) by mail1.fluidhosting.com with SMTP; 23 Jul 2005 19:28:03 -0000 Message-ID: <42E29A42.7040203@FreeBSD.org> Date: Sat, 23 Jul 2005 12:28:02 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.com> <20050723.130941.93453281.imp@bsdimp.com> In-Reply-To: <20050723.130941.93453281.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: grog@freebsd.org, freebsd-current@freebsd.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 19:28:07 -0000 M. Warner Losh wrote: > In message: <20050723064449.GZ842@wantadilla.lemis.com> > "Greg 'groggy' Lehey" writes: > : You should take a look at what I committed. It simply uses the > : microsecond value returned by getlocaltime() for the automatic seeding > : by srandomdev(). It fixes the problem. I can see only two > : explanations: > : > : 1. srandomdev(), random(4) or friends are broken. > : 2. random(4) has been initialized incorrectly. > : > : Currently I'm guessing (2), but I don't care much either way. > > When sradnomdev() is broken, *DO*NOT* kludge around them by committing > half-baked "fixes" like you did. I agree with you in principal Warner, but it's not at all clear that the real problem is srandomdev(). For instance, I just took a look at my laptop and noticed that there was still an old version of the fortunes2 file in /usr/share/games/fortune. The first fortune in that file is the one that I have been seeing with much greater frequency than the others, so I deleted those old files and we'll see what happens from here. I also changed my fortune invocation in my shell startup file to: /usr/games/fortune -D -D -D -sa 2>$HOME/fortune-debug sysctl kern.random.sys.seeded >> $HOME/fortune-debug Hopefully that will tell us something interesting. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:38: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 0CD9116A41F; Sat, 23 Jul 2005 19:38:23 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B4FA43D4C; Sat, 23 Jul 2005 19:38:22 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6NJcIo5029911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jul 2005 12:38:21 -0700 Message-ID: <42E29CAA.1020007@root.org> Date: Sat, 23 Jul 2005 12:38:18 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <42E1481F.5040306@root.org> <20050723133819.36efb537.lists@yazzy.org> In-Reply-To: <20050723133819.36efb537.lists@yazzy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, Eric Kjeldergaard , freebsd-current@freebsd.org Subject: Re: acpi battery rework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:38:23 -0000 Marcin Jessa wrote: > On Sat, 23 Jul 2005 19:00:01 +0900 > Eric Kjeldergaard wrote: >>>Please test to be sure your battery status works as usual, along with >>>any apps. Since most apps (xbatt, gnome, etc.) use the apm compat >>>layer, they should work as before with no recompilation needed. > > >>-CURRENT as of 23/07/2005, does not compile. > > > Prolly because it's for 6.0, not 7.0 Sorry, the problem was I left a file out of the diff. I just committed the patch so please just cvsup and test from 7-CURRENT. Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:44: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 0E77816A41F; Sat, 23 Jul 2005 19:44:18 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C3643D46; Sat, 23 Jul 2005 19:44:17 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j6NJiHo5029968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jul 2005 12:44:17 -0700 Message-ID: <42E29E10.4080403@root.org> Date: Sat, 23 Jul 2005 12:44:16 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Lyashkov References: <1122116967.4884.4.camel@berloga.shadowland> In-Reply-To: <1122116967.4884.4.camel@berloga.shadowland> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [panic] 6.0 Beta1 can`t boot - acpi_pci_link_add_reference: apparently invalid index 27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 19:44:18 -0000 Alex Lyashkov wrote: > With lastes RELENG_6 i can`t boot SMP box with Intell SAI2 motherboard. > This log from an install CD created via make release at RELENG_5 box. > > pci_link13: irq 29 on acpi0 > pci_link13: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 29 N 0 29 > pci_link13: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 29 N 0 29 > pci_link13: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 29 > ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > panic: acpi_pci_link_add_reference: apparently invalid index 27 > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x2b: nop > db> where > Tracing pid 0 tid 0 td 0xc091be80 > kdb_enter(c0854ce4) at kdb_enter+0x2b > panic(c0ef4d5b,c0ef0bb3,1b,c1eeb480,c1eeb480) at panic+0x127 > acpi_pci_link_add_reference(c1eeb480,1b,c1e40180,6,1) at > acpi_pci_link_add_refe3 > prt_attach_devices(c1db3268,c1e40180,c1e40980,0,c1e40180) at > prt_attach_devicesb > prt_walk_table(c1e40180,0,c1db70e0,c1dfe300,0) at prt_walk_table+0x26 > acpi_pcib_attach(c1e40180,c1dfe314,0,c1020c58,c0649d9c) at > acpi_pcib_attach+0x1a > acpi_pcib_acpi_attach(c1e40180) at acpi_pcib_acpi_attach+0xcf Need to see your acpidump -t -d output. It appears your _PRT table has an invalid reference to a link (one that doesn't exist.) -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 19:55: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 A1ABF16A41F for ; Sat, 23 Jul 2005 19:55:00 +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 5BB9343D46 for ; Sat, 23 Jul 2005 19:55:00 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id 26E09BE22A; Sat, 23 Jul 2005 15:56:47 -0400 (EDT) Date: Sat, 23 Jul 2005 15:56:47 -0400 From: James Snow To: freebsd-current@freebsd.org Message-ID: <20050723195647.GA84352@teardrop.org> References: <20050722200948.GA636@stderror.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722200948.GA636@stderror.at> User-Agent: Mutt/1.4.2.1i Subject: Re: 6.0 BETA1 if_ath problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 19:55:00 -0000 On Fri, Jul 22, 2005 at 10:09:48PM +0200, Toni Schmidbauer wrote: > > so it seems things are getting better under 6.0. Unfortunately, I'm having the opposite experience. My X40's ath seems to get worse with each update. Right now it downs the ath0 interface at random intervals. Also, when in adhoc mode it will sometimes spew errors, to the point of slowing the machine down. Repeatedly doing an 'ifconfig down' and reconfiguring the interface will eventually stabilize it. -Snow From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 20:01: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 BFF3716A41F for ; Sat, 23 Jul 2005 20:01:28 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from sev.net.ua (www.sev.net.ua [213.227.237.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD8243D45 for ; Sat, 23 Jul 2005 20:01:27 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from sev.net.ua (localhost [127.0.0.1]) by sev.net.ua (Postfix) with ESMTP id 1762F28431; Sat, 23 Jul 2005 23:01:59 +0300 (EEST) Received: from berloga.shadowland (unknown [172.16.185.254]) by sev.net.ua (Postfix) with ESMTP id 482E028430; Sat, 23 Jul 2005 23:01:58 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1] (may be forged)) by berloga.shadowland (8.12.11/8.12.11) with ESMTP id j6NJvvVX004335; Sat, 23 Jul 2005 22:57:58 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11/8.12.11/Submit) id j6NJvuJj004333; Sat, 23 Jul 2005 22:57:56 +0300 From: Alex Lyashkov To: Nate Lawson In-Reply-To: <42E29E10.4080403@root.org> References: <1122116967.4884.4.camel@berloga.shadowland> <42E29E10.4080403@root.org> Content-Type: multipart/mixed; boundary="=-T6tAMIgdDALHMtHs9L/I" Organization: Positive Software Message-Id: <1122148675.3335.11.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Sat, 23 Jul 2005 22:57:56 +0300 X-Virus-Scanned: ClamAV using ClamSMTP X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" Subject: Re: [panic] 6.0 Beta1 can`t boot - acpi_pci_link_add_reference: apparently invalid index 27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 20:01:29 -0000 --=-T6tAMIgdDALHMtHs9L/I Content-Type: text/plain Content-Transfer-Encoding: 7bit > Need to see your acpidump -t -d output. It appears your _PRT table has > an invalid reference to a link (one that doesn't exist.) > > -- requested output is attached. this box i has are acpi problems early. At 5.2-Current box have interrupt storm, but later it`s fixed. -- Alex Lyashkov Positive Software --=-T6tAMIgdDALHMtHs9L/I-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 21:33: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 A20B516A41F for ; Sat, 23 Jul 2005 21:33:57 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D95543D45 for ; Sat, 23 Jul 2005 21:33:56 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050723213351.RHZK21492.lakermmtao12.cox.net@mezz.mezzweb.com>; Sat, 23 Jul 2005 17:33:51 -0400 Date: Sat, 23 Jul 2005 16:34:55 -0500 To: "Alexander Leidinger" References: <200507231423.j6NENULF017447@repoman.freebsd.org> <20050723165510.0ba168d0@Magellan.Leidinger.net> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20050723165510.0ba168d0@Magellan.Leidinger.net> User-Agent: Opera M2/8.01 (Linux, build 1204) Cc: current@freebsd.org Subject: Re: HEADS-UP: new feature: removing of obsolete files (was: Re: cvs commit: src Makefile Makefile.inc1 ObsoleteFiles.inc UPDATING src/share/man/man7 build.7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2005 21:33:57 -0000 On Sat, 23 Jul 2005 09:55:10 -0500, Alexander Leidinger wrote: > On Sat, 23 Jul 2005 14:23:30 +0000 (UTC) > Alexander Leidinger wrote: > > I covered nearly 6 years of obsolete files in this commit, but I may > have missed some. I also tried to add a short comment why a files was > removed. So in case you find a wrong comment or a file which isn't > covered by this commit feel free to send a patch or commit it on our > own. Nice, about time! I usually use my own script to remove old stuff. It's depend on find's ctime to find old stuff. http://people.freebsd.org/~mezz/script/delete.sh I did a clean up and add a few comments today, so it's untest and will find out tomorrow if it still works. Cheers, Mezz > I haven't specified a MFC time in this commit, since I only have commit > access at the weekends ATM. And at the weekends my spare time is shared > with other (maybe more important) things. If someone wants to MFC this > on his own: please run "make check-old" on a virgin RELENG_6 system to > make sure no files show up as obsolete. > > Bye, > Alexander. > >> netchild 2005-07-23 14:23:30 UTC >> >> FreeBSD src repository >> >> Modified files: >> . Makefile Makefile.inc1 UPDATING >> share/man/man7 build.7 >> Added files: >> . ObsoleteFiles.inc >> Log: >> Add delete-old and delete-old-libs targets: >> - removes obsolete files/dirs or libraries. >> - works in interactive (default) and batch mode >> - respects DISTDIR >> - documented in UPDATING and build(7) >> >> The head of the file ObsoleteFiles.inc contains instructions how to >> add >> obsolete files/dirs/libs to the list. Obviously one should add >> obsolete >> files to this list, when he removes a file/dir/lib from the >> basesystem. > [...] > > Bye, > Alexander. -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 23:07: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 4A3E216A41F; Sat, 23 Jul 2005 23:07:13 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0A9E43D48; Sat, 23 Jul 2005 23:07:12 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 9E3E886DD9; Sun, 24 Jul 2005 08:37:11 +0930 (CST) Date: Sun, 24 Jul 2005 08:37:11 +0930 From: Greg 'groggy' Lehey To: "M. Warner Losh" Message-ID: <20050723230711.GD842@wantadilla.lemis.com> References: <20050723020120.GV842@wantadilla.lemis.com> <42E1DFCE.6090506@FreeBSD.org> <20050723064449.GZ842@wantadilla.lemis.com> <20050723.130941.93453281.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lBPdJKrYqo3eKYSb" Content-Disposition: inline In-Reply-To: <20050723.130941.93453281.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: dougb@freebsd.org, freebsd-current@freebsd.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 23:07:13 -0000 --lBPdJKrYqo3eKYSb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 23 July 2005 at 13:09:41 -0600, M. Warner Losh wrote: > In message: <20050723064449.GZ842@wantadilla.lemis.com> > "Greg 'groggy' Lehey" writes: >> You should take a look at what I committed. It simply uses the >> microsecond value returned by getlocaltime() for the automatic seeding >> by srandomdev(). It fixes the problem. I can see only two >> explanations: >> >> 1. srandomdev(), random(4) or friends are broken. >> 2. random(4) has been initialized incorrectly. >> >> Currently I'm guessing (2), but I don't care much either way. > > When sradnomdev() is broken, *DO*NOT* kludge around them by > committing half-baked "fixes" like you did. This code is good enough for fortune. Nobody's claiming that it's a solution to random number generation. Others should look at that aspect, not get involved in a commit war. > It is broken. We need to find out the *REAL* cause of the problem. Agreed. Is anybody doing that? It's not my area. > If Rush gets more quotes than normal, and that annoys people to find > the real problem, we shouldn't mask it. It is a really bad choice > from a security point of view. So it's better to back perfectly valid code rather than to look for the real culprit? What kind of security is that? Greg -- The virus once contained in this message has lost interest in life, shrivelled up and died. LEMIS anti-virus has given it an appropriate burial. For further details see http://www.lemis.com/grog/lemis-virus.html Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. --lBPdJKrYqo3eKYSb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC4s2fIubykFB6QiMRAi6FAJwPe8xnesZGxYkB0o1zgEBV6Q2hlgCgnnUy +FBVfHbHspqjSQL+NmzyJh4= =3/lv -----END PGP SIGNATURE----- --lBPdJKrYqo3eKYSb-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 23:19: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 BF30316A41F for ; Sat, 23 Jul 2005 23:19:11 +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 7552943D45 for ; Sat, 23 Jul 2005 23:19:11 +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 j6NNJAms052248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jul 2005 16:19:10 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E2D091.4050409@errno.com> Date: Sat, 23 Jul 2005 16:19:45 -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: <20050722200948.GA636@stderror.at> <20050723195647.GA84352@teardrop.org> In-Reply-To: <20050723195647.GA84352@teardrop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 6.0 BETA1 if_ath problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 23:19:11 -0000 James Snow wrote: > On Fri, Jul 22, 2005 at 10:09:48PM +0200, Toni Schmidbauer wrote: > >>so it seems things are getting better under 6.0. > > > Unfortunately, I'm having the opposite experience. My X40's ath seems to > get worse with each update. Right now it downs the ath0 interface > at random intervals. I have one of almost every version of atheros part and I do not see the problems you allude to; not that you've provided any useful info here. In general I tend to ignore complaints of the form "it don't work". > > Also, when in adhoc mode it will sometimes spew errors, to the point of > slowing the machine down. Repeatedly doing an 'ifconfig down' and > reconfiguring the interface will eventually stabilize it. Again, nothing useful here. I just fixed a couple of adhoc mode problems yesterday that are likely unrelated. I had a network of 4 machines setup in adhoc mode; 2 ath freebsd systems, one powerbook with tiger, and one freebsd system with wi. All were in the same room. I saw no problems in several hours of testing. When the 11b station was not in the network I routinely got 28Mb/s for tcp netperf between stations (this is 11g). I am not saying the code is perfect. I'm aware of a couple of issues that I'm working on but in general I am not seeing significant issues with ath devices. If you or anyone else wants to help fix problems you need to provide useful information such as the mac/phy version for the part and the output from 80211stats and/or athstats. It also helps to enable debugging msgs; usually at the 802.11 layer using 80211debug. Sam From owner-freebsd-current@FreeBSD.ORG Sat Jul 23 23:30: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 0B8F516A421; Sat, 23 Jul 2005 23:30:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CAB043D53; Sat, 23 Jul 2005 23:30:38 +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 j6NNU8nr023542; Sat, 23 Jul 2005 17:30:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jul 2005 17:31:00 -0600 (MDT) Message-Id: <20050723.173100.123341239.imp@bsdimp.com> To: grog@lemis.com From: "M. Warner Losh" In-Reply-To: <20050723230711.GD842@wantadilla.lemis.com> References: <20050723064449.GZ842@wantadilla.lemis.com> <20050723.130941.93453281.imp@bsdimp.com> <20050723230711.GD842@wantadilla.lemis.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: dougb@freebsd.org, freebsd-current@freebsd.org Subject: Re: cvs commit: src/games/fortune/fortune fortune.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: Sat, 23 Jul 2005 23:30:39 -0000 In message: <20050723230711.GD842@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : > If Rush gets more quotes than normal, and that annoys people to find : > the real problem, we shouldn't mask it. It is a really bad choice : > from a security point of view. : : So it's better to back perfectly valid code rather than to look for : the real culprit? What kind of security is that? I'm saying we should fix the real, underlying problem. Kludging around the symptom, like you did with fortune, only prolongs the time we have the real, underlying problem. Warner