From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 09:44:34 2006 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 B871316A400 for ; Sun, 2 Apr 2006 09:44:34 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 35BFC43D45 for ; Sun, 2 Apr 2006 09:44:34 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 58051 invoked from network); 2 Apr 2006 09:44:32 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 2 Apr 2006 09:44:32 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k329iWar081989 for ; Sun, 2 Apr 2006 11:44:32 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k329iVeX081988 for current@freebsd.org; Sun, 2 Apr 2006 11:44:31 +0200 (CEST) (envelope-from pho) Date: Sun, 2 Apr 2006 11:44:31 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20060402094431.GA81954@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: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 09:44:34 -0000 I managed to zoom in on the livelocks I've been seeing lately. The livelock is provoked by deleting lots of files. Here's a livelock from single user mode and caught by the watchdogd with GENERIC HEAD from Apr 1 07:40 UTC: http://people.freebsd.org/~pho/stress/log/cons197.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 11:03:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17FFC16A41F; Sun, 2 Apr 2006 11:03:30 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F45343D45; Sun, 2 Apr 2006 11:03:29 +0000 (GMT) (envelope-from conrads@cox.net) Received: from serene.no-ip.org ([68.14.59.177]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060402110326.QPGW3988.eastrmmtao01.cox.net@serene.no-ip.org>; Sun, 2 Apr 2006 07:03:26 -0400 Received: from localhost (localhost [127.0.0.1]) by serene.no-ip.org (8.13.6/8.13.6) with SMTP id k32B3TXP002941; Sun, 2 Apr 2006 06:03:29 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sun, 2 Apr 2006 06:03:23 -0500 From: "Conrad J. Sabatier" To: John Baldwin Message-Id: <20060402060323.cbe762a7.conrads@cox.net> In-Reply-To: <200603290842.40970.jhb@freebsd.org> References: <20060329020527.f8f087a4.conrads@cox.net> <200603290842.40970.jhb@freebsd.org> X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.8.16; amd64-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: device atpic to be deprecated? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 11:03:30 -0000 On Wed, 29 Mar 2006 08:42:40 -0500 John Baldwin wrote: > On Wednesday 29 March 2006 03:05 am, Conrad J. Sabatier wrote: > > While searching the mailing lists recently on an unrelated subject, I > > happened across a message mentioning the intended removal of "device atpic" > > in 7.0. So, I tried building a kernel without it on my RELENG_6 amd64 box > > (nVidia nForce 3 chipset) and discovered that it was unable to mount the > > root slice. > > > > Naturally, I'm a little concerned about this. :-) > > Some more details would be handy. :) Is your machine UP or SMP? It's a uniprocessor box: FreeBSD 6.1-PRERELEASE #4: Fri Mar 31 18:42:21 CST 2006 conrads@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (1995.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf4a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 1073479680 (1023 MB) avail memory = 1026379776 (978 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 (...) > > Is the plan still in effect to abolish this device? > > Yes, if it works for folks. I'll do a few more test kernels in the days to come after each cvsup and see if this problem persists, or if it may even turn out to have been something completely unrelated. Thanks for the interest. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 11:07:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16BD216A427; Sun, 2 Apr 2006 11:07:49 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao04.cox.net (eastrmmtao04.cox.net [68.230.240.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A5643D70; Sun, 2 Apr 2006 11:07:42 +0000 (GMT) (envelope-from conrads@cox.net) Received: from serene.no-ip.org ([68.14.59.177]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060402110739.RZOE19943.eastrmmtao04.cox.net@serene.no-ip.org>; Sun, 2 Apr 2006 07:07:39 -0400 Received: from localhost (localhost [127.0.0.1]) by serene.no-ip.org (8.13.6/8.13.6) with SMTP id k32B7dTm004124; Sun, 2 Apr 2006 06:07:39 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sun, 2 Apr 2006 06:07:34 -0500 From: "Conrad J. Sabatier" To: John Baldwin Message-Id: <20060402060734.0cc8fdd0.conrads@cox.net> In-Reply-To: <200603291315.56671.jhb@freebsd.org> References: <20060329020527.f8f087a4.conrads@cox.net> <200603291157.54467.jhb@freebsd.org> <442ABF1B.5040305@samsco.org> <200603291315.56671.jhb@freebsd.org> X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.8.16; amd64-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bms@spc.org, freebsd-current@freebsd.org Subject: Re: device atpic to be deprecated? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 11:07:49 -0000 On Wed, 29 Mar 2006 13:15:54 -0500 John Baldwin wrote: > On Wednesday 29 March 2006 12:08, Scott Long wrote: > > John Baldwin wrote: > > > > > > I think that once the lapic timer stuff was added almost all of the APIC > > > issues I was aware of went away on amd64 that were fixed by using device > > > atpic instead. Most of the earlier problems were due to chipsets not > > > setting up pin 0 as extint, etc. but all that is no longer relevant when > > > we switched to using the lapic timer and stopped using irq0 and irq8 with > > > APIC. This is the first I've heard since the lapic timer stuff that APIC > > > didn't work on an amd64 box, and device atpic has been off by default in > > > HEAD for quite a while now. If we were able to require APIC on amd64, then > > > we might be able to try out some optimizations and other things I haven't > > > bothered with since they wouldn't be feasible on i386. > > > > > > > Fine, remove it. > > I have to make sure it really works for everyone first though before > removing it would really be viable. :-/ So, would it be necessary to upgrade to HEAD in order to make sure that this problem won't still occur on my box? Or has this stuff already been merged to STABLE? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 12:32:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06CCD16A422 for ; Sun, 2 Apr 2006 12:32:06 +0000 (UTC) (envelope-from tobias.svehagen@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47EDF43D4C for ; Sun, 2 Apr 2006 12:32:05 +0000 (GMT) (envelope-from tobias.svehagen@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1297597nzf for ; Sun, 02 Apr 2006 05:32:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iXYU+GcYQfmjxDyvJYO1JrPMRmrF7JEr6feRd1TDRLEeGKRbeAwLRm412XPQObCoasM3RX6K9gLhAH+86Msh2cHmas503QPILEZvhPkeP/ufs485yK8Qw1Zu++R4MaVI5OWUMwyynDW+X58v8QLaRx1264s/acL2gxmdA96JkDQ= Received: by 10.35.37.18 with SMTP id p18mr92404pyj; Sun, 02 Apr 2006 05:32:04 -0700 (PDT) Received: by 10.35.28.7 with HTTP; Sun, 2 Apr 2006 05:32:04 -0700 (PDT) Message-ID: Date: Sun, 2 Apr 2006 14:32:04 +0200 From: "Tobias Svehagen" To: freebsd-current@freebsd.org, tjr@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: About gnu/93629 : GNU sort(1) tool dumps core within non-regular locale settings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 12:32:06 -0000 I saw that this issue was on the todo list for 6.1R so I decided to take a look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D93629 As it says in the report you can recreate the abort by doing the following setenv LANG uk_UA.KOI8-U setenv LC_CTYPE ja_JP.UTF-8 /usr/bin/sort This is quite a weird problem and the it lies in that sort tries to handle the LC_TIME values in inittables_mb() thinking that they are in UTF format. The LC_TIME values for uk_UA.KOI8-U does not use UTF encoding but it uses NONE as encoding. Normally this wouldn't be a problem since the multibyte routines handle normal ascii values <=3D 7f just fine and that's why sort works fine when setting LANG to C for example (since Jan-Dec has no ascii > 7f). The thing about uk_UA.KOI8-U (and some others) is that it uses ascii values > 7f to represent the ukrainian alphabet. For example Jan in uk_UA.KOI8-U's LC_TIME is d3 a6 de 00. When you parse that string as UTF, d3 says that it is a multibyte of length 2 and that one works fine (does not trigger the assertion) but then d6 also says that it is a multibyte of length 2 and that makes mbrtowc() return -2 (see man mbrtowc) and that's what makes the assertion go off and abort. I don't know what I think is the best way to solve this but I think that something should be done to make sort not abort and core dump. One solution is of course to make sort check that LC_CTYPE and LC_TIME is the same (or C) but maybe some people want's to have it that way (although I don't see why). Do you have any ideas on how this can be solved in a nice way or do you think that the fix "set LC_CTYPE and LC_TIME to same value" is enough? /Tobias Svehagen From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 18:01:58 2006 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 1522516A420; Sun, 2 Apr 2006 18:01:58 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7475243D48; Sun, 2 Apr 2006 18:01:56 +0000 (GMT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.13.6/8.13.1) with ESMTP id k32I1som014390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2006 20:01:54 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.13.4/8.13.4) with ESMTP id k32I1r2P097888; Sun, 2 Apr 2006 18:01:54 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Sun, 02 Apr 2006 18:01:53 +0000 (UTC) Message-Id: <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> To: peter@holm.cc From: Tor Egge In-Reply-To: <20060402094431.GA81954@peter.osted.lan> References: <20060402094431.GA81954@peter.osted.lan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Apr__2_18:01:53_2006_708)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 18:01:58 -0000 ----Next_Part(Sun_Apr__2_18:01:53_2006_708)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I managed to zoom in on the livelocks I've been seeing lately. According to the console log, process 708 has marked one dependency as being in progress, locked a vnode and then slept waiting for the softdep lock. softdep_flush() doesn't take into account that some of the remaining dependencies cannot be processed at once. Process 45 ended up looping inside softdep_flush(), never sleeping, always believing that more work could be done. The enclosed patch might help. - Tor Egge ----Next_Part(Sun_Apr__2_18:01:53_2006_708)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="softdep.diff2" Index: sys/ufs/ffs/ffs_softdep.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v retrieving revision 1.193 diff -u -r1.193 ffs_softdep.c --- sys/ufs/ffs/ffs_softdep.c 12 Mar 2006 05:25:16 -0000 1.193 +++ sys/ufs/ffs/ffs_softdep.c 2 Apr 2006 17:21:13 -0000 @@ -718,6 +718,7 @@ { struct mount *nmp; struct mount *mp; + struct ufsmount *ump; struct thread *td; int remaining; int vfslocked; @@ -752,7 +753,9 @@ continue; vfslocked = VFS_LOCK_GIANT(mp); softdep_process_worklist(mp, 0); - remaining += VFSTOUFS(mp)->softdep_on_worklist; + ump = VFSTOUFS(mp); + remaining += ump->softdep_on_worklist - + ump->softdep_on_worklist_inprogress; VFS_UNLOCK_GIANT(vfslocked); mtx_lock(&mountlist_mtx); nmp = TAILQ_NEXT(mp, mnt_list); @@ -914,11 +917,13 @@ if ((flags & LK_NOWAIT) == 0 || wk->wk_type != D_DIRREM) break; wk->wk_state |= INPROGRESS; + ump->softdep_on_worklist_inprogress++; FREE_LOCK(&lk); ffs_vget(mp, WK_DIRREM(wk)->dm_oldinum, LK_NOWAIT | LK_EXCLUSIVE, &vp); ACQUIRE_LOCK(&lk); wk->wk_state &= ~INPROGRESS; + ump->softdep_on_worklist_inprogress--; if (vp != NULL) break; } Index: sys/ufs/ufs/ufsmount.h =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufsmount.h,v retrieving revision 1.36 diff -u -r1.36 ufsmount.h --- sys/ufs/ufs/ufsmount.h 8 Mar 2006 23:43:39 -0000 1.36 +++ sys/ufs/ufs/ufsmount.h 2 Apr 2006 17:21:13 -0000 @@ -76,6 +76,7 @@ struct workhead softdep_workitem_pending; /* softdep work queue */ struct worklist *softdep_worklist_tail; /* Tail pointer for above */ int softdep_on_worklist; /* Items on the worklist */ + int softdep_on_worklist_inprogress; /* Busy items on worklist */ int softdep_deps; /* Total dependency count */ int softdep_accdeps; /* accumulated dep count */ int softdep_req; /* Wakeup when deps hits 0. */ ----Next_Part(Sun_Apr__2_18:01:53_2006_708)---- From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 19:09:16 2006 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 85F0616A425 for ; Sun, 2 Apr 2006 19:09:16 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A8F243D60 for ; Sun, 2 Apr 2006 19:09:13 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 7651 invoked from network); 2 Apr 2006 19:09:12 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 2 Apr 2006 19:09:12 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k32J9BCk012980; Sun, 2 Apr 2006 21:09:11 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k32J9Asn012979; Sun, 2 Apr 2006 21:09:10 +0200 (CEST) (envelope-from pho) Date: Sun, 2 Apr 2006 21:09:10 +0200 From: Peter Holm To: Tor Egge Message-ID: <20060402190910.GA12759@peter.osted.lan> References: <20060402094431.GA81954@peter.osted.lan> <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 19:09:16 -0000 On Sun, Apr 02, 2006 at 06:01:53PM +0000, Tor Egge wrote: > > I managed to zoom in on the livelocks I've been seeing lately. > > According to the console log, process 708 has marked one dependency as being in > progress, locked a vnode and then slept waiting for the softdep lock. > > softdep_flush() doesn't take into account that some of the remaining > dependencies cannot be processed at once. > > Process 45 ended up looping inside softdep_flush(), never sleeping, always > believing that more work could be done. > > The enclosed patch might help. > I'm testing it right now. - Peter > - Tor Egge > Index: sys/ufs/ffs/ffs_softdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v > retrieving revision 1.193 > diff -u -r1.193 ffs_softdep.c > --- sys/ufs/ffs/ffs_softdep.c 12 Mar 2006 05:25:16 -0000 1.193 > +++ sys/ufs/ffs/ffs_softdep.c 2 Apr 2006 17:21:13 -0000 > @@ -718,6 +718,7 @@ > { > struct mount *nmp; > struct mount *mp; > + struct ufsmount *ump; > struct thread *td; > int remaining; > int vfslocked; > @@ -752,7 +753,9 @@ > continue; > vfslocked = VFS_LOCK_GIANT(mp); > softdep_process_worklist(mp, 0); > - remaining += VFSTOUFS(mp)->softdep_on_worklist; > + ump = VFSTOUFS(mp); > + remaining += ump->softdep_on_worklist - > + ump->softdep_on_worklist_inprogress; > VFS_UNLOCK_GIANT(vfslocked); > mtx_lock(&mountlist_mtx); > nmp = TAILQ_NEXT(mp, mnt_list); > @@ -914,11 +917,13 @@ > if ((flags & LK_NOWAIT) == 0 || wk->wk_type != D_DIRREM) > break; > wk->wk_state |= INPROGRESS; > + ump->softdep_on_worklist_inprogress++; > FREE_LOCK(&lk); > ffs_vget(mp, WK_DIRREM(wk)->dm_oldinum, > LK_NOWAIT | LK_EXCLUSIVE, &vp); > ACQUIRE_LOCK(&lk); > wk->wk_state &= ~INPROGRESS; > + ump->softdep_on_worklist_inprogress--; > if (vp != NULL) > break; > } > Index: sys/ufs/ufs/ufsmount.h > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ufs/ufsmount.h,v > retrieving revision 1.36 > diff -u -r1.36 ufsmount.h > --- sys/ufs/ufs/ufsmount.h 8 Mar 2006 23:43:39 -0000 1.36 > +++ sys/ufs/ufs/ufsmount.h 2 Apr 2006 17:21:13 -0000 > @@ -76,6 +76,7 @@ > struct workhead softdep_workitem_pending; /* softdep work queue */ > struct worklist *softdep_worklist_tail; /* Tail pointer for above */ > int softdep_on_worklist; /* Items on the worklist */ > + int softdep_on_worklist_inprogress; /* Busy items on worklist */ > int softdep_deps; /* Total dependency count */ > int softdep_accdeps; /* accumulated dep count */ > int softdep_req; /* Wakeup when deps hits 0. */ -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 19:52:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3748216A425; Sun, 2 Apr 2006 19:52:01 +0000 (UTC) (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 758AA43D88; Sun, 2 Apr 2006 19:51:56 +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.4/8.13.4) with ESMTP id k32JoKd4033301; Sun, 2 Apr 2006 13:50:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44302AF5.2040607@samsco.org> Date: Sun, 02 Apr 2006 13:50:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Holger Kipp References: <442EE1D7.90909@samsco.org> <20060402192250.GA29100@intserv.int1.b.intern> In-Reply-To: <20060402192250.GA29100@intserv.int1.b.intern> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: 'FreeBSD Current' , freebsd-stable Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 19:52:01 -0000 Holger Kipp wrote: > On Sat, Apr 01, 2006 at 01:25:59PM -0700, Scott Long wrote: > >>It is my great pleasure and privilege to announce the availability of >>FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN >>months of tireless work by the FreeBSD developers, users, their children, >>and their pets. Significant features in this release: > > > Ah, at last I can upgrade my old 2.2.8 without hassle. A minor note (maybe > I am getting this wrong): my 2.2.8 is from January 1999, so shouldn't this > be 87 months instead of 77? > Yeah, I realized that I screwed up the math after I sent it out. I actually meant 89, since 2.2.8 was officially released in Nov 1998. I think that the CD's were issued a couple of months after that. > >>- - The 8GB barrier in IDE drive sizes has finally been broken. The wd(4) >> driver now supports unimaginable sizes of 137GB on a single drive! > > > Hmm, the 4GB SCSI is still working fine here - and I still have a spare drive > for replacement, but that is good news anyway. > 4GB SCSI drive? You were a big spender at the time =-D > >>A full description of the release can be found here: >> >> ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/README.TXT >> ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/RELNOTES.TXT > > > Looks okay to me. I am still missing support for IBMs Microchannel, though. > Any chance this will be ready for the next release (2.2.10)? Have the MicroChannel patents expired yet? > > Anyway, thanks a lot to all involved for making FreeBSD even better ;-) > > Regards, > Holger > Scott From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 20:48:57 2006 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 75BA916A401; Sun, 2 Apr 2006 20:48:57 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40A7343D53; Sun, 2 Apr 2006 20:48:54 +0000 (GMT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.13.6/8.13.1) with ESMTP id k32KmqGU029007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Apr 2006 22:48:53 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.13.4/8.13.4) with ESMTP id k32KmqtG098988; Sun, 2 Apr 2006 20:48:52 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Sun, 02 Apr 2006 20:48:51 +0000 (UTC) Message-Id: <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> To: peter@holm.cc From: Tor Egge In-Reply-To: <20060402190910.GA12759@peter.osted.lan> References: <20060402094431.GA81954@peter.osted.lan> <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> <20060402190910.GA12759@peter.osted.lan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Apr__2_20:48:51_2006_162)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 0 seconds Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 20:48:57 -0000 ----Next_Part(Sun_Apr__2_20:48:51_2006_162)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > The enclosed patch might help. > > > > I'm testing it right now. Similarly to the softdepflush process looping in softdep_flush(), the process creating a snapshot might loop in ffs_sync(). - Tor Egge ----Next_Part(Sun_Apr__2_20:48:51_2006_162)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="softdep2.diff2" Index: sys/ufs/ffs/ffs_softdep.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v retrieving revision 1.193 diff -u -r1.193 ffs_softdep.c --- sys/ufs/ffs/ffs_softdep.c 12 Mar 2006 05:25:16 -0000 1.193 +++ sys/ufs/ffs/ffs_softdep.c 2 Apr 2006 20:20:15 -0000 @@ -718,6 +718,7 @@ { struct mount *nmp; struct mount *mp; + struct ufsmount *ump; struct thread *td; int remaining; int vfslocked; @@ -752,7 +753,9 @@ continue; vfslocked = VFS_LOCK_GIANT(mp); softdep_process_worklist(mp, 0); - remaining += VFSTOUFS(mp)->softdep_on_worklist; + ump = VFSTOUFS(mp); + remaining += ump->softdep_on_worklist - + ump->softdep_on_worklist_inprogress; VFS_UNLOCK_GIANT(vfslocked); mtx_lock(&mountlist_mtx); nmp = TAILQ_NEXT(mp, mnt_list); @@ -914,11 +917,17 @@ if ((flags & LK_NOWAIT) == 0 || wk->wk_type != D_DIRREM) break; wk->wk_state |= INPROGRESS; + ump->softdep_on_worklist_inprogress++; FREE_LOCK(&lk); ffs_vget(mp, WK_DIRREM(wk)->dm_oldinum, LK_NOWAIT | LK_EXCLUSIVE, &vp); ACQUIRE_LOCK(&lk); wk->wk_state &= ~INPROGRESS; + if (--ump->softdep_on_worklist_inprogress == 0 && + ump->softdep_on_worklist_inprogress_req != 0) { + ump->softdep_on_worklist_inprogress_req = 0; + wakeup(&ump->softdep_on_worklist_inprogress); + } if (vp != NULL) break; } @@ -6099,6 +6108,17 @@ VI_LOCK(devvp); continue; } + if (ump->softdep_on_worklist_inprogress != 0) { + VI_UNLOCK(devvp); + ump->softdep_on_worklist_inprogress_req = 1; + msleep(&ump->softdep_on_worklist_inprogress, + &lk, + (PUSER - 1) | PDROP, + "sdipdr" /* soft dep in progress drain */, + 0); + VI_LOCK(devvp); + continue; + } if (!MNT_ITRYLOCK(mp)) { FREE_LOCK(&lk); VI_UNLOCK(devvp); Index: sys/ufs/ufs/ufsmount.h =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufsmount.h,v retrieving revision 1.36 diff -u -r1.36 ufsmount.h --- sys/ufs/ufs/ufsmount.h 8 Mar 2006 23:43:39 -0000 1.36 +++ sys/ufs/ufs/ufsmount.h 2 Apr 2006 20:20:15 -0000 @@ -76,6 +76,8 @@ struct workhead softdep_workitem_pending; /* softdep work queue */ struct worklist *softdep_worklist_tail; /* Tail pointer for above */ int softdep_on_worklist; /* Items on the worklist */ + int softdep_on_worklist_inprogress; /* Busy items on worklist */ + int softdep_on_worklist_inprogress_req;/* Wakeup when not busy */ int softdep_deps; /* Total dependency count */ int softdep_accdeps; /* accumulated dep count */ int softdep_req; /* Wakeup when deps hits 0. */ ----Next_Part(Sun_Apr__2_20:48:51_2006_162)---- From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 22:37:26 2006 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 D95A516A401 for ; Sun, 2 Apr 2006 22:37:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D7243D67 for ; Sun, 2 Apr 2006 22:37:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4831346B9D for ; Sun, 2 Apr 2006 18:37:21 -0400 (EDT) Date: Sun, 2 Apr 2006 23:37:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20060401170554.R82503@fledge.watson.org> Message-ID: <20060402233436.P76562@fledge.watson.org> References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 22:37:26 -0000 On Sat, 1 Apr 2006, Robert Watson wrote: > On Sat, 1 Apr 2006, Robert Watson wrote: > >> You get to experience the above in the order presented. :-) I will send >> out a follow-up e-mail once the merges have stopped and/or slowed down, >> which will be later today sometime. > > This e-mail is to let you know that the commit spree is over for the day, > with no remaining changes in the rwatson_sockref branch. > > There are likely bugs. You may find them. If you do, please e-mail bug > reports, ideally including any panic messages, stack traces, reproduction > cases, etc, to current@, and I will try to get to them as quickly as > possible. OK, so it's been >24 hours since this was committed, and I've not received any bug reports yet. This means once of three things: (1) There are no bugs. (2) I've broken everyone's systems so badly they can't submit bug reports. (3) Everyone is waiting for everyone else to upgrade due to the advance notice of instability. I consider (1) highly likely, (2) a property of 1990's development and we've left that time since most people have multiple machines now, and (3) much more likely. Please help test these changes! I leave for a trip to the US on Thursday, and I'd rather get things working before I leave than while on travel, it will save a lot of hassle for everyone. And if you're reading this after spending 48 hours getting your systems working again to the point where you can read e-mail, sorry :-). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 22:46:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B562916A400 for ; Sun, 2 Apr 2006 22:46:27 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id D383543D62 for ; Sun, 2 Apr 2006 22:46:20 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id D46E3D458B5 for ; Sun, 2 Apr 2006 18:46:18 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Sun, 02 Apr 2006 18:46:14 -0400 X-Sasl-enc: Kk4v9bVodz+fc/dZNEiGT7swZD586GYNbI1+zbC4leiL 1144017974 Received: from [192.168.193.165] (unknown [12.176.108.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id 2331C38D for ; Sun, 2 Apr 2006 18:46:12 -0400 (EDT) Message-ID: <44305439.8080703@fastmail.fm> Date: Sun, 02 Apr 2006 17:46:17 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> <20060402233436.P76562@fledge.watson.org> In-Reply-To: <20060402233436.P76562@fledge.watson.org> Content-Type: multipart/mixed; boundary="------------050007090204050100080107" Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 22:46:27 -0000 This is a multi-part message in MIME format. --------------050007090204050100080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: > > On Sat, 1 Apr 2006, Robert Watson wrote: > >> On Sat, 1 Apr 2006, Robert Watson wrote: >> >>> You get to experience the above in the order presented. :-) I will >>> send out a follow-up e-mail once the merges have stopped and/or >>> slowed down, which will be later today sometime. >> >> >> This e-mail is to let you know that the commit spree is over for the >> day, with no remaining changes in the rwatson_sockref branch. >> >> There are likely bugs. You may find them. If you do, please e-mail >> bug reports, ideally including any panic messages, stack traces, >> reproduction cases, etc, to current@, and I will try to get to them >> as quickly as possible. > > > OK, so it's been >24 hours since this was committed, and I've not > received any bug reports yet. This means once of three things: > > (1) There are no bugs. > > (2) I've broken everyone's systems so badly they can't submit bug > reports. > > (3) Everyone is waiting for everyone else to upgrade due to the > advance notice > of instability. > > I consider (1) highly likely, (2) a property of 1990's development and > we've left that time since most people have multiple machines now, and > (3) much more likely. > > Please help test these changes! I leave for a trip to the US on > Thursday, and I'd rather get things working before I leave than while > on travel, it will save a lot of hassle for everyone. > > And if you're reading this after spending 48 hours getting your > systems working again to the point where you can read e-mail, sorry :-). > > Robert N M Watson > _______________________________________________ > 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" > Mr. Watson; I updated last night and have been using my laptop all day with no problems (linux-mozilla for email and web). You do good work! I included my last dmesg(8) just FYI. Thanks, Patrick --------------050007090204050100080107 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2006 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 #1: Sat Apr 1 21:34:55 CST 2006 pbowen@sg1.sgc.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. 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 = 515604480 (491 MB) kbd1 at kbdmux0 npx0: [FAST] 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 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xecff mem 0xf8000000-0xfbffffff,0xfdffc000-0xfdffffff irq 11 at device 0.0 on pci1 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 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 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: xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffdc00-0xf3ffdc7f,0xf3ffd800-0xf3ffd87f 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 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 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 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 601366025 Hz quality 800 Timecounters tick every 1.000 msec Interrupt storm detected on "irq11:"; throttling interrupt source cardbus1: at device 0.0 (no driver attached) ad0: 19077MB at ata0-master UDMA33 acd0: CDRW at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a cpu0: too many short sleeps, backing off to C1 ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus1 ath0: Ethernet address: 00:13:46:b6:19:ea ath0: mac 7.8 phy 4.5 radio 5.6 ath0: link state changed to UP cpu0: too many short sleeps, backing off to C1 --------------050007090204050100080107-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 23:03:13 2006 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 7342316A420; Sun, 2 Apr 2006 23:03:13 +0000 (UTC) (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 2180443D46; Sun, 2 Apr 2006 23:03:13 +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 k32N3C4C090488; Sun, 2 Apr 2006 16:03:12 -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 k32N3CAo090487; Sun, 2 Apr 2006 16:03:12 -0700 (PDT) (envelope-from sgk) Date: Sun, 2 Apr 2006 16:03:12 -0700 From: Steve Kargl To: Robert Watson Message-ID: <20060402230312.GA90457@troutmask.apl.washington.edu> References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> <20060402233436.P76562@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402233436.P76562@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 23:03:13 -0000 On Sun, Apr 02, 2006 at 11:37:21PM +0100, Robert Watson wrote: > > On Sat, 1 Apr 2006, Robert Watson wrote: > > >On Sat, 1 Apr 2006, Robert Watson wrote: > > > >>You get to experience the above in the order presented. :-) I will send > >>out a follow-up e-mail once the merges have stopped and/or slowed down, > >>which will be later today sometime. > > > >This e-mail is to let you know that the commit spree is over for the day, > >with no remaining changes in the rwatson_sockref branch. > > > >There are likely bugs. You may find them. If you do, please e-mail bug > >reports, ideally including any panic messages, stack traces, reproduction > >cases, etc, to current@, and I will try to get to them as quickly as > >possible. > > OK, so it's been >24 hours since this was committed, and I've not received > any bug reports yet. This means once of three things: > > (1) There are no bugs. > > (2) I've broken everyone's systems so badly they can't submit bug reports. > > (3) Everyone is waiting for everyone else to upgrade due to the advance > notice of instability. (4) The last 2 days of cvs commit emails has never arrived, here. So, perhaps, users don't know you've completed the commits. :-) -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 23:40:13 2006 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 556EC16A401 for ; Sun, 2 Apr 2006 23:40:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECCEB43D45 for ; Sun, 2 Apr 2006 23:40:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4882A46B52; Sun, 2 Apr 2006 19:40:12 -0400 (EDT) Date: Mon, 3 Apr 2006 00:40:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Birrell In-Reply-To: <20060402230012.GA24758@what-creek.com> Message-ID: <20060403003428.X76562@fledge.watson.org> References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> <20060402233436.P76562@fledge.watson.org> <20060402230012.GA24758@what-creek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 23:40:13 -0000 On Sun, 2 Apr 2006, John Birrell wrote: > I've just updated a current system which also serves as a (socket based) > backup system for a remotely hosted web site with LOTS of file updates. The > update went without a hitch and the system seems to work fine AFAICT. > > I guess that sounds like a bit of an anti-climax, but there really isn't > anything to report. Sorry. 8-) > > Perhaps I just don't know what to look for. Shrug. Well, other than the normal array of panics and bad network behavior, I'm particularly interested in possible memory leaks in the TCP and socket code. Generally speaking, I find the following useful for keeping an eye on it: vmstat -z | head -1 ; vmstat -z | grep -i tcp ; vmstat -z | grep -i socket Of course, because a lot of events and tear-downs in the network stack are asynchronous anyway, you have to watch for the leaks over a longer run time rather than the short term. Finally, I had some reports of additional connection resets from Kris during his testing, which may be tricky to track down if they still exist. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 01:27:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FC716A401 for ; Mon, 3 Apr 2006 01:27:31 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from ngwee.ugcs.caltech.edu (ngwee.ugcs.caltech.edu [131.215.176.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B6B43D53 for ; Mon, 3 Apr 2006 01:27:30 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by ngwee.ugcs.caltech.edu (Postfix, from userid 3640) id 58FC6CC065; Sun, 2 Apr 2006 18:27:30 -0700 (PDT) Date: Sun, 2 Apr 2006 18:27:30 -0700 From: Paul Allen To: "Marc G. Fournier" Message-ID: <20060403012730.GJ5929@ngwee.ugcs.caltech.edu> References: <20060402163504.T947@ganymede.hub.org> <25422.1144016604@sss.pgh.pa.us> <25526.1144017388@sss.pgh.pa.us> <20060402213921.V947@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402213921.V947@ganymede.hub.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org Subject: Re: [HACKERS] semaphore usage "port based"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 01:27:31 -0000 What happened to pjd's patches to make the ipc space per jail? re: kern/48471 From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 08:26:28 2006 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 180DE16A420 for ; Mon, 3 Apr 2006 08:26:28 +0000 (UTC) (envelope-from nikruzhan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D521243D5C for ; Mon, 3 Apr 2006 08:26:26 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1505823nzf for ; Mon, 03 Apr 2006 01:26:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GTwG7SmIth4gYnCJZqsshvx8+Kce4ABCe9L912alq9IeU41Yn2rXDu29/VLK5FOeSpUT7PBjoxe4DxtQatbJfnDLsnYvj/vrvKYO0SasCUgmSb+qmJF08VjtJSLgdSTkDU43kJc5WDp4G5JbOhkQtrlnB0OCnJTmTPJjnBMotcU= Received: by 10.35.39.2 with SMTP id r2mr939614pyj; Mon, 03 Apr 2006 01:26:26 -0700 (PDT) Received: by 10.35.92.9 with HTTP; Mon, 3 Apr 2006 01:26:26 -0700 (PDT) Message-ID: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> Date: Mon, 3 Apr 2006 16:26:26 +0800 From: Nik To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 08:26:28 -0000 Hi all, I got four FreeBSD router and two of them using FreeBSD 6.1 Prerelease and quagga 0.99.3 and the other two is using FreeBSD 5.4 with quagga 0.98.5. I try to implement IBGP session in this 4 router and I encounter this problem when activate the IBGP; Info: 1) Two router is a Core - each has different version of OS and Quagga 2) Two router is a Distribution -each has different version of OS and Quagg= a BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 BGP: can't set sockopt TCP_MD5SIG 0 to socket 15 BGP: can't set sockopt TCP_MD5SIG 0 to socket 18 FYI, I've already compile quagga with MD5 patch for BGP. Thanks a lot. From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 08:39:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE71716A401; Mon, 3 Apr 2006 08:39:42 +0000 (UTC) (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 B1A7943D4C; Mon, 3 Apr 2006 08:39:41 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQKgP-000CEP-03; Mon, 03 Apr 2006 17:45:12 +0900 Message-ID: <4430DF4E.1060600@micom.mng.net> Date: Mon, 03 Apr 2006 17:39:42 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@FreeBSD.org Subject: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 08:39:42 -0000 Hi, I've got page fault on today's CURRENT. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa0 fault code = supervisor write, page not present instructon pointer = 0x20: 0xc062bbde stack pointer = 0x28: 0xcc8efc10 frame pointer = 0x28: 0xcc8efc2c 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 = 435 (smbd) [thread pid 435 tid 100039] stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) I'm running samba (samba-3.0.21b,1) on this test machine and there is no load. FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon Apr 3 14:15:48 ULAST 2006 tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 Ganbold From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:07:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0097F16A420 for ; Mon, 3 Apr 2006 09:07:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABCB843D45 for ; Mon, 3 Apr 2006 09:07:36 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 135CD46B89; Mon, 3 Apr 2006 05:07:36 -0400 (EDT) Date: Mon, 3 Apr 2006 10:07:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ganbold In-Reply-To: <4430DF4E.1060600@micom.mng.net> Message-ID: <20060403100516.C76562@fledge.watson.org> References: <4430DF4E.1060600@micom.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:07:37 -0000 On Mon, 3 Apr 2006, Ganbold wrote: > I've got page fault on today's CURRENT. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa0 > fault code = supervisor write, page not > present > instructon pointer = 0x20: 0xc062bbde > stack pointer = 0x28: 0xcc8efc10 > frame pointer = 0x28: 0xcc8efc2c > 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 = 435 (smbd) > [thread pid 435 tid 100039] > stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) > > I'm running samba (samba-3.0.21b,1) on this test machine and there is no > load. > > FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon Apr 3 > 14:15:48 ULAST 2006 tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 Is there any chance you can extract a stack trace, as well as file names and line numbers for the trace? If you have a core, could I get you to dump the state from the relevant frames? The above looks like a NULL pointer derefernece in tcp_usr_accept(). Since I've moderately exercised the accept() path on TCP, it's presumably a race condition of some sort. Thanks! Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:11:16 2006 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 C7C9F16A400 for ; Mon, 3 Apr 2006 09:11:16 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53C6043D46 for ; Mon, 3 Apr 2006 09:11:15 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 60A7A62B9; Mon, 3 Apr 2006 11:11:05 +0200 (CEST) Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 76771-03-5; Mon, 3 Apr 2006 11:11:04 +0200 (CEST) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 7391062A3; Mon, 3 Apr 2006 11:11:04 +0200 (CEST) From: Thomas To: Nik In-Reply-To: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> Content-Type: text/plain Date: Mon, 03 Apr 2006 11:11:08 +0200 Message-Id: <1144055468.15377.12.camel@bert.mlan.solnet.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 SolNet.ch ISP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:11:16 -0000 Am Montag, den 03.04.2006, 16:26 +0800 schrieb Nik: > Hi all, > > I got four FreeBSD router and two of them using FreeBSD 6.1 Prerelease and > quagga 0.99.3 and the other two is using FreeBSD 5.4 with quagga 0.98.5. I > try to implement IBGP session in this 4 router and I encounter this problem > when activate the IBGP; > > Info: > 1) Two router is a Core - each has different version of OS and Quagga > 2) Two router is a Distribution -each has different version of OS and Quagga > > BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 > BGP: can't set sockopt TCP_MD5SIG 0 to socket 15 > BGP: can't set sockopt TCP_MD5SIG 0 to socket 18 > > FYI, I've already compile quagga with MD5 patch for BGP. Thanks a lot. Use this kernel options: # quagga needs this for MD5 passwords on BGP sessions options TCP_SIGNATURE options FAST_IPSEC device crypto device cryptodev Regards, Thomas PS: This is a question for freebsd-net@ rather than current@ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:53:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54E8916A429; Mon, 3 Apr 2006 09:53:07 +0000 (UTC) (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 E7DDB43D5A; Mon, 3 Apr 2006 09:53:02 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQLpc-000DUC-MH; Mon, 03 Apr 2006 18:58:45 +0900 Message-ID: <4430F08E.5080602@micom.mng.net> Date: Mon, 03 Apr 2006 18:53:18 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Robert Watson References: <4430DF4E.1060600@micom.mng.net> <20060403100516.C76562@fledge.watson.org> In-Reply-To: <20060403100516.C76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:53:08 -0000 Robert Watson wrote: > > On Mon, 3 Apr 2006, Ganbold wrote: > >> I've got page fault on today's CURRENT. >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0xa0 >> fault code = supervisor write, >> page not present >> instructon pointer = 0x20: 0xc062bbde >> stack pointer = 0x28: 0xcc8efc10 >> frame pointer = 0x28: 0xcc8efc2c >> 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 = 435 (smbd) >> [thread pid 435 tid 100039] >> stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) >> >> I'm running samba (samba-3.0.21b,1) on this test machine and there is >> no load. >> >> FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon >> Apr 3 14:15:48 ULAST 2006 >> tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 > > Is there any chance you can extract a stack trace, as well as file > names and line numbers for the trace? If you have a core, could I get > you to dump the state from the relevant frames? The above looks like > a NULL pointer derefernece in tcp_usr_accept(). Since I've moderately > exercised the accept() path on TCP, it's presumably a race condition > of some sort. When I try to browse samba directory from network, above error occurs and the trace is: db>trace Tracing pid 1051 tid 100053 td 0xc224fbd0 tcp_usr_accept(c23d167c,cc916c54,cc916c58,cc916c7c,c05a8398) at tcp_usr_accept+0xd6 soaccept(c23d176c,cc916c54,c24f5300,0,0) at soaccept+0x7d accept1(c224fbd0,cc916d04,0,cc916d30,c06da93e) at accept1+0x458 accept(c224fbd0, cc916d04,3,246,c077bce8) at accept+0x10 syscall(849003b,849003b,bfbf003b,0,15) at syscall+0x2ee Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (30, FreeBSD ELF32, accept), eip = 0x28715a33, esp = 0xbfbfd91c, ebp = 0xbfbfec28 --- Ganbold > > Thanks! > > Robert N M Watson > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:54:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE9116A41F for ; Mon, 3 Apr 2006 09:54:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00B1843D48 for ; Mon, 3 Apr 2006 09:54:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 01F8D46C32; Mon, 3 Apr 2006 05:54:01 -0400 (EDT) Date: Mon, 3 Apr 2006 10:54:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ganbold In-Reply-To: <4430DF4E.1060600@micom.mng.net> Message-ID: <20060403105231.D76562@fledge.watson.org> References: <4430DF4E.1060600@micom.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:54:02 -0000 On Mon, 3 Apr 2006, Ganbold wrote: > I've got page fault on today's CURRENT. After looking at tcp_usr_accept(), I certainly see *a* bug, which might be the one you've run into. I've committed what I believe is the fix as tcp_usrreq.c:1.134. Could you pull that down and see if life gets better? Basically, there was erroneous handling of a connection that has been disconnected while sitting in the accept queue before the application manages to call accept() on it (indeed, a race). Robert N M Watson > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa0 > fault code = supervisor write, page not > present > instructon pointer = 0x20: 0xc062bbde > stack pointer = 0x28: 0xcc8efc10 > frame pointer = 0x28: 0xcc8efc2c > 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 = 435 (smbd) > [thread pid 435 tid 100039] > stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) > > I'm running samba (samba-3.0.21b,1) on this test machine and there is no > load. > > FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon Apr 3 > 14:15:48 ULAST 2006 tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 > > Ganbold > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:55:59 2006 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 E697816A41F for ; Mon, 3 Apr 2006 09:55:59 +0000 (UTC) (envelope-from nikruzhan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E9143D53 for ; Mon, 3 Apr 2006 09:55:57 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1525492nzf for ; Mon, 03 Apr 2006 02:55:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=h+Wfy+IjUDNuNdZ9TGDNTxNOuQchbamoJSu0DT52jW5xTcZFe+7Y0iEVRiIASrAbZiBdYhQAWgmj4OFbehxro2KCF8JMCSS7n7hoRMEZnyVpSw1vggObKi6XbLX4lwn32BXqYEbP91rPAifP2SeCqB5vUkGiX6zCm/OMvSXwfe4= Received: by 10.35.96.11 with SMTP id y11mr1632088pyl; Mon, 03 Apr 2006 02:55:56 -0700 (PDT) Received: by 10.35.92.9 with HTTP; Mon, 3 Apr 2006 02:55:56 -0700 (PDT) Message-ID: <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> Date: Mon, 3 Apr 2006 17:55:56 +0800 From: Nik To: Thomas In-Reply-To: <1144055468.15377.12.camel@bert.mlan.solnet.ch> MIME-Version: 1.0 References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> <1144055468.15377.12.camel@bert.mlan.solnet.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:56:00 -0000 I'm curious why I need to enable MD5 because in my system I don't use any authentication method. Is there any way to off the parameter. Also I notice that vlan in FreeBSD is not fully trunk. Examples ; vlan 1000 : 192.168.0.1/26 connect to L2 switch and untag certain port to connect to PC. I still can use internet when I set that PC to use this IP; IP =3D 192.168.0.5/24 Gateway =3D 192.168.0.1/24 Is there any options that I need to put in kernel to prevent thing like thi= s happen. On 4/3/06, Thomas wrote: > > Am Montag, den 03.04.2006, 16:26 +0800 schrieb Nik: > > Hi all, > > > > I got four FreeBSD router and two of them using FreeBSD 6.1 Prerelease > and > > quagga 0.99.3 and the other two is using FreeBSD 5.4 with quagga 0.98.5= . > I > > try to implement IBGP session in this 4 router and I encounter this > problem > > when activate the IBGP; > > > > Info: > > 1) Two router is a Core - each has different version of OS and Quagga > > 2) Two router is a Distribution -each has different version of OS and > Quagga > > > > BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 > > BGP: can't set sockopt TCP_MD5SIG 0 to socket 15 > > BGP: can't set sockopt TCP_MD5SIG 0 to socket 18 > > > > FYI, I've already compile quagga with MD5 patch for BGP. Thanks a lot. > > Use this kernel options: > # quagga needs this for MD5 passwords on BGP sessions > options TCP_SIGNATURE > options FAST_IPSEC > device crypto > device cryptodev > > Regards, > Thomas > > PS: This is a question for freebsd-net@ rather than current@ > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 09:57:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53E4516A41F; Mon, 3 Apr 2006 09:57:40 +0000 (UTC) (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 359B943D68; Mon, 3 Apr 2006 09:57:34 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQLu2-000DZt-7i; Mon, 03 Apr 2006 19:03:18 +0900 Message-ID: <4430F19F.9020602@micom.mng.net> Date: Mon, 03 Apr 2006 18:57:51 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Robert Watson References: <4430DF4E.1060600@micom.mng.net> <20060403105231.D76562@fledge.watson.org> In-Reply-To: <20060403105231.D76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 09:57:40 -0000 Robert Watson wrote: > > On Mon, 3 Apr 2006, Ganbold wrote: > >> I've got page fault on today's CURRENT. > > After looking at tcp_usr_accept(), I certainly see *a* bug, which > might be the one you've run into. I've committed what I believe is > the fix as tcp_usrreq.c:1.134. Could you pull that down and see if > life gets better? > > Basically, there was erroneous handling of a connection that has been > disconnected while sitting in the accept queue before the application > manages to call accept() on it (indeed, a race). I see, I'll try it tomorrow and let you know if there is anything. thanks, Ganbold > > Robert N M Watson > >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0xa0 >> fault code = supervisor write, >> page not present >> instructon pointer = 0x20: 0xc062bbde >> stack pointer = 0x28: 0xcc8efc10 >> frame pointer = 0x28: 0xcc8efc2c >> 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 = 435 (smbd) >> [thread pid 435 tid 100039] >> stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) >> >> I'm running samba (samba-3.0.21b,1) on this test machine and there is >> no load. >> >> FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon >> Apr 3 14:15:48 ULAST 2006 >> tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 >> >> Ganbold >> >> >> > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 10:15:24 2006 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 0D67916A426 for ; Mon, 3 Apr 2006 10:15:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5609843D86 for ; Mon, 3 Apr 2006 10:15:07 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail15.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k33AF5YP026329 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 3 Apr 2006 20:15:05 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k33AF4FF001392; Mon, 3 Apr 2006 20:15:04 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k33AF4Zl001391; Mon, 3 Apr 2006 20:15:04 +1000 (EST) (envelope-from peter) Date: Mon, 3 Apr 2006 20:15:04 +1000 From: Peter Jeremy To: Nik Message-ID: <20060403101504.GB683@turion.vk2pj.dyndns.org> References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> <1144055468.15377.12.camel@bert.mlan.solnet.ch> <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 10:15:24 -0000 On Mon, 2006-Apr-03 17:55:56 +0800, Nik wrote: >I'm curious why I need to enable MD5 because in my system I don't use any >authentication method. Is there any way to off the parameter. Also I notice >that vlan in FreeBSD is not fully trunk. > >Examples ; > >vlan 1000 : 192.168.0.1/26 > >connect to L2 switch and untag certain port to connect to PC. I still can >use internet when I set that PC to use this IP; > >IP = 192.168.0.5/24 >Gateway = 192.168.0.1/24 I use VLAN trunks extensively in FreeBSD and have no problems with them (I've had more problems with broken VLAN implementations in switches). Can you detail exactly what your interface configuration is and what commands your are issuing that aren't working as expected. Have you looked at the network traffic using (eg) tcpdump. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 10:42:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC89B16A400 for ; Mon, 3 Apr 2006 10:42:28 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip8.gate01.com [61.122.117.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545C743D48 for ; Mon, 3 Apr 2006 10:42:27 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop11.isp.us-com.jp with esmtp (Mail 4.20) id 1FQMVu-0005UK-Np for freebsd-current@freebsd.org; Mon, 03 Apr 2006 19:42:26 +0900 Message-ID: <4430FAAF.2040809@highway.ne.jp> Date: Mon, 03 Apr 2006 19:36:31 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 10:42:28 -0000 Hi, I got a panic on -CURRENT. [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". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0718779 stack pointer = 0x28:0xd4422b74 frame pointer = 0x28:0xd4422b80 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 = 14 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 38s Dumping 510 MB (2 chunks) chunk 0: 1MB (158 pages) ... ok chunk 1: 510MB (130544 pages) 494 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 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc066f05e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc066f385 in panic (fmt=0xc088dde3 "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc083c9b0 in trap_fatal (frame=0xd4422b34, eva=8) at /usr/src/sys/i386/i386/trap.c:870 #4 0xc083c6ef in trap_pfault (frame=0xd4422b34, usermode=0, eva=8) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc083c305 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1012600796, tf_esi = 0, tf_ebp = -733860992, tf_isp = -733861024, tf_ebx = 2, tf_edx = -998501728, tf_ecx = 0, tf_eax = 1498072816, tf_trapno = 12, tf_err = 0, tf_eip = -1066301575, tf_cs = 32, tf_eflags = 66050, tf_esp = -998501728, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc082836a in calltrap () at /usr/src/sys/i386/i386/exception.s:137 #7 0xc0718779 in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3a4f024, m=0xc3a27400, tlen=0) at /usr/src/sys/netinet/tcp_input.c:3202 #8 0xc07159d8 in tcp_input (m=0xc3a27400, off0=20) at /usr/src/sys/netinet/tcp_input.c:763 #9 0xc070ee01 in ip_input (m=0xc3a27400) at /usr/src/sys/netinet/ip_input.c:656 #10 0xc06eb92f in netisr_processqueue (ni=0xc0971d18) at /usr/src/sys/net/netisr.c:236 #11 0xc06ebb2e in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #12 0xc0659e65 in ithread_execute_handlers (p=0xc32fd468, ie=0xc333f100) at /usr/src/sys/kern/kern_intr.c:662 #13 0xc0659f85 in ithread_loop (arg=0xc32dc840) at /usr/src/sys/kern/kern_intr.c:745 #14 0xc0658d7d in fork_exit (callout=0xc0659f30 , arg=0xc32dc840, frame=0xd4422d38) at /usr/src/sys/kern/kern_fork.c:819 #15 0xc08283cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:198 (kgdb) -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 12:10:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B03E16A400 for ; Mon, 3 Apr 2006 12:10:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEE7943D45 for ; Mon, 3 Apr 2006 12:10:05 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQNsi-000CDl-SB for freebsd-current@freebsd.org; Mon, 03 Apr 2006 12:10:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQNsf-0002Jw-QJ for freebsd-current@freebsd.org; Mon, 03 Apr 2006 20:10:01 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17457.4249.383686.765032@roam.psg.com> Date: Mon, 3 Apr 2006 20:10:01 +0800 To: FreeBSD Current Subject: natd when doubled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 12:10:06 -0000 i am in a hotel which gives me an address from 10/8 on the ether. i have it plugged into em0 on a -current system. i have another machine on wireless out the ath0 port which is configured as 192.168.0.1 my natd.conf is dynamic yes unregistered_only yes interface em0 my ipfw.rules sez add divert natd all from 192.168.0.0/24 to any via em0 add divert natd all from any to 192.168.0.0/24 via ath0 i suspect the latter two are a bit too clever the two machines can ping eachother over the wireless. but nat is just not doing it. hit me with he clue bat, please randy From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 12:39:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8644716A42F for ; Mon, 3 Apr 2006 12:39:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 293A843D48 for ; Mon, 3 Apr 2006 12:39:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DFE1446BC7; Mon, 3 Apr 2006 08:39:08 -0400 (EDT) Date: Mon, 3 Apr 2006 13:39:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kazuaki Oda In-Reply-To: <4430FAAF.2040809@highway.ne.jp> Message-ID: <20060403133210.U36756@fledge.watson.org> References: <4430FAAF.2040809@highway.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 12:39:10 -0000 On Mon, 3 Apr 2006, Kazuaki Oda wrote: ... > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 This is a NULL pointer dereference. > #6 0xc082836a in calltrap () at /usr/src/sys/i386/i386/exception.s:137 > #7 0xc0718779 in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3a4f024, m=0xc3a27400, tlen=0) at /usr/src/sys/netinet/tcp_input.c:3202 > #8 0xc07159d8 in tcp_input (m=0xc3a27400, off0=20) at /usr/src/sys/netinet/tcp_input.c:763 Since you have a kernel dump, could I ask you to print the following in the tcp_input frame using kgdb: p inp p *inp p *inp->inp_socket p *inp->inp_ppcb In the tcp_timewait frame, could you print the following: p tw p *tw p *to p *th Also, are you running with INVARIANTS and/or WITNESS? It looks a lot like the inp->inp_ppcb pointer is NULL while the inpcb lock is held, meaning that some of the above commands should fail, but This Should Never Happen. It looks like I have a bug in tcp_twclose() which allows the socket and inpcb to persist with the inp_ppcb pointer NULL, which I'll investigate now. Having the additional debugging output would help confirm this is the cause, and hopefully I'll have a fix in a few hours. Thanks, Robert N M Watson > #9 0xc070ee01 in ip_input (m=0xc3a27400) at /usr/src/sys/netinet/ip_input.c:656 > #10 0xc06eb92f in netisr_processqueue (ni=0xc0971d18) at /usr/src/sys/net/netisr.c:236 > #11 0xc06ebb2e in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 > #12 0xc0659e65 in ithread_execute_handlers (p=0xc32fd468, ie=0xc333f100) at /usr/src/sys/kern/kern_intr.c:662 > #13 0xc0659f85 in ithread_loop (arg=0xc32dc840) at /usr/src/sys/kern/kern_intr.c:745 > #14 0xc0658d7d in fork_exit (callout=0xc0659f30 , arg=0xc32dc840, frame=0xd4422d38) at /usr/src/sys/kern/kern_fork.c:819 > #15 0xc08283cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:198 > (kgdb) > > -- > Kazuaki Oda > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 12:59:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D724916A401; Mon, 3 Apr 2006 12:59:15 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip8.gate01.com [61.122.117.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7A5243D69; Mon, 3 Apr 2006 12:59:06 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop11.isp.us-com.jp with esmtp (Mail 4.20) id 1FQOe9-0002J5-8f; Mon, 03 Apr 2006 21:59:05 +0900 Message-ID: <44311AB5.2010407@highway.ne.jp> Date: Mon, 03 Apr 2006 21:53:09 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> In-Reply-To: <20060403133210.U36756@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 12:59:15 -0000 Robert Watson wrote: > Since you have a kernel dump, could I ask you to print the following in > the tcp_input frame using kgdb: > > p inp > p *inp > p *inp->inp_socket > p *inp->inp_ppcb (kgdb) frame 8 #8 0xc07159d8 in tcp_input (m=0xc3a27400, off0=20) at /usr/src/sys/netinet/tcp_input.c:763 763 if (tcp_timewait((struct tcptw *)inp->inp_ppcb, (kgdb) p inp $1 = (struct inpcb *) 0xc47c12a0 (kgdb) p *inp $1 = {inp_hash = {le_next = 0x0, le_prev = 0xc3544bd4}, inp_list = {le_next = 0xc47c1348, le_prev = 0xc47c1200}, inp_flow = 0, inp_inc = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_pad = 0, inc_ie = {ie_fport = 28169, ie_lport = 20480, ie_dependfaddr = { ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 84650176}}, ie6_foreign = {__u6_addr = { __u6_addr8 = '\0' , "À¨\v\005", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 1291}, __u6_addr32 = {0, 0, 0, 84650176}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 51095744}}, ie6_local = {__u6_addr = {__u6_addr8 = '\0' , "À¨\v\003", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 779}, __u6_addr32 = {0, 0, 0, 51095744}}}}}}, inp_ppcb = 0x0, inp_pcbinfo = 0xc0972a80, inp_socket = 0xc476d298, inp_label = 0x0, inp_flags = 8388608, inp_sp = 0x0, inp_vflag = 41 ')', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', inp_ip_minttl = 0 '\0', inp_depend4 = {inp4_ip_tos = 0 '\0', inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = { inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_ifindex = 0, inp6_hops = 0}, inp_portlist = {le_next = 0xc47c1348, le_prev = 0xc47c1274}, inp_phd = 0xc35562f0, inp_gencnt = 36, inp_mtx = {mtx_object = {lo_name = 0xc08b6d26 "inp", lo_type = 0xc08b4853 "tcpinp", lo_flags = 21692416, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3274697680, mtx_recurse = 0}} (kgdb) p *inp->inp_socket $3 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 8192, so_qstate = 0, so_pcb = 0xc47c12a0, so_proto = 0xc093a6e8, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0xc476d14c, tqe_prev = 0xc37ae6a0}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc476d2e0}, so_rcv = { sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0xc36ea540}, si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc065364c , kl_unlock = 0xc0653684 , kl_locked = 0xc06536c0 , kl_lockarg = 0xc476d30c}, si_flags = 0}, sb_mtx = {mtx_object = { lo_name = 0xc08adc57 "so_rcv", lo_type = 0xc08adc57 "so_rcv", lo_flags = 16973824, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, sb_state = 32, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 0}, so_snd = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = { slh_first = 0x0}, kl_lock = 0xc065364c , kl_unlock = 0xc0653684 , kl_locked = 0xc06536c0 , kl_lockarg = 0xc476d378}, si_flags = 0}, sb_mtx = {mtx_object = { lo_name = 0xc08adc50 "so_snd", lo_type = 0xc08adc50 "so_snd", lo_flags = 16973824, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 33304, sb_mbcnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 0}, so_upcall = 0, so_upcallarg = 0x0, so_cred = 0xc3a9d180, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 485, so_emuldata = 0x0, so_accf = 0x0} (kgdb) p *inp->inp_ppcb Cannot access memory at address 0x0 > In the tcp_timewait frame, could you print the following: > > p tw > p *tw > p *to > p *th kgdb) frame 7 #7 0xc0718779 in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3a4f024, m=0xc3a27400, tlen=0) at /usr/src/sys/netinet/tcp_input.c:3202 3202 if ((thflags & TH_SYN) && SEQ_GT(th->th_seq, tw->rcv_nxt)) { (kgdb) p tw $4 = (struct tcptw *) 0x0 (kgdb) p *tw Cannot access memory at address 0x0 (kgdb) p *to $5 = {to_flags = 49, to_tsval = 82773511, to_tsecr = 0, to_mss = 1460, to_requested_s_scale = 0 '\0', to_nsacks = 0 '\0', to_sacks = 0x0} (kgdb) p *th $6 = {th_sport = 28169, th_dport = 20480, th_seq = 1498072816, th_ack = 0, th_x2 = 0, th_off = 10, th_flags = 2 '\002', th_win = 57344, th_sum = 0, th_urp = 0} > Also, are you running with INVARIANTS and/or WITNESS? Sorry, I compiled kernel without INVARIANTS and WITNESS. -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 13:13:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85E2D16A400 for ; Mon, 3 Apr 2006 13:13:02 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D967843D45 for ; Mon, 3 Apr 2006 13:13:01 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from lfw.hetzner.co.za ([196.7.18.226] helo=hetzner.co.za) by mail1a.your-server.co.za with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1FQOrW-0005iF-5v; Mon, 03 Apr 2006 15:12:54 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.51 (FreeBSD)) id 1FQOrW-000KPH-69; Mon, 03 Apr 2006 15:12:54 +0200 To: Randy Bush From: Ian FREISLICH In-Reply-To: Message from Randy Bush of "Mon, 03 Apr 2006 20:10:01 +0800." <17457.4249.383686.765032@roam.psg.com> X-Attribution: BOFH Date: Mon, 03 Apr 2006 15:12:54 +0200 Sender: ianf@hetzner.co.za Message-Id: X-Virus-Scanned: Clear (ClamAV 0.88/1369/Mon Apr 3 12:25:15 2006) Cc: FreeBSD Current Subject: Re: natd when doubled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 13:13:02 -0000 Randy Bush wrote: > i am in a hotel which gives me an address from 10/8 on the ether. > i have it plugged into em0 on a -current system. > > i have another machine on wireless out the ath0 port which is > configured as 192.168.0.1 > > my natd.conf is > > dynamic yes > unregistered_only yes > interface em0 > > my ipfw.rules sez > > add divert natd all from 192.168.0.0/24 to any via em0 > add divert natd all from any to 192.168.0.0/24 via ath0 > > i suspect the latter two are a bit too clever > > the two machines can ping eachother over the wireless. but > nat is just not doing it. > > hit me with he clue bat, please I thought that all you'd need is: add divert natd all from any to any via em0 Since natd needs te see all traffic both in and out of the world facing interface. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 13:15:38 2006 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 E334216A400; Mon, 3 Apr 2006 13:15:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4385943D46; Mon, 3 Apr 2006 13:15:37 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5F316.dip.t-dialin.net [84.165.243.22]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.4/8.13.1) with ESMTP id k33DDmsX012015; Mon, 3 Apr 2006 15:13:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k33DFYoj094435; Mon, 3 Apr 2006 15:15:34 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 03 Apr 2006 15:15:34 +0200 Message-ID: <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 03 Apr 2006 15:15:34 +0200 From: Alexander Leidinger To: "Angka H. K." References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> In-Reply-To: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-multimedia@freebsd.org, njl@freebsd.org, current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 13:15:39 -0000 "Angka H. K." wrote: Please strip freebsd-multimedia@ on reply... > I have other problem now , which is saying "acpi: bad read to port 0x073" > and "acpi: bad write to port 0x073(8) val 82", where can ask about this ? It > looks like google has no archive about this error. I assume you are using -current. So the right place is to ask on current@ (CCed). I also CCed njl@, since he's our "master of acpi". Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 "This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you?" From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 14:04:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A171316A400 for ; Mon, 3 Apr 2006 14:04:19 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D7043D48 for ; Mon, 3 Apr 2006 14:04:17 +0000 (GMT) (envelope-from matpockuh@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1595925nzf for ; Mon, 03 Apr 2006 07:04:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Lo2hRndRA7z8N+2oOmHn6U0Q+ekhttlDezHebu5gpvFrQDMxZqa65t58cEG7l/dbgJXVjDP6hLm3+l3Us0SaQ2iQhfTbNJm0UyGDNSzfZEcuyQClL+vJ3QCO6yJzOCMyCWI5V431v0dXRuCmF0w0AB80/4Bp7UpP1uJcgvNjHLc= Received: by 10.35.105.18 with SMTP id h18mr58200pym; Mon, 03 Apr 2006 07:04:17 -0700 (PDT) Received: by 10.35.60.17 with HTTP; Mon, 3 Apr 2006 07:04:13 -0700 (PDT) Message-ID: <3979a4b0604030704u4a8a43fcxb76bdaab0de5f0f2@mail.gmail.com> Date: Mon, 3 Apr 2006 18:04:13 +0400 From: "KOT MATPOCKuH" To: freebsd-current@freebsd.org, sos@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23893_21770539.1144073053219" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problems with SATA drives on PDC20771 and SiI3512 controllers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 14:04:19 -0000 ------=_Part_23893_21770539.1144073053219 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello! I got problems with my SATA II drives. 1. If drive attached to Promise FastTrak TX2300 (PDC20771 chipset), all "small" operations like fsck, newfs with this drive works propertly. But on hard load (like "dump 0f - / | restore rf -" or something like this) on this drive, I have a WRITE_DMA (or WRITE_DMA48) errors, disk detach, an= d as result - system panic. After reboot and fsck, I does not see anything on filesystem. boot -hsv log is attached, and named boot.promise.log. Panic log is panic.promise.log. 2. If drive attached to SiI 3512 SATA150 (second SATA controller on my motherboard), I have same problems, but system crashes after 1-2 minutes of hard load, and after fsck I see a lot of directories on filesystem. boot -hsv - boot.sii.log. Panic log is panic.sii.log. I'm tried to check this problem with another SATA drive, and I got problems with Promise and SiI controllers, but If THIS drive is connected to nForce3 Pro SATA150 (chipset's SATA controller) - all is fine, "dump | restore" successfully completed. What is wrong? -- MATPOCKuH ------=_Part_23893_21770539.1144073053219 Content-Type: application/octet-stream; name="boot.promise.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot.promise.log" X-Attachment-Id: f_elkv4kzn TUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAwMDAwMDAwMDAwIGxlbj0wMDAwMDAwMDAwMDk5YzAwClNN QVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwZjAwMDAgbGVuPTAwMDAwMDAwMDAwMTAwMDAKU01B UCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZWMwMDAwMCBsZW49MDAwMDAwMDAwMDAwMTAwMApTTUFQ IHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZlZTAwMDAwIGxlbj0wMDAwMDAwMDAwMDAxMDAwClNNQVAg dHlwZT0wMiBiYXNlPTAwMDAwMDAwZmZmZjAwMDAgbGVuPTAwMDAwMDAwMDAwMTAwMDAKU01BUCB0 eXBlPTAyIGJhc2U9MDAwMDAwMDAwMDA5ZjgwMCBsZW49MDAwMDAwMDAwMDAwMDgwMApTTUFQIHR5 cGU9MDEgYmFzZT0wMDAwMDAwMDAwMTAwMDAwIGxlbj0wMDAwMDAwMDNmZWYwMDAwClNNQVAgdHlw ZT0wMyBiYXNlPTAwMDAwMDAwM2ZmZjMwMDAgbGVuPTAwMDAwMDAwMDAwMGQwMDAKU01BUCB0eXBl PTA0IGJhc2U9MDAwMDAwMDAzZmZmMDAwMCBsZW49MDAwMDAwMDAwMDAwMzAwMApDb3B5cmlnaHQg KGMpIDE5OTItMjAwNiBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5 ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKICAgICAg ICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRz IHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICMyMzogVGh1IE1hciAzMCAyMzo0OTo1NyBN U0QgMjAwNgogICAgcm9vdEBncmVlbjovdXNyL29iai91c3Ivc3JjL3N5cy9ncmVlbgpQcmVsb2Fk ZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhmZmZmZmZmZjgwNzFiMDAw LgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xvY2s6IDExOTMyNzggSHoKQ0xLX1VT RV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNpbmcgZGVmYXVsdCBmcmVxdWVu Y3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ2Fs aWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDE4MDg4MTEwNDIgSHoKQ1BVOiBBTUQg QXRobG9uKHRtKSA2NCBQcm9jZXNzb3IgMjgwMCsgKDE4MDguODEtTUh6IEs4LWNsYXNzIENQVSkK ICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweGZjMCAgU3RlcHBpbmcgPSAwCiAgRmVh dHVyZXM9MHg3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxT RVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTI+ CiAgQU1EIEZlYXR1cmVzPTB4ZTA1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLExNLDNETm93KywzRE5v dz4KTDEgMk1CIGRhdGEgVExCOiA4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDJNQiBp bnN0cnVjdGlvbiBUTEI6IDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgNEtCIGRhdGEg VExCOiAzMiBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSA0S0IgaW5zdHJ1Y3Rpb24gVExC OiAzMiBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSBkYXRhIGNhY2hlOiA2NCBrYnl0ZXMs IDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMSBpbnN0cnVj dGlvbiBjYWNoZTogNjQga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkg YXNzb2NpYXRpdmUKTDIgMk1CIHVuaWZpZWQgVExCOiAwIGVudHJpZXMsIGRpc2FibGVkL25vdCBw cmVzZW50CkwyIDRLQiBkYXRhIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFzc29jaWF0aXZlCkwy IDRLQiBpbnN0cnVjdGlvbiBUTEI6IDUxMiBlbnRyaWVzLCA0LXdheSBhc3NvY2lhdGl2ZQpMMiB1 bmlmaWVkIGNhY2hlOiA1MTIga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMTYt d2F5IGFzc29jaWF0aXZlCnVzYWJsZSBtZW1vcnkgID0gMTA2NTgxMTk2OCAoMTAxNiBNQikKUGh5 c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAw OThmZmYsIDYyMjU5MiBieXRlcyAoMTUyIHBhZ2VzKQoweDAwMDAwMDAwMDA4MTgwMDAgLSAweDAw MDAwMDAwM2UxYWZmZmYsIDEwMzM0Njk5NTIgYnl0ZXMgKDI1MjMxMiBwYWdlcykKYXZhaWwgbWVt b3J5ID0gMTAyNzYzNzI0OCAoOTgwIE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxOdmlkaWEgQVdSREFD UEk+CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDAKTUFEVDogRm91bmQgSU8gQVBJQyBJRCAyLCBJ bnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEn cyAtPiBpbnRwaW4gMAppb2FwaWMwOiBpbnRwaW4gMCAtPiBFeHRJTlQgKGVkZ2UsIGhpZ2gpCmlv YXBpYzA6IGludHBpbiAxIC0+IElTQSBJUlEgMSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGlu IDIgLT4gSVNBIElSUSAyIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMyAtPiBJU0EgSVJR IDMgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA0IC0+IElTQSBJUlEgNCAoZWRnZSwgaGln aCkKaW9hcGljMDogaW50cGluIDUgLT4gSVNBIElSUSA1IChlZGdlLCBoaWdoKQppb2FwaWMwOiBp bnRwaW4gNiAtPiBJU0EgSVJRIDYgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA3IC0+IElT QSBJUlEgNyAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDggLT4gSVNBIElSUSA4IChlZGdl LCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gOSAtPiBJU0EgSVJRIDkgKGVkZ2UsIGhpZ2gpCmlvYXBp YzA6IGludHBpbiAxMCAtPiBJU0EgSVJRIDEwIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4g MTEgLT4gSVNBIElSUSAxMSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDEyIC0+IElTQSBJ UlEgMTIgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxMyAtPiBJU0EgSVJRIDEzIChlZGdl LCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTQgLT4gSVNBIElSUSAxNCAoZWRnZSwgaGlnaCkKaW9h cGljMDogaW50cGluIDE1IC0+IElTQSBJUlEgMTUgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBp biAxNiAtPiBQQ0kgSVJRIDE2IChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMTcgLT4gUENJ IElSUSAxNyAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDE4IC0+IFBDSSBJUlEgMTggKGxl dmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxOSAtPiBQQ0kgSVJRIDE5IChsZXZlbCwgbG93KQpp b2FwaWMwOiBpbnRwaW4gMjAgLT4gUENJIElSUSAyMCAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50 cGluIDIxIC0+IFBDSSBJUlEgMjEgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAyMiAtPiBQ Q0kgSVJRIDIyIChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMjMgLT4gUENJIElSUSAyMyAo bGV2ZWwsIGxvdykKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKaW9h cGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgppb2FwaWMwOiBpbnRwaW4gMiB0cmlnZ2Vy OiBlZGdlCmlvYXBpYzA6IGludHBpbiAyIHBvbGFyaXR5OiBoaWdoCk1BRFQ6IEludGVycnVwdCBv dmVycmlkZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVs CmlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5OiBoaWdoCk1BRFQ6IEludGVycnVwdCBvdmVycmlk ZTogc291cmNlIDE0LCBpcnEgMTQKaW9hcGljMDogaW50cGluIDE0IHRyaWdnZXI6IGVkZ2UKaW9h cGljMDogaW50cGluIDE0IHBvbGFyaXR5OiBoaWdoCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTog c291cmNlIDE1LCBpcnEgMTUKaW9hcGljMDogaW50cGluIDE1IHRyaWdnZXI6IGVkZ2UKaW9hcGlj MDogaW50cGluIDE1IHBvbGFyaXR5OiBoaWdoCmxhcGljMDogUm91dGluZyBOTUkgLT4gTElOVDEK aW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoK ICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA0MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZS OiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAw eDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAw MDAwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAwMDAKbWVtOiA8bWVtb3J5PgpuZnNs b2NrOiBwc2V1ZG8tZGV2aWNlCm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CnJhbmRv bTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgppbzogPEkvTz4KYWNwaTA6IDxO dmlkaWEgQVdSREFDUEk+IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDkg KElTQSBJUlEgOSkgdG8gdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKTogICAg bW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDAwODg4CnBjaV9vcGVuKDFhKTogICBt b2RlMXJlcz0weDgwMDAwMDAwICgweDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6ICAgZGV2aWNlIDAg W2NsYXNzPTA2MDAwMF0gW2hkcj0wMF0gaXMgdGhlcmUgKGlkPTAwZTExMGRlKQpBY3BpT3NEZXJp dmVQY2lJZDogYnVzIDAgZGV2IDEgZnVuYyAwCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpB Y3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDEgZnVuYyAwCnBjaV9saW5rMDogTGlua3MgYWZ0 ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMDogTGlua3MgYWZ0 ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg IDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmswOiBMaW5r cyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiBMaW5rcyBhZnRl ciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDExICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiBMaW5rcyBhZnRl ciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAg MTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE6IExpbmtz IGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVy IGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgIDkgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVy IGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAg OSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMjogTGlua3Mg YWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIg aW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIg aW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEw ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmszOiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBp bml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA5ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBp bml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgIDkg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazQ6IExpbmtzIGFm dGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazU6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazU6IExpbmtzIGFmdGVyIGlu aXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNTogTGlua3MgYWZ0 ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNjogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNjogTGlua3MgYWZ0ZXIgaW5p dGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEwICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms2OiBMaW5rcyBhZnRl ciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBpbml0 aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBpbml0 aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazc6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazg6IExpbmtzIGFmdGVyIGluaXRp YWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazg6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rODogTGlua3MgYWZ0ZXIg ZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rOTogTGlua3MgYWZ0ZXIgaW5pdGlh bCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rOTogTGlua3MgYWZ0ZXIgaW5pdGlh bCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDExICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms5OiBMaW5rcyBhZnRlciBk aXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAg MyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMDogTGlua3MgYWZ0ZXIgaW5pdGlh bCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTA6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTA6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazExOiBMaW5rcyBhZnRlciBpbml0 aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA5ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMTogTGlua3MgYWZ0ZXIgaW5p dGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA5ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMTogTGlua3MgYWZ0 ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTI6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEyOiBMaW5rcyBhZnRlciBp bml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEyOiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMzogTGlua3MgYWZ0ZXIg aW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTM6IExpbmtzIGFmdGVy IGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTM6IExpbmtz IGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE0OiBMaW5rcyBhZnRl ciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNDogTGlua3MgYWZ0 ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNDogTGlu a3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTU6IExpbmtzIGFm dGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE1OiBMaW5rcyBh ZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE1OiBM aW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNjogTGlua3Mg YWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTY6IExpbmtz IGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTY6 IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE3OiBMaW5r cyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg IDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNzogTGlu a3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsx NzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTg6IExp bmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAxNgpwY2lfbGluazE4OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlk YXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAx NgpwY2lfbGluazE4OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKcGNpX2xpbmsxOTogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDE3CnBjaV9saW5rMTk6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE3CnBjaV9saW5rMTk6 IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAxNwpwY2lfbGluazIwOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTgKcGNpX2xp bmsyMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTgKcGNpX2xpbmsyMDogTGlua3MgYWZ0ZXIg ZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDE4CnBjaV9saW5rMjE6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAxOQpwY2lfbGluazIxOiBMaW5rcyBh ZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAxOQpwY2lfbGluazIxOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTkKcGNpX2xpbmsy MjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgICAxNiAgIE4gICAgIDAgIDE2CnBjaV9saW5rMjI6IExpbmtzIGFmdGVyIGluaXRpYWwg dmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxNiAgIE4gICAg IDAgIDE2CnBjaV9saW5rMjI6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAxNgpwY2lfbGluazIzOiBMaW5rcyBhZnRl ciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0 aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAg MjEgMjIKcGNpX2xpbmsyMzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjQ6IExpbmtz IGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI0OiBMaW5rcyBhZnRlciBpbml0aWFsIHZh bGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAyMCAyMSAyMgpwY2lfbGluazI0OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNTog TGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAg IDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjU6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjU6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGlu azI2OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNjogTGlua3MgYWZ0ZXIg aW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1 ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNjogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBj aV9saW5rMjc6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI3OiBMaW5rcyBh ZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI3OiBMaW5rcyBhZnRlciBkaXNhYmxl OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEg MjIKcGNpX2xpbmsyODogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjg6IExp bmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjg6IExpbmtzIGFmdGVyIGRp c2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAy MCAyMSAyMgpwY2lfbGluazI5OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDIzICAgTiAgICAgMCAgMjMKcGNpX2xpbmsyOTogTGlu a3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgIDIzICAgTiAgICAgMCAgMjMKcGNpX2xpbmsyOTogTGlua3MgYWZ0ZXIgZGlzYWJsZToK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIzCnBjaV9s aW5rMzA6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazMwOiBMaW5rcyBhZnRl ciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazMwOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIK cGNpX2xpbmszMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzE6IExpbmtz IGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAg IDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzE6IExpbmtzIGFmdGVyIGRpc2Fi bGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAy MSAyMgpwY2lfbGluazMyOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszMjog TGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszMjogTGlua3MgYWZ0ZXIg ZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDIwIDIxIDIyCnBjaV9saW5rMzM6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGlu azMzOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazMzOiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBj aV9saW5rMzQ6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzQ6IExp bmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUg ICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazM1OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2Jl OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEg MjIKcGNpX2xpbmszNTogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsz NTogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg IDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCkFDUEkgdGltZXI6IDEvMiAxLzIgMS8yIDEvMiAxLzEg MS8xIDEvMSAxLzIgMS8xIDEvMiAtPiAxMApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVu Y3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+ IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxB Q1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiwweGNmMC0weGNmMyBvbiBhY3Bp MApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiBwaHlzaWNhbCBidXM9MApmb3Vu ZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTEsIHJldmlkPTB4YTEKICAgICAgICBidXM9MCwg c2xvdD0wLCBmdW5jPTAKICAgICAgICBjbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCiAgICAgICAgY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChk d29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCiAgICAgICAgbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFz ZSBlODAwMDAwMCwgc2l6ZSAyNSwgZW5hYmxlZApmb3VuZC0+IHZlbmRvcj0weDEwZGUsIGRldj0w eDAwZTAsIHJldmlkPTB4YTIKICAgICAgICBidXM9MCwgc2xvdD0xLCBmdW5jPTAKICAgICAgICBj bGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAw Ziwgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5k LT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDBlNCwgcmV2aWQ9MHhhMQogICAgICAgIGJ1cz0wLCBz bG90PTEsIGZ1bmM9MQogICAgICAgIGNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKICAgICAgICBjbWRyZWc9MHgwMDAxLCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyks IG1heGxhdD0weDAxICgyNTAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT05CiAgICAgICAgcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlw ZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZTAwMCwgc2l6ZSAgNSwgZW5hYmxlZAogICAgICAgIG1h cFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDFjMDAsIHNpemUgIDYsIGVuYWJsZWQK ICAgICAgICBtYXBbMjRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAyMDAwLCBzaXplICA2 LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQSAoc3JjIFxfU0JfLlBD STAuQVBDUzowKQpwY2liMDogc2xvdCAxIElOVEEgcm91dGVkIHRvIGlycSAyMyB2aWEgXF9TQl8u UENJMC5BUENTCmZvdW5kLT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDBlNywgcmV2aWQ9MHhhMQog ICAgICAgIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MAogICAgICAgIGNsYXNzPTBjLTAzLTEwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDBiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCiAgICAgICAgaW50cGluPWEsIGly cT0xMAogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MAogICAgICAgIG1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWYwMDIwMDAsIHNpemUg MTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRBIChzcmMgXF9TQl8u UENJMC5BUENGOjApCnBjaV9saW5rMjM6IFBpY2tlZCBJUlEgMjAgd2l0aCB3ZWlnaHQgMAppb2Fw aWMwOiBDaGFuZ2luZyBwb2xhcml0eSBmb3IgcGluIDIwIHRvIGhpZ2gKcGNpYjA6IHNsb3QgMiBJ TlRBIHJvdXRlZCB0byBpcnEgMjAgdmlhIFxfU0JfLlBDSTAuQVBDRgpmb3VuZC0+IHZlbmRvcj0w eDEwZGUsIGRldj0weDAwZTcsIHJldmlkPTB4YTEKICAgICAgICBidXM9MCwgc2xvdD0yLCBmdW5j PTEKICAgICAgICBjbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAg Y21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAg ICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgw MSAoMjUwIG5zKQogICAgICAgIGludHBpbj1iLCBpcnE9MTAKICAgICAgICBwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDEs IHJhbmdlIDMyLCBiYXNlIGVmMDAzMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjIuSU5UQiAoc3JjIFxfU0JfLlBDSTAuQVBDRzowKQpwY2lfbGluazI0OiBQ aWNrZWQgSVJRIDIxIHdpdGggd2VpZ2h0IDAKaW9hcGljMDogQ2hhbmdpbmcgcG9sYXJpdHkgZm9y IHBpbiAyMSB0byBoaWdoCnBjaWIwOiBzbG90IDIgSU5UQiByb3V0ZWQgdG8gaXJxIDIxIHZpYSBc X1NCXy5QQ0kwLkFQQ0cKZm91bmQtPiB2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMGU4LCByZXZpZD0w eGEyCiAgICAgICAgYnVzPTAsIHNsb3Q9MiwgZnVuYz0yCiAgICAgICAgY2xhc3M9MGMtMDMtMjAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQogICAgICAgIGNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgw MGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKICAgICAgICBpbnRwaW49 YywgaXJxPTEwCiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJy ZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZjAwNDAwMCwg c2l6ZSAgOCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEMgKHNyYyBc X1NCXy5QQ0kwLkFQQ0w6MCkKcGNpX2xpbmszMDogUGlja2VkIElSUSAyMiB3aXRoIHdlaWdodCAw CmlvYXBpYzA6IENoYW5naW5nIHBvbGFyaXR5IGZvciBwaW4gMjIgdG8gaGlnaApwY2liMDogc2xv dCAyIElOVEMgcm91dGVkIHRvIGlycSAyMiB2aWEgXF9TQl8uUENJMC5BUENMCmZvdW5kLT4gdmVu ZG9yPTB4MTBkZSwgZGV2PTB4MDBlYSwgcmV2aWQ9MHhhMQogICAgICAgIGJ1cz0wLCBzbG90PTYs IGZ1bmM9MAogICAgICAgIGNsYXNzPTA0LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAg ICAgICBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK ICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxh dD0weDA1ICgxMjUwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9MTEKICAgICAgICBwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0 eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiODAwLCBzaXplICA4LCBlbmFibGVkCiAgICAgICAg bWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwYmMwMCwgc2l6ZSAgNywgZW5hYmxl ZAogICAgICAgIG1hcFsxOF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWYwMDAwMDAsIHNpemUg MTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNi5JTlRBIChzcmMgXF9TQl8u UENJMC5BUENKOjApCnBjaV9saW5rMjc6IFBpY2tlZCBJUlEgMjAgd2l0aCB3ZWlnaHQgMQpwY2li MDogc2xvdCA2IElOVEEgcm91dGVkIHRvIGlycSAyMCB2aWEgXF9TQl8uUENJMC5BUENKCmZvdW5k LT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDBlNSwgcmV2aWQ9MHhhMgogICAgICAgIGJ1cz0wLCBz bG90PTgsIGZ1bmM9MAogICAgICAgIGNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKICAgICAgICBjbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyks IG1heGxhdD0weDAxICgyNTAgbnMpCiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw ZjAwMCwgc2l6ZSAgNCwgZW5hYmxlZApmb3VuZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTMs IHJldmlkPTB4YTIKICAgICAgICBidXM9MCwgc2xvdD0xMCwgZnVuYz0wCiAgICAgICAgY2xhc3M9 MDEtMDEtODUsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDUsIHN0 YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKICAgICAg ICBpbnRwaW49YSwgaXJxPTExCiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMDlm MCwgc2l6ZSAgMywgZW5hYmxlZAogICAgICAgIG1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJh c2UgMDAwMDBiZjAsIHNpemUgIDIsIGVuYWJsZWQKICAgICAgICBtYXBbMThdOiB0eXBlIDQsIHJh bmdlIDMyLCBiYXNlIDAwMDAwOTcwLCBzaXplICAzLCBlbmFibGVkCiAgICAgICAgbWFwWzFjXTog dHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMGI3MCwgc2l6ZSAgMiwgZW5hYmxlZAogICAgICAg IG1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGQ4MDAsIHNpemUgIDQsIGVuYWJs ZWQKICAgICAgICBtYXBbMjRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBkYzAwLCBzaXpl ICA3LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjEwLklOVEEgKHNyYyBcX1NC Xy5QQ0kwLkFQU0o6MCkKcGNpX2xpbmszNTogUGlja2VkIElSUSAyMSB3aXRoIHdlaWdodCAxCnBj aWIwOiBzbG90IDEwIElOVEEgcm91dGVkIHRvIGlycSAyMSB2aWEgXF9TQl8uUENJMC5BUFNKCmZv dW5kLT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDBlMiwgcmV2aWQ9MHhhMgogICAgICAgIGJ1cz0w LCBzbG90PTExLCBmdW5jPTAKICAgICAgICBjbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0wCiAgICAgICAgY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0w IChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgxMCAoNDgwIG5zKSwgbWluZ250PTB4MGMgKDMw MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPiB2ZW5kb3I9MHgxMGRlLCBkZXY9MHgw MGVkLCByZXZpZD0weGEyCiAgICAgICAgYnVzPTAsIHNsb3Q9MTQsIGZ1bmM9MAogICAgICAgIGNs YXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDA3 LCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91 bmQtPiB2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAwLCByZXZpZD0weDAwCiAgICAgICAgYnVzPTAs IHNsb3Q9MjQsIGZ1bmM9MAogICAgICAgIGNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPiB2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAxLCBy ZXZpZD0weDAwCiAgICAgICAgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MQogICAgICAgIGNsYXNzPTA2 LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDAwLCBzdGF0 cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPiB2ZW5k b3I9MHgxMDIyLCBkZXY9MHgxMTAyLCByZXZpZD0weDAwCiAgICAgICAgYnVzPTAsIHNsb3Q9MjQs IGZ1bmM9MgogICAgICAgIGNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAg ICAgICBjbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK ICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKZm91bmQtPiB2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAzLCByZXZpZD0weDAw CiAgICAgICAgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwogICAgICAgIGNsYXNzPTA2LTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAw MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKYWdwMDogPE5WSURJQSBuRm9yY2Uz LTI1MCBBR1AgQ29udHJvbGxlcj4gb24gaG9zdGIwCmFncDA6IDEgTWlzY2VsbGFuZW91cyBDb250 cm9sIHVuaXQocykgZm91bmQuCmFncDA6IEFwZXJ0dXJlIEJhc2VbMF06IDB4MDAwMDAwNzQKaG9z dGIwOiBSZXNlcnZlZCAweDIwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGU4 MDAwMDAwCmFncDA6IGFsbG9jYXRpbmcgR0FUVCBmb3IgYXBlcnR1cmUgb2Ygc2l6ZSAzMk0KaXNh YjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVz PiBvbiBpc2FiMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAxLjEgKG5vIGRy aXZlciBhdHRhY2hlZCkKb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVt IDB4ZWYwMDIwMDAtMHhlZjAwMmZmZiBpcnEgMjAgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCm9oY2kw OiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGVmMDAyMDAw CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIwIChQQ0kgSVJRIDIwKSB0byB2ZWN0b3IgNDkKb2hj aTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0 CnVzYjA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTAKdXNiMDogVVNC IHJldmlzaW9uIDEuMAp1aHViMDogPG5WaWRpYSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMAp1aHViMDogNCBwb3J0cyB3aXRoIDQgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKb2hjaTE6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g bWVtIDB4ZWYwMDMwMDAtMHhlZjAwM2ZmZiBpcnEgMjEgYXQgZGV2aWNlIDIuMSBvbiBwY2kwCm9o Y2kxOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGVmMDAz MDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byB2ZWN0b3IgNTAK b2hjaTE6IFtHSUFOVC1MT0NLRURdCnVzYjE6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBw b3J0CnVzYjE6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTEKdXNiMTog VVNCIHJldmlzaW9uIDEuMAp1aHViMTogPG5WaWRpYSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMQp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6IDxOVklESUEgbkZvcmNlMyAyNTAgVVNCIDIuMCBj b250cm9sbGVyPiBtZW0gMHhlZjAwNDAwMC0weGVmMDA0MGZmIGlycSAyMiBhdCBkZXZpY2UgMi4y IG9uIHBjaTAKZWhjaTA6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMg YXQgMHhlZjAwNDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8g dmVjdG9yIDUxCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IyOiBFSENJIHZlcnNpb24gMS4wCnVz YjI6IGNvbXBhbmlvbiBjb250cm9sbGVycywgNCBwb3J0cyBlYWNoOiB1c2IwIHVzYjEKdXNiMjog PE5WSURJQSBuRm9yY2UzIDI1MCBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjI6IFVT QiByZXZpc2lvbiAyLjAKdWh1YjI6IDxuVmlkaWEgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIKdWh1YjI6IDggcG9ydHMgd2l0aCA4IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCnBjbTA6IDxuVmlkaWEgbkZvcmNlMyAyNTA+IHBvcnQgMHhiODAw LTB4YjhmZiwweGJjMDAtMHhiYzdmIG1lbSAweGVmMDAwMDAwLTB4ZWYwMDBmZmYgaXJxIDIwIGF0 IGRldmljZSA2LjAgb24gcGNpMApwY20wOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4 MTAgdHlwZSA0IGF0IDB4YjgwMApwY20wOiBSZXNlcnZlZCAweDgwIGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHhiYzAwCnBjbTA6IFtNUFNBRkVdCnBjbTA6IDxBdmFuY2UgTG9naWMgQUxD ODUwIEFDOTcgQ29kZWMgKGlkID0gMHg0MTRjNDc5MCk+CnBjbTA6IENvZGVjIGZlYXR1cmVzIDUg Yml0IG1hc3RlciB2b2x1bWUsIG5vIDNEIFN0ZXJlbyBFbmhhbmNlbWVudApwY20wOiBQcmltYXJ5 IGNvZGVjIGV4dGVuZGVkIGZlYXR1cmVzIGRvdWJsZSByYXRlIFBDTSwgcmVzZXJ2ZWQgMSwgY2Vu dGVyIERBQywgc3Vycm91bmQgREFDLCBMRkUgREFDLCByZXNlcnZlZCA1CnBjbTA6IGFjOTcgY29k ZWMgZGFjIHJlYWR5IGNvdW50OiAwCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgM2RiOTUwMDAsIDQwMDA7 IDB4ZmZmZmZmZmZhMDRhMzAwMCAtPiAzZGI5NTAwMApwY20wOiBzbmRidWZfc2V0bWFwIDNkYjkx MDAwLCA0MDAwOyAweGZmZmZmZmZmYTA0YTcwMDAgLT4gM2RiOTEwMDAKYXRhcGNpMDogPG5WaWRp YSBuRm9yY2UzIFBybyBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYs MHgxNzAtMHgxNzcsMHgzNzYsMHhmMDAwLTB4ZjAwZiBhdCBkZXZpY2UgOC4wIG9uIHBjaTAKYXRh cGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZjAwMAph dGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0 ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBv c3RhdDA9NTAgb3N0YXQxPTAwCmF0YTA6IHN0YXQwPTB4OTAgZXJyPTB4OTAgbHNiPTB4OTAgbXNi PTB4OTAKYXRhMDogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiBz dGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0 MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPgppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDUyCmF0YTA6IFtNUFNBRkVdCmF0YTE6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Ig cmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3Ig cmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01 MCBvc3RhdDE9MDAKYXRhMTogc3RhdDA9MHgxMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgph dGExOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTE6IHJlc2V0IHRw MiBzdGF0MD0xMCBzdGF0MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byB2ZWN0b3IgNTMKYXRhMTogW01QU0FGRV0K YXRhcGNpMTogPG5WaWRpYSBuRm9yY2UzIFBybyBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHg5 ZjAtMHg5ZjcsMHhiZjAtMHhiZjMsMHg5NzAtMHg5NzcsMHhiNzAtMHhiNzMsMHhkODAwLTB4ZDgw ZiwweGRjMDAtMHhkYzdmIGlycSAyMSBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwCmF0YXBjaTE6IFJl c2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGQ4MDAKYXRhcGNpMTog W01QU0FGRV0KYXRhcGNpMTogUmVzZXJ2ZWQgMHg4MCBieXRlcyBmb3IgcmlkIDB4MjQgdHlwZSA0 IGF0IDB4ZGMwMAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNl cnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDlmMAphdGFwY2kxOiBSZXNl cnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweGJmMAphdGEyOiBTQVRBIGNv bm5lY3QgcmVhZHkgdGltZT0wbXMKYXRhMjogc2F0YV9jb25uZWN0IGRldmljZXM9MHgxPEFUQV9N QVNURVI+CmF0YTI6IFtNUFNBRkVdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0 YXBjaTE6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4OTcwCmF0 YXBjaTE6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4YjcwCmF0 YTM6IFNBVEEgY29ubmVjdCBzdGF0dXM9MDAwMDAwMDAKYXRhMzogW01QU0FGRV0KcGNpYjE6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwCnBjaWIxOiAgIHNlY29u ZGFyeSBidXMgICAgIDEKcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBJL08g ZGVjb2RlICAgICAgICAweDYwMDAtMHg2ZmZmCnBjaWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 ZWEwMDAwMDAtMHhlYmZmZmZmZgpwY2liMTogICBwcmVmZXRjaGVkIGRlY29kZSAweGUwMDAwMDAw LTB4ZTdmZmZmZmYKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogcGh5c2ljYWwg YnVzPTEKZm91bmQtPiB2ZW5kb3I9MHgxMDAyLCBkZXY9MHg1MTU3LCByZXZpZD0weDAwCiAgICAg ICAgYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwODcsIHN0YXRyZWc9MHgwMmIwLCBjYWNo ZWxuc3o9OCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0w eDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT05 CiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCiAg ICAgICAgbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSBlMDAwMDAwMCwgc2l6ZSAyNywg ZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlMDAwMDAwMC0w eGU3ZmZmZmZmOiBnb29kCiAgICAgICAgbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAw MDAwNjAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFu Z2UgMHg2MDAwLTB4NjBmZjogaW4gcmFuZ2UKICAgICAgICBtYXBbMThdOiB0eXBlIDEsIHJhbmdl IDMyLCBiYXNlIGViMDAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxOiAobnVsbCkgcmVxdWVz dGVkIG1lbW9yeSByYW5nZSAweGViMDAwMDAwLTB4ZWIwMGZmZmY6IGdvb2QKcGNpYjE6IG1hdGNo ZWQgZW50cnkgZm9yIDEuMC5JTlRBIChzcmMgXF9TQl8uUENJMC5BUEM1OjApCnBjaWIxOiBzbG90 IDAgSU5UQSByb3V0ZWQgdG8gaXJxIDE2IHZpYSBcX1NCXy5QQ0kwLkFQQzUKdmdhcGNpMDogPFZH QS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg2MDAwLTB4NjBmZiBtZW0gMHhlMDAwMDAwMC0w eGU3ZmZmZmZmLDB4ZWIwMDAwMDAtMHhlYjAwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBw Y2kxCmRybTA6IDxBVEkgUmFkZW9uIFFXIFJWMjAwIDc1MDA+IG9uIHZnYXBjaTAKaW5mbzogW2Ry bV0gQUdQIGF0IDB4ZTgwMDAwMDAgMzJNQgppbmZvOiBbZHJtXSBJbml0aWFsaXplZCByYWRlb24g MS4xOS4wIDIwMDUwOTExCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDE0 LjAgb24gcGNpMApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHg3MDAwLTB4YWZmZgpwY2li MjogICBtZW1vcnkgZGVjb2RlICAgICAweGVjMDAwMDAwLTB4ZWRmZmZmZmYKcGNpYjI6ICAgcHJl ZmV0Y2hlZCBkZWNvZGUgMHhlZTAwMDAwMC0weGVlZmZmZmZmCnBjaTI6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIyCnBjaTI6IHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4gdmVuZG9yPTB4MTA1YSwgZGV2 PTB4MzU3MCwgcmV2aWQ9MHgwMgogICAgICAgIGJ1cz0yLCBzbG90PTYsIGZ1bmM9MAogICAgICAg IGNsYXNzPTAxLTA0LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTEgKGR3b3JkcykKICAgICAgICBsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgxMiAoNDUw MCBucykKICAgICAgICBpbnRwaW49YSwgaXJxPTkKICAgICAgICBwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDEgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDA3MDAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVk IEkvTyByYW5nZSAweDcwMDAtMHg3MDdmOiBpbiByYW5nZQogICAgICAgIG1hcFsxOF06IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDc0MDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjI6IChudWxs KSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4NzQwMC0weDc0ZmY6IGluIHJhbmdlCiAgICAgICAgbWFw WzFjXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAyODAwMCwgc2l6ZSAxMiwgZW5hYmxlZApw Y2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlZDAyODAwMC0weGVkMDI4ZmZm OiBnb29kCiAgICAgICAgbWFwWzIwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAwMDAwMCwg c2l6ZSAxNywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhl ZDAwMDAwMC0weGVkMDFmZmZmOiBnb29kCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjYuSU5U QSAoc3JjIFxfU0JfLlBDSTAuQVBDMzowKQpwY2lfbGluazIwOiBQaWNrZWQgSVJRIDE4IHdpdGgg d2VpZ2h0IDAKcGNpYjI6IHNsb3QgNiBJTlRBIHJvdXRlZCB0byBpcnEgMTggdmlhIFxfU0JfLlBD STAuQVBDMwpmb3VuZC0+IHZlbmRvcj0weDExMDIsIGRldj0weDAwMDIsIHJldmlkPTB4MDgKICAg ICAgICBidXM9Miwgc2xvdD03LCBmdW5jPTAKICAgICAgICBjbGFzcz0wNC0wMS0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250 PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDE0ICg1MDAwIG5zKQogICAgICAgIGludHBpbj1hLCBp cnE9MTAKICAgICAgICBwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQg RDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA3ODAwLCBzaXpl ICA1LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDc4MDAtMHg3 ODFmOiBpbiByYW5nZQpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi43LklOVEEgKHNyYyBcX1NC Xy5QQ0kwLkFQQzQ6MCkKcGNpX2xpbmsyMTogUGlja2VkIElSUSAxOSB3aXRoIHdlaWdodCAwCnBj aWIyOiBzbG90IDcgSU5UQSByb3V0ZWQgdG8gaXJxIDE5IHZpYSBcX1NCXy5QQ0kwLkFQQzQKZm91 bmQtPiB2ZW5kb3I9MHgxMTAyLCBkZXY9MHg3MDAyLCByZXZpZD0weDA4CiAgICAgICAgYnVzPTIs IHNsb3Q9NywgZnVuYz0xCiAgICAgICAgY2xhc3M9MDktODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQogICAgICAgIGNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCiAgICAgICAgcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQx IEQyIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFz ZSAwMDAwN2MwMCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08g cmFuZ2UgMHg3YzAwLTB4N2MwNzogaW4gcmFuZ2UKZm91bmQtPiB2ZW5kb3I9MHgxMDllLCBkZXY9 MHgwMzZlLCByZXZpZD0weDExCiAgICAgICAgYnVzPTIsIHNsb3Q9OCwgZnVuYz0wCiAgICAgICAg Y2xhc3M9MDQtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQogICAgICAgIGNtZHJlZz0weDAw MDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVy PTB4MjAgKDk2MCBucyksIG1pbmdudD0weDEwICg0MDAwIG5zKSwgbWF4bGF0PTB4MjggKDEwMDAw IG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9MTAKICAgICAgICBwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBi YXNlIGVlMDAwMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweGVlMDAwMDAwLTB4ZWUwMDBmZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50 cnkgZm9yIDIuOC5JTlRBIChzcmMgXF9TQl8uUENJMC5BUEMxOjApCnBjaV9saW5rMTg6IFBpY2tl ZCBJUlEgMTYgd2l0aCB3ZWlnaHQgMQpwY2liMjogc2xvdCA4IElOVEEgcm91dGVkIHRvIGlycSAx NiB2aWEgXF9TQl8uUENJMC5BUEMxCmZvdW5kLT4gdmVuZG9yPTB4MTA5ZSwgZGV2PTB4MDg3OCwg cmV2aWQ9MHgxMQogICAgICAgIGJ1cz0yLCBzbG90PTgsIGZ1bmM9MQogICAgICAgIGNsYXNzPTA0 LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDA2LCBzdGF0 cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDIwICg5 NjAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weGZmICg2Mzc1MCBucykKICAg ICAgICBpbnRwaW49YSwgaXJxPTEwCiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSBlZTAw MTAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHhlZTAwMTAwMC0weGVlMDAxZmZmOiBnb29kCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAy LjguSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDMTowKQpwY2liMjogc2xvdCA4IElOVEEgcm91dGVk IHRvIGlycSAxNiB2aWEgXF9TQl8uUENJMC5BUEMxCmZvdW5kLT4gdmVuZG9yPTB4MTBlYywgZGV2 PTB4ODEzOSwgcmV2aWQ9MHgxMAogICAgICAgIGJ1cz0yLCBzbG90PTksIGZ1bmM9MAogICAgICAg IGNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MjAgKDgwMDAgbnMpLCBtYXhsYXQ9MHg0MCAoMTYw MDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT0xMQogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5cGUgNCwgcmFu Z2UgMzIsIGJhc2UgMDAwMDgwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1 ZXN0ZWQgSS9PIHJhbmdlIDB4ODAwMC0weDgwZmY6IGluIHJhbmdlCiAgICAgICAgbWFwWzE0XTog dHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAyYjAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMjog KG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlZDAyYjAwMC0weGVkMDJiMGZmOiBnb29k CnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjkuSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDMjow KQpwY2lfbGluazE5OiBQaWNrZWQgSVJRIDE3IHdpdGggd2VpZ2h0IDAKcGNpYjI6IHNsb3QgOSBJ TlRBIHJvdXRlZCB0byBpcnEgMTcgdmlhIFxfU0JfLlBDSTAuQVBDMgpmb3VuZC0+IHZlbmRvcj0w eDExYWIsIGRldj0weDQzMjAsIHJldmlkPTB4MTMKICAgICAgICBidXM9Miwgc2xvdD0xMSwgZnVu Yz0wCiAgICAgICAgY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAogICAgICAg IGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQogICAg ICAgIGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgxNyAoNTc1MCBucyksIG1heGxh dD0weDFmICg3NzUwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9MTAKICAgICAgICBwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGVkMDIwMDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIyOiAo bnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGVkMDIwMDAwLTB4ZWQwMjNmZmY6IGdvb2QK ICAgICAgICBtYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA4NDAwLCBzaXplICA4 LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDg0MDAtMHg4NGZm OiBpbiByYW5nZQpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4xMS5JTlRBIChzcmMgXF9TQl8u UENJMC5BUEM0OjApCnBjaWIyOiBzbG90IDExIElOVEEgcm91dGVkIHRvIGlycSAxOSB2aWEgXF9T Ql8uUENJMC5BUEM0CmZvdW5kLT4gdmVuZG9yPTB4MTI4MywgZGV2PTB4ODIxMiwgcmV2aWQ9MHgx MQogICAgICAgIGJ1cz0yLCBzbG90PTEyLCBmdW5jPTAKICAgICAgICBjbGFzcz0wMS04MC0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCiAgICAgICAgY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAy MzAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDggKDIwMDAgbnMpCiAgICAgICAgaW50cGlu PWEsIGlycT0xMAogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MAogICAgICAgIG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDg4MTAsIHNpemUg IDMsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ODgxMC0weDg4 MTc6IGluIHJhbmdlCiAgICAgICAgbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw OGMwMCwgc2l6ZSAgMiwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHg4YzAwLTB4OGMwMzogaW4gcmFuZ2UKICAgICAgICBtYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDA5MDEwLCBzaXplICAzLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVk IEkvTyByYW5nZSAweDkwMTAtMHg5MDE3OiBpbiByYW5nZQogICAgICAgIG1hcFsxY106IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDk0MDAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjI6IChudWxs KSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4OTQwMC0weDk0MDM6IGluIHJhbmdlCiAgICAgICAgbWFw WzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwOTgwMCwgc2l6ZSAgNCwgZW5hYmxlZApw Y2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHg5ODAwLTB4OTgwZjogaW4gcmFuZ2UK cGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMTIuSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDMTow KQpwY2liMjogc2xvdCAxMiBJTlRBIHJvdXRlZCB0byBpcnEgMTYgdmlhIFxfU0JfLlBDSTAuQVBD MQpmb3VuZC0+IHZlbmRvcj0weDEwOTUsIGRldj0weDM1MTIsIHJldmlkPTB4MDEKICAgICAgICBi dXM9Miwgc2xvdD0xMywgZnVuYz0wCiAgICAgICAgY2xhc3M9MDEtODAtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxu c3o9OCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT0xMQogICAg ICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAogICAgICAg IG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDljMDAsIHNpemUgIDMsIGVuYWJs ZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4OWMwMC0weDljMDc6IGluIHJh bmdlCiAgICAgICAgbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwYTAwMCwgc2l6 ZSAgMiwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhhMDAwLTB4 YTAwMzogaW4gcmFuZ2UKICAgICAgICBtYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDBhNDAwLCBzaXplICAzLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5n ZSAweGE0MDAtMHhhNDA3OiBpbiByYW5nZQogICAgICAgIG1hcFsxY106IHR5cGUgNCwgcmFuZ2Ug MzIsIGJhc2UgMDAwMGE4MDAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0 ZWQgSS9PIHJhbmdlIDB4YTgwMC0weGE4MDM6IGluIHJhbmdlCiAgICAgICAgbWFwWzIwXTogdHlw ZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwYWMwMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liMjogKG51 bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhhYzAwLTB4YWMwZjogaW4gcmFuZ2UKICAgICAgICBt YXBbMjRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGVkMDI5MDAwLCBzaXplICA5LCBlbmFibGVk CnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGVkMDI5MDAwLTB4ZWQwMjkx ZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMTMuSU5UQSAoc3JjIFxfU0JfLlBD STAuQVBDMjowKQpwY2liMjogc2xvdCAxMyBJTlRBIHJvdXRlZCB0byBpcnEgMTcgdmlhIFxfU0Jf LlBDSTAuQVBDMgpmb3VuZC0+IHZlbmRvcj0weDEwNGMsIGRldj0weDgwMjQsIHJldmlkPTB4MDAK ICAgICAgICBidXM9Miwgc2xvdD0xNCwgZnVuYz0wCiAgICAgICAgY2xhc3M9MGMtMDAtMTAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjEw LCBjYWNoZWxuc3o9OCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1p bmdudD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykKICAgICAgICBpbnRwaW49 YSwgaXJxPTkKICAgICAgICBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJl bnQgRDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGVkMDJhMDAwLCBz aXplIDExLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGVk MDJhMDAwLTB4ZWQwMmE3ZmY6IGdvb2QKICAgICAgICBtYXBbMTRdOiB0eXBlIDEsIHJhbmdlIDMy LCBiYXNlIGVkMDI0MDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVk IG1lbW9yeSByYW5nZSAweGVkMDI0MDAwLTB4ZWQwMjdmZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQg ZW50cnkgZm9yIDIuMTQuSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDMzowKQpwY2liMjogc2xvdCAx NCBJTlRBIHJvdXRlZCB0byBpcnEgMTggdmlhIFxfU0JfLlBDSTAuQVBDMwphdGFwY2kyOiA8UHJv bWlzZSBQREMyMDc3MSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHg3MDAwLTB4NzA3ZiwweDc0 MDAtMHg3NGZmIG1lbSAweGVkMDI4MDAwLTB4ZWQwMjhmZmYsMHhlZDAwMDAwMC0weGVkMDFmZmZm IGlycSAxOCBhdCBkZXZpY2UgNi4wIG9uIHBjaTIKcGNpMjogY2hpbGQgYXRhcGNpMiByZXF1ZXN0 ZWQgdHlwZSA0IGZvciByaWQgMHgyMCwgYnV0IHRoZSBCQVIgc2F5cyBpdCBpcyBhbiBtZW1pbwpp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gdmVjdG9yIDU0CmF0YXBj aTI6IFtNUFNBRkVdCmF0YXBjaTI6IFJlc2VydmVkIDB4MjAwMDAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgMyBhdCAweGVkMDAwMDAwCmF0YXBjaTI6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3Ig cmlkIDB4MWMgdHlwZSAzIGF0IDB4ZWQwMjgwMDAKYXRhcGNpMjogW01QU0FGRV0KYXRhNDogPEFU QSBjaGFubmVsIDA+IG9uIGF0YXBjaTIKYXRhNDogU0FUQSBjb25uZWN0IHJlYWR5IHRpbWU9MG1z CmF0YTQ6IHNhdGFfY29ubmVjdCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPgphdGE0OiBbTVBTQUZF XQphdGE1OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMgphdGE1OiBTQVRBIGNvbm5lY3Qgc3Rh dHVzPTAwMDAwMDAwCmF0YTU6IFtNUFNBRkVdCmF0YTY6IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFw Y2kyCmF0YTY6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD1lMCBvc3RhdDE9ZjAKYXRhNjogc3Rh dDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0w eGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAg bXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2 OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAg ZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9 MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEw CmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9 MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEw IGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNi PTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBz dGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJy PTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhh MCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0 YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhh MCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxz Yj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4 YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0 MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4 YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBt c2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6 IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBl cnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0w eGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAK YXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0w eGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAg bHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9 MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0 YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9 MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEw IG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRh Njogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEw IGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNi PTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhh MAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQw PTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhh MCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1z Yj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjog c3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVy cj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4 YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAph dGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4 YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBs c2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0w eGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3Rh dDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0w eGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAg bXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2 OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAg ZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9 MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEw CmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9 MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEw IGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNi PTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBz dGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJy PTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhh MCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0 YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhh MCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxz Yj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4 YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0 MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4 YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBt c2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6 IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBl cnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0w eGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAK YXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0w eGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAg bHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9 MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0 YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9 MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEw IG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRh Njogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEw IGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNi PTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhh MAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQw PTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDE9MHhiMCBlcnI9MHhi MCBsc2I9MHhiMCBtc2I9MHhiMAphdGE2OiByZXNldCB0cDIgc3RhdDA9YTAgc3RhdDE9YjAgZGV2 aWNlcz0weDAKYXRhNjogW01QU0FGRV0KcGNtMTogPENyZWF0aXZlIEVNVTEwSzE+IHBvcnQgMHg3 ODAwLTB4NzgxZiBpcnEgMTkgYXQgZGV2aWNlIDcuMCBvbiBwY2kyCnBjbTE6IFJlc2VydmVkIDB4 MjAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDc4MDAKZW11OiBzZXRtYXAgKDNkYWY1 MDAwLCA4MDApLCBuc2VnPTEsIGVycm9yPTAKZW11OiBzZXRtYXAgKDlhYzAwMCwgMTAwMCksIG5z ZWc9MSwgZXJyb3I9MApwY20xOiA8VHJpVGVjaCBUUjI4NjAyIEFDOTcgQ29kZWMgKGlkID0gMHg1 NDUyNDEyMyk+CnBjbTE6IENvZGVjIGZlYXR1cmVzIDUgYml0IG1hc3RlciB2b2x1bWUsIG5vIDNE IFN0ZXJlbyBFbmhhbmNlbWVudApwY20xOiBhYzk3IGNvZGVjIGRhYyByZWFkeSBjb3VudDogMApp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxOSAoUENJIElSUSAxOSkgdG8gdmVjdG9yIDU1CnBjbTE6 IFtNUFNBRkVdCmVtdTogc2V0bWFwICgzZGFmNDAwMCwgMTAwMCksIG5zZWc9MSwgZXJyb3I9MApl bXU6IHNldG1hcCAoOWI1MDAwLCAxMDAwKSwgbnNlZz0xLCBlcnJvcj0wCmVtdTogc2V0bWFwICg5 YjMwMDAsIDEwMDApLCBuc2VnPTEsIGVycm9yPTAKZW11OiBzZXRtYXAgKDNkYWEzMDAwLCAxMDAw KSwgbnNlZz0xLCBlcnJvcj0wCnBjbTE6IHNuZGJ1Zl9zZXRtYXAgM2RhYTAwMDAsIDEwMDA7IDB4 ZmZmZmZmMDAzZGFhMDAwMCAtPiAzZGFhMDAwMApwY20xOiBzbmRidWZfc2V0bWFwIDNkYTllMDAw LCAxMDAwOyAweGZmZmZmZjAwM2RhOWUwMDAgLT4gM2RhOWUwMDAKYmt0cjA6IDxCcm9va1RyZWUg ODc4PiBtZW0gMHhlZTAwMDAwMC0weGVlMDAwZmZmIGlycSAxNiBhdCBkZXZpY2UgOC4wIG9uIHBj aTIKYmt0cjA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4 ZWUwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTYgKFBDSSBJUlEgMTYpIHRvIHZlY3Rv ciA1Ngpia3RyMDogW0dJQU5ULUxPQ0tFRF0KYnJvb2t0cmVlMDogUENJIGJ1cyBsYXRlbmN5IGlz IDMyLgpia3RyMDogYnVmZmVyIHNpemUgMzU1NTMyOCwgYWRkciAweDM5MDAwMDAwCmJrdHIwOiBH UElPIGlzIDB4MDA4NGZmZjMKYmt0cjA6IHN1YnN5c3RlbSAweDE0NjEgMHgwMDAzCmJrdHIwOiBB VmVyIE1lZGlhIFRWL0ZNLCBQaGlsaXBzIEZSMTIxNiBQQUwgRk0gdHVuZXIuCnBjaTI6IDxtdWx0 aW1lZGlhPiBhdCBkZXZpY2UgOC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTI6IDxuZXR3b3Jr LCBldGhlcm5ldD4gYXQgZGV2aWNlIDkuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpza2MwOiA8TWFy dmVsbCBHaWdhYml0IEV0aGVybmV0PiBwb3J0IDB4ODQwMC0weDg0ZmYgbWVtIDB4ZWQwMjAwMDAt MHhlZDAyM2ZmZiBpcnEgMTkgYXQgZGV2aWNlIDExLjAgb24gcGNpMgpza2MwOiBSZXNlcnZlZCAw eDQwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGVkMDIwMDAwCnNrYzA6IGludGVy cnVwdCBtb2RlcmF0aW9uIGlzIDEwMCB1cwpza2MwOiBiYWQgVlBEIHJlc291cmNlIGlkOiBleHBl Y3RlZCA4MiBnb3QgMApza2MwOiBNYXJ2ZWxsIFl1a29uIExpdGUgR2lnYWJpdCBFdGhlcm5ldCBy ZXYuIEEzKDB4NykKc2tjMDogY2hpcCB2ZXIgID0gMHhiMQpza2MwOiBjaGlwIHJldiAgPSAweDA3 CnNrYzA6IFNLX0VQUk9NMCA9IDB4MTAKc2tjMDogU1JBTSBzaXplID0gMHgwMTAwMDAKc2swOiA8 TWFydmVsbCBTZW1pY29uZHVjdG9yLCBJbmMuIFl1a29uPiBvbiBza2MwCnNrMDogYnBmIGF0dGFj aGVkCnNrMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGY6ZWE6NDA6ZjE6NWEKbWlpYnVzMDogPE1J SSBidXM+IG9uIHNrMAplMTAwMHBoeTA6IDxNYXJ2ZWxsIDg4RTEwMDAgR2lnYWJpdCBQSFk+IG9u IG1paWJ1czAKZTEwMDBwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgMTAwMGJhc2VUWC1GRFgsIGF1dG8Kc2tjMDogW01QU0FGRV0KYXRhcGNpMzog PElURSBJVDgyMTJGIFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDg4MTAtMHg4ODE3LDB4OGMw MC0weDhjMDMsMHg5MDEwLTB4OTAxNywweDk0MDAtMHg5NDAzLDB4OTgwMC0weDk4MGYgaXJxIDE2 IGF0IGRldmljZSAxMi4wIG9uIHBjaTIKYXRhcGNpMzogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3Ig cmlkIDB4MjAgdHlwZSA0IGF0IDB4OTgwMAphdGFwY2kzOiBbTVBTQUZFXQphdGE3OiA8QVRBIGNo YW5uZWwgMD4gb24gYXRhcGNpMwphdGFwY2kzOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgNCBhdCAweDg4MTAKYXRhcGNpMzogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQg MHgxNCB0eXBlIDQgYXQgMHg4YzAwCmF0YTc6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBv c3RhdDE9MDAKYXRhNzogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGE3 OiBzdGF0MT0weDAwIGVycj0weDA0IGxzYj0weDE0IG1zYj0weGViCmF0YTc6IHJlc2V0IHRwMiBz dGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTc6IFtNUFNBRkVd CmF0YTg6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kzCmF0YXBjaTM6IFJlc2VydmVkIDB4OCBi eXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4OTAxMAphdGFwY2kzOiBSZXNlcnZlZCAweDQg Ynl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDk0MDAKYXRhODogcmVzZXQgdHAxIG1hc2s9 MDMgb3N0YXQwPTYwIG9zdGF0MT03MAphdGE4OiBzdGF0MD0weDIwIGVycj0weDIwIGxzYj0weDIw IG1zYj0weDIwCmF0YTg6IHN0YXQxPTB4MzAgZXJyPTB4MzAgbHNiPTB4MzAgbXNiPTB4MzAKYXRh ODogcmVzZXQgdHAyIHN0YXQwPTIwIHN0YXQxPTMwIGRldmljZXM9MHgwCmF0YTg6IFtNUFNBRkVd CmF0YXBjaTQ6IDxTaUkgMzUxMiBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHg5YzAwLTB4OWMw NywweGEwMDAtMHhhMDAzLDB4YTQwMC0weGE0MDcsMHhhODAwLTB4YTgwMywweGFjMDAtMHhhYzBm IG1lbSAweGVkMDI5MDAwLTB4ZWQwMjkxZmYgaXJxIDE3IGF0IGRldmljZSAxMy4wIG9uIHBjaTIK YXRhcGNpNDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YWMw MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNyAoUENJIElSUSAxNykgdG8gdmVjdG9yIDU3CmF0 YXBjaTQ6IFtNUFNBRkVdCmF0YXBjaTQ6IFJlc2VydmVkIDB4MjAwIGJ5dGVzIGZvciByaWQgMHgy NCB0eXBlIDMgYXQgMHhlZDAyOTAwMAphdGE5OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpNAph dGE5OiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAwMDAwMDAwCmF0YTk6IFtNUFNBRkVdCmF0YTEwOiA8 QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpNAphdGExMDogU0FUQSBjb25uZWN0IHN0YXR1cz0wMDAw MDAwMAphdGExMDogW01QU0FGRV0KZndvaGNpMDogPFRleGFzIEluc3RydW1lbnRzIFRTQjQzQUIy Mz4gbWVtIDB4ZWQwMmEwMDAtMHhlZDAyYTdmZiwweGVkMDI0MDAwLTB4ZWQwMjdmZmYgaXJxIDE4 IGF0IGRldmljZSAxNC4wIG9uIHBjaTIKZndvaGNpMDogUmVzZXJ2ZWQgMHg4MDAgYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgMyBhdCAweGVkMDJhMDAwCmZ3b2hjaTA6IFtNUFNBRkVdCmZ3b2hjaTA6 IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MSkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNo YW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDAwOjBmOmVhOjAwOjAwOjNjOjlmOjVhCmZ3b2hj aTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMyBwb3J0cy4KZndvaGNpMDogTGluayBTNDAw LCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+ IG9uIGZ3b2hjaTAKZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApp Zl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOjBmOmVhOjNjOjlmOjVhCmZ3ZTA6IGJw ZiBhdHRhY2hlZApmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjowZjplYTozYzo5Zjo1YQpmd2Uw OiBpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBHaWFudApzYnAwOiA8U0JQLTIvU0NTSSBv dmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3 b2hjaTA6IG5vZGVfaWQ9MHhjODAwZmZjMCwgZ2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdp cmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDog YnVzIG1hbmFnZXIgMCAobWUpCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4gcG9ydCAw eDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBlIDkwIHBh cnRfaWQgODAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElSUSA2KSB0byB2ZWN0b3Ig NTgKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZBU1RdCnNpbzA6IGlycSBtYXBzOiAweGMwMSAweGMx MSAweGMwMSAweGMwMQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgz ZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQSwgY29u c29sZQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIHZlY3RvciA1OQpz aW8wOiBbRkFTVF0Kc2lvMTogaXJxIG1hcHM6IDB4YzAxIDB4YzA5IDB4YzAxIDB4YzAxCnNpbzE6 IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBh Y3BpMApzaW8xOiB0eXBlIDE2NTUwQQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAzIChJU0EgSVJR IDMpIHRvIHZlY3RvciA2MApzaW8xOiBbRkFTVF0KcHBjMDogdXNpbmcgZXh0ZW5kZWQgSS9PIHBv cnQgcmFuZ2UKcHBjMDogU1BQCnBwYzA6IDxTdGFuZGFyZCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+ IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gYWNwaTAKcHBjMDogR2VuZXJpYyBjaGlwc2V0IChO SUJCTEUtb25seSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVz PiBvbiBwcGMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZl biBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiA3IChJU0EgSVJRIDcpIHRvIHZlY3RvciA2MQpwcGMwOiBbR0lBTlQtTE9DS0VEXQpwc21j cG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2Fy ZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2Jk MDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEgaXJxIDEgb24gYXRrYmRjMAphdGtiZDogdGhlIGN1 cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcKYXRrYmQ6IGtleWJvYXJkIElE IDB4NDFhYiAoMikKa2JkYzogUkVTRVRfS0JEIHJldHVybiBjb2RlOjAwZmEKa2JkYzogUkVTRVRf S0JEIHN0YXR1czowMGFhCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQgMTAxLzEwMiAo MiksIGNvbmZpZzoweDEsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEg KElTQSBJUlEgMSkgdG8gdmVjdG9yIDYyCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogY3Vy cmVudCBjb21tYW5kIGJ5dGU6MDA0NwprYmRjOiBURVNUX0FVWF9QT1JUIHN0YXR1czowMDAwCmti ZGM6IFJFU0VUX0FVWCByZXR1cm4gY29kZTowMGZhCmtiZGM6IFJFU0VUX0FVWCBzdGF0dXM6MDBh YQprYmRjOiBSRVNFVF9BVVggSUQ6MDAwMAprYmRjOiBSRVNFVF9BVVggcmV0dXJuIGNvZGU6MDBm YQprYmRjOiBSRVNFVF9BVVggc3RhdHVzOjAwYWEKa2JkYzogUkVTRVRfQVVYIElEOjAwMDAKcHNt OiBzdGF0dXMgMDAgMDIgNjQKcHNtOiBzdGF0dXMgMDAgMDAgNjQKcHNtOiBzdGF0dXMgMDAgMDMg NjQKcHNtOiBzdGF0dXMgMDAgMDMgNjQKcHNtOiBkYXRhIDA4IDAwIDAwCnBzbTogc3RhdHVzIDAw IDAyIDY0CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gdmVjdG9yIDYzCnBzbTA6IFtHSUFOVC1MT0NL RURdCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMtMDAsIDMgYnV0dG9ucwpw c20wOiBjb25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTo0CnBzbTA6 IHN5bmNtYXNrOjA4LCBzeW5jYml0czowMAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7 IHNraXBwaW5nIGl0CmZkYzogZmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKcHBjOiBw cGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNpbzAgYWxyZWFkeSBleGlzdHM7 IHNraXBwaW5nIGl0CnNpbzogc2lvMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDIwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMjQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDJjMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMzAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgM2MzClBOUCBJZGVudGlmeSBjb21wbGV0ZQpzYzogc2MwIGFscmVhZHkgZXhpc3Rz OyBza2lwcGluZyBpdAp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmlzYV9w cm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzCmlzYV9wcm9iZV9jaGlsZHJlbjog cHJvYmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21lbSAw eGMwMDAwLTB4Y2JmZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xl PiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBm bGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lzY29u cyB0ZXJtaW5hbCkKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9iZWQg KGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlv bWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQ blAgZGV2aWNlcwpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KbGFwaWM6IERpdmlzb3Ig MiwgRnJlcXVlbmN5IDEwMDQ4OTUxNSBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMTgw ODgxMTA0MiBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2Vj CkxpbnV4IEVMRiBleGVjIGhhbmRsZXIgaW5zdGFsbGVkCmxvMDogYnBmIGF0dGFjaGVkCmF0YTAt bWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEwMCBjYWJsZT04MCB3aXJlCmFk MDogc2V0dGluZyBQSU80IG9uIG5Gb3JjZTMgUHJvIGNoaXAKYWQwOiBzZXR0aW5nIFVETUExMDAg b24gbkZvcmNlMyBQcm8gY2hpcAphZDA6IDExNDQ3Mk1CIDxTZWFnYXRlIFNUMzEyMDAyNEEgMy4z Mz4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMAphZDA6IDIzNDQzOTUzNSBzZWN0b3JzIFsyMzI1NzhD LzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRp c2sgYWQwCmFkMDogblZpZGlhIGNoZWNrMSBmYWlsZWQKYWQwOiBBZGFwdGVjIGNoZWNrMSBmYWls ZWQKYWQwOiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkMDogTFNJICh2MikgY2hlY2sxIGZhaWxl ZAphZDA6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphdGExLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1X RE1BMiB1ZG1hPVVETUEzMyBjYWJsZT00MCB3aXJlCmFjZDA6IHNldHRpbmcgUElPNCBvbiBuRm9y Y2UzIFBybyBjaGlwCmFjZDA6IHNldHRpbmcgVURNQTMzIG9uIG5Gb3JjZTMgUHJvIGNoaXAKYWNk MDogPENSVy00ODI0QS8xLjAwPiBDRFJXIGRyaXZlIGF0IGF0YTEgYXMgbWFzdGVyCmFjZDA6IHJl YWQgODk1OEtCL3MgKDg5NThLQi9zKSB3cml0ZSA4MjY5S0IvcyAoODI2OUtCL3MpLCAyMDQ4S0Ig YnVmZmVyLCBVRE1BMzMKYWNkMDogUmVhZHM6IENEUiwgQ0RSVywgQ0REQSBzdHJlYW0sIHBhY2tl dAphY2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1 ZGlvOiBwbGF5LCAyNTUgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0 cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKYXRhMi1tYXN0ZXI6IHBp bz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQ0OiAyODYxNjhN QiA8U2VhZ2F0ZSBTVDMzMDA4MzFBUyAzLjAzPiBhdCBhdGEyLW1hc3RlciBTQVRBMTUwCmFkNDog NTg2MDcyMzY4IHNlY3RvcnMgWzU4MTQyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQg MSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDQKYWQ0OiBuVmlkaWEgY2hlY2sxIGZhaWxl ZAphZDQ6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQK YWQ0OiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkCmFkNDogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0 YTQtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJl CmFkODogMjM4NDc0TUIgPFNlYWdhdGUgU1QzMjUwODI0QVMgMy5BQUQ+IGF0IGF0YTQtbWFzdGVy IFNBVEEzMDAKYWQ4OiA0ODgzOTUwNTUgc2VjdG9ycyBbNDg0NTE4Qy8xNkgvNjNTXSAxNiBzZWN0 b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkOAphZDg6IFByb21p c2UgY2hlY2sxIGZhaWxlZAphZDg6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDg6IExTSSAodjMp IGNoZWNrMSBmYWlsZWQKYWQ4OiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkCmFkODogRnJlZUJTRCBj aGVjazEgZmFpbGVkCmF0YTctbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTMz IGNhYmxlPTQwIHdpcmUKYWNkMTogc3VjY2VzcyBzZXR0aW5nIFBJTzQgb24gSVRFODIxMkYgY2hp cAphY2QxOiBzdWNjZXNzIHNldHRpbmcgVURNQTMzIG9uIElURTgyMTJGIGNoaXAKYWNkMTogPE5F QyBEVkQgUlcgTkQtMzU0MEEvMS4wMT4gRFZEUiBkcml2ZSBhdCBhdGE3IGFzIG1hc3RlcgphY2Qx OiByZWFkIDgyNjhLQi9zICg4MjY4S0Ivcykgd3JpdGUgODI2OEtCL3MgKDgyNjhLQi9zKSwgMjA0 OEtCIGJ1ZmZlciwgVURNQTMzCmFjZDE6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBE VkRST00sIERWRFIsIHBhY2tldAphY2QxOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwgdGVzdCB3 cml0ZSwgYnVybnByb29mCmFjZDE6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2Qx OiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QxOiBNZWRpdW06IG5vL2Js YW5rIGRpc2MKcGNtMDogbWVhc3VyZWQgYWM5NyBsaW5rIHJhdGUgYXQgNDc5OTUgSHosIHdpbGwg dXNlIDQ4MDAwIEh6Cihwcm9iZTU6c2JwMDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDow OjU6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihw cm9iZTY6c2JwMDowOjY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6c2JwMDowOjA6MCk6 IGVycm9yIDIyCihwcm9iZTA6c2JwMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6 c2JwMDowOjE6MCk6IGVycm9yIDIyCihwcm9iZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTI6c2JwMDowOjI6MCk6IGVycm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6IFVu cmV0cnlhYmxlIEVycm9yCihwcm9iZTM6c2JwMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6c2Jw MDowOjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9yIDIy Cihwcm9iZTQ6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCkFUQSBQc2V1ZG9SQUlEIGxv YWRlZApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQpzdGFydF9pbml0 OiB0cnlpbmcgL3NiaW4vaW5pdAo= ------=_Part_23893_21770539.1144073053219 Content-Type: application/octet-stream; name="panic.promise.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="panic.promise.log" X-Attachment-Id: f_elkv5b4y YWQ4OiBXQVJOSU5HIC0gV1JJVEVfRE1BIFVETUEgSUNSQyBlcnJvciAocmV0cnlpbmcgcmVxdWVz dCkgTEJBPTUwMzc2MzE5CmF0YTQ6IHJlaW5pdGluZyBjaGFubmVsIC4uCmF0YTQ6IFNBVEEgY29u bmVjdCByZWFkeSB0aW1lPTEwMDAwbXMKYXRhNDogc2F0YV9jb25uZWN0IGRldmljZXM9MHgwCmFk ODogRkFJTFVSRSAtIGRldmljZSBkZXRhY2hlZApzdWJkaXNrODogZGV0YWNoZWQKYWQ4OiBkZXRh Y2hlZAphdGE0OiByZWluaXQgZG9uZSAuLgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD0yMjk1Mzk4NCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZb V1JJVEUob2Zmc2V0PTIzMTk5NzQ0LCBsZW5ndGg9MTE0Njg4KV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjMzMzA4MTYsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2 CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTY1NTM2LCBsZW5ndGg9MjA0OCldZXJy b3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTYxNDQwMDAsIGxlbmd0aD0y MDQ4KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjI4MzkyOTYs IGxlbmd0aD0xMTQ2ODgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD0yMzA4NTA1NiwgbGVuZ3RoPTExNDY4OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZb V1JJVEUob2Zmc2V0PTIzMzYzNTg0LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjM0OTQ2NTYsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0g NgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMzYyNTcyOCwgbGVuZ3RoPTEzMTA3 MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTIzNzU2ODAwLCBs ZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9 MjM4ODc4NzIsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yNDAxODk0NCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0MTUwMDE2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYK Z192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjQyODEwODgsIGxlbmd0aD0xMzEwNzIp XWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNDQxMjE2MCwgbGVu Z3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0 NTQzMjMyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklU RShvZmZzZXQ9MjQ2NzQzMDQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6 YWQ4czFmW1dSSVRFKG9mZnNldD0yNDgwNTM3NiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2Cmdf dmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0OTM2NDQ4LCBsZW5ndGg9MTMxMDcyKV1l cnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjUwNjc1MjAsIGxlbmd0 aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNTE5 ODU5MiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUo b2Zmc2V0PTI1MzI5NjY0LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFk OHMxZltXUklURShvZmZzZXQ9NjE2MDM4NCwgbGVuZ3RoPTIwNDgpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNTQ2MDczNiwgbGVuZ3RoPTEzMTA3MildZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTYxOTMxNTIsIGxlbmd0aD0xNjM4 NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTIyODM5Mjk2LCBs ZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9 MjI5NzAzNjgsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yMzEwMTQ0MCwgbGVuZ3RoPTk4MzA0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgp OmFkOHMxZltXUklURShvZmZzZXQ9MjMzNjM1ODQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpn X3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMzQ5NDY1NiwgbGVuZ3RoPTEzMTA3Mild ZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTIzNjI1NzI4LCBsZW5n dGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjM3 NTY4MDAsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRF KG9mZnNldD0yMzg4Nzg3MiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTph ZDhzMWZbV1JJVEUob2Zmc2V0PTI0MDE4OTQ0LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192 ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjQxNTAwMTYsIGxlbmd0aD0xMzEwNzIpXWVy cm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNDI4MTA4OCwgbGVuZ3Ro PTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0NDEy MTYwLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShv ZmZzZXQ9MjQ1NDMyMzIsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4 czFmW1dSSVRFKG9mZnNldD0yNDY3NDMwNCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZz X2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0ODA1Mzc2LCBsZW5ndGg9MTMxMDcyKV1lcnJv ciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjQ5MzY0NDgsIGxlbmd0aD0x MzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNTA2NzUy MCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zm c2V0PTI1MTk4NTkyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMx ZltXUklURShvZmZzZXQ9MjUzMjk2NjQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNTQ2MDczNiwgbGVuZ3RoPTEzMTA3MildZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI1NTkxODA4LCBsZW5ndGg9MTE0 Njg4KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjU1OTE4MDgs IGxlbmd0aD0xMTQ2ODgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD02MjA5NTM2LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yMzE5OTc0NCwgbGVuZ3RoPTExNDY4OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDhzMWZbV1JJVEUob2Zmc2V0PTIzMzMwODE2LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpn X3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMzE5OTc0NCwgbGVuZ3RoPTExNDY4OCld ZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTY0NzE2ODAsIGxlbmd0 aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD03MTI3 MDQwLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShv ZmZzZXQ9Njg2NDg5NiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhz MWZbV1JJVEUob2Zmc2V0PTc2NTEzMjgsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMTAwNDI4OCwgbGVuZ3RoPTEzMTA3MildZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI1NzA2NDk2LCBsZW5ndGg9MTMx MDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjU4ODY3MjAs IGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD0yNjAzNDE3NiwgbGVuZ3RoPTExNDY4OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZb V1JJVEUob2Zmc2V0PTI2MzYxODU2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjYyNDcxNjgsIGxlbmd0aD0xMTQ2ODgpXWVycm9yID0g NgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNjU5MTIzMiwgbGVuZ3RoPTEzMTA3 MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI2NzM4Njg4LCBs ZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9 MjY4ODYxNDQsIGxlbmd0aD0xMTQ2ODgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yNzExNTUyMCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDhzMWZbV1JJVEUob2Zmc2V0PTI3MDAwODMyLCBsZW5ndGg9MTE0Njg4KV1lcnJvciA9IDYK Z192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjczNzc2NjQsIGxlbmd0aD0xMzEwNzIp XWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNzU3NDI3MiwgbGVu Z3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI3 MjQ2NTkyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklU RShvZmZzZXQ9Mjc3MDUzNDQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6 YWQ4czFmW1dSSVRFKG9mZnNldD0yNzgzNjQxNiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2Cmdf dmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI4MTE0OTQ0LCBsZW5ndGg9MTMxMDcyKV1l cnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9Mjc5Njc0ODgsIGxlbmd0 aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yODI0 NjAxNiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUo b2Zmc2V0PTI4NDA5ODU2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFk OHMxZltXUklURShvZmZzZXQ9Mjg3MjExNTIsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zm c19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMjgzOTI5NiwgbGVuZ3RoPTEzMTA3MildZXJy b3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTIyOTcwMzY4LCBsZW5ndGg9 MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjMxMDE0 NDAsIGxlbmd0aD05ODMwNCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zm c2V0PTIzMzYzNTg0LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMx ZltXUklURShvZmZzZXQ9MjM0OTQ2NTYsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yMzYyNTcyOCwgbGVuZ3RoPTEzMTA3MildZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTIzNzU2ODAwLCBsZW5ndGg9MTMx MDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjM4ODc4NzIs IGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD0yNDAxODk0NCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZb V1JJVEUob2Zmc2V0PTI0MTUwMDE2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjQyODEwODgsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0g NgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNDQxMjE2MCwgbGVuZ3RoPTEzMTA3 MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0NTQzMjMyLCBs ZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9 MjQ2NzQzMDQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yNDgwNTM3NiwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDhzMWZbV1JJVEUob2Zmc2V0PTI0OTM2NDQ4LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYK Z192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjUwNjc1MjAsIGxlbmd0aD0xMzEwNzIp XWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNTE5ODU5MiwgbGVu Z3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI1 MzI5NjY0LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklU RShvZmZzZXQ9MjU0NjA3MzYsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6 YWQ4czFmW1dSSVRFKG9mZnNldD0yNTU5MTgwOCwgbGVuZ3RoPTExNDY4OCldZXJyb3IgPSA2Cmdf dmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTY0NzE2ODAsIGxlbmd0aD0xMzEwNzIpXWVy cm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD03MTI3MDQwLCBsZW5ndGg9 MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9NzY1MTMy OCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zm c2V0PTIxMDA0Mjg4LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMx ZltXUklURShvZmZzZXQ9MjU3MDY0OTYsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNjAzNDE3NiwgbGVuZ3RoPTExNDY4OCldZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI2MzYxODU2LCBsZW5ndGg9MTMx MDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjY1OTEyMzIs IGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNl dD0yNjczODY4OCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZb V1JJVEUob2Zmc2V0PTI3MTE1NTIwLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjczNzc2NjQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0g NgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNzU3NDI3MiwgbGVuZ3RoPTEzMTA3 MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI3NzA1MzQ0LCBs ZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9 Mjc4MzY0MTYsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dS SVRFKG9mZnNldD0yNzk2NzQ4OCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDhzMWZbV1JJVEUob2Zmc2V0PTI4MjQ2MDE2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYK Z192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9Mjg3MjExNTIsIGxlbmd0aD0xMzEwNzIp XWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yODg2ODYwOCwgbGVu Z3RoPTk4MzA0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjMx OTk3NDQsIGxlbmd0aD0xMTQ2ODgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRF KG9mZnNldD02ODY0ODk2LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFk OHMxZltXUklURShvZmZzZXQ9MjU4ODY3MjAsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zm c19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yNjI0NzE2OCwgbGVuZ3RoPTExNDY4OCldZXJy b3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI2ODg2MTQ0LCBsZW5ndGg9 MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9MjcwMTcy MTYsIGxlbmd0aD05ODMwNCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zm c2V0PTI3MjQ2NTkyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMx ZltXUklURShvZmZzZXQ9MjgxMTQ5NDQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNgpnX3Zmc19k b25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD0yODQwOTg1NiwgbGVuZ3RoPTEzMTA3MildZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDhzMWZbV1JJVEUob2Zmc2V0PTI4NTQwOTI4LCBsZW5ndGg9MTE0 Njg4KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkOHMxZltXUklURShvZmZzZXQ9NjE0NDAwMCwg bGVuZ3RoPTIwNDgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9mZnNldD02 NTUzNiwgbGVuZ3RoPTIwNDgpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQ4czFmW1dSSVRFKG9m ZnNldD0yODU0MDkyOCwgbGVuZ3RoPTEzMTA3MildZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDhz MWZbV1JJVEUob2Zmc2V0PTI4ODY4NjA4LCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKcGFuaWM6 IHZpbnZhbGJ1ZjogZGlydHkgYnVmcwpVcHRpbWU6IDRtNDRzCkNhbm5vdCBkdW1wLiBObyBkdW1w IGRldmljZSBkZWZpbmVkLgpBdXRvbWF0aWMgcmVib290IGluIDE1IHNlY29uZHMgLSBwcmVzcyBh IGtleSBvbiB0aGUgY29uc29sZSB0byBhYm9ydAotLT4gUHJlc3MgYSBrZXkgb24gdGhlIGNvbnNv bGUgdG8gcmVib290LAotLT4gb3Igc3dpdGNoIG9mZiB0aGUgc3lzdGVtIG5vdy4KCg== ------=_Part_23893_21770539.1144073053219 Content-Type: application/octet-stream; name="panic.sii.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="panic.sii.log" X-Attachment-Id: f_elkv6au9 YXRhOTogcmVpbml0aW5nIGNoYW5uZWwgLi4KYXRhOTogRElTQ09OTkVDVCByZXF1ZXN0ZWQKYXRh OTogU0FUQSBjb25uZWN0IHJlYWR5IHRpbWU9MjAwbXMKYXRhOTogc2F0YV9jb25uZWN0IGRldmlj ZXM9MHgxPEFUQV9NQVNURVI+CnN1YmRpc2sxODogZGV0YWNoZWQKYWQxODogZGV0YWNoZWQKYXRh OTogRElTQ09OTkVDVEVECmdfdmZzX2RvbmUoKTphZDE4czFmW1dSSVRFKG9mZnNldD0zMjA2MzQ4 OCwgbGVuZ3RoPTk4MzA0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWZbV1JJVEUob2Zm c2V0PTY1NTM2LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFmW1dS SVRFKG9mZnNldD02MTQ0MDAwLCBsZW5ndGg9MjA0OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTph ZDE4czFmW1dSSVRFKG9mZnNldD0zMTk2NTE4NCwgbGVuZ3RoPTk4MzA0KV1lcnJvciA9IDYKdW5r bm93bjogV0FSTklORyAtIFNFVEZFQVRVUkVTIFNFVCBUUkFOU0ZFUiBNT0RFIHRhc2txdWV1ZSB0 aW1lb3V0IC0gY29tcGxldGluZyByZXF1ZXN0IGRpcmVjdGx5CmdfdmZzX2RvbmUoKTphZDE4czFl W1dSSVRFKG9mZnNldD02MTQ0MDAwLCBsZW5ndGg9MjA0OCldZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDE4czFlW1dSSVRFKG9mZnNldD02NTUzNiwgbGVuZ3RoPTIwNDgpXWVycm9yID0gNgp1bmtu b3duOiBXQVJOSU5HIC0gU0VURkVBVFVSRVMgRU5BQkxFIFJDQUNIRSB0YXNrcXVldWUgdGltZW91 dCAtIGNvbXBsZXRpbmcgcmVxdWVzdCBkaXJlY3RseQp1bmtub3duOiBXQVJOSU5HIC0gU0VURkVB VFVSRVMgRU5BQkxFIFdDQUNIRSB0YXNrcXVldWUgdGltZW91dCAtIGNvbXBsZXRpbmcgcmVxdWVz dCBkaXJlY3RseQpnX3Zmc19kb25lKCk6YWQxOHMxZltXUklURShvZmZzZXQ9NjE2MDM4NCwgbGVu Z3RoPTIwNDgpXWVycm9yID0gNgp1bmtub3duOiBXQVJOSU5HIC0gU0VUX01VTFRJIHRhc2txdWV1 ZSB0aW1lb3V0IC0gY29tcGxldGluZyByZXF1ZXN0IGRpcmVjdGx5CmF0YTk6IHJlaW5pdCBkb25l IC4uCnVua25vd246IFRJTUVPVVQgLSBXUklURV9ETUEgcmV0cnlpbmcgKDEgcmV0cnkgbGVmdCkg TEJBPTMzNzA5MDIzCnVua25vd246IFdBUk5JTkcgLSBTRVRGRUFUVVJFUyBTRVQgVFJBTlNGRVIg TU9ERSBmcmVlaW5nIHRhc2txdWV1ZSB6b21iaWUgcmVxdWVzdAp1bmtub3duOiBXQVJOSU5HIC0g U0VURkVBVFVSRVMgRU5BQkxFIFJDQUNIRSBmcmVlaW5nIHRhc2txdWV1ZSB6b21iaWUgcmVxdWVz dAp1bmtub3duOiBXQVJOSU5HIC0gU0VURkVBVFVSRVMgRU5BQkxFIFdDQUNIRSBmcmVlaW5nIHRh c2txdWV1ZSB6b21iaWUgcmVxdWVzdAp1bmtub3duOiBXQVJOSU5HIC0gU0VUX01VTFRJIGZyZWVp bmcgdGFza3F1ZXVlIHpvbWJpZSByZXF1ZXN0CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9m ZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQx OHMxZVtXUklURShvZmZzZXQ9ODY2ODk1NDYyNCwgbGVuZ3RoPTIwNDgpXWVycm9yID0gNgpnX3Zm c19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1l cnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxl bmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04 NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtX UklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9 MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1 MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUo b2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTph ZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpn X3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0 KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5Mjgs IGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNl dD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMx ZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNf ZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJy b3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5n dGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2 OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJ VEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUo KTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0g NgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2 Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5 MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9m ZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQx OHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192 ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCld ZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBs ZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9 ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVb V1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2Rv bmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9y ID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3Ro PTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2Njkw NTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRF KG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6 YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYK Z192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4 NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4 LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZz ZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThz MWZbV1JJVEUob2Zmc2V0PTkwNzY3MzYsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2Rv bmUoKTphZDE4czFmW1dSSVRFKG9mZnNldD0zMjA2MzQ4OCwgbGVuZ3RoPTk4MzA0KV1lcnJvciA9 IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0x NjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUy OTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShv ZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFk MThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2Cmdf dmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQp XWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwg bGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWZbV1JJVEUob2Zmc2V0 PTYxOTMxNTIsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFmW1dS SVRFKG9mZnNldD0zMTk2NTE4NCwgbGVuZ3RoPTk4MzA0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgp OmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2 CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYz ODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1Mjky OCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zm c2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4 czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zm c19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1l cnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxl bmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04 NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtX UklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9u ZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9 MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1 MjkyOCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUo b2Zmc2V0PTg2NjkwNTI5MjgsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTph ZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpn X3Zmc19kb25lKCk6YWQxOHMxZVtXUklURShvZmZzZXQ9ODY2OTA1MjkyOCwgbGVuZ3RoPTE2Mzg0 KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJVEUob2Zmc2V0PTg2NjkwNTI5Mjgs IGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1JFQUQob2Zmc2V0 PTczMjA1MzUwNDAsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2RvbmUoKTphZDE4czFl W1JFQUQob2Zmc2V0PTc1MTMxNzgxMTIsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CmdfdmZzX2Rv bmUoKTphZDE4czFlW1JFQUQob2Zmc2V0PTc4OTg0NjQyNTYsIGxlbmd0aD0xNjM4NCldZXJyb3Ig PSA2CmdfdmZzX2RvbmUoKTphZDE4czFlW1dSSVRFKG9mZnNldD04NjY5MDUyOTI4LCBsZW5ndGg9 MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtSRUFEKG9mZnNldD02NTQ5OTYy NzUyLCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtSRUFEKG9m ZnNldD02NzQyNjA1ODI0LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQx OHMxZVtSRUFEKG9mZnNldD03MTI3ODkxOTY4LCBsZW5ndGg9MTYzODQpXWVycm9yID0gNgpnX3Zm c19kb25lKCk6YWQxOHMxZVtSRUFEKG9mZnNldD03ODk4NDY0MjU2LCBsZW5ndGg9MTYzODQpXWVy cm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtSRUFEKG9mZnNldD05NDM5NjA4ODMyLCBsZW5n dGg9MTYzODQpXWVycm9yID0gNgpnX3Zmc19kb25lKCk6YWQxOHMxZVtSRUFEKG9mZnNldD0xMjUy MTg5Nzk4NCwgbGVuZ3RoPTE2Mzg0KV1lcnJvciA9IDYKZ192ZnNfZG9uZSgpOmFkMThzMWVbV1JJ VEUob2Zmc2V0PTEzNDg2NDg5NjAsIGxlbmd0aD0xNjM4NCldZXJyb3IgPSA2CnBhbmljOiB2aW52 YWxidWY6IGRpcnR5IGJ1ZnMKVXB0aW1lOiA1bTlzCkNhbm5vdCBkdW1wLiBObyBkdW1wIGRldmlj ZSBkZWZpbmVkLgpBdXRvbWF0aWMgcmVib290IGluIDE1IHNlY29uZHMgLSBwcmVzcyBhIGtleSBv biB0aGUgY29uc29sZSB0byBhYm9ydAotLT4gUHJlc3MgYSBrZXkgb24gdGhlIGNvbnNvbGUgdG8g cmVib290LAotLT4gb3Igc3dpdGNoIG9mZiB0aGUgc3lzdGVtIG5vdy4KCg== ------=_Part_23893_21770539.1144073053219 Content-Type: application/octet-stream; name="boot.sii.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot.sii.log" X-Attachment-Id: f_elkvc2hd U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAwMDAwMDA5ZjQwMApT TUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMDAwMGYwMDAwIGxlbj0wMDAwMDAwMDAwMDEwMDAwClNN QVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmVjMDAwMDAgbGVuPTAwMDAwMDAwMDAwMDEwMDAKU01B UCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZWUwMDAwMCBsZW49MDAwMDAwMDAwMDAwMTAwMApTTUFQ IHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZmZmYwMDAwIGxlbj0wMDAwMDAwMDAwMDEwMDAwClNNQVAg dHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwOWY4MDAgbGVuPTAwMDAwMDAwMDAwMDA4MDAKU01BUCB0 eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDEwMDAwMCBsZW49MDAwMDAwMDAzZmVmMDAwMApTTUFQIHR5 cGU9MDMgYmFzZT0wMDAwMDAwMDNmZmYzMDAwIGxlbj0wMDAwMDAwMDAwMDBkMDAwClNNQVAgdHlw ZT0wNCBiYXNlPTAwMDAwMDAwM2ZmZjAwMDAgbGVuPTAwMDAwMDAwMDAwMDMwMDAKQ29weXJpZ2h0 IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAx OTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CiAgICAg ICAgVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0 cyByZXNlcnZlZC4KRnJlZUJTRCA3LjAtQ1VSUkVOVCAjMjM6IFRodSBNYXIgMzAgMjM6NDk6NTcg TVNEIDIwMDYKICAgIHJvb3RAZ3JlZW46L3Vzci9vYmovdXNyL3NyYy9zeXMvZ3JlZW4KUHJlbG9h ZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4ZmZmZmZmZmY4MDcxYjAw MC4KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4uIGk4MjU0IGNsb2NrOiAxMTkzMjczIEh6CkNMS19V U0VfSTgyNTRfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVl bmN5ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNh bGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAxODA4ODExNDA1IEh6CkNQVTogQU1E IEF0aGxvbih0bSkgNjQgUHJvY2Vzc29yIDI4MDArICgxODA4LjgxLU1IeiBLOC1jbGFzcyBDUFUp CiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHhmYzAgIFN0ZXBwaW5nID0gMAogIEZl YXR1cmVzPTB4NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMs U0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0Uy PgogIEFNRCBGZWF0dXJlcz0weGUwNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxMTSwzRE5vdyssM0RO b3c+CkwxIDJNQiBkYXRhIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSAyTUIg aW5zdHJ1Y3Rpb24gVExCOiA4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBkYXRh IFRMQjogMzIgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgNEtCIGluc3RydWN0aW9uIFRM QjogMzIgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgZGF0YSBjYWNoZTogNjQga2J5dGVz LCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUKTDEgaW5zdHJ1 Y3Rpb24gY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5 IGFzc29jaWF0aXZlCkwyIDJNQiB1bmlmaWVkIFRMQjogMCBlbnRyaWVzLCBkaXNhYmxlZC9ub3Qg cHJlc2VudApMMiA0S0IgZGF0YSBUTEI6IDUxMiBlbnRyaWVzLCA0LXdheSBhc3NvY2lhdGl2ZQpM MiA0S0IgaW5zdHJ1Y3Rpb24gVExCOiA1MTIgZW50cmllcywgNC13YXkgYXNzb2NpYXRpdmUKTDIg dW5pZmllZCBjYWNoZTogNTEyIGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDE2 LXdheSBhc3NvY2lhdGl2ZQp1c2FibGUgbWVtb3J5ICA9IDEwNjU4MzY1NDQgKDEwMTYgTUIpClBo eXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAw MDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykKMHgwMDAwMDAwMDAwODE4MDAwIC0gMHgw MDAwMDAwMDNlMWFmZmZmLCAxMDMzNDY5OTUyIGJ5dGVzICgyNTIzMTIgcGFnZXMpCmF2YWlsIG1l bW9yeSA9IDEwMjc2NjE4MjQgKDk4MCBNQikKQUNQSSBBUElDIFRhYmxlOiA8TnZpZGlhIEFXUkRB Q1BJPgpBUElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMiwg SW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlB J3MgLT4gaW50cGluIDAKaW9hcGljMDogaW50cGluIDAgLT4gRXh0SU5UIChlZGdlLCBoaWdoKQpp b2FwaWMwOiBpbnRwaW4gMSAtPiBJU0EgSVJRIDEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBp biAyIC0+IElTQSBJUlEgMiAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDMgLT4gSVNBIElS USAzIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQgKGVkZ2UsIGhp Z2gpCmlvYXBpYzA6IGludHBpbiA1IC0+IElTQSBJUlEgNSAoZWRnZSwgaGlnaCkKaW9hcGljMDog aW50cGluIDYgLT4gSVNBIElSUSA2IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNyAtPiBJ U0EgSVJRIDcgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA4IC0+IElTQSBJUlEgOCAoZWRn ZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDkgLT4gSVNBIElSUSA5IChlZGdlLCBoaWdoKQppb2Fw aWMwOiBpbnRwaW4gMTAgLT4gSVNBIElSUSAxMCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGlu IDExIC0+IElTQSBJUlEgMTEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxMiAtPiBJU0Eg SVJRIDEyIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTMgLT4gSVNBIElSUSAxMyAoZWRn ZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDE0IC0+IElTQSBJUlEgMTQgKGVkZ2UsIGhpZ2gpCmlv YXBpYzA6IGludHBpbiAxNSAtPiBJU0EgSVJRIDE1IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRw aW4gMTYgLT4gUENJIElSUSAxNiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDE3IC0+IFBD SSBJUlEgMTcgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxOCAtPiBQQ0kgSVJRIDE4IChs ZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMTkgLT4gUENJIElSUSAxOSAobGV2ZWwsIGxvdykK aW9hcGljMDogaW50cGluIDIwIC0+IFBDSSBJUlEgMjAgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGlu dHBpbiAyMSAtPiBQQ0kgSVJRIDIxIChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMjIgLT4g UENJIElSUSAyMiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIzIC0+IFBDSSBJUlEgMjMg KGxldmVsLCBsb3cpCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlv YXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKaW9hcGljMDogaW50cGluIDIgdHJpZ2dl cjogZWRnZQppb2FwaWMwOiBpbnRwaW4gMiBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQg b3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZl bAppb2FwaWMwOiBpbnRwaW4gOSBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJp ZGU6IHNvdXJjZSAxNCwgaXJxIDE0CmlvYXBpYzA6IGludHBpbiAxNCB0cmlnZ2VyOiBlZGdlCmlv YXBpYzA6IGludHBpbiAxNCBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6 IHNvdXJjZSAxNSwgaXJxIDE1CmlvYXBpYzA6IGludHBpbiAxNSB0cmlnZ2VyOiBlZGdlCmlvYXBp YzA6IGludHBpbiAxNSBwb2xhcml0eTogaGlnaApsYXBpYzA6IFJvdXRpbmcgTk1JIC0+IExJTlQx CmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6 CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNDAwMTAgTERSOiAweDAwMDAwMDAwIERG UjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjog MHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgw MDAwMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwCm1lbTogPG1lbW9yeT4KbmZz bG9jazogcHNldWRvLWRldmljZQpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5k b206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KaW86IDxJL08+CmFjcGkwOiA8 TnZpZGlhIEFXUkRBQ1BJPiBvbiBtb3RoZXJib2FyZAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5 IChJU0EgSVJRIDkpIHRvIHZlY3RvciA0OAphY3BpMDogW01QU0FGRV0KcGNpX29wZW4oMSk6ICAg IG1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwMDg4OApwY2lfb3BlbigxYSk6ICAg bW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOiAgIGRldmljZSAw IFtjbGFzcz0wNjAwMDBdIFtoZHI9MDBdIGlzIHRoZXJlIChpZD0wMGUxMTBkZSkKQWNwaU9zRGVy aXZlUGNpSWQ6IGJ1cyAwIGRldiAxIGZ1bmMgMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkK QWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxIGZ1bmMgMApwY2lfbGluazA6IExpbmtzIGFm dGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazA6IExpbmtzIGFm dGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg ICAxMCAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMDogTGlu a3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogTGlua3MgYWZ0 ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogTGlua3MgYWZ0 ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg IDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiBMaW5r cyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiBMaW5rcyBhZnRl ciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA5ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiBMaW5rcyBhZnRl ciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAg IDkgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtz IGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazM6IExpbmtzIGFmdGVy IGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazM6IExpbmtzIGFmdGVy IGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAx MCAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogTGlua3Mg YWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNDogTGlua3MgYWZ0ZXIg aW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAgOSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNDogTGlua3MgYWZ0ZXIg aW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA5 ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiBMaW5rcyBhZnRlciBp bml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEwICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiBMaW5rcyBhZnRlciBp bml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazU6IExpbmtzIGFm dGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazY6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazY6IExpbmtzIGFmdGVyIGlu aXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNjogTGlua3MgYWZ0 ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNzogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNzogTGlua3MgYWZ0ZXIgaW5p dGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRl ciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms4OiBMaW5rcyBhZnRlciBpbml0 aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms4OiBMaW5rcyBhZnRlciBpbml0 aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazg6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazk6IExpbmtzIGFmdGVyIGluaXRp YWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTEgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazk6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rOTogTGlua3MgYWZ0ZXIg ZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTA6IExpbmtzIGFmdGVyIGluaXRp YWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEwOiBMaW5rcyBhZnRlciBpbml0 aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEwOiBMaW5rcyBhZnRl ciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMTogTGlua3MgYWZ0ZXIgaW5p dGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAgOSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTE6IExpbmtzIGFmdGVyIGlu aXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAgOSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTE6IExpbmtzIGFm dGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEyOiBMaW5rcyBhZnRlciBp bml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEwICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMjogTGlua3MgYWZ0ZXIg aW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEw ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxMjogTGlua3Mg YWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTM6IExpbmtzIGFmdGVy IGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEzOiBMaW5rcyBhZnRl ciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazEzOiBMaW5r cyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNDogTGlua3MgYWZ0 ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTQ6IExpbmtzIGFm dGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTQ6IExp bmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE1OiBMaW5rcyBh ZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNTogTGlua3Mg YWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNTog TGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTY6IExpbmtz IGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE2OiBMaW5r cyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE2 OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxNzogTGlu a3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg ICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTc6IExp bmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5r MTc6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazE4OiBM aW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMTYKcGNpX2xpbmsxODogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxp ZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAg MTYKcGNpX2xpbmsxODogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2CnBjaV9saW5rMTk6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAg ICAwICAxNwpwY2lfbGluazE5OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAxNwpwY2lfbGluazE5 OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMTcKcGNpX2xpbmsyMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE4CnBjaV9s aW5rMjA6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE4CnBjaV9saW5rMjA6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAxOApwY2lfbGluazIxOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTkKcGNpX2xpbmsyMTogTGlua3Mg YWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMTkKcGNpX2xpbmsyMTogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDE5CnBjaV9saW5r MjI6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAgMTYgICBOICAgICAwICAxNgpwY2lfbGluazIyOiBMaW5rcyBhZnRlciBpbml0aWFs IHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTYgICBOICAg ICAwICAxNgpwY2lfbGluazIyOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMTYKcGNpX2xpbmsyMzogTGlua3MgYWZ0 ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjM6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRh dGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIw IDIxIDIyCnBjaV9saW5rMjM6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI0OiBMaW5r cyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2 YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgMjAgMjEgMjIKcGNpX2xpbmsyNDogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjU6 IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI1OiBMaW5rcyBhZnRlciBpbml0 aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI1OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xp bmsyNjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjY6IExpbmtzIGFmdGVy IGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1 NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMjY6IExpbmtzIGFmdGVyIGRpc2FibGU6Cklu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpw Y2lfbGluazI3OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNzogTGlua3Mg YWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmsyNzogTGlua3MgYWZ0ZXIgZGlzYWJs ZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIx IDIyCnBjaV9saW5rMjg6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI4OiBM aW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazI4OiBMaW5rcyBhZnRlciBk aXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAg MjAgMjEgMjIKcGNpX2xpbmsyOTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICAgIDAgICAyMyAgIE4gICAgIDAgIDIzCnBjaV9saW5rMjk6IExp bmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgICAyMyAgIE4gICAgIDAgIDIzCnBjaV9saW5rMjk6IExpbmtzIGFmdGVyIGRpc2FibGU6 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMwpwY2lf bGluazMwOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszMDogTGlua3MgYWZ0 ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszMDogTGlua3MgYWZ0ZXIgZGlzYWJsZToK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIy CnBjaV9saW5rMzE6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazMxOiBMaW5r cyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazMxOiBMaW5rcyBhZnRlciBkaXNh YmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAg MjEgMjIKcGNpX2xpbmszMjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzI6 IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzI6IExpbmtzIGFmdGVy IGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAw ICAyMCAyMSAyMgpwY2lfbGluazMzOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xp bmszMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszMzogTGlua3Mg YWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDIwIDIxIDIyCnBjaV9saW5rMzQ6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6Cklu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpw Y2lfbGluazM0OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpwY2lfbGluazM0OiBM aW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1 ICAgTiAgICAgMCAgMjAgMjEgMjIKcGNpX2xpbmszNTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9i ZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIx IDIyCnBjaV9saW5rMzU6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyCnBjaV9saW5r MzU6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMgpBQ1BJIHRpbWVyOiAxLzEgMS8xIDEvMSAxLzEgMS8x IDEvMSAxLzEgMS8xIDEvMSAxLzEgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVl bmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0 IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BV PiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8 QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYsMHhjZjAtMHhjZjMgb24gYWNw aTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKZm91 bmQtPiB2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMGUxLCByZXZpZD0weGExCiAgICAgICAgYnVzPTAs IHNsb3Q9MCwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQogICAgICAgIG1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJh c2UgZTgwMDAwMDAsIHNpemUgMjUsIGVuYWJsZWQKZm91bmQtPiB2ZW5kb3I9MHgxMGRlLCBkZXY9 MHgwMGUwLCByZXZpZD0weGEyCiAgICAgICAgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCiAgICAgICAg Y2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQogICAgICAgIGNtZHJlZz0weDAw MGYsIHN0YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3Vu ZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTQsIHJldmlkPTB4YTEKICAgICAgICBidXM9MCwg c2xvdD0xLCBmdW5jPTEKICAgICAgICBjbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0xCiAgICAgICAgY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChk d29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMp LCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9OQogICAgICAgIHBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGUwMDAsIHNpemUgIDUsIGVuYWJsZWQKICAgICAgICBt YXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxYzAwLCBzaXplICA2LCBlbmFibGVk CiAgICAgICAgbWFwWzI0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMjAwMCwgc2l6ZSAg NiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEgKHNyYyBcX1NCXy5Q Q0kwLkFQQ1M6MCkKcGNpYjA6IHNsb3QgMSBJTlRBIHJvdXRlZCB0byBpcnEgMjMgdmlhIFxfU0Jf LlBDSTAuQVBDUwpmb3VuZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTcsIHJldmlkPTB4YTEK ICAgICAgICBidXM9MCwgc2xvdD0yLCBmdW5jPTAKICAgICAgICBjbGFzcz0wYy0wMy0xMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwYjAs IGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQogICAgICAgIGludHBpbj1hLCBp cnE9MTAKICAgICAgICBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQg RDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGVmMDAyMDAwLCBzaXpl IDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQSAoc3JjIFxfU0Jf LlBDSTAuQVBDRjowKQpwY2lfbGluazIzOiBQaWNrZWQgSVJRIDIwIHdpdGggd2VpZ2h0IDAKaW9h cGljMDogQ2hhbmdpbmcgcG9sYXJpdHkgZm9yIHBpbiAyMCB0byBoaWdoCnBjaWIwOiBzbG90IDIg SU5UQSByb3V0ZWQgdG8gaXJxIDIwIHZpYSBcX1NCXy5QQ0kwLkFQQ0YKZm91bmQtPiB2ZW5kb3I9 MHgxMGRlLCBkZXY9MHgwMGU3LCByZXZpZD0weGExCiAgICAgICAgYnVzPTAsIHNsb3Q9MiwgZnVu Yz0xCiAgICAgICAgY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQogICAgICAg IGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAg ICAgIGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4 MDEgKDI1MCBucykKICAgICAgICBpbnRwaW49YiwgaXJxPTEwCiAgICAgICAgcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSAx LCByYW5nZSAzMiwgYmFzZSBlZjAwMzAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hl ZCBlbnRyeSBmb3IgMC4yLklOVEIgKHNyYyBcX1NCXy5QQ0kwLkFQQ0c6MCkKcGNpX2xpbmsyNDog UGlja2VkIElSUSAyMSB3aXRoIHdlaWdodCAwCmlvYXBpYzA6IENoYW5naW5nIHBvbGFyaXR5IGZv ciBwaW4gMjEgdG8gaGlnaApwY2liMDogc2xvdCAyIElOVEIgcm91dGVkIHRvIGlycSAyMSB2aWEg XF9TQl8uUENJMC5BUENHCmZvdW5kLT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDBlOCwgcmV2aWQ9 MHhhMgogICAgICAgIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MgogICAgICAgIGNsYXNzPTBjLTAzLTIw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4 MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCiAgICAgICAgaW50cGlu PWMsIGlycT0xMAogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3Vy cmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWYwMDQwMDAs IHNpemUgIDgsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRDIChzcmMg XF9TQl8uUENJMC5BUENMOjApCnBjaV9saW5rMzA6IFBpY2tlZCBJUlEgMjIgd2l0aCB3ZWlnaHQg MAppb2FwaWMwOiBDaGFuZ2luZyBwb2xhcml0eSBmb3IgcGluIDIyIHRvIGhpZ2gKcGNpYjA6IHNs b3QgMiBJTlRDIHJvdXRlZCB0byBpcnEgMjIgdmlhIFxfU0JfLlBDSTAuQVBDTApmb3VuZC0+IHZl bmRvcj0weDEwZGUsIGRldj0weDAwZWEsIHJldmlkPTB4YTEKICAgICAgICBidXM9MCwgc2xvdD02 LCBmdW5jPTAKICAgICAgICBjbGFzcz0wNC0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCiAg ICAgICAgY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMp CiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAgbnMpLCBtYXhs YXQ9MHgwNSAoMTI1MCBucykKICAgICAgICBpbnRwaW49YSwgaXJxPTExCiAgICAgICAgcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTog dHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwYjgwMCwgc2l6ZSAgOCwgZW5hYmxlZAogICAgICAg IG1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGJjMDAsIHNpemUgIDcsIGVuYWJs ZWQKICAgICAgICBtYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGVmMDAwMDAwLCBzaXpl IDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjYuSU5UQSAoc3JjIFxfU0Jf LlBDSTAuQVBDSjowKQpwY2lfbGluazI3OiBQaWNrZWQgSVJRIDIwIHdpdGggd2VpZ2h0IDEKcGNp YjA6IHNsb3QgNiBJTlRBIHJvdXRlZCB0byBpcnEgMjAgdmlhIFxfU0JfLlBDSTAuQVBDSgpmb3Vu ZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTUsIHJldmlkPTB4YTIKICAgICAgICBidXM9MCwg c2xvdD04LCBmdW5jPTAKICAgICAgICBjbGFzcz0wMS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRl dj0wCiAgICAgICAgY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChk d29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMp LCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAogICAgICAgIG1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAw MGYwMDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPiB2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMGUz LCByZXZpZD0weGEyCiAgICAgICAgYnVzPTAsIHNsb3Q9MTAsIGZ1bmM9MAogICAgICAgIGNsYXNz PTAxLTAxLTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDA1LCBz dGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCiAgICAg ICAgaW50cGluPWEsIGlycT0xMQogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDA5 ZjAsIHNpemUgIDMsIGVuYWJsZWQKICAgICAgICBtYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDAwYmYwLCBzaXplICAyLCBlbmFibGVkCiAgICAgICAgbWFwWzE4XTogdHlwZSA0LCBy YW5nZSAzMiwgYmFzZSAwMDAwMDk3MCwgc2l6ZSAgMywgZW5hYmxlZAogICAgICAgIG1hcFsxY106 IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDBiNzAsIHNpemUgIDIsIGVuYWJsZWQKICAgICAg ICBtYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBkODAwLCBzaXplICA0LCBlbmFi bGVkCiAgICAgICAgbWFwWzI0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZGMwMCwgc2l6 ZSAgNywgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xMC5JTlRBIChzcmMgXF9T Ql8uUENJMC5BUFNKOjApCnBjaV9saW5rMzU6IFBpY2tlZCBJUlEgMjEgd2l0aCB3ZWlnaHQgMQpw Y2liMDogc2xvdCAxMCBJTlRBIHJvdXRlZCB0byBpcnEgMjEgdmlhIFxfU0JfLlBDSTAuQVBTSgpm b3VuZC0+IHZlbmRvcj0weDEwZGUsIGRldj0weDAwZTIsIHJldmlkPTB4YTIKICAgICAgICBidXM9 MCwgc2xvdD0xMSwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwg bWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MTAgKDQ4MCBucyksIG1pbmdudD0weDBjICgz MDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4gdmVuZG9yPTB4MTBkZSwgZGV2PTB4 MDBlZCwgcmV2aWQ9MHhhMgogICAgICAgIGJ1cz0wLCBzbG90PTE0LCBmdW5jPTAKICAgICAgICBj bGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCiAgICAgICAgY21kcmVnPTB4MDAw Nywgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4gdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMCwgcmV2aWQ9MHgwMAogICAgICAgIGJ1cz0w LCBzbG90PTI0LCBmdW5jPTAKICAgICAgICBjbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0w IChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4gdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMSwg cmV2aWQ9MHgwMAogICAgICAgIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTEKICAgICAgICBjbGFzcz0w Ni0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4gdmVu ZG9yPTB4MTAyMiwgZGV2PTB4MTEwMiwgcmV2aWQ9MHgwMAogICAgICAgIGJ1cz0wLCBzbG90PTI0 LCBmdW5jPTIKICAgICAgICBjbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCiAg ICAgICAgY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMp CiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4gdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMywgcmV2aWQ9MHgw MAogICAgICAgIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTMKICAgICAgICBjbGFzcz0wNi0wMC0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MDAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmFncDA6IDxOVklESUEgbkZvcmNl My0yNTAgQUdQIENvbnRyb2xsZXI+IG9uIGhvc3RiMAphZ3AwOiAxIE1pc2NlbGxhbmVvdXMgQ29u dHJvbCB1bml0KHMpIGZvdW5kLgphZ3AwOiBBcGVydHVyZSBCYXNlWzBdOiAweDAwMDAwMDc0Cmhv c3RiMDogUmVzZXJ2ZWQgMHgyMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhl ODAwMDAwMAphZ3AwOiBhbGxvY2F0aW5nIEdBVFQgZm9yIGFwZXJ0dXJlIG9mIHNpemUgMzJNCmlz YWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1 cz4gb24gaXNhYjAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMS4xIChubyBk cml2ZXIgYXR0YWNoZWQpCm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1l bSAweGVmMDAyMDAwLTB4ZWYwMDJmZmYgaXJxIDIwIGF0IGRldmljZSAyLjAgb24gcGNpMApvaGNp MDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlZjAwMjAw MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkgdG8gdmVjdG9yIDQ5Cm9o Y2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9y dAp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVzYjA6IFVT QiByZXZpc2lvbiAxLjAKdWh1YjA6IDxuVmlkaWEgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDQgcG9ydHMgd2l0aCA0IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+ IG1lbSAweGVmMDAzMDAwLTB4ZWYwMDNmZmYgaXJxIDIxIGF0IGRldmljZSAyLjEgb24gcGNpMApv aGNpMTogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlZjAw MzAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElSUSAyMSkgdG8gdmVjdG9yIDUw Cm9oY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3Vw cG9ydAp1c2IxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kxCnVzYjE6 IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IDxuVmlkaWEgT0hDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6IDQgcG9ydHMgd2l0aCA0IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8TlZJRElBIG5Gb3JjZTMgMjUwIFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4ZWYwMDQwMDAtMHhlZjAwNDBmZiBpcnEgMjIgYXQgZGV2aWNlIDIu MiBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAz IGF0IDB4ZWYwMDQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjIgKFBDSSBJUlEgMjIpIHRv IHZlY3RvciA1MQplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMjogRUhDSSB2ZXJzaW9uIDEuMAp1 c2IyOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDQgcG9ydHMgZWFjaDogdXNiMCB1c2IxCnVzYjI6 IDxOVklESUEgbkZvcmNlMyAyNTAgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAp1c2IyOiBV U0IgcmV2aXNpb24gMi4wCnVodWIyOiA8blZpZGlhIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IyCnVodWIyOiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApwY20wOiA8blZpZGlhIG5Gb3JjZTMgMjUwPiBwb3J0IDB4Yjgw MC0weGI4ZmYsMHhiYzAwLTB4YmM3ZiBtZW0gMHhlZjAwMDAwMC0weGVmMDAwZmZmIGlycSAyMCBh dCBkZXZpY2UgNi4wIG9uIHBjaTAKcGNtMDogUmVzZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgNCBhdCAweGI4MDAKcGNtMDogUmVzZXJ2ZWQgMHg4MCBieXRlcyBmb3IgcmlkIDB4 MTQgdHlwZSA0IGF0IDB4YmMwMApwY20wOiBbTVBTQUZFXQpwY20wOiA8QXZhbmNlIExvZ2ljIEFM Qzg1MCBBQzk3IENvZGVjIChpZCA9IDB4NDE0YzQ3OTApPgpwY20wOiBDb2RlYyBmZWF0dXJlcyA1 IGJpdCBtYXN0ZXIgdm9sdW1lLCBubyAzRCBTdGVyZW8gRW5oYW5jZW1lbnQKcGNtMDogUHJpbWFy eSBjb2RlYyBleHRlbmRlZCBmZWF0dXJlcyBkb3VibGUgcmF0ZSBQQ00sIHJlc2VydmVkIDEsIGNl bnRlciBEQUMsIHN1cnJvdW5kIERBQywgTEZFIERBQywgcmVzZXJ2ZWQgNQpwY20wOiBhYzk3IGNv ZGVjIGRhYyByZWFkeSBjb3VudDogMApwY20wOiBzbmRidWZfc2V0bWFwIDNkYjk1MDAwLCA0MDAw OyAweGZmZmZmZmZmYTA0YTUwMDAgLT4gM2RiOTUwMDAKcGNtMDogc25kYnVmX3NldG1hcCAzZGI5 MTAwMCwgNDAwMDsgMHhmZmZmZmZmZmEwNGE5MDAwIC0+IDNkYjkxMDAwCmF0YXBjaTA6IDxuVmlk aWEgbkZvcmNlMyBQcm8gVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2 LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZjAwMC0weGYwMGYgYXQgZGV2aWNlIDguMCBvbiBwY2kwCmF0 YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGYwMDAK YXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5 dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMg b3N0YXQwPTUwIG9zdGF0MT0wMAphdGEwOiBzdGF0MD0weDkwIGVycj0weDkwIGxzYj0weDkwIG1z Yj0weDkwCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDog c3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3Rh dDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8QVRBX01BU1RFUj4KaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIHZlY3RvciA1MgphdGEwOiBbTVBTQUZFXQphdGExOiA8 QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9y IHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9y IHJpZCAweDFjIHR5cGUgNCBhdCAweDM3NgphdGExOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9 NTAgb3N0YXQxPTAwCmF0YTE6IHN0YXQwPTB4MTAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIK YXRhMTogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGExOiByZXNldCB0 cDIgc3RhdDA9MTAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPgppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAxNSAoSVNBIElSUSAxNSkgdG8gdmVjdG9yIDUzCmF0YTE6IFtNUFNBRkVd CmF0YXBjaTE6IDxuVmlkaWEgbkZvcmNlMyBQcm8gU0FUQTE1MCBjb250cm9sbGVyPiBwb3J0IDB4 OWYwLTB4OWY3LDB4YmYwLTB4YmYzLDB4OTcwLTB4OTc3LDB4YjcwLTB4YjczLDB4ZDgwMC0weGQ4 MGYsMHhkYzAwLTB4ZGM3ZiBpcnEgMjEgYXQgZGV2aWNlIDEwLjAgb24gcGNpMAphdGFwY2kxOiBS ZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhkODAwCmF0YXBjaTE6 IFtNUFNBRkVdCmF0YXBjaTE6IFJlc2VydmVkIDB4ODAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUg NCBhdCAweGRjMDAKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhcGNpMTogUmVz ZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHg5ZjAKYXRhcGNpMTogUmVz ZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhiZjAKYXRhMjogU0FUQSBj b25uZWN0IHJlYWR5IHRpbWU9MG1zCmF0YTI6IHNhdGFfY29ubmVjdCBkZXZpY2VzPTB4MTxBVEFf TUFTVEVSPgphdGEyOiBbTVBTQUZFXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQph dGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDk3MAph dGFwY2kxOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweGI3MAph dGEzOiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAwMDAwMDAwCmF0YTM6IFtNUFNBRkVdCnBjaWIxOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDExLjAgb24gcGNpMApwY2liMTogICBzZWNv bmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9P IGRlY29kZSAgICAgICAgMHg2MDAwLTB4NmZmZgpwY2liMTogICBtZW1vcnkgZGVjb2RlICAgICAw eGVhMDAwMDAwLTB4ZWJmZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhlMDAwMDAw MC0weGU3ZmZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IHBoeXNpY2Fs IGJ1cz0xCmZvdW5kLT4gdmVuZG9yPTB4MTAwMiwgZGV2PTB4NTE1NywgcmV2aWQ9MHgwMAogICAg ICAgIGJ1cz0xLCBzbG90PTAsIGZ1bmM9MAogICAgICAgIGNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDg3LCBzdGF0cmVnPTB4MDJiMCwgY2Fj aGVsbnN6PTggKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9 MHgwOCAoMjAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9 OQogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAog ICAgICAgIG1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2UgZTAwMDAwMDAsIHNpemUgMjcs IGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZTAwMDAwMDAt MHhlN2ZmZmZmZjogZ29vZAogICAgICAgIG1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2Ug MDAwMDYwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJh bmdlIDB4NjAwMC0weDYwZmY6IGluIHJhbmdlCiAgICAgICAgbWFwWzE4XTogdHlwZSAxLCByYW5n ZSAzMiwgYmFzZSBlYjAwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHhlYjAwMDAwMC0weGViMDBmZmZmOiBnb29kCnBjaWIxOiBtYXRj aGVkIGVudHJ5IGZvciAxLjAuSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDNTowKQpwY2liMTogc2xv dCAwIElOVEEgcm91dGVkIHRvIGlycSAxNiB2aWEgXF9TQl8uUENJMC5BUEM1CnZnYXBjaTA6IDxW R0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4NjAwMC0weDYwZmYgbWVtIDB4ZTAwMDAwMDAt MHhlN2ZmZmZmZiwweGViMDAwMDAwLTB4ZWIwMGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24g cGNpMQpkcm0wOiA8QVRJIFJhZGVvbiBRVyBSVjIwMCA3NTAwPiBvbiB2Z2FwY2kwCmluZm86IFtk cm1dIEFHUCBhdCAweGU4MDAwMDAwIDMyTUIKaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQgcmFkZW9u IDEuMTkuMCAyMDA1MDkxMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAx NC4wIG9uIHBjaTAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRp bmF0ZSBidXMgICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NzAwMC0weGFmZmYKcGNp YjI6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlYzAwMDAwMC0weGVkZmZmZmZmCnBjaWIyOiAgIHBy ZWZldGNoZWQgZGVjb2RlIDB4ZWUwMDAwMDAtMHhlZWZmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMgpwY2kyOiBwaHlzaWNhbCBidXM9Mgpmb3VuZC0+IHZlbmRvcj0weDEwNWEsIGRl dj0weDM1NzAsIHJldmlkPTB4MDIKICAgICAgICBidXM9Miwgc2xvdD02LCBmdW5jPTAKICAgICAg ICBjbGFzcz0wMS0wNC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCiAgICAgICAgY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0xIChkd29yZHMpCiAgICAgICAgbGF0dGlt ZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MTIgKDQ1 MDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT05CiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQxIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAz MiwgYmFzZSAwMDAwNzAwMCwgc2l6ZSAgNywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHg3MDAwLTB4NzA3ZjogaW4gcmFuZ2UKICAgICAgICBtYXBbMThdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA3NDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIyOiAobnVs bCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDc0MDAtMHg3NGZmOiBpbiByYW5nZQogICAgICAgIG1h cFsxY106IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWQwMjgwMDAsIHNpemUgMTIsIGVuYWJsZWQK cGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZWQwMjgwMDAtMHhlZDAyOGZm ZjogZ29vZAogICAgICAgIG1hcFsyMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWQwMDAwMDAs IHNpemUgMTcsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 ZWQwMDAwMDAtMHhlZDAxZmZmZjogZ29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi42LklO VEEgKHNyYyBcX1NCXy5QQ0kwLkFQQzM6MCkKcGNpX2xpbmsyMDogUGlja2VkIElSUSAxOCB3aXRo IHdlaWdodCAwCnBjaWIyOiBzbG90IDYgSU5UQSByb3V0ZWQgdG8gaXJxIDE4IHZpYSBcX1NCXy5Q Q0kwLkFQQzMKZm91bmQtPiB2ZW5kb3I9MHgxMTAyLCBkZXY9MHgwMDAyLCByZXZpZD0weDA4CiAg ICAgICAgYnVzPTIsIHNsb3Q9NywgZnVuYz0wCiAgICAgICAgY2xhc3M9MDQtMDEtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQogICAgICAgIGNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdu dD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgxNCAoNTAwMCBucykKICAgICAgICBpbnRwaW49YSwg aXJxPTEwCiAgICAgICAgcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50 IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwNzgwMCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHg3ODAwLTB4 NzgxZjogaW4gcmFuZ2UKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuNy5JTlRBIChzcmMgXF9T Ql8uUENJMC5BUEM0OjApCnBjaV9saW5rMjE6IFBpY2tlZCBJUlEgMTkgd2l0aCB3ZWlnaHQgMApw Y2liMjogc2xvdCA3IElOVEEgcm91dGVkIHRvIGlycSAxOSB2aWEgXF9TQl8uUENJMC5BUEM0CmZv dW5kLT4gdmVuZG9yPTB4MTEwMiwgZGV2PTB4NzAwMiwgcmV2aWQ9MHgwOAogICAgICAgIGJ1cz0y LCBzbG90PTcsIGZ1bmM9MQogICAgICAgIGNsYXNzPTA5LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTEKICAgICAgICBjbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQogICAgICAgIHBvd2Vyc3BlYyAxICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJh c2UgMDAwMDdjMDAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9P IHJhbmdlIDB4N2MwMC0weDdjMDc6IGluIHJhbmdlCmZvdW5kLT4gdmVuZG9yPTB4MTA5ZSwgZGV2 PTB4MDM2ZSwgcmV2aWQ9MHgxMQogICAgICAgIGJ1cz0yLCBzbG90PTgsIGZ1bmM9MAogICAgICAg IGNsYXNzPTA0LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKICAgICAgICBjbWRyZWc9MHgw MDA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1l cj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgxMCAoNDAwMCBucyksIG1heGxhdD0weDI4ICgxMDAw MCBucykKICAgICAgICBpbnRwaW49YSwgaXJxPTEwCiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwg YmFzZSBlZTAwMDAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHhlZTAwMDAwMC0weGVlMDAwZmZmOiBnb29kCnBjaWIyOiBtYXRjaGVkIGVu dHJ5IGZvciAyLjguSU5UQSAoc3JjIFxfU0JfLlBDSTAuQVBDMTowKQpwY2lfbGluazE4OiBQaWNr ZWQgSVJRIDE2IHdpdGggd2VpZ2h0IDEKcGNpYjI6IHNsb3QgOCBJTlRBIHJvdXRlZCB0byBpcnEg MTYgdmlhIFxfU0JfLlBDSTAuQVBDMQpmb3VuZC0+IHZlbmRvcj0weDEwOWUsIGRldj0weDA4Nzgs IHJldmlkPTB4MTEKICAgICAgICBidXM9Miwgc2xvdD04LCBmdW5jPTEKICAgICAgICBjbGFzcz0w NC04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDAwNiwgc3Rh dHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgyMCAo OTYwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHhmZiAoNjM3NTAgbnMpCiAg ICAgICAgaW50cGluPWEsIGlycT0xMAogICAgICAgIHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAogICAgICAgIG1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2UgZWUw MDEwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJh bmdlIDB4ZWUwMDEwMDAtMHhlZTAwMWZmZjogZ29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3Ig Mi44LklOVEEgKHNyYyBcX1NCXy5QQ0kwLkFQQzE6MCkKcGNpYjI6IHNsb3QgOCBJTlRBIHJvdXRl ZCB0byBpcnEgMTYgdmlhIFxfU0JfLlBDSTAuQVBDMQpmb3VuZC0+IHZlbmRvcj0weDEwZWMsIGRl dj0weDgxMzksIHJldmlkPTB4MTAKICAgICAgICBidXM9Miwgc2xvdD05LCBmdW5jPTAKICAgICAg ICBjbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCiAgICAgICAgY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAgICAgbGF0dGlt ZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDIwICg4MDAwIG5zKSwgbWF4bGF0PTB4NDAgKDE2 MDAwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9MTEKICAgICAgICBwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDQsIHJh bmdlIDMyLCBiYXNlIDAwMDA4MDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVx dWVzdGVkIEkvTyByYW5nZSAweDgwMDAtMHg4MGZmOiBpbiByYW5nZQogICAgICAgIG1hcFsxNF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZWQwMmIwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjI6 IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZWQwMmIwMDAtMHhlZDAyYjBmZjogZ29v ZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi45LklOVEEgKHNyYyBcX1NCXy5QQ0kwLkFQQzI6 MCkKcGNpX2xpbmsxOTogUGlja2VkIElSUSAxNyB3aXRoIHdlaWdodCAwCnBjaWIyOiBzbG90IDkg SU5UQSByb3V0ZWQgdG8gaXJxIDE3IHZpYSBcX1NCXy5QQ0kwLkFQQzIKZm91bmQtPiB2ZW5kb3I9 MHgxMWFiLCBkZXY9MHg0MzIwLCByZXZpZD0weDEzCiAgICAgICAgYnVzPTIsIHNsb3Q9MTEsIGZ1 bmM9MAogICAgICAgIGNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAg ICBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKICAg ICAgICBsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MTcgKDU3NTAgbnMpLCBtYXhs YXQ9MHgxZiAoNzc1MCBucykKICAgICAgICBpbnRwaW49YSwgaXJxPTEwCiAgICAgICAgcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCiAgICAgICAgbWFwWzEwXTog dHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAyMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMjog KG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlZDAyMDAwMC0weGVkMDIzZmZmOiBnb29k CiAgICAgICAgbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwODQwMCwgc2l6ZSAg OCwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHg4NDAwLTB4ODRm ZjogaW4gcmFuZ2UKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMTEuSU5UQSAoc3JjIFxfU0Jf LlBDSTAuQVBDNDowKQpwY2liMjogc2xvdCAxMSBJTlRBIHJvdXRlZCB0byBpcnEgMTkgdmlhIFxf U0JfLlBDSTAuQVBDNApmb3VuZC0+IHZlbmRvcj0weDEyODMsIGRldj0weDgyMTIsIHJldmlkPTB4 MTEKICAgICAgICBidXM9Miwgc2xvdD0xMiwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDEtODAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgw MjMwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwOCAoMjAwMCBucyksIG1heGxhdD0weDA4ICgyMDAwIG5zKQogICAgICAgIGludHBp bj1hLCBpcnE9MTAKICAgICAgICBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKICAgICAgICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA4ODEwLCBzaXpl ICAzLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDg4MTAtMHg4 ODE3OiBpbiByYW5nZQogICAgICAgIG1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAw MDhjMDAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdl IDB4OGMwMC0weDhjMDM6IGluIHJhbmdlCiAgICAgICAgbWFwWzE4XTogdHlwZSA0LCByYW5nZSAz MiwgYmFzZSAwMDAwOTAxMCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHg5MDEwLTB4OTAxNzogaW4gcmFuZ2UKICAgICAgICBtYXBbMWNdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA5NDAwLCBzaXplICAyLCBlbmFibGVkCnBjaWIyOiAobnVs bCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDk0MDAtMHg5NDAzOiBpbiByYW5nZQogICAgICAgIG1h cFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDk4MDAsIHNpemUgIDQsIGVuYWJsZWQK cGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4OTgwMC0weDk4MGY6IGluIHJhbmdl CnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjEyLklOVEEgKHNyYyBcX1NCXy5QQ0kwLkFQQzE6 MCkKcGNpYjI6IHNsb3QgMTIgSU5UQSByb3V0ZWQgdG8gaXJxIDE2IHZpYSBcX1NCXy5QQ0kwLkFQ QzEKZm91bmQtPiB2ZW5kb3I9MHgxMDk1LCBkZXY9MHgzNTEyLCByZXZpZD0weDAxCiAgICAgICAg YnVzPTIsIHNsb3Q9MTMsIGZ1bmM9MAogICAgICAgIGNsYXNzPTAxLTgwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVs bnN6PTggKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQogICAgICAgIGludHBpbj1hLCBpcnE9MTEKICAg ICAgICBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKICAgICAg ICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDA5YzAwLCBzaXplICAzLCBlbmFi bGVkCnBjaWIyOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDljMDAtMHg5YzA3OiBpbiBy YW5nZQogICAgICAgIG1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGEwMDAsIHNp emUgIDIsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YTAwMC0w eGEwMDM6IGluIHJhbmdlCiAgICAgICAgbWFwWzE4XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAw MDAwYTQwMCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFu Z2UgMHhhNDAwLTB4YTQwNzogaW4gcmFuZ2UKICAgICAgICBtYXBbMWNdOiB0eXBlIDQsIHJhbmdl IDMyLCBiYXNlIDAwMDBhODAwLCBzaXplICAyLCBlbmFibGVkCnBjaWIyOiAobnVsbCkgcmVxdWVz dGVkIEkvTyByYW5nZSAweGE4MDAtMHhhODAzOiBpbiByYW5nZQogICAgICAgIG1hcFsyMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGFjMDAsIHNpemUgIDQsIGVuYWJsZWQKcGNpYjI6IChu dWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YWMwMC0weGFjMGY6IGluIHJhbmdlCiAgICAgICAg bWFwWzI0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAyOTAwMCwgc2l6ZSAgOSwgZW5hYmxl ZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlZDAyOTAwMC0weGVkMDI5 MWZmOiBnb29kCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjEzLklOVEEgKHNyYyBcX1NCXy5Q Q0kwLkFQQzI6MCkKcGNpYjI6IHNsb3QgMTMgSU5UQSByb3V0ZWQgdG8gaXJxIDE3IHZpYSBcX1NC Xy5QQ0kwLkFQQzIKZm91bmQtPiB2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDI0LCByZXZpZD0weDAw CiAgICAgICAgYnVzPTIsIHNsb3Q9MTQsIGZ1bmM9MAogICAgICAgIGNsYXNzPTBjLTAwLTEwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDIx MCwgY2FjaGVsbnN6PTggKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBt aW5nbnQ9MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMpCiAgICAgICAgaW50cGlu PWEsIGlycT05CiAgICAgICAgcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJy ZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBlZDAyYTAwMCwg c2l6ZSAxMSwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhl ZDAyYTAwMC0weGVkMDJhN2ZmOiBnb29kCiAgICAgICAgbWFwWzE0XTogdHlwZSAxLCByYW5nZSAz MiwgYmFzZSBlZDAyNDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMjogKG51bGwpIHJlcXVlc3Rl ZCBtZW1vcnkgcmFuZ2UgMHhlZDAyNDAwMC0weGVkMDI3ZmZmOiBnb29kCnBjaWIyOiBtYXRjaGVk IGVudHJ5IGZvciAyLjE0LklOVEEgKHNyYyBcX1NCXy5QQ0kwLkFQQzM6MCkKcGNpYjI6IHNsb3Qg MTQgSU5UQSByb3V0ZWQgdG8gaXJxIDE4IHZpYSBcX1NCXy5QQ0kwLkFQQzMKYXRhcGNpMjogPFBy b21pc2UgUERDMjA3NzEgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4NzAwMC0weDcwN2YsMHg3 NDAwLTB4NzRmZiBtZW0gMHhlZDAyODAwMC0weGVkMDI4ZmZmLDB4ZWQwMDAwMDAtMHhlZDAxZmZm ZiBpcnEgMTggYXQgZGV2aWNlIDYuMCBvbiBwY2kyCnBjaTI6IGNoaWxkIGF0YXBjaTIgcmVxdWVz dGVkIHR5cGUgNCBmb3IgcmlkIDB4MjAsIGJ1dCB0aGUgQkFSIHNheXMgaXQgaXMgYW4gbWVtaW8K aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIHZlY3RvciA1NAphdGFw Y2kyOiBbTVBTQUZFXQphdGFwY2kyOiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciByaWQgMHgy MCB0eXBlIDMgYXQgMHhlZDAwMDAwMAphdGFwY2kyOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9y IHJpZCAweDFjIHR5cGUgMyBhdCAweGVkMDI4MDAwCmF0YXBjaTI6IFtNUFNBRkVdCmF0YTQ6IDxB VEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kyCmF0YTQ6IFNBVEEgY29ubmVjdCBzdGF0dXM9MDAwMDAw MDAKYXRhNDogW01QU0FGRV0KYXRhNTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTIKYXRhNTog U0FUQSBjb25uZWN0IHN0YXR1cz0wMDAwMDAwMAphdGE1OiBbTVBTQUZFXQphdGE2OiA8QVRBIGNo YW5uZWwgMj4gb24gYXRhcGNpMgphdGE2OiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9ZTAgb3N0 YXQxPWYwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjog c3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVy cj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4 YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAph dGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4 YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBs c2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0w eGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3Rh dDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0w eGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAg bXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2 OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAg ZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9 MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEw CmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9 MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEw IGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNi PTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBz dGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJy PTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhh MCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0 YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhh MCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxz Yj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4 YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0 MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4 YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBt c2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6 IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBl cnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0w eGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAK YXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0w eGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAg bHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9 MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0 YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9 MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEw IG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRh Njogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEw IGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNi PTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhh MAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQw PTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhh MCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1z Yj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjog c3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVy cj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4 YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAph dGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4 YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBs c2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0w eGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3Rh dDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0w eGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAg bXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2 OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAg ZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9 MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEw CmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9 MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEw IGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNi PTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBz dGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJy PTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhh MCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0 YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhh MCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxz Yj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4 YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0 MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4 YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBt c2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6 IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBl cnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0w eGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAgbHNiPTB4YTAgbXNiPTB4YTAK YXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9MHhhMAphdGE2OiBzdGF0MD0w eGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0YXQwPTB4YTAgZXJyPTB4YTAg bHNiPTB4YTAgbXNiPTB4YTAKYXRhNjogc3RhdDA9MHhhMCBlcnI9MHhhMCBsc2I9MHhhMCBtc2I9 MHhhMAphdGE2OiBzdGF0MD0weGEwIGVycj0weGEwIGxzYj0weGEwIG1zYj0weGEwCmF0YTY6IHN0 YXQxPTB4YjAgZXJyPTB4YjAgbHNiPTB4YjAgbXNiPTB4YjAKYXRhNjogcmVzZXQgdHAyIHN0YXQw PWEwIHN0YXQxPWIwIGRldmljZXM9MHgwCmF0YTY6IFtNUFNBRkVdCnBjbTE6IDxDcmVhdGl2ZSBF TVUxMEsxPiBwb3J0IDB4NzgwMC0weDc4MWYgaXJxIDE5IGF0IGRldmljZSA3LjAgb24gcGNpMgpw Y20xOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHg3ODAwCmVt dTogc2V0bWFwICgzZGFmNTAwMCwgODAwKSwgbnNlZz0xLCBlcnJvcj0wCmVtdTogc2V0bWFwICg5 YTYwMDAsIDEwMDApLCBuc2VnPTEsIGVycm9yPTAKcGNtMTogPFRyaVRlY2ggVFIyODYwMiBBQzk3 IENvZGVjIChpZCA9IDB4NTQ1MjQxMjMpPgpwY20xOiBDb2RlYyBmZWF0dXJlcyA1IGJpdCBtYXN0 ZXIgdm9sdW1lLCBubyAzRCBTdGVyZW8gRW5oYW5jZW1lbnQKcGNtMTogYWM5NyBjb2RlYyBkYWMg cmVhZHkgY291bnQ6IDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTkgKFBDSSBJUlEgMTkpIHRv IHZlY3RvciA1NQpwY20xOiBbTVBTQUZFXQplbXU6IHNldG1hcCAoM2RhZjQwMDAsIDEwMDApLCBu c2VnPTEsIGVycm9yPTAKZW11OiBzZXRtYXAgKDlhZjAwMCwgMTAwMCksIG5zZWc9MSwgZXJyb3I9 MAplbXU6IHNldG1hcCAoOWFkMDAwLCAxMDAwKSwgbnNlZz0xLCBlcnJvcj0wCmVtdTogc2V0bWFw ICgzZGFhMzAwMCwgMTAwMCksIG5zZWc9MSwgZXJyb3I9MApwY20xOiBzbmRidWZfc2V0bWFwIDNk YWEwMDAwLCAxMDAwOyAweGZmZmZmZjAwM2RhYTAwMDAgLT4gM2RhYTAwMDAKcGNtMTogc25kYnVm X3NldG1hcCAzZGE5ZTAwMCwgMTAwMDsgMHhmZmZmZmYwMDNkYTllMDAwIC0+IDNkYTllMDAwCmJr dHIwOiA8QnJvb2tUcmVlIDg3OD4gbWVtIDB4ZWUwMDAwMDAtMHhlZTAwMGZmZiBpcnEgMTYgYXQg ZGV2aWNlIDguMCBvbiBwY2kyCmJrdHIwOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgMyBhdCAweGVlMDAwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kg SVJRIDE2KSB0byB2ZWN0b3IgNTYKYmt0cjA6IFtHSUFOVC1MT0NLRURdCmJyb29rdHJlZTA6IFBD SSBidXMgbGF0ZW5jeSBpcyAzMi4KYmt0cjA6IGJ1ZmZlciBzaXplIDM1NTUzMjgsIGFkZHIgMHgz OTAwMDAwMApia3RyMDogR1BJTyBpcyAweDAwODRmZmYzCmJrdHIwOiBzdWJzeXN0ZW0gMHgxNDYx IDB4MDAwMwpia3RyMDogQVZlciBNZWRpYSBUVi9GTSwgUGhpbGlwcyBGUjEyMTYgUEFMIEZNIHR1 bmVyLgpwY2kyOiA8bXVsdGltZWRpYT4gYXQgZGV2aWNlIDguMSAobm8gZHJpdmVyIGF0dGFjaGVk KQpwY2kyOiA8bmV0d29yaywgZXRoZXJuZXQ+IGF0IGRldmljZSA5LjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkKc2tjMDogPE1hcnZlbGwgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweDg0MDAtMHg4NGZm IG1lbSAweGVkMDIwMDAwLTB4ZWQwMjNmZmYgaXJxIDE5IGF0IGRldmljZSAxMS4wIG9uIHBjaTIK c2tjMDogUmVzZXJ2ZWQgMHg0MDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlZDAy MDAwMApza2MwOiBpbnRlcnJ1cHQgbW9kZXJhdGlvbiBpcyAxMDAgdXMKc2tjMDogYmFkIFZQRCBy ZXNvdXJjZSBpZDogZXhwZWN0ZWQgODIgZ290IDAKc2tjMDogTWFydmVsbCBZdWtvbiBMaXRlIEdp Z2FiaXQgRXRoZXJuZXQgcmV2LiBBMygweDcpCnNrYzA6IGNoaXAgdmVyICA9IDB4YjEKc2tjMDog Y2hpcCByZXYgID0gMHgwNwpza2MwOiBTS19FUFJPTTAgPSAweDEwCnNrYzA6IFNSQU0gc2l6ZSA9 IDB4MDEwMDAwCnNrMDogPE1hcnZlbGwgU2VtaWNvbmR1Y3RvciwgSW5jLiBZdWtvbj4gb24gc2tj MApzazA6IGJwZiBhdHRhY2hlZApzazA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjBmOmVhOjQwOmYx OjVhCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBzazAKZTEwMDBwaHkwOiA8TWFydmVsbCA4OEUxMDAw IEdpZ2FiaXQgUEhZPiBvbiBtaWlidXMwCmUxMDAwcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVFgtRkRYLCBhdXRvCnNrYzA6IFtN UFNBRkVdCmF0YXBjaTM6IDxJVEUgSVQ4MjEyRiBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHg4 ODEwLTB4ODgxNywweDhjMDAtMHg4YzAzLDB4OTAxMC0weDkwMTcsMHg5NDAwLTB4OTQwMywweDk4 MDAtMHg5ODBmIGlycSAxNiBhdCBkZXZpY2UgMTIuMCBvbiBwY2kyCmF0YXBjaTM6IFJlc2VydmVk IDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDk4MDAKYXRhcGNpMzogW01QU0FG RV0KYXRhNzogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTMKYXRhcGNpMzogUmVzZXJ2ZWQgMHg4 IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHg4ODEwCmF0YXBjaTM6IFJlc2VydmVkIDB4 NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4OGMwMAphdGE3OiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTc6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4 MTQgbXNiPTB4ZWIKYXRhNzogc3RhdDE9MHgwMCBlcnI9MHgwNCBsc2I9MHgxNCBtc2I9MHhlYgph dGE3OiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVS PgphdGE3OiBbTVBTQUZFXQphdGE4OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMwphdGFwY2kz OiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDkwMTAKYXRhcGNp MzogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHg5NDAwCmF0YTg6 IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD02MCBvc3RhdDE9NzAKYXRhODogc3RhdDA9MHgyMCBl cnI9MHgyMCBsc2I9MHgyMCBtc2I9MHgyMAphdGE4OiBzdGF0MT0weDMwIGVycj0weDMwIGxzYj0w eDMwIG1zYj0weDMwCmF0YTg6IHJlc2V0IHRwMiBzdGF0MD0yMCBzdGF0MT0zMCBkZXZpY2VzPTB4 MAphdGE4OiBbTVBTQUZFXQphdGFwY2k0OiA8U2lJIDM1MTIgU0FUQTE1MCBjb250cm9sbGVyPiBw b3J0IDB4OWMwMC0weDljMDcsMHhhMDAwLTB4YTAwMywweGE0MDAtMHhhNDA3LDB4YTgwMC0weGE4 MDMsMHhhYzAwLTB4YWMwZiBtZW0gMHhlZDAyOTAwMC0weGVkMDI5MWZmIGlycSAxNyBhdCBkZXZp Y2UgMTMuMCBvbiBwY2kyCmF0YXBjaTQ6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweGFjMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcp IHRvIHZlY3RvciA1NwphdGFwY2k0OiBbTVBTQUZFXQphdGFwY2k0OiBSZXNlcnZlZCAweDIwMCBi eXRlcyBmb3IgcmlkIDB4MjQgdHlwZSAzIGF0IDB4ZWQwMjkwMDAKYXRhOTogPEFUQSBjaGFubmVs IDA+IG9uIGF0YXBjaTQKYXRhOTogU0FUQSBjb25uZWN0IHJlYWR5IHRpbWU9MzBtcwphdGE5OiBz YXRhX2Nvbm5lY3QgZGV2aWNlcz0weDE8QVRBX01BU1RFUj4KYXRhOTogW01QU0FGRV0KYXRhMTA6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2k0CmF0YTEwOiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAw MDAwMDAwCmF0YTEwOiBbTVBTQUZFXQpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVudHMgVFNCNDNB QjIzPiBtZW0gMHhlZDAyYTAwMC0weGVkMDJhN2ZmLDB4ZWQwMjQwMDAtMHhlZDAyN2ZmZiBpcnEg MTggYXQgZGV2aWNlIDE0LjAgb24gcGNpMgpmd29oY2kwOiBSZXNlcnZlZCAweDgwMCBieXRlcyBm b3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZWQwMmEwMDAKZndvaGNpMDogW01QU0FGRV0KZndvaGNp MDogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0xKQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25vdXMg Y2hhbm5lbHMgaXMgNC4KZndvaGNpMDogRVVJNjQgMDA6MGY6ZWE6MDA6MDA6M2M6OWY6NWEKZndv aGNpMDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAzIHBvcnRzLgpmd29oY2kwOiBMaW5rIFM0 MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1 cz4gb24gZndvaGNpMApmd2UwOiA8RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUw CmlmX2Z3ZTA6IEZha2UgRXRoZXJuZXQgYWRkcmVzczogMDI6MGY6ZWE6M2M6OWY6NWEKZndlMDog YnBmIGF0dGFjaGVkCmZ3ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAyOjBmOmVhOjNjOjlmOjVhCmZ3 ZTA6IGlmX3N0YXJ0IHJ1bm5pbmcgZGVmZXJyZWQgZm9yIEdpYW50CnNicDA6IDxTQlAtMi9TQ1NJ IG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQK ZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBnZW49MSwgQ1lDTEVNQVNURVIgbW9kZQpmaXJl d2lyZTA6IDEgbm9kZXMsIG1heGhvcCA8PSAwLCBjYWJsZSBJUk0gPSAwIChtZSkKZmlyZXdpcmUw OiBidXMgbWFuYWdlciAwIChtZSkKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0 IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGljX3R5cGUgOTAg cGFydF9pZCA4MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA2IChJU0EgSVJRIDYpIHRvIHZlY3Rv ciA1OApmZGMwOiBbTVBTQUZFXQpmZGMwOiBbRkFTVF0Kc2lvMDogaXJxIG1hcHM6IDB4YzAxIDB4 YzExIDB4YzAxIDB4YzAxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAw eDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBLCBj b25zb2xlCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gdmVjdG9yIDU5 CnNpbzA6IFtGQVNUXQpzaW8xOiBpcnEgbWFwczogMHhjMDEgMHhjMDkgMHhjMDEgMHhjMDEKc2lv MTogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9u IGFjcGkwCnNpbzE6IHR5cGUgMTY1NTBBCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDMgKElTQSBJ UlEgMykgdG8gdmVjdG9yIDYwCnNpbzE6IFtGQVNUXQpwcGMwOiB1c2luZyBleHRlbmRlZCBJL08g cG9ydCByYW5nZQpwcGMwOiBTUFAKcHBjMDogPFN0YW5kYXJkIHBhcmFsbGVsIHByaW50ZXIgcG9y dD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBhY3BpMApwcGMwOiBHZW5lcmljIGNoaXBzZXQg KE5JQkJMRS1vbmx5KSBpbiBDT01QQVRJQkxFIG1vZGUKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBi dXM+IG9uIHBwYzAKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJp dmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDcgKElTQSBJUlEgNykgdG8gdmVjdG9yIDYxCnBwYzA6IFtHSUFOVC1MT0NLRURdCnBz bWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKYXRrYmRjMDogPEtleWJv YXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRr YmQwOiA8QVQgS2V5Ym9hcmQ+IGZsYWdzIDB4MSBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUg Y3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA0NwphdGtiZDoga2V5Ym9hcmQg SUQgMHg0MWFiICgyKQprYmRjOiBSRVNFVF9LQkQgcmV0dXJuIGNvZGU6MDBmYQprYmRjOiBSRVNF VF9LQkQgc3RhdHVzOjAwYWEKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCAxMDEvMTAy ICgyKSwgY29uZmlnOjB4MSwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MSAoSVNBIElSUSAxKSB0byB2ZWN0b3IgNjIKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBj dXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ3CmtiZGM6IFRFU1RfQVVYX1BPUlQgc3RhdHVzOjAwMDAK a2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmEKa2JkYzogUkVTRVRfQVVYIHN0YXR1czow MGFhCmtiZGM6IFJFU0VUX0FVWCBJRDowMDAwCmtiZGM6IFJFU0VUX0FVWCByZXR1cm4gY29kZTow MGZhCmtiZGM6IFJFU0VUX0FVWCBzdGF0dXM6MDBhYQprYmRjOiBSRVNFVF9BVVggSUQ6MDAwMApw c206IHN0YXR1cyAwMCAwMiA2NApwc206IHN0YXR1cyAwMCAwMCA2NApwc206IHN0YXR1cyAwMCAw MyA2NApwc206IHN0YXR1cyAwMCAwMyA2NApwc206IGRhdGEgMDggMDAgMDAKcHNtOiBzdGF0dXMg MDAgMDIgNjQKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byB2ZWN0b3IgNjMKcHNtMDogW0dJQU5ULUxP Q0tFRF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMy0wMCwgMyBidXR0b25z CnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjQKcHNt MDogc3luY21hc2s6MDgsIHN5bmNiaXRzOjAwCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKZmRjOiBmZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwcGM6 IHBwYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKc2lvOiBzaW8xIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwbnBf aWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJl YWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBf aWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJl YWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBf aWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJl YWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCnNjOiBzYzAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNh X3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVu OiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21l bSAweGMwMDAwLTB4Y2JmZmYsMHhjYzAwMC0weGQwN2ZmIHBucGlkIE9STTAwMDAgb24gaXNhMApz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYg dmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBl bXVsYXRvcjogc2MgKHN5c2NvbnMgdGVybWluYWwpCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQpzaW8zOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQg cG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAppc2FfcHJvYmVf Y2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNo ZWQuCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDA0ODk1MzIgaHoKVGltZWNvdW50ZXIg IlRTQyIgZnJlcXVlbmN5IDE4MDg4MTE0MDUgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMS4wMDAgbXNlYwpMaW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3RhbGxlZApsbzA6 IGJwZiBhdHRhY2hlZAphdGEwLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEx MDAgY2FibGU9ODAgd2lyZQphZDA6IHNldHRpbmcgUElPNCBvbiBuRm9yY2UzIFBybyBjaGlwCmFk MDogc2V0dGluZyBVRE1BMTAwIG9uIG5Gb3JjZTMgUHJvIGNoaXAKYWQwOiAxMTQ0NzJNQiA8U2Vh Z2F0ZSBTVDMxMjAwMjRBIDMuMzM+IGF0IGF0YTAtbWFzdGVyIFVETUExMDAKYWQwOiAyMzQ0Mzk1 MzUgc2VjdG9ycyBbMjMyNTc4Qy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRo IHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkMAphZDA6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkMDog QWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkMDogTFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDA6IExT SSAodjIpIGNoZWNrMSBmYWlsZWQKYWQwOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKYXRhMS1tYXN0 ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQphY2QwOiBz ZXR0aW5nIFBJTzQgb24gbkZvcmNlMyBQcm8gY2hpcAphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiBu Rm9yY2UzIFBybyBjaGlwCmFjZDA6IDxDUlctNDgyNEEvMS4wMD4gQ0RSVyBkcml2ZSBhdCBhdGEx IGFzIG1hc3RlcgphY2QwOiByZWFkIDg5NThLQi9zICg4OTU4S0Ivcykgd3JpdGUgODI2OUtCL3Mg KDgyNjlLQi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcs IENEREEgc3RyZWFtLCBwYWNrZXQKYWNkMDogV3JpdGVzOiBDRFIsIENEUlcsIHRlc3Qgd3JpdGUs IGJ1cm5wcm9vZgphY2QwOiBBdWRpbzogcGxheSwgMjU1IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVj aGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFuayBk aXNjCmF0YTItbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00 MCB3aXJlCmFkNDogMjg2MTY4TUIgPFNlYWdhdGUgU1QzMzAwODMxQVMgMy4wMz4gYXQgYXRhMi1t YXN0ZXIgU0FUQTE1MAphZDQ6IDU4NjA3MjM2OCBzZWN0b3JzIFs1ODE0MjFDLzE2SC82M1NdIDE2 IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ0CmFkNDog blZpZGlhIGNoZWNrMSBmYWlsZWQKYWQ0OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQKYWQ0OiBMU0kg KHYzKSBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2MikgY2hlY2sxIGZhaWxlZAphZDQ6IEZyZWVC U0QgY2hlY2sxIGZhaWxlZAphdGE3LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVE TUEzMyBjYWJsZT00MCB3aXJlCmFjZDE6IHN1Y2Nlc3Mgc2V0dGluZyBQSU80IG9uIElURTgyMTJG IGNoaXAKYWNkMTogc3VjY2VzcyBzZXR0aW5nIFVETUEzMyBvbiBJVEU4MjEyRiBjaGlwCmFjZDE6 IDxORUMgRFZEIFJXIE5ELTM1NDBBLzEuMDE+IERWRFIgZHJpdmUgYXQgYXRhNyBhcyBtYXN0ZXIK YWNkMTogcmVhZCA4MjY4S0IvcyAoODI2OEtCL3MpIHdyaXRlIDgyNjhLQi9zICg4MjY4S0Ivcyks IDIwNDhLQiBidWZmZXIsIFVETUEzMwphY2QxOiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0cmVh bSwgRFZEUk9NLCBEVkRSLCBwYWNrZXQKYWNkMTogV3JpdGVzOiBDRFIsIENEUlcsIERWRFIsIHRl c3Qgd3JpdGUsIGJ1cm5wcm9vZgphY2QxOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMK YWNkMTogTWVjaGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMTogTWVkaXVtOiBu by9ibGFuayBkaXNjCmF0YTktbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEz MyBjYWJsZT00MCB3aXJlCmFkMTg6IDIzODQ3NE1CIDxTZWFnYXRlIFNUMzI1MDgyNEFTIDMuQUFE PiBhdCBhdGE5LW1hc3RlciBTQVRBMTUwCmFkMTg6IDQ4ODM5NTA1NSBzZWN0b3JzIFs0ODQ1MThD LzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRp c2sgYWQxOAphZDE4OiBTaWxpY29uIEltYWdlIGNoZWNrMyBmYWlsZWQKYWQxODogQWRhcHRlYyBj aGVjazEgZmFpbGVkCmFkMTg6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQKYWQxODogTFNJICh2Mikg Y2hlY2sxIGZhaWxlZAphZDE4OiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKcGNtMDogbWVhc3VyZWQg YWM5NyBsaW5rIHJhdGUgYXQgNDc5OTYgSHosIHdpbGwgdXNlIDQ4MDAwIEh6Cihwcm9iZTU6c2Jw MDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTA6c2JwMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6c2JwMDowOjA6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTE6c2JwMDowOjE6MCk6IGVycm9yIDIyCihwcm9iZTE6c2JwMDow OjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI6c2JwMDowOjI6MCk6IGVycm9yIDIyCihw cm9iZTI6c2JwMDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTM6c2JwMDowOjM6MCk6 IGVycm9yIDIyCihwcm9iZTM6c2JwMDowOjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6 c2JwMDowOjQ6MCk6IGVycm9yIDIyCihwcm9iZTQ6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVy cm9yCihwcm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjY6MCk6IFVu cmV0cnlhYmxlIEVycm9yCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FkMHMxYQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdAoK ------=_Part_23893_21770539.1144073053219-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 14:16:46 2006 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 15D5516A41F for ; Mon, 3 Apr 2006 14:16:46 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43BD43D46 for ; Mon, 3 Apr 2006 14:16:45 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 313CF5CF0; Mon, 3 Apr 2006 10:16:45 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90125-09; Mon, 3 Apr 2006 10:16:44 -0400 (EDT) Received: from [192.168.1.3] (pool-68-160-194-11.ny325.east.verizon.net [68.160.194.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 5E8A55C57; Mon, 3 Apr 2006 10:16:44 -0400 (EDT) Message-ID: <44312E56.3040606@mac.com> Date: Mon, 03 Apr 2006 10:16:54 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nik References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> <1144055468.15377.12.camel@bert.mlan.solnet.ch> <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> In-Reply-To: <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 14:16:46 -0000 Nik wrote: > I'm curious why I need to enable MD5 because in my system I don't use any > authentication method. [ ... ] Using the MD5 signature TCP option for BGP has become a common requirement since the RST-window vulnerability was published... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 14:16:48 2006 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 8431716A400 for ; Mon, 3 Apr 2006 14:16:48 +0000 (UTC) (envelope-from harikurniawan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F80743D46 for ; Mon, 3 Apr 2006 14:16:47 +0000 (GMT) (envelope-from harikurniawan@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so1225884wra for ; Mon, 03 Apr 2006 07:16:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=f9FzU0HeMpkikkPpq/qNrnXn3s2N1DPCrXLwuxorwIErSskvEMbBFIv+SPEFP+mdvmi8vUe/PioxlF5C4AewPtLd99wXWGlQtO7pCKeMyuwcnl0a4zL5HPJ+01ET6GhPScCM+26InPFc+kEwp98Rf1QXbzdhhhYZKigQhfpsj9Y= Received: by 10.64.185.6 with SMTP id i6mr708177qbf; Mon, 03 Apr 2006 07:16:46 -0700 (PDT) Received: by 10.64.201.6 with HTTP; Mon, 3 Apr 2006 07:16:46 -0700 (PDT) Message-ID: <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> Date: Mon, 3 Apr 2006 14:16:46 +0000 From: "Angka H. K." To: "Alexander Leidinger" In-Reply-To: <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> MIME-Version: 1.0 References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: njl@freebsd.org, current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 14:16:48 -0000 Thanks for the replay I am updating my source now and planing to rebuild it again, but I don't se= e any changes on ACPI code. I was mistype on the val that return by kernel, the error should be "acpi: bad write to port 0x073(8) val 20", I am sorry. Hope it'll be fixed soon. FYI : I am using HP V2388TU with current source. The error is produced by source updated at 2 April 2006 On 4/3/06, Alexander Leidinger wrote: > > "Angka H. K." wrote: > > Please strip freebsd-multimedia@ on reply... > > > I have other problem now , which is saying "acpi: bad read to port > 0x073" > > and "acpi: bad write to port 0x073(8) val 82", where can ask about this > ? It > > looks like google has no archive about this error. > > I assume you are using -current. So the right place is to ask on current@ > (CCed). I also CCed njl@, since he's our "master of acpi". > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 > "This is a test of the Emergency Broadcast System. If this had been an > actual emergency, do you really think we'd stick around to tell you?" > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 14:24:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B42CB16A400 for ; Mon, 3 Apr 2006 14:24:35 +0000 (UTC) (envelope-from ahebert@pubnix.net) Received: from mail.pubnix.net (Mail.pubnix.net [192.172.250.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31FB343D46 for ; Mon, 3 Apr 2006 14:24:34 +0000 (GMT) (envelope-from ahebert@pubnix.net) Received: from [10.0.1.2] (aal.pubnix.net [64.235.216.13]) (authenticated bits=0) by mail.pubnix.net (8.13.6/8.13.6) with ESMTP id k33EOXJt027301 for ; Mon, 3 Apr 2006 10:24:34 -0400 (EDT) (envelope-from ahebert@pubnix.net) Message-ID: <44312217.7040904@pubnix.net> Date: Mon, 03 Apr 2006 09:24:39 -0400 From: Alain Hebert Organization: PubNIX, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060130 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <3979a4b0604030704u4a8a43fcxb76bdaab0de5f0f2@mail.gmail.com> In-Reply-To: <3979a4b0604030704u4a8a43fcxb76bdaab0de5f0f2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems with SATA drives on PDC20771 and SiI3512 controllers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahebert@pubnix.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 14:24:35 -0000 Known problem with the 2300. I've tried every combinaison possible of firmware and drive without avail. Even geom with raid confirguration would replicate the problem. I suggest that you go with a 3ware device which works perfectly in my cases (Production servers). Or a PDC20378 which also work perfectly with 5.4 here. (dont know about 6+ and kinda scare to try it.) Good luck. KOT MATPOCKuH wrote: >Hello! > >I got problems with my SATA II drives. > >1. If drive attached to Promise FastTrak TX2300 (PDC20771 chipset), all >"small" operations like fsck, newfs with this drive works propertly. >But on hard load (like "dump 0f - / | restore rf -" or something like this) >on this drive, I have a WRITE_DMA (or WRITE_DMA48) errors, disk detach, and >as result - system panic. >After reboot and fsck, I does not see anything on filesystem. > >boot -hsv log is attached, and named boot.promise.log. >Panic log is panic.promise.log. > >2. If drive attached to SiI 3512 SATA150 (second SATA controller on my >motherboard), I have same problems, but system crashes after 1-2 minutes of >hard load, and after fsck I see a lot of directories on filesystem. > >boot -hsv - boot.sii.log. >Panic log is panic.sii.log. > >I'm tried to check this problem with another SATA drive, and I got problems >with Promise and SiI controllers, but If THIS drive is connected to nForce3 >Pro SATA150 (chipset's SATA controller) - all is fine, "dump | restore" >successfully completed. > >What is wrong? > >-- >MATPOCKuH > > >------------------------------------------------------------------------ > >_______________________________________________ >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" > -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443 From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 14:47:06 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D32716A400; Mon, 3 Apr 2006 14:47:06 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80B443D6D; Mon, 3 Apr 2006 14:47:03 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id k33El2Mg000430; Mon, 3 Apr 2006 16:47:02 +0200 (CEST) (envelope-from sos@deepcore.dk) Message-ID: <44313566.4060206@deepcore.dk> Date: Mon, 03 Apr 2006 16:47:02 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5 (X11/20060213) MIME-Version: 1.0 To: KOT MATPOCKuH References: <3979a4b0604030704u4a8a43fcxb76bdaab0de5f0f2@mail.gmail.com> In-Reply-To: <3979a4b0604030704u4a8a43fcxb76bdaab0de5f0f2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: Problems with SATA drives on PDC20771 and SiI3512 controllers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 14:47:06 -0000 KOT MATPOCKuH wrote: > Hello! > > I got problems with my SATA II drives. > > 1. If drive attached to Promise FastTrak TX2300 (PDC20771 chipset), all > "small" operations like fsck, newfs with this drive works propertly. > But on hard load (like "dump 0f - / | restore rf -" or something like > this) on this drive, I have a WRITE_DMA (or WRITE_DMA48) errors, disk > detach, and as result - system panic. > After reboot and fsck, I does not see anything on filesystem. > > boot -hsv log is attached, and named boot.promise.log. > Panic log is panic.promise.log. Since you are getting ICRC errors I'd suggest you try a new/different SATA cable. -Søren From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 15:35:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB29216A401; Mon, 3 Apr 2006 15:35:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB0D143D49; Mon, 3 Apr 2006 15:35:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CE5D046B08; Mon, 3 Apr 2006 11:34:59 -0400 (EDT) Date: Mon, 3 Apr 2006 16:34:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20060403003318.K947@ganymede.hub.org> Message-ID: <20060403163220.F36756@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pjd@FreeBSD.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 15:35:05 -0000 On Mon, 3 Apr 2006, Marc G. Fournier wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471 > > [kernel] [patch] new feature: private IPC for every jail > > Its an ancient, 4.x patch for having private IPC in a jail ... not sure how > hard it would be to bring it up to 6.x / -current standards though ... but > it seems like something 'good' that is needed ... In the past I've looked at doing things along these lines, but usually stall after a first hack when trying to decide how to deal with two critical issues: (1) The fact that system v ipc primitives are loadable, and unloadable, which requires some careful handling relating to registration order, etc. (2) The name space model for system v ipc is flat, so while it's desirable to allow the administrator in the host environment to monitor and control resource use in the jail (for example, delete allocated but unused segments), doing that requires developing an administrative model for it. These challenges can be surmounted, but the doing them in a nice way requires some thought. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 15:55:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 326BA16A501 for ; Mon, 3 Apr 2006 15:55:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96FCA43D5F for ; Mon, 3 Apr 2006 15:55:31 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k33FtMoq043315; Mon, 3 Apr 2006 11:55:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Conrad J. Sabatier" Date: Mon, 3 Apr 2006 11:52:25 -0400 User-Agent: KMail/1.9.1 References: <20060329020527.f8f087a4.conrads@cox.net> <200603291315.56671.jhb@freebsd.org> <20060402060734.0cc8fdd0.conrads@cox.net> In-Reply-To: <20060402060734.0cc8fdd0.conrads@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604031152.27109.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1369/Mon Apr 3 06:25:15 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: bms@spc.org, freebsd-current@freebsd.org Subject: Re: device atpic to be deprecated? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 15:55:33 -0000 On Sunday 02 April 2006 07:07, Conrad J. Sabatier wrote: > On Wed, 29 Mar 2006 13:15:54 -0500 > John Baldwin wrote: > > On Wednesday 29 March 2006 12:08, Scott Long wrote: > > > John Baldwin wrote: > > > > > > > > I think that once the lapic timer stuff was added almost all of the APIC > > > > issues I was aware of went away on amd64 that were fixed by using device > > > > atpic instead. Most of the earlier problems were due to chipsets not > > > > setting up pin 0 as extint, etc. but all that is no longer relevant when > > > > we switched to using the lapic timer and stopped using irq0 and irq8 with > > > > APIC. This is the first I've heard since the lapic timer stuff that APIC > > > > didn't work on an amd64 box, and device atpic has been off by default in > > > > HEAD for quite a while now. If we were able to require APIC on amd64, then > > > > we might be able to try out some optimizations and other things I haven't > > > > bothered with since they wouldn't be feasible on i386. > > > > > > > > > > Fine, remove it. > > > > I have to make sure it really works for everyone first though before > > removing it would really be viable. :-/ > > So, would it be necessary to upgrade to HEAD in order to make sure that > this problem won't still occur on my box? Or has this stuff already > been merged to STABLE? This particular bunch of code is identical in HEAD and 6.x right now, so we can probably debug it on STABLE just fine. -- 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 Apr 3 16:22:18 2006 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 7609816A41F for ; Mon, 3 Apr 2006 16:22:18 +0000 (UTC) (envelope-from nikruzhan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73E8A43D45 for ; Mon, 3 Apr 2006 16:22:15 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1651366nzf for ; Mon, 03 Apr 2006 09:22:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QTuK+uhErJ2e2WA1qB4e2AlSdCiKh4lVjexCWxFIvTD0CC/2IaRrtuTCmjpD4QWMiH8asRiMWGkRgQ4iUoGMk/5T7L9BMjQINBXxUwoIQs436gxkwDb2oyTe0xmM9R7xcD7lFV11i4tbB+WTh2MjRwZQWg6U3eknuouNmYM6k9s= Received: by 10.35.87.8 with SMTP id p8mr122508pyl; Mon, 03 Apr 2006 09:22:14 -0700 (PDT) Received: by 10.35.92.9 with HTTP; Mon, 3 Apr 2006 09:22:14 -0700 (PDT) Message-ID: <60ffc71f0604030922yec065bfs73493a4f80a225e2@mail.gmail.com> Date: Mon, 3 Apr 2006 16:22:14 +0000 From: Nik To: "Peter Jeremy" In-Reply-To: <20060403101504.GB683@turion.vk2pj.dyndns.org> MIME-Version: 1.0 References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> <1144055468.15377.12.camel@bert.mlan.solnet.ch> <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> <20060403101504.GB683@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 16:22:18 -0000 I'm using FreeBSD 5.4 with quagga 0.98.5. For L2 switch I'm using D-link DES3326S and router using intel GB network card (dual port). The routing process is controlled using quagga by ospfd and zebra. I forgot to see the network traffice from tcpdump, for that I need to do a testing first and will let u know the result. Therefore, here is my vlan's config : # --*Network*-- network_interfaces=3D"em0 em1 em2 em3 rl0 lo0" ifconfig_rl0=3D"inet 192.168.0.10 netmask 255.255.255.0" ifconfig_em0=3D"up" ifconfig_em1=3D"up" ifconfig_em2=3D"up" cloned_interfaces=3D"vlan0 vlan1 vlan2 vlan3 vlan4 vlan6 vlan7 vlan8 vlan9 vlan10" ifconfig_vlan0=3D"inet xx.xx.0.1 netmask 255.255.255.0 vlan 1 vlandev em0" ifconfig_vlan1=3D"inet xx.xx.8.1 netmask 255.255.255.248 vlan 20 vlandev em= 0" ifconfig_vlan2=3D"inet xx.xx.1.1 netmask 255.255.255.192 vlan 2 vlandev em2= " ifconfig_vlan3=3D"inet xx.xx.11.1 netmask 255.255.255.0 vlan 1000 vlandev e= m0" ifconfig_vlan4=3D"inet xx.xx.13.1 netmask 255.255.255.0 vlan 1001 vlandev e= m0" ifconfig_vlan6=3D"inet xx.xx.10.129 netmask 255.255.255.240 vlan 50 vlandev em1" ifconfig_vlan7=3D"inet xx.xx.10.145 netmask 255.255.255.248 vlan 51 vlandev em1" ifconfig_vlan8=3D"inet xx.xx.10.161 netmask 255.255.255.224 vlan 52 vlandev em1" ifconfig_vlan9=3D"inet xx.xx.10.1 netmask 255.255.255.192 vlan 4000 vlandev em1" ifconfig_vlan10=3D"inet xx.xx.14.1 netmask 255.255.255.248 vlan 2001 vlande= v em2" -*ospfd's configuration*- interface em0 description To Vlans ! interface em1 description To Vlans ! interface em2 description To Vlans - Business ! interface em3 description To p2p - CORE ! interface lo0 description To IBGP - Loopback ! interface plip0 ! interface rl0 ! interface rl1 description To PG DistRouter ! interface vlan0 description To Switch Management ! interface vlan1 description To Authentication ! interface vlan2 description To Business Switch Management ! interface vlan3 description To Vlan1000 ! interface vlan4 description To Vlan1001 ! interface vlan6 description To Vlan50 - IDC 1 ! interface vlan7 description To Vlan51 - IDC 2 ! interface vlan8 description To Vlan52 - IDC 3 ! interface vlan9 description To Vlan4000 - DMZ ! interface vlan10 description To Vlan2001 - Business Customer ! router ospf ospf router-id xx.xx.8.130 network xx.xx.0.0/24 area 0.0.0.1 network xx.xx.1.0/26 area 0.0.0.1 network xx.xx.8.0/29 area 0.0.0.1 network xx.xx.8.66/32 area 0.0.0.0 network xx.xx.8.128/29 area 0.0.0.0 network xx.xx.8.168/30 area 0.0.0.0 network xx.xx.10.0/26 area 0.0.0.1 network xx.xx.10.128/28 area 0.0.0.10 network xx.xx.10.144/29 area 0.0.0.10 network xx.xx.10.160/27 area 0.0.0.10 network xx.xx.11.0/24 area 0.0.0.50 network xx.xx.13.0/24 area 0.0.0.51 network xx.xx.14.0/29 area 0.0.0.52 ! line vty ! -*zebra configuration*- ! interface em0 ipv6 nd suppress-ra ! interface em1 description To Vlans ipv6 nd suppress-ra ! interface em2 ipv6 nd suppress-ra ! interface em3 ip address xx.xx.8.130/29 ipv6 nd suppress-ra ! interface lo0 description To IBGP Loopback ip address xx.xx.8.66/32 ! interface plip0 ipv6 nd suppress-ra ! interface rl0 ipv6 nd suppress-ra ! interface rl1 ip address xx.xx.8.169/30 ipv6 nd suppress-ra ! interface vlan0 ipv6 nd suppress-ra ! interface vlan1 description To Authentication ipv6 nd suppress-ra ! interface vlan2 ipv6 nd suppress-ra ! interface vlan3 description To Customer ipv6 nd suppress-ra ! interface vlan4 description To Customer ipv6 nd suppress-ra ! interface vlan6 description To IDC ipv6 nd suppress-ra ! interface vlan7 description To IDC ipv6 nd suppress-ra ! interface vlan8 description To IDC ipv6 nd suppress-ra ! interface vlan9 ipv6 nd suppress-ra ! interface vlan10 ipv6 nd suppress-ra ! ip forwarding ! line vty ! On 4/3/06, Peter Jeremy wrote: > > On Mon, 2006-Apr-03 17:55:56 +0800, Nik wrote: > >I'm curious why I need to enable MD5 because in my system I don't use an= y > >authentication method. Is there any way to off the parameter. Also I > notice > >that vlan in FreeBSD is not fully trunk. > > > >Examples ; > > > >vlan 1000 : 192.168.0.1/26 > > > >connect to L2 switch and untag certain port to connect to PC. I still ca= n > >use internet when I set that PC to use this IP; > > > >IP =3D 192.168.0.5/24 > >Gateway =3D 192.168.0.1/24 > > I use VLAN trunks extensively in FreeBSD and have no problems with > them (I've had more problems with broken VLAN implementations in > switches). Can you detail exactly what your interface configuration > is and what commands your are issuing that aren't working as expected. > Have you looked at the network traffic using (eg) tcpdump. > > -- > Peter Jeremy > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 16:27:17 2006 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 3B0A116A423 for ; Mon, 3 Apr 2006 16:27:17 +0000 (UTC) (envelope-from nikruzhan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A7743D4C for ; Mon, 3 Apr 2006 16:27:14 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1653424nzf for ; Mon, 03 Apr 2006 09:27:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LaJtBQGtX+9M0nAaxmPDbhvg5ircPc+0wYaRJp4/ybS6ozXuFGh7oTx+ALSVZ9re9daGY1NopXZq3TyCkXsu2Lg+G6KimMKV/QEtr9yQZ1Q9ZXrLe7i02sRBWW+EHFHCurzCk0KHnMufm5hFYhNlhFTjF4nMzVs1kedkQYvW+mw= Received: by 10.35.91.10 with SMTP id t10mr1468399pyl; Mon, 03 Apr 2006 09:27:13 -0700 (PDT) Received: by 10.35.92.9 with HTTP; Mon, 3 Apr 2006 09:27:13 -0700 (PDT) Message-ID: <60ffc71f0604030927g3a75f914hf32457fe8934c091@mail.gmail.com> Date: Mon, 3 Apr 2006 16:27:13 +0000 From: Nik To: "Chuck Swiger" In-Reply-To: <44312E56.3040606@mac.com> MIME-Version: 1.0 References: <60ffc71f0604030126w60070561i9781729205d3790d@mail.gmail.com> <1144055468.15377.12.camel@bert.mlan.solnet.ch> <60ffc71f0604030255h3b418706vfaf51bb5f088dff3@mail.gmail.com> <44312E56.3040606@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: BGP: can't set sockopt TCP_MD5SIG 0 to socket 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 16:27:17 -0000 If that is the case then I only need to recompile my kernel as what Thomas said. Thanks a lot Thomas & Chuck. # quagga needs this for MD5 passwords on BGP sessions options TCP_SIGNATURE options FAST_IPSEC device crypto device cryptodev On 4/3/06, Chuck Swiger wrote: > > Nik wrote: > > I'm curious why I need to enable MD5 because in my system I don't use > any > > authentication method. [ ... ] > > Using the MD5 signature TCP option for BGP has become a common requiremen= t > since > the RST-window vulnerability was published... > > -- > -Chuck > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 16:42:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F94116A401; Mon, 3 Apr 2006 16:42:33 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id D128743D5D; Mon, 3 Apr 2006 16:42:26 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 53674823A9D; Mon, 3 Apr 2006 13:42:25 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 26926-10; Mon, 3 Apr 2006 13:42:26 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id CC9F9823A87; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id CC5123C9A2; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id C6FF83C8FA; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Date: Mon, 3 Apr 2006 13:42:24 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20060403163220.F36756@fledge.watson.org> Message-ID: <20060403132401.I947@ganymede.hub.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 16:42:33 -0000 On Mon, 3 Apr 2006, Robert Watson wrote: > (1) The fact that system v ipc primitives are loadable, and unloadable, > which requires some careful handling relating to registration order, > etc. For this one, I'm lost at the issue ... if not loaded, jail processes just couldn't attach ... if loaded, and you try to unload, while there are shared memory segments in play, don't unload ... or is there something i'm missing here? What happens now, if I load ipc, start up postgresql and then try to unload ipc? I hardcode all the stuff I use in my kernel, so don't use the load/unload mechanism, so can't test this easily ... > (2) The name space model for system v ipc is flat, so while it's > desirable to allow the administrator in the host environment to monitor > and control resource use in the jail (for example, delete allocated but > unused segments), doing that requires developing an administrative model > for it. Again, you've lost me here ... how is that different then not using a jail? from the root server, one does an 'ipcs -a' and ipcrm as required ... the only thing I could think of 'being a nice thing' here is to maybe add a 'jail' value, simpler to what is in proc, so that you know what segments below to a specific jail ... I'm free to admit that I may be missing something you are seeing as obvious, mind you ;) For instance, are you suggesting that 'root' in the jail himself could issue ipcs -a and ipcrm? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 17:16:12 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EBB016A427; Mon, 3 Apr 2006 17:16:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id F202C43D45; Mon, 3 Apr 2006 17:16:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 215A946BE4; Mon, 3 Apr 2006 13:15:59 -0400 (EDT) Date: Mon, 3 Apr 2006 18:15:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20060403132401.I947@ganymede.hub.org> Message-ID: <20060403174952.E76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060403132401.I947@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 17:16:12 -0000 On Mon, 3 Apr 2006, Marc G. Fournier wrote: > On Mon, 3 Apr 2006, Robert Watson wrote: > >> (1) The fact that system v ipc primitives are loadable, and unloadable, >> which requires some careful handling relating to registration order, etc. > > For this one, I'm lost at the issue ... if not loaded, jail processes just > couldn't attach ... if loaded, and you try to unload, while there are shared > memory segments in play, don't unload ... or is there something i'm missing > here? What happens now, if I load ipc, start up postgresql and then try to > unload ipc? I hardcode all the stuff I use in my kernel, so don't use the > load/unload mechanism, so can't test this easily ... The problem is the relationship between jails and loadable System V IPC, and has to do with how you might implement the relationship between the two subsystems. There are two general ways to approach adding virtualization to the System V IPC name spaces: (1) Add a general virtualization facility, which causes the current process and its children to see a new name space. (2) Key virtualization to the identity of the jail. When dealing with the file system, jail relies on the existing chroot() subsetting facility to introduce virtualization. This is a nice piece of behavior, as it means file system subsetting is a facility available to be used regardless of the use of jail, and avoids hard-coding jail instrumentation throughout the file system code. So the question is this: if you load System V IPC support after you start a jail, how do we handle jails that have already started? Do we go out and create new name spaces for jails already started (a problem for method (1), because it implies System V IPC will have pretty intimate knowledge of jails, and know how to walk lists, etc), do we deny access to System V IPC for jails not present when it was loaded? Likewise, although we tend to refer to the different IPC mechanisms as in a single category, System V IPC, there are actually three name spaces, and the functionality for each can be loaded separately. It's not that these questions can't be answered, but they do have to be answered. My leaning, btw, in implementing this would be to: - For each System V IPC mechanism, implement a mechanism to create a new name space, to be used by the current process and any children (until they replace them with a new one, similar to chroot). - In jail(), similar to the way in which it uses chroot() to subset the file system name space, cause the creation of new name spaces, if the IPC services are present. - We'll need a way to flag jails as not permitting any System V IPC of a particular type, to be used when the IPC service isn't loaded at the time jail() is to create a new jail, and the System V IPC services will need to check those flags (or whatever). - We'll need a way to name the new name spaces (unlike the file system, we can't rely on an existing facility), and we'll need to enhance the System V IPC monitoring and management tools. For example, ipcs, ipcrm, etc, will need to know about this, the kernel interfaces for management will need to know how to deal with name spaces, and they will have to make sure to use the right checks and decide how to represent the fact that processes in jails should not be able to see name spaces other than their name space. Maybe this is a flag to name space creation, but something is needed here. Note there are some other tricky dependency problems, such as the fact that jails have to interact with code that may or may not be loaded, how to have jail vs IPC notions of privilege interact, etc. >> (2) The name space model for system v ipc is flat, so while it's desirable >> to allow the administrator in the host environment to monitor and control >> resource use in the jail (for example, delete allocated but unused >> segments), doing that requires developing an administrative model for it. > > Again, you've lost me here ... how is that different then not using a jail? > from the root server, one does an 'ipcs -a' and ipcrm as required ... the > only thing I could think of 'being a nice thing' here is to maybe add a > 'jail' value, simpler to what is in proc, so that you know what segments > below to a specific jail ... > > I'm free to admit that I may be missing something you are seeing as obvious, > mind you ;) > > For instance, are you suggesting that 'root' in the jail himself could issue > ipcs -a and ipcrm? I'm referring to how ipcs, ipcrm, etc, in the host environment interact with the IPC resources in the jail environments. In particular, I'm making the assumption that it is useful and desirable for the administrator running in the host to be able to directly monitor allocation in the jails, and manage that allocation, without running the management commands in the jail. I'm not sure if you've ever programmed to the System V IPC API, but if you have done so, you'll know that the name space for IPC objects is "odd". It's non-hierarchal, and hence highly subject to collisions between applications. This means that we can't use neat tricks, such as chroot() in the file system, to implement virtualization. If you compare the behavior of MySQL in a Jail with PostgreSQL, you'll see how this plays out immediately: MySQL uses UNIX domain sockets by default, and this means it "just works" with Jail, as the UNIX domain socket name space is, in fact, the file system name space. If MySQL uses /tmp/mysql.sock in a jail, it's virtualized by virtue of the fact that /jail/www.whatever.com/tmp doesn't, by definition, collide with /jail/www.notanother.com/tmp. Because the System V IPC name space is non-hierarchal, we have to deal with the fact that names can and do collide. If each jail has its own name space, for example, and each contains a PostgreSQL session with an ID of 54321 (made up), then a process in the host environment can't simply issue the normal System V IPC system calls in order to delete them, because those calls have no way to express "which name space" the operation is in. In the jail, this is OK, because applications will get whatever the jail-local name space is. But outside the Jail, these commands would see the name space for the host, but none of the contents of the Jail's name spaces. In essense, this mean that we need to add new interfaces to allow ipcs, ipcrm, etc, to run outside the jails yet see and operate on objects in the jails. Again, this can be done, but the details are non-trivial, since they raise hard questions about generalization, interactions between dynamically loaded components, access control, name spaces etc. This is why no one has done it yet. Several people, including myself, have sat down and done the first 30% hack -- enough to get things working a bit, and to bump into all the tricky parts (see above). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 17:26:12 2006 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 7A49A16A401 for ; Mon, 3 Apr 2006 17:26:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0D6F43D4C for ; Mon, 3 Apr 2006 17:26:11 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k33HQBSp083783 for ; Mon, 3 Apr 2006 10:26:11 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k33HQBsw083782 for current@freebsd.org; Mon, 3 Apr 2006 10:26:11 -0700 (PDT) (envelope-from david) Date: Mon, 3 Apr 2006 10:26:11 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20060403172611.GA83741@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Panic "div_bind: inp == NULL" on -CURRENT from 02 Apr 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wolfskill , dhw@mail-abuse.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 17:26:12 -0000 [I'm at least a week behind on mail -- just got back in town over the weekend -- so if this has been covered, I apologize for the duplication.] I've been tracking both RELENG_6 & HEAD on my laptop on a daily basis for a while; I also try to track them on a weekly basis on my desktop at work. On 25 March, I had no problem doing that; on 02 April, RELENG_6 was fine, but HEAD hit a panic during the transition from single-user mode to multi-user mode -- but only on my work desktop (my laptop doesn't exhibit the problem at all). I *suspect* -- based on the sequence of events -- that the initial panic may well be associated with a NIC, and that the kbd driver gets a secondary panic; regardless of what I suspect, the keyboard isn't usable once the panic message spits out, but a serial console does work. The nice thing is that the panic appears to be 100% reproducible; here is a cut/paste from the serial console: /boot/kernel/acpi.ko text=0x43b18 data=0x24a0+0xff0 syms=[0x4+0x7c10+0x4+0xa8bb] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 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 #41: Sun Apr 2 16:10:36 PDT 2006 root@catmint.mail-abuse.org:/common/S3/obj/usr/src/sys/CATMINT WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x441d> real memory = 535232512 (510 MB) avail memory = 514162688 (490 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) 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_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xed98-0xed9f mem 0xe8000000-0xefffffff,0xfeb80000-0xfebfffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 892k stolen memory agp0: aperture size is 128M uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: wrong number of companions (4 != 3) usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 8 ports with 8 removable, self powered pcib1: at device 30.0 on pci0 pci1: on pcib1 dc0: port 0xdf00-0xdf7f mem 0xfe9fec00-0xfe9fefff irq 21 at device 0.0 on pci1 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:c0:f0:3b:ea:b7 fxp0: port 0xdec0-0xdeff mem 0xfe9ff000-0xfe9fffff irq 20 at device 8.0 on pci1 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:13:20:2d:f5:b7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7ffff irq 18 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xee00-0xeeff,0xedc0-0xedff mem 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0 pcm0: primary codec not ready! pcm0: speaker0: port 0x61 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, console sio0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 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 ppc0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff,0xca800-0xcbfff pnpid ORM0000 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 2793016905 Hz quality 800 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, unlimited logging ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to deny, logging unlimited ad0: 38146MB at ata0-master UDMA100 acd0: CDROM at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s3a dc0: link state changed to UP fxp0: link state changed to UP panic: div_bind: inp == NULL cpuid = 0 KDB: enter: panic [thread pid 254 tid 100056 ] Stopped at kdb_enter+0x2b: nop db> bt Tracing pid 254 tid 100056 td 0xc34236c0 kdb_enter(c0866a2c) at kdb_enter+0x2b panic(c08758c6,0,c34236c0,c3680240,d568dc44) at panic+0x127 div_bind(c367abac,c3680240,c34236c0,d568dc68,c0685f87) at div_bind+0x1d sobind(c367abac,c3680240,c34236c0,c35d0b40,d568dd04) at sobind+0x16 kern_bind(c34236c0,3,c3680240,c3680240,0) at kern_bind+0x5b bind(c34236c0,d568dd04,c0928080,c32e4a00,0) at bind+0x2f syscall(3b,3b,3b,8210150,bfbfee20) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (104, FreeBSD ELF32, bind), eip = 0x28103d37, esp = 0xbfbeeb9c, ebp = 0xbfbfee48 --- db> panic panic: from debugger cpuid = 0 Uptime: 5s Dumping 510 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 510MB (130416 pages) 494 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 Automatic reboot in 15 seconds - press a key on the console to abort At this point, I'll await suggestions. I can make the dump available, I expect, should that be useful. I'm not sure how soon I will be able to do much with my email backlog (which was at around 1K messages), so I've set Reply-To to add an address for which I'll be monitoring mail more closely during the workday. Oh: the local mirror from which /usr/src was updated had last been updated a bit before 0400 hrs US/Pacific on 02 Apr 2006. Peace, david -- David H. Wolfskill david@catwhisker.org Mail filters, like sewers, need to be most restrictive at the point of entry. See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 17:27:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5622116A400 for ; Mon, 3 Apr 2006 17:27:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4393443D81 for ; Mon, 3 Apr 2006 17:27:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k33HRaZ7043864; Mon, 3 Apr 2006 13:27:36 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Conrad J. Sabatier" Date: Mon, 3 Apr 2006 11:56:27 -0400 User-Agent: KMail/1.9.1 References: <20060329020527.f8f087a4.conrads@cox.net> <200603290842.40970.jhb@freebsd.org> <20060402060323.cbe762a7.conrads@cox.net> In-Reply-To: <20060402060323.cbe762a7.conrads@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604031156.28916.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1369/Mon Apr 3 06:25:15 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: device atpic to be deprecated? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 17:27:45 -0000 On Sunday 02 April 2006 07:03, Conrad J. Sabatier wrote: > On Wed, 29 Mar 2006 08:42:40 -0500 > John Baldwin wrote: > > > On Wednesday 29 March 2006 03:05 am, Conrad J. Sabatier wrote: > > > While searching the mailing lists recently on an unrelated subject, I > > > happened across a message mentioning the intended removal of "device atpic" > > > in 7.0. So, I tried building a kernel without it on my RELENG_6 amd64 box > > > (nVidia nForce 3 chipset) and discovered that it was unable to mount the > > > root slice. > > > > > > Naturally, I'm a little concerned about this. :-) > > > > Some more details would be handy. :) Is your machine UP or SMP? > > It's a uniprocessor box: > > FreeBSD 6.1-PRERELEASE #4: Fri Mar 31 18:42:21 CST 2006 > conrads@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3200+ (1995.01-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0xf4a Stepping = 10 > Features=0x78bfbff CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > AMD Features=0xe0500800 > real memory = 1073479680 (1023 MB) > avail memory = 1026379776 (978 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > (...) Ok. Can you provide verbose dmesg's (boot -v) from a kernel w/o 'device atpic' and a kernel with 'device atpic'? -- 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 Apr 3 17:35:59 2006 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 E35BF16A400 for ; Mon, 3 Apr 2006 17:35:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5880343D45 for ; Mon, 3 Apr 2006 17:35:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 867D846C40; Mon, 3 Apr 2006 13:35:58 -0400 (EDT) Date: Mon, 3 Apr 2006 18:35:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Wolfskill , dhw@mail-abuse.org In-Reply-To: <20060403172611.GA83741@bunrab.catwhisker.org> Message-ID: <20060403183158.O76562@fledge.watson.org> References: <20060403172611.GA83741@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Panic "div_bind: inp == NULL" on -CURRENT from 02 Apr 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 17:36:00 -0000 On Mon, 3 Apr 2006, David Wolfskill wrote: > [I'm at least a week behind on mail -- just got back in town over the > weekend -- so if this has been covered, I apologize for the duplication.] > > I've been tracking both RELENG_6 & HEAD on my laptop on a daily basis for a > while; I also try to track them on a weekly basis on my desktop at work. > On 25 March, I had no problem doing that; on 02 April, RELENG_6 was fine, > but HEAD hit a panic during the transition from single-user mode to > multi-user mode -- but only on my work desktop (my laptop doesn't exhibit > the problem at all). > > I *suspect* -- based on the sequence of events -- that the initial panic may > well be associated with a NIC, and that the kbd driver gets a secondary > panic; regardless of what I suspect, the keyboard isn't usable once the > panic message spits out, but a serial console does work. > > The nice thing is that the panic appears to be 100% reproducible; here is a > cut/paste from the serial console: You'll want to pick up ip_divert.c:1.117, which I committed earlier today: revision 1.117 date: 2006/04/03 09:01:17; author: rwatson; state: Exp; lines: +1 -1 Correct incorrect assertion in div_bind(): inp must not be NULL here. Reported by: tegge MFC after: 3 months This was fallout from my network stack related commits over the weekend, which I'm in the process of sweeping up. Robert N M Watson > > /boot/kernel/acpi.ko text=0x43b18 data=0x24a0+0xff0 syms=[0x4+0x7c10+0x4+0xa8bb] > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2006 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 #41: Sun Apr 2 16:10:36 PDT 2006 > root@catmint.mail-abuse.org:/common/S3/obj/usr/src/sys/CATMINT > WARNING: WITNESS option enabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.02-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > Features=0xbfebfbff > Features2=0x441d> > real memory = 535232512 (510 MB) > avail memory = 514162688 (490 MB) > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > 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_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xed98-0xed9f mem 0xe8000000-0xefffffff,0xfeb80000-0xfebfffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 892k stolen memory > agp0: aperture size is 128M > uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb3: EHCI version 1.0 > usb3: wrong number of companions (4 != 3) > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 8 ports with 8 removable, self powered > pcib1: at device 30.0 on pci0 > pci1: on pcib1 > dc0: port 0xdf00-0xdf7f mem 0xfe9fec00-0xfe9fefff irq 21 at device 0.0 on pci1 > miibus0: on dc0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:c0:f0:3b:ea:b7 > fxp0: port 0xdec0-0xdeff mem 0xfe9ff000-0xfe9fffff irq 20 at device 8.0 on pci1 > miibus1: on fxp0 > inphy0: on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:13:20:2d:f5:b7 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7ffff irq 18 at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 31.3 (no driver attached) > pcm0: port 0xee00-0xeeff,0xedc0-0xedff mem 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0 > pcm0: primary codec not ready! > pcm0: > speaker0: port 0x61 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, console > sio0: [FAST] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 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 > ppc0: [GIANT-LOCKED] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xca7ff,0xca800-0xcbfff pnpid ORM0000 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 2793016905 Hz quality 800 > Timecounters tick every 1.000 msec > IPv6 packet filtering initialized, unlimited logging > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to deny, logging unlimited > ad0: 38146MB at ata0-master UDMA100 > acd0: CDROM at ata1-master UDMA33 > Trying to mount root from ufs:/dev/ad0s3a > dc0: link state changed to UP > fxp0: link state changed to UP > panic: div_bind: inp == NULL > cpuid = 0 > KDB: enter: panic > [thread pid 254 tid 100056 ] > Stopped at kdb_enter+0x2b: nop > db> bt > Tracing pid 254 tid 100056 td 0xc34236c0 > kdb_enter(c0866a2c) at kdb_enter+0x2b > panic(c08758c6,0,c34236c0,c3680240,d568dc44) at panic+0x127 > div_bind(c367abac,c3680240,c34236c0,d568dc68,c0685f87) at div_bind+0x1d > sobind(c367abac,c3680240,c34236c0,c35d0b40,d568dd04) at sobind+0x16 > kern_bind(c34236c0,3,c3680240,c3680240,0) at kern_bind+0x5b > bind(c34236c0,d568dd04,c0928080,c32e4a00,0) at bind+0x2f > syscall(3b,3b,3b,8210150,bfbfee20) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (104, FreeBSD ELF32, bind), eip = 0x28103d37, esp = 0xbfbeeb9c, ebp = 0xbfbfee48 --- > db> panic > panic: from debugger > cpuid = 0 > Uptime: 5s > Dumping 510 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 510MB (130416 pages) 494 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 > Automatic reboot in 15 seconds - press a key on the console to abort > > > At this point, I'll await suggestions. I can make the dump available, I > expect, should that be useful. I'm not sure how soon I will be able to > do much with my email backlog (which was at around 1K messages), so I've > set Reply-To to add an address for which I'll be monitoring mail more > closely during the workday. > > Oh: the local mirror from which /usr/src was updated had last been > updated a bit before 0400 hrs US/Pacific on 02 Apr 2006. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Mail filters, like sewers, need to be most restrictive at the point of entry. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 18:25:01 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C29B716A401 for ; Mon, 3 Apr 2006 18:25:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5344743D46 for ; Mon, 3 Apr 2006 18:25:01 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k33IOsTU019965; Mon, 3 Apr 2006 14:24:54 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 3 Apr 2006 14:24:36 -0400 User-Agent: KMail/1.6.2 References: <20060329020527.f8f087a4.conrads@cox.net> <442A5354.4020108@samsco.org> In-Reply-To: <442A5354.4020108@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200604031424.38375.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1370/Mon Apr 3 13:31:59 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: "Conrad J. Sabatier" Subject: Re: device atpic to be deprecated? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 18:25:01 -0000 On Wednesday 29 March 2006 04:28 am, Scott Long wrote: > There might have been hope at one time that amd64 would not > need it. I beleive that that ioapic is part of the amd64 > system spec that motherboard/chipset makers must implement. Don't forget we also have EM64T support. I have a box with Intel CPUs and it doesn't work without ATPIC. :-( > However, engineering inertia is hard to overcome, and it's > likely that this is just a fantasy. For i386, it simply has > no chance of ever going away. My guess is that it'll take > a next generation platform to completely do away with ISA, > ATPIC, and other legacy components. Hmmm.... maybe that > next-gen platform is the MacIntel? That's another issue. We don't have EFI loader for amd64/i386 and amd64/i386 requires BIOS to boot. Unfortunately we are stuck in the middle of transition. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 19:07:13 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76FA016A400; Mon, 3 Apr 2006 19:07:13 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F8743D64; Mon, 3 Apr 2006 19:07:12 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 7ABF28244C4; Mon, 3 Apr 2006 16:07:06 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 61860-09; Mon, 3 Apr 2006 16:07:08 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id CC74582448C; Mon, 3 Apr 2006 16:07:05 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id BC73238A6B; Mon, 3 Apr 2006 16:07:07 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id BB02C341E8; Mon, 3 Apr 2006 16:07:07 -0300 (ADT) Date: Mon, 3 Apr 2006 16:07:07 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20060403174952.E76562@fledge.watson.org> Message-ID: <20060403160231.P947@ganymede.hub.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060403132401.I947@ganymede.hub.org> <20060403174952.E76562@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 19:07:13 -0000 On Mon, 3 Apr 2006, Robert Watson wrote: > So the question is this: if you load System V IPC support after you > start a jail, how do we handle jails that have already started? Do we go > out and create new name spaces for jails already started (a problem for > method (1), because it implies System V IPC will have pretty intimate > knowledge of jails, and know how to walk lists, etc), do we deny access > to System V IPC for jails not present when it was loaded? Likewise, > although we tend to refer to the different IPC mechanisms as in a single > category, System V IPC, there are actually three name spaces, and the > functionality for each can be loaded separately. Stupid question, but why does a namespace need to be created prior to a process in the jail needing it? "if jail requests IPC, and IPC is loaded, then create namespace at that point" ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 19:22:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FCF816A400 for ; Mon, 3 Apr 2006 19:22:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0388B43D5F for ; Mon, 3 Apr 2006 19:22:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k33JMO8V044663; Mon, 3 Apr 2006 15:22:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 3 Apr 2006 15:22:20 -0400 User-Agent: KMail/1.9.1 References: <442EE1D7.90909@samsco.org> <442EE429.9020500@gmail.com> <442EE79B.1060003@bitfreak.org> In-Reply-To: <442EE79B.1060003@bitfreak.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604031522.22302.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1370/Mon Apr 3 13:31:59 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Darren Pilgrim , Rainer Alves Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 19:22:28 -0000 On Saturday 01 April 2006 15:50, Darren Pilgrim wrote: > Rainer Alves wrote: > >> It is my great pleasure and privilege to announce the availability of > >> FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN > >> months of tireless work. > > > > Small typo, you probably mean 77 *years* here... how's that for a time > > travel. > > Happy april 1st everyone. > > cvsweb.freebsd.org is a wayback machine. Can it go all the way back to the beginning of time? No Sherman, just to 2.0. -- 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 Apr 3 19:28:16 2006 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 4CEBF16A420 for ; Mon, 3 Apr 2006 19:28:16 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B9A943D75 for ; Mon, 3 Apr 2006 19:28:12 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 48133 invoked from network); 3 Apr 2006 19:28:10 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 3 Apr 2006 19:28:10 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k33JS9rJ091882; Mon, 3 Apr 2006 21:28:09 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k33JS90v091881; Mon, 3 Apr 2006 21:28:09 +0200 (CEST) (envelope-from pho) Date: Mon, 3 Apr 2006 21:28:08 +0200 From: Peter Holm To: Tor Egge Message-ID: <20060403192808.GA91475@peter.osted.lan> References: <20060402094431.GA81954@peter.osted.lan> <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> <20060402190910.GA12759@peter.osted.lan> <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 19:28:16 -0000 On Sun, Apr 02, 2006 at 08:48:51PM +0000, Tor Egge wrote: > > > The enclosed patch might help. > > > > > > > I'm testing it right now. > > Similarly to the softdepflush process looping in softdep_flush(), the process > creating a snapshot might loop in ffs_sync(). > I ran the same test with your first patch for two hours and your second patch for 7 hours, without seeing any livelocks. I added snapshots to the test and still did not get any livelocks, but I'm not certain that this last test covers your change. - Peter > - Tor Egge > Index: sys/ufs/ffs/ffs_softdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v > retrieving revision 1.193 > diff -u -r1.193 ffs_softdep.c > --- sys/ufs/ffs/ffs_softdep.c 12 Mar 2006 05:25:16 -0000 1.193 > +++ sys/ufs/ffs/ffs_softdep.c 2 Apr 2006 20:20:15 -0000 > @@ -718,6 +718,7 @@ > { > struct mount *nmp; > struct mount *mp; > + struct ufsmount *ump; > struct thread *td; > int remaining; > int vfslocked; > @@ -752,7 +753,9 @@ > continue; > vfslocked = VFS_LOCK_GIANT(mp); > softdep_process_worklist(mp, 0); > - remaining += VFSTOUFS(mp)->softdep_on_worklist; > + ump = VFSTOUFS(mp); > + remaining += ump->softdep_on_worklist - > + ump->softdep_on_worklist_inprogress; > VFS_UNLOCK_GIANT(vfslocked); > mtx_lock(&mountlist_mtx); > nmp = TAILQ_NEXT(mp, mnt_list); > @@ -914,11 +917,17 @@ > if ((flags & LK_NOWAIT) == 0 || wk->wk_type != D_DIRREM) > break; > wk->wk_state |= INPROGRESS; > + ump->softdep_on_worklist_inprogress++; > FREE_LOCK(&lk); > ffs_vget(mp, WK_DIRREM(wk)->dm_oldinum, > LK_NOWAIT | LK_EXCLUSIVE, &vp); > ACQUIRE_LOCK(&lk); > wk->wk_state &= ~INPROGRESS; > + if (--ump->softdep_on_worklist_inprogress == 0 && > + ump->softdep_on_worklist_inprogress_req != 0) { > + ump->softdep_on_worklist_inprogress_req = 0; > + wakeup(&ump->softdep_on_worklist_inprogress); > + } > if (vp != NULL) > break; > } > @@ -6099,6 +6108,17 @@ > VI_LOCK(devvp); > continue; > } > + if (ump->softdep_on_worklist_inprogress != 0) { > + VI_UNLOCK(devvp); > + ump->softdep_on_worklist_inprogress_req = 1; > + msleep(&ump->softdep_on_worklist_inprogress, > + &lk, > + (PUSER - 1) | PDROP, > + "sdipdr" /* soft dep in progress drain */, > + 0); > + VI_LOCK(devvp); > + continue; > + } > if (!MNT_ITRYLOCK(mp)) { > FREE_LOCK(&lk); > VI_UNLOCK(devvp); > Index: sys/ufs/ufs/ufsmount.h > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ufs/ufsmount.h,v > retrieving revision 1.36 > diff -u -r1.36 ufsmount.h > --- sys/ufs/ufs/ufsmount.h 8 Mar 2006 23:43:39 -0000 1.36 > +++ sys/ufs/ufs/ufsmount.h 2 Apr 2006 20:20:15 -0000 > @@ -76,6 +76,8 @@ > struct workhead softdep_workitem_pending; /* softdep work queue */ > struct worklist *softdep_worklist_tail; /* Tail pointer for above */ > int softdep_on_worklist; /* Items on the worklist */ > + int softdep_on_worklist_inprogress; /* Busy items on worklist */ > + int softdep_on_worklist_inprogress_req;/* Wakeup when not busy */ > int softdep_deps; /* Total dependency count */ > int softdep_accdeps; /* accumulated dep count */ > int softdep_req; /* Wakeup when deps hits 0. */ -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 19:40:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05F116A422; Mon, 3 Apr 2006 19:40:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE9B443D70; Mon, 3 Apr 2006 19:40:53 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 03 Apr 2006 12:40:54 -0700 Message-ID: <44317A45.9000504@elischer.org> Date: Mon, 03 Apr 2006 12:40:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> In-Reply-To: <20060403163220.F36756@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Marc G. Fournier" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org, pjd@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 19:40:56 -0000 Robert Watson wrote: > > On Mon, 3 Apr 2006, Marc G. Fournier wrote: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471 >> >> [kernel] [patch] new feature: private IPC for every jail >> >> Its an ancient, 4.x patch for having private IPC in a jail ... not >> sure how hard it would be to bring it up to 6.x / -current standards >> though ... but it seems like something 'good' that is needed ... > > > In the past I've looked at doing things along these lines, but usually > stall after a first hack when trying to decide how to deal with two > critical issues: > > (1) The fact that system v ipc primitives are loadable, and > unloadable, which > requires some careful handling relating to registration order, etc. this is related to the problem that needs to be solved for getting vimage into -current. > > (2) The name space model for system v ipc is flat, so while it's > desirable to > allow the administrator in the host environment to monitor and > control > resource use in the jail (for example, delete allocated but unused > segments), doing that requires developing an administrative model > for it. it is possible the admin environment can't see it. unless you prefix it with something.. > > These challenges can be surmounted, but the doing them in a nice way > requires some thought. > > Robert N M Watson > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 20:34:10 2006 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 CB28916A400; Mon, 3 Apr 2006 20:34:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AF0143D73; Mon, 3 Apr 2006 20:34:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E313B1A3C25; Mon, 3 Apr 2006 13:34:03 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 37D3A54A79; Mon, 3 Apr 2006 16:34:03 -0400 (EDT) Date: Mon, 3 Apr 2006 16:34:03 -0400 From: Kris Kennaway To: Peter Holm Message-ID: <20060403203402.GA89233@xor.obsecurity.org> References: <20060402094431.GA81954@peter.osted.lan> <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> <20060402190910.GA12759@peter.osted.lan> <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> <20060403192808.GA91475@peter.osted.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20060403192808.GA91475@peter.osted.lan> User-Agent: Mutt/1.4.2.1i Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 20:34:10 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 03, 2006 at 09:28:08PM +0200, Peter Holm wrote: > On Sun, Apr 02, 2006 at 08:48:51PM +0000, Tor Egge wrote: > > > > The enclosed patch might help. > > > >=20 > > >=20 > > > I'm testing it right now. > >=20 > > Similarly to the softdepflush process looping in softdep_flush(), the p= rocess > > creating a snapshot might loop in ffs_sync(). > >=20 >=20 > I ran the same test with your first patch for two hours and your > second patch for 7 hours, without seeing any livelocks. >=20 > I added snapshots to the test and still did not get any livelocks, but > I'm not certain that this last test covers your change. Hmm, there is a PR reporting hangs when removing many files with snapshots enabled, on 6.0. I tried to reproduce it on 6.1 but failed with the test case that the PR said was a reliable cause for them, so I assumed it was fixed. It may be that I didn't try hard enough though, since I didn't see your problem either. Kris --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEMYa6Wry0BWjoQKURAr6DAKD5iGz6aYO5LNPlgFj4RixFonaJfQCgt3S3 gut18DnWCkJsG6rmLzp6wx8= =hHdh -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 20:37:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 623F616A400 for ; Mon, 3 Apr 2006 20:37:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B2E43D45 for ; Mon, 3 Apr 2006 20:37:28 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [127.0.0.1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.4/8.12.9) with ESMTP id k33KbKWV045729; Mon, 3 Apr 2006 22:37:21 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <17457.4249.383686.765032@roam.psg.com> References: <17457.4249.383686.765032@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 3 Apr 2006 22:36:44 +0200 To: Randy Bush X-Mailer: Apple Mail (2.746.3) Cc: FreeBSD Current Subject: Re: natd when doubled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 20:37:30 -0000 Am 03.04.2006 um 14:10 schrieb Randy Bush: > i am in a hotel which gives me an address from 10/8 on the ether. > i have it plugged into em0 on a -current system. > > i have another machine on wireless out the ath0 port which is > configured as 192.168.0.1 > > my natd.conf is > > dynamic yes > unregistered_only yes > interface em0 > > my ipfw.rules sez > > add divert natd all from 192.168.0.0/24 to any via em0 > add divert natd all from any to 192.168.0.0/24 via ath0 natd works on the outbound interface, so "divert natd from any to any via em0" should be just the right thing. Packets originating on em0 will be left alone by natd, and replies that natd doesn't know how to handle will be processed as if natd hadn't been in the loop (modulo - deny_incoming). Also, make sure forwarding is enabled. As long as packets received on ath0 will be routed out on em0, and the return route via ath0 is set correctly, it should work. This would be a standard setup for a cable modem or ADSL with direct ethernet (as opposed to PPPoE or PPPoA). HTH, Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 21:04:09 2006 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 DEA7F16A400; Mon, 3 Apr 2006 21:04:08 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id E570243D45; Mon, 3 Apr 2006 21:04:07 +0000 (GMT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.13.6/8.13.1) with ESMTP id k33L44AH016483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2006 23:04:04 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.13.4/8.13.4) with ESMTP id k33L433U008673; Mon, 3 Apr 2006 21:04:03 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Mon, 03 Apr 2006 21:04:03 +0000 (UTC) Message-Id: <20060403.210403.74745739.Tor.Egge@cvsup.no.freebsd.org> To: peter@holm.cc From: Tor Egge In-Reply-To: <20060403192808.GA91475@peter.osted.lan> References: <20060402190910.GA12759@peter.osted.lan> <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> <20060403192808.GA91475@peter.osted.lan> 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 X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 21:04:09 -0000 > I ran the same test with your first patch for two hours and your > second patch for 7 hours, without seeing any livelocks. > > I added snapshots to the test and still did not get any livelocks, but > I'm not certain that this last test covers your change. On third thought, the second patch is probably not necessary. The calls to process_worklist_item() with LK_NOWAIT as flags has to be inside regions protected by vn_start_write()/vn_finished_write() or vn_start_secondary_write()/vn_finished_secondary_write() since the calling functions (ffs_alloc(), ffs_realloccg(), newdirrem(), softdep_setup_freeblocks(), softdep_setup_directory_add(), softdep_setup_directory_change(), softdep_change_linkcnt()) involve write operations. I did not take that into account when I had second thoughts about the first patch. vfs_write_suspend() sleeps until noone is inside regions protected by vn_start_write()/vn_finished_write() for that file system before calling VFS_SYNC(). softdep_check_suspend() sleeps until noone is inside regions protected by vn_start_secondary_write()/vn_finished_secondary_write() for that file system. Thus, with the first patch applied, ump->softdep_on_worklist_inprogress will always be zero when softdep_check_suspend() returns. - Tor Egge From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 21:12:45 2006 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 854E916A424 for ; Mon, 3 Apr 2006 21:12:45 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id ABD0943D58 for ; Mon, 3 Apr 2006 21:12:44 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 15930 invoked from network); 3 Apr 2006 21:12:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; b=alV9ghxMvBugilwBE87cGMPfmNveItZzkuxX1uGEBlcu6Q2hdMUeKrg8EQLz+VA3UA0zqtLC5x6SLfmEwjiKjt2bYsMlfy+5YPEpDBHI+abpakCDj0LOhS2C7I8nqd4N5Y28S2u/ult4ulXkRVj+YYlSfTAI8HqAXCc1NGWJCMA= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2006 21:12:43 -0000 Message-ID: <44318FD2.1050206@rogers.com> Date: Mon, 03 Apr 2006 17:12:50 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sos@FreeBSD.ORG Subject: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 21:12:45 -0000 It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA chipset, and we are still missing it. Is there any way to port their code over? There are a few nice motherboards out there that use this chipset (most amd server boards use the crappy nvidia chipset and the accompanying crappy network card). --- http://www.openbsd.org/39.html#new From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 21:13:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7912616A400 for ; Mon, 3 Apr 2006 21:13:39 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3815F43D69 for ; Mon, 3 Apr 2006 21:13:33 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MH-MR001.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0IX600DPG0AKLAD0@VL-MH-MR001.ip.videotron.ca> for freebsd-current@freebsd.org; Mon, 03 Apr 2006 17:13:32 -0400 (EDT) Date: Mon, 03 Apr 2006 17:13:25 -0400 From: Nicolas Blais In-reply-to: <790a9fff0603310612v72b9528ewf52e53ec5fc1b647@mail.gmail.com> To: freebsd-current@freebsd.org Message-id: <200604031713.31780.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart3468637.G3srHdXOX0; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <790a9fff0603300616y62afae4cp50b448b53112de8c@mail.gmail.com> <20060331124817.GA83081@fit.vutbr.cz> <790a9fff0603310612v72b9528ewf52e53ec5fc1b647@mail.gmail.com> User-Agent: KMail/1.9.1 Subject: Re: wpa_supplicant fails to find the NDIS adapter names X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 21:13:39 -0000 --nextPart3468637.G3srHdXOX0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 31 March 2006 09:12, Scot Hetzel wrote: > On 3/31/06, Rudolf Cejka wrote: > > Scot Hetzel wrote (2006/03/30): > > > NDIS: Failed to get adapter list (PacketGetAdapterNames) > > > Failed to initialize driver interface > > > > Hello, please see PR bin/94735 - you can try to give your force > > so somebody will commit it ;o) > > The first patch in that PR is exactly what I am using (except I used > TRUE/FALSE instead of 0/1). > > Scot Could someone commit one of the patches on PR bin/94735 ASAP on -CURRENT=20 and -STABLE? Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #0: Sat Apr 1 10:05:34 EST 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart3468637.G3srHdXOX0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEMY/74wTBlvcsbJURAjBbAJ4oF+GMKE5gkMRLgEjD4U88zi53oACgkguq LM6+DVF/kTfrUIfPb1SbxuM= =Nw87 -----END PGP SIGNATURE----- --nextPart3468637.G3srHdXOX0-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 22:07:18 2006 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 4BB5616A423 for ; Mon, 3 Apr 2006 22:07:18 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 63B0D43D46 for ; Mon, 3 Apr 2006 22:07:17 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 43585 invoked from network); 3 Apr 2006 22:07:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0AY1/007jdNcm+nmkdO5qYueIOT+e2w3ROJFSTNid6luvbgzV3mExpS36VV8r2P7Io2Uqdmq1bhmuz9bZkjviHmunaSdJVgmJI4xBkAQAaVQqxGEXNoQ3tVbr95ELiLObThbzHO8HIseWMu4mv/++v0hfvtyTvQUtm5eH7qAmOo= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2006 22:07:15 -0000 Message-ID: <44319C9A.1060105@rogers.com> Date: Mon, 03 Apr 2006 18:07:22 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> In-Reply-To: <443196DD.603@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 22:07:18 -0000 Søren Schmidt wrote: > Mike Jakubik wrote: >> It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA >> chipset, and we are still missing it. Is there any way to port their >> code over? There are a few nice motherboards out there that use this >> chipset (most amd server boards use the crappy nvidia chipset and the >> accompanying crappy network card). > > I've been promised a board with the serverworks chipset on it so I can > get support running, as you can probably figure out it hasn't > materialized yet, and no timeline as to when/if. > The Openbsd code is of as much use as the Linux counterpart. I need HW > to test and maintain support, simple as that... I see. If i could id contribute, but alas I'm unemployed now. Maybe freebsd should charge for CDs like openbsd does, to fund the cause :P From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 22:16:19 2006 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 722BC16A420 for ; Mon, 3 Apr 2006 22:16:19 +0000 (UTC) (envelope-from ps@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A2D343D46 for ; Mon, 3 Apr 2006 22:16:18 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [216.145.53.62] (lactose.corp.yahoo.com [216.145.53.62]) by elvis.mu.org (Postfix) with ESMTP id E8F881A3C29; Mon, 3 Apr 2006 15:16:18 -0700 (PDT) Message-ID: <44319E9F.9010909@freebsd.org> Date: Mon, 03 Apr 2006 15:15:59 -0700 From: Paul Saab User-Agent: Mail/News 1.5.0.2 (Macintosh/20060324) MIME-Version: 1.0 To: Mike Jakubik References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> <44319C9A.1060105@rogers.com> In-Reply-To: <44319C9A.1060105@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org, =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 22:16:19 -0000 Mike Jakubik wrote: > Søren Schmidt wrote: >> Mike Jakubik wrote: >>> It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA >>> chipset, and we are still missing it. Is there any way to port their >>> code over? There are a few nice motherboards out there that use this >>> chipset (most amd server boards use the crappy nvidia chipset and >>> the accompanying crappy network card). >> >> I've been promised a board with the serverworks chipset on it so I >> can get support running, as you can probably figure out it hasn't >> materialized yet, and no timeline as to when/if. >> The Openbsd code is of as much use as the Linux counterpart. I need >> HW to test and maintain support, simple as that... > The hardware to support this stuff should go out this week to Søren. From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 22:22:56 2006 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 C22F816A428 for ; Mon, 3 Apr 2006 22:22:56 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by mx1.FreeBSD.org (Postfix) with SMTP id E1B4143D48 for ; Mon, 3 Apr 2006 22:22:55 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 93321 invoked from network); 3 Apr 2006 22:22:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ejYTZXNBy3s1Qcy4Xv3EJfUSGoDA4XPCrbE16GbpcdI/AnWZTCC8X/wBZwg8QKL5eKDnfLmBknzj6AK8xS+Yf522GETT7kx9R4pkKgXaErrCvBiOgs/zIxmXHYLhBi0NhDPng3Mbr2f5+9mdr1KYJpD4MQv3W2J/AuSQwFDhQ5M= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2006 22:22:55 -0000 Message-ID: <4431A043.3040205@rogers.com> Date: Mon, 03 Apr 2006 18:22:59 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Saab References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> <44319C9A.1060105@rogers.com> <44319E9F.9010909@freebsd.org> In-Reply-To: <44319E9F.9010909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org, =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 22:22:56 -0000 Paul Saab wrote: > The hardware to support this stuff should go out this week to Søren. Excellent! Thanks for the donation Paul! From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 22:35:34 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AC8016A400; Mon, 3 Apr 2006 22:35:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76E4843D58; Mon, 3 Apr 2006 22:35:22 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4F55B46C4D; Mon, 3 Apr 2006 18:35:21 -0400 (EDT) Date: Mon, 3 Apr 2006 23:35:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20060403160231.P947@ganymede.hub.org> Message-ID: <20060403233030.W76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060403132401.I947@ganymede.hub.org> <20060403174952.E76562@fledge.watson.org> <20060403160231.P947@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 22:35:35 -0000 On Mon, 3 Apr 2006, Marc G. Fournier wrote: > On Mon, 3 Apr 2006, Robert Watson wrote: > >> So the question is this: if you load System V IPC support after you start a >> jail, how do we handle jails that have already started? Do we go out and >> create new name spaces for jails already started (a problem for method (1), >> because it implies System V IPC will have pretty intimate knowledge of >> jails, and know how to walk lists, etc), do we deny access to System V IPC >> for jails not present when it was loaded? Likewise, although we tend to >> refer to the different IPC mechanisms as in a single category, System V >> IPC, there are actually three name spaces, and the functionality for each >> can be loaded separately. > > Stupid question, but why does a namespace need to be created prior to a > process in the jail needing it? "if jail requests IPC, and IPC is loaded, > then create namespace at that point" ... ? In principle, it can be done any time, but there are some nice simplifying assumptions about doing it up-front: among these is that the point of jail creation is very useful from a security perspective because you're not running contained code at that point, only code that's sufficiently privileged to perform the jail creation operation, and that you can avoid extra synchronization (locking) of the name space reference to make sure it's acessed and allocated with reasonable atomicity. It should be possible to allocate on demand, although there could be catches I haven't thought of by virtue of not trying it. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 01:05:59 2006 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 4144E16A422 for ; Tue, 4 Apr 2006 01:05:59 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71A043D48 for ; Tue, 4 Apr 2006 01:05:58 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k3415Kbi003199 for ; Mon, 3 Apr 2006 21:05:20 -0400 X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by pimout7-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k3415nC4117846; Mon, 3 Apr 2006 21:05:50 -0400 Message-ID: <4431C647.7050608@root.org> Date: Mon, 03 Apr 2006 18:05:11 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Angka H. K." References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> In-Reply-To: <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 01:05:59 -0000 Angka H. K. wrote: > Thanks for the replay > I am updating my source now and planing to rebuild it again, but I don't see > any changes on ACPI code. > > I was mistype on the val that return by kernel, the error should be "acpi: > bad write to port 0x073(8) val 20", I am sorry. > Hope it'll be fixed soon. > > FYI : I am using HP V2388TU with current source. The error is produced by > source updated at 2 April 2006 > > > On 4/3/06, Alexander Leidinger wrote: >> "Angka H. K." wrote: >> >> Please strip freebsd-multimedia@ on reply... >> >>> I have other problem now , which is saying "acpi: bad read to port >> 0x073" >>> and "acpi: bad write to port 0x073(8) val 82", where can ask about this >> ? It >>> looks like google has no archive about this error. >> I assume you are using -current. So the right place is to ask on current@ >> (CCed). I also CCed njl@, since he's our "master of acpi". This error message is only a warning currently. Are you sure it's 0x73? That's not on the blacklist. We note reads/writes to 0x70 - 0x71 and 0x74 - 0x76. Those are the CMOS and RTC areas and AML shouldn't write there. /* * Some BIOS vendors use AML to read/write directly to IO space. This * can cause a problem if such accesses interfere with the OS's access to * the same ports. Windows XP and newer systems block accesses to certain * IO ports. We print a message or block accesses based on a tunable. */ static int illegal_bios_ports[] = { 0x000, 0x00f, /* DMA controller 1 */ 0x020, 0x021, /* PIC */ 0x040, 0x043, /* Timer 1 */ 0x048, 0x04b, /* Timer 2 failsafe */ 0x070, 0x071, /* CMOS and RTC */ 0x074, 0x076, /* Extended CMOS */ 0x081, 0x083, /* DMA1 page registers */ 0x087, 0x087, /* DMA1 ch0 low page */ 0x089, 0x08b, /* DMA2 ch2 (0x89), ch3 low page (0x8a, 0x8b) */ 0x08f, 0x091, /* DMA2 low page refresh (0x8f) */ /* Arb ctrl port, card select feedback (0x90, 0x91) */ 0x093, 0x094, /* System board setup */ 0x096, 0x097, /* POS channel select */ 0x0a0, 0x0a1, /* PIC (cascaded) */ 0x0c0, 0x0df, /* ISA DMA */ 0x4d0, 0x4d1, /* PIC ELCR (edge/level control) */ 0xcf8, 0xcff, /* PCI config space. Microsoft adds 0xd00 also but that seems incorrect. */ -1, -1 }; In the future, this warning will become an error and the access will be rejected. That's to prevent bad AML from conflicting with drivers and hanging or crashing the system. Your system has always had this behavior, we're just detecting it now. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 01:07:36 2006 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 4FC7B16A400 for ; Tue, 4 Apr 2006 01:07:36 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A47143D55 for ; Tue, 4 Apr 2006 01:07:35 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm01.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k3417Wag031017 for ; Mon, 3 Apr 2006 21:07:32 -0400 X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by pimout7-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k3417U4q118334; Mon, 3 Apr 2006 21:07:33 -0400 Message-ID: <4431C6AB.2040104@root.org> Date: Mon, 03 Apr 2006 18:06:51 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Angka H. K." References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> In-Reply-To: <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 01:07:36 -0000 Angka H. K. wrote: > Thanks for the replay > I am updating my source now and planing to rebuild it again, but I don't see > any changes on ACPI code. > > I was mistype on the val that return by kernel, the error should be "acpi: > bad write to port 0x073(8) val 20", I am sorry. > Hope it'll be fixed soon. > > FYI : I am using HP V2388TU with current source. The error is produced by > source updated at 2 April 2006 > > > On 4/3/06, Alexander Leidinger wrote: >> "Angka H. K." wrote: >> >> Please strip freebsd-multimedia@ on reply... >> >>> I have other problem now , which is saying "acpi: bad read to port >> 0x073" >>> and "acpi: bad write to port 0x073(8) val 82", where can ask about this >> ? It >>> looks like google has no archive about this error. >> I assume you are using -current. So the right place is to ask on current@ >> (CCed). I also CCed njl@, since he's our "master of acpi". Ah, I see a logic error in the code (off by one) so it's triggering on 0x73. I'll commit a fix. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 02:07:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C8DA16A400 for ; Tue, 4 Apr 2006 02:07:23 +0000 (UTC) (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 2BF9743D45 for ; Tue, 4 Apr 2006 02:07:21 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQb2U-0003gA-Vm for freebsd-current@freebsd.org; Tue, 04 Apr 2006 11:13:04 +0900 Message-ID: <4431D4E5.3080507@micom.mng.net> Date: Tue, 04 Apr 2006 11:07:33 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 02:07:23 -0000 Hi, I've got panic "CPU class not configured" on today's CURRENT. I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. When machine tries to boot following message appears: ... CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) ... logical CPUs per core: 2 panic: CPU class not configured cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] stopped at kdb_enter+0x2b : nop db> Ganbold From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 02:29:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C199216A401 for ; Tue, 4 Apr 2006 02:29:30 +0000 (UTC) (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 131E343D48 for ; Tue, 4 Apr 2006 02:29:27 +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.4/8.13.4) with ESMTP id k342TPGw043099; Mon, 3 Apr 2006 20:29:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4431D9FE.4030602@samsco.org> Date: Mon, 03 Apr 2006 20:29:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganbold References: <4431D4E5.3080507@micom.mng.net> In-Reply-To: <4431D4E5.3080507@micom.mng.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 02:29:30 -0000 Ganbold wrote: > Hi, > > I've got panic "CPU class not configured" on today's CURRENT. > I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. > > When machine tries to boot following message appears: > ... > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) > ... > logical CPUs per core: 2 > panic: CPU class not configured > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > stopped at kdb_enter+0x2b : nop > db> > > Ganbold > You need to provide the exact kernel config file that you used to produce this problem. Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 02:30:13 2006 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 7899616A400 for ; Tue, 4 Apr 2006 02:30:13 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF1A043D48 for ; Tue, 4 Apr 2006 02:30:12 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k342U6bJ012482 for ; Mon, 3 Apr 2006 22:30:06 -0400 X-ORBL: [71.139.14.61] Received: from [10.0.5.51] (ppp-71-139-14-61.dsl.snfc21.pacbell.net [71.139.14.61]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k342U6Pp110708; Mon, 3 Apr 2006 22:30:06 -0400 Message-ID: <4431DA08.3020002@root.org> Date: Mon, 03 Apr 2006 19:29:28 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Angka H. K." References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> In-Reply-To: <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 02:30:13 -0000 Angka H. K. wrote: > Thanks for the replay > I am updating my source now and planing to rebuild it again, but I don't see > any changes on ACPI code. > > I was mistype on the val that return by kernel, the error should be "acpi: > bad write to port 0x073(8) val 20", I am sorry. > Hope it'll be fixed soon. Ok, I fixed the range check on ports so 0x73 should not trigger it. If you have some other write to a port that IS in the blacklist, you'll still get the warning. Ultimately, I intend to emulate what Windows does which is block all writes to the PIC, and block all writes on XP or newer BIOSen. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 02:47:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 539A616A400 for ; Tue, 4 Apr 2006 02:47:54 +0000 (UTC) (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 D555343D46 for ; Tue, 4 Apr 2006 02:47:45 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQbf9-000HQX-T0; Tue, 04 Apr 2006 11:53:30 +0900 Message-ID: <4431DE42.1020304@micom.mng.net> Date: Tue, 04 Apr 2006 11:47:30 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Scott Long References: <4431D4E5.3080507@micom.mng.net> <4431D9FE.4030602@samsco.org> In-Reply-To: <4431D9FE.4030602@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 02:47:54 -0000 Scott Long wrote: > Ganbold wrote: >> Hi, >> >> I've got panic "CPU class not configured" on today's CURRENT. >> I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. >> >> When machine tries to boot following message appears: >> ... >> CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >> ... >> logical CPUs per core: 2 >> panic: CPU class not configured >> cpuid = 0 >> KDB: enter: panic >> [thread pid 0 tid 0 ] >> stopped at kdb_enter+0x2b : nop >> db> >> >> Ganbold >> > > You need to provide the exact kernel config file that you used to > produce this problem. Sorry, actually it was yesterday's CURRENT. It is standard GENERIC kernel config file with some options commented out: #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints"GENERIC.hints"# Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols #options SCHED_ULE# ULE scheduler options SCHED_4BSD# 4BSD scheduler options PREEMPTION# Enable kernel thread preemption options INET# InterNETworking #options INET6# IPv6 communications protocols options FFS# Berkeley Fast Filesystem options SOFTUPDATES# Enable FFS soft updates support options UFS_ACL# Support for access control lists options UFS_DIRHASH# Improve performance on big directories #options MD_ROOT# MD is a potential root device #options 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_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4# Compatible with FreeBSD4 options COMPAT_FREEBSD5# Compatible with FreeBSD5 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. options STOP_NMI# Stop CPUS using NMI instead of IPI # Debugging for use in -current options KDB# Enable kernel debugger support. options DDB# Support DDB. options GDB# Support remote GDB. options INVARIANTS# Enable calls of extra sanity checking options INVARIANT_SUPPORT# Extra sanity checks of internal structures, required by INVARIANTS options WITNESS# Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP# Symmetric MultiProcessor Kernel device apic# I/O APIC # Bus support. #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk# ATA disk drives device ataraid# ATA RAID drives device atapicd# ATAPI CDROM drives #device atapifd# ATAPI floppy drives #device atapist# ATAPI tape drives options ATA_STATIC_ID# Static device numbering # SCSI Controllers device ahb# EISA AHA1742 family device ahc# AHA2940 and onboard AIC7xxx devices device ahd# AHA39320/29320 and onboard AIC79xx devices device amd# AMD 53C974 (Tekram DC-390(T)) device isp# Qlogic family #device ispfw# Firmware for QLogic HBAs- normally a module device mpt# LSI-Logic MPT-Fusion #device ncr# NCR/Symbios Logic device sym# NCR/Symbios Logic (newer chipsets + those of `ncr') device trm# Tekram DC395U/UW/F DC315U adapters device adv# Advansys SCSI adapters device adw# Advansys wide SCSI adapters device aha# Adaptec 154x SCSI adapters device aic# Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt# Buslogic/Mylex MultiMaster SCSI adapters device ncv# NCR 53C500 device nsp# Workbit Ninja SCSI-3 device stg# TMC 18C30/18C50 # SCSI peripherals 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) # RAID controllers interfaced to the SCSI subsystem device amr# AMI MegaRAID device arcmsr# Areca SATA II RAID device asr# DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* device dpt# DPT Smartcache III, IV - See NOTES for options device hptmv# Highpoint RocketRAID 182x device iir# Intel Integrated RAID device ips# IBM (Adaptec) ServeRAID device mly# Mylex AcceleRAID/eXtremeRAID device twa# 3ware 9000 series PATA/SATA RAID # RAID controllers device aac# Adaptec FSA RAID device aacp# SCSI passthrough for aac (requires CAM) device ida# Compaq Smart RAID device mfi# LSI MegaRAID SAS device mlx# Mylex DAC960 family device pst# Promise Supertrak SX6000 device twe# 3ware ATA RAID # 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 kbdmux# keyboard multiplexer 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 # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb# cardbus (yenta) bridge #device pccard# PC Card (16-bit) bus #device cardbus# CardBus (32-bit) bus # Serial (COM) ports device sio# 8250, 16[45]50 based serial ports device uart# Generic UART driver # 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 sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de# DEC/Intel DC21x4x (``Tulip'') device em# Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb# Intel PRO/10GbE Ethernet Card device txp# 3Com 3cR990 (``Typhoon'') device vx# 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus# MII bus support device bfe# Broadcom BCM440x 10/100 Ethernet device bge# Broadcom BCM570xx Gigabit Ethernet device dc# DEC/Intel 21143 and various workalikes device fxp# Intel EtherExpress PRO/100B (82557, 82558) device lge# Level 1 LXT1001 gigabit Ethernet device nge# NatSemi DP83820 gigabit Ethernet device nve# nVidia nForce MCP on-board Ethernet Networking device pcn# AMD Am79C97x PCI 10/100(precedence over 'lnc') device re# RealTek 8139C+/8169/8169S/8110S device rl# RealTek 8129/8139 device sf# Adaptec AIC-6915 (``Starfire'') device sis# Silicon Integrated Systems SiS 900/SiS 7016 device sk# SysKonnect SK-984x & SK-982x gigabit Ethernet device ste# Sundance ST201 (D-Link DFE-550TX) device ti# Alteon Networks Tigon I/II gigabit Ethernet device tl# Texas Instruments ThunderLAN device tx# SMC EtherPower II (83c170 ``EPIC'') device vge# VIA VT612x gigabit Ethernet device vr# VIA Rhine, Rhine II device wb# Winbond W89C840F device xl# 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs# Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed# NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex# Intel EtherExpress Pro/10 and Pro/10+ #device ep# Etherlink III based cards #device fe# Fujitsu MB8696x based cards #device ie# EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc# NE2100, NE32-VL Lance Ethernet cards #device sn# SMC's 9000 series of Ethernet chips #device xe# Xircom pccard Ethernet # Wireless NIC cards #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 wl# Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop# Network loopback device random# Entropy device device ether# Ethernet support #device sl# Kernel SLIP #device ppp# Kernel PPP device tun# Packet tunnel. device pty# Pseudo-ttys (telnet etc) #device md# Memory "disks" #device gif# IPv6 and IPv4 tunneling #device faith# IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # 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 # USB Ethernet, requires miibus #device aue# ADMtek USB Ethernet #device axe# ASIX Electronics USB Ethernet #device cdce# Generic USB over Ethernet #device cue# CATC USB Ethernet #device kue# Kawasaki LSI USB Ethernet #device rue# RealTek RTL8150 USB Ethernet # FireWire support #device firewire# FireWire bus code #device sbp# SCSI over FireWire (Requires scbus and da) #device fwe# Ethernet over FireWire (non-standard!) > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 03:57:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D89C316A41F for ; Tue, 4 Apr 2006 03:57:34 +0000 (UTC) (envelope-from cel@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA5DE43D55 for ; Tue, 4 Apr 2006 03:57:33 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from [192.168.0.102] (adsl-69-220-225-100.dsl.sfldmi.ameritech.net [69.220.225.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Chuck Lever", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id CA4321BC86 for ; Mon, 3 Apr 2006 23:57:32 -0400 (EDT) Message-ID: <4431EEAD.7000406@citi.umich.edu> Date: Mon, 03 Apr 2006 23:57:33 -0400 From: Chuck Lever Organization: Center for Information Technology Integration User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------010805020009000904010607" Subject: g_vfs_done errors in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cel@citi.umich.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 03:57:35 -0000 This is a multi-part message in MIME format. --------------010805020009000904010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit not sure what is going on here, but i thought i should report it. 6.0 seems to work OK. but with CURRENT, i get these about 2 minutes after rebooting: Mar 18 13:49:07 springfield kernel: g_vfs_done():ad0s1f[READ(offset=8796014739456, length=16384)]error = 5 Mar 18 13:49:08 springfield kernel: g_vfs_done():ad0s1f[READ(offset=8796014739456, length=16384)]error = 5 Mar 18 13:49:08 springfield last message repeated 2 times dozens of 'em, and then the system panics. no core dump. pciconf is attached.... the file system lives on the IDE drive, which is a fairly new Seagate. i replaced an ancient IBM Deskstar thinking i had hit a bad block, but the error with the new drive is the same. the southbridge on this mainboard (Tyan 250x) is known to have IDE issues. -- corporate: personal: --------------010805020009000904010607 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="pciconf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf" hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00091166 rev=0x06 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6536 (CNB20-LE) AGP interface' class = bridge subclass = HOST-PCI hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00091166 rev=0x06 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6536 (CNB20-LE) AGP interface' class = bridge subclass = HOST-PCI none0@pci0:1:0: class=0x030000 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class = display subclass = VGA atapci0@pci0:3:0: class=0x010400 card=0x4d32105a chip=0x4d30105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20267 FastTrack100 EIDE Controller' class = mass storage subclass = RAID isab0@pci0:15:0: class=0x060100 card=0x02001166 chip=0x02001166 rev=0x50 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 PCI to ISA Bridge' class = bridge subclass = PCI-ISA atapci1@pci0:15:1: class=0x01018a card=0x00000000 chip=0x02111166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 PCI EIDE Controller' class = mass storage subclass = ATA ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x04 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class = serial bus subclass = USB bge0@pci1:3:0: class=0x020000 card=0x100610b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme Gigabit Ethernet' class = network subclass = ethernet --------------010805020009000904010607-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 04:30:46 2006 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 C7F2E16A422 for ; Tue, 4 Apr 2006 04:30:46 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id E823543D4C for ; Tue, 4 Apr 2006 04:30:45 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 73093 invoked from network); 4 Apr 2006 04:30:44 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 4 Apr 2006 04:30:44 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k344UhDj009584; Tue, 4 Apr 2006 06:30:43 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k344UhfI009583; Tue, 4 Apr 2006 06:30:43 +0200 (CEST) (envelope-from pho) Date: Tue, 4 Apr 2006 06:30:43 +0200 From: Peter Holm To: Kris Kennaway Message-ID: <20060404043043.GA9507@peter.osted.lan> References: <20060402094431.GA81954@peter.osted.lan> <20060402.180153.74658240.Tor.Egge@cvsup.no.freebsd.org> <20060402190910.GA12759@peter.osted.lan> <20060402.204851.78799557.Tor.Egge@cvsup.no.freebsd.org> <20060403192808.GA91475@peter.osted.lan> <20060403203402.GA89233@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060403203402.GA89233@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: truckman@freebsd.org, current@freebsd.org Subject: Re: Livelock / softdep_flush "loop" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 04:30:46 -0000 On Mon, Apr 03, 2006 at 04:34:03PM -0400, Kris Kennaway wrote: > On Mon, Apr 03, 2006 at 09:28:08PM +0200, Peter Holm wrote: > > On Sun, Apr 02, 2006 at 08:48:51PM +0000, Tor Egge wrote: > > > > > The enclosed patch might help. > > > > > > > > > > > > > I'm testing it right now. > > > > > > Similarly to the softdepflush process looping in softdep_flush(), the process > > > creating a snapshot might loop in ffs_sync(). > > > > > > > I ran the same test with your first patch for two hours and your > > second patch for 7 hours, without seeing any livelocks. > > > > I added snapshots to the test and still did not get any livelocks, but > > I'm not certain that this last test covers your change. > > Hmm, there is a PR reporting hangs when removing many files with > snapshots enabled, on 6.0. I tried to reproduce it on 6.1 but failed > with the test case that the PR said was a reliable cause for them, so > I assumed it was fixed. It may be that I didn't try hard enough > though, since I didn't see your problem either. > I'll pursue this problem as I've seen this once recently. - Peter > Kris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (FreeBSD) > > iD8DBQFEMYa6Wry0BWjoQKURAr6DAKD5iGz6aYO5LNPlgFj4RixFonaJfQCgt3S3 > gut18DnWCkJsG6rmLzp6wx8= > =hHdh > -----END PGP SIGNATURE----- -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 07:41:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F73016A401 for ; Tue, 4 Apr 2006 07:41:44 +0000 (UTC) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8A4143D49 for ; Tue, 4 Apr 2006 07:41:43 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id C8A644CD1F; Tue, 4 Apr 2006 07:42:15 +0000 (GMT) Received: from [192.168.0.2] (ppp157-158.static.internode.on.net [150.101.157.158]) by p4.roq.com (Postfix) with ESMTP id D5F894CD1D; Tue, 4 Apr 2006 07:42:14 +0000 (GMT) Message-ID: <44322334.8010402@roq.com> Date: Tue, 04 Apr 2006 17:41:40 +1000 From: Michael Vince User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ganbold References: <442B79AE.9000800@micom.mng.net> In-Reply-To: <442B79AE.9000800@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: mysql performance test results under FreeBSD-7.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 07:41:44 -0000 Ganbold wrote: > Hi all, > > I did make some mysql performance tests under FreeBSD-7.0-CURRENT with > various > scheduler and compile time options. > It seems like mysql(BUILD_OPTIMIZED=yes, BUILD_STATIC=yes, > WITH_PROC_SCOPE_PTH=yes)-libpthread-tsc-sched_4bsd+preemption gives > better performance. > > The test results are at: > > http://www.mnbsd.org/ftp/mysql_test_results.txt > > There are several things I didn't test and this leads to some questions: > > 1. I didn't make test with Poul-Henning's CPU accounting patch. > Somehow I can't apply it > (http://phk.freebsd.dk/patch/cpu_acct_2.patch) cleanly. Where can I > find latest patch? > When this patch will be included in CURRENT? > > 2. I didn't make test with Robert Watson's patch > (http://www.watson.org/~robert/freebsd/clock/)? Does CURRENT src tree > include it? If not when this patch will be included in CURRENT? > > 3. I did make tests with default malloc in CURRENT. I'm confused what > malloc options should try (jemalloc? phkmalloc?) What is the default > malloc in CURRENT? How to use these different mallocs? > > thanks in advance, > Ganbold Nice work! I think it would be equally interesting if you posted benchmarks for MySQL 4.1.x Since the last post comparing MySQL 5.x vs 4.1.x on FreeBSD showed that MySQL 4.1 series had almost double the benchmark performance numbers over 5.x MySQL I couldn't bare the idea of using MySQL 5 if its still only half as fast and has features I don't need. I believe most people would prefer 4.1 unless they really need the features that are in 5.x or don't need performance at all. Mike From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 08:31:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEE9516A401 for ; Tue, 4 Apr 2006 08:31:01 +0000 (UTC) (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 EC03B43D45 for ; Tue, 4 Apr 2006 08:31:00 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQh1Y-0003xf-Sc; Tue, 04 Apr 2006 17:36:28 +0900 Message-ID: <44322EC2.2080700@micom.mng.net> Date: Tue, 04 Apr 2006 17:30:58 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Scott Long References: <4431D4E5.3080507@micom.mng.net> <4431D9FE.4030602@samsco.org> In-Reply-To: <4431D9FE.4030602@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 08:31:02 -0000 Scott Long wrote: > Ganbold wrote: >> Hi, >> >> I've got panic "CPU class not configured" on today's CURRENT. >> I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. >> >> When machine tries to boot following message appears: >> ... >> CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >> ... >> logical CPUs per core: 2 >> panic: CPU class not configured >> cpuid = 0 >> KDB: enter: panic >> [thread pid 0 tid 0 ] >> stopped at kdb_enter+0x2b : nop >> db> >> >> Ganbold >> > > You need to provide the exact kernel config file that you used to > produce this problem. > > Scott I got this trace: db>trace Tracing pid 0 tid 0 td 0xc084ff78 kdb_enter(c0796996) at kdb_enter+0x2b panic(c07b3500,c0c20d74,c072ea1c,c4ace4ec,c08292f0) at panic+0x127 panicifcpuunsupported(c4ace4ec,c08292f0,c0c20d88,c05c3d66,0) at panicifcpuunsupported+0x123 cpu_startup(0,c1ec00,c1e000,0,c043d4e5) at cpu_startup+0x14 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> Ganbold From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 08:39:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BADA16A41F; Tue, 4 Apr 2006 08:39:48 +0000 (UTC) (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 4F58443D53; Tue, 4 Apr 2006 08:39:47 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQhAM-00046i-9W; Tue, 04 Apr 2006 17:45:34 +0900 Message-ID: <443230E4.4070701@micom.mng.net> Date: Tue, 04 Apr 2006 17:40:04 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Robert Watson References: <4430DF4E.1060600@micom.mng.net> <20060403105231.D76562@fledge.watson.org> In-Reply-To: <20060403105231.D76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: page fault on today's CURRENT (tcp_usr_accept) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 08:39:48 -0000 Robert Watson wrote: > > On Mon, 3 Apr 2006, Ganbold wrote: > >> I've got page fault on today's CURRENT. > > After looking at tcp_usr_accept(), I certainly see *a* bug, which > might be the one you've run into. I've committed what I believe is > the fix as tcp_usrreq.c:1.134. Could you pull that down and see if > life gets better? > > Basically, there was erroneous handling of a connection that has been > disconnected while sitting in the accept queue before the application > manages to call accept() on it (indeed, a race). It looks like not crashing anymore with new tcp_usrreq code. thanks a lot, Ganbold > > Robert N M Watson > >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0xa0 >> fault code = supervisor write, >> page not present >> instructon pointer = 0x20: 0xc062bbde >> stack pointer = 0x28: 0xcc8efc10 >> frame pointer = 0x28: 0xcc8efc2c >> 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 = 435 (smbd) >> [thread pid 435 tid 100039] >> stopped at tcp_usr_accept+0xd6: cmpxchgl %ecx, 0xa0(%ebx) >> >> I'm running samba (samba-3.0.21b,1) on this test machine and there is >> no load. >> >> FreeBSD gw.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Mon >> Apr 3 14:15:48 ULAST 2006 >> tsgan@gw.micom.mng.net:/usr/obj/usr/src/sys/GW i386 >> >> Ganbold >> >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 09:08:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A25816A401 for ; Tue, 4 Apr 2006 09:08:43 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6564743D45 for ; Tue, 4 Apr 2006 09:08:42 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k3498c4O031122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Apr 2006 19:08:39 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k3498b6N094061; Tue, 4 Apr 2006 19:08:37 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k3498bvk094060; Tue, 4 Apr 2006 19:08:37 +1000 (EST) (envelope-from peter) Date: Tue, 4 Apr 2006 19:08:37 +1000 From: Peter Jeremy To: Ganbold Message-ID: <20060404090837.GC683@turion.vk2pj.dyndns.org> References: <4431D4E5.3080507@micom.mng.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4431D4E5.3080507@micom.mng.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 09:08:43 -0000 On Tue, 2006-Apr-04 11:07:33 +0900, Ganbold wrote: >I've got panic "CPU class not configured" on today's CURRENT. >I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. > >When machine tries to boot following message appears: >... >CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >... The indented lines after 'CPU:' are fairly critical as they define what the CPU is reporting which can then be compared to the logic in i386/i386/identcpu.c to see why the CPU isn't being identified. Is this a new machine or has it worked in the past? -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 09:23:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BAC016A420 for ; Tue, 4 Apr 2006 09:23:54 +0000 (UTC) (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 5E05343D4C for ; Tue, 4 Apr 2006 09:23:53 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQhqz-0004qw-KL; Tue, 04 Apr 2006 18:29:37 +0900 Message-ID: <44323B37.4040605@micom.mng.net> Date: Tue, 04 Apr 2006 18:24:07 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> In-Reply-To: <20060404090837.GC683@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 09:23:54 -0000 Peter Jeremy wrote: > On Tue, 2006-Apr-04 11:07:33 +0900, Ganbold wrote: > >> I've got panic "CPU class not configured" on today's CURRENT. >> I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. >> >> When machine tries to boot following message appears: >> ... >> CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >> ... >> > > The indented lines after 'CPU:' are fairly critical as they define > what the CPU is reporting which can then be compared to the logic > in i386/i386/identcpu.c to see why the CPU isn't being identified. > > Is this a new machine or has it worked in the past? > It is new machine that I'm trying to install FreeBSD. FreeBSD 6.x runs fine, except everytime after reboot I have to press Enter to boot continue. That's why I wanted to test FreeBSD-7.0-CURRENT on it. Ganbold From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 09:29:37 2006 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 1ADC016A400 for ; Tue, 4 Apr 2006 09:29:37 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5DCE43D46 for ; Tue, 4 Apr 2006 09:29:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id B0ECFD0990; Tue, 4 Apr 2006 05:29:36 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 6CABC353BC; Tue, 4 Apr 2006 05:29:34 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQhqu-000DBf-1k; Tue, 04 Apr 2006 10:29:32 +0100 Date: Tue, 4 Apr 2006 10:29:31 +0100 From: Brian Candler To: Mike Jakubik Message-ID: <20060404092931.GB50647@uk.tiscali.com> References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> <44319C9A.1060105@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44319C9A.1060105@rogers.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 09:29:37 -0000 On Mon, Apr 03, 2006 at 06:07:22PM -0400, Mike Jakubik wrote: > I see. If i could id contribute, but alas I'm unemployed now. Maybe > freebsd should charge for CDs like openbsd does, to fund the cause :P Like these? http://www.freebsdmall.com/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 09:46:57 2006 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 EBC0016A422 for ; Tue, 4 Apr 2006 09:46:57 +0000 (UTC) (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 D706643D5A for ; Tue, 4 Apr 2006 09:46:56 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 54104 invoked by uid 89); 4 Apr 2006 09:46:55 -0000 Received: by simscan 1.1.0 ppid: 54094, pid: 54096, t: 2.6666s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@217.71.84.110) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Apr 2006 09:46:52 -0000 Message-ID: <4432408B.3070905@ultra-secure.de> Date: Tue, 04 Apr 2006 11:46:51 +0200 From: Rainer Duffner User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Brian Candler References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> <44319C9A.1060105@rogers.com> <20060404092931.GB50647@uk.tiscali.com> In-Reply-To: <20060404092931.GB50647@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 09:46:58 -0000 Brian Candler wrote: > On Mon, Apr 03, 2006 at 06:07:22PM -0400, Mike Jakubik wrote: > >> I see. If i could id contribute, but alas I'm unemployed now. Maybe >> freebsd should charge for CDs like openbsd does, to fund the cause :P >> > > Like these? http://www.freebsdmall.com/ > I think he wants to suggest that the project should not produce ISO-Images anymore. The problem I have with the OpenBSD CDs is that they don't contain enough packages - for FreeBSD, there are actually DVDs available with most[*] packages. But I do buy the OpenBSD CDs (where would we be without pf+sshd?). Rainer [*] http://www.freebsdfoundation.org/ - seems like there's on package less I have to worry about.... From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 10:08:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9437C16A420; Tue, 4 Apr 2006 10:08:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B7A43D64; Tue, 4 Apr 2006 10:07:53 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail16.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k34A7pwx006804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Apr 2006 20:07:51 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k34A7oUe091232; Tue, 4 Apr 2006 20:07:50 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k34A7o3X091231; Tue, 4 Apr 2006 20:07:50 +1000 (EST) (envelope-from peter) Date: Tue, 4 Apr 2006 20:07:50 +1000 From: Peter Jeremy To: Robert Watson Message-ID: <20060404100750.GG683@turion.vk2pj.dyndns.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060403163220.F36756@fledge.watson.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 10:08:02 -0000 On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote: >(2) The name space model for system v ipc is flat, so while it's desirable >to > allow the administrator in the host environment to monitor and control > resource use in the jail (for example, delete allocated but unused > segments), doing that requires developing an administrative model for > it. The SysV SHM name space is made up of a 32-bit user-selected key which is mapped into a 32-bit (system chosen) identifier, which (on FreeBSD) is made up of a 16-bit pool identifier (in the range 0..shmmni-1) and a 16-bit generation counter. At the expense of restricting shmmni, the generation counter and JAIL_MAX, it would seem possible to embed prison.pr_id into the shmid and treat pr_id as an (implicit) part of the key - insisting they must match for jailed processes. Since the name space remains the same, ipcs and ipcrm would not be affected and a non-jailed ipcrm could delete jailed IPC by identifier. On the surface, this approach looks easier than having a distinct name space associated with each prison (as per kern/48471) and has the advantage of allowing non-jailed processes to manage jailed IPC. The disadvantage is restricting the ranges of various counters - though I believe they are overly generous by default. This doesn't really address the problem of SysV IPC and jails becoming more intimately entwined. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 10:35:00 2006 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 CB2D116A420 for ; Tue, 4 Apr 2006 10:35:00 +0000 (UTC) (envelope-from dd@freebsd.org) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33B4543D48 for ; Tue, 4 Apr 2006 10:34:59 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from maverick.trit.org (maverick.trit.org [IPv6:2001:4830:2381:2062:212:f0ff:fe4c:896a]) by charade.trit.org (Postfix) with ESMTP id CF73F1AF954 for ; Tue, 4 Apr 2006 10:34:57 +0000 (UTC) Received: from maverick.trit.org (localhost [127.0.0.1]) by maverick.trit.org (8.13.4/8.13.4) with ESMTP id k34AYvXb001650 for ; Tue, 4 Apr 2006 10:34:57 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by maverick.trit.org (8.13.4/8.13.4/Submit) id k34AYueX001648 for current@freebsd.org; Tue, 4 Apr 2006 10:34:56 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: maverick.trit.org: dima set sender to dd@freebsd.org using -f Date: Tue, 4 Apr 2006 10:34:56 +0000 From: Dima Dorfman To: current@freebsd.org Message-ID: <20060404103456.GA988@trit.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline X-PGP-Key: 69FAE582 (https://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: Mutt/1.5.9i Cc: Subject: CARP broken with IPv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 10:35:01 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable CARP seems to be broken with IPv6 on today's -current. When an inet6 address is configured on a carp interface, it panics the first time it tries to send an advertisement: panic: _mtx_lock_sleep: recursed on non-recursive mutex carp_if @ ../../../= netinet/ip_carp.c:1191 The traceback looks like this: #14 0xc05c4a65 in carp_macmatch6 (v=3D0xc6a71500, m=3D0xc6646700, taddr=3D0= xc6b3449c) at ../../../netinet/ip_carp.c:1191 #15 0xc060414c in nd6_na_output (ifp=3D0xc64c7000, daddr6_0=3D0xe4fabbc4,= =20 taddr6=3D0xc6b3449c, flags=3D32, tlladdr=3D1, sdl0=3D0x0) at ../../../netinet6/nd6_nbr.c:968 #16 0xc05c45dd in carp_send_na (sc=3D0xc69e9200) at ../../../netinet/ip_carp.c:1053 #17 0xc05c4e10 in carp_master_down_locked (sc=3D0xc69e9200) at ../../../netinet/ip_carp.c:1273 #18 0xc05c4d4b in carp_master_down (v=3D0xc69e9200) at ../../../netinet/ip_carp.c:1251 #19 0xc05370d9 in softclock (dummy=3D0x0) at ../../../kern/kern_timeout.c:2= 71 If I allow the mutex to recurse, the panic goes away (of course) but I never see an advertisement being sent. CARP appears to work okay with IPv4. The cause of the panic is obvious, but I don't quite understand what carp_macmatch6 is for. Should it be supported in this code path? If so, I'll try to investigate further why advertisements aren't sent even after the mutex is allowed to recurse. I believe that the same issue exists in the 6-STABLE branch, but I can't be sure. It does not appear to work there with inet6, but that test was in a completely environment, so it might be a different issue. Is this issue known on -current? --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFEMkvQBzAFW2n65YIRAvEVAJ0YSVOzWiOdbqWu/vi/bW3sNYAdcACggtaL k605Detmyp+Vp7OyJTQU+q4= =ORZD -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 10:45:37 2006 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 D8BF916A401 for ; Tue, 4 Apr 2006 10:45:37 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34EC143D64 for ; Tue, 4 Apr 2006 10:45:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 518B3D0CB2; Tue, 4 Apr 2006 06:45:35 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 1293834804; Tue, 4 Apr 2006 06:45:34 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQj2S-000DGh-NO; Tue, 04 Apr 2006 11:45:32 +0100 Date: Tue, 4 Apr 2006 11:45:32 +0100 From: Brian Candler To: Rainer Duffner Message-ID: <20060404104532.GA50936@uk.tiscali.com> References: <44318FD2.1050206@rogers.com> <443196DD.603@deepcore.dk> <44319C9A.1060105@rogers.com> <20060404092931.GB50647@uk.tiscali.com> <4432408B.3070905@ultra-secure.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4432408B.3070905@ultra-secure.de> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 10:45:37 -0000 On Tue, Apr 04, 2006 at 11:46:51AM +0200, Rainer Duffner wrote: > Brian Candler wrote: > >On Mon, Apr 03, 2006 at 06:07:22PM -0400, Mike Jakubik wrote: > > > >>I see. If i could id contribute, but alas I'm unemployed now. Maybe > >>freebsd should charge for CDs like openbsd does, to fund the cause :P > >> > > > >Like these? http://www.freebsdmall.com/ > > > > > I think he wants to suggest that the project should not produce > ISO-Images anymore. I see, or sell CDs which you are explicitly forbidden from copying: http://www.openbsd.org/faq/faq3.html#ISO "The official OpenBSD CD-ROM layout is copyright Theo de Raadt. Theo does not permit people to redistribute images of the official OpenBSD CDs." I'd say that's not really in the spirit of BSD. If FreeBSD went this way, I'd start looking elsewhere. So they lose out on users and developers (OpenBSD probably wouldn't want me as a user anyway :-) I can see the point though. It's probably easier as a corporate user to raise a PO for a CD-ROM set to support the project, if the image isn't available for download. > [*] http://www.freebsdfoundation.org/ - seems like there's on package > less I have to worry about.... I guess that means Java needs FreeBSD now more than FreeBSD needs Java :-) Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 10:47:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABD3916A400; Tue, 4 Apr 2006 10:47:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56A1743D45; Tue, 4 Apr 2006 10:47:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6D00C46C6A; Tue, 4 Apr 2006 06:47:14 -0400 (EDT) Date: Tue, 4 Apr 2006 11:47:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20060404100750.GG683@turion.vk2pj.dyndns.org> Message-ID: <20060404112938.G76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 10:47:15 -0000 On Tue, 4 Apr 2006, Peter Jeremy wrote: > On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote: >> (2) The name space model for system v ipc is flat, so while it's desirable >> to >> allow the administrator in the host environment to monitor and control >> resource use in the jail (for example, delete allocated but unused >> segments), doing that requires developing an administrative model for >> it. > > The SysV SHM name space is made up of a 32-bit user-selected key which is > mapped into a 32-bit (system chosen) identifier, which (on FreeBSD) is made > up of a 16-bit pool identifier (in the range 0..shmmni-1) and a 16-bit > generation counter. > > At the expense of restricting shmmni, the generation counter and JAIL_MAX, > it would seem possible to embed prison.pr_id into the shmid and treat pr_id > as an (implicit) part of the key - insisting they must match for jailed > processes. Since the name space remains the same, ipcs and ipcrm would not > be affected and a non-jailed ipcrm could delete jailed IPC by identifier. > > On the surface, this approach looks easier than having a distinct name space > associated with each prison (as per kern/48471) and has the advantage of > allowing non-jailed processes to manage jailed IPC. The disadvantage is > restricting the ranges of various counters - though I believe they are > overly generous by default. > > This doesn't really address the problem of SysV IPC and jails becoming more > intimately entwined. Hmm. This sounds like it might be workable. To make sure I understand your proposal: - We add a new prison ID field to the in-kernel description of each segment, semaphore, message queue, etc. This is initialized to the prison ID of the process creating the object at the time of creation. - shmget(), et al, will, in addition to matching the key when searching for an existing object, will also attempt to match the prison ID of the object to the process. For the sake of completeness, we will use prison ID 0 for unjailed processes (or something along those lines). This guarantees that two jails, or even the host and a jail, will never receive an ID already allocated to another jail, and in particular, not an ID for an object from another jail with the same key as might be used in the current jail. - shmat(), et al, will perform an access control check to confirm that if a process is jailed, its prison ID matches that of the object. Is it necessary, as you suggest, to change the IPC ID name space at all? I assume applications do consistently use shmget() to look up IDs, and that they can't/don't make assumptions about long-term persistence of those mappings across boot (which is effectively what a jail restart is? Is the behavior of IPXSEQ_TO_IPCID() something that has documented or relied on properties, or are we free to perform a mapping from a name (key) to an object (id) in any way we choose? I guess another change is also needed: - At jail termination, we GC all resources with the prison ID in question. This prevents a future jail from turning up with the same ID and seeing old shared memory (etc) segments. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:00:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0680416A42A; Tue, 4 Apr 2006 11:00:20 +0000 (UTC) (envelope-from SRS0=K4CHTMzd=52=metro.cx=fbsd@sonologic.nl) Received: from mx1.sonologic.nl (mx1.sonologic.nl [82.94.245.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC0443D49; Tue, 4 Apr 2006 11:00:19 +0000 (GMT) (envelope-from SRS0=K4CHTMzd=52=metro.cx=fbsd@sonologic.nl) Received: from [10.1.5.2] (sonologic.xs4all.nl [80.127.84.188]) (authenticated bits=0) by mx1.sonologic.nl (8.13.6/8.13.6) with ESMTP id k34B0Hbk073285; Tue, 4 Apr 2006 11:00:18 GMT Message-ID: <443252A1.8000704@metro.cx> Date: Tue, 04 Apr 2006 13:04:01 +0200 From: Koen Martens Organization: Sonologic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> In-Reply-To: <20060404112938.G76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Helo-Milter-Authen: gmc@sonologic.nl, fbsd@metro.cx, mx1 Received-SPF: pass (mx1.sonologic.nl: 80.127.84.188 is authenticated by a trusted mechanism) Cc: Peter Jeremy , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:00:21 -0000 Robert Watson wrote: > > Hmm. This sounds like it might be workable. To make sure I understand > your proposal: > > - We add a new prison ID field to the in-kernel description of each > segment, > semaphore, message queue, etc. This is initialized to the prison ID > of the > process creating the object at the time of creation. > > - shmget(), et al, will, in addition to matching the key when searching > for an > existing object, will also attempt to match the prison ID of the > object to > the process. For the sake of completeness, we will use prison ID 0 for > unjailed processes (or something along those lines). This guarantees > that > two jails, or even the host and a jail, will never receive an ID already > allocated to another jail, and in particular, not an ID for an object > from > another jail with the same key as might be used in the current jail. > > - shmat(), et al, will perform an access control check to confirm that if a > process is jailed, its prison ID matches that of the object. > > Is it necessary, as you suggest, to change the IPC ID name space at > all? I assume applications do consistently use shmget() to look up IDs, > and that they can't/don't make assumptions about long-term persistence > of those mappings across boot (which is effectively what a jail restart > is? Is the behavior of IPXSEQ_TO_IPCID() something that has documented > or relied on properties, or are we free to perform a mapping from a name > (key) to an object (id) in any way we choose? > > I guess another change is also needed: > > - At jail termination, we GC all resources with the prison ID in question. > > This prevents a future jail from turning up with the same ID and seeing > old shared memory (etc) segments. FWIW, I already implemented this once for 5.x a while back, but abandoned the project due to lack of time back then. If no-one else is going to pick this up, i might try and dig up that code again, and port it to 6.x, since this feature is still quite high on my wish list.. Best, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:05:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 930EA16A401; Tue, 4 Apr 2006 11:05:35 +0000 (UTC) (envelope-from SRS0=K4CHTMzd=52=metro.cx=fbsd@sonologic.nl) Received: from mx1.sonologic.nl (mx1.sonologic.nl [82.94.245.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1D943D4C; Tue, 4 Apr 2006 11:05:34 +0000 (GMT) (envelope-from SRS0=K4CHTMzd=52=metro.cx=fbsd@sonologic.nl) Received: from [10.1.5.2] (sonologic.xs4all.nl [80.127.84.188]) (authenticated bits=0) by mx1.sonologic.nl (8.13.6/8.13.6) with ESMTP id k34B5R3s073546; Tue, 4 Apr 2006 11:05:29 GMT Message-ID: <443253D7.3090409@metro.cx> Date: Tue, 04 Apr 2006 13:09:11 +0200 From: Koen Martens Organization: Sonologic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Koen Martens References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <443252A1.8000704@metro.cx> In-Reply-To: <443252A1.8000704@metro.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Helo-Milter-Authen: gmc@sonologic.nl, fbsd@metro.cx, mx1 Received-SPF: pass (mx1.sonologic.nl: 80.127.84.188 is authenticated by a trusted mechanism) Cc: Peter Jeremy , freebsd-current@freebsd.org, Robert Watson , freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:05:35 -0000 Koen Martens wrote: > FWIW, I already implemented this once for 5.x a while back, but > abandoned the project due to lack of time back then. If no-one else > is going to pick this up, i might try and dig up that code again, > and port it to 6.x, since this feature is still quite high on my > wish list.. Here is some further discussion: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2004-11/0321.html Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:07:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E4ED16A420; Tue, 4 Apr 2006 11:07:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C5F143D55; Tue, 4 Apr 2006 11:07:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 931BD46C64; Tue, 4 Apr 2006 07:07:08 -0400 (EDT) Date: Tue, 4 Apr 2006 12:07:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Koen Martens In-Reply-To: <443252A1.8000704@metro.cx> Message-ID: <20060404120252.J76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <443252A1.8000704@metro.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:07:13 -0000 On Tue, 4 Apr 2006, Koen Martens wrote: > FWIW, I already implemented this once for 5.x a while back, but abandoned > the project due to lack of time back then. If no-one else is going to pick > this up, i might try and dig up that code again, and port it to 6.x, since > this feature is still quite high on my wish list.. Another related, and necessary change, is to fix the field types in our public IPC data structures. Right now they still contain 16-bit ID fields. We've done the first step in separating the user and kernel data structures, but we'll need to do the whole compatibility system call thing. The comment above ipc_perm in ipc.h pretty much says it all: /* * XXX almost all members have wrong types. */ Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:41:12 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0D5616A420; Tue, 4 Apr 2006 11:41:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC6FC43D5C; Tue, 4 Apr 2006 11:41:10 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k34Bf8Qh026122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Apr 2006 21:41:08 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k34Bf7Ab030853; Tue, 4 Apr 2006 21:41:07 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k34Bf7DF030852; Tue, 4 Apr 2006 21:41:07 +1000 (EST) (envelope-from peter) Date: Tue, 4 Apr 2006 21:41:07 +1000 From: Peter Jeremy To: Robert Watson Message-ID: <20060404114107.GJ683@turion.vk2pj.dyndns.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404112938.G76562@fledge.watson.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:41:13 -0000 On Tue, 2006-Apr-04 11:47:14 +0100, Robert Watson wrote: >Hmm. This sounds like it might be workable. To make sure I understand >your proposal: > >- We add a new prison ID field to the in-kernel description of each segment, >- shmget(), et al, will, in addition to matching the key when searching for >an > existing object, will also attempt to match the prison ID of the object to > the process. >- shmat(), et al, will perform an access control check to confirm that if a > process is jailed, its prison ID matches that of the object. Yes. And prison.pr_id can't be 0 so 0 makes a good choice as the unjailed flag. >Is it necessary, as you suggest, to change the IPC ID name space at all? By merging the prison ID into the IPC ID, a non-jailed process can be allowed to see (and control) jailed IPC without needing any changes to ipcs/ipcrm. A non-jailed process won't be able to attach by key but would be able to attach by ID. > I >assume applications do consistently use shmget() to look up IDs, and that >they can't/don't make assumptions about long-term persistence of those >mappings across boot (which is effectively what a jail restart is? The IPC ID must be treated as a non-persistent opaque number by the application. It's supposed to be treated much as you would an FD - it makes no sense for an application to remember that opening /some/file returned FD 5 last time so you can skip the open by remembering the 5. (Though, unlike FDs, the kernel doesn't actually validate that the ID presented for an IPC operation was returned by an IPC get). > Is the >behavior of IPXSEQ_TO_IPCID() something that has documented or relied on >properties, or are we free to perform a mapping from a name (key) to an >object (id) in any way we choose? Those macros are all protected by #ifdef _KERNEL so a portable application can't assume anything about them (I know Tru64 uses a different algorithm to combine the pool and generation number). My suggestion is something along the lines of: #define IPCID_TO_IX(id) ((id) & 0x03ff) #define IPCID_TO_SEQ(id) (((id) >> 10) & 0x03ff) #define IPCID_TO_PRID(id) (((id) >> 20) & 0x0fff) #define IXSEQ_TO_IPCID(ix,perm,prid) (((prid) << 20) | ((perm).seq << 10) | ((ix) & 0x03ff)) >I guess another change is also needed: > >- At jail termination, we GC all resources with the prison ID in question. This is probably a good idea but somewhat messier because SysV IPC has no concept of GC (another brain-dead mis-feature). The implementation should be a JKH project - I don't need the feature and can't currently justify the time to implement it. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:47:00 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4863A16A401; Tue, 4 Apr 2006 11:47:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B506843D46; Tue, 4 Apr 2006 11:46:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BE90246BB3; Tue, 4 Apr 2006 07:46:58 -0400 (EDT) Date: Tue, 4 Apr 2006 12:46:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20060404114107.GJ683@turion.vk2pj.dyndns.org> Message-ID: <20060404124313.B76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <20060404114107.GJ683@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:47:00 -0000 On Tue, 4 Apr 2006, Peter Jeremy wrote: > On Tue, 2006-Apr-04 11:47:14 +0100, Robert Watson wrote: >> Hmm. This sounds like it might be workable. To make sure I understand >> your proposal: >> >> - We add a new prison ID field to the in-kernel description of each segment, >> - shmget(), et al, will, in addition to matching the key when searching for >> an >> existing object, will also attempt to match the prison ID of the object to >> the process. >> - shmat(), et al, will perform an access control check to confirm that if a >> process is jailed, its prison ID matches that of the object. > > Yes. And prison.pr_id can't be 0 so 0 makes a good choice as the unjailed > flag. > >> Is it necessary, as you suggest, to change the IPC ID name space at all? > > By merging the prison ID into the IPC ID, a non-jailed process can be > allowed to see (and control) jailed IPC without needing any changes to > ipcs/ipcrm. A non-jailed process won't be able to attach by key but would > be able to attach by ID. I guess I'm asking a more specific question: you're suggesting treating the prison ID as a logical, but transparent, extension to the key. Are you suggesting actually changing the way values for the ID field are assigned, or are you suggesting we continue to allocate and manage IDs as we do currently? >> Is the behavior of IPXSEQ_TO_IPCID() something that has documented or >> relied on properties, or are we free to perform a mapping from a name (key) >> to an object (id) in any way we choose? > > Those macros are all protected by #ifdef _KERNEL so a portable application > can't assume anything about them (I know Tru64 uses a different algorithm to > combine the pool and generation number). > > My suggestion is something along the lines of: > #define IPCID_TO_IX(id) ((id) & 0x03ff) > #define IPCID_TO_SEQ(id) (((id) >> 10) & 0x03ff) > #define IPCID_TO_PRID(id) (((id) >> 20) & 0x0fff) > #define IXSEQ_TO_IPCID(ix,perm,prid) (((prid) << 20) | ((perm).seq << 10) | ((ix) & 0x03ff)) Would it make more sense to simply allocate ID's sequentially, and simply not allow access to objects with a non-matching prison? If the ID value is entirely opaque, there's no real reason to assign a meaning to it, especially if it leads to potential collisions if, say, the prison ID space becomes large and sparse (due to lots of stopping and starting of prisons over a long run). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 12:24:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E761716A401; Tue, 4 Apr 2006 12:24:41 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EA1743D45; Tue, 4 Apr 2006 12:24:40 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k34COQHj079674; Tue, 4 Apr 2006 15:24:26 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 4 Apr 2006 15:24:26 +0300 (EEST) From: Dmitry Pryanishnikov To: Julian Elischer In-Reply-To: <44317A45.9000504@elischer.org> Message-ID: <20060404151508.P73219@atlantis.atlantis.dp.ua> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <44317A45.9000504@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Marc G. Fournier" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Robert Watson , pjd@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 12:24:42 -0000 Hello! On Mon, 3 Apr 2006, Julian Elischer wrote: >> (2) The name space model for system v ipc is flat, so while it's desirable >> to >> allow the administrator in the host environment to monitor and control >> resource use in the jail (for example, delete allocated but unused >> segments), doing that requires developing an administrative model for >> it. > > > it is possible the admin environment can't see it. > unless you prefix it with something.. I think it would be nice if we can just name jail's IPC objects from host environment using syntax like e.g. /JID/name_in_jail or /jail_IP/name_in_jail However, I can't find info whether "/" is legal as the 1st character of IPC object ID. If yes, we should use another prefix. This approach won't work if there are no restriction on IPC object IDs 1st character. Are there any? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 12:28:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A92316A400; Tue, 4 Apr 2006 12:28:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC90E43D46; Tue, 4 Apr 2006 12:28:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B2F5A46C8F; Tue, 4 Apr 2006 08:28:01 -0400 (EDT) Date: Tue, 4 Apr 2006 13:28:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dmitry Pryanishnikov In-Reply-To: <20060404151508.P73219@atlantis.atlantis.dp.ua> Message-ID: <20060404132647.E76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <44317A45.9000504@elischer.org> <20060404151508.P73219@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Marc G. Fournier" , pjd@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 12:28:05 -0000 On Tue, 4 Apr 2006, Dmitry Pryanishnikov wrote: > However, I can't find info whether "/" is legal as the 1st character of IPC > object ID. If yes, we should use another prefix. This approach won't work if > there are no restriction on IPC object IDs 1st character. Are there any? System V IPC object name spaces aren't string-based, you may be thinking of the POSIX IPC primitives, which while having string-based names, are deficient in other ways, such as using non-hierarchal names. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 13:27:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A955A16A41F for ; Tue, 4 Apr 2006 13:27:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C75143D49 for ; Tue, 4 Apr 2006 13:27:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8D61E46BE4; Tue, 4 Apr 2006 09:27:29 -0400 (EDT) Date: Tue, 4 Apr 2006 14:27:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kazuaki Oda In-Reply-To: <44311AB5.2010407@highway.ne.jp> Message-ID: <20060404141813.H22854@fledge.watson.org> References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 13:27:31 -0000 On Mon, 3 Apr 2006, Kazuaki Oda wrote: >> Also, are you running with INVARIANTS and/or WITNESS? > > Sorry, I compiled kernel without INVARIANTS and WITNESS. No problem at all -- the debugging information you have sent me is enough to track down the source of the problem. It looks like we have an inconsistency in how we handle (especially in my new world order) the recycling of timewait state for an inpcb that is still present. I've committed a work-around which should prevent the panic you're seeing, but I need to investigate a bit more before I can commit a full solution. For those interested, the problem is how to handle sockets with attached inpcbs that represent closed or time wait TCP connections. This can happen if shutdown() is called on a socket, kicking the TCP state engine into a close cycle, rather than a reset. In the current world order, the following sets of socket, pcb, and ppcb protocol state can occur: fd -> socket <-> inpcb <-> tcpcb Normal TCP socket in various states. fd -> socket <-> inpcb <-> twtcp Unclosed TCP socket in time wait. fd -> socket <-> inpcb <-> NULL Unclosed TCP socket after tw recycle. socket <-> inpcb <-> tcpcb Socket closed, buffer still needed. inpcb <-> twtcp Socket closed, time wait. The problem was that the middle case exists, but was not accounted for. There's another problem that is still present in the new socket/pcb model, in which the inpcb of an open socket with a closed TCP connection continues to reserve the address/port combination. This is related to the inpcb without twtcp case, where we recycle the twtcp, but can't recylce the inpcb immediately because there's still an fd reference to the socket, and hence a socket reference to the inpcb. My current leaning is to do the following: - Since we now keep inpcb's around for the lifetime of the socket, either teach the inpcb lookup routines to ignore INP_DROPPED, or to move them to another inpcb list for open but dropped inpcb's. This will avoid the reservation hanging around. - Either eliminate the inp_ppcb pointer NULL case by prohibiting recycling of the twtcp state of a socket that is still open, or more formally supporting it through the previous change. The trick is to prevent the twtcp/inpcb pairs from turning up and being used during input and allocation collision processing. The summary is that we're not quite there yet in terms of how it all should be working, but that we should avoid the panic for now due to the workarounds I committed (which basically are changes to handle the inp_ppcb pointer being NULL for INP_TIMEWAIT sockets). Thanks! Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 13:36:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BDDE16A401 for ; Tue, 4 Apr 2006 13:36:30 +0000 (UTC) (envelope-from livefreebsd@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD9DC43D45 for ; Tue, 4 Apr 2006 13:36:29 +0000 (GMT) (envelope-from livefreebsd@mac.com) Received: from mac.com (webmail16-en1 [10.13.10.142]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id k34DaT1G015439 for ; Tue, 4 Apr 2006 06:36:29 -0700 (PDT) Received: from webmail16 (localhost [127.0.0.1]) by mac.com (Xserve/webmail16/MantshX 4.0) with ESMTP id k34DaSLt023821 for ; Tue, 4 Apr 2006 06:36:29 -0700 (PDT) Message-ID: <15906083.1144157788983.JavaMail.livefreebsd@mac.com> Date: Tue, 04 Apr 2006 09:36:28 -0400 From: livefreebsd@mac.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 64.74.39.60/instID=233 Subject: cPCI Hot Plug problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 13:36:30 -0000 I am trying to use a dual ethernet car that plugs into a cCPI slot. cPCI is a hot pluggable technology. The system is a Nokia IP330 firewall. FreeBSD sees the two interfaces. I can assign IP addresses and bring the interfaces up. BUT, I cannot get a link light. It seems that even though the interfaces are configurable, they remain powered down for hot plugging. How do I get this to be activated? Ideally, when all interfaces are down: ifconfig dc0 down ifconfig dc1 down then, the car should power down for hot plugging. If any of the interfaces is up, then the card should be powered up. Thoughts... From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 15:09:26 2006 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 989C716A422; Tue, 4 Apr 2006 15:09:26 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB0443D46; Tue, 4 Apr 2006 15:09:26 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k34F9PGu026646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Apr 2006 11:09:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k34F9KXx094084; Tue, 4 Apr 2006 11:09:20 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17458.35872.175979.759077@grasshopper.cs.duke.edu> Date: Tue, 4 Apr 2006 11:09:20 -0400 (EDT) To: Mike Jakubik In-Reply-To: <44318FD2.1050206@rogers.com> References: <44318FD2.1050206@rogers.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org, sos@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 15:09:26 -0000 Mike Jakubik writes: > It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA chipset, > and we are still missing it. Is there any way to port their code over? > There are a few nice motherboards out there that use this chipset (most > amd server boards use the crappy nvidia chipset and the accompanying > crappy network card). Why do you call the Nvida chipset "crappy"? I assume you don't care about the PCI Express bandwidth of the accompanying "northbridge"? >From a performance standpoint, the Nvida chipset is far from crappy, and can easily sustain 10GbE speeds for both send and receive, as well as send+receive at the same time. Our lab tests have shown well over 18Gb/s for send+receive using our PCI-e x8 10GbE card in an Nvidia CK804 based opteron. For any application which is moving a lot of data using PCI-e cards on an opteron, I would strongly recommend Nvidia based servers. Drew From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 16:46:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E9816A400 for ; Tue, 4 Apr 2006 16:46:42 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD35643D53 for ; Tue, 4 Apr 2006 16:46:41 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1962822nzf for ; Tue, 04 Apr 2006 09:46:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SFhxQAtgB4AHJLfxik4Cz1P76ETrjL+6KsKq8lodjr75ka90IhejZfYp+9IzNN3Wp5a4qbMB5RZO8SgUonlRUIsBUDxDthHjthFvQzX0J+jFjXd3XzGET+tlDDLslIF/gycZQW/LGpvONQAtuFqMO3iLqGZtHoRhWxrmM5ko2jk= Received: by 10.36.68.4 with SMTP id q4mr98406nza; Tue, 04 Apr 2006 09:46:38 -0700 (PDT) Received: by 10.36.133.10 with HTTP; Tue, 4 Apr 2006 09:46:38 -0700 (PDT) Message-ID: <7daacbbe0604040946m34826010k2a5ac967fa4bd9e0@mail.gmail.com> Date: Tue, 4 Apr 2006 18:46:38 +0200 From: "Dominique Goncalves" 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: Unable to mount a USB Key X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 16:46:42 -0000 Hi, I'm trying to mount a USB Key on FreeBSD 7.0-CURRENT (also on RELENG_6) formatted with msdosfs, but FreeBSD could not mount it. I remember that it was working well on 6.0-RELEASE. umass0: on uh= ub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) Sometimes I don't have /dev/da0s1(?) but when there is /dev/da0s1: # ls -l /dev/da0s1 crw-r----- 1 root operator 0, 142 Apr 4 18:17 /dev/da0s1 # mount_msdosfs /dev/da0s1 /mnt/CF Mount point /mnt/CF had 1 dangling refs mount_msdosfs: /dev/da0s1: Device not configured This usb key works on others operating system and the same box. Thanks for your help. Regards. # usbdevs -vv Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 addr 2: low speed, power 100 mA, config 1, USB Mouse(0xc00c), Logitech(0x046d), rev 6.10 port 2 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 addr 2: high speed, power 120 mA, config 1, USB Storage(0x07a0), vendor 0x05e3(0x05e3), rev 1.25 Copyright (c) 1992-2006 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 #0: Tue Apr 4 00:50:30 CEST 2006 root@djdomics.sceen.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf24 Stepping =3D 4 Features=3D0x3febfbff real memory =3D 268369920 (255 MB) avail memory =3D 252882944 (241 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) 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_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa800-0xa8ff mem 0xd0000000-0xd7ffffff,0xdfef0000-0xdfefffff irq 16 at device 0.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xdc00-0xdcff,0xd800-0xd87f irq 18 at device 2.7 on p= ci0 pcm0: ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xdfffe000-0xdfffefff irq 21 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xdffff000-0xdfffffff irq 22 at device 3.2 on pci0 ohci2: [GIANT-LOCKED] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdfffd000-0xdfffdfff irq 23 at device 3.3 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: on usb3 uhub3: 6 ports with 6 removable, self powered rl0: port 0xd400-0xd4ff mem 0xdfffbf00-0xdfffbfff irq 17 at device 6.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:ba:b8:90:da pci0: at device 7.0 (no driver attached) ral0: mem 0xdfff8000-0xdfff9fff irq 19 at device 8.0 on pci0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:11:09:29:e4:68 pci0: at device 9.0 (no driver attached) pci0: at device 9.1 (no driver attached) rl1: port 0xcc00-0xccff mem 0xdfffbe00-0xdfffbeff irq 18 at device 11.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:10:dc:82:9b:d2 fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A sio0: [FAST] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FAST] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xcf7ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub2 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2000149480 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57241MB at ata0-master UDMA100 ad1: 57241MB at ata0-slave UDMA100 acd0: DVDROM at ata1-master UDMA33 acd1: CDRW at ata1-slave UDMA33 Trying to mount root from ufs:/dev/ad1s2a WARNING: /var was not properly dismounted ral0: device timeout umass0: on uh= ub3 umass0: at uhub3 port 6 (addr 2) disconnected (da0:dead_sim0:0:0:0): lost device (da0:dead_sim0:0:0:0): got CAM status 0x8 (da0:dead_sim0:0:0:0): fatal error, failed to attach to device (da0:dead_sim0:0:0:0): removing device entry umass0: detached umass0: on uh= ub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) umass0: at uhub3 port 6 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:dead_sim0:0:0:0): removing device entry umass0: detached umass0: on uh= ub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) Mount point /mnt had 1 dangling refs Mount point /mnt/CF had 1 dangling refs -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 17:55:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4043916A41F for ; Tue, 4 Apr 2006 17:55:05 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from efacilitas.de (smtp.efacilitas.de [85.10.196.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 853B043D45 for ; Tue, 4 Apr 2006 17:55:04 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-169-72.dynamic.qsc.de [212.202.169.72]) by efacilitas.de (Postfix) with ESMTP id 2E93E4C9A0; Tue, 4 Apr 2006 20:06:03 +0200 (CEST) Received: from [192.168.1.2] (muhkuh.local [192.168.1.2]) by eurystheus.local (Postfix) with ESMTP id A354A52866; Tue, 4 Apr 2006 19:54:31 +0200 (CEST) Message-ID: <4432B2FA.9000003@cs.tu-berlin.de> Date: Tue, 04 Apr 2006 19:55:06 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Dominique Goncalves References: <7daacbbe0604040946m34826010k2a5ac967fa4bd9e0@mail.gmail.com> In-Reply-To: <7daacbbe0604040946m34826010k2a5ac967fa4bd9e0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Unable to mount a USB Key X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 17:55:05 -0000 Dominique Goncalves schrieb: > Hi, > > I'm trying to mount a USB Key on FreeBSD 7.0-CURRENT (also on > RELENG_6) formatted with msdosfs, but FreeBSD could not mount it. I > remember that it was working well on 6.0-RELEASE. > > umass0: on uhub3 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) > > Sometimes I don't have /dev/da0s1(?) but when there is /dev/da0s1: > > # ls -l /dev/da0s1 > crw-r----- 1 root operator 0, 142 Apr 4 18:17 /dev/da0s1 > # mount_msdosfs /dev/da0s1 /mnt/CF > Mount point /mnt/CF had 1 dangling refs > mount_msdosfs: /dev/da0s1: Device not configured > > This usb key works on others operating system and the same box. > > Thanks for your help. > > Regards. Tried fsck_msdosfs first? Regards Björn From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 18:04:14 2006 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 91C5B16A400; Tue, 4 Apr 2006 18:04:14 +0000 (UTC) (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 F178543D45; Tue, 4 Apr 2006 18:04:13 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:IGPiI61VUUmY5trSspFWexInsPy2fhFOT9Ee06fNdtC3LvhNQN9I7A30cJowumTj@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.6/8.13.6) with ESMTP/inet6 id k34I44Ri074276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 03:04:08 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 05 Apr 2006 03:04:04 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@FreeBSD.org, current@FreeBSD.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-PRERELEASE 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.1.3 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 05 Apr 2006 03:04:08 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ameno.mahoroba.org Cc: Subject: [CFR] exposable reentrant functions of netdb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 18:04:14 -0000 Hi, I reworked the netdb functions in our libc to conform to the Solaris's API. With this change, we can expose get*_r(3) to the outside of libc. Further, I changed the internal of gethostby*(3) and getnetby*(3) to NSS friendly. Please review it. You can get the patch from: http://www.imasy.or.jp/~ume/FreeBSD/netdb-solaris-api-20060405.diff.gz 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 Tue Apr 4 18:40:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1014B16A400 for ; Tue, 4 Apr 2006 18:40:05 +0000 (UTC) (envelope-from cel@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A871D43D53 for ; Tue, 4 Apr 2006 18:40:05 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from [141.211.133.130] (dh130.citi.umich.edu [141.211.133.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Chuck Lever", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 4074C1BD03 for ; Tue, 4 Apr 2006 14:40:05 -0400 (EDT) Message-ID: <4432BD87.7080407@citi.umich.edu> Date: Tue, 04 Apr 2006 14:40:07 -0400 From: Chuck Lever Organization: Center for Information Technology Integration User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: unable to build RELENG_6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cel@citi.umich.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 18:40:06 -0000 after checking out RELENG_6 today to do some unrelated testing, i find that i can no longer build the kernel. the config is a copy of GENERIC. "make depend" ends with this: cc -O2 -fno-strict-aliasing -pipe -nostdinc -I/usr/include -I. -I../../../dev/aic7xxx/aicasm -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll ./aicasm -nostdinc -I- -I. -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -I../../../cam/scsi -I../../../dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i ../../../dev/aic7xxx/aic7xxx_osm.h ../../../dev/aic7xxx/aic7xxx.seq ./aicasm: Stopped at file scsi_message.h, line 47 - Regex compilation failed ./aicasm: Removing aic7xxx_seq.h due to error ./aicasm: Removing aic7xxx_reg.h due to error *** Error code 70 Stop in /u/cel/RELENG_6/sys/i386/compile/SPRINGFIELD. -- corporate: personal: From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 18:54:21 2006 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 4AF0116A400 for ; Tue, 4 Apr 2006 18:54:21 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51AAA43D83 for ; Tue, 4 Apr 2006 18:54:12 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so928118ugc for ; Tue, 04 Apr 2006 11:54:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=bzHHYOdr9zLQciXQDH2D2srhmw1Vmi7Yl/AhGcYcSYM3QIAx4TACbe7o5bRceId3t3Z8FJT0gutHO2za56psgQqL6es+4795wPSNn5uEbNK9qcAc8LJ9QK6f0iy2k6j4eu5Cfm5l00eyPvA2oJmTJe1puv7X58ladH+lqYqfaVs= Received: by 10.78.47.9 with SMTP id u9mr183937huu; Tue, 04 Apr 2006 11:54:10 -0700 (PDT) Received: by 10.78.75.15 with HTTP; Tue, 4 Apr 2006 11:54:10 -0700 (PDT) Message-ID: Date: Tue, 4 Apr 2006 20:54:10 +0200 From: "Pawel Worach" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: mpt(4) mirror 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: Tue, 04 Apr 2006 18:54:21 -0000 Hi, After the recent changes to mpt(4) it seems the driver has some isses with the mirroring configuration (two . This is on a IBM x345 server with a kernel from today. kernel messages: mpt0: port 0x2600-0x26ff mem 0xf7ff0000-0xf7= fffff f,0xf7fe0000-0xf7feffff irq 27 at device 7.0 on pci8 mpt0: [GIANT-LOCKED] mpt0: MPI Version=3D1.2.15.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) mpt1: port 0x2700-0x27ff mem 0xf7fd0000-0xf7= fdfff f,0xf7fc0000-0xf7fcffff irq 28 at device 7.1 on pci8 mpt1: [GIANT-LOCKED] mpt1: MPI Version=3D1.2.15.0 mpt1: Capabilities: ( RAID-1 SAFTE ) mpt1: 0 Active Volumes (0 Max) mpt1: 0 Hidden Drive Members (0 Max) ... mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:0:0): Primary (mpt0:0:1): Secondary mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) (mpt0:vol0:0): Online (mpt0:vol0:1): Physical (mpt0:0:1), Pass-thru (mpt0:1:1) (mpt0:vol0:1): Online mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: mpt_cam_event: 0xb (mpt0:vol0:0): Physical Disk Status Changed mpt0: mpt_cam_event: 0xb (mpt0:vol0:0): Volume Status Changed mpt0: mpt_cam_event: 0xb (mpt0:vol0:0): Physical Disk Status Changed mpt0: IOC Bus Reset Port: 0 mpt0: mpt_write_cfg_page: Config Info Status 2 mpt0: mpt_setwidth: write cur page failed mpt0: Set width Failed! mpt0: IOC Bus Reset Port: 0 mpt0: mpt_read_cfg_page: Config Info Status 2 mpt0: mpt_setwidth: read cur page failed mpt0: Set width Failed! mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): No longer configured mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: mpt_read_cfg_page: Config Info Status 2 mpt0: cannot get target 1 DP0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 mpt0: IOC Bus Reset Port: 0 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 3.300MB/s transfers, Tagged Queueing Enabled da0: 34710MB (71087625 512 byte sectors: 255H 63S/T 4425C) Trying to mount root from ufs:/dev/da0s1a Booting an older kernel from around Mar. 25 works fine. Anything else I can dig out? -- Pawel From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 18:56:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B73B16A401 for ; Tue, 4 Apr 2006 18:56:23 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B572F43D45 for ; Tue, 4 Apr 2006 18:56:22 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so24299nzf for ; Tue, 04 Apr 2006 11:56:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l7B8vQE66ztApbivWZMBwrUrVPIT6NwYz3Ow5/Bv88VcC5guysY19NQHEVtQvECPNySDnf5TeQZQKtKdSWfjDfiz+GKtLhXqg+pt7/zu3V6YsBNsYa3Pnhkbnzu1ihIR7BdE8QGicrEyNi9DUTii5fZxR7/9FDLBzqsRZ1kBKEc= Received: by 10.36.25.10 with SMTP id 10mr69731nzy; Tue, 04 Apr 2006 11:56:09 -0700 (PDT) Received: by 10.36.133.10 with HTTP; Tue, 4 Apr 2006 11:56:09 -0700 (PDT) Message-ID: <7daacbbe0604041156j252e6572x69436c2e44e3288b@mail.gmail.com> Date: Tue, 4 Apr 2006 20:56:09 +0200 From: "Dominique Goncalves" To: "=?ISO-8859-1?Q?Bj=F6rn_K=F6nig?=" In-Reply-To: <4432B2FA.9000003@cs.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7daacbbe0604040946m34826010k2a5ac967fa4bd9e0@mail.gmail.com> <4432B2FA.9000003@cs.tu-berlin.de> Cc: freebsd-current@freebsd.org Subject: Re: Unable to mount a USB Key X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 18:56:23 -0000 On 4/4/06, Bj=F6rn K=F6nig wrote: > Dominique Goncalves schrieb: > > Hi, > > > > I'm trying to mount a USB Key on FreeBSD 7.0-CURRENT (also on > > RELENG_6) formatted with msdosfs, but FreeBSD could not mount it. I > > remember that it was working well on 6.0-RELEASE. > > > > umass0: o= n uhub3 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 devic= e > > da0: 40.000MB/s transfers > > da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) > > > > Sometimes I don't have /dev/da0s1(?) but when there is /dev/da0s1: > > > > # ls -l /dev/da0s1 > > crw-r----- 1 root operator 0, 142 Apr 4 18:17 /dev/da0s1 > > # mount_msdosfs /dev/da0s1 /mnt/CF > > Mount point /mnt/CF had 1 dangling refs > > mount_msdosfs: /dev/da0s1: Device not configured > > > > This usb key works on others operating system and the same box. > > > > Thanks for your help. > > > > Regards. > > Tried fsck_msdosfs first? It didn't work: # fsck_msdosfs /dev/da0s1 ** /dev/da0s1 Can't open (Device not configured) and from time to time I see this on the console: umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT > Regards > Bj=F6rn > Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 19:07:11 2006 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 0631F16A401 for ; Tue, 4 Apr 2006 19:07:11 +0000 (UTC) (envelope-from harikurniawan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id F254C43D46 for ; Tue, 4 Apr 2006 19:07:09 +0000 (GMT) (envelope-from harikurniawan@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so1284332wra for ; Tue, 04 Apr 2006 12:07:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FFfmnNgtnWMMTskNqhnGrkVDPv972gBGEwC2K1t9UyqcjrhjZqggTv5ZwlMpMiOa4WVTGpqDVhKidOKw0KaUTtivx7LiPpDNPKGhYN5QU9lChR76qAaLPDvwKqGdmi/bcMnHXZ7wR/0RxXqAcOkBFdyrFKITWmLTw+EH6exC3WE= Received: by 10.65.191.13 with SMTP id t13mr775591qbp; Tue, 04 Apr 2006 12:07:08 -0700 (PDT) Received: by 10.64.201.6 with HTTP; Tue, 4 Apr 2006 12:07:08 -0700 (PDT) Message-ID: <4c40c4e70604041207n62120865y3bce8a716fbf6c34@mail.gmail.com> Date: Wed, 5 Apr 2006 02:07:08 +0700 From: "Angka H. K." To: "Nate Lawson" In-Reply-To: <4431DA08.3020002@root.org> MIME-Version: 1.0 References: <4c40c4e70604030346g3305dc9bo580413026c33e148@mail.gmail.com> <20060403151534.eqdmhc6f404o4co0@netchild.homeip.net> <4c40c4e70604030716k429d263ek29e8b8edf31be664@mail.gmail.com> <4431DA08.3020002@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Leidinger , current@freebsd.org Subject: Re: My snd_ich working well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 19:07:11 -0000 Thanks a lot, you really dedicate your time to FreeBSD Sorry I still don't have good connection to do cvsup, may be tomorrow. Ah.. hard time to finish my job sorry can't help :( On 4/4/06, Nate Lawson wrote: > > Angka H. K. wrote: > > Thanks for the replay > > I am updating my source now and planing to rebuild it again, but I don'= t > see > > any changes on ACPI code. > > > > I was mistype on the val that return by kernel, the error should be > "acpi: > > bad write to port 0x073(8) val 20", I am sorry. > > Hope it'll be fixed soon. > > Ok, I fixed the range check on ports so 0x73 should not trigger it. If > you have some other write to a port that IS in the blacklist, you'll > still get the warning. > > Ultimately, I intend to emulate what Windows does which is block all > writes to the PIC, and block all writes on XP or newer BIOSen. > > -- > Nate > From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 19:26:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D977E16A401; Tue, 4 Apr 2006 19:26:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outbound7.internet-mail-service.net (outbound7.internet-mail-service.net [216.240.47.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2C143D53; Tue, 4 Apr 2006 19:26:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id EB70F243082; Tue, 4 Apr 2006 12:26:14 -0700 (PDT) Received: from [10.251.17.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id k34JQDi8021285; Tue, 4 Apr 2006 12:26:14 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4432C84E.8050007@elischer.org> Date: Tue, 04 Apr 2006 12:26:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> In-Reply-To: <20060404112938.G76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 19:26:22 -0000 Robert Watson wrote: > > On Tue, 4 Apr 2006, Peter Jeremy wrote: > >> On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote: >> >>> (2) The name space model for system v ipc is flat, so while it's >>> desirable >>> to >>> allow the administrator in the host environment to monitor and >>> control >>> resource use in the jail (for example, delete allocated but unused >>> segments), doing that requires developing an administrative model >>> for >>> it. >> >> >> The SysV SHM name space is made up of a 32-bit user-selected key >> which is mapped into a 32-bit (system chosen) identifier, which (on >> FreeBSD) is made up of a 16-bit pool identifier (in the range >> 0..shmmni-1) and a 16-bit generation counter. >> >> At the expense of restricting shmmni, the generation counter and >> JAIL_MAX, it would seem possible to embed prison.pr_id into the shmid >> and treat pr_id as an (implicit) part of the key - insisting they >> must match for jailed processes. Since the name space remains the >> same, ipcs and ipcrm would not be affected and a non-jailed ipcrm >> could delete jailed IPC by identifier. >> >> On the surface, this approach looks easier than having a distinct >> name space associated with each prison (as per kern/48471) and has >> the advantage of allowing non-jailed processes to manage jailed IPC. >> The disadvantage is restricting the ranges of various counters - >> though I believe they are overly generous by default. >> >> This doesn't really address the problem of SysV IPC and jails >> becoming more intimately entwined. > > > Hmm. This sounds like it might be workable. To make sure I > understand your proposal: > > - We add a new prison ID field to the in-kernel description of each > segment, > semaphore, message queue, etc. This is initialized to the prison ID > of the > process creating the object at the time of creation. > > - shmget(), et al, will, in addition to matching the key when > searching for an > existing object, will also attempt to match the prison ID of the > object to > the process. For the sake of completeness, we will use prison ID 0 for > unjailed processes (or something along those lines). This > guarantees that > two jails, or even the host and a jail, will never receive an ID > already > allocated to another jail, and in particular, not an ID for an > object from > another jail with the same key as might be used in the current jail. what if a host wants to communicate with a jail? does it make sense? at teh moment a host ca see into a jail inmany ways.. (filesystem, sockets, process space etc.) > > - shmat(), et al, will perform an access control check to confirm that > if a > process is jailed, its prison ID matches that of the object. > > Is it necessary, as you suggest, to change the IPC ID name space at > all? I assume applications do consistently use shmget() to look up > IDs, and that they can't/don't make assumptions about long-term > persistence of those mappings across boot (which is effectively what a > jail restart is? Is the behavior of IPXSEQ_TO_IPCID() something that > has documented or relied on properties, or are we free to perform a > mapping from a name (key) to an object (id) in any way we choose? > > I guess another change is also needed: > > - At jail termination, we GC all resources with the prison ID in > question. > > This prevents a future jail from turning up with the same ID and > seeing old shared memory (etc) segments. > > Robert N M Watson > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 19:54:51 2006 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 4A54316A400 for ; Tue, 4 Apr 2006 19:54:51 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 831DB43D64 for ; Tue, 4 Apr 2006 19:54:49 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 98873 invoked from network); 4 Apr 2006 19:54:47 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 4 Apr 2006 19:54:47 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k34Jslmh028061; Tue, 4 Apr 2006 21:54:47 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k34Jsk3f028060; Tue, 4 Apr 2006 21:54:46 +0200 (CEST) (envelope-from pho) Date: Tue, 4 Apr 2006 21:54:46 +0200 From: Peter Holm To: Tor Egge Message-ID: <20060404195446.GA28037@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: truckman@freebsd.org, current@freebsd.org Subject: softdep_flush panic with snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 19:54:51 -0000 With GENERIC HEAD from Apr 4 14:50 UTC I got this panic: panic: lockmgr: thread 0xc22a6d80, not exclusive lock holder 0xc240fa20 unlocking cpuid = 0 KDB: enter: panic [thread pid 45 tid 100043 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 45 tid 100043 td 0xc22a6d80 kdb_enter(c08a1a10) at kdb_enter+0x2b panic(c089f9af,c22a6d80,c089f999,c240fa20,c22a6d80) at panic+0x14b lockmgr(c2a54e90,6,c2a54eb4,c22a6d80,cc998c2c) at lockmgr+0x514 vop_stdunlock(cc998c4c,c2941294,c2a54e38,cc998c68,c06c74b4) at vop_stdunlock+0x22 VOP_UNLOCK_APV(c09475a0,cc998c4c) at VOP_UNLOCK_APV+0x95 vput(c2a54e38,c09caab8,0,c08b9e51,df7) at vput+0xe4 handle_workitem_remove(c2e38280,0) at handle_workitem_remove+0x10f process_worklist_item(c23fca20,0) at process_worklist_item+0x183 softdep_process_worklist(c23fca20,0,0,c23e3234,c079ab50) at softdep_process_worklist+0x7c softdep_flush(0,cc998d38) at softdep_flush+0x132 There's no dump, but I ran the test in single user mode so I hope it's not totally worthlesss. http://people.freebsd.org/~pho/stress/log/cons198.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 20:45:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B3FC16A400 for ; Tue, 4 Apr 2006 20:45:41 +0000 (UTC) (envelope-from cel@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F5843D49 for ; Tue, 4 Apr 2006 20:45:41 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from [192.168.0.102] (adsl-68-73-204-112.dsl.sfldmi.ameritech.net [68.73.204.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Chuck Lever", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 706311BBE4 for ; Tue, 4 Apr 2006 16:45:40 -0400 (EDT) Message-ID: <4432DAF3.2040007@citi.umich.edu> Date: Tue, 04 Apr 2006 16:45:39 -0400 From: Chuck Lever Organization: Center for Information Technology Integration User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4432BD87.7080407@citi.umich.edu> In-Reply-To: <4432BD87.7080407@citi.umich.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: unable to build RELENG_6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cel@citi.umich.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 20:45:41 -0000 false alarm. this was a tool chain problem. Chuck Lever wrote: > after checking out RELENG_6 today to do some unrelated testing, i find > that i can no longer build the kernel. the config is a copy of GENERIC. > > "make depend" ends with this: > > cc -O2 -fno-strict-aliasing -pipe -nostdinc -I/usr/include -I. > -I../../../dev/aic7xxx/aicasm -o aicasm aicasm.o aicasm_symbol.o > aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll > ./aicasm -nostdinc -I- -I. -I../../.. -I../../../contrib/altq > -I../../../contrib/ipfilter -I../../../contrib/pf > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > -I../../../contrib/ngatm -I../../../dev/twa -I../../../cam/scsi > -I../../../dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p > aic7xxx_reg_print.c -i ../../../dev/aic7xxx/aic7xxx_osm.h > ../../../dev/aic7xxx/aic7xxx.seq > ./aicasm: Stopped at file scsi_message.h, line 47 - Regex compilation > failed > ./aicasm: Removing aic7xxx_seq.h due to error > ./aicasm: Removing aic7xxx_reg.h due to error > *** Error code 70 > > Stop in /u/cel/RELENG_6/sys/i386/compile/SPRINGFIELD. > > -- corporate: personal: From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 21:54:29 2006 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 E752216A41F for ; Tue, 4 Apr 2006 21:54:29 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by mx1.FreeBSD.org (Postfix) with SMTP id 545C943D77 for ; Tue, 4 Apr 2006 21:54:20 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 63082 invoked from network); 4 Apr 2006 21:54:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LyH5fw2lVlIKSCi+VAMPrYJyuNy2tgZnzs+EUrcxK/JxRd7AjuBJ1/ZxdslUCBfJilwtnqpf6K7rPl9LFgNdJq2TjrXG9ykEHnSho9wPTsM5S2URe02Tt5NuFb59QdHM4V1vV21HHVBdwhDg7NEBbiQez0zl37NtZ03fN7COM+k= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 4 Apr 2006 21:54:20 -0000 Message-ID: <4432EB19.5050501@rogers.com> Date: Tue, 04 Apr 2006 17:54:33 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Gallatin References: <44318FD2.1050206@rogers.com> <17458.35872.175979.759077@grasshopper.cs.duke.edu> In-Reply-To: <17458.35872.175979.759077@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 21:54:30 -0000 Andrew Gallatin wrote: > Mike Jakubik writes: > > It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA chipset, > > and we are still missing it. Is there any way to port their code over? > > There are a few nice motherboards out there that use this chipset (most > > amd server boards use the crappy nvidia chipset and the accompanying > > crappy network card). > > Why do you call the Nvida chipset "crappy"? I assume you don't care > about the PCI Express bandwidth of the accompanying "northbridge"? > > From a performance standpoint, the Nvida chipset is far from crappy, > and can easily sustain 10GbE speeds for both send and receive, as well > as send+receive at the same time. Our lab tests have shown well over > 18Gb/s for send+receive using our PCI-e x8 10GbE card in an Nvidia > CK804 based opteron. > > For any application which is moving a lot of data using PCI-e cards on > an opteron, I would strongly recommend Nvidia based servers. > None of that matters if the system is unreliable, and what you are boasting here is just the speed of a PCIe bus. See the mailing lists for the numerous problems associated with this chipset and the network card. From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 23:44:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE9516A425 for ; Tue, 4 Apr 2006 23:44:59 +0000 (UTC) (envelope-from sthalik@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id F324143D66 for ; Tue, 4 Apr 2006 23:44:58 +0000 (GMT) (envelope-from sthalik@tehran.lain.pl) Received: from sthalik by tehran.lain.pl with local (envelope-from ) id 1FQvCi-000PjD-Sz for freebsd-current@freebsd.org; Wed, 05 Apr 2006 01:44:56 +0200 Date: Wed, 5 Apr 2006 01:44:56 +0200 From: Stanislaw Halik To: freebsd-current@freebsd.org Message-ID: <20060404234456.GA98710@tehran.lain.pl> Mail-Followup-To: freebsd-current@freebsd.org References: <17457.4249.383686.765032@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <17457.4249.383686.765032@roam.psg.com> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Sender: Stanislaw Halik X-User: sthalik Subject: Re: natd when doubled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 23:44:59 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 03, 2006, Randy Bush wrote: > my ipfw.rules sez > add divert natd all from 192.168.0.0/24 to any via em0 > add divert natd all from any to 192.168.0.0/24 via ath0 > the two machines can ping eachother over the wireless. but > nat is just not doing it. try it that way: add divert natd all from any to external_ip in recv ext0 add divert natd all from lan_ip/24 to any out xmit rl0 HTH, -- sh --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEMwT4adU+vjT62TERAoqZAJ9SEdZrpKa1yKdQNlufHPl1xToYjgCfaEEb cU/x9kfk1yn4fbpyG9wTqe4= =a/CF -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 00:34:05 2006 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 473D416A41F for ; Wed, 5 Apr 2006 00:34:05 +0000 (UTC) (envelope-from flag@longino.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34CC743D53 for ; Wed, 5 Apr 2006 00:34:03 +0000 (GMT) (envelope-from flag@longino.wired.org) Received: from longino.wired.org (ip-114-46.sn1.eutelia.it [62.94.114.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id C6E9B11B1FC; Wed, 5 Apr 2006 02:34:05 +0200 (CEST) Received: from longino.wired.org (localhost [127.0.0.1]) by longino.wired.org (8.13.4/8.13.4) with ESMTP id k350Y0xO083689; Wed, 5 Apr 2006 02:34:00 +0200 (CEST) (envelope-from flag@longino.wired.org) Received: (from flag@localhost) by longino.wired.org (8.13.4/8.13.4/Submit) id k350Xx8F083688; Wed, 5 Apr 2006 02:33:59 +0200 (CEST) (envelope-from flag) Date: Wed, 5 Apr 2006 02:33:58 +0200 From: Paolo Pisati To: current@freebsd.org Message-ID: <20060405003358.GA83600@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: Luigi Rizzo Subject: Interesting data on network interrupt - part II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 00:34:05 -0000 Hi, i updated my work on interrupt profiling with sone new experiments. In total we have now: -FreeBSD 4 PIC (no asm part) -FreeBSD 7 APIC -FreeBSD 7 PIC -FreeBSD 7 PREE APIC -FreeBSD 7 APIC JHB Some quick comments: -PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) -PREE let new thread save less than 500 ticks of 'queue' while preempted threads are often resumed after a lot -JHB patch shaved 2.5k ticks in interrupt masking op For graphs, data and more comments: http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ bye -- Paolo "le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p" - Anonymous Lumbard From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 00:35:14 2006 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 3B35516A401 for ; Wed, 5 Apr 2006 00:35:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF6CC43D45 for ; Wed, 5 Apr 2006 00:35:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 04 Apr 2006 17:35:13 -0700 Message-ID: <443310BF.4030600@elischer.org> Date: Tue, 04 Apr 2006 17:35:11 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 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: change to syslog to allow specifying prot to send to.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 00:35:14 -0000 Does anyone think that this would be useful? the syslog.conf line would look like: *.* @logger.mynet.com:823 Index: syslogd.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/usr.sbin/syslogd/syslogd.c,v retrieving revision 1.59.2.28 diff -u -r1.59.2.28 syslogd.c --- syslogd.c 29 Feb 2004 20:59:19 -0000 1.59.2.28 +++ syslogd.c 5 Apr 2006 00:33:14 -0000 @@ -168,7 +168,7 @@ struct { char f_hname[MAXHOSTNAMELEN]; struct addrinfo *f_addr; - + u_short port; } f_forw; /* forwarding address */ char f_fname[MAXPATHLEN]; struct { @@ -1749,14 +1749,30 @@ p++; switch (*p) { + char * tp; + char *tp2; case '@': - (void)strlcpy(f->f_un.f_forw.f_hname, ++p, + /* + * scan forward to see if there is a port defined. + */ + tp2 = NULL; + tp = ++p; + while (*tp && (*tp++ != ':')) ; + if (*tp == ':') { + *tp++ = '\0'; + if (*tp) { + tp2 = tp; + } + } + + (void)strlcpy(f->f_un.f_forw.f_hname, p, sizeof(f->f_un.f_forw.f_hname)); + if (tp2) *--tp = ':'; memset(&hints, 0, sizeof(hints)); hints.ai_family = family; hints.ai_socktype = SOCK_DGRAM; - error = getaddrinfo(f->f_un.f_forw.f_hname, "syslog", &hints, - &res); + error = getaddrinfo(f->f_un.f_forw.f_hname, + tp2 ? tp2: "syslog", &hints, &res); if (error) { logerror(gai_strerror(error)); break; From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 01:29:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B5116A41F for ; Wed, 5 Apr 2006 01:29:16 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from pipa.vshosting.cz (pipa.vshosting.cz [81.0.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE0A43D49 for ; Wed, 5 Apr 2006 01:29:15 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhosl [127.0.0.1]) by pipa.vshosting.cz (Postfix) with ESMTP id 71FBD4E709; Wed, 5 Apr 2006 03:29:15 +0200 (CEST) Received: from pipa.vshosting.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16507-09; Wed, 5 Apr 2006 03:29:15 +0200 (CEST) Received: from gandalf (r3bc228.chello.upc.cz [213.220.246.228]) by pipa.vshosting.cz (Postfix) with ESMTP id 9D3D24E708; Wed, 5 Apr 2006 03:29:14 +0200 (CEST) From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= To: Date: Wed, 5 Apr 2006 03:29:11 +0200 Message-ID: <000701c65850$5830d0e0$6508280a@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C65861.1BB9A0E0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcZYSOqlphahHOFJRzK9YS/V3A4Ulw== X-Antivirus: avast! (VPS 0614-1, 04.04.2006), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: dandee@hellteam.net Subject: one side show: associated and second side show: no carrier 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, 05 Apr 2006 01:29:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Hello all, first of all I would like to thank Sam L. and others how helped with 80211ieee and atheros driver. Your work in last months is great ! With new ath_hal in source in RELENG_6 I decided to buy 2 new Wistron WNC CM10 with MAC chip AR5414A to connect 2 nodes with distance 3,5 km. My problem is associated or not. One side where is hostap show this: # ifconfig ath1 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS ERP 00:0b:6b:XX:YY:ZZ 1 108 6M 33 180 1200 16 E 0 WME RSSI=33, okay 33-95 = -62 dBm A datasheet for CM10 said for receive sensitivity: -85dBm@6Mbps -67dBm@54Mbps So theoretically the client should work with 6-54 Mbps/s without any difference, because the RF signal is enough to associate even at 54Mbps/s. Now go to client side, and what it show: ifconfig -v ath0 ath0: flags=8843 mtu 1500 inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2 inet 10.40.64.18 netmask 0xfffffffc broadcast 10.40.64.19 ether 00:0b:6b:XX:YY:ZZ media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11a status: no carrier ssid PtP channel 108 (5540) bssid 00:00:00:00:00:00 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 37 txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 pureg protmode OFF wme burst roaming AUTO bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ifconfig ath0 list ap SSID BSSID CHAN RATE S:N INT CAPS PtP 00:0b:6b:XX:YY:ZZ 108 54M 24:0 100 E WME It said "no carrier". RF signal on client side is lower, okay but 24-95 is -71dBm so it is enough signal strength to associate to AP at the minimum 6 Mbps/s. But it does not work. Any operation at both side like ifconfig ath0 down and up do not help me. How can hostap side say: "yes I see my client, it is accossiated to me with this mac", and client say: "yes I see my ap, but I could not associate to ap, even if I should associate to ap" ??? Any help is very appreciated. P.S.: ath_hal, ath driver and ath sample rate is compiled to my custom kernel. ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-wlanstats.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sta-wlanstats.txt" # wlanstats -i ath0 16652 rx discard 'cuz dup 213426 rx discard mgt frames 93283 rx beacon frames 62 rx element unknown 4 rx deauthentication 3 rx disassociation 6321 rx discard 'cuz port unauthorized 7114 active scans started ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-athstats,athdebug.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="hostap-athstats,athdebug.txt" # cd /usr/src/tools/tools/ath/ # ls athctrl.sh athdebug athstats Makefile # less Makefile # $FreeBSD: src/tools/tools/ath/Makefile,v 1.5.2.1 2006/01/31 = 20:48:19 sam Exp $ SUBDIR=3D athstats athdebug .include # make =3D=3D=3D> athstats (all) Warning: Object directory not changed from original = /usr/src/tools/tools/ath/athstats cc -O -pipe -march=3Dathlon-xp -c athstats.c cc -O -pipe -march=3Dathlon-xp -o athstats athstats.o =3D=3D=3D> athdebug (all) Warning: Object directory not changed from original = /usr/src/tools/tools/ath/athdebug cc -O -pipe -march=3Dathlon-xp -c athdebug.c cc -O -pipe -march=3Dathlon-xp -o athdebug athdebug.o # make install =3D=3D=3D> athstats (install) install -C -s -o root -g wheel -m 555 athstats /usr/local/bin =3D=3D=3D> athdebug (install) install -C -s -o root -g wheel -m 555 athdebug /usr/local/bin # rehash # athstats -i ath1 4122 tx management frames 20 tx frames discarded prior to association 6 tx stopped 'cuz no xmit buffer 29 tx failed 'cuz FIFO underrun 322 tx failed 'cuz bogus xmit rate 2926 tx frames with rts enabled 127 rx management frames 36119 beacon setup failed 'cuz no mbuf 8475 beacons transmitted 140 periodic calibration failures 2 tx used alternate antenna Antenna profile: [2] tx 2638 rx 129 [3] tx 1473 rx 0 # athdebug -i ath1 dev.ath.1.debug: 0x0 # sysctl dev.ath.1.debug=3D1 dev.ath.1.debug: 0 -> 1 # athdebug -i ath1 dev.ath.1.debug: 0x1 # athdebug -i ath1 dev.ath.1.debug: 0x1 # ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-ifconfig.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hostap-ifconfig.txt" # ifconfig -v ath1 ath1: flags=8843 mtu 1500 inet6 fe80::20b:6bff:fe2a:b8d5%ath1 prefixlen 64 scopeid 0x5 inet 10.40.64.17 netmask 0xfffffffc broadcast 10.40.64.19 ether 00:0b:6b:2a:b8:d5 media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11a status: associated ssid PtP-JSPOJ channel 108 (5540) bssid 00:0b:6b:2a:b8:d5 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 37 txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 pureg protmode OFF wme burst ssid SHOW -apbridge dtimperiod 1 bintval 100 AC_BE cwmin 4 cwmax 6 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 1 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 1 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-IFS, sysctl.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="hostap-IFS, sysctl.txt" # /root/athctrl.sh -i ath1 -d 3440 Setup IFS parameters on interface ath1 for 3440 meter p-2-p link dev.ath.1.slottime: 21 -> 21 dev.ath.1.acktimeout: 45 -> 45 dev.ath.1.ctstimeout: 45 -> 45 # sysctl dev.ath.1 dev.ath.1.%desc: Atheros 5212 dev.ath.1.%driver: ath dev.ath.1.%location: slot=3D19 function=3D0 dev.ath.1.%pnpinfo: vendor=3D0x168c device=3D0x001b subvendor=3D0x185f = subdevice=3D0x1600 class=3D0x020000 dev.ath.1.%parent: pci0 dev.ath.1.smoothing_rate: 95 dev.ath.1.sample_rate: 10 dev.ath.1.countrycode: 0 dev.ath.1.regdomain: 96 dev.ath.1.debug: 0 dev.ath.1.slottime: 21 dev.ath.1.acktimeout: 45 dev.ath.1.ctstimeout: 45 dev.ath.1.softled: 0 dev.ath.1.ledpin: 0 dev.ath.1.ledon: 0 dev.ath.1.ledidle: 2700 dev.ath.1.txantenna: 0 dev.ath.1.rxantenna: 2 dev.ath.1.diversity: 1 dev.ath.1.txintrperiod: 5 dev.ath.1.diag: 0 dev.ath.1.tpscale: 0 dev.ath.1.tpc: 0 dev.ath.1.tpack: 63 dev.ath.1.tpcts: 63 dev.ath.1.rfsilent: 1 dev.ath.1.rfkill: 1 dev.ath.1.monpass: 24 # sysctl hw.ath hw.ath.hal.version: 0.9.16.16 hw.ath.hal.dma_brt: 2 hw.ath.hal.sw_brt: 10 hw.ath.hal.swba_backoff: 0 hw.ath.dwell: 200 hw.ath.calibrate: 30 hw.ath.outdoor: 1 hw.ath.xchanmode: 1 hw.ath.countrycode: 0 hw.ath.regdomain: 0 hw.ath.rxbuf: 40 hw.ath.txbuf: 100 hw.ath.debug: 0 ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-list sta.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hostap-list sta.txt" # ifconfig ath1 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS ERP 00:0b:6b:2a:c7:8e 1 108 6M 33 165 1210 16 E 0 WME ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-wlanstats.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hostap-wlanstats.txt" # wlanstats -i ath1 5 active scans started ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-athstats,athdebug.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sta-athstats,athdebug.txt" # athstats -i ath0 12575 tx management frames 37988 tx frames discarded prior to association 3 tx linearized to cluster 9661 tx failed 'cuz too many retries 180725 long on-chip tx retries 5509 tx frames with no ack marked 16312 rx failed 'cuz of bad CRC 1 rx failed 'cuz frame too short 1 rx failed 'cuz frame too large 293597 rx failed 'cuz of PHY err 293597 OFDM timing 274 periodic calibrations rssi of last ack: 2 avg recv rssi: 22 1 switched default/rx antenna Antenna profile: [0] tx 0 rx 1 [1] tx 1628817 rx 2115750 # sysctl dev.ath.0.debug=1 dev.ath.0.debug: 0 -> 1 # athdebug -i ath0 dev.ath.0.debug: 0x1 # athdebug -i ath0 dev.ath.0.debug: 0x1 ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-ifconfig.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sta-ifconfig.txt" #ifconfig -v ath0 ath0: flags=8843 mtu 1500 inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2 inet 10.40.64.18 netmask 0xfffffffc broadcast 10.40.64.19 ether 00:0b:6b:2a:c7:8e media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11a status: no carrier ssid PtP-JSPOJ channel 108 (5540) bssid 00:00:00:00:00:00 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 37 txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 pureg protmode OFF wme burst roaming AUTO bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-IFS, sysctl.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sta-IFS, sysctl.txt" # /root/athctrl.sh -i ath0 -d 3440 Setup IFS parameters on interface ath0 for 3440 meter p-2-p link dev.ath.0.slottime: 21 -> 21 dev.ath.0.acktimeout: 45 -> 45 dev.ath.0.ctstimeout: 45 -> 45 # sysctl dev.ath.0 dev.ath.0.%desc: Atheros 5212 dev.ath.0.%driver: ath dev.ath.0.%location: slot=3D9 function=3D0 dev.ath.0.%pnpinfo: vendor=3D0x168c device=3D0x001b subvendor=3D0x185f = subdevice=3D0x1600 class=3D0x020000 dev.ath.0.%parent: pci0 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 96 dev.ath.0.debug: 0 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 45 dev.ath.0.ctstimeout: 45 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 1 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.monpass: 24 # sysctl hw.ath hw.ath.hal.version: 0.9.16.16 hw.ath.hal.dma_brt: 2 hw.ath.hal.sw_brt: 10 hw.ath.hal.swba_backoff: 0 hw.ath.dwell: 200 hw.ath.calibrate: 30 hw.ath.outdoor: 1 hw.ath.xchanmode: 1 hw.ath.countrycode: 0 hw.ath.regdomain: 0 hw.ath.rxbuf: 40 hw.ath.txbuf: 100 hw.ath.debug: 0 ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-list ap.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sta-list ap.txt" SSID BSSID CHAN RATE S:N INT CAPS PtP-JSPOJ 00:0b:6b:2a:b8:d5 108 54M 21:0 100 E WME ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-pciconf.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sta-pciconf.txt" ath0@pci0:9:0: class=3D0x020000 card=3D0x1600185f chip=3D0x001b168c = rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' class =3D network subclass =3D ethernet ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-pciconf.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="hostap-pciconf.txt" this ath0 is old CM9: ath0@pci0:14:0: class=3D0x020000 card=3D0x1012185f chip=3D0x0013168c = rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class =3D network subclass =3D ethernet this ath1 is new CM10: ath1@pci0:19:0: class=3D0x020000 card=3D0x1600185f chip=3D0x001b168c = rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' class =3D network subclass =3D ethernet BTW: Does somebody know where device information is ? :) ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="hostap-dmesq_-a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="hostap-dmesq_-a.txt" Copyright (c) 1992-2006 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.1-PRERELEASE #1: Sat Apr 1 06:36:36 CEST 2006 *****@*****:/usr/obj/usr/src/sys/***** Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(TM) 2300+ (1583.16-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x681 Stepping =3D 1 = Features=3D0x383fbff AMD Features=3D0xc0480800 real memory =3D 268419072 (255 MB) avail memory =3D 253181952 (241 MB) wlan: mac acl policy registered netsmb_dev: loaded ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, = RF5413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem = 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) rl0: port 0xd800-0xd8ff mem = 0xee800000-0xee8000ff irq 7 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:c0:df:02:af:cb rl1: port 0xd400-0xd4ff mem = 0xee000000-0xee0000ff irq 5 at device 11.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:50:fc:f9:39:31 ath0: mem 0xed800000-0xed80ffff irq 3 at device 14.0 on = pci0 ath0: Ethernet address: 00:0b:6b:35:50:9a ath0: mac 5.9 phy 4.3 radio 3.6 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb000-0xb00f at device 17.1 on pci0 ata0: on atapci0 ata1: on atapci0 vr0: port 0xa800-0xa8ff mem = 0xec800000-0xec8000ff at device 18.0 on pci0 miibus2: on vr0 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:11:2f:ca:cb:aa ath1: mem 0xec000000-0xec00ffff irq 4 at device 19.0 on = pci0 ath1: Ethernet address: 00:0b:6b:2a:b8:d5 ath1: mac 10.5 phy 6.1 radio 6.3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc9fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 Timecounter "TSC" frequency 1583161150 Hz quality 800 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, default to accept, logging limited to = 100 packets/entry ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding = enabled, default to accept, logging limited to 100 packets/entry by = default ad0: 9541MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s1a ------=_NextPart_000_0008_01C65861.1BB9A0E0 Content-Type: text/plain; name="sta-dmesq_-a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sta-dmesq_-a.txt" Copyright (c) 1992-2006 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.1-PRERELEASE #2: Mon Apr 3 03:45:25 CEST 2006 *****@*****:/usr/obj/usr/src/sys/***** Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2300+ (1579.38-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x681 Stepping =3D 1 = Features=3D0x383fbff AMD Features=3D0xc0480800 real memory =3D 234815488 (223 MB) avail memory =3D 220274688 (210 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered netsmb_dev: loaded ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, = RF5413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) 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_button0: on acpi0 acpi_button1: on acpi0 pcib0: port = 0xcf8-0xcff,0x480-0x48f,0x1000-0x10df,0x10e0-0x10ff on acpi0 pci0: on pcib0 agp0: mem 0xe8000000-0xebffffff at device = 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x4000-0x400f at device 2.5 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xed113000-0xed113fff irq 20 at = device 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xed114000-0xed114fff irq 21 at = device 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ohci2: mem 0xed110000-0xed110fff irq 22 at = device 3.2 on pci0 ohci2: [GIANT-LOCKED] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xed111000-0xed111fff irq = 23 at device 3.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 3 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: SiS EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 8 ports with 8 removable, self powered sis0: port 0xe000-0xe0ff mem = 0xed112000-0xed112fff irq 19 at device 4.0 on pci0 miibus0: on sis0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:0d:87:b0:5c:13 ath0: mem 0xed100000-0xed10ffff irq 17 at device 9.0 on = pci0 ath0: Ethernet address: 00:0b:6b:2a:c7:8e ath0: mac 10.5 phy 6.1 radio 6.3 rl0: port 0xe400-0xe4ff mem = 0xed115000-0xed1150ff irq 18 at device 10.0 on pci0 miibus1: on rl0 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:79:af:1f rl1: port 0xe800-0xe8ff mem = 0xed116000-0xed1160ff irq 19 at device 11.0 on pci0 miibus2: on rl1 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:00:1c:81:3a:9a acpi_tz0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 Timecounter "TSC" frequency 1579381961 Hz quality 800 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, default to accept, logging limited to = 100 packets/entry ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding = enabled, default to accept, logging limited to 100 packets/entry by = default ad0: 38166MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s1a ------=_NextPart_000_0008_01C65861.1BB9A0E0-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 02:57:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77CD416A401; Wed, 5 Apr 2006 02:57:14 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id E475143D46; Wed, 5 Apr 2006 02:57:13 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1FQyCm-0001k2-C4; Wed, 05 Apr 2006 11:57:12 +0900 Message-ID: <44333063.70606@highway.ne.jp> Date: Wed, 05 Apr 2006 11:50:11 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> <20060404141813.H22854@fledge.watson.org> In-Reply-To: <20060404141813.H22854@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 02:57:14 -0000 Robert Watson wrote: > > On Mon, 3 Apr 2006, Kazuaki Oda wrote: > >>> Also, are you running with INVARIANTS and/or WITNESS? >> >> >> Sorry, I compiled kernel without INVARIANTS and WITNESS. > > > No problem at all -- the debugging information you have sent me is > enough to track down the source of the problem. It looks like we have > an inconsistency in how we handle (especially in my new world order) the > recycling of timewait state for an inpcb that is still present. I've > committed a work-around which should prevent the panic you're seeing, > but I need to investigate a bit more before I can commit a full solution. > > For those interested, the problem is how to handle sockets with attached > inpcbs that represent closed or time wait TCP connections. This can > happen if shutdown() is called on a socket, kicking the TCP state engine > into a close cycle, rather than a reset. In the current world order, > the following sets of socket, pcb, and ppcb protocol state can occur: > > fd -> socket <-> inpcb <-> tcpcb Normal TCP socket in various states. > fd -> socket <-> inpcb <-> twtcp Unclosed TCP socket in time wait. > fd -> socket <-> inpcb <-> NULL Unclosed TCP socket after tw > recycle. > socket <-> inpcb <-> tcpcb Socket closed, buffer still needed. > inpcb <-> twtcp Socket closed, time wait. > > The problem was that the middle case exists, but was not accounted for. > There's another problem that is still present in the new socket/pcb > model, in which the inpcb of an open socket with a closed TCP connection > continues to reserve the address/port combination. This is related to > the inpcb without twtcp case, where we recycle the twtcp, but can't > recylce the inpcb immediately because there's still an fd reference to > the socket, and hence a socket reference to the inpcb. > > My current leaning is to do the following: > > - Since we now keep inpcb's around for the lifetime of the socket, either > teach the inpcb lookup routines to ignore INP_DROPPED, or to move them to > another inpcb list for open but dropped inpcb's. This will avoid the > reservation hanging around. > > - Either eliminate the inp_ppcb pointer NULL case by prohibiting > recycling of > the twtcp state of a socket that is still open, or more formally > supporting > it through the previous change. The trick is to prevent the twtcp/inpcb > pairs from turning up and being used during input and allocation > collision > processing. > > The summary is that we're not quite there yet in terms of how it all > should be working, but that we should avoid the panic for now due to the > workarounds I committed (which basically are changes to handle the > inp_ppcb pointer being NULL for INP_TIMEWAIT sockets). > > Thanks! > > Robert N M Watson > > I re-cvsup'ed today and rebuilt kernel. After reboot with new kernel, I got: # kgdb kernel.debug /var/crash/vmcore.5 [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". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc071886b stack pointer = 0x28:0xd4422b74 frame pointer = 0x28:0xd4422b80 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 = 14 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 9m26s Dumping 510 MB (2 chunks) chunk 0: 1MB (158 pages) ... ok chunk 1: 510MB (130544 pages) 494 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 #0 doadump () at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc066f042 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc066f369 in panic (fmt=0xc088de83 "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc083ca50 in trap_fatal (frame=0xd4422b34, eva=0) at /usr/src/sys/i386/i386/trap.c:870 #4 0xc083c78f in trap_pfault (frame=0xd4422b34, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc083c3a5 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1014804444, tf_esi = 0, tf_ebp = -733860992, tf_isp = -733861024, tf_ebx = -997587984, tf_edx = -997587984, tf_ecx = -1020269616, tf_eax = -733860800, tf_trapno = 12, tf_err = 0, tf_eip = -1066301333, tf_cs = 32, tf_eflags = 66118, tf_esp = -997587984, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc082841a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc071886b in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3835024, m=0xc3801b00, tlen=0) at pcpu.h:166 #8 0xc0715a44 in tcp_input (m=0xc3801b00, off0=20) at /usr/src/sys/netinet/tcp_input.c:763 #9 0xc070ee6d in ip_input (m=0xc3801b00) at /usr/src/sys/netinet/ip_input.c:656 #10 0xc06eb98b in netisr_processqueue (ni=0xc0971e38) at /usr/src/sys/net/netisr.c:236 #11 0xc06ebb8a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #12 0xc0659e49 in ithread_execute_handlers (p=0xc32fd468, ie=0xc333f100) at /usr/src/sys/kern/kern_intr.c:662 #13 0xc0659f69 in ithread_loop (arg=0xc32dc840) at /usr/src/sys/kern/kern_intr.c:745 #14 0xc0658d61 in fork_exit (callout=0xc0659f14 , arg=0xc32dc840, frame=0xd4422d38) at /usr/src/sys/kern/kern_fork.c:819 #15 0xc082847c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 (kgdb) frame 8 #8 0xc0715a44 in tcp_input (m=0xc3801b00, off0=20) at /usr/src/sys/netinet/tcp_input.c:763 763 if (tcp_timewait(intotw(inp), &to, th, m, tlen)) (kgdb) p inp $1 = (struct inpcb *) 0xc48a03f0 (kgdb) p *inp $2 = {inp_hash = {le_next = 0xc48ad690, le_prev = 0xc4962348}, inp_list = { le_next = 0xc48cddc8, le_prev = 0xc48d2dd0}, inp_flow = 0, inp_inc = { inc_flags = 0 '\0', inc_len = 0 '\0', inc_pad = 0, inc_ie = { ie_fport = 4364, ie_lport = 20480, ie_dependfaddr = {ie46_foreign = { ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 84650176}}, ie6_foreign = {__u6_addr = { __u6_addr8 = '\0' , "À¨\v\005", __u6_addr16 = { 0, 0, 0, 0, 0, 0, 43200, 1291}, __u6_addr32 = {0, 0, 0, 84650176}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 51095744}}, ie6_local = { __u6_addr = {__u6_addr8 = '\0' , "À¨\v\003", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 779}, __u6_addr32 = {0, 0, 0, 51095744}}}}}}, inp_ppcb = 0x0, inp_pcbinfo = 0xc0972ba0, inp_socket = 0xc494a530, inp_label = 0x0, inp_flags = 8388608, inp_sp = 0x0, inp_vflag = 41 ')', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', inp_ip_minttl = 0 '\0', inp_depend4 = {inp4_ip_tos = 0 '\0', inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = { inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_ifindex = 0, inp6_hops = 0}, inp_portlist = {le_next = 0xc48cddc8, le_prev = 0xc48d2e44}, inp_phd = 0xc341e780, inp_gencnt = 926118, inp_mtx = {mtx_object = { lo_name = 0xc08b6e09 "inp", lo_type = 0xc08b4936 "tcpinp", lo_flags = 21692416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3274697680, mtx_recurse = 0}} (kgdb) p *inp->inp_socket $3 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 8192, so_qstate = 0, so_pcb = 0xc48a03f0, so_proto = 0xc093a7c8, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = { tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc37a4bd0}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = { tqh_first = 0x0, tqh_last = 0xc494a578}, so_rcv = {sb_sel = {si_thrlist = { tqe_next = 0x0, tqe_prev = 0xc3ecaa50}, si_thread = 0x0, si_note = { kl_list = {slh_first = 0x0}, kl_lock = 0xc0653644 , kl_unlock = 0xc065367c , kl_locked = 0xc06536b8 , kl_lockarg = 0xc494a5a4}, si_flags = 0}, sb_mtx = {mtx_object = {lo_name = 0xc08adcf7 "so_rcv", lo_type = 0xc08adcf7 "so_rcv", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, sb_state = 32, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 0}, so_snd = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0653644 , kl_unlock = 0xc065367c , kl_locked = 0xc06536b8 , kl_lockarg = 0xc494a610}, si_flags = 0}, sb_mtx = {mtx_object = {lo_name = 0xc08adcf0 "so_snd", lo_type = 0xc08adcf0 "so_snd", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 33304, sb_mbcnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 0}, so_upcall = 0, so_upcallarg = 0x0, so_cred = 0xc3b91600, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 622463, so_emuldata = 0x0, so_accf = 0x0} (kgdb) p *inp->inp_ppcb Attempt to dereference a generic pointer. (kgdb) frame 7 #7 0xc071886b in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3835024, m=0xc3801b00, tlen=0) at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) p tw $4 = (struct tcptw *) 0x0 (kgdb) p *tw Cannot access memory at address 0x0 (kgdb) p *to $5 = {to_flags = 49, to_tsval = 97163995, to_tsecr = 0, to_mss = 1460, to_requested_s_scale = 0 '\0', to_nsacks = 0 '\0', to_sacks = 0x0} (kgdb) p *th $6 = {th_sport = 4364, th_dport = 20480, th_seq = 2749703150, th_ack = 0, th_x2 = 0, th_off = 10, th_flags = 2 '\002', th_win = 57344, th_sum = 0, th_urp = 0} (kgdb) Is more information required? -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 03:13:58 2006 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 E567016A41F; Wed, 5 Apr 2006 03:13:58 +0000 (UTC) (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 24B0D43D48; Wed, 5 Apr 2006 03:13:55 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:qfmBc6yw2lmmCFN1tXXvTWtrkdigVlcsaTHst+npVW7X9OLOAVg6qdSeM5AurjZw@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.6/8.13.6) with ESMTP/inet6 id k353DoqM078925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 12:13:50 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 05 Apr 2006 12:13:49 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@FreeBSD.org, current@FreeBSD.org In-Reply-To: References: User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.5) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.5-PRERELEASE 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.1.3 (ameno.mahoroba.org [IPv6:::1]); Wed, 05 Apr 2006 12:13:50 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ameno.mahoroba.org Cc: Subject: Re: [CFR] exposable reentrant functions of netdb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 03:13:59 -0000 Hi, >>>>> On Wed, 05 Apr 2006 03:04:04 +0900 >>>>> Hajimu UMEMOTO said: ume> http://www.imasy.or.jp/~ume/FreeBSD/netdb-solaris-api-20060405.diff.gz Oops, getprotobyname(3) is broken. Please throw my previous patch away, and use the following instead: http://www.imasy.or.jp/~ume/FreeBSD/netdb-solaris-api-20060405-2.diff.gz Sorry for the mess. 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 Apr 5 05:09:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C114716A420; Wed, 5 Apr 2006 05:09:21 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip8.gate01.com [61.122.117.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A735143D48; Wed, 5 Apr 2006 05:09:20 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop11.isp.us-com.jp with esmtp (Mail 4.20) id 1FR0Gc-0003Hl-Ur; Wed, 05 Apr 2006 14:09:19 +0900 Message-ID: <44334F5A.9060408@highway.ne.jp> Date: Wed, 05 Apr 2006 14:02:18 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kazuaki Oda References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> <20060404141813.H22854@fledge.watson.org> <44333063.70606@highway.ne.jp> In-Reply-To: <44333063.70606@highway.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 05:09:21 -0000 Kazuaki Oda wrote: > I re-cvsup'ed today and rebuilt kernel. After reboot with new kernel, I > got: > > > # kgdb kernel.debug /var/crash/vmcore.5 > [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". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc071886b > stack pointer = 0x28:0xd4422b74 > frame pointer = 0x28:0xd4422b80 > 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 = 14 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 9m26s > Dumping 510 MB (2 chunks) > chunk 0: 1MB (158 pages) ... ok > chunk 1: 510MB (130544 pages) 494 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 > > #0 doadump () at pcpu.h:166 > 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc066f042 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 > #2 0xc066f369 in panic (fmt=0xc088de83 "%s") > at /usr/src/sys/kern/kern_shutdown.c:558 > #3 0xc083ca50 in trap_fatal (frame=0xd4422b34, eva=0) > at /usr/src/sys/i386/i386/trap.c:870 > #4 0xc083c78f in trap_pfault (frame=0xd4422b34, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:778 > #5 0xc083c3a5 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1014804444, tf_esi = > 0, tf_ebp = -733860992, tf_isp = -733861024, tf_ebx = -997587984, tf_edx > = -997587984, tf_ecx = -1020269616, tf_eax = -733860800, tf_trapno = 12, > tf_err = 0, tf_eip = -1066301333, tf_cs = 32, tf_eflags = 66118, tf_esp > = -997587984, tf_ss = 0}) > at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc082841a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #7 0xc071886b in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3835024, > m=0xc3801b00, tlen=0) at pcpu.h:166 > #8 0xc0715a44 in tcp_input (m=0xc3801b00, off0=20) > at /usr/src/sys/netinet/tcp_input.c:763 > #9 0xc070ee6d in ip_input (m=0xc3801b00) > at /usr/src/sys/netinet/ip_input.c:656 > #10 0xc06eb98b in netisr_processqueue (ni=0xc0971e38) > at /usr/src/sys/net/netisr.c:236 > #11 0xc06ebb8a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 > #12 0xc0659e49 in ithread_execute_handlers (p=0xc32fd468, ie=0xc333f100) > at /usr/src/sys/kern/kern_intr.c:662 > #13 0xc0659f69 in ithread_loop (arg=0xc32dc840) > at /usr/src/sys/kern/kern_intr.c:745 > #14 0xc0658d61 in fork_exit (callout=0xc0659f14 , > arg=0xc32dc840, frame=0xd4422d38) at /usr/src/sys/kern/kern_fork.c:819 > #15 0xc082847c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:199 > (kgdb) frame 8 > #8 0xc0715a44 in tcp_input (m=0xc3801b00, off0=20) > at /usr/src/sys/netinet/tcp_input.c:763 > 763 if (tcp_timewait(intotw(inp), &to, th, m, tlen)) > (kgdb) p inp > $1 = (struct inpcb *) 0xc48a03f0 > (kgdb) p *inp > $2 = {inp_hash = {le_next = 0xc48ad690, le_prev = 0xc4962348}, inp_list = { > le_next = 0xc48cddc8, le_prev = 0xc48d2dd0}, inp_flow = 0, inp_inc = { > inc_flags = 0 '\0', inc_len = 0 '\0', inc_pad = 0, inc_ie = { > ie_fport = 4364, ie_lport = 20480, ie_dependfaddr = {ie46_foreign = { > ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 84650176}}, > ie6_foreign = {__u6_addr = { > __u6_addr8 = '\0' , "À¨\v\005", > __u6_addr16 = { > 0, 0, 0, 0, 0, 0, 43200, 1291}, __u6_addr32 = {0, 0, 0, > 84650176}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = > {0, > 0, 0}, ia46_addr4 = {s_addr = 51095744}}, ie6_local = { > __u6_addr = {__u6_addr8 = '\0' , "À¨\v\003", > __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 779}, __u6_addr32 = > {0, 0, > 0, 51095744}}}}}}, inp_ppcb = 0x0, inp_pcbinfo = 0xc0972ba0, > inp_socket = 0xc494a530, inp_label = 0x0, inp_flags = 8388608, inp_sp > = 0x0, > inp_vflag = 41 ')', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', > inp_ip_minttl = 0 '\0', inp_depend4 = {inp4_ip_tos = 0 '\0', > inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = { > inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, > inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_ifindex = 0, inp6_hops = 0}, > inp_portlist = {le_next = 0xc48cddc8, le_prev = 0xc48d2e44}, > inp_phd = 0xc341e780, inp_gencnt = 926118, inp_mtx = {mtx_object = { > lo_name = 0xc08b6e09 "inp", lo_type = 0xc08b4936 "tcpinp", > lo_flags = 21692416, lo_witness_data = {lod_list = {stqe_next = 0x0}, > lod_witness = 0x0}}, mtx_lock = 3274697680, mtx_recurse = 0}} > (kgdb) p *inp->inp_socket > $3 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, > so_state = 8192, so_qstate = 0, so_pcb = 0xc48a03f0, so_proto = > 0xc093a7c8, > so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = { > tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, > tqe_prev = 0xc37a4bd0}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, > so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq > = { > tqh_first = 0x0, tqh_last = 0xc494a578}, so_rcv = {sb_sel = > {si_thrlist = { > tqe_next = 0x0, tqe_prev = 0xc3ecaa50}, si_thread = 0x0, si_note > = { > kl_list = {slh_first = 0x0}, kl_lock = 0xc0653644 > , > kl_unlock = 0xc065367c , > kl_locked = 0xc06536b8 , kl_lockarg = > 0xc494a5a4}, > si_flags = 0}, sb_mtx = {mtx_object = {lo_name = 0xc08adcf7 "so_rcv", > lo_type = 0xc08adcf7 "so_rcv", lo_flags = 16973824, > lo_witness_data = { > lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, > mtx_recurse = 0}, sb_state = 32, sb_mb = 0x0, sb_mbtail = 0x0, > sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, > sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags > = 0}, > so_snd = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, > si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, > kl_lock = 0xc0653644 , > kl_unlock = 0xc065367c , > kl_locked = 0xc06536b8 , kl_lockarg = > 0xc494a610}, > si_flags = 0}, sb_mtx = {mtx_object = {lo_name = 0xc08adcf0 "so_snd", > lo_type = 0xc08adcf0 "so_snd", lo_flags = 16973824, > lo_witness_data = { > lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, > mtx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, > sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat = 33304, sb_mbcnt = 0, > sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, > sb_flags = 0}, so_upcall = 0, so_upcallarg = 0x0, so_cred = 0xc3b91600, > so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 622463, so_emuldata = > 0x0, > so_accf = 0x0} > (kgdb) p *inp->inp_ppcb > Attempt to dereference a generic pointer. > (kgdb) frame 7 > #7 0xc071886b in tcp_timewait (tw=0x0, to=0xd4422c40, th=0xc3835024, > m=0xc3801b00, tlen=0) at pcpu.h:166 > 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) p tw > $4 = (struct tcptw *) 0x0 > (kgdb) p *tw > Cannot access memory at address 0x0 > (kgdb) p *to > $5 = {to_flags = 49, to_tsval = 97163995, to_tsecr = 0, to_mss = 1460, > to_requested_s_scale = 0 '\0', to_nsacks = 0 '\0', to_sacks = 0x0} > (kgdb) p *th > $6 = {th_sport = 4364, th_dport = 20480, th_seq = 2749703150, th_ack = 0, > th_x2 = 0, th_off = 10, th_flags = 2 '\002', th_win = 57344, th_sum = 0, > th_urp = 0} > (kgdb) > > > Is more information required? > > -- > Kazuaki Oda > I've read the source code: /* * XXXRW: Time wait state for inpcb has been recycled, but inpcb is * still present. This is undesirable, but temporarily necessary * until we work out how to handle inpcb's who's timewait state has * been removed. */ if (tw == NULL) goto drop; drop: INP_UNLOCK(tw->tw_inpcb); m_freem(m); return (0); Hmm, it seems to be null pointer dereference because tw is NULL... -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 05:53:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7238B16A41F for ; Wed, 5 Apr 2006 05:53:36 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 089BC43D48 for ; Wed, 5 Apr 2006 05:53:35 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by zproxy.gmail.com with SMTP id s1so2155693nze for ; Tue, 04 Apr 2006 22:53:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MqEwGsUxKN1BrlNSSJhu8lmtyUc9tHQzGBuovLPvDEJDq+ZISCNR/n0h2ijtEXvq7WFxbLBt5M+ve+mKws+bTOoduldrkPJ2daM1oLPhmUFrtUS2Hxha3NfEpdyYNc4t+LPwJjd3pKq20o83nx69dh184GWmUK4t5WMJLIVd+VE= Received: by 10.37.2.6 with SMTP id e6mr501070nzi; Tue, 04 Apr 2006 22:53:35 -0700 (PDT) Received: by 10.36.75.9 with HTTP; Tue, 4 Apr 2006 22:53:35 -0700 (PDT) Message-ID: <47d0403c0604042253n5f5dabeap333ff5df977b087b@mail.gmail.com> Date: Wed, 5 Apr 2006 00:53:35 -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: acpi: bad [read from | write to] port 0x086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 05:53:36 -0000 Hi all, Robert Watson's call for testing of his network code prompted me to upgrade my current, from one of january 29 to one of today: -bash-2.05b$ uname -a FreeBSD prolepsis.urh.uiuc.edu 7.0-CURRENT FreeBSD 7.0-CURRENT #21: Mon Apr 3 13:35:05 UTC 2006 =20 kaduk@prolepsis.urh.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 In the process, I managed to install world before installing the kernel, since I misread the build log (which had errored out due to a lack of audit group), but afterwards I installed the new kernel, then re-cvsuped (to get a few new changes), and rebuilt world and kernel via the standard procedure, with no errors. Since the entire (second) sequence finished without error, I am operating on the assumption that this is not a result of me shooting myself in the foot. After installing world of a few days ago, both new and old kernels will spew out spurts of the following on the console: acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) acpi: bad write to port 0x086 (8), val 0 acpi: bad read from port 0x086 (8) ... I seem to recall there being an off-by-one error for someone else, but that was port 83, IIRC (I can't seem to find the commit message for that fix at the moment). Does anyone have any thoughts about this? An incomplete (non-verbose) dmesg and pciconf may be found at: https://netfiles.uiuc.edu/kaduk/www/prolepsis/ (sorry that it thinks the dmesg is a binary file) Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 06:27:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A922716A400; Wed, 5 Apr 2006 06:27:10 +0000 (UTC) (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 3713043D46; Wed, 5 Apr 2006 06:27:04 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR1Z9-000JJl-Dt; Wed, 05 Apr 2006 15:32:31 +0900 Message-ID: <44336331.40909@micom.mng.net> Date: Wed, 05 Apr 2006 15:26:57 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> In-Reply-To: <20060404101223.GH683@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lydianconcepts@gmail.com, freebsd-current@freebsd.org, mjacob@FreeBSD.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 06:27:10 -0000 Hi, Here is the information of HP Proliant ML 370 G4 and trace of panic: ProLiant System BIOS - P50 (11/09/2005) Copyright 1982, 2005 Hewlett-Packard Development Group, L.P. 1024 MB Detected Processor 1 initialized at 3.20 GHz/800 MHz(2MB L2) Processor 2 initialized at 3.20 GHz/800 MHz(2MB L2) Advanced Memory Protection Mode: Advanced ECC Support Redundant ROM Detected - This system contains a valid backup system ROM. 1024 MB Initialized / 1024 MB Detected ProLiant System BIOS - P50 (11/09/2005) Copyright 1982, 2005 Hewlett-Packard Development Group, L.P. Processor 1 initialized at 3.20 GHz/800 MHz(2MB L2) Processor 2 initialized at 3.20 GHz/800 MHz(2MB L2) Advanced Memory Protection Mode: Advanced ECC Support Redundant ROM Detected - This system contains a valid backup system ROM. LSI Logic Corp. MPT BIOS Copyright 1995-2005 LSI Logic Corp. MPTBIOS-5.05.20.00 HP Build <<>> HBA ID LUN VENDOR PRODUCT REV SYNC WIDE CAPACITY --- -- --- -------- ---------------- -------- ----- ---- ------------ 0 0 0 COMPAQ BD1468A4B5 HPB8 80.0 16 146 GB ** 0 7 0 LSILogic LSI1030-IT 1032700 320.0 16 1 7 0 LSILogic LSI1030-IT 1032700 320.0 16 This device has been validated to run at 80MB/s and should support, (**) 320MB/s, when the operating system is loaded. LSI Logic Corp. MPT boot ROM successfully installed! Integrated Lights-Out is disabled. Use the iLO Security Override Switch and iLO F8 ROM-Based Setup Utility to enable iLO functionality. Press "F9" key for ROM-Based Setup Utility Press "F10" key for System Maintenance Menu For access via BIOS Serial Console Press "ESC+9" for ROM-Based Setup Utility Press "ESC+0" for System Maintenance Menu Attempting Boot From CD-ROM Attempting Boot From Hard Drive (C:) -\|/-\|// bboooott..ccoonnffiigg:: --DDhh FFrreeeeBBSSDD//ii338866 bboooott DDeeffaauulltt:: 00::ddaa((00,,aa))//bboooott//llooaaddeerr bboooott:: //--\\||//-- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 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 #0: Tue Apr 4 01:16:20 ULAST 2006 tsgan@asiatel.micom.mng.net:/usr/obj/usr/src/sys/GW WARNING: WITNESS option enabled, expect reduced performance. MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20000000 Logical CPUs per core: 2 panic: CPU class not configured cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop db> trace Tracing pid 0 tid 0 td 0xc084ff78 kdb_enter(c0796996) at kdb_enter+0x2b panic(c07b3500,c0c20d74,c072ea1c,c4ace4ec,c08292f0) at panic+0x127 panicifcpuunsupported(c4ace4ec,c08292f0,c0c20d88,c05c3d66,0) at panicifcpuunsupported+0x23 cpu_startup(0,c1ec00,c1e000,0,c043d4e5) at cpu_startup+0x14 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> where Tracing pid 0 tid 0 td 0xc084ff78 kdb_enter(c0796996) at kdb_enter+0x2b panic(c07b3500,c0c20d74,c072ea1c,c4ace4ec,c08292f0) at panic+0x127 panicifcpuunsupported(c4ace4ec,c08292f0,c0c20d88,c05c3d66,0) at panicifcpuunsupported+0x23 cpu_startup(0,c1ec00,c1e000,0,c043d4e5) at cpu_startup+0x14 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> c panic: sched_bind: cannot bind non-running thread cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop db> Ganbold Peter Jeremy wrote: > On Tue, 2006-Apr-04 18:24:07 +0900, Ganbold wrote: > >> Peter Jeremy wrote: >> >>> On Tue, 2006-Apr-04 11:07:33 +0900, Ganbold wrote: >>> >>> >>>> I've got panic "CPU class not configured" on today's CURRENT. >>>> I have HP Proliant ML370 G4 machine with Xeon CPU 3.20GHz CPU. >>>> >>>> When machine tries to boot following message appears: >>>> ... >>>> CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >>>> ... >>>> >>>> >>> The indented lines after 'CPU:' are fairly critical as they define >>> what the CPU is reporting which can then be compared to the logic >>> in i386/i386/identcpu.c to see why the CPU isn't being identified. >>> > > Basically, FreeBSD can't identify the CPU and so is panicing. If > you care to post the indented lines after 'CPU:' which you elided, > someone may be able to work out why. > > From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 06:38:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2F4916A401 for ; Wed, 5 Apr 2006 06:38:16 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2925043D45 for ; Wed, 5 Apr 2006 06:38:15 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k356rLVI084471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 02:53:27 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Wed, 5 Apr 2006 02:37:58 -0400 User-Agent: KMail/1.9.1 References: <47d0403c0604042253n5f5dabeap333ff5df977b087b@mail.gmail.com> In-Reply-To: <47d0403c0604042253n5f5dabeap333ff5df977b087b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1261254.1z1lVr0vhz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604050238.12584.mistry.7@osu.edu> X-Spam-Status: No, score=-6.6 required=5.0 tests=ALL_TRUSTED,BAYES_05, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1376/Wed Apr 5 01:51:25 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: Ben Kaduk Subject: Re: acpi: bad [read from | write to] port 0x086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 06:38:16 -0000 --nextPart1261254.1z1lVr0vhz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 April 2006 01:53, Ben Kaduk wrote: > Hi all, > > After installing world of a few days ago, both new and old kernels > will spew out spurts of the following on the console: > acpi: bad read from port 0x086 (8) > acpi: bad write to port 0x086 (8), val 0 > I seem to recall there being an off-by-one error for someone else, > but that was port 83, IIRC (I can't seem to find the commit message > for that fix at the moment). > > Does anyone have any thoughts about this? See the commit log for revision 1.18 of=20 src/sys/dev/acpica/Osd/OsdHardware.c. =2D-=20 Anish Mistry --nextPart1261254.1z1lVr0vhz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEM2XUxqA5ziudZT0RAjSUAKDC/Zp9Y3NgmMh5PRKV8hCdEPKXKQCghitM JS5nmIu0MTnvMTYeFSJ6SS4= =MWEI -----END PGP SIGNATURE----- --nextPart1261254.1z1lVr0vhz-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 07:54:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F0FA16A401 for ; Wed, 5 Apr 2006 07:54:23 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF6EF43D45 for ; Wed, 5 Apr 2006 07:54:22 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k3589SFM021827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Apr 2006 04:09:34 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Wed, 5 Apr 2006 03:53:57 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4028611.KI2YrRSBHp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604050354.19659.mistry.7@osu.edu> X-Spam-Status: No, score=-8.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1376/Wed Apr 5 01:51:25 2006 on mail.united-ware.com X-Virus-Status: Clean Subject: [PATCH] ugen detach race X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 07:54:23 -0000 --nextPart4028611.KI2YrRSBHp Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline While working on getting hplip ported I ran across a race condition=20 in the ugen code that causes a crash. The following patch fixes a=20 problem where read, write, and ioctl can be called during a detach=20 since sc_dying isn't checked before bumping the reference count. =20 This puts the sc_dying check before the *_do_* functions are called. =20 This includes the patch from usb/81308 to prevent polling on the=20 control endpoint. As well as a few NULL pointer checks from NetBSD. =20 This patch is applicable to RELENG_6. http://am-productions.biz/docs/ugen-detach-race.patch This doesn't fix the case where an application has a read/write=20 pending and then detach is called. In this case destroy_devl will=20 just keep looping until the read/write completes. =2D-=20 Anish Mistry --nextPart4028611.KI2YrRSBHp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEM3erxqA5ziudZT0RAlGZAJ0TSVBxCXNRkQVXDwcGL7eGu93D6wCdExde JtVKuqPsDTCHhYN8fF0eGVs= =BEn/ -----END PGP SIGNATURE----- --nextPart4028611.KI2YrRSBHp-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 07:58:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB85E16A401; Wed, 5 Apr 2006 07:58:52 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA1E43D60; Wed, 5 Apr 2006 07:58:46 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail02.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k357wfKv014097 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Apr 2006 17:58:44 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k357wfpX000889; Wed, 5 Apr 2006 17:58:41 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k357wfkb000888; Wed, 5 Apr 2006 17:58:41 +1000 (EST) (envelope-from peter) Date: Wed, 5 Apr 2006 17:58:41 +1000 From: Peter Jeremy To: Ganbold Message-ID: <20060405075841.GB699@turion.vk2pj.dyndns.org> References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44336331.40909@micom.mng.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: lydianconcepts@gmail.com, freebsd-current@freebsd.org, mjacob@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 07:58:52 -0000 On Wed, 2006-Apr-05 15:26:57 +0900, Ganbold wrote: >FreeBSD 7.0-CURRENT #0: Tue Apr 4 01:16:20 ULAST 2006 > tsgan@asiatel.micom.mng.net:/usr/obj/usr/src/sys/GW >WARNING: WITNESS option enabled, expect reduced performance. >MPTable: >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) > Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 > >Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20000000 > Logical CPUs per core: 2 >panic: CPU class not configured The Origin and Id look sane. Checking printcpuinfo(), the 'Unknown-class' is printed because cpu_class is not valid. cpu_class is initialised based on 'cpu' which is set in i386/locore.s::identify_cpu Next request: Can you please print the 'cpu' and 'cpu_class' variables in DDB. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 08:39:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B394F16A400; Wed, 5 Apr 2006 08:39:00 +0000 (UTC) (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 022B443D45; Wed, 5 Apr 2006 08:38:09 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR3cF-000LQw-Ap; Wed, 05 Apr 2006 17:43:51 +0900 Message-ID: <443381F9.3010504@micom.mng.net> Date: Wed, 05 Apr 2006 17:38:17 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> In-Reply-To: <20060405075841.GB699@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lydianconcepts@gmail.com, freebsd-current@freebsd.org, mjacob@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 08:39:00 -0000 Peter Jeremy wrote: > On Wed, 2006-Apr-05 15:26:57 +0900, Ganbold wrote: > >> FreeBSD 7.0-CURRENT #0: Tue Apr 4 01:16:20 ULAST 2006 >> tsgan@asiatel.micom.mng.net:/usr/obj/usr/src/sys/GW >> WARNING: WITNESS option enabled, expect reduced performance. >> MPTable: >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) >> Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 >> >> Features=0xbfebfbff >> Features2=0x641d> >> AMD Features=0x20000000 >> Logical CPUs per core: 2 >> panic: CPU class not configured >> > > The Origin and Id look sane. Checking printcpuinfo(), the > 'Unknown-class' is printed because cpu_class is not valid. > cpu_class is initialised based on 'cpu' which is set in > i386/locore.s::identify_cpu > > Next request: Can you please print the 'cpu' and 'cpu_class' variables > in DDB. > Here is what I get when I reboot from FreeBSD-6.1-PRERELEASE after installing new CURRENT kernel: mpt0: Unhandled Event Notify Frame. Event 0x30. mpt1: Unhandled Event Notify Frame. Event 0x30. Shutting down ACPI Interrupt storm detected on "irq9:"; throttling interrupt source Rebooting... cpu_reset: Stopping other CPUs Here is cpu and cpu_class variables after booting to CURRENT: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 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 #1: Wed Apr 5 08:13:14 ULAST 2006 root@asiatel.micom.mng.net:/usr/obj/usr/src/sys/GW WARNING: WITNESS option enabled, expect reduced performance. MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (Unknown-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20000000 Logical CPUs per core: 2 panic: CPU class not configured cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop db> trace Tracing pid 0 tid 0 td 0xc0850118 kdb_enter(c0796a76) at kdb_enter+0x2b panic(c07b3652,c0c20d74,c072eafc,c4ace4ec,c0829490) at panic+0x127 panicifcpuunsupported(c4ace4ec,c0829490,c0c20d88,c05c3d5e,0) at panicifcpuunsupported+0x23 cpu_startup(0,c1ec00,c1e000,0,c043d4e5) at cpu_startup+0x14 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> p cpu c08c7014 db> p cpu_class c08c6f20 db> show pcpu cpuid = 0 curthread = 0xc0850118: pid 0 "" curpcb = 0xc0c20d90 fpcurthread = none idlethread = none APIC ID = 0 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xc0850118: pid 0 "" curpcb = 0xc0c20d90 fpcurthread = none idlethread = none APIC ID = 0 currentldt = 0x50 spin locks held: db> Ganbold From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 08:44:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C10E16A400 for ; Wed, 5 Apr 2006 08:44:55 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DD3743D46 for ; Wed, 5 Apr 2006 08:44:54 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k35900PJ022362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Apr 2006 05:00:06 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Wed, 5 Apr 2006 04:44:51 -0400 User-Agent: KMail/1.9.1 References: <200604050354.19659.mistry.7@osu.edu> In-Reply-To: <200604050354.19659.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3010816.88CGtNQh18"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604050444.51670.mistry.7@osu.edu> X-Spam-Status: No, score=-8.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1376/Wed Apr 5 01:51:25 2006 on mail.united-ware.com X-Virus-Status: Clean Subject: Re: [PATCH] ugen detach race X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 08:44:55 -0000 --nextPart3010816.88CGtNQh18 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 April 2006 03:53, Anish Mistry wrote: > While working on getting hplip ported I ran across a race > condition in the ugen code that causes a crash. The following > patch fixes a problem where read, write, and ioctl can be called > during a detach since sc_dying isn't checked before bumping the > reference count. This puts the sc_dying check before the *_do_* > functions are called. This includes the patch from usb/81308 to > prevent polling on the control endpoint. As well as a few NULL > pointer checks from NetBSD. This patch is applicable to RELENG_6. And CURRENT. > http://am-productions.biz/docs/ugen-detach-race.patch > > This doesn't fix the case where an application has a read/write > pending and then detach is called. In this case destroy_devl will > just keep looping until the read/write completes. =2D-=20 Anish Mistry --nextPart3010816.88CGtNQh18 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEM4ODxqA5ziudZT0RAu9UAJ94AfM2fkvSbL9Eh8q0G5488caJOACfbLyn T2TqceWKJtOy5AFDI3+s5ys= =q5+p -----END PGP SIGNATURE----- --nextPart3010816.88CGtNQh18-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 08:55:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2F9616A420; Wed, 5 Apr 2006 08:55:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3248343D48; Wed, 5 Apr 2006 08:55:44 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail12.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k358tfGl020166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Apr 2006 18:55:42 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k358tfvN001030; Wed, 5 Apr 2006 18:55:41 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k358tf7k001029; Wed, 5 Apr 2006 18:55:41 +1000 (EST) (envelope-from peter) Date: Wed, 5 Apr 2006 18:55:41 +1000 From: Peter Jeremy To: Robert Watson Message-ID: <20060405085541.GC699@turion.vk2pj.dyndns.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <20060404114107.GJ683@turion.vk2pj.dyndns.org> <20060404124313.B76562@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404124313.B76562@fledge.watson.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 08:55:45 -0000 On Tue, 2006-Apr-04 12:46:58 +0100, Robert Watson wrote: >On Tue, 4 Apr 2006, Peter Jeremy wrote: >>By merging the prison ID into the IPC ID, a non-jailed process can be >>allowed to see (and control) jailed IPC without needing any changes to >>ipcs/ipcrm. A non-jailed process won't be able to attach by key but would >>be able to attach by ID. > >I guess I'm asking a more specific question: you're suggesting treating the >prison ID as a logical, but transparent, extension to the key. Are you >suggesting actually changing the way values for the ID field are assigned, >or are you suggesting we continue to allocate and manage IDs as we do >currently? Currently, the ID number comprises a pool number and a generation number (16 bits of each). I'm suggesting that the algorithm be changed so that the ID number comprises a pool number, a generation number and a prison ID (or 0 if outside a prison). My initial suggestion is 10, 10 and 12 bits, respectively, but they will probably need to be tunable since I gather some users run very large numbers of jails. >Would it make more sense to simply allocate ID's sequentially, and simply >not allow access to objects with a non-matching prison? If the ID value is >entirely opaque, there's no real reason to assign a meaning to it, >especially if it leads to potential collisions if, say, the prison ID space >becomes large and sparse (due to lots of stopping and starting of prisons >over a long run). The difficulty of a totally opaque ID is mapping it to an actual instance. Currently, all SysV IPC types have fixed, system-wide limits on the number of identifiers that exist: msgmni, semmni and shmmni. FreeBSD (and probably other implementations) therefore allocate fixed- size arrays of identifiers and use a simple/cheap algorithm to map from an ID to the array slot (modulo in Tru64, masking in FreeBSD), combined with a generation count to catch attempts to reuse an old identifier. I believe that the IPCID_TO_{IX,SEQ}() and IXSEQ_TO_IPCID() macros are used for all translations so changing the mapping algorithm is not out of the question. The requirements are: - Given an ID, it must be cheap to locate the IPC object instance. (This operation has to be carried out on each IPCop() call). - It must be possible to determine if the number of existing objects is at the system limit and, if not, allocate a new object instance. - A management tool (ipcs) much be able to determine all the valid IDs. Given a suitable hashing algorithm then a totally opaque ID does offer advantages because there are no longer any arbitrary restrictions on parts of the ID. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 09:25:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CBE16A41F for ; Wed, 5 Apr 2006 09:25:22 +0000 (UTC) (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 6CEA443D49 for ; Wed, 5 Apr 2006 09:25:21 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR4Lv-000MFa-SK; Wed, 05 Apr 2006 18:31:03 +0900 Message-ID: <44338D08.3070000@micom.mng.net> Date: Wed, 05 Apr 2006 18:25:28 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> <20060405090326.GD699@turion.vk2pj.dyndns.org> In-Reply-To: <20060405090326.GD699@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 09:25:22 -0000 Peter Jeremy wrote: > On Wed, 2006-Apr-05 17:38:17 +0900, Ganbold wrote: > >> Here is what I get when I reboot from FreeBSD-6.1-PRERELEASE after >> installing new CURRENT kernel: >> > > The weird thing is that I can't see any relevant differences in > the CPU ident code between -stable and -current. > Me too, I checked identcpu.c, not much difference, except some preprocessor definitions. > >> db> p cpu >> c08c7014 >> db> p cpu_class >> c08c6f20 >> > > Drat. That's the address. Try "x/lu cpu" and "x/lu cpu_class". > db> x/lu cpu cpu: 16 db> x/lu cpu_class cpu_class: 4 db> Ganbold From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 09:35:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20AFE16A401 for ; Wed, 5 Apr 2006 09:35:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2429B43D6E for ; Wed, 5 Apr 2006 09:35:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0A24246CDE; Wed, 5 Apr 2006 05:35:02 -0400 (EDT) Date: Wed, 5 Apr 2006 10:35:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kazuaki Oda In-Reply-To: <44334F5A.9060408@highway.ne.jp> Message-ID: <20060405103429.D82516@fledge.watson.org> References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> <20060404141813.H22854@fledge.watson.org> <44333063.70606@highway.ne.jp> <44334F5A.9060408@highway.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 09:35:07 -0000 On Wed, 5 Apr 2006, Kazuaki Oda wrote: > I've read the source code: > > > /* > * XXXRW: Time wait state for inpcb has been recycled, but inpcb is > * still present. This is undesirable, but temporarily necessary > * until we work out how to handle inpcb's who's timewait state has > * been removed. > */ > if (tw == NULL) > goto drop; > > > > drop: > INP_UNLOCK(tw->tw_inpcb); > m_freem(m); > return (0); > > > Hmm, it seems to be null pointer dereference because tw is NULL... Indeed. I've inserted a NULL check here. Thanks again! Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 11:05:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B87416A400 for ; Wed, 5 Apr 2006 11:05:59 +0000 (UTC) (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 0D26E43D45 for ; Wed, 5 Apr 2006 11:05:58 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR5vL-000Nnm-1R; Wed, 05 Apr 2006 20:11:43 +0900 Message-ID: <4433A4A0.5060300@micom.mng.net> Date: Wed, 05 Apr 2006 20:06:08 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> <20060405090326.GD699@turion.vk2pj.dyndns.org> <44338D08.3070000@micom.mng.net> <20060405102528.GE699@turion.vk2pj.dyndns.org> In-Reply-To: <20060405102528.GE699@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT-solved, boot problem remains X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 11:05:59 -0000 Peter Jeremy wrote: > On Wed, 2006-Apr-05 18:25:28 +0900, Ganbold wrote: > >> db> x/lu cpu >> cpu: 16 >> > > That's correct for CPU_P4 but my reading of the code suggests that it > should be initialised by identify_cpu to CPU_686 (7). > > >> db> x/lu cpu_class >> cpu_class: 4 >> > > And that's correct for CPUCLASS_686. > > It's beginning to look like the "switch (cpu_class)" statement doesn't > have the I686_CPU code compiled in. Do you want to double check that > your kernel config really does have "cpu I686_CPU" and that you are > running a kernel compiled from that config. > Sorry for the noise, it was my big fault, I was using I486_CPU instead of I686_CPU in the config and never thought this problem might happen because of incorrect CPU definition in the config. Thanks a lot Peter, for pointing me this out. Only one problem still remains, it still can not boot without pressing "Enter" key at the boot prompt (- sign waits forever). I created /boot.config with -Dh, now it shows boot.config: -Dh and waits for user to press "Enter". FYI, it boots fine with Ubuntu Linux. Please advise me, where should I look in the code for solution? Is it under /usr/src/sys/boot/ or somewhere else? thanks a lot, Ganbold > If your i386 assembler is up to it, you might like to disassemble > printcpuinfo() using gdb and confirm that the above switch statement > looks correct. Unfortunately, it's a massive function so finding the > relevant code is not trivial - though the extensive use of global > variables makes it a lot easier than it could be. > > The relevant code in a -current kernel that I built last night looks > like the following. This covers the switch statement and the printf() > statements that immediately preceded and follow it. This was built > using CPUTYPE=athlon-xp COPTFLAGS="-O -pipe" - the relative offsets > may be different if you use different flags. If you find the address > of cpu_class (0xc0799440 in the following), there are only a couple of > references to it and only one is followed by those cmp statements. > > The critical code is the 'cmp $0x4,%eax' - this is the > 'case CPUCLASS_686:' test. > > 0xc0673400 : movl $0xc0799460,0x4(%esp) > 0xc0673408 : movl $0xc06e3416,(%esp) > 0xc067340f : call 0xc05243e0 > 0xc0673414 : mov 0xc0799440,%eax > 0xc0673419 : cmp $0x1,%eax > 0xc067341c : je 0xc067344b > 0xc067341e : cmp $0x1,%eax > 0xc0673421 : jg 0xc0673430 > 0xc0673423 : test %eax,%eax > 0xc0673425 : je 0xc067343a > 0xc0673427 : jmp 0xc0673526 > 0xc067342c : lea 0x0(%esi),%esi > 0xc0673430 : cmp $0x4,%eax > 0xc0673433 : je 0xc067345c > 0xc0673435 : jmp 0xc0673526 > 0xc067343a : movl $0xc06cdbea,(%esp) > 0xc0673441 : call 0xc05243e0 > 0xc0673446 : jmp 0xc0673532 > 0xc067344b : movl $0xc06e2d76,(%esp) > 0xc0673452 : call 0xc05243e0 > 0xc0673457 : jmp 0xc0673532 > 0xc067345c : mov 0xc079b960,%ebx > 0xc0673462 : mov 0xc079b964,%esi > 0xc0673468 : mov %ebx,%eax > 0xc067346a : mov %esi,%edx > 0xc067346c : add $0x1388,%eax > 0xc0673471 : adc $0x0,%edx > 0xc0673474 : movl $0xf4240,0x8(%esp) > 0xc067347c : movl $0x0,0xc(%esp) > 0xc0673484 : mov %eax,(%esp) > 0xc0673487 : mov %edx,0x4(%esp) > 0xc067348b : call 0xc068bca0 <__udivdi3> > 0xc0673490 : mov %eax,0xc07994e0 > 0xc0673495 : add $0x1387,%ebx > 0xc067349b : adc $0x0,%esi > 0xc067349e : movl $0x2710,0x8(%esp) > 0xc06734a6 : movl $0x0,0xc(%esp) > 0xc06734ae : mov %ebx,(%esp) > 0xc06734b1 : mov %esi,0x4(%esp) > 0xc06734b5 : call 0xc068bca0 <__udivdi3> > 0xc06734ba : mov %eax,%ecx > 0xc06734bc : mov $0x51eb851f,%edx > 0xc06734c1 : mov %ecx,%eax > 0xc06734c3 : mul %edx > 0xc06734c5 : shr $0x5,%edx > 0xc06734c8 : imul $0x64,%edx,%edx > 0xc06734cb : mov %ecx,%eax > 0xc06734cd : sub %edx,%eax > 0xc06734cf : mov %eax,0xc(%esp) > 0xc06734d3 : mov 0x8(%esp),%edx > 0xc06734d7 : mov 0xc(%esp),%ecx > 0xc06734db : mov %edx,0xffffffdc(%ebp) > 0xc06734de : mov %ecx,0xffffffe0(%ebp) > 0xc06734e1 : movl $0xf4240,0x8(%esp) > 0xc06734e9 : movl $0x0,0xc(%esp) > 0xc06734f1 : mov %ebx,(%esp) > 0xc06734f4 : mov %esi,0x4(%esp) > 0xc06734f8 : call 0xc068b610 <__divdi3> > 0xc06734fd : mov 0xffffffe0(%ebp),%ebx > 0xc0673500 : mov %ebx,0xc(%esp) > 0xc0673504 : mov %eax,0x4(%esp) > 0xc0673508 : mov %edx,0x8(%esp) > 0xc067350c : movl $0xc06e341b,(%esp) > 0xc0673513 : call 0xc05243e0 > 0xc0673518 : movl $0xc06e3171,(%esp) > 0xc067351f : call 0xc05243e0 > 0xc0673524 : jmp 0xc0673532 > 0xc0673526 : movl $0xc06e33dc,(%esp) > 0xc067352d : call 0xc05243e0 > 0xc0673532 : movl $0xc06e3429,(%esp) > 0xc0673539 : call 0xc05243e0 > > > >> db> >> >> Ganbold >> >> >> _______________________________________________ >> 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 Apr 5 12:04:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FE8C16A41F; Wed, 5 Apr 2006 12:04:26 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id D99C343E2F; Wed, 5 Apr 2006 12:02:51 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1FR6i6-0004XL-60; Wed, 05 Apr 2006 21:02:06 +0900 Message-ID: <4433B014.9040004@highway.ne.jp> Date: Wed, 05 Apr 2006 20:55:00 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: lock order reversal: tcp_input.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: Wed, 05 Apr 2006 12:04:26 -0000 Hi Robert, I re-cvsup'ed and rebuilt kernel again, and I got the following: lock order reversal: 1st 0xc493bb10 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:743 2nd 0xc09bdb8c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:616 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c097ef48,c097ef70,c0931524) at kdb_backtrace+0x29 witness_checkorder(c09bdb8c,9,c08afc89,268) at witness_checkorder+0x586 _mtx_lock_flags(c09bdb8c,0,c08afc89,268,0) at _mtx_lock_flags+0x6b tcp_input(c47f7c00,14,138,30ba8c0,0) at tcp_input+0x432 ip_input(c47f7c00) at ip_input+0x5a6 netisr_processqueue(c09bcdf8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c32fd468,c333f100) at ithread_execute_handlers+0xea ithread_loop(c32c1860,d4422d38) at ithread_loop+0x67 fork_exit(c06592e4,c32c1860,d4422d38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4422d6c, ebp = 0 --- Is there any other information I can provide to help you? -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Thu Mar 30 06:46:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115C416A400; Thu, 30 Mar 2006 06:46:50 +0000 (UTC) (envelope-from Matthew.Thyer@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CF443D5C; Thu, 30 Mar 2006 06:46:30 +0000 (GMT) (envelope-from Matthew.Thyer@dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id k2U6iUu0001811; Thu, 30 Mar 2006 16:14:30 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 30 Mar 2006 16:16:22 +0930 Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au [131.185.2.170]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id k2U6hXp20440; Thu, 30 Mar 2006 16:13:33 +0930 (CST) Received: from ednex511.dsto.defence.gov.au ([131.185.2.171]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 16:13:33 +0930 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Mar 2006 16:13:32 +0930 Message-ID: <07018E951F2FBF42B40B3D61086788344C1D9D@ednex511.dsto.defence.gov.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: mysql performance test results under FreeBSD-7.0-CURRENT Thread-Index: AcZTw0p28B08za9bS3GxT3I5LlQQxQAARnBA From: "Thyer, Matthew" To: "Ganbold" , X-OriginalArrivalTime: 30 Mar 2006 06:43:33.0030 (UTC) FILETIME=[435A6C60:01C653C5] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14353.000 X-TM-AS-Result: No--11.900000-8.000000-2 X-Mailman-Approved-At: Wed, 05 Apr 2006 12:18:01 +0000 Cc: jasone@freebsd.org, deischen@freebsd.org, phk@phk.freebsd.dk, rwatson@freebsd.org, davidxu@freebsd.org, grog@freebsd.org Subject: RE: mysql performance test results under FreeBSD-7.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 06:46:50 -0000 A couple of things I have noticed in the kernel messages: WARNING: WITNESS option enabled, expect reduced performance. You need to remove the WITNESS and the INVARIANTS options from your kernel when benchmarking. ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 28629MB at ata0-master UDMA33 ad1: DMA limited to UDMA33, controller found non-ATA66 cable ad1: 28629MB at ata0-slave UDMA33 ad3: 38166MB at ata1-slave UDMA100 You need to use the 80 core conductor cables instead of the old standard 40 core conductor IDE cables to get the best performance from your hard drives. Just use another cable like you already have connected to the 40GB drive. -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Ganbold Sent: Thursday, 30 March 2006 4:55 PM To: freebsd-current@freebsd.org Cc: jasone@freebsd.org; deischen@freebsd.org; phk@phk.freebsd.dk; rwatson@freebsd.org; davidxu@freebsd.org; grog@freebsd.org Subject: mysql performance test results under FreeBSD-7.0-CURRENT Hi all, I did make some mysql performance tests under FreeBSD-7.0-CURRENT with=20 various scheduler and compile time options. It seems like mysql(BUILD_OPTIMIZED=3Dyes, BUILD_STATIC=3Dyes,=20 WITH_PROC_SCOPE_PTH=3Dyes)-libpthread-tsc-sched_4bsd+preemption gives better performance. The test results are at: http://www.mnbsd.org/ftp/mysql_test_results.txt There are several things I didn't test and this leads to some questions: 1. I didn't make test with Poul-Henning's CPU accounting patch. Somehow=20 I can't apply it (http://phk.freebsd.dk/patch/cpu_acct_2.patch) cleanly. Where can I find latest patch? When this patch will be included in CURRENT? 2. I didn't make test with Robert Watson's patch=20 (http://www.watson.org/~robert/freebsd/clock/)? Does CURRENT src tree=20 include it? If not when this patch will be included in CURRENT? 3. I did make tests with default malloc in CURRENT. I'm confused what=20 malloc options should try (jemalloc? phkmalloc?) What is the default=20 malloc in CURRENT? How to use these different mallocs? thanks in advance, Ganbold _______________________________________________ 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 Thu Mar 30 12:11:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCE9416A41F for ; Thu, 30 Mar 2006 12:11:52 +0000 (UTC) (envelope-from leo@finalresort.org) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42AF243D46 for ; Thu, 30 Mar 2006 12:11:51 +0000 (GMT) (envelope-from leo@finalresort.org) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 8C409389D0; Thu, 30 Mar 2006 14:11:50 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 77E0A387C0 for ; Thu, 30 Mar 2006 14:11:50 +0200 (CEST) Received: from [10.4.1.100] (81-232-129-114-no21.tbcn.telia.com [81.232.129.114]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 61E9A37E49 for ; Thu, 30 Mar 2006 14:11:50 +0200 (CEST) Message-ID: <442BCB05.6080000@finalresort.org> Date: Thu, 30 Mar 2006 14:11:49 +0200 From: "Leo R. Lundgren" User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 05 Apr 2006 12:18:01 +0000 Subject: mdmfs -P X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2006 12:11:52 -0000 Hey all, Is there any way we could get the somewhat new -P option of mdmfs (http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mdmfs/mdmfs.c.diff?r1=1.25&r2=1.26) to be put into -stable as well? As far as I can see from the diff, there's no way it would break any existing implementation/usage of mdmfs, but the feature is highly desired, has been for years. With it all I need for my case is a line in an fstab, without it I need to have three lines in rc.local/equiv instead, and it's still not as dynamic as it should be, of course. Pretty please? =) PS: Please reply to me directly as well, since I'm not subscribed to this list (tracking stable). Thank you! Kind regards, // Leo From owner-freebsd-current@FreeBSD.ORG Sun Apr 2 23:00:13 2006 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 BF73216A426; Sun, 2 Apr 2006 23:00:13 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E05C243D45; Sun, 2 Apr 2006 23:00:12 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 51A3778C1D; Sun, 2 Apr 2006 23:00:12 +0000 (GMT) Date: Sun, 2 Apr 2006 23:00:12 +0000 From: John Birrell To: Robert Watson Message-ID: <20060402230012.GA24758@what-creek.com> References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> <20060402233436.P76562@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402233436.P76562@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 05 Apr 2006 12:18:01 +0000 Cc: current@FreeBSD.org Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2006 23:00:14 -0000 On Sun, Apr 02, 2006 at 11:37:21PM +0100, Robert Watson wrote: > OK, so it's been >24 hours since this was committed, and I've not received > any bug reports yet. This means once of three things: > > (1) There are no bugs. > > (2) I've broken everyone's systems so badly they can't submit bug reports. > > (3) Everyone is waiting for everyone else to upgrade due to the advance > notice > of instability. > > I consider (1) highly likely, (2) a property of 1990's development and > we've left that time since most people have multiple machines now, and (3) > much more likely. > > Please help test these changes! I leave for a trip to the US on Thursday, > and I'd rather get things working before I leave than while on travel, it > will save a lot of hassle for everyone. > > And if you're reading this after spending 48 hours getting your systems > working again to the point where you can read e-mail, sorry :-). I've just updated a current system which also serves as a (socket based) backup system for a remotely hosted web site with LOTS of file updates. The update went without a hitch and the system seems to work fine AFAICT. I guess that sounds like a bit of an anti-climax, but there really isn't anything to report. Sorry. 8-) Perhaps I just don't know what to look for. Shrug. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:56:00 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEBA716A41F; Tue, 4 Apr 2006 11:56:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from aaron.protected-networks.net (aaron.protected-networks.net [202.12.127.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF7E43D46; Tue, 4 Apr 2006 11:55:59 +0000 (GMT) (envelope-from imb@protected-networks.net) Received: from localhost (localhost [127.0.0.1]) by aaron.protected-networks.net (Postfix) with ESMTP id E98B7C576; Tue, 4 Apr 2006 07:55:58 -0400 (EDT) Received: from aaron.protected-networks.net (localhost [127.0.0.1]) by aaron.protected-networks.net (Postfix) with ESMTP id DE09FC4C6; Tue, 4 Apr 2006 07:55:53 -0400 (EDT) Authentication-Results: aaron.protected-networks.net from=imb@protected-networks.net; domainkey=pass Received: from aaron.protected-networks.net (localhost [127.0.0.1]) by aaron.protected-networks.net (Postfix) with ESMTP id 46FEDC434; Tue, 4 Apr 2006 07:55:53 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=200509; d=protected-networks.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=HTHD2LBy+UxxcFx2sTMV/VxI5wTbkX00qZ+9GTH/9ftflIWp9kccxFXtdWOxfdDdariQyQtANM4NzfQ41U4UHdlb2Yrlc5Ms6UtCVEh3kPp5sCFc/QkMXgsou0MQb/Dy; Received: from [192.168.1.11] (c-24-218-147-31.hsd1.ma.comcast.net [24.218.147.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) by aaron.protected-networks.net (Postfix) with ESMTP id CC367C29E; Tue, 4 Apr 2006 07:55:52 -0400 (EDT) Message-ID: <44325EC6.9090608@protected-networks.net> Date: Tue, 04 Apr 2006 07:55:50 -0400 From: Michael Butler User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert Watson References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <20060404114107.GJ683@turion.vk2pj.dyndns.org> <20060404124313.B76562@fledge.watson.org> In-Reply-To: <20060404124313.B76562@fledge.watson.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030900080501040703080208" X-Mailman-Approved-At: Wed, 05 Apr 2006 12:18:01 +0000 Cc: Peter Jeremy , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Apr 2006 11:56:01 -0000 This is a cryptographically signed message in MIME format. --------------ms030900080501040703080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: > Would it make more sense to simply allocate ID's sequentially, and > simply not allow access to objects with a non-matching prison? .. This depends on the expected size of the system-wide pool; sequential allocation invites sequential searches of the name/id-space when looking for items any individual jail-id "owns". However, what would work is a linked list of associated ids from each jail descriptor thereby creating the list of things to deallocate on jail termination, -- Michael Butler, CISSP Security Architect Protected Networks http://www.protected-networks.net --------------ms030900080501040703080208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN0DCC BuQwggTMoAMCAQICATEwDQYJKoZIhvcNAQEFBQAwgccxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJNQTEQMA4GA1UEBxMHTWVkZm9yZDEbMBkGA1UEChMSUHJvdGVjdGVkIE5ldHdvcmtzMR4w HAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxMTAvBgNVBAMTKFByb3RlY3RlZCBOZXR3 b3JrcyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxKTAnBgkqhkiG9w0BCQEWGmltYkBwcm90ZWN0 ZWQtbmV0d29ya3MubmV0MB4XDTA2MDIwNzE0MDE0NloXDTExMDMwODE0MDE0NlowgagxCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJNQTEQMA4GA1UEBxMHTWVkZm9yZDEbMBkGA1UEChMSUHJv dGVjdGVkIE5ldHdvcmtzMRQwEgYDVQQLEwtNYWlsIGNsaWVudDEcMBoGA1UEAxMTSWFpbiBN aWNoYWVsIEJ1dGxlcjEpMCcGCSqGSIb3DQEJARYaaW1iQHByb3RlY3RlZC1uZXR3b3Jrcy5u ZXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALJGiIrZoBOaYG7p44h64oIsBmQmi0n4 vfRKAdQY1TGGXAWWAWjdhJDUJJCLrkv2a3chbEBWfKOr+n8vHV5wI5fHN7Yp+9R7wVQ5Hb/F rUp3fZPRx83rd8+FvrtBLcfKDT7J8cIaUF+I14YTPFMSf6thm55hrjLIUB2FlPFrcH/7AgMB AAGjggJ6MIICdjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDBGBglghkgBhvhCAQ0E ORY3Q2VydGlmaWNhdGUgaXNzdWVkIGJ5IGh0dHA6Ly93d3cucHJvdGVjdGVkLW5ldHdvcmtz Lm5ldDAdBgNVHQ4EFgQUKTHICg24Uox83sZjRL50XypVU0IwgfwGA1UdIwSB9DCB8YAUVEXu oZyg4TYTDDa5wzviGlSDFj6hgc2kgcowgccxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNQTEQ MA4GA1UEBxMHTWVkZm9yZDEbMBkGA1UEChMSUHJvdGVjdGVkIE5ldHdvcmtzMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxMTAvBgNVBAMTKFByb3RlY3RlZCBOZXR3b3JrcyBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxKTAnBgkqhkiG9w0BCQEWGmltYkBwcm90ZWN0ZWQtbmV0 d29ya3MubmV0ggkAzFwjxK9/fmIwJQYDVR0SBB4wHIEaaW1iQHByb3RlY3RlZC1uZXR3b3Jr cy5uZXQwRwYJYIZIAYb4QgEEBDoWOGh0dHA6Ly93d3cucHJvdGVjdGVkLW5ldHdvcmtzLm5l dC9Qcm90ZWN0ZWRfTmV0d29ya3MuY3JsMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly93d3cu cHJvdGVjdGVkLW5ldHdvcmtzLm5ldC9Qcm90ZWN0ZWRfTmV0d29ya3MuY3JsMCUGA1UdEQQe MByBGmltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0MA4GA1UdDwEB/wQEAwIF4DANBgkqhkiG 9w0BAQUFAAOCAgEAlS1aZVoA0yQSiK8Jds1K1pZE7dvE6yJHcih3tMqBah5tzTHMDBoeuu7b rJ6lEbYM6r/y1WSJ+0PtMyMac/QxAw1nEtKmECOcNMUlwjiazDonHKNw/BjyCcZZ18SRL63p Jr209xa6c93PfSUFkM2ya8TfHnAjcfcR8NNsr53I6g/jItLqTltY56xglP8OVjDf7fXpzXhV 8w66pmye0tTldcTE95YjVGhr24aM5l42Mp6wveHQIaO9nALa5p3ujqMX72EpCG/phC7dy/2g xdhG7epqtWCEsC7XI4CrBke/fx4TO0T5tLhKGLFtNeqHXl3CjFnxGv9HAm6vutDpM90sTs5e F1M04tM2b7asNKAj0o1AOm0TIPk8obIOnu/8ifbOIOax8WtsbaR9wbpi5JU10FZdZPYfx91b NMztR/1ViCTsvAxPkluU3/I2EPjQZKpbwu7h06D+FH++9aStylZL0N9Hyf09EsYfYL3LGzWn NkMmmzSRHYtD8dHHWpby9OLsWtvKOqG7nrE0e5QZ8CWmc8xeAa4vGQDRTqkk3ALwiUeI/LG7 IoBCqVQXJWnTPtD2wcssG2j9phlDBa5XRo49yC/MTYOHmuAib/oORtsMR49Pv4/wTVNcwvZ+ iY473W36N0mfXXcEL7GD2OPzl89vIBLeUeP5gl3sKoV2JqYJBzwwggbkMIIEzKADAgECAgEx MA0GCSqGSIb3DQEBBQUAMIHHMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUExEDAOBgNVBAcT B01lZGZvcmQxGzAZBgNVBAoTElByb3RlY3RlZCBOZXR3b3JrczEeMBwGA1UECxMVQ2VydGlm aWNhdGUgQXV0aG9yaXR5MTEwLwYDVQQDEyhQcm90ZWN0ZWQgTmV0d29ya3MgQ2VydGlmaWNh dGUgQXV0aG9yaXR5MSkwJwYJKoZIhvcNAQkBFhppbWJAcHJvdGVjdGVkLW5ldHdvcmtzLm5l dDAeFw0wNjAyMDcxNDAxNDZaFw0xMTAzMDgxNDAxNDZaMIGoMQswCQYDVQQGEwJVUzELMAkG A1UECBMCTUExEDAOBgNVBAcTB01lZGZvcmQxGzAZBgNVBAoTElByb3RlY3RlZCBOZXR3b3Jr czEUMBIGA1UECxMLTWFpbCBjbGllbnQxHDAaBgNVBAMTE0lhaW4gTWljaGFlbCBCdXRsZXIx KTAnBgkqhkiG9w0BCQEWGmltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0MIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQCyRoiK2aATmmBu6eOIeuKCLAZkJotJ+L30SgHUGNUxhlwFlgFo 3YSQ1CSQi65L9mt3IWxAVnyjq/p/Lx1ecCOXxze2KfvUe8FUOR2/xa1Kd32T0cfN63fPhb67 QS3Hyg0+yfHCGlBfiNeGEzxTEn+rYZueYa4yyFAdhZTxa3B/+wIDAQABo4ICejCCAnYwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwRgYJYIZIAYb4QgENBDkWN0NlcnRpZmljYXRl IGlzc3VlZCBieSBodHRwOi8vd3d3LnByb3RlY3RlZC1uZXR3b3Jrcy5uZXQwHQYDVR0OBBYE FCkxyAoNuFKMfN7GY0S+dF8qVVNCMIH8BgNVHSMEgfQwgfGAFFRF7qGcoOE2Eww2ucM74hpU gxY+oYHNpIHKMIHHMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUExEDAOBgNVBAcTB01lZGZv cmQxGzAZBgNVBAoTElByb3RlY3RlZCBOZXR3b3JrczEeMBwGA1UECxMVQ2VydGlmaWNhdGUg QXV0aG9yaXR5MTEwLwYDVQQDEyhQcm90ZWN0ZWQgTmV0d29ya3MgQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MSkwJwYJKoZIhvcNAQkBFhppbWJAcHJvdGVjdGVkLW5ldHdvcmtzLm5ldIIJAMxc I8Svf35iMCUGA1UdEgQeMByBGmltYkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0MEcGCWCGSAGG +EIBBAQ6FjhodHRwOi8vd3d3LnByb3RlY3RlZC1uZXR3b3Jrcy5uZXQvUHJvdGVjdGVkX05l dHdvcmtzLmNybDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vd3d3LnByb3RlY3RlZC1uZXR3 b3Jrcy5uZXQvUHJvdGVjdGVkX05ldHdvcmtzLmNybDAlBgNVHREEHjAcgRppbWJAcHJvdGVj dGVkLW5ldHdvcmtzLm5ldDAOBgNVHQ8BAf8EBAMCBeAwDQYJKoZIhvcNAQEFBQADggIBAJUt WmVaANMkEoivCXbNStaWRO3bxOsiR3Iod7TKgWoebc0xzAwaHrru26yepRG2DOq/8tVkiftD 7TMjGnP0MQMNZxLSphAjnDTFJcI4msw6JxyjcPwY8gnGWdfEkS+t6Sa9tPcWunPdz30lBZDN smvE3x5wI3H3EfDTbK+dyOoP4yLS6k5bWOesYJT/DlYw3+316c14VfMOuqZsntLU5XXExPeW I1Roa9uGjOZeNjKesL3h0CGjvZwC2uad7o6jF+9hKQhv6YQu3cv9oMXYRu3qarVghLAu1yOA qwZHv38eEztE+bS4ShixbTXqh15dwoxZ8Rr/RwJur7rQ6TPdLE7OXhdTNOLTNm+2rDSgI9KN QDptEyD5PKGyDp7v/In2ziDmsfFrbG2kfcG6YuSVNdBWXWT2H8fdWzTM7Uf9VYgk7LwMT5Jb lN/yNhD40GSqW8Lu4dOg/hR/vvWkrcpWS9DfR8n9PRLGH2C9yxs1pzZDJps0kR2LQ/HRx1qW 8vTi7Frbyjqhu56xNHuUGfAlpnPMXgGuLxkA0U6pJNwC8IlHiPyxuyKAQqlUFyVp0z7Q9sHL LBto/aYZQwWuV0aOPcgvzE2Dh5rgIm/6DkbbDEePT7+P8E1TXML2fomOO91t+jdJn113BC+x g9jj85fPbyAS3lHj+YJd7CqFdiamCQc8MYID7TCCA+kCAQEwgc0wgccxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJNQTEQMA4GA1UEBxMHTWVkZm9yZDEbMBkGA1UEChMSUHJvdGVjdGVkIE5l dHdvcmtzMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxMTAvBgNVBAMTKFByb3Rl Y3RlZCBOZXR3b3JrcyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxKTAnBgkqhkiG9w0BCQEWGmlt YkBwcm90ZWN0ZWQtbmV0d29ya3MubmV0AgExMAkGBSsOAwIaBQCgggJ1MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDQwNDExNTU1MFowIwYJKoZIhvcN AQkEMRYEFM1/xaw1ciIwRgPNfNMWsj/pBNjpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIHeBgkrBgEEAYI3EAQxgdAwgc0wgccxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNQTEQ MA4GA1UEBxMHTWVkZm9yZDEbMBkGA1UEChMSUHJvdGVjdGVkIE5ldHdvcmtzMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxMTAvBgNVBAMTKFByb3RlY3RlZCBOZXR3b3JrcyBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxKTAnBgkqhkiG9w0BCQEWGmltYkBwcm90ZWN0ZWQtbmV0 d29ya3MubmV0AgExMIHgBgsqhkiG9w0BCRACCzGB0KCBzTCBxzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAk1BMRAwDgYDVQQHEwdNZWRmb3JkMRswGQYDVQQKExJQcm90ZWN0ZWQgTmV0d29y a3MxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTExMC8GA1UEAxMoUHJvdGVjdGVk IE5ldHdvcmtzIENlcnRpZmljYXRlIEF1dGhvcml0eTEpMCcGCSqGSIb3DQEJARYaaW1iQHBy b3RlY3RlZC1uZXR3b3Jrcy5uZXQCATEwDQYJKoZIhvcNAQEBBQAEgYAYHAZXKkUiu3e78CH7 y1HsrxIqDKLweZEbbqT8yiYfjICefCCJFebdqY8US5fy0zR7YBmL42vMCo7BJKvGt9b07Slr ZZz8SAa9uZZ6809Spj5Xzunu6TEJnCnwvKSZQnbavV6Vbqt2lywYi9IGGTHp+HnKnCzwfYeR j9cRKDLsJwAAAAAAAA== --------------ms030900080501040703080208-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 03:36:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F73A16A400; Mon, 3 Apr 2006 03:36:08 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8512943D55; Mon, 3 Apr 2006 03:36:06 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 920D4824479; Mon, 3 Apr 2006 00:36:05 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11481-08; Mon, 3 Apr 2006 00:36:05 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id 1E9E2823E22; Mon, 3 Apr 2006 00:36:05 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 353DE3AF85; Mon, 3 Apr 2006 00:36:04 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 341C53A959; Mon, 3 Apr 2006 00:36:04 -0300 (ADT) Date: Mon, 3 Apr 2006 00:36:04 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20060403003318.K947@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org X-Mailman-Approved-At: Wed, 05 Apr 2006 12:18:49 +0000 Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org Subject: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2006 03:36:08 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471 [kernel] [patch] new feature: private IPC for every jail Its an ancient, 4.x patch for having private IPC in a jail ... not sure how hard it would be to bring it up to 6.x / -current standards though ... but it seems like something 'good' that is needed ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 12:32:50 2006 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 0EE8D16A422 for ; Wed, 5 Apr 2006 12:32:50 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA3043D45 for ; Wed, 5 Apr 2006 12:32:48 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k35CWm0O005148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Apr 2006 08:32:48 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k35CWgpg095415; Wed, 5 Apr 2006 08:32:42 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17459.47338.830306.784833@grasshopper.cs.duke.edu> Date: Wed, 5 Apr 2006 08:32:42 -0400 (EDT) To: Mike Jakubik In-Reply-To: <4432EB19.5050501@rogers.com> References: <44318FD2.1050206@rogers.com> <17458.35872.175979.759077@grasshopper.cs.duke.edu> <4432EB19.5050501@rogers.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org Subject: Re: Broadcom ServerWorks HT-1000 support in OpenBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 12:32:50 -0000 Mike Jakubik writes: > Andrew Gallatin wrote: > > Mike Jakubik writes: > > > It seems like OpenBSD 3.9 has support for the HT-1000 IDE/SATA chipset, > > > and we are still missing it. Is there any way to port their code over? > > > There are a few nice motherboards out there that use this chipset (most > > > amd server boards use the crappy nvidia chipset and the accompanying > > > crappy network card). > > > > Why do you call the Nvida chipset "crappy"? I assume you don't care > > about the PCI Express bandwidth of the accompanying "northbridge"? > > > > From a performance standpoint, the Nvida chipset is far from crappy, > > and can easily sustain 10GbE speeds for both send and receive, as well > > as send+receive at the same time. Our lab tests have shown well over > > 18Gb/s for send+receive using our PCI-e x8 10GbE card in an Nvidia > > CK804 based opteron. > > > > For any application which is moving a lot of data using PCI-e cards on > > an opteron, I would strongly recommend Nvidia based servers. > > > > None of that matters if the system is unreliable, and what you are > boasting here is just the speed of a PCIe bus. See the mailing lists for Not only is the nvida PCIe bus faster, it is more reliable as well. This may be the fault of various motherboard vendor's implementations, > the numerous problems associated with this chipset and the network card. Then FreeBSD needs to use a decent driver for the network card. How about bringing in the OpenBSD if_nfe driver? I have had zero problems with any Nvidia based machine (aside from early problems with FreeBSD's buggy if_nve ethernet driver). We currently have in excess of 40 nforce 4 based servers and desktops, all of which work perfectly with Linux and Solaris. Even FreeBSD has behaved OK for me for the last few months since the fix that got the if_nve ethernet driver to work at all. The buggiest machines I have seen have been HT2000/HT1000 based. Drew From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 12:55:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D864C16A422; Wed, 5 Apr 2006 12:55:14 +0000 (UTC) (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 BA1A043D79; Wed, 5 Apr 2006 12:55:11 +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 5703E200126; Wed, 5 Apr 2006 14:55:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 1510920013A; Wed, 5 Apr 2006 14:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id EE857444F41; Wed, 5 Apr 2006 12:53:16 +0000 (UTC) Date: Wed, 5 Apr 2006 12:53:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kazuaki Oda In-Reply-To: <4433B014.9040004@highway.ne.jp> Message-ID: <20060405125247.I76259@maildrop.int.zabbadoz.net> References: <4433B014.9040004@highway.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: lock order reversal: tcp_input.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: Wed, 05 Apr 2006 12:55:15 -0000 On Wed, 5 Apr 2006, Kazuaki Oda wrote: Hi, > I re-cvsup'ed and rebuilt kernel again, and I got the following: > > lock order reversal: > 1st 0xc493bb10 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:743 > 2nd 0xc09bdb8c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:616 I added it to "the LOR page" with ID #182: http://sources.zabbadoz.net/freebsd/lor.html#182 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 13:46:31 2006 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 5FB6316A420 for ; Wed, 5 Apr 2006 13:46:31 +0000 (UTC) (envelope-from dpz@ack.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [128.32.206.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6C9E43D4C for ; Wed, 5 Apr 2006 13:46:30 +0000 (GMT) (envelope-from dpz@ack.berkeley.edu) Received: from [10.0.1.4] (adsl-63-193-25-74.dsl.snfc21.pacbell.net [63.193.25.74]) (authenticated bits=0) by malcolm.berkeley.edu (8.13.6/8.13.3) with ESMTP id k35DkUfJ023425 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 06:46:30 -0700 (PDT) (envelope-from dpz@ack.berkeley.edu) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Paul Zimmerman Date: Wed, 5 Apr 2006 06:46:29 -0700 To: "Pawel Worach" X-Mailer: Apple Mail (2.623) X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (malcolm.berkeley.edu [128.32.206.239]); Wed, 05 Apr 2006 06:46:30 -0700 (PDT) Cc: current@freebsd.org Subject: Re: mpt(4) mirror 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: Wed, 05 Apr 2006 13:46:31 -0000 I noticed a similar thing on my Sun X4100 (LSI1064) after csup'ing yesterday. I'll be rolling back to my Mar 10 snapshot kernel when I get into work. dp On Apr 4, 2006, at 11:54 AM, Pawel Worach wrote: > Hi, > > After the recent changes to mpt(4) it seems the driver has some isses > with the mirroring configuration (two . This is on a IBM x345 server > with a kernel from today. > > kernel messages: > mpt0: port 0x2600-0x26ff mem > 0xf7ff0000-0xf7fffff > f,0xf7fe0000-0xf7feffff irq 27 at device 7.0 on pci8 > mpt0: [GIANT-LOCKED] > mpt0: MPI Version=1.2.15.0 > mpt0: Capabilities: ( RAID-1 SAFTE ) > mpt0: 1 Active Volume (1 Max) > mpt0: 2 Hidden Drive Members (6 Max) > mpt1: port 0x2700-0x27ff mem > 0xf7fd0000-0xf7fdfff > f,0xf7fc0000-0xf7fcffff irq 28 at device 7.1 on pci8 > mpt1: [GIANT-LOCKED] > mpt1: MPI Version=1.2.15.0 > mpt1: Capabilities: ( RAID-1 SAFTE ) > mpt1: 0 Active Volumes (0 Max) > mpt1: 0 Hidden Drive Members (0 Max) > ... > mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) > mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 > mpt0:vol0(mpt0:0:0): 2 Members: > (mpt0:0:0): Primary > (mpt0:0:1): Secondary > mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) > (mpt0:vol0:0): Online > (mpt0:vol0:1): Physical (mpt0:0:1), Pass-thru (mpt0:1:1) > (mpt0:vol0:1): Online > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: mpt_cam_event: 0xb > (mpt0:vol0:0): Physical Disk Status Changed > mpt0: mpt_cam_event: 0xb > (mpt0:vol0:0): Volume Status Changed > mpt0: mpt_cam_event: 0xb > (mpt0:vol0:0): Physical Disk Status Changed > mpt0: IOC Bus Reset Port: 0 > mpt0: mpt_write_cfg_page: Config Info Status 2 > mpt0: mpt_setwidth: write cur page failed > mpt0: Set width Failed! > mpt0: IOC Bus Reset Port: 0 > mpt0: mpt_read_cfg_page: Config Info Status 2 > mpt0: mpt_setwidth: read cur page failed > mpt0: Set width Failed! > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0:vol0(mpt0:0:0): RAID-1 - Degraded > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:0): No longer configured > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: mpt_read_cfg_page: Config Info Status 2 > mpt0: cannot get target 1 DP0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > mpt0: IOC Bus Reset Port: 0 > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 3.300MB/s transfers, Tagged Queueing Enabled > da0: 34710MB (71087625 512 byte sectors: 255H 63S/T 4425C) > Trying to mount root from ufs:/dev/da0s1a > > Booting an older kernel from around Mar. 25 works fine. Anything else > I can dig out? > > -- > Pawel > _______________________________________________ > 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 Apr 5 13:47:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A5F816A41F; Wed, 5 Apr 2006 13:47:01 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9557143D48; Wed, 5 Apr 2006 13:47:00 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.101] (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 75563244C19; Wed, 5 Apr 2006 22:46:59 +0900 (JST) Message-ID: <4433CA53.5050000@freebsd.org> Date: Wed, 05 Apr 2006 22:46:59 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5 (X11/20060404) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> In-Reply-To: <4417DD8D.3050201@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander@Leidinger.net, Daichi GOTO , Dario Freni , ozawa@ongs.co.jp Subject: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 13:47:01 -0000 It is my pleasure and honor to announce the availability of the unionfs patchset-10. Patchset-10: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff Changes in unionfs-p10.diff - Fixed a problem that does not unlock a vnode around some treatments of VOP_RENAME. - Added workaround implementation for panic by umount(8) -f. - Changed around VOP_ADVLOCK treatments to make shadow file into upper layer always to keep lock consistency. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Attentions: We are getting union_getwritemount rewrite work still now. The p-10 is intermediate step implementation, and some code in not according to style(9) source code style. I want to get active unionfs patchset users to test it. If you want stable implementation, please wait until p-11. However, of course, p-10 is stable rather than p-9 already :) Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 14:03:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D19F116A420; Wed, 5 Apr 2006 14:03:04 +0000 (UTC) (envelope-from bln@deprese.net) Received: from hades.deprese.net (hades.deprese.net [81.2.209.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E67243D77; Wed, 5 Apr 2006 14:03:04 +0000 (GMT) (envelope-from bln@deprese.net) Received: from [147.32.98.167] (traveler.hk.cvut.cz [147.32.98.167]) by hades.deprese.net (Postfix) with ESMTP id B287433C1F; Wed, 5 Apr 2006 16:03:02 +0200 (CEST) Message-ID: <4433CE0E.7000809@deprese.net> Date: Wed, 05 Apr 2006 16:02:54 +0200 From: Ondra Holecek User-Agent: Thunderbird 1.5 (X11/20060213) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: sunix rs-232 pcmcia card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 14:03:04 -0000 hello, i have this pcmcia card with two rs-232 connectors - http://www.sunix.com.tw/ipc/sunix_en/detail.php?class_a=16&prod_id=57#spec it is sunix CBS2000X with Oxford CF950 UART (16C950 compatible) host controller. but it doesn't seem to work with fbsd, i have added this record do pucdata.c { "Sunix CBS2000X", { 0x1409, 0x7168, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ }, }, }, using also this instead of COM_FREQ COM_FREQ * 8 33000000 / 2 but the only result is that system shows that ports as sio4 and sio5, but when i try to open these device the system freeze and must be restarted. the same result with editing sio_pci.c does anybody else use it? i'm prepared to provide any additional information. -- after inserting card into slot: cardbus0: Resource not specified in CIS: id=10, size=20 puc0: port 0x1000-0x101f irq 10 at device 0.0 on cardbus0 sio4: on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode thx in advance Ondra Holecek From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 14:09:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE5E516A400 for ; Wed, 5 Apr 2006 14:09:51 +0000 (UTC) (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 960A143D48 for ; Wed, 5 Apr 2006 14:09:50 +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 k35E9nQ2017127 for ; Wed, 5 Apr 2006 09:09:49 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4433CFA1.90509@centtech.com> Date: Wed, 05 Apr 2006 09:09:37 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) 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: ClamAV 0.87.1/1376/Wed Apr 5 00:51:25 2006 on mh2.centtech.com X-Virus-Status: Clean Subject: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 14:09:51 -0000 Is this what is needed to get it booting FreeBSD? http://www.apple.com/macosx/bootcamp/ Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 14:27:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 381EE16A41F; Wed, 5 Apr 2006 14:27:26 +0000 (UTC) (envelope-from rabe@p-i-n.com) Received: from aposerv.p-i-n.com (aposerv.p-i-n.com [145.253.185.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5EFC43D60; Wed, 5 Apr 2006 14:27:24 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from p-i-n.com (inside.p-i-n.com [129.10.9.21]) by aposerv.p-i-n.com (8.12.11/8.12.11) with ESMTP id k35ERKZ1023609; Wed, 5 Apr 2006 16:27:20 +0200 (CEST) (envelope-from rabe@p-i-n.com) Received: (from rabe@localhost) by p-i-n.com (8.11.6/8.11.6) id k35ERF587557; Wed, 5 Apr 2006 16:27:15 +0200 (CEST) (envelope-from rabe) Date: Wed, 5 Apr 2006 16:27:15 +0200 From: "Raphael H. Becker" To: John Baldwin Message-ID: <20060405162714.L60206@p-i-n.com> References: <20060327093503.G60206@p-i-n.com> <20060329180704.I60206@p-i-n.com> <20060329183259.J60206@p-i-n.com> <200603291154.18847.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200603291154.18847.jhb@freebsd.org>; from jhb@freebsd.org on Wed, Mar 29, 2006 at 11:54:17AM -0500 Organization: PHOENIX Pharmahandel AG & Co KG, Mannheim, Deutschland Cc: freebsd-current@freebsd.org Subject: Re: devfs ruleset 4 (jails) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 14:27:26 -0000 On Wed, Mar 29, 2006 at 11:54:17AM -0500, John Baldwin wrote: > On Wednesday 29 March 2006 11:32, Raphael H. Becker wrote: > > On Wed, Mar 29, 2006 at 06:07:05PM +0200, Raphael H. Becker wrote: > > > PS: the box crashed just while writing this (while using devfs > > > ) so I'll need to powercycle it before leaving my office. > > crash: [...] > > I don't know much about the debugger, so I just resetted the box by > > typing "reset" at the prompt. > > Hope that helps a little. > Well, it means that it's broken in HEAD as well at least. Is there a workaround to hide "critical" devices from a mounted devfs? ... any patches to test? >From my point of view this is a critical situation for machines with jails and "foreign" roots in them while I (host admin) cannot hide disk devices (and other critical stuff) from the jails. Regrads Raphael Becker From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 15:06:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57DB616A401 for ; Wed, 5 Apr 2006 15:06:31 +0000 (UTC) (envelope-from zach@webges.com) Received: from mail.webges.com (mail.webges.com [195.128.164.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C9D43D5C for ; Wed, 5 Apr 2006 15:06:30 +0000 (GMT) (envelope-from zach@webges.com) Received: from localhost (localhost [127.0.0.1]) by mail.webges.com (Postfix) with ESMTP id 03B0315204AB for ; Wed, 5 Apr 2006 17:06:30 +0200 (CEST) Received: from [192.168.0.167] (webges-office [86.59.10.162]) by mail.webges.com (Postfix) with ESMTP id DED0F1520496 for ; Wed, 5 Apr 2006 17:06:29 +0200 (CEST) Message-ID: <4433DCF6.8060802@webges.com> Date: Wed, 05 Apr 2006 17:06:30 +0200 From: Michael Zach User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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: by amavisd-new-20030616-p10 (Debian) at mail.webges.com Subject: make buildworld error with current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 15:06:31 -0000 Hi, when trying to make a buildworld with the current cvs snapshot I get an error in /usr/src/lib/libc (regardless of multi-user / single-user). What I've tried so far is: -) CPUTYPE?=athlon in make.conf -) provide a TARGET_ARCH=i386 when calling make buildworld -) go to single-user & run the above steps -) even did not work out in multiuser The error in question is (which occurs after a warning): /usr/src/lib/libc/stdlib/malloc.c: In function `arena_run_reg_alloc': /usr/src/lib/libc/stdlib/malloc.c:1540: warning: control reaches end of a non-void function *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. If needed a script-snippet is available. Actually I'm running out of ideas what could raise the error since line 1540 in malloc.c is an "assert(0);" ... Thank you in advance, Michael From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 15:22:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AEC916A42C for ; Wed, 5 Apr 2006 15:22:00 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51E2443D64 for ; Wed, 5 Apr 2006 15:21:52 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id B1B0CD45721 for ; Wed, 5 Apr 2006 11:21:51 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 11:21:42 -0400 X-Sasl-enc: Pt5kdFaM8ZFbcXo5C2xW5yt2AaslpZ1pAh0El1ClDflT 1144250501 Received: from [192.168.188.108] (unknown [12.109.9.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id DD9A36CB for ; Wed, 5 Apr 2006 11:21:41 -0400 (EDT) Message-ID: <4433E08A.3010802@fastmail.fm> Date: Wed, 05 Apr 2006 10:21:46 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------010108060903080607010901" Subject: Interrupt storm on IRQ11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 15:22:00 -0000 This is a multi-part message in MIME format. --------------010108060903080607010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List; I get the following on boot in -current; Interrupt storm detected on "irq11:"; throttling interrupt source If I have my atheros card in the laptop (Dell C600) during boot I can then do "kldload if_ath" and I'm good to go. If I plug the card in anytime *after* I get to the login prompt it's non-functional. When the card is in the slot at boot, and after I "kldload if_ath" I see; ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus1 ath0: Ethernet address: 00:13:46:b6:19:ea ath0: mac 7.8 phy 4.5 radio 5.6 If I plug the card in later all I see is; ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) I'm wondering if this is related to RM's recent commits. (full dmesg attached). Thanks, Patrick --------------010108060903080607010901 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2006 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 #1: Sat Apr 1 21:34:55 CST 2006 pbowen@sg1.sgc.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. 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 = 515604480 (491 MB) kbd1 at kbdmux0 npx0: [FAST] 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 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xecff mem 0xf8000000-0xfbffffff,0xfdffc000-0xfdffffff irq 11 at device 0.0 on pci1 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 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 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: xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffdc00-0xf3ffdc7f,0xf3ffd800-0xf3ffd87f 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 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 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 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 601367225 Hz quality 800 Timecounters tick every 1.000 msec Interrupt storm detected on "irq11:"; throttling interrupt source cardbus1: at device 0.0 (no driver attached) ad0: 19077MB at ata0-master UDMA33 acd0: CDRW at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a cpu0: too many short sleeps, backing off to C1 ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus1 ath0: Ethernet address: 00:13:46:b6:19:ea ath0: mac 7.8 phy 4.5 radio 5.6 ath0: link state changed to UP --------------010108060903080607010901-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 15:58:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A25716A400 for ; Wed, 5 Apr 2006 15:58:29 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 314A043D58 for ; Wed, 5 Apr 2006 15:58:28 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id E5AA65E4921; Wed, 5 Apr 2006 08:58:16 -0700 (PDT) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 900115E482A; Wed, 5 Apr 2006 08:58:15 -0700 (PDT) Message-ID: <4433E915.1090509@FreeBSD.org> Date: Wed, 05 Apr 2006 08:58:13 -0700 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Zach References: <4433DCF6.8060802@webges.com> In-Reply-To: <4433DCF6.8060802@webges.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.5 Cc: freebsd-current@freebsd.org Subject: Re: make buildworld error with current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 15:58:29 -0000 Michael Zach wrote: > Hi, > > when trying to make a buildworld with the current cvs snapshot I get an > error in /usr/src/lib/libc (regardless of multi-user / single-user). > What I've tried so far is: > > -) CPUTYPE?=athlon in make.conf > -) provide a TARGET_ARCH=i386 when calling make buildworld > -) go to single-user & run the above steps > -) even did not work out in multiuser > > The error in question is (which occurs after a warning): > > /usr/src/lib/libc/stdlib/malloc.c: In function `arena_run_reg_alloc': > /usr/src/lib/libc/stdlib/malloc.c:1540: warning: control reaches end of > a non-void function > *** Error code 1 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > If needed a script-snippet is available. Actually I'm running out of > ideas what could raise the error since line 1540 in malloc.c is an > "assert(0);" ... Do you have non-standard compiler flags set? I don't see this warning. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 16:00:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E6FB16A425; Wed, 5 Apr 2006 16:00:42 +0000 (UTC) (envelope-from zach@webges.com) Received: from mail.webges.com (mail.webges.com [195.128.164.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0C1E43D77; Wed, 5 Apr 2006 16:00:32 +0000 (GMT) (envelope-from zach@webges.com) Received: from localhost (localhost [127.0.0.1]) by mail.webges.com (Postfix) with ESMTP id AD08815204AE; Wed, 5 Apr 2006 18:00:31 +0200 (CEST) Received: from [192.168.0.167] (webges-office [86.59.10.162]) by mail.webges.com (Postfix) with ESMTP id 6ED4615204AC; Wed, 5 Apr 2006 18:00:31 +0200 (CEST) Message-ID: <4433E99D.1080602@webges.com> Date: Wed, 05 Apr 2006 18:00:29 +0200 From: Michael Zach User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <4433DCF6.8060802@webges.com> <4433E915.1090509@FreeBSD.org> In-Reply-To: <4433E915.1090509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mail.webges.com Cc: freebsd-current@freebsd.org Subject: Re: make buildworld error with current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 16:00:42 -0000 I've CFLAGS= -O -pipe in make.conf, but trying it currently without them, we'll see how it works out. Thanks, Michael Jason Evans wrote: > Michael Zach wrote: > >> Hi, >> >> when trying to make a buildworld with the current cvs snapshot I get >> an error in /usr/src/lib/libc (regardless of multi-user / >> single-user). What I've tried so far is: >> >> -) CPUTYPE?=athlon in make.conf >> -) provide a TARGET_ARCH=i386 when calling make buildworld >> -) go to single-user & run the above steps >> -) even did not work out in multiuser >> >> The error in question is (which occurs after a warning): >> >> /usr/src/lib/libc/stdlib/malloc.c: In function `arena_run_reg_alloc': >> /usr/src/lib/libc/stdlib/malloc.c:1540: warning: control reaches end >> of a non-void function >> *** Error code 1 >> >> Stop in /usr/src/lib/libc. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> If needed a script-snippet is available. Actually I'm running out of >> ideas what could raise the error since line 1540 in malloc.c is an >> "assert(0);" ... > > > Do you have non-standard compiler flags set? I don't see this warning. > > Thanks, > Jason From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 16:08:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA8516A41F for ; Wed, 5 Apr 2006 16:08:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25DD743D6E for ; Wed, 5 Apr 2006 16:08:22 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6520E46BC9; Wed, 5 Apr 2006 12:08:21 -0400 (EDT) Date: Wed, 5 Apr 2006 17:08:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kazuaki Oda In-Reply-To: <44333063.70606@highway.ne.jp> Message-ID: <20060405170737.P82516@fledge.watson.org> References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> <20060404141813.H22854@fledge.watson.org> <44333063.70606@highway.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 16:08:23 -0000 On Wed, 5 Apr 2006, Kazuaki Oda wrote: > Is more information required? Could you try the attached patch? Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.296 diff -u -r1.296 tcp_input.c --- tcp_input.c 5 Apr 2006 08:45:59 -0000 1.296 +++ tcp_input.c 5 Apr 2006 16:07:23 -0000 @@ -173,7 +173,7 @@ struct mbuf *); static void tcp_xmit_timer(struct tcpcb *, int); static void tcp_newreno_partial_ack(struct tcpcb *, struct tcphdr *); -static int tcp_timewait(struct tcptw *, struct tcpopt *, +static int tcp_timewait(struct inpcb *, struct tcpopt *, struct tcphdr *, struct mbuf *, int); /* Neighbor Discovery, Neighbor Unreachability Detection Upper layer hint. */ @@ -760,7 +760,7 @@ */ if (thflags & TH_SYN) tcp_dooptions(&to, optp, optlen, 1); - if (tcp_timewait(intotw(inp), &to, th, m, tlen)) + if (tcp_timewait(inp, &to, th, m, tlen)) goto findpcb; /* * tcp_timewait unlocks inp. @@ -3141,13 +3141,14 @@ * looking for a pcb in the listen state. Returns 0 otherwise. */ static int -tcp_timewait(tw, to, th, m, tlen) - struct tcptw *tw; +tcp_timewait(inp, to, th, m, tlen) + struct inpcb *inp; struct tcpopt *to; struct tcphdr *th; struct mbuf *m; int tlen; { + struct tcptw *tw; int thflags; tcp_seq seq; #ifdef INET6 @@ -3156,19 +3157,20 @@ const int isipv6 = 0; #endif + /* tcbinfo lock required for tcp_twclose(), tcp_2msl_reset. */ + INP_INFO_WLOCK_ASSERT(&tcbinfo); + INP_LOCK_ASSERT(inp); + /* * XXXRW: Time wait state for inpcb has been recycled, but inpcb is * still present. This is undesirable, but temporarily necessary * until we work out how to handle inpcb's who's timewait state has * been removed. */ + tw = intotw(inp); if (tw == NULL) goto drop; - /* tcbinfo lock required for tcp_twclose(), tcp_2msl_reset. */ - INP_INFO_WLOCK_ASSERT(&tcbinfo); - INP_LOCK_ASSERT(tw->tw_inpcb); - thflags = th->th_flags; /* @@ -3268,12 +3270,11 @@ tcp_respond(NULL, mtod(m, void *), th, m, seq, 0, TH_RST|TH_ACK); } - INP_UNLOCK(tw->tw_inpcb); + INP_UNLOCK(inp); return (0); drop: - if (tw != NULL) - INP_UNLOCK(tw->tw_inpcb); + INP_UNLOCK(inp); m_freem(m); return (0); } From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 16:47:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7330516A400 for ; Wed, 5 Apr 2006 16:47:40 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB16B43D46 for ; Wed, 5 Apr 2006 16:47:39 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i34so77622wra for ; Wed, 05 Apr 2006 09:47:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UiYewRTbFgQhcAQ2rvhx9OrXZ+N2JAAkixz5wbRPiUuc8SDDjZVjAYVyVQPPRf6udB3gHGaTDJA0kGS+I2NAQOXeVqjFtqqALQwM5Va7pMieIrdlWyTsz0mQZBQroxSf9XGzn/c2gBnbqWknPh2WxQK7YY7UhOibopXayt0KeVI= Received: by 10.65.107.6 with SMTP id j6mr2022317qbm; Wed, 05 Apr 2006 09:47:39 -0700 (PDT) Received: by 10.65.155.4 with HTTP; Wed, 5 Apr 2006 09:47:39 -0700 (PDT) Message-ID: <7579f7fb0604050947l6b0fdfdamcbc7507102617eff@mail.gmail.com> Date: Wed, 5 Apr 2006 09:47:39 -0700 From: "Matthew Jacob" To: Ganbold In-Reply-To: <443381F9.3010504@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4431D4E5.3080507@micom.mng.net> <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 16:47:40 -0000 > mpt0: Unhandled Event Notify Frame. Event 0x30. > mpt1: Unhandled Event Notify Frame. Event 0x30. Ignore. From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 17:38:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D32FC16A400; Wed, 5 Apr 2006 17:38:05 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 718C143D53; Wed, 5 Apr 2006 17:38:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5B76E1A4DD4; Wed, 5 Apr 2006 10:38:04 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 52959517D2; Wed, 5 Apr 2006 13:38:03 -0400 (EDT) Date: Wed, 5 Apr 2006 13:38:03 -0400 From: Kris Kennaway To: Daichi GOTO Message-ID: <20060405173802.GA25588@xor.obsecurity.org> References: <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> <4433CA53.5050000@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <4433CA53.5050000@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: ozawa@ongs.co.jp, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Alexander@Leidinger.net, Dario Freni Subject: Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 17:38:06 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2006 at 10:46:59PM +0900, Daichi GOTO wrote: > It is my pleasure and honor to announce the availability of > the unionfs patchset-10. >=20 > Patchset-10: > For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff >=20 > For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff Thanks for your continued work! I get this panic with mount_unionfs -b: kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at kdb_backtrac= e+0x29 vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11 assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at assert_vop_locked= +0x4a VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2 VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip =3D 0x280d3dfb, esp =3D 0xbfbf= e35c, ebp =3D 0xbfbfe808 --- VOP_OPEN: 0xc72d7000 is not locked but should be Kris --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFENAB6Wry0BWjoQKURAgcQAJ4jGv1QxWUns/csWDZlApWTW9tY+gCgzXke adNivNKI4bAZSE7ixOAfnQY= =uuQM -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 17:51:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C41416A401 for ; Wed, 5 Apr 2006 17:51:15 +0000 (UTC) (envelope-from harikurniawan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB6443D5A for ; Wed, 5 Apr 2006 17:51:12 +0000 (GMT) (envelope-from harikurniawan@gmail.com) Received: by wproxy.gmail.com with SMTP id i34so91096wra for ; Wed, 05 Apr 2006 10:51:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=q1UgD+kb6tSBw9ssMM8ffleNfYz4w0SwRN4ZN1WNpr/hRGAJ6jn6DWA/L0yeRKYm7/4TbfVVhXY55qgnEXfA1EiXN8xBJgE45VuhjJmiYeMaO2sRPlDDhW8kj2MlAf/yYfDixUMUeoQYpCPdluA/NV5rhYpwdumYhUSK3VQu4LU= Received: by 10.64.243.14 with SMTP id q14mr2051675qbh; Wed, 05 Apr 2006 10:44:58 -0700 (PDT) Received: by 10.64.201.6 with HTTP; Wed, 5 Apr 2006 10:44:58 -0700 (PDT) Message-ID: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> Date: Wed, 5 Apr 2006 17:44:58 +0000 From: "Angka H. K." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Make distribution 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: Wed, 05 Apr 2006 17:51:15 -0000 Dear all, Why does below error always appear when I type "make distribution" in CURRENT source from existing 6.1-PRERELEASE "/tmp/hd/usr/src/etc/Makefile", line 59: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 60: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 62: Malformed conditional (${MK_BIND_ETC} !=3D "no") "/tmp/hd/usr/src/etc/Makefile", line 65: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 69: Malformed conditional (${MK_SENDMAIL} =3D=3D "no") "/tmp/hd/usr/src/etc/Makefile", line 71: if-less else "/tmp/hd/usr/src/etc/Makefile", line 74: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 80: Malformed conditional (${MK_MAN} != =3D "no") "/tmp/hd/usr/src/etc/Makefile", line 82: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 130: Malformed conditional (${MK_I4B} !=3D "no") "/tmp/hd/usr/src/etc/Makefile", line 132: if-less endif "/tmp/hd/usr/src/etc/Makefile", line 133: Malformed conditional (${MK_SENDMAIL} !=3D "no" From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:07:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63C9A16A400; Wed, 5 Apr 2006 18:07:12 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1362F43D5F; Wed, 5 Apr 2006 18:07:11 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1FRCPO-0005iA-Fw; Thu, 06 Apr 2006 03:07:10 +0900 Message-ID: <443405A4.40906@highway.ne.jp> Date: Thu, 06 Apr 2006 03:00:04 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <4430FAAF.2040809@highway.ne.jp> <20060403133210.U36756@fledge.watson.org> <44311AB5.2010407@highway.ne.jp> <20060404141813.H22854@fledge.watson.org> <44333063.70606@highway.ne.jp> <20060405170737.P82516@fledge.watson.org> In-Reply-To: <20060405170737.P82516@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic: page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 18:07:12 -0000 Robert Watson wrote: > > On Wed, 5 Apr 2006, Kazuaki Oda wrote: > >> Is more information required? > > > Could you try the attached patch? I've tried. The patch has fixed the problems I had ever got. No kernel panics and no lock order reversals at all. Thanks, -- Kazuaki Oda From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:12:43 2006 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 5751816A401 for ; Wed, 5 Apr 2006 18:12:43 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3800243D58 for ; Wed, 5 Apr 2006 18:12:38 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by zproxy.gmail.com with SMTP id n1so5305nzf for ; Wed, 05 Apr 2006 11:12:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=PUt+8/hY08OQDoXDfMVpq3CpxOrvnzuIhdposudJwUmbcTXHYqMxptRgFDZvCAL8SB072Q83KIFuIe7ik1IIMStKEJ/T3o3cchO6g+OYGMU2d4GHALsHmFl53NYAlfewjJcxcNfwKlTSR/Q9HIHNNqlINwCPd/rjOgCzOhaoqrc= Received: by 10.36.157.10 with SMTP id f10mr2283917nze; Wed, 05 Apr 2006 11:12:37 -0700 (PDT) Received: by 10.36.75.9 with HTTP; Wed, 5 Apr 2006 11:12:37 -0700 (PDT) Message-ID: <47d0403c0604051112wf30426bt2c3a7c9b2909c8c1@mail.gmail.com> Date: Wed, 5 Apr 2006 18:12:37 +0000 From: "Ben Kaduk" To: "Nate Lawson" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: current@freebsd.org Subject: Re: acpi: bad write: (was: Re: My snd_ich working well) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 18:12:43 -0000 On 4/4/06, Nate Lawson wrote: > Angka H. K. wrote: > > Thanks for the replay > > I am updating my source now and planing to rebuild it again, but I don'= t see > > any changes on ACPI code. > > > > I was mistype on the val that return by kernel, the error should be "ac= pi: > > bad write to port 0x073(8) val 20", I am sorry. > > Hope it'll be fixed soon. > > > > FYI : I am using HP V2388TU with current source. The error is produced = by > > source updated at 2 April 2006 > > > > > > On 4/3/06, Alexander Leidinger wrote: > >> "Angka H. K." wrote: > >> > >> Please strip freebsd-multimedia@ on reply... > >> > >>> I have other problem now , which is saying "acpi: bad read to port > >> 0x073" > >>> and "acpi: bad write to port 0x073(8) val 82", where can ask about th= is > >> ? It > >>> looks like google has no archive about this error. > >> I assume you are using -current. So the right place is to ask on curre= nt@ > >> (CCed). I also CCed njl@, since he's our "master of acpi". > > This error message is only a warning currently. Are you sure it's 0x73? > That's not on the blacklist. We note reads/writes to 0x70 - 0x71 and > 0x74 - 0x76. Those are the CMOS and RTC areas and AML shouldn't write > there. > > /* > * Some BIOS vendors use AML to read/write directly to IO space. This > * can cause a problem if such accesses interfere with the OS's access t= o > * the same ports. Windows XP and newer systems block accesses to certa= in > * IO ports. We print a message or block accesses based on a tunable. > */ > static int illegal_bios_ports[] =3D { > 0x000, 0x00f, /* DMA controller 1 */ > 0x020, 0x021, /* PIC */ > 0x040, 0x043, /* Timer 1 */ > 0x048, 0x04b, /* Timer 2 failsafe */ > 0x070, 0x071, /* CMOS and RTC */ > 0x074, 0x076, /* Extended CMOS */ > 0x081, 0x083, /* DMA1 page registers */ > 0x087, 0x087, /* DMA1 ch0 low page */ > 0x089, 0x08b, /* DMA2 ch2 (0x89), ch3 low page (0x8a, 0x8b) */ > 0x08f, 0x091, /* DMA2 low page refresh (0x8f) */ > /* Arb ctrl port, card select feedback (0x90, 0x9= 1) */ > 0x093, 0x094, /* System board setup */ > 0x096, 0x097, /* POS channel select */ > 0x0a0, 0x0a1, /* PIC (cascaded) */ > 0x0c0, 0x0df, /* ISA DMA */ > 0x4d0, 0x4d1, /* PIC ELCR (edge/level control) */ > 0xcf8, 0xcff, /* PCI config space. Microsoft adds 0xd00 also bu= t > that seems incorrect. */ > -1, -1 > }; > Hi Nate, As posted earlier, I'm getting these acpi: bad write messages spamming my console, with port 0x086 instead of Angka's 0x073. I don't see 0x086 in the above list, though, so I'm a bit confused. I have revision 1.120 of src/sys/dev/acpica/Osd/OsdHardware.c As detailed here: http://lists.freebsd.org/pipermail/freebsd-current/2006-April/062245.html this appeared somewhere between 29 january and 3 april. Any thoughts? Am I completely missing where this is coming from? -Ben Kaduk > In the future, this warning will become an error and the access will be > rejected. That's to prevent bad AML from conflicting with drivers and > hanging or crashing the system. Your system has always had this > behavior, we're just detecting it now. > > -- > Nate > _______________________________________________ > 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 Apr 5 18:14:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C8B16A424 for ; Wed, 5 Apr 2006 18:14:52 +0000 (UTC) (envelope-from zach@webges.com) Received: from mail.webges.com (mail.webges.com [195.128.164.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5DEE43D5A for ; Wed, 5 Apr 2006 18:14:51 +0000 (GMT) (envelope-from zach@webges.com) Received: from localhost (localhost [127.0.0.1]) by mail.webges.com (Postfix) with ESMTP id 2F28D15204B1 for ; Wed, 5 Apr 2006 20:14:50 +0200 (CEST) Received: from webmail.webges.com (rs3 [192.168.9.182]) by mail.webges.com (Postfix) with ESMTP id 0FDB6152047D for ; Wed, 5 Apr 2006 20:14:50 +0200 (CEST) Received: from 62.178.112.107 (SquirrelMail authenticated user zach_webges) by webmail.webges.com with HTTP; Wed, 5 Apr 2006 20:14:49 +0200 (CEST) Message-ID: <1425.62.178.112.107.1144260889.squirrel@webmail.webges.com> Date: Wed, 5 Apr 2006 20:14:49 +0200 (CEST) From: "Michael Zach" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mail.webges.com Subject: another make buildworld error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zach@webges.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 18:14:52 -0000 hi, another error occured. thanks jason for the tip, changing CFLAGS in make.conf actually helped, but during the build process another error occured: [snip] ... magic, 47985: Warning offset `text' invalid magic, 47985: Warning type `text' invalid magic, 47986: Warning offset `@@' invalid magic, 47986: Warning type `@@' invalid magic, 47989: Warning type `.1.1.1.2.1' invalid magic, 47990: Warning offset `log' invalid magic, 47990: Warning type `log' invalid magic, 47991: Warning offset `@MFC: Christos Zoulas's FILE 3.33' invalid magic, 47991: Warning type `@MFC: Christos Zoulas's FILE 3.33' invalid magic, 47992: Warning offset `@' invalid magic, 47992: Warning type `@' invalid magic, 47993: Warning offset `text' invalid magic, 47993: Warning type `text' invalid magic, 47994: Warning offset `@@' invalid magic, 47994: Warning type `@@' invalid mkmagic: could not find any magic files! *** Error code 1 Stop in /usr/src/lib/libmagic. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. any ideas? there are actually only a Makefile and a config.h in libmagic, so I guess the magic file is missing at all (if it's ever been in there) From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:22:08 2006 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 0FF9516A427 for ; Wed, 5 Apr 2006 18:22:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C523343D45 for ; Wed, 5 Apr 2006 18:22:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 05 Apr 2006 11:22:08 -0700 Message-ID: <44340ACE.5020106@elischer.org> Date: Wed, 05 Apr 2006 11:22:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <443310BF.4030600@elischer.org> In-Reply-To: <443310BF.4030600@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: change to syslog to allow specifying prot to send to.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 18:22:08 -0000 Duh, that would be "port" not "prot" Julian Elischer wrote: > Does anyone think that this would be useful? > > the syslog.conf line would look like: > > > *.* @logger.mynet.com:823 > > Index: syslogd.c > =================================================================== > RCS file: /usr/local/cvsroot/freebsd/src/usr.sbin/syslogd/syslogd.c,v > retrieving revision 1.59.2.28 > diff -u -r1.59.2.28 syslogd.c > --- syslogd.c 29 Feb 2004 20:59:19 -0000 1.59.2.28 > +++ syslogd.c 5 Apr 2006 00:33:14 -0000 > @@ -168,7 +168,7 @@ > struct { > char f_hname[MAXHOSTNAMELEN]; > struct addrinfo *f_addr; > - > + u_short port; > } f_forw; /* forwarding address */ > char f_fname[MAXPATHLEN]; > struct { > @@ -1749,14 +1749,30 @@ > p++; > > switch (*p) { > + char * tp; > + char *tp2; > case '@': > - (void)strlcpy(f->f_un.f_forw.f_hname, ++p, > + /* > + * scan forward to see if there is a port defined. > + */ > + tp2 = NULL; > + tp = ++p; > + while (*tp && (*tp++ != ':')) ; > + if (*tp == ':') { > + *tp++ = '\0'; > + if (*tp) { > + tp2 = tp; > + } > + } > + > + (void)strlcpy(f->f_un.f_forw.f_hname, p, > sizeof(f->f_un.f_forw.f_hname)); > + if (tp2) *--tp = ':'; > memset(&hints, 0, sizeof(hints)); > hints.ai_family = family; > hints.ai_socktype = SOCK_DGRAM; > - error = getaddrinfo(f->f_un.f_forw.f_hname, "syslog", > &hints, > - &res); > + error = getaddrinfo(f->f_un.f_forw.f_hname, > + tp2 ? tp2: "syslog", &hints, &res); > if (error) { > logerror(gai_strerror(error)); > break; > _______________________________________________ > 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 Apr 5 18:43:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBA2516A41F for ; Wed, 5 Apr 2006 18:43:32 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49B0C43D45 for ; Wed, 5 Apr 2006 18:43:32 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so1170058wxc for ; Wed, 05 Apr 2006 11:43:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=flVl9JwzTZx1Npv/c8mHP+btH+1EBkNs7r8nXg8ucEgmlXEp6T+UtZNVxtxPI0kQsp9mOfLOL7YeHRbWc5m3VDgPkR7xrtWOoJVYnpqU9WHwnW9P1NE01sQHFkjT57EadjZ8uY4SmuipngyuvWDnrj9HGujbfF6PiORSXfbjwS4= Received: by 10.70.62.10 with SMTP id k10mr696514wxa; Wed, 05 Apr 2006 11:43:31 -0700 (PDT) Received: by 10.70.27.9 with HTTP; Wed, 5 Apr 2006 11:43:31 -0700 (PDT) Message-ID: <790a9fff0604051143q50bfc350j4e3c2060a77d2280@mail.gmail.com> Date: Wed, 5 Apr 2006 13:43:31 -0500 From: "Scot Hetzel" To: "Angka H. K." In-Reply-To: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Make distribution 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: Wed, 05 Apr 2006 18:43:33 -0000 On 4/5/06, Angka H. K. wrote: > Dear all, > > Why does below error always appear when I type "make distribution" in > CURRENT source from existing 6.1-PRERELEASE > Doing a "make distribution" from src/etc is no longer supported, because you will encounter these types of errors. These errors are ocurring because the MK_* variables are not defined in your 6.1-PRERELEASE /usr/share/mk/* files. These vaiables are defined in the src/share/mk/* files in -CURRENT. So, just do a "make distribution" from src/ instead of src/etc. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:46:41 2006 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 EBB4016A430 for ; Wed, 5 Apr 2006 18:46:40 +0000 (UTC) (envelope-from harikurniawan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7644B43D46 for ; Wed, 5 Apr 2006 18:46:38 +0000 (GMT) (envelope-from harikurniawan@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so16734nzp for ; Wed, 05 Apr 2006 11:46:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=gGbuBUnjkwlIHpHrOZEEi5tXcOwr98gnjR7Nj6Bm0PHm5DvWCRN6Z/4IW62K4xnQ0Z7JwXEAb0eROlBFqBPJCWsEmr6U0eDhUM/znqYNX8gvAqgZJtlt7K+HJySFLSud6cBvvpE2yJHieP0fskdcwHkOyALxWLFvhOBaGIuR3u8= Received: by 10.64.143.4 with SMTP id q4mr54035qbd; Wed, 05 Apr 2006 11:46:37 -0700 (PDT) Received: by 10.64.201.6 with HTTP; Wed, 5 Apr 2006 11:46:37 -0700 (PDT) Message-ID: <4c40c4e70604051146y48cc35fal1680d5121f73ab29@mail.gmail.com> Date: Wed, 5 Apr 2006 18:46:37 +0000 From: "Angka H. K." To: "Nate Lawson" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3413_6255684.1144262797216" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Leidinger , current@freebsd.org Subject: ACPI 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: Wed, 05 Apr 2006 18:46:41 -0000 ------=_Part_3413_6255684.1144262797216 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Great the error is gone now thanks. I have other question about ACPI. My dmesg showing like below and I know nothing about ACPI. What does it mean and can it be fix ? acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 On 4/4/06, Angka H. K. wrote: > > Thanks a lot, you really dedicate your time to FreeBSD > Sorry I still don't have good connection to do cvsup, may be tomorrow. > > Ah.. hard time to finish my job sorry can't help :( > > > On 4/4/06, Nate Lawson wrote: > > > Angka H. K. wrote: > > > Thanks for the replay > > > I am updating my source now and planing to rebuild it again, but I > > don't see > > > any changes on ACPI code. > > > > > > I was mistype on the val that return by kernel, the error should be > > "acpi: > > > bad write to port 0x073(8) val 20", I am sorry. > > > Hope it'll be fixed soon. > > > > Ok, I fixed the range check on ports so 0x73 should not trigger it. If > > you have some other write to a port that IS in the blacklist, you'll > > still get the warning. > > > > Ultimately, I intend to emulate what Windows does which is block all > > writes to the PIC, and block all writes on XP or newer BIOSen. > > > > -- > > Nate > > > > ------=_Part_3413_6255684.1144262797216-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:50:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 638B516A41F for ; Wed, 5 Apr 2006 18:50:53 +0000 (UTC) (envelope-from harikurniawan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E5F443D70 for ; Wed, 5 Apr 2006 18:50:42 +0000 (GMT) (envelope-from harikurniawan@gmail.com) Received: by wproxy.gmail.com with SMTP id i34so102996wra for ; Wed, 05 Apr 2006 11:50:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Y76M50sgePXbgfMdKALBQW7T9N6gULb4lxufnIVh4VVHROFDOHLG13VAktTcMD0vedWXWaT1WDPo3CTaCl5FvUbzeMhjkGqfz3Tvs2S+4hNtJ4raz5+ztTrBrVGMM2J+n/mlyxPmDbNzvSSOcMk9yNy2pcQbDcXdruz/2QlNKYM= Received: by 10.64.179.13 with SMTP id b13mr2140543qbf; Wed, 05 Apr 2006 11:50:41 -0700 (PDT) Received: by 10.64.201.6 with HTTP; Wed, 5 Apr 2006 11:50:41 -0700 (PDT) Message-ID: <4c40c4e70604051150s4d033473wbfe3ddf6e40ec281@mail.gmail.com> Date: Wed, 5 Apr 2006 18:50:41 +0000 From: "Angka H. K." To: "Scot Hetzel" In-Reply-To: <790a9fff0604051143q50bfc350j4e3c2060a77d2280@mail.gmail.com> MIME-Version: 1.0 References: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> <790a9fff0604051143q50bfc350j4e3c2060a77d2280@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Make distribution 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: Wed, 05 Apr 2006 18:50:53 -0000 Ups... But regarding to "UPDATING" on 7.0 source it still say "cd src/etc; make distribution DESTDIR=3D${CURRENT_ROOT} # if newfs'd". Should it be change ? On 4/5/06, Scot Hetzel wrote: > > On 4/5/06, Angka H. K. wrote: > > Dear all, > > > > Why does below error always appear when I type "make distribution" in > > CURRENT source from existing 6.1-PRERELEASE > > > > Doing a "make distribution" from src/etc is no longer supported, > because you will encounter these types of errors. These errors are > ocurring because the MK_* variables are not defined in your > 6.1-PRERELEASE /usr/share/mk/* files. These vaiables are defined in > the src/share/mk/* files in -CURRENT. > > So, just do a "make distribution" from src/ instead of src/etc. > > Scot > > -- > DISCLAIMER: > No electrons were mamed while sending this message. Only slightly bruised= . > From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:52:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E6616A400 for ; Wed, 5 Apr 2006 18:52:30 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5ED743D6D for ; Wed, 5 Apr 2006 18:52:27 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail01.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k35IqNKM011049 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Apr 2006 04:52:26 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k35IqNAL003027; Thu, 6 Apr 2006 04:52:23 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k35IqM28003026; Thu, 6 Apr 2006 04:52:22 +1000 (EST) (envelope-from peter) Date: Thu, 6 Apr 2006 04:52:22 +1000 From: Peter Jeremy To: Ganbold Message-ID: <20060405185221.GI699@turion.vk2pj.dyndns.org> References: <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> <20060405090326.GD699@turion.vk2pj.dyndns.org> <44338D08.3070000@micom.mng.net> <20060405102528.GE699@turion.vk2pj.dyndns.org> <4433A4A0.5060300@micom.mng.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4433A4A0.5060300@micom.mng.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT-solved, boot problem remains X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 18:52:30 -0000 On Wed, 2006-Apr-05 20:06:08 +0900, Ganbold wrote: >Sorry for the noise, it was my big fault, I was using I486_CPU instead >of I686_CPU in the config and never thought this problem might happen >because of incorrect CPU definition in the config. The Ixxx_CPU flags are used to conditionally compile CPU support code so failing to include the correct CPU type is fatal. If you'd posted the correct config file, we could have solved it much faster. >Only one problem still remains, it still can not boot without >pressing "Enter" key at the boot prompt (- sign waits forever). >I created /boot.config with -Dh, now it shows boot.config: -Dh and waits >for user to press "Enter". I presume 6.x and -current behave the same. This prompt is from the second-stage boot loader (boot2). If the problem goes away when you add '-n' to your /boot.config then your bios isn't starting the 18.2Hz timer. Otherwise, I have no idea. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 18:57:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB4EB16A420 for ; Wed, 5 Apr 2006 18:57:45 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D537343D45 for ; Wed, 5 Apr 2006 18:57:44 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so1172737wxc for ; Wed, 05 Apr 2006 11:57:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=itAJNVmxSqHy9Qv2UpAgAMAv2xtwO/TiPQZnv1rYGYcdbxnO3htAjYaSaAyZXaJk7jujXty60gUVPAnUxh7/Yv50iZ6qOaD42PGW7TTzz2As+DY8UHFL15xxkLo4cagIWAqhAzhdKbDyyUoZW3Xh4gOc9yE3UWmdATWYvyizmPY= Received: by 10.70.124.2 with SMTP id w2mr1506165wxc; Wed, 05 Apr 2006 11:57:43 -0700 (PDT) Received: by 10.70.27.9 with HTTP; Wed, 5 Apr 2006 11:57:43 -0700 (PDT) Message-ID: <790a9fff0604051157r349cf2c7q17aa17d94f2cce66@mail.gmail.com> Date: Wed, 5 Apr 2006 13:57:43 -0500 From: "Scot Hetzel" To: "Angka H. K." In-Reply-To: <4c40c4e70604051150s4d033473wbfe3ddf6e40ec281@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> <790a9fff0604051143q50bfc350j4e3c2060a77d2280@mail.gmail.com> <4c40c4e70604051150s4d033473wbfe3ddf6e40ec281@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Make distribution 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: Wed, 05 Apr 2006 18:57:45 -0000 On 4/5/06, Angka H. K. wrote: > Ups... > > But regarding to "UPDATING" on 7.0 source it still say "cd src/etc; make > distribution DESTDIR=3D${CURRENT_ROOT} # if newfs'd". Should it be change= ? > > Yes, that needs to be changed. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 19:03:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B870B16A420; Wed, 5 Apr 2006 19:03:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1183B43D45; Wed, 5 Apr 2006 19:03:28 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k35J3Q5I004923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Apr 2006 05:03:26 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k35J3QO2003101; Thu, 6 Apr 2006 05:03:26 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k35J3PKu003100; Thu, 6 Apr 2006 05:03:25 +1000 (EST) (envelope-from peter) Date: Thu, 6 Apr 2006 05:03:25 +1000 From: Peter Jeremy To: Jason Evans Message-ID: <20060405190325.GK699@turion.vk2pj.dyndns.org> References: <4433DCF6.8060802@webges.com> <4433E915.1090509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4433E915.1090509@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: Michael Zach , freebsd-current@freebsd.org Subject: Re: make buildworld error with current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 19:03:29 -0000 On Wed, 2006-Apr-05 08:58:13 -0700, Jason Evans wrote: >Michael Zach wrote: >>/usr/src/lib/libc/stdlib/malloc.c: In function `arena_run_reg_alloc': >>/usr/src/lib/libc/stdlib/malloc.c:1540: warning: control reaches end of >>a non-void function ... >>If needed a script-snippet is available. Actually I'm running out of >>ideas what could raise the error since line 1540 in malloc.c is an >>"assert(0);" ... > >Do you have non-standard compiler flags set? I don't see this warning. I get the same error with malloc.c v1.123. The compiler warning makes sense. arena_run_reg_alloc() should return a void* but ends with assert(0);. This is not safe because assert() can be compiled out by setting 'NDEBUG'. You should probably use abort() rather than assert(0). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 19:10:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C66A16A401 for ; Wed, 5 Apr 2006 19:10:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0211E43D46 for ; Wed, 5 Apr 2006 19:10:17 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k35JACJR012577 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Apr 2006 05:10:15 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k35JACll003132; Thu, 6 Apr 2006 05:10:12 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k35JABMD003131; Thu, 6 Apr 2006 05:10:12 +1000 (EST) (envelope-from peter) Date: Thu, 6 Apr 2006 05:10:11 +1000 From: Peter Jeremy To: Michael Zach Message-ID: <20060405191011.GL699@turion.vk2pj.dyndns.org> References: <1425.62.178.112.107.1144260889.squirrel@webmail.webges.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1425.62.178.112.107.1144260889.squirrel@webmail.webges.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: another make buildworld 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: Wed, 05 Apr 2006 19:10:18 -0000 On Wed, 2006-Apr-05 20:14:49 +0200, Michael Zach wrote: >another error occured. thanks jason for the tip, changing CFLAGS in >make.conf actually helped, but during the build process another error >occured: > >[snip] >... >magic, 47985: Warning offset `text' invalid >magic, 47985: Warning type `text' invalid >magic, 47986: Warning offset `@@' invalid >magic, 47986: Warning type `@@' invalid Somehow your /usr/src/contrib/file/Magdir/magic has been replaced by a CVS repository file. Delete it and re-CVsup. You might like to check for similar problems with other files. >any ideas? there are actually only a Makefile and a config.h in libmagic, >so I guess the magic file is missing at all (if it's ever been in there) The Makefile points to the actual code under src/contrib. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 19:28:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE61A16A401 for ; Wed, 5 Apr 2006 19:28:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C59B343D6D for ; Wed, 5 Apr 2006 19:28:39 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k35JSbQu063286; Wed, 5 Apr 2006 15:28:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Raphael H. Becker" Date: Wed, 5 Apr 2006 15:25:41 -0400 User-Agent: KMail/1.9.1 References: <20060327093503.G60206@p-i-n.com> <200603291154.18847.jhb@freebsd.org> <20060405162714.L60206@p-i-n.com> In-Reply-To: <20060405162714.L60206@p-i-n.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051525.42680.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1376/Wed Apr 5 01:51:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: devfs ruleset 4 (jails) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 19:28:43 -0000 On Wednesday 05 April 2006 10:27, Raphael H. Becker wrote: > On Wed, Mar 29, 2006 at 11:54:17AM -0500, John Baldwin wrote: > > On Wednesday 29 March 2006 11:32, Raphael H. Becker wrote: > > > On Wed, Mar 29, 2006 at 06:07:05PM +0200, Raphael H. Becker wrote: > > > > PS: the box crashed just while writing this (while using devfs > > > > ) so I'll need to powercycle it before leaving my office. > > > crash: > [...] > > > I don't know much about the debugger, so I just resetted the box by > > > typing "reset" at the prompt. > > > Hope that helps a little. > > Well, it means that it's broken in HEAD as well at least. > > Is there a workaround to hide "critical" devices from a mounted devfs? > ... any patches to test? > > From my point of view this is a critical situation for machines with > jails and "foreign" roots in them while I (host admin) cannot hide disk > devices (and other critical stuff) from the jails. No, someone needs to sit down and debug it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 19:42:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C2B016A42A for ; Wed, 5 Apr 2006 19:42:47 +0000 (UTC) (envelope-from frode@nordahl.net) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F6E143D4C for ; Wed, 5 Apr 2006 19:42:44 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.123.167] (s1013-0092.dsl.start.no [195.159.196.188]) by smtp1.powertech.no (Postfix) with ESMTP id DF431A790; Wed, 5 Apr 2006 21:42:41 +0200 (CEST) In-Reply-To: <4433CFA1.90509@centtech.com> References: <4433CFA1.90509@centtech.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> Content-Transfer-Encoding: 7bit From: Frode Nordahl Date: Wed, 5 Apr 2006 21:42:37 +0200 To: Eric Anderson X-Mailer: Apple Mail (2.749.3) Cc: freebsd-current@freebsd.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 19:42:47 -0000 On 5. apr. 2006, at 16.09, Eric Anderson wrote: > Is this what is needed to get it booting FreeBSD? > > http://www.apple.com/macosx/bootcamp/ According to this: http://forum.osx86project.org/index.php? s=&showtopic=14048&view=findpost&p=89523 The actual magic is in a Firmware update wich seems to add some Legacy BIOS support to make it work. Boot Camp is just a nice helper to resize your hard drive and provide some Windows drivers in a package :-) I just tried to boot FreeBSD on my MacBook Pro, and it did seem to start booting, but I could not see anything, just a white / grey screen. I guess I need framebuffer support? I am downloading Fedora now and will give it a shot shortly. How would I go about building a FreeBSD CD with a framebuffer on it? :-) Frode Nordahl frode@nordahl.net From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 20:10:17 2006 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 016B116A400 for ; Wed, 5 Apr 2006 20:10:17 +0000 (UTC) (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 5BA7F43D49 for ; Wed, 5 Apr 2006 20:10:16 +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 k35KAMYA022810 for ; Wed, 5 Apr 2006 16:10:22 -0400 X-ORBL: [71.139.116.48] Received: from [10.0.5.51] (ppp-71-139-116-48.dsl.snfc21.pacbell.net [71.139.116.48]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k35KACFr096266; Wed, 5 Apr 2006 16:10:13 -0400 Message-ID: <443423FC.2070201@root.org> Date: Wed, 05 Apr 2006 13:09:32 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ben Kaduk References: <47d0403c0604051112wf30426bt2c3a7c9b2909c8c1@mail.gmail.com> In-Reply-To: <47d0403c0604051112wf30426bt2c3a7c9b2909c8c1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: acpi: bad write: (was: Re: My snd_ich working well) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 20:10:17 -0000 Ben Kaduk wrote: > On 4/4/06, Nate Lawson wrote: >> /* >> * Some BIOS vendors use AML to read/write directly to IO space. This >> * can cause a problem if such accesses interfere with the OS's access to >> * the same ports. Windows XP and newer systems block accesses to certain >> * IO ports. We print a message or block accesses based on a tunable. >> */ >> static int illegal_bios_ports[] = { >> 0x000, 0x00f, /* DMA controller 1 */ >> 0x020, 0x021, /* PIC */ >> 0x040, 0x043, /* Timer 1 */ >> 0x048, 0x04b, /* Timer 2 failsafe */ >> 0x070, 0x071, /* CMOS and RTC */ >> 0x074, 0x076, /* Extended CMOS */ >> 0x081, 0x083, /* DMA1 page registers */ >> 0x087, 0x087, /* DMA1 ch0 low page */ >> 0x089, 0x08b, /* DMA2 ch2 (0x89), ch3 low page (0x8a, 0x8b) */ >> 0x08f, 0x091, /* DMA2 low page refresh (0x8f) */ >> /* Arb ctrl port, card select feedback (0x90, 0x91) */ >> 0x093, 0x094, /* System board setup */ >> 0x096, 0x097, /* POS channel select */ >> 0x0a0, 0x0a1, /* PIC (cascaded) */ >> 0x0c0, 0x0df, /* ISA DMA */ >> 0x4d0, 0x4d1, /* PIC ELCR (edge/level control) */ >> 0xcf8, 0xcff, /* PCI config space. Microsoft adds 0xd00 also but >> that seems incorrect. */ >> -1, -1 >> }; >> > > Hi Nate, > > As posted earlier, I'm getting these acpi: bad write > messages spamming my console, with port 0x086 instead of Angka's > 0x073. I don't see 0x086 in the above list, though, so I'm a bit > confused. This message would have been triggered by the off-by-one error before my fix (86 is just below 87, which is on the list). The check is now: if ((addr >= port[0] && addr <= port[1]) || (addr < port[0] && addr + (width / 8) > port[0])) Which gives (with addr = 86 and width = 8): 86 >= 87 ... FALSE 86 < 87 (TRUE) && 86 + 1 > 87 (FALSE) ... FALSE You can try it yourself with (play around with addr and width): main() { int addr = 0x86; int width = 8; int port[2] = { 0x87, 0x87 }; if ((addr >= port[0] && addr <= port[1]) || (addr < port[0] && addr + (width / 8) > port[0])) printf("BUGGY BUGGY BIOS\n"); else printf("KRAD!\n"); } So the code is correct. Please be sure you have the right version that matches this code snippet above and recompile your acpi module (or entire kernel) and reinstall it. > I have revision 1.120 of src/sys/dev/acpica/Osd/OsdHardware.c The correct version is 1.20. Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 20:11:51 2006 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 A432D16A420 for ; Wed, 5 Apr 2006 20:11:51 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EDAD43D6D for ; Wed, 5 Apr 2006 20:11:49 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm01.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k35KBjag027849 for ; Wed, 5 Apr 2006 16:11:46 -0400 X-ORBL: [71.139.116.48] Received: from [10.0.5.51] (ppp-71-139-116-48.dsl.snfc21.pacbell.net [71.139.116.48]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k35KBe9k176386; Wed, 5 Apr 2006 16:11:40 -0400 Message-ID: <44342454.8000207@root.org> Date: Wed, 05 Apr 2006 13:11:00 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Angka H. K." References: <4c40c4e70604051146y48cc35fal1680d5121f73ab29@mail.gmail.com> In-Reply-To: <4c40c4e70604051146y48cc35fal1680d5121f73ab29@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , current@freebsd.org Subject: Re: ACPI 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: Wed, 05 Apr 2006 20:11:51 -0000 It can't attach your acpi_perf device (cpu frequency). Try also loading cpufreq.ko, it may work. Or, try adding to loader.conf: debug.acpi.disabled="sysres" Something might be claiming the status port. Angka H. K. wrote: > Great the error is gone now thanks. > > I have other question about ACPI. My dmesg showing like below and I know > nothing about ACPI. What does it mean and can it be fix ? > > acpi_perf0: on cpu0 > acpi_perf0: failed in PERF_STATUS attach > device_attach: acpi_perf0 attach returned 6 > acpi_perf0: on cpu0 > acpi_perf0: failed in PERF_STATUS attach > device_attach: acpi_perf0 attach returned 6 > > > On 4/4/06, Angka H. K. wrote: >> Thanks a lot, you really dedicate your time to FreeBSD >> Sorry I still don't have good connection to do cvsup, may be tomorrow. >> >> Ah.. hard time to finish my job sorry can't help :( >> >> >> On 4/4/06, Nate Lawson wrote: >> >>> Angka H. K. wrote: >>>> Thanks for the replay >>>> I am updating my source now and planing to rebuild it again, but I >>> don't see >>>> any changes on ACPI code. >>>> >>>> I was mistype on the val that return by kernel, the error should be >>> "acpi: >>>> bad write to port 0x073(8) val 20", I am sorry. >>>> Hope it'll be fixed soon. >>> Ok, I fixed the range check on ports so 0x73 should not trigger it. If >>> you have some other write to a port that IS in the blacklist, you'll >>> still get the warning. >>> >>> Ultimately, I intend to emulate what Windows does which is block all >>> writes to the PIC, and block all writes on XP or newer BIOSen. >>> >>> -- >>> Nate >>> >> > -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 20:28:12 2006 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 92A9716A41F for ; Wed, 5 Apr 2006 20:28:12 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F3C843D6B for ; Wed, 5 Apr 2006 20:28:03 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so59542nzf for ; Wed, 05 Apr 2006 13:28:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BN4nvHcXkbb6r4jHU78wsMOIqsI4HE6G2pb/ppeeRhQ2ipf5xKj/8SZwS4QHDPybn8lRN/lKN06TDBjiL4BV/Sgx8rPAzzdaD9UoeNFzHagtc7u0eHZuVnEK8UbdtwqHsfeduEpbCI8gb/RkpDuvktD7wi/q6lTL9tSqM+dFajo= Received: by 10.36.68.7 with SMTP id q7mr47974nza; Wed, 05 Apr 2006 13:28:03 -0700 (PDT) Received: by 10.36.75.9 with HTTP; Wed, 5 Apr 2006 13:28:03 -0700 (PDT) Message-ID: <47d0403c0604051328l7c6fba8ob2719dfedf1b7110@mail.gmail.com> Date: Wed, 5 Apr 2006 15:28:03 -0500 From: "Ben Kaduk" To: "Nate Lawson" In-Reply-To: <443423FC.2070201@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47d0403c0604051112wf30426bt2c3a7c9b2909c8c1@mail.gmail.com> <443423FC.2070201@root.org> Cc: current@freebsd.org Subject: Re: acpi: bad write: (was: Re: My snd_ich working well) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 20:28:12 -0000 On 4/5/06, Nate Lawson wrote: > Ben Kaduk wrote: > > On 4/4/06, Nate Lawson wrote: > >> /* > >> * Some BIOS vendors use AML to read/write directly to IO space. Thi= s > >> * can cause a problem if such accesses interfere with the OS's acces= s to > >> * the same ports. Windows XP and newer systems block accesses to ce= rtain > >> * IO ports. We print a message or block accesses based on a tunable= . > >> */ > >> static int illegal_bios_ports[] =3D { > >> 0x000, 0x00f, /* DMA controller 1 */ > >> 0x020, 0x021, /* PIC */ > >> 0x040, 0x043, /* Timer 1 */ > >> 0x048, 0x04b, /* Timer 2 failsafe */ > >> 0x070, 0x071, /* CMOS and RTC */ > >> 0x074, 0x076, /* Extended CMOS */ > >> 0x081, 0x083, /* DMA1 page registers */ > >> 0x087, 0x087, /* DMA1 ch0 low page */ > >> 0x089, 0x08b, /* DMA2 ch2 (0x89), ch3 low page (0x8a, 0x8b) = */ > >> 0x08f, 0x091, /* DMA2 low page refresh (0x8f) */ > >> /* Arb ctrl port, card select feedback (0x90, = 0x91) */ > >> 0x093, 0x094, /* System board setup */ > >> 0x096, 0x097, /* POS channel select */ > >> 0x0a0, 0x0a1, /* PIC (cascaded) */ > >> 0x0c0, 0x0df, /* ISA DMA */ > >> 0x4d0, 0x4d1, /* PIC ELCR (edge/level control) */ > >> 0xcf8, 0xcff, /* PCI config space. Microsoft adds 0xd00 also= but > >> that seems incorrect. */ > >> -1, -1 > >> }; > >> > > > > Hi Nate, > > > > As posted earlier, I'm getting these acpi: bad write > > messages spamming my console, with port 0x086 instead of Angka's > > 0x073. I don't see 0x086 in the above list, though, so I'm a bit > > confused. > > This message would have been triggered by the off-by-one error before my > fix (86 is just below 87, which is on the list). > > The check is now: > if ((addr >=3D port[0] && addr <=3D port[1]) || > (addr < port[0] && addr + (width / 8) > port[0])) > > Which gives (with addr =3D 86 and width =3D 8): > 86 >=3D 87 ... FALSE > 86 < 87 (TRUE) && 86 + 1 > 87 (FALSE) ... FALSE > > You can try it yourself with (play around with addr and width): > > main() > { > int addr =3D 0x86; > int width =3D 8; > int port[2] =3D { 0x87, 0x87 }; > > if ((addr >=3D port[0] && addr <=3D port[1]) || > (addr < port[0] && addr + (width / 8) > port[0])) > printf("BUGGY BUGGY BIOS\n"); > else > printf("KRAD!\n"); > } > > So the code is correct. Please be sure you have the right version that > matches this code snippet above and recompile your acpi module (or > entire kernel) and reinstall it. > > > I have revision 1.120 of src/sys/dev/acpica/Osd/OsdHardware.c > > The correct version is 1.20. > > Thanks, > -- > Nate > Well, I went back and checked my build log, and it seems that my sleepy fingers typed "buildkernel" instead of "kernel", so I'm running a kernel from april 3, (with the old OsdHardware.c), instead of the new one. I currently have v. 1.20 (1.120 was a typo), so when I can get at the machine later tonight, I will install the new kernel and reboot, and report back if the problem remains (but I highly doubt that it will). Terribly sorry about the noise -- I guess I shouldn't be so excited about the chance to report a bug and get some sleep before sending something off. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 20:39:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D882A16A41F for ; Wed, 5 Apr 2006 20:39:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D24A43D67 for ; Wed, 5 Apr 2006 20:39:08 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k35Kd17l063685; Wed, 5 Apr 2006 16:39:03 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 5 Apr 2006 16:38:57 -0400 User-Agent: KMail/1.9.1 References: <20060405003358.GA83600@tin.it> In-Reply-To: <20060405003358.GA83600@tin.it> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200604051638.59800.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1376/Wed Apr 5 01:51:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Luigi Rizzo Subject: Re: Interesting data on network interrupt - part II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 20:39:12 -0000 On Tuesday 04 April 2006 20:33, Paolo Pisati wrote: > Hi, > > i updated my work on interrupt profiling with sone new > experiments. > > In total we have now: > > -FreeBSD 4 PIC (no asm part) > -FreeBSD 7 APIC > -FreeBSD 7 PIC > -FreeBSD 7 PREE APIC > -FreeBSD 7 APIC JHB > > Some quick comments: > > -PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) > -PREE let new thread save less than 500 ticks of 'queue' while > preempted threads are often resumed after a lot > -JHB patch shaved 2.5k ticks in interrupt masking op > > For graphs, data and more comments: > > http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ I'll commit the patch then. :) One thing you might try to do to better measure the effects of preemption is to generate kernel work so that the bge interrupts occur while the current thread is in the kernel rather than in userland. In that case preemption should provide much lower latency for interrupt handlers, as w/o preemption, an interrupt in kernel mode won't run the ithread until either curthread blocks or returns to userland. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 20:40:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39CFD16A422; Wed, 5 Apr 2006 20:40:16 +0000 (UTC) (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 72E6C43D70; Wed, 5 Apr 2006 20:40:11 +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 E9CB8200141; Wed, 5 Apr 2006 22:40:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 21CBC200137; Wed, 5 Apr 2006 22:40:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A7D44444F41; Wed, 5 Apr 2006 20:39:32 +0000 (UTC) Date: Wed, 5 Apr 2006 20:39:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Baldwin In-Reply-To: <200604051525.42680.jhb@freebsd.org> Message-ID: <20060405203200.N76259@maildrop.int.zabbadoz.net> References: <20060327093503.G60206@p-i-n.com> <200603291154.18847.jhb@freebsd.org> <20060405162714.L60206@p-i-n.com> <200604051525.42680.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org, "Raphael H. Becker" Subject: Re: devfs ruleset 4 (jails) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 20:40:16 -0000 On Wed, 5 Apr 2006, John Baldwin wrote: > On Wednesday 05 April 2006 10:27, Raphael H. Becker wrote: >> On Wed, Mar 29, 2006 at 11:54:17AM -0500, John Baldwin wrote: >>> On Wednesday 29 March 2006 11:32, Raphael H. Becker wrote: >>>> On Wed, Mar 29, 2006 at 06:07:05PM +0200, Raphael H. Becker wrote: >>>>> PS: the box crashed just while writing this (while using devfs >>>>> ) so I'll need to powercycle it before leaving my office. >>>> crash: >> [...] >>>> I don't know much about the debugger, so I just resetted the box by >>>> typing "reset" at the prompt. >>>> Hope that helps a little. >>> Well, it means that it's broken in HEAD as well at least. >> >> Is there a workaround to hide "critical" devices from a mounted devfs? >> ... any patches to test? >> >> From my point of view this is a critical situation for machines with >> jails and "foreign" roots in them while I (host admin) cannot hide disk >> devices (and other critical stuff) from the jails. > > No, someone needs to sit down and debug it. I don't know about the crash but the usual thing from startup scripts: jail_foo...=... jail_foo_devfs_ruleset="devfsrules_jail" jail_foo...=... does the right thing on a RELENG_6 box so things must work. It even works for some manually added rulesets. See /etc/defaults/rc.conf for a complete sample. And it did also work some days or perhaps weeks ago on current. Perhaps looking what is done in /etc/rc.subr (from /etc/rc.d/jail) might be a good start to find out how to do things correctly. I suspect the >>>> # devfs -m /data/jails/pinserv3j01.p-i-n.com/dev/ ruleset 4 is missing an apply? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 21:40:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5EAB16A520; Wed, 5 Apr 2006 21:40:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500CD43D48; Wed, 5 Apr 2006 21:40:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 05 Apr 2006 14:40:33 -0700 Message-ID: <4434394F.8020105@elischer.org> Date: Wed, 05 Apr 2006 14:40:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20060405003358.GA83600@tin.it> <200604051638.59800.jhb@freebsd.org> In-Reply-To: <200604051638.59800.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: Interesting data on network interrupt - part II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 21:40:33 -0000 John Baldwin wrote: >On Tuesday 04 April 2006 20:33, Paolo Pisati wrote: > > >>Hi, >> >>i updated my work on interrupt profiling with sone new >>experiments. >> >>In total we have now: >> >>-FreeBSD 4 PIC (no asm part) >>-FreeBSD 7 APIC >>-FreeBSD 7 PIC >>-FreeBSD 7 PREE APIC >>-FreeBSD 7 APIC JHB >> >>Some quick comments: >> >>-PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) >>-PREE let new thread save less than 500 ticks of 'queue' while >> preempted threads are often resumed after a lot >>-JHB patch shaved 2.5k ticks in interrupt masking op >> >>For graphs, data and more comments: >> >>http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ >> >> > >I'll commit the patch then. :) One thing you might try to do to better >measure the effects of preemption is to generate kernel work so that >the bge interrupts occur while the current thread is in the kernel >rather than in userland. In that case preemption should provide much >lower latency for interrupt handlers, as w/o preemption, an interrupt >in kernel mode won't run the ithread until either curthread blocks or >returns to userland. > > it looks a bit like the preempted threads shuld be put onto a stack of threads to resume so that when the pre-empter finishes, teh previosly active thread is resumed. Basically, a preempted thread should be put at the HEAD of it's run queue, and not the tail.. From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 21:57:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0A9616A41F for ; Wed, 5 Apr 2006 21:57:13 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AB7F43D70 for ; Wed, 5 Apr 2006 21:57:12 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id D1727D474B8 for ; Wed, 5 Apr 2006 17:57:10 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 17:57:01 -0400 X-Sasl-enc: +Nfox3/hzkGhR/3bNviNmB4duYPaPy6SSFXmEw6XNzRv 1144274221 Received: from [192.168.199.129] (unknown [12.109.26.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id 3006843B for ; Wed, 5 Apr 2006 17:57:00 -0400 (EDT) Message-ID: <44343D31.4030506@fastmail.fm> Date: Wed, 05 Apr 2006 16:57:05 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4433E08A.3010802@fastmail.fm> In-Reply-To: <4433E08A.3010802@fastmail.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Interrupt storm on IRQ11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 21:57:13 -0000 Patrick Bowen wrote: (snip...) > > I'm wondering if this is related to RM's recent commits. Replying to myself...That should be RW (Robert Watson), of course. Not RM. My bad... From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 22:10:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED10C16A4A0 for ; Wed, 5 Apr 2006 22:10:51 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CD5243D48 for ; Wed, 5 Apr 2006 22:10:51 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k35MAn5c097268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 15:10:50 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44344068.6060406@errno.com> Date: Wed, 05 Apr 2006 15:10:48 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dandee@volny.cz References: <000701c65850$5830d0e0$6508280a@tocnet28.jspoj.czf> In-Reply-To: <000701c65850$5830d0e0$6508280a@tocnet28.jspoj.czf> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dandee@hellteam.net, freebsd-current@freebsd.org Subject: Re: one side show: associated and second side show: no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Apr 2006 22:10:52 -0000 Daniel Dvoøák wrote: > Hello all, > > first of all I would like to thank Sam L. and others how helped with > 80211ieee and atheros driver. Your work in last months is great ! > > With new ath_hal in source in RELENG_6 I decided to buy 2 new Wistron WNC > CM10 with MAC chip AR5414A to connect 2 nodes with distance 3,5 km. > > My problem is associated or not. > > One side where is hostap show this: > > # ifconfig ath1 list sta > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS ERP > 00:0b:6b:XX:YY:ZZ 1 108 6M 33 180 1200 16 E 0 WME > > RSSI=33, okay 33-95 = -62 dBm > > A datasheet for CM10 said for receive sensitivity: > -85dBm@6Mbps > -67dBm@54Mbps > > So theoretically the client should work with 6-54 Mbps/s without any > difference, because the RF signal is enough to associate even at 54Mbps/s. > > Now go to client side, and what it show: > > ifconfig -v ath0 > > ath0: flags=8843 mtu 1500 > inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2 > inet 10.40.64.18 netmask 0xfffffffc broadcast 10.40.64.19 > ether 00:0b:6b:XX:YY:ZZ > media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11a > status: no carrier > ssid PtP channel 108 (5540) bssid 00:00:00:00:00:00 > authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF > powersavesleep 100 txpowmax 37 txpower 63 rtsthreshold 2346 > mcastrate 1 fragthreshold 2346 pureg protmode OFF wme burst > roaming AUTO bintval 100 > AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack > cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm > AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack > cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm > AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack > cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm > AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack > cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm > > ifconfig ath0 list ap > > SSID BSSID CHAN RATE S:N INT CAPS > PtP 00:0b:6b:XX:YY:ZZ 108 54M 24:0 100 E WME > > It said "no carrier". > > RF signal on client side is lower, okay but 24-95 is -71dBm so it is enough > signal strength to associate to AP at the minimum 6 Mbps/s. > > But it does not work. Any operation at both side like ifconfig ath0 down and > up do not help me. > > How can hostap side say: "yes I see my client, it is accossiated to me with > this mac", and client say: "yes I see my ap, but I could not associate to > ap, even if I should associate to ap" ??? > > Any help is very appreciated. > > P.S.: ath_hal, ath driver and ath sample rate is compiled to my custom > kernel. <> You need to search for references on long distance links; google(wireless ack timeout) found a few reasonable ones. The athctrl script is a faithful port of the original linux program but it's horrible flawed in calculating effective settings. If you look at the stats you'll see lots of dup'd frames which indicates you're not getting an ack in time before the station retransmits. Hence no association. Sniffing from a 3rd station would also show this. If you're doing long distance p2p configs you should use adhoc demo mode; I added it explicitly for this application. Then tune your IFS parameters to reflect the propagation delay. Past that there are many things you can do to improve performance but I'll leave that to others to explain. Sam From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 02:35:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A6116A400 for ; Thu, 6 Apr 2006 02:35:53 +0000 (UTC) (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 7639843D53 for ; Thu, 6 Apr 2006 02:35:50 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRKRM-0004Fx-BV for freebsd-current@freebsd.org; Thu, 06 Apr 2006 11:41:44 +0900 Message-ID: <44347E96.8030104@micom.mng.net> Date: Thu, 06 Apr 2006 11:36:06 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060325180630.V31295@pano.marabu.ch> In-Reply-To: <20060325180630.V31295@pano.marabu.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bin/94767: [patch] rcorder(8) dumps core when does not use a proper RCng script (dansguardian) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 02:35:53 -0000 Can somebody close this PR by committing? By commenting out those free()s in rcorder.c solves the core dump problem when there are circular dependent rc scripts on the system. thanks, Ganbold From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 03:08:12 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A31116A401 for ; Thu, 6 Apr 2006 03:08:12 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7BEE43D46 for ; Thu, 6 Apr 2006 03:08:11 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.4/8.13.4) with ESMTP id k363MtFG027135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 20:23:02 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44348603.9070503@FreeBSD.org> Date: Wed, 05 Apr 2006 20:07:47 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Frode Nordahl References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> In-Reply-To: <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 03:08:12 -0000 No, I don't think it's framebuffer issue, since FreeBSD CD starts loading (I see message indicating that cdboot is trying to start BOOT/LOADER on the screen). My guess is that Apple has only implemented BIOS in amount necessary to bootstrap WinXP, while FreeBSD requires some functionality that doesn't exist. -Maxim Frode Nordahl wrote: > On 5. apr. 2006, at 16.09, Eric Anderson wrote: > >> Is this what is needed to get it booting FreeBSD? >> >> http://www.apple.com/macosx/bootcamp/ > > According to this: > http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 > > > The actual magic is in a Firmware update wich seems to add some Legacy > BIOS support to make it work. Boot Camp is just a nice helper to resize > your hard drive and provide some Windows drivers in a package :-) > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem to start > booting, but I could not see anything, just a white / grey screen. > > I guess I need framebuffer support? > > I am downloading Fedora now and will give it a shot shortly. > > > How would I go about building a FreeBSD CD with a framebuffer on it? :-) > > Frode Nordahl > frode@nordahl.net > > > > _______________________________________________ > 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 Thu Apr 6 03:14:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CC7D16A401 for ; Thu, 6 Apr 2006 03:14:10 +0000 (UTC) (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 04DCE43D45 for ; Thu, 6 Apr 2006 03:14:08 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRL2P-0007U7-VC; Thu, 06 Apr 2006 12:20:02 +0900 Message-ID: <44348790.6040006@micom.mng.net> Date: Thu, 06 Apr 2006 12:14:24 +0900 From: Ganbold User-Agent: Thunderbird 1.5 (X11/20060202) MIME-Version: 1.0 To: Peter Jeremy References: <20060404090837.GC683@turion.vk2pj.dyndns.org> <44323B37.4040605@micom.mng.net> <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> <20060405090326.GD699@turion.vk2pj.dyndns.org> <44338D08.3070000@micom.mng.net> <20060405102528.GE699@turion.vk2pj.dyndns.org> <4433A4A0.5060300@micom.mng.net> <20060405185221.GI699@turion.vk2pj.dyndns.org> In-Reply-To: <20060405185221.GI699@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT-solved, boot problem -SOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 03:14:10 -0000 Hi Peter, Peter Jeremy wrote: > On Wed, 2006-Apr-05 20:06:08 +0900, Ganbold wrote: > >> Sorry for the noise, it was my big fault, I was using I486_CPU instead >> of I686_CPU in the config and never thought this problem might happen >> because of incorrect CPU definition in the config. >> > > The Ixxx_CPU flags are used to conditionally compile CPU support code > so failing to include the correct CPU type is fatal. If you'd posted > the correct config file, we could have solved it much faster. > Yes, that was basically my fault, wasted your time on basic thing. I'm really sorry about that. > >> Only one problem still remains, it still can not boot without >> pressing "Enter" key at the boot prompt (- sign waits forever). >> I created /boot.config with -Dh, now it shows boot.config: -Dh and waits >> for user to press "Enter". >> > > I presume 6.x and -current behave the same. This prompt is from the > second-stage boot loader (boot2). If the problem goes away when you > add '-n' to your /boot.config then your bios isn't starting the 18.2Hz > timer. Otherwise, I have no idea. > Really great news, thanks a lot Peter, actually by adding -n option in /boot.config solves the boot problem. It boots now without user intervention both 6.1-PRERELEASE and CURRENT. However should this kind of situation must be documented somewhere, maybe in FAQ ? thanks again, Ganbold From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 06:14:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5836E16A400 for ; Thu, 6 Apr 2006 06:14:44 +0000 (UTC) (envelope-from amurphy@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 219C243D49 for ; Thu, 6 Apr 2006 06:14:42 +0000 (GMT) (envelope-from amurphy@gsoft.com.au) Received: from [203.31.81.32] (priscilla.gsoft.com.au [203.31.81.32]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k366EchN011325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 15:44:39 +0930 (CST) (envelope-from amurphy@gsoft.com.au) Message-ID: <4434B1CE.9050102@gsoft.com.au> Date: Thu, 06 Apr 2006 15:44:38 +0930 From: Adrian Murphy User-Agent: Thunderbird 1.5 (X11/20060405) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4433E08A.3010802@fastmail.fm> In-Reply-To: <4433E08A.3010802@fastmail.fm> Content-Type: multipart/mixed; boundary="------------040500040801020903020504" X-Spam-Score: -1.132 () ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Subject: Re: Interrupt storm on IRQ11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 06:14:44 -0000 This is a multi-part message in MIME format. --------------040500040801020903020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I too have a similar problem. I have a Dell Inspiron 8000 and the wireless card (Alloy WLT245401) which has a TI chipset. I have used the ndis scheme successfully for the last few months with current dated November 3 2005. I updated current on March 30th. Now I get the interrupt storm on irq 10. Unlike Patrick, I always get an interrupt storm, whether the card is inserted at boot time or if it is inserted later. See my dmesg below. The devices Patrick has on irq 11 (vgapci0, uhci0, xl0) are attached to irq 10 in this laptop. cardbus is also on irq10. I note the commit messages for the file src/sys/dev/cardbus/cardbus.c indicate there may be issues in the current version. But that is dated March 1st. I have tried increasing sysctl hw.intr_storm_threshold up to 200000 from 500 but it doesn't seem to help, so far. Thanks, Adrian Patrick Bowen wrote: > List; > > I get the following on boot in -current; > > Interrupt storm detected on "irq11:"; throttling interrupt source > > If I have my atheros card in the laptop (Dell C600) during boot I can > then do "kldload if_ath" and I'm good to go. If I plug the card in > anytime *after* I get to the login prompt it's non-functional. > > When the card is in the slot at boot, and after I "kldload if_ath" I see; > > ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, > RF2413, RF5413) > ath0: mem 0x88000000-0x8800ffff at device 0.0 on > cardbus1 > ath0: Ethernet address: 00:13:46:b6:19:ea > ath0: mac 7.8 phy 4.5 radio 5.6 > > If I plug the card in later all I see is; > > ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, > RF2413, RF5413) > > I'm wondering if this is related to RM's recent commits. > > (full dmesg attached). > > Thanks, > Patrick > > > ------------------------------------------------------------------------ > > Copyright (c) 1992-2006 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 #1: Sat Apr 1 21:34:55 CST 2006 > pbowen@sg1.sgc.org:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > 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 = 515604480 (491 MB) > kbd1 at kbdmux0 > npx0: [FAST] > 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 > battery0: on acpi0 > battery1: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xec00-0xecff mem 0xf8000000-0xfbffffff,0xfdffc000-0xfdffffff irq 11 at device 0.0 on pci1 > 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 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > 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: > xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffdc00-0xf3ffdc7f,0xf3ffd800-0xf3ffd87f 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 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 > fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FAST] > ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 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 601367225 Hz quality 800 > Timecounters tick every 1.000 msec > Interrupt storm detected on "irq11:"; throttling interrupt source > cardbus1: at device 0.0 (no driver attached) > ad0: 19077MB at ata0-master UDMA33 > acd0: CDRW at ata1-master PIO4 > Trying to mount root from ufs:/dev/ad0s1a > cpu0: too many short sleeps, backing off to C1 > ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0x88000000-0x8800ffff at device 0.0 on cardbus1 > ath0: Ethernet address: 00:13:46:b6:19:ea > ath0: mac 7.8 phy 4.5 radio 5.6 > ath0: link state changed to UP > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" --------------040500040801020903020504 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2006 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 #4: Fri Mar 31 15:08:44 CST 2006 root@priscilla.gsoft.com.au:/usr/obj/usr/src/sys/PRISCILLA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (698.47-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 536780800 (511 MB) avail memory = 515854336 (491 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard 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_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xcc00-0xccff mem 0xe8000000-0xebffffff,0xfcffc000-0xfcffffff irq 11 at device 0.0 on pci1 acpi_video0: on vgapci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 pcm0: port 0xdc00-0xdcff mem 0xf6ffe000-0xf6ffffff irq 5 at device 3.0 on pci2 pcm0: pcib3: at device 6.0 on pci2 pci8: on pcib3 fxp0: port 0xecc0-0xecff mem 0xf8fff000-0xf8ffffff,0xf8e00000-0xf8efffff irq 10 at device 4.0 on pci8 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:20:e0:65:13:1d pci8: at device 8.0 (no driver attached) cbb0: at device 15.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 15.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xf6ffd800-0xf6ffdfff,0xf6ff8000-0xf6ffbfff irq 10 at device 15.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 5b:4f:c0:00:3f:ff:ff:ff 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=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xbce0-0xbcff irq 10 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered 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 Generic PS/2 mouse, device ID 0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] sio1 port 0x2f8-0x2ff,0x280-0x287 irq 3 drq 3 on acpi0 sio1: type 16550A sio1: [FAST] 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 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 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 698472961 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: CDROM at ata0-slave UDMA33 cd0 at ata0 bus 0 target 1 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/ad0s2a ums0: on uhub0 ums0: 5 buttons and Z dir. Interrupt storm detected on "irq10:"; throttling interrupt source --------------040500040801020903020504-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 07:23:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A98B216A400 for ; Thu, 6 Apr 2006 07:23:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED9A343D46 for ; Thu, 6 Apr 2006 07:23:44 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k367NeIV002772 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 Apr 2006 17:23:42 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k367NeHv000773; Thu, 6 Apr 2006 17:23:40 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k367NdGf000772; Thu, 6 Apr 2006 17:23:39 +1000 (EST) (envelope-from peter) Date: Thu, 6 Apr 2006 17:23:38 +1000 From: Peter Jeremy To: Ganbold Message-ID: <20060406072338.GA700@turion.vk2pj.dyndns.org> References: <20060404101223.GH683@turion.vk2pj.dyndns.org> <44336331.40909@micom.mng.net> <20060405075841.GB699@turion.vk2pj.dyndns.org> <443381F9.3010504@micom.mng.net> <20060405090326.GD699@turion.vk2pj.dyndns.org> <44338D08.3070000@micom.mng.net> <20060405102528.GE699@turion.vk2pj.dyndns.org> <4433A4A0.5060300@micom.mng.net> <20060405185221.GI699@turion.vk2pj.dyndns.org> <44348790.6040006@micom.mng.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44348790.6040006@micom.mng.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: CPU class not configured problem in CURRENT-solved, boot problem -SOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 07:23:45 -0000 On Thu, 2006-Apr-06 12:14:24 +0900, Ganbold wrote: >Yes, that was basically my fault, wasted your time on basic thing. >I'm really sorry about that. That's OK. We all make mistakes. >>I presume 6.x and -current behave the same. This prompt is from the >>second-stage boot loader (boot2). If the problem goes away when you >>add '-n' to your /boot.config then your bios isn't starting the 18.2Hz >>timer. Otherwise, I have no idea. >> >Really great news, thanks a lot Peter, actually by adding -n option in >/boot.config solves >the boot problem. It boots now without user intervention both >6.1-PRERELEASE and CURRENT. Actually, this means your BIOS is broken. It's supposed to initialise one of the timers (I don't recall which one) to provice an 18.2Hz interrupt and tick counter for MS-DOS. FreeBSD boot2 (and possibly loader) rely on this tick counter to provide timeouts when waiting for input (normally there's a 3 or 5 second timeout at those prompts). The '-n' disables the timeouts so you can no longer override the defaults - this is not necessarily desirable in general. You might like to look at the BIOS configuration to see if there's anything that looks relevant. Alternatively, you might try HP's technical support and ask why the longword at 0x46c is not incrementing (see sys/boot/i386/boot2/boot2.c:keyhit()). Ubuntu presumably uses some alternative mechanism for any timeouts whilst booting. >However should this kind of situation must be documented somewhere, >maybe in FAQ ? I don't recall anyone reporting this sort of problem before. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 07:54:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 369C816A400; Thu, 6 Apr 2006 07:54:40 +0000 (UTC) (envelope-from dd@freebsd.org) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6268C43D67; Thu, 6 Apr 2006 07:54:26 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from maverick.trit.org (maverick.trit.org [IPv6:2001:4830:2381:2062:212:f0ff:fe4c:896a]) by charade.trit.org (Postfix) with ESMTP id 0F9D01AFB19; Thu, 6 Apr 2006 07:54:26 +0000 (UTC) Received: from maverick.trit.org (localhost [127.0.0.1]) by maverick.trit.org (8.13.4/8.13.4) with ESMTP id k367sP9h021066; Thu, 6 Apr 2006 07:54:25 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by maverick.trit.org (8.13.4/8.13.4/Submit) id k367sOod021064; Thu, 6 Apr 2006 07:54:24 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: maverick.trit.org: dima set sender to dd@freebsd.org using -f Date: Thu, 6 Apr 2006 07:54:24 +0000 From: Dima Dorfman To: "Leo R. Lundgren" Message-ID: <20060406075424.GD843@trit.org> References: <442BCB05.6080000@finalresort.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <442BCB05.6080000@finalresort.org> X-PGP-Key: 69FAE582 (https://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, wkoszek@freebsd.org Subject: Re: mdmfs -P X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 07:54:40 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Leo R. Lundgren wrote: > Is there any way we could get the somewhat new -P option of mdmfs=20 > (http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mdmfs/mdmfs.c.diff?r1=3D1= =2E25&r2=3D1.26)=20 > to be put into -stable as well? Have you tried using this feature on -CURRENT? When I committed it, the original submitter (Wojciech, CC'd) said that my change didn't work for him because it is disabled in compat mode (when mdmfs is called as mount_mfs). I agree that this is a problem since the name "mount_md" no longer works, although I didn't realize that at the time. Since it seems that a lot of people are asking for this, a reasonable interim solution is to allow just this option in compat mode, although figuring out what to do about the other non-compat-only options would be a better long term solution. Wojciech, would a change that removes the compat mode test for this option be acceptable for you too? --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFENMkwBzAFW2n65YIRAv+yAJsHjovW83HRfW8ssIXW5P9sP1d9hACfd2XV W3X8752MGYbCmBC/yilmUGc= =uCrI -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 09:24:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FBA316A423; Thu, 6 Apr 2006 09:24:07 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F46F43D55; Thu, 6 Apr 2006 09:24:06 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.101] (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 806E3244C19; Thu, 6 Apr 2006 18:24:05 +0900 (JST) Message-ID: <4434DE35.4010209@freebsd.org> Date: Thu, 06 Apr 2006 18:24:05 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5 (X11/20060404) MIME-Version: 1.0 To: Kris Kennaway References: <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> <4433CA53.5050000@freebsd.org> <20060405173802.GA25588@xor.obsecurity.org> In-Reply-To: <20060405173802.GA25588@xor.obsecurity.org> Content-Type: text/plain; charset=Shift_JIS Content-Transfer-Encoding: 7bit Cc: ozawa@ongs.co.jp, freebsd-hackers@freebsd.org, Daichi GOTO , freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Alexander@Leidinger.net, Dario Freni Subject: Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 09:24:07 -0000 Kris Kennaway wrote: > I get this panic with mount_unionfs -b: We cannot get the same kernel panic error. Please give us a how-to-repeat-the-same-problem in simple way. > kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at kdb_backtrace+0x29 > vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11 > assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at assert_vop_locked+0x4a > VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e > union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2 > VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b > exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb > do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a > kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c > execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f > syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, ebp = 0xbfbfe808 --- > VOP_OPEN: 0xc72d7000 is not locked but should be > > Kris -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 19:10:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 680AD16A7B6; Thu, 6 Apr 2006 19:10:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outbound7.internet-mail-service.net (outbound7.internet-mail-service.net [216.240.47.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7964F45BF2; Thu, 6 Apr 2006 18:18:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id 964012453D9; Thu, 6 Apr 2006 11:18:47 -0700 (PDT) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id k36IIjHj005840; Thu, 6 Apr 2006 11:18:46 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <44355B85.9060709@elischer.org> Date: Thu, 06 Apr 2006 11:18:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20060405003358.GA83600@tin.it> <200604051638.59800.jhb@freebsd.org> <4434394F.8020105@elischer.org> <200604061311.31632.jhb@freebsd.org> In-Reply-To: <200604061311.31632.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: Interesting data on network interrupt - part II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 19:10:55 -0000 John Baldwin wrote: >On Wednesday 05 April 2006 17:40, Julian Elischer wrote: > > >>John Baldwin wrote: >> >> >> >>>On Tuesday 04 April 2006 20:33, Paolo Pisati wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>i updated my work on interrupt profiling with sone new >>>>experiments. >>>> >>>>In total we have now: >>>> >>>>-FreeBSD 4 PIC (no asm part) >>>>-FreeBSD 7 APIC >>>>-FreeBSD 7 PIC >>>>-FreeBSD 7 PREE APIC >>>>-FreeBSD 7 APIC JHB >>>> >>>>Some quick comments: >>>> >>>>-PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) >>>>-PREE let new thread save less than 500 ticks of 'queue' while >>>>preempted threads are often resumed after a lot >>>>-JHB patch shaved 2.5k ticks in interrupt masking op >>>> >>>>For graphs, data and more comments: >>>> >>>>http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ >>>> >>>> >>>> >>>> >>>I'll commit the patch then. :) One thing you might try to do to better >>>measure the effects of preemption is to generate kernel work so that >>>the bge interrupts occur while the current thread is in the kernel >>>rather than in userland. In that case preemption should provide much >>>lower latency for interrupt handlers, as w/o preemption, an interrupt >>>in kernel mode won't run the ithread until either curthread blocks or >>>returns to userland. >>> >>> >>> >>> >>it looks a bit like the preempted threads shuld be put onto a stack of >>threads to resume >>so that when the pre-empter finishes, teh previosly active thread is >>resumed. >>Basically, a preempted thread should be put at the HEAD of it's run >>queue, and not the tail.. >> >> > >You changed the scheduler to already do that. > > oh, yeah,..... at least I'm consistent.. From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 19:11:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEAA016A8CB for ; Thu, 6 Apr 2006 19:11:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A8BE454CF for ; Thu, 6 Apr 2006 17:11:51 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k36HBf0I072446; Thu, 6 Apr 2006 13:11:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Julian Elischer Date: Thu, 6 Apr 2006 13:11:29 -0400 User-Agent: KMail/1.9.1 References: <20060405003358.GA83600@tin.it> <200604051638.59800.jhb@freebsd.org> <4434394F.8020105@elischer.org> In-Reply-To: <4434394F.8020105@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604061311.31632.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1377/Thu Apr 6 02:17:48 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: Interesting data on network interrupt - part II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 19:11:08 -0000 On Wednesday 05 April 2006 17:40, Julian Elischer wrote: > John Baldwin wrote: > > >On Tuesday 04 April 2006 20:33, Paolo Pisati wrote: > > > > > >>Hi, > >> > >>i updated my work on interrupt profiling with sone new > >>experiments. > >> > >>In total we have now: > >> > >>-FreeBSD 4 PIC (no asm part) > >>-FreeBSD 7 APIC > >>-FreeBSD 7 PIC > >>-FreeBSD 7 PREE APIC > >>-FreeBSD 7 APIC JHB > >> > >>Some quick comments: > >> > >>-PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) > >>-PREE let new thread save less than 500 ticks of 'queue' while > >> preempted threads are often resumed after a lot > >>-JHB patch shaved 2.5k ticks in interrupt masking op > >> > >>For graphs, data and more comments: > >> > >>http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ > >> > >> > > > >I'll commit the patch then. :) One thing you might try to do to better > >measure the effects of preemption is to generate kernel work so that > >the bge interrupts occur while the current thread is in the kernel > >rather than in userland. In that case preemption should provide much > >lower latency for interrupt handlers, as w/o preemption, an interrupt > >in kernel mode won't run the ithread until either curthread blocks or > >returns to userland. > > > > > > it looks a bit like the preempted threads shuld be put onto a stack of > threads to resume > so that when the pre-empter finishes, teh previosly active thread is > resumed. > Basically, a preempted thread should be put at the HEAD of it's run > queue, and not the tail.. You changed the scheduler to already do that. -- 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 Apr 6 20:17:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D54C516A410 for ; Thu, 6 Apr 2006 20:17:28 +0000 (UTC) (envelope-from bln@deprese.net) Received: from hades.deprese.net (hades.deprese.net [81.2.209.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC7D844261 for ; Thu, 6 Apr 2006 16:58:16 +0000 (GMT) (envelope-from bln@deprese.net) Received: from [192.168.1.194] (r2g242.chello.upc.cz [62.245.70.242]) by hades.deprese.net (Postfix) with ESMTP id 1224D33C2C for ; Thu, 6 Apr 2006 18:58:15 +0200 (CEST) Message-ID: <4435489E.9060105@deprese.net> Date: Thu, 06 Apr 2006 18:58:06 +0200 From: Ondra Holecek User-Agent: Thunderbird 1.5 (X11/20060213) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: serial port 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: Thu, 06 Apr 2006 20:17:28 -0000 hello, i have got PCI card with two RS-232 connectors (made by Sunix) and I managed to add record into pucdata.c to see it in my system. the problem is that i can only read from port but cannot send any - if i connect it with other computer (B), everything what i write on B's terminal I can see on Sunix card (A), but nothing what i write on A can be seen on B. speeds are the same, and tested for 2400, 4800, 9600, 14400, 19200, 28800, 38400, 57600, 115200. what i added to pucdata.c: { "Sunix XXX", { 0x1409, 0x7168, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ * 8 }, { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ * 8 }, }, }, pciconf -lv: puc0@pci0:17:0: class=0x070002 card=0x50791409 chip=0x71681409 rev=0x01 hdr=0x00 class = simple comms subclass = UART thanks for help Ondra From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 20:50:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE15816A402 for ; Thu, 6 Apr 2006 20:50:09 +0000 (UTC) (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 2FAE143D45 for ; Thu, 6 Apr 2006 20:50:09 +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 0E7022000C1; Thu, 6 Apr 2006 22:50:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 53FDD2000AE; Thu, 6 Apr 2006 22:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 55021444F41; Thu, 6 Apr 2006 20:46:26 +0000 (UTC) Date: Thu, 6 Apr 2006 20:46:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ondra Holecek In-Reply-To: <4435489E.9060105@deprese.net> Message-ID: <20060406204133.S30410@maildrop.int.zabbadoz.net> References: <4435489E.9060105@deprese.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: serial port 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: Thu, 06 Apr 2006 20:50:09 -0000 On Thu, 6 Apr 2006, Ondra Holecek wrote: Hi, > i have got PCI card with two RS-232 connectors (made by Sunix) and I > managed to add record into pucdata.c to see it in my system. > > what i added to pucdata.c: [...] > > pciconf -lv: > > puc0@pci0:17:0: class=0x070002 card=0x50791409 chip=0x71681409 rev=0x01 hdr=0x00 serach for the matching entry in http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/dev/pci/pucdata.c?rev=1.44&content-type=text/plain if you only have 2xserial and no parallel it's most likely the SUNIX 403X 2S. we should really sync with NetBSD... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 20:54:42 2006 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 29C6A16A400; Thu, 6 Apr 2006 20:54:42 +0000 (UTC) (envelope-from dpz@ack.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [128.32.206.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 840B443D72; Thu, 6 Apr 2006 20:54:16 +0000 (GMT) (envelope-from dpz@ack.berkeley.edu) Received: from [128.32.155.51] (soliloquy.Net.Berkeley.EDU [128.32.155.51]) (authenticated bits=0) by malcolm.berkeley.edu (8.13.6/8.13.3) with ESMTP id k36KsG0r086050 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 13:54:16 -0700 (PDT) (envelope-from dpz@ack.berkeley.edu) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6340eeea2adb8b05df21f35a2c2cd109@ack.berkeley.edu> Content-Transfer-Encoding: 7bit From: David Paul Zimmerman Date: Thu, 6 Apr 2006 13:54:22 -0700 To: Pawel Worach X-Mailer: Apple Mail (2.623) X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (malcolm.berkeley.edu [128.32.206.239]); Thu, 06 Apr 2006 13:54:16 -0700 (PDT) Cc: Matthew Jacob , current@freebsd.org Subject: Re: mpt(4) mirror 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: Thu, 06 Apr 2006 20:54:42 -0000 I've tried a few different csup's now on my X4100 to get back to a functioning RAID-1 setup: - As mentioned below, a full CURRENT csup on 2006.04.04 produced the same behavior you saw. An install from 7.0-CURRENT-SNAP013-amd64-disc1.iso (2006.03.10 snapshot) boots fine. So those were the two bookends that I worked from. - A backdated CURRENT csup for date=2006.03.30.15.00.00 (previous to the last big mpt change) built fine, but produced equally broken behavior on reboot. By the time I got to look at the console, it was scrolling a single mpt error line off the screen, which I presume by this point in the mpt development cycle is irrelevant. The system never came back up fully, and forced a backout. - A backdated CURRENT csup for date=2006.03.23.00.00.00 (previous to the last two big mpt changes) built and booted fine. So it looks like the big change on 2006.03.25 is where things went awry. Not surprisingly, the notes for 1.22 say, "Regression testing with Fusion RAID instances has not been possible." I'm CC'ing Matthew directly so he's aware. dp On Apr 5, 2006, at 6:46 AM, David Paul Zimmerman wrote: > I noticed a similar thing on my Sun X4100 (LSI1064) after csup'ing > yesterday. I'll be rolling back to my Mar 10 snapshot kernel when I > get into work. > > dp > > On Apr 4, 2006, at 11:54 AM, Pawel Worach wrote: > >> Hi, >> >> After the recent changes to mpt(4) it seems the driver has some isses >> with the mirroring configuration (two . This is on a IBM x345 server >> with a kernel from today. >> >> kernel messages: >> mpt0: port 0x2600-0x26ff mem >> 0xf7ff0000-0xf7fffff >> f,0xf7fe0000-0xf7feffff irq 27 at device 7.0 on pci8 >> mpt0: [GIANT-LOCKED] >> mpt0: MPI Version=1.2.15.0 >> mpt0: Capabilities: ( RAID-1 SAFTE ) >> mpt0: 1 Active Volume (1 Max) >> mpt0: 2 Hidden Drive Members (6 Max) >> mpt1: port 0x2700-0x27ff mem >> 0xf7fd0000-0xf7fdfff >> f,0xf7fc0000-0xf7fcffff irq 28 at device 7.1 on pci8 >> mpt1: [GIANT-LOCKED] >> mpt1: MPI Version=1.2.15.0 >> mpt1: Capabilities: ( RAID-1 SAFTE ) >> mpt1: 0 Active Volumes (0 Max) >> mpt1: 0 Hidden Drive Members (0 Max) >> ... >> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) >> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 >> mpt0:vol0(mpt0:0:0): 2 Members: >> (mpt0:0:0): Primary >> (mpt0:0:1): Secondary >> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) >> (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) >> (mpt0:vol0:0): Online >> (mpt0:vol0:1): Physical (mpt0:0:1), Pass-thru (mpt0:1:1) >> (mpt0:vol0:1): Online >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: mpt_cam_event: 0xb >> (mpt0:vol0:0): Physical Disk Status Changed >> mpt0: mpt_cam_event: 0xb >> (mpt0:vol0:0): Volume Status Changed >> mpt0: mpt_cam_event: 0xb >> (mpt0:vol0:0): Physical Disk Status Changed >> mpt0: IOC Bus Reset Port: 0 >> mpt0: mpt_write_cfg_page: Config Info Status 2 >> mpt0: mpt_setwidth: write cur page failed >> mpt0: Set width Failed! >> mpt0: IOC Bus Reset Port: 0 >> mpt0: mpt_read_cfg_page: Config Info Status 2 >> mpt0: mpt_setwidth: read cur page failed >> mpt0: Set width Failed! >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0:vol0(mpt0:0:0): RAID-1 - Degraded >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) >> (mpt0:vol0:0): No longer configured >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: mpt_read_cfg_page: Config Info Status 2 >> mpt0: cannot get target 1 DP0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> mpt0: IOC Bus Reset Port: 0 >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #3 Launched! >> >> da0 at mpt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 >> device >> da0: 3.300MB/s transfers, Tagged Queueing Enabled >> da0: 34710MB (71087625 512 byte sectors: 255H 63S/T 4425C) >> Trying to mount root from ufs:/dev/da0s1a >> >> Booting an older kernel from around Mar. 25 works fine. Anything else >> I can dig out? >> >> -- >> Pawel From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 21:39:49 2006 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 B526516A405 for ; Thu, 6 Apr 2006 21:39:49 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F2843D76 for ; Thu, 6 Apr 2006 21:39:35 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so240709wra for ; Thu, 06 Apr 2006 14:39:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YKqsTBS+cycYoncPaXy2vUkXLKdQzhT0IE4Sa9ys42lj4GpM5UtfaeJvvTFqdtfkbo+nB9F9l8siaRk+CSRCq4aEiVEIwI1pmHrbmiF5XtqlBQ90oCczIgMHg5n2YhumBVZOWKxEfd0go7SxnsxjdOz06hHTiz/M+JYGf/W2q+s= Received: by 10.65.105.11 with SMTP id h11mr239664qbm; Thu, 06 Apr 2006 14:39:35 -0700 (PDT) Received: by 10.65.155.4 with HTTP; Thu, 6 Apr 2006 14:39:35 -0700 (PDT) Message-ID: <7579f7fb0604061439h2fd4f96bo9ad83dcd69901fba@mail.gmail.com> Date: Thu, 6 Apr 2006 14:39:35 -0700 From: "Matthew Jacob" To: "David Paul Zimmerman" In-Reply-To: <6340eeea2adb8b05df21f35a2c2cd109@ack.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6340eeea2adb8b05df21f35a2c2cd109@ack.berkeley.edu> Cc: Matthew Jacob , current@freebsd.org Subject: Re: mpt(4) mirror 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: Thu, 06 Apr 2006 21:39:49 -0000 Okay. It'll take me a couple of days to respond to this issue, but I *am* a= ware. Sorry for the breakage. On 4/6/06, David Paul Zimmerman wrote: > I've tried a few different csup's now on my X4100 to get back to a > functioning RAID-1 setup: > > - As mentioned below, a full CURRENT csup on 2006.04.04 produced the > same behavior you saw. An install from > 7.0-CURRENT-SNAP013-amd64-disc1.iso (2006.03.10 snapshot) boots fine. > So those were the two bookends that I worked from. > > - A backdated CURRENT csup for date=3D2006.03.30.15.00.00 (previous to > the last big mpt change) built fine, but produced equally broken > behavior on reboot. By the time I got to look at the console, it was > scrolling a single mpt error line off the screen, which I presume by > this point in the mpt development cycle is irrelevant. The system > never came back up fully, and forced a backout. > > - A backdated CURRENT csup for date=3D2006.03.23.00.00.00 (previous to > the last two big mpt changes) built and booted fine. > > So it looks like the big change on 2006.03.25 is where things went > awry. Not surprisingly, the notes for 1.22 say, "Regression testing > with Fusion RAID instances has not been possible." I'm CC'ing Matthew > directly so he's aware. > > dp > > On Apr 5, 2006, at 6:46 AM, David Paul Zimmerman wrote: > > > I noticed a similar thing on my Sun X4100 (LSI1064) after csup'ing > > yesterday. I'll be rolling back to my Mar 10 snapshot kernel when I > > get into work. > > > > dp > > > > On Apr 4, 2006, at 11:54 AM, Pawel Worach wrote: > > > >> Hi, > >> > >> After the recent changes to mpt(4) it seems the driver has some isses > >> with the mirroring configuration (two . This is on a IBM x345 server > >> with a kernel from today. > >> > >> kernel messages: > >> mpt0: port 0x2600-0x26ff mem > >> 0xf7ff0000-0xf7fffff > >> f,0xf7fe0000-0xf7feffff irq 27 at device 7.0 on pci8 > >> mpt0: [GIANT-LOCKED] > >> mpt0: MPI Version=3D1.2.15.0 > >> mpt0: Capabilities: ( RAID-1 SAFTE ) > >> mpt0: 1 Active Volume (1 Max) > >> mpt0: 2 Hidden Drive Members (6 Max) > >> mpt1: port 0x2700-0x27ff mem > >> 0xf7fd0000-0xf7fdfff > >> f,0xf7fc0000-0xf7fcffff irq 28 at device 7.1 on pci8 > >> mpt1: [GIANT-LOCKED] > >> mpt1: MPI Version=3D1.2.15.0 > >> mpt1: Capabilities: ( RAID-1 SAFTE ) > >> mpt1: 0 Active Volumes (0 Max) > >> mpt1: 0 Hidden Drive Members (0 Max) > >> ... > >> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) > >> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 > >> mpt0:vol0(mpt0:0:0): 2 Members: > >> (mpt0:0:0): Primary > >> (mpt0:0:1): Secondary > >> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) > >> (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) > >> (mpt0:vol0:0): Online > >> (mpt0:vol0:1): Physical (mpt0:0:1), Pass-thru (mpt0:1:1) > >> (mpt0:vol0:1): Online > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: mpt_cam_event: 0xb > >> (mpt0:vol0:0): Physical Disk Status Changed > >> mpt0: mpt_cam_event: 0xb > >> (mpt0:vol0:0): Volume Status Changed > >> mpt0: mpt_cam_event: 0xb > >> (mpt0:vol0:0): Physical Disk Status Changed > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: mpt_write_cfg_page: Config Info Status 2 > >> mpt0: mpt_setwidth: write cur page failed > >> mpt0: Set width Failed! > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: mpt_read_cfg_page: Config Info Status 2 > >> mpt0: mpt_setwidth: read cur page failed > >> mpt0: Set width Failed! > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0:vol0(mpt0:0:0): RAID-1 - Degraded > >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) > >> (mpt0:vol0:0): No longer configured > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: mpt_read_cfg_page: Config Info Status 2 > >> mpt0: cannot get target 1 DP0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> mpt0: IOC Bus Reset Port: 0 > >> SMP: AP CPU #2 Launched! > >> SMP: AP CPU #1 Launched! > >> SMP: AP CPU #3 Launched! > >> > >> da0 at mpt0 bus 0 target 0 lun 0 > >> da0: Fixed Direct Access SCSI-2 > >> device > >> da0: 3.300MB/s transfers, Tagged Queueing Enabled > >> da0: 34710MB (71087625 512 byte sectors: 255H 63S/T 4425C) > >> Trying to mount root from ufs:/dev/da0s1a > >> > >> Booting an older kernel from around Mar. 25 works fine. Anything else > >> I can dig out? > >> > >> -- > >> Pawel > > _______________________________________________ > 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 Thu Apr 6 21:48:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B5AB16A404 for ; Thu, 6 Apr 2006 21:48:28 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C8F843D45 for ; Thu, 6 Apr 2006 21:48:27 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so250932nzf for ; Thu, 06 Apr 2006 14:48:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bNnH3S0TJy9ksi1T8hyiVR+iTP32kRtTiyHR1JGXKOA42obHe4niu/59sl2cyl5u8bhZFmtuKb0Py+h8D5YU2R+q0vyaeQ++9QG4C0O+qNGEL7PrAZym7rhO9ue/3C+FYtaWNjwEl/Au2XwaXyUz54Pfy782kT8BdlH3VWVfvig= Received: by 10.37.20.43 with SMTP id x43mr1668740nzi; Thu, 06 Apr 2006 14:48:24 -0700 (PDT) Received: by 10.36.75.9 with HTTP; Thu, 6 Apr 2006 14:48:24 -0700 (PDT) Message-ID: <47d0403c0604061448n49d85eaesa1d692f5900cdc67@mail.gmail.com> Date: Thu, 6 Apr 2006 21:48:24 +0000 From: "Ben Kaduk" To: "Adrian Murphy" In-Reply-To: <4434B1CE.9050102@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4433E08A.3010802@fastmail.fm> <4434B1CE.9050102@gsoft.com.au> Cc: freebsd-current@freebsd.org Subject: Re: Interrupt storm on IRQ11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 21:48:28 -0000 On 4/6/06, Adrian Murphy wrote: > Hi, > > I too have a similar problem. I have a Dell Inspiron 8000 and the > wireless card (Alloy WLT245401) which has a TI chipset. I have used the > ndis scheme successfully for the last few months with current dated > November 3 2005. > > I updated current on March 30th. Now I get the interrupt storm on irq > 10. Unlike Patrick, I always get an interrupt storm, whether the card > is inserted at boot time or if it is inserted later. > > See my dmesg below. The devices Patrick has on irq 11 (vgapci0, uhci0, > xl0) are attached to irq 10 in this laptop. cardbus is also on irq10. > > I note the commit messages for the file src/sys/dev/cardbus/cardbus.c > indicate there may be issues in the current version. But that is dated > March 1st. > > I have tried increasing sysctl hw.intr_storm_threshold up to 200000 from > 500 but it doesn't seem to help, so far. > > Thanks, > > Adrian > > > Patrick Bowen wrote: > > List; > > > > I get the following on boot in -current; > > > > Interrupt storm detected on "irq11:"; throttling interrupt source > > > > If I have my atheros card in the laptop (Dell C600) during boot I can > > then do "kldload if_ath" and I'm good to go. If I plug the card in > > anytime *after* I get to the login prompt it's non-functional. > > > > When the card is in the slot at boot, and after I "kldload if_ath" I se= e; > > > > ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, > > RF2413, RF5413) > > ath0: mem 0x88000000-0x8800ffff at device 0.0 on > > cardbus1 > > ath0: Ethernet address: 00:13:46:b6:19:ea > > ath0: mac 7.8 phy 4.5 radio 5.6 > > > > If I plug the card in later all I see is; > > > > ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, > > RF2413, RF5413) > > > > I'm wondering if this is related to RM's recent commits. > > > > (full dmesg attached). > > > > Thanks, > > Patrick > > [other people's dmesg's snipped] Hi, all, I, too am now seeing an interrupt storm on irq 11 after upgrading to april 5 (from ~jan 29). The devices that are on irq 11 for me are vgapci, uhci, ehci, bfe, fwohci, and a non-functional pcmcia modem which attaches to sio. A full dmesg may be found here (sorry it's not verbose, I can get one if I need to), as well as pciconf -lv: https://netfiles.uiuc.edu/kaduk/www/prolepsis/ My bfe network card seems to be working just fine, though I haven't been stressing it too much. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 23:17:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5B4016A400; Thu, 6 Apr 2006 23:17:33 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55B2843D46; Thu, 6 Apr 2006 23:17:33 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id k36NHUBY056437; Thu, 6 Apr 2006 19:17:30 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id k36NHUJx056434; Thu, 6 Apr 2006 19:17:30 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 6 Apr 2006 19:17:30 -0400 (EDT) From: Andre Guibert de Bruet To: Maxim Sobolev In-Reply-To: <44348603.9070503@FreeBSD.org> Message-ID: <20060406190944.G56354@lexi.siliconlandmark.com> References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.449, required 6, autolearn=not spam, AWL 0.15, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 23:17:33 -0000 On Wed, 5 Apr 2006, Maxim Sobolev wrote: > No, I don't think it's framebuffer issue, since FreeBSD CD starts loading (I > see message indicating that cdboot is trying to start BOOT/LOADER on the > screen). My guess is that Apple has only implemented BIOS in amount necessary > to bootstrap WinXP, while FreeBSD requires some functionality that doesn't > exist. Does it drop you to the loader prompt or die before that? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Thu Apr 6 23:26:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F0FD16A402 for ; Thu, 6 Apr 2006 23:26:35 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BE0143D46 for ; Thu, 6 Apr 2006 23:26:33 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A72FE.dip.t-dialin.net [84.154.114.254]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k36NQUeh019078 for ; Fri, 7 Apr 2006 01:26:31 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k36NQLWr008947 for ; Fri, 7 Apr 2006 01:26:30 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k36NQxL5037240 for ; Fri, 7 Apr 2006 01:26:59 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200604062326.k36NQxL5037240@fire.jhs.private> To: freebsd-current@freebsd.org Date: Fri, 07 Apr 2006 01:26:59 +0200 From: "Julian H. Stacey" Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Apr 2006 23:26:35 -0000 > It is my great pleasure and privilege to announce the availability of > FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN > months of tireless work. I was away over 1st April, & came back to a backlog of mail when 1st April was no longer current, so didn't notice date for a few seconds, & found the announcement rather weird but not necessarily totaly daft ;-) ... FreeBSD-2.X is really obsolete, but some of us occasionaly keep/ resuscitate obsolete hardware (eg for vintage purposes http://vcfe.org/E/ ), one example: between FreeBSD-2 & 3 I think support for some old 8 bit scsi controllers was dumped, so old software can be attractive. So I checked on FTP site: no CHECKSUM.MD5, just a single file, 142 Meg ( 142 186 496 ) ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/2.2.9-RELEASE.iso That .iso contains 620 files, I didnt try running it [yet .. maybe] If it's some silly spoof, its quite elaborately big, if so, I'd suggest reduce to a README to save a lot of mirror space & bandwidth. Either way, a CHECKSUM.MD5 would be good. -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 00:32:11 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 612E716A401 for ; Fri, 7 Apr 2006 00:32:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AB843D45 for ; Fri, 7 Apr 2006 00:32:10 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.4/8.13.4) with ESMTP id k370l7MP042343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 17:47:09 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4435B303.5040205@FreeBSD.org> Date: Thu, 06 Apr 2006 17:32:03 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andre Guibert de Bruet References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> <20060406190944.G56354@lexi.siliconlandmark.com> In-Reply-To: <20060406190944.G56354@lexi.siliconlandmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 00:32:11 -0000 Andre Guibert de Bruet wrote: > > On Wed, 5 Apr 2006, Maxim Sobolev wrote: > >> No, I don't think it's framebuffer issue, since FreeBSD CD starts >> loading (I see message indicating that cdboot is trying to start >> BOOT/LOADER on the screen). My guess is that Apple has only >> implemented BIOS in amount necessary to bootstrap WinXP, while FreeBSD >> requires some functionality that doesn't exist. > > Does it drop you to the loader prompt or die before that? Dies before. I have not time to investigate the exact point when it dies. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 00:48:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9141D16A401; Fri, 7 Apr 2006 00:48:47 +0000 (UTC) (envelope-from msergeant@snsonline.net) Received: from xyzzy.snsonline.net (office-fw.iexec.net.au [210.18.210.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23ED343D48; Fri, 7 Apr 2006 00:48:46 +0000 (GMT) (envelope-from msergeant@snsonline.net) Received: from [127.0.0.1] (localhost [127.0.0.1]) by xyzzy.snsonline.net (Postfix) with ESMTP id D74BD9FCD07; Fri, 7 Apr 2006 10:48:44 +1000 (EST) In-Reply-To: <4435B303.5040205@FreeBSD.org> References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> <20060406190944.G56354@lexi.siliconlandmark.com> <4435B303.5040205@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <196C209A-A585-4AD5-B7C9-A27DD57ECD8C@snsonline.net> Content-Transfer-Encoding: 7bit From: Mark Sergeant Date: Fri, 7 Apr 2006 10:48:43 +1000 To: Maxim Sobolev X-Mailer: Apple Mail (2.749.3) Cc: freebsd-current@freebsd.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 00:48:47 -0000 On 07/04/2006, at 10:32 AM, Maxim Sobolev wrote: > Andre Guibert de Bruet wrote: >> On Wed, 5 Apr 2006, Maxim Sobolev wrote: >>> No, I don't think it's framebuffer issue, since FreeBSD CD starts >>> loading (I see message indicating that cdboot is trying to start >>> BOOT/LOADER on the screen). My guess is that Apple has only >>> implemented BIOS in amount necessary to bootstrap WinXP, while >>> FreeBSD requires some functionality that doesn't exist. >> Does it drop you to the loader prompt or die before that? > > Dies before. I have not time to investigate the exact point when it > dies. > > -Maxim It could be worth trying http://www.macworld.com/news/2006/04/06/parallels/index.php From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 01:17:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6266F16A40F for ; Fri, 7 Apr 2006 01:17:39 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id E016F43D46 for ; Fri, 7 Apr 2006 01:17:38 +0000 (GMT) (envelope-from bazzoola@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so399105pyc for ; Thu, 06 Apr 2006 18:17: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:subject:content-type:content-transfer-encoding; b=dg7eik/AMVtTNpF+8XRPy9d62i4BEiXFRnlcSIzeRfHa1g/UMqIWOW0N7TlQ0NFq2gLtp/hJMuFIY0GPUrnUbTgEp8bhsiLsrYRS0t74V/LvGkzOf5usvKlTs0WANGDVVdtbxW0Hu9vwVDwfFFb1IYfOfqso57NVlCKLb0yvwQg= Received: by 10.35.36.13 with SMTP id o13mr268469pyj; Thu, 06 Apr 2006 18:17:37 -0700 (PDT) Received: from ?192.168.1.9? ( [35.11.158.74]) by mx.gmail.com with ESMTP id r66sm86373pye.2006.04.06.18.17.36; Thu, 06 Apr 2006 18:17:36 -0700 (PDT) Message-ID: <4435BEA6.4060607@gmail.com> Date: Thu, 06 Apr 2006 21:21:42 -0400 From: bazzoola User-Agent: Mail/News 1.5.0.2 (Macintosh/20060313) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Apr 2006 02:54:52 +0000 Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 01:17:39 -0000 Maxim Sobolev wrote: > No, I don't think it's framebuffer issue, since FreeBSD CD starts > loading (I see message indicating that cdboot is trying to start > BOOT/LOADER on the screen). My guess is that Apple has only implemented > BIOS in amount necessary to bootstrap WinXP, while FreeBSD requires some > functionality that doesn't exist. > > -Maxim > > Frode Nordahl wrote: > > On 5. apr. 2006, at 16.09, Eric Anderson wrote: > > > >> Is this what is needed to get it booting FreeBSD? > >> > >> http://www.apple.com/macosx/bootcamp/ > > > > According to this: > > http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 > > > > > > The actual magic is in a Firmware update wich seems to add some Legacy > > BIOS support to make it work. Boot Camp is just a nice helper to resize > > your hard drive and provide some Windows drivers in a package :-) > > > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem to start > > booting, but I could not see anything, just a white / grey screen. > > > > I guess I need framebuffer support? > > > > I am downloading Fedora now and will give it a shot shortly. > > > > > > How would I go about building a FreeBSD CD with a framebuffer on it? :-) > > > > Frode Nordahl > > frode@nordahl.net > > > > > > > > _______________________________________________ > > 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" > > > > I too tried booting FreeBSD 6.0 on a 2.0Ghz Macbook Pro with 1GB RAM I get the following CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found _ the cursor at the end is blinkin so fast. There isnt any activity. At least thats what I feel. From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 04:14:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B4916A400 for ; Fri, 7 Apr 2006 04:14:34 +0000 (UTC) (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 0532143D46 for ; Fri, 7 Apr 2006 04:14:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k374ETDF005748; Thu, 6 Apr 2006 22:14:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4435E725.5060103@samsco.org> Date: Thu, 06 Apr 2006 22:14:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bazzoola References: <4435BEA6.4060607@gmail.com> In-Reply-To: <4435BEA6.4060607@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 04:14:34 -0000 bazzoola wrote: > Maxim Sobolev wrote: > > No, I don't think it's framebuffer issue, since FreeBSD CD starts > > loading (I see message indicating that cdboot is trying to start > > BOOT/LOADER on the screen). My guess is that Apple has only implemented > > BIOS in amount necessary to bootstrap WinXP, while FreeBSD requires some > > functionality that doesn't exist. > > > > -Maxim > > > > Frode Nordahl wrote: > > > On 5. apr. 2006, at 16.09, Eric Anderson wrote: > > > > > >> Is this what is needed to get it booting FreeBSD? > > >> > > >> http://www.apple.com/macosx/bootcamp/ > > > > > > According to this: > > > > http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 > > > > > > > > > > The actual magic is in a Firmware update wich seems to add some Legacy > > > BIOS support to make it work. Boot Camp is just a nice helper to > resize > > > your hard drive and provide some Windows drivers in a package :-) > > > > > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem to > start > > > booting, but I could not see anything, just a white / grey screen. > > > > > > I guess I need framebuffer support? > > > > > > I am downloading Fedora now and will give it a shot shortly. > > > > > > > > > How would I go about building a FreeBSD CD with a framebuffer on > it? :-) > > > > > > Frode Nordahl > > > frode@nordahl.net > > > > > > > > > > > > _______________________________________________ > > > 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" > > > > > > > > I too tried booting FreeBSD 6.0 on a 2.0Ghz Macbook Pro with 1GB RAM > I get the following > > > CD Loader 1.2 > > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > _ > > > > > the cursor at the end is blinkin so fast. There isnt any activity. > At least thats what I feel. Someone should pull out a 4.11 CD and see if that boots. The CD boots via emulated El Torito, meaning that it makes itself look like a floppy disk. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 04:35:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AF0016A407 for ; Fri, 7 Apr 2006 04:35:38 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E69043D53 for ; Fri, 7 Apr 2006 04:35:35 +0000 (GMT) (envelope-from bazzoola@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so428780pyc for ; Thu, 06 Apr 2006 21:35:34 -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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YR0g+q++cCbsiv+6XglhTiXb9I4jzcA7HtbhBRVshsokhaJyhqk4gUxhdAwDLrU3qAUGdYx5bEEgdJukvalzqYZbop+QXKSV/vmUaHu8SH/M6kkE/WjISD/XDRVjhg9f5tQA+00SdS5qQEW40xG5hZ2dzgqTrfqt0xij+J60GYM= Received: by 10.35.51.6 with SMTP id d6mr905890pyk; Thu, 06 Apr 2006 21:35:34 -0700 (PDT) Received: from ?192.168.1.9? ( [35.11.158.74]) by mx.gmail.com with ESMTP id f20sm285882pyf.2006.04.06.21.35.34; Thu, 06 Apr 2006 21:35:34 -0700 (PDT) Message-ID: <4435ED0B.6000006@gmail.com> Date: Fri, 07 Apr 2006 00:39:39 -0400 From: bazzoola User-Agent: Mail/News 1.5.0.2 (Macintosh/20060313) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4435BEA6.4060607@gmail.com> <4435E725.5060103@samsco.org> In-Reply-To: <4435E725.5060103@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 04:35:38 -0000 Scott Long wrote: > bazzoola wrote: > >> Maxim Sobolev wrote: >> > No, I don't think it's framebuffer issue, since FreeBSD CD starts >> > loading (I see message indicating that cdboot is trying to start >> > BOOT/LOADER on the screen). My guess is that Apple has only >> implemented >> > BIOS in amount necessary to bootstrap WinXP, while FreeBSD requires >> some >> > functionality that doesn't exist. >> > >> > -Maxim >> > >> > Frode Nordahl wrote: >> > > On 5. apr. 2006, at 16.09, Eric Anderson wrote: >> > > >> > >> Is this what is needed to get it booting FreeBSD? >> > >> >> > >> http://www.apple.com/macosx/bootcamp/ >> > > >> > > According to this: >> > > >> http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 >> >> > > >> > > >> > > The actual magic is in a Firmware update wich seems to add some >> Legacy >> > > BIOS support to make it work. Boot Camp is just a nice helper to >> resize >> > > your hard drive and provide some Windows drivers in a package :-) >> > > >> > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem >> to start >> > > booting, but I could not see anything, just a white / grey screen. >> > > >> > > I guess I need framebuffer support? >> > > >> > > I am downloading Fedora now and will give it a shot shortly. >> > > >> > > >> > > How would I go about building a FreeBSD CD with a framebuffer on >> it? :-) >> > > >> > > Frode Nordahl >> > > frode@nordahl.net >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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" >> > > >> > > >> >> I too tried booting FreeBSD 6.0 on a 2.0Ghz Macbook Pro with 1GB RAM >> I get the following >> >> >> CD Loader 1.2 >> >> Building the boot loader arguments >> Looking up /BOOT/LOADER... Found >> _ >> >> >> >> >> the cursor at the end is blinkin so fast. There isnt any activity. >> At least thats what I feel. > > Someone should pull out a 4.11 CD and see if that boots. The CD boots > via emulated El Torito, meaning that it makes itself look like a floppy > disk. > > Scott > > I tried 4.11 mininst iso it gives the following: _ Just a cursor that keeps blinking. No activity after that. From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 04:39:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D8E316A400 for ; Fri, 7 Apr 2006 04:39:10 +0000 (UTC) (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 8B0D043D45 for ; Fri, 7 Apr 2006 04:39:09 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k374d7Ir005875; Thu, 6 Apr 2006 22:39:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4435ECEB.5070902@samsco.org> Date: Thu, 06 Apr 2006 22:39:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bazzoola References: <4435BEA6.4060607@gmail.com> <4435E725.5060103@samsco.org> <4435ED0B.6000006@gmail.com> In-Reply-To: <4435ED0B.6000006@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 04:39:10 -0000 bazzoola wrote: > Scott Long wrote: > >> bazzoola wrote: >> >>> Maxim Sobolev wrote: >>> > No, I don't think it's framebuffer issue, since FreeBSD CD starts >>> > loading (I see message indicating that cdboot is trying to start >>> > BOOT/LOADER on the screen). My guess is that Apple has only >>> implemented >>> > BIOS in amount necessary to bootstrap WinXP, while FreeBSD requires >>> some >>> > functionality that doesn't exist. >>> > >>> > -Maxim >>> > >>> > Frode Nordahl wrote: >>> > > On 5. apr. 2006, at 16.09, Eric Anderson wrote: >>> > > >>> > >> Is this what is needed to get it booting FreeBSD? >>> > >> >>> > >> http://www.apple.com/macosx/bootcamp/ >>> > > >>> > > According to this: >>> > > >>> http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 >>> >>> > > >>> > > >>> > > The actual magic is in a Firmware update wich seems to add some >>> Legacy >>> > > BIOS support to make it work. Boot Camp is just a nice helper to >>> resize >>> > > your hard drive and provide some Windows drivers in a package :-) >>> > > >>> > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem >>> to start >>> > > booting, but I could not see anything, just a white / grey screen. >>> > > >>> > > I guess I need framebuffer support? >>> > > >>> > > I am downloading Fedora now and will give it a shot shortly. >>> > > >>> > > >>> > > How would I go about building a FreeBSD CD with a framebuffer on >>> it? :-) >>> > > >>> > > Frode Nordahl >>> > > frode@nordahl.net >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > 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" >>> > > >>> > > >>> >>> I too tried booting FreeBSD 6.0 on a 2.0Ghz Macbook Pro with 1GB RAM >>> I get the following >>> >>> >>> CD Loader 1.2 >>> >>> Building the boot loader arguments >>> Looking up /BOOT/LOADER... Found >>> _ >>> >>> >>> >>> >>> the cursor at the end is blinkin so fast. There isnt any activity. >>> At least thats what I feel. >> >> >> Someone should pull out a 4.11 CD and see if that boots. The CD boots >> via emulated El Torito, meaning that it makes itself look like a floppy >> disk. >> >> Scott >> >> > I tried 4.11 mininst iso it gives the following: > > _ > > > > Just a cursor that keeps blinking. No activity after that. > Oh well, thanks anyways for trying =-) Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 05:28:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E83616A400 for ; Fri, 7 Apr 2006 05:28:15 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B571043D46 for ; Fri, 7 Apr 2006 05:28:14 +0000 (GMT) (envelope-from bazzoola@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so435721pyc for ; Thu, 06 Apr 2006 22:28:13 -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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Yy4Fk8+Wcni7Q7zewTGqKvGpjXaT33K/vmrc4CA7LX+YjFzWLVmeTsYWYH9t5NYvoih6MI9tV+YZwVTGjEeGQ7jYhNDMfiUe+gx/NAdj03VOrQ1iu9aUWwz59zVllfQG/FxjEeN23FDVEr+dFiEIYv8mI+8NppPKcZ0RuS3JtDg= Received: by 10.35.12.13 with SMTP id p13mr354418pyi; Thu, 06 Apr 2006 22:28:13 -0700 (PDT) Received: from ?192.168.1.9? ( [35.11.158.74]) by mx.gmail.com with ESMTP id r66sm222258pye.2006.04.06.22.28.13; Thu, 06 Apr 2006 22:28:13 -0700 (PDT) Message-ID: <4435F95E.9000703@gmail.com> Date: Fri, 07 Apr 2006 01:32:14 -0400 From: bazzoola User-Agent: Mail/News 1.5.0.2 (Macintosh/20060313) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4435BEA6.4060607@gmail.com> <4435E725.5060103@samsco.org> <4435ED0B.6000006@gmail.com> <4435ECEB.5070902@samsco.org> In-Reply-To: <4435ECEB.5070902@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 05:28:15 -0000 Scott Long wrote: > bazzoola wrote: > >> Scott Long wrote: >> >>> bazzoola wrote: >>> >>>> Maxim Sobolev wrote: >>>> > No, I don't think it's framebuffer issue, since FreeBSD CD starts >>>> > loading (I see message indicating that cdboot is trying to start >>>> > BOOT/LOADER on the screen). My guess is that Apple has only >>>> implemented >>>> > BIOS in amount necessary to bootstrap WinXP, while FreeBSD >>>> requires some >>>> > functionality that doesn't exist. >>>> > >>>> > -Maxim >>>> > >>>> > Frode Nordahl wrote: >>>> > > On 5. apr. 2006, at 16.09, Eric Anderson wrote: >>>> > > >>>> > >> Is this what is needed to get it booting FreeBSD? >>>> > >> >>>> > >> http://www.apple.com/macosx/bootcamp/ >>>> > > >>>> > > According to this: >>>> > > >>>> http://forum.osx86project.org/index.php?s=&showtopic=14048&view=findpost&p=89523 >>>> >>>> > > >>>> > > >>>> > > The actual magic is in a Firmware update wich seems to add some >>>> Legacy >>>> > > BIOS support to make it work. Boot Camp is just a nice helper >>>> to resize >>>> > > your hard drive and provide some Windows drivers in a package :-) >>>> > > >>>> > > I just tried to boot FreeBSD on my MacBook Pro, and it did seem >>>> to start >>>> > > booting, but I could not see anything, just a white / grey screen. >>>> > > >>>> > > I guess I need framebuffer support? >>>> > > >>>> > > I am downloading Fedora now and will give it a shot shortly. >>>> > > >>>> > > >>>> > > How would I go about building a FreeBSD CD with a framebuffer >>>> on it? :-) >>>> > > >>>> > > Frode Nordahl >>>> > > frode@nordahl.net >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > 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" >>>> > > >>>> > > >>>> >>>> I too tried booting FreeBSD 6.0 on a 2.0Ghz Macbook Pro with 1GB RAM >>>> I get the following >>>> >>>> >>>> CD Loader 1.2 >>>> >>>> Building the boot loader arguments >>>> Looking up /BOOT/LOADER... Found >>>> _ >>>> >>>> >>>> >>>> >>>> the cursor at the end is blinkin so fast. There isnt any activity. >>>> At least thats what I feel. >>> >>> >>> Someone should pull out a 4.11 CD and see if that boots. The CD >>> boots via emulated El Torito, meaning that it makes itself look like >>> a floppy >>> disk. >>> >>> Scott >>> >>> >> I tried 4.11 mininst iso it gives the following: >> >> _ >> >> >> >> Just a cursor that keeps blinking. No activity after that. >> > > Oh well, thanks anyways for trying =-) > > Scott > > No Problem, I am willing to test any boot loader if anyone wants to write one that works for macintels Thanks From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 05:41:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 001C716A401 for ; Fri, 7 Apr 2006 05:41:45 +0000 (UTC) (envelope-from clcchu@hotmail.com) Received: from hotmail.com (bay112-f5.bay112.hotmail.com [64.4.26.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2147543D66 for ; Fri, 7 Apr 2006 05:41:41 +0000 (GMT) (envelope-from clcchu@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Apr 2006 22:41:41 -0700 Message-ID: Received: from 64.4.26.200 by by112fd.bay112.hotmail.msn.com with HTTP; Fri, 07 Apr 2006 05:41:38 GMT X-Originating-IP: [61.92.71.203] X-Originating-Email: [clcchu@hotmail.com] X-Sender: clcchu@hotmail.com From: "Clarence Chu" To: freebsd-current@freebsd.org Date: Fri, 07 Apr 2006 13:41:38 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Apr 2006 05:41:41.0540 (UTC) FILETIME=[F26FFE40:01C65A05] Subject: FYI: Mactel Run WinXP 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, 07 Apr 2006 05:41:46 -0000 hi all, starting from Apr 5, 2006., Mactel's Win/XP support may be found under Apple's support of Boot_Camp_Beta. related links to efi-booting, are as follows: elilo and reFit at sourceforge.net WinxponMac at mactel-linux.org Boot_Camp_Beta at apple.com i think the best approach of using FreeBSD under Mactel is to ask jkh@FreeBSD.org for some sort of assistance from Apple. don't you think so? Clarence CHU clcchu@hotmail.com _________________________________________________________________ Learn English via Shopping Game, FREE! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-03ETFJ-0211E From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 05:55:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A703B16A403 for ; Fri, 7 Apr 2006 05:55:52 +0000 (UTC) (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 1BABC43D46 for ; Fri, 7 Apr 2006 05:55:51 +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.4/8.13.4) with ESMTP id k375tg68006258; Thu, 6 Apr 2006 23:55:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4435FED7.8080201@samsco.org> Date: Thu, 06 Apr 2006 23:55:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Julian H. Stacey" References: <200604062326.k36NQxL5037240@fire.jhs.private> In-Reply-To: <200604062326.k36NQxL5037240@fire.jhs.private> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 05:55:52 -0000 Julian H. Stacey wrote: >>It is my great pleasure and privilege to announce the availability of >>FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN >>months of tireless work. > > > I was away over 1st April, & came back to a backlog of mail when > 1st April was no longer current, so didn't notice date for a few seconds, > & found the announcement rather weird but not necessarily totaly daft ;-) ... > FreeBSD-2.X is really obsolete, but some of us occasionaly > keep/ resuscitate obsolete hardware (eg for vintage purposes > http://vcfe.org/E/ ), one example: between FreeBSD-2 & 3 > I think support for some old 8 bit scsi controllers was > dumped, so old software can be attractive. > > So I checked on FTP site: no CHECKSUM.MD5, just a single file, 142 Meg > ( 142 186 496 ) > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/2.2.9-RELEASE.iso > > That .iso contains 620 files, I didnt try running it [yet .. maybe] > If it's some silly spoof, its quite elaborately big, if so, I'd > suggest reduce to a README to save a lot of mirror space & bandwidth. > Either way, a CHECKSUM.MD5 would be good. > The ISO image is valid, but we didn't do things like bump the version numbers, tag CVS, or build ports. I hand-edited the .TXT files available from FTP, but the same files in the ISO are the stock 2.2.8 ones. However, the release was built from the RELENG_2_2 tree, so it actually does incorporate the small handful of changes that went in after the 2.2.8 tag was laid down. It was a fun little trip in the Way-Back machine, and the announcement email was meant to poke some fun at that. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 06:04:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D087916A401 for ; Fri, 7 Apr 2006 06:04:26 +0000 (UTC) (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 2EA2E43D49 for ; Fri, 7 Apr 2006 06:04:26 +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.4/8.13.4) with ESMTP id k3764NHa006300; Fri, 7 Apr 2006 00:04:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <443600DF.10602@samsco.org> Date: Fri, 07 Apr 2006 00:04:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Julian H. Stacey" References: <200604062326.k36NQxL5037240@fire.jhs.private> <4435FED7.8080201@samsco.org> In-Reply-To: <4435FED7.8080201@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 06:04:26 -0000 Scott Long wrote: > Julian H. Stacey wrote: > >>> It is my great pleasure and privilege to announce the availability of >>> FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN >>> months of tireless work. >> >> >> >> I was away over 1st April, & came back to a backlog of mail when >> 1st April was no longer current, so didn't notice date for a few seconds, >> & found the announcement rather weird but not necessarily totaly daft >> ;-) ... >> FreeBSD-2.X is really obsolete, but some of us occasionaly >> keep/ resuscitate obsolete hardware (eg for vintage purposes >> http://vcfe.org/E/ ), one example: between FreeBSD-2 & 3 >> I think support for some old 8 bit scsi controllers was >> dumped, so old software can be attractive. >> >> So I checked on FTP site: no CHECKSUM.MD5, just a single file, 142 Meg >> ( 142 186 496 ) >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/2.2.9-RELEASE.iso >> >> >> That .iso contains 620 files, I didnt try running it [yet .. maybe] >> If it's some silly spoof, its quite elaborately big, if so, I'd >> suggest reduce to a README to save a lot of mirror space & bandwidth. >> Either way, a CHECKSUM.MD5 would be good. >> > > The ISO image is valid, but we didn't do things like bump the version > numbers, tag CVS, or build ports. I hand-edited the .TXT files > available from FTP, but the same files in the ISO are the stock 2.2.8 > ones. However, the release was built from the RELENG_2_2 tree, so it > actually does incorporate the small handful of changes that went in > after the 2.2.8 tag was laid down. It was a fun little trip in the > Way-Back machine, and the announcement email was meant to poke some fun > at that. > > Scott Btw, Ruslan Ermilov was the creative force behind all of this, he deserves 99% of the credit. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 08:34:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E476716A404 for ; Fri, 7 Apr 2006 08:34:13 +0000 (UTC) (envelope-from bln@deprese.net) Received: from hades.deprese.net (hades.deprese.net [81.2.209.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645EB43D45 for ; Fri, 7 Apr 2006 08:34:13 +0000 (GMT) (envelope-from bln@deprese.net) Received: from [192.168.1.194] (r2g242.chello.upc.cz [62.245.70.242]) by hades.deprese.net (Postfix) with ESMTP id 196BF33C22 for ; Fri, 7 Apr 2006 10:34:12 +0200 (CEST) Message-ID: <443623FB.2060109@deprese.net> Date: Fri, 07 Apr 2006 10:34:03 +0200 From: Ondra Holecek User-Agent: Thunderbird 1.5 (X11/20060213) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4435489E.9060105@deprese.net> <20060406204133.S30410@maildrop.int.zabbadoz.net> In-Reply-To: <20060406204133.S30410@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: serial port 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, 07 Apr 2006 08:34:14 -0000 i used the structure from netbsd (it is SUNIX 407X 2S/1P), but it still doesn't work. i still can read data from serial port but cannot write Ondra Bjoern A. Zeeb wrote: >> >> puc0@pci0:17:0: class=0x070002 card=0x50791409 chip=0x71681409 >> rev=0x01 hdr=0x00 > > serach for the matching entry in > http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/dev/pci/pucdata.c?rev=1.44&content-type=text/plain > > > if you only have 2xserial and no parallel it's most likely the > SUNIX 403X 2S. > > we should really sync with NetBSD... > From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 10:00:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CE4416A401 for ; Fri, 7 Apr 2006 10:00:45 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8382843D48 for ; Fri, 7 Apr 2006 10:00:44 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A4CEC.dip.t-dialin.net [84.154.76.236]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k37A0fC5020236; Fri, 7 Apr 2006 12:00:42 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k37A0Z9J010321; Fri, 7 Apr 2006 12:00:35 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k37A1GAw075536; Fri, 7 Apr 2006 12:01:16 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200604071001.k37A1GAw075536@fire.jhs.private> To: Scott Long In-Reply-To: Message from Scott Long of "Thu, 06 Apr 2006 23:55:35 MDT." <4435FED7.8080201@samsco.org> Date: Fri, 07 Apr 2006 12:01:16 +0200 From: "Julian H. Stacey" Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 10:00:45 -0000 Scott Long wrote: > The ISO image is valid, but we didn't do things like bump the version > numbers, tag CVS, or build ports. I hand-edited the .TXT files > available from FTP, but the same files in the ISO are the stock 2.2.8 > ones. However, the release was built from the RELENG_2_2 tree, so it > actually does incorporate the small handful of changes that went in > after the 2.2.8 tag was laid down. It was a fun little trip in the > Way-Back machine, and the announcement email was meant to poke some fun > at that. > Btw, Ruslan Ermilov was the creative force behind all of this, he > deserves 99% of the credit. Hi Scott, cc list Thanks for explanation, perhaps you might create ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/CHECKSUM.MD5 with MD5 (2.2.9-RELEASE.iso) = fba4c8fa17bf9d8210a0989ca6cc57f9 perhaps appending your text summary above to eg ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/README -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 11:37:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07DBA16A406 for ; Fri, 7 Apr 2006 11:37:47 +0000 (UTC) (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 DE8FB43D78 for ; Fri, 7 Apr 2006 11:37:31 +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 k37BbUdD083083; Fri, 7 Apr 2006 14:37:30 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ip.net.ua [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 65587-03; Fri, 7 Apr 2006 14:37:00 +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 k37Bamcs083054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Apr 2006 14:36:49 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.6/8.13.6) id k37BamSW061536; Fri, 7 Apr 2006 14:36:48 +0300 (EEST) (envelope-from ru) Date: Fri, 7 Apr 2006 14:36:48 +0300 From: Ruslan Ermilov To: Scot Hetzel Message-ID: <20060407113647.GB89618@ip.net.ua> References: <4c40c4e70604051044o719a72bct418364312fa66b40@mail.gmail.com> <790a9fff0604051143q50bfc350j4e3c2060a77d2280@mail.gmail.com> <4c40c4e70604051150s4d033473wbfe3ddf6e40ec281@mail.gmail.com> <790a9fff0604051157r349cf2c7q17aa17d94f2cce66@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <790a9fff0604051157r349cf2c7q17aa17d94f2cce66@mail.gmail.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at ip.net.ua Cc: "Angka H. K." , freebsd-current@freebsd.org Subject: Re: Make distribution 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: Fri, 07 Apr 2006 11:37:47 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2006 at 01:57:43PM -0500, Scot Hetzel wrote: > On 4/5/06, Angka H. K. wrote: > > Ups... > > > > But regarding to "UPDATING" on 7.0 source it still say "cd src/etc; make > > distribution DESTDIR=3D${CURRENT_ROOT} # if newfs'd". Should it be chan= ge ? > > > > > Yes, that needs to be changed. >=20 Fixed. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFENk7PqRfpzJluFF4RAo0TAJ9YG9J8YfAyWzCCL6LHY61MMSK2NACePZkZ JAZHLaG/9MSK335+ZbXlVTw= =0HUP -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 11:45:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05FC016A400 for ; Fri, 7 Apr 2006 11:45:17 +0000 (UTC) (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 3839B43D6E for ; Fri, 7 Apr 2006 11:45:12 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FRpOd-00083F-SQ for freebsd-current@freebsd.org; Fri, 07 Apr 2006 13:44:59 +0200 Received: from www.creo.hu ([217.113.62.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Apr 2006 13:44:59 +0200 Received: from csaba-ml by www.creo.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Apr 2006 13:44:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Csaba Henk Date: Fri, 7 Apr 2006 11:44:47 +0000 (UTC) Lines: 19 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: www.creo.hu User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 11:45:17 -0000 Hi! Compiling a threaded program foo with "-pthread", if I want to run it like LD_LIBMAP=libpthread.so.2=libc_r.so foo then it will complain /libexec/ld-elf.so.1: /usr/lib/libc_r.so: version LIBTHREAD_1_0 required by foo not defined I know it's because symbol versioning has entered the scene... I just wonder if there is some workaround... Some way to trasparently switch between threading libs? Thanks! Regards, Csaba From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 13:11:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 891EC16A405 for ; Fri, 7 Apr 2006 13:11:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2BE043D67 for ; Fri, 7 Apr 2006 13:10:59 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k37DAuVj020194; Fri, 7 Apr 2006 09:10:56 -0400 (EDT) Date: Fri, 7 Apr 2006 09:10:56 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Csaba Henk In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 13:11:00 -0000 On Fri, 7 Apr 2006, Csaba Henk wrote: > Hi! > > Compiling a threaded program foo with "-pthread", if I want to run it > like > > LD_LIBMAP=libpthread.so.2=libc_r.so foo > > then it will complain > > /libexec/ld-elf.so.1: /usr/lib/libc_r.so: version LIBTHREAD_1_0 required by foo not defined > > I know it's because symbol versioning has entered the scene... I just > wonder if there is some workaround... Some way to trasparently switch > between threading libs? Only between libthr and libpthread. libc_r doesn't have symbol versioning. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 14:08:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76F3516A403; Fri, 7 Apr 2006 14:08:31 +0000 (UTC) (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 B9FA943D55; Fri, 7 Apr 2006 14:08:30 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.4/8.13.4) with ESMTP id k37E897u022951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Apr 2006 16:08:09 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.4/8.13.4/Submit) id k37E893F022950; Fri, 7 Apr 2006 16:08:09 +0200 (CEST) (envelope-from csaba) Date: Fri, 7 Apr 2006 16:08:09 +0200 From: Csaba Henk To: Daniel Eischen Message-ID: <20060407140809.GZ1323@beastie.creo.hu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 14:08:31 -0000 On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: > Only between libthr and libpthread. libc_r doesn't have symbol > versioning. That's sad -- given, as noted elsewhere, libc_r is the best suitable for tracing. Will it remain like this or can we expect a symver'd libc_r in due time? Regards, Csaba From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 16:55:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED6F416A400 for ; Fri, 7 Apr 2006 16:55:27 +0000 (UTC) (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 73CCE43D55 for ; Fri, 7 Apr 2006 16:55:27 +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; Fri, 07 Apr 2006 09:55:22 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8B78C45046; Fri, 7 Apr 2006 09:55:21 -0700 (PDT) To: Scott Long In-reply-to: Your message of "Fri, 07 Apr 2006 00:04:15 MDT." <443600DF.10602@samsco.org> Date: Fri, 07 Apr 2006 09:55:21 -0700 From: "Kevin Oberman" Message-Id: <20060407165521.8B78C45046@ptavv.es.net> Cc: freebsd-current@freebsd.org, "Julian H. Stacey" Subject: Re: FreeBSD 2.2.9 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 16:55:28 -0000 > Date: Fri, 07 Apr 2006 00:04:15 -0600 > From: Scott Long > Sender: owner-freebsd-current@freebsd.org > > Scott Long wrote: > > Julian H. Stacey wrote: > > > >>> It is my great pleasure and privilege to announce the availability of > >>> FreeBSD 2.2.9-RELEASE. This release is the culmination of SEVENTY-SEVEN > >>> months of tireless work. > >> > >> > >> > >> I was away over 1st April, & came back to a backlog of mail when > >> 1st April was no longer current, so didn't notice date for a few seconds, > >> & found the announcement rather weird but not necessarily totaly daft > >> ;-) ... > >> FreeBSD-2.X is really obsolete, but some of us occasionaly > >> keep/ resuscitate obsolete hardware (eg for vintage purposes > >> http://vcfe.org/E/ ), one example: between FreeBSD-2 & 3 > >> I think support for some old 8 bit scsi controllers was > >> dumped, so old software can be attractive. > >> > >> So I checked on FTP site: no CHECKSUM.MD5, just a single file, 142 Meg > >> ( 142 186 496 ) > >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/2.2.9/2.2.9-RELEASE.iso > >> > >> > >> That .iso contains 620 files, I didnt try running it [yet .. maybe] > >> If it's some silly spoof, its quite elaborately big, if so, I'd > >> suggest reduce to a README to save a lot of mirror space & bandwidth. > >> Either way, a CHECKSUM.MD5 would be good. > >> > > > > The ISO image is valid, but we didn't do things like bump the version > > numbers, tag CVS, or build ports. I hand-edited the .TXT files > > available from FTP, but the same files in the ISO are the stock 2.2.8 > > ones. However, the release was built from the RELENG_2_2 tree, so it > > actually does incorporate the small handful of changes that went in > > after the 2.2.8 tag was laid down. It was a fun little trip in the > > Way-Back machine, and the announcement email was meant to poke some fun > > at that. > > > > Scott > > Btw, Ruslan Ermilov was the creative force behind all of this, he > deserves 99% of the credit. While I'm sure Ruslan was involved, I suspect that the real credit belongs to Sniffy The Wonder Cat. I know that my cat, Sam, has had input on a lot of my work, but his code seems even less well structured than mine and is very poorly formatted. Clearly Sniffy is much better at it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 17:19:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A103916A405 for ; Fri, 7 Apr 2006 17:19:36 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web30715.mail.mud.yahoo.com (web30715.mail.mud.yahoo.com [68.142.201.253]) by mx1.FreeBSD.org (Postfix) with SMTP id EBB9E43D55 for ; Fri, 7 Apr 2006 17:19:35 +0000 (GMT) (envelope-from neshort@yahoo.com) Received: (qmail 91469 invoked by uid 60001); 7 Apr 2006 17:19:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iyu2/Z/1QgHoEkQmDntD8FxcWxKmi6vA+kUrn178lQRSM8LbP0wQAg/O4k2NOFRFPJJ1q6EJdx35BbGa2Jnbodvnu6EnkpurLtnpKFEvpgN+UjunuBc3ojTcVfhy/uIlAq38oAatWNxL/yFA8td8r2WHj7aJp3PgNY2XofIyzMQ= ; Message-ID: <20060407171935.91467.qmail@web30715.mail.mud.yahoo.com> Received: from [208.240.243.170] by web30715.mail.mud.yahoo.com via HTTP; Fri, 07 Apr 2006 10:19:35 PDT Date: Fri, 7 Apr 2006 10:19:35 -0700 (PDT) From: Neil Short To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Chris@lainos.org Subject: fglrx ATI driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 17:19:36 -0000 Has anybody had success with the fglrx driver? I had some difficulty building it since the qt33 port is hiccupping and this build tries to add a KDE icon - but I don't use KDE. doing: X -configure gives a bunch of lines that say... Symbol firegl_PM4Alloc from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! My graphics device is detected as: "RC410 [Radeon Xpress 200M]" BusID is "PCI:1:5:0" running FBSD current on Toshiba A105-S301 laptop. ====== Now I, Nebuchadnezzar, praise and extol and honor the King of heaven, for all his works are truth, and his ways are justice; and he is able to bring low those who walk in pride. Daniel 4:37 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:17:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F02FF16A403; Fri, 7 Apr 2006 18:17:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outbound7.internet-mail-service.net (outbound7.internet-mail-service.net [216.240.47.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A8CC43D46; Fri, 7 Apr 2006 18:17:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id DBC4A24E067; Fri, 7 Apr 2006 11:17:15 -0700 (PDT) Received: from [10.251.19.131] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id k37IHF0U017557; Fri, 7 Apr 2006 11:17:15 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4436ACA3.3000507@elischer.org> Date: Fri, 07 Apr 2006 11:17:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Csaba Henk References: <20060407140809.GZ1323@beastie.creo.hu> In-Reply-To: <20060407140809.GZ1323@beastie.creo.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 18:17:17 -0000 Csaba Henk wrote: >On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: > > >>Only between libthr and libpthread. libc_r doesn't have symbol >>versioning. >> >> > >That's sad -- given, as noted elsewhere, libc_r is the best suitable >for tracing. > >Will it remain like this or can we expect a symver'd libc_r >in due time? > >Regards, >Csaba >_______________________________________________ >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" > > Dan, maybe we can make an option where libc_r degrades down to one kse somehow then it would probable be more traceable. Csaba Henk.. Mit jelent "tracing"? pontosan? gdb vagy valamit mas? From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:21:53 2006 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 7884116A403; Fri, 7 Apr 2006 18:21:53 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA89F43D49; Fri, 7 Apr 2006 18:21:52 +0000 (GMT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (ns01.locore.org [218.45.21.227]) by locore.org (8.13.1/8.13.1/iwasaki) with ESMTP/inet id k37ILo7a076042; Sat, 8 Apr 2006 03:21:50 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sat, 08 Apr 2006 03:21:51 +0900 (JST) Message-Id: <20060408.032151.07645075.iwasaki@jp.FreeBSD.org> To: acpi@freebsd.org, current@freebsd.org From: Mitsuru IWASAKI X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: CFR: ACPI Dock driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 18:21:53 -0000 Hi all I wrote ACPI Dock driver for RELENG_6 and put at http://www.freebsd.org/~iwasaki/acpi/acpi_dock-RELENG_6-20060408.tar.gz Please review and test it. Testing was done on ThinkPad X40 and X4 UltraBase. BTW, I'm trying to port this for 7-CURRENT, but the ACPICA function AcpiNsInitOneDevice() is no longer public in newer version of ACPICA. Any hints? Note: ATA devices are not dock-aware, so you need to detach ATA devices by `atacontrol detach ata1' before undocking, otherwise the system will freeze. # I had not idea where to add DEVMETHOD(device_detach, ata_detach)... Thanks From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:25:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7141B16A402 for ; Fri, 7 Apr 2006 18:25:32 +0000 (UTC) (envelope-from ahebert@pubnix.net) Received: from mail.pubnix.net (Mail.pubnix.net [192.172.250.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D66CC43D7B for ; Fri, 7 Apr 2006 18:25:31 +0000 (GMT) (envelope-from ahebert@pubnix.net) Received: from [10.0.1.2] (aal.pubnix.net [64.235.216.13]) (authenticated bits=0) by mail.pubnix.net (8.13.6/8.13.6) with ESMTP id k37IPTSo042066 for ; Fri, 7 Apr 2006 14:25:30 -0400 (EDT) (envelope-from ahebert@pubnix.net) Message-ID: <4436AE99.7000600@pubnix.net> Date: Fri, 07 Apr 2006 14:25:29 -0400 From: Alain Hebert Organization: PubNIX, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060407171935.91467.qmail@web30715.mail.mud.yahoo.com> In-Reply-To: <20060407171935.91467.qmail@web30715.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: fglrx ATI driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahebert@pubnix.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 18:25:32 -0000 Hi, Can I make a suggestion? (Don't wanna start a flame war, just my opinion) Drop ATI for nVidia. ----- I was using and yes, hooked, on ATI since their VGA Wonder and more with their 8514 compatible card (for which I found a way to make it work with X11R4 btw, dont know if its still there ... lookup aal@broue.rot.qc.ca). But ATI close/limited access/"got snob" the developer channels and stop providing documentation under the excuse that its propriatory informations (yeah sure... come on). So my ATI contacts dried up, no way to get a NDA to get that documentation, and even then, there is no TV documentation, and 3D is limited. So bye, bye ATI. ----- I got a nVidia 6600 and since nVidia support FreeBSD natively its a breeze. (With 3D!) Now TV is coming from a low cost bktr card and I'm happy. Neil Short wrote: >Has anybody had success with the fglrx driver? >I had some difficulty building it since the qt33 port >is hiccupping and this build tries to add a KDE icon - >but I don't use KDE. > >doing: >X -configure >gives a bunch of lines that say... >Symbol firegl_PM4Alloc from module >/usr/X11R6/lib/modules/drivers/fglrx_drv.o is >unresolved! > >My graphics device is detected as: >"RC410 [Radeon Xpress 200M]" > >BusID is "PCI:1:5:0" > >running FBSD current on Toshiba A105-S301 laptop. > >====== >Now I, Nebuchadnezzar, praise and extol and honor the King of heaven, for all his works are truth, and his ways are justice; and he is able to bring low those who walk in pride. >Daniel 4:37 > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >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" > > > -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443 From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:33:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93B7E16A400 for ; Fri, 7 Apr 2006 18:33:38 +0000 (UTC) (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 96E0143D48 for ; Fri, 7 Apr 2006 18:33:37 +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 k37IXZiu056548; Fri, 7 Apr 2006 13:33:36 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4436B072.90700@centtech.com> Date: Fri, 07 Apr 2006 13:33:22 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060402) MIME-Version: 1.0 To: ahebert@pubnix.net References: <20060407171935.91467.qmail@web30715.mail.mud.yahoo.com> <4436AE99.7000600@pubnix.net> In-Reply-To: <4436AE99.7000600@pubnix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1381/Fri Apr 7 07:54:35 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: fglrx ATI driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 18:33:38 -0000 Alain Hebert wrote: > Hi, > > Can I make a suggestion? (Don't wanna start a flame war, just my > opinion) > > Drop ATI for nVidia. Great idea! Maybe you can now write a how-to on swapping out the video card on laptops? :) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:37:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2159516A403 for ; Fri, 7 Apr 2006 18:37:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8789743D55 for ; Fri, 7 Apr 2006 18:37:05 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k37Iax4e007508; Fri, 7 Apr 2006 14:36:59 -0400 (EDT) Date: Fri, 7 Apr 2006 14:36:59 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <4436ACA3.3000507@elischer.org> Message-ID: References: <20060407140809.GZ1323@beastie.creo.hu> <4436ACA3.3000507@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Csaba Henk , freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 18:37:06 -0000 On Fri, 7 Apr 2006, Julian Elischer wrote: > Csaba Henk wrote: > >> On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: >> >>> Only between libthr and libpthread. libc_r doesn't have symbol >>> versioning. >>> >> >> That's sad -- given, as noted elsewhere, libc_r is the best suitable >> for tracing. >> >> Will it remain like this or can we expect a symver'd libc_r >> in due time? >> >> Regards, >> Csaba >> _______________________________________________ >> 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" >> > Dan, maybe we can make an option where libc_r degrades down to one kse > somehow > then it would probable be more traceable. You mean like: $ sudo sysctl kern.threads.virtual_cpu=1 and, or $ LIBPTHREAD_PROCESS_SCOPE=yes; export LIBPTHREAD_PROCESS_SCOPE ?? -- DE From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 18:52:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 648B516A400 for ; Fri, 7 Apr 2006 18:52:11 +0000 (UTC) (envelope-from ahebert@pubnix.net) Received: from mail.pubnix.net (Mail.pubnix.net [192.172.250.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F323843D45 for ; Fri, 7 Apr 2006 18:52:10 +0000 (GMT) (envelope-from ahebert@pubnix.net) Received: from [10.0.1.2] (aal.pubnix.net [64.235.216.13]) (authenticated bits=0) by mail.pubnix.net (8.13.6/8.13.6) with ESMTP id k37Iq9ku072142 for ; Fri, 7 Apr 2006 14:52:10 -0400 (EDT) (envelope-from ahebert@pubnix.net) Message-ID: <4436B4D9.6030203@pubnix.net> Date: Fri, 07 Apr 2006 14:52:09 -0400 From: Alain Hebert Organization: PubNIX, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060407171935.91467.qmail@web30715.mail.mud.yahoo.com> <4436AE99.7000600@pubnix.net> <4436B072.90700@centtech.com> In-Reply-To: <4436B072.90700@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: fglrx ATI driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahebert@pubnix.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 18:52:11 -0000 No problem, It will involve manual labor (5 pounds hammer) and a lot of dexterity. (; Eric Anderson wrote: > Alain Hebert wrote: > >> Hi, >> >> Can I make a suggestion? (Don't wanna start a flame war, just my >> opinion) >> >> Drop ATI for nVidia. > > > > Great idea! Maybe you can now write a how-to on swapping out the > video card on laptops? :) > > > Eric > > > > -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443 From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 19:44:31 2006 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 B332916A400 for ; Fri, 7 Apr 2006 19:44:31 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFB943D48 for ; Fri, 7 Apr 2006 19:44:31 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from [10.7.6.254] ([63.76.235.163]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id k37JiEBC067838; Fri, 7 Apr 2006 15:44:14 -0400 (EDT) (envelope-from andy@siliconlandmark.com) In-Reply-To: <443310BF.4030600@elischer.org> References: <443310BF.4030600@elischer.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Fri, 7 Apr 2006 15:43:03 -0400 To: Julian Elischer X-Mailer: Apple Mail (2.749.3) X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-1.457, required 6, BAYES_00 -2.60, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Cc: current@freebsd.org Subject: Re: change to syslog to allow specifying prot to send to.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 19:44:31 -0000 On Apr 4, 2006, at 8:35 PM, Julian Elischer wrote: > Does anyone think that this would be useful? > > the syslog.conf line would look like: > > > *.* @logger.mynet.com:823 Off the top of my head, there are two scenarios that I see this useful in: - Forwarding log messages to a secure syslog server, on a non- privileged port (I think everyone agrees that reducing the number of root-run services is a good thing). - Logging to a remote syslog over a local port, forwarded over an ssh tunnel (To an off-site centralized logging server, for example), while still having local logging enabled. I have been looking for this type of functionality for a little while now. I was about to look into coding it. Thanks! :) Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 19:53:14 2006 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 DDF8816A400 for ; Fri, 7 Apr 2006 19:53:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outbound7.internet-mail-service.net (outbound7.internet-mail-service.net [216.240.47.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8356543D79 for ; Fri, 7 Apr 2006 19:53:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id 2DC6F24DCF4; Fri, 7 Apr 2006 12:53:12 -0700 (PDT) Received: from [10.251.19.131] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id k37JrBFd090488; Fri, 7 Apr 2006 12:53:11 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4436C31A.80006@elischer.org> Date: Fri, 07 Apr 2006 12:52:58 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <443310BF.4030600@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: change to syslog to allow specifying prot to send to.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 19:53:14 -0000 Andre Guibert de Bruet wrote: > On Apr 4, 2006, at 8:35 PM, Julian Elischer wrote: > >> Does anyone think that this would be useful? >> >> the syslog.conf line would look like: >> >> >> *.* @logger.mynet.com:823 > > > Off the top of my head, there are two scenarios that I see this > useful in: > - Forwarding log messages to a secure syslog server, on a non- > privileged port (I think everyone agrees that reducing the number of > root-run services is a good thing). > - Logging to a remote syslog over a local port, forwarded over an ssh > tunnel (To an off-site centralized logging server, for example), > while still having local logging enabled. > > I have been looking for this type of functionality for a little while > now. I was about to look into coding it. Thanks! :) the first part of the patch is not required.... Included by accident. > > Andy > > /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ > /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ > /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 21:03:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2C7316A401; Fri, 7 Apr 2006 21:03:36 +0000 (UTC) (envelope-from rwatosn@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F17B43D53; Fri, 7 Apr 2006 21:03:36 +0000 (GMT) (envelope-from rwatosn@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8269C46B0E; Fri, 7 Apr 2006 17:03:35 -0400 (EDT) Date: Fri, 7 Apr 2006 22:03:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Csaba Henk In-Reply-To: <20060407140809.GZ1323@beastie.creo.hu> Message-ID: <20060407220302.Y21361@fledge.watson.org> References: <20060407140809.GZ1323@beastie.creo.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Apr 2006 21:03:36 -0000 On Fri, 7 Apr 2006, Csaba Henk wrote: > On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: >> Only between libthr and libpthread. libc_r doesn't have symbol >> versioning. > > That's sad -- given, as noted elsewhere, libc_r is the best suitable for > tracing. > > Will it remain like this or can we expect a symver'd libc_r in due time? BTW, I've found libthr works quite well with ktrace, now that it has thread ID support. Make sure to use -H with kdump. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Apr 7 21:28:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7951D16A402 for ; Fri, 7 Apr 2006 21:28:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AF043D48 for ; Fri, 7 Apr 2006 21:28:43 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k37LSfLh024091; Fri, 7 Apr 2006 17:28:41 -0400 (EDT) Date: Fri, 7 Apr 2006 17:28:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Csaba Henk In-Reply-To: <20060407140809.GZ1323@beastie.creo.hu> Message-ID: References: <20060407140809.GZ1323@beastie.creo.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 21:28:44 -0000 On Fri, 7 Apr 2006, Csaba Henk wrote: > On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: >> Only between libthr and libpthread. libc_r doesn't have symbol >> versioning. > > That's sad -- given, as noted elsewhere, libc_r is the best suitable > for tracing. > > Will it remain like this or can we expect a symver'd libc_r > in due time? Does this work for you: http://people.freebsd.org/~deischen/symver/libc_r.symver.diffs ? -- DE From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 02:09:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C052816A402 for ; Sat, 8 Apr 2006 02:09:26 +0000 (UTC) (envelope-from casper@web.am) Received: from mx1.web.am (mx1.web.am [217.113.0.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5BFD43D46 for ; Sat, 8 Apr 2006 02:09:25 +0000 (GMT) (envelope-from casper@web.am) Received: from antispam (localhost.web.am [127.0.0.1]) by localhost (Postfix) with ESMTP id 24FA661C1E for ; Sat, 8 Apr 2006 07:09:14 +0500 (AMST) Received: from localhost (localhost.web.am [127.0.0.1]) by localhost (Postfix) with SMTP id A127861C0E; Sat, 8 Apr 2006 07:09:13 +0500 (AMST) Received: from [192.168.0.2] (unknown [217.113.1.123]) by mx1.web.am (Postfix) with ESMTP id 636EA61C05; Sat, 8 Apr 2006 07:09:13 +0500 (AMST) Message-ID: <44371B4F.5090504@web.am> Date: Sat, 08 Apr 2006 07:09:19 +0500 From: Gaspar Chilingarov Organization: Netter Ltd. User-Agent: Thunderbird 1.5 (X11/20060329) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.web.am X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.60 X-Spam-Level: Cc: Subject: /sys/i386/acpica/acpi_machdep.c - source code clarification 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: Sat, 08 Apr 2006 02:09:26 -0000 Hi! I'm trying to implement acpi support (I'm interested in s3 level) on amd64 platform and now working on porting code from i386. I'm really missing something why there are apm device creation and emulation in acpi_machdep.c? Is it to provide some apm-compatible way to view battery information or it's used (in some hidden way) for some other purposes elsewhere? Also I would like ask some of gurus and acpi developers to let me know who should contacted with implementation questions -- this may be offlist communication :) x-posted in freebsd-acpi,freebsd-current. Thanks in advance, Gaspar Chilingarov From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 04:43:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C56716A401; Sat, 8 Apr 2006 04:43:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11DE343D48; Sat, 8 Apr 2006 04:43:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k384gp23098463; Fri, 7 Apr 2006 22:42:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 07 Apr 2006 22:42:52 -0600 (MDT) Message-Id: <20060407.224252.32174177.imp@bsdimp.com> To: casper@web.am From: "M. Warner Losh" In-Reply-To: <44371B4F.5090504@web.am> References: <44371B4F.5090504@web.am> 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-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: /sys/i386/acpica/acpi_machdep.c - source code clarification 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: Sat, 08 Apr 2006 04:43:32 -0000 In message: <44371B4F.5090504@web.am> Gaspar Chilingarov writes: : I'm really missing something why there are apm device creation and : emulation in acpi_machdep.c? Is it to provide some apm-compatible way : to view battery information or it's used (in some hidden way) for some : other purposes elsewhere? Former. It is just a compat interface for battery programs. Warner From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 05:42:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D05A216A405; Sat, 8 Apr 2006 05:42:52 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 8 Apr 2006 13:42:36 +0800 User-Agent: KMail/1.8.2 References: <20060407140809.GZ1323@beastie.creo.hu> In-Reply-To: <20060407140809.GZ1323@beastie.creo.hu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604081342.36295.davidxu@freebsd.org> Cc: Csaba Henk , Daniel Eischen Subject: Re: switching threading libraries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 05:42:53 -0000 On Friday 07 April 2006 22:08, Csaba Henk wrote: > On Fri, Apr 07, 2006 at 09:10:56AM -0400, Daniel Eischen wrote: > > Only between libthr and libpthread. libc_r doesn't have symbol > > versioning. > > That's sad -- given, as noted elsewhere, libc_r is the best suitable > for tracing. > > Will it remain like this or can we expect a symver'd libc_r > in due time? > > Regards, > Csaba libc_r does not have debugger can be used, libthr and libpthread do have. libthr can use ktrace to print thread ID, libthr can use top to observe a thread blocked on what event, I don't believe libc_r is best tracable. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 08:12:48 2006 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 6D29C16A400; Sat, 8 Apr 2006 08:12:48 +0000 (UTC) (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 C9EEB43D45; Sat, 8 Apr 2006 08:12:47 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:/+1m73LIGH4/qW5Th7DjbqhXvrPa63yu9zp042+tV71kSDrebj5N0+bq271If0ji@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.6/8.13.6) with ESMTP/inet6 id k388Cfqj078205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 17:12:42 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 08 Apr 2006 17:12:41 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@FreeBSD.org, current@FreeBSD.org In-Reply-To: References: User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-PRERELEASE 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.1.3 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 08 Apr 2006 17:12:42 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ameno.mahoroba.org Cc: Subject: Re: [CFR] exposable reentrant functions of netdb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 08:12:48 -0000 Hi, >>>>> On Wed, 05 Apr 2006 03:04:04 +0900 >>>>> Hajimu UMEMOTO said: ume> I reworked the netdb functions in our libc to conform to the Solaris's ume> API. With this change, we can expose get*_r(3) to the outside of ume> libc. Further, I changed the internal of gethostby*(3) and ume> getnetby*(3) to NSS friendly. It came to be thought that it was better to use glibc style API at the end about which it thought for a while. Because, glibc style API is more similar to getpw*_r(3) which is defined in POSIX. So, I changed to use glibc style API. You can get the patch from: http://www.imasy.or.jp/~ume/FreeBSD/netdb-glibc-api-20060407.diff.gz 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 Sat Apr 8 09:04:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E076116A400 for ; Sat, 8 Apr 2006 09:04:13 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C4D543D4C for ; Sat, 8 Apr 2006 09:04:13 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so544871nzf for ; Sat, 08 Apr 2006 02:04:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=m42TG7WS9qSRHhRX+goIvmRN558MNljS8uAe4Pcz0K/tcjdW1p563e/sY2R/uqRNip1MFeBLR6q/9GaMmg4uyxBtQP8oYbXXED9HOUyZXGNc0L3yyc0nsSwATTYtSCfo/ZQ+n7/2Ebe+mq5IjQQl82j9I+3H1Pmb5+VM4ai17I0= Received: by 10.36.12.13 with SMTP id 13mr1712276nzl; Sat, 08 Apr 2006 02:04:12 -0700 (PDT) Received: by 10.36.133.10 with HTTP; Sat, 8 Apr 2006 02:04:12 -0700 (PDT) Message-ID: <7daacbbe0604080204q1d8b8995kbadc61eb1461eefd@mail.gmail.com> Date: Sat, 8 Apr 2006 11:04:12 +0200 From: "Dominique Goncalves" 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: PS/2 keyboard not working in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 09:04:14 -0000 Hi, With FreeBSD 7.0-CURRENT, I can't type anything with my PS/2 keyboard when I enter in ddb (ctrl+alt+esc) in the prompt 'db>'. A work around is to boot with 'Boot FreeBSD in safe mode' menu 3. Regards. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 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 #0: Fri Apr 7 20:49:09 CEST 2006 root@djdomics.sceen.net:/usr/obj/share/src/FreeBSD/HEAD/src/sys/FREESBI= E WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x673 Stepping =3D 3 Features=3D0x387f9ff real memory =3D 134205440 (127 MB) avail memory =3D 121573376 (115 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ACPI disabled by blacklist. Contact your BIOS vendor. cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37 6,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xd400-0xd41f irq 10 at de vice 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered piix0: port 0xe800-0xe80f at device 4.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 fxp0: port 0xd000-0xd01f mem 0xe3800000-0xe3800ff f,0xe1800000-0xe18fffff irq 11 at device 11.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:90:27:26:49:2f vgapci0: mem 0xe2800000-0xe2bfffff at device 12.0 on pc i0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on= isa0 fdc0: [FAST] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio0: [FAST] sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: [FAST] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 501138835 Hz quality 800 Timecounters tick every 1.000 msec ad2: 9641MB at ata1-master UDMA33 acd0: CDROM at ata1-slave PIO4 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 GEOcd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: cd present [81386 x 2048 byte records] M_LABEL: Label for provider acd0 is iso9660/FreeSBIE. acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 acd0: FAILURE - READ _BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 (cd0:ata1:0:1:0): READ(10). CDB: 28 0 0 1 3d e9 0 0 1 0 (cd0:ata1:0:1:0): CAM Status: SCSI Status Error (cd0:ata1:0:1:0): SCSI Status: Check Condition (cd0:ata1:0:1:0): ILLEGAL REQUEST asc:64,0 (cd0:ata1:0:1:0): Illegal mode for this track (cd0:ata1:0:1:0): Unretryable error (cd0:ata1:0:1:0): cddone: got error 0x6 back Trying to mount root from cd9660:/dev/iso9660/FreeSBIE KDB: enter: manual escape to debugger [thread pid 18 tid 100008 ] Stopped at kdb_enter+0x2b: nop db> -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 09:46:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C65616A401 for ; Sat, 8 Apr 2006 09:46:12 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BFD243D4C for ; Sat, 8 Apr 2006 09:46:11 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so548462nzf for ; Sat, 08 Apr 2006 02:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gmq1+fzXufCg5M+mxQjF7UJU/F0n2FSmr7F8+zFpaTzduKY3DwShukuzF+ojWbUKWNU5pYVhZYAoNOCWSYcGMFZr4wwxihovKnyls5EJOMANUePxkuPykX5ZG8j11/6HH55ol4m2pC7T9eW0gpi4rOuIXYKhCDm51ELdrMCLdS8= Received: by 10.36.251.76 with SMTP id y76mr894235nzh; Sat, 08 Apr 2006 02:46:10 -0700 (PDT) Received: by 10.36.133.10 with HTTP; Sat, 8 Apr 2006 02:46:10 -0700 (PDT) Message-ID: <7daacbbe0604080246g61db2c5am88ec86d9d20f6e64@mail.gmail.com> Date: Sat, 8 Apr 2006 11:46:10 +0200 From: "Dominique Goncalves" To: "=?ISO-8859-1?Q?Bj=F6rn_K=F6nig?=" In-Reply-To: <7daacbbe0604041156j252e6572x69436c2e44e3288b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7daacbbe0604040946m34826010k2a5ac967fa4bd9e0@mail.gmail.com> <4432B2FA.9000003@cs.tu-berlin.de> <7daacbbe0604041156j252e6572x69436c2e44e3288b@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Unable to mount a USB Key X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 09:46:12 -0000 On 4/4/06, Dominique Goncalves wrote: > On 4/4/06, Bj=F6rn K=F6nig wrote: > > Dominique Goncalves schrieb: > > > Hi, > > > > > > I'm trying to mount a USB Key on FreeBSD 7.0-CURRENT (also on > > > RELENG_6) formatted with msdosfs, but FreeBSD could not mount it. I > > > remember that it was working well on 6.0-RELEASE. > > > > > > umass0: = on uhub3 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: Removable Direct Access SCSI-0 dev= ice > > > da0: 40.000MB/s transfers > > > da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) > > > > > > Sometimes I don't have /dev/da0s1(?) but when there is /dev/da0s1: > > > > > > # ls -l /dev/da0s1 > > > crw-r----- 1 root operator 0, 142 Apr 4 18:17 /dev/da0s1 > > > # mount_msdosfs /dev/da0s1 /mnt/CF > > > Mount point /mnt/CF had 1 dangling refs > > > mount_msdosfs: /dev/da0s1: Device not configured > > > > > > This usb key works on others operating system and the same box. > > > > > > Thanks for your help. > > > > > > Regards. > > > > Tried fsck_msdosfs first? > > It didn't work: > > # fsck_msdosfs /dev/da0s1 > ** /dev/da0s1 > Can't open (Device not configured) > > and from time to time I see this on the console: > > umass0: BBB reset failed, TIMEOUT > umass0: BBB bulk-in clear stall failed, TIMEOUT > umass0: BBB bulk-out clear stall failed, TIMEOUT > > > > Regards > > Bj=F6rn > > > > Regards. > > -- > There's this old saying: "Give a man a fish, feed him for a day. Teach > a man to fish, feed him for life." > My USB key works when ehci is disabled (nodevice ehci in my kernel). Is this a problem with my USB key or a chipset ehci problem ? Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 10:32:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38F0016A401; Sat, 8 Apr 2006 10:32:31 +0000 (UTC) (envelope-from bms@spc.org) Received: from mindfull.spc.org (mindfull.spc.org [83.167.185.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591F243D45; Sat, 8 Apr 2006 10:32:30 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org ([83.167.185.2]) by mindfull.spc.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FSAjx-0003w9-Uv; Sat, 08 Apr 2006 11:32:25 +0100 Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 871CD6564E; Sat, 8 Apr 2006 11:32:27 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 55166-01; Sat, 8 Apr 2006 11:32:24 +0100 (BST) Received: by arginine.spc.org (Postfix, from userid 1078) id B513B65499; Sat, 8 Apr 2006 11:32:24 +0100 (BST) Date: Sat, 8 Apr 2006 11:32:24 +0100 From: Bruce M Simpson To: Mark Sergeant Message-ID: <20060408103224.GR80492@spc.org> Mail-Followup-To: Bruce M Simpson , Mark Sergeant , Maxim Sobolev , freebsd-current@freebsd.org References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> <20060406190944.G56354@lexi.siliconlandmark.com> <4435B303.5040205@FreeBSD.org> <196C209A-A585-4AD5-B7C9-A27DD57ECD8C@snsonline.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XLsjFikA86nwwlhe" Content-Disposition: inline In-Reply-To: <196C209A-A585-4AD5-B7C9-A27DD57ECD8C@snsonline.net> User-Agent: Mutt/1.4.1i Organization: Incunabulum X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mindfull.spc.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - spc.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: [DOCUMENT] Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 10:32:31 -0000 --XLsjFikA86nwwlhe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I wrote a document which explains exactly which BIOS calls FreeBSD uses to boot. Unfortunately there is a bit of an ongoing re-jig with my web stuff so it isn't up anywhere but I will repost it here. BMS --XLsjFikA86nwwlhe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="freebsd-bios-interaction.txt" ----------------------------------------- FreeBSD BIOS Coupling on i386 Bruce M. Simpson 2002-12-27 ----------------------------------------- Copyright (c) 2002 Bruce M. Simpson, All rights reserved. Redistribution and use are freely permitted provided that the above copyright notice and this paragraph are duplicated in all forms. Introduction ------------ This file is intended purely as a source of technical information on how closely coupled the FreeBSD/i386 boot process is to the BIOS and legacy i386 hardware. It should be of interest to anybody considering implementing their own BIOS and who wishes to be able to boot FreeBSD with it. FreeBSD Boot Process -------------------- The FreeBSD OS employs a three stage boot loader. Here we consider the most common case: booting from a hard disk recognised by the BIOS. The flow of execution runs thus: boot0 is loaded from the MBR, which then looks for the first FreeBSD DOS partition; boot1 is loaded from the BPB, which then loads and invokes boot2 from the boot sectors inside the FreeBSD disk label; then boot2 attempts to load and invoke the FreeBSD Loader from the root slice. Finally, the loader invokes the kernel. boot0/boot0sio -------------- - Master Boot Record (MBR) boot loader - Permits selection of DOS partition to boot from - Loaded from INT 19h (Bootstrap Loader) by BIOS - Self-relocates to 0000:7C00 (well clear of BIOS Data Area) - Loads boot sector from selected partition into segment 0, and performs a near jmp through BX to it BIOS functions used: Int Fn SFn Description ------------------------------------------------------------------ 10h 0Eh n/a Write Character in Teletype Mode (boot0) 13h 02h n/a Read Disk Sectors 13h 03h n/a Write Disk Sectors 13h 42h n/a Extended Read Sectors 13h 43h n/a Extended Write Sectors 14h 00h n/a Initialize Serial Port (boot0sio) 14h 01h n/a Send Byte (boot0sio) 14h 02h n/a Receive Byte (boot0sio) 14h 03h n/a Read Status (boot0sio) 16h 00h n/a Read Keyboard Input (boot0) 16h 01h n/a Check Keyboard Status (boot0) 1Ah 00h n/a Get System Time BIOS parameters accepted: Register Description ------------------------------- dl BIOS Drive Number (when invoked via INT 19h IPL) boot1 ----- - BIOS Parameter Block (BPB) boot loader - Resides in the BPB of the first FreeBSD partition on the disk - Loaded and invoked by boot0 at 0000:7C00 - Self-relocates on load to 0000:0700 (above BIOS data area and IDT) - Enables A20 by itself using the AT keyboard controller method - Reads and relocates boot2 to low memory to continue boot process - boot1 is kept resident in memory, and V86 mode is used to call into the real mode xread routine in this segment. BIOS functions used: Int Fn SFn Description ------------------------------------------------------------------ 10h 0Eh n/a Write Character in Teletype Mode 13h 00h n/a Disk Controller Reset 13h 02h n/a Read Disk Sectors 13h 08h n/a Read Disk Drive Parameters 13h 41h n/a Check If Extensions Present 13h 42h n/a Extended Read Sectors 13h 43h n/a Extended Write Sectors 16h 00h n/a Read Keyboard Input boot2 meta-binary ----------------- btxldr, btx, and boot2 are actually compiled into the same binary. Many things are going on in here. BTXLDR ------ - This is used to load the BTX framework. - It enters 'unreal' mode to allow the use of a 32-bit flat address space, thus permitting boot2 to be compiled using gcc. BIOS Data Area locations referenced: Address Description ------------------------------------------------------------------ 40:13h Main Memory Size 40:49h Video Mode 40:50h Video -- Cursor Position Page 0 BTXLDR addresses the VGA video memory at B8000h directly. BTXLDR does not make any BIOS calls. BTX and boot2 ------------- - BTX sets up a small protected mode kernel. It's actually quite a good example of how to drive the i386. - A V86 monitor is used to redirect calls into the BIOS (and capture some), whilst remaining in protected mode. - INT 19h is used by the BTX client to reset the machine. BIOS Data Area locations referenced: Address Description ------------------------------------------------------------------ 40:13h Main Memory Size 40:17h Keyboard Shift Flags 1 40:49h Video Mode 40:50h Video -- Cursor Position Page 0 40:72h Warm Boot Flag Direct I/O Port Hardware Accesses: Port Description ------------------------------------------------------------------ 0x20 8259 Master Interrupt Command Register 0x21 8259 Master Interrupt Mask Register 0xA0 8259 Slave Interrupt Command Register 0xA1 8259 Slave Interrupt Mask Register 0x3F8 UART 0 Transmit/Receive Buffer and Divisor LSB 0x3F9 UART 0 Divisor MSB 0x3FB UART 0 Line Control 0x3FC UART 0 Modem Control 0x3FD UART 0 Line Status BIOS Calls intercepted by the V86 Monitor: Int Fn SFn Description ------------------------------------------------------------------ 15h 87h n/a Access Extended Memory 19h n/a n/a Bootstrap Loader BIOS Calls passed through by the V86 Monitor: Int Fn SFn Description ------------------------------------------------------------------ 10h 0Eh n/a Write Character in Teletype Mode 12h 88h n/a Base Memory Size 13h 08h n/a Read Disk Drive Parameters 15h 88h n/a Extended Memory Size 16h 00h n/a Read Keyboard Input 16h 01h n/a Check Keyboard Status boot2 ----- boot2 is the BTX client. It uses the protected-mode kernel to call into the BIOS through the V86 monitor. It understands enough of FreeBSD FFS to load /boot/loader or /kernel on its own. The FORTH loader is preferable for modern FreeBSD configurations. It uses the /boot.config file for some settings of its own (such as forcing an autoboot on a CD installation). It knows enough to load an ELF or an a.out executable. loader ------ - This is the newer, advanced FreeBSD third stage bootstrap which has an embedded, Forth-like interpreter called FICL. - It is actually referred to as BOOT3 in the boot2 source. - Source is found under: /usr/src/sys/boot - Picks up i386 specific functions from i386/libi386, these handle interaction with the platform hardware, and the BIOS. BIOS Calls passed through by the V86 Monitor: Int Fn SFn Description ------------------------------------------------------------------ 10h 02h n/a Set Cursor Position (from vidconsole.c) 10h 03h n/a Read Cursor Position and Type (from vidconsole.c) 10h 06h n/a Scroll Active Page Up (from vidconsole.c) 10h 08h n/a Read Character and Attribute (from vidconsole.c) 10h 09h n/a Write Character and Attribute (from vidconsole.c) 10h 0Eh n/a Write Character in Teletype Mode (from vidconsole.c) 12h 88h n/a Base Memory Size (from biosmem.c) 13h 00h n/a Disk Controller Reset (from bioscd.c, biosdisk.c) 13h 02h n/a Read Disk Sectors (from biosdisk.c) 13h 08h n/a Read Disk Drive Parameters (from biosdisk.c) 13h 42h n/a Extended Read Sectors (from bioscd.c, biosdisk.c) 13h 4Bh 01h Terminate Disk Emulation (from bioscd.c) 15h 86h n/a Wait (from time.c) 15h 88h n/a Extended Memory Size (from biosmem.c) 15h E8h 01h Get Extended Memory Info (from biosmem.c) 15h E8h 20h Get System Memory Map (from biosmem.c) 16h 00h n/a Read Keyboard Input (from vidconsole.c) 16h 01h n/a Check Keyboard Status (from vidconsole.c) 1Ah 02h n/a Read CMOS Time (from time.c) 1Ah B1h 01h PCI Test for PCI BIOS Present (from biospci.c) 1Ah B1h 03h PCI Find Device Matching Class Code (from biospci.c) 1Ah B1h 0Ah PCI Read Device Configuration DWORD (from biospci.c) - FreeBSD's import of ficl has functions which wrap the in/out instructions to allow them to be used from boot FORTH. The actions of any FORTH programs which use these bindings are not documented here. - biospnp.c wraps the PnP BIOS. The PnP specification dictates that there must be a $PnP structure in the BIOS image, which contains a real mode CS:IP vector to be used for calls into the PnP BIOS. This vector will vary according to the BIOS in use. - pxe.c uses v86 to bounce into routines inside the PXE UNDI BIOS which knows how to get the IP address, etc. These ROMs exist on the network card, which can reside on an ISA or PCI bus. PXE compliant cards have $PnP headers in the boot ROM. Again, the PnP BIOS specification details how the various boot vectors in this header work, when a PnP BIOS is loading a PnP compliant expansion ROM. Kernel->BIOS entry points ------------------------- - Some BIOS extensions can be called from protected mode using the BIOS32 Service Directory. Others must be called from real mode. - We're lurking in: /usr/src/sys/i386 - i386/bios.c, i386/bioscall.s and i386/vm86.c define the following: - bios16() -- Make a 16-bit BIOS call in real mode *no man page* - bios32() -- Make a 32-bit BIOS call in protected mode (bios(9)) - bios32_SDlookup() -- Attempt to locate a BIOS32 service (bios(9)) - bios_sigsearch() -- Search for a service signature in ROM (bios(9)) - vm86_intcall() -- Make a 16-bit BIOS call in V86 mode *no man page* - vm86_datacall() -- Make a 16-bit BIOS call in V86 mode which returns some data *no man page* - vm86_bioscall() -- Make a 16-bit BIOS call in V86 mode *no man page* - BIOS_PADDRTOVADDR() wraps a reference to BIOS Data Area memory. - Grepping for the relevant permutations of the above entry points will let you see where kernel drivers are entering the BIOS, or referencing the BIOS Data Area. Boot-time Kernel->BIOS Communication ------------------------------------ - i386 specific low level code is in: /usr/src/sys/i386/i386 - Early boot initialization is handled in: locore.s - loader enters kernel at the entry point 'newboot' - The kernel reloads the GDT whilst bringing up the system. vm86 descriptors are created as part of the system-wide GDT. These are used to call into the BIOS or other real mode expansion ROMs later on. - Most of the kernel coupling is to the loader and not the BIOS, which is a good thing. That is, handling the BIOS directly has been farmed out to the loader, which passes this information to the kernel using a boot information structure, _bootinfo, which it fills in after loading the kernel. - The kernel does make a limited number of BIOS calls during boot, these are mainly made within machdep.c to discover the BIOS's idea of the system memory map: Int Fn SFn Description ------------------------------------------------------------------ 12h 88h n/a Base Memory Size 15h 88h n/a Extended Memory Size 15h E8h 01h Get Extended Memory Info 15h E8h 20h Get System Memory Map - If you set bootverbose to 1 from the loader, you can see the SMAP initialization being printed out on the console. - isa/mca_machdep.c makes these calls via vm86_intcall(): Int Fn SFn Description ------------------------------------------------------------------ 15h C0h n/a Return System BIOS Configuration - This is used to discover a MicroChannel Bus (MCA) machine. - isa/pci_cfgreg.c makes these calls via bios32(): Int Fn SFn Description ------------------------------------------------------------------ 1Ah B1h 01h PCI Test for PCI BIOS Present 1Ah B1h 0Fh PCI Route Device Interrupt - This is necessary as the board specific knowledge/code to route interrupts according to the northbridge/southbridge pair is contained within the BIOS on i386 machines. Note however that configuration register access is a well defined process on the i386 which doesn't require assistance from the BIOS. - The kernel doesn't specifically call into the BIOS after boot, unless separate initialization is required on behalf of drivers (e.g. APM). These are considered separately; please see below. Run-time Kernel->BIOS Communication ----------------------------------- - apm/apm.c makes these BIOS calls in 16- or 32-bit mode depending on whether or not the APM BIOS supports 32-bit invocation: Int Fn SFn Description ------------------------------------------------------------------ 15h 53h nnh APM BIOS Calls (PC/AT) 1Fh 9Ah nnh APM BIOS Calls (PC98) - i386/isa/vesa.c makes the following calls via vm86_[int|data]call(): Int Fn SFn Description ------------------------------------------------------------------ 10h 00h n/a Set Video Mode 10h 4Fh 00h VBE Initialize VESA BIOS 10h 4Fh 01h VBE Get Extended Modes 10h 4Fh 02h VBE Set Extended Mode 10h 4Fh 04h VBE Buffer Manipulation 10h 4Fh 05h VBE Window Manipulation 10h 4Fh 06h VBE Scanline Manipulation 10h 4Fh 07h VBE Linear Framebuffer Manipulation 10h 4Fh 08h VBE DAC Manipulation 10h 4Fh 09h VBE Palette Manipulation - dev/fb/vga.c uses the BIOS Data Area, primarily if there is no VESA BIOS present. BIOS Data Area locations referenced: Address Description ------------------------------------------------------------------ 40:4Ah Video Columns (BYTE) 40:4Ch Video Bytes per Page (WORD) 40:4Dh Video Current Page Offset (WORD) 40:63h Video I/O Port Number Base (WORD) 40:84h Video Number of Rows (BYTE) 40:85h Video Pixels per Character (WORD) 40:87h Video Options (BYTE) 40:88h Video Switches (BYTE) 40:A8h Video Parameter Control Block Pointer (DWORD) - dev/kbd/atkbd.c makes the following calls via vm86_intcall(), and may reference a BIOS Data Area location as a result of INT 15h: Int Fn SFn Description ------------------------------------------------------------------ 15h C0h n/a Return System BIOS Configuration 16h 03h 06h Get Typematic Rate 16h 09h n/a Get Typematic Capabilities - XXX: The DMItable is documented in bios(9), but not implemented. - XXX: The SMBIOStable is documented in bios(9), but not implemented. - XXX: I haven't documented how ACPI is called yet. References ---------- The Undocumented PC 2e van Gilluwe, Frank; Addison-Wesley; ISBN 0-201-47950-8 PC Intern 6e Tischer & Jennrich; Abacus; ISBN 1-55755-304-1 PCI System Architecture 4e Shanley & Anderson; Addison-Wesley; ISBN 0-201-30974-2 --XLsjFikA86nwwlhe-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 10:44:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6E9D16A401; Sat, 8 Apr 2006 10:44:03 +0000 (UTC) (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 41D0343D45; Sat, 8 Apr 2006 10:44:02 +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 k38Ahwiw044572; Sat, 8 Apr 2006 03:43:58 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k38Ahwek044571; Sat, 8 Apr 2006 03:43:58 -0700 (PDT) (envelope-from rizzo) Date: Sat, 8 Apr 2006 03:43:58 -0700 From: Luigi Rizzo To: Bruce M Simpson , Mark Sergeant , Maxim Sobolev , freebsd-current@freebsd.org Message-ID: <20060408034357.A44217@xorpc.icir.org> References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> <20060406190944.G56354@lexi.siliconlandmark.com> <4435B303.5040205@FreeBSD.org> <196C209A-A585-4AD5-B7C9-A27DD57ECD8C@snsonline.net> <20060408103224.GR80492@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060408103224.GR80492@spc.org>; from bms@spc.org on Sat, Apr 08, 2006 at 11:32:24AM +0100 Cc: Subject: Re: [DOCUMENT] Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 10:44:03 -0000 On Sat, Apr 08, 2006 at 11:32:24AM +0100, Bruce M Simpson wrote: > I wrote a document which explains exactly which BIOS calls FreeBSD > uses to boot. > > Unfortunately there is a bit of an ongoing re-jig with my web stuff so > it isn't up anywhere but I will repost it here. > > BMS very interesting stuff, thanks. Ii wonder if we can do more progress if we use a picobsd-like approach namely bypass btx and load the kernel directly. Reading your list we may well get stuck at the pci probe, but at least we should see the initial kernel messages. Testing (given available hardware) should be as simple as running picobsd on current or 6.1 and creating a 'bridge' image, then trying it from a flash card... cheers luigi > ----------------------------------------- > FreeBSD BIOS Coupling on i386 > Bruce M. Simpson 2002-12-27 > ----------------------------------------- > > Copyright (c) 2002 Bruce M. Simpson, All rights reserved. > > Redistribution and use are freely permitted provided that the above > copyright notice and this paragraph are duplicated in all forms. > > Introduction > ------------ > This file is intended purely as a source of technical information > on how closely coupled the FreeBSD/i386 boot process is to the BIOS > and legacy i386 hardware. > > It should be of interest to anybody considering implementing their > own BIOS and who wishes to be able to boot FreeBSD with it. > > FreeBSD Boot Process > -------------------- > The FreeBSD OS employs a three stage boot loader. Here we consider the > most common case: booting from a hard disk recognised by the BIOS. > > The flow of execution runs thus: boot0 is loaded from the MBR, which then > looks for the first FreeBSD DOS partition; boot1 is loaded from the BPB, > which then loads and invokes boot2 from the boot sectors inside the FreeBSD > disk label; then boot2 attempts to load and invoke the FreeBSD Loader from > the root slice. Finally, the loader invokes the kernel. > > boot0/boot0sio > -------------- > - Master Boot Record (MBR) boot loader > - Permits selection of DOS partition to boot from > - Loaded from INT 19h (Bootstrap Loader) by BIOS > - Self-relocates to 0000:7C00 (well clear of BIOS Data Area) > - Loads boot sector from selected partition into segment 0, and > performs a near jmp through BX to it > > BIOS functions used: > Int Fn SFn Description > ------------------------------------------------------------------ > 10h 0Eh n/a Write Character in Teletype Mode (boot0) > 13h 02h n/a Read Disk Sectors > 13h 03h n/a Write Disk Sectors > 13h 42h n/a Extended Read Sectors > 13h 43h n/a Extended Write Sectors > 14h 00h n/a Initialize Serial Port (boot0sio) > 14h 01h n/a Send Byte (boot0sio) > 14h 02h n/a Receive Byte (boot0sio) > 14h 03h n/a Read Status (boot0sio) > 16h 00h n/a Read Keyboard Input (boot0) > 16h 01h n/a Check Keyboard Status (boot0) > 1Ah 00h n/a Get System Time > > BIOS parameters accepted: > Register Description > ------------------------------- > dl BIOS Drive Number (when invoked via INT 19h IPL) > > boot1 > ----- > - BIOS Parameter Block (BPB) boot loader > - Resides in the BPB of the first FreeBSD partition on the disk > - Loaded and invoked by boot0 at 0000:7C00 > - Self-relocates on load to 0000:0700 (above BIOS data area and IDT) > - Enables A20 by itself using the AT keyboard controller method > - Reads and relocates boot2 to low memory to continue boot process > - boot1 is kept resident in memory, and V86 mode is used to call into > the real mode xread routine in this segment. > > BIOS functions used: > Int Fn SFn Description > ------------------------------------------------------------------ > 10h 0Eh n/a Write Character in Teletype Mode > 13h 00h n/a Disk Controller Reset > 13h 02h n/a Read Disk Sectors > 13h 08h n/a Read Disk Drive Parameters > 13h 41h n/a Check If Extensions Present > 13h 42h n/a Extended Read Sectors > 13h 43h n/a Extended Write Sectors > 16h 00h n/a Read Keyboard Input > > boot2 meta-binary > ----------------- > btxldr, btx, and boot2 are actually compiled into the same binary. > Many things are going on in here. > > BTXLDR > ------ > - This is used to load the BTX framework. > - It enters 'unreal' mode to allow the use of a 32-bit flat address > space, thus permitting boot2 to be compiled using gcc. > > BIOS Data Area locations referenced: > Address Description > ------------------------------------------------------------------ > 40:13h Main Memory Size > 40:49h Video Mode > 40:50h Video -- Cursor Position Page 0 > > BTXLDR addresses the VGA video memory at B8000h directly. > BTXLDR does not make any BIOS calls. > > BTX and boot2 > ------------- > - BTX sets up a small protected mode kernel. It's actually quite a good > example of how to drive the i386. > - A V86 monitor is used to redirect calls into the BIOS (and capture some), > whilst remaining in protected mode. > - INT 19h is used by the BTX client to reset the machine. > > BIOS Data Area locations referenced: > Address Description > ------------------------------------------------------------------ > 40:13h Main Memory Size > 40:17h Keyboard Shift Flags 1 > 40:49h Video Mode > 40:50h Video -- Cursor Position Page 0 > 40:72h Warm Boot Flag > > Direct I/O Port Hardware Accesses: > Port Description > ------------------------------------------------------------------ > 0x20 8259 Master Interrupt Command Register > 0x21 8259 Master Interrupt Mask Register > 0xA0 8259 Slave Interrupt Command Register > 0xA1 8259 Slave Interrupt Mask Register > 0x3F8 UART 0 Transmit/Receive Buffer and Divisor LSB > 0x3F9 UART 0 Divisor MSB > 0x3FB UART 0 Line Control > 0x3FC UART 0 Modem Control > 0x3FD UART 0 Line Status > > BIOS Calls intercepted by the V86 Monitor: > Int Fn SFn Description > ------------------------------------------------------------------ > 15h 87h n/a Access Extended Memory > 19h n/a n/a Bootstrap Loader > > BIOS Calls passed through by the V86 Monitor: > Int Fn SFn Description > ------------------------------------------------------------------ > 10h 0Eh n/a Write Character in Teletype Mode > 12h 88h n/a Base Memory Size > 13h 08h n/a Read Disk Drive Parameters > 15h 88h n/a Extended Memory Size > 16h 00h n/a Read Keyboard Input > 16h 01h n/a Check Keyboard Status > > boot2 > ----- > boot2 is the BTX client. It uses the protected-mode kernel to call into > the BIOS through the V86 monitor. It understands enough of FreeBSD FFS > to load /boot/loader or /kernel on its own. The FORTH loader is preferable > for modern FreeBSD configurations. It uses the /boot.config file for > some settings of its own (such as forcing an autoboot on a CD installation). > > It knows enough to load an ELF or an a.out executable. > > loader > ------ > - This is the newer, advanced FreeBSD third stage bootstrap which has > an embedded, Forth-like interpreter called FICL. > - It is actually referred to as BOOT3 in the boot2 source. > - Source is found under: /usr/src/sys/boot > - Picks up i386 specific functions from i386/libi386, these handle > interaction with the platform hardware, and the BIOS. > > BIOS Calls passed through by the V86 Monitor: > Int Fn SFn Description > ------------------------------------------------------------------ > 10h 02h n/a Set Cursor Position (from vidconsole.c) > 10h 03h n/a Read Cursor Position and Type (from vidconsole.c) > 10h 06h n/a Scroll Active Page Up (from vidconsole.c) > 10h 08h n/a Read Character and Attribute (from vidconsole.c) > 10h 09h n/a Write Character and Attribute (from vidconsole.c) > 10h 0Eh n/a Write Character in Teletype Mode (from vidconsole.c) > 12h 88h n/a Base Memory Size (from biosmem.c) > 13h 00h n/a Disk Controller Reset (from bioscd.c, biosdisk.c) > 13h 02h n/a Read Disk Sectors (from biosdisk.c) > 13h 08h n/a Read Disk Drive Parameters (from biosdisk.c) > 13h 42h n/a Extended Read Sectors (from bioscd.c, biosdisk.c) > 13h 4Bh 01h Terminate Disk Emulation (from bioscd.c) > 15h 86h n/a Wait (from time.c) > 15h 88h n/a Extended Memory Size (from biosmem.c) > 15h E8h 01h Get Extended Memory Info (from biosmem.c) > 15h E8h 20h Get System Memory Map (from biosmem.c) > 16h 00h n/a Read Keyboard Input (from vidconsole.c) > 16h 01h n/a Check Keyboard Status (from vidconsole.c) > 1Ah 02h n/a Read CMOS Time (from time.c) > 1Ah B1h 01h PCI Test for PCI BIOS Present (from biospci.c) > 1Ah B1h 03h PCI Find Device Matching Class Code (from biospci.c) > 1Ah B1h 0Ah PCI Read Device Configuration DWORD (from biospci.c) > > - FreeBSD's import of ficl has functions which wrap the in/out > instructions to allow them to be used from boot FORTH. The actions of > any FORTH programs which use these bindings are not documented here. > > - biospnp.c wraps the PnP BIOS. The PnP specification dictates that > there must be a $PnP structure in the BIOS image, which contains a > real mode CS:IP vector to be used for calls into the PnP BIOS. This > vector will vary according to the BIOS in use. > > - pxe.c uses v86 to bounce into routines inside the PXE UNDI BIOS which > knows how to get the IP address, etc. These ROMs exist on the network > card, which can reside on an ISA or PCI bus. PXE compliant cards have > $PnP headers in the boot ROM. Again, the PnP BIOS specification details > how the various boot vectors in this header work, when a PnP BIOS is > loading a PnP compliant expansion ROM. > > Kernel->BIOS entry points > ------------------------- > - Some BIOS extensions can be called from protected mode using the > BIOS32 Service Directory. Others must be called from real mode. > > - We're lurking in: /usr/src/sys/i386 > > - i386/bios.c, i386/bioscall.s and i386/vm86.c define the following: > - bios16() -- Make a 16-bit BIOS call in real mode *no man page* > - bios32() -- Make a 32-bit BIOS call in protected mode (bios(9)) > - bios32_SDlookup() -- Attempt to locate a BIOS32 service (bios(9)) > - bios_sigsearch() -- Search for a service signature in ROM (bios(9)) > - vm86_intcall() -- Make a 16-bit BIOS call in V86 mode *no man page* > - vm86_datacall() -- Make a 16-bit BIOS call in V86 mode which returns > some data *no man page* > - vm86_bioscall() -- Make a 16-bit BIOS call in V86 mode *no man page* > - BIOS_PADDRTOVADDR() wraps a reference to BIOS Data Area memory. > > - Grepping for the relevant permutations of the above entry points > will let you see where kernel drivers are entering the BIOS, or > referencing the BIOS Data Area. > > Boot-time Kernel->BIOS Communication > ------------------------------------ > - i386 specific low level code is in: /usr/src/sys/i386/i386 > - Early boot initialization is handled in: locore.s > - loader enters kernel at the entry point 'newboot' > - The kernel reloads the GDT whilst bringing up the system. vm86 > descriptors are created as part of the system-wide GDT. These are used > to call into the BIOS or other real mode expansion ROMs later on. > > - Most of the kernel coupling is to the loader and not the BIOS, which > is a good thing. That is, handling the BIOS directly has been farmed > out to the loader, which passes this information to the kernel using > a boot information structure, _bootinfo, which it fills in after > loading the kernel. > > - The kernel does make a limited number of BIOS calls during boot, > these are mainly made within machdep.c to discover the BIOS's > idea of the system memory map: > > Int Fn SFn Description > ------------------------------------------------------------------ > 12h 88h n/a Base Memory Size > 15h 88h n/a Extended Memory Size > 15h E8h 01h Get Extended Memory Info > 15h E8h 20h Get System Memory Map > > - If you set bootverbose to 1 from the loader, you can see the SMAP > initialization being printed out on the console. > > - isa/mca_machdep.c makes these calls via vm86_intcall(): > > Int Fn SFn Description > ------------------------------------------------------------------ > 15h C0h n/a Return System BIOS Configuration > > - This is used to discover a MicroChannel Bus (MCA) machine. > > - isa/pci_cfgreg.c makes these calls via bios32(): > > Int Fn SFn Description > ------------------------------------------------------------------ > 1Ah B1h 01h PCI Test for PCI BIOS Present > 1Ah B1h 0Fh PCI Route Device Interrupt > > - This is necessary as the board specific knowledge/code to route > interrupts according to the northbridge/southbridge pair is contained > within the BIOS on i386 machines. Note however that configuration > register access is a well defined process on the i386 which doesn't > require assistance from the BIOS. > > - The kernel doesn't specifically call into the BIOS after boot, unless > separate initialization is required on behalf of drivers (e.g. APM). > These are considered separately; please see below. > > Run-time Kernel->BIOS Communication > ----------------------------------- > - apm/apm.c makes these BIOS calls in 16- or 32-bit mode depending > on whether or not the APM BIOS supports 32-bit invocation: > > Int Fn SFn Description > ------------------------------------------------------------------ > 15h 53h nnh APM BIOS Calls (PC/AT) > 1Fh 9Ah nnh APM BIOS Calls (PC98) > > - i386/isa/vesa.c makes the following calls via vm86_[int|data]call(): > > Int Fn SFn Description > ------------------------------------------------------------------ > 10h 00h n/a Set Video Mode > 10h 4Fh 00h VBE Initialize VESA BIOS > 10h 4Fh 01h VBE Get Extended Modes > 10h 4Fh 02h VBE Set Extended Mode > 10h 4Fh 04h VBE Buffer Manipulation > 10h 4Fh 05h VBE Window Manipulation > 10h 4Fh 06h VBE Scanline Manipulation > 10h 4Fh 07h VBE Linear Framebuffer Manipulation > 10h 4Fh 08h VBE DAC Manipulation > 10h 4Fh 09h VBE Palette Manipulation > > - dev/fb/vga.c uses the BIOS Data Area, primarily if there is no VESA > BIOS present. > > BIOS Data Area locations referenced: > Address Description > ------------------------------------------------------------------ > 40:4Ah Video Columns (BYTE) > 40:4Ch Video Bytes per Page (WORD) > 40:4Dh Video Current Page Offset (WORD) > 40:63h Video I/O Port Number Base (WORD) > 40:84h Video Number of Rows (BYTE) > 40:85h Video Pixels per Character (WORD) > 40:87h Video Options (BYTE) > 40:88h Video Switches (BYTE) > 40:A8h Video Parameter Control Block Pointer (DWORD) > > - dev/kbd/atkbd.c makes the following calls via vm86_intcall(), > and may reference a BIOS Data Area location as a result of INT 15h: > > Int Fn SFn Description > ------------------------------------------------------------------ > 15h C0h n/a Return System BIOS Configuration > 16h 03h 06h Get Typematic Rate > 16h 09h n/a Get Typematic Capabilities > > - XXX: The DMItable is documented in bios(9), but not implemented. > - XXX: The SMBIOStable is documented in bios(9), but not implemented. > - XXX: I haven't documented how ACPI is called yet. > > References > ---------- > The Undocumented PC 2e > van Gilluwe, Frank; Addison-Wesley; ISBN 0-201-47950-8 > > PC Intern 6e > Tischer & Jennrich; Abacus; ISBN 1-55755-304-1 > > PCI System Architecture 4e > Shanley & Anderson; Addison-Wesley; ISBN 0-201-30974-2 > _______________________________________________ > 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 Apr 8 10:50:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AB9816A403; Sat, 8 Apr 2006 10:50:17 +0000 (UTC) (envelope-from bms@spc.org) Received: from mindfull.spc.org (mindfull.spc.org [83.167.185.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAD4743D5C; Sat, 8 Apr 2006 10:50:16 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org ([83.167.185.2]) by mindfull.spc.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FSB1B-00042M-IB; Sat, 08 Apr 2006 11:50:13 +0100 Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B891865499; Sat, 8 Apr 2006 11:50:15 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 54754-06; Sat, 8 Apr 2006 11:50:14 +0100 (BST) Received: by arginine.spc.org (Postfix, from userid 1078) id A3CD1653F9; Sat, 8 Apr 2006 11:50:14 +0100 (BST) Date: Sat, 8 Apr 2006 11:50:14 +0100 From: Bruce M Simpson To: Luigi Rizzo Message-ID: <20060408105014.GV80492@spc.org> Mail-Followup-To: Bruce M Simpson , Luigi Rizzo , Mark Sergeant , Maxim Sobolev , freebsd-current@freebsd.org References: <4433CFA1.90509@centtech.com> <2C74BB8F-271B-4505-9D94-B270B3A4ACBA@nordahl.net> <44348603.9070503@FreeBSD.org> <20060406190944.G56354@lexi.siliconlandmark.com> <4435B303.5040205@FreeBSD.org> <196C209A-A585-4AD5-B7C9-A27DD57ECD8C@snsonline.net> <20060408103224.GR80492@spc.org> <20060408034357.A44217@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060408034357.A44217@xorpc.icir.org> User-Agent: Mutt/1.4.1i Organization: Incunabulum X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mindfull.spc.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - spc.org X-Source: X-Source-Args: X-Source-Dir: Cc: Mark Sergeant , freebsd-current@freebsd.org Subject: Re: [DOCUMENT] Re: Intel Macs that boot FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 10:50:17 -0000 On Sat, Apr 08, 2006 at 03:43:58AM -0700, Luigi Rizzo wrote: > Ii wonder if we can do more progress if we use > a picobsd-like approach namely bypass btx and load the kernel > directly. Reading your list we may well get stuck at the pci > probe, but at least we should see the initial kernel messages. I would suggest that anyone who wants to get FreeBSD booting on the mini-mac purchases a port 0x80 POST diag card (<$10 on eBay), and instruments the early boot paths to output to such a device. If hacking kernel code then probably quicker to just use NFS and PXE for starter bootstrap :-) Of course those of us who are lucky enough to have a PCI logic analyzer (not me, though I bought an FPGA card explicitly for this purpose, ENOTIME to learn hardware design language) will be able to do this right away. It shouldn't be too difficult to implement PCI Configuration Register Type 1 support. Ideally of course we'd support EFI natively w/o the shim. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 12:42:39 2006 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 E91F716A400 for ; Sat, 8 Apr 2006 12:42:39 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from jay.exetel.com.au (jay.exetel.com.au [220.233.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 259B543D46 for ; Sat, 8 Apr 2006 12:42:38 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: (qmail 27395 invoked by uid 507); 8 Apr 2006 22:42:36 +1000 Received: from 180.205.233.220.exetel.com.au (HELO ?192.168.0.157?) (220.233.205.180) by jay.exetel.com.au with SMTP; 8 Apr 2006 22:42:36 +1000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <4C255DB7-A023-4B91-983A-EA0828656C4E@brooknet.com.au> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Sam Lawrance Date: Sat, 8 Apr 2006 22:42:32 +1000 X-Mailer: Apple Mail (2.749.3) Cc: Subject: building RELENG_4 failure on recent -current - bootparamd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 12:42:40 -0000 I'm trying to build a RELENG_4 jail on a -current host for marcuscom tinderbox. Any ideas about the failure below? Host machine is FreeBSD 7.0-CURRENT #0: Sun Mar 26 01:45:22 EST 2006 ===> usr.sbin/bootparamd ===> usr.sbin/bootparamd/bootparamd cc -O -pipe -DTFTP_DIR=\"/tftpboot\" -I. -c /usr/local/tinderbox/ jails/4-STABLE/src/usr.sbin/bootparamd/bootparamd/bootparamd.c /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/ bootparamd/bootparamd.c: In function `bootparamproc_whoami_1': /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/ bootparamd/bootparamd.c:47: number of arguments doesn't match prototype bootparam_prot.h:78: prototype declaration /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/ bootparamd/bootparamd.c: In function `bootparamproc_getfile_1': /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/ bootparamd/bootparamd.c:112: number of arguments doesn't match prototype bootparam_prot.h:81: prototype declaration *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/ bootparamd. *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd. *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin. *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src. *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src. *** Error code 1 Stop in /usr/local/tinderbox/jails/4-STABLE/src. ERROR: make world failed. See above output. FAILED. From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 13:59:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2030516A403 for ; Sat, 8 Apr 2006 13:59:14 +0000 (UTC) (envelope-from zach@webges.com) Received: from mail.webges.com (mail.webges.com [195.128.164.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B71B43D45 for ; Sat, 8 Apr 2006 13:59:13 +0000 (GMT) (envelope-from zach@webges.com) Received: from localhost (localhost [127.0.0.1]) by mail.webges.com (Postfix) with ESMTP id 794A31520638 for ; Sat, 8 Apr 2006 15:59:09 +0200 (CEST) Received: from webmail.webges.com (rs3 [192.168.9.182]) by mail.webges.com (Postfix) with ESMTP id 51DC9152062C for ; Sat, 8 Apr 2006 15:59:09 +0200 (CEST) Received: from 213.47.105.203 (SquirrelMail authenticated user zach_webges) by webmail.webges.com with HTTP; Sat, 8 Apr 2006 15:59:08 +0200 (CEST) Message-ID: <2851.213.47.105.203.1144504748.squirrel@webmail.webges.com> In-Reply-To: <20060405191011.GL699@turion.vk2pj.dyndns.org> References: <1425.62.178.112.107.1144260889.squirrel@webmail.webges.com> <20060405191011.GL699@turion.vk2pj.dyndns.org> Date: Sat, 8 Apr 2006 15:59:08 +0200 (CEST) From: "Michael Zach" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mail.webges.com Subject: Re: another make buildworld error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zach@webges.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 13:59:14 -0000 Hi Peter, it seemed the magic file was not the only problem (CVSup didn't solve it), but moving src to src_ and doing a complete new checkout solved the problem. Just thought I'd let you guys know in case anybody else encounters the same problem. Thanks for the help, Michael > On Wed, 2006-Apr-05 20:14:49 +0200, Michael Zach wrote: >>another error occured. thanks jason for the tip, changing CFLAGS in >>make.conf actually helped, but during the build process another error >>occured: >> >>[snip] >>... >>magic, 47985: Warning offset `text' invalid >>magic, 47985: Warning type `text' invalid >>magic, 47986: Warning offset `@@' invalid >>magic, 47986: Warning type `@@' invalid > > Somehow your /usr/src/contrib/file/Magdir/magic has been replaced by > a CVS repository file. Delete it and re-CVsup. You might like to > check for similar problems with other files. > >>any ideas? there are actually only a Makefile and a config.h in libmagic, >>so I guess the magic file is missing at all (if it's ever been in there) > > The Makefile points to the actual code under src/contrib. > > -- > Peter Jeremy > From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 16:15:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D59DE16A400 for ; Sat, 8 Apr 2006 16:15:53 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7487A43D49 for ; Sat, 8 Apr 2006 16:15:53 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060408161552.NYYW12719.mta11.adelphia.net@[192.168.1.254]>; Sat, 8 Apr 2006 12:15:52 -0400 Message-ID: <4437E1AD.7000303@savvis.net> Date: Sat, 08 Apr 2006 09:15:41 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dominique Goncalves References: <7daacbbe0604080204q1d8b8995kbadc61eb1461eefd@mail.gmail.com> In-Reply-To: <7daacbbe0604080204q1d8b8995kbadc61eb1461eefd@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PS/2 keyboard not working in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 16:15:53 -0000 Dominique Goncalves wrote: > Hi, > > With FreeBSD 7.0-CURRENT, I can't type anything with my PS/2 keyboard > when I enter in ddb (ctrl+alt+esc) in the prompt 'db>'. known issue. this is due to kbdmux(4) being enabled by default. i'm working on this (no eta yet). > A work around is to boot with 'Boot FreeBSD in safe mode' menu 3. yes. 'safe mode' disables kbdmux(4). thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 17:07:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D78C16A400 for ; Sat, 8 Apr 2006 17:07:34 +0000 (UTC) (envelope-from gexlie@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E0EE43D46 for ; Sat, 8 Apr 2006 17:07:33 +0000 (GMT) (envelope-from gexlie@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so560230wra for ; Sat, 08 Apr 2006 10:07:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=NKOSHqykpNDb3ku9VuO7ve6NqrCAMcXptDbgR0V/qkZsA7Ce7+U5aJKzRZGmYmqMZjpHDfMnZtRkcRCB4Wz+498u9nj/aGxVLrHd4lGcLbCq3FqfS/9j1RCDpVGpl+ZnT7N3S8ZWH02/GPyF2ng1Y9A8u5EdqRqf5E9FlnQZNYE= Received: by 10.64.181.14 with SMTP id d14mr1280452qbf; Sat, 08 Apr 2006 10:07:32 -0700 (PDT) Received: by 10.65.214.5 with HTTP; Sat, 8 Apr 2006 10:07:32 -0700 (PDT) Message-ID: <53cc795f0604081007u2b68b60tf2da0121eca46841@mail.gmail.com> Date: Sat, 8 Apr 2006 21:07:32 +0400 From: GeX To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 7.0 and Genius SlimStar Pro USB keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 17:07:34 -0000 Hello! I have FreeBSD 5.4 and I have tried to use Genius SlimStar Pro USB keyboard. The kernel configuration file contains following lines: -------------------------------------------------------- device uhci device ohci device usb device ukbd options KBD_INSTALL_CDEV -------------------------------------------------------- The /etc/rc.conf file contains following line: -------------------------------------------------------- usbd_enable=3D"YES" -------------------------------------------------------- The /etc/rc.i386 file contains following line: -------------------------------------------------------- kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null -------------------------------------------------------- The device /dev/kbd0 is created during the boot time. But the system does not response properly on the keys pressing. The "Enter" key works fine but all other keys produces some mess charters like "^K" etc. Could you tell me, please, what's the problem and what's the way to solve it? From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 17:25:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76F2616A402 for ; Sat, 8 Apr 2006 17:25:32 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DAF943D48 for ; Sat, 8 Apr 2006 17:25:31 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so595635nzf for ; Sat, 08 Apr 2006 10:25:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cT9vj/6GXT918fOt5ENOcml67OmeYqJQikPS1oEpGB3tI/vFRu9VLniJqnkTabg06FIN6SU8+WCRlTMSw5hhwrthgxS82JPHTjl7hDODchvXfTiwNPTqmRhrDy8MrjtHvkG1f4bdFGtlhTPxqRGkrMtdvBvS0UW1u5mnXwgo3IM= Received: by 10.36.61.13 with SMTP id j13mr3414495nza; Sat, 08 Apr 2006 10:25:30 -0700 (PDT) Received: by 10.36.57.15 with HTTP; Sat, 8 Apr 2006 10:25:30 -0700 (PDT) Message-ID: <6eb82e0604081025i506ae352m583d6057d17a9677@mail.gmail.com> Date: Sat, 8 Apr 2006 13:25:30 -0400 From: "Rong-En Fan" To: "Maksim Yevmenkin" In-Reply-To: <4437E1AD.7000303@savvis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7daacbbe0604080204q1d8b8995kbadc61eb1461eefd@mail.gmail.com> <4437E1AD.7000303@savvis.net> Cc: freebsd-current@freebsd.org Subject: Re: PS/2 keyboard not working in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 17:25:32 -0000 On 4/8/06, Maksim Yevmenkin wrote: > Dominique Goncalves wrote: > > Hi, > > > > With FreeBSD 7.0-CURRENT, I can't type anything with my PS/2 keyboard > > when I enter in ddb (ctrl+alt+esc) in the prompt 'db>'. > > known issue. this is due to kbdmux(4) being enabled by default. i'm > working on this (no eta yet). Does this mean that if we want to use ddb, then we have to disable kbdmux? Maybe we should document this know issue in the manual pages? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 17:52:10 2006 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 07D9E16A400 for ; Sat, 8 Apr 2006 17:52:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B848343D45 for ; Sat, 8 Apr 2006 17:52:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 9E1231A4D80; Sat, 8 Apr 2006 10:52:09 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DCA9051558; Sat, 8 Apr 2006 13:52:08 -0400 (EDT) Date: Sat, 8 Apr 2006 13:52:08 -0400 From: Kris Kennaway To: Sam Lawrance Message-ID: <20060408175208.GA35433@xor.obsecurity.org> References: <4C255DB7-A023-4B91-983A-EA0828656C4E@brooknet.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <4C255DB7-A023-4B91-983A-EA0828656C4E@brooknet.com.au> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: building RELENG_4 failure on recent -current - bootparamd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 17:52:10 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 08, 2006 at 10:42:32PM +1000, Sam Lawrance wrote: > I'm trying to build a RELENG_4 jail on a -current host for marcuscom =20 > tinderbox. Any ideas about the failure below? >=20 > Host machine is FreeBSD 7.0-CURRENT #0: Sun Mar 26 01:45:22 EST 2006 >=20 > =3D=3D=3D> usr.sbin/bootparamd > =3D=3D=3D> usr.sbin/bootparamd/bootparamd > cc -O -pipe -DTFTP_DIR=3D\"/tftpboot\" -I. -c /usr/local/tinderbox/= =20 > jails/4-STABLE/src/usr.sbin/bootparamd/bootparamd/bootparamd.c > /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/=20 > bootparamd/bootparamd.c: In function `bootparamproc_whoami_1': > /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/=20 > bootparamd/bootparamd.c:47: number of arguments doesn't match prototype > bootparam_prot.h:78: prototype declaration > /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/=20 > bootparamd/bootparamd.c: In function `bootparamproc_getfile_1': > /usr/local/tinderbox/jails/4-STABLE/src/usr.sbin/bootparamd/=20 > bootparamd/bootparamd.c:112: number of arguments doesn't match prototype > bootparam_prot.h:81: prototype declaration > *** Error code 1 You can't build 4.x on 7.0. Best you can do is a chroot/jail - i.e. download the 4.11-release media and populate with that. This may negate the whole purpose of your exercise though :-) Kris --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEN/hIWry0BWjoQKURArQ9AKCDynMPg8kdJWygjT8wyFGsGE661gCdGvVb 8cgKy+oWShDVnzxaa/GJc/A= =ZQx8 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 19:49:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 912A916A400 for ; Sat, 8 Apr 2006 19:49:39 +0000 (UTC) (envelope-from gexlie@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951BE43D5F for ; Sat, 8 Apr 2006 19:49:38 +0000 (GMT) (envelope-from gexlie@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so570955wri for ; Sat, 08 Apr 2006 12:49:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GphC6Vitqofl194yf5TzvXsuj+z3xWX99x39EIE9y/hW/+2TWXH6h45pSTClYJnHOhYOVm6jRCVbHpCQQI+teZLhwIrRIWhUMtlwIMmtZ10Ht3WUNLP89gWg0KvnkyWJoE8j/edfhHCDFsNRMkw+gCw+PLD/QU/5dkXTIjAp5As= Received: by 10.64.199.17 with SMTP id w17mr3284169qbf; Sat, 08 Apr 2006 12:49:38 -0700 (PDT) Received: by 10.65.214.5 with HTTP; Sat, 8 Apr 2006 12:49:38 -0700 (PDT) Message-ID: <53cc795f0604081249j2b85950bpe462353080f862f@mail.gmail.com> Date: Sat, 8 Apr 2006 23:49:38 +0400 From: GeX To: mistry.7@osu.edu, freebsd-current@freebsd.org In-Reply-To: <200604081456.42343.mistry.7@osu.edu> MIME-Version: 1.0 References: <53cc795f0604081007u2b68b60tf2da0121eca46841@mail.gmail.com> <200604081456.42343.mistry.7@osu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD 7.0 and Genius SlimStar Pro USB keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 19:49:39 -0000 sorry i mistyped, of course i meant freebsd 7.0-current at all On 4/8/06, Anish Mistry wrote: > > On Saturday 08 April 2006 13:07, GeX wrote: > > Hello! > > > > I have FreeBSD 5.4 and I have tried to use Genius SlimStar Pro > > USB keyboard. > This doesn't match email subject. If you're not using CURRENT don't > post to this list. There are the questions and stable lists for just > that purpose. > > > The kernel configuration file contains following lines: > > -------------------------------------------------------- > > device uhci > > device ohci > > device usb > > device ukbd > > options KBD_INSTALL_CDEV > > -------------------------------------------------------- > > > > The /etc/rc.conf file contains following line: > > -------------------------------------------------------- > > usbd_enable=3D"YES" > Case in point. usbd no longer exists in the CURRENT. > > > -------------------------------------------------------- > > > > The /etc/rc.i386 file contains following line: > > -------------------------------------------------------- > > kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null > > -------------------------------------------------------- > > > > The device /dev/kbd0 is created during the boot time. But the > > system does not response properly on the keys pressing. The "Enter" > > key works fine but all other keys produces some mess charters like > > "^K" etc. Could you tell me, please, what's the problem and what's > > the way to solve it? > > -- > Anish Mistry > > > From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 21:06:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 075CE16A402 for ; Sat, 8 Apr 2006 21:06:22 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DC1F43D48 for ; Sat, 8 Apr 2006 21:06:21 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k38LLoSq092501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 17:21:55 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: GeX Date: Sat, 8 Apr 2006 17:06:10 -0400 User-Agent: KMail/1.9.1 References: <53cc795f0604081007u2b68b60tf2da0121eca46841@mail.gmail.com> <200604081456.42343.mistry.7@osu.edu> <53cc795f0604081249j2b85950bpe462353080f862f@mail.gmail.com> In-Reply-To: <53cc795f0604081249j2b85950bpe462353080f862f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2254929.0KYgdhWZQq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604081706.19818.mistry.7@osu.edu> X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.1/1384/Sat Apr 8 07:35:26 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 and Genius SlimStar Pro USB keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 21:06:22 -0000 --nextPart2254929.0KYgdhWZQq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 08 April 2006 15:49, GeX wrote: > sorry i mistyped, of course i meant freebsd 7.0-current at all > > On 4/8/06, Anish Mistry wrote: > > On Saturday 08 April 2006 13:07, GeX wrote: > > > Hello! > > > > > > I have FreeBSD 5.4 and I have tried to use Genius SlimStar > > > Pro USB keyboard. > > > > This doesn't match email subject. If you're not using CURRENT > > don't post to this list. There are the questions and stable > > lists for just that purpose. > > > > > The kernel configuration file contains following lines: > > > -------------------------------------------------------- > > > device uhci > > > device ohci > > > device usb > > > device ukbd > > > options KBD_INSTALL_CDEV > > > -------------------------------------------------------- > > > > > > The /etc/rc.conf file contains following line: > > > -------------------------------------------------------- > > > usbd_enable=3D"YES" > > > > Case in point. usbd no longer exists in the CURRENT. Remove usbd_enable, it doesn't do anything. Make sure devd is=20 enabled. > > > > > -------------------------------------------------------- > > > > > > The /etc/rc.i386 file contains following line: > > > -------------------------------------------------------- > > > kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null > > > -------------------------------------------------------- > > > > > > The device /dev/kbd0 is created during the boot time. But > > > the system does not response properly on the keys pressing. The > > > "Enter" key works fine but all other keys produces some mess > > > charters like "^K" etc. Could you tell me, please, what's the > > > problem and what's the way to solve it? You should probably use kbdmux and you shouldn't need anything=20 in /etc/rc.i386. With kbdmux everything should just work. If not=20 report back. =2D-=20 Anish Mistry --nextPart2254929.0KYgdhWZQq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEOCXLxqA5ziudZT0RAqqMAJwPaJhjFiJIfZ2kBm7Q17x7JxiDSgCeLYO2 g3vlTW7GAGu2Y9lF7selotk= =C5xq -----END PGP SIGNATURE----- --nextPart2254929.0KYgdhWZQq-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 8 21:10:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE01416A405 for ; Sat, 8 Apr 2006 21:10:57 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D607043D55 for ; Sat, 8 Apr 2006 21:10:54 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060408211054.DUKJ23465.mta10.adelphia.net@[192.168.1.254]>; Sat, 8 Apr 2006 17:10:54 -0400 Message-ID: <443826D2.7060002@savvis.net> Date: Sat, 08 Apr 2006 14:10:42 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rong-En Fan References: <7daacbbe0604080204q1d8b8995kbadc61eb1461eefd@mail.gmail.com> <4437E1AD.7000303@savvis.net> <6eb82e0604081025i506ae352m583d6057d17a9677@mail.gmail.com> In-Reply-To: <6eb82e0604081025i506ae352m583d6057d17a9677@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PS/2 keyboard not working in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Apr 2006 21:10:57 -0000 Rong-En Fan wrote: >>>With FreeBSD 7.0-CURRENT, I can't type anything with my PS/2 keyboard >>>when I enter in ddb (ctrl+alt+esc) in the prompt 'db>'. >> >>known issue. this is due to kbdmux(4) being enabled by default. i'm >>working on this (no eta yet). > > Does this mean that if we want to use ddb, then we have to disable kbdmux? well, yes and no. usb keyboards, for example, work in ddb with kbdmux(4). for whatever reason only ps/2 keyboards are affected. > Maybe we should document this know issue in the manual pages? this used to work. this is relatively new issue. thanks, max