From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 00:53: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 D729816A4DA for ; Sun, 30 Jul 2006 00:53:43 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4AD43D46 for ; Sun, 30 Jul 2006 00:53:43 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id 508CB5880B; Sat, 29 Jul 2006 17:53:42 -0700 (PDT) Date: Sat, 29 Jul 2006 17:53:42 -0700 From: Paul Allen To: Michal Mertl Message-ID: <20060730005342.GJ12597@groat.ugcs.caltech.edu> References: <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> <1154217036.23616.28.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1154217036.23616.28.camel@genius.i.cz> Sender: jd@ugcs.caltech.edu Cc: Peter Jeremy , Paul Allen , Brian Candler , freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 00:53:43 -0000 >From Michal Mertl , Sun, Jul 30, 2006 at 01:50:36AM +0200: > Michal Mertl wrote: > > Paul Allen wrote: > > > Surely all you need to do is a cheap crit_enter,crit_exit > > > while updating the 64-bit per cpu counters. and on > > > a 64-bit arch you skip the crit_enter,crit_exit. > > > > Critical_enter/exit seem to be quite lightweight (single > > read/modify/write of a variable). > > One more question. Why do you say that crit_* can be avoided on 64-bit > arch? If the reason was that "increment of a 64 bit number is one > operation there" it probably is not true - as somebody already stated, > some instruction sets don't allow atomic increment of a memory location. > > Michal Which FreeBSD tier-I 64b arch do you have in mind... > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 09:07: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 E1BBB16A4DA for ; Sun, 30 Jul 2006 09:07:50 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4205D43D4C for ; Sun, 30 Jul 2006 09:07:49 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6U97l4m080418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 11:07:47 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Paul Allen In-Reply-To: <20060730005342.GJ12597@groat.ugcs.caltech.edu> References: <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> <1154217036.23616.28.camel@genius.i.cz> <20060730005342.GJ12597@groat.ugcs.caltech.edu> Content-Type: text/plain Date: Sun, 30 Jul 2006 11:07:31 +0200 Message-Id: <1154250451.23616.37.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 09:07:51 -0000 Paul Allen wrote: > >From Michal Mertl , Sun, Jul 30, 2006 at 01:50:36AM +0200: > > Michal Mertl wrote: > > > Paul Allen wrote: > > > > Surely all you need to do is a cheap crit_enter,crit_exit > > > > while updating the 64-bit per cpu counters. and on > > > > a 64-bit arch you skip the crit_enter,crit_exit. > > > > > > Critical_enter/exit seem to be quite lightweight (single > > > read/modify/write of a variable). > > > > One more question. Why do you say that crit_* can be avoided on 64-bit > > arch? If the reason was that "increment of a 64 bit number is one > > operation there" it probably is not true - as somebody already stated, > > some instruction sets don't allow atomic increment of a memory location. > > > > Michal > > Which FreeBSD tier-I 64b arch do you have in mind... I was referring to what Peter Jeremy said earlier in this thread: > RISC architectures usually only have TAS lock primitives (because "inc > mem" doesn't exist) and so require a spinlock to perform an atomic > update. I don't know anything that low level about any platform but i386. Michal From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 11:30: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 16BFE16A4DE for ; Sun, 30 Jul 2006 11:30:35 +0000 (UTC) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 255E143D45 for ; Sun, 30 Jul 2006 11:30:29 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 0DD1B1A789; Sun, 30 Jul 2006 13:30:26 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63554-09; Sun, 30 Jul 2006 13:30:24 +0200 (CEST) Received: from [192.168.1.89] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id C65E61A74E; Sun, 30 Jul 2006 13:30:23 +0200 (CEST) Message-ID: <44CC984C.1010908@shapeshifter.se> Date: Sun, 30 Jul 2006 13:30:20 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: gurney_j@resnet.uoregon.edu References: <44C61470.3070005@shapeshifter.se> <20060725173924.GR96589@funkthat.com> <44C79A66.6000204@shapeshifter.se> In-Reply-To: <44C79A66.6000204@shapeshifter.se> Content-Type: multipart/mixed; boundary="------------020503090300040103040502" X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-current@freebsd.org Subject: Re: Extending EVFILT_NETDEV to support ip-address changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 11:30:35 -0000 This is a multi-part message in MIME format. --------------020503090300040103040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fredrik Lindberg wrote: > The documented way of using EVFILT_NETDEV according to kqueue(2) is to > obtain the status from fflags, but as it apparently sets data too > somebody is using it, that's for sure. > > Users of EVFILT_NETDEV are required to pass a mask of > NOTE_LINK{UP,DOWN,INV} in fflags with the initial kevent call, otherwise > no events will fire. > > What if we add NOTE_ADDR{NEW,DEL} as bit masks and change filt_netdev to > only set kn_data when a monitored event occurs instead of just setting > it regardless of if the event is being monitored or not. > If we also restrict the values of kn_data to NOTE_LINK{UP,DOWN,INV}, > existing applications shouldn't break as they would only receive the > events they subscribed to and both data and fflags would be > intact. NOTE_ADDR{NEW,DEL} would be obtain only through fflags and > kn_data would be left as it is in these cases (0 with EV_CLEAR set). > > Doing it this way shouldn't break the API, as no fields would be touched > because kn_sfflags & hint would fail for ADDR{NEW,DEL} on existing > applications as they would only be subscribed to one or more of the > NOTE_LINK{UP,DOWN,INV} events. > But maybe I'm missing some rare edge case... > Replying to myself here, but anyway. I've attached a complete patch with the modified filt_netdev as described above. Fredrik Lindberg --------------020503090300040103040502 Content-Type: text/plain; name="kqueue-netdev-20060730.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kqueue-netdev-20060730.patch" Index: sys/event.h =================================================================== RCS file: /home/ncvs/src/sys/sys/event.h,v retrieving revision 1.36 diff -u -r1.36 event.h --- sys/event.h 16 Mar 2006 11:19:36 -0000 1.36 +++ sys/event.h 30 Jul 2006 10:54:31 -0000 @@ -115,6 +115,8 @@ #define NOTE_LINKUP 0x0001 /* link is up */ #define NOTE_LINKDOWN 0x0002 /* link is down */ #define NOTE_LINKINV 0x0004 /* link state is invalid */ +#define NOTE_ADDRNEW 0x0008 /* ip-address added */ +#define NOTE_ADDRDEL 0x0010 /* ip-address removed */ struct knote; SLIST_HEAD(klist, knote); Index: netinet/in.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.93 diff -u -r1.93 in.c --- netinet/in.c 24 Jan 2006 16:19:31 -0000 1.93 +++ netinet/in.c 30 Jul 2006 10:54:31 -0000 @@ -399,8 +399,10 @@ (struct sockaddr_in *) &ifr->ifr_addr, 1); if (error != 0 && iaIsNew) break; - if (error == 0) + if (error == 0) { EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_ADDRNEW); + } return (0); case SIOCSIFNETMASK: @@ -443,8 +445,10 @@ if ((ifp->if_flags & IFF_BROADCAST) && (ifra->ifra_broadaddr.sin_family == AF_INET)) ia->ia_broadaddr = ifra->ifra_broadaddr; - if (error == 0) + if (error == 0) { EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_ADDRNEW); + } return (error); case SIOCDIFADDR: @@ -460,6 +464,7 @@ */ in_ifadown(&ia->ia_ifa, 1); EVENTHANDLER_INVOKE(ifaddr_event, ifp); + KNOTE_UNLOCKED(&ifp->if_klist, NOTE_ADDRDEL); error = 0; break; Index: net/if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.261 diff -u -r1.261 if.c --- net/if.c 9 Jul 2006 06:04:00 -0000 1.261 +++ net/if.c 30 Jul 2006 10:54:31 -0000 @@ -265,10 +265,12 @@ knlist_remove_inevent(klist, kn); return (1); } - if (hint != 0) - kn->kn_data = hint; /* current status */ - if (kn->kn_sfflags & hint) + + if (kn->kn_sfflags & hint) { kn->kn_fflags |= hint; + if (hint & (NOTE_LINKUP | NOTE_LINKDOWN)) + kn->kn_data = hint; /* current link status */ + } return (kn->kn_fflags != 0); } --------------020503090300040103040502-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 11:54: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 3D99E16A4E1 for ; Sun, 30 Jul 2006 11:54:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail31.syd.optusnet.com.au (mail31.syd.optusnet.com.au [211.29.132.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F8E43D55 for ; Sun, 30 Jul 2006 11:54:30 +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 mail31.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6UBsScI000800 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Jul 2006 21:54:28 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6UBsRaI002633; Sun, 30 Jul 2006 21:54:27 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6UBsRaJ002632; Sun, 30 Jul 2006 21:54:27 +1000 (EST) (envelope-from peter) Date: Sun, 30 Jul 2006 21:54:27 +1000 From: Peter Jeremy To: Michal Mertl Message-ID: <20060730115427.GD1310@turion.vk2pj.dyndns.org> References: <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> <1154217036.23616.28.camel@genius.i.cz> <20060730005342.GJ12597@groat.ugcs.caltech.edu> <1154250451.23616.37.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline In-Reply-To: <1154250451.23616.37.camel@genius.i.cz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: Paul Allen , freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 11:54:31 -0000 --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2006-Jul-30 11:07:31 +0200, Michal Mertl wrote: >Paul Allen wrote: >> Which FreeBSD tier-I 64b arch do you have in mind... > >I was referring to what Peter Jeremy said earlier in this thread: > >> RISC architectures usually only have TAS lock primitives (because "inc >> mem" doesn't exist) and so require a spinlock to perform an atomic >> update. This was based on an examination of /usr/src/sys/*/include/atomic.h. It looks like I was overly quick because the RISC architectures are using compare-and-swap, rather than test-and-set primitives - sorry about the error. The details are: - Alpha (RIP) used a loop around a locked conditional store - amd64 appears to support RMW - arm doesn't support 64-bit atomic operations - i386 doesn't support 64-bit atomic operations (but could implement them using cmpxchg8b in a loop) - ia64 uses cmpxchg in a loop - ppc doesn't support 64-bit atomic operations - sparc64 uses cas in a loop. Whilst true spinlocks are not needed, amd64 is the only architecture FreeBSD supports that does not require some sort of loop to perform a 64-bit atomic operation. --=20 Peter Jeremy --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEzJ3z/opHv/APuIcRAvVoAJwJlui519oOiZLyP8+5iFYaitQ10wCePe84 eyYj5Yh1vv42M52G46YwlBg= =mU7A -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 12:23: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 8917E16A4DA for ; Sun, 30 Jul 2006 12:23:48 +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 1970C43D45 for ; Sun, 30 Jul 2006 12:23:48 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 917DF5DAC; Sun, 30 Jul 2006 08:23:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com 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 1ssIzrfqXHjI; Sun, 30 Jul 2006 08:23:46 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 3B1505C33; Sun, 30 Jul 2006 08:23:46 -0400 (EDT) Message-ID: <44CCA4CD.1050309@mac.com> Date: Sun, 30 Jul 2006 08:23:41 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Jeremy References: <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> <1154217036.23616.28.camel@genius.i.cz> <20060730005342.GJ12597@groat.ugcs.caltech.edu> <1154250451.23616.37.camel@genius.i.cz> <20060730115427.GD1310@turion.vk2pj.dyndns.org> In-Reply-To: <20060730115427.GD1310@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: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 12:23:48 -0000 Peter Jeremy wrote: [ ... ] > This was based on an examination of /usr/src/sys/*/include/atomic.h. > It looks like I was overly quick because the RISC architectures are > using compare-and-swap, rather than test-and-set primitives - sorry > about the error. The details are: [ ... ] > - ppc doesn't support 64-bit atomic operations lwarx/stwcx...? http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/lwarx.htm http://www-128.ibm.com/developerworks/library/pa-atom/ > - sparc64 uses cas in a loop. > > Whilst true spinlocks are not needed, amd64 is the only architecture > FreeBSD supports that does not require some sort of loop to perform > a 64-bit atomic operation. You can use membar instructions on the SPARCv9 to enforce various memory models (RMO, PSO, TSO, if not full sequential consistency). -- -Chuck From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 15:33: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 3A18516A4DE for ; Sun, 30 Jul 2006 15:33: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 C6E8F43D45 for ; Sun, 30 Jul 2006 15:33: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 4AA8D46BF8; Sun, 30 Jul 2006 11:33:36 -0400 (EDT) Date: Sun, 30 Jul 2006 16:33:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Michal Mertl In-Reply-To: <1154217036.23616.28.camel@genius.i.cz> Message-ID: <20060730162756.N16341@fledge.watson.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <200607271058.13055.jhb@freebsd.org> <20060728121525.GA44917@uk.tiscali.com> <200607280928.36573.jhb@freebsd.org> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <1154189612.1565.10.camel@genius.i.cz> <20060729205655.GE748@turion.vk2pj.dyndns.org> <20060729211530.GA50342@uk.tiscali.com> <1154212340.3609.18.camel@genius.i.cz> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> <1154217036.23616.28.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , Paul Allen , Brian Candler , freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jul 2006 15:33:37 -0000 On Sun, 30 Jul 2006, Michal Mertl wrote: > Michal Mertl wrote: >> Paul Allen wrote: >>> Surely all you need to do is a cheap crit_enter,crit_exit >>> while updating the 64-bit per cpu counters. and on >>> a 64-bit arch you skip the crit_enter,crit_exit. >> >> Critical_enter/exit seem to be quite lightweight (single read/modify/write >> of a variable). > > One more question. Why do you say that crit_* can be avoided on 64-bit arch? > If the reason was that "increment of a 64 bit number is one operation there" > it probably is not true - as somebody already stated, some instruction sets > don't allow atomic increment of a memory location. The UMA zone allocator and malloc allocator both use critical sections to protect their per-cpu statistics and this works quite well in practice. However, critical sections are also significantly not-free compared to a simple integer increment. The argument for using 64-bit arithmetic without synchronization is that a small amount of occasional inaccuracy could be tolerated (a 64-bit increment being lost due to a race, for example), but that large amounts associated with 64-bit arithmetic using 32-bit operations, might not be (a 32-bit wrap being counted 0 times or 2 times). If statistics are going to be protected using critical sections, I suggest we investigate a way to minimize the number of critical sections we enter and exit for statistics purposes, ideally minimizing and amortizing the entry/exit of critical sections. The more time you spend in critical sections, the more likely it is an interrupt will fire during the critical section, and our critical sections are optimized to optimistically assume that interrupts won't fire during critical sections. FWIW, One of the reasons some of the lower level network statistics haven't been modified to occur in critical sections or locked regions is that there are still open design questions about locking for network interfaces and address lists. It's likely that once that work is done, locking of the statistics can be done "for free" by piggy-backing it on other necessary work. I've wanted to see 64-bit statistics on our network interfaces for a long time -- I wrap 32-bit counters very quickly, myself, and it will only happen more quickly in the future! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Jul 30 20:39: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 29CD716A4DD for ; Sun, 30 Jul 2006 20:39:27 +0000 (UTC) (envelope-from Wolfram.Fenske@Student.Uni-Magdeburg.DE) Received: from mail.uni-magdeburg.de (mail.uni-magdeburg.de [141.44.1.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A518C43D45 for ; Sun, 30 Jul 2006 20:39:26 +0000 (GMT) (envelope-from Wolfram.Fenske@Student.Uni-Magdeburg.DE) Received: from sunny.urz.uni-magdeburg.de ([141.44.8.7]) by mail.uni-magdeburg.de with esmtp (EXIM Version 4.62) id 1G7I4I-000252-LW; Sun, 30 Jul 2006 22:39:24 +0200 Received: from hondo. (pD9515191.dip0.t-ipconnect.de [217.81.81.145]) (authenticated bits=0) by sunny.urz.uni-magdeburg.de (8.12.10/8.12.10) with ESMTP id k6UKdKSX016497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Jul 2006 22:39:21 +0200 To: Markus Trippelsdorf References: <20060729105933.GA687@bsd.trippelsdorf.de> From: Wolfram Fenske Date: Sun, 30 Jul 2006 22:37:13 +0200 In-Reply-To: <20060729105933.GA687@bsd.trippelsdorf.de> (Markus Trippelsdorf's message of "Sat, 29 Jul 2006 12:59:33 +0200") Message-ID: <86mzaqn81y.fsf@student.uni-magdeburg.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Spam-Report: ---- Start SpamAssassin results -2.6 points, 5.0 required; -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list ---- End of SpamAssassin results X-Scan-Signature: a6013c0e33abd25698719c75475606ab Cc: freebsd-current@freebsd.org Subject: Re: Keyboard LEDs always on X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 20:39:27 -0000 Markus Trippelsdorf writes: > After upgrading from -stable to -current, the three LEDs on my > USB keyboard are switched on at boot time and cannot be controlled > by the caps-, num- or scroll-lock keys anymore. > Is this a known problem? I would be grateful for any hints. I can't really help you solve this, but I can confirm it. I had the same problem with my USB keyboard. It didn't happen with an older -current from around around april. Wolfram -- A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 01:49: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 64A6A16A4DA for ; Mon, 31 Jul 2006 01:49:22 +0000 (UTC) (envelope-from emil@cs.rmit.edu.au) Received: from its-mu-mail1.its.rmit.edu.au (its-mu-mail1.its.rmit.edu.au [131.170.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DC743D53 for ; Mon, 31 Jul 2006 01:49:20 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by its-mu-mail1.its.rmit.edu.au (8.13.7/8.13.7/mail1) with ESMTP id k6V1jC8T000562; Mon, 31 Jul 2006 11:49:08 +1000 (EST) Received: from goanna.cs.rmit.edu.au (root@goanna.cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.12.10/8.12.10/cshub) with ESMTP id k6V1eYHl013333; Mon, 31 Jul 2006 11:40:34 +1000 (EST) Received: from goanna.cs.rmit.edu.au (emil@localhost [127.0.0.1]) by goanna.cs.rmit.edu.au (8.13.4+Sun/8.13.4/csnode) with ESMTP id k6V1eXQ3015145; Mon, 31 Jul 2006 11:40:34 +1000 (EST) Received: (from emil@localhost) by goanna.cs.rmit.edu.au (8.13.4+Sun/8.13.3/Submit) id k6V1eN6I015126; Mon, 31 Jul 2006 11:40:23 +1000 (EST) Date: Mon, 31 Jul 2006 11:40:23 +1000 From: Emil Mikulic To: Wolfram Fenske Message-ID: <20060731014023.GB12725@cs.rmit.edu.au> References: <20060729105933.GA687@bsd.trippelsdorf.de> <86mzaqn81y.fsf@student.uni-magdeburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mzaqn81y.fsf@student.uni-magdeburg.de> X-Operating-System: SunOS 5.10 X-PGP-Fingerprint: D2B4 7C14 0C41 9AE5 8D2B 16B0 D3D6 F910 8E4C 5D35 X-Authentication-Warning: localhost: emil pwned teh intarweb User-Agent: Mutt/1.5.11 X-Scanned-By: MIMEDefang 2.44 Cc: freebsd-current@freebsd.org, Markus Trippelsdorf Subject: Re: Keyboard LEDs always on X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 01:49:22 -0000 On Sun, Jul 30, 2006 at 10:37:13PM +0200, Wolfram Fenske wrote: > Markus Trippelsdorf writes: > > > After upgrading from -stable to -current, the three LEDs on my > > USB keyboard are switched on at boot time and cannot be controlled > > by the caps-, num- or scroll-lock keys anymore. > > Is this a known problem? I would be grateful for any hints. > > I can't really help you solve this, but I can confirm it. I had the > same problem with my USB keyboard. It didn't happen with an older > -current from around around april. I'm seeing it too, but only in X11. If I switch to a textmode console, NumLock and CapsLock behave as I expect them to. ScrollLock does weird wacky things to the LEDs though... This is on a Dell GX280 with a USB keyboard. --Emil From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 04:34: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 D076016A4DF for ; Mon, 31 Jul 2006 04:34:41 +0000 (UTC) (envelope-from freebsd@bitfreak.org) Received: from mail.twinthornes.com (mail.twinthornes.com [65.75.198.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CADE43D49 for ; Mon, 31 Jul 2006 04:34:41 +0000 (GMT) (envelope-from freebsd@bitfreak.org) Received: from [10.242.169.24] (c-67-171-135-169.hsd1.or.comcast.net [67.171.135.169]) by mail.twinthornes.com (Postfix) with ESMTP id D618FECD; Sun, 30 Jul 2006 21:34:39 -0700 (PDT) Message-ID: <44CD8860.70600@bitfreak.org> Date: Sun, 30 Jul 2006 21:34:40 -0700 From: freebsd@bitfreak.org User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Emil Mikulic References: <20060729105933.GA687@bsd.trippelsdorf.de> <86mzaqn81y.fsf@student.uni-magdeburg.de> <20060731014023.GB12725@cs.rmit.edu.au> In-Reply-To: <20060731014023.GB12725@cs.rmit.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Wolfram Fenske , Markus Trippelsdorf Subject: Re: Keyboard LEDs always on X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 04:34:41 -0000 Emil Mikulic wrote: > On Sun, Jul 30, 2006 at 10:37:13PM +0200, Wolfram Fenske wrote: >> Markus Trippelsdorf writes: >> >>> After upgrading from -stable to -current, the three LEDs on my >>> USB keyboard are switched on at boot time and cannot be controlled >>> by the caps-, num- or scroll-lock keys anymore. >>> Is this a known problem? I would be grateful for any hints. >> I can't really help you solve this, but I can confirm it. I had the >> same problem with my USB keyboard. It didn't happen with an older >> -current from around around april. > > I'm seeing it too, but only in X11. If I switch to a textmode console, > NumLock and CapsLock behave as I expect them to. ScrollLock does weird > wacky things to the LEDs though... > > This is on a Dell GX280 with a USB keyboard. I recall having this problem years ago with a keyboard. The trick, IIRC though well-fogged memory, involved editting a keymap and changing the codes used to toggle the LEDs. This may not be applicable to USB keyboards, however. From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 05:16: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 245F816A4DA for ; Mon, 31 Jul 2006 05:16:09 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C85143D53 for ; Mon, 31 Jul 2006 05:16:08 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G7Q8J-0003t9-LC; Mon, 31 Jul 2006 07:16:03 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: Message from Pyun YongHyeon of "Wed, 26 Jul 2006 11:22:35 +0900." <20060726022235.GB14991@cdnetworks.co.kr> X-Attribution: BOFH Date: Mon, 31 Jul 2006 07:16:03 +0200 Sender: ianf@hetzner.co.za Message-Id: Cc: current@freebsd.org Subject: Re: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 05:16:09 -0000 Pyun YongHyeon wrote: > On Tue, Jul 25, 2006 at 08:07:04AM +0200, Ian FREISLICH wrote: > > Hi > > > > It seems that placing an em(4) interface into promiscuous mode the > > card stops doing hardware offload of 802.1Q tagging, in fact, it > > stops tagging entirely if vlanhwtag is enabled on the card. > > > > With vlanhwtag: > > 15:40:48.050645 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0 800), length 70: (tos 0x10, ttl 255, id 44821, offset 0, flags [DF], proto: VRR P (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.4 2.167,148.235.231.80,70.180.123.113,201.169.28.232,19.31.18.203,59.148.50.175 > > > > Without vlanhwtag: > > 15:40:57.419522 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype 802.1Q (0 x8100), length 74: vlan 1001, p 0, ethertype IPv4, (tos 0x10, ttl 255, id 44867 , offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.1 8: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.42.176,8.148.142.115,171.178.137.11,211.216.40 .239,67.124.122.122,253.155.32.152 > > > > The interface is placed in promiscuous mode by the carp driver. > > > > em0: flags=8943 mtu 1500 > > options=cb > > ether 00:04:23:cf:50:00 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > vlan1001: flags=8943 mtu 1 500 > > inet 196.30.82.62 netmask 0xfffffff0 broadcast 196.30.82.63 > > ether 00:04:23:cf:50:00 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > vlan: 1001 parent interface: em0 > > > > carp1001: flags=49 mtu 1500 > > inet 196.30.82.60 netmask 0xfffffff0 > > carp: BACKUP vhid 2 advbase 1 advskew 0 > > > > Hardware VLAN tagging was disabled in em(4) when it operates > in promiscuous mode and em(4) will insert a VLAN tag in the > driver. Um, no. When an em interface with hardware VLAN tagging enabled is placed in promiscuous mode, it just _stops_ tagging. Entirely. The 802.1Q vlan just breaks. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 05:43:52 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 3022416A4DD for ; Mon, 31 Jul 2006 05:43:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7932D43D45 for ; Mon, 31 Jul 2006 05:43:51 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so131999nzn for ; Sun, 30 Jul 2006 22:43:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=abbBRGMZC5H/6QWTA8/GGjyJJcbfS/Ngjycd9Y0QBe3bj+2wYBsjyJH92Ul/pfViCOmhft6L0LKLP/XuCnTQjhOLo8v2mL5yyZZNxouo01emOu1g4oWpMC2Uu6DND8TPvU+gPspb6mb558oe5V764pcHkPzhmH5r6KLO/U3PdSY= Received: by 10.65.139.9 with SMTP id r9mr2908478qbn; Sun, 30 Jul 2006 22:43:50 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 38sm123664nza.2006.07.30.22.43.48; Sun, 30 Jul 2006 22:43:50 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6V5iMcU036578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jul 2006 14:44:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6V5iLJ1036577; Mon, 31 Jul 2006 14:44:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 31 Jul 2006 14:44:21 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20060731054421.GB35573@cdnetworks.co.kr> References: <20060726022235.GB14991@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 05:43:52 -0000 On Mon, Jul 31, 2006 at 07:16:03AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Tue, Jul 25, 2006 at 08:07:04AM +0200, Ian FREISLICH wrote: > > > Hi > > > > > > It seems that placing an em(4) interface into promiscuous mode the > > > card stops doing hardware offload of 802.1Q tagging, in fact, it > > > stops tagging entirely if vlanhwtag is enabled on the card. > > > > > > With vlanhwtag: > > > 15:40:48.050645 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0 > 800), length 70: (tos 0x10, ttl 255, id 44821, offset 0, flags [DF], proto: VRR > P (112), length: 56) 196.30.82.61 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, > prio 10, authtype none, intvl 1s, length 36, addrs(7): 157.248.206.115,76.246.4 > 2.167,148.235.231.80,70.180.123.113,201.169.28.232,19.31.18.203,59.148.50.175 > > > > > > Without vlanhwtag: > > > 15:40:57.419522 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype 802.1Q (0 > x8100), length 74: vlan 1001, p 0, ethertype IPv4, (tos 0x10, ttl 255, id 44867 > , offset 0, flags [DF], proto: VRRP (112), length: 56) 196.30.82.61 > 224.0.0.1 > 8: VRRPv2, Advertisement, vrid 2, prio 10, authtype none, intvl 1s, length 36, > addrs(7): 157.248.206.115,76.246.42.176,8.148.142.115,171.178.137.11,211.216.40 > .239,67.124.122.122,253.155.32.152 > > > > > > The interface is placed in promiscuous mode by the carp driver. > > > > > > em0: flags=8943 mtu 1500 > > > options=cb > > > ether 00:04:23:cf:50:00 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > vlan1001: flags=8943 mtu 1 > 500 > > > inet 196.30.82.62 netmask 0xfffffff0 broadcast 196.30.82.63 > > > ether 00:04:23:cf:50:00 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > vlan: 1001 parent interface: em0 > > > > > > carp1001: flags=49 mtu 1500 > > > inet 196.30.82.60 netmask 0xfffffff0 > > > carp: BACKUP vhid 2 advbase 1 advskew 0 > > > > > > > Hardware VLAN tagging was disabled in em(4) when it operates > > in promiscuous mode and em(4) will insert a VLAN tag in the > > driver. > > Um, no. When an em interface with hardware VLAN tagging enabled > is placed in promiscuous mode, it just _stops_ tagging. Entirely. > The 802.1Q vlan just breaks. > Would you try latest em(4) in CURRENT?(if_em.c, rev. 1.122) > Ian > > -- > Ian Freislich -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 06:24: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 46D5516A4E0 for ; Mon, 31 Jul 2006 06:24:31 +0000 (UTC) (envelope-from rmgls@wanadoo.fr) Received: from smtp14.orange.fr (smtp14.orange.fr [193.252.23.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id E020643D4C for ; Mon, 31 Jul 2006 06:24:30 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from smtp-msa-out14.orange.fr (mwinf1401 [172.22.145.23]) by mwinf1405.orange.fr (SMTP Server) with ESMTP id B8D151C0C2F5 for ; Mon, 31 Jul 2006 08:21:02 +0200 (CEST) Received: from wanadoo.fr (ARouen-252-1-111-65.w86-208.abo.wanadoo.fr [86.208.62.65]) by mwinf1401.orange.fr (SMTP Server) with ESMTP id 0B821700009C for ; Mon, 31 Jul 2006 08:21:01 +0200 (CEST) X-ME-UUID: 20060731062101472.0B821700009C@mwinf1401.orange.fr To: freebsd-current@freebsd.org From: rmgls@wanadoo.Fr Date: Mon, 31 Jul 2006 08:20:52 +0200 Sender: rmgls@wanadoo.fr Message-Id: <20060731062101.0B821700009C@mwinf1401.orange.fr> Subject: two uarts 32bits pccard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 06:24:31 -0000 hi all, a new 32bits (2 uarts) pccard is not recognized with the following report: cbb0: card inserted: event=0x00000006, state=30000910 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 3V pccard0: read_cis pcib2: pccard0 requested memory range 0xb0000000-0xb00fffff: good cis mem map 0xe62a9000 (resource: 0xb0010000) pccard0: CIS tuple chain: CISTPL_DEVICE type=null speed=null 01 02 00 ff unhandled CISTPL 3 03 00 CISTPL_END ff cis mem map e62a9000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: Card has no functions! cbb0: PC Card card activation failed Many thanks for your help. rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 09:43: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 3FA2A16A4DA; Mon, 31 Jul 2006 09:43:26 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F54743D46; Mon, 31 Jul 2006 09:43:24 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6V9hJ4M022658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Jul 2006 11:43:19 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6V9hHwU022656; Mon, 31 Jul 2006 11:43:17 +0200 (CEST) Date: Mon, 31 Jul 2006 11:43:17 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20060731094316.GA22563@stud.fit.vutbr.cz> References: <44C39D7E.30102@mail.web.am> <200607251230.39953.jhb@freebsd.org> <20060727131344.GA81122@stud.fit.vutbr.cz> <200607271357.36839.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607271357.36839.jhb@freebsd.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org, Gaspar Chilingarov Subject: Re: Are there any beakage of linuxulator (on amd64)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 09:43:26 -0000 On Thu, Jul 27, 2006 at 01:57:36PM -0400, John Baldwin wrote: > On Thursday 27 July 2006 09:13, Divacky Roman wrote: > > > > this thursday at work I'll try to provide some more info, what exaclty > do you > > > > need? is what -DDEBUG prints enough? > > > > > > Probably. The changes in question were just in the linux semctl function, > so you > > > really only need printf's for that function to figure out which case it is > blowing > > > up one and why. > > > > soooo.... > > > > I checked the coredump and found this: > > > > 1) its not acroread what coredumps but bash binary (the binary used for the > > script) > > when I manually tried running the bash and "exec /bin/ls" etc. it worked > > I havent investigated further waht causes the coredump > > > > 2) I put printf() at the very begining of the linux_semctl() function and > > ran the acroread binary. The printf was not printed (ie. it didnt used the > > linxu_semctl function) > > That's odd, because the person who did the binary test claimed it was just the > change to this file that caused the breakage. That is, if they reverted > linux_ipc.c to the revision before the kern_semctl() changes it worked fine. > Can you test that to see if that's true for you? (You'll have to revert last > revision of linux_util.h as well.) pls, can you provide me patch which contains all the changes? thnx From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 11:26: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 A476C16A4DA for ; Mon, 31 Jul 2006 11:26:05 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10E7F43D49 for ; Mon, 31 Jul 2006 11:26:04 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G7VuJ-000560-Dh; Mon, 31 Jul 2006 13:25:59 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: Message from Pyun YongHyeon of "Mon, 31 Jul 2006 14:44:21 +0900." <20060731054421.GB35573@cdnetworks.co.kr> X-Attribution: BOFH Date: Mon, 31 Jul 2006 13:25:59 +0200 Sender: ianf@hetzner.co.za Message-Id: Cc: current@freebsd.org Subject: Re: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 11:26:05 -0000 Pyun YongHyeon wrote: > On Mon, Jul 31, 2006 at 07:16:03AM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > Hardware VLAN tagging was disabled in em(4) when it operates > > > in promiscuous mode and em(4) will insert a VLAN tag in the > > > driver. > > > > Um, no. When an em interface with hardware VLAN tagging enabled > > is placed in promiscuous mode, it just _stops_ tagging. Entirely. > > The 802.1Q vlan just breaks. > > > > Would you try latest em(4) in CURRENT?(if_em.c, rev. 1.122) No change with r1.122 (used to be r1.116). Note that with VLAN_HWTAGGING enabled, both hosts bring up their carp interface as master. This is because none of the frames are tagged when the carp driver puts the vlan interface which in turn puts the em interface into promiscuous mode. You stated that in an earlier email that VLAN_HWTAGGING is disabled when the interface is placed in promiscuous mode. Is there any reason for this appart from not being to view the VLAN header with tcpdump? My site runs a lot of VLANS (500+) and it would be nice to offload this work to the card. With vlanhwtag enabled: Host1 em1: flags=8943 mtu 1500 options=db ether 00:04:23:ce:cc:cd media: Ethernet autoselect (1000baseTX ) status: active vlan1: flags=8943 mtu 1500 options=3 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:04:23:ce:cc:cd media: Ethernet autoselect (1000baseTX ) status: active vlan: 1 parent interface: em1 carp2: flags=49 mtu 1500 inet 10.0.0.3 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0 Host2 em1: flags=8943 mtu 1500 options=cb ether 00:04:23:ce:ca:a1 media: Ethernet autoselect (1000baseTX ) status: active vlan1: flags=8943 mtu 1500 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:04:23:ce:ca:a1 media: Ethernet autoselect (1000baseTX ) status: active vlan: 1 parent interface: em1 carp2: flags=49 mtu 1500 inet 10.0.0.3 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0 With vlanhwtag disabled: Host1 em1: flags=8943 mtu 1500 options=cb ether 00:04:23:ce:cc:cd media: Ethernet autoselect (1000baseTX ) status: active vlan1: flags=8943 mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:04:23:ce:cc:cd media: Ethernet autoselect (1000baseTX ) status: active vlan: 1 parent interface: em1 carp2: flags=49 mtu 1500 inet 10.0.0.3 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0 Host2 em1: flags=8943 mtu 1500 options=cb ether 00:04:23:ce:ca:a1 media: Ethernet autoselect (1000baseTX ) status: active vlan1: flags=8943 mtu 1500 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:04:23:ce:ca:a1 media: Ethernet autoselect (1000baseTX ) status: active vlan: 1 parent interface: em1 carp2: flags=49 mtu 1500 inet 10.0.0.3 netmask 0xffffff00 carp: BACKUP vhid 2 advbase 1 advskew 0 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 17:35: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 2068216A4E5 for ; Mon, 31 Jul 2006 17:35:51 +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 4782343D45 for ; Mon, 31 Jul 2006 17:35:49 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7bg1-0007ax-GR for freebsd-current@freebsd.org; Mon, 31 Jul 2006 19:35:39 +0200 Received: from p54ba7426.dip.t-dialin.net ([84.186.116.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 19:35:37 +0200 Received: from der_julian by p54ba7426.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 19:35:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Mon, 31 Jul 2006 19:35:14 +0200 Lines: 405 Message-ID: <86mzap4qzx.fsf@dellbeast.localnet> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p54ba7426.dip.t-dialin.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.5-b27 (berkeley-unix) Cancel-Lock: sha1:eHg0LsNHE18ZJ5uJ7z8tMhw8vb8= Sender: news Subject: SSP/ProPolice build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 17:35:51 -0000 --=-=-= Hello, I just tried to build a SSP-enabled world (with patches from http://tataz.chchile.org/~tataz/FreeBSD/SSP/) and ended up with: mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include config.c /usr/src/usr.sbin/config/main.c lang.c /usr/src/usr.sbin/config/mkmakefile.c /usr/src/usr.sbin/config/mkheaders.c /usr/src/usr.sbin/config/mkoptions.c /usr/src/usr.sbin/config/config.y:78:20: config.h: No such file or directory /usr/src/usr.sbin/config/main.c:55:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/lang.l:38:20: config.h: No such file or directory /usr/src/usr.sbin/config/mkmakefile.c:49:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/mkheaders.c:48:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/mkoptions.c:49:19: y.tab.h: No such file or directory (full log as attachment) --=-=-= Content-Disposition: attachment; filename=build.log Content-Transfer-Encoding: quoted-printable Content-Description: Build log -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/tmp mkdir -p /usr/obj/usr/src/tmp/legacy/usr/bin mkdir -p /usr/obj/usr/src/tmp/legacy/usr/games mkdir -p /usr/obj/usr/src/tmp/legacy/usr/include/c++/3.4 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/include/sys mkdir -p /usr/obj/usr/src/tmp/legacy/usr/lib mkdir -p /usr/obj/usr/src/tmp/legacy/usr/libexec mkdir -p /usr/obj/usr/src/tmp/legacy/usr/sbin mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/dict mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devX100 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devX100-12 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devX75 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devX75-12 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devascii mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devcp1047 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devdvi mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devhtml mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devkoi8-r mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devlatin1 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devlbp mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devlj4 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devps mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devutf8 mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/tmac/mdoc mkdir -p /usr/obj/usr/src/tmp/legacy/usr/share/tmac/mm mkdir -p /usr/obj/usr/src/tmp/lib mkdir -p /usr/obj/usr/src/tmp/usr/bin mkdir -p /usr/obj/usr/src/tmp/usr/include mkdir -p /usr/obj/usr/src/tmp/usr/lib/compat/aout mkdir -p /usr/obj/usr/src/tmp/usr/libdata/ldscripts mkdir -p /usr/obj/usr/src/tmp/usr/libexec mkdir -p /usr/obj/usr/src/tmp/usr/sbin mkdir -p /usr/obj/usr/src/tmp/usr/share/misc mkdir -p /usr/obj/usr/src/tmp/usr/share/snmp/defs mkdir -p /usr/obj/usr/src/tmp/usr/share/snmp/mibs mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/= usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/tmp -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp INSTALL=3D"sh /usr/sr= c/tools/install.sh" PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/u= sr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:= /usr/sbin:/usr/bin WORLDTMP=3D/usr/obj/usr/src/tmp MAKEFLAGS=3D"-m /usr/s= rc/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR=3D = BOOTSTRAPPING=3D700019 SSP_CFLAGS=3D -DWITHOUT_HTML -DWITHOUT_INFO -DNO_= LINT -DWITHOUT_MAN -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -= DNO_CPU_CFLAGS -DNO_WARNS legacy =3D=3D=3D> tools/build (obj,includes,depend,all,install) /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build cd /usr/src/tools/build; make buildincludes; make installincludes rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/t= ools/build/dummy.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/tools/= build/dummy.c building static egacy library ranlib libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/o= bj/usr/src/tmp/legacy/usr/lib -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp INSTALL=3D"sh /usr/sr= c/tools/install.sh" PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/u= sr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:= /usr/sbin:/usr/bin WORLDTMP=3D/usr/obj/usr/src/tmp MAKEFLAGS=3D"-m /usr/s= rc/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR=3D = BOOTSTRAPPING=3D700019 SSP_CFLAGS=3D -DWITHOUT_HTML -DWITHOUT_INFO -DNO_= LINT -DWITHOUT_MAN -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -= DNO_CPU_CFLAGS -DNO_WARNS bootstrap-tools =3D=3D=3D> games/fortune/strfile (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/games/fortune/strfile created for /usr/src/gam= es/fortune/strfile rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/g= ames/fortune/strfile/strfile.c echo strfile: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.= a >> .depend cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/games/= fortune/strfile/strfile.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/ob= j/usr/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/= usr/src/tmp/legacy/usr/games =3D=3D=3D> gnu/usr.bin/gperf (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/gperf created for /usr/src/gnu/usr= .bin/gperf =3D=3D=3D> gnu/usr.bin/gperf/doc (obj) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/gperf/doc created for /usr/src/gnu= /usr.bin/gperf/doc rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src= /gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf = /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc /usr/src/gnu/us= r.bin/gperf/../../../contrib/gperf/src/hash-table.cc /usr/src/gnu/usr.bin/g= perf/../../../contrib/gperf/src/iterator.cc /usr/src/gnu/usr.bin/gperf/../.= ./../contrib/gperf/src/key-list.cc /usr/src/gnu/usr.bin/gperf/../../../cont= rib/gperf/src/list-node.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gper= f/src/main.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc = /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /usr/src/g= nu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc /usr/src/gnu/usr.b= in/gperf/../../../contrib/gperf/src/trace.cc /usr/src/gnu/usr.bin/gperf/../= ../../contrib/gperf/src/vectors.cc /usr/src/gnu/usr.bin/gperf/../../../cont= rib/gperf/src/version.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/= lib/hash.cc=20=20=20 echo gperf: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a = >> .depend echo gperf: /usr/lib/libstdc++.a >> .depend =3D=3D=3D> gnu/usr.bin/gperf/doc (depend) c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/s= rc/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.= bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -static = -L/usr/obj/usr/src/tmp/legacy/usr/lib -o gperf bool-array.o gen-perf.o hash= -table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line= .o trace.o vectors.o version.o hash.o -legacy =3D=3D=3D> gnu/usr.bin/gperf/doc (all) sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 gperf /usr/obj/us= r/src/tmp/legacy/usr/bin =3D=3D=3D> gnu/usr.bin/gperf/doc (install) =3D=3D=3D> gnu/usr.bin/groff/tmac (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/tmac created for /usr/src/gn= u/usr.bin/groff/tmac sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/doc-com= mon > doc-common-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/doc-dit= roff > doc-ditroff-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/doc-nro= ff > doc-nroff-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/doc-sym= s > doc-syms-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/fr.ISO8859-1 > fr.ISO8859-1-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/ru.KOI8-R > ru.KOI8-R-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/e.tmac = > e.tmac-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/doc.tma= c > doc.tmac-s sed -f /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/strip= .sed /usr/src/gnu/usr.bin/groff/tmac/mdoc.local > mdoc.local-s sed -e "s;@TMAC_AN_PREFIX@;;g" -e "s;@TMAC_S_PREFIX@;;g" -e "s;@PNMTOPS_N= OSETPAGE@;pnmtops;g" /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/g= roff/tmac/an.tmac > an.tmac-s sed -e "s;@TMAC_AN_PREFIX@;;g" -e "s;@TMAC_S_PREFIX@;;g" -e "s;@PNMTOPS_N= OSETPAGE@;pnmtops;g" /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/g= roff/tmac/man.tmac > man.tmac-s sed -e "s;@TMAC_AN_PREFIX@;;g" -e "s;@TMAC_S_PREFIX@;;g" -e "s;@PNMTOPS_N= OSETPAGE@;pnmtops;g" /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/g= roff/tmac/s.tmac > s.tmac-s sed -e "s;@TMAC_AN_PREFIX@;;g" -e "s;@TMAC_S_PREFIX@;;g" -e "s;@PNMTOPS_N= OSETPAGE@;pnmtops;g" /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/g= roff/tmac/ms.tmac > ms.tmac-s sed -e "s;@TMAC_AN_PREFIX@;;g" -e "s;@TMAC_S_PREFIX@;;g" -e "s;@PNMTOPS_N= OSETPAGE@;pnmtops;g" /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/g= roff/tmac/www.tmac > www.tmac-s cd /usr/src/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac; sh /usr= /src/tools/install.sh -o root -g wheel -m 444 mandoc.tmac andoc.tmac an-ol= d.tmac me.tmac mdoc.tmac pic.tmac a4.tmac papersize.tmac ec.tmac saf= er.tmac trace.tmac ps.tmac psold.tmac pspic.tmac psatk.tmac dvi.tmac tt= y.tmac tty-char.tmac latin1.tmac latin2.tmac latin9.tmac cp1047.tmac unic= ode.tmac X.tmac Xps.tmac lj4.tmac lbp.tmac html.tmac html-end.tmac dev= tag.tmac europs.tmac composite.tmac eqnrc troffrc troffrc-end hyphen.u= s hyphenex.us /usr/obj/usr/src/tmp/legacy/usr/share/tmac cd /usr/src/gnu/usr.bin/groff/tmac; sh /usr/src/tools/install.sh -o root -= g wheel -m 444 koi8-r.tmac hyphen.ru /usr/obj/usr/src/tmp/legacy/usr/share= /tmac cd /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 e.tmac-s /usr/obj/usr= /src/tmp/legacy/usr/share/tmac/e.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 doc.tmac-s /usr/obj/u= sr/src/tmp/legacy/usr/share/tmac/doc.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 mdoc.local-s /usr/obj= /usr/src/tmp/legacy/usr/share/tmac/mdoc.local sh /usr/src/tools/install.sh -o root -g wheel -m 444 an.tmac-s /usr/obj/us= r/src/tmp/legacy/usr/share/tmac/an.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 man.tmac-s /usr/obj/u= sr/src/tmp/legacy/usr/share/tmac/man.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 s.tmac-s /usr/obj/usr= /src/tmp/legacy/usr/share/tmac/s.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 ms.tmac-s /usr/obj/us= r/src/tmp/legacy/usr/share/tmac/ms.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 www.tmac-s /usr/obj/u= sr/src/tmp/legacy/usr/share/tmac/www.tmac sh /usr/src/tools/install.sh -o root -g wheel -m 444 doc-common-s /usr/obj= /usr/src/tmp/legacy/usr/share/tmac/mdoc/doc-common sh /usr/src/tools/install.sh -o root -g wheel -m 444 doc-ditroff-s /usr/ob= j/usr/src/tmp/legacy/usr/share/tmac/mdoc/doc-ditroff sh /usr/src/tools/install.sh -o root -g wheel -m 444 doc-nroff-s /usr/obj/= usr/src/tmp/legacy/usr/share/tmac/mdoc/doc-nroff sh /usr/src/tools/install.sh -o root -g wheel -m 444 doc-syms-s /usr/obj/u= sr/src/tmp/legacy/usr/share/tmac/mdoc/doc-syms sh /usr/src/tools/install.sh -o root -g wheel -m 444 fr.ISO8859-1-s /usr/o= bj/usr/src/tmp/legacy/usr/share/tmac/mdoc/fr.ISO8859-1 sh /usr/src/tools/install.sh -o root -g wheel -m 444 ru.KOI8-R-s /usr/obj/= usr/src/tmp/legacy/usr/share/tmac/mdoc/ru.KOI8-R sh /usr/src/tools/install.sh -o root -g wheel -m 444 /usr/src/gnu/usr.bin/= groff/tmac/../../../../contrib/groff/tmac/man.local /usr/obj/usr/src/tmp/le= gacy/usr/share/tmac =3D=3D=3D> usr.bin/lorder (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/lorder created for /usr/src/usr.bin/lo= rder sh /usr/src/tools/install.sh -o root -g wheel -m 555 /usr/src/usr.bin/lor= der/lorder.sh /usr/obj/usr/src/tmp/legacy/usr/bin/lorder =3D=3D=3D> usr.bin/makewhatis (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/makewhatis created for /usr/src/usr.bi= n/makewhatis rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/u= sr.bin/makewhatis/makewhatis.c echo makewhatis: /usr/lib/libc.a /usr/lib/libz.a /usr/obj/usr/src/tmp/legac= y/usr/lib/libegacy.a >> .depend cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/makewhatis/makewhatis.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/ob= j/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 makewhatis /usr/o= bj/usr/src/tmp/legacy/usr/bin sh /usr/src/tools/install.sh -o root -g wheel -m 555 /usr/src/usr.bin/mak= ewhatis/makewhatis.local.sh /usr/obj/usr/src/tmp/legacy/usr/libexec/makewh= atis.local /usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local -> /usr/obj/usr/src/tm= p/legacy/usr/libexec/makewhatis.local =3D=3D=3D> usr.bin/rpcgen (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/rpcgen created for /usr/src/usr.bin/rp= cgen rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/u= sr.bin/rpcgen/rpc_main.c /usr/src/usr.bin/rpcgen/rpc_clntout.c /usr/src/usr= .bin/rpcgen/rpc_cout.c /usr/src/usr.bin/rpcgen/rpc_hout.c /usr/src/usr.bin/= rpcgen/rpc_parse.c /usr/src/usr.bin/rpcgen/rpc_sample.c /usr/src/usr.bin/rp= cgen/rpc_scan.c /usr/src/usr.bin/rpcgen/rpc_svcout.c /usr/src/usr.bin/rpcge= n/rpc_tblout.c /usr/src/usr.bin/rpcgen/rpc_util.c echo rpcgen: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a= >> .depend cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_main.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_clntout.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_cout.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_hout.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_parse.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_sample.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_scan.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_svcout.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_tblout.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/rpcgen/rpc_util.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/ob= j/usr/src/tmp/legacy/usr/lib -o rpcgen rpc_main.o rpc_clntout.o rpc_cout.o = rpc_hout.o rpc_parse.o rpc_sample.o rpc_scan.o rpc_svcout.o rpc_tblout.o rp= c_util.o -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 rpcgen /usr/obj/u= sr/src/tmp/legacy/usr/bin =3D=3D=3D> usr.bin/xinstall (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall created for /usr/src/usr.bin/= xinstall rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/u= sr.bin/xinstall/xinstall.c echo xinstall: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy= .a >> .depend cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bi= n/xinstall/xinstall.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/ob= j/usr/src/tmp/legacy/usr/lib -o xinstall xinstall.o -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 xinstall /usr/obj= /usr/src/tmp/legacy/usr/bin/install =3D=3D=3D> usr.sbin/config (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.sbin/config created for /usr/src/usr.sbin/= config yacc -d /usr/src/usr.sbin/config/config.y cp y.tab.c config.c lex -t /usr/src/usr.sbin/config/lang.l > lang.c rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include config.c /= usr/src/usr.sbin/config/main.c lang.c /usr/src/usr.sbin/config/mkmakefile.c= /usr/src/usr.sbin/config/mkheaders.c /usr/src/usr.sbin/config/mkoptions.c /usr/src/usr.sbin/config/config.y:78:20: config.h: No such file or directory /usr/src/usr.sbin/config/main.c:55:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/lang.l:38:20: config.h: No such file or directory /usr/src/usr.sbin/config/mkmakefile.c:49:19: y.tab.h: No such file or direc= tory /usr/src/usr.sbin/config/mkheaders.c:48:19: y.tab.h: No such file or direct= ory /usr/src/usr.sbin/config/mkoptions.c:49:19: y.tab.h: No such file or direct= ory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.sbin/config. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --=-=-= My src.conf just says: CFLAGS=-O2 -pipe CPUTYPE?=pentium-m WITH_SSP=yes WITHOUT_LPR=yes Any help is appreciated. Regards, -- Julian Stecklina C has all the expressive power of two dixie cups and a string. (Jamie Zawinski) --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 18:02: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 AD8AB16A4DE for ; Mon, 31 Jul 2006 18:02:01 +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 B553B43D5A for ; Mon, 31 Jul 2006 18:01:55 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6VI1o3L072680; Mon, 31 Jul 2006 14:01:50 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 31 Jul 2006 13:05:37 -0400 User-Agent: KMail/1.9.1 References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <20060729230214.GI12597@groat.ugcs.caltech.edu> <1154216319.23616.23.camel@genius.i.cz> In-Reply-To: <1154216319.23616.23.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607311305.38398.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 31 Jul 2006 14:01:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 19:34:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 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: Paul Allen , Michal Mertl , Brian Candler , Peter Jeremy Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 18:02:01 -0000 On Saturday 29 July 2006 19:38, Michal Mertl wrote: > Paul Allen wrote: > > Surely all you need to do is a cheap crit_enter,crit_exit > > while updating the 64-bit per cpu counters. and on > > a 64-bit arch you skip the crit_enter,crit_exit. > > Critical_enter/exit seem to be quite lightweight (single > read/modify/write of a variable). > > > Seriously this is a bike shed. We can summarize it thus: > > statistics should be maintained in 64-bit counters, these > > counters should be per-cpu and consistent in that context, > > nothing else should appear on the critical path. > > Why do you call it a bikesched? I think that your proposal could work > but as nobody proposed doing the stuff with critical_* before, the > thread may be fruitful. > > Is critical_* good enough protection though? What if two threads were > updating the same per-CPU counter on the same CPU at the same time? With > 64bits counter on a 32bit architecture? I expect the cache coherency > issues are completely eliminated with per-CPU data, aren't they? critical_* would prevent an interrupt from preempting the thread, so you wouldn't have this case. That said, I think just using a simple algo (like inc; jnc 1b; inc; 1:) would be fine. With the counter being per-cpu you don't even need the 'lock' prefix for i386. You would have to find similar solutions for other 32-bit archs (arm, ppc, mips). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 18:57: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 3704316A4DA for ; Mon, 31 Jul 2006 18:57:16 +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 7953543D45 for ; Mon, 31 Jul 2006 18:57:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6VIvEII073012; Mon, 31 Jul 2006 14:57:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Peter Jeremy Date: Mon, 31 Jul 2006 14:37:56 -0400 User-Agent: KMail/1.9.1 References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> In-Reply-To: <20060728210154.GC748@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607311437.57273.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 31 Jul 2006 14:57:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 19:34:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 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, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 18:57:16 -0000 On Friday 28 July 2006 17:01, Peter Jeremy wrote: > On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote: > >On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: > >> lock incl counter > >> jnc 1f > >> lock incl counter+4 > >> 1: > > This approach still requires the reader to loop with something like > do { > a.lo = counter.lo; > a.hi = counter.hi; > b.lo = counter.lo; > b.hi = counter.hi; > } while (a.hi != b.hi || a.lo > b.lo); > to ensure that the reader doesn't read the middle of an update. Yes, but the idea here is that these stats are written to far more often than read, so it's ok to pessimize the read case. > lock prefixes are always going to be extremely expensive on a MP > system because they require physical bus cycles. RISC architectures > usually only have TAS lock primitives (because "inc mem" doesn't > exist) and so require a spinlock to perform an atomic update. Nah, you can do it directly using different primitives w/o a full spin lock. If you had a 32-bit RISC arch that supported linked-load conditional-store like Alpha/MIPS you could do something like: 1: ldl_l t0, (a0) addi t0, 1 mov t2, t0 # or add t2, t0, zero stl_c t0, (a0) beq t0, 1b bne t2, 2f # skip next if we didn't wrap 2: ldl_l t0, 4(a0) addi t0, 1 stl_c t0, (a0) beq t0, 2b That doesn't require a full-blow spinlock which disables interrupts, etc. > In a MP configuration where it doesn't particularly matter if a > particular update gets counted this time or next time, I think the > cheapest option is to have per-CPU 32-bit counters (so no locks are > needed to update the counters) with a polling function to accumulate > all the individual counters into a 64-bit total. This pushes the cost > from the update (very frequent) into the read (which is relatively > infrequent), for a lower overall cost. > > This turns the update into something like: > PCPU_SET(counter, PCPU_GET(counter)+1); > or > incl %fs:counter > (no locks or atomic operations) Note that if you go with per-cpu counters then you don't need 'lock' prefixes for the 'inc; jnc 1f; inc; 1:' case either. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 19:12: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 B755016A4E1; Mon, 31 Jul 2006 19:12:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5DF643D6D; Mon, 31 Jul 2006 19:12:09 +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 mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6VJC7Jw016454 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 05:12:08 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6VJC67e005190; Tue, 1 Aug 2006 05:12:06 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6VJC6KG005189; Tue, 1 Aug 2006 05:12:06 +1000 (EST) (envelope-from peter) Date: Tue, 1 Aug 2006 05:12:06 +1000 From: Peter Jeremy To: John Baldwin Message-ID: <20060731191206.GE749@turion.vk2pj.dyndns.org> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <200607311437.57273.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline In-Reply-To: <200607311437.57273.jhb@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 19:12:11 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2006-Jul-31 14:37:56 -0400, John Baldwin wrote: >On Friday 28 July 2006 17:01, Peter Jeremy wrote: >> This approach still requires the reader to loop with something like >> do { >> a.lo =3D counter.lo; >> a.hi =3D counter.hi; >> b.lo =3D counter.lo; >> b.hi =3D counter.hi; >> } while (a.hi !=3D b.hi || a.lo > b.lo); >> to ensure that the reader doesn't read the middle of an update. > >Yes, but the idea here is that these stats are written to far more often t= han=20 >read, so it's ok to pessimize the read case. We are in violent agreement here. My point was that the reader has to be aware of this requirement. --=20 Peter Jeremy --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEzlYG/opHv/APuIcRAs3zAJwIm4E1vcj9KcBtgMswGbZvi9XzEwCgpWWH NU5HOWWSUlt4vAnSSLKS4lY= =CJyo -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 19:12: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 E198C16A4E2; Mon, 31 Jul 2006 19:12:59 +0000 (UTC) (envelope-from prvs=julian=360b2d18d@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02FB443D83; Mon, 31 Jul 2006 19:12:52 +0000 (GMT) (envelope-from prvs=julian=360b2d18d@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 31 Jul 2006 12:12:52 -0700 Message-ID: <44CE5634.9080205@elischer.org> Date: Mon, 31 Jul 2006 12:12:52 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <200607311437.57273.jhb@freebsd.org> In-Reply-To: <200607311437.57273.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 19:13:00 -0000 John Baldwin wrote: >On Friday 28 July 2006 17:01, Peter Jeremy wrote: > > >>On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote: >> >> >>>On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote: >>> >>> >>>> lock incl counter >>>> jnc 1f >>>> lock incl counter+4 >>>>1: >>>> >>>> >>This approach still requires the reader to loop with something like >> do { >> a.lo = counter.lo; >> a.hi = counter.hi; >> b.lo = counter.lo; >> b.hi = counter.hi; >> } while (a.hi != b.hi || a.lo > b.lo); >>to ensure that the reader doesn't read the middle of an update. >> >> > >Yes, but the idea here is that these stats are written to far more often than >read, so it's ok to pessimize the read case. > > > >>lock prefixes are always going to be extremely expensive on a MP >>system because they require physical bus cycles. RISC architectures >>usually only have TAS lock primitives (because "inc mem" doesn't >>exist) and so require a spinlock to perform an atomic update. >> >> > >Nah, you can do it directly using different primitives w/o a full spin lock. >If you had a 32-bit RISC arch that supported linked-load conditional-store >like Alpha/MIPS you could do something like: > >1: > ldl_l t0, (a0) > addi t0, 1 > mov t2, t0 # or add t2, t0, zero > stl_c t0, (a0) > beq t0, 1b > bne t2, 2f # skip next if we didn't wrap >2: > ldl_l t0, 4(a0) > addi t0, 1 > stl_c t0, (a0) > beq t0, 2b > >That doesn't require a full-blow spinlock which disables interrupts, etc. > > > >>In a MP configuration where it doesn't particularly matter if a >>particular update gets counted this time or next time, I think the >>cheapest option is to have per-CPU 32-bit counters (so no locks are >>needed to update the counters) with a polling function to accumulate >>all the individual counters into a 64-bit total. This pushes the cost >>from the update (very frequent) into the read (which is relatively >>infrequent), for a lower overall cost. >> >>This turns the update into something like: >> PCPU_SET(counter, PCPU_GET(counter)+1); >>or >> incl %fs:counter >>(no locks or atomic operations) >> >> > >Note that if you go with per-cpu counters then you don't need 'lock' prefixes >for the 'inc; jnc 1f; inc; 1:' case either. > > but you do want to disable interrupts so that you don't get switched to another cpu in the middle of it. That would result in the possibility of 2 threads writing to the same stats at the same time. From owner-freebsd-current@FreeBSD.ORG Mon Jul 31 20:46: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 A92B716A4DA for ; Mon, 31 Jul 2006 20:46:03 +0000 (UTC) (envelope-from csjp@FreeBSD.org) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.FreeBSD.org (Postfix) with SMTP id EED5C43D4C for ; Mon, 31 Jul 2006 20:46:02 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: (qmail 67809 invoked by uid 86); 31 Jul 2006 21:00:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (204.112.0.40) by ems01.seccuris.com with SMTP; 31 Jul 2006 21:00:21 -0000 Message-ID: <44CE6C0A.50009@FreeBSD.org> Date: Mon, 31 Jul 2006 15:46:02 -0500 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Robert Huff References: <20060726063636.GA58151@freefall.freebsd.org> <17610.836.663396.331448@jerusalem.litteratus.org> In-Reply-To: <17610.836.663396.331448@jerusalem.litteratus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jul 2006 20:46:03 -0000 Robert Huff wrote: > Yar Tikhiy writes: > > >> FWIW, the LOR still is there. I was seeing it yesterday while >> fiddling with the ipfw and natd rc.d scripts. >> >> lock order reversal: >> 1st 0xc1a36090 inp (divinp) @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350 >> 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 >> > > For the record, I'm (still) getting this also. > > > Robert Huff > _______________________________________________ > 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" > > > This appears to be similar to the LOR associated with IPFW and ucred based rules, I think. Although this is a lock order reversal and it probably isn't a false positive, it should be reasonably harmless, because the pfil hook lock is a reader lock, thus different threads can acquire it (at this point) con-currently, presumably preventing a dead lock from actually occurring here. iirc witness it not aware of the reader/writer semantics, so it makes sense that it will be dropping a warning here. But I can look at this in further detail when I get a bit of time. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 00:09:25 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 0FB3216A4DD; Tue, 1 Aug 2006 00:09:25 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from mark.ugcs.caltech.edu (mark.ugcs.caltech.edu [131.215.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1494943D45; Tue, 1 Aug 2006 00:09:24 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by mark.ugcs.caltech.edu (Postfix, from userid 3640) id 2C6D83F050; Mon, 31 Jul 2006 17:09:23 -0700 (PDT) Date: Mon, 31 Jul 2006 17:09:23 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20060801000923.GA308@mark.ugcs.caltech.edu> References: <200607251254.k6PCsBef092737@lurza.secnetix.de> <20060728134701.GA45273@uk.tiscali.com> <20060728210154.GC748@turion.vk2pj.dyndns.org> <200607311437.57273.jhb@freebsd.org> <44CE5634.9080205@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CE5634.9080205@elischer.org> Sender: jd@ugcs.caltech.edu Cc: Peter Jeremy , freebsd-current@freebsd.org, Brian Candler Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 00:09:25 -0000 >From Julian Elischer , Mon, Jul 31, 2006 at 12:12:52PM -0700: > but you do want to disable interrupts so that you don't get switched to > another cpu in the middle of it. > That would result in the possibility of 2 threads writing to the same > stats at the same time. Or just setup the sched to pin the kernel thread to the CPU and then use N_CPU threads for your packet processing + a load balancing algorithm to allocate flows between threads. I'm not saying this always the best solution, but certainly it is worth consideration--especially in cases where the word 'flow' can be omitted from my earlier statement without making anyone quesy. (Parallelism versus pipelining: the difference between Time-Division-Multiplexing each step in a packet's lifetime and Spacial-Division Multiplexing the flows versus Time-Division-Multiplexing the flows and Spacial-Division Multiplexing the packet's lifetime. From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 00:18: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 9383E16A4E0 for ; Tue, 1 Aug 2006 00:18:18 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id D461E43D46 for ; Tue, 1 Aug 2006 00:18:17 +0000 (GMT) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 31 Jul 2006 20:18:21 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LYY17804; Mon, 31 Jul 2006 20:18:06 -0400 (EDT) Received: from 65-78-24-149.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.24.149]) by smtp01.lnh.mail.rcn.net with ESMTP; 31 Jul 2006 20:18:01 -0400 X-IronPort-AV: i="4.07,199,1151899200"; d="scan'208"; a="247204692:sNHT27340020" From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.40142.109365.481255@jerusalem.litteratus.org> Date: Mon, 31 Jul 2006 20:14:06 -0400 To: freebsd-current@FreeBSD.org In-Reply-To: <44CE6C0A.50009@FreeBSD.org> References: <20060726063636.GA58151@freefall.freebsd.org> <17610.836.663396.331448@jerusalem.litteratus.org> <44CE6C0A.50009@FreeBSD.org> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.44CE9D66.0007,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Cc: Subject: Re: LOR when booting 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, 01 Aug 2006 00:18:18 -0000 Christian S.J. Peron writes: > > For the record, I'm (still) getting this also. > > This appears to be similar to the LOR associated with IPFW and ucred > based rules, I think. Although this is a lock order reversal and it > probably isn't a false positive, it should be reasonably harmless, > because the pfil hook lock is a reader lock, thus different threads can > acquire it (at this point) con-currently, presumably preventing a dead > lock from actually occurring here. To my knowledge, not so: please see kern/86427. This puppy will choke my -CURRENT system in around ten days under a light network load. Under substantial traffic, less than three. I had hoped the network stack changes Robert Watson committed a while back would fix this, but apparently not. This is a _major_ pain in the ass, and I look forward to the day when someone drives a backtrace through its pulsing green heart. Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 01:04: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 D7EBF16A4DA for ; Tue, 1 Aug 2006 01:04:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B67743D46 for ; Tue, 1 Aug 2006 01:04:41 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by ug-out-1314.google.com with SMTP id k40so1269702ugc for ; Mon, 31 Jul 2006 18:04:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=YQpFkIw4wxHsWF0wFhv+1xf+mCYbL6JETw+nMnrY0oEren3nLKgsGWfQYGK1rvFLuOqp6HnP8WIvr3bz5mVPIEB0WBK8brKZzh9Uh1G+VoZtlKW/Lr+/DxJEx/lZert4FWEwi0eECcCT01J+I68gd40suonR74BRZVE9Qn/6Kj4= Received: by 10.65.160.7 with SMTP id m7mr30538qbo; Mon, 31 Jul 2006 18:04:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm10099616nzn.2006.07.31.18.04.38; Mon, 31 Jul 2006 18:04:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7115Mmr040042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Aug 2006 10:05:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7115Ku0040041; Tue, 1 Aug 2006 10:05:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 1 Aug 2006 10:05:20 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20060801010520.GD39581@cdnetworks.co.kr> References: <20060731054421.GB35573@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: em promiscuous mode bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 01:04:42 -0000 On Mon, Jul 31, 2006 at 01:25:59PM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Mon, Jul 31, 2006 at 07:16:03AM +0200, Ian FREISLICH wrote: > > > Pyun YongHyeon wrote: > > > > Hardware VLAN tagging was disabled in em(4) when it operates > > > > in promiscuous mode and em(4) will insert a VLAN tag in the > > > > driver. > > > > > > Um, no. When an em interface with hardware VLAN tagging enabled > > > is placed in promiscuous mode, it just _stops_ tagging. Entirely. > > > The 802.1Q vlan just breaks. > > > > > > > Would you try latest em(4) in CURRENT?(if_em.c, rev. 1.122) > > No change with r1.122 (used to be r1.116). Note that with > VLAN_HWTAGGING enabled, both hosts bring up their carp interface > as master. This is because none of the frames are tagged when the > carp driver puts the vlan interface which in turn puts the em > interface into promiscuous mode. > Then I have no clue. I'm not familiar with carp(4) but I guess carp(4) has nothing to do with em(4). > You stated that in an earlier email that VLAN_HWTAGGING is disabled > when the interface is placed in promiscuous mode. Is there any See cvs logs if_em.c, rev 1.58. > reason for this appart from not being to view the VLAN header with > tcpdump? My site runs a lot of VLANS (500+) and it would be nice > to offload this work to the card. > Normally you can't see VLAN information with tcpdump if your NIC supports VLAN_HWTAGGING. On Tx side the VLAN information is carried with a mbuf tag and the hardware is programmed to send the VLAN id from the mbuf tag. On Rx side the hardware performs VLAN tag stripping before tcpdump see the received packet. You have to disable VLAN_HWTAGGING to see VLAN header with tcpdump. If you need real hardware VLAN tag stripping/insertion in promiscuous mode switch your NIC with other cards such as bge(4)/bce(4). -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 08:42: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 21F1516A4DE; Tue, 1 Aug 2006 08:42:02 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901AF43D46; Tue, 1 Aug 2006 08:42:01 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id ACBF65C1B; Tue, 1 Aug 2006 09:42:00 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 779064073; Tue, 1 Aug 2006 09:41:56 +0100 (BST) Date: Tue, 1 Aug 2006 09:41:56 +0100 From: Josef Karthauser To: Chris Message-ID: <20060801084156.GD3440@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Chris , Phil Regnauld , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RhUH2Ysw6aD5utA4" Content-Disposition: inline In-Reply-To: <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: Phil Regnauld , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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, 01 Aug 2006 08:42:02 -0000 --RhUH2Ysw6aD5utA4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear current folk, I'm forwarding this thread from the -net list where I asked the question, is it possible to have more than one IP address in a jail? The answer is yes, with Pawel's patch. The question here is can I pursuade anyone to commit this to head and MFC it please? The motivation is simple. I need to run a second SSL web server inside of a jail, however that needs another IP address because SSL is incompatible with HTTP/1.1. Thanks :). Joe On Thu, Jun 29, 2006 at 03:40:33AM +0100, Chris wrote: > On 28/06/06, Phil Regnauld wrote: > >Josef Karthauser (joe) writes: > >> Hi, > >> > >> I've got a jail on a machine running some web stuff and I need to add a > >> second SSL web site to it. This would mean binding another IP address > >> to the jail. Has anyone got a work around for this? > > > > Yes, use Pawel's patches: > > > > http://people.freebsd.org/~pjd/patches/jail_2006012001.patch > > > > Older readme here: > > > > http://garage.freebsd.pl/mijail5.README > > > > >=20 > these patches have been around a while, any reason why its not been > ported to the base code? seems a trivial function to have, single ip > jail is very limiting. >=20 > thanks >=20 > Chris >=20 >=20 --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --RhUH2Ysw6aD5utA4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkTPE9MACgkQXVIcjOaxUBY+rQCfQSRHymCK7prdcyGdARiodY7V MYoAoNMMIn6U/unXN2G5Sv4QTZa70Dsj =l03C -----END PGP SIGNATURE----- --RhUH2Ysw6aD5utA4-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 08:45: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 0ED9316A4DF; Tue, 1 Aug 2006 08:45:26 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8553B43D46; Tue, 1 Aug 2006 08:45:25 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id AC8216343B7; Tue, 1 Aug 2006 10:45:23 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 19674-08; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id B922163439E; Tue, 1 Aug 2006 10:45:22 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 768F378C31; Tue, 1 Aug 2006 10:40:53 +0200 (CEST) Date: Tue, 1 Aug 2006 10:40:53 +0200 From: Phil Regnauld To: Josef Karthauser , Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20060801084053.GE22731@catpipe.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801084156.GD3440@genius.tao.org.uk> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net X-Mailman-Approved-At: Tue, 01 Aug 2006 11:37:29 +0000 Cc: Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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, 01 Aug 2006 08:45:26 -0000 Josef Karthauser (joe) writes: > Dear current folk, I'm forwarding this thread from the -net list where I > asked the question, is it possible to have more than one IP address in a > jail? The answer is yes, with Pawel's patch. The question here is can > I pursuade anyone to commit this to head and MFC it please? The > motivation is simple. I need to run a second SSL web server inside of a > jail, however that needs another IP address because SSL is incompatible > with HTTP/1.1. We have been using these patches all the way back since 5-CURRENT and they work very stable for us. I seem to remember that there were some reservations about the way it was being done, but for that matter it wouldn't be the first hack in jail (like u_int32_t for the ip_number in struct jail :) From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 09: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 CACA816A4DD for ; Tue, 1 Aug 2006 09:57:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03EFD43D45 for ; Tue, 1 Aug 2006 09:57:44 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (xydilc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k719vbTd036396 for ; Tue, 1 Aug 2006 11:57:43 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k719vb9X036395; Tue, 1 Aug 2006 11:57:37 +0200 (CEST) (envelope-from olli) Date: Tue, 1 Aug 2006 11:57:37 +0200 (CEST) Message-Id: <200608010957.k719vb9X036395@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <20060801084156.GD3440@genius.tao.org.uk> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 01 Aug 2006 11:57:43 +0200 (CEST) X-Mailman-Approved-At: Tue, 01 Aug 2006 11:37:39 +0000 Cc: Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP ?addresses in a jail.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 09:57:45 -0000 Josef Karthauser wrote: > Dear current folk, I'm forwarding this thread from the -net list where I > asked the question, is it possible to have more than one IP address in a > jail? The answer is yes, with Pawel's patch. The question here is can > I pursuade anyone to commit this to head and MFC it please? The > motivation is simple. I need to run a second SSL web server inside of a > jail, however that needs another IP address because SSL is incompatible > with HTTP/1.1. There are several solutions to that problem, even with a single IP address within the jail. The simplest solution is probably to give the jail an internal IP address (such as 10.0.0.1, or even a localhost address such as 127.0.0.2), put the SSL servers on multiple different port addresses, and use IPFW FWD rules to forward packets to the appropriate ports within the jail (you'll also need a NAT rule to fix the source in outgoing packets). I think PF provides similar functionality if you don't want to use IPFW. For example (FWD rules): 40.30.20.10:443 --> 127.0.0.2:10443 40.30.20.11:443 --> 127.0.0.2:11443 40.30.20.12:443 --> 127.0.0.2:12443 In that example, 40.30.20.* are the official IP addresses, and 127.0.0.2 is the jail's address. Such a solution has several advantages: - The jail doesn't have an official, routable IP at all (security!). - There's no limit on the number of SSL servers per jail (despite the jail having only one IP address). - The SSL servers can be bound to ports > 1024, so they can be run as non-privileged user right from the start. - Works on standard FreeBSD 4.x, 5.x, 6.x. However, there are certainly other situations where it would be useful to be able to have multiple IP addresses per jail, or even a completely virtualized IP stack and routing table per jail. Therefore I wouldn't mind if such a patch gets commited. :-) Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 10:11: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 6068B16A4DE for ; Tue, 1 Aug 2006 10:11:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76FD243D45 for ; Tue, 1 Aug 2006 10:11:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mlifor@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k71ABAaO036858 for ; Tue, 1 Aug 2006 12:11:16 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k71ABA6n036857; Tue, 1 Aug 2006 12:11:10 +0200 (CEST) (envelope-from olli) Date: Tue, 1 Aug 2006 12:11:10 +0200 (CEST) Message-Id: <200608011011.k71ABA6n036857@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <20060731191206.GE749@turion.vk2pj.dyndns.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 01 Aug 2006 12:11:16 +0200 (CEST) X-Mailman-Approved-At: Tue, 01 Aug 2006 11:37:50 +0000 Cc: Subject: Re: vmstat's entries type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 10:11:18 -0000 Peter Jeremy wrote: > John Baldwin wrote: > > Peter Jeremy wrote: > > > This approach still requires the reader to loop with something like > > > do { > > > a.lo = counter.lo; > > > a.hi = counter.hi; > > > b.lo = counter.lo; > > > b.hi = counter.hi; > > > } while (a.hi != b.hi || a.lo > b.lo); > > > to ensure that the reader doesn't read the middle of an update. > > > > Yes, but the idea here is that these stats are written to far more often than > > read, so it's ok to pessimize the read case. > > We are in violent agreement here. My point was that the reader has > to be aware of this requirement. I assume that there is only _one_ reader, e.g. a single function which performs the operations necessary to read the value. Everything else must use that function and need not care about the internals. So there is only one piece of code that has to be aware of the requirement. Regarding the argument "cheap vs. accurate": For simple statistics counters it is certainly acceptable if a single update is lost once in a while (i.e. if one out of 2^32 updates is lost). However, if an update to the overflow (upper 32 bits) is lost or erroneously doubled, it would mean a huge error of 2^32 at once. That's not acceptable, in my opinion. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 14:34: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 952C116A4DA for ; Tue, 1 Aug 2006 14:34:42 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD69643D49 for ; Tue, 1 Aug 2006 14:34:36 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 7AB177A22E; Tue, 1 Aug 2006 16:34:35 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id DA9869C22D; Tue, 1 Aug 2006 14:35:08 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id BCB5E405B; Tue, 1 Aug 2006 16:35:08 +0200 (CEST) Date: Tue, 1 Aug 2006 16:35:08 +0200 From: Jeremie Le Hen To: Julian Stecklina Message-ID: <20060801143508.GO1458@obiwan.tataz.chchile.org> References: <86mzap4qzx.fsf@dellbeast.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mzap4qzx.fsf@dellbeast.localnet> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: [fbsd] SSP/ProPolice build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 14:34:42 -0000 Hi Julian, On Mon, Jul 31, 2006 at 07:35:14PM +0200, Julian Stecklina wrote: > Hello, > > I just tried to build a SSP-enabled world (with patches from > http://tataz.chchile.org/~tataz/FreeBSD/SSP/) and ended up with: > > mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include config.c /usr/src/usr.sbin/config/main.c lang.c /usr/src/usr.sbin/config/mkmakefile.c /usr/src/usr.sbin/config/mkheaders.c /usr/src/usr.sbin/config/mkoptions.c > /usr/src/usr.sbin/config/config.y:78:20: config.h: No such file or directory > /usr/src/usr.sbin/config/main.c:55:19: y.tab.h: No such file or directory > /usr/src/usr.sbin/config/lang.l:38:20: config.h: No such file or directory > /usr/src/usr.sbin/config/mkmakefile.c:49:19: y.tab.h: No such file or directory > /usr/src/usr.sbin/config/mkheaders.c:48:19: y.tab.h: No such file or directory > /usr/src/usr.sbin/config/mkoptions.c:49:19: y.tab.h: No such file or directory > > (full log as attachment) I think this has nothing to do with the ProPolice patch. Try fetching your sources again, there may be a temporary breakage in the CVS sources. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 15:45: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 0B52416A4E0; Tue, 1 Aug 2006 15:45:44 +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 B3E8C43D6E; Tue, 1 Aug 2006 15:45:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k71FjeFM080313; Tue, 1 Aug 2006 11:45:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 1 Aug 2006 11:22:17 -0400 User-Agent: KMail/1.9.1 References: <20060726063636.GA58151@freefall.freebsd.org> <17610.836.663396.331448@jerusalem.litteratus.org> <44CE6C0A.50009@FreeBSD.org> In-Reply-To: <44CE6C0A.50009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608011122.18189.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 01 Aug 2006 11:45:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1629/Tue Aug 1 07:19:34 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJECT_EXCESS_QP autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Robert Huff , "Christian S.J. Peron" Subject: Re: LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 15:45:44 -0000 On Monday 31 July 2006 16:46, Christian S.J. Peron wrote: > Robert Huff wrote: > > Yar Tikhiy writes: > > > > > >> FWIW, the LOR still is there. I was seeing it yesterday while > >> fiddling with the ipfw and natd rc.d scripts. > >> > >> lock order reversal: > >> 1st 0xc1a36090 inp (divinp) @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350 > >> 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 > >> > > > > For the record, I'm (still) getting this also. > > > > > > Robert Huff > > _______________________________________________ > > 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" > > > > > > > > This appears to be similar to the LOR associated with IPFW and ucred > based rules, I think. Although this is a lock order reversal and it > probably isn't a false positive, it should be reasonably harmless, > because the pfil hook lock is a reader lock, thus different threads can > acquire it (at this point) con-currently, presumably preventing a dead > lock from actually occurring here. > > iirc witness it not aware of the reader/writer semantics, so it makes > sense that it will be dropping a warning here. But I can look at this in > further detail when I get a bit of time. No, a LOR is a LOR. Readers vs writers don't matter for ordering reasons. Talk yourself through it and you'll see. The reason is that a writer can always block on a reader, and a reader will block if there's a writer already holding the lock. While you can end up in some situations where a LOR might not deadlock at the time if both threads involved are getting read locks, at some point a thread will need to get a write lock (otherwise you wouldn't need a lock!) and then you can get a deadlock between the thread with the write lock and a thread acquiring the locks in reverse order even if that second thread is only getting a read lock. Specifically, given mtx A, and rwlock B, while it may be safe for a thread to rlock B and lock A while another thread does lock A and rlock B w/o triggering deadlock, if a thread does lock A and then wlock B, then when another tried tries to rlock B and then lock A you will get deadlock. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 16:14: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 2DA0616A4FA for ; Tue, 1 Aug 2006 16:14:29 +0000 (UTC) (envelope-from csjp@FreeBSD.org) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 8288B43D6E for ; Tue, 1 Aug 2006 16:14:28 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: (qmail 44399 invoked by uid 86); 1 Aug 2006 16:29:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (204.112.0.40) by ems01.seccuris.com with SMTP; 1 Aug 2006 16:29:08 -0000 Message-ID: <44CF7DE4.1090302@FreeBSD.org> Date: Tue, 01 Aug 2006 11:14:28 -0500 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: John Baldwin References: <20060726063636.GA58151@freefall.freebsd.org> <17610.836.663396.331448@jerusalem.litteratus.org> <44CE6C0A.50009@FreeBSD.org> <200608011122.18189.jhb@freebsd.org> In-Reply-To: <200608011122.18189.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Huff Subject: Re: LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 16:14:29 -0000 John Baldwin wrote: > On Monday 31 July 2006 16:46, Christian S.J. Peron wrote: > >> Robert Huff wrote: >> >>> Yar Tikhiy writes: >>> >>> >>> >>>> FWIW, the LOR still is there. I was seeing it yesterday while >>>> fiddling with the ipfw and natd rc.d scripts. >>>> >>>> lock order reversal: >>>> 1st 0xc1a36090 inp (divinp) >>>> > @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350 > >>>> 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) >>>> > @ /usr/src/sys/net/pfil.c:73 > >>>> >>>> >>> For the record, I'm (still) getting this also. >>> >>> >>> Robert Huff >>> _______________________________________________ >>> 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" >>> >>> >>> >>> >> This appears to be similar to the LOR associated with IPFW and ucred >> based rules, I think. Although this is a lock order reversal and it >> probably isn't a false positive, it should be reasonably harmless, >> because the pfil hook lock is a reader lock, thus different threads can >> acquire it (at this point) con-currently, presumably preventing a dead >> lock from actually occurring here. >> >> iirc witness it not aware of the reader/writer semantics, so it makes >> sense that it will be dropping a warning here. But I can look at this in >> further detail when I get a bit of time. >> > > No, a LOR is a LOR. Readers vs writers don't matter for ordering reasons. > Talk yourself through it and you'll see. The reason is that a writer can > always block on a reader, and a reader will block if there's a writer already > holding the lock. > > While you can end up in some situations where a LOR might not deadlock at the > time if both threads involved are getting read locks, at some point a thread > will need to get a write lock (otherwise you wouldn't need a lock!) and then > you can get a deadlock between the thread with the write lock and a thread > acquiring the locks in reverse order even if that second thread is only > getting a read lock. Specifically, given mtx A, and rwlock B, while it may > be safe for a thread to rlock B and lock A while another thread does lock A > and rlock B w/o triggering deadlock, if a thread does lock A and then wlock > B, then when another tried tries to rlock B and then lock A you will get > deadlock. > > This is true. However, I am not disputing the validity of witness here, don't get me wrong. I think in this case, the LOR between pfil and INP should be harmless, because I can not think of any place in our code where we will pickup the pfil write lock then an INP lock (or vice versa) since the the only place we are picking up write locks for pfil is when we load or unload hooks. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 20:45: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 AC14C16A4F3 for ; Tue, 1 Aug 2006 20:45:03 +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 6FE4743D58 for ; Tue, 1 Aug 2006 20:45:02 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k71Kj1aH019738 for ; Tue, 1 Aug 2006 13:45:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k71Kj1KJ019737 for freebsd-current@freebsd.org; Tue, 1 Aug 2006 13:45:01 -0700 (PDT) (envelope-from sgk) Date: Tue, 1 Aug 2006 13:45:01 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20060801204501.GA19647@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 20:45:03 -0000 I have a system that I have not updated since 16 Jun 06. I read /usr/src/UPDATING and note that the 3 newest entries do not affect me. So, I rebuild and update my kernel and world. Upon rebooting, I find that firefox dies with troutmask:kargl[202] firefox /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" OK, this is -current, so I rebuild and reinstall firefox. The firefox again gives me /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" Sure enough, grepping the sources in src/lib/libthr indeed shows that thr_getscheduler is used but never defined. It appears that libthr has been broken since 13 Jul 06. Is there any time line for when libthr will be fixed? Should an entry be added to /usr/src/UPDATING to warn people that libthr is broken? -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:02: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 A259D16A4DD for ; Tue, 1 Aug 2006 21:02:55 +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 432BC43D49 for ; Tue, 1 Aug 2006 21:02:55 +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.7/8.13.7/NETPLEX) with ESMTP id k71L2rFY006546; Tue, 1 Aug 2006 17:02:54 -0400 (EDT) Date: Tue, 1 Aug 2006 17:02:53 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20060801204501.GA19647@troutmask.apl.washington.edu> Message-ID: References: <20060801204501.GA19647@troutmask.apl.washington.edu> 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: Where is thr_getscheduler 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: Tue, 01 Aug 2006 21:02:55 -0000 On Tue, 1 Aug 2006, Steve Kargl wrote: > I have a system that I have not updated since 16 Jun 06. > I read /usr/src/UPDATING and note that the 3 newest entries > do not affect me. So, I rebuild and update my kernel and > world. Upon rebooting, I find that firefox dies with > > troutmask:kargl[202] firefox > /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" > > OK, this is -current, so I rebuild and reinstall firefox. The > firefox again gives me > /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "thr_getscheduler" > > Sure enough, grepping the sources in src/lib/libthr indeed shows > that thr_getscheduler is used but never defined. > > It appears that libthr has been broken since 13 Jul 06. Is there > any time line for when libthr will be fixed? Should an entry > be added to /usr/src/UPDATING to warn people that libthr is > broken? It's not borken. Your ports are probably just out-of-date and were built against a previous version of libc (libc.so.6) which doesn't have thr_getscheduler. What does `ldd /path/to/firefox_binary` show? I don't think rebuilding just firefox is going to fix the problem since it depends on other libraries that depend on libc.so.6, not libc.so.7. What does 'readelf -sW /lib/libc.so.7 | grep thr_get' show? Is firefox linked against libc.so.7 or libc.so.6 on your system? -- DE From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:16:58 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 EEC0016A4DA; Tue, 1 Aug 2006 21:16:58 +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 8D78743D46; Tue, 1 Aug 2006 21:16:58 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k71LGvLn009575; Tue, 1 Aug 2006 14:16:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k71LGvQW009574; Tue, 1 Aug 2006 14:16:57 -0700 (PDT) (envelope-from sgk) Date: Tue, 1 Aug 2006 14:16:57 -0700 From: Steve Kargl To: Daniel Eischen Message-ID: <20060801211657.GA29737@troutmask.apl.washington.edu> References: <20060801204501.GA19647@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 21:16:59 -0000 On Tue, Aug 01, 2006 at 05:02:53PM -0400, Daniel Eischen wrote: > On Tue, 1 Aug 2006, Steve Kargl wrote: > > >Sure enough, grepping the sources in src/lib/libthr indeed shows > >that thr_getscheduler is used but never defined. > > > >It appears that libthr has been broken since 13 Jul 06. Is there > >any time line for when libthr will be fixed? Should an entry > >be added to /usr/src/UPDATING to warn people that libthr is > >broken? > > It's not borken. Your ports are probably just out-of-date and were > built against a previous version of libc (libc.so.6) which doesn't > have thr_getscheduler. What does `ldd /path/to/firefox_binary` > show? troutmask:kargl[202] ldd `locate firefox-bin` | wc -l 37 troutmask:kargl[203] ldd `locate firefox-bin` | grep libc libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x201cce000) libc.so.7 => /lib/libc.so.7 (0x203245000) > I don't think rebuilding just firefox is going to fix the problem > since it depends on other libraries that depend on libc.so.6, > not libc.so.7. > > What does 'readelf -sW /lib/libc.so.7 | grep thr_get' show? It shows what you expect. 809: 0000000000053df0 0 FUNC WEAK DEFAULT 8 _thr_getscheduler 1993: 0000000000053df0 0 FUNC GLOBAL DEFAULT 8 __sys_thr_getscheduler 2437: 0000000000053df0 0 FUNC WEAK DEFAULT 8 thr_getscheduler > Is firefox linked against libc.so.7 or libc.so.6 on your system? I'm guess that one or more of the 37 shared libraries noted above is linked against libc.so.6. If this change would have been noted in UPDATING, I would have chosen a different day to deal with the mess that David Xu has caused. --- UPDATING.orig Tue Aug 1 14:11:56 2006 +++ UPDATING Tue Aug 1 14:15:03 2006 @@ -28,6 +28,13 @@ generated with an older version on 64 bit architectures. If you have such a file, you need old utility to decrypt it. +20060713: + David Xu updated libthr to use thr_getscheduler(), which is + present in libc.so.7 but not libc.so.6. This change wreaks + havoc on installed ports that use libthr and that are linked + against libc.so.6. It is suggested that one update their + installed ports. + 20060709: The interface version of the i4b kernel part has changed. So after updating the kernel sources and compiling a new kernel, -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:24: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 2223416A4DF; Tue, 1 Aug 2006 21:24:14 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6DC43D64; Tue, 1 Aug 2006 21:23:58 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 4D3CC191; Tue, 1 Aug 2006 16:23:58 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 891FA61C52; Tue, 1 Aug 2006 16:23:57 -0500 (CDT) Date: Tue, 1 Aug 2006 16:23:57 -0500 From: "Matthew D. Fuller" To: Steve Kargl Message-ID: <20060801212357.GS69505@over-yonder.net> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801211657.GA29737@troutmask.apl.washington.edu> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 21:24:14 -0000 On Tue, Aug 01, 2006 at 02:16:57PM -0700 I heard the voice of Steve Kargl, and lo! it spake thus: > > If this change would have been noted in UPDATING, I would have > chosen a different day to deal with the mess that David Xu has > caused. Considering how recently changes in libpthread in libc 6 vs 7 were causing every threaded program to just dump core, this seems a rather harsh indictment. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:27: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 913B216A4E5 for ; Tue, 1 Aug 2006 21:27:43 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt6.ihug.co.nz (grunt6.ihug.co.nz [203.109.254.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C92A43D53 for ; Tue, 1 Aug 2006 21:27:42 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt6.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1G81m8-0003oq-00; Wed, 02 Aug 2006 09:27:40 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 0B6271CC23; Wed, 2 Aug 2006 09:27:42 +1200 (NZST) Date: Wed, 2 Aug 2006 09:27:42 +1200 From: Andrew Thompson To: Steve Kargl Message-ID: <20060801212742.GB13841@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Steve Kargl , Daniel Eischen , freebsd-current@freebsd.org References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801211657.GA29737@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.11 Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 21:27:43 -0000 On Tue, Aug 01, 2006 at 02:16:57PM -0700, Steve Kargl wrote: > On Tue, Aug 01, 2006 at 05:02:53PM -0400, Daniel Eischen wrote: > > It's not borken. Your ports are probably just out-of-date and were > > built against a previous version of libc (libc.so.6) which doesn't > > have thr_getscheduler. What does `ldd /path/to/firefox_binary` > > show? > > troutmask:kargl[202] ldd `locate firefox-bin` | wc -l > 37 > troutmask:kargl[203] ldd `locate firefox-bin` | grep libc > libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x201cce000) > libc.so.7 => /lib/libc.so.7 (0x203245000) > > > If this change would have been noted in UPDATING, I would have > chosen a different day to deal with the mess that David Xu has > caused. > > --- UPDATING.orig Tue Aug 1 14:11:56 2006 > +++ UPDATING Tue Aug 1 14:15:03 2006 > @@ -28,6 +28,13 @@ > generated with an older version on 64 bit architectures. > If you have such a file, you need old utility to decrypt it. > > +20060713: > + David Xu updated libthr to use thr_getscheduler(), which is > + present in libc.so.7 but not libc.so.6. This change wreaks > + havoc on installed ports that use libthr and that are linked > + against libc.so.6. It is suggested that one update their > + installed ports. > + This is uncalled for, you should running stable if you dont want to deal with the changes in the latest working sources. From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:32: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 0F08616A509; Tue, 1 Aug 2006 21:32:50 +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 7C0B243D49; Tue, 1 Aug 2006 21:32:49 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k71LWmEZ024878; Tue, 1 Aug 2006 14:32:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k71LWmB3024877; Tue, 1 Aug 2006 14:32:48 -0700 (PDT) (envelope-from sgk) Date: Tue, 1 Aug 2006 14:32:48 -0700 From: Steve Kargl To: "Matthew D. Fuller" Message-ID: <20060801213248.GA9583@troutmask.apl.washington.edu> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212357.GS69505@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801212357.GS69505@over-yonder.net> User-Agent: Mutt/1.4.2.2i Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 21:32:50 -0000 On Tue, Aug 01, 2006 at 04:23:57PM -0500, Matthew D. Fuller wrote: > On Tue, Aug 01, 2006 at 02:16:57PM -0700 I heard the voice of > Steve Kargl, and lo! it spake thus: > > > > If this change would have been noted in UPDATING, I would have > > chosen a different day to deal with the mess that David Xu has > > caused. > > Considering how recently changes in libpthread in libc 6 vs 7 were > causing every threaded program to just dump core, this seems a rather > harsh indictment. I've switch to libpthread and everything is working, again. If I use libmap.conf to map libpthread to libthr, everything is broken. David Xu committed a change that uses a libc.so.7 function where libthr previously functioned fine with libc.so.6. This change should be noted in UPDATING. If you don't like the words I chose to use, then write whatever political correct message you want and add it to UPDATING. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:38: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 6A71716A4DA; Tue, 1 Aug 2006 21:38:09 +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 5102343D7E; Tue, 1 Aug 2006 21:38:05 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k71Lc36Y024922; Tue, 1 Aug 2006 14:38:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k71Lc3u8024921; Tue, 1 Aug 2006 14:38:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 1 Aug 2006 14:38:03 -0700 From: Steve Kargl To: Andrew Thompson , Daniel Eischen , freebsd-current@freebsd.org Message-ID: <20060801213803.GB9583@troutmask.apl.washington.edu> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801212742.GB13841@heff.fud.org.nz> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 21:38:09 -0000 On Wed, Aug 02, 2006 at 09:27:42AM +1200, Andrew Thompson wrote: > > > > +20060713: > > + David Xu updated libthr to use thr_getscheduler(), which is > > + present in libc.so.7 but not libc.so.6. This change wreaks > > + havoc on installed ports that use libthr and that are linked > > + against libc.so.6. It is suggested that one update their > > + installed ports. > > + > > This is uncalled for, you should running stable if you dont want to deal > with the changes in the latest working sources. I do run stable on other systems, and I'm well prepared to deal with problems on -current. The problem is that there is no notice in UPDATING the this problem exists. If UPDATING had a proper notice, I would have updated on a Saturday when I could afford down time. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 21:44: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 C60B316A4DF for ; Tue, 1 Aug 2006 21:44:15 +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 1526A43DBA for ; Tue, 1 Aug 2006 21:43:48 +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.7/8.13.7/NETPLEX) with ESMTP id k71Lhjfs011030; Tue, 1 Aug 2006 17:43:46 -0400 (EDT) Date: Tue, 1 Aug 2006 17:43:45 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20060801213248.GA9583@troutmask.apl.washington.edu> Message-ID: References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212357.GS69505@over-yonder.net> <20060801213248.GA9583@troutmask.apl.washington.edu> 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, "Matthew D. Fuller" Subject: Re: Where is thr_getscheduler 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: Tue, 01 Aug 2006 21:44:15 -0000 On Tue, 1 Aug 2006, Steve Kargl wrote: > On Tue, Aug 01, 2006 at 04:23:57PM -0500, Matthew D. Fuller wrote: >> On Tue, Aug 01, 2006 at 02:16:57PM -0700 I heard the voice of >> Steve Kargl, and lo! it spake thus: >>> >>> If this change would have been noted in UPDATING, I would have >>> chosen a different day to deal with the mess that David Xu has >>> caused. >> >> Considering how recently changes in libpthread in libc 6 vs 7 were >> causing every threaded program to just dump core, this seems a rather >> harsh indictment. > > I've switch to libpthread and everything is working, again. > If I use libmap.conf to map libpthread to libthr, everything > is broken. David Xu committed a change that uses a libc.so.7 > function where libthr previously functioned fine with libc.so.6. > This change should be noted in UPDATING. If you don't like the > words I chose to use, then write whatever political correct > message you want and add it to UPDATING. The problem is really that libthr (and all other necessary libraries) need to have their versions bumped. It's not just thr_getscheduler. There were networking changes added that required the libc version bump. If there had not been a version bump to libc, adding thr_getscheduler() and friends to libc.so.6 would not have caused you or anyone else any grief. We add functions and system calls all the time to libc without any problems. It is only when library versions are bumped that cause problems. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 22:00: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 8C1A616A50D for ; Tue, 1 Aug 2006 22:00:49 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D26CC43D5E for ; Tue, 1 Aug 2006 22:00:48 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id k71M0k1t013966 (8.13.4/1.4); Wed, 2 Aug 2006 00:00:46 +0200 (MEST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id k71M0k5c014661 (8.13.2/2.02); Wed, 2 Aug 2006 00:00:46 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Wed, 2 Aug 2006 00:00:46 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: calcru: runtime went backwards after resuming from DDB session X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 22:00:49 -0000 Hi. I keep seeing messages like calcru: runtime went backwards from 7521 usec to 5986 usec for pid 819 (bash) (repeated for several other processes) each time I resume from a DDB session and then type 'ps x'. Any way to get my machine to shut up about this? (-CURRENT from 1 Aug 2006) Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Tue Aug 1 23:40: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 3853D16A4DD for ; Tue, 1 Aug 2006 23:40:54 +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 B9F4543D5E for ; Tue, 1 Aug 2006 23:40:51 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G83qs-0006LW-EU for freebsd-current@freebsd.org; Wed, 02 Aug 2006 01:40:42 +0200 Received: from p54ba684e.dip.t-dialin.net ([84.186.104.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Aug 2006 01:40:42 +0200 Received: from der_julian by p54ba684e.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Aug 2006 01:40:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Wed, 02 Aug 2006 01:40:32 +0200 Lines: 17 Message-ID: <86hd0w2ff3.fsf@dellbeast.localnet> References: <86mzap4qzx.fsf@dellbeast.localnet> <20060801143508.GO1458@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p54ba684e.dip.t-dialin.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.5-b27 (berkeley-unix) Cancel-Lock: sha1:TJTQ+YF8ian8ZT3pMhZp85qhsFw= Sender: news Subject: Re: [fbsd] SSP/ProPolice build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Aug 2006 23:40:54 -0000 Jeremie Le Hen writes: > I think this has nothing to do with the ProPolice patch. Try fetching > your sources again, there may be a temporary breakage in the CVS sources. Actually, I am running a -CURRENT built from the very same patched sources without WITH_SSP in src.conf. I'll try again with CURRENT as of today, just to make sure. (There is no need to CC me, as I am subscribed to the group.) Regards, -- Julian Stecklina C has all the expressive power of two dixie cups and a string. (Jamie Zawinski) From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 00:54: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 1C52216A4DA for ; Wed, 2 Aug 2006 00:54:34 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web56504.mail.re3.yahoo.com (web56504.mail.re3.yahoo.com [66.196.97.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 8FD6443D46 for ; Wed, 2 Aug 2006 00:54:33 +0000 (GMT) (envelope-from neshort@yahoo.com) Received: (qmail 73477 invoked by uid 60001); 2 Aug 2006 00:54:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2IwRLtAd5RMgczJUfOhU+ydKDRqp8uO019jsioqcnlAVxYM9A+y9Iofddw9m8zDTXdRfjYKuDQ5E3aQsUctXsb4ilouBc1fgU/YP0rzXfpnMQkdCwXCxzTqXDOoHsZ+FrsymCerzVuwC9J6hFuuf3gE1d/LSgAq9Oh6IPuO+GLg= ; Message-ID: <20060802005432.73475.qmail@web56504.mail.re3.yahoo.com> Received: from [24.221.134.150] by web56504.mail.re3.yahoo.com via HTTP; Tue, 01 Aug 2006 17:54:32 PDT Date: Tue, 1 Aug 2006 17:54:32 -0700 (PDT) From: Neil Short To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ath0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 00:54:34 -0000 is this a new problem? Everything has been working famously on this box with respect to the builtin atheros ethernet device. I updated to current a few days ago and now after a few minutes the connection dies with repeated: ath0: device timeout. The difference is, as mentioned, I am on the latest current. also, since the generic kernel has the atheros stuff in it I took them out of /boot/loader.conf. so, here's what I have: /boot/loader.conf: #wlan_wep_load="yes" #wlan_tkip_load="YES" #wlan_ccmp_load="YES" wlan_xauth_load="YES" #if_ath_load="yes" kernel config file: ... # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device wlan_xauth # INTERESTING THAT THIS MODULE DOESN'T AUTO-LOAD WITH WPA ... ====== 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 Wed Aug 2 03:34: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 8512216A4DD for ; Wed, 2 Aug 2006 03:34:38 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2415543D45 for ; Wed, 2 Aug 2006 03:34:37 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 752F0114FF; Tue, 1 Aug 2006 23:34:05 -0400 (EDT) Message-ID: <44D01D51.2090409@rogers.com> Date: Tue, 01 Aug 2006 23:34:41 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michiel Boland References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.471, required 3.5, ALL_TRUSTED -1.80, AWL 0.02, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: calcru: runtime went backwards after resuming from DDB session X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 03:34:38 -0000 Michiel Boland wrote: > Hi. I keep seeing messages like > > calcru: runtime went backwards from 7521 usec to 5986 usec for pid 819 > (bash) > > (repeated for several other processes) > > each time I resume from a DDB session and then type 'ps x'. Any way to > get my machine to shut up about this? I have tons of these in 6-STABLE, from normal ps/w/top usage, without the use of a debugger. CURRENT however seems to work fine for me, but it seems the changes are too great to MFC, so what i did is i just commented the warnings out from the source code. Look into src/sys/kern/kern_resource.c, and comment out the following statement --- printf("calcru: runtime went backwards from %ju usec " "to %ju usec for pid %d (%s)\n", (uintmax_t)ruxp->rux_tu, (uintmax_t)tu, p->p_pid, p->p_comm); --- recompile kernel. From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 05:17: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 C059A16A4DA; Wed, 2 Aug 2006 05:17:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F6143D46; Wed, 2 Aug 2006 05:17:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k725Ht6W033705; Wed, 2 Aug 2006 01:17:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k725Hu1L002469; Wed, 2 Aug 2006 01:17:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0C8717302F; Wed, 2 Aug 2006 01:17:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060802051756.0C8717302F@freebsd-current.sentex.ca> Date: Wed, 2 Aug 2006 01:17:56 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 05:17:57 -0000 TB --- 2006-08-02 03:49:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-08-02 03:49:44 - starting HEAD tinderbox run for i386/i386 TB --- 2006-08-02 03:49:45 - cleaning the object tree TB --- 2006-08-02 03:50:19 - checking out the source tree TB --- 2006-08-02 03:50:19 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-08-02 03:50:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-08-02 03:57:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-08-02 03:57:26 - cd /src TB --- 2006-08-02 03:57:26 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-08-02 05:06:15 - generating LINT kernel config TB --- 2006-08-02 05:06:15 - cd /src/sys/i386/conf TB --- 2006-08-02 05:06:15 - /usr/bin/make -B LINT TB --- 2006-08-02 05:06:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-08-02 05:06:15 - cd /src TB --- 2006-08-02 05:06:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 2 05:06:15 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/bridgestp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/bsd_comp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_arcsubr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_atmsubr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/net/if_bridge.c /src/sys/net/if_bridge.c: In function `bridge_clone_create': /src/sys/net/if_bridge.c:569: error: too few arguments to function `bstp_attach' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-08-02 05:17:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-08-02 05:17:55 - ERROR: failed to build lint kernel TB --- 2006-08-02 05:17:55 - tinderbox aborted TB --- 1.19 user 6.07 system 5290.94 real From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 11:00: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 4231A16A575 for ; Wed, 2 Aug 2006 11:00:35 +0000 (UTC) (envelope-from amogilny@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 783D643D66 for ; Wed, 2 Aug 2006 11:00:28 +0000 (GMT) (envelope-from amogilny@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so612553nfc for ; Wed, 02 Aug 2006 04:00:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=RbzWMgdUUzng/KTwdyp1cw7e/WONcHkySr8EB6TSihG1pxarMpoPwlMgwyHOXlpZv2FFBOyc7Tc+JtNLiiCAJjmm7Lr9EywKynW1s/8ZWIW9SdxfcLnS88AY5ECZz3i1jos8nLSRuX5W1YIILJvv0m7X0LFwJDfDfEHcxe97jpY= Received: by 10.78.183.8 with SMTP id g8mr263018huf; Wed, 02 Aug 2006 04:00:26 -0700 (PDT) Received: by 10.78.178.3 with HTTP; Wed, 2 Aug 2006 04:00:26 -0700 (PDT) Message-ID: <7403d2a30608020400i7c5027d5v3cc762efd5eeb36f@mail.gmail.com> Date: Wed, 2 Aug 2006 14:00:26 +0300 From: "Alexander Mogilny" Sender: amogilny@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4367_28429539.1154516426829" X-Google-Sender-Auth: 8dd8283e180b3694 Subject: [patch] make doxygen failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 11:00:35 -0000 ------=_Part_4367_28429539.1154516426829 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all. I recently tried to build doxygen target in order to build kernel sources documentation but failed. The most recent error you would get trying to build this target is that make tries to change dir to sys/doc directory. Here are the patches which corrects the build of doxygen target. You may try it on your own. -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ ------=_Part_4367_28429539.1154516426829 Content-Type: application/octet-stream; name=Makefile.inc1.patch.doxygen Content-Transfer-Encoding: base64 X-Attachment-Id: f_eqdl1n6p Content-Disposition: attachment; filename="Makefile.inc1.patch.doxygen" LS0tIC91c3Ivc3JjL01ha2VmaWxlLmluYzEub3JpZwlXZWQgQXVnICAyIDEzOjE4OjA1IDIwMDYK KysrIC91c3Ivc3JjL01ha2VmaWxlLmluYzEJV2VkIEF1ZyAgMiAxMzoyMTo1NCAyMDA2CkBAIC03 MzEsNyArNzMxLDcgQEAKIAkJZWNobyAiWW91IG5lZWQgZG94eWdlbiAoZGV2ZWwvZG94eWdlbikg dG8gZ2VuZXJhdGUgdGhlIEFQSSBkb2N1bWVudGF0aW9uIG9mIHRoZSBrZXJuZWwuIiB8IC91c3Iv YmluL2ZtdDsgXAogCQlleGl0IDE7IFwKIAlmaQotCWNkICR7LkNVUkRJUn0vc3lzL2RvYy9zdWJz eXMgJiYgJHtNQUtFfSBvYmogYWxsCisJY2QgJHsuQ1VSRElSfS90b29scy9rZXJuZWxkb2Mvc3Vi c3lzICYmICR7TUFLRX0gYWxsCiAKICMKICMgdXBkYXRlCg== ------=_Part_4367_28429539.1154516426829 Content-Type: application/octet-stream; name=Makefile.patch.doxygen Content-Transfer-Encoding: base64 X-Attachment-Id: f_eqdl1uwh Content-Disposition: attachment; filename="Makefile.patch.doxygen" LS0tIC91c3Ivc3JjL3Rvb2xzL2tlcm5lbGRvYy9zdWJzeXMvTWFrZWZpbGUub3JpZwlXZWQgQXVn ICAyIDEzOjIzOjA2IDIwMDYKKysrIC91c3Ivc3JjL3Rvb2xzL2tlcm5lbGRvYy9zdWJzeXMvTWFr ZWZpbGUJV2VkIEF1ZyAgMiAxMzo0NDoxMSAyMDA2CkBAIC03Myw2ICs3Myw3IEBACiBET1hZR0VO X0RFU1RfUEFUSD0JJHsuT0JKRElSfQogRE9YWUdFTl9MQVRFWF9ERVNUX1BBVEg9JHsuT0JKRElS fQogRE9YWUdFTl9QREZfREVTVF9QQVRIPQkkey5PQkpESVJ9CitMT0NBTF9QUkVGSVg9L3Vzci9s b2NhbC9iaW4KIAogLmlmIGV4aXN0c3ske1N9LyR7VEFSR0VUX0FSQ0h9L2xpbnV4fQogRE9YWUdF Tl9MSU5VWF9QQVRIPQkke1N9LyR7VEFSR0VUX0FSQ0h9L2xpbnV4CkBAIC04OCw2ICs4OSw3IEBA CiAke3RhcmdldH06CW1maWxlcyAkey5PQkpESVJ9LyR7dGFyZ2V0fS8ke3RhcmdldH0udGFnCiAK ICR7Lk9CSkRJUn0vJHt0YXJnZXR9LyR7dGFyZ2V0fS50YWc6CisJQG1rZGlyIC1wICR7Lk9CSkRJ Un0vJHt0YXJnZXR9LwogCUBjZCAkey5PQkpESVJ9ICYmIFwKIAkJZW52IERPWFlHRU5fSU5DTFVE RV9QQVRIPSR7LkNVUkRJUn0gXAogCQkgICAgRE9YWUdFTl9TUkNfUEFUSD0ke1N9ICBcCkBAIC05 Niw2ICs5OCw3IEBACiAJCSAgICBET1hZR0VOX1RBUkdFVF9BUkNIPSR7VEFSR0VUX0FSQ0h9IFwK IAkJICAgIERPWFlHRU5fTElOVVhfUEFUSD0ke0RPWFlHRU5fTElOVVhfUEFUSH0gXAogCQkgICAg Tk9UUkVWSUVXRUQ9JHsuQ1VSRElSfS9ub3RyZXZpZXdlZC5kb3ggXAorCQkJUEFUSD0ke0xPQ0FM X1BSRUZJWH0gXAogCQkJZG94eWdlbiAkey5DVVJESVJ9L0RveHlmaWxlLSR7dGFyZ2V0fQogCUBl Y2hvICJBUEkgZG9jcyBmb3IgJHt0YXJnZXR9IGFyZSBub3cgYXZhaWxhYmxlIGluICR7Lk9CSkRJ Un0vJHt0YXJnZXR9Ly4iIHwgL3Vzci9iaW4vZm10CiAK ------=_Part_4367_28429539.1154516426829-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 14:10: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 3C81216A4DD for ; Wed, 2 Aug 2006 14:10:44 +0000 (UTC) (envelope-from bsdlists@gmx.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CBDF43D5E for ; Wed, 2 Aug 2006 14:10:43 +0000 (GMT) (envelope-from bsdlists@gmx.de) Received: (qmail 24252 invoked from network); 2 Aug 2006 14:10:41 -0000 Received: from unknown (HELO tobias) (369593@[213.54.220.235]) (envelope-sender ) by smtprelay06.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 2 Aug 2006 14:10:41 -0000 From: Tobias =?ISO-8859-1?Q?Gro=DFer?= To: freebsd-current@freebsd.org Content-Type: text/plain Date: Wed, 02 Aug 2006 16:05:24 +0200 Message-Id: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 14:10:44 -0000 Hi, im trying to build an dtrace enabled FreeBSD current and use the source from: *default host=cvsup10.freebsd.org *default release=cvs *default delete use-rel-suffix p4-cvs-dtraced Details at: http://people.freebsd.org/~jb/dtrace/ Unfortunally I am not able to finish the build because it always breaks in /usr/src/cddl/usr.bin/ctfconvert with this ld-error: /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread I was able to "solve" this problem by adding the following line to the Makefile: CFLAGS += -L/usr/obj/usr/src/lib/libpthread But now it hangs in ggatec: ===> sbin/ggate (all) ===> sbin/ggate/ggatec (all) cc -O2 -fno-strict-aliasing -pipe -DNO_MALLOC_EXTRAS -O -pipe -DLIBGEOM -I/usr/src/sbin/ggate/ggat ec/../shared -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -W shadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decl s -c /usr/src/sbin/ggate/ggatec/ggatec.c ctfconvert -L VERSION ggatec.o cc -O2 -fno-strict-aliasing -pipe -DNO_MALLOC_EXTRAS -O -pipe -DLIBGEOM -I/usr/src/sbin/ggate/ggat ec/../shared -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -W shadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decl s -c /usr/src/sbin/ggate/ggatec/../shared/ggate.c ctfconvert -L VERSION ggate.o cc -O2 -fno-strict-aliasing -pipe -DNO_MALLOC_EXTRAS -O -pipe -DLIBGEOM -I/usr/src/sbin/ggate/ggat ec/../shared -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -W shadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decl s -o ggatec ggatec.o ggate.o -lgeom -lsbuf -lbsdxml -lutil -lpthread /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread *** Error code 1 Stop in /usr/src/sbin Is there something generally broken with my threading libraries? It doesn't seem to be an dtrace issue? Thanks for any hint to solve this problem. Tobias From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 14:43: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 76F9116A4DF; Wed, 2 Aug 2006 14:43:01 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B2EF43D77; Wed, 2 Aug 2006 14:42:56 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 3C379191; Wed, 2 Aug 2006 09:42:56 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7E1DF61C2B; Wed, 2 Aug 2006 09:42:55 -0500 (CDT) Date: Wed, 2 Aug 2006 09:42:55 -0500 From: "Matthew D. Fuller" To: Steve Kargl Message-ID: <20060802144255.GU69505@over-yonder.net> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801213803.GB9583@troutmask.apl.washington.edu> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: Daniel Eischen , freebsd-current@freebsd.org, Andrew Thompson Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 14:43:01 -0000 On Tue, Aug 01, 2006 at 02:38:03PM -0700 I heard the voice of Steve Kargl, and lo! it spake thus: > > If UPDATING had a proper notice, If UPDATING had a notice every time a {library,program} in 7 did something that wasn't supported by 6 (for various values of 7 and 6), it would be a very, very long and very boring file. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 14:44:51 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA05F16A4DE for ; Wed, 2 Aug 2006 14:44:51 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 215E643D45 for ; Wed, 2 Aug 2006 14:44:50 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.4) with ESMTP id k72EiZL3011119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Aug 2006 16:44:35 +0200 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.6/Submit) with ESMTP id k72EiYfn011115 for ; Wed, 2 Aug 2006 16:44:34 +0200 Date: Wed, 2 Aug 2006 16:44:34 +0200 (CEST) From: Goran Gajic To: freebsd-current@mx1.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1536391169-1355910645-1154529874=:10912" X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Wed, 02 Aug 2006 14:55:12 +0000 Cc: Subject: 7.0-CURRENT panic from today build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 14:44:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1536391169-1355910645-1154529874=:10912 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT fbsd# kgdb /usr/src/sys/i386/compile/GENERIC/kernel.debug /var/crash/vmcore.3 [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: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex so_rcv r = 0 (0xc30a56f0) locked @ kern/uipc_socket2.c:166 exclusive sleep mutex inp (tcpinp) r = 0 (0xc30db480) locked @ netinet/tcp_usrreq.c:252 exclusive sleep mutex tcp r = 0 (0xc0a5a2ec) locked @ netinet/tcp_usrreq.c:251 KDB: stack backtrace: kdb_backtrace(3,c2c91d38,c,c2773360,d5aa8a5c,...) at kdb_backtrace+0x29 witness_warn(5,0,c0946263) at witness_warn+0x192 trap(c0a50008,28,c0910028,c30a56d8,c30a567c,...) at trap+0x108 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06818d2, esp = 0xd5aa8aa4, ebp = 0xd5aa8aa4 --- knlist_mtx_locked(0) at knlist_mtx_locked+0x6 knote(c30a56d8,0,1,c30a56f0,c30a567c,...) at knote+0x1d sowakeup(c30a567c,c30a56cc) at sowakeup+0x61 soisdisconnected(c30a567c) at soisdisconnected+0x61 tcp_discardcb(c30b6570) at tcp_discardcb+0x1f5 tcp_detach(c30a567c,c30db3f0,c30a567c,c09d1568,d5aa8b74,...) at tcp_detach+0x14e tcp_usr_detach(c30a567c) at tcp_usr_detach+0x67 sofree(c30a567c) at sofree+0x1fe soclose(c30a567c) at soclose+0x2d9 soo_close(c30dfbd0,c2773360) at soo_close+0x4b fdrop_locked(c30dfbd0,c2773360,c24806d0,0,c091adae,...) at fdrop_locked+0x88 fdrop(c30dfbd0,c2773360,6b5,c0a11a94,0,...) at fdrop+0x24 closef(c30dfbd0,c2773360,1,0,0,...) at closef+0x367 kern_close(c2773360,1d,d5aa8d30,c08990de,c2773360,...) at kern_close+0x1b6 close(c2773360,d5aa8d04) at close+0x10 syscall(a8e0003b,bf1f003b,8245003b,e,947fa38,...) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, Linux ELF, close), eip = 0x28feecaf, esp = 0xbf1ff698, ebp = 0x91ed218 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06818d2 stack pointer = 0x28:0xd5aa8aa4 frame pointer = 0x28:0xd5aa8aa4 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 = 598 (skype) Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:166 166 pcpu.h: No such file or directory. in pcpu.h (kgdb) ) where #0 doadump () at pcpu.h:166 #1 0xc04758a3 in db_fncall (dummy1=-710244144, dummy2=0, dummy3=1016, dummy4=0xd5aa88a4 "¼\210ªÕø\003") at ../../../ddb/db_command.c:481 #2 0xc04756af in db_command (last_cmdp=0xc09f0a84, cmd_table=0x0) at ../../../ddb/db_command.c:396 #3 0xc047576a in db_command_loop () at ../../../ddb/db_command.c:448 #4 0xc0477369 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 #5 0xc06b71d0 in kdb_trap (type=12, code=0, tf=0xd5aa8a64) at ../../../kern/subr_kdb.c:502 #6 0xc0898dc1 in trap_fatal (frame=0xd5aa8a64, eva=16) at ../../../i386/i386/trap.c:858 #7 0xc089843f in trap (frame= {tf_fs = -1062928376, tf_es = 40, tf_ds = -1064239064, tf_edi = -1022732584, tf_esi = -1022732676, tf_ebp = -710243676, tf_isp = -710243696, tf_ebx = -102 2732596, tf_edx = -1032388600, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 16, tf_eip = -1066919726, tf_cs = 32, tf_eflags = 66050, tf_esp = -710243652, tf _ss = -1066920643}) at ../../../i386/i386/trap.c:277 #8 0xc0883e2a in calltrap () at ../../../i386/i386/exception.s:138 #9 0xc06818d2 in knlist_mtx_locked (arg=0x0) at ../../../kern/kern_event.c:1644 #10 0xc068153d in knote (list=0xc30a56d8, hint=0, islocked=1) at ../../../kern/kern_event.c:1520 #11 0xc06da6dd in sowakeup (so=0xc30a567c, sb=0xc30a56cc) at ../../../kern/uipc_sockbuf.c:190 #12 0xc06df7dd in soisdisconnected (so=0xc30a567c) at ../../../kern/uipc_socket2.c:170 #13 0xc07476d1 in tcp_discardcb (tp=0xc30b6570) at ../../../netinet/tcp_subr.c:786 #14 0xc074bee2 in tcp_detach (so=0xc30a567c, inp=0xc30db3f0) at ../../../netinet/tcp_usrreq.c:212 #15 0xc074bf9b in tcp_usr_detach (so=0xc30a567c) at ../../../netinet/tcp_usrreq.c:257 #16 0xc06dc206 in sofree (so=0xc30a567c) at ../../../kern/uipc_socket.c:614 #17 0xc06dc4f1 in soclose (so=0xc30a567c) at ../../../kern/uipc_socket.c:684 #18 0xc06c9c53 in soo_close (fp=0xc30dfbd0, td=0xc2773360) at ../../../kern/sys_socket.c:315 #19 0xc067dcc8 in fdrop_locked (fp=0xc30dfbd0, td=0xc2773360) at file.h:296 #20 0xc067dc38 in fdrop (fp=0xc30dfbd0, td=0xc2773360) at ../../../kern/kern_descrip.c:2164 #21 0xc067c727 in closef (fp=0xc30dfbd0, td=0xc2773360) at ../../../kern/kern_descrip.c:1979 #22 0xc067a002 in kern_close (td=0xc2773360, fd=29) at ../../../kern/kern_descrip.c:1026 #23 0xc0679e48 in close (td=0xc2773360, uap=0x0) at ../../../kern/kern_descrip.c:977 #24 0xc08990de in syscall (frame= {tf_fs = -1461714885, tf_es = -1088487365, tf_ds = -2109407173, tf_edi = 14, tf_esi = 155712056, tf_ebp = 153014808, tf_isp = -710242972, tf_ebx = 29, tf_ edx = 156362632, tf_ecx = 1, tf_eax = 6, tf_trapno = 22, tf_err = 2, tf_eip = 687795375, tf_cs = 51, tf_eflags = 582, tf_esp = -1088424296, tf_ss = 59}) at ../../../i386/i386/trap.c:1006 #25 0xc0883e7f in Xint0x80_syscall () at ../../../i386/i386/exception.s:191 #26 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) FreeBSD fbsd.interex.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Aug 2 13:15:27 CEST 2006 root@fbsd.interex.net:/usr/src/sys/i386/compile/GENERIC i386 Regards, gg. --1536391169-1355910645-1154529874=:10912-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 15:06:14 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47CDE16A4E2 for ; Wed, 2 Aug 2006 15:06:14 +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 0C9F843D5D for ; Wed, 2 Aug 2006 15:06:13 +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 6BDAC46CF9; Wed, 2 Aug 2006 11:06:11 -0400 (EDT) Date: Wed, 2 Aug 2006 16:06:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Goran Gajic In-Reply-To: Message-ID: <20060802160339.G56791@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-214084542-1154531171=:56791" Cc: freebsd-current@mx1.freebsd.org Subject: Re: 7.0-CURRENT panic from today build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 15:06:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-214084542-1154531171=:56791 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 2 Aug 2006, Goran Gajic wrote: > fbsd# kgdb /usr/src/sys/i386/compile/GENERIC/kernel.debug /var/crash/vmco= re.3 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o:=20 > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd". Thanks for the report. This is similar to a problem that cropped up in the= =20 UNIX domain socket code last week after changes in the way socket tear-down= =20 were made. I'll likely have a fix for this in the next 24 hours or so, jus= t=20 need to read some code and decide which of two or three approaches is most= =20 likely the right one. To be specific: the problem is that right now we largely tear down socket= =20 state, such as socket buffers and kqueue, before we enter the pru_detach=20 routine now. This means that the call to soisdisconnected() from=20 tcp_discardcb() is no longer occuring in the right place, and needs to move= =2E=20 There was already a comment from me there suggesting it was in the wrong pl= ace=20 from before, now it is definitely in the wrong place. Likely the socket=20 should already be detached from the pcb when we run tcp_discardcb(), and th= e=20 caller should have called soisdisconnected() if it was needed. I'll commit the fix directly to CVS, so you will want to cvsup in about 24= =20 hours to pick it up. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > Unread portion of the kernel message buffer: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex so_rcv r =3D 0 (0xc30a56f0) locked @=20 > kern/uipc_socket2.c:166 > exclusive sleep mutex inp (tcpinp) r =3D 0 (0xc30db480) locked @=20 > netinet/tcp_usrreq.c:252 > exclusive sleep mutex tcp r =3D 0 (0xc0a5a2ec) locked @=20 > netinet/tcp_usrreq.c:251 > KDB: stack backtrace: > kdb_backtrace(3,c2c91d38,c,c2773360,d5aa8a5c,...) at kdb_backtrace+0x29 > witness_warn(5,0,c0946263) at witness_warn+0x192 > trap(c0a50008,28,c0910028,c30a56d8,c30a567c,...) at trap+0x108 > calltrap() at calltrap+0x5 > --- trap 0xc, eip =3D 0xc06818d2, esp =3D 0xd5aa8aa4, ebp =3D 0xd5aa8aa4 = --- > knlist_mtx_locked(0) at knlist_mtx_locked+0x6 > knote(c30a56d8,0,1,c30a56f0,c30a567c,...) at knote+0x1d > sowakeup(c30a567c,c30a56cc) at sowakeup+0x61 > soisdisconnected(c30a567c) at soisdisconnected+0x61 > tcp_discardcb(c30b6570) at tcp_discardcb+0x1f5 > tcp_detach(c30a567c,c30db3f0,c30a567c,c09d1568,d5aa8b74,...) at=20 > tcp_detach+0x14e > tcp_usr_detach(c30a567c) at tcp_usr_detach+0x67 > sofree(c30a567c) at sofree+0x1fe > soclose(c30a567c) at soclose+0x2d9 > soo_close(c30dfbd0,c2773360) at soo_close+0x4b > fdrop_locked(c30dfbd0,c2773360,c24806d0,0,c091adae,...) at fdrop_locked+0= x88 > fdrop(c30dfbd0,c2773360,6b5,c0a11a94,0,...) at fdrop+0x24 > closef(c30dfbd0,c2773360,1,0,0,...) at closef+0x367 > kern_close(c2773360,1d,d5aa8d30,c08990de,c2773360,...) at kern_close+0x1b= 6 > close(c2773360,d5aa8d04) at close+0x10 > syscall(a8e0003b,bf1f003b,8245003b,e,947fa38,...) at syscall+0x256 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (6, Linux ELF, close), eip =3D 0x28feecaf, esp =3D 0xbf1ff698= , ebp =3D=20 > 0x91ed218 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x10 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc06818d2 > stack pointer =3D 0x28:0xd5aa8aa4 > frame pointer =3D 0x28:0xd5aa8aa4 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 598 (skype) > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 33= 5=20 > 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:166 > 166 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) ) where > #0 doadump () at pcpu.h:166 > #1 0xc04758a3 in db_fncall (dummy1=3D-710244144, dummy2=3D0, dummy3=3D10= 16,=20 > dummy4=3D0xd5aa88a4 "=BC\210=AA=D5=F8\003") at ../../../ddb/db_command.c:= 481 > #2 0xc04756af in db_command (last_cmdp=3D0xc09f0a84, cmd_table=3D0x0) at= =20 > ../../../ddb/db_command.c:396 > #3 0xc047576a in db_command_loop () at ../../../ddb/db_command.c:448 > #4 0xc0477369 in db_trap (type=3D12, code=3D0) at ../../../ddb/db_main.c= :221 > #5 0xc06b71d0 in kdb_trap (type=3D12, code=3D0, tf=3D0xd5aa8a64) at=20 > ../../../kern/subr_kdb.c:502 > #6 0xc0898dc1 in trap_fatal (frame=3D0xd5aa8a64, eva=3D16) at=20 > ../../../i386/i386/trap.c:858 > #7 0xc089843f in trap (frame=3D > {tf_fs =3D -1062928376, tf_es =3D 40, tf_ds =3D -1064239064, tf_edi = =3D=20 > -1022732584, tf_esi =3D -1022732676, tf_ebp =3D -710243676, tf_isp =3D -7= 10243696,=20 > tf_ebx =3D -102 > 2732596, tf_edx =3D -1032388600, tf_ecx =3D 4, tf_eax =3D 0, tf_trapno = =3D 12, tf_err=20 > =3D 16, tf_eip =3D -1066919726, tf_cs =3D 32, tf_eflags =3D 66050, tf_esp= =3D=20 > -710243652, tf > _ss =3D -1066920643}) at ../../../i386/i386/trap.c:277 > #8 0xc0883e2a in calltrap () at ../../../i386/i386/exception.s:138 > #9 0xc06818d2 in knlist_mtx_locked (arg=3D0x0) at=20 > ../../../kern/kern_event.c:1644 > #10 0xc068153d in knote (list=3D0xc30a56d8, hint=3D0, islocked=3D1) at=20 > ../../../kern/kern_event.c:1520 > #11 0xc06da6dd in sowakeup (so=3D0xc30a567c, sb=3D0xc30a56cc) at=20 > ../../../kern/uipc_sockbuf.c:190 > #12 0xc06df7dd in soisdisconnected (so=3D0xc30a567c) at=20 > ../../../kern/uipc_socket2.c:170 > #13 0xc07476d1 in tcp_discardcb (tp=3D0xc30b6570) at=20 > ../../../netinet/tcp_subr.c:786 > #14 0xc074bee2 in tcp_detach (so=3D0xc30a567c, inp=3D0xc30db3f0) at=20 > ../../../netinet/tcp_usrreq.c:212 > #15 0xc074bf9b in tcp_usr_detach (so=3D0xc30a567c) at=20 > ../../../netinet/tcp_usrreq.c:257 > #16 0xc06dc206 in sofree (so=3D0xc30a567c) at ../../../kern/uipc_socket.c= :614 > #17 0xc06dc4f1 in soclose (so=3D0xc30a567c) at ../../../kern/uipc_socket.= c:684 > #18 0xc06c9c53 in soo_close (fp=3D0xc30dfbd0, td=3D0xc2773360) at=20 > ../../../kern/sys_socket.c:315 > #19 0xc067dcc8 in fdrop_locked (fp=3D0xc30dfbd0, td=3D0xc2773360) at file= =2Eh:296 > #20 0xc067dc38 in fdrop (fp=3D0xc30dfbd0, td=3D0xc2773360) at=20 > ../../../kern/kern_descrip.c:2164 > #21 0xc067c727 in closef (fp=3D0xc30dfbd0, td=3D0xc2773360) at=20 > ../../../kern/kern_descrip.c:1979 > #22 0xc067a002 in kern_close (td=3D0xc2773360, fd=3D29) at=20 > ../../../kern/kern_descrip.c:1026 > #23 0xc0679e48 in close (td=3D0xc2773360, uap=3D0x0) at=20 > ../../../kern/kern_descrip.c:977 > #24 0xc08990de in syscall (frame=3D > {tf_fs =3D -1461714885, tf_es =3D -1088487365, tf_ds =3D -2109407173= , tf_edi=20 > =3D 14, tf_esi =3D 155712056, tf_ebp =3D 153014808, tf_isp =3D -710242972= , tf_ebx =3D=20 > 29, tf_ > edx =3D 156362632, tf_ecx =3D 1, tf_eax =3D 6, tf_trapno =3D 22, tf_err = =3D 2, tf_eip =3D=20 > 687795375, tf_cs =3D 51, tf_eflags =3D 582, tf_esp =3D -1088424296, tf_ss= =3D 59}) > at ../../../i386/i386/trap.c:1006 > #25 0xc0883e7f in Xint0x80_syscall () at ../../../i386/i386/exception.s:1= 91 > #26 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > FreeBSD fbsd.interex.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Aug 2= =20 > 13:15:27 CEST 2006 root@fbsd.interex.net:/usr/src/sys/i386/compile/GENERI= C=20 > i386 > > > Regards, > gg. > --0-214084542-1154531171=:56791-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 15:27: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 90D2D16A4DE for ; Wed, 2 Aug 2006 15:27:42 +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 DE9BA43D49 for ; Wed, 2 Aug 2006 15:27:41 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E03B.dip.t-dialin.net [84.165.224.59]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k72FE3qo034177 for ; Wed, 2 Aug 2006 17:14:04 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k72FRiid092870 for ; Wed, 2 Aug 2006 17:27:45 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Wed, 2 Aug 2006 17:29:25 +0200 From: Alexander Leidinger To: freebsd-current@freebsd.org Message-ID: <20060802172925.2e6c08fe@Magellan.Leidinger.net> In-Reply-To: <7403d2a30608020400i7c5027d5v3cc762efd5eeb36f@mail.gmail.com> References: <7403d2a30608020400i7c5027d5v3cc762efd5eeb36f@mail.gmail.com> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Subject: Re: [patch] make doxygen failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 15:27:42 -0000 Quoting "Alexander Mogilny" (Wed, 2 Aug 2006 14:00:26 +0300): > Hi all. > I recently tried to build doxygen target in order to build kernel > sources documentation but failed. The most recent error you would get > trying to build this target is that make tries to change dir to > sys/doc directory. Here are the patches which corrects the build of > doxygen target. You may try it on your own. I committed a different fix for the Makefile, the Makefile.inc1 patch was ok. Thanks! Bye, Alexander. -- There's a way out of any cage. -- Captain Christopher Pike, "The Menagerie" ("The Cage"), stardate unknown. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 16:18:47 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5384B16A4E1 for ; Wed, 2 Aug 2006 16:18:47 +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 A754343D46 for ; Wed, 2 Aug 2006 16:18:46 +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 3435C46D24; Wed, 2 Aug 2006 12:18:38 -0400 (EDT) Date: Wed, 2 Aug 2006 17:18:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Goran Gajic In-Reply-To: <20060802160339.G56791@fledge.watson.org> Message-ID: <20060802171811.R56791@fledge.watson.org> References: <20060802160339.G56791@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@mx1.freebsd.org Subject: Re: 7.0-CURRENT panic from today build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 16:18:47 -0000 On Wed, 2 Aug 2006, Robert Watson wrote: > I'll commit the fix directly to CVS, so you will want to cvsup in about 24 > hours to pick it up. I've committed a possible fix as tcp_subr.c:1.254. Thanks! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 16:20:17 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E71A916A4E5 for ; Wed, 2 Aug 2006 16:20:17 +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 5544943D45 for ; Wed, 2 Aug 2006 16:20:17 +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 2ED9546D2A; Wed, 2 Aug 2006 12:20:16 -0400 (EDT) Date: Wed, 2 Aug 2006 17:20:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Goran Gajic In-Reply-To: <20060802171811.R56791@fledge.watson.org> Message-ID: <20060802171957.R56791@fledge.watson.org> References: <20060802160339.G56791@fledge.watson.org> <20060802171811.R56791@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@mx1.freebsd.org Subject: Re: 7.0-CURRENT panic from today build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 16:20:18 -0000 On Wed, 2 Aug 2006, Robert Watson wrote: > On Wed, 2 Aug 2006, Robert Watson wrote: > >> I'll commit the fix directly to CVS, so you will want to cvsup in about 24 >> hours to pick it up. > > I've committed a possible fix as tcp_subr.c:1.254. This should read tcp_subr.c:1.253. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 16:56: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 EB16016A4E1; Wed, 2 Aug 2006 16:56:05 +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 4499243D67; Wed, 2 Aug 2006 16:56:05 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k72Gu4Zt001280; Wed, 2 Aug 2006 09:56:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k72Gu4Uh001279; Wed, 2 Aug 2006 09:56:04 -0700 (PDT) (envelope-from sgk) Date: Wed, 2 Aug 2006 09:56:04 -0700 From: Steve Kargl To: "Matthew D. Fuller" Message-ID: <20060802165604.GA970@troutmask.apl.washington.edu> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060802144255.GU69505@over-yonder.net> User-Agent: Mutt/1.4.2.2i Cc: Daniel Eischen , freebsd-current@freebsd.org, Andrew Thompson Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 16:56:06 -0000 On Wed, Aug 02, 2006 at 09:42:55AM -0500, Matthew D. Fuller wrote: > On Tue, Aug 01, 2006 at 02:38:03PM -0700 I heard the voice of > Steve Kargl, and lo! it spake thus: > > > > If UPDATING had a proper notice, > > If UPDATING had a notice every time a {library,program} in 7 did > something that wasn't supported by 6 (for various values of 7 and 6), > it would be a very, very long and very boring file. > Sigh. We go through this every time someone bumps libc's version number without bumping the version numbers of all other libraries. There is significant difference bewteen changing libgpib.so version number and changing libc.so version number. Changeing libc's version number should have been noted in UPDATING. The version number of libthr should have been bumped when David Xu committed his change. Last time I checked there were several integers between 2 and INT_MAX. Is there some sort of shortage of integers at freebsd.org that prevents bumping libthr.so.2 to libthr.so.3? -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 17:09: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 5738A16A4DA; Wed, 2 Aug 2006 17:09:23 +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 BD87D43D67; Wed, 2 Aug 2006 17:09:22 +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.7/8.13.7/NETPLEX) with ESMTP id k72H9LOF010220; Wed, 2 Aug 2006 13:09:21 -0400 (EDT) Date: Wed, 2 Aug 2006 13:09:21 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20060802165604.GA970@troutmask.apl.washington.edu> Message-ID: References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> 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, Andrew Thompson , "Matthew D. Fuller" Subject: Re: Where is thr_getscheduler 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: Wed, 02 Aug 2006 17:09:23 -0000 On Wed, 2 Aug 2006, Steve Kargl wrote: > On Wed, Aug 02, 2006 at 09:42:55AM -0500, Matthew D. Fuller wrote: >> On Tue, Aug 01, 2006 at 02:38:03PM -0700 I heard the voice of >> Steve Kargl, and lo! it spake thus: >>> >>> If UPDATING had a proper notice, >> >> If UPDATING had a notice every time a {library,program} in 7 did >> something that wasn't supported by 6 (for various values of 7 and 6), >> it would be a very, very long and very boring file. >> > > Sigh. We go through this every time someone bumps libc's > version number without bumping the version numbers of > all other libraries. There is significant difference > bewteen changing libgpib.so version number and changing > libc.so version number. Changeing libc's version number > should have been noted in UPDATING. > > The version number of libthr should have been bumped > when David Xu committed his change. No, it has nothing to do with that change. There were other changes to libc that would necessitate bumping libpthread and libthr version numbers. If you take a libc.so.6 from 6-stable, you'll note that it wouldn't have worked in -current (under the same circumstances) before the thr_getscheduler() changes. If you look at the -current archives you'll see this problem even with libpthread which doesn't use thr_getscheduler(). > Last time I checked there were several integers between 2 and > INT_MAX. Is there some sort of shortage of integers at > freebsd.org that prevents bumping libthr.so.2 to libthr.so.3? Hold your horses. The libraries are going to be bumped, and this issue is going to be addressed in the near future. This is -current, so expect some problems like this. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 17:25: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 54FD316A4DE; Wed, 2 Aug 2006 17:25:10 +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 3DF5943D69; Wed, 2 Aug 2006 17:25:06 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k72HP5N8005824; Wed, 2 Aug 2006 10:25:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k72HP5Cr005823; Wed, 2 Aug 2006 10:25:05 -0700 (PDT) (envelope-from sgk) Date: Wed, 2 Aug 2006 10:25:05 -0700 From: Steve Kargl To: Daniel Eischen Message-ID: <20060802172505.GA1935@troutmask.apl.washington.edu> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org, Andrew Thompson , "Matthew D. Fuller" Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 17:25:10 -0000 On Wed, Aug 02, 2006 at 01:09:21PM -0400, Daniel Eischen wrote: > > This is -current, so expect some problems like this. I do expect problems with -current such as the soisdisconnected() panic I had last night. Spent a portion of my morning preparing a bug report complete with kgdb output. Fortunately, rwatson appears to have already fixed the problem. Almost everything on a FreeBSD system depends on libc. Bumping its version number without careful coordination of bumping all other version numbers is full of landmines. Falling back of the retort "this is -current expect problesm" just glosses over what appears to be sloppy planning. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 19:48:20 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 DFEFF16A4DA for ; Wed, 2 Aug 2006 19:48:20 +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 9DE7C43D53 for ; Wed, 2 Aug 2006 19:48:20 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id DE01578C1F; Wed, 2 Aug 2006 19:48:17 +0000 (GMT) Date: Wed, 2 Aug 2006 19:48:17 +0000 From: John Birrell To: Tobias Gro?er Message-ID: <20060802194817.GA53062@what-creek.com> References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 19:48:21 -0000 On Wed, Aug 02, 2006 at 04:05:24PM +0200, Tobias Gro?er wrote: > > Unfortunally I am not able to finish the build because it always breaks > in /usr/src/cddl/usr.bin/ctfconvert with this ld-error: > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread Sorry. At the moment the dtrace project has an experimental implementation of threads merged into libc and you need to enable this by adding WITH_LIBC_THREADS=1 to /etc/make.conf. Then it will build. Also, since the KSE code in the kernel doesn't handle signals properly in a many-cpu system, in order to make progress on sun4v, the KSE code has been removed. We really need to try to make it a kernel option so that we can compare the thread implementations. Making KSE a kernel option is very messy, though. Without KSE support in the dtrace kernel, libpthread cannot work. You need to use libthr. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 20:13: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 8F72416A4E5 for ; Wed, 2 Aug 2006 20:13:36 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5309343D58 for ; Wed, 2 Aug 2006 20:13:35 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k72KDYUq009459; Wed, 2 Aug 2006 16:13:34 -0400 (EDT) Date: Wed, 2 Aug 2006 16:13:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Birrell In-Reply-To: <20060802194817.GA53062@what-creek.com> Message-ID: References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> 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, Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 20:13:36 -0000 On Wed, 2 Aug 2006, John Birrell wrote: > On Wed, Aug 02, 2006 at 04:05:24PM +0200, Tobias Gro?er wrote: >> >> Unfortunally I am not able to finish the build because it always breaks >> in /usr/src/cddl/usr.bin/ctfconvert with this ld-error: >> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread > > Sorry. At the moment the dtrace project has an experimental implementation of > threads merged into libc and you need to enable this by adding WITH_LIBC_THREADS=1 > to /etc/make.conf. Then it will build. > > Also, since the KSE code in the kernel doesn't handle signals properly in a > many-cpu system, in order to make progress on sun4v, the KSE code has been > removed. We really need to try to make it a kernel option so that we can compare > the thread implementations. Making KSE a kernel option is very messy, though. KSE doesn't yet work on sparc64, which is why libc_r and libthr are used for that platform. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 20:16:08 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87F1616A4E0 for ; Wed, 2 Aug 2006 20:16:08 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3F1043D53 for ; Wed, 2 Aug 2006 20:16:07 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.4) with ESMTP id k72KFv9K031454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Aug 2006 22:15:57 +0200 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.6/Submit) with ESMTP id k72KFuwc031451 for ; Wed, 2 Aug 2006 22:15:57 +0200 Date: Wed, 2 Aug 2006 22:15:56 +0200 (CEST) From: Goran Gajic To: freebsd-current@mx1.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Wed, 02 Aug 2006 20:39:33 +0000 Cc: Subject: scroll lock pressed during boot related panic on 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: Wed, 02 Aug 2006 20:16:08 -0000 Hi, Some time ago I have reported that when scroll lock is pressed during boot on amd64 box panic occurs (it has to be pressed somwhere after sc0/vga0 kernel message during boot.Also if I use serial console this can't be repeated. Btw if in /boot/device.hints hint.kbdmux.0.disabled is set to 1 this doesn't happen. But, today even after panic for some reason I could type so here is what I've got from ddb: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffffff000000b1 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff8065b026 stack pointer = 0x10:0xffffffff80b3c790 frame pointer = 0x10:0xffffffff80b3c7c0 code segment = base 0x0, limit 0xffffff, type 0x1b = DPL 0, pres 1, long 1, def 32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at sc_cnputc+0x96: testb $0x2,0xb1(%rbx) db> bt Tracing pid 0 tid 0 td 0xfffffffff80935c80 sc_cnputc() at sc_cnputc+0x96 putchar() at putchar+0xc8 kvprintf() at printf+0xe7 device_printf() at device_printf+0x6f ad_attach() at ad_attach+0x298 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 ata_identify() at ata_identify+0xea ata_boot_attach() at ata_boot_attach+0x50 run_interrput_driven_config_books() at run_interrypt_driven_config_books+0x78 mi_startup() at mi_startup+0xd3 btext() at btext+0x2c db> However I couldn't call doadump() since there is no device defined to dump to. Of course: uname -a FreeBSD magarac 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Aug 1 23:44:16 CEST 2006 root@magarac:/usr/src/sys/amd64/compile/GENERIC amd64 Regards, gg. From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 21:07: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 DA37B16A4DA for ; Wed, 2 Aug 2006 21:07:09 +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 5ED3E43D45 for ; Wed, 2 Aug 2006 21:07:09 +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.7/8.13.7/NETPLEX) with ESMTP id k72L78Xx028207; Wed, 2 Aug 2006 17:07:08 -0400 (EDT) Date: Wed, 2 Aug 2006 17:07:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kip Macy In-Reply-To: <20060802135246.J66851@demos.bsdclusters.com> Message-ID: References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> <20060802135246.J66851@demos.bsdclusters.com> 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, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) 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: Wed, 02 Aug 2006 21:07:09 -0000 On Wed, 2 Aug 2006, Kip Macy wrote: > sun4u is a dead architecture. Signals are broken with KSE on a > tightly coupled SMP so sun4v doesn't even have KSE in the tree. On every platform or on sparc64? I am unaware of any signal problems in i386. > Unless someone steps up to fix KSE "will not work" is more correct. Please clarify. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 22:02: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 3772F16A4DD for ; Wed, 2 Aug 2006 22:02:49 +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 C0EE843D45 for ; Wed, 2 Aug 2006 22:02:48 +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.7/8.13.7/NETPLEX) with ESMTP id k72M2lKl016198; Wed, 2 Aug 2006 18:02:47 -0400 (EDT) Date: Wed, 2 Aug 2006 18:02:47 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kip Macy In-Reply-To: <20060802141115.D71770@demos.bsdclusters.com> Message-ID: References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> <20060802135246.J66851@demos.bsdclusters.com> <20060802141115.D71770@demos.bsdclusters.com> 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, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) 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: Wed, 02 Aug 2006 22:02:49 -0000 On Wed, 2 Aug 2006, Kip Macy wrote: > I described it previously. Signals won't always be sent to the right > process, i.e. running a process under GDB the debuggee will sometimes > get the SIGTRAP instead of GDB. When restarting mysql, mysql-server > becomes unkillable. Removing KSE (bike_sched et al.) makes the problem > go away. That sounds more like a bug with gdb/libthread_db. It also doesn't sound like a major bug either, like "signals are broken with KSE" makes it sound. > It is trivial to hit on sun4v. However, I've seen it (or a problem with > similar symptoms) on x86 using NetApp's development simulator which > makes very heavy use of signals. I believe NetApp ended up giving up on > using FreeBSD for running their simulator as this problem made FreeBSD a > non-starter for them. I no longer work for NetApp so I don't have access > to the sources for the simulator any more, so I don't know if bike_sched > fixes that problem for them or not. > > -Kip > > > On Wed, 2 Aug 2006, Daniel Eischen wrote: > >> On Wed, 2 Aug 2006, Kip Macy wrote: >> >>> sun4u is a dead architecture. Signals are broken with KSE on a >>> tightly coupled SMP so sun4v doesn't even have KSE in the tree. >> >> On every platform or on sparc64? I am unaware of any signal >> problems in i386. >> >>> Unless someone steps up to fix KSE "will not work" is more correct. >> >> Please clarify. >> >> -- >> DE >> _______________________________________________ -- DE From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 22:35: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 A64AC16A4E2; Wed, 2 Aug 2006 22:35:57 +0000 (UTC) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos.bsdclusters.com [69.55.225.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A59843D4C; Wed, 2 Aug 2006 22:35:57 +0000 (GMT) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id k72MZvlZ095070; Wed, 2 Aug 2006 15:35:57 -0700 (PDT) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id k72MZuPi095067; Wed, 2 Aug 2006 15:35:56 -0700 (PDT) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 2 Aug 2006 15:35:56 -0700 (PDT) From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Daniel Eischen In-Reply-To: Message-ID: <20060802151129.R79030@demos.bsdclusters.com> References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> <20060802135246.J66851@demos.bsdclusters.com> <20060802141115.D71770@demos.bsdclusters.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 22:35:57 -0000 > That sounds more like a bug with gdb/libthread_db. It also doesn't > sound like a major bug either, like "signals are broken with KSE" > makes it sound. Uhhhmmm no it doesn't. And even if it did, it wouldn't explain why threaded processes become unkillable. In any event removing KSE makes the problem go away. I guess I'll just continue advocating for the removal of KSE after libthr has proven itself. I've been pretty happy with nokse+libthr on my desktop running the dtrace branch, so I think we're getting there. -Kip > > > It is trivial to hit on sun4v. However, I've seen it (or a problem with > > similar symptoms) on x86 using NetApp's development simulator which > > makes very heavy use of signals. I believe NetApp ended up giving up on > > using FreeBSD for running their simulator as this problem made FreeBSD a > > non-starter for them. I no longer work for NetApp so I don't have access > > to the sources for the simulator any more, so I don't know if bike_sched > > fixes that problem for them or not. > > > > -Kip > > > > > > On Wed, 2 Aug 2006, Daniel Eischen wrote: > > > >> On Wed, 2 Aug 2006, Kip Macy wrote: > >> > >>> sun4u is a dead architecture. Signals are broken with KSE on a > >>> tightly coupled SMP so sun4v doesn't even have KSE in the tree. > >> > >> On every platform or on sparc64? I am unaware of any signal > >> problems in i386. > >> > >>> Unless someone steps up to fix KSE "will not work" is more correct. > >> > >> Please clarify. > >> > >> -- > >> DE > >> _______________________________________________ > > -- > DE > _______________________________________________ > 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 Aug 2 21:03: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 A445916A4E1 for ; Wed, 2 Aug 2006 21:03:44 +0000 (UTC) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos.bsdclusters.com [69.55.225.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72AD543D78 for ; Wed, 2 Aug 2006 21:03:28 +0000 (GMT) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id k72L3SlZ069582; Wed, 2 Aug 2006 14:03:28 -0700 (PDT) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id k72L3RQO069579; Wed, 2 Aug 2006 14:03:27 -0700 (PDT) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 2 Aug 2006 14:03:27 -0700 (PDT) From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Daniel Eischen In-Reply-To: Message-ID: <20060802135246.J66851@demos.bsdclusters.com> References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 02 Aug 2006 22:46:12 +0000 Cc: freebsd-current@freebsd.org, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 21:03:44 -0000 sun4u is a dead architecture. Signals are broken with KSE on a tightly coupled SMP so sun4v doesn't even have KSE in the tree. Unless someone steps up to fix KSE "will not work" is more correct. On Wed, 2 Aug 2006, Daniel Eischen wrote: > On Wed, 2 Aug 2006, John Birrell wrote: > > > On Wed, Aug 02, 2006 at 04:05:24PM +0200, Tobias Gro?er wrote: > >> > >> Unfortunally I am not able to finish the build because it always breaks > >> in /usr/src/cddl/usr.bin/ctfconvert with this ld-error: > >> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread > > > > Sorry. At the moment the dtrace project has an experimental implementation of > > threads merged into libc and you need to enable this by adding WITH_LIBC_THREADS=1 > > to /etc/make.conf. Then it will build. > > > > Also, since the KSE code in the kernel doesn't handle signals properly in a > > many-cpu system, in order to make progress on sun4v, the KSE code has been > > removed. We really need to try to make it a kernel option so that we can compare > > the thread implementations. Making KSE a kernel option is very messy, though. > > KSE doesn't yet work on sparc64, which is why libc_r and libthr are > used for that platform. > > -- > DE > _______________________________________________ > 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 Aug 2 21:33: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 E74A816A4DA; Wed, 2 Aug 2006 21:33:49 +0000 (UTC) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos.bsdclusters.com [69.55.225.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9887D43D45; Wed, 2 Aug 2006 21:33:49 +0000 (GMT) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id k72LXnlZ077812; Wed, 2 Aug 2006 14:33:49 -0700 (PDT) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id k72LXn65077809; Wed, 2 Aug 2006 14:33:49 -0700 (PDT) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Wed, 2 Aug 2006 14:33:49 -0700 (PDT) From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Daniel Eischen In-Reply-To: Message-ID: <20060802141115.D71770@demos.bsdclusters.com> References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> <20060802135246.J66851@demos.bsdclusters.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 02 Aug 2006 22:46:20 +0000 Cc: freebsd-current@freebsd.org, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 21:33:50 -0000 I described it previously. Signals won't always be sent to the right process, i.e. running a process under GDB the debuggee will sometimes get the SIGTRAP instead of GDB. When restarting mysql, mysql-server becomes unkillable. Removing KSE (bike_sched et al.) makes the problem go away. It is trivial to hit on sun4v. However, I've seen it (or a problem with similar symptoms) on x86 using NetApp's development simulator which makes very heavy use of signals. I believe NetApp ended up giving up on using FreeBSD for running their simulator as this problem made FreeBSD a non-starter for them. I no longer work for NetApp so I don't have access to the sources for the simulator any more, so I don't know if bike_sched fixes that problem for them or not. -Kip On Wed, 2 Aug 2006, Daniel Eischen wrote: > On Wed, 2 Aug 2006, Kip Macy wrote: > > > sun4u is a dead architecture. Signals are broken with KSE on a > > tightly coupled SMP so sun4v doesn't even have KSE in the tree. > > On every platform or on sparc64? I am unaware of any signal > problems in i386. > > > Unless someone steps up to fix KSE "will not work" is more correct. > > Please clarify. > > -- > DE > _______________________________________________ > 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 Aug 2 22:44: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 07AB916A4E1; Wed, 2 Aug 2006 22:44:49 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 514A343D49; Wed, 2 Aug 2006 22:44:47 +0000 (GMT) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k72MiiaU032478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 15:44:45 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <44D12AC0.90009@sippysoft.com> Date: Wed, 02 Aug 2006 15:44:16 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "current@freebsd.org" , freebsd-ppc@FreeBSD.ORG Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Aug 2006 22:46:30 +0000 Cc: Subject: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 22:44:49 -0000 Hi, Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps core with seg 11. The same csup(8) version compiled on 6.0 works just fine on the same 7-CURRENT kernel. Unfortunately lack of gdb doesn't allow to extract backtrace out of core file. Any ideas? -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:04:07 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 CBC7116A4E5; Wed, 2 Aug 2006 23:04:07 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C14143D46; Wed, 2 Aug 2006 23:04:07 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k72N46WC019080; Wed, 2 Aug 2006 16:04:06 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <44D12AC0.90009@sippysoft.com> References: <44D12AC0.90009@sippysoft.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 2 Aug 2006 16:03:55 -0700 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.2) Cc: "current@freebsd.org" , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:04:07 -0000 On Aug 2, 2006, at 3:44 PM, Maxim Sobolev wrote: > Hi, > > Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) > dumps core with seg 11. The same csup(8) version compiled on 6.0 > works just fine on the same 7-CURRENT kernel. > > Unfortunately lack of gdb doesn't allow to extract backtrace out of > core file. > > Any ideas? I can't say anything about the threading bug, but I can say this: I'm working on gdb-6.5, which involves implementing debugger support for threaded applications other than i386 and amd64. I'd like it to include PowerPC support as well, but that requires some additional work because there's no PowerPC support yet. I could use some help with the ABI details. If the problem of no debugger is addressed, you will be able to look into the threading bug and maybe fix it without much pain... FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:08: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 3EFF516A4DD; Wed, 2 Aug 2006 23:08:12 +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 8E1FC43D55; Wed, 2 Aug 2006 23:08:06 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k72N83d7043050; Wed, 2 Aug 2006 16:08:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k72N83Gt043049; Wed, 2 Aug 2006 16:08:03 -0700 (PDT) (envelope-from sgk) Date: Wed, 2 Aug 2006 16:08:03 -0700 From: Steve Kargl To: Maxim Sobolev Message-ID: <20060802230803.GA32778@troutmask.apl.washington.edu> References: <44D12AC0.90009@sippysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D12AC0.90009@sippysoft.com> User-Agent: Mutt/1.4.2.2i Cc: "current@freebsd.org" , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:08:12 -0000 On Wed, Aug 02, 2006 at 03:44:16PM -0700, Maxim Sobolev wrote: > > Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps > core with seg 11. The same csup(8) version compiled on 6.0 works just > fine on the same 7-CURRENT kernel. > What does ldd show? -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:23: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 5B01116A4E1; Wed, 2 Aug 2006 23:23:18 +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 0DC7743D93; Wed, 2 Aug 2006 23:22:53 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k72NMfwP032947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 16:22:43 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44D133A5.5090301@FreeBSD.org> Date: Wed, 02 Aug 2006 16:22:13 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Steve Kargl References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> In-Reply-To: <20060802230803.GA32778@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:23:18 -0000 Steve Kargl wrote: > On Wed, Aug 02, 2006 at 03:44:16PM -0700, Maxim Sobolev wrote: >> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps >> core with seg 11. The same csup(8) version compiled on 6.0 works just >> fine on the same 7-CURRENT kernel. >> > > What does ldd show? [sobomax@sobomac ~]$ ldd /usr/bin/csup /usr/bin/csup: libcrypto.so.5 => /lib/libcrypto.so.5 (0x2186b000) libz.so.3 => /lib/libz.so.3 (0x219d1000) libpthread.so.2 => /lib/libpthread.so.2 (0x219f4000) libc.so.7 => /lib/libc.so.7 (0x21a2b000) -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:36: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 6281B16A4DF; Wed, 2 Aug 2006 23:36:57 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1B3643D58; Wed, 2 Aug 2006 23:36:56 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id BZW83428 (AUTH peterg@ptree32.com.au); Thu, 3 Aug 2006 09:36:44 +1000 (EST) Message-ID: <44D13736.6000209@freebsd.org> Date: Wed, 02 Aug 2006 16:37:26 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Marcel Moolenaar References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> In-Reply-To: <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Maxim Sobolev , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:36:57 -0000 > I could use some help with the ABI details. Fire away Marcel. The SVR4 ppc abi is at http://www.cloudcaptech.com/MPC555%20Resources/Programming%20Environment/SVR4abippc.pdf later, Peter. From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:48: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 7B53916A4DA; Wed, 2 Aug 2006 23:48:37 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D7943D49; Wed, 2 Aug 2006 23:48:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k72Nma5P019435; Wed, 2 Aug 2006 16:48:36 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <44D13736.6000209@freebsd.org> References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D13736.6000209@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84F5F2D9-F9F9-41DF-A191-B7EEEA6B2C3A@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 2 Aug 2006 16:48:25 -0700 To: Peter Grehan X-Mailer: Apple Mail (2.752.2) Cc: "current@freebsd.org" , Maxim Sobolev , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:48:37 -0000 On Aug 2, 2006, at 4:37 PM, Peter Grehan wrote: >> I could use some help with the ABI details. > > Fire away Marcel. > > The SVR4 ppc abi is at http://www.cloudcaptech.com/MPC555% > 20Resources/Programming%20Environment/SVR4abippc.pdf Thanks for the pointer, I'll take a look at it before asling questions. In general, the biggest gap in my knowledge relates to registers, how the ABI defines their use and how GDB likes to number them. Things that eventually need to be implemented: o KGDB * src/sys/powerpc/include/gdb_machdep.h * src/gnu/usr.bin/gdb/kgdb/trgt_powerpc.c o Threading: * src/lib/libthread_db/arch/powerpc/* -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:57: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 3596A16A4DF; Wed, 2 Aug 2006 23:57:36 +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 17AD743D69; Wed, 2 Aug 2006 23:57:26 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k72NvNlZ033377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 16:57:25 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44D13BC7.8010309@FreeBSD.org> Date: Wed, 02 Aug 2006 16:56:55 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Steve Kargl References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> In-Reply-To: <20060802230803.GA32778@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:57:36 -0000 Steve Kargl wrote: > On Wed, Aug 02, 2006 at 03:44:16PM -0700, Maxim Sobolev wrote: >> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps >> core with seg 11. The same csup(8) version compiled on 6.0 works just >> fine on the same 7-CURRENT kernel. >> > > What does ldd show? Here is the backtrace: Loaded symbols for /libexec/ld-elf.so.1 #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, offset=4294934528) at rtld.c:2663 2663 if (dtv[0] != tls_dtv_generation) { (gdb) bt #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, offset=4294934528) at rtld.c:2663 #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at /usr/src/libexec/rtld-elf/powerpc/reloc.c:577 #2 0x21ad3ef8 in choose_arena () at /usr/src/lib/libc/stdlib/malloc.c:1422 #3 0x21ad8f40 in imalloc (size=480) at /usr/src/lib/libc/stdlib/malloc.c:2662 #4 0x21ada810 in malloc (size=480) at /usr/src/lib/libc/stdlib/malloc.c:3422 #5 0x21a1ba90 in _thr_alloc (curthread=0x1a502e0) at /usr/src/lib/libpthread/thread/thr_kern.c:2369 #6 0x21a021b0 in _pthread_create (thread=0x1ab05a0, attr=0x0, start_routine=0x18109dc , arg=0x1ab0580) at /usr/src/lib/libpthread/thread/thr_create.c:110 #7 0x01810640 in mux_init (m=0x1ab0580) at /usr/src/usr.bin/csup/../../contrib/csup/mux.c:661 #8 0x0180f8b0 in mux_open (sock=3, chan=0x7fffdad8) at /usr/src/usr.bin/csup/../../contrib/csup/mux.c:328 #9 0x018146a4 in proto_mux (config=0x1a118c0) at /usr/src/usr.bin/csup/../../contrib/csup/proto.c:555 #10 0x018148f4 in proto_run (config=0x1a118c0) at /usr/src/usr.bin/csup/../../contrib/csup/proto.c:617 #11 0x0180dddc in main (argc=1, argv=0x7fffdcac) at /usr/src/usr.bin/csup/../../contrib/csup/main.c:314 (gdb) print dtv $1 = (Elf_Addr *) 0x0 (gdb) -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 00:45:52 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 97AE416A4DD for ; Thu, 3 Aug 2006 00:45:52 +0000 (UTC) (envelope-from prvs=julian=363777195@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7139243D46 for ; Thu, 3 Aug 2006 00:45:52 +0000 (GMT) (envelope-from prvs=julian=363777195@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 02 Aug 2006 17:45:52 -0700 Message-ID: <44D1473F.1000204@elischer.org> Date: Wed, 02 Aug 2006 17:45:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 00:45:52 -0000 I haven't tried 7.x yet but has anyone seen the FWD command of ipfw running on 6.1? or anyone know of problems with it that may have been fixed on -current? From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 23:47:22 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 72B0516A4DE; Wed, 2 Aug 2006 23:47:22 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7A2643D58; Wed, 2 Aug 2006 23:47:21 +0000 (GMT) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k72NlIlH033265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 16:47:19 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <44D1396A.8000801@sippysoft.com> Date: Wed, 02 Aug 2006 16:46:50 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Grehan References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D13736.6000209@freebsd.org> In-Reply-To: <44D13736.6000209@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Aug 2006 00:53:56 +0000 Cc: freebsd-ppc@freebsd.org, "current@freebsd.org" , Marcel Moolenaar Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Aug 2006 23:47:22 -0000 Peter Grehan wrote: >> I could use some help with the ABI details. > > Fire away Marcel. > > The SVR4 ppc abi is at > http://www.cloudcaptech.com/MPC555%20Resources/Programming%20Environment/SVR4abippc.pdf I have committed some initial support into devel/gdb6 port. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 01:26:47 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 827F116A4DA for ; Thu, 3 Aug 2006 01:26:47 +0000 (UTC) (envelope-from prvs=julian=363777195@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 555F343D45 for ; Thu, 3 Aug 2006 01:26:47 +0000 (GMT) (envelope-from prvs=julian=363777195@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 02 Aug 2006 18:26:47 -0700 Message-ID: <44D150D6.6010101@elischer.org> Date: Wed, 02 Aug 2006 18:26:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44D1473F.1000204@elischer.org> In-Reply-To: <44D1473F.1000204@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Ignore: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 01:26:47 -0000 Julian Elischer wrote: > I haven't tried 7.x yet but has anyone seen > the FWD command of ipfw running on 6.1? > > or anyone know of problems with it that may have been fixed on -current? Just found the "EXTENDED" option for ipfw fwd. Why we need that is wierd since it just allows it to act as it always used to and it never aused any massive problems that I know of (I committed it originally). personally I consider removing the option and making it default or reversing it and calling it IPFIREWALL_FORWARD_CRIPPLED > _______________________________________________ > 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 Aug 3 03:07: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 DFC5416A4DE; Thu, 3 Aug 2006 03:07:49 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F81143D46; Thu, 3 Aug 2006 03:07:48 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id BZX16024 (AUTH peterg@ptree32.com.au); Thu, 3 Aug 2006 13:07:43 +1000 (EST) Message-ID: <44D168A8.1060201@freebsd.org> Date: Wed, 02 Aug 2006 20:08:24 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Maxim Sobolev References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> In-Reply-To: <44D13BC7.8010309@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Steve Kargl , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 03:07:50 -0000 > #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, > offset=4294934528) at rtld.c:2663 > #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at I think you might want to try point libpthread at libthr with libmap.conf. TLS is known to work for that where I don't think it works for libpthread. later, Peter. From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 03:56: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 4C99416A5B3; Thu, 3 Aug 2006 03:56:05 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 281DF43D5C; Thu, 3 Aug 2006 03:55:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k733tuUp020448; Wed, 2 Aug 2006 20:55:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <44D13BC7.8010309@FreeBSD.org> References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 2 Aug 2006 20:55:44 -0700 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.2) Cc: "current@freebsd.org" , Steve Kargl , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 03:56:05 -0000 On Aug 2, 2006, at 4:56 PM, Maxim Sobolev wrote: > Steve Kargl wrote: >> On Wed, Aug 02, 2006 at 03:44:16PM -0700, Maxim Sobolev wrote: >>> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) >>> dumps core with seg 11. The same csup(8) version compiled on 6.0 >>> works just fine on the same 7-CURRENT kernel. >>> >> What does ldd show? > > Here is the backtrace: > > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, > offset=4294934528) at rtld.c:2663 > 2663 if (dtv[0] != tls_dtv_generation) { > (gdb) bt > #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, > offset=4294934528) at rtld.c:2663 > #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at /usr/src/ > libexec/rtld-elf/powerpc/reloc.c:577 > #2 0x21ad3ef8 in choose_arena () at /usr/src/lib/libc/stdlib/ > malloc.c:1422 > #3 0x21ad8f40 in imalloc (size=480) at /usr/src/lib/libc/stdlib/ > malloc.c:2662 > #4 0x21ada810 in malloc (size=480) at /usr/src/lib/libc/stdlib/ > malloc.c:3422 > #5 0x21a1ba90 in _thr_alloc (curthread=0x1a502e0) at /usr/src/lib/ > libpthread/thread/thr_kern.c:2369 > #6 0x21a021b0 in _pthread_create (thread=0x1ab05a0, attr=0x0, > start_routine=0x18109dc , > arg=0x1ab0580) at /usr/src/lib/libpthread/thread/thr_create.c:110 > #7 0x01810640 in mux_init (m=0x1ab0580) at /usr/src/usr.bin/ > csup/../../contrib/csup/mux.c:661 > #8 0x0180f8b0 in mux_open (sock=3, chan=0x7fffdad8) at /usr/src/ > usr.bin/csup/../../contrib/csup/mux.c:328 > #9 0x018146a4 in proto_mux (config=0x1a118c0) at /usr/src/usr.bin/ > csup/../../contrib/csup/proto.c:555 > #10 0x018148f4 in proto_run (config=0x1a118c0) at /usr/src/usr.bin/ > csup/../../contrib/csup/proto.c:617 > #11 0x0180dddc in main (argc=1, argv=0x7fffdcac) at /usr/src/ > usr.bin/csup/../../contrib/csup/main.c:314 > (gdb) print dtv > $1 = (Elf_Addr *) 0x0 > (gdb) This is probably the same bug that affects ia64. See PR ia64/91846. I think the following should work-around it: Index: malloc.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.132 diff -u -r1.132 malloc.c --- malloc.c 27 Jul 2006 19:09:32 -0000 1.132 +++ malloc.c 3 Aug 2006 03:55:03 -0000 @@ -279,6 +279,7 @@ # define QUANTUM_2POW_MIN 4 # define SIZEOF_PTR 4 # define USE_BRK +# define NO_TLS #endif /* sizeof(int) == (1 << SIZEOF_INT_2POW). */ FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 03:56: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 C74E816A5AB; Thu, 3 Aug 2006 03:56:08 +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 D883743D49; Thu, 3 Aug 2006 03:56:07 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k733u3Xr035953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 20:56:04 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44D173B7.6040302@FreeBSD.org> Date: Wed, 02 Aug 2006 20:55:35 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Peter Grehan References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> <44D168A8.1060201@freebsd.org> In-Reply-To: <44D168A8.1060201@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Steve Kargl , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 03:56:08 -0000 Peter Grehan wrote: >> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, >> offset=4294934528) at rtld.c:2663 >> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at > > I think you might want to try point libpthread at libthr with > libmap.conf. TLS is known to work for that where I don't think it works > for libpthread. But libpthread works in 6.0. What's the difference? -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 03:57: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 598CA16A4E1; Thu, 3 Aug 2006 03:57:11 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0470C43D49; Thu, 3 Aug 2006 03:57:10 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k733vAaE020458; Wed, 2 Aug 2006 20:57:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <44D1396A.8000801@sippysoft.com> References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D13736.6000209@freebsd.org> <44D1396A.8000801@sippysoft.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 2 Aug 2006 20:56:58 -0700 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.2) Cc: "current@freebsd.org" , Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 03:57:11 -0000 On Aug 2, 2006, at 4:46 PM, Maxim Sobolev wrote: > Peter Grehan wrote: >>> I could use some help with the ABI details. >> Fire away Marcel. >> The SVR4 ppc abi is at http://www.cloudcaptech.com/MPC555% >> 20Resources/Programming%20Environment/SVR4abippc.pdf > > I have committed some initial support into devel/gdb6 port. Excellent! I'll take a look at it... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 04:02: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 95FBD16A4DD; Thu, 3 Aug 2006 04:02:34 +0000 (UTC) (envelope-from peterg@ptree32.com.au) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 388B043D46; Thu, 3 Aug 2006 04:02:32 +0000 (GMT) (envelope-from peterg@ptree32.com.au) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id BZX23713 (AUTH peterg@ptree32.com.au); Thu, 3 Aug 2006 14:02:28 +1000 (EST) Message-ID: <44D1757D.4010103@ptree32.com.au> Date: Wed, 02 Aug 2006 21:03:09 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Maxim Sobolev References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> <44D168A8.1060201@freebsd.org> <44D173B7.6040302@FreeBSD.org> In-Reply-To: <44D173B7.6040302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@FreeBSD.org, Steve Kargl , Peter Grehan , "current@freebsd.org" Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 04:02:34 -0000 > But libpthread works in 6.0. What's the difference? jemalloc. From the backtrace, t's doing a TLS allocation, where I'm certain phkmalloc didn't do anything like that. later, Peter. From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 07:12: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 7A78E16A4DA for ; Thu, 3 Aug 2006 07:12:53 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F4D43D46 for ; Thu, 3 Aug 2006 07:12:52 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G8XNs-0000Qt-U7; Thu, 03 Aug 2006 09:12:45 +0200 To: Julian Elischer From: Ian FREISLICH In-Reply-To: Message from Julian Elischer of "Wed, 02 Aug 2006 17:45:51 MST." <44D1473F.1000204@elischer.org> X-Attribution: BOFH Date: Thu, 03 Aug 2006 09:12:44 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 07:12:53 -0000 Julian Elischer wrote: > I haven't tried 7.x yet but has anyone seen > the FWD command of ipfw running on 6.1? > > or anyone know of problems with it that may have been fixed on -current? ipfw fwd ... works like it does in 4, but not like the broken version in 5 and 6. This is precisely (well actually only one of the many reasons) why I'm running -CURRENT on our production firewalls. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 11:06: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 CAD2916A4E8; Thu, 3 Aug 2006 11:06:39 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECC2A43DDB; Thu, 3 Aug 2006 11:05:33 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id AC72E5C1B; Thu, 3 Aug 2006 12:05:30 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 65B5C4054; Thu, 3 Aug 2006 12:05:25 +0100 (BST) Date: Thu, 3 Aug 2006 12:05:25 +0100 From: Josef Karthauser To: Phil Regnauld Message-ID: <20060803110525.GE804@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Phil Regnauld , Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline In-Reply-To: <20060801084053.GE22731@catpipe.net> User-Agent: Mutt/1.5.11 Cc: Chris , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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: Thu, 03 Aug 2006 11:06:39 -0000 --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 01, 2006 at 10:40:53AM +0200, Phil Regnauld wrote: > Josef Karthauser (joe) writes: > > Dear current folk, I'm forwarding this thread from the -net list where I > > asked the question, is it possible to have more than one IP address in a > > jail? The answer is yes, with Pawel's patch. The question here is can > > I pursuade anyone to commit this to head and MFC it please? The > > motivation is simple. I need to run a second SSL web server inside of a > > jail, however that needs another IP address because SSL is incompatible > > with HTTP/1.1. >=20 > We have been using these patches all the way back since 5-CURRENT and > they work very stable for us. I seem to remember that there were > some reservations about the way it was being done, but for that matter > it wouldn't be the first hack in jail (like u_int32_t for the ip_number > in struct jail :) >=20 I no longer have a commit bit, so I can't commit these myself.... :/. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkTR2HQACgkQXVIcjOaxUBYnEwCgsALSsYUym1Kka31eqMyPWYjb vs4AoOp2QbTgKfQ6PX7tuPu511f6rE6H =Bcb8 -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 12:09: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 0B73A16A4E2 for ; Thu, 3 Aug 2006 12:09:39 +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 BA9B843D4C for ; Thu, 3 Aug 2006 12:09:33 +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.7/8.13.7/NETPLEX) with ESMTP id k73C9VHa005806; Thu, 3 Aug 2006 08:09:32 -0400 (EDT) Date: Thu, 3 Aug 2006 08:09:31 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kip Macy In-Reply-To: <20060802151129.R79030@demos.bsdclusters.com> Message-ID: References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> <20060802135246.J66851@demos.bsdclusters.com> <20060802141115.D71770@demos.bsdclusters.com> <20060802151129.R79030@demos.bsdclusters.com> 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, John Birrell , Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) 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: Thu, 03 Aug 2006 12:09:39 -0000 On Wed, 2 Aug 2006, Kip Macy wrote: >> That sounds more like a bug with gdb/libthread_db. It also doesn't >> sound like a major bug either, like "signals are broken with KSE" >> makes it sound. > > Uhhhmmm no it doesn't. And even if it did, it wouldn't explain why > threaded processes become unkillable. In any event removing KSE makes > the problem go away. I've seen unthreaded processes become unkillable too. And again, you can't comment on problems with threading under sparc64 because KSE doesn't work there until "someone steps up" and makes it work. I've been using libpthread under x86 without seeing any of the problems you are describing. I'm not discounting your problems, but your advocating removal of KSE when it's been very functional for a long time is very unjust. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 12:11: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 1A4E916A4DA; Thu, 3 Aug 2006 12:11:13 +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 2B30843D45; Thu, 3 Aug 2006 12:11:12 +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.7/8.13.7/NETPLEX) with ESMTP id k73CBBHB007273; Thu, 3 Aug 2006 08:11:11 -0400 (EDT) Date: Thu, 3 Aug 2006 08:11:11 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Maxim Sobolev In-Reply-To: <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> Message-ID: References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> 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: "current@freebsd.org" , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc 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: Thu, 03 Aug 2006 12:11:13 -0000 On Wed, 2 Aug 2006, Marcel Moolenaar wrote: > > On Aug 2, 2006, at 3:44 PM, Maxim Sobolev wrote: > >> Hi, >> >> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps core >> with seg 11. The same csup(8) version compiled on 6.0 works just fine on >> the same 7-CURRENT kernel. AFAIK, libpthread/KSE isn't quite there yet for powerpc. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 15:29:52 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 E5C8B16A4DA for ; Thu, 3 Aug 2006 15:29:52 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from enterprise.sd73.bc.ca (fax.sd73.bc.ca [142.24.13.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACF5C43D45 for ; Thu, 3 Aug 2006 15:29:52 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by enterprise.sd73.bc.ca (Postfix) with ESMTP id D432D14000862 for ; Thu, 3 Aug 2006 07:19:37 -0700 (PDT) Received: from webmail.sd73.bc.ca (localhost.localdomain [127.0.0.1]) by webmail.sd73.bc.ca (Postfix) with ESMTP id C50B79000616 for ; Thu, 3 Aug 2006 08:29:47 -0700 (PDT) Received: from 192.168.0.10 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Thu, 3 Aug 2006 08:29:47 -0700 (PDT) Message-ID: <59004.192.168.0.10.1154618987.squirrel@webmail.sd73.bc.ca> In-Reply-To: <44D1473F.1000204@elischer.org> References: <44D1473F.1000204@elischer.org> Date: Thu, 3 Aug 2006 08:29:47 -0700 (PDT) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fcash@ocis.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 15:29:53 -0000 On Wed, August 2, 2006 5:45 pm, Julian Elischer wrote: > I haven't tried 7.x yet but has anyone seen > the FWD command of ipfw running on 6.1? > > or anyone know of problems with it that may have been fixed on > -current? It's working fine for us here. Been using the same kernel config file (with the needed changes from 4.x to 5.x to 6.x) and ruleset on our firewalls. They started life as FreeBSD 4.2 boxes, were upgraded through to 4.11, and then re-installed with 6.0 and finally upgraded to 6.1. The kernel config section for our firewall kernels is just: # Firewall options options IPSTEALTH options IPDIVERT options DUMMYNET options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=500 options IPFIREWALL_DEFAULT_TO_ACCEPT We used fwd rules a lot for our VPN links between schools, and a couple of sites use them for trasparent proxying using squid+dansguardian. Haven't had any issues so far. We've never included the _EXTENDED option, nor really seen a need for it (or a problem without it). HTH, ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 17:10:22 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 8164C16A4E2; Thu, 3 Aug 2006 17:10:22 +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 019A243D49; Thu, 3 Aug 2006 17:10:19 +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.7/8.13.7/NETPLEX) with ESMTP id k73HAI0a028988; Thu, 3 Aug 2006 13:10:18 -0400 (EDT) Date: Thu, 3 Aug 2006 13:10:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Maxim Sobolev In-Reply-To: <44D22C7A.8030204@sippysoft.com> Message-ID: References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D22C7A.8030204@sippysoft.com> 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: "current@freebsd.org" , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc 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: Thu, 03 Aug 2006 17:10:22 -0000 On Thu, 3 Aug 2006, Maxim Sobolev wrote: > Daniel Eischen wrote: >> On Wed, 2 Aug 2006, Marcel Moolenaar wrote: >> >>> >>> On Aug 2, 2006, at 3:44 PM, Maxim Sobolev wrote: >>> >>>> Hi, >>>> >>>> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps >>>> core with seg 11. The same csup(8) version compiled on 6.0 works just >>>> fine on the same 7-CURRENT kernel. >> >> AFAIK, libpthread/KSE isn't quite there yet for powerpc. > > Do you have any idea about what's wrong with it? By the way, the same problem > affects ia64 too (ia64/91846) and it has been working in 6.0 just file. Looks > like it has something to do with the thread-local storage. No, I've no idea. Nothing's changed that I know of. I'm surprised that it (powerpc libpthread) works! I know some supporting MD bits were added to libpthread but never knew that they actually worked :) Has the compiler changed recently? -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 17:04: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 9FC0416A4DE; Thu, 3 Aug 2006 17:04:31 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A6F643D46; Thu, 3 Aug 2006 17:04:31 +0000 (GMT) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.56] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k73H4PEJ045006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Aug 2006 10:04:27 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <44D22C7A.8030204@sippysoft.com> Date: Thu, 03 Aug 2006 10:03:54 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Daniel Eischen References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Aug 2006 18:04:54 +0000 Cc: "current@freebsd.org" , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 17:04:31 -0000 Daniel Eischen wrote: > On Wed, 2 Aug 2006, Marcel Moolenaar wrote: > >> >> On Aug 2, 2006, at 3:44 PM, Maxim Sobolev wrote: >> >>> Hi, >>> >>> Apparently threading is b0rken on the FreeBSD/powerpc - csup(8) dumps >>> core with seg 11. The same csup(8) version compiled on 6.0 works just >>> fine on the same 7-CURRENT kernel. > > AFAIK, libpthread/KSE isn't quite there yet for powerpc. Do you have any idea about what's wrong with it? By the way, the same problem affects ia64 too (ia64/91846) and it has been working in 6.0 just file. Looks like it has something to do with the thread-local storage. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 18:32:40 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 A4DD816A4EF; Thu, 3 Aug 2006 18:32:40 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA1043D58; Thu, 3 Aug 2006 18:32:38 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id BZY44875 (AUTH peterg@ptree32.com.au); Fri, 4 Aug 2006 04:32:33 +1000 (EST) Message-ID: <44D2416A.3070806@freebsd.org> Date: Thu, 03 Aug 2006 11:33:14 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Daniel Eischen References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D22C7A.8030204@sippysoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Maxim Sobolev , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 18:32:40 -0000 > No, I've no idea. Nothing's changed that I know of. I'm surprised > that it (powerpc libpthread) works! I know some supporting MD bits > were added to libpthread but never knew that they actually worked :) It only works in system scope. In theory it could work in process scope, though there's no simple way to determine if floating point regs have been used by another thread so you have to unconditionally context-switch fp state. I did a limited amount of testing, mostly with apps and the Sun 'ping-pong' thread test. I think Suleiman also ran up a bunch of larger apps with it (e.g. apache-threads). But that was in the 6.0 timeframe, and I've not seriously run up PPC for a few months now, certainly not since jemalloc went in. > Has the compiler changed recently? Nope, still at 3.4.4. later, Peter. From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 19:03:47 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 9211316A4DF; Thu, 3 Aug 2006 19:03:47 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB5443D62; Thu, 3 Aug 2006 19:03:46 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.250.2] (80-219-8-155.dclient.hispeed.ch [80.219.8.155]) by elvis.mu.org (Postfix) with ESMTP id A48C21A3C19; Thu, 3 Aug 2006 12:03:45 -0700 (PDT) Message-ID: <44D24886.1090500@FreeBSD.org> Date: Thu, 03 Aug 2006 21:03:34 +0200 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Grehan References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D22C7A.8030204@sippysoft.com> <44D2416A.3070806@freebsd.org> In-Reply-To: <44D2416A.3070806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , "current@freebsd.org" , Maxim Sobolev , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 19:03:47 -0000 Peter Grehan wrote: >> No, I've no idea. Nothing's changed that I know of. I'm surprised >> that it (powerpc libpthread) works! I know some supporting MD bits >> were added to libpthread but never knew that they actually worked :) > > > It only works in system scope. In theory it could work in process > scope, though there's no simple way to determine if floating point regs > have been used by another thread so you have to unconditionally > context-switch fp state. > > I did a limited amount of testing, mostly with apps and the Sun > 'ping-pong' thread test. I think Suleiman also ran up a bunch of larger > apps with it (e.g. apache-threads). I believe I only tried apache-threads with libthr. In fact, I don't think I've ever even used libpthread on powerpc.. :-( -- Suleiman From owner-freebsd-current@FreeBSD.ORG Thu Aug 3 19:46: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 7541C16A4DD; Thu, 3 Aug 2006 19:46:08 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01DB143D5A; Thu, 3 Aug 2006 19:46:06 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id BZY57158 (AUTH peterg@ptree32.com.au); Fri, 4 Aug 2006 05:46:04 +1000 (EST) Message-ID: <44D252A5.3090208@freebsd.org> Date: Thu, 03 Aug 2006 12:46:45 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Suleiman Souhlal References: <44D12AC0.90009@sippysoft.com> <0C6ADBC1-E3DF-47D1-AA77-EA9BD14E059F@xcllnt.net> <44D22C7A.8030204@sippysoft.com> <44D2416A.3070806@freebsd.org> <44D24886.1090500@FreeBSD.org> In-Reply-To: <44D24886.1090500@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , "current@freebsd.org" , Maxim Sobolev , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Aug 2006 19:46:08 -0000 > I believe I only tried apache-threads with libthr. Oh well, libpthread has had less coverage than I thought. > In fact, I don't think I've ever even used libpthread on powerpc.. :-( Maybe unintentionally :) later, Peter. From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 02:47: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 142C316A4DE; Fri, 4 Aug 2006 02:47:26 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95F7C43D45; Fri, 4 Aug 2006 02:47:25 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-03.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k742lNpu023612; Thu, 3 Aug 2006 22:47:23 -0400 (EDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.6/8.13.6) with ESMTP id k742lMIk088842; Thu, 3 Aug 2006 22:47:22 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Thu, 3 Aug 2006 22:47:22 -0400 (EDT) From: Wesley Morgan To: Maxim Sobolev In-Reply-To: <44D173B7.6040302@FreeBSD.org> Message-ID: <20060803224133.R87008@volatile.chemikals.org> References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> <44D168A8.1060201@freebsd.org> <44D173B7.6040302@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Steve Kargl , "current@freebsd.org" , Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 02:47:26 -0000 On Wed, 2 Aug 2006, Maxim Sobolev wrote: > Peter Grehan wrote: >>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, >>> offset=4294934528) at rtld.c:2663 >>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at >> >> I think you might want to try point libpthread at libthr with libmap.conf. >> TLS is known to work for that where I don't think it works for libpthread. > > But libpthread works in 6.0. What's the difference? > > -Maxim FWIW, recently csup stopped working for me in -current on i386. It fails when checking the errno set after calling access() to check if a file exists: Updater failed: Cannot create directories leading to "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0 According to gdb, errno is being set correctly but changes almost immediately back to zero. Not sure how/why, and I'm not sure that I'm even using gdb correctly for threaded applications. Switching to libthr with libmap.conf results in the same error. I swear that it had something to do with turning on symbol versioning, but attempting to turn it back off was not a fun experience and didn't have the patience to see it through. -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 05:02: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 7767016A4DF; Fri, 4 Aug 2006 05:02:47 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D642343D45; Fri, 4 Aug 2006 05:02:46 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (lsv284iazebsoyre@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k7452jEW067621; Thu, 3 Aug 2006 22:02:46 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k7452hpU067620; Thu, 3 Aug 2006 22:02:43 -0700 (PDT) (envelope-from jmg) Date: Thu, 3 Aug 2006 22:02:43 -0700 From: John-Mark Gurney To: Steve Kargl Message-ID: <20060804050242.GC58082@funkthat.com> Mail-Followup-To: Steve Kargl , Daniel Eischen , freebsd-current@freebsd.org, Andrew Thompson , "Matthew D. Fuller" References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060802172505.GA1935@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Daniel Eischen , freebsd-current@freebsd.org, "Matthew D. Fuller" , Andrew Thompson Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 05:02:47 -0000 Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: > Almost everything on a FreeBSD system depends on libc. Bumping > its version number without careful coordination of bumping all > other version numbers is full of landmines. Falling back of the > retort "this is -current expect problesm" just glosses over what > appears to be sloppy planning. Ummm.. don't we have have symbol versioning? isn't this exactly what symbol versioning is for? I haven't been following this particular discussion, but I thought now that we have symbol versioning in the tree that we never have to bump the numbers? or is this failure to have a proper document to tell someone what to do when they change the API and provide the correct hooks for the new versions? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 08:20: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 E0F8F16A4DD; Fri, 4 Aug 2006 08:20:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FDA543D49; Fri, 4 Aug 2006 08:20:57 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k748P9U3057410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 11:25:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k748KqtP038057; Fri, 4 Aug 2006 11:20:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k748Ko5D038056; Fri, 4 Aug 2006 11:20:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Aug 2006 11:20:50 +0300 From: Kostik Belousov To: Steve Kargl , Daniel Eischen , freebsd-current@freebsd.org, Andrew Thompson , "Matthew D. Fuller" , kan@freebsd.org Message-ID: <20060804082050.GE59809@deviant.kiev.zoral.com.ua> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VMt1DrMGOVs3KQwf" Content-Disposition: inline In-Reply-To: <20060804050242.GC58082@funkthat.com> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 08:20:59 -0000 --VMt1DrMGOVs3KQwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 03, 2006 at 10:02:43PM -0700, John-Mark Gurney wrote: > Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: > > Almost everything on a FreeBSD system depends on libc. Bumping > > its version number without careful coordination of bumping all > > other version numbers is full of landmines. Falling back of the > > retort "this is -current expect problesm" just glosses over what > > appears to be sloppy planning.=20 >=20 > Ummm.. don't we have have symbol versioning? isn't this exactly > what symbol versioning is for? I haven't been following this > particular discussion, but I thought now that we have symbol versioning > in the tree that we never have to bump the numbers? or is this failure > to have a proper document to tell someone what to do when they change > the API and provide the correct hooks for the new versions? The situation on the problematic machine is follows: /lib contains libc.so.7, libc.so.6 and libthr.so.2 (version number for libthr is not bumped still). libc.so.7 and libpthread.so.2 contain versioned symbols, libc.so.6 is not versioned. Old build of the application linked against libc.so.6 and libthr.so.2. References to symbols in libthr.so.2 are satisfied by default version of the symbols.=20 Missing are two things: 1. libpthread/libthr are still not linked against libc (as well as most shared libraries). Correspondingly, version information for referenced libc symbols is absent in the shared libraries. 2. check for presence of the required version in the depended libraries is absent too, IMHO. Given these two issues are resolved, libthr.so.2 (and libpthread.so.2) references to libc would be unsatisfied with different diagnostic. I added kan@ to the mail loop, but he seems to be unreacheable for some time now. --VMt1DrMGOVs3KQwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE0wNgC3+MBN1Mb4gRAgqeAKCfIODC2cR9sXqkDzJwF6skB/ay6ACfZB/X IbcSGs/saBrqv6C3kn26gDY= =Vd28 -----END PGP SIGNATURE----- --VMt1DrMGOVs3KQwf-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 08:29: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 4379516A4DA; Fri, 4 Aug 2006 08:29:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38A2843D45; Fri, 4 Aug 2006 08:29:26 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k748Xck3057577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 11:33:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k748TLmH038332; Fri, 4 Aug 2006 11:29:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k748TKBm038331; Fri, 4 Aug 2006 11:29:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Aug 2006 11:29:20 +0300 From: Kostik Belousov To: Steve Kargl , Daniel Eischen , freebsd-current@freebsd.org, Andrew Thompson , "Matthew D. Fuller" , kan@freebsd.org Message-ID: <20060804082920.GF59809@deviant.kiev.zoral.com.ua> References: <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> <20060804082050.GE59809@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <20060804082050.GE59809@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 08:29:27 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 04, 2006 at 11:20:50AM +0300, Kostik Belousov wrote: > 2. check for presence of the required version in the > depended libraries is absent too, IMHO. I am mistaken, this code is present in rtld. --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE0wVgC3+MBN1Mb4gRAoRAAJ4gVHLCasBtNgtBLTM8+5FsrL8yrQCgwJTL Riyh8a6x9A9jPDvnz9ixUEs= =A2tl -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 10:12:04 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 1684116A4DA for ; Fri, 4 Aug 2006 10:12:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B17143D45 for ; Fri, 4 Aug 2006 10:12:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k74AAsOk035086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 14:10:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k74AAr8W035085; Fri, 4 Aug 2006 14:10:53 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 4 Aug 2006 14:10:52 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20060804101052.GW96644@FreeBSD.org> References: <44D1473F.1000204@elischer.org> <44D150D6.6010101@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <44D150D6.6010101@elischer.org> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: Ignore: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 10:12:04 -0000 On Wed, Aug 02, 2006 at 06:26:46PM -0700, Julian Elischer wrote: J> >I haven't tried 7.x yet but has anyone seen J> >the FWD command of ipfw running on 6.1? J> > J> >or anyone know of problems with it that may have been fixed on -current? J> J> Just found the "EXTENDED" option for ipfw fwd. J> J> Why we need that is wierd since it just allows it to act as it always J> used to and it never J> aused any massive problems that I know of (I committed it originally). J> personally I consider removing the option and making it default or J> reversing it and J> calling it J> J> IPFIREWALL_FORWARD_CRIPPLED I'm suprised that you have noticed it only now. When Andre has introduced this option that turns on a functionality that was present always before, I was quite angry but everyone ignored me. This even went to release notes as "new feature". -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 12:58: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 164ED16A4DE; Fri, 4 Aug 2006 12:58:01 +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 46BDE43D7F; Fri, 4 Aug 2006 12:57:53 +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.7/8.13.7/NETPLEX) with ESMTP id k74CvqhX020878; Fri, 4 Aug 2006 08:57:52 -0400 (EDT) Date: Fri, 4 Aug 2006 08:57:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John-Mark Gurney In-Reply-To: <20060804050242.GC58082@funkthat.com> Message-ID: References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> 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: "Matthew D. Fuller" , freebsd-current@freebsd.org, Andrew Thompson , Steve Kargl Subject: Re: Where is thr_getscheduler 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, 04 Aug 2006 12:58:01 -0000 On Thu, 3 Aug 2006, John-Mark Gurney wrote: > Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: >> Almost everything on a FreeBSD system depends on libc. Bumping >> its version number without careful coordination of bumping all >> other version numbers is full of landmines. Falling back of the >> retort "this is -current expect problesm" just glosses over what >> appears to be sloppy planning. > > Ummm.. don't we have have symbol versioning? isn't this exactly > what symbol versioning is for? I haven't been following this > particular discussion, but I thought now that we have symbol versioning > in the tree that we never have to bump the numbers? or is this failure > to have a proper document to tell someone what to do when they change > the API and provide the correct hooks for the new versions? We have symbol versioning but it isn't enabled by default yet. We're waiting for the library versions to be bumped before enabling it. We can't support old non-symbol-versioned ABIs (e.g. libc.so.6) in a symbol-versioned library so we need to bump the library versions before enabling it. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 14:37: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 E58A416A4DA; Fri, 4 Aug 2006 14:37:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2474E43D49; Fri, 4 Aug 2006 14:37:39 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k74EfwBe068087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 17:41:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k74EbYNN046494; Fri, 4 Aug 2006 17:37:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k74EbWgF046493; Fri, 4 Aug 2006 17:37:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Aug 2006 17:37:32 +0300 From: Kostik Belousov To: Daniel Eischen Message-ID: <20060804143732.GG59809@deviant.kiev.zoral.com.ua> References: <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IvGM3kKqwtniy32b" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: John-Mark Gurney , freebsd-current@freebsd.org, Steve Kargl , Andrew Thompson , "Matthew D. Fuller" Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 14:37:41 -0000 --IvGM3kKqwtniy32b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 04, 2006 at 08:57:52AM -0400, Daniel Eischen wrote: > On Thu, 3 Aug 2006, John-Mark Gurney wrote: >=20 > >Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: > >>Almost everything on a FreeBSD system depends on libc. Bumping > >>its version number without careful coordination of bumping all > >>other version numbers is full of landmines. Falling back of the > >>retort "this is -current expect problesm" just glosses over what > >>appears to be sloppy planning. > > > >Ummm.. don't we have have symbol versioning? isn't this exactly > >what symbol versioning is for? I haven't been following this > >particular discussion, but I thought now that we have symbol versioning > >in the tree that we never have to bump the numbers? or is this failure > >to have a proper document to tell someone what to do when they change > >the API and provide the correct hooks for the new versions? >=20 > We have symbol versioning but it isn't enabled by default > yet. We're waiting for the library versions to be bumped > before enabling it. We can't support old non-symbol-versioned > ABIs (e.g. libc.so.6) in a symbol-versioned library so we > need to bump the library versions before enabling it. Hmm, yes, libc versioning is disabled. I looked at the libpthread/libthr. Then, why versioning for threaded libraries is on ? BTW, as far as I know, there is technical possibility to declare the "unspecified" version for the symbol (like .symver XXX_old,XXX@ ), but I agree that deciding when to do that when libc.so.7 already broke the ABI in unknown locations is too hard. --IvGM3kKqwtniy32b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE01usC3+MBN1Mb4gRAujmAJ4wPw1b4KkeKjuqAioK9sL3X2a1cwCdGZXr TDZlJvz6ViLrxDobSHLE/Lw= =LVDq -----END PGP SIGNATURE----- --IvGM3kKqwtniy32b-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 14:38: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 468B216A538; Fri, 4 Aug 2006 14:38:38 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86E5943D5D; Fri, 4 Aug 2006 14:38:37 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.6/8.13.6) with ESMTP id k74EcUEc054325; Fri, 4 Aug 2006 18:38:30 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 4 Aug 2006 18:38:30 +0400 (MSD) From: Dmitry Morozovsky To: Josef Karthauser , Pawel Jakub Dawidek In-Reply-To: <20060803110525.GE804@genius.tao.org.uk> Message-ID: <20060804183146.N15526@woozle.rinet.ru> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Fri, 04 Aug 2006 18:38:30 +0400 (MSD) Cc: Chris , Phil Regnauld , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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: Fri, 04 Aug 2006 14:38:38 -0000 On Thu, 3 Aug 2006, Josef Karthauser wrote: JK> > > Dear current folk, I'm forwarding this thread from the -net list where I JK> > > asked the question, is it possible to have more than one IP address in a JK> > > jail? The answer is yes, with Pawel's patch. The question here is can JK> > > I pursuade anyone to commit this to head and MFC it please? The JK> > > motivation is simple. I need to run a second SSL web server inside of a JK> > > jail, however that needs another IP address because SSL is incompatible JK> > > with HTTP/1.1. JK> > JK> > We have been using these patches all the way back since 5-CURRENT and JK> > they work very stable for us. I seem to remember that there were JK> > some reservations about the way it was being done, but for that matter JK> > it wouldn't be the first hack in jail (like u_int32_t for the ip_number JK> > in struct jail :) JK> I no longer have a commit bit, so I can't commit these myself.... :/. I suppose pinging pjd@ did not work? ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 15:35: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 5EF8F16A4E0; Fri, 4 Aug 2006 15:35:55 +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 8850043D45; Fri, 4 Aug 2006 15:35:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k74FZnG2003112; Fri, 4 Aug 2006 11:35:52 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, John-Mark Gurney Date: Fri, 4 Aug 2006 11:08:55 -0400 User-Agent: KMail/1.9.1 References: <20060801204501.GA19647@troutmask.apl.washington.edu> <20060802172505.GA1935@troutmask.apl.washington.edu> <20060804050242.GC58082@funkthat.com> In-Reply-To: <20060804050242.GC58082@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608041108.56969.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Aug 2006 11:35:53 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 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: Daniel Eischen , Andrew Thompson , "Matthew D. Fuller" , Steve Kargl Subject: Re: Where is thr_getscheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 15:35:55 -0000 On Friday 04 August 2006 01:02, John-Mark Gurney wrote: > Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700: > > Almost everything on a FreeBSD system depends on libc. Bumping > > its version number without careful coordination of bumping all > > other version numbers is full of landmines. Falling back of the > > retort "this is -current expect problesm" just glosses over what > > appears to be sloppy planning. > > Ummm.. don't we have have symbol versioning? isn't this exactly > what symbol versioning is for? I haven't been following this > particular discussion, but I thought now that we have symbol versioning > in the tree that we never have to bump the numbers? or is this failure > to have a proper document to tell someone what to do when they change > the API and provide the correct hooks for the new versions? 1) It's not on by default. 2) Once it is turned on by default, we will have to do one last bump to bootstrap into using symbol versioning for future ABI changes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 15:00:58 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 631A516A4DE; Fri, 4 Aug 2006 15:00:58 +0000 (UTC) (envelope-from regnauld@macbook.catpipe.net) Received: from macbook.catpipe.net (flow.catpipe.net [195.249.214.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E717F43D46; Fri, 4 Aug 2006 15:00:57 +0000 (GMT) (envelope-from regnauld@macbook.catpipe.net) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 544CB135502; Fri, 4 Aug 2006 17:00:58 +0200 (CEST) Date: Fri, 4 Aug 2006 17:00:58 +0200 From: Phil Regnauld To: Dmitry Morozovsky Message-ID: <20060804150057.GP29827@catpipe.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> <20060804183146.N15526@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060804183146.N15526@woozle.rinet.ru> X-Operating-System: Darwin 8.7.1 i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Mailman-Approved-At: Fri, 04 Aug 2006 17:38:02 +0000 Cc: Josef Karthauser , Chris , freebsd-current@freebsd.org, Pawel Jakub Dawidek , freebsd-net@freebsd.org Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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: Fri, 04 Aug 2006 15:00:58 -0000 Dmitry Morozovsky (marck) writes: > > I suppose pinging pjd@ did not work? ;) Good question -- why did Pawel not commit them himself if he could ? :) Phil From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 18:02: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 C365E16A4E1 for ; Fri, 4 Aug 2006 18:02:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C759343D46 for ; Fri, 4 Aug 2006 18:02:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 13570 invoked from network); 4 Aug 2006 17:53:38 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2006 17:53:38 -0000 Message-ID: <44D38BB5.4080009@freebsd.org> Date: Fri, 04 Aug 2006 20:02:29 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Gleb Smirnoff References: <44D1473F.1000204@elischer.org> <44D150D6.6010101@elischer.org> <20060804101052.GW96644@FreeBSD.org> In-Reply-To: <20060804101052.GW96644@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , current@FreeBSD.org Subject: Re: Ignore: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 18:02:31 -0000 Gleb Smirnoff wrote: > On Wed, Aug 02, 2006 at 06:26:46PM -0700, Julian Elischer wrote: > J> >I haven't tried 7.x yet but has anyone seen > J> >the FWD command of ipfw running on 6.1? > J> > > J> >or anyone know of problems with it that may have been fixed on -current? > J> > J> Just found the "EXTENDED" option for ipfw fwd. > J> > J> Why we need that is wierd since it just allows it to act as it always > J> used to and it never > J> aused any massive problems that I know of (I committed it originally). > J> personally I consider removing the option and making it default or > J> reversing it and > J> calling it > J> > J> IPFIREWALL_FORWARD_CRIPPLED > > I'm suprised that you have noticed it only now. When Andre has introduced > this option that turns on a functionality that was present always before, > I was quite angry but everyone ignored me. This even went to release notes > as "new feature". The reason I did it this way was to prevent way too easy foot shooting by redirecting too much traffic somewhere else and killing the reachability of the host itself of other hosts on directly connected networks. Yes, the two level approach has some drawbacks but also makes people much more aware of what they are doing by having to explicitly specify the second kernel option. To enable ipfirewall forwarding people have to compile their own kernel anyway, having them specify the second additional option is not too much of a burden. Although I agree that for experienced people it is some additional work to enter the two dozen characters. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 18:16: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 BAB5B16A4DE; Fri, 4 Aug 2006 18:16:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C92943D72; Fri, 4 Aug 2006 18:16:35 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k74IG9tW000854 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 20:16:20 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <44D38BB5.4080009@freebsd.org> References: <44D1473F.1000204@elischer.org> <44D150D6.6010101@elischer.org> <20060804101052.GW96644@FreeBSD.org> <44D38BB5.4080009@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 4 Aug 2006 20:16:07 +0200 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) Cc: Gleb Smirnoff , Julian Elischer , current@freebsd.org Subject: Re: Ignore: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 18:16:36 -0000 Am 04.08.2006 um 20:02 schrieb Andre Oppermann: > Gleb Smirnoff wrote: >> On Wed, Aug 02, 2006 at 06:26:46PM -0700, Julian Elischer wrote: >> J> >I haven't tried 7.x yet but has anyone seen >> J> >the FWD command of ipfw running on 6.1? >> J> > >> J> >or anyone know of problems with it that may have been fixed on >> -current? >> J> J> Just found the "EXTENDED" option for ipfw fwd. >> J> J> Why we need that is wierd since it just allows it to act as >> it always J> used to and it never >> J> aused any massive problems that I know of (I committed it >> originally). >> J> personally I consider removing the option and making it default >> or J> reversing it and >> J> calling it >> J> J> IPFIREWALL_FORWARD_CRIPPLED >> I'm suprised that you have noticed it only now. When Andre has >> introduced >> this option that turns on a functionality that was present always >> before, >> I was quite angry but everyone ignored me. This even went to >> release notes >> as "new feature". > > The reason I did it this way was to prevent way too easy foot > shooting by > redirecting too much traffic somewhere else and killing the > reachability > of the host itself of other hosts on directly connected networks. > Yes, the > two level approach has some drawbacks but also makes people much > more aware > of what they are doing by having to explicitly specify the second > kernel > option. To enable ipfirewall forwarding people have to compile > their own > kernel anyway, having them specify the second additional option is > not too > much of a burden. I couldn't find a good description what functionality IPFIREWALL_FORWARD_EXTENDED actually enables, besides the one half- sentence in ipfw(8): [...] With the additional option options IPFIREWALL_FORWARD_EXTENDED all safeguards are removed and it also makes it possible to redirect packets destined to locally configured IP addresses. Removing "all safeguards" sounds like my machine is going to burn up if I enable this. And it turns out (at least in RELENG_5) that you need IPFIREWALL_FORWARD_EXTENDED also if you want to forward packets that *originate* at the local host. It might help future users to clarify under which circumstances the option is needed, and which potential feet they might shoot... Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 19:55: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 64DC716A4DE; Fri, 4 Aug 2006 19:55:50 +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 08AD643D45; Fri, 4 Aug 2006 19:55:50 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id D4BC05E4906; Fri, 4 Aug 2006 12:55:49 -0700 (PDT) Received: from [192.168.168.201] (coeur_dalene_cuda1_id-eacb02-00-crdlid-70-36-10-195.losaca.adelphia.net [70.36.10.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 2CFE85E48C9; Fri, 4 Aug 2006 12:55:48 -0700 (PDT) Message-ID: <44D3A642.1000905@FreeBSD.org> Date: Fri, 04 Aug 2006 12:55:46 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.5 (X11/20060726) MIME-Version: 1.0 To: Peter Grehan References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> <44D168A8.1060201@freebsd.org> <44D173B7.6040302@FreeBSD.org> <44D1757D.4010103@ptree32.com.au> In-Reply-To: <44D1757D.4010103@ptree32.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on lh.synack.net X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=RCVD_IN_SORBS_DUL autolearn=no version=3.0.6 Cc: Maxim Sobolev , "current@freebsd.org" , Peter Grehan , Steve Kargl , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 19:55:50 -0000 Peter Grehan wrote: >> But libpthread works in 6.0. What's the difference? > > jemalloc. From the backtrace, t's doing a TLS allocation, where I'm > certain phkmalloc didn't do anything like that. Indeed, jemalloc does add a dependency on TLS for PIC versions, though it can be configured to run (more slowly) without TLS, as Marcel pointed out. This appears to be a bug in the TLS implementation, rather than in jemalloc; the appropriate fix is to make TLS work. Jason From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 20:02: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 4750E16A536; Fri, 4 Aug 2006 20:02:29 +0000 (UTC) (envelope-from prvs=julian=3646b5a3c@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C528D43D46; Fri, 4 Aug 2006 20:02:28 +0000 (GMT) (envelope-from prvs=julian=3646b5a3c@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 04 Aug 2006 13:02:26 -0700 Message-ID: <44D3A7D1.2060607@elischer.org> Date: Fri, 04 Aug 2006 13:02:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <44D1473F.1000204@elischer.org> <44D150D6.6010101@elischer.org> <20060804101052.GW96644@FreeBSD.org> <44D38BB5.4080009@freebsd.org> In-Reply-To: <44D38BB5.4080009@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , current@freebsd.org Subject: Re: Ignore: Re: ipfw output FWD broken on 6.1 and newer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 20:02:29 -0000 Andre Oppermann wrote: > Gleb Smirnoff wrote: > >> On Wed, Aug 02, 2006 at 06:26:46PM -0700, Julian Elischer wrote: >> J> >I haven't tried 7.x yet but has anyone seen >> J> >the FWD command of ipfw running on 6.1? >> J> > >> J> >or anyone know of problems with it that may have been fixed on >> -current? >> J> J> Just found the "EXTENDED" option for ipfw fwd. >> J> J> Why we need that is wierd since it just allows it to act as it >> always J> used to and it never >> J> aused any massive problems that I know of (I committed it >> originally). >> J> personally I consider removing the option and making it default or >> J> reversing it and >> J> calling it >> J> J> IPFIREWALL_FORWARD_CRIPPLED >> >> I'm suprised that you have noticed it only now. When Andre has >> introduced >> this option that turns on a functionality that was present always >> before, >> I was quite angry but everyone ignored me. This even went to release >> notes >> as "new feature". > > > The reason I did it this way was to prevent way too easy foot shooting by > redirecting too much traffic somewhere else and killing the reachability > of the host itself of other hosts on directly connected networks. > Yes, the > two level approach has some drawbacks but also makes people much more > aware > of what they are doing by having to explicitly specify the second kernel > option. To enable ipfirewall forwarding people have to compile their own > kernel anyway, having them specify the second additional option is not > too > much of a burden. Although I agree that for experienced people it is > some > additional work to enter the two dozen characters. > Andre, I committer the original fwd code. I do not thnk that it is any more danger ous eot do this than to block yourself off with the firewall in any other way. If you don't mind I plan to remove that option and restore the original functionality as default. From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 20:39:03 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 EC5C816A4DA; Fri, 4 Aug 2006 20:39:03 +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 71D0743D49; Fri, 4 Aug 2006 20:39:02 +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 B682C1FFDDC; Fri, 4 Aug 2006 22:39:00 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id C3F981FFACC; Fri, 4 Aug 2006 22:38:56 +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 48FAB4448D6; Fri, 4 Aug 2006 20:38:34 +0000 (UTC) Date: Fri, 4 Aug 2006 20:38:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <20060804150057.GP29827@catpipe.net> Message-ID: <20060804203052.D26932@maildrop.int.zabbadoz.net> References: <20060628103238.GA815@genius.tao.org.uk> <20060628103949.GJ2005@catpipe.net> <3aaaa3a0606281940k63c77ebfga84a854b2cd4ed84@mail.gmail.com> <20060801084156.GD3440@genius.tao.org.uk> <20060801084053.GE22731@catpipe.net> <20060803110525.GE804@genius.tao.org.uk> <20060804183146.N15526@woozle.rinet.ru> <20060804150057.GP29827@catpipe.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 net mailing list Subject: Re: Can I pursuade someone to commit this patch? (Re: Multiple IP addresses in a 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: Fri, 04 Aug 2006 20:39:04 -0000 On Fri, 4 Aug 2006, Phil Regnauld wrote: > Dmitry Morozovsky (marck) writes: >> >> I suppose pinging pjd@ did not work? ;) > > Good question -- why did Pawel not commit them himself if he could ? :) quoting my last status report http://www.freebsd.org/news/status/report-apr-2006-jun-2006.html#Multi-IP-v4/v6-jails "As an intermediate step until FreeBSD will have full network stack virtualisation this work shall provide support for multi-IP IPv4/v6 jails. .... This is not considered to be the right thing todo so do not ask for official support or if this will be committed to the FreeBSD source repository. ... " I guess pjd was/is thinking about the same as I do - Pawel correct me if I am wrong? /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 20:54: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 741A816A4DF; Fri, 4 Aug 2006 20:54:05 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCA943D45; Fri, 4 Aug 2006 20:54:03 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CAA48629 (AUTH peterg@ptree32.com.au); Sat, 5 Aug 2006 06:54:00 +1000 (EST) Message-ID: <44D3B416.1060508@freebsd.org> Date: Fri, 04 Aug 2006 13:54:46 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Jason Evans References: <44D12AC0.90009@sippysoft.com> <20060802230803.GA32778@troutmask.apl.washington.edu> <44D13BC7.8010309@FreeBSD.org> <44D168A8.1060201@freebsd.org> <44D173B7.6040302@FreeBSD.org> <44D1757D.4010103@ptree32.com.au> <44D3A642.1000905@FreeBSD.org> In-Reply-To: <44D3A642.1000905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , "current@freebsd.org" , Peter Grehan , Steve Kargl , freebsd-ppc@FreeBSD.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Aug 2006 20:54:05 -0000 >> jemalloc. From the backtrace, t's doing a TLS allocation, where I'm >> certain phkmalloc didn't do anything like that. > > Indeed, jemalloc does add a dependency on TLS for PIC versions, though > it can be configured to run (more slowly) without TLS, as Marcel pointed > out. This appears to be a bug in the TLS implementation, rather than in > jemalloc; the appropriate fix is to make TLS work. Exactly. I was pointing out the difference, sorry if it appeared to be putting blame on jemalloc. later, Peter. From owner-freebsd-current@FreeBSD.ORG Fri Aug 4 21:18: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 4695A16A60A for ; Fri, 4 Aug 2006 21:18:22 +0000 (UTC) (envelope-from victor.cruceru@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0852643D64 for ; Fri, 4 Aug 2006 21:18:20 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by nf-out-0910.google.com with SMTP id g2so561708nfe for ; Fri, 04 Aug 2006 14:18:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FKxqKXGv52ytZcvIw3bb9SzBpkq5mHjFU/wIynypddWFuIHGd04Tp5JPRLKidbGHue+svQOiHHpp6a0o9sY6J5FCvlbbDrX9klrvv2tvfiM706MRnWQDqPmyKSqcp4zwNv6+59NwKdbmdQ5lipqJp0jlg0zE5QgIWVCWLud6wW0= Received: by 10.48.220.15 with SMTP id s15mr4746533nfg; Fri, 04 Aug 2006 14:18:19 -0700 (PDT) Received: by 10.70.47.19 with HTTP; Fri, 4 Aug 2006 14:18:19 -0700 (PDT) Message-ID: <49402550608041418j1b4d2ac9r66cae310c11e7ec5@mail.gmail.com> Date: Sat, 5 Aug 2006 00:18:19 +0300 From: "victor cruceru" To: freebsd-current@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: SMUX (RFC 1227) implementation for BSNMPd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 21:18:22 -0000 Hi folks, I'm glad to announce an implementation of the venerable SNMP SMUX protocol for FreeBSD SNMP agent, bsnmpd. You can grab it from its wiki page http://wikitest.freebsd.org/SnmpSmux There you will find instructions about how to build it (it is a patch against -current) and how to play with it. For now it is only a bsnmpd module (the "server side") - but if someone is interested I have plans to write a libsmux library and API to be used in building smux peers (the "client side"). Any feedback is greatly appreciated. Thanks, -- victor cruceru ------------------------------------------------ Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 00:16:28 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 9340616A4DE; Sat, 5 Aug 2006 00:16:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 5 Aug 2006 08:16:23 +0800 User-Agent: KMail/1.8.2 References: <44D12AC0.90009@sippysoft.com> <44D173B7.6040302@FreeBSD.org> <20060803224133.R87008@volatile.chemikals.org> In-Reply-To: <20060803224133.R87008@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608050816.23656.davidxu@freebsd.org> Cc: "current@freebsd.org" , Steve Kargl , Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 00:16:29 -0000 On Friday 04 August 2006 10:47, Wesley Morgan wrote: > On Wed, 2 Aug 2006, Maxim Sobolev wrote: > > Peter Grehan wrote: > >>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, > >>> offset=4294934528) at rtld.c:2663 > >>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at > >> > >> I think you might want to try point libpthread at libthr with > >> libmap.conf. TLS is known to work for that where I don't think it works > >> for libpthread. > > > > But libpthread works in 6.0. What's the difference? > > > > -Maxim > > FWIW, recently csup stopped working for me in -current on i386. It fails > when checking the errno set after calling access() to check if a file > exists: > > Updater failed: Cannot create directories leading to > "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0 > > According to gdb, errno is being set correctly but changes almost > immediately back to zero. Not sure how/why, and I'm not sure that I'm even > using gdb correctly for threaded applications. Switching to libthr with > libmap.conf results in the same error. > > I swear that it had something to do with turning on symbol versioning, but > attempting to turn it back off was not a fun experience and didn't have > the patience to see it through. libthr does not have mutliple versioning, the hack in libpthread is rather dirty, there is a plan to bump libthr version when symbol versioning is enabled and get rid of LIBTHREAD_1_0 symbol, it should only exist in libthr.so.2, libthr.so.3 will not have it. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 00:16:28 2006 Return-Path: X-Original-To: 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 9340616A4DE; Sat, 5 Aug 2006 00:16:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 5 Aug 2006 08:16:23 +0800 User-Agent: KMail/1.8.2 References: <44D12AC0.90009@sippysoft.com> <44D173B7.6040302@FreeBSD.org> <20060803224133.R87008@volatile.chemikals.org> In-Reply-To: <20060803224133.R87008@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608050816.23656.davidxu@freebsd.org> Cc: "current@freebsd.org" , Steve Kargl , Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 00:16:29 -0000 On Friday 04 August 2006 10:47, Wesley Morgan wrote: > On Wed, 2 Aug 2006, Maxim Sobolev wrote: > > Peter Grehan wrote: > >>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, > >>> offset=4294934528) at rtld.c:2663 > >>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at > >> > >> I think you might want to try point libpthread at libthr with > >> libmap.conf. TLS is known to work for that where I don't think it works > >> for libpthread. > > > > But libpthread works in 6.0. What's the difference? > > > > -Maxim > > FWIW, recently csup stopped working for me in -current on i386. It fails > when checking the errno set after calling access() to check if a file > exists: > > Updater failed: Cannot create directories leading to > "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0 > > According to gdb, errno is being set correctly but changes almost > immediately back to zero. Not sure how/why, and I'm not sure that I'm even > using gdb correctly for threaded applications. Switching to libthr with > libmap.conf results in the same error. > > I swear that it had something to do with turning on symbol versioning, but > attempting to turn it back off was not a fun experience and didn't have > the patience to see it through. libthr does not have mutliple versioning, the hack in libpthread is rather dirty, there is a plan to bump libthr version when symbol versioning is enabled and get rid of LIBTHREAD_1_0 symbol, it should only exist in libthr.so.2, libthr.so.3 will not have it. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 01:32: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 1E85B16A4DE; Sat, 5 Aug 2006 01:32:38 +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 7D9E143D46; Sat, 5 Aug 2006 01:32:37 +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.7/8.13.7/NETPLEX) with ESMTP id k751Waps017001; Fri, 4 Aug 2006 21:32:36 -0400 (EDT) Date: Fri, 4 Aug 2006 21:32:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200608050816.23656.davidxu@freebsd.org> Message-ID: References: <44D12AC0.90009@sippysoft.com> <44D173B7.6040302@FreeBSD.org> <20060803224133.R87008@volatile.chemikals.org> <200608050816.23656.davidxu@freebsd.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: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org, "current@freebsd.org" , Steve Kargl , Peter Grehan Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc 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: Sat, 05 Aug 2006 01:32:38 -0000 On Sat, 5 Aug 2006, David Xu wrote: > On Friday 04 August 2006 10:47, Wesley Morgan wrote: >> On Wed, 2 Aug 2006, Maxim Sobolev wrote: >>> Peter Grehan wrote: >>>>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, >>>>> offset=4294934528) at rtld.c:2663 >>>>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at >>>> >>>> I think you might want to try point libpthread at libthr with >>>> libmap.conf. TLS is known to work for that where I don't think it works >>>> for libpthread. >>> >>> But libpthread works in 6.0. What's the difference? >>> >>> -Maxim >> >> FWIW, recently csup stopped working for me in -current on i386. It fails >> when checking the errno set after calling access() to check if a file >> exists: >> >> Updater failed: Cannot create directories leading to >> "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0 >> >> According to gdb, errno is being set correctly but changes almost >> immediately back to zero. Not sure how/why, and I'm not sure that I'm even >> using gdb correctly for threaded applications. Switching to libthr with >> libmap.conf results in the same error. >> >> I swear that it had something to do with turning on symbol versioning, but >> attempting to turn it back off was not a fun experience and didn't have >> the patience to see it through. > > libthr does not have mutliple versioning, the hack in libpthread is > rather dirty, there is a plan to bump libthr version when symbol versioning > is enabled and get rid of LIBTHREAD_1_0 symbol, it should only exist > in libthr.so.2, libthr.so.3 will not have it. Yes, there is a hack in libpthread that was necessary in order to enable symbol versioning for libc. It can and will be removed once all the necessary libraries have been bumped in preparation for the release of 7.0. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 01:32: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 1E85B16A4DE; Sat, 5 Aug 2006 01:32:38 +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 7D9E143D46; Sat, 5 Aug 2006 01:32:37 +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.7/8.13.7/NETPLEX) with ESMTP id k751Waps017001; Fri, 4 Aug 2006 21:32:36 -0400 (EDT) Date: Fri, 4 Aug 2006 21:32:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200608050816.23656.davidxu@freebsd.org> Message-ID: References: <44D12AC0.90009@sippysoft.com> <44D173B7.6040302@FreeBSD.org> <20060803224133.R87008@volatile.chemikals.org> <200608050816.23656.davidxu@freebsd.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: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org, "current@freebsd.org" , Steve Kargl , Peter Grehan Subject: Re: Looks like threading is b0rken on FreeBSD/powerpc 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: Sat, 05 Aug 2006 01:32:38 -0000 On Sat, 5 Aug 2006, David Xu wrote: > On Friday 04 August 2006 10:47, Wesley Morgan wrote: >> On Wed, 2 Aug 2006, Maxim Sobolev wrote: >>> Peter Grehan wrote: >>>>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2, >>>>> offset=4294934528) at rtld.c:2663 >>>>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at >>>> >>>> I think you might want to try point libpthread at libthr with >>>> libmap.conf. TLS is known to work for that where I don't think it works >>>> for libpthread. >>> >>> But libpthread works in 6.0. What's the difference? >>> >>> -Maxim >> >> FWIW, recently csup stopped working for me in -current on i386. It fails >> when checking the errno set after calling access() to check if a file >> exists: >> >> Updater failed: Cannot create directories leading to >> "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0 >> >> According to gdb, errno is being set correctly but changes almost >> immediately back to zero. Not sure how/why, and I'm not sure that I'm even >> using gdb correctly for threaded applications. Switching to libthr with >> libmap.conf results in the same error. >> >> I swear that it had something to do with turning on symbol versioning, but >> attempting to turn it back off was not a fun experience and didn't have >> the patience to see it through. > > libthr does not have mutliple versioning, the hack in libpthread is > rather dirty, there is a plan to bump libthr version when symbol versioning > is enabled and get rid of LIBTHREAD_1_0 symbol, it should only exist > in libthr.so.2, libthr.so.3 will not have it. Yes, there is a hack in libpthread that was necessary in order to enable symbol versioning for libc. It can and will be removed once all the necessary libraries have been bumped in preparation for the release of 7.0. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 08:28: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 A2BBF16A4DF for ; Sat, 5 Aug 2006 08:28:18 +0000 (UTC) (envelope-from gexlie@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A8FD43D49 for ; Sat, 5 Aug 2006 08:28:17 +0000 (GMT) (envelope-from gexlie@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so48859pyc for ; Sat, 05 Aug 2006 01:28: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=sQMA/BY1bSxlxbEFSzgOc/gffiqPZ5aYawdaUCUUMszC4E2n/ZXDt9ftBzurUwKa0uTgPKuPOlrbz3cJGLyNkOZpuyGtVy1Ojve5WYc0xOHLWX7tjjHZePwnrPDGjTch6NArLKZM9CqE1Zje3jMfUo57ExJiGfszEu2MjDo5Tx0= Received: by 10.35.121.9 with SMTP id y9mr6851133pym; Sat, 05 Aug 2006 01:28:17 -0700 (PDT) Received: by 10.35.98.19 with HTTP; Sat, 5 Aug 2006 01:28:17 -0700 (PDT) Message-ID: <53cc795f0608050128s7187f757xea47e86f6e471ba1@mail.gmail.com> Date: Sat, 5 Aug 2006 12:28:17 +0400 From: sekes To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: today's cvsup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 08:28:18 -0000 after the subj i failed to build world sh /usr/src/tools/install.sh -o root -g wheel -m 555 rpcgen /usr/obj/usr/src/tmp/legacy/usr/bin ===> usr.bin/xinstall (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall created for /usr/src/usr.bin/xinstall rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/usr.bin/xinstall/xinstall.c echo xinstall: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend cc -O2 -pipe -funroll-loops -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/xinstall/xinstall.c cc -O2 -pipe -funroll-loops -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o xinstall xinstall.o -legacy sh /usr/src/tools/install.sh -o root -g wheel -m 555 xinstall /usr/obj/usr/src/tmp/legacy/usr/bin/install ===> usr.sbin/config (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.sbin/config created for /usr/src/usr.sbin/config yacc -d /usr/src/usr.sbin/config/config.y cp y.tab.c config.c lex -t /usr/src/usr.sbin/config/lang.l > lang.c rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include config.c/usr/src/usr.sbin/config/main.c lang.c /usr/src/usr.sbin/config/mkmakefile.c /usr/src/usr.sbin/config/mkheaders.c /usr/src/usr.sbin/config/mkoptions.c /usr/src/usr.sbin/config/config.y:78:20: config.h: No such file or directory /usr/src/usr.sbin/config/main.c:55:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/lang.l:38:20: config.h: No such file or directory /usr/src/usr.sbin/config/mkmakefile.c:49:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/mkheaders.c:48:19: y.tab.h: No such file or directory /usr/src/usr.sbin/config/mkoptions.c:49:19: y.tab.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.sbin/config. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 09:00: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 7ADD716A50A; Sat, 5 Aug 2006 09:00:52 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E8DA43D46; Sat, 5 Aug 2006 09:00:51 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id 5E2E9547E9; Sat, 5 Aug 2006 11:00:50 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 0183C9CC19; Sat, 5 Aug 2006 09:01:19 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id D240D405A; Sat, 5 Aug 2006 11:01:19 +0200 (CEST) Date: Sat, 5 Aug 2006 11:01:19 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20060805090119.GM4498@obiwan.tataz.chchile.org> References: <20060529153103.GA17178@obiwan.tataz.chchile.org> <20060530223226.GT1890@obiwan.tataz.chchile.org> <200606011441.07494.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606011441.07494.jhb@freebsd.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: [fbsd] Re: [fbsd] timer goes sluggish X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 09:00:52 -0000 Hi John, On Thu, Jun 01, 2006 at 02:41:07PM -0400, John Baldwin wrote: > On Tuesday 30 May 2006 18:32, Jeremie Le Hen wrote: > > Hi, > > > > On Mon, May 29, 2006 at 05:31:03PM +0200, Jeremie Le Hen wrote: > > > Hi, > > > > > > I won't write too much, the following session will tell much more: > > > > > > % jarjarbinks:root# ntpdate -b chronos.cru.fr > > > % 29 May 17:08:44 ntpdate[4254]: step time server 195.220.94.163 offset > 0.000273 sec > > > % jarjarbinks:root# sysctl kern.timecounter.hardware > > > % kern.timecounter.hardware: ACPI-fast > > > % jarjarbinks:root# while : ; do date ; sleep 1 ; done > > > % Mon May 29 17:08:56 CEST 2006 > > > % Mon May 29 17:09:03 CEST 2006 > > > % Mon May 29 17:09:09 CEST 2006 > > > % Mon May 29 17:09:16 CEST 2006 > > > % Mon May 29 17:09:22 CEST 2006 > > > % ^C > > > > Sometimes, I feel dumb. > > > > I noticed that the clock sped up when the CPU makes heavy computing, > > which meant there was some power saving on idleness. > > > > I dug a bit I found that hw.acpi.cpu.cx_lowest=C4. > > Setting it hw.acpi.cpu.cx_lowest=C1 makes the clock goes ``in time'' :). > > If you are using APIC, try disabling APIC and see if it works ok with higher > Cx states. Sorry for the delay. I was indeed using APIC, and got a chance to disable it. I am writing this mail with C4 state set and it works flawlessly: % # sysctl hw.acpi.cpu.cx_lowest % hw.acpi.cpu.cx_lowest: C4 % # while : ; do date ; sleep 1 ; done % Sat Aug 5 10:54:19 UTC 2006 % Sat Aug 5 10:54:20 UTC 2006 % Sat Aug 5 10:54:21 UTC 2006 % Sat Aug 5 10:54:22 UTC 2006 What's the point in disabling apic ? Am I supposed to lose some features along with the apic support removal, or is it something I won't notice ? Thank you. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 15:55: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 E98B816A4DA; Sat, 5 Aug 2006 15:55:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F6E43D46; Sat, 5 Aug 2006 15:55:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k75Ftm47042471; Sat, 5 Aug 2006 11:55:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k75FtnOL047272; Sat, 5 Aug 2006 11:55:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EBE837302F; Sat, 5 Aug 2006 11:55:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060805155548.EBE837302F@freebsd-current.sentex.ca> Date: Sat, 5 Aug 2006 11:55:48 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 15:55:51 -0000 TB --- 2006-08-05 14:53:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-08-05 14:53:11 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-08-05 14:53:11 - cleaning the object tree TB --- 2006-08-05 14:53:53 - checking out the source tree TB --- 2006-08-05 14:53:53 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-08-05 14:53:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-08-05 15:01:17 - building world (CFLAGS=-O2 -pipe) TB --- 2006-08-05 15:01:17 - cd /src TB --- 2006-08-05 15:01:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRDUMP -DRESCUE /src/sbin/dump/itime.c /src/sbin/dump/main.c /src/sbin/dump/optr.c /src/sbin/dump/dumprmt.c /src/sbin/dump/tape.c /src/sbin/dump/traverse.c /src/sbin/dump/unctime.c /src/sbin/dump/cache.c echo dump: /obj/amd64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/itime.c cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/main.c cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/optr.c /src/sbin/dump/optr.c: In function `timeest': /src/sbin/dump/optr.c:214: warning: field precision is not type int (arg 7) *** Error code 1 Stop in /src/sbin/dump. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-08-05 15:55:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-08-05 15:55:48 - ERROR: failed to build world TB --- 2006-08-05 15:55:48 - tinderbox aborted TB --- 1.27 user 7.31 system 3756.83 real From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 16:15: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 13C5D16A4DD for ; Sat, 5 Aug 2006 16:15:35 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BEE943D46 for ; Sat, 5 Aug 2006 16:15:34 +0000 (GMT) (envelope-from jamesfrancistoy@gmail.com) Received: by nf-out-0910.google.com with SMTP id g2so796806nfe for ; Sat, 05 Aug 2006 09:15: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:content-transfer-encoding:content-disposition; b=ndapsPgaGiFm4exEN7RaClnjrGg8Bffv5sSGp/lWeLA5qmlCnll+/smgV5wgDnC+y/vOWKqI3IUhfp7BGfJuwdxhLjSu8NNbnJxWisoDbYQ31iM444wXeDCK6YKh4EXii/fdnx639dnQeprxLNi6Ddc+xuBV8sJQVVK29aztxH8= Received: by 10.78.157.8 with SMTP id f8mr1936587hue; Sat, 05 Aug 2006 09:15:32 -0700 (PDT) Received: by 10.78.50.18 with HTTP; Sat, 5 Aug 2006 09:15:32 -0700 (PDT) Message-ID: <9f8af95f0608050915u86e414au1c8d7a6da5cb0ce9@mail.gmail.com> Date: Sat, 5 Aug 2006 12:15:32 -0400 From: "james toy" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Macbook -- 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, 05 Aug 2006 16:15:35 -0000 Hello, i have been using freebsd since i was around 10 -- i really love the OS and prefer it to everything else as i grew up on it -- i am writing concerning how robust the support is for the new macbook -- i was helping to develop ppc freebsd and know some of the new issues with the macintosh hardware -- now with the new northbridge a lot of the hardware has been rearranged in terms of controllers -- i was curious about the acpi concern -- as well as the fact 5 separate usb devices register for keyboards -- i assume that this is the bluetooth device searching for and making a device for a non existent component -- the mouse too does not work -- when clicked it simply drags to the bottom right -- perhaps at the loader prompt hint.pcib.1.skipslot=26 or some such to avoid the bluetooth -- any comments or questions are welcomed i'm just curious and want to get some more talk about these new machines -- the are very well engineered and have all the right components to run a really nice freebsd system -- ___ -jt From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 18:09: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 0BD3816A4DE; Sat, 5 Aug 2006 18:09:29 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F95443D49; Sat, 5 Aug 2006 18:09:27 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.6/8.13.6) with ESMTP id k75I9Q2s011511; Sat, 5 Aug 2006 22:09:26 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 5 Aug 2006 22:09:26 +0400 (MSD) From: Dmitry Morozovsky To: rse@freebsd.org In-Reply-To: <20060805155548.EBE837302F@freebsd-current.sentex.ca> Message-ID: <20060805220746.U9314@woozle.rinet.ru> References: <20060805155548.EBE837302F@freebsd-current.sentex.ca> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Sat, 05 Aug 2006 22:09:26 +0400 (MSD) Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 18:09:29 -0000 On Sat, 5 Aug 2006, FreeBSD Tinderbox wrote: FT> mkdep -f .depend -a -DRDUMP -DRESCUE /src/sbin/dump/itime.c /src/sbin/dump/main.c /src/sbin/dump/optr.c /src/sbin/dump/dumprmt.c /src/sbin/dump/tape.c /src/sbin/dump/traverse.c /src/sbin/dump/unctime.c /src/sbin/dump/cache.c FT> echo dump: /obj/amd64/src/tmp/usr/lib/libc.a >> .depend FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/itime.c FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/main.c FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/optr.c FT> /src/sbin/dump/optr.c: In function `timeest': FT> /src/sbin/dump/optr.c:214: warning: field precision is not type int (arg 7) It seems at least on amd64 size_t (strlen() result) is not int. Maybe the following quick fix? Index: optr.c =================================================================== RCS file: /home/ncvs/src/sbin/dump/optr.c,v retrieving revision 1.33 diff -u -r1.33 optr.c --- optr.c 5 Aug 2006 12:50:38 -0000 1.33 +++ optr.c 5 Aug 2006 18:07:34 -0000 @@ -211,7 +211,7 @@ tdone_str = ctime(&tdone); setproctitle( "%s: pass %d: %3.2f%% done, finished in %d:%02d at %.*s", - disk, passno, percent, hours, mins, strlen(tdone_str) - 1, tdone_str); + disk, passno, percent, hours, mins, (int)(strlen(tdone_str) - 1), tdone_str); if (tnow >= tschedule) { tschedule = tnow + 300; if (blockswritten < 500) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 18:39: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 8E4E816A4E2; Sat, 5 Aug 2006 18:39:37 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5453143D55; Sat, 5 Aug 2006 18:39:36 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.6/8.13.6) with ESMTP id k75IdZd2011970; Sat, 5 Aug 2006 22:39:35 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 5 Aug 2006 22:39:35 +0400 (MSD) From: Dmitry Morozovsky To: rse@freebsd.org In-Reply-To: <20060805220746.U9314@woozle.rinet.ru> Message-ID: <20060805223658.X9314@woozle.rinet.ru> References: <20060805155548.EBE837302F@freebsd-current.sentex.ca> <20060805220746.U9314@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Sat, 05 Aug 2006 22:39:35 +0400 (MSD) Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 18:39:37 -0000 On Sat, 5 Aug 2006, Dmitry Morozovsky wrote: DM> FT> mkdep -f .depend -a -DRDUMP -DRESCUE /src/sbin/dump/itime.c /src/sbin/dump/main.c /src/sbin/dump/optr.c /src/sbin/dump/dumprmt.c /src/sbin/dump/tape.c /src/sbin/dump/traverse.c /src/sbin/dump/unctime.c /src/sbin/dump/cache.c DM> FT> echo dump: /obj/amd64/src/tmp/usr/lib/libc.a >> .depend DM> FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/itime.c DM> FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/main.c DM> FT> cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/optr.c DM> FT> /src/sbin/dump/optr.c: In function `timeest': DM> FT> /src/sbin/dump/optr.c:214: warning: field precision is not type int (arg 7) DM> DM> It seems at least on amd64 size_t (strlen() result) is not int. DM> DM> Maybe the following quick fix? Or, maybe, the following would be less ugly: Index: optr.c =================================================================== RCS file: /home/ncvs/src/sbin/dump/optr.c,v retrieving revision 1.33 diff -u -r1.33 optr.c --- optr.c 5 Aug 2006 12:50:38 -0000 1.33 +++ optr.c 5 Aug 2006 18:38:21 -0000 @@ -209,14 +209,15 @@ mins = (deltat % 3600) / 60; tdone_str = ctime(&tdone); + tdone_str[(strlen(tdone_str) - 1)] = '\0'; setproctitle( - "%s: pass %d: %3.2f%% done, finished in %d:%02d at %.*s", - disk, passno, percent, hours, mins, strlen(tdone_str) - 1, tdone_str); + "%s: pass %d: %3.2f%% done, finished in %d:%02d at %s", + disk, passno, percent, hours, mins, tdone_str); if (tnow >= tschedule) { tschedule = tnow + 300; if (blockswritten < 500) return; - msg("%3.2f%% done, finished in %d:%02d at %s", percent, + msg("%3.2f%% done, finished in %d:%02d at %s\n", percent, hours, mins, tdone_str); } } Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 21:04: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 D0B9416A4DD; Sat, 5 Aug 2006 21:04:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C88843D46; Sat, 5 Aug 2006 21:04:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.6/8.13.4) with ESMTP id k75L4tkl060647; Sat, 5 Aug 2006 17:04:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k75L4t0w094002; Sat, 5 Aug 2006 17:04:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4109D7302F; Sat, 5 Aug 2006 17:04:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060805210455.4109D7302F@freebsd-current.sentex.ca> Date: Sat, 5 Aug 2006 17:04:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 21:04:56 -0000 TB --- 2006-08-05 20:03:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-08-05 20:03:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-08-05 20:03:22 - cleaning the object tree TB --- 2006-08-05 20:03:51 - checking out the source tree TB --- 2006-08-05 20:03:51 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-08-05 20:03:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-08-05 20:11:31 - building world (CFLAGS=-O2 -pipe) TB --- 2006-08-05 20:11:31 - cd /src TB --- 2006-08-05 20:11:31 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRDUMP -DRESCUE /src/sbin/dump/itime.c /src/sbin/dump/main.c /src/sbin/dump/optr.c /src/sbin/dump/dumprmt.c /src/sbin/dump/tape.c /src/sbin/dump/traverse.c /src/sbin/dump/unctime.c /src/sbin/dump/cache.c echo dump: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/itime.c cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/main.c cc -O2 -pipe -DRDUMP -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/dump/optr.c /src/sbin/dump/optr.c: In function `timeest': /src/sbin/dump/optr.c:214: warning: field precision is not type int (arg 7) *** Error code 1 Stop in /src/sbin/dump. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-08-05 21:04:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-08-05 21:04:55 - ERROR: failed to build world TB --- 2006-08-05 21:04:55 - tinderbox aborted TB --- 0.95 user 5.27 system 3693.02 real From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 21:22: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 68A5516A4E6 for ; Sat, 5 Aug 2006 21:22:21 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 236A443D53 for ; Sat, 5 Aug 2006 21:22:20 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 95F08D93A35 for ; Sat, 5 Aug 2006 17:22:18 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sat, 05 Aug 2006 17:22:19 -0400 X-Sasl-enc: l8hAYEvSlSjFavUlFdTkKXNESFnAPIj3KirEn6Viy+Zx 1154812938 Received: from [192.168.1.105] (unknown [207.160.231.2]) by mail.messagingengine.com (Postfix) with ESMTP id 9DE5D1C0E for ; Sat, 5 Aug 2006 17:22:18 -0400 (EDT) Message-ID: <44D50C09.3080108@fastmail.fm> Date: Sat, 05 Aug 2006 16:22:17 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <44C3FEDA.5060501@fastmail.fm> In-Reply-To: <44C3FEDA.5060501@fastmail.fm> Content-Type: multipart/mixed; boundary="------------060206060006020502050602" Subject: Re: D-Link ath card not recognized X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 21:22:21 -0000 This is a multi-part message in MIME format. --------------060206060006020502050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Patrick Bowen wrote: > Just upgraded from 6.1 RELEASE to -current, and a previously working > D-Link DWL-G630 AirPlus G wireless notebook adapter no longer works. > > H/W ver.: C2 F/W ver.: 3.01 > > This from dmesg; > > cbb alloc res fail > cbb alloc res fail > cardbus0: at device 0.0 (no driver attached) > > and this from dumpcis on Linux; > > Socket 0: > manfid 0x0271, 0x0012 > config_cb base 0x0000 last_index 0x01 > cftable_entry_cb 0x01 [default] > [master] [parity] [serr] [fast back] > Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA > irq mask 0xffff [level] > mem_base 1 > BAR 1 size 64kb [mem] > vers_1 7.1, "Atheros Communications, Inc.", "AR5001-0000-0000", > "Wireless LAN Reference Card", "00" > funcid network_adapter [post] > lan_speed 6 mb/sec > lan_speed 9 mb/sec > lan_speed 12 mb/sec > lan_speed 18 mb/sec > lan_speed 24 mb/sec > lan_speed 36 mb/sec > lan_speed 48 mb/sec > lan_speed 54 mb/sec > lan_speed 72 mb/sec > lan_media 5.4_GHz > lan_node_id 00 03 2f 55 55 55 > lan_connector Closed connector standard > > Ialso snagged this from Linux's dmesg; > > [17179589.744000] pccard: CardBus card inserted into slot 0 > [17179589.776000] ath_hal: module license 'Proprietary' taints kernel. > [17179589.776000] ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, > RF5112, RF2 > 413) > [17179589.796000] cs: IO port probe 0x100-0x3af: clean. > [17179589.800000] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > [17179589.800000] cs: IO port probe 0x820-0x8ff: clean. > [17179589.800000] cs: IO port probe 0xc00-0xcf7: clean. > [17179589.800000] cs: IO port probe 0xa00-0xaff: clean. > [17179589.824000] wlan: 0.8.6.0 (EXPERIMENTAL) > [17179589.824000] ath_rate_sample: 1.2 > [17179589.832000] ath_pci: 0.9.6.0 (EXPERIMENTAL) > [17179589.832000] PCI: Enabling device 0000:07:00.0 (0000 -> 0002) > [17179589.832000] ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 16 > (level, low) -> > IRQ 177 > [17179590.416000] Build date: Jul 10 2006 > [17179590.416000] Debugging version (IEEE80211) > [17179590.416000] ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > [17179590.416000] ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps > 9Mbps 12Mbps > 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > [17179590.416000] ath0: H/W encryption support: WEP AES AES_CCM TKIP > [17179590.416000] ath0: mac 7.8 phy 4.5 radio 5.6 > [17179590.416000] ath0: Use hw queue 1 for WME_AC_BE traffic > [17179590.416000] ath0: Use hw queue 0 for WME_AC_BK traffic > [17179590.416000] ath0: Use hw queue 2 for WME_AC_VI traffic > [17179590.416000] ath0: Use hw queue 3 for WME_AC_VO traffic > [17179590.416000] ath0: Use hw queue 8 for CAB traffic > [17179590.416000] ath0: Use hw queue 9 for beacons > [17179590.416000] Debugging version (ATH) > [17179590.416000] ath0: Atheros 5212: mem=0x24000000, irq=177 > > If I can provide any more info, please let me know. > > Thanks, > Patrick > > > > > _______________________________________________ > 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 put this up on the list a couple of weeks ago, and haven't seen anything come back in the way of a dialog, so I figured I'd re-post it to see if I get any nibbles. The only thing I have to add is the following from a verbose dmesg. Complete verbose dmesg attached; > map[10]: type 1, range 64, base b4000000, size 14, enabled > pcib2: (null) requested memory range 0xb4000000-0xb4003fff: good > cbb alloc res fail > map[18]: type 4, range 32, base 00003000, size 8, enabled > cbb alloc res fail > found-> vendor=0x11ab, dev=0x4351, revid=0x10 > bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 2 messages, 64 bit > cardbus0: at device 0.0 (no driver attached) Thanks, Patrick --------------060206060006020502050602 Content-Type: text/plain; name="dmesg.verbose.ath0" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.verbose.ath0" AMD Features=0x100000 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 1 MB, 4-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 1024 kbytes, 4-way associative, 64 bytes/line real memory = 258867200 (246 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000000f24efff, 237137920 bytes (57895 pages) avail memory = 239394816 (228 MB) Table 'APIC' at 0xf6e9e88 MADT: Found table at 0xf6e9e88 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: disabled INTR: Adding local APIC 0 as a target ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f6810 bios32: Entry = 0xfd700 (c00fd700) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd700+0x244 pnpbios: Found PnP BIOS data at 0xc00f6860 pnpbios: Entry = f0000:aee2 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jul 29 2006 17:35:51) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f920 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc6a74000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 10 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2590, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2592, revid=0x04 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base b0080000, size 19, enabled map[14]: type 4, range 32, base 00001800, size 3, enabled map[18]: type 3, range 32, base c0000000, size 28, enabled map[1c]: type 1, range 32, base b0000000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2792, revid=0x04 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 00000000, size 19, memory disabled found-> vendor=0x8086, dev=0x2660, revid=0x04 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2658, revid=0x04 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2659, revid=0x04 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 23 found-> vendor=0x8086, dev=0x265a, revid=0x04 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x265b, revid=0x04 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 22 found-> vendor=0x8086, dev=0x265c, revid=0x04 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base b0040000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2448, revid=0xd4 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x266e, revid=0x04 bus=0, slot=30, func=2 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 4, range 32, base 000018c0, size 6, enabled map[18]: type 1, range 32, base b0040800, size 9, enabled map[1c]: type 1, range 32, base b0040400, size 8, enabled pcib0: matched entry for 0.30.INTA pcib0: slot 30 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x266d, revid=0x04 bus=0, slot=30, func=3 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002400, size 8, enabled map[14]: type 4, range 32, base 00002000, size 7, enabled pcib0: matched entry for 0.30.INTB pcib0: slot 30 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2641, revid=0x04 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x266f, revid=0x04 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001810, size 4, enabled found-> vendor=0x8086, dev=0x266a, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 000020a0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xb0080000-0xb00fffff,0xc0000000-0xcfffffff,0xb0000000-0xb003ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xb0080000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xb0080000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xb0000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: at device 2.1 on pci0 pcib1: irq 17 at device 28.0 on pci0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xb4000000-0xb7ffffff pcib1: prefetched decode 0xd0000000-0xd3ffffff pci2: on pcib1 pci2: physical bus=2 found-> vendor=0x11ab, dev=0x4351, revid=0x10 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 1, range 64, base b4000000, size 14, enabled pcib1: (null) requested memory range 0xb4000000-0xb4003fff: good map[18]: type 4, range 32, base 00003000, size 8, enabled pcib1: (null) requested I/O range 0x3000-0x30ff: in range pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) uhci0: port 0x1820-0x183f irq 19 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 23 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 22 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 51 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 22 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb0040000-0xb00403ff irq 19 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xb0040000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 6 pcib2: subordinate bus 7 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xb8000000-0xb80fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci6: on pcib2 pci6: physical bus=6 found-> vendor=0x14e4, dev=0x4318, revid=0x02 bus=6, slot=4, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 1, range 32, base b8004000, size 13, enabled pcib2: (null) requested memory range 0xb8004000-0xb8005fff: good pcib2: matched entry for 6.4.INTA pcib2: slot 4 INTA hardwired to IRQ 17 found-> vendor=0x104c, dev=0x8031, revid=0x00 bus=6, slot=9, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x32 (1500 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0x8032, revid=0x00 bus=6, slot=9, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x04 (1000 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8008000, size 11, enabled pcib2: (null) requested memory range 0xb8008000-0xb80087ff: good map[14]: type 1, range 32, base b8000000, size 14, enabled pcib2: (null) requested memory range 0xb8000000-0xb8003fff: good pcib2: matched entry for 6.9.INTC pcib2: slot 9 INTC hardwired to IRQ 18 found-> vendor=0x104c, dev=0x8033, revid=0x00 bus=6, slot=9, func=3 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8006000, size 13, enabled pcib2: (null) requested memory range 0xb8006000-0xb8007fff: good pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 found-> vendor=0x104c, dev=0x8034, revid=0x00 bus=6, slot=9, func=4 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8009000, size 8, enabled pcib2: (null) requested memory range 0xb8009000-0xb80090ff: good map[14]: type 1, range 32, base b8008c00, size 8, enabled pcib2: (null) requested memory range 0xb8008c00-0xb8008cff: good map[18]: type 1, range 32, base b8008800, size 8, enabled pcib2: (null) requested memory range 0xb8008800-0xb80088ff: good pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 ndis0: mem 0xb8004000-0xb8005fff irq 17 at device 4.0 on pci6 ndis0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xb8004000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 52 ndis0: [MPSAFE] ndis0: NDIS API version: 5.1 ndis0: bpf attached ndis0: Ethernet address: 00:14:a5:80:f5:c9 ndis0: bpf attached cbb0: at device 9.0 on pci6 pcib2: cbb0 requested memory range 0xb8000000-0xb80fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xb800a000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x8031104c 0x02100007 0x06070000 0x00823200 0x10: 0xb800a000 0x020000a0 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400110 0x40: 0x0365107b 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d061 0x00000000 0x000f0000 0x01ac1b22 0x90: 0x606482c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=104c, dev=8032 fwohci0: vendor=104c, dev=8032 fwohci0: <1394 Open Host Controller Interface> mem 0xb8008000-0xb80087ff,0xb8000000-0xb8003fff irq 18 at device 9.2 on pci6 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xb8008000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 54 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:b8:03:65:02:20:31 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:b8:02:20:31 fwe0: bpf attached fwe0: Ethernet address: 02:e0:b8:02:20:31 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=2, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int pci6: at device 9.3 (no driver attached) pci6: at device 9.4 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xb0040800-0xb00409ff,0xb0040400-0xb00404ff irq 21 at device 30.2 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xb0040800 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xb0040400 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 pcm0: [MPSAFE] pcm0: pcm0: Codec features reserved, headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features reserved 1, AMAP, reserved 5 pcm0: ac97 codec dac ready count: 0 pcm0: sndbuf_setmap efc6000, 4000; 0xcc2a0000 -> efc6000 pcm0: sndbuf_setmap efbc000, 4000; 0xcc2a4000 -> efbc000 pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=50 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 56 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 57 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xcf800-0xd0fff,0xdc000-0xdffff,0xe0000-0xe07ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 60 sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 50488942 hz Timecounter "TSC" frequency 1514668172 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. acpi_acad0: acline initialization start battery0: battery initialization start ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ICH6 chip ad0: setting UDMA100 on ICH6 chip ad0: 57231MB at ata0-master UDMA100 ad0: 117210240 sectors [116280C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization done, tried 1 times ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on ICH6 chip acd0: setting UDMA33 on ICH6 chip acd0: CDRW drive at ata0 as slave acd0: read 689KB/s (4126KB/s) write 4126KB/s (4126KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48012 Hz, will use 48000 Hz (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s3a start_init: trying /sbin/init Linux ELF exec handler installed map[10]: type 1, range 64, base b4000000, size 14, enabled pcib2: (null) requested memory range 0xb4000000-0xb4003fff: good cbb alloc res fail map[18]: type 4, range 32, base 00003000, size 8, enabled cbb alloc res fail found-> vendor=0x11ab, dev=0x4351, revid=0x10 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit cardbus0: at device 0.0 (no driver attached) --------------060206060006020502050602-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 5 21:38: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 A65C616A4E0 for ; Sat, 5 Aug 2006 21:38:21 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A33D43D5D for ; Sat, 5 Aug 2006 21:38:20 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 19109D93376 for ; Sat, 5 Aug 2006 17:38:18 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sat, 05 Aug 2006 17:38:18 -0400 X-Sasl-enc: dQksBVH/P+eisHBH3ugG+tjuG0ReGAxMumyF/h5zWIr4 1154813898 Received: from [192.168.1.105] (unknown [207.160.231.2]) by mail.messagingengine.com (Postfix) with ESMTP id 333DE1C25 for ; Sat, 5 Aug 2006 17:38:18 -0400 (EDT) Message-ID: <44D50FCF.5050402@fastmail.fm> Date: Sat, 05 Aug 2006 16:38:23 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <44C3FEDA.5060501@fastmail.fm> In-Reply-To: <44C3FEDA.5060501@fastmail.fm> Content-Type: multipart/mixed; boundary="------------040808000102040400030108" Subject: Re: D-Link ath card not recognized X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Aug 2006 21:38:21 -0000 This is a multi-part message in MIME format. --------------040808000102040400030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry...previous msg had part of dmesg missing... Patrick Bowen wrote: > Just upgraded from 6.1 RELEASE to -current, and a previously working > D-Link DWL-G630 AirPlus G wireless notebook adapter no longer works. > > H/W ver.: C2 F/W ver.: 3.01 > > This from dmesg; > > cbb alloc res fail > cbb alloc res fail > cardbus0: at device 0.0 (no driver attached) > > and this from dumpcis on Linux; > > Socket 0: > manfid 0x0271, 0x0012 > config_cb base 0x0000 last_index 0x01 > cftable_entry_cb 0x01 [default] > [master] [parity] [serr] [fast back] > Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA > irq mask 0xffff [level] > mem_base 1 > BAR 1 size 64kb [mem] > vers_1 7.1, "Atheros Communications, Inc.", "AR5001-0000-0000", > "Wireless LAN Reference Card", "00" > funcid network_adapter [post] > lan_speed 6 mb/sec > lan_speed 9 mb/sec > lan_speed 12 mb/sec > lan_speed 18 mb/sec > lan_speed 24 mb/sec > lan_speed 36 mb/sec > lan_speed 48 mb/sec > lan_speed 54 mb/sec > lan_speed 72 mb/sec > lan_media 5.4_GHz > lan_node_id 00 03 2f 55 55 55 > lan_connector Closed connector standard > > Ialso snagged this from Linux's dmesg; > > [17179589.744000] pccard: CardBus card inserted into slot 0 > [17179589.776000] ath_hal: module license 'Proprietary' taints kernel. > [17179589.776000] ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, > RF5112, RF2 > 413) > [17179589.796000] cs: IO port probe 0x100-0x3af: clean. > [17179589.800000] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > [17179589.800000] cs: IO port probe 0x820-0x8ff: clean. > [17179589.800000] cs: IO port probe 0xc00-0xcf7: clean. > [17179589.800000] cs: IO port probe 0xa00-0xaff: clean. > [17179589.824000] wlan: 0.8.6.0 (EXPERIMENTAL) > [17179589.824000] ath_rate_sample: 1.2 > [17179589.832000] ath_pci: 0.9.6.0 (EXPERIMENTAL) > [17179589.832000] PCI: Enabling device 0000:07:00.0 (0000 -> 0002) > [17179589.832000] ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 16 > (level, low) -> > IRQ 177 > [17179590.416000] Build date: Jul 10 2006 > [17179590.416000] Debugging version (IEEE80211) > [17179590.416000] ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > [17179590.416000] ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps > 9Mbps 12Mbps > 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > [17179590.416000] ath0: H/W encryption support: WEP AES AES_CCM TKIP > [17179590.416000] ath0: mac 7.8 phy 4.5 radio 5.6 > [17179590.416000] ath0: Use hw queue 1 for WME_AC_BE traffic > [17179590.416000] ath0: Use hw queue 0 for WME_AC_BK traffic > [17179590.416000] ath0: Use hw queue 2 for WME_AC_VI traffic > [17179590.416000] ath0: Use hw queue 3 for WME_AC_VO traffic > [17179590.416000] ath0: Use hw queue 8 for CAB traffic > [17179590.416000] ath0: Use hw queue 9 for beacons > [17179590.416000] Debugging version (ATH) > [17179590.416000] ath0: Atheros 5212: mem=0x24000000, irq=177 > > If I can provide any more info, please let me know. > > Thanks, > Patrick > > > > > _______________________________________________ > 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 put this up on the list a couple of weeks ago, and haven't seen anything come back in the way of a dialog, so I figured I'd re-post it to see if I get any nibbles. The only thing I have to add is the following from a verbose dmesg. Complete verbose dmesg attached; > map[10]: type 1, range 64, base b4000000, size 14, enabled > pcib2: (null) requested memory range 0xb4000000-0xb4003fff: good > cbb alloc res fail > map[18]: type 4, range 32, base 00003000, size 8, enabled > cbb alloc res fail > found-> vendor=0x11ab, dev=0x4351, revid=0x10 > bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 2 messages, 64 bit > cardbus0: at device 0.0 (no driver attached) Thanks, Patrick --------------040808000102040400030108 Content-Type: text/plain; name="dmesg.verbose" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.verbose" Preloaded elf module "/boot/kernel/ndis.ko" at 0xc0ccb408. Preloaded elf module "/boot/kernel/if_ndis.ko" at 0xc0ccb4b4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ccb560. Calibrating clock(s) ... i8254 clock: 1182468 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1514668172 Hz CPU: Intel(R) Celeron(R) M processor 1.50GHz (1514.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff AMD Features=0x100000 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 1 MB, 4-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 1024 kbytes, 4-way associative, 64 bytes/line real memory = 258867200 (246 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000000f24efff, 237137920 bytes (57895 pages) avail memory = 239394816 (228 MB) Table 'APIC' at 0xf6e9e88 MADT: Found table at 0xf6e9e88 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: disabled INTR: Adding local APIC 0 as a target ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f6810 bios32: Entry = 0xfd700 (c00fd700) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd700+0x244 pnpbios: Found PnP BIOS data at 0xc00f6860 pnpbios: Entry = f0000:aee2 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jul 29 2006 17:35:51) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f920 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc6a74000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 10 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 11 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 11 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2590, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2592, revid=0x04 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base b0080000, size 19, enabled map[14]: type 4, range 32, base 00001800, size 3, enabled map[18]: type 3, range 32, base c0000000, size 28, enabled map[1c]: type 1, range 32, base b0000000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2792, revid=0x04 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 00000000, size 19, memory disabled found-> vendor=0x8086, dev=0x2660, revid=0x04 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2658, revid=0x04 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2659, revid=0x04 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 23 found-> vendor=0x8086, dev=0x265a, revid=0x04 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x265b, revid=0x04 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 22 found-> vendor=0x8086, dev=0x265c, revid=0x04 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base b0040000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2448, revid=0xd4 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x266e, revid=0x04 bus=0, slot=30, func=2 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 4, range 32, base 000018c0, size 6, enabled map[18]: type 1, range 32, base b0040800, size 9, enabled map[1c]: type 1, range 32, base b0040400, size 8, enabled pcib0: matched entry for 0.30.INTA pcib0: slot 30 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x266d, revid=0x04 bus=0, slot=30, func=3 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002400, size 8, enabled map[14]: type 4, range 32, base 00002000, size 7, enabled pcib0: matched entry for 0.30.INTB pcib0: slot 30 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2641, revid=0x04 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x266f, revid=0x04 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001810, size 4, enabled found-> vendor=0x8086, dev=0x266a, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 000020a0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xb0080000-0xb00fffff,0xc0000000-0xcfffffff,0xb0000000-0xb003ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xb0080000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xb0080000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xb0000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: at device 2.1 on pci0 pcib1: irq 17 at device 28.0 on pci0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xb4000000-0xb7ffffff pcib1: prefetched decode 0xd0000000-0xd3ffffff pci2: on pcib1 pci2: physical bus=2 found-> vendor=0x11ab, dev=0x4351, revid=0x10 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 1, range 64, base b4000000, size 14, enabled pcib1: (null) requested memory range 0xb4000000-0xb4003fff: good map[18]: type 4, range 32, base 00003000, size 8, enabled pcib1: (null) requested I/O range 0x3000-0x30ff: in range pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) uhci0: port 0x1820-0x183f irq 19 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 23 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 22 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 51 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 22 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb0040000-0xb00403ff irq 19 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xb0040000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 6 pcib2: subordinate bus 7 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xb8000000-0xb80fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci6: on pcib2 pci6: physical bus=6 found-> vendor=0x14e4, dev=0x4318, revid=0x02 bus=6, slot=4, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 1, range 32, base b8004000, size 13, enabled pcib2: (null) requested memory range 0xb8004000-0xb8005fff: good pcib2: matched entry for 6.4.INTA pcib2: slot 4 INTA hardwired to IRQ 17 found-> vendor=0x104c, dev=0x8031, revid=0x00 bus=6, slot=9, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x32 (1500 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0x8032, revid=0x00 bus=6, slot=9, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x04 (1000 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8008000, size 11, enabled pcib2: (null) requested memory range 0xb8008000-0xb80087ff: good map[14]: type 1, range 32, base b8000000, size 14, enabled pcib2: (null) requested memory range 0xb8000000-0xb8003fff: good pcib2: matched entry for 6.9.INTC pcib2: slot 9 INTC hardwired to IRQ 18 found-> vendor=0x104c, dev=0x8033, revid=0x00 bus=6, slot=9, func=3 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8006000, size 13, enabled pcib2: (null) requested memory range 0xb8006000-0xb8007fff: good pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 found-> vendor=0x104c, dev=0x8034, revid=0x00 bus=6, slot=9, func=4 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base b8009000, size 8, enabled pcib2: (null) requested memory range 0xb8009000-0xb80090ff: good map[14]: type 1, range 32, base b8008c00, size 8, enabled pcib2: (null) requested memory range 0xb8008c00-0xb8008cff: good map[18]: type 1, range 32, base b8008800, size 8, enabled pcib2: (null) requested memory range 0xb8008800-0xb80088ff: good pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 ndis0: mem 0xb8004000-0xb8005fff irq 17 at device 4.0 on pci6 ndis0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xb8004000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 52 ndis0: [MPSAFE] ndis0: NDIS API version: 5.1 ndis0: bpf attached ndis0: Ethernet address: 00:14:a5:80:f5:c9 ndis0: bpf attached cbb0: at device 9.0 on pci6 pcib2: cbb0 requested memory range 0xb8000000-0xb80fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xb800a000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 6.9.INTA pcib2: slot 9 INTA hardwired to IRQ 16 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x8031104c 0x02100007 0x06070000 0x00823200 0x10: 0xb800a000 0x020000a0 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400110 0x40: 0x0365107b 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d061 0x00000000 0x000f0000 0x01ac1b22 0x90: 0x606482c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=104c, dev=8032 fwohci0: vendor=104c, dev=8032 fwohci0: <1394 Open Host Controller Interface> mem 0xb8008000-0xb80087ff,0xb8000000-0xb8003fff irq 18 at device 9.2 on pci6 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xb8008000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 54 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:b8:03:65:02:20:31 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:b8:02:20:31 fwe0: bpf attached fwe0: Ethernet address: 02:e0:b8:02:20:31 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=2, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int pci6: at device 9.3 (no driver attached) pci6: at device 9.4 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xb0040800-0xb00409ff,0xb0040400-0xb00404ff irq 21 at device 30.2 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xb0040800 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xb0040400 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 pcm0: [MPSAFE] pcm0: pcm0: Codec features reserved, headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features reserved 1, AMAP, reserved 5 pcm0: ac97 codec dac ready count: 0 pcm0: sndbuf_setmap efc6000, 4000; 0xcc2a0000 -> efc6000 pcm0: sndbuf_setmap efbc000, 4000; 0xcc2a4000 -> efbc000 pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=50 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 56 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 57 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xcf800-0xd0fff,0xdc000-0xdffff,0xe0000-0xe07ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 60 sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4e01 0x4e01 0x4e01 0x4e01 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 50488942 hz Timecounter "TSC" frequency 1514668172 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. acpi_acad0: acline initialization start battery0: battery initialization start ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ICH6 chip ad0: setting UDMA100 on ICH6 chip ad0: 57231MB at ata0-master UDMA100 ad0: 117210240 sectors [116280C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization done, tried 1 times ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on ICH6 chip acd0: setting UDMA33 on ICH6 chip acd0: CDRW drive at ata0 as slave acd0: read 689KB/s (4126KB/s) write 4126KB/s (4126KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48012 Hz, will use 48000 Hz (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s3a start_init: trying /sbin/init Linux ELF exec handler installed map[10]: type 1, range 64, base b4000000, size 14, enabled pcib2: (null) requested memory range 0xb4000000-0xb4003fff: good cbb alloc res fail map[18]: type 4, range 32, base 00003000, size 8, enabled cbb alloc res fail found-> vendor=0x11ab, dev=0x4351, revid=0x10 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit cardbus0: at device 0.0 (no driver attached) --------------040808000102040400030108--