From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 06:21:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C743106566B for ; Sun, 5 Dec 2010 06:21:04 +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 4E44E8FC12 for ; Sun, 5 Dec 2010 06:21:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB56L3JY063440 for ; Sat, 4 Dec 2010 22:21:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB56L3Kv063439 for freebsd-current@freebsd.org; Sat, 4 Dec 2010 22:21:03 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2010 22:21:03 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20101205062103.GA63430@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: wlan0 going UP/DOWN problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 06:21:04 -0000 It seems some recent change (as in the last 7-10 days) has caused an instability in wlan0. Just a small excerpt from /var/log/messages, Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP So, every 18 minutes the devices is going DOWN/UP. :-/ -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 08:59:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 912AF106566C for ; Sun, 5 Dec 2010 08:59:41 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 271118FC08 for ; Sun, 5 Dec 2010 08:59:40 +0000 (UTC) Received: by bwz2 with SMTP id 2so10135834bwz.13 for ; Sun, 05 Dec 2010 00:59:40 -0800 (PST) Received: by 10.204.113.131 with SMTP id a3mr4455225bkq.123.1291538139456; Sun, 05 Dec 2010 00:35:39 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-219-237.pools.arcor-ip.net [88.67.219.237]) by mx.google.com with ESMTPS id d11sm1132356bkd.22.2010.12.05.00.35.37 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Dec 2010 00:35:38 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Steve Kargl Date: Sun, 5 Dec 2010 09:34:46 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: <20101205062103.GA63430@troutmask.apl.washington.edu> In-Reply-To: <20101205062103.GA63430@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012050934.46566.bschmidt@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: wlan0 going UP/DOWN problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 08:59:41 -0000 On Sunday 05 December 2010 07:21:03 Steve Kargl wrote: > It seems some recent change (as in the last 7-10 days) > has caused an instability in wlan0. Just a small > excerpt from /var/log/messages, > > Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP > Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN > Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP > Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN > Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP > Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN > Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP > Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN > Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP > Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN > Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP > Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN > Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP > Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN > Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP > Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN > Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP > Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN > Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP > Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN > Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP > > So, every 18 minutes the devices is going DOWN/UP. :-/ More details please. Which driver? How is that stuff configured? wpa_supplicant involved? Try running it with debug messages enabled. We need to figure out what entity is causing the device to go down/up, this can either be wpa_supplicant or net80211 (or a cronjob calling ifconfig down/up every 18 minutes ;). The appropriate debug options enabled (wlandebug 0xffffffff or wpa_supplicant with -dd) should reveal that. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 17:24:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1076E106564A for ; Sun, 5 Dec 2010 17:24:06 +0000 (UTC) (envelope-from pierre@userid.org) Received: from mail.storm.ca (unknown [IPv6:2607:f0b0:0:6:209:87:239:66]) by mx1.freebsd.org (Postfix) with ESMTP id B72D68FC16 for ; Sun, 5 Dec 2010 17:24:05 +0000 (UTC) Received: from mail.userid.org (pandora.userid.org [216.106.102.33]) by mail.storm.ca (8.14.2+Sun/8.14.2) with ESMTP id oB5HEN7Z019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Dec 2010 12:14:29 -0500 (EST) Received: from [IPv6:2607:f0b0:1:3800:3d6f:667c:bc13:230d] (unknown [IPv6:2607:f0b0:1:3800:3d6f:667c:bc13:230d]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre) by mail.userid.org (Postfix) with ESMTP id 8FAF62C7515 for ; Sun, 5 Dec 2010 12:14:17 -0500 (EST) Message-ID: <4CFBC86D.8090602@userid.org> Date: Sun, 05 Dec 2010 12:14:21 -0500 From: Pierre Lamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-userid-MailScanner-Information: Please contact the ISP for more information X-userid-MailScanner-ID: 8FAF62C7515.ADB0C X-userid-MailScanner: Found to be clean X-userid-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.001, required 6, autolearn=not spam, NO_RELAYS -0.00) X-userid-MailScanner-From: pierre@userid.org X-Spam-Status: No Subject: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Dec 2010 17:24:06 -0000 Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? From using it for a long time in OpenBSD I always found it quite stable and easy to use. -Pierre From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 17:31:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1819F106564A for ; Sun, 5 Dec 2010 17:31:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD858FC0A for ; Sun, 5 Dec 2010 17:31:08 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id oB5HVCI6058097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Dec 2010 18:31:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id oB5HUxW8040434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Dec 2010 18:30:59 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id oB5HUx62043464; Sun, 5 Dec 2010 18:30:59 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id oB5HUxFA043463; Sun, 5 Dec 2010 18:30:59 +0100 (CET) (envelope-from ticso) Date: Sun, 5 Dec 2010 18:30:59 +0100 From: Bernd Walter To: Pierre Lamy Message-ID: <20101205173059.GG36574@cicely7.cicely.de> References: <4CFBC86D.8090602@userid.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFBC86D.8090602@userid.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 17:31:09 -0000 On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: > Just curious about why the in-kernel PPPoE interface was never ported > from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? > From using it for a long time in OpenBSD I always found it quite stable > and easy to use. The same is true with mpd/ng_pppoe. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 17:52:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 445B5106564A for ; Sun, 5 Dec 2010 17:52:28 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 058608FC08 for ; Sun, 5 Dec 2010 17:52:27 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PPIPQ-000IGK-1C for freebsd-current@freebsd.org; Sun, 05 Dec 2010 18:30:00 +0100 Date: Sun, 5 Dec 2010 18:29:55 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <439369682.20101205182955@nitronet.pl> To: Pierre Lamy In-Reply-To: <4CFBC86D.8090602@userid.org> References: <4CFBC86D.8090602@userid.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Dec 2010 17:52:28 -0000 Pierre Lamy wrote: > Just curious about why the in-kernel PPPoE interface was never ported=20 > from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? > From using it for a long time in OpenBSD I always found it quite stable > and easy to use. Have you tried netgraph-based mpd? From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 18:10:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC79106564A; Sun, 5 Dec 2010 18:10:17 +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 DC5A78FC0C; Sun, 5 Dec 2010 18:10:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB5IAGDg066862; Sun, 5 Dec 2010 10:10:16 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB5IAGQ8066861; Sun, 5 Dec 2010 10:10:16 -0800 (PST) (envelope-from sgk) Date: Sun, 5 Dec 2010 10:10:16 -0800 From: Steve Kargl To: Bernhard Schmidt Message-ID: <20101205181016.GA66750@troutmask.apl.washington.edu> References: <20101205062103.GA63430@troutmask.apl.washington.edu> <201012050934.46566.bschmidt@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012050934.46566.bschmidt@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: wlan0 going UP/DOWN problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 18:10:17 -0000 On Sun, Dec 05, 2010 at 09:34:46AM +0100, Bernhard Schmidt wrote: > On Sunday 05 December 2010 07:21:03 Steve Kargl wrote: > > It seems some recent change (as in the last 7-10 days) > > has caused an instability in wlan0. Just a small > > excerpt from /var/log/messages, > > > > Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP > > Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP > > Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP > > Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP > > Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP > > Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP > > Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP > > Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP > > Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP > > Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP > > Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN > > Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP > > > > So, every 18 minutes the devices is going DOWN/UP. :-/ > > More details please. Which driver? wpi0. > How is that stuff configured? laptop:root[204] ifconfig wpi0 wpi0: flags=8843 metric 0 mtu 2290 ether 00:1c:bf:90:ab:44 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated laptop:root[205] ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:1c:bf:90:ab:44 inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid SpartanTeepee channel 6 (2437 MHz 11g) bssid 00:18:e7:d4:f2:1b country US authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 0 bmiss 7 scanvalid 60 protmode CTS > wpa_supplicant involved? No. > Try running it with debug messages enabled. > > We need to figure out what entity is causing the device to go down/up, this > can either be wpa_supplicant or net80211 (or a cronjob calling ifconfig > down/up every 18 minutes ;). The appropriate debug options enabled (wlandebug > 0xffffffff or wpa_supplicant with -dd) should reveal that. laptop:root[209] wlandebug wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory Looks like I need to rebuild the kernel. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 20:30:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78776106564A for ; Sun, 5 Dec 2010 20:30:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-33.mx.aerioconnect.net [216.240.47.93]) by mx1.freebsd.org (Postfix) with ESMTP id 592E98FC15 for ; Sun, 5 Dec 2010 20:30:27 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oB5KUMCE029700; Sun, 5 Dec 2010 12:30:23 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 885A42D6015; Sun, 5 Dec 2010 12:30:21 -0800 (PST) Message-ID: <4CFBF658.4060705@freebsd.org> Date: Sun, 05 Dec 2010 12:30:16 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: ticso@cicely.de References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> In-Reply-To: <20101205173059.GG36574@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Bernd Walter , Pierre Lamy , freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Dec 2010 20:30:27 -0000 On 12/5/10 9:30 AM, Bernd Walter wrote: > On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: >> Just curious about why the in-kernel PPPoE interface was never ported >> from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? > Maybe because everyone who cares about in-kernel uses the FreeBSD > in-kernel ng_pppoe via mpd? > >> From using it for a long time in OpenBSD I always found it quite stable >> and easy to use. > The same is true with mpd/ng_pppoe. while I like mpd, I should point out that the regular 'in source' ppp that comes with freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my gateway as I never got around to installing mpd and it "did the job". From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 21:12:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D22E1106566C for ; Sun, 5 Dec 2010 21:12:41 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 429698FC1A for ; Sun, 5 Dec 2010 21:12:40 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id oB5LClQC065979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Dec 2010 22:12:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id oB5LCQbv047831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Dec 2010 22:12:26 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id oB5LCQRL044424; Sun, 5 Dec 2010 22:12:26 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id oB5LCPDc044423; Sun, 5 Dec 2010 22:12:25 +0100 (CET) (envelope-from ticso) Date: Sun, 5 Dec 2010 22:12:25 +0100 From: Bernd Walter To: Julian Elischer Message-ID: <20101205211224.GL36574@cicely7.cicely.de> References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFBF658.4060705@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter , ticso@cicely.de, Pierre Lamy , freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 21:12:41 -0000 On Sun, Dec 05, 2010 at 12:30:16PM -0800, Julian Elischer wrote: > On 12/5/10 9:30 AM, Bernd Walter wrote: > >On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: > >>Just curious about why the in-kernel PPPoE interface was never ported > >>from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? > >Maybe because everyone who cares about in-kernel uses the FreeBSD > >in-kernel ng_pppoe via mpd? > > > >> From using it for a long time in OpenBSD I always found it quite stable > >>and easy to use. > >The same is true with mpd/ng_pppoe. > while I like mpd, I should point out that the regular 'in source' ppp No surprise that you like it ;-) > that comes with > freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x > 7 on my gateway > as I never got around to installing mpd and it "did the job". Same for me if the machine's power is good enough, but my Router is a tiny FreeBSD/ARM, which has trouble to keep up with load if running traffic via userland. I use mpd together with ipfw nat to keep traffic in kernel. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 23:18:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C1C1065679 for ; Sun, 5 Dec 2010 23:18:31 +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 8BE4E8FC18 for ; Sun, 5 Dec 2010 23:18:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB5NIU3V068167 for ; Sun, 5 Dec 2010 15:18:30 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB5NITJL068166 for freebsd-current@freebsd.org; Sun, 5 Dec 2010 15:18:29 -0800 (PST) (envelope-from sgk) Date: Sun, 5 Dec 2010 15:18:29 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20101205231829.GA68156@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Dec 2010 23:18:31 -0000 Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 69.55 real 38.39 user 30.94 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 68.82 real 40.95 user 27.60 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 69.14 real 38.90 user 30.02 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 68.79 real 40.59 user 27.99 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 68.93 real 39.76 user 28.96 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 68.71 real 41.21 user 27.29 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 69.05 real 39.68 user 29.15 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 68.99 real 39.98 user 28.80 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 69.02 real 39.64 user 29.16 sys Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 69.38 real 37.49 user 31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Dec 5 23:32:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74491106566C; Sun, 5 Dec 2010 23:32:41 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 887DA8FC15; Sun, 5 Dec 2010 23:32:39 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA26759; Mon, 06 Dec 2010 01:32:37 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPO4L-0009hD-84; Mon, 06 Dec 2010 01:32:37 +0200 Message-ID: <4CFC2114.6040203@freebsd.org> Date: Mon, 06 Dec 2010 01:32:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> In-Reply-To: <4CFBF658.4060705@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Dec 2010 23:32:41 -0000 on 05/12/2010 22:30 Julian Elischer said the following: > On 12/5/10 9:30 AM, Bernd Walter wrote: >> On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: >>> Just curious about why the in-kernel PPPoE interface was never ported >>> from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? >> Maybe because everyone who cares about in-kernel uses the FreeBSD >> in-kernel ng_pppoe via mpd? >> >>> From using it for a long time in OpenBSD I always found it quite stable >>> and easy to use. >> The same is true with mpd/ng_pppoe. > while I like mpd, I should point out that the regular 'in source' ppp that comes > with > freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my > gateway > as I never got around to installing mpd and it "did the job". BTW, there is a rumor that mpd may become an 'in source' program too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 00:00:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1686F106566B for ; Mon, 6 Dec 2010 00:00:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-37.mx.aerioconnect.net [216.240.47.97]) by mx1.freebsd.org (Postfix) with ESMTP id B54AB8FC0A for ; Mon, 6 Dec 2010 00:00:35 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oB600YI8008669; Sun, 5 Dec 2010 16:00:34 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id B59AA2D6015; Sun, 5 Dec 2010 16:00:33 -0800 (PST) Message-ID: <4CFC27A0.8000406@freebsd.org> Date: Sun, 05 Dec 2010 16:00:32 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Steve Kargl References: <20101205231829.GA68156@troutmask.apl.washington.edu> In-Reply-To: <20101205231829.GA68156@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 00:00:36 -0000 On 12/5/10 3:18 PM, Steve Kargl wrote: > Sometime in the last 7-10 days, some one made a > change that has broken process accounting/timing. > > laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > foreach? time ./testf > foreach? end > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.55 real 38.39 user 30.94 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.82 real 40.95 user 27.60 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.14 real 38.90 user 30.02 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.79 real 40.59 user 27.99 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.93 real 39.76 user 28.96 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.71 real 41.21 user 27.29 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.05 real 39.68 user 29.15 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.99 real 39.98 user 28.80 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.02 real 39.64 user 29.16 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.38 real 37.49 user 31.67 sys > > testf is a numerically intensive program that tests the > accuracy of expf() in a tight loop. User time varies > by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > I'm fairly certain that the code does not suddenly grow/loose > 6 GFLOP of operations. > I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an "old hand" you can check out sources at different revisions.. From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 00:07:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 820E6106566C for ; Mon, 6 Dec 2010 00:07:23 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 416478FC16 for ; Mon, 6 Dec 2010 00:07:23 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PPOby-000C1Z-I2 for freebsd-current@freebsd.org; Mon, 06 Dec 2010 01:07:22 +0100 Date: Mon, 6 Dec 2010 01:07:17 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <164793553.20101206010717@nitronet.pl> To: Andriy Gapon In-Reply-To: <4CFC2114.6040203@freebsd.org> References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> <4CFC2114.6040203@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 00:07:23 -0000 Andriy Gapon wrote: >> as I never got around to installing mpd and it "did the job". > BTW, there is a rumor that mpd may become an 'in source' program too. Not to paraphrase the muppet show, but... 'the question is... who cares?' :> --=20 This e-mail was sponsored by the letters 'please GTFO with bind from the base' and the number 1338 ;) From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 01:45:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67AD106564A; Mon, 6 Dec 2010 01:45:55 +0000 (UTC) (envelope-from sdrhodus@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E42AB8FC08; Mon, 6 Dec 2010 01:45:54 +0000 (UTC) Received: by wyf19 with SMTP id 19so11706231wyf.13 for ; Sun, 05 Dec 2010 17:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+qJODSXdS9qeN/5SfuCq4Ntqm/a8sh7DNevGE1nny7s=; b=N3lvKbDYTd5gfChuifTHl8RjxMGOqAg0dXeRpGzA5RJhuDhj5ozoKv8XTNmCnPAQi6 O9XPv2FKywkRaUaiPYSCDGFN6r5EwvQueTYN8wbxJWUq7sxQg+lJf2nXDeo1KkFg1iiw 2imjuQHZ0pjI/7fnItZP9KaNfxIE6jSIcaW70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LN0GvVPQUe0wGijwMMKmza3Mg2/kZY8q7UvPDOBBsaAgdIbbumHsid+dgZhn62PUUj OKGIKpO6aHB/+7ZttwKOJjwNCRrI1gvtfhonAwx7ThMYknZU/FcS/NQL2E/DCqaAh9TY wBT5dwLVTyv42szQy6m0S6WriTtO0BuddBzHY= Received: by 10.216.24.134 with SMTP id x6mr935356wex.34.1291599953743; Sun, 05 Dec 2010 17:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.4.10 with HTTP; Sun, 5 Dec 2010 17:45:33 -0800 (PST) In-Reply-To: <4CFC2114.6040203@freebsd.org> References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> <4CFC2114.6040203@freebsd.org> From: David Rhodus Date: Sun, 5 Dec 2010 20:45:33 -0500 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 01:45:55 -0000 On Sun, Dec 5, 2010 at 6:32 PM, Andriy Gapon wrote: > on 05/12/2010 22:30 Julian Elischer said the following: >> On 12/5/10 9:30 AM, Bernd Walter wrote: >>> On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: >>>> Just curious about why the in-kernel PPPoE interface was never ported >>>> from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? >>> Maybe because everyone who cares about in-kernel uses the FreeBSD >>> in-kernel ng_pppoe via mpd? >>> >>>> =A0From using it for a long time in OpenBSD I always found it quite st= able >>>> and easy to use. >>> The same is true with mpd/ng_pppoe. >> while I like mpd, I should point out that the regular 'in source' ppp th= at comes >> with >> freebsd also uses the in-kernel netgraph pppoe module. =A0 I use it 24 x= 7 on my >> gateway >> as I never got around to installing mpd and it "did the job". > > BTW, there is a rumor that mpd may become an 'in source' program too. > > > -- > Andriy Gapon Does mpd work in -current ? Last tried I, netgraph had problems with mpd. From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 03:08:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B40106564A for ; Mon, 6 Dec 2010 03:08:45 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 573DB8FC13 for ; Mon, 6 Dec 2010 03:08:45 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id oB62UBUU069487 for ; Sun, 5 Dec 2010 20:30:11 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=LKKxmGyfRObozfvC7jjxJeJZrRXm0da4Z8u9tkh/5fDo3k8pRTQ6Tzz7TvlOUaJ2n sXs7JNObN+/CSUP4RTGbgl48RC8Dr/XC1OQhnwhCHrXzSsTwcbpmvN37QqNiDyoMZnA f/HJ3Xsp30k9lPHtIN/uCwx7rmpRzXnEQLH83uU= Message-ID: <4CFC4AB3.4090604@jrv.org> Date: Sun, 05 Dec 2010 20:30:11 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 03:08:45 -0000 FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 23:20:14 CST 2010 root@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 I have been getting a lot of ts_to_ct for months: are we supposed to look for something or report anything about these? I just noticed an NTP error in /var/log/messages: ... Dec 4 02:52:18 gohorns kernel: ts_to_ct(1291431138.717914676) = [2010-12-04 02:52:18] Dec 4 03:09:05 gohorns ntpd[1934]: time reset +2.018106 s Dec 4 03:09:05 gohorns kernel: ts_to_ct(1291432145.779273676) = [2010-12-04 03:09:05] Dec 4 03:11:40 gohorns kernel: ts_to_ct(1291432301.024288164) = [2010-12-04 03:11:41] Dec 4 03:45:36 gohorns ntpd[1934]: time reset +1.976613 s Dec 4 03:45:36 gohorns kernel: ts_to_ct(1291434336.662385061) = [2010-12-04 03:45:36] Dec 4 03:45:36 gohorns ntpd[1934]: kernel time sync status change 6001 Dec 4 03:45:36 gohorns kernel: ts_to_ct(1291434336.712917848) = [2010-12-04 03:45:36] Dec 4 03:46:38 gohorns ntpd[1934]: time correction of -1200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Dec 4 04:15:36 gohorns kernel: ts_to_ct(1291436136.712892982) = [2010-12-04 04:15:36] Dec 4 04:45:36 gohorns kernel: ts_to_ct(1291437936.712891437) = [2010-12-04 04:45:36] Dec 4 05:15:36 gohorns kernel: ts_to_ct(1291439736.712890731) = [2010-12-04 05:15:36] ... At "Sun Dec 5 19:56:19 CST 2010" according to other systems, this machine says the time is gohorns:/root# date Sun Dec 5 20:11:01 CST 2010 gohorns:/root# Has anyone seen anything like this? Suggestions on what to look for as a cause? The system is a Dell Zino HD, dmesg: CPU: AMD Athlon(tm) Neo X2 Dual Core Processor 6850e (1800.10-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Family = f Model = 6b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:12:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2578A106566B; Mon, 6 Dec 2010 06:12:31 +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 F09718FC19; Mon, 6 Dec 2010 06:12:30 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB66CUDv069505; Sun, 5 Dec 2010 22:12:30 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB66CUd7069504; Sun, 5 Dec 2010 22:12:30 -0800 (PST) (envelope-from sgk) Date: Sun, 5 Dec 2010 22:12:30 -0800 From: Steve Kargl To: Julian Elischer Message-ID: <20101206061230.GA69477@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFC27A0.8000406@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:12:31 -0000 On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: > On 12/5/10 3:18 PM, Steve Kargl wrote: > >Sometime in the last 7-10 days, some one made a > >change that has broken process accounting/timing. > > > >laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > >foreach? time ./testf > >foreach? end > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.55 real 38.39 user 30.94 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.82 real 40.95 user 27.60 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.14 real 38.90 user 30.02 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.79 real 40.59 user 27.99 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.93 real 39.76 user 28.96 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.71 real 41.21 user 27.29 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.05 real 39.68 user 29.15 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.99 real 39.98 user 28.80 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.02 real 39.64 user 29.16 sys > >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.38 real 37.49 user 31.67 sys > > > >testf is a numerically intensive program that tests the > >accuracy of expf() in a tight loop. User time varies > >by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > >I'm fairly certain that the code does not suddenly grow/loose > >6 GFLOP of operations. > > > I know it's a lot to ask but it may be something that you can help > with if you > had the time to triangulate in on the change that did it.. > I presume that since you are an "old hand" you can check out sources > at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:19:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434E6106566B; Mon, 6 Dec 2010 06:19:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA588FC15; Mon, 6 Dec 2010 06:19:13 +0000 (UTC) Received: by wwf26 with SMTP id 26so7486648wwf.31 for ; Sun, 05 Dec 2010 22:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QyvzREL/NO9Th1BugKaqU07Dgnfa14p3tO4eWQrKWYM=; b=u24fUjgzILJG+tGIal53eed0W3b1OC6G4b1txPOSinFzNmtFv8aJ+4s9j0o6Q1FBaJ l7K1BqKnVp6mSMSuQGElTATajWO2VYYwFOuwuyzThGD0IP4vjqQGuEhXKJzfMmA8efUi kxhjDlq1JvG9TEOyJHYipE3P9CfXqhuiZmNsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WpxE9uGtHv77Weq5jV3X2UCi9nKLxxufBqRIVwcsgcUMZvwLK4NrW2dwQzl+ztOPeV sofO+f+1cb6t8WVK6l7gU+Hs4VFIplaqlVRxIAaG9q6jB/HPP2mmmHKBaGaBW0izC/Gg wPBnoXR9A74BSe4xjK1V5kqnGbx+QuyB6smwI= MIME-Version: 1.0 Received: by 10.216.168.136 with SMTP id k8mr1255904wel.45.1291616352560; Sun, 05 Dec 2010 22:19:12 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 5 Dec 2010 22:19:12 -0800 (PST) In-Reply-To: <20101206061230.GA69477@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@troutmask.apl.washington.edu> Date: Sun, 5 Dec 2010 22:19:12 -0800 X-Google-Sender-Auth: lCDhp5_cIZP0Sr-20T1Y6T9bfvI Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:19:14 -0000 On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl wrote: > On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: >> On 12/5/10 3:18 PM, Steve Kargl wrote: >> >Sometime in the last 7-10 days, some one made a >> >change that has broken process accounting/timing. >> > >> >laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >> >foreach? time ./testf >> >foreach? end >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A069.55 real =A0 =A0 =A0 =A038.39 user =A0 =A0 =A0 =A030.= 94 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A068.82 real =A0 =A0 =A0 =A040.95 user =A0 =A0 =A0 =A027.= 60 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A069.14 real =A0 =A0 =A0 =A038.90 user =A0 =A0 =A0 =A030.= 02 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A068.79 real =A0 =A0 =A0 =A040.59 user =A0 =A0 =A0 =A027.= 99 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A068.93 real =A0 =A0 =A0 =A039.76 user =A0 =A0 =A0 =A028.= 96 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A068.71 real =A0 =A0 =A0 =A041.21 user =A0 =A0 =A0 =A027.= 29 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A069.05 real =A0 =A0 =A0 =A039.68 user =A0 =A0 =A0 =A029.= 15 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A068.99 real =A0 =A0 =A0 =A039.98 user =A0 =A0 =A0 =A028.= 80 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A069.02 real =A0 =A0 =A0 =A039.64 user =A0 =A0 =A0 =A029.= 16 sys >> >Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.067100e= -04 >> > =A0 =A0 =A0 =A069.38 real =A0 =A0 =A0 =A037.49 user =A0 =A0 =A0 =A031.= 67 sys >> > >> >testf is a numerically intensive program that tests the >> >accuracy of expf() in a tight loop. =A0User time varies >> >by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >> >I'm fairly certain that the code does not suddenly grow/loose >> >6 GFLOP of operations. >> > >> I know it's a lot to ask but it may be something that you can help >> with if you >> had the time to triangulate in on the change that did it.. >> I presume that since you are an "old hand" you can check out sources >> at different revisions.. > > I was hoping that someone (possibly the person responsible) would > recognize the symptoms and recommend a revision or two to revert. > Otherwise, doing a binary search will take some time in that it > takes 4+ hours for a buildworld/kernel cycle on my laptop. If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:22:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E43E106564A for ; Mon, 6 Dec 2010 06:22:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3AB8FC08 for ; Mon, 6 Dec 2010 06:22:38 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oB66MbR4024029; Sun, 5 Dec 2010 22:22:37 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 291312D6014; Sun, 5 Dec 2010 22:22:35 -0800 (PST) Message-ID: <4CFC812B.9060505@freebsd.org> Date: Sun, 05 Dec 2010 22:22:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@troutmask.apl.washington.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:22:38 -0000 On 12/5/10 10:19 PM, Garrett Cooper wrote: > On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl > wrote: >> On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: >>> On 12/5/10 3:18 PM, Steve Kargl wrote: >>>> Sometime in the last 7-10 days, some one made a >>>> change that has broken process accounting/timing. >>>> >>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >>>> foreach? time ./testf >>>> foreach? end >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.55 real 38.39 user 30.94 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.82 real 40.95 user 27.60 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.14 real 38.90 user 30.02 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.79 real 40.59 user 27.99 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.93 real 39.76 user 28.96 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.71 real 41.21 user 27.29 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.05 real 39.68 user 29.15 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.99 real 39.98 user 28.80 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.02 real 39.64 user 29.16 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.38 real 37.49 user 31.67 sys >>>> >>>> testf is a numerically intensive program that tests the >>>> accuracy of expf() in a tight loop. User time varies >>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >>>> I'm fairly certain that the code does not suddenly grow/loose >>>> 6 GFLOP of operations. >>>> >>> I know it's a lot to ask but it may be something that you can help >>> with if you >>> had the time to triangulate in on the change that did it.. >>> I presume that since you are an "old hand" you can check out sources >>> at different revisions.. >> I was hoping that someone (possibly the person responsible) would >> recognize the symptoms and recommend a revision or two to revert. >> Otherwise, doing a binary search will take some time in that it >> takes 4+ hours for a buildworld/kernel cycle on my laptop. > If you can provide the source for the application you're running > above and instructions on how to compile it, I can at least give you a > bit of a head start :). > Thanks, > -Garrett > plus which probably just `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` would be enough... From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:24:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB82F106566C; Mon, 6 Dec 2010 06:24:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52F358FC15; Mon, 6 Dec 2010 06:24:13 +0000 (UTC) Received: by wyf19 with SMTP id 19so11863615wyf.13 for ; Sun, 05 Dec 2010 22:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lNeFIC1K9qGN6xe1DRZpNF1zAHAcnhQ2fpzaNjnjS7o=; b=GKwapV5oNsc5SQVFRAJAOJkvnmpEkBTtg+/rgN//upv2rd3h3r/FkCz8n44625U07H bv0Su+VxOafX9GVjy6xt1Gz0iGqCJjduF8qEoo37WB85QaAFvNJQ5kgCE3pq5Ud28H/4 njtFbW/rZuAm2wFpjyF1t8g58AW9luwFI5prU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=K/bIYjE5p2tUilG6nnN6Hs34on//JSEkEHvlViIPP+/G9qopO8hR0xHV6FtgRMHSAZ yIFDPGhQ9AyjMLRcwkwQGz1914RdxrYgPLQAX8G2T2PXbQ9v9k5eDJtLh9dFV+ma/xjv kC9E76No17K7BZVZLX7WAoDCXOnaAxTLh5z2c= MIME-Version: 1.0 Received: by 10.216.168.136 with SMTP id k8mr1259639wel.45.1291616652987; Sun, 05 Dec 2010 22:24:12 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 5 Dec 2010 22:24:12 -0800 (PST) In-Reply-To: <4CFC812B.9060505@freebsd.org> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@troutmask.apl.washington.edu> <4CFC812B.9060505@freebsd.org> Date: Sun, 5 Dec 2010 22:24:12 -0800 X-Google-Sender-Auth: mR-tZrEM2c4O-wdGQUNbVE1ODRQ Message-ID: From: Garrett Cooper To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:24:15 -0000 On Sun, Dec 5, 2010 at 10:22 PM, Julian Elischer wrote= : > On 12/5/10 10:19 PM, Garrett Cooper wrote: >> >> On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl >> =A0wrote: >>> >>> On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: >>>> >>>> On 12/5/10 3:18 PM, Steve Kargl wrote: >>>>> >>>>> Sometime in the last 7-10 days, some one made a >>>>> change that has broken process accounting/timing. >>>>> >>>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >>>>> foreach? time ./testf >>>>> foreach? end >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A069.55 real =A0 =A0 =A0 =A038.39 user =A0 =A0 =A0 =A030= .94 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A068.82 real =A0 =A0 =A0 =A040.95 user =A0 =A0 =A0 =A027= .60 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A069.14 real =A0 =A0 =A0 =A038.90 user =A0 =A0 =A0 =A030= .02 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A068.79 real =A0 =A0 =A0 =A040.59 user =A0 =A0 =A0 =A027= .99 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A068.93 real =A0 =A0 =A0 =A039.76 user =A0 =A0 =A0 =A028= .96 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A068.71 real =A0 =A0 =A0 =A041.21 user =A0 =A0 =A0 =A027= .29 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A069.05 real =A0 =A0 =A0 =A039.68 user =A0 =A0 =A0 =A029= .15 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A068.99 real =A0 =A0 =A0 =A039.98 user =A0 =A0 =A0 =A028= .80 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A069.02 real =A0 =A0 =A0 =A039.64 user =A0 =A0 =A0 =A029= .16 sys >>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D >>>>> 1.067100e-04 >>>>> =A0 =A0 =A0 =A069.38 real =A0 =A0 =A0 =A037.49 user =A0 =A0 =A0 =A031= .67 sys >>>>> >>>>> testf is a numerically intensive program that tests the >>>>> accuracy of expf() in a tight loop. =A0User time varies >>>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >>>>> I'm fairly certain that the code does not suddenly grow/loose >>>>> 6 GFLOP of operations. >>>>> >>>> I know it's a lot to ask but it may be something that you can help >>>> with if you >>>> had the time to triangulate in on the change that did it.. >>>> I presume that since you are an "old hand" you can check out sources >>>> at different revisions.. >>> >>> I was hoping that someone (possibly the person responsible) would >>> recognize the symptoms and recommend a revision or two to revert. >>> Otherwise, doing a binary search will take some time in that it >>> takes 4+ hours for a buildworld/kernel cycle on my laptop. >> >> =A0 =A0 If you can provide the source for the application you're running >> above and instructions on how to compile it, I can at least give you a >> bit of a head start :). >> Thanks, >> -Garrett >> > plus which probably just > `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` > =A0would be enough... But couldn't it be libthr changes? There have been a handful of those that have been committed recently by davidxu. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:27:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 539C71065673 for ; Mon, 6 Dec 2010 06:27:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 304208FC13 for ; Mon, 6 Dec 2010 06:27:21 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oB66RK6e024194; Sun, 5 Dec 2010 22:27:20 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 2BFF32D6011; Sun, 5 Dec 2010 22:27:18 -0800 (PST) Message-ID: <4CFC8246.4040507@freebsd.org> Date: Sun, 05 Dec 2010 22:27:18 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@troutmask.apl.washington.edu> <4CFC812B.9060505@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:27:23 -0000 On 12/5/10 10:24 PM, Garrett Cooper wrote: > On Sun, Dec 5, 2010 at 10:22 PM, Julian Elischer wrote: >> On 12/5/10 10:19 PM, Garrett Cooper wrote: >>> On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl >>> wrote: >>>> On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: >>>>> On 12/5/10 3:18 PM, Steve Kargl wrote: >>>>>> Sometime in the last 7-10 days, some one made a >>>>>> change that has broken process accounting/timing. >>>>>> >>>>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >>>>>> foreach? time ./testf >>>>>> foreach? end >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 69.55 real 38.39 user 30.94 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 68.82 real 40.95 user 27.60 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 69.14 real 38.90 user 30.02 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 68.79 real 40.59 user 27.99 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 68.93 real 39.76 user 28.96 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 68.71 real 41.21 user 27.29 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 69.05 real 39.68 user 29.15 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 68.99 real 39.98 user 28.80 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 69.02 real 39.64 user 29.16 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = >>>>>> 1.067100e-04 >>>>>> 69.38 real 37.49 user 31.67 sys >>>>>> >>>>>> testf is a numerically intensive program that tests the >>>>>> accuracy of expf() in a tight loop. User time varies >>>>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >>>>>> I'm fairly certain that the code does not suddenly grow/loose >>>>>> 6 GFLOP of operations. >>>>>> >>>>> I know it's a lot to ask but it may be something that you can help >>>>> with if you >>>>> had the time to triangulate in on the change that did it.. >>>>> I presume that since you are an "old hand" you can check out sources >>>>> at different revisions.. >>>> I was hoping that someone (possibly the person responsible) would >>>> recognize the symptoms and recommend a revision or two to revert. >>>> Otherwise, doing a binary search will take some time in that it >>>> takes 4+ hours for a buildworld/kernel cycle on my laptop. >>> If you can provide the source for the application you're running >>> above and instructions on how to compile it, I can at least give you a >>> bit of a head start :). >>> Thanks, >>> -Garrett >>> >> plus which probably just >> `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` >> would be enough... > But couldn't it be libthr changes? There have been a handful of > those that have been committed recently by davidxu. Unlikely as there was no mention of there being any thread involvement. probably just replacing the kernel would be enough.. It'd be easy to find out.. see if one 2 weeks old fixes the problem :-) > HTH, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:49:22 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950761065679; Mon, 6 Dec 2010 06:49:22 +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 6F04B8FC08; Mon, 6 Dec 2010 06:49:22 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB66nMVU069708; Sun, 5 Dec 2010 22:49:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB66nMFk069707; Sun, 5 Dec 2010 22:49:22 -0800 (PST) (envelope-from sgk) Date: Sun, 5 Dec 2010 22:49:22 -0800 From: Steve Kargl To: Garrett Cooper Message-ID: <20101206064922.GA69683@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@troutmask.apl.washington.edu> <4CFC812B.9060505@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:49:22 -0000 On Sun, Dec 05, 2010 at 10:24:12PM -0800, Garrett Cooper wrote: > > But couldn't it be libthr changes? There have been a handful of > those that have been committed recently by davidxu. > HTH, There is no threading involved in the application. However, it was David's recent changes that caused me to upgrade from a 7-10 day old install. The recent libthr chnages have improved the stalling that I experience with firefox. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 06:58:59 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5A6A106564A; Mon, 6 Dec 2010 06:58:59 +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 A47558FC0A; Mon, 6 Dec 2010 06:58:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB66wxeR069759; Sun, 5 Dec 2010 22:58:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB66wxOu069758; Sun, 5 Dec 2010 22:58:59 -0800 (PST) (envelope-from sgk) Date: Sun, 5 Dec 2010 22:58:59 -0800 From: Steve Kargl To: Garrett Cooper Message-ID: <20101206065859.GB69683@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <4CFC27A0.8000406@freebsd.org> <20101206061230.GA69477@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.3i Cc: freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 06:58:59 -0000 On Sun, Dec 05, 2010 at 10:19:12PM -0800, Garrett Cooper wrote: > > If you can provide the source for the application you're running > above and instructions on how to compile it, I can at least give you a > bit of a head start :). > Thanks, > -Garrett The app is statically linked. I can give you the binary. Compiling the code would be a pain. You need mpfr and gmp from ports and you would need to patch libm with my expf implementation. Unfortunately, I have extensive libm patches that will take sometime to unravel for only my expf file. My give my a 1/2 hour. I recompile with standard libm expf. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 14:04:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F1B7106564A for ; Mon, 6 Dec 2010 14:04:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E4DB08FC08 for ; Mon, 6 Dec 2010 14:04:13 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oB6E4AGM051722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2010 16:04:10 +0200 (EET) (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.14.4/8.14.4) with ESMTP id oB6E49da067387; Mon, 6 Dec 2010 16:04:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oB6E49M0067386; Mon, 6 Dec 2010 16:04:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Dec 2010 16:04:09 +0200 From: Kostik Belousov To: "James R. Van Artsdalen" Message-ID: <20101206140409.GC2417@deviant.kiev.zoral.com.ua> References: <4CFC4AB3.4090604@jrv.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline In-Reply-To: <4CFC4AB3.4090604@jrv.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 14:04:14 -0000 --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote: > FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 > 23:20:14 CST 2010 root@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > I have been getting a lot of ts_to_ct for months: are we supposed to > look for something or report anything about these? They should be silenced. I have this local change for too long, will commit it shortly unless somebody objects: diff --git a/sys/kern/subr_clock.c b/sys/kern/subr_clock.c index 4e7bcd0..c04b5ac 100644 --- a/sys/kern/subr_clock.c +++ b/sys/kern/subr_clock.c @@ -49,7 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include =20 -#define ct_debug bootverbose +static int ct_debug; static int adjkerntz; /* local offset from UTC in seconds */ static int wall_cmos_clock; /* wall CMOS clock assumed if !=3D 0 */ =20 --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkz87VkACgkQC3+MBN1Mb4hjfQCgksji9kx/DjkXqPdE7kVrwzgn VmIAn2DOzIzB+Yoco2+eCY1oxm/Tz07I =vC8b -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 14:15:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BC8E106566B for ; Mon, 6 Dec 2010 14:15:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id C80298FC19 for ; Mon, 6 Dec 2010 14:15:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C48AC41C729; Mon, 6 Dec 2010 15:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Ux8AZIwyOPRG; Mon, 6 Dec 2010 15:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id CF6C541C712; Mon, 6 Dec 2010 15:15:05 +0100 (CET) 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 0B5474448F3; Mon, 6 Dec 2010 14:10:49 +0000 (UTC) Date: Mon, 6 Dec 2010 14:10:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kostik Belousov In-Reply-To: <20101206140409.GC2417@deviant.kiev.zoral.com.ua> Message-ID: <20101206140932.S6126@maildrop.int.zabbadoz.net> References: <4CFC4AB3.4090604@jrv.org> <20101206140409.GC2417@deviant.kiev.zoral.com.ua> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , "James R. Van Artsdalen" Subject: Re: ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 14:15:08 -0000 On Mon, 6 Dec 2010, Kostik Belousov wrote: > On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote: >> FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 >> 23:20:14 CST 2010 root@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 >> >> I have been getting a lot of ts_to_ct for months: are we supposed to >> look for something or report anything about these? > They should be silenced. I have this local change for too long, will > commit it shortly unless somebody objects: > > diff --git a/sys/kern/subr_clock.c b/sys/kern/subr_clock.c > index 4e7bcd0..c04b5ac 100644 > --- a/sys/kern/subr_clock.c > +++ b/sys/kern/subr_clock.c > @@ -49,7 +49,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > > -#define ct_debug bootverbose > +static int ct_debug; > static int adjkerntz; /* local offset from UTC in seconds */ > static int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ I have actually been using this one for two months now, which allows you to enable it if you want the debugging. --- sys/kern/subr_clock.c.orig 2010-11-14 16:10:15.000000000 +0000 +++ sys/kern/subr_clock.c 2010-12-04 23:39:51.000000000 +0000 @@ -49,7 +49,7 @@ __FBSDID("$FreeBSD: src/sys/kern/subr_cl #include #include -#define ct_debug bootverbose +static int ct_debug; static int adjkerntz; /* local offset from UTC in seconds */ static int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ @@ -60,6 +60,8 @@ int tz_dsttime; * This have traditionally been in machdep, but should probably be moved to * kern. */ +SYSCTL_INT(_machdep, OID_AUTO, ct_debug, + CTLFLAG_RW, &ct_debug, 0, "Print ct debug if enabled."); SYSCTL_INT(_machdep, OID_AUTO, wall_cmos_clock, CTLFLAG_RW, &wall_cmos_clock, 0, "CMOS clock keeps wall time"); -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 14:41:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71FF1065673; Mon, 6 Dec 2010 14:41:32 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 41CC28FC1E; Mon, 6 Dec 2010 14:41:32 +0000 (UTC) Received: from [41.154.88.20] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1PPbbC-0004eP-0g; Mon, 06 Dec 2010 15:59:26 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PPbbA-00012z-K3; Mon, 06 Dec 2010 15:59:24 +0200 Message-Id: To: David Rhodus From: Ian FREISLICH In-Reply-To: References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> <4CFC2114.6040203@freebsd.org> X-Attribution: BOFH Date: Mon, 06 Dec 2010 15:59:24 +0200 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 14:41:32 -0000 David Rhodus wrote: > Does mpd work in -current ? Last tried I, netgraph had problems with mpd. I have successfully used it on -CURRENT as late as: FreeBSD mini 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Wed Nov 17 07:11:06 SAST 2010 ianf@mini:/usr/obj/usr/src/sys/APPLE i386 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 14:45:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E331065672; Mon, 6 Dec 2010 14:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id F321F8FC13; Mon, 6 Dec 2010 14:45:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5618A41C733; Mon, 6 Dec 2010 15:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id xBuHkKWs8s+i; Mon, 6 Dec 2010 15:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 86D7D41C730; Mon, 6 Dec 2010 15:45:05 +0100 (CET) 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 0D81344490B; Mon, 6 Dec 2010 14:40:19 +0000 (UTC) Date: Mon, 6 Dec 2010 14:40:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andriy Gapon In-Reply-To: <4CFC2114.6040203@freebsd.org> Message-ID: <20101206141201.O6126@maildrop.int.zabbadoz.net> References: <4CFBC86D.8090602@userid.org> <20101205173059.GG36574@cicely7.cicely.de> <4CFBF658.4060705@freebsd.org> <4CFC2114.6040203@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 14:45:07 -0000 On Mon, 6 Dec 2010, Andriy Gapon wrote: > BTW, there is a rumor that mpd may become an 'in source' program too. It comes 'in source';-) I think last time it came up for base, the package ended up being in the dataset of the release packages and I think that's fine enough. I cannot see any advantage having it in base. I could see a lot more advantage with someone picking up the netgraph problem reports and fixing them... /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 15:15:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E38106564A for ; Mon, 6 Dec 2010 15:15:37 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 870568FC0A for ; Mon, 6 Dec 2010 15:15:37 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1PPcmt-00020O-Pj; Mon, 06 Dec 2010 15:15:36 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PPcmt-0007ZA-KK; Mon, 06 Dec 2010 15:15:35 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id oB6FFZZm055435; Mon, 6 Dec 2010 15:15:35 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id oB6FFZVS055434; Mon, 6 Dec 2010 15:15:35 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Mon, 6 Dec 2010 15:15:30 +0000 From: Anton Shterenlikht To: Dimitry Andric Message-ID: <20101206151530.GA55368@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Dimitry Andric , freebsd-current@freebsd.org, Marcel Moolenaar References: <20101203095831.GA5468@mech-cluster241.men.bris.ac.uk> <4CF982D9.7070602@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF982D9.7070602@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: binutils problem? WAS [Re: static linking error: ELF binary type "0" not known. Exec format error. Binary file not executable.] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 15:15:37 -0000 On Sat, Dec 04, 2010 at 12:52:57AM +0100, Dimitry Andric wrote: > On 2010-12-03 10:58, Anton Shterenlikht wrote: > >>>a.out: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically > >>>linked, not stripped > ... > >>The branding on ia64 is wrong. The executable is not marked as being > >>a FreeBSD executable. It's declared as SYSV, whereas on amd64 it's > >>properly declared as FreeBSD. > >> > >>This is a binutils problem. > ... > >Anybody here can explain better what Marcel means > >by "binutils problem", and how to fix it? > > > >I've binutils-2.20.1_3 installed from devel/binutils. > > The problem is that our base binutils's BFD library has a custom hack to > 'brand' the produced executables, e.g. set the ELF_OSABI field in the > ELF header to ELFOSABI_FREEBSD. > > Other arches such as i386, amd64 (x86_64 in binutils land), sparc and > even alpha (!) have had patches sent upstream to do the right thing for > FreeBSD, but not ia64. > > If you can, please try the attached patch, which resolves the problem on > the ia64 machine I have tried it on. It should really be sent upstream > to the binutils people, if there is some interest. Could there be a problem in the patch?: % pwd /usr/src/contrib/binutils/bfd % patch < binutils-ia64-freebsd.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/bfd/config.bfd b/bfd/config.bfd |index 9b719d8..d2fe23e 100644 |--- a/bfd/config.bfd |+++ b/bfd/config.bfd -------------------------- Patching file config.bfd using Plan A... Hunk #1 failed at 182. 1 out of 1 hunks failed--saving rejects to config.bfd.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/bfd/configure b/bfd/configure |index 278cc1d..ad9dcc9 100755 |--- a/bfd/configure |+++ b/bfd/configure -------------------------- Patching file configure using Plan A... Hunk #1 succeeded at 6365 with fuzz 1 (offset -8804 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/bfd/elfxx-ia64.c b/bfd/elfxx-ia64.c |index d42ad89..5625c44 100644 |--- a/bfd/elfxx-ia64.c |+++ b/bfd/elfxx-ia64.c -------------------------- Patching file elfxx-ia64.c using Plan A... Hunk #1 succeeded at 5013 (offset -1064 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/bfd/targets.c b/bfd/targets.c |index 3e99754..a642a8d 100644 |--- a/bfd/targets.c |+++ b/bfd/targets.c -------------------------- Patching file targets.c using Plan A... Hunk #1 succeeded at 595 with fuzz 1 (offset -102 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/ld/emulparams/elf64_ia64_fbsd.sh b/ld/emulparams/elf64_ia64_fbsd.sh |index ab7e78f..a7e2675 100644 |--- a/ld/emulparams/elf64_ia64_fbsd.sh |+++ b/ld/emulparams/elf64_ia64_fbsd.sh -------------------------- File to patch: ../ld/emulparams/elf64_ia64_fbsd.sh Patching file ../ld/emulparams/elf64_ia64_fbsd.sh using Plan A... Hunk #1 succeeded at 4 with fuzz 2. patch: **** misordered hunks! output would be garbled % many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 16:18:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECA8A1065674 for ; Mon, 6 Dec 2010 16:18:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C04878FC08 for ; Mon, 6 Dec 2010 16:18:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6B8F346B29; Mon, 6 Dec 2010 11:18:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7D6748A009; Mon, 6 Dec 2010 11:18:49 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 6 Dec 2010 09:44:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101205231829.GA68156@troutmask.apl.washington.edu> In-Reply-To: <20101205231829.GA68156@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012060944.03196.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 06 Dec 2010 11:18:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 16:18:51 -0000 On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > Sometime in the last 7-10 days, some one made a > change that has broken process accounting/timing. > > laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > foreach? time ./testf > foreach? end > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.55 real 38.39 user 30.94 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.82 real 40.95 user 27.60 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.14 real 38.90 user 30.02 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.79 real 40.59 user 27.99 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.93 real 39.76 user 28.96 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.71 real 41.21 user 27.29 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.05 real 39.68 user 29.15 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 68.99 real 39.98 user 28.80 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.02 real 39.64 user 29.16 sys > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > 69.38 real 37.49 user 31.67 sys > > testf is a numerically intensive program that tests the > accuracy of expf() in a tight loop. User time varies > by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > I'm fairly certain that the code does not suddenly grow/loose > 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 16:38:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B31106566C; Mon, 6 Dec 2010 16:38:31 +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 CC8588FC08; Mon, 6 Dec 2010 16:38:30 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB6GcU01067499; Mon, 6 Dec 2010 08:38:30 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB6GcUNf067495; Mon, 6 Dec 2010 08:38:30 -0800 (PST) (envelope-from sgk) Date: Mon, 6 Dec 2010 08:38:30 -0800 From: Steve Kargl To: John Baldwin Message-ID: <20101206163830.GA53157@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012060944.03196.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 16:38:31 -0000 On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > > Sometime in the last 7-10 days, some one made a > > change that has broken process accounting/timing. > > > > laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > > foreach? time ./testf > > foreach? end > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 69.55 real 38.39 user 30.94 sys > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > 68.82 real 40.95 user 27.60 sys > > > > testf is a numerically intensive program that tests the > > accuracy of expf() in a tight loop. User time varies > > by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > > I'm fairly certain that the code does not suddenly grow/loose > > 6 GFLOP of operations. > > The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > hz) to figure out a user vs sys split and use that to divide up the total > runtime (which actually is fairly accurate). All you need is for the clock > ticks to fire just a bit differently between runs to get a swing in user vs > system time. > > What I would like is to keep separate raw bintime's for user vs system time in > the raw data instead, but that would involve checking the CPU ticker more > often (e.g. twice for each syscall, interrupt, and trap in addition to the > current once per context switch). So far folks seem to be more worried about > the extra overhead rather than the loss of accuracy. > John, Thanks for the comment. It seems this splitting has become worse (for some definition of worse) in that previously the user time variation was on the order of tenth of a second not seconds. In thinking about the issue, I recalled that some changes to npx.c were committed 10 days ago. Perhaps, there is slightly more context switch overhead in dealing with the FPU registers, and this has increased the sys time. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 17:03:51 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 59972106564A for ; Mon, 6 Dec 2010 17:03:51 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Tue, 7 Dec 2010 02:03:50 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org Message-Id: <20101207020350.d0d04b88.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 17:03:51 -0000 Hi. I tested like following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- share/mk/bsd.own.mk.orig 2010-10-06 12:22:05.747697000 +0900 +++ share/mk/bsd.own.mk 2010-12-06 23:40:59.058632584 +0900 @@ -169,8 +169,8 @@ STRIP?= -s .endif -COMPRESS_CMD?= gzip -cn -COMPRESS_EXT?= .gz +COMPRESS_CMD?= xz -c +COMPRESS_EXT?= .xz .if !defined(_WITHOUT_SRCCONF) # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I got following results: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man -name \*.gz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}' 31186768 8629 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man -name \*.xz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}' 30010640 8631 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .xz smaller than .gz, but effective is about 96.2%:-(. Different from files.gz to files.xz: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +/usr/share/man/man3/log2.3.xz +/usr/share/man/man3/log2f.3.xz - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Sorry, .gz environment is just older) And I noticed that tooooooo long ObsoleteFiles.inc:-(. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # YYYYMMDD: Remove *.gz (Replaced by *.xz) OLD_FILES+=usr/share/doc/papers/beyond43.ascii.gz OLD_FILES+=usr/share/doc/papers/bio.ascii.gz OLD_FILES+=usr/share/doc/papers/contents.ascii.gz : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Humm.. JFYI. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 17:35:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D675A106566B; Mon, 6 Dec 2010 17:35:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 57CBA8FC0A; Mon, 6 Dec 2010 17:35:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oB6HZWcx067133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2010 19:35:32 +0200 (EET) (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.14.4/8.14.4) with ESMTP id oB6HZVer009266; Mon, 6 Dec 2010 19:35:31 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oB6HZVsB009265; Mon, 6 Dec 2010 19:35:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Dec 2010 19:35:31 +0200 From: Kostik Belousov To: Steve Kargl Message-ID: <20101206173531.GI2417@deviant.kiev.zoral.com.ua> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N8NGGaQn1mzfvaPg" Content-Disposition: inline In-Reply-To: <20101206163830.GA53157@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 17:35:40 -0000 --N8NGGaQn1mzfvaPg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote: > On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: > > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > > > Sometime in the last 7-10 days, some one made a > > > change that has broken process accounting/timing. > > >=20 > > > laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > > > foreach? time ./testf > > > foreach? end > > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.06710= 0e-04 > > > 69.55 real 38.39 user 30.94 sys > > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx =3D 1.06710= 0e-04 > > > 68.82 real 40.95 user 27.60 sys > > >=20 > > > testf is a numerically intensive program that tests the > > > accuracy of expf() in a tight loop. User time varies > > > by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > > > I'm fairly certain that the code does not suddenly grow/loose > > > 6 GFLOP of operations. > >=20 > > The user/sys thing is a hack (and has been). We sample the PC at stath= z (~128=20 > > hz) to figure out a user vs sys split and use that to divide up the tot= al=20 > > runtime (which actually is fairly accurate). All you need is for the c= lock=20 > > ticks to fire just a bit differently between runs to get a swing in use= r vs=20 > > system time. > >=20 > > What I would like is to keep separate raw bintime's for user vs system = time in=20 > > the raw data instead, but that would involve checking the CPU ticker mo= re=20 > > often (e.g. twice for each syscall, interrupt, and trap in addition to = the=20 > > current once per context switch). So far folks seem to be more worried= about=20 > > the extra overhead rather than the loss of accuracy. > >=20 >=20 > John, >=20 > Thanks for the comment. It seems this splitting has become > worse (for some definition of worse) in that previously the > user time variation was on the order of tenth of a second not > seconds. In thinking about the issue, I recalled that some > changes to npx.c were committed 10 days ago. Perhaps, there > is slightly more context switch overhead in dealing with the > FPU registers, and this has increased the sys time. If you can confirm this statement, it would be interesting. Otherwise, I claim that the changes did not affected the context switch path at all. The changes were mostly relevant for context(2) family of functions and debugger access to the FPU register file. --N8NGGaQn1mzfvaPg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkz9HuIACgkQC3+MBN1Mb4goigCfUrSmv4GQAdPe5Tf+AvXj/IUp aScAoMbFtZxNXw0Ne0vw/p8qZKTVsq1T =VWQx -----END PGP SIGNATURE----- --N8NGGaQn1mzfvaPg-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 17:43:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 739801065673; Mon, 6 Dec 2010 17:43:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 12:42:59 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012031938.12684.jkim@FreeBSD.org> <4CFA220A.30405@freebsd.org> In-Reply-To: <4CFA220A.30405@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061243.08577.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 17:43:22 -0000 On Saturday 04 December 2010 06:12 am, Andriy Gapon wrote: > on 04/12/2010 02:38 Jung-uk Kim said the following: > > If my understanding is correct, your patch uses the dummy > > timecounter until a real timecounter is chosen. > > Perhaps this is one way to look at it. > But I look at it differently - the patch makes cpu_ticks refer to > tc_cpu_ticks. That is, it make _the_ timecounter be used for cpu > ticks. > Exact timecounter backend is not important to me. > > > When a real timecounter is set, > > tc_cpu_ticks() changes the frequency naturally. How are you > > going to solve this problem? > > Do we really care about cpu ticks accounting that early in the > boot? > > > What should we do when a user set a new > > timecounter hardware via "sysctl kern.timecounter.hardware"? > > User can expect some instability (*if any*) when he does such a > significant system reconfiguration. > I put "if any", because I think that tc_cpu_ticks() should handle > this. The same way as you don't see time returned by e.g. > nanotime() going crazy at that moment. > > > I don't > > think it is any better than current code. Am I missing > > something? :-( > > I think that it is much better. > Handling of P-state changes for non-invariant TSC is just > incorrect. kern.timecounter.hardware is not going to be changed as > frequently as P-states, if ever. Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revision&revision=155444 http://svn.freebsd.org/viewvc/base?view=revision&revision=155534 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 17:44:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2671065674; Mon, 6 Dec 2010 17:44:49 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF6078FC16; Mon, 6 Dec 2010 17:44:48 +0000 (UTC) Received: by fxm16 with SMTP id 16so9622582fxm.13 for ; Mon, 06 Dec 2010 09:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=0lzysLwfe1GpeLyAiaZVpitSSpbQagYM8INXzYGGQWw=; b=eOVb7zUG+F2aQfHWILsksiWdjAY7JCuk++iPvGviWwfP8x7m4nkqZSjhsZ2BX+BH2n fTeapyU7K2znkKyIi/KsJsHGprP5QiXfyEc9Oeb1+Y4fdyLzw1nvHEadrDxpn84kVMYJ kSQp2UJV8btHkxxeJ2mzmQ6VxcSQwz/cJRLNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=ufLOgVBbYQSUpux7DtriCj0uXoeg//3TcLsQOfSQqvKnGp1YE4Uj0N/WI69b8Gyt15 g3jaqU7g/RzLBhA/z4HIy3wkeNxcGCaY2jnjKTF6vzr9TWnz7Ki/Ai2TvnyNT9c46COP 9Yc8UZE0v+tVoLC19F7f/FhHTYPc6jIi+CkJE= Received: by 10.223.93.137 with SMTP id v9mr5850537fam.77.1291655675235; Mon, 06 Dec 2010 09:14:35 -0800 (PST) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id v1sm2612924bkt.17.2010.12.06.09.14.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 09:14:32 -0800 (PST) Sender: Alex Kozlov Date: Mon, 6 Dec 2010 19:13:58 +0200 From: Alex Kozlov To: Norikatsu Shigemura , freebsd-current@FreeBSD.org, spam@rm-rf.kiev.ua Message-ID: <20101206171358.GA17125@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 17:44:49 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: > .xz smaller than .gz, but effective is about 96.2%:-(. Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. -- Adios --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="results.txt" RELENG_8 2010-04-26: 4,0M /tmp/mangzxz.hm0P7PH4xi/1_raw 1,7M /tmp/mangzxz.hm0P7PH4xi/1gz 1,6M /tmp/mangzxz.hm0P7PH4xi/1xz 1,1M /tmp/mangzxz.hm0P7PH4xi/2_raw 604K /tmp/mangzxz.hm0P7PH4xi/2gz 598K /tmp/mangzxz.hm0P7PH4xi/2xz 5,7M /tmp/mangzxz.hm0P7PH4xi/3_raw 2,6M /tmp/mangzxz.hm0P7PH4xi/3gz 2,6M /tmp/mangzxz.hm0P7PH4xi/3xz 3,5M /tmp/mangzxz.hm0P7PH4xi/4_raw 1,7M /tmp/mangzxz.hm0P7PH4xi/4gz 1,7M /tmp/mangzxz.hm0P7PH4xi/4xz 1,8M /tmp/mangzxz.hm0P7PH4xi/5_raw 748K /tmp/mangzxz.hm0P7PH4xi/5gz 718K /tmp/mangzxz.hm0P7PH4xi/5xz 10K /tmp/mangzxz.hm0P7PH4xi/6_raw 6,0K /tmp/mangzxz.hm0P7PH4xi/6gz 6,0K /tmp/mangzxz.hm0P7PH4xi/6xz 804K /tmp/mangzxz.hm0P7PH4xi/7_raw 308K /tmp/mangzxz.hm0P7PH4xi/7gz 296K /tmp/mangzxz.hm0P7PH4xi/7xz 3,0M /tmp/mangzxz.hm0P7PH4xi/8_raw 1,4M /tmp/mangzxz.hm0P7PH4xi/8gz 1,4M /tmp/mangzxz.hm0P7PH4xi/8xz 2,1M /tmp/mangzxz.hm0P7PH4xi/9_raw 1,0M /tmp/mangzxz.hm0P7PH4xi/9gz 1,0M /tmp/mangzxz.hm0P7PH4xi/9xz --ikeVEW9yuYc//A+q-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 17:58:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F561065670; Mon, 6 Dec 2010 17:58:28 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 40AFA8FC08; Mon, 6 Dec 2010 17:58:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA13487; Mon, 06 Dec 2010 19:58:25 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD2441.5090408@freebsd.org> Date: Mon, 06 Dec 2010 19:58:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012031938.12684.jkim@FreeBSD.org> <4CFA220A.30405@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> In-Reply-To: <201012061243.08577.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 17:58:28 -0000 on 06/12/2010 19:42 Jung-uk Kim said the following: > Sigh... Please see the history of calcru() in > sys/kern/kern_resource.c. Most important ones are: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=155444 > http://svn.freebsd.org/viewvc/base?view=revision&revision=155534 > > Basically, we chose efficiency over accuracy and you are suggesting > going backwards. Well, I guess that it depends. Looking at r155444 - the time is still going to be accounted in ticks (but timecounter ticks). BTW, I think that this quote says something: "On more modern hardware no change in performance is seen." and that was ~5 years ago. Looking at r155534 - the only change that is going to get undone is using TSC for the accounting ticks, and that is only for machines with non-invariant TSC. And I think that all sufficiently modern machines have invariant TSC and, in Intel's words, that's an architectural path going forward. So, I don't think that I propose a dramatic change. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:04:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C254106564A for ; Mon, 6 Dec 2010 18:04:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EDEBB8FC18 for ; Mon, 6 Dec 2010 18:04:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 88B9746B60; Mon, 6 Dec 2010 13:04:06 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F9C18A009; Mon, 6 Dec 2010 13:04:05 -0500 (EST) From: John Baldwin To: Steve Kargl Date: Mon, 6 Dec 2010 13:01:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> In-Reply-To: <20101206163830.GA53157@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061301.13647.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 06 Dec 2010 13:04:05 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:04:07 -0000 On Monday, December 06, 2010 11:38:30 am Steve Kargl wrote: > On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: > > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > > > Sometime in the last 7-10 days, some one made a > > > change that has broken process accounting/timing. > > > > > > laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > > > foreach? time ./testf > > > foreach? end > > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > > 69.55 real 38.39 user 30.94 sys > > > Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > > > 68.82 real 40.95 user 27.60 sys > > > > > > testf is a numerically intensive program that tests the > > > accuracy of expf() in a tight loop. User time varies > > > by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > > > I'm fairly certain that the code does not suddenly grow/loose > > > 6 GFLOP of operations. > > > > The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > > hz) to figure out a user vs sys split and use that to divide up the total > > runtime (which actually is fairly accurate). All you need is for the clock > > ticks to fire just a bit differently between runs to get a swing in user vs > > system time. > > > > What I would like is to keep separate raw bintime's for user vs system time in > > the raw data instead, but that would involve checking the CPU ticker more > > often (e.g. twice for each syscall, interrupt, and trap in addition to the > > current once per context switch). So far folks seem to be more worried about > > the extra overhead rather than the loss of accuracy. > > > > John, > > Thanks for the comment. It seems this splitting has become > worse (for some definition of worse) in that previously the > user time variation was on the order of tenth of a second not > seconds. In thinking about the issue, I recalled that some > changes to npx.c were committed 10 days ago. Perhaps, there > is slightly more context switch overhead in dealing with the > FPU registers, and this has increased the sys time. Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could be a factor? It might change when statclock() is called. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:10:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7987F106566C; Mon, 6 Dec 2010 18:10:34 +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 3E1B88FC15; Mon, 6 Dec 2010 18:10:34 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB6IAY47038768; Mon, 6 Dec 2010 10:10:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB6IAXtk038767; Mon, 6 Dec 2010 10:10:33 -0800 (PST) (envelope-from sgk) Date: Mon, 6 Dec 2010 10:10:33 -0800 From: Steve Kargl To: Kostik Belousov Message-ID: <20101206181033.GA38739@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <20101206173531.GI2417@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101206173531.GI2417@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:10:34 -0000 On Mon, Dec 06, 2010 at 07:35:31PM +0200, Kostik Belousov wrote: > On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote: > > John, > > > > Thanks for the comment. It seems this splitting has become > > worse (for some definition of worse) in that previously the > > user time variation was on the order of tenth of a second not > > seconds. In thinking about the issue, I recalled that some > > changes to npx.c were committed 10 days ago. Perhaps, there > > is slightly more context switch overhead in dealing with the > > FPU registers, and this has increased the sys time. > If you can confirm this statement, it would be interesting. Otherwise, > I claim that the changes did not affected the context switch path at > all. The changes were mostly relevant for context(2) family of functions > and debugger access to the FPU register file. I won't be able to test this possibiolity until later tonight (about 9 hours from now). -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:24:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA8C0106564A; Mon, 6 Dec 2010 18:24:30 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DDC7D8FC17; Mon, 6 Dec 2010 18:24:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA13734; Mon, 06 Dec 2010 20:24:27 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD2A5B.1030006@freebsd.org> Date: Mon, 06 Dec 2010 20:24:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> In-Reply-To: <201012061301.13647.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:24:31 -0000 on 06/12/2010 20:01 John Baldwin said the following: > Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could > be a factor? It might change when statclock() is called. But I think that that code was committed more than 7-10 days ago, which Steve mentioned. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:34:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 21E3B106566B; Mon, 6 Dec 2010 18:34:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 13:34:19 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> <4CFD2441.5090408@freebsd.org> In-Reply-To: <4CFD2441.5090408@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061334.22475.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:34:36 -0000 On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: > on 06/12/2010 19:42 Jung-uk Kim said the following: > > Sigh... Please see the history of calcru() in > > sys/kern/kern_resource.c. Most important ones are: > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=155444 > > http://svn.freebsd.org/viewvc/base?view=revision&revision=155534 > > > > Basically, we chose efficiency over accuracy and you are > > suggesting going backwards. > > Well, I guess that it depends. > > Looking at r155444 - the time is still going to be accounted in > ticks (but timecounter ticks). BTW, I think that this quote says > something: "On more modern hardware no change in performance is > seen." and that was ~5 years ago. "On slower machines, the avoided multiplications to normalize timestams at every context switch, comes out as a 5-7% better score on the unixbench/context1 microbenchmark. On more modern hardware no change in performance is seen." His performance measurement was done for "the avoided multiplications to normalize timestamps at every context switch", not for "change CPU ticker from tc_cpu_ticks() to cpu_ticks()", which actually happened in r155534 later. > Looking at r155534 - the only change that is going to get undone is > using TSC for the accounting ticks, and that is only for machines > with non-invariant TSC. And I think that all sufficiently modern > machines have invariant TSC and, in Intel's words, that's an > architectural path going forward. I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. > So, I don't think that I propose a dramatic change. Shrug... Still I want to see some evidence. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:40:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 089A21065679; Mon, 6 Dec 2010 18:40:34 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F24FC8FC1F; Mon, 6 Dec 2010 18:40:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA13938; Mon, 06 Dec 2010 20:40:31 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD2E1E.2080604@freebsd.org> Date: Mon, 06 Dec 2010 20:40:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> <4CFD2441.5090408@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> In-Reply-To: <201012061334.22475.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:40:34 -0000 on 06/12/2010 20:34 Jung-uk Kim said the following: > On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: >> on 06/12/2010 19:42 Jung-uk Kim said the following: >>> Sigh... Please see the history of calcru() in >>> sys/kern/kern_resource.c. Most important ones are: >>> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=155444 >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=155534 >>> >>> Basically, we chose efficiency over accuracy and you are >>> suggesting going backwards. >> >> Well, I guess that it depends. >> >> Looking at r155444 - the time is still going to be accounted in >> ticks (but timecounter ticks). BTW, I think that this quote says >> something: "On more modern hardware no change in performance is >> seen." and that was ~5 years ago. > > "On slower machines, the avoided multiplications to normalize > timestams at every context switch, comes out as a 5-7% better score > on the unixbench/context1 microbenchmark. On more modern hardware no > change in performance is seen." > > His performance measurement was done for "the avoided multiplications > to normalize timestamps at every context switch", not for "change CPU > ticker from tc_cpu_ticks() to cpu_ticks()", which actually happened > in r155534 later. Right. I was just pointing out a fact. That change is not going to get undone anyways. >> Looking at r155534 - the only change that is going to get undone is >> using TSC for the accounting ticks, and that is only for machines >> with non-invariant TSC. And I think that all sufficiently modern >> machines have invariant TSC and, in Intel's words, that's an >> architectural path going forward. > > I understand that. However, it is not clear to me why you want to > pessimize performance of old hardware. If you can convince me old > hardware with slow timecounter hardware (e.g., i8254) does not hurt > too much, maybe it's okay. Well, weighing totally bogus stats vs slight stats collection pessimization, I have a new proposal - why we don't just hardcode some stats values? That would give that code unbeatable performance! >> So, I don't think that I propose a dramatic change. > > Shrug... Still I want to see some evidence. Evidence of what? That nothing is going to be changed for new hardware? Or that older hardware won't be slowed down to a crawl? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:43:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919B51065697; Mon, 6 Dec 2010 18:43: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 6D22A8FC2D; Mon, 6 Dec 2010 18:43:09 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB6Ih9YQ039009; Mon, 6 Dec 2010 10:43:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB6Ih9Gv039008; Mon, 6 Dec 2010 10:43:09 -0800 (PST) (envelope-from sgk) Date: Mon, 6 Dec 2010 10:43:09 -0800 From: Steve Kargl To: Andriy Gapon Message-ID: <20101206184309.GB38739@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> <4CFD2A5B.1030006@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFD2A5B.1030006@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:43:09 -0000 On Mon, Dec 06, 2010 at 08:24:27PM +0200, Andriy Gapon wrote: > on 06/12/2010 20:01 John Baldwin said the following: > > Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could > > be a factor? It might change when statclock() is called. > > But I think that that code was committed more than 7-10 days ago, which Steve > mentioned. > The 7-10 days is an estimate. I upgraded world/kernel on Saturday. The previous world/kernel could have been older than I'm guessing. It could be upto 4 weeks old because my laptop tends to lag behind the upgrades to my servers. I would normally use gprof to measure execution times for the functions I'm writing, but in some quick testing last night gprof appears to be broken. I'm seeing a larger variation that I would expect in self-seconds for the accumulated time for execution of expf. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:46:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987551065674; Mon, 6 Dec 2010 18:46:21 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF918FC15; Mon, 6 Dec 2010 18:46:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA14016; Mon, 06 Dec 2010 20:46:16 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD2F77.8020409@freebsd.org> Date: Mon, 06 Dec 2010 20:46:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Steve Kargl References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> <4CFD2A5B.1030006@freebsd.org> <20101206184309.GB38739@troutmask.apl.washington.edu> In-Reply-To: <20101206184309.GB38739@troutmask.apl.washington.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:46:21 -0000 on 06/12/2010 20:43 Steve Kargl said the following: > The 7-10 days is an estimate. I upgraded world/kernel on > Saturday. The previous world/kernel could have been older > than I'm guessing. It could be upto 4 weeks old because > my laptop tends to lag behind the upgrades to my servers. I see. > I would normally use gprof to measure execution times > for the functions I'm writing, but in some quick > testing last night gprof appears to be broken. I'm > seeing a larger variation that I would expect in > self-seconds for the accumulated time for execution > of expf. Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's not 1 already? And cc-ing Alexander, just in case. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:49:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCFF106564A; Mon, 6 Dec 2010 18:49:49 +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 58E798FC1D; Mon, 6 Dec 2010 18:49:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oB6InnCQ052153; Mon, 6 Dec 2010 10:49:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oB6Inn25052152; Mon, 6 Dec 2010 10:49:49 -0800 (PST) (envelope-from sgk) Date: Mon, 6 Dec 2010 10:49:49 -0800 From: Steve Kargl To: Andriy Gapon Message-ID: <20101206184949.GA39028@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> <4CFD2A5B.1030006@freebsd.org> <20101206184309.GB38739@troutmask.apl.washington.edu> <4CFD2F77.8020409@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFD2F77.8020409@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:49:49 -0000 On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote: > on 06/12/2010 20:43 Steve Kargl said the following: > > The 7-10 days is an estimate. I upgraded world/kernel on > > Saturday. The previous world/kernel could have been older > > than I'm guessing. It could be upto 4 weeks old because > > my laptop tends to lag behind the upgrades to my servers. > > I see. > > > I would normally use gprof to measure execution times > > for the functions I'm writing, but in some quick > > testing last night gprof appears to be broken. I'm > > seeing a larger variation that I would expect in > > self-seconds for the accumulated time for execution > > of expf. > > Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's > not 1 already? > > And cc-ing Alexander, just in case. > Thanks for the suggestion. I'll try this tonight (I left the laptop at home) and will report back here. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:51:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03381065693 for ; Mon, 6 Dec 2010 18:51:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8063A8FC14 for ; Mon, 6 Dec 2010 18:51:38 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 35092A68684; Tue, 7 Dec 2010 02:51:37 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id RWN18aNXU1P1; Tue, 7 Dec 2010 02:51:29 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 483B6A68665; Tue, 7 Dec 2010 02:51:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=wwjy8MXPpspvO+V8WVgWGh96xYxruJOWjWPC/mDMUm9CiEInXvBFPilZnBCFPScsL f42sjiooft+smlMp4n2Xg== Message-ID: <4CFD30A9.7060502@delphij.net> Date: Mon, 06 Dec 2010 10:51:21 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: Irakli References: <4CEBBDEC.7090700@delphij.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------050100070905040504050908" Cc: FreeBSD Current Subject: Re: coretemp TjMax X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:51:39 -0000 This is a multi-part message in MIME format. --------------050100070905040504050908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 12/04/10 13:59, Irakli wrote: > Hi, > > ns# cpucontrol -m 0x1a2 /dev/cpuctl0 > MSR 0x1a2: 0x00000000 0x00001600 > > ns# grep GenuineIntel /var/run/dmesg.boot > Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 I didn't found any authoritative source that gives me 95. Where did you get the information? Attached is a patch that uses 95C for stepping G0 but I'm really clueless whether that's right. > On Tue, Nov 23, 2010 at 5:13 PM, Xin LI > wrote: > > [Redirected to -current@] > > Hi, > > On 11/15/10 03:32, Irakli wrote: >> Hi >> coretemp gets wrong TjMax for Intel E6750 CPU (CPUID 06FBh), 85 > instead of >> 95. >> and therefore monitoring programs see low then room temperature > (in air >> cooling) >> Please fix this and would be nice allowing users manual setting > TjMax from >> sysctl > > Would you please provide the following information? > > cpucontrol -m 0x1a2 /dev/cpuctl0 > > (kldload cpuctl if necessary). > > And: > > grep GenuineIntel /var/run/dmesg.boot > > Thanks in advance! > > Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM/TCpAAoJEATO+BI/yjfBoxwH/RzrcuHXjo8buG3suGheD2kP 4N1LNMR/lPzmlG9duhqPOE3Y7DsKqe/tiZ91QykyFmJylePHf5gAv+bASP8An+xv piyq12ghePUoWsl9kYJwSBQ1wkvpkYf6RJ+mWIGTMp3+xpmEa9yyQnnE2AvSWAga HduALNzJnqqxQwlHFFqi216ay79ItUPvJEWCGeP1AfGt3CJqg1aAJ8fY3rF7m37P whWg89QqWu6U0WDJ2QFmzJxxtbyHIT9CUcGsJrpfZKVQf2kglPn0rPSLjaBTQcGK RJMyOW3KI/LueSJ+PgvRNtaSVhhGL2cm4L9Mz2uo/vp5OVoe48oWn68dZgFkffw= =MKgf -----END PGP SIGNATURE----- --------------050100070905040504050908 Content-Type: text/plain; name="coretemp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="coretemp.diff" Index: coretemp.c =================================================================== --- coretemp.c (revision 216236) +++ coretemp.c (working copy) @@ -178,8 +178,13 @@ */ sc->sc_tjmax = 100; - if ((cpu_model == 0xf && cpu_stepping >= 2) || cpu_model == 0xe) { + if (cpu_model == 0xf && cpu_stepping == 11) { /* + * Use 95C for stepping G0 + */ + sc->sc_tjmax = 95; + } else if ((cpu_model == 0xf && cpu_stepping >= 2) || cpu_model == 0xe) { + /* * On some Core 2 CPUs, there's an undocumented MSR that * can tell us if Tj(max) is 100 or 85. * --------------050100070905040504050908-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 18:56:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D20711065673; Mon, 6 Dec 2010 18:56:35 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C95338FC13; Mon, 6 Dec 2010 18:56:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA14100; Mon, 06 Dec 2010 20:56:33 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD31E0.8070107@freebsd.org> Date: Mon, 06 Dec 2010 20:56:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012061243.08577.jkim@FreeBSD.org> <4CFD2441.5090408@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> In-Reply-To: <201012061334.22475.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 18:56:35 -0000 on 06/12/2010 20:34 Jung-uk Kim said the following: > I understand that. However, it is not clear to me why you want to > pessimize performance of old hardware. If you can convince me old > hardware with slow timecounter hardware (e.g., i8254) does not hurt > too much, maybe it's okay. Overlooked this point - TSC can be very well used as a timecounter. And in that case non-invariant TSC would veto P-state changes, which is the proper thing to do, IMO. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:01:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 557E1106566B; Mon, 6 Dec 2010 19:01:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f49.google.com (mail-bw0-f49.google.com [209.85.214.49]) by mx1.freebsd.org (Postfix) with ESMTP id 728918FC1D; Mon, 6 Dec 2010 19:00:59 +0000 (UTC) Received: by bwz5 with SMTP id 5so11386203bwz.8 for ; Mon, 06 Dec 2010 11:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mckNjxMcpywpwxdAeX17m6t6XRLjXpxUHG5kNBpMB28=; b=EqUW9Dv7kZJZPVSHW1x8oD0iPqx3335WGVvOkY/s41ao2d0aXMXaNq8KhmnUaUJilk dWwx0xgjU7EDwbVza5vsvu9560W73q5cJoyOpa3iPtN3FPWD6bGIqQz74yav/xZb6zie 5hknnkvBD+PHZL7P28DefAx3LOs8K9VSig8j4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DKYR2NWTPqN7852NdKrw+Z1uvgpCxxrd529RsCXeJlSQW49H5xTbKTkevxOoD+/rYB QU3d3kWnddGJMMJWh93E2nzEA3WYBZ0WoL949Fqsj9/RYDulUWX4WbQKNyJI2XAdwo0D qKJeE86frV4pm+tw/IZWCRAFbfcUy1CPaeuV8= Received: by 10.223.89.143 with SMTP id e15mr277674fam.100.1291662058095; Mon, 06 Dec 2010 11:00:58 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n7sm1640201fam.11.2010.12.06.11.00.55 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 11:00:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4CFD32E6.7040003@FreeBSD.org> Date: Mon, 06 Dec 2010 21:00:54 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: Steve Kargl References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> <4CFD2A5B.1030006@freebsd.org> <20101206184309.GB38739@troutmask.apl.washington.edu> <4CFD2F77.8020409@freebsd.org> <20101206184949.GA39028@troutmask.apl.washington.edu> In-Reply-To: <20101206184949.GA39028@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:01:00 -0000 On 06.12.2010 20:49, Steve Kargl wrote: > On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote: >> on 06/12/2010 20:43 Steve Kargl said the following: >>> The 7-10 days is an estimate. I upgraded world/kernel on >>> Saturday. The previous world/kernel could have been older >>> than I'm guessing. It could be upto 4 weeks old because >>> my laptop tends to lag behind the upgrades to my servers. >> >> I see. >> >>> I would normally use gprof to measure execution times >>> for the functions I'm writing, but in some quick >>> testing last night gprof appears to be broken. I'm >>> seeing a larger variation that I would expect in >>> self-seconds for the accumulated time for execution >>> of expf. >> >> Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's >> not 1 already? >> >> And cc-ing Alexander, just in case. > > Thanks for the suggestion. I'll try this tonight (I left the > laptop at home) and will report back here. Unless your application utilizes all CPUs all the time, you can also try to set sysctl kern.eventtimer.idletick=1. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:01:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1D92C10656B7; Mon, 6 Dec 2010 19:01:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 14:01:15 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> <4CFD2E1E.2080604@freebsd.org> In-Reply-To: <4CFD2E1E.2080604@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061401.17904.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:01:31 -0000 On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote: > on 06/12/2010 20:34 Jung-uk Kim said the following: > > On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: > >> on 06/12/2010 19:42 Jung-uk Kim said the following: > >>> Sigh... Please see the history of calcru() in > >>> sys/kern/kern_resource.c. Most important ones are: > >>> > >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15544 > >>>4 > >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15553 > >>>4 > >>> > >>> Basically, we chose efficiency over accuracy and you are > >>> suggesting going backwards. > >> > >> Well, I guess that it depends. > >> > >> Looking at r155444 - the time is still going to be accounted in > >> ticks (but timecounter ticks). BTW, I think that this quote > >> says something: "On more modern hardware no change in > >> performance is seen." and that was ~5 years ago. > > > > "On slower machines, the avoided multiplications to normalize > > timestams at every context switch, comes out as a 5-7% better > > score on the unixbench/context1 microbenchmark. On more modern > > hardware no change in performance is seen." > > > > His performance measurement was done for "the avoided > > multiplications to normalize timestamps at every context switch", > > not for "change CPU ticker from tc_cpu_ticks() to cpu_ticks()", > > which actually happened in r155534 later. > > Right. I was just pointing out a fact. > That change is not going to get undone anyways. > > >> Looking at r155534 - the only change that is going to get undone > >> is using TSC for the accounting ticks, and that is only for > >> machines with non-invariant TSC. And I think that all > >> sufficiently modern machines have invariant TSC and, in Intel's > >> words, that's an architectural path going forward. > > > > I understand that. However, it is not clear to me why you want > > to pessimize performance of old hardware. If you can convince me > > old hardware with slow timecounter hardware (e.g., i8254) does > > not hurt too much, maybe it's okay. > > Well, weighing totally bogus stats vs slight stats collection > pessimization, I have a new proposal - why we don't just hardcode > some stats values? That would give that code unbeatable > performance! :-) Don't get me wrong, I generally agree with you *iff* it does not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. > >> So, I don't think that I propose a dramatic change. > > > > Shrug... Still I want to see some evidence. > > Evidence of what? > That nothing is going to be changed for new hardware? > Or that older hardware won't be slowed down to a crawl? The latter, kinda. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:09:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B208F106566B; Mon, 6 Dec 2010 19:09:24 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C8AAE8FC12; Mon, 6 Dec 2010 19:09:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA14300; Mon, 06 Dec 2010 21:09:22 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD34E1.40008@freebsd.org> Date: Mon, 06 Dec 2010 21:09:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> <4CFD2E1E.2080604@freebsd.org> <201012061401.17904.jkim@FreeBSD.org> In-Reply-To: <201012061401.17904.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:09:24 -0000 on 06/12/2010 21:01 Jung-uk Kim said the following: > :-) Don't get me wrong, I generally agree with you *iff* it does not > hurt too much. Anyway, this issue should be resolved from the root, > i.e., kern_resouce.c, if possible. But what to resolve there? I just want to always have a stable source "cpu ticks", and then everything else should just work? BTW, if someone comes up with a patch for more or less correct accounting when "cpu ticks" frequency is allowed to change, then I am all for it. But, IMO, it's just easier to use stable "cpu ticks". -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:11:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B827E1065673; Mon, 6 Dec 2010 19:11:02 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 14:10:34 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061334.22475.jkim@FreeBSD.org> <4CFD31E0.8070107@freebsd.org> In-Reply-To: <4CFD31E0.8070107@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061410.46351.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:11:02 -0000 On Monday 06 December 2010 01:56 pm, Andriy Gapon wrote: > on 06/12/2010 20:34 Jung-uk Kim said the following: > > I understand that. However, it is not clear to me why you want > > to pessimize performance of old hardware. If you can convince me > > old hardware with slow timecounter hardware (e.g., i8254) does > > not hurt too much, maybe it's okay. > > Overlooked this point - TSC can be very well used as a timecounter. > And in that case non-invariant TSC would veto P-state changes, > which is the proper thing to do, IMO. Yes, thanks to njl. He made it "somewhat bogus" from "totally bogus". I made it "almost correct" from "somewhat bogus" for modern P-state invariant CPUs. ;-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:17:46 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6D81065693 for ; Mon, 6 Dec 2010 19:17:46 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id D47F68FC18 for ; Mon, 6 Dec 2010 19:17:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LD00084DTLKFC30@asmtp030.mac.com>; Mon, 06 Dec 2010 11:17:46 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012060114 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-06_12:2010-12-06, 2010-12-06, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <20101206171358.GA17125@ravenloft.kiev.ua> Date: Mon, 06 Dec 2010 11:17:44 -0800 Message-id: <9132C068-A9C7-41EE-AA98-714385441EE3@mac.com> References: <20101206171358.GA17125@ravenloft.kiev.ua> To: Alex Kozlov X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:17:47 -0000 On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote: > On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: >> .xz smaller than .gz, but effective is about 96.2%:-(. > > Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. Oh, agreed. The issue with small files is that they will always take up at least one sector [*]; different compression routines don't gain any benefit if they don't change the number of sectors needed to store the file. More than half of the manpages end up as 1K .gz catman files as it is; ~90% are 2K or smaller. Regards, -- -Chuck [*]: 1K seems to be the smallest fragment size on the particular filesystem I was looking at, rather than DEV_BSIZE, ie a 512 byte sector.... From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:29:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 52FC2106566C; Mon, 6 Dec 2010 19:29:20 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 14:27:36 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061401.17904.jkim@FreeBSD.org> <4CFD34E1.40008@freebsd.org> In-Reply-To: <4CFD34E1.40008@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061429.08085.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:29:20 -0000 On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: > on 06/12/2010 21:01 Jung-uk Kim said the following: > > :-) Don't get me wrong, I generally agree with you *iff* it does > > : not > > > > hurt too much. Anyway, this issue should be resolved from the > > root, i.e., kern_resouce.c, if possible. > > But what to resolve there? Better algorithm for stat. > I just want to always have a stable source "cpu ticks", and then > everything else should just work? If we had one, yes. But we don't, at least for old x86 hardware. :-( > BTW, if someone comes up with a patch for more or less correct > accounting when "cpu ticks" frequency is allowed to change, then I > am all for it. But, IMO, it's just easier to use stable "cpu > ticks". If it doesn't hurt too much, yes. Remember the P-state invariant CPUs are pretty new. SMP-correct TSC is quite rare if there is any. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 19:38:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BF081065693; Mon, 6 Dec 2010 19:38:12 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6370C8FC17; Mon, 6 Dec 2010 19:38:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA14628; Mon, 06 Dec 2010 21:38:09 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD3BA1.8080901@freebsd.org> Date: Mon, 06 Dec 2010 21:38:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jung-uk Kim References: <4CF92852.20705@freebsd.org> <201012061401.17904.jkim@FreeBSD.org> <4CFD34E1.40008@freebsd.org> <201012061429.08085.jkim@FreeBSD.org> In-Reply-To: <201012061429.08085.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 19:38:12 -0000 on 06/12/2010 21:27 Jung-uk Kim said the following: > On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: >> on 06/12/2010 21:01 Jung-uk Kim said the following: >>> :-) Don't get me wrong, I generally agree with you *iff* it does >>> : not >>> >>> hurt too much. Anyway, this issue should be resolved from the >>> root, i.e., kern_resouce.c, if possible. >> >> But what to resolve there? > > Better algorithm for stat. > >> I just want to always have a stable source "cpu ticks", and then >> everything else should just work? > > If we had one, yes. But we don't, at least for old x86 hardware. :-( This sounds contradictory... I don't follow. So, TSC as a direct source of cpu ticks is good enough, but TSC as a source for timecounter acting as a source for cpu ticks is not stable? >> BTW, if someone comes up with a patch for more or less correct >> accounting when "cpu ticks" frequency is allowed to change, then I >> am all for it. But, IMO, it's just easier to use stable "cpu >> ticks". > > If it doesn't hurt too much, yes. Remember the P-state invariant CPUs > are pretty new. Well, not that new in this fast changing world. > SMP-correct TSC is quite rare if there is any. This contradicts my experience. All systems that I could test have "SMP-correct TSC". Yes, they all are 1-2 years old and they all are single-package multi-core systems. I tested only one two-socket machine from perf-cluster and it had more or less "SMP-correct TSC" too. BTW: http://people.freebsd.org/~avg/tsc/ But, this SMP-correctness is not a requirement for the cpu ticks accounting that we are discussing, right? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 20:07:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7F49F106566C; Mon, 6 Dec 2010 20:07:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Mon, 6 Dec 2010 15:07:25 -0500 User-Agent: KMail/1.6.2 References: <4CF92852.20705@freebsd.org> <201012061429.08085.jkim@FreeBSD.org> <4CFD3BA1.8080901@freebsd.org> In-Reply-To: <4CFD3BA1.8080901@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012061507.27936.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: non-invariant tsc and cputicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Dec 2010 20:07:47 -0000 On Monday 06 December 2010 02:38 pm, Andriy Gapon wrote: > on 06/12/2010 21:27 Jung-uk Kim said the following: > > On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: > >> on 06/12/2010 21:01 Jung-uk Kim said the following: > >>> :-) Don't get me wrong, I generally agree with you *iff* it > >>> : does not > >>> > >>> hurt too much. Anyway, this issue should be resolved from the > >>> root, i.e., kern_resouce.c, if possible. > >> > >> But what to resolve there? > > > > Better algorithm for stat. > > > >> I just want to always have a stable source "cpu ticks", and then > >> everything else should just work? > > > > If we had one, yes. But we don't, at least for old x86 hardware. > > :-( > > This sounds contradictory... I don't follow. > So, TSC as a direct source of cpu ticks is good enough, but TSC as > a source for timecounter acting as a source for cpu ticks is not > stable? CPU ticker is per-CPU property, not global. So, it is okay even if it cannot be used as a timecounter backend. If TSC is selected as a timecounter source, that means a) it is a P-state invariant UP system or b) the user forced it. If the CPU is P-state invariant, it does not matter it is UP or SMP because it is per-CPU property. If the CPU is not invariant or UP system, then it does not allow frequency changes as you've noticed. If the user forced it on SMP, well, the user should know its consequence. ;-) > >> BTW, if someone comes up with a patch for more or less correct > >> accounting when "cpu ticks" frequency is allowed to change, then > >> I am all for it. But, IMO, it's just easier to use stable "cpu > >> ticks". > > > > If it doesn't hurt too much, yes. Remember the P-state invariant > > CPUs are pretty new. > > Well, not that new in this fast changing world. But most of our users do have old hardware, unfortunately. > > SMP-correct TSC is quite rare if there is any. > > This contradicts my experience. All systems that I could test have > "SMP-correct TSC". Yes, they all are 1-2 years old and they all > are single-package multi-core systems. AFAIK, multi-core/single-package/single-socket systems have usually P-state invariant TSCs already, i.e., it can be used as a CPU ticker naturally. > I tested only one two-socket machine from perf-cluster and it had > more or less "SMP-correct TSC" too. Unfortunately "more or less" does not work for us because timecounter should never go backwards. It MUST be monotonic. > BTW: > http://people.freebsd.org/~avg/tsc/ Interesting... I've seen something like this in the past. In fact, I've written my own long ago but I wasn't able to make it 100% correct, unfortunately. :-( > But, this SMP-correctness is not a requirement for the cpu ticks > accounting that we are discussing, right? No, it is not. Sorry, if I confused you somehow. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 00:11:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 19AA21065673; Tue, 7 Dec 2010 00:11:51 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4CFD7BB0.20500@freebsd.org> Date: Tue, 07 Dec 2010 08:11:28 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: John Baldwin References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> In-Reply-To: <201012060944.03196.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 00:11:53 -0000 John Baldwin wrote: > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > >> Sometime in the last 7-10 days, some one made a >> change that has broken process accounting/timing. >> >> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >> foreach? time ./testf >> foreach? end >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.55 real 38.39 user 30.94 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.82 real 40.95 user 27.60 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.14 real 38.90 user 30.02 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.79 real 40.59 user 27.99 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.93 real 39.76 user 28.96 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.71 real 41.21 user 27.29 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.05 real 39.68 user 29.15 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.99 real 39.98 user 28.80 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.02 real 39.64 user 29.16 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.38 real 37.49 user 31.67 sys >> >> testf is a numerically intensive program that tests the >> accuracy of expf() in a tight loop. User time varies >> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >> I'm fairly certain that the code does not suddenly grow/loose >> 6 GFLOP of operations. >> > > The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > hz) to figure out a user vs sys split and use that to divide up the total > runtime (which actually is fairly accurate). All you need is for the clock > ticks to fire just a bit differently between runs to get a swing in user vs > system time. > > What I would like is to keep separate raw bintime's for user vs system time in > the raw data instead, but that would involve checking the CPU ticker more > often (e.g. twice for each syscall, interrupt, and trap in addition to the > current once per context switch). So far folks seem to be more worried about > the extra overhead rather than the loss of accuracy. > > Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 01:32:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3B54106564A for ; Tue, 7 Dec 2010 01:32:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id E627A8FC15 for ; Tue, 7 Dec 2010 01:32:34 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id B76AFA68A75; Tue, 7 Dec 2010 09:32:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id itzoPw-+yZQG; Tue, 7 Dec 2010 09:32:26 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id EF627A5FE4B; Tue, 7 Dec 2010 09:32:24 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=YEPi7guXXKsIFu7ObRaSZZ9Rse2FjvYEc3WjXk4N2DiXbY1IPF/Mty6Gt/xH0QaR+ PjkDz6zOJEairid7H9jXw== Message-ID: <4CFD8EA1.1060808@delphij.net> Date: Mon, 06 Dec 2010 17:32:17 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: Irakli References: <4CEBBDEC.7090700@delphij.net> <4CFD30A9.7060502@delphij.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: coretemp TjMax X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 01:32:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 12/06/10 12:52, Irakli wrote: > Information about this cpu I get from windows coretemp program > http://www.alcpu.com/CoreTemp/ > > this is screenshot of this program (new version) > http://technbball.files.wordpress.com/2009/09/coretemp_e6750.jpg > > older version gets 100 degree for this cpu > http://img233.imageshack.us/img233/8525/voltagecm9.jpg > > and some forums > http://www.overclock.net/intel-cpus/378478-tjmax-e6750.html > > I haven't any authoritative source but sure 85 degree is wrong for this cpu > because freebsd gets lower core temperature then room temperature is Ok to make it clear - I did see some forums mentioned 95 C but these are not authoritative in my opinion (e.g. I was not able to figure out if all 0x6fb CPUs have 95C TjMax, or just a few models, etc). > can you add some code for setting tjmax manualy from sysctl ? Yes will do. Did the patch help your situation by the way? > thank you > > > On Mon, Dec 6, 2010 at 10:51 PM, Xin LI > wrote: > > Hi, > > On 12/04/10 13:59, Irakli wrote: >> Hi, > >> ns# cpucontrol -m 0x1a2 /dev/cpuctl0 >> MSR 0x1a2: 0x00000000 0x00001600 > >> ns# grep GenuineIntel /var/run/dmesg.boot >> Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f > Stepping = 11 > > I didn't found any authoritative source that gives me 95. Where did you > get the information? > > Attached is a patch that uses 95C for stepping G0 but I'm really > clueless whether that's right. > >> On Tue, Nov 23, 2010 at 5:13 PM, Xin LI >> >> wrote: > >> [Redirected to -current@] > >> Hi, > >> On 11/15/10 03:32, Irakli wrote: >>> Hi >>> coretemp gets wrong TjMax for Intel E6750 CPU (CPUID 06FBh), 85 >> instead of >>> 95. >>> and therefore monitoring programs see low then room temperature >> (in air >>> cooling) >>> Please fix this and would be nice allowing users manual setting >> TjMax from >>> sysctl > >> Would you please provide the following information? > >> cpucontrol -m 0x1a2 /dev/cpuctl0 > >> (kldload cpuctl if necessary). > >> And: > >> grep GenuineIntel /var/run/dmesg.boot > >> Thanks in advance! > >> Cheers, > > -- > ][rakli - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM/Y6hAAoJEATO+BI/yjfB6tAIAJSzuNDQEKBhwaXHGKBTavai 2OlF8L+clazY2BrhzV0sBWnqewABHMHmEwtWqM+dp7GkD0TuiD9Shft4NG/pC+Hm wT/7aF7Ipa0jrH6bo5oqk42oqNWOKt6edBSARdYtodtRTRKAFocyje0J0XNpw6r8 AWXxM1NXNM0/+Nf0ZG1jwLu8WhLGQ9V0eJ510Kd1uKh+jZkyOnBlP3tipkrDLgRQ x8CdCJHtuWrqIk8KIOqqMMT3WVpddP4hdNH7usQYkHYh3bVthTamz75E+fGDut9w Poia7FnRXC5odC1EWU8QUMuzpSzNM5Hy/6ePKOrxhfr0x9WpyssJzl9tPHfp/2s= =cPJd -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 06:51:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B20EF106566B for ; Tue, 7 Dec 2010 06:51:14 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 891958FC1A for ; Tue, 7 Dec 2010 06:51:14 +0000 (UTC) Received: by pwi10 with SMTP id 10so2470024pwi.13 for ; Mon, 06 Dec 2010 22:51:14 -0800 (PST) Received: by 10.142.161.16 with SMTP id j16mr332223wfe.281.1291704674052; Mon, 06 Dec 2010 22:51:14 -0800 (PST) Received: from [10.123.2.178] (99-74-169-43.lightspeed.sntcca.sbcglobal.net [99.74.169.43]) by mx.google.com with ESMTPS id b11sm8462429wff.21.2010.12.06.22.51.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 22:51:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <9132C068-A9C7-41EE-AA98-714385441EE3@mac.com> Date: Mon, 6 Dec 2010 22:50:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1639A255-7C84-4D81-A97E-AEB624E68A70@kientzle.com> References: <20101206171358.GA17125@ravenloft.kiev.ua> <9132C068-A9C7-41EE-AA98-714385441EE3@mac.com> To: Chuck Swiger X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org, Alex Kozlov , Norikatsu Shigemura Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 06:51:14 -0000 On Dec 6, 2010, at 11:17 AM, Chuck Swiger wrote: > On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote: >> On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: >>> .xz smaller than .gz, but effective is about 96.2%:-(. >>=20 >> Some time ago I do similar tests. Changing compression for base man's = to bz2 or xz doesn't make much sense. >=20 > Oh, agreed. The issue with small files is that they will always take = up at least one sector [*]; different compression routines don't gain = any benefit if they don't change the number of sectors needed to store = the file. >=20 > More than half of the manpages end up as 1K .gz catman files as it is; = ~90% are 2K or smaller. It might make sense if XZ decompression were significantly faster than GZip decompression. (Especially since man pages are decompressed much more often than they are compressed.) Tim From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 07:50:20 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3AE6106564A for ; Tue, 7 Dec 2010 07:50:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 509A68FC1F for ; Tue, 7 Dec 2010 07:50:19 +0000 (UTC) Received: by fxm16 with SMTP id 16so10286617fxm.13 for ; Mon, 06 Dec 2010 23:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IfKftr4jJFm4nQVhsU5B/1VqtvbcFicb+slnTWf7sC8=; b=dGd/WD+OAL6EBLAmYShaNkT72+hBDIyYPGpx8fzQEomYyUML7oclA+9gtDO7l46C7J N5/pLPmlYoDCpRGCa0HeewFfkjDbATfcrr2Sh6lJ4sm6BPDzqdqTKbvUEEoNk+qSBvn0 U4BZL6YUcRqU1b9ci5O4KZtX/SVdgBpYJdnxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JjKEwI1j+N3UdVdN0NtjeEV7+ZJNfR6DcIhpaUh0J6emZHXxnWTLnsro7B4BJcQXgp 3wLXWAb5Xvv8+INi18Ewt6g0r9+SIwUxvY8BMS69LjTg4RpQk5YSXrbEtxgGjAvj9c7J 5D0QG0/Kf12SURTaCHKjJX/tpjpyl6/S1O7BY= Received: by 10.223.74.141 with SMTP id u13mr2331056faj.62.1291708219162; Mon, 06 Dec 2010 23:50:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y1sm1810562fak.39.2010.12.06.23.50.17 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 23:50:17 -0800 (PST) Sender: Alexander Motin Message-ID: <4CFDE738.9020801@FreeBSD.org> Date: Tue, 07 Dec 2010 09:50:16 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Rhodus References: <4CFC2114.6040203@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 07:50:20 -0000 On 06.12.2010 03:45, David Rhodus wrote: > On Sun, Dec 5, 2010 at 6:32 PM, Andriy Gapon wrote: >> on 05/12/2010 22:30 Julian Elischer said the following: >>> On 12/5/10 9:30 AM, Bernd Walter wrote: >>>> On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: >>>>> Just curious about why the in-kernel PPPoE interface was never ported >>>>> from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? >>>> Maybe because everyone who cares about in-kernel uses the FreeBSD >>>> in-kernel ng_pppoe via mpd? >>>> >>>>> From using it for a long time in OpenBSD I always found it quite stable >>>>> and easy to use. >>>> The same is true with mpd/ng_pppoe. >>> while I like mpd, I should point out that the regular 'in source' ppp that comes >>> with >>> freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my >>> gateway >>> as I never got around to installing mpd and it "did the job". >> >> BTW, there is a rumor that mpd may become an 'in source' program too. > > Does mpd work in -current ? Last tried I, netgraph had problems with mpd. Sure it does! What is the problem? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 07:55:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3299A106566B; Tue, 7 Dec 2010 07:55:40 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f49.google.com (mail-bw0-f49.google.com [209.85.214.49]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2E88FC15; Tue, 7 Dec 2010 07:55:39 +0000 (UTC) Received: by bwz5 with SMTP id 5so11954885bwz.8 for ; Mon, 06 Dec 2010 23:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=kznlTadG6pcqx0Wm5YnGdccGWDF60fmUj7a8KPjDsN4=; b=M8PATM6VrPVOx4W1VUM4VDHSAD3kf5ZBI2wO3IibRj1oVBChu6r6bjbSbEXNL97oVU p+ldNd0Iir02yS5vJQO/+zIfOLoLTYji0ZQpeIXGvmmALeBJLTDo5E21//g0VmngOa9Q iJwmI97DPnHAc5YKTdnHMkVK1Cwk/QIPzWeZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=LTuLV5wD676YayMPN1/ZbAa/sNBt0R8FeKaf13ujvHfGn1AHqxhknbpJnZJnWAFDYj TSosf6aaxaaKVLKA451Xu1RN8i1pa3VkZgBH3rLWAlR82E7DhkZx4wgkFUc8jSmhdP40 MIIb4fI5ziwZx7Qx91+54Sn6P1f4GVuq58t90= Received: by 10.204.75.77 with SMTP id x13mr90890bkj.162.1291707168766; Mon, 06 Dec 2010 23:32:48 -0800 (PST) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id f12sm2739034bkf.16.2010.12.06.23.32.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 23:32:47 -0800 (PST) Sender: Alex Kozlov Date: Tue, 7 Dec 2010 09:30:13 +0200 From: Alex Kozlov To: Tim Kientzle , Chuck Swiger , Norikatsu Shigemura , freebsd-current@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20101207073013.GA59001@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 07:55:40 -0000 On Mon, Dec 06, 2010 at 10:50:44PM -0800, Tim Kientzle wrote: > On Dec 6, 2010, at 11:17 AM, Chuck Swiger wrote: >> On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote: >>> On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: >>>> .xz smaller than .gz, but effective is about 96.2%:-(. >>> Some time ago I do similar tests. Changing compression for base man's >>> to bz2 or xz doesn't make much sense. >> Oh, agreed. The issue with small files is that they will always take up >> at least one sector [*]; different compression routines don't gain any >> benefit if they don't change the number of sectors needed to store the file. >> More than half of the manpages end up as 1K .gz catman files as it is; >> ~90% are 2K or smaller. > It might make sense if XZ decompression were significantly > faster than GZip decompression. (Especially since man pages > are decompressed much more often than they are compressed.) It's not. Bigest man from the base, FreeBSD 9.0-CURRENT Sat Oct 23 amd64, CPU: Pentium(R) Dual-Core CPU T4400 @ 2.20GHz (2194.55-MHz K8-class CPU), average of 3 tries: $ls -l CC.1* -rw-r--r-- 1 kozlov kozlov 584775 Dec 7 09:14 CC.1 -rw-r--r-- 1 kozlov kozlov 161663 Dec 7 09:14 CC.1.gz -rw-r--r-- 1 kozlov kozlov 131580 Dec 7 09:13 CC.1.xz $cat CC.1.?z >/dev/null $time xzcat CC.1.xz >/dev/null real 0m0.032s user 0m0.028s sys 0m0.000s $time gzcat CC.1.gz >/dev/null real 0m0.012s user 0m0.008s sys 0m0.000s -- Adios From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 08:52:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E52106566C for ; Tue, 7 Dec 2010 08:52:24 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5D718FC17 for ; Tue, 7 Dec 2010 08:52:23 +0000 (UTC) Received: by iwn39 with SMTP id 39so15759758iwn.13 for ; Tue, 07 Dec 2010 00:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=gOqD53YJrpA+kphcrK4rqaPy/ZhrPqASluY4c69F4UA=; b=bK/yer9LO+IKW31kwXNljQsEjg9Cjr7NKEAXxfNgKsl+MXMJYoDHo7LmwqhAjalfD6 PCtqEX5d6w48sTG3b5jyBiOQxTE/w8ysKlM34uZyMmNBQfLGoWCjKv+qGeRKGDeO9soQ CbiInnLX1P5LPfnjvWGc3vw79eDs2eX/ziEGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tWfyUjFhT0cvi8s13o5x0t988GzRtDmjDWDIxMwTvA9Alr2q5BFLNVTVZuaJqIQ2Al d4Hy3OI2Qnl21GFXd0HbFUlEcdZVTwxlLyzfvYc7RsemnZpjTVOjaD+84Rr53X3sPc27 GOu1l8TL+LHFycWF/pd5WiKrNe9zBeOi2TuT4= MIME-Version: 1.0 Received: by 10.231.14.140 with SMTP id g12mr7276335iba.84.1291710417245; Tue, 07 Dec 2010 00:26:57 -0800 (PST) Received: by 10.231.153.73 with HTTP; Tue, 7 Dec 2010 00:26:57 -0800 (PST) Date: Tue, 7 Dec 2010 03:26:57 -0500 Message-ID: From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: multipart/mixed; boundary=000325574d669295ee0496cdc456 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 08:52:24 -0000 --000325574d669295ee0496cdc456 Content-Type: text/plain; charset=UTF-8 A Dmesg.TXT is attached having a lock order reversal message . Thank you very much . Mehmet Erol Sanliturk --000325574d669295ee0496cdc456 Content-Type: text/plain; charset=US-ASCII; name="DMESG.TXT" Content-Disposition: attachment; filename="DMESG.TXT" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gheizskv0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5LjAtQ1VSUkVOVC0yMDEwMTEgIzA6IFdlZCBOb3Yg IDMgMTc6NDQ6NDggVVRDIDIwMTAKICAgIHJvb3RAZmFycmVsbC5jc2UuYnVmZmFsby5lZHU6L3Vz ci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBl bmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KQ1BVOiBJbnRlbChSKSBDb3JlKFRN KTIgUXVhZCBDUFUgICAgUTY2MDAgIEAgMi40MEdIeiAoMjM5Ny42NS1NSHogSzgtY2xhc3MgQ1BV KQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmZiICBGYW1pbHkgPSA2ICBNb2Rl bCA9IGYgIFN0ZXBwaW5nID0gMTEKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNF LFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2 LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0 dXJlczI9MHhlM2JkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsVk1YLEVTVCxUTTIsU1NTRTMsQ1gx Nix4VFBSLFBEQ00+CiAgQU1EIEZlYXR1cmVzPTB4MjAxMDA4MDA8U1lTQ0FMTCxOWCxMTT4KICBB TUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKcmVhbCBtZW1v cnkgID0gMjE0NzQ4MzY0OCAoMjA0OCBNQikKYXZhaWwgbWVtb3J5ID0gMjAyNDAzODQwMCAoMTkz MCBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxJ TlRFTCAgREc5NjVXSCA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0 ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpCiBjcHUwIChC U1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElD IElEOiAgMgogY3B1MyAoQVApOiBBUElDIElEOiAgMwppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElE IHRvIDIKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQx IGF0IGtiZG11eDAKYWNwaTA6IDxJTlRFTCBERzk2NVdIPiBvbiBtb3RoZXJib2FyZAphY3BpMDog UG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1 Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5 NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNw aTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNw dTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBh Y3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFj cGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJs ZSBkaXNwbGF5PiBwb3J0IDB4MzQxMC0weDM0MTcgbWVtIDB4OTAyMDAwMDAtMHg5MDJmZmZmZiww eDgwMDAwMDAwLTB4OGZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNpMAphZ3AwOiA8 SW50ZWwgRzk2NSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAKYWdwMDogYXBlcnR1cmUgc2l6 ZSBpcyAyNTZNLCBkZXRlY3RlZCA3Njc2ayBzdG9sZW4gbWVtb3J5CnBjaTA6IDxzaW1wbGUgY29t bXM+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZW0wOiA8SW50ZWwoUikgUFJP LzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDcuMS43PiBwb3J0IDB4MzBlMC0weDMwZmYgbWVtIDB4 OTAzMDAwMDAtMHg5MDMxZmZmZiwweDkwMzI0MDAwLTB4OTAzMjRmZmYgaXJxIDIwIGF0IGRldmlj ZSAyNS4wIG9uIHBjaTAKZW0wOiBVc2luZyBhbiBNU0kgaW50ZXJydXB0CmFjcXVpcmluZyBkdXBs aWNhdGUgbG9jayBvZiBzYW1lIHR5cGU6ICJuZXR3b3JrIGRyaXZlciIKIDFzdCAmZGV2X3NwZWMt PnN3ZmxhZ19tdXRleCBAIC91c3Ivc3JjL3N5cy9kZXYvZTEwMDAvZTEwMDBfaWNoOGxhbi5jOjc3 OAogMm5kICZkZXZfc3BlYy0+bnZtX211dGV4IEAgL3Vzci9zcmMvc3lzL2Rldi9lMTAwMC9lMTAw MF9pY2g4bGFuLmM6NzQ0CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBw ZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQprZGJfYmFja3RyYWNlKCkgYXQga2Ri X2JhY2t0cmFjZSsweDM3Cl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIr MHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4ZGUKX210 eF9sb2NrX2ZsYWdzKCkgYXQgX210eF9sb2NrX2ZsYWdzKzB4NzkKZTEwMDBfYWNxdWlyZV9udm1f aWNoOGxhbigpIGF0IGUxMDAwX2FjcXVpcmVfbnZtX2ljaDhsYW4rMHgxZQplMTAwMF9yZWFkX252 bV9pY2g4bGFuKCkgYXQgZTEwMDBfcmVhZF9udm1faWNoOGxhbisweDc2CmUxMDAwX3Bvc3RfcGh5 X3Jlc2V0X2ljaDhsYW4oKSBhdCBlMTAwMF9wb3N0X3BoeV9yZXNldF9pY2g4bGFuKzB4MWIxCmUx MDAwX3Jlc2V0X2h3X2ljaDhsYW4oKSBhdCBlMTAwMF9yZXNldF9od19pY2g4bGFuKzB4NGMxCmVt X2F0dGFjaCgpIGF0IGVtX2F0dGFjaCsweDEyMGYKZGV2aWNlX2F0dGFjaCgpIGF0IGRldmljZV9h dHRhY2grMHg2OQpidXNfZ2VuZXJpY19hdHRhY2goKSBhdCBidXNfZ2VuZXJpY19hdHRhY2grMHgx YQphY3BpX3BjaV9hdHRhY2goKSBhdCBhY3BpX3BjaV9hdHRhY2grMHgxNGYKZGV2aWNlX2F0dGFj aCgpIGF0IGRldmljZV9hdHRhY2grMHg2OQpidXNfZ2VuZXJpY19hdHRhY2goKSBhdCBidXNfZ2Vu ZXJpY19hdHRhY2grMHgxYQphY3BpX3BjaWJfYXR0YWNoKCkgYXQgYWNwaV9wY2liX2F0dGFjaCsw eDFhNwphY3BpX3BjaWJfYWNwaV9hdHRhY2goKSBhdCBhY3BpX3BjaWJfYWNwaV9hdHRhY2grMHgx ZmQKZGV2aWNlX2F0dGFjaCgpIGF0IGRldmljZV9hdHRhY2grMHg2OQpidXNfZ2VuZXJpY19hdHRh Y2goKSBhdCBidXNfZ2VuZXJpY19hdHRhY2grMHgxYQphY3BpX2F0dGFjaCgpIGF0IGFjcGlfYXR0 YWNoKzB4YWEwCmRldmljZV9hdHRhY2goKSBhdCBkZXZpY2VfYXR0YWNoKzB4NjkKYnVzX2dlbmVy aWNfYXR0YWNoKCkgYXQgYnVzX2dlbmVyaWNfYXR0YWNoKzB4MWEKbmV4dXNfYWNwaV9hdHRhY2go KSBhdCBuZXh1c19hY3BpX2F0dGFjaCsweDY5CmRldmljZV9hdHRhY2goKSBhdCBkZXZpY2VfYXR0 YWNoKzB4NjkKYnVzX2dlbmVyaWNfbmV3X3Bhc3MoKSBhdCBidXNfZ2VuZXJpY19uZXdfcGFzcysw eGQ2CmJ1c19zZXRfcGFzcygpIGF0IGJ1c19zZXRfcGFzcysweDdhCmNvbmZpZ3VyZSgpIGF0IGNv bmZpZ3VyZSsweGEKbWlfc3RhcnR1cCgpIGF0IG1pX3N0YXJ0dXArMHg3NwpidGV4dCgpIGF0IGJ0 ZXh0KzB4MmMKZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxYzpjMDoxZTpjNDowNQp1aGNpMDog PEludGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IHBvcnQgMHgzMGMwLTB4 MzBkZiBpcnEgMTYgYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNpMDogTGVnU3VwID0gMHgyZjAw CnVzYnVzMDogPEludGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IG9uIHVo Y2kwCnVoY2kxOiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBVU0ItRT4gcG9y dCAweDMwYTAtMHgzMGJmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBMZWdT dXAgPSAweDJmMDAKdXNidXMxOiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBV U0ItRT4gb24gdWhjaTEKZWhjaTA6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiAyLjAgY29udHJv bGxlciBVU0IyLUI+IG1lbSAweDkwMzI1YzAwLTB4OTAzMjVmZmYgaXJxIDE4IGF0IGRldmljZSAy Ni43IG9uIHBjaTAKdXNidXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPEludGVsIDgyODAx SCAoSUNIOCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQjItQj4gb24gZWhjaTAKcGNpMDogPG11bHRp bWVkaWEsIEhEQT4gYXQgZGV2aWNlIDI3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4 LjEgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgphdGFwY2kwOiA8TWFydmVs bCA4OFNYNjEwMSBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgyMDE4LTB4MjAxZiwweDIwMjQt MHgyMDI3LDB4MjAxMC0weDIwMTcsMHgyMDIwLTB4MjAyMywweDIwMDAtMHgyMDBmIG1lbSAweDkw MTAwMDAwLTB4OTAxMDAxZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMgphdGEyOiA8QVRB IGNoYW5uZWwgMD4gb24gYXRhcGNpMApwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAyOC4yIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4 LjQgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQp1aGNpMjogPEludGVsIDgy ODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHgzMDgwLTB4MzA5ZiBpcnEg MjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMjogTGVnU3VwID0gMHgyZjAwCnVzYnVzMzog PEludGVsIDgyODAxSCAoSUNIOCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kyCnVoY2kz OiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweDMwNjAt MHgzMDdmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kzOiBMZWdTdXAgPSAweDJm MDAKdXNidXM0OiA8SW50ZWwgODI4MDFIIChJQ0g4KSBVU0IgY29udHJvbGxlciBVU0ItQj4gb24g dWhjaTMKdWhjaTQ6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBw b3J0IDB4MzA0MC0weDMwNWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTQ6IExl Z1N1cCA9IDB4MmYwMAp1c2J1czU6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250cm9sbGVy IFVTQi1DPiBvbiB1aGNpNAplaGNpMTogPEludGVsIDgyODAxSCAoSUNIOCkgVVNCIDIuMCBjb250 cm9sbGVyIFVTQjItQT4gbWVtIDB4OTAzMjU4MDAtMHg5MDMyNWJmZiBpcnEgMjMgYXQgZGV2aWNl IDI5Ljcgb24gcGNpMAp1c2J1czY6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM2OiA8SW50ZWwgODI4 MDFIIChJQ0g4KSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCMi1BPiBvbiBlaGNpMQpwY2liNjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpNjogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjYKcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJhc2VUWD4gcG9ydCAweDEw MDAtMHgxMGZmIG1lbSAweDkwMDA0ODAwLTB4OTAwMDQ4ZmYgaXJxIDE4IGF0IGRldmljZSAyLjAg b24gcGNpNgptaWlidXMwOiA8TUlJIGJ1cz4gb24gcmwwCnJscGh5MDogPFJlYWxUZWsgaW50ZXJu YWwgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMCBvbiBtaWlidXMwCnJscGh5MDogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KcmwwOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDoxZjoxZjozODpiZDo5Ywpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVudHMgVFNC NDNBQjIyL0E+IG1lbSAweDkwMDA0MDAwLTB4OTAwMDQ3ZmYsMHg5MDAwMDAwMC0weDkwMDAzZmZm IGlycSAxOSBhdCBkZXZpY2UgMy4wIG9uIHBjaTYKZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMTAg KFJPTT0wKQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNp MDogRVVJNjQgMDA6OTA6Mjc6MDA6MDE6ZjM6MTA6MzcKZndvaGNpMDogUGh5IDEzOTRhIGF2YWls YWJsZSBTNDAwLCAyIHBvcnRzLgpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRl cy4KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMApmd2UwOiA8 RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwCmlmX2Z3ZTA6IEZha2UgRXRoZXJu ZXQgYWRkcmVzczogMDI6OTA6Mjc6ZjM6MTA6MzcKZndlMDogRXRoZXJuZXQgYWRkcmVzczogMDI6 OTA6Mjc6ZjM6MTA6MzcKZndpcDA6IDxJUCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndp cDA6IEZpcmV3aXJlIGFkZHJlc3M6IDAwOjkwOjI3OjAwOjAxOmYzOjEwOjM3IEAgMHhmZmZlMDAw MDAwMDAsIFM0MDAsIG1heHJlYyAyMDQ4CnNicDA6IDxTQlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+ IG9uIGZpcmV3aXJlMApkY29uc19jcm9tMDogPGRjb25zIGNvbmZpZ3VyYXRpb24gUk9NPiBvbiBm aXJld2lyZTAKZGNvbnNfY3JvbTA6IGJ1c19hZGRyIDB4N2U1YzQwMDAKZndvaGNpMDogSW5pdGlh dGUgYnVzIHJlc2V0CmZ3b2hjaTA6IGZ3b2hjaV9pbnRyX2NvcmU6IEJVUyByZXNldApmd29oY2kw OiBmd29oY2lfaW50cl9jb3JlOiBub2RlX2lkPTB4MDAwMDAwMDAsIFNlbGZJRCBDb3VudD0xLCBD WUNMRU1BU1RFUiBtb2RlCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9u IHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTE6IDxJbnRlbCBJQ0g4IFNBVEEz MDAgY29udHJvbGxlcj4gcG9ydCAweDM0MDgtMHgzNDBmLDB4MzQxYy0weDM0MWYsMHgzNDAwLTB4 MzQwNywweDM0MTgtMHgzNDFiLDB4MzAyMC0weDMwM2YgbWVtIDB4OTAzMjUwMDAtMHg5MDMyNTdm ZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kxOiBBSENJIGNhbGxlZCBmcm9t IHZlbmRvciBzcGVjaWZpYyBkcml2ZXIKYXRhcGNpMTogQUhDSSB2MS4xMCBjb250cm9sbGVyIHdp dGggNiAzR2JwcyBwb3J0cywgUE0gbm90IHN1cHBvcnRlZAphdGEzOiA8QVRBIGNoYW5uZWwgMD4g b24gYXRhcGNpMQphdGE0OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGE1OiA8QVRBIGNo YW5uZWwgMj4gb24gYXRhcGNpMQphdGE2OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNpMQphdGE3 OiA8QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMQphdGE4OiA8QVRBIGNoYW5uZWwgNT4gb24gYXRh cGNpMQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIg YXR0YWNoZWQpCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSwweDc0 LTB4NzcgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6 IHF1YWxpdHkgMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMg aXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5 IDEwMApwcGMwOiA8UGFyYWxsZWwgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiwweDc3OC0weDc3ZiBp cnEgNyBvbiBhY3BpMApwcGMwOiBHZW5lcmljIGNoaXBzZXQgKEVDUC9QUzIvTklCQkxFKSBpbiBD T01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2LzggYnl0ZXMgdGhyZXNob2xkCnBw YnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBsaXAwOiA8UExJUCBuZXR3b3JrIGlu dGVyZmFjZT4gb24gcHBidXMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJy dXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAp1YXJ0MDogPDE2 NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBh Y3BpMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGQwODAwLTB4ZDE3ZmYsMHhk MTgwMC0weGQyN2ZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAw IG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2Ew OiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhi ZmZmZiBvbiBpc2EwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBv cnQgMHg2MCwweDY0IG9uIGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2Jk YzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMvMiBNb3Vz ZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwgTW91 c2VNYW4rLCBkZXZpY2UgSUQgMAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBD b250cm9sPiBvbiBjcHUwCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHUwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNw dTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKZXN0Mjog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MgpwNHRjYzI6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Mgplc3QzOiA8RW5oYW5jZWQgU3Bl ZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCnA0dGNjMzogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHUzClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1z ZWMKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCBjYWJsZSBJUk0gaXJtKDApICAobWUp IApmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNC IHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDQ4ME1icHMg SGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVl ZCBVU0IgdjEuMAp1c2J1czY6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAphY2QwOiBEVkRS IDxQSElMSVBTIFNQRDI0MTRUL1AxLjA+IGF0IGF0YTItbWFzdGVyIFVETUE2NiAKdWdlbjAuMTog PEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNi dXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPElu dGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBVSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW40LjE6 IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2VuNS4xOiA8SW50ZWw+IGF0IHVz YnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2J1czUKdWdlbjYuMTogPEludGVsPiBhdCB1c2J1czYKdWh1YjY6IDxJ bnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXM2CmFkODogNDc2OTQwTUIgPFNlYWdhdGUgU1QzNTAwMzIwQVMgU0QxNT4gYXQgYXRhNC1t YXN0ZXIgVURNQTEwMCBTQVRBIDEuNUdiL3MKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogNCBwb3J0cyB3aXRoIDQgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBh c2NxPTB4MDAgCihwcm9iZTc6YXRhMjowOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAg MCAwIDAgMCAKKHByb2JlNzphdGEyOjA6MDowKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0dXMgRXJy b3IKKHByb2JlNzphdGEyOjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlvbgoocHJv YmU3OmF0YTI6MDowOjApOiBTQ1NJIHNlbnNlOiBOT1QgUkVBRFkgYXNjOjNhLDEgKE1lZGl1bSBu b3QgcHJlc2VudCAtIHRyYXkgY2xvc2VkKQpjZDAgYXQgYXRhMiBidXMgMCBzY2J1czEgdGFyZ2V0 IDAgbHVuIDAKY2QwOiA8UEhJTElQUyBTUEQyNDE0VCBQMS4wPiBSZW1vdmFibGUgQ0QtUk9NIFND U0ktMCBkZXZpY2UgCmNkMDogNjYuMDAwTUIvcyB0cmFuc2ZlcnMKY2QwOiBBdHRlbXB0IHRvIHF1 ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQgLSB0 cmF5IGNsb3NlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1bmNo ZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFi bGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJv bSB1ZnM6L2Rldi9hZDhzMWEgW3J3XS4uLgp1Z2VuMi4yOiA8S2luZ3N0b24+IGF0IHVzYnVzMgp1 bWFzczA6IDxLaW5nc3RvbiBEYXRhVHJhdmVsZXIgMi4wLCBjbGFzcyAwLzAsIHJldiAyLjAwLzIu MDAsIGFkZHIgMj4gb24gdXNidXMyCnVtYXNzMDogIFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJr cyA9IDB4MDAwMAp1bWFzczA6MzowOi0xOiBBdHRhY2hlZCB0byBzY2J1czMKZGEwIGF0IHVtYXNz LXNpbTAgYnVzIDAgc2NidXMzIHRhcmdldCAwIGx1biAwCmRhMDogPEtpbmdzdG9uIERhdGFUcmF2 ZWxlciAyLjAgMS4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSAKZGEw OiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDk4OE1CICgyMDIzNDI0IDUxMiBieXRlIHNlY3Rv cnM6IDY0SCAzMlMvVCA5ODhDKQpHRU9NOiBkYTA6IHBhcnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0 IG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGRhMDogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5k IG9uIGEgdHJhY2sgYm91bmRhcnkuCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhmZmZmZmYw MDA5MjI3Mjc4IHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19tb3VudC5jOjEyMDgK IDJuZCAweGZmZmZmZjAwMDk1ZDcyNzggZGV2ZnMgKGRldmZzKSBAIC91c3Ivc3JjL3N5cy9mcy9t c2Rvc2ZzL21zZG9zZnNfdmZzb3BzLmM6OTU2CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFj ZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQprZGJfYmFja3Ry YWNlKCkgYXQga2RiX2JhY2t0cmFjZSsweDM3Cl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5l c3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3Jk ZXIrMHg4MDcKX19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGQ0Mgp2b3Bfc3Rk bG9jaygpIGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9B UFYrMHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NDcKbXNkb3Nmc19zeW5jKCkgYXQgbXNk b3Nmc19zeW5jKzB4MjI3CmRvdW5tb3VudCgpIGF0IGRvdW5tb3VudCsweDJjMAp1bm1vdW50KCkg YXQgdW5tb3VudCsweDI4ZQpzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsw eGUyCi0tLSBzeXNjYWxsICgyMiwgRnJlZUJTRCBFTEY2NCwgdW5tb3VudCksIHJpcCA9IDB4ODAw NmEyM2JjLCByc3AgPSAweDdmZmZmZmZmZTQwOCwgcmJwID0gMHg4MDBjMDg0MzggLS0tCg== --000325574d669295ee0496cdc456-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 09:20:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1728A1065693 for ; Tue, 7 Dec 2010 09:20:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C00DE8FC19 for ; Tue, 7 Dec 2010 09:20:23 +0000 (UTC) Received: by ywp6 with SMTP id 6so6964750ywp.13 for ; Tue, 07 Dec 2010 01:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=mH/AHVojK/Tih9XCSekLtuY0Ver8Wn0Mm9L3ZU2W8yQ=; b=yDwMzWxaEcf1f9tsCnoQyY4xzMkr5QK+rLzSvCzwXosYvqh4VbSbhrjcMIBWYMBmKG oJRcDZ0OR2M5/WQKbvW9V/RUKip7MMFZ+eIDpr8jfbmErOHpool3xD6GRvGBnGAru9W7 uBakTMSr7hogTLNFnroB6oYkyRGtv88eWiF7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=xBwavPn1uoK2VCDg8BzR8E4fQJIBeNLc+H0UG/v66etfgBSh+37mlYQhmySAP1fUXM x4uO5s8yq413JxxmmvaAIWY5Yq6htZty+7lY9VKOclbVFEHhaDV9zE6rSlF66YN6/pUY u6JR5Atzl4gWbdr+sUZ3BaETVDvhBJWaJFR78= Received: by 10.151.150.11 with SMTP id c11mr1294121ybo.413.1291713623365; Tue, 07 Dec 2010 01:20:23 -0800 (PST) Received: from [192.168.20.8] (c-76-102-149-233.hsd1.ca.comcast.net [76.102.149.233]) by mx.google.com with ESMTPS id f73sm3735106yhc.4.2010.12.07.01.20.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 01:20:22 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <44B787D8-243C-4880-A532-261435C89940@gmail.com> X-Mailer: iPhone Mail (8C148) From: Garrett Cooper Date: Tue, 7 Dec 2010 01:20:13 -0800 To: Mehmet Erol Sanliturk Cc: freebsd-current Subject: Re: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 09:20:26 -0000 On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk = wrote: > A Dmesg.TXT is attached having a lock order reversal . The mount LOR is well known. The duplicate lock held WITNESS warning wit= h em(4) might be of interest though. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 10:15:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB16106564A for ; Tue, 7 Dec 2010 10:15:45 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 220E18FC0A for ; Tue, 7 Dec 2010 10:15:44 +0000 (UTC) Received: from [192.168.0.22] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp3.one.com (Postfix) with ESMTP id 492DE2406908; Tue, 7 Dec 2010 09:57:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-18--123955561; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <44B787D8-243C-4880-A532-261435C89940@gmail.com> Date: Tue, 7 Dec 2010 10:57:36 +0100 Message-Id: References: <44B787D8-243C-4880-A532-261435C89940@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 10:15:45 -0000 --Apple-Mail-18--123955561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 07/12/2010 kl. 10.20 skrev Garrett Cooper: > On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk = wrote: >=20 >> A Dmesg.TXT is attached having a lock order reversal . >=20 > The mount LOR is well known. I see that this is the standard response to lot's of LOR reports. It = seems to be one of the most-reported errors on CURRENT (and it's = certainly a loud one), but I think a lot of people waste time = researching the error and browsing Bjoerns LOR page, only to get the = above response (not picking on you, Garrett). Do we have the possibility of silencing well-known and presumably = harmless LOR's if there isn't sufficient motivation to fix the source? Erik= --Apple-Mail-18--123955561-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 11:10:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74E99106564A; Tue, 7 Dec 2010 11:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id F26658FC1B; Tue, 7 Dec 2010 11:10:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0788E41C736; Tue, 7 Dec 2010 12:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id HaJew7EIgbMq; Tue, 7 Dec 2010 12:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6CBC341C735; Tue, 7 Dec 2010 12:10:05 +0100 (CET) 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 5BCDE4448F3; Tue, 7 Dec 2010 11:07:50 +0000 (UTC) Date: Tue, 7 Dec 2010 11:07:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Alexander Motin In-Reply-To: <4CFDE738.9020801@FreeBSD.org> Message-ID: <20101207110603.S6126@maildrop.int.zabbadoz.net> References: <4CFC2114.6040203@freebsd.org> <4CFDE738.9020801@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 11:10:07 -0000 On Tue, 7 Dec 2010, Alexander Motin wrote: >> Does mpd work in -current ? Last tried I, netgraph had problems with mpd. > > Sure it does! What is the problem? There have been several reports (incl. panics) on various lists like net, stable, ... during the last months for mostly 8.x (and HEAD). None of which was really followed up to to my memory. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 11:41:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C7EE1065673 for ; Tue, 7 Dec 2010 11:41:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx1.freebsd.org (Postfix) with ESMTP id 532E68FC14 for ; Tue, 7 Dec 2010 11:41:22 +0000 (UTC) Received: by gxk28 with SMTP id 28so7954654gxk.17 for ; Tue, 07 Dec 2010 03:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PmbT6p6ibj+1b7hh/YQZ8SaVP3kxtLAugyKAsPwsvxA=; b=mDhUy2rwVe0PMtg+zlP2lwiFpU7TRJwczMjIH8VT/7ZUB9LuggTPuq+x7TL6d3tpsV 17zi3Ggr18a/2OUvAcf4e4LlYKKNE2Yp3tH5EdxftqM6y9g63HryHMt3FUgUK5fr+ev5 TJhCibClsZlWS6auII7rqc0gAgz9VjVjJeKmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ei1T3fTtiX+Tc5F43cxZc3IXGM5tFn7eI9wjZp88YVjsdqERlAgL8I/ViA8cQE0MjZ 0gu4UJ5wYOGuoDkLzsrvr3Wh/YCc+DljU/pUcDFZY75hTV08dqI6I8QYEDVNaBpeZkT0 7ABgoZ82mKJkr9FrjwR4VpsjA3AWzEwAYTF4A= MIME-Version: 1.0 Received: by 10.150.11.5 with SMTP id 5mr1532739ybk.430.1291722081672; Tue, 07 Dec 2010 03:41:21 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.236.109.45 with HTTP; Tue, 7 Dec 2010 03:41:21 -0800 (PST) In-Reply-To: References: <44B787D8-243C-4880-A532-261435C89940@gmail.com> Date: Tue, 7 Dec 2010 12:41:21 +0100 X-Google-Sender-Auth: l8iyPT7HIU7bZdHaTQqp84WI8nI Message-ID: From: Attilio Rao To: Erik Cederstrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current Subject: Re: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 11:41:22 -0000 2010/12/7 Erik Cederstrand : > > Den 07/12/2010 kl. 10.20 skrev Garrett Cooper: > >> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk wrote: >> >>> A Dmesg.TXT is attached having a lock order reversal . >> >> =C2=A0 =C2=A0The mount LOR is well known. > > I see that this is the standard response to lot's of LOR reports. It seem= s to be one of the most-reported errors on CURRENT (and it's certainly a lo= ud one), but I think a lot of people waste time researching the error and b= rowsing Bjoerns LOR page, only to get the above response (not picking on yo= u, Garrett). > > Do we have the possibility of silencing well-known and presumably harmles= s LOR's if there isn't sufficient motivation to fix the source? Witness has an 'internal blessing list' we never wanted to use in order to keep them popping up as reminder. Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'. The very few 'Analyzed but harmless' cases in the past have been handled via _NOWITNESS flags I guess. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 14:39:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534D0106566C; Tue, 7 Dec 2010 14:39:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D2B8F8FC17; Tue, 7 Dec 2010 14:39:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5EBB746B38; Tue, 7 Dec 2010 09:39:55 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 575328A009; Tue, 7 Dec 2010 09:39:54 -0500 (EST) From: John Baldwin To: David Xu Date: Tue, 7 Dec 2010 09:13:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <4CFD7BB0.20500@freebsd.org> In-Reply-To: <4CFD7BB0.20500@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012070913.17118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 07 Dec 2010 09:39:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 14:39:56 -0000 On Monday, December 06, 2010 7:11:28 pm David Xu wrote: > John Baldwin wrote: > > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > > > >> Sometime in the last 7-10 days, some one made a > >> change that has broken process accounting/timing. > >> > >> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > >> foreach? time ./testf > >> foreach? end > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 69.55 real 38.39 user 30.94 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 68.82 real 40.95 user 27.60 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 69.14 real 38.90 user 30.02 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 68.79 real 40.59 user 27.99 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 68.93 real 39.76 user 28.96 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 68.71 real 41.21 user 27.29 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 69.05 real 39.68 user 29.15 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 68.99 real 39.98 user 28.80 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 69.02 real 39.64 user 29.16 sys > >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >> 69.38 real 37.49 user 31.67 sys > >> > >> testf is a numerically intensive program that tests the > >> accuracy of expf() in a tight loop. User time varies > >> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > >> I'm fairly certain that the code does not suddenly grow/loose > >> 6 GFLOP of operations. > >> > > > > The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > > hz) to figure out a user vs sys split and use that to divide up the total > > runtime (which actually is fairly accurate). All you need is for the clock > > ticks to fire just a bit differently between runs to get a swing in user vs > > system time. > > > > What I would like is to keep separate raw bintime's for user vs system time in > > the raw data instead, but that would involve checking the CPU ticker more > > often (e.g. twice for each syscall, interrupt, and trap in addition to the > > current once per context switch). So far folks seem to be more worried about > > the extra overhead rather than the loss of accuracy. > > > > > Adding any instruction into global syscall path should be cautioned, it > is worse then before, thinking about a threaded application, a userland > thread may have locked a mutex and calls a system call, the overhead > added to system call path can directly affect a threaded application's > performance now, because the time window the mutex is held > is longer than before, I have seen some people likes to fiddle with > system call path, it should be cautioned. OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful thing you can do is to sum them since the total is known to be accurate at least. If it wouldn't make things so messy I'd consider a new kernel option 'ACCURATE_RUSAGE' or some such. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 16:53:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1F7C106564A for ; Tue, 7 Dec 2010 16:53:36 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 474808FC0C for ; Tue, 7 Dec 2010 16:53:35 +0000 (UTC) Received: by ywp6 with SMTP id 6so96969ywp.13 for ; Tue, 07 Dec 2010 08:53:35 -0800 (PST) Received: by 10.151.39.11 with SMTP id r11mr2177269ybj.121.1291740814908; Tue, 07 Dec 2010 08:53:34 -0800 (PST) Received: from [10.123.2.178] (99-74-169-43.lightspeed.sntcca.sbcglobal.net [99.74.169.43]) by mx.google.com with ESMTPS id d4sm2539637ybi.12.2010.12.07.08.53.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 08:53:32 -0800 (PST) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Tue, 7 Dec 2010 08:53:27 -0800 Content-Transfer-Encoding: 7bit Message-Id: <51C74C0C-659E-40F2-83F9-502A26C40584@freebsd.org> References: To: Sergey Kandaurov X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Current Subject: Re: Extracting tgz file: Attempt to write to an empty file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 16:53:36 -0000 On Nov 29, 2010, at 9:19 AM, Sergey Kandaurov wrote: > I see these errors when tar (not limited to but including the version > from FreeBSD -current) > > # bsdtar -xf ~/arch.tgz > ./: Attempt to write to an empty file > ./.cpan/: Attempt to write to an empty file > ./.cpan/CPAN/: Attempt to write to an empty file > ./.cpan/build/: Attempt to write to an empty file I just committed a fix to -CURRENT (r216258). Please try it and let me know if this fixes the problem for you. Tim From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 17:00:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from pelsia.ninth-nine.com (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 651261065670; Tue, 7 Dec 2010 17:00:12 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Wed, 8 Dec 2010 01:59:29 +0900 From: Norikatsu Shigemura To: freebsd-current@freebsd.org Message-Id: <20101208015929.4aec1bdb.nork@FreeBSD.org> In-Reply-To: <1639A255-7C84-4D81-A97E-AEB624E68A70@kientzle.com> References: <20101206171358.GA17125@ravenloft.kiev.ua> <9132C068-A9C7-41EE-AA98-714385441EE3@mac.com> <1639A255-7C84-4D81-A97E-AEB624E68A70@kientzle.com> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alex, Norikatsu Shigemura , Kozlov Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 17:00:13 -0000 On Mon, 6 Dec 2010 22:50:44 -0800 Tim Kientzle wrote: > >> Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. > > Oh, agreed. The issue with small files is that they will always take up at least one sector [*]; different compression routines don't gain any benefit if they don't change the number of sectors needed to store the file. > > More than half of the manpages end up as 1K .gz catman files as it is; ~90% are 2K or smaller. > It might make sense if XZ decompression were significantly > faster than GZip decompression. (Especially since man pages > are decompressed much more often than they are compressed.) Oh, that's good! But this setting causes pkg-plist break of ports. Maybe, some ports chase bsd.own.mk (COMPRESS_CMD, COMPRESS_EXT), but it assumed that MANEXT is .gz:-(. Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 17:19:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6B8106567A for ; Tue, 7 Dec 2010 17:19:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-12.mx.aerioconnect.net [216.240.47.72]) by mx1.freebsd.org (Postfix) with ESMTP id ADD128FC12 for ; Tue, 7 Dec 2010 17:19:05 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oB7HJ2qS026140; Tue, 7 Dec 2010 09:19:02 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 279AD2D6021; Tue, 7 Dec 2010 09:19:00 -0800 (PST) Message-ID: <4CFE6C83.70100@freebsd.org> Date: Tue, 07 Dec 2010 09:18:59 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Attilio Rao References: <44B787D8-243C-4880-A532-261435C89940@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Garrett Cooper , freebsd-current , Erik Cederstrand Subject: Re: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 17:19:05 -0000 On 12/7/10 3:41 AM, Attilio Rao wrote: > 2010/12/7 Erik Cederstrand: >> Den 07/12/2010 kl. 10.20 skrev Garrett Cooper: >> >>> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk wrote: >>> >>>> A Dmesg.TXT is attached having a lock order reversal . >>> The mount LOR is well known. >> I see that this is the standard response to lot's of LOR reports. It seems to be one of the most-reported errors on CURRENT (and it's certainly a loud one), but I think a lot of people waste time researching the error and browsing Bjoerns LOR page, only to get the above response (not picking on you, Garrett). >> >> Do we have the possibility of silencing well-known and presumably harmless LOR's if there isn't sufficient motivation to fix the source? > Witness has an 'internal blessing list' we never wanted to use in > order to keep them popping up as reminder. > Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'. > The very few 'Analyzed but harmless' cases in the past have been > handled via _NOWITNESS flags I guess. the problem is that the witness output tells you the second case (the reversed case) but it doesn't have any clues about the first case (the one that wsa the other way around). An extended witness might use a lot of memory but associate with each lock a 'last place called when a lock was already held' that might give a clue as to where the other instance was. I'm not volunteering to write it, but it might be very worth while.. I'd certainly like to hear other ideas as well. > Attilio > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 19:10:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A07D106567A for ; Tue, 7 Dec 2010 19:10:31 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 718538FC17 for ; Tue, 7 Dec 2010 19:10:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LD2006K0NX8Y220@asmtp025.mac.com> for freebsd-current@freebsd.org; Tue, 07 Dec 2010 11:10:21 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012070133 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-07_09:2010-12-07, 2010-12-07, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <20101207073013.GA59001@ravenloft.kiev.ua> Date: Tue, 07 Dec 2010 11:10:20 -0800 Message-id: <8637F403-A98A-4814-8769-BC713858962E@mac.com> References: <20101207073013.GA59001@ravenloft.kiev.ua> To: Alex Kozlov X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Current Subject: Re: trying to use xz on manuals. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 19:10:31 -0000 On Dec 6, 2010, at 11:30 PM, Alex Kozlov wrote: > On Mon, Dec 06, 2010 at 10:50:44PM -0800, Tim Kientzle wrote: >> It might make sense if XZ decompression were significantly >> faster than GZip decompression. (Especially since man pages >> are decompressed much more often than they are compressed.) > > It's not. Agreed, gzip is faster than XZ, but for manpages the difference is so small that a human won't notice any difference. The slowest machine I have around is a Pentium III @ 933 MHz, and it's getting (typical results from 5 trials, on a FreeBSD 7.4-PRERELEASE system) shows: $ time gzcat CC.1.gz > /dev/null real 0m0.021s user 0m0.013s sys 0m0.007s $ time xzcat CC.1.xz > /dev/null real 0m0.063s user 0m0.055s sys 0m0.007s Regards, -- -Chuck PS: I installed bash just to get millisecond-accuracy for the timing. :-) Is there any way to convince the default /bin/sh or /usr/bin/time to output the same...? From owner-freebsd-current@FreeBSD.ORG Tue Dec 7 19:40:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341AE1065673 for ; Tue, 7 Dec 2010 19:40:45 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id CE6318FC23 for ; Tue, 7 Dec 2010 19:40:44 +0000 (UTC) Received: by iwn9 with SMTP id 9so252035iwn.19 for ; Tue, 07 Dec 2010 11:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=juBEuXkOB9/OTN7xpo+kQ/u6sPgrGJdqF3H7lVUBANA=; b=GkIiVSBNZKuQmDTAb0+EyhheZ9YsseCy6bvvK0mqBRK4DzPEFOq7siy2iePOL8GvFk E1bZrp6KOva6Q/DSt1Oi82Hil4M30RDIB/2UIsjodpoS2QDnrS/nthxSYflko9gXuqlP FF00rU6chnbWW+iPnPmfSOWDwCbMUH77+nK84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KaYL7ZP2Iq5pI5voMeB1/7UKmBMo12JnJ49/gUiaV4fDtMGVfU2fH9qfEJZgILR/xt u0ZZd5sWM0wFg+cErHkLvKlvQF/VMiidktvMbcam897KKOi8YOIXAarDwf8FubS4Xe/R LkC77LwJz6vxIJ+D04oc8T7CMxRXXaMn1EqGs= MIME-Version: 1.0 Received: by 10.231.15.136 with SMTP id k8mr7999786iba.51.1291750843930; Tue, 07 Dec 2010 11:40:43 -0800 (PST) Received: by 10.231.35.130 with HTTP; Tue, 7 Dec 2010 11:40:41 -0800 (PST) In-Reply-To: <4CFE6C83.70100@freebsd.org> References: <44B787D8-243C-4880-A532-261435C89940@gmail.com> <4CFE6C83.70100@freebsd.org> Date: Tue, 7 Dec 2010 11:40:41 -0800 Message-ID: From: Matthew Fleming To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , Garrett Cooper , freebsd-current , Erik Cederstrand Subject: Re: Lock order reversal . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Dec 2010 19:40:45 -0000 On Tue, Dec 7, 2010 at 9:18 AM, Julian Elischer wrote: > On 12/7/10 3:41 AM, Attilio Rao wrote: >> >> 2010/12/7 Erik Cederstrand: >>> >>> Den 07/12/2010 kl. 10.20 skrev Garrett Cooper: >>> >>>> On Dec 7, 2010, at 12:26 AM, Mehmet Erol >>>> Sanliturk =A0wrote: >>>> >>>>> A Dmesg.TXT is attached having a lock order reversal . >>>> >>>> =A0 =A0The mount LOR is well known. >>> >>> I see that this is the standard response to lot's of LOR reports. It >>> seems to be one of the most-reported errors on CURRENT (and it's certai= nly a >>> loud one), but I think a lot of people waste time researching the error= and >>> browsing Bjoerns LOR page, only to get the above response (not picking = on >>> you, Garrett). >>> >>> Do we have the possibility of silencing well-known and presumably >>> harmless LOR's if there isn't sufficient motivation to fix the source? >> >> Witness has an 'internal blessing list' we never wanted to use in >> order to keep them popping up as reminder. >> Actually, the fact the LOR is 'known' doesn't mean it is 'analyzed'. >> The very few 'Analyzed but harmless' cases in the past have been >> handled via _NOWITNESS flags I guess. > > the problem is that the witness output tells you the second case (the > reversed case) > but it doesn't have any clues about the first case (the one that wsa the > other way around). > > An extended witness might use a lot of memory but associate with each loc= k a > 'last place called when a lock was already held' > that might give a clue as to where the other instance was. I'm not > volunteering to write it, > but it might be very worth while.. I'd certainly like to hear other ideas= as > well. I have a small patch against stable/7 that adds a single bit to each witness structure so that, if the "normal" lock order is ever encountered after a reversal, the stack is printed. It doesn't help when the order is defined statically, though. I could try to roll this up against -CURRENT this weekend. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 02:54:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2C0106566B; Wed, 8 Dec 2010 02:54:07 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 604A58FC16; Wed, 8 Dec 2010 02:54:07 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB82s5nx082060; Wed, 8 Dec 2010 02:54:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4CFEF34D.1030701@freebsd.org> Date: Wed, 08 Dec 2010 10:54:05 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: John Baldwin References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <4CFD7BB0.20500@freebsd.org> <201012070913.17118.jhb@freebsd.org> In-Reply-To: <201012070913.17118.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Dec 2010 02:54:07 -0000 John Baldwin wrote: > On Monday, December 06, 2010 7:11:28 pm David Xu wrote: >> John Baldwin wrote: >>> On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: >>> >>>> Sometime in the last 7-10 days, some one made a >>>> change that has broken process accounting/timing. >>>> >>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >>>> foreach? time ./testf >>>> foreach? end >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.55 real 38.39 user 30.94 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.82 real 40.95 user 27.60 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.14 real 38.90 user 30.02 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.79 real 40.59 user 27.99 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.93 real 39.76 user 28.96 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.71 real 41.21 user 27.29 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.05 real 39.68 user 29.15 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 68.99 real 39.98 user 28.80 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.02 real 39.64 user 29.16 sys >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>> 69.38 real 37.49 user 31.67 sys >>>> >>>> testf is a numerically intensive program that tests the >>>> accuracy of expf() in a tight loop. User time varies >>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >>>> I'm fairly certain that the code does not suddenly grow/loose >>>> 6 GFLOP of operations. >>>> >>> The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 >>> hz) to figure out a user vs sys split and use that to divide up the total >>> runtime (which actually is fairly accurate). All you need is for the clock >>> ticks to fire just a bit differently between runs to get a swing in user vs >>> system time. >>> >>> What I would like is to keep separate raw bintime's for user vs system time in >>> the raw data instead, but that would involve checking the CPU ticker more >>> often (e.g. twice for each syscall, interrupt, and trap in addition to the >>> current once per context switch). So far folks seem to be more worried about >>> the extra overhead rather than the loss of accuracy. >>> >>> >> Adding any instruction into global syscall path should be cautioned, it >> is worse then before, thinking about a threaded application, a userland >> thread may have locked a mutex and calls a system call, the overhead >> added to system call path can directly affect a threaded application's >> performance now, because the time window the mutex is held >> is longer than before, I have seen some people likes to fiddle with >> system call path, it should be cautioned. > > OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful > thing you can do is to sum them since the total is known to be accurate at > least. > > If it wouldn't make things so messy I'd consider a new kernel option > 'ACCURATE_RUSAGE' or some such. > Our getrusage is already very slow, everytime, it needs to iterate the threads list with a process SLOCK held. I saw some mysql versions heavily use getrusage, and a horribly slow. I think a ACCURATE_RUSAGE will make it worse ? From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 10:28:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC691106566C for ; Wed, 8 Dec 2010 10:28:56 +0000 (UTC) (envelope-from vermaden@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 21A4E8FC18 for ; Wed, 8 Dec 2010 10:28:55 +0000 (UTC) Received: (qmail invoked by alias); 08 Dec 2010 10:28:54 -0000 Received: from unknown (EHLO [10.48.50.2]) [194.0.181.128] by mail.gmx.com (mp-eu004) with SMTP; 08 Dec 2010 11:28:54 +0100 X-Authenticated: #68675852 X-Provags-ID: V01U2FsdGVkX1/UhbpTfXPUeQfzKeBydH6AT2V3ySHoe9vb3y8+Zv DE0uOT/EZYhsuF From: vermaden To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Dec 2010 11:29:51 +0100 Message-ID: <1291804191.9972.2.camel@e6400.gkpge.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 08 Dec 2010 12:21:13 +0000 Cc: Subject: OpenIndiana code improovements that may be used in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 10:28:56 -0000 Hi, if you know about these, the forget about this mail. There are interesgin code changes that are useful for FreeBSD, these include for example improoved printf command: http://gdamore.blogspot.com/2010/12/zfs-should-not-depend-on-python-and.html ... and python-free ZFS commands: http://gdamore.blogspot.com/2010/10/new-implementation-of-printf.html "FreeBSD folks, you might want to incorporate this into your tree. If you do, I'd sure like to know." "The license remains BSD, so the various BSD operating systems (or even Oracle) are free to incorporate these improvements if they like." Regards, vermaden From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 11:00:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D346106566B for ; Wed, 8 Dec 2010 11:00:26 +0000 (UTC) (envelope-from vermaden@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 8A4DE8FC16 for ; Wed, 8 Dec 2010 11:00:25 +0000 (UTC) Received: (qmail invoked by alias); 08 Dec 2010 11:00:24 -0000 Received: from unknown (EHLO [10.48.50.2]) [194.0.181.128] by mail.gmx.com (mp-eu005) with SMTP; 08 Dec 2010 12:00:24 +0100 X-Authenticated: #68675852 X-Provags-ID: V01U2FsdGVkX18fZqx0x6MfGgqIIh7p4hs2StnmiV0j1+2YiQRmE9 qh/kPsGf/GLtKF From: vermaden To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Dec 2010 12:01:26 +0100 Message-ID: <1291806086.9972.9.camel@e6400.gkpge.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 08 Dec 2010 12:21:25 +0000 Cc: Subject: OpenIndiana code improovements that may be used in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 11:00:26 -0000 Hi, If you know about these, the forge These include for example improoved printf command: http://gdamore.blogspot.com/2010/12/zfs-should-not-depend-on-python-and.html ... and python-free ZFS commands: http://gdamore.blogspot.com/2010/10/new-implementation-of-printf.html "FreeBSD folks, you might want to incorporate this into your tree. If you do, I'd sure like to know." "The license remains BSD, so the various BSD operating systems (or even Oracle) are free to incorporate these improvements if they like." From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:12:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A9E9106566B; Wed, 8 Dec 2010 15:12:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5964E8FC16; Wed, 8 Dec 2010 15:12:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 046AC46B0D; Wed, 8 Dec 2010 10:12:08 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B685D8A009; Wed, 8 Dec 2010 10:12:06 -0500 (EST) From: John Baldwin To: David Xu Date: Wed, 8 Dec 2010 09:29:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012070913.17118.jhb@freebsd.org> <4CFEF34D.1030701@freebsd.org> In-Reply-To: <4CFEF34D.1030701@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012080929.22825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 08 Dec 2010 10:12:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Dec 2010 15:12:08 -0000 On Tuesday, December 07, 2010 9:54:05 pm David Xu wrote: > John Baldwin wrote: > > On Monday, December 06, 2010 7:11:28 pm David Xu wrote: > >> John Baldwin wrote: > >>> On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > >>> > >>>> Sometime in the last 7-10 days, some one made a > >>>> change that has broken process accounting/timing. > >>>> > >>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) > >>>> foreach? time ./testf > >>>> foreach? end > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 69.55 real 38.39 user 30.94 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 68.82 real 40.95 user 27.60 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 69.14 real 38.90 user 30.02 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 68.79 real 40.59 user 27.99 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 68.93 real 39.76 user 28.96 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 68.71 real 41.21 user 27.29 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 69.05 real 39.68 user 29.15 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 68.99 real 39.98 user 28.80 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 69.02 real 39.64 user 29.16 sys > >>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 > >>>> 69.38 real 37.49 user 31.67 sys > >>>> > >>>> testf is a numerically intensive program that tests the > >>>> accuracy of expf() in a tight loop. User time varies > >>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. > >>>> I'm fairly certain that the code does not suddenly grow/loose > >>>> 6 GFLOP of operations. > >>>> > >>> The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > >>> hz) to figure out a user vs sys split and use that to divide up the total > >>> runtime (which actually is fairly accurate). All you need is for the clock > >>> ticks to fire just a bit differently between runs to get a swing in user vs > >>> system time. > >>> > >>> What I would like is to keep separate raw bintime's for user vs system time in > >>> the raw data instead, but that would involve checking the CPU ticker more > >>> often (e.g. twice for each syscall, interrupt, and trap in addition to the > >>> current once per context switch). So far folks seem to be more worried about > >>> the extra overhead rather than the loss of accuracy. > >>> > >>> > >> Adding any instruction into global syscall path should be cautioned, it > >> is worse then before, thinking about a threaded application, a userland > >> thread may have locked a mutex and calls a system call, the overhead > >> added to system call path can directly affect a threaded application's > >> performance now, because the time window the mutex is held > >> is longer than before, I have seen some people likes to fiddle with > >> system call path, it should be cautioned. > > > > OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful > > thing you can do is to sum them since the total is known to be accurate at > > least. > > > > If it wouldn't make things so messy I'd consider a new kernel option > > 'ACCURATE_RUSAGE' or some such. > > > Our getrusage is already very slow, everytime, it needs to > iterate the threads list with a process SLOCK held. I saw some mysql > versions heavily use getrusage, and a horribly slow. I think a > ACCURATE_RUSAGE will make it worse ? Using 'time foo' only retrieves the usage once at the end via wait(). However, FWIW, I think ACCURATE_RUSAGE would simplify calcru1() quite a bit since you would just sum up the thread's usage (as we do know), but then do a direct conversion from bintime to timeval for user and system without ever having to worry about time going backwards, etc. All the hacks to enforce monotonicity that are currently in place would go away since we would have the real measurements and not be inferring them from statclock ticks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:18:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C7D6106564A; Wed, 8 Dec 2010 15:18:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A9A8E8FC14; Wed, 8 Dec 2010 15:18:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FIpGR069770; Wed, 8 Dec 2010 10:18:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FIkTH069454; Wed, 8 Dec 2010 15:18:46 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:18:46 GMT Message-Id: <201012081518.oB8FIkTH069454@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm 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, 08 Dec 2010 15:18:53 -0000 TB --- 2010-12-08 14:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 14:55:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-12-08 14:55:00 - cleaning the object tree TB --- 2010-12-08 14:55:09 - cvsupping the source tree TB --- 2010-12-08 14:55:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-12-08 14:55:29 - building world TB --- 2010-12-08 14:55:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 14:55:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 14:55:29 - TARGET=arm TB --- 2010-12-08 14:55:29 - TARGET_ARCH=arm TB --- 2010-12-08 14:55:29 - TZ=UTC TB --- 2010-12-08 14:55:29 - __MAKE_CONF=/dev/null TB --- 2010-12-08 14:55:29 - cd /src TB --- 2010-12-08 14:55:29 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 14:55:30 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:18:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:18:46 - ERROR: failed to build world TB --- 2010-12-08 15:18:46 - 1069.31 user 269.38 system 1426.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:22:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9E2106566B; Wed, 8 Dec 2010 15:22:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B2A8C8FC1A; Wed, 8 Dec 2010 15:22:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FMdTA098055; Wed, 8 Dec 2010 10:22:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FMd11098024; Wed, 8 Dec 2010 15:22:39 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:22:39 GMT Message-Id: <201012081522.oB8FMd11098024@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 08 Dec 2010 15:22:41 -0000 TB --- 2010-12-08 14:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 14:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-12-08 14:55:00 - cleaning the object tree TB --- 2010-12-08 14:55:24 - cvsupping the source tree TB --- 2010-12-08 14:55:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-12-08 14:55:38 - building world TB --- 2010-12-08 14:55:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 14:55:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 14:55:38 - TARGET=i386 TB --- 2010-12-08 14:55:38 - TARGET_ARCH=i386 TB --- 2010-12-08 14:55:38 - TZ=UTC TB --- 2010-12-08 14:55:38 - __MAKE_CONF=/dev/null TB --- 2010-12-08 14:55:38 - cd /src TB --- 2010-12-08 14:55:38 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 14:55:38 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:22:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:22:39 - ERROR: failed to build world TB --- 2010-12-08 15:22:39 - 1258.89 user 278.24 system 1659.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:22:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E1E010656BE; Wed, 8 Dec 2010 15:22:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DC05A8FC14; Wed, 8 Dec 2010 15:22:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FMnOP001016; Wed, 8 Dec 2010 10:22:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FMnDA001006; Wed, 8 Dec 2010 15:22:49 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:22:49 GMT Message-Id: <201012081522.oB8FMnDA001006@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 15:22:50 -0000 TB --- 2010-12-08 14:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 14:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-12-08 14:55:00 - cleaning the object tree TB --- 2010-12-08 14:55:22 - cvsupping the source tree TB --- 2010-12-08 14:55:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-12-08 14:55:37 - building world TB --- 2010-12-08 14:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 14:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 14:55:37 - TARGET=pc98 TB --- 2010-12-08 14:55:37 - TARGET_ARCH=i386 TB --- 2010-12-08 14:55:37 - TZ=UTC TB --- 2010-12-08 14:55:37 - __MAKE_CONF=/dev/null TB --- 2010-12-08 14:55:37 - cd /src TB --- 2010-12-08 14:55:37 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 14:55:37 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:22:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:22:49 - ERROR: failed to build world TB --- 2010-12-08 15:22:49 - 1256.80 user 289.79 system 1669.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:26:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D084D1065693; Wed, 8 Dec 2010 15:26:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE498FC12; Wed, 8 Dec 2010 15:26:31 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:2c91:fa66:2350:ddab] ([IPv6:2607:f3e0:0:4:2c91:fa66:2350:ddab]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FQSss036820 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 Dec 2010 10:26:29 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CFFA39D.9000907@sentex.net> Date: Wed, 08 Dec 2010 10:26:21 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4CFC2114.6040203@freebsd.org> <4CFDE738.9020801@FreeBSD.org> <20101207110603.S6126@maildrop.int.zabbadoz.net> In-Reply-To: <20101207110603.S6126@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , FreeBSD current mailing list Subject: Re: In-kernel PPPoE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Dec 2010 15:26:31 -0000 On 12/7/2010 6:07 AM, Bjoern A. Zeeb wrote: > On Tue, 7 Dec 2010, Alexander Motin wrote: > >>> Does mpd work in -current ? Last tried I, netgraph had problems with >>> mpd. >> >> Sure it does! What is the problem? > > There have been several reports (incl. panics) on various lists like > net, stable, ... during the last months for mostly 8.x (and HEAD). > None of which was really followed up to to my memory. > >From a kernel from Sept2, I would get this panic / crash after a week of running mpd with ipv6 enabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc5ef3e15 stack pointer = 0x28:0xc4fe4838 frame pointer = 0x28:0xc4fe484c 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 = 1000 (ng_queue1) trap number = 12 panic: page fault cpuid = 1 Uptime: 6d4h9m42s Physical memory: 2036 MB Dumping 240 MB: 225 209 193 177panic: bufwrite: buffer is not busy??? cpuid = 1 161 145 129 113 97 81 65 49 33 17 1 (kgdb) #0 doadump () at pcpu.h:231 #1 0xc0681233 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0681499 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc08ea3ec in trap_fatal (frame=0xc4fe47f8, eva=36) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc08ea650 in trap_pfault (frame=0xc4fe47f8, usermode=0, eva=36) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc08eaf19 in trap (frame=0xc4fe47f8) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc08cd4bc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5ef3e15 in ng_address_hook (here=0x0, item=0xc5f03c40, hook=0xcb685980, retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3504 #8 0xc5f7ebfb in ng_tcpmss_rcvdata (hook=0xc6618300, item=0xc5f03c40) at /usr/src/sys/modules/netgraph/tcpmss/../../../netgraph/ng_tcpmss.c:347 #9 0xc5ef57c4 in ng_apply_item (node=0xca955b00, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #10 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #11 0xc5f6dd30 in ng_ppp_proto_recv (node=0xc6431300, item=0xc5f03c40, proto=Variable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:949 #12 0xc5f6ea25 in ng_ppp_rcvdata (hook=0xcb228a80, item=0xc5f03c40) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1524 #13 0xc5ef57c4 in ng_apply_item (node=0xc6431300, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #14 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #15 0xc5ef57c4 in ng_apply_item (node=0xcb375c80, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #16 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #17 0xc5ef57c4 in ng_apply_item (node=0xc6330100, item=0xc5f03c40, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0xc5ef479f in ng_snd_item (item=0xc5f03c40, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #19 0xc5f4db1c in ng_ksocket_incoming2 (node=0xc6431e00, hook=0x0, arg1=0xc63479a8, arg2=0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1153 #20 0xc5ef58f9 in ng_apply_item (node=0xc6431e00, item=0xc5f02780, rw=1) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #21 0xc5ef6a46 in ngthread (arg=0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3351 #22 0xc0656cd1 in fork_exit (callout=0xc5ef68e0 , arg=0x0, frame=0xc4fe4d38) at /usr/src/sys/kern/kern_fork.c:844 #23 0xc08cd534 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 (kgdb) Since there were a number of ipv6 patches, I thought I would try again with a kernel from today as well as the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=148857 Still get the WITNESS warning below. Not sure if its a "bad" thing or has anything to do with the above panic. uma_zalloc_arg: zone "1024" with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0b67144) locked @ /usr/src/sys/net/if.c:434 KDB: stack backtrace: db_trace_self_wrapper(c0928b5a,c2d0,2e,0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(1b2,2,ffffffff,c0b399d4,e7cda8f4,...) at kdb_backtrace+0x2a _witness_debugger(c092a29d,e7cda908,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0940817,c092486e,c06b9966,...) at witness_warn+0x1fe uma_zalloc_arg(c158a000,0,102,400,c5658c00,...) at uma_zalloc_arg+0x34 malloc(400,c09b9c14,102,80,c5658c00,...) at malloc+0x4e if_grow(c0b67144,c093128c,1b2,1b2,35000101,...) at if_grow+0x35 if_alloc(35,c63920a0,101,c6392160,0,...) at if_alloc+0xd3 ng_iface_constructor(c67ced00,e7cdaa54,c5816800,c685b400,e7cdaa64,...) at ng_iface_constructor+0x3b ng_make_node(c685b438,e7cdaa54,0,0,0,...) at ng_make_node+0x5b ng_apply_item(c5816848,0,1,e7cdaa84,c5816800,...) at ng_apply_item+0x3ea ng_snd_item(c6362400,0,c6541340,0,28afcf40,...) at ng_snd_item+0x28f ngc_send(c6203670,0,c67ed200,c656b1c0,0,...) at ngc_send+0x1c2 sosend_generic(c6203670,c656b1c0,e7cdabb8,0,0,...) at sosend_generic+0x50d sosend(c6203670,c656b1c0,e7cdabb8,0,0,...) at sosend+0x3f kern_sendit(c66df5a0,5,e7cdac2c,0,0,...) at kern_sendit+0x107 sendit(0,c656b1c0,5,e7cdac48,1,...) at sendit+0xb1 sendto(c66df5a0,e7cdacec,e7cdad28,c0929daa,0,...) at sendto+0x48 syscallenter(c66df5a0,e7cdace4,e7cdace4,0,c66df5a0,...) at syscallenter+0x22b syscall(e7cdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x284b3977, esp = 0xbf7fc8cc, ebp = 0xbf7fc8f8 --- > /bz > From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:28:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B445106564A; Wed, 8 Dec 2010 15:28:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A86B38FC12; Wed, 8 Dec 2010 15:28:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FStlx056978; Wed, 8 Dec 2010 10:28:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FSsTk056976; Wed, 8 Dec 2010 15:28:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:28:54 GMT Message-Id: <201012081528.oB8FSsTk056976@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 08 Dec 2010 15:28:57 -0000 TB --- 2010-12-08 14:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 14:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-12-08 14:55:00 - cleaning the object tree TB --- 2010-12-08 14:55:27 - cvsupping the source tree TB --- 2010-12-08 14:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-12-08 15:00:51 - building world TB --- 2010-12-08 15:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:00:51 - TARGET=amd64 TB --- 2010-12-08 15:00:51 - TARGET_ARCH=amd64 TB --- 2010-12-08 15:00:51 - TZ=UTC TB --- 2010-12-08 15:00:51 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:00:51 - cd /src TB --- 2010-12-08 15:00:51 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:00:52 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:28:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:28:54 - ERROR: failed to build world TB --- 2010-12-08 15:28:54 - 1291.13 user 281.74 system 2034.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:47:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE04A1065670; Wed, 8 Dec 2010 15:47:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECA58FC22; Wed, 8 Dec 2010 15:47:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FlPoK039455; Wed, 8 Dec 2010 10:47:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FlPod039450; Wed, 8 Dec 2010 15:47:25 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:47:25 GMT Message-Id: <201012081547.oB8FlPod039450@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips 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, 08 Dec 2010 15:47:27 -0000 TB --- 2010-12-08 15:22:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:22:40 - starting HEAD tinderbox run for mips/mips TB --- 2010-12-08 15:22:40 - cleaning the object tree TB --- 2010-12-08 15:22:47 - cvsupping the source tree TB --- 2010-12-08 15:22:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-12-08 15:22:58 - building world TB --- 2010-12-08 15:22:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:22:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:22:58 - TARGET=mips TB --- 2010-12-08 15:22:58 - TARGET_ARCH=mips TB --- 2010-12-08 15:22:58 - TZ=UTC TB --- 2010-12-08 15:22:58 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:22:58 - cd /src TB --- 2010-12-08 15:22:58 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:22:59 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:47:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:47:25 - ERROR: failed to build world TB --- 2010-12-08 15:47:25 - 1105.76 user 257.85 system 1485.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:48:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0835E1065673; Wed, 8 Dec 2010 15:48:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A01478FC1D; Wed, 8 Dec 2010 15:48:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8Fmphn047019; Wed, 8 Dec 2010 10:48:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8Fmp8V047014; Wed, 8 Dec 2010 15:48:51 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:48:51 GMT Message-Id: <201012081548.oB8Fmp8V047014@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 15:48:52 -0000 TB --- 2010-12-08 15:18:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:18:52 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-12-08 15:18:52 - cleaning the object tree TB --- 2010-12-08 15:19:04 - cvsupping the source tree TB --- 2010-12-08 15:19:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-12-08 15:19:17 - building world TB --- 2010-12-08 15:19:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:19:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:19:17 - TARGET=ia64 TB --- 2010-12-08 15:19:17 - TARGET_ARCH=ia64 TB --- 2010-12-08 15:19:17 - TZ=UTC TB --- 2010-12-08 15:19:17 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:19:17 - cd /src TB --- 2010-12-08 15:19:17 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:19:18 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:48:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:48:51 - ERROR: failed to build world TB --- 2010-12-08 15:48:51 - 1403.33 user 269.40 system 1798.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:50:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC8F1065673; Wed, 8 Dec 2010 15:50:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E755A8FC08; Wed, 8 Dec 2010 15:50:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FoK2d055275; Wed, 8 Dec 2010 10:50:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FoKA1055270; Wed, 8 Dec 2010 15:50:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:50:20 GMT Message-Id: <201012081550.oB8FoKA1055270@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc 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, 08 Dec 2010 15:50:21 -0000 TB --- 2010-12-08 15:22:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:22:49 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-12-08 15:22:49 - cleaning the object tree TB --- 2010-12-08 15:22:59 - cvsupping the source tree TB --- 2010-12-08 15:22:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-12-08 15:23:12 - building world TB --- 2010-12-08 15:23:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:23:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:23:12 - TARGET=powerpc TB --- 2010-12-08 15:23:12 - TARGET_ARCH=powerpc TB --- 2010-12-08 15:23:12 - TZ=UTC TB --- 2010-12-08 15:23:12 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:23:12 - cd /src TB --- 2010-12-08 15:23:12 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:23:12 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:50:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:50:20 - ERROR: failed to build world TB --- 2010-12-08 15:50:20 - 1252.06 user 260.14 system 1650.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 15:56:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D14E106566B; Wed, 8 Dec 2010 15:56:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D18288FC1B; Wed, 8 Dec 2010 15:56:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FuLGo004451; Wed, 8 Dec 2010 10:56:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FuLbr004446; Wed, 8 Dec 2010 15:56:21 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:56:21 GMT Message-Id: <201012081556.oB8FuLbr004446@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc 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, 08 Dec 2010 15:56:22 -0000 TB --- 2010-12-08 15:28:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:28:55 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-12-08 15:28:55 - cleaning the object tree TB --- 2010-12-08 15:29:08 - cvsupping the source tree TB --- 2010-12-08 15:29:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-12-08 15:29:22 - building world TB --- 2010-12-08 15:29:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:29:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:29:22 - TARGET=powerpc TB --- 2010-12-08 15:29:22 - TARGET_ARCH=powerpc64 TB --- 2010-12-08 15:29:22 - TZ=UTC TB --- 2010-12-08 15:29:22 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:29:22 - cd /src TB --- 2010-12-08 15:29:22 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:29:23 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:56:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:56:21 - ERROR: failed to build world TB --- 2010-12-08 15:56:21 - 1272.06 user 269.80 system 1646.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:11:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2D21106564A; Wed, 8 Dec 2010 16:11:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5278FC12; Wed, 8 Dec 2010 16:11:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8GB1ht093614; Wed, 8 Dec 2010 11:11:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8GB1rE093613; Wed, 8 Dec 2010 16:11:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:11:01 GMT Message-Id: <201012081611.oB8GB1rE093613@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 08 Dec 2010 16:11:02 -0000 TB --- 2010-12-08 15:47:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:47:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-12-08 15:47:25 - cleaning the object tree TB --- 2010-12-08 15:47:37 - cvsupping the source tree TB --- 2010-12-08 15:47:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-12-08 15:47:50 - building world TB --- 2010-12-08 15:47:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:47:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:47:50 - TARGET=sparc64 TB --- 2010-12-08 15:47:50 - TARGET_ARCH=sparc64 TB --- 2010-12-08 15:47:50 - TZ=UTC TB --- 2010-12-08 15:47:50 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:47:50 - cd /src TB --- 2010-12-08 15:47:50 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:47:50 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:11:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:11:01 - ERROR: failed to build world TB --- 2010-12-08 16:11:01 - 1161.25 user 245.38 system 1415.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:12:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E7A71065672; Wed, 8 Dec 2010 16:12:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E6CB88FC13; Wed, 8 Dec 2010 16:12:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8GCLuW097173; Wed, 8 Dec 2010 11:12:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8GCLht097172; Wed, 8 Dec 2010 16:12:21 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:12:21 GMT Message-Id: <201012081612.oB8GCLht097172@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v 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, 08 Dec 2010 16:12:22 -0000 TB --- 2010-12-08 15:48:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:48:51 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-12-08 15:48:51 - cleaning the object tree TB --- 2010-12-08 15:48:59 - cvsupping the source tree TB --- 2010-12-08 15:48:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-12-08 15:49:12 - building world TB --- 2010-12-08 15:49:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:49:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:49:12 - TARGET=sun4v TB --- 2010-12-08 15:49:12 - TARGET_ARCH=sparc64 TB --- 2010-12-08 15:49:12 - TZ=UTC TB --- 2010-12-08 15:49:12 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:49:12 - cd /src TB --- 2010-12-08 15:49:12 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:49:13 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:12:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:12:21 - ERROR: failed to build world TB --- 2010-12-08 16:12:21 - 1158.87 user 246.28 system 1410.10 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:38:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2473110656AB; Wed, 8 Dec 2010 16:38:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C3AAE8FC2C; Wed, 8 Dec 2010 16:38:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8GcGGD029069; Wed, 8 Dec 2010 11:38:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8GcG4G029047; Wed, 8 Dec 2010 16:38:16 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:38:16 GMT Message-Id: <201012081638.oB8GcG4G029047@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm 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, 08 Dec 2010 16:38:18 -0000 TB --- 2010-12-08 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-12-08 16:15:00 - cleaning the object tree TB --- 2010-12-08 16:15:04 - cvsupping the source tree TB --- 2010-12-08 16:15:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-12-08 16:15:17 - building world TB --- 2010-12-08 16:15:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:15:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:15:17 - TARGET=arm TB --- 2010-12-08 16:15:17 - TARGET_ARCH=arm TB --- 2010-12-08 16:15:17 - TZ=UTC TB --- 2010-12-08 16:15:17 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:15:17 - cd /src TB --- 2010-12-08 16:15:17 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:15:17 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:38:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:38:16 - ERROR: failed to build world TB --- 2010-12-08 16:38:16 - 1068.16 user 266.59 system 1396.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:42:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425E0106566C; Wed, 8 Dec 2010 16:42:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D74488FC08; Wed, 8 Dec 2010 16:42:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8GgKKj064243; Wed, 8 Dec 2010 11:42:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8GgKol064228; Wed, 8 Dec 2010 16:42:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:42:20 GMT Message-Id: <201012081642.oB8GgKol064228@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 08 Dec 2010 16:42:21 -0000 TB --- 2010-12-08 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-12-08 16:15:00 - cleaning the object tree TB --- 2010-12-08 16:15:04 - cvsupping the source tree TB --- 2010-12-08 16:15:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-12-08 16:15:17 - building world TB --- 2010-12-08 16:15:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:15:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:15:17 - TARGET=i386 TB --- 2010-12-08 16:15:17 - TARGET_ARCH=i386 TB --- 2010-12-08 16:15:17 - TZ=UTC TB --- 2010-12-08 16:15:17 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:15:17 - cd /src TB --- 2010-12-08 16:15:17 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:15:18 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:42:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:42:20 - ERROR: failed to build world TB --- 2010-12-08 16:42:20 - 1258.48 user 266.71 system 1639.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:42:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930F31065697; Wed, 8 Dec 2010 16:42:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4A48FC2D; Wed, 8 Dec 2010 16:42:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8Ggqpo069868; Wed, 8 Dec 2010 11:42:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8GgqG4069867; Wed, 8 Dec 2010 16:42:52 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:42:52 GMT Message-Id: <201012081642.oB8GgqG4069867@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 08 Dec 2010 16:42:53 -0000 TB --- 2010-12-08 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-12-08 16:15:00 - cleaning the object tree TB --- 2010-12-08 16:15:04 - cvsupping the source tree TB --- 2010-12-08 16:15:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-12-08 16:15:17 - building world TB --- 2010-12-08 16:15:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:15:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:15:17 - TARGET=amd64 TB --- 2010-12-08 16:15:17 - TARGET_ARCH=amd64 TB --- 2010-12-08 16:15:17 - TZ=UTC TB --- 2010-12-08 16:15:17 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:15:17 - cd /src TB --- 2010-12-08 16:15:17 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:15:18 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:42:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:42:52 - ERROR: failed to build world TB --- 2010-12-08 16:42:52 - 1285.38 user 275.77 system 1672.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:47:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F0B9106567A; Wed, 8 Dec 2010 16:47:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BAD558FC14; Wed, 8 Dec 2010 16:47:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8Glq0Y013684; Wed, 8 Dec 2010 11:47:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8Glqh0013679; Wed, 8 Dec 2010 16:47:52 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 16:47:52 GMT Message-Id: <201012081647.oB8Glqh0013679@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 16:47:54 -0000 TB --- 2010-12-08 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-12-08 16:15:00 - cleaning the object tree TB --- 2010-12-08 16:15:04 - cvsupping the source tree TB --- 2010-12-08 16:15:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-12-08 16:20:27 - building world TB --- 2010-12-08 16:20:27 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:20:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:20:27 - TARGET=pc98 TB --- 2010-12-08 16:20:27 - TARGET_ARCH=i386 TB --- 2010-12-08 16:20:27 - TZ=UTC TB --- 2010-12-08 16:20:27 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:20:27 - cd /src TB --- 2010-12-08 16:20:27 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:20:27 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 16:47:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 16:47:52 - ERROR: failed to build world TB --- 2010-12-08 16:47:52 - 1260.06 user 274.34 system 1972.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 16:54:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08EEE10656DB; Wed, 8 Dec 2010 16:54:47 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB2C8FC1A; Wed, 8 Dec 2010 16:54:46 +0000 (UTC) Received: by qwj9 with SMTP id 9so1483088qwj.13 for ; Wed, 08 Dec 2010 08:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=asg5ayqdVyrtD3LdVPouz9ESuV/0F1idlVInDE30Gsg=; b=WvYilkPVUe86CMM9W1VmQojs7dl2tcAf1LL1lMYzsbZrILwcYtCM7paX5CnoNkgc4I /RpZP0F4yKuD7lgz1EzSOM7Ow9mnDfgpkJDxH9LXQCovMklx16XSFAwm+DRge4jA5oYp xWKz2OF1N1JhWo4ovLrI+sFgx8W2QlOYQGXew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nRENfBi4qDx1+IloWIZeQZceBF4Y2gei9HsHexNPsRnRQFfoYnhjV7VQd/U2kTBL4f ZI+V3w65Eg5cWVe0zSX6lDE0YQv5tPd3KUco29PARsxBytc3cLMDW++4UdoBXotoWDW+ 1QBGwbmFvdqd1nb2Pk8hCnMYWCNCgsO7LnKY0= MIME-Version: 1.0 Received: by 10.229.224.81 with SMTP id in17mr7087224qcb.81.1291827285824; Wed, 08 Dec 2010 08:54:45 -0800 (PST) Received: by 10.229.39.147 with HTTP; Wed, 8 Dec 2010 08:54:45 -0800 (PST) In-Reply-To: <51C74C0C-659E-40F2-83F9-502A26C40584@freebsd.org> References: <51C74C0C-659E-40F2-83F9-502A26C40584@freebsd.org> Date: Wed, 8 Dec 2010 19:54:45 +0300 Message-ID: From: Sergey Kandaurov To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Extracting tgz file: Attempt to write to an empty file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Dec 2010 16:54:47 -0000 On 7 December 2010 19:53, Tim Kientzle wrote: > On Nov 29, 2010, at 9:19 AM, Sergey Kandaurov wrote: >> I see these errors when tar (not limited to but including the version >> from FreeBSD -current) >> >> # bsdtar -xf ~/arch.tgz >> ./: Attempt to write to an empty file >> ./.cpan/: Attempt to write to an empty file >> ./.cpan/CPAN/: Attempt to write to an empty file >> ./.cpan/build/: Attempt to write to an empty file > > I just committed a fix to -CURRENT (r216258). > > Please try it and let me know if this fixes the problem for you. > I applied the fix to 8.1-RELEASE, and am fine with it. No more "Attempt to write..". Thanks! -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 17:07:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425C1106566C; Wed, 8 Dec 2010 17:07:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DD80C8FC20; Wed, 8 Dec 2010 17:07:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8H72ss000684; Wed, 8 Dec 2010 12:07:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8H723M000675; Wed, 8 Dec 2010 17:07:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 17:07:02 GMT Message-Id: <201012081707.oB8H723M000675@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips 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, 08 Dec 2010 17:07:03 -0000 TB --- 2010-12-08 16:42:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:42:20 - starting HEAD tinderbox run for mips/mips TB --- 2010-12-08 16:42:20 - cleaning the object tree TB --- 2010-12-08 16:42:24 - cvsupping the source tree TB --- 2010-12-08 16:42:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-12-08 16:42:36 - building world TB --- 2010-12-08 16:42:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:42:36 - TARGET=mips TB --- 2010-12-08 16:42:36 - TARGET_ARCH=mips TB --- 2010-12-08 16:42:36 - TZ=UTC TB --- 2010-12-08 16:42:36 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:42:36 - cd /src TB --- 2010-12-08 16:42:36 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:42:36 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 17:07:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 17:07:02 - ERROR: failed to build world TB --- 2010-12-08 17:07:02 - 1105.76 user 255.27 system 1481.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 17:07:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6627B1065695; Wed, 8 Dec 2010 17:07:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6608FC1F; Wed, 8 Dec 2010 17:07:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8H7vs4006023; Wed, 8 Dec 2010 12:07:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8H7vvp006022; Wed, 8 Dec 2010 17:07:57 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 17:07:57 GMT Message-Id: <201012081707.oB8H7vvp006022@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 17:07:58 -0000 TB --- 2010-12-08 16:38:17 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:38:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-12-08 16:38:17 - cleaning the object tree TB --- 2010-12-08 16:38:19 - cvsupping the source tree TB --- 2010-12-08 16:38:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-12-08 16:38:30 - building world TB --- 2010-12-08 16:38:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:38:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:38:30 - TARGET=ia64 TB --- 2010-12-08 16:38:30 - TARGET_ARCH=ia64 TB --- 2010-12-08 16:38:30 - TZ=UTC TB --- 2010-12-08 16:38:30 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:38:30 - cd /src TB --- 2010-12-08 16:38:30 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:38:30 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 17:07:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 17:07:57 - ERROR: failed to build world TB --- 2010-12-08 17:07:57 - 1401.00 user 265.70 system 1780.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 8 17:09:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58CE4106566C; Wed, 8 Dec 2010 17:09:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0109A8FC0C; Wed, 8 Dec 2010 17:09:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8H9rG6015651; Wed, 8 Dec 2010 12:09:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8H9rWQ015646; Wed, 8 Dec 2010 17:09:53 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 17:09:53 GMT Message-Id: <201012081709.oB8H9rWQ015646@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc 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, 08 Dec 2010 17:09:54 -0000 TB --- 2010-12-08 16:42:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:42:52 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-12-08 16:42:52 - cleaning the object tree TB --- 2010-12-08 16:42:55 - cvsupping the source tree TB --- 2010-12-08 16:42:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-12-08 16:43:06 - building world TB --- 2010-12-08 16:43:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:43:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:43:06 - TARGET=powerpc TB --- 2010-12-08 16:43:06 - TARGET_ARCH=powerpc TB --- 2010-12-08 16:43:06 - TZ=UTC TB --- 2010-12-08 16:43:06 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:43:06 - cd /src TB --- 2010-12-08 16:43:06 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:43:06 UTC 2010 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 17:09:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 17:09:53 - ERROR: failed to build world TB --- 2010-12-08 17:09:53 - 1249.07 user 257.07 system 1620.46 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 02:22:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 079781065673; Thu, 9 Dec 2010 02:22:30 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CDFB38FC18; Thu, 9 Dec 2010 02:22:29 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB92MR3t082793; Thu, 9 Dec 2010 02:22:28 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D003D64.8010409@freebsd.org> Date: Thu, 09 Dec 2010 10:22:28 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: John Baldwin References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012070913.17118.jhb@freebsd.org> <4CFEF34D.1030701@freebsd.org> <201012080929.22825.jhb@freebsd.org> In-Reply-To: <201012080929.22825.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 02:22:30 -0000 John Baldwin wrote: > On Tuesday, December 07, 2010 9:54:05 pm David Xu wrote: >> John Baldwin wrote: >>> On Monday, December 06, 2010 7:11:28 pm David Xu wrote: >>>> John Baldwin wrote: >>>>> On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: >>>>> >>>>>> Sometime in the last 7-10 days, some one made a >>>>>> change that has broken process accounting/timing. >>>>>> >>>>>> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >>>>>> foreach? time ./testf >>>>>> foreach? end >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 69.55 real 38.39 user 30.94 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 68.82 real 40.95 user 27.60 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 69.14 real 38.90 user 30.02 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 68.79 real 40.59 user 27.99 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 68.93 real 39.76 user 28.96 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 68.71 real 41.21 user 27.29 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 69.05 real 39.68 user 29.15 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 68.99 real 39.98 user 28.80 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 69.02 real 39.64 user 29.16 sys >>>>>> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >>>>>> 69.38 real 37.49 user 31.67 sys >>>>>> >>>>>> testf is a numerically intensive program that tests the >>>>>> accuracy of expf() in a tight loop. User time varies >>>>>> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >>>>>> I'm fairly certain that the code does not suddenly grow/loose >>>>>> 6 GFLOP of operations. >>>>>> >>>>> The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 >>>>> hz) to figure out a user vs sys split and use that to divide up the total >>>>> runtime (which actually is fairly accurate). All you need is for the clock >>>>> ticks to fire just a bit differently between runs to get a swing in user vs >>>>> system time. >>>>> >>>>> What I would like is to keep separate raw bintime's for user vs system time in >>>>> the raw data instead, but that would involve checking the CPU ticker more >>>>> often (e.g. twice for each syscall, interrupt, and trap in addition to the >>>>> current once per context switch). So far folks seem to be more worried about >>>>> the extra overhead rather than the loss of accuracy. >>>>> >>>>> >>>> Adding any instruction into global syscall path should be cautioned, it >>>> is worse then before, thinking about a threaded application, a userland >>>> thread may have locked a mutex and calls a system call, the overhead >>>> added to system call path can directly affect a threaded application's >>>> performance now, because the time window the mutex is held >>>> is longer than before, I have seen some people likes to fiddle with >>>> system call path, it should be cautioned. >>> OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful >>> thing you can do is to sum them since the total is known to be accurate at >>> least. >>> >>> If it wouldn't make things so messy I'd consider a new kernel option >>> 'ACCURATE_RUSAGE' or some such. >>> >> Our getrusage is already very slow, everytime, it needs to >> iterate the threads list with a process SLOCK held. I saw some mysql >> versions heavily use getrusage, and a horribly slow. I think a >> ACCURATE_RUSAGE will make it worse ? > > Using 'time foo' only retrieves the usage once at the end via wait(). > > However, FWIW, I think ACCURATE_RUSAGE would simplify calcru1() quite a bit > since you would just sum up the thread's usage (as we do know), but then do a > direct conversion from bintime to timeval for user and system without ever > having to worry about time going backwards, etc. All the hacks to enforce > monotonicity that are currently in place would go away since we would have > the real measurements and not be inferring them from statclock ticks. > I don't worry getrusage, though it is not necessary that it is used with wait(), I saw mysql used it to measure its internal code's performance, it did not use it with wait(), it is questionable if this usage is correct. However, I worry anyone who adds overhead to system call path. From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 08:03:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782B8106567A; Thu, 9 Dec 2010 08:03:50 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 683AF8FC15; Thu, 9 Dec 2010 08:03:50 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB983n8U067494; Thu, 9 Dec 2010 08:03:49 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D008D65.2000600@freebsd.org> Date: Thu, 09 Dec 2010 16:03:49 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: FreeBSD Current References: <4CF4901B.8030108@freebsd.org> <4CF5B421.2040807@freebsd.org> In-Reply-To: <4CF5B421.2040807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen Subject: Re: CFT(2): patch for process shared pthread objects X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 08:03:50 -0000 David Xu wrote: > David Xu wrote: >> Hi, >> >> I finally have worked out first patch to make our pthread library >> support process shared pthread objects: >> >> http://people.freebsd.org/~davidxu/pshared/patch1.diff >> > > Patch is updated: > http://people.freebsd.org/~davidxu/pshared/patch2.diff > > Changes: > 1) Macro _POSIX_THREAD_PROCESS_SHARED in unistd.h is changed, > now its value is 200112L. > 2) Version of libgcc is bumped. > 3) Thread cancellation is fixed in pthread_cond_wait(), this > should make csup run again. > > I have updated patch again: http://people.freebsd.org/~davidxu/pshared/patch6.diff This time, process shared priority-inherit mutex is supported. Now my machine is running with various threaded applications and a gnome desktop, I have not found any problem. I wish the patch can be committed before 9.0 release. :-) Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 08:06:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80AD71065670; Thu, 9 Dec 2010 08:06:17 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 55E8C8FC13; Thu, 9 Dec 2010 08:06:17 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB986F37067550; Thu, 9 Dec 2010 08:06:16 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D008DF8.8070807@freebsd.org> Date: Thu, 09 Dec 2010 16:06:16 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: FreeBSD Current References: <4CF4901B.8030108@freebsd.org> <4CF5B421.2040807@freebsd.org> <4D008D65.2000600@freebsd.org> In-Reply-To: <4D008D65.2000600@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen Subject: Re: CFT(2): patch for process shared pthread objects X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 08:06:17 -0000 > I have updated patch again: > http://people.freebsd.org/~davidxu/pshared/patch6.diff > > This time, process shared priority-inherit mutex is supported. > Now my machine is running with various threaded applications and > a gnome desktop, I have not found any problem. > > I wish the patch can be committed before 9.0 release. :-) > > Regards, > David Xu > Note that you should update source tree before applying this patch. From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 12:45:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558EA106566B for ; Thu, 9 Dec 2010 12:45:49 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 32F058FC16 for ; Thu, 9 Dec 2010 12:45:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.0.101] ([74.56.135.175]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LD500JFYVEYLM10@vl-mo-mrz23.ip.videotron.ca> for freebsd-current@freebsd.org; Thu, 09 Dec 2010 07:44:59 -0500 (EST) Message-id: <4D00CDCE.8040509@gthcfoundation.org> Date: Thu, 09 Dec 2010 07:38:38 -0500 From: Etienne Robillard User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101102 Thunderbird/3.0.10 To: freebsd-current@freebsd.org Subject: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 12:45:49 -0000 Hi $ sudo rm -rf /usr/obj/* rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/local/freebsd8/src/lib32/usr: Directory not empty rm: /usr/obj/usr/local/freebsd8/src/lib32: Directory not empty rm: /usr/obj/usr/local/freebsd8/src: Directory not empty rm: /usr/obj/usr/local/freebsd8: Directory not empty rm: /usr/obj/usr/local: Directory not empty rm: /usr/obj/usr: Directory not empty $ uname -a FreeBSD marina 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Nov 21 00:48:28 EST 2010 root@:/usbj/usr/local/freebsd8/src/sys/GENERIC.ndebug amd64 Is this a corrupted obj directory ? If so, why should theses libs have the schg flag enabled? Thx, Etienne $ sudo ls -lao /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/ total 2520 drwxr-xr-x 2 root wheel - 12288 Dec 9 07:24 . drwxr-xr-x 3 root wheel - 512 Dec 9 07:25 .. -r--r--r-- 1 root wheel schg 1128116 Nov 21 02:15 libc.so.7 -r--r--r-- 1 root wheel schg 32060 Nov 21 02:18 libcrypt.so.5 -r--r--r-- 1 root wheel schg 16444 Nov 21 02:27 librt.so.1 -r--r--r-- 1 root wheel schg 76668 Nov 21 02:19 libthr.so.3 From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 13:06:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AEF106566B for ; Thu, 9 Dec 2010 13:06:48 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 92F2D8FC08 for ; Thu, 9 Dec 2010 13:06:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.0.101] ([74.56.135.175]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LD500MKJWEV5S20@vl-mo-mrz23.ip.videotron.ca> for freebsd-current@freebsd.org; Thu, 09 Dec 2010 08:06:32 -0500 (EST) Message-id: <4D00D2DC.8030606@gthcfoundation.org> Date: Thu, 09 Dec 2010 08:00:12 -0500 From: Etienne Robillard User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101102 Thunderbird/3.0.10 To: Giorgos Keramidas , freebsd-current@freebsd.org References: <4D00CDCE.8040509@gthcfoundation.org> In-reply-to: Cc: Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 13:06:48 -0000 On 12/09/10 07:57, Giorgos Keramidas wrote: > On Thu, 09 Dec 2010 07:38:38 -0500, Etienne Robillard wrote: > >> Hi >> >> $ sudo rm -rf /usr/obj/* >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libc.so.7: Operation >> not permitted >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libcrypt.so.5: >> Operation not permitted >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libthr.so.3: >> Operation not permitted >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/librt.so.1: >> Operation not permitted >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32: Directory not empty >> rm: /usr/obj/usr/local/freebsd8/src/lib32/usr: Directory not empty >> rm: /usr/obj/usr/local/freebsd8/src/lib32: Directory not empty >> rm: /usr/obj/usr/local/freebsd8/src: Directory not empty >> rm: /usr/obj/usr/local/freebsd8: Directory not empty >> rm: /usr/obj/usr/local: Directory not empty >> rm: /usr/obj/usr: Directory not empty >> $ uname -a >> FreeBSD marina 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Nov 21 00:48:28 EST >> 2010 root@:/usbj/usr/local/freebsd8/src/sys/GENERIC.ndebug amd64 >> >> Is this a corrupted obj directory ? If so, why should theses libs have >> the schg flag enabled? >> > >> $ sudo ls -lao /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/ >> total 2520 >> drwxr-xr-x 2 root wheel - 12288 Dec 9 07:24 . >> drwxr-xr-x 3 root wheel - 512 Dec 9 07:25 .. >> -r--r--r-- 1 root wheel schg 1128116 Nov 21 02:15 libc.so.7 >> -r--r--r-- 1 root wheel schg 32060 Nov 21 02:18 libcrypt.so.5 >> -r--r--r-- 1 root wheel schg 16444 Nov 21 02:27 librt.so.1 >> -r--r--r-- 1 root wheel schg 76668 Nov 21 02:19 libthr.so.3 >> > They are installed with "make install" and when you run "make install" > with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: > > .if defined(PRECIOUSLIB) > .if !defined(NO_FSCHG) > SHLINSTALLFLAGS+= -fschg > .endif > SHLINSTALLFLAGS+= -S > .endif > > The Makefiles that set PRECIOUSLIB today are: > > keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' * > lib/libc/Makefile:PRECIOUSLIB= > lib/libcrypt/Makefile:PRECIOUSLIB= > lib/libkse/Makefile:PRECIOUSLIB= > lib/librt/Makefile:PRECIOUSLIB= > lib/libthr/Makefile:PRECIOUSLIB= > keramida@bokos:/usr/src$ > > Ok thanks. I will try defining NO_FSCHG in /etc/make.conf next time i run "buildworld".. :-) Regards, Etienne From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 13:11:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8201E1065672 for ; Thu, 9 Dec 2010 13:11:01 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 033E78FC14 for ; Thu, 9 Dec 2010 13:11:00 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oB9CvH0B027821 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oB9CvH0B027821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 14:57:25 +0200 From: Giorgos Keramidas To: Etienne Robillard References: <4D00CDCE.8040509@gthcfoundation.org> Date: Thu, 09 Dec 2010 13:57:16 +0100 In-Reply-To: <4D00CDCE.8040509@gthcfoundation.org> (Etienne Robillard's message of "Thu, 09 Dec 2010 07:38:38 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 13:11:01 -0000 On Thu, 09 Dec 2010 07:38:38 -0500, Etienne Robillard wrote: > Hi > > $ sudo rm -rf /usr/obj/* > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libc.so.7: Operation > not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libcrypt.so.5: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libthr.so.3: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/librt.so.1: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src/lib32: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src: Directory not empty > rm: /usr/obj/usr/local/freebsd8: Directory not empty > rm: /usr/obj/usr/local: Directory not empty > rm: /usr/obj/usr: Directory not empty > $ uname -a > FreeBSD marina 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Nov 21 00:48:28 EST > 2010 root@:/usbj/usr/local/freebsd8/src/sys/GENERIC.ndebug amd64 > > Is this a corrupted obj directory ? If so, why should theses libs have > the schg flag enabled? > $ sudo ls -lao /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/ > total 2520 > drwxr-xr-x 2 root wheel - 12288 Dec 9 07:24 . > drwxr-xr-x 3 root wheel - 512 Dec 9 07:25 .. > -r--r--r-- 1 root wheel schg 1128116 Nov 21 02:15 libc.so.7 > -r--r--r-- 1 root wheel schg 32060 Nov 21 02:18 libcrypt.so.5 > -r--r--r-- 1 root wheel schg 16444 Nov 21 02:27 librt.so.1 > -r--r--r-- 1 root wheel schg 76668 Nov 21 02:19 libthr.so.3 They are installed with "make install" and when you run "make install" with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: .if defined(PRECIOUSLIB) .if !defined(NO_FSCHG) SHLINSTALLFLAGS+= -fschg .endif SHLINSTALLFLAGS+= -S .endif The Makefiles that set PRECIOUSLIB today are: keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' * lib/libc/Makefile:PRECIOUSLIB= lib/libcrypt/Makefile:PRECIOUSLIB= lib/libkse/Makefile:PRECIOUSLIB= lib/librt/Makefile:PRECIOUSLIB= lib/libthr/Makefile:PRECIOUSLIB= keramida@bokos:/usr/src$ From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 13:15:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3ADF1065675 for ; Thu, 9 Dec 2010 13:15:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 815818FC16 for ; Thu, 9 Dec 2010 13:15:08 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oB9DF2Om011065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 15:15:02 +0200 (EET) (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.14.4/8.14.4) with ESMTP id oB9DF2kM065782; Thu, 9 Dec 2010 15:15:02 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oB9DF2rX065781; Thu, 9 Dec 2010 15:15:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Dec 2010 15:15:02 +0200 From: Kostik Belousov To: Giorgos Keramidas Message-ID: <20101209131502.GM33073@deviant.kiev.zoral.com.ua> References: <4D00CDCE.8040509@gthcfoundation.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fNagykWcDoSVAmSd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Etienne Robillard Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 13:15:09 -0000 --fNagykWcDoSVAmSd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 09, 2010 at 01:57:16PM +0100, Giorgos Keramidas wrote: > On Thu, 09 Dec 2010 07:38:38 -0500, Etienne Robillard wrote: > > Hi > > > > $ sudo rm -rf /usr/obj/* > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libc.so.7: Operation > > not permitted > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libcrypt.so.5: > > Operation not permitted > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libthr.so.3: > > Operation not permitted > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/librt.so.1: > > Operation not permitted > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32: Directory not empty > > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr: Directory not empty > > rm: /usr/obj/usr/local/freebsd8/src/lib32: Directory not empty > > rm: /usr/obj/usr/local/freebsd8/src: Directory not empty > > rm: /usr/obj/usr/local/freebsd8: Directory not empty > > rm: /usr/obj/usr/local: Directory not empty > > rm: /usr/obj/usr: Directory not empty > > $ uname -a > > FreeBSD marina 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Nov 21 00:48:28 EST > > 2010 root@:/usbj/usr/local/freebsd8/src/sys/GENERIC.ndebug amd64 > > > > Is this a corrupted obj directory ? If so, why should theses libs have > > the schg flag enabled? >=20 > > $ sudo ls -lao /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/ > > total 2520 > > drwxr-xr-x 2 root wheel - 12288 Dec 9 07:24 . > > drwxr-xr-x 3 root wheel - 512 Dec 9 07:25 .. > > -r--r--r-- 1 root wheel schg 1128116 Nov 21 02:15 libc.so.7 > > -r--r--r-- 1 root wheel schg 32060 Nov 21 02:18 libcrypt.so.5 > > -r--r--r-- 1 root wheel schg 16444 Nov 21 02:27 librt.so.1 > > -r--r--r-- 1 root wheel schg 76668 Nov 21 02:19 libthr.so.3 >=20 > They are installed with "make install" and when you run "make install" > with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: >=20 > .if defined(PRECIOUSLIB) > .if !defined(NO_FSCHG) > SHLINSTALLFLAGS+=3D -fschg > .endif > SHLINSTALLFLAGS+=3D -S > .endif >=20 > The Makefiles that set PRECIOUSLIB today are: >=20 > keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=3D' * > lib/libc/Makefile:PRECIOUSLIB=3D > lib/libcrypt/Makefile:PRECIOUSLIB=3D > lib/libkse/Makefile:PRECIOUSLIB=3D > lib/librt/Makefile:PRECIOUSLIB=3D > lib/libthr/Makefile:PRECIOUSLIB=3D > keramida@bokos:/usr/src$ Would be nice if lib32 installation into the obj/ area somehow eliminated the setting of schg flag. There is no reason to have schg set on files in obj. --fNagykWcDoSVAmSd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0A1lYACgkQC3+MBN1Mb4hA0wCcDfDnPodC454AAwOEILGct/s1 L8gAoPEvN5VOUPjZPFfg9Ak+wfXsnP5T =6+ix -----END PGP SIGNATURE----- --fNagykWcDoSVAmSd-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 13:52:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76015106566B for ; Thu, 9 Dec 2010 13:52:25 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id CE89F8FC0A for ; Thu, 9 Dec 2010 13:52:24 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oB9Dq9jB030931 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oB9Dq9jB030931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 15:52:15 +0200 From: keramida@freebsd.org (Giorgos Keramidas) To: Kostik Belousov References: <4D00CDCE.8040509@gthcfoundation.org> <20101209131502.GM33073@deviant.kiev.zoral.com.ua> Date: Thu, 09 Dec 2010 14:52:06 +0100 In-Reply-To: <20101209131502.GM33073@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Thu, 9 Dec 2010 15:15:02 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org, Etienne Robillard Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 13:52:25 -0000 --=-=-= Content-Type: text/plain On Thu, 9 Dec 2010 15:15:02 +0200, Kostik Belousov wrote: > On Thu, Dec 09, 2010 at 01:57:16PM +0100, Giorgos Keramidas wrote: >> They are installed with "make install" and when you run "make install" >> with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: >> >> .if defined(PRECIOUSLIB) >> .if !defined(NO_FSCHG) >> SHLINSTALLFLAGS+= -fschg >> .endif >> SHLINSTALLFLAGS+= -S >> .endif >> >> The Makefiles that set PRECIOUSLIB today are: >> >> keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' * >> lib/libc/Makefile:PRECIOUSLIB= >> lib/libcrypt/Makefile:PRECIOUSLIB= >> lib/libkse/Makefile:PRECIOUSLIB= >> lib/librt/Makefile:PRECIOUSLIB= >> lib/libthr/Makefile:PRECIOUSLIB= >> keramida@bokos:/usr/src$ > > Would be nice if lib32 installation into the obj/ area somehow > eliminated the setting of schg flag. There is no reason to have schg > set on files in obj. Yes, that's a good idea. I don't have root access to an amd64 system to test this now, but I think all we need to change is: %%% $ hg diff . diff -r e52d3f3de04d Makefile.inc1 --- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100 +++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100 @@ -318,7 +318,8 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTR CXX="${CXX} ${LIB32FLAGS}" \ OBJC="${OBJC} ${LIB32FLAGS}" \ LIBDIR=/usr/lib32 \ - SHLIBDIR=/usr/lib32 + SHLIBDIR=/usr/lib32 \ + NO_FSCHG='' LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ $ %%% This should strip the -fschg option from lib32's installation commands. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0A3wkACgkQ1g+UGjGGA7bWcQCfal3NVPjWqaPJtsT/bA4E1Pop iEgAni0CE/KnCoYC6NPnPDcVsJvhP3B7 =MYtV -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 15:09:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AE7106566C; Thu, 9 Dec 2010 15:09:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 373678FC0C; Thu, 9 Dec 2010 15:09:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CC5D246B03; Thu, 9 Dec 2010 10:09:54 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC6858A01D; Thu, 9 Dec 2010 10:09:53 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 9 Dec 2010 10:01:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4D00CDCE.8040509@gthcfoundation.org> <20101209131502.GM33073@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201012091001.32727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 09 Dec 2010 10:09:53 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Kostik Belousov , Etienne Robillard , Giorgos Keramidas Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 15:09:55 -0000 On Thursday, December 09, 2010 8:52:06 am Giorgos Keramidas wrote: > On Thu, 9 Dec 2010 15:15:02 +0200, Kostik Belousov wrote: > > On Thu, Dec 09, 2010 at 01:57:16PM +0100, Giorgos Keramidas wrote: > >> They are installed with "make install" and when you run "make install" > >> with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: > >> > >> .if defined(PRECIOUSLIB) > >> .if !defined(NO_FSCHG) > >> SHLINSTALLFLAGS+= -fschg > >> .endif > >> SHLINSTALLFLAGS+= -S > >> .endif > >> > >> The Makefiles that set PRECIOUSLIB today are: > >> > >> keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' * > >> lib/libc/Makefile:PRECIOUSLIB= > >> lib/libcrypt/Makefile:PRECIOUSLIB= > >> lib/libkse/Makefile:PRECIOUSLIB= > >> lib/librt/Makefile:PRECIOUSLIB= > >> lib/libthr/Makefile:PRECIOUSLIB= > >> keramida@bokos:/usr/src$ > > > > Would be nice if lib32 installation into the obj/ area somehow > > eliminated the setting of schg flag. There is no reason to have schg > > set on files in obj. > > Yes, that's a good idea. > > I don't have root access to an amd64 system to test this now, but I > think all we need to change is: > > %%% > $ hg diff . > diff -r e52d3f3de04d Makefile.inc1 > --- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100 > +++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100 > @@ -318,7 +318,8 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTR > CXX="${CXX} ${LIB32FLAGS}" \ > OBJC="${OBJC} ${LIB32FLAGS}" \ > LIBDIR=/usr/lib32 \ > - SHLIBDIR=/usr/lib32 > + SHLIBDIR=/usr/lib32 \ > + NO_FSCHG='' > > LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ > -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ > $ > %%% > > This should strip the -fschg option from lib32's installation commands. Does that affect the installed versions of the libraries in /usr/lib32? Those should probably have schg set. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 15:36:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85211106566B; Thu, 9 Dec 2010 15:36:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFD58FC1B; Thu, 9 Dec 2010 15:36:50 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oB9FakUg022323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 17:36:46 +0200 (EET) (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.14.4/8.14.4) with ESMTP id oB9FakEL076369; Thu, 9 Dec 2010 17:36:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oB9Fakgp076368; Thu, 9 Dec 2010 17:36:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Dec 2010 17:36:46 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20101209153646.GN33073@deviant.kiev.zoral.com.ua> References: <4D00CDCE.8040509@gthcfoundation.org> <20101209131502.GM33073@deviant.kiev.zoral.com.ua> <201012091001.32727.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XLsjFikA86nwwlhe" Content-Disposition: inline In-Reply-To: <201012091001.32727.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Etienne Robillard , Giorgos Keramidas Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 15:36:51 -0000 --XLsjFikA86nwwlhe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 09, 2010 at 10:01:32AM -0500, John Baldwin wrote: > On Thursday, December 09, 2010 8:52:06 am Giorgos Keramidas wrote: > > On Thu, 9 Dec 2010 15:15:02 +0200, Kostik Belousov =20 > wrote: > > > On Thu, Dec 09, 2010 at 01:57:16PM +0100, Giorgos Keramidas wrote: > > >> They are installed with "make install" and when you run "make instal= l" > > >> with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: > > >> > > >> .if defined(PRECIOUSLIB) > > >> .if !defined(NO_FSCHG) > > >> SHLINSTALLFLAGS+=3D -fschg > > >> .endif > > >> SHLINSTALLFLAGS+=3D -S > > >> .endif > > >> > > >> The Makefiles that set PRECIOUSLIB today are: > > >> > > >> keramida@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=3D' * > > >> lib/libc/Makefile:PRECIOUSLIB=3D > > >> lib/libcrypt/Makefile:PRECIOUSLIB=3D > > >> lib/libkse/Makefile:PRECIOUSLIB=3D > > >> lib/librt/Makefile:PRECIOUSLIB=3D > > >> lib/libthr/Makefile:PRECIOUSLIB=3D > > >> keramida@bokos:/usr/src$ > > > > > > Would be nice if lib32 installation into the obj/ area somehow > > > eliminated the setting of schg flag. There is no reason to have schg > > > set on files in obj. > >=20 > > Yes, that's a good idea. > >=20 > > I don't have root access to an amd64 system to test this now, but I > > think all we need to change is: > >=20 > > %%% > > $ hg diff . > > diff -r e52d3f3de04d Makefile.inc1 > > --- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100 > > +++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100 > > @@ -318,7 +318,8 @@ LIB32WMAKEENV+=3D MAKEOBJDIRPREFIX=3D${OBJTR > > CXX=3D"${CXX} ${LIB32FLAGS}" \ > > OBJC=3D"${OBJC} ${LIB32FLAGS}" \ > > LIBDIR=3D/usr/lib32 \ > > - SHLIBDIR=3D/usr/lib32 > > + SHLIBDIR=3D/usr/lib32 \ > > + NO_FSCHG=3D'' > >=20 > > LIB32WMAKE=3D ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32B= IT \ > > -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ > > $ > > %%% > >=20 > > This should strip the -fschg option from lib32's installation commands. >=20 > Does that affect the installed versions of the libraries in > /usr/lib32? Those should probably have schg set. Yes, it does affect lib32. I did full buildworld+installworld of the patched tree on amd64, and the newly installed /usr/lib32/libc.so.7 has no schg flag. --XLsjFikA86nwwlhe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0A940ACgkQC3+MBN1Mb4h0LgCfUM4Wm5TOzev9lEArC2cgPJmc RiMAnRvYsr9hkPLASDAq7k4lfFoZTUge =bhTq -----END PGP SIGNATURE----- --XLsjFikA86nwwlhe-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 16:07:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE4D4106566C; Thu, 9 Dec 2010 16:07:45 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 591A68FC08; Thu, 9 Dec 2010 16:07:44 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oB9G7QlJ007015 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oB9G7QlJ007015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 18:07:32 +0200 From: keramida@freebsd.org (Giorgos Keramidas) To: John Baldwin References: <4D00CDCE.8040509@gthcfoundation.org> <20101209131502.GM33073@deviant.kiev.zoral.com.ua> <201012091001.32727.jhb@freebsd.org> Date: Thu, 09 Dec 2010 17:07:26 +0100 In-Reply-To: <201012091001.32727.jhb@freebsd.org> (John Baldwin's message of "Thu, 9 Dec 2010 10:01:32 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Kostik Belousov , freebsd-current@freebsd.org, Etienne Robillard , Giorgos Keramidas Subject: Re: shared lib issue in /usr/obj? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 16:07:45 -0000 On Thu, 9 Dec 2010 10:01:32 -0500, John Baldwin wrote: >> I don't have root access to an amd64 system to test this now, but I >> think all we need to change is: >> >> %%% >> $ hg diff . >> diff -r e52d3f3de04d Makefile.inc1 >> --- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100 >> +++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100 >> @@ -318,7 +318,8 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTR >> CXX="${CXX} ${LIB32FLAGS}" \ >> OBJC="${OBJC} ${LIB32FLAGS}" \ >> LIBDIR=/usr/lib32 \ >> - SHLIBDIR=/usr/lib32 >> + SHLIBDIR=/usr/lib32 \ >> + NO_FSCHG='' >> >> LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ >> -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ >> $ >> %%% >> >> This should strip the -fschg option from lib32's installation commands. > > Does that affect the installed versions of the libraries in > /usr/lib32? Those should probably have schg set. I think it does. I'll have to rethink a bit about the best way to avoid schg for lib32 but only during buildworld. From owner-freebsd-current@FreeBSD.ORG Thu Dec 9 16:46:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDBF106566B for ; Thu, 9 Dec 2010 16:46:01 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id CCC9E8FC14 for ; Thu, 9 Dec 2010 16:46:00 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id oB9GO0xV084457 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL) for ; Thu, 9 Dec 2010 11:24:13 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <4D010215.8020600@uffner.com> Date: Thu, 09 Dec 2010 11:21:41 -0500 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.15) Gecko/20101106 Lightning/1.0b1 SeaMonkey/2.0.10 MIME-Version: 1.0 To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: USB 1.1 devs not working on ASUS K8VSE (x86) MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Dec 2010 16:46:01 -0000 I have a fairly recent Current system running on an ASUS K8V SE Deluxe MB. It was a dual boot amd64/x86 system (until a few days ago when the drive w/ the amd64 partitions unexpectedly failed after only a week of use) When running it as x86, USB 1.1 devices are not recognized by FreeBSD. They worked fine on the amd64 kernel built from the same code. both ohci and uhci are in the kernel even though they don't show up in dmesg. the devices in question (currently a 1.1 hub and a mouse) are both seen and activated by the BIOS but turned off once FreeBSD takes over. I had the same problem with GENERIC kernels from the 9.0-current-201011 snapshot, so it is not my kernel config. the mouse also works fine on either x86 or amd64 when plugged into a USB 2.0 hub or a PS2 adapter. and both these devices worked w/ the x86 kernel on the previous incarnation of this system with an ASUS A7N8X MB (NVIDIA chipset) so i suspect that the problem may be in the initialization code for the Via chipset. thanks in advance for any help, tom FreeBSD xiombarg.uffner.com 9.0-CURRENT FreeBSD 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.87-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0xfc0 Family = f Model = c Stepping = 0 Features=0x78bfbff AMD Features=0xe0500800 real memory = 2147483648 (2048 MB) avail memory = 2094309376 (1997 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xe0000000-0xefffffff,0xfce00000-0xfce0ffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xd0000000-0xdfffffff,0xfcc00000-0xfcc0ffff at device 0.1 on pci1 atapci0: port 0xe800-0xe87f,0xe400-0xe4ff mem 0xfda00000-0xfda00fff,0xfd900000-0xfd91ffff irq 16 at device 9.0 on pci0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 skc0: port 0xe000-0xe0ff mem 0xfdc00000-0xfdc03fff irq 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:38:7b:87 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto re0: port 0xd800-0xd8ff mem 0xfd700000-0xfd7000ff irq 17 at device 12.0 on pci0 re0: Chip rev. 0x10000000 re0: MAC rev. 0x00000000 miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:14:d1:14:33:e6 pcm0: port 0xd400-0xd4ff irq 19 at device 14.0 on pci0 atapci1: port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 ata5: on atapci1 ata6: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 16.2 (no driver attached) pci0: at device 16.3 (no driver attached) ehci0: mem 0xfd500000-0xfd5000ff irq 21 at device 16.4 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd57ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. powernow0: on cpu0 Timecounter "TSC" frequency 2202867030 Hz quality 800 Timecounters tick every 1.000 msec ata2: SIGNATURE: 00000101 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata2 bus 0 scbus0 target 0 lun 0cd0 at ata0 bus 0 scbus5 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 scbus6 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub_reattach_port: port 4 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 4 Trying to mount root from ufs:/dev/ada0s1a [rw]... uhub_reattach_port: port 5 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 5 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf8000000 32MB info: [drm] Initialized radeon 1.31.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs info: [drm] Num pipes: 1 From owner-freebsd-current@FreeBSD.ORG Fri Dec 10 13:51:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5FA1065673 for ; Fri, 10 Dec 2010 13:51:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC5F28FC1A for ; Fri, 10 Dec 2010 13:51:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 689F946B2A; Fri, 10 Dec 2010 08:51:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD91E8A01D; Fri, 10 Dec 2010 08:51:46 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 10 Dec 2010 08:20:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4D010215.8020600@uffner.com> In-Reply-To: <4D010215.8020600@uffner.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012100820.52926.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 10 Dec 2010 08:51:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2010 13:51:58 -0000 On Thursday, December 09, 2010 11:21:41 am Tom Uffner wrote: > I have a fairly recent Current system running on an ASUS K8V SE Deluxe MB. > > It was a dual boot amd64/x86 system (until a few days ago when the drive > w/ the amd64 partitions unexpectedly failed after only a week of use) > > When running it as x86, USB 1.1 devices are not recognized by FreeBSD. > They worked fine on the amd64 kernel built from the same code. both > ohci and uhci are in the kernel even though they don't show up in dmesg. > the devices in question (currently a 1.1 hub and a mouse) are both seen > and activated by the BIOS but turned off once FreeBSD takes over. > > I had the same problem with GENERIC kernels from the 9.0-current-201011 > snapshot, so it is not my kernel config. > > the mouse also works fine on either x86 or amd64 when plugged into a > USB 2.0 hub or a PS2 adapter. and both these devices worked w/ the x86 > kernel on the previous incarnation of this system with an ASUS A7N8X MB > (NVIDIA chipset) so i suspect that the problem may be in the initialization > code for the Via chipset. > > thanks in advance for any help, > tom > > pci0: at device 16.0 (no driver attached) > pci0: at device 16.1 (no driver attached) > pci0: at device 16.2 (no driver attached) > pci0: at device 16.3 (no driver attached) Can you get pciconf -lv output for these four devices? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 10 18:15:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5047E1065674; Fri, 10 Dec 2010 18:15:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 79E5F8FC23; Fri, 10 Dec 2010 18:15:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=KFcVJYsbzGUA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=8kQB0OdkAAAA:8 a=y1D6EcbfUNCBmWDcUugA:9 a=4OoJYbwDOlt0HrFXVbP7obc5opgA:4 a=PUjeQqilurYA:10 a=MSl-tDqOz04A:10 a=9aOQ2cSd83gA:10 a=-_6uVcgtE8pHcPzIwvgA:9 a=7cmd5gyT0pd2OpG_6YxnCmSL46oA:4 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 59735069; Fri, 10 Dec 2010 19:15:19 +0100 From: Hans Petter Selasky To: Oleg Nauman Date: Fri, 10 Dec 2010 19:15:40 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_M5mANEC8qZagE7a" Message-Id: <201012101915.40878.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2010 18:15:22 -0000 --Boundary-00=_M5mANEC8qZagE7a Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, I think this is a known issue which never got fixed. Please try the attached patch and report back. XXX_SAFE != XXX_REAL_SAFE :-) --HPS On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: > On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman wrote: > > Hello Hans, > > > > On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky wrote: > >> On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: > >>> Hello, > >>> > >>> Unfortunately my notebook experienced the crash during the attempts to > >>> attach EVDO modem supplied with builtin MicroSD cardreader. > >>> Related core.txt file is attached as well as 'usbconfig > >>> dump_all_config_desc' output (all_config.txt) > >>> USB subsystem reports endless USB_ERR_STALLED events during attempts > >>> to attach umass device, but attaches it finally ( sometimes it > >>> attached after two attempts, sometimes it trying to attach during > >>> 15-20 minutes ).MicroSD is inserted there, without any effect on > >>> attachment attempts though. > >> > >> Hi, > >> > >> Can you reproduce the panic using a kernel built with INVARIANTS options > >> and DEBUG_MEMGUARD . > > > > I rebuilt my kernel with options you mentioned ( have added > > INVARIANT_SUPPORT required by INVARIANTS though ) > > > > Waiting on panic.. > > Got it finally ( core.txt file is attached ) > --Boundary-00=_M5mANEC8qZagE7a Content-Type: text/x-patch; charset="iso-8859-15"; name="kern_conf.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kern_conf.c.patch" === kern_conf.c ================================================================== --- kern_conf.c (revision 215787) +++ kern_conf.c (local) @@ -926,7 +926,7 @@ destroy_devl(struct cdev *dev) { struct cdevsw *csw; - struct cdev_privdata *p, *p1; + struct cdev_privdata *p; mtx_assert(&devmtx, MA_OWNED); KASSERT(dev->si_flags & SI_NAMED, @@ -974,7 +974,7 @@ dev_unlock(); notify_destroy(dev); mtx_lock(&cdevpriv_mtx); - LIST_FOREACH_SAFE(p, &cdev2priv(dev)->cdp_fdpriv, cdpd_list, p1) { + while ((p = LIST_FIRST(&cdev2priv(dev)->cdp_fdpriv)) != NULL) { devfs_destroy_cdevpriv(p); mtx_lock(&cdevpriv_mtx); } --Boundary-00=_M5mANEC8qZagE7a-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 10 19:15:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63FE9106564A; Fri, 10 Dec 2010 19:15:16 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 761338FC0C; Fri, 10 Dec 2010 19:15:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA12023; Fri, 10 Dec 2010 21:15:09 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D027C3C.2030606@freebsd.org> Date: Fri, 10 Dec 2010 21:15:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky References: <201012101915.40878.hselasky@c2i.net> In-Reply-To: <201012101915.40878.hselasky@c2i.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Oleg Nauman , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2010 19:15:16 -0000 on 10/12/2010 20:15 Hans Petter Selasky said the following: > Hi, > > I think this is a known issue which never got fixed. Please try the attached > patch and report back. > > XXX_SAFE != XXX_REAL_SAFE :-) SAFE in sys/queue.h macros means only that it is safe to unlink/free current element in the loop body. Specifically it has nothing to do with concurrent modifications and locking. So, yes :) > On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: >> On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman wrote: >>> Hello Hans, >>> >>> On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky > wrote: >>>> On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: >>>>> Hello, >>>>> >>>>> Unfortunately my notebook experienced the crash during the attempts to >>>>> attach EVDO modem supplied with builtin MicroSD cardreader. >>>>> Related core.txt file is attached as well as 'usbconfig >>>>> dump_all_config_desc' output (all_config.txt) >>>>> USB subsystem reports endless USB_ERR_STALLED events during attempts >>>>> to attach umass device, but attaches it finally ( sometimes it >>>>> attached after two attempts, sometimes it trying to attach during >>>>> 15-20 minutes ).MicroSD is inserted there, without any effect on >>>>> attachment attempts though. >>>> >>>> Hi, >>>> >>>> Can you reproduce the panic using a kernel built with INVARIANTS options >>>> and DEBUG_MEMGUARD . >>> >>> I rebuilt my kernel with options you mentioned ( have added >>> INVARIANT_SUPPORT required by INVARIANTS though ) >>> >>> Waiting on panic.. >> >> Got it finally ( core.txt file is attached ) >> -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 10 20:33:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 874271065672 for ; Fri, 10 Dec 2010 20:33:42 +0000 (UTC) (envelope-from crockabiscuit@yahoo.com) Received: from nm20.bullet.mail.ne1.yahoo.com (nm20.bullet.mail.ne1.yahoo.com [98.138.90.83]) by mx1.freebsd.org (Postfix) with SMTP id 39A2B8FC16 for ; Fri, 10 Dec 2010 20:33:41 +0000 (UTC) Received: from [98.138.90.48] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 20:33:41 -0000 Received: from [98.138.86.156] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 20:33:41 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 20:33:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 641628.18729.bm@omp1014.mail.ne1.yahoo.com Received: (qmail 11883 invoked by uid 60001); 10 Dec 2010 20:33:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1292013221; bh=3c3+TTDHHZQNpA7nC5QAI+L5WAGaoNhlpXU/UpSSNkY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=RgYZ2WWw3UM/sh+gkJAHbVe/0+IVYlBusw5JVJ3HydjywdhlhBwYHQ7ZzDz5L/esln4PWkKxm/jBTr/Rag7792gakZUgqZz3VbYagiuupGXs7jcen/vidZx21jvuh5FlL4U8dR7VHS7EPF+nQRX+iq7gdBunhdRLQeUOmMx1taw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=mLW6MJw1kKBNUffJxPKdUm8wG8kbfJ8AuOuqbbKP33k+OwrbZpENf5fpsSgPxa0wcqi1/6xD/Crk9Ihft6CfO9owa1brz/AbGkdbN5U3JnifMJMxB1G3pE2OdHMdlp+bYZQZrw0KwlfpGy3ovn0cQMeQDRD0BXSG7sD4XhC+04U=; Message-ID: <462323.11813.qm@web120303.mail.ne1.yahoo.com> X-YMail-OSG: UXz7I9IVM1n0kHCjTZWgC5TWZfHpKHoC6WcMCE9BHnmXxeF HZSN4qyrvF2ykI8pgwesrlXnzaQAJHtweKjlmcI1l7yfa2QOCa6bvpB1w7OT Gxfh6k5ukiv.fIuaqd2XlnwssEBp.uniriSGcOJDeMLOPxpqFvtK79lPZnsC Hdw477YpCZu.eiINdxtT3dtZeeohHfbu3nRe0 Received: from [180.68.85.212] by web120303.mail.ne1.yahoo.com via HTTP; Fri, 10 Dec 2010 12:33:41 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 Date: Fri, 10 Dec 2010 12:33:41 -0800 (PST) From: crocket To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 10 Dec 2010 20:57:06 +0000 Subject: Is there any plan on implementing TEKEN_XTERM on FreeBSD 8? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 20:33:42 -0000 I know that 9-CURRENT supports it, but I want to have xterm on stable versions. Is there any plan for this? From owner-freebsd-current@FreeBSD.ORG Fri Dec 10 23:52:16 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBF62106564A; Fri, 10 Dec 2010 23:52:16 +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 A7A088FC14; Fri, 10 Dec 2010 23:52:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oBANqGJh028201; Fri, 10 Dec 2010 15:52:16 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oBANqGnV028200; Fri, 10 Dec 2010 15:52:16 -0800 (PST) (envelope-from sgk) Date: Fri, 10 Dec 2010 15:52:16 -0800 From: Steve Kargl To: Alexander Motin Message-ID: <20101210235216.GA28190@troutmask.apl.washington.edu> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org> <20101206163830.GA53157@troutmask.apl.washington.edu> <201012061301.13647.jhb@freebsd.org> <4CFD2A5B.1030006@freebsd.org> <20101206184309.GB38739@troutmask.apl.washington.edu> <4CFD2F77.8020409@freebsd.org> <20101206184949.GA39028@troutmask.apl.washington.edu> <4CFD32E6.7040003@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFD32E6.7040003@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, John Baldwin , Andriy Gapon Subject: Re: Process accounting/timing has broken recently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Dec 2010 23:52:16 -0000 On Mon, Dec 06, 2010 at 09:00:54PM +0200, Alexander Motin wrote: > On 06.12.2010 20:49, Steve Kargl wrote: > >On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote: > >>on 06/12/2010 20:43 Steve Kargl said the following: > >>>The 7-10 days is an estimate. I upgraded world/kernel on > >>>Saturday. The previous world/kernel could have been older > >>>than I'm guessing. It could be upto 4 weeks old because > >>>my laptop tends to lag behind the upgrades to my servers. > >> > >>I see. > >> > >>>I would normally use gprof to measure execution times > >>>for the functions I'm writing, but in some quick > >>>testing last night gprof appears to be broken. I'm > >>>seeing a larger variation that I would expect in > >>>self-seconds for the accumulated time for execution > >>>of expf. > >> > >>Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 > >>if it's > >>not 1 already? > >> > >>And cc-ing Alexander, just in case. > > > >Thanks for the suggestion. I'll try this tonight (I left the > >laptop at home) and will report back here. > > Unless your application utilizes all CPUs all the time, you can also try > to set sysctl kern.eventtimer.idletick=1. > To follow-up on the effect these tunables, I have the following results for my application: kern.eventtimer.idletick=0 kern.eventtimer.periodic=0 139.39 real 78.34 user 60.62 sys 138.70 real 79.26 user 59.01 sys 138.99 real 78.54 user 60.03 sys 139.04 real 78.96 user 59.65 sys 139.25 real 77.65 user 61.17 sys 138.95 real 79.07 user 59.45 sys 139.00 real 78.85 user 59.72 sys 139.04 real 78.32 user 60.29 sys 138.96 real 78.49 user 60.05 sys 138.97 real 78.24 user 60.31 sys kern.eventtimer.idletick=1 kern.eventtimer.periodic=0 137.79 real 85.32 user 52.04 sys 137.67 real 84.08 user 53.16 sys 137.59 real 84.24 user 52.93 sys 137.58 real 84.50 user 52.65 sys 137.21 real 85.81 user 50.97 sys 137.84 real 84.14 user 53.27 sys 137.41 real 84.32 user 52.67 sys 137.74 real 83.00 user 54.32 sys 137.34 real 84.15 user 52.76 sys 137.82 real 83.83 user 53.57 sys kern.eventtimer.idletick=1 kern.eventtimer.periodic=1 138.35 real 98.02 user 39.89 sys 138.14 real 98.29 user 39.43 sys 138.62 real 98.17 user 40.01 sys 138.62 real 97.69 user 40.51 sys 138.39 real 97.83 user 40.14 sys 138.77 real 97.28 user 41.07 sys 138.51 real 97.89 user 40.19 sys 138.23 real 97.46 user 40.35 sys 138.53 real 97.34 user 40.77 sys 138.90 real 97.27 user 41.20 sys kern.eventtimer.idletick=0 kern.eventtimer.periodic=1 138.93 real 98.23 user 40.26 sys 138.74 real 97.45 user 40.87 sys 138.55 real 98.33 user 39.80 sys 138.50 real 98.57 user 39.50 sys 138.22 real 96.45 user 41.35 sys 138.41 real 98.05 user 39.93 sys 138.58 real 98.14 user 40.01 sys 138.80 real 97.25 user 41.12 sys 138.62 real 97.01 user 41.17 sys 138.51 real 96.98 user 41.10 sys In the end, I'll go with jhb's explanation that getrusage is not robust when it comes to accounting for user time versus system time. I'll have to devise some other method for monitoring execution speed of the functions I'm writing. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 01:13:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5634106566C for ; Sat, 11 Dec 2010 01:13:10 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id A1DA08FC08 for ; Sat, 11 Dec 2010 01:13:10 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id oBB1FLWj031925 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL); Fri, 10 Dec 2010 20:15:27 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <4D02D01D.7090902@uffner.com> Date: Fri, 10 Dec 2010 20:13:01 -0500 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.15) Gecko/20101106 Lightning/1.0b1 SeaMonkey/2.0.10 MIME-Version: 1.0 To: John Baldwin References: <4D010215.8020600@uffner.com> <201012100820.52926.jhb@freebsd.org> In-Reply-To: <201012100820.52926.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 01:13:11 -0000 John Baldwin wrote: >> pci0: at device 16.0 (no driver attached) >> pci0: at device 16.1 (no driver attached) >> pci0: at device 16.2 (no driver attached) >> pci0: at device 16.3 (no driver attached) > > Can you get pciconf -lv output for these four devices? > none0@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB none1@pci0:0:16:1: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB none2@pci0:0:16:2: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB none3@pci0:0:16:3: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 09:30:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B36B1065672; Sat, 11 Dec 2010 09:30:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1F68B8FC17; Sat, 11 Dec 2010 09:30:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oBB9Uo4s009249; Sat, 11 Dec 2010 04:30:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oBB9UoxS009248; Sat, 11 Dec 2010 09:30:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 Dec 2010 09:30:50 GMT Message-Id: <201012110930.oBB9UoxS009248@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Sat, 11 Dec 2010 09:30:51 -0000 TB --- 2010-12-11 09:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-11 09:25:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-12-11 09:25:00 - cleaning the object tree TB --- 2010-12-11 09:25:21 - cvsupping the source tree TB --- 2010-12-11 09:25:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-12-11 09:30:49 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-12-11 09:30:49 - ERROR: unable to cvsup the source tree TB --- 2010-12-11 09:30:49 - 2.03 user 13.09 system 349.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 10:02:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 639D6106566B; Sat, 11 Dec 2010 10:02:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id AF2188FC13; Sat, 11 Dec 2010 10:02:49 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=KFcVJYsbzGUA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=QejBW4MsObNjzp0IyZ0A:9 a=fJm4RbYbpIfBNPFQrfo5C9Vf5SAA:4 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 60690030; Sat, 11 Dec 2010 11:02:47 +0100 From: Hans Petter Selasky To: Nick Hibma Date: Sat, 11 Dec 2010 11:03:09 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201012101915.40878.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201012111103.09422.hselasky@c2i.net> Cc: Oleg Nauman , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 10:02:50 -0000 On Saturday 11 December 2010 10:09:45 Oleg Nauman wrote: > Hello Hans, > > On Fri, Dec 10, 2010 at 8:15 PM, Hans Petter Selasky wrote: > > Hi, > > > > I think this is a known issue which never got fixed. Please try the > > attached patch and report back. > > Have applied your patch, my laptop was not crashing anymore. Thank you! > > But we will continue the saga about this strange USB modem, if no > objections from your side :) > Is it possible to apply some quirk or some another workaround which > will solve the issue with endless USB_ERR_STALLED reported while it > trying to attach its builtin cardreader? Nick, do you have any hints on this? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 09:38:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DB4F106566C for ; Sat, 11 Dec 2010 09:38:53 +0000 (UTC) (envelope-from oleg.nauman@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB538FC17 for ; Sat, 11 Dec 2010 09:38:52 +0000 (UTC) Received: by pwi10 with SMTP id 10so952312pwi.13 for ; Sat, 11 Dec 2010 01:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fWb+kUTdNmdKQYoanDxl/YF6UmWQ7qZ4i8cmv3xwHd0=; b=HjYsWkZbs16rR1ZtNBXH5N0UM8GnpIACwwXVV0WsYggaM9zAdAfAIZpFpJYEa0/D2G L31fd7BXpajyBYfrl/iNV3CXkxSuZlNKUdMmjOQCtgdZKWZWr5PXkvFw4njb59ZL4HT+ qNXMQr+pddCo1G34nob5DDPErES9xus6ch+YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EsmEl3eQRCF6ld1c/CSaTZaSaw9mzmxJj9mloJgQZDw5taVRjsfXvcKladLf/XpEgO BTomwCULv/iHsttC9fxU+kHDEs+8yAjsFzI7XQg54tkyiblOoSotP9kLN066WKaEdizA cSHSqG4iSU5Oq6RxL8n8C2XT3r5jYXxXuGybs= MIME-Version: 1.0 Received: by 10.143.11.19 with SMTP id o19mr1249727wfi.100.1292058585603; Sat, 11 Dec 2010 01:09:45 -0800 (PST) Received: by 10.142.230.17 with HTTP; Sat, 11 Dec 2010 01:09:45 -0800 (PST) In-Reply-To: <201012101915.40878.hselasky@c2i.net> References: <201012101915.40878.hselasky@c2i.net> Date: Sat, 11 Dec 2010 11:09:45 +0200 Message-ID: From: Oleg Nauman To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 11 Dec 2010 12:21:43 +0000 Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 09:38:53 -0000 Hello Hans, On Fri, Dec 10, 2010 at 8:15 PM, Hans Petter Selasky wro= te: > Hi, > > I think this is a known issue which never got fixed. Please try the attac= hed > patch and report back. Have applied your patch, my laptop was not crashing anymore. Thank you! But we will continue the saga about this strange USB modem, if no objections from your side :) Is it possible to apply some quirk or some another workaround which will solve the issue with endless USB_ERR_STALLED reported while it trying to attach its builtin cardreader? Thank you again. > > XXX_SAFE !=3D XXX_REAL_SAFE :-) > > --HPS > > On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: >> On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman wrot= e: >> > =C2=A0Hello Hans, >> > >> > On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky > wrote: >> >> On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: >> >>> Hello, >> >>> >> >>> Unfortunately my notebook experienced the crash during the attempts = to >> >>> attach EVDO modem supplied with builtin MicroSD cardreader. >> >>> Related core.txt file is attached as well as 'usbconfig >> >>> dump_all_config_desc' output (all_config.txt) >> >>> USB subsystem reports endless USB_ERR_STALLED events during attempts >> >>> to attach umass device, but attaches it finally ( sometimes it >> >>> attached after two attempts, sometimes it trying to attach during >> >>> 15-20 minutes ).MicroSD is inserted there, without any effect =C2=A0= on >> >>> attachment attempts though. >> >> >> >> Hi, >> >> >> >> Can you reproduce the panic using a kernel built with INVARIANTS opti= ons >> >> and DEBUG_MEMGUARD . >> > >> > =C2=A0I rebuilt my kernel with options you mentioned ( have added >> > INVARIANT_SUPPORT required =C2=A0by INVARIANTS though ) >> > >> > Waiting on panic.. >> >> =C2=A0Got it finally ( core.txt file is attached ) >> > From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 22:24:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 61A3B106566B; Sat, 11 Dec 2010 22:24:17 +0000 (UTC) Date: Sat, 11 Dec 2010 22:24:17 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101211222417.GA41847@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline Subject: a few OptionalObsoleteFiles.inc improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:24:17 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, any thoughts on this patch? it adds files which will be removed when WITHOUT_SYSCONS is set. also it makes sure sysinstall(8) and sade(8) only get installed when WITHOUT_SYSINSTALL wasn't defined and also that any related executables and manual pages get removed if in fact that var is defined. cheers. alex -- a13x --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="optional-files.diff" diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile index b7747d8..2ab7fc7 100644 --- a/share/man/man4/Makefile +++ b/share/man/man4/Makefile @@ -414,7 +414,6 @@ MAN= aac.4 \ sym.4 \ syncache.4 \ syncer.4 \ - syscons.4 \ sysmouse.4 \ tap.4 \ targ.4 \ @@ -611,7 +610,6 @@ MLINKS+=ste.4 if_ste.4 MLINKS+=stf.4 if_stf.4 MLINKS+=stge.4 if_stge.4 MLINKS+=syncache.4 syncookies.4 -MLINKS+=syscons.4 sc.4 MLINKS+=tap.4 if_tap.4 MLINKS+=tdfx.4 tdfx_linux.4 MLINKS+=ti.4 if_ti.4 @@ -637,6 +635,11 @@ MLINKS+=xe.4 if_xe.4 MLINKS+=xl.4 if_xl.4 MLINKS+=zyd.4 if_zyd.4 +.if ${MK_SYSCONS} != "no" +MAN+= syscons.4 +MLINKS+=syscons.4 sc.4 +.endif + .if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386" _acpi_asus.4= acpi_asus.4 _acpi_dock.4= acpi_dock.4 diff --git a/tools/build/mk/OptionalObsoleteFiles.inc b/tools/build/mk/OptionalObsoleteFiles.inc index db8251c..91b3cbf 100644 --- a/tools/build/mk/OptionalObsoleteFiles.inc +++ b/tools/build/mk/OptionalObsoleteFiles.inc @@ -1943,7 +1943,7 @@ OLD_FILES+=usr/lib/libz_p.a .if ${MK_RCMDS} == no OLD_FILES+=bin/rcp -OLD_FILES+=etc/periodic/daily/140.clean-rwho +OLD_FILES+=etc/periodic/daily/140.clean-rwho OLD_FILES+=etc/periodic/daily/430.status-rwho OLD_FILES+=rescue/rcp OLD_FILES+=usr/bin/rlogin @@ -2226,9 +2226,196 @@ OLD_FILES+=usr/share/sendmail/cf/siteconfig/uucp.ucbvax.m4 #.endif #.if ${MK_SYSCONS} == no -# to be filled in +OLD_FILES+=share/man/man4/sc.4.gz +OLD_FILES+=share/man/man4/syscons.4.gz +OLD_FILES+=share/syscons/fonts/INDEX.fonts +OLD_FILES+=share/syscons/fonts/armscii8-8x14.fnt +OLD_FILES+=share/syscons/fonts/armscii8-8x16.fnt +OLD_FILES+=share/syscons/fonts/armscii8-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp1251-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp1251-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp1251-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp437-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp437-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp437-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp437-thin-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp437-thin-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp850-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp850-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp850-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp850-thin-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp850-thin-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp865-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp865-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp865-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp865-thin-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp865-thin-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp866-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp866-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp866-8x8.fnt +OLD_FILES+=share/syscons/fonts/cp866b-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp866c-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp866u-8x14.fnt +OLD_FILES+=share/syscons/fonts/cp866u-8x16.fnt +OLD_FILES+=share/syscons/fonts/cp866u-8x8.fnt +OLD_FILES+=share/syscons/fonts/haik8-8x14.fnt +OLD_FILES+=share/syscons/fonts/haik8-8x16.fnt +OLD_FILES+=share/syscons/fonts/haik8-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso-thin-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso02-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso02-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso02-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso04-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso04-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso04-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso04-vga9-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso04-vga9-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso04-vga9-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso04-vga9-wide-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso04-wide-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso05-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso05-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso05-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso07-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso07-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso07-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso08-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso08-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso08-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso09-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso15-8x14.fnt +OLD_FILES+=share/syscons/fonts/iso15-8x16.fnt +OLD_FILES+=share/syscons/fonts/iso15-8x8.fnt +OLD_FILES+=share/syscons/fonts/iso15-thin-8x16.fnt +OLD_FILES+=share/syscons/fonts/koi8-r-8x14.fnt +OLD_FILES+=share/syscons/fonts/koi8-r-8x16.fnt +OLD_FILES+=share/syscons/fonts/koi8-r-8x8.fnt +OLD_FILES+=share/syscons/fonts/koi8-rb-8x16.fnt +OLD_FILES+=share/syscons/fonts/koi8-rc-8x16.fnt +OLD_FILES+=share/syscons/fonts/koi8-u-8x14.fnt +OLD_FILES+=share/syscons/fonts/koi8-u-8x16.fnt +OLD_FILES+=share/syscons/fonts/koi8-u-8x8.fnt +OLD_FILES+=share/syscons/fonts/swiss-1131-8x16.fnt +OLD_FILES+=share/syscons/fonts/swiss-1251-8x16.fnt +OLD_FILES+=share/syscons/fonts/swiss-8x14.fnt +OLD_FILES+=share/syscons/fonts/swiss-8x16.fnt +OLD_FILES+=share/syscons/fonts/swiss-8x8.fnt +OLD_FILES+=share/syscons/keymaps/INDEX.keymaps +OLD_FILES+=share/syscons/keymaps/be.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/be.iso.kbd +OLD_FILES+=share/syscons/keymaps/bg.bds.ctrlcaps.kbd +OLD_FILES+=share/syscons/keymaps/bg.phonetic.ctrlcaps.kbd +OLD_FILES+=share/syscons/keymaps/br275.cp850.kbd +OLD_FILES+=share/syscons/keymaps/br275.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/br275.iso.kbd +OLD_FILES+=share/syscons/keymaps/by.cp1131.kbd +OLD_FILES+=share/syscons/keymaps/by.cp1251.kbd +OLD_FILES+=share/syscons/keymaps/by.iso5.kbd +OLD_FILES+=share/syscons/keymaps/ce.iso2.kbd +OLD_FILES+=share/syscons/keymaps/colemak.iso15.acc.kbd +OLD_FILES+=share/syscons/keymaps/cs.latin2.qwertz.kbd +OLD_FILES+=share/syscons/keymaps/cz.iso2.kbd +OLD_FILES+=share/syscons/keymaps/danish.cp865.kbd +OLD_FILES+=share/syscons/keymaps/danish.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/danish.iso.kbd +OLD_FILES+=share/syscons/keymaps/dutch.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/eee_nordic.kbd +OLD_FILES+=share/syscons/keymaps/el.iso07.kbd +OLD_FILES+=share/syscons/keymaps/estonian.cp850.kbd +OLD_FILES+=share/syscons/keymaps/estonian.iso.kbd +OLD_FILES+=share/syscons/keymaps/estonian.iso15.kbd +OLD_FILES+=share/syscons/keymaps/finnish.cp850.kbd +OLD_FILES+=share/syscons/keymaps/finnish.iso.kbd +OLD_FILES+=share/syscons/keymaps/fr.dvorak.acc.kbd +OLD_FILES+=share/syscons/keymaps/fr.dvorak.kbd +OLD_FILES+=share/syscons/keymaps/fr.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/fr.iso.kbd +OLD_FILES+=share/syscons/keymaps/fr.macbook.acc.kbd +OLD_FILES+=share/syscons/keymaps/fr_CA.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/german.cp850.kbd +OLD_FILES+=share/syscons/keymaps/german.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/german.iso.kbd +OLD_FILES+=share/syscons/keymaps/gr.elot.acc.kbd +OLD_FILES+=share/syscons/keymaps/gr.us101.acc.kbd +OLD_FILES+=share/syscons/keymaps/hr.iso.kbd +OLD_FILES+=share/syscons/keymaps/hu.iso2.101keys.kbd +OLD_FILES+=share/syscons/keymaps/hu.iso2.102keys.kbd +OLD_FILES+=share/syscons/keymaps/hy.armscii-8.kbd +OLD_FILES+=share/syscons/keymaps/icelandic.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/icelandic.iso.kbd +OLD_FILES+=share/syscons/keymaps/it.iso.kbd +OLD_FILES+=share/syscons/keymaps/iw.iso8.kbd +OLD_FILES+=share/syscons/keymaps/jp.106.kbd +OLD_FILES+=share/syscons/keymaps/jp.106x.kbd +OLD_FILES+=share/syscons/keymaps/jp.pc98.iso.kbd +OLD_FILES+=share/syscons/keymaps/jp.pc98.kbd +OLD_FILES+=share/syscons/keymaps/kk.pt154.io.kbd +OLD_FILES+=share/syscons/keymaps/kk.pt154.kst.kbd +OLD_FILES+=share/syscons/keymaps/latinamerican.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/latinamerican.kbd +OLD_FILES+=share/syscons/keymaps/lt.iso4.kbd +OLD_FILES+=share/syscons/keymaps/norwegian.dvorak.kbd +OLD_FILES+=share/syscons/keymaps/norwegian.iso.kbd +OLD_FILES+=share/syscons/keymaps/pl_PL.ISO8859-2.kbd +OLD_FILES+=share/syscons/keymaps/pl_PL.dvorak.kbd +OLD_FILES+=share/syscons/keymaps/pt.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/pt.iso.kbd +OLD_FILES+=share/syscons/keymaps/ru.cp866.kbd +OLD_FILES+=share/syscons/keymaps/ru.iso5.kbd +OLD_FILES+=share/syscons/keymaps/ru.koi8-r.kbd +OLD_FILES+=share/syscons/keymaps/ru.koi8-r.shift.kbd +OLD_FILES+=share/syscons/keymaps/ru.koi8-r.win.kbd +OLD_FILES+=share/syscons/keymaps/si.iso.kbd +OLD_FILES+=share/syscons/keymaps/sk.iso2.kbd +OLD_FILES+=share/syscons/keymaps/spanish.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/spanish.iso.kbd +OLD_FILES+=share/syscons/keymaps/spanish.iso15.acc.kbd +OLD_FILES+=share/syscons/keymaps/swedish.cp850.kbd +OLD_FILES+=share/syscons/keymaps/swedish.iso.kbd +OLD_FILES+=share/syscons/keymaps/swissfrench.cp850.kbd +OLD_FILES+=share/syscons/keymaps/swissfrench.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/swissfrench.iso.kbd +OLD_FILES+=share/syscons/keymaps/swissgerman.cp850.kbd +OLD_FILES+=share/syscons/keymaps/swissgerman.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/swissgerman.iso.kbd +OLD_FILES+=share/syscons/keymaps/swissgerman.macbook.acc.kbd +OLD_FILES+=share/syscons/keymaps/tr.iso9.q.kbd +OLD_FILES+=share/syscons/keymaps/ua.iso5.kbd +OLD_FILES+=share/syscons/keymaps/ua.koi8-u.kbd +OLD_FILES+=share/syscons/keymaps/ua.koi8-u.shift.alt.kbd +OLD_FILES+=share/syscons/keymaps/uk.cp850-ctrl.kbd +OLD_FILES+=share/syscons/keymaps/uk.cp850.kbd +OLD_FILES+=share/syscons/keymaps/uk.dvorak.kbd +OLD_FILES+=share/syscons/keymaps/uk.iso-ctrl.kbd +OLD_FILES+=share/syscons/keymaps/uk.iso.kbd +OLD_FILES+=share/syscons/keymaps/us.dvorak.kbd +OLD_FILES+=share/syscons/keymaps/us.dvorakl.kbd +OLD_FILES+=share/syscons/keymaps/us.dvorakr.kbd +OLD_FILES+=share/syscons/keymaps/us.dvorakx.kbd +OLD_FILES+=share/syscons/keymaps/us.emacs.kbd +OLD_FILES+=share/syscons/keymaps/us.iso.acc.kbd +OLD_FILES+=share/syscons/keymaps/us.iso.kbd +OLD_FILES+=share/syscons/keymaps/us.pc-ctrl.kbd +OLD_FILES+=share/syscons/keymaps/us.unix.kbd +OLD_FILES+=share/syscons/scrnmaps/armscii8-2haik8 +OLD_FILES+=share/syscons/scrnmaps/iso-8859-1_to_cp437 +OLD_FILES+=share/syscons/scrnmaps/iso-8859-4_for_vga9 +OLD_FILES+=share/syscons/scrnmaps/iso-8859-7_to_cp437 +OLD_FILES+=share/syscons/scrnmaps/koi8-r2cp866 +OLD_FILES+=share/syscons/scrnmaps/koi8-u2cp866u +OLD_FILES+=share/syscons/scrnmaps/us-ascii_to_cp437 #.endif +.if ${MK_SYSINSTALL} == no +OLD_FILES+=usr/sbin/sade +OLD_FILES+=usr/sbin/sysinstall +OLD_FILES+=usr/share/man/man8/sade.8.gz +OLD_FILES+=usr/share/man/man8/sysinstall.8.gz +.endif + .if ${MK_TCSH} == no OLD_FILES+=bin/csh OLD_FILES+=bin/tcsh diff --git a/tools/build/options/WITHOUT_SYSINSTALL b/tools/build/options/WITHOUT_SYSINSTALL index 60426e3..e268c2f 100644 --- a/tools/build/options/WITHOUT_SYSINSTALL +++ b/tools/build/options/WITHOUT_SYSINSTALL @@ -1,4 +1,5 @@ .\" $FreeBSD$ Set to not build -.Xr sysinstall 8 -and related programs. +.Xr sade 8 +and +.Xr sysinstall 8 . diff --git a/usr.sbin/Makefile b/usr.sbin/Makefile index f3e853e..2151868 100644 --- a/usr.sbin/Makefile +++ b/usr.sbin/Makefile @@ -250,7 +250,6 @@ SUBDIR+= ftp-proxy SUBDIR+= pkg_install .endif -# XXX MK_TOOLCHAIN? .if ${MK_PMC} != "no" SUBDIR+= pmcannotate SUBDIR+= pmccontrol @@ -283,7 +282,9 @@ SUBDIR+= praliases SUBDIR+= sendmail .endif +.if ${MK_SYSINSTALL} != "no" SUBDIR+= sysinstall +.endif .if ${MK_TOOLCHAIN} != "no" SUBDIR+= config --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 11 22:48:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9337F106566C for ; Sat, 11 Dec 2010 22:48:52 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2AF8FC13 for ; Sat, 11 Dec 2010 22:48:51 +0000 (UTC) Received: from cpbrm-ews25.kpnxchange.com ([10.94.84.156]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Dec 2010 23:48:51 +0100 Received: from CPSMTPM-CMT104.kpnxchange.com ([195.121.3.20]) by cpbrm-ews25.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Dec 2010 23:48:50 +0100 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by CPSMTPM-CMT104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 11 Dec 2010 23:48:50 +0100 Received: from hillary.van-laarhoven.org (Hillary.van-laarhoven.org [10.66.0.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by uitsmijter.van-laarhoven.org (Postfix) with ESMTPSA id E39E34267; Sat, 11 Dec 2010 23:48:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nick Hibma In-Reply-To: <201012111103.09422.hselasky@c2i.net> Date: Sat, 11 Dec 2010 23:48:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21DC55BC-CC3B-48EF-8C9A-C29674CD38E7@van-laarhoven.org> References: <201012101915.40878.hselasky@c2i.net> <201012111103.09422.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 11 Dec 2010 22:48:50.0347 (UTC) FILETIME=[940867B0:01CB9985] X-RcptDomain: freebsd.org Cc: Oleg Nauman , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:48:52 -0000 >> But we will continue the saga about this strange USB modem, if no >> objections from your side :) >> Is it possible to apply some quirk or some another workaround which >> will solve the issue with endless USB_ERR_STALLED reported while it >> trying to attach its builtin cardreader? >=20 > Nick, do you have any hints on this? It says in the messages log (a view messages ago) that it does not = support GET MAX LUN. You can quirk that: While the device is attached use the following command: usbconfig -d ugenX.Y add_quirk UQ_MSC_NO_GETMAXLUN where ugenX.Y is the ugen device for the device that causes you trouble. = usbconfig will add a quirk using the PID/VID/RID for the device it finds = at that location. If that works, let me know, and I will commit the quirk into the quirk = table. Nick=