From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 23:13: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 4EE18106566C for ; Sat, 4 Sep 2010 23:13:51 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id F1B6C8FC0A for ; Sat, 4 Sep 2010 23:13:50 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o84NDnXP003270; Sat, 4 Sep 2010 19:13:49 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o84NDm0i003267; Sat, 4 Sep 2010 19:13:48 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19586.53932.73238.617003@hergotha.csail.mit.edu> Date: Sat, 4 Sep 2010 19:13:48 -0400 From: Garrett Wollman To: Andriy Gapon In-Reply-To: <4C7F6229.3040708@icyb.net.ua> References: <19577.18337.120013.129482@hergotha.csail.mit.edu> <4C79499B.3050305@icyb.net.ua> <201008281741.o7SHfqH1008851@hergotha.csail.mit.edu> <4C7E7C43.7070209@icyb.net.ua> <19582.39357.917382.37670@hergotha.csail.mit.edu> <4C7F6229.3040708@icyb.net.ua> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 04 Sep 2010 19:13:49 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 05 Sep 2010 01:10:13 +0000 Cc: current@FreeBSD.org Subject: Re: Difficulty playing DVDs under AHCI/CAM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2010 23:13:51 -0000 < said: > Not sure if debugging with CAMDEBUG would be easier or not. > There could be lots of output. I never found out, as once I rebooted with the new CAMDEBUG-ified kernel, everything started working. No idea why. (Maybe the DVD player just wanted to be rebooted with a disc in it?) -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:27: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 5F10410656C8; Sun, 5 Sep 2010 08:27:31 +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 214BE8FC20; Sun, 5 Sep 2010 08:27:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o858RUaD031903; Sun, 5 Sep 2010 04:27:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o858RU2V031902; Sun, 5 Sep 2010 08:27:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 08:27:30 GMT Message-Id: <201009050827.o858RU2V031902@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: Sun, 05 Sep 2010 08:27:31 -0000 TB --- 2010-09-05 07:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 07:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-09-05 07:50:00 - cleaning the object tree TB --- 2010-09-05 07:50:47 - cvsupping the source tree TB --- 2010-09-05 07:50:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-09-05 08:27:30 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 08:27:30 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 08:27:30 - 0.94 user 28.07 system 2249.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:27: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 A16B510656F2; Sun, 5 Sep 2010 08:27: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 637758FC18; Sun, 5 Sep 2010 08:27:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o858Rvw6031911; Sun, 5 Sep 2010 04:27:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o858Rv8k031910; Sun, 5 Sep 2010 08:27:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 08:27:57 GMT Message-Id: <201009050827.o858Rv8k031910@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: Sun, 05 Sep 2010 08:27:58 -0000 TB --- 2010-09-05 07:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 07:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-09-05 07:50:00 - cleaning the object tree TB --- 2010-09-05 07:50:26 - cvsupping the source tree TB --- 2010-09-05 07:50:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-09-05 08:27:57 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 08:27:57 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 08:27:57 - 0.55 user 18.15 system 2277.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:28: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 9E5E510656C9; Sun, 5 Sep 2010 08:28: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 57A008FC12; Sun, 5 Sep 2010 08:28:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o858SL7N031919; Sun, 5 Sep 2010 04:28:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o858SLZP031918; Sun, 5 Sep 2010 08:28:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 08:28:21 GMT Message-Id: <201009050828.o858SLZP031918@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: Sun, 05 Sep 2010 08:28:22 -0000 TB --- 2010-09-05 07:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 07:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-09-05 07:50:00 - cleaning the object tree TB --- 2010-09-05 07:50:51 - cvsupping the source tree TB --- 2010-09-05 07:50:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-09-05 08:28:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 08:28:21 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 08:28:21 - 1.12 user 31.12 system 2301.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:30:30 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 876F31065675; Sun, 5 Sep 2010 08:30:30 +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 441898FC0A; Sun, 5 Sep 2010 08:30:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o858UTAA031935; Sun, 5 Sep 2010 04:30:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o858UTq0031934; Sun, 5 Sep 2010 08:30:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 08:30:29 GMT Message-Id: <201009050830.o858UTq0031934@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: Sun, 05 Sep 2010 08:30:30 -0000 TB --- 2010-09-05 07:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 07:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-09-05 07:50:00 - cleaning the object tree TB --- 2010-09-05 07:50:40 - cvsupping the source tree TB --- 2010-09-05 07:50:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-09-05 08:30:29 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 08:30:29 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 08:30:29 - 0.78 user 23.25 system 2429.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:02:16 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 53ECF10656C0; Sun, 5 Sep 2010 09:02:16 +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 111458FC12; Sun, 5 Sep 2010 09:02:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8592Fah032054; Sun, 5 Sep 2010 05:02:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8592FRK032053; Sun, 5 Sep 2010 09:02:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:02:15 GMT Message-Id: <201009050902.o8592FRK032053@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: Sun, 05 Sep 2010 09:02:16 -0000 TB --- 2010-09-05 08:27:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 08:27:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-09-05 08:27:30 - cleaning the object tree TB --- 2010-09-05 08:27:42 - cvsupping the source tree TB --- 2010-09-05 08:27:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-09-05 09:02:15 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:02:15 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:02:15 - 0.48 user 8.05 system 2084.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:06:36 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 692E410656BC; Sun, 5 Sep 2010 09:06:36 +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 268118FC12; Sun, 5 Sep 2010 09:06:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8596Z7f032072; Sun, 5 Sep 2010 05:06:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8596Znf032071; Sun, 5 Sep 2010 09:06:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:06:35 GMT Message-Id: <201009050906.o8596Znf032071@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: Sun, 05 Sep 2010 09:06:36 -0000 TB --- 2010-09-05 08:27:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 08:27:57 - starting HEAD tinderbox run for mips/mips TB --- 2010-09-05 08:27:57 - cleaning the object tree TB --- 2010-09-05 08:28:07 - cvsupping the source tree TB --- 2010-09-05 08:28:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-09-05 09:06:35 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:06:35 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:06:35 - 0.38 user 4.78 system 2317.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:07:47 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 E244E10656CF; Sun, 5 Sep 2010 09:07:47 +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 9BE198FC12; Sun, 5 Sep 2010 09:07:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8597kNr032080; Sun, 5 Sep 2010 05:07:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8597k7i032079; Sun, 5 Sep 2010 09:07:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:07:46 GMT Message-Id: <201009050907.o8597k7i032079@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: Sun, 05 Sep 2010 09:07:48 -0000 TB --- 2010-09-05 08:28:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 08:28:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-05 08:28:21 - cleaning the object tree TB --- 2010-09-05 08:28:38 - cvsupping the source tree TB --- 2010-09-05 08:28:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-05 09:07:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:07:46 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:07:46 - 0.54 user 7.96 system 2364.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:08:33 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 1563D10656BD; Sun, 5 Sep 2010 09:08:33 +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 CC1AD8FC0C; Sun, 5 Sep 2010 09:08:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8598WtO032084; Sun, 5 Sep 2010 05:08:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8598WKU032083; Sun, 5 Sep 2010 09:08:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:08:32 GMT Message-Id: <201009050908.o8598WKU032083@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: Sun, 05 Sep 2010 09:08:33 -0000 TB --- 2010-09-05 08:30:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 08:30:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-05 08:30:29 - cleaning the object tree TB --- 2010-09-05 08:30:44 - cvsupping the source tree TB --- 2010-09-05 08:30:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-05 09:08:32 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:08:32 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:08:32 - 0.62 user 10.23 system 2282.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:37:06 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 A4F5C10656AB; Sun, 5 Sep 2010 09:37:06 +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 623CA8FC12; Sun, 5 Sep 2010 09:37:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o859b5No032182; Sun, 5 Sep 2010 05:37:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o859b5H7032181; Sun, 5 Sep 2010 09:37:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:37:05 GMT Message-Id: <201009050937.o859b5H7032181@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: Sun, 05 Sep 2010 09:37:06 -0000 TB --- 2010-09-05 09:02:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:02:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-09-05 09:02:15 - cleaning the object tree TB --- 2010-09-05 09:02:26 - cvsupping the source tree TB --- 2010-09-05 09:02:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-09-05 09:37:05 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:37:05 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:37:05 - 0.53 user 7.72 system 2090.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:42:59 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 D43FC1065674; Sun, 5 Sep 2010 09:42:59 +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 8DB2F8FC1A; Sun, 5 Sep 2010 09:42:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o859gwOK032200; Sun, 5 Sep 2010 05:42:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o859gw1K032199; Sun, 5 Sep 2010 09:42:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 09:42:58 GMT Message-Id: <201009050942.o859gw1K032199@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: Sun, 05 Sep 2010 09:42:59 -0000 TB --- 2010-09-05 09:06:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:06:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-09-05 09:06:35 - cleaning the object tree TB --- 2010-09-05 09:06:44 - cvsupping the source tree TB --- 2010-09-05 09:06:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-09-05 09:42:58 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 09:42:58 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 09:42:58 - 0.39 user 6.42 system 2183.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 15:41: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 A166510656A4 for ; Sun, 5 Sep 2010 15:41:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 68AAE8FC19 for ; Sun, 5 Sep 2010 15:41:57 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5EEE373098; Sun, 5 Sep 2010 17:53:11 +0200 (CEST) Date: Sun, 5 Sep 2010 17:53:11 +0200 From: Luigi Rizzo To: Anderson Eduardo Message-ID: <20100905155311.GA48095@onelab2.iet.unipi.it> References: <4C825094.5040204@secover.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C825094.5040204@secover.com.br> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Using ipfw table names instead of numbers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:41:57 -0000 On Sat, Sep 04, 2010 at 10:58:44AM -0300, Anderson Eduardo wrote: > Hello developers, > > I use the ipfw firewall with many tables and, I would like of able to > use it with name/alias instead of just numbers. > > E.g: > > lab# ipfw table 1 name lanetwork > Setting table 1 to lanetwork > lab# ipfw table lanetwork add 192.168.0.0/24 > lab# ipfw table lanetwork list > 192.168.0.0/24 0 > lab# > > I think a good idea a patch to do that. if you have a patch feel free to post it. the main issue is that internally, for efficiency reason, the name must be translated to a number anyways, so before implementing it one must decide where the name-number translation table is stored and how it is managed The same applies to any name vs. number issue in ipfw/dummynet Service, protocol and host names solve these issues because there is a well defined place for the translation table. But, for instance, hostname mappings are static (translated at rule insertion time) whereas one might want a more dynamic behaviour (e.g. refresh whenever the DNS response expires). cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 19:03: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 3A20D10656BE; Sun, 5 Sep 2010 19:03:26 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2D88FC16; Sun, 5 Sep 2010 19:03:25 +0000 (UTC) Received: by gyg4 with SMTP id 4so1658271gyg.13 for ; Sun, 05 Sep 2010 12:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=wSO+9jy6zBsBb5E23F5G9KG9bokJsj2NU2jlYuk/AJk=; b=TxNEjGKf7ef1aEVxq3Owbc1mwUowAmNr+Y5u+rZ6wfP8rVGGaUhFwi+ooGgEGIM6Dg 6wh9PGW0HNgaykNHH7w0hB2GwuxwkQRsUKWthL1+GIgqyqBEU6zr7p6LcbNoR17xFLfT Nx+tfw5l2Qfx3HbIT+LyRXpG5gxU0FEn+NgxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=MxsD72ysK31Yo7TCIB73ABdE8rOCL2Vnwdxwxo2Z9ZuYtrRkDX6tUVg0qnJn2W++u9 p2ihfbuHqF8wrhpQtcpbVLazi84LGW9f9wnh8/y3JW8xPVu6RxCRVmMlchyJ3wsCl+WB xy8W+U69GoPGAPx2XbwA0YcI6OW+iaLqQIDm4= Received: by 10.150.148.2 with SMTP id v2mr207842ybd.184.1283713405166; Sun, 05 Sep 2010 12:03:25 -0700 (PDT) Received: from localhost (tor-exit-proxy3-readme.formlessnetworking.net [208.53.142.39]) by mx.google.com with ESMTPS id t20sm2585340ybm.5.2010.09.05.12.03.22 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 12:03:24 -0700 (PDT) From: Anonymous To: Pawel Jakub Dawidek References: <20100831215915.GE1932@garage.freebsd.pl> Date: Sun, 05 Sep 2010 22:56:27 +0400 Message-ID: <86mxrwow84.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:03:26 -0000 Pawel Jakub Dawidek writes: > Hello. > > I'd like to give you ZFS v28 for testing. If you are neither brave nor > mad, you can stop here. [...] > So test whatever you can and report back. Look for regressions, > strange behaviour, I wonder why new files tend to have different ACLs than old ones. $ ls -lh foo -rw-r--r-- 1 holo holo 17K Aug 19 11:43 foo $ cp foo bar $ ls -lh bar -rw-r--r--+ 1 holo holo 17K Sep 5 21:20 bar $ getfacl foo bar # file: foo # owner: holo # group: holo owner@:--x-----------:------:deny owner@:rw-p---A-W-Co-:------:allow group@:-wxp----------:------:deny group@:r-------------:------:allow everyone@:-wxp---A-W-Co-:------:deny everyone@:r-----a-R-c--s:------:allow # file: bar # owner: holo # group: holo owner@:rw-p--aARWcCos:------:allow group@:r-----a-R-c--s:------:allow everyone@:r-----a-R-c--s:------:allow $ zfs get aclinherit h$PWD NAME PROPERTY VALUE SOURCE h/home/holo aclinherit restricted default Note, I didn't upgrade the pool to v28. > missing features, deadlocks, livelocks, preformance degradation, etc. From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 20:15: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 7906D1065992; Sun, 5 Sep 2010 20:15:33 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7F48FC12; Sun, 5 Sep 2010 20:15:33 +0000 (UTC) Received: by vws7 with SMTP id 7so3155424vws.13 for ; Sun, 05 Sep 2010 13:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.126.208 with SMTP id d16mr2249245vcs.206.1283717732368; Sun, 05 Sep 2010 13:15:32 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Sun, 5 Sep 2010 13:15:32 -0700 (PDT) X-Originating-IP: [71.1.133.114] In-Reply-To: <4C83D04E.4050000@freebsd.org> References: <4C83D04E.4050000@freebsd.org> Date: Sun, 5 Sep 2010 13:15:32 -0700 Message-ID: From: Rob Farmer To: vwe@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, bug-followup@freebsd.org Subject: Re: ports/150265: [patch] print/ghostscript8 disable bogus port conflicts in make release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 20:15:36 -0000 On Sun, Sep 5, 2010 at 10:15, wrote: > > Rob, > > IMO the question is not if the problem _can_ be solved in the base build > system. I doubt you'll find many src committers willing to break other > peoples machines by using DISABLE_CONFLICTS as a general problem solver. > > It may well work for your machine and you're free to do that. > > The maintainer of ghostscript8 may check the issue but is free to close the > PR as WONTFIX (I suspect that will most likely happen). > > Instead of filing a PR for such problems, a discussion on our fine mailing > lists might be good. > > Thanks! > [adding a mailing list per your suggestion] I think you are misunderstanding the issue here. This is not a ghostscript issue and the maintainer of ghostscript isn't the right person to look at it. The same issue can appear with other ports used by make release, such as perl. In fact, there isn't any way for this to be solved in the ports tree short of removing the CONFLICTS handling (which is not what I am suggesting). What happens is the release building process uses certain ports to generate the HTML documentation (release notes, etc.) on the CDs. To insure a clean build environment, these ports are built and installed in a chroot away from the main system. However, prior to entering the chroot, the distfiles for these ports are fetched and checksummed with "make checksum-recursive". This process occurs outside the chroot, so the ports system looks for conflicts with what is installed in /usr/local, assuming that these distfiles are for ports to be installed in /usr/local. This assumption is flawed, since they will not be installed there and thus will not conflict. My patch runs the "make checksum-recursive" target with -DDISABLE_CONFLICTS to avoid these false positives. This will not "break other people's machines" as you state because the absolute worst case scenario with my patch is having a couple duplicate distfiles (such as perl5.10 and perl5.12). Nothing is built or installed with the DISABLE_CONFLICTS flag. What I'm asking you to do is revert the description, category, and assignment of the PR so that someone who is familiar with the release building process will see it. -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 00:31:13 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 C594810656E7 for ; Mon, 6 Sep 2010 00:31:13 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 785588FC08 for ; Mon, 6 Sep 2010 00:31:13 +0000 (UTC) Received: by gwb15 with SMTP id 15so1630576gwb.13 for ; Sun, 05 Sep 2010 17:31:12 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=4jVWG7C81fMtpHLPTnjHCC96IBYOYq6kr/CsDdaEQWA=; b=h18zxiigmBumXiYCgJ/BRuoWx258o1V31pqnVMtrddW5z0WFW3n9gMt0nuXnDuwyqF 9KGJZ7OdWdQBIrB2w9177dt6FrNznjh2Too0KaUSyPQo4Yxt2U4eQ+wD1oltv19IKJYw 1UuBLWBG+sqd0ZXe2Im/XUD4TYbPN2m0Luoxc= 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:x-enigmail-version:content-type :content-transfer-encoding; b=feh1JfzfLugMH0avL0PzhYAdzd5jeLUR5iEbEZM8ck0wQlzcFoggRBHRLbEKmnJNjk Sm4F0EcjUusrm9LL1TMSHMRh3eJCL69Z1S7uAEkDdDR6FAKl0k3fFWKyig4auqhOElSy QyI+R3JjqzicdmSK1Mp+TCeAUSJmhF6DkjkhY= Received: by 10.151.17.31 with SMTP id u31mr1869010ybi.194.1283733072351; Sun, 05 Sep 2010 17:31:12 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id q25sm5256066ybk.6.2010.09.05.17.31.10 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 17:31:11 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C84364D.9070700@DataIX.net> Date: Sun, 05 Sep 2010 20:31:09 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Luigi Rizzo References: <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> In-Reply-To: <20100905155311.GA48095@onelab2.iet.unipi.it> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Anderson Eduardo Subject: Re: Using ipfw table names instead of numbers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 00:31:13 -0000 On 09/05/2010 11:53, Luigi Rizzo wrote: > whereas one might want a more dynamic behaviour (e.g. refresh > whenever the DNS response expires). Lord that would be nice! if only PF had this ;) -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:47: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 8AD6E10656CA for ; Mon, 6 Sep 2010 06:47:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41C778FC15 for ; Mon, 6 Sep 2010 06:47:06 +0000 (UTC) Received: by gwb15 with SMTP id 15so1695518gwb.13 for ; Sun, 05 Sep 2010 23:47:06 -0700 (PDT) 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=22tq6WwTChCzBn3SDtysRJT93OJuIXiNQ9BEEoGY0VE=; b=mD3IUL3IYDQ5ciyPNk1i3G37mEjCUS0SH07oKF8oaauP3IiRjsNdpglDrgBCFjwALe RggKrReEMxg7Vgz5YyWU+DAjn09pwUEPkGN66BnBHznckTF/qJ5lCDttXYKI5+4lKD/l xw9tWiMgmyjsLX72BcX+GUijQTFX8HUm0b260= 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=rQ2BYw0yL4uzJE1YQTctzrqaJcuXPJfuErrSem2S+jYU7OOeTTSVw9Bpz9HG/L4Nu8 arxhMuAPSgihJ4gMmud8I4mchyW6GTN8nnUiR3DZ0Q9erLpHimdi3KYki63qc7T6jlxi NTiFV07ud0HbROFUquhQYKD1o31I2njqsWIvU= MIME-Version: 1.0 Received: by 10.151.48.17 with SMTP id a17mr1390391ybk.95.1283755626339; Sun, 05 Sep 2010 23:47:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.168.14 with HTTP; Sun, 5 Sep 2010 23:47:06 -0700 (PDT) In-Reply-To: <4C84364D.9070700@DataIX.net> References: <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> Date: Mon, 6 Sep 2010 14:47:06 +0800 X-Google-Sender-Auth: uXvGFrizShsyAF4mVEqYc0ILZvw Message-ID: From: Adrian Chadd To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Luigi Rizzo , Anderson Eduardo Subject: Re: Using ipfw table names instead of numbers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 06:47:07 -0000 I'd argue that "DNS" clue pushes the firewall out from a packet inspection thing and into a user-space application inspection thing. DNS entries in filter rules doesn't work as well in all situations as you'd like. :) Adrian (who has done this, and it doesn't quite work right in all situations thanks to split-horizon, per-user, geo-location, server-balancing DNS..) On 6 September 2010 08:31, jhell wrote: > On 09/05/2010 11:53, Luigi Rizzo wrote: >> whereas one might want a more dynamic behaviour (e.g. refresh >> whenever the DNS response expires). > > Lord that would be nice! if only PF had this ;) > > -- > > =A0jhell,v > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:59: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 BB8D110656C5 for ; Mon, 6 Sep 2010 06:59:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 46C328FC20 for ; Mon, 6 Sep 2010 06:59:42 +0000 (UTC) Received: (qmail 30515 invoked by uid 399); 6 Sep 2010 06:59:41 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 6 Sep 2010 06:59:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C84915A.1000703@FreeBSD.org> Date: Sun, 05 Sep 2010 23:59:38 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Adrian Chadd References: <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Luigi Rizzo , Anderson Eduardo Subject: Re: Using ipfw table names instead of numbers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 06:59:42 -0000 On 09/05/2010 11:47 PM, Adrian Chadd wrote: > I'd argue that "DNS" clue pushes the firewall out from a packet > inspection thing and into a user-space application inspection thing. It also opens up an attack vector on your firewall. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 08:21: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 AE43510656D2 for ; Mon, 6 Sep 2010 08:21:34 +0000 (UTC) (envelope-from peter@3mail4.co.uk) Received: from mail4.morpheushosting.sk (mail4.morpheushosting.sk [69.60.120.12]) by mx1.freebsd.org (Postfix) with ESMTP id 724DC8FC26 for ; Mon, 6 Sep 2010 08:21:34 +0000 (UTC) Received: from [192.168.1.5] (cpc14-know8-0-0-cust118.know.cable.virginmedia.com [82.46.228.119]) (authenticated bits=0) by mail4.morpheushosting.sk (8.14.4/8.14.4) with ESMTP id o868LJs4081563 for ; Mon, 6 Sep 2010 10:21:34 +0200 (CEST) (envelope-from peter@3mail4.co.uk) Message-ID: <4C84A44D.90403@3mail4.co.uk> Date: Mon, 06 Sep 2010 09:20:29 +0100 From: Peter Reo Molnar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> In-Reply-To: <4C84364D.9070700@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-101.9 required=5.1 tests=BAYES_00,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail4.morpheushosting.sk Subject: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 08:21:34 -0000 Hello, I tried setup NAT with IPFW, compiled my kernel and I found that there is very slow connection. After I disabled NAT and IPFW then speed was increased. 64-bit FreeBSD 9-CURRENT : With IPFW: 1.2 MB/sec Without IPFW: 33 MB/sec my ipfw work with i386 (stable) without speed decreasing: fw.test.conf: -f flush add 00050 divert 8668 ip4 from any to any via re0 add 00100 allow ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 add 00300 deny ip from 127.0.0.0/8 to any -- peter From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 08:49: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 1CBE710656B7 for ; Mon, 6 Sep 2010 08:49:36 +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 AA2818FC0A for ; Mon, 6 Sep 2010 08:49:35 +0000 (UTC) Received: from [41.154.88.19] (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 1OsXOO-0005iw-Kq; Mon, 06 Sep 2010 10:49:32 +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 1OsXO0-00017U-Fa; Mon, 06 Sep 2010 10:49:08 +0200 Message-Id: To: Peter Reo Molnar From: Ian FREISLICH In-Reply-To: <4C84A44D.90403@3mail4.co.uk> References: <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> X-Attribution: BOFH Date: Mon, 06 Sep 2010 10:49:08 +0200 Cc: freebsd-current@freebsd.org Subject: Re: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 08:49:36 -0000 Peter Reo Molnar wrote: > Hello, > > I tried setup NAT with IPFW, compiled my kernel and I found that there > is very slow connection. > After I disabled NAT and IPFW then speed was increased. > > 64-bit FreeBSD 9-CURRENT : > With IPFW: 1.2 MB/sec > Without IPFW: 33 MB/sec > > > my ipfw work with i386 (stable) without speed decreasing: > > fw.test.conf: > -f flush > add 00050 divert 8668 ip4 from any to any via re0 > add 00100 allow ip from any to any via lo0 > add 00200 deny ip from any to 127.0.0.0/8 > add 00300 deny ip from 127.0.0.0/8 to any This looks like you're using the old style NAT - divert to userland. That has always performed poorly. Perhaps not as poorly as this though. How much CPU is natd consuming? Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS TRANSLATION' section in the ipfw manual. It's worth a try. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 10:46: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 28D2210656D1; Mon, 6 Sep 2010 10:46: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 DA4798FC0A; Mon, 6 Sep 2010 10:46:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o86AkG05066263; Mon, 6 Sep 2010 06:46:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o86AkGBP066252; Mon, 6 Sep 2010 10:46:16 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 6 Sep 2010 10:46:16 GMT Message-Id: <201009061046.o86AkGBP066252@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: Mon, 06 Sep 2010 10:46:18 -0000 TB --- 2010-09-06 10:40:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-06 10:40:14 - starting HEAD tinderbox run for mips/mips TB --- 2010-09-06 10:40:14 - cleaning the object tree TB --- 2010-09-06 10:40:41 - cvsupping the source tree TB --- 2010-09-06 10:40:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/mips/mips/supfile TB --- 2010-09-06 10:46:16 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-06 10:46:16 - ERROR: unable to cvsup the source tree TB --- 2010-09-06 10:46:16 - 1.57 user 24.16 system 362.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 11:08: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 4BA071065696 for ; Mon, 6 Sep 2010 11:08:16 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6738FC2A for ; Mon, 6 Sep 2010 11:08:16 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OsZYa-0005Rh-Lw; Mon, 06 Sep 2010 11:08:12 +0000 Date: Mon, 06 Sep 2010 20:08:12 +0900 Message-ID: From: Randy Bush To: Ian FREISLICH In-Reply-To: References: <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 11:08:16 -0000 Ian FREISLICH wrote: > > Peter Reo Molnar wrote: > > Hello, > > > > I tried setup NAT with IPFW, compiled my kernel and I found that there > > is very slow connection. > > After I disabled NAT and IPFW then speed was increased. > > > > 64-bit FreeBSD 9-CURRENT : > > With IPFW: 1.2 MB/sec > > Without IPFW: 33 MB/sec > > > > > > my ipfw work with i386 (stable) without speed decreasing: > > > > fw.test.conf: > > -f flush > > add 00050 divert 8668 ip4 from any to any via re0 > > add 00100 allow ip from any to any via lo0 > > add 00200 deny ip from any to 127.0.0.0/8 > > add 00300 deny ip from 127.0.0.0/8 to any > > This looks like you're using the old style NAT - divert to userland. > That has always performed poorly. Perhaps not as poorly as this > though. How much CPU is natd consuming? > > Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS > TRANSLATION' section in the ipfw manual. It's worth a try. i never managed to figure out how to convert my pppoe nat config to ipfw natting. foo: set device PPPoE:vr0 set MTU 1454 accept CHAP enable lqr add default HISADDR nat enable yes nat port tcp 192.168.0.33:51332 51332 nat port udp 192.168.0.33:51332 51332 set authname blogovitch set authkey vitchoblog loop: set log phase chat connect lcp ipcp command set device localhost:pptp set dial set login set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255 clue bat solicited randy From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 11:42: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 2D3A010656BF for ; Mon, 6 Sep 2010 11:42:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id E55778FC1F for ; Mon, 6 Sep 2010 11:42:29 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 389A69D633; Mon, 6 Sep 2010 11:42:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Mon, 6 Sep 2010 13:42:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D932B42-A1EB-423A-A0D3-9BC05D4C8F3F@lassitu.de> References: <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> To: Randy Bush X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Current Subject: Re: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 11:42:30 -0000 Am 06.09.2010 um 13:08 schrieb Randy Bush: > i never managed to figure out how to convert my pppoe nat config to = ipfw > natting. I did not see a significant improvement going from ppp(8)+9 and ipfw to = ppp(8) and pf+nat. Since ppp(8) already incurs the kernel/userland cost, = having it handle NAT on top does not increase latency. I've recently switched to mpd (and pf), and things "feel" snappier. I = haven't benchmarked it though, and my router box is rather oversized for = the task anyway (C2D). Friends using a Soekris swear that it helps a = lot though. The switchover is fairly painless, and the excellent mpd manual helps a = lot. Using one of the many examples, I managed to set up the mpd.conf = rather quickly; the only real adaptation was in the up and down scripts = I was using (my ISP kicks the connection every 24 hours, and I get a new = IP, so I like to bounce a couple of things when the connection comes up = again.) Stefan --=20 Stefan Bethke Fon +49 151 14070811 mpd.conf: # # Default configuration is "dialup" default: load hansenet hansenet: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static hansenet #set bundle yes ipv6cp set iface route default set iface up-script /etc/ppp/hansenet.up set iface down-script /etc/ppp/hansenet.down set iface enable tcpmssfix create link static hansenet pppoe set pppoe iface vlan2 set pppoe service "" set link action bundle hansenet set link max-redial 0 set link keep-alive 10 60 set auth authname 04012345678 #set auth password MyPass set ipcp ranges 0.0.0.0/0 0.0.0.0/0 =09 open My old ppp.conf: hansenet: set device PPPoE:vlan2: set mru 1492 set mtu 1492 set speed sync enable lqr enable echo set lqrperiod 5 set cd 5 set dial set login set timeout 0 set authname 04012345678 add default HISADDR From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 11:50: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 39EAF10656AB; Mon, 6 Sep 2010 11:50:22 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [IPv6:2a01:4f8:100:1043::2]) by mx1.freebsd.org (Postfix) with ESMTP id C420A8FC16; Mon, 6 Sep 2010 11:50:21 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id D98A111410A; Mon, 6 Sep 2010 13:50:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F7nZcdZZHzy9; Mon, 6 Sep 2010 13:50:19 +0200 (CEST) Received: from [10.0.3.17] (188-167-67-67.dynamic.chello.sk [188.167.67.67]) by mail.vx.sk (Postfix) with ESMTPSA id 0CC7A114101; Mon, 6 Sep 2010 13:50:19 +0200 (CEST) Message-ID: <4C84D581.6060205@FreeBSD.org> Date: Mon, 06 Sep 2010 13:50:25 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <20100831215915.GE1932@garage.freebsd.pl> In-Reply-To: <20100831215915.GE1932@garage.freebsd.pl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 11:50:22 -0000 Hi everyone, I have put together a slightly improved patch of Pawel's that compiles correctly and supports booting from ZFS v19 pools. You can download the patch here: http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch For users who don't want to compile I have created a mfsBSD ISO image with a zfs-only install of 9-CURRENT-amd64: http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso You can read more about all of this here: http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html More information about ZFS pool and filesystem versions: http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html Thanks to everybody participating in testing, mm From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 12:17: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 AC98F10656D3; Mon, 6 Sep 2010 12:17:45 +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 639378FC19; Mon, 6 Sep 2010 12:17:44 +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 PAA01838; Mon, 06 Sep 2010 15:17:42 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84DBE6.5010809@freebsd.org> Date: Mon, 06 Sep 2010 15:17:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> In-Reply-To: <4C7A2782.5040009@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jung-uk Kim Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:17:45 -0000 on 29/08/2010 12:25 Andriy Gapon said the following: > The below patch is against sources in FreeBSD tree, it should be applied > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > on the desired architecture: > http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 12:23: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 EA1C010656D9 for ; Mon, 6 Sep 2010 12:23:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id C24018FC22 for ; Mon, 6 Sep 2010 12:23:27 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 3QGq1f0030QkzPwAEQPTzq; Mon, 06 Sep 2010 12:23:27 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.emeryville.ca.mail.comcast.net with comcast id 3QPS1f0023LrwQ28NQPS6g; Mon, 06 Sep 2010 12:23:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1C66A9B425; Mon, 6 Sep 2010 05:23:26 -0700 (PDT) Date: Mon, 6 Sep 2010 05:23:26 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906122325.GA78727@icarus.home.lan> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84DBE6.5010809@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 06 Sep 2010 12:41:57 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jung-uk Kim Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:23:28 -0000 On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: > on 29/08/2010 12:25 Andriy Gapon said the following: > > The below patch is against sources in FreeBSD tree, it should be applied > > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > > on the desired architecture: > > http://people.freebsd.org/~avg/intel-cpu-topo.diff > > I see that I am not getting as many testers as I expected, so I am going to commit > the patch. > > You still have a short while to either objectively object to the patch or to > voluntary test it :-) I would gladly assist in testing this, except there doesn't appear to be an authoritative statement that it will apply to RELENG_8; when I see WIP, I assume -CURRENT/HEAD only. Let me know, since all the systems I have are Intel multi-core. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 12:50: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 7F76310656CB for ; Mon, 6 Sep 2010 12:50:06 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFD08FC1A for ; Mon, 6 Sep 2010 12:50:06 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Osb9B-00048K-3d for freebsd-current@freebsd.org; Mon, 06 Sep 2010 13:50:05 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Osb9B-00016J-1B for freebsd-current@freebsd.org; Mon, 06 Sep 2010 13:50:05 +0100 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 o86Co4qw046461 for ; Mon, 6 Sep 2010 13:50:04 +0100 (BST) (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 o86Co4aU046460 for freebsd-current@freebsd.org; Mon, 6 Sep 2010 13:50:04 +0100 (BST) (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 Sep 2010 13:50:04 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:50:06 -0000 On sparc64 after updating to r212060, libz.so.5 came up as old library. I rebuit all ports to use libz.so.6 instead, but libchk still shows that Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat What did I do wrong that resulted in these 2 programs still linked against the old version of libz? many thanks 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 Sep 6 12:56: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 11D6F10656A7; Mon, 6 Sep 2010 12:56:06 +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 253BC8FC25; Mon, 6 Sep 2010 12:56:04 +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 PAA02386; Mon, 06 Sep 2010 15:56:01 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84E4E1.8010709@freebsd.org> Date: Mon, 06 Sep 2010 15:56:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> In-Reply-To: <20100906122325.GA78727@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:56:06 -0000 on 06/09/2010 15:23 Jeremy Chadwick said the following: > On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: >> on 29/08/2010 12:25 Andriy Gapon said the following: >>> The below patch is against sources in FreeBSD tree, it should be applied >>> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending >>> on the desired architecture: >>> http://people.freebsd.org/~avg/intel-cpu-topo.diff >> >> I see that I am not getting as many testers as I expected, so I am going to commit >> the patch. >> >> You still have a short while to either objectively object to the patch or to >> voluntary test it :-) > > I would gladly assist in testing this, except there doesn't appear to be > an authoritative statement that it will apply to RELENG_8; when I see > WIP, I assume -CURRENT/HEAD only. patch -C is much better than any statement :) > Let me know, since all the systems I have are Intel multi-core. Yes, the patch should be applicable to stable/8 without any issues. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:03:33 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 7B56710656A4 for ; Mon, 6 Sep 2010 13:03:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD578FC0A for ; Mon, 6 Sep 2010 13:03:32 +0000 (UTC) Received: by qyk31 with SMTP id 31so2451329qyk.13 for ; Mon, 06 Sep 2010 06:03:32 -0700 (PDT) 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=VwjFl/npv1XQ13571jm5yxpakhU8jfiFxZG9mTuzj5o=; b=PD2qFkx1vdP3llZhnsuvlaTRFCnV4YFWsMlJ6G2Ok59EsHXlil/tKum3yLBf3nQqUH gG5dUjXvgMcIUYhQU2+mzuEJrOxHCwZTDyBmciE+EGxxRO1/ATRki5b+iHG5KB85eV0g Bd4Y4N7HU/H+yKC+s96ZUcuxXCMzQjlbyxzko= 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=nkGCBmvNhOWGdKQ80YFQQrSSH5rIiN7zBX2UxcHT8TsRRXwlN9UM9W2eG89Pw8B9g4 WXPcATPbbtnYnZJFYC33bSuQhFiaCktH1sX6ibcpPtz7dP3b0QpVYfpn2eP1pg7WcrwR XXgWuVDprXdyEeA417j7pTqbqJU2CRXhcW/+o= MIME-Version: 1.0 Received: by 10.229.215.8 with SMTP id hc8mr3510144qcb.23.1283778211910; Mon, 06 Sep 2010 06:03:31 -0700 (PDT) Received: by 10.229.19.206 with HTTP; Mon, 6 Sep 2010 06:03:31 -0700 (PDT) In-Reply-To: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> References: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> Date: Mon, 6 Sep 2010 17:03:31 +0400 Message-ID: From: pluknet To: Anton Shterenlikht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:03:33 -0000 On 6 September 2010 16:50, Anton Shterenlikht wrote: > On sparc64 after updating to r212060, libz.so.5 came up > as old library. I rebuit all ports to use > libz.so.6 instead, but libchk still shows that > > Binaries that are linked with: /lib/libz.so.5 > =A0 =A0 =A0 =A0/usr/sbin/dtrace > =A0 =A0 =A0 =A0/usr/sbin/lockstat > > What did I do wrong that resulted in these 2 > programs still linked against the old version > of libz? > Hi, Anton. After r210693, these utilities are built for i386 and amd64 only. Thereby you have stale binaries installed from older sources. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:05:15 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 918FF10656C0 for ; Mon, 6 Sep 2010 13:05:15 +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 8912A8FC28 for ; Mon, 6 Sep 2010 13:05:14 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OsbNG-0003iu-LC; Mon, 06 Sep 2010 14:05:13 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OsbNG-0001ZG-Ax; Mon, 06 Sep 2010 14:04:38 +0100 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 o86D4bQH049640; Mon, 6 Sep 2010 14:04:38 +0100 (BST) (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 o86D4bn1049639; Mon, 6 Sep 2010 14:04:37 +0100 (BST) (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 Sep 2010 14:04:37 +0100 From: Anton Shterenlikht To: Pyun YongHyeon Message-ID: <20100906130437.GA46535@mech-cluster241.men.bris.ac.uk> References: <20100902100014.GA26562@mech-cluster241.men.bris.ac.uk> <20100902170316.GA28362@mech-cluster241.men.bris.ac.uk> <20100902183603.GD21940@michelle.cdnetworks.com> <20100903084204.GA35820@mech-cluster241.men.bris.ac.uk> <20100903182534.GM21940@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100903182534.GM21940@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: bge(4) problem on sparc64 between r204991M and r212097 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:05:15 -0000 On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote: > On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote: > > On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote: > > > On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote: > > > > On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote: > > > > > I just updated world and kernel from r204991M to r212097 on sparc64. > > > > > > > > > > Now I can't ping my gateway. If I boot kernel.old, then > > > > > the network works fine. As far as I could see mergemaster > > > > > didn't update any network files. > > > > > > > > > > Please advise > > > > > > > > > > In the meantime I'll try intermediate revisions. > > > > > > > > I narrowed down the problem to between r212050 and r212080. > > > > Will continue tomorrow. > > > > > > > > > > Thanks for reporting. There was a big change in r212061, so try > > > backing out that revision and see whether this makes differences > > > or not. > > > > yes, r212061 is the offending revision, r212060 works fine. > > Please let me know if you want any further information. > > Thanks for narrowing down guilty revision. Would you show me > verbose boot message? First here's diff between dmesg outputs from r212060 and r212061: 8c8 < FreeBSD 9.0-CURRENT #0 r212060: Fri Sep 3 09:06:59 BST 2010 --- > FreeBSD 9.0-CURRENT #0 r212061: Fri Sep 3 09:32:25 BST 2010 11c11 < Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc08ee000. --- > Preloaded elf kernel "/boot/kernel/kernel" at 0xc08ee000. 333,334c333,334 < ct_to_ts([2010-09-06 13:57:13]) = 1283781433.000000000 < rtc0: current time: 1283781433.000000000 --- > ct_to_ts([2010-09-06 13:51:20]) = 1283781080.000000000 > rtc0: current time: 1283781080.000000000 340c340 < uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 44 on isa0 --- > uart1: at port 0x2e8-0x2ef irq 44 on isa0 435c435 < ct_to_ts([2010-09-06 13:57:16]) = 1283781436.000000000 --- > ct_to_ts([2010-09-06 13:51:23]) = 1283781083.000000000 437d436 < bge0: link UP 439d437 < ts_to_ct(1283781463.000000000) = [2010-09-06 13:57:43] 442c440 < 2nd 0xfffff80001557600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 --- > 2nd 0xfffff8000155f400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 This is full dmesg from r212060, below that is r212061. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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 #0 r212060: Fri Sep 3 09:06:59 BST 2010 root@mech-anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc08ee000. real memory = 2147483648 (2048 MB) avail memory = 2079604736 (1983 MB) machine: SUNW,Sun-Blade-1500-S cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) mask=0x34 maxtl=5 maxwin=7 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: random: nfslock: pseudo-device mem: openfirm: nexus0: nexus0: mem 0x40000000000-0x40000000007 type memory-controller (no driver attached) pcib0: mem 0x4000f600000-0x4000f60afff,0x4000f410000-0x4000f41701f,0x7fe00000000-0x7fe000000ff,0x4000f780000-0x4000f78ffff irq 1970,1968,1969,1972,1953 on nexus0 pcib0: Tomatillo, version 4, IGN 0x1e, bus A, 33MHz Timecounter "pcib0" frequency 167000000 Hz quality -100 pcib0: DVMA map: 0xc0000000 to 0xdfffffff 65536 entries pcib0: PROM IOTSB size: 1 (2048 entries) pcib0: adding PROM IOTSB slot 0 (kernel slot 63488) TTE: 0x800000023fdc0012 pcib0: adding PROM IOTSB slot 1 (kernel slot 63489) TTE: 0x800000023fdc2012 pcib0: adding PROM IOTSB slot 2 (kernel slot 63490) TTE: 0x800000023fdc4012 pcib0: adding PROM IOTSB slot 3 (kernel slot 63491) TTE: 0x800000023fdc6012 pcib0: adding PROM IOTSB slot 4 (kernel slot 63492) TTE: 0x800000023fdc8012 pcib0: adding PROM IOTSB slot 5 (kernel slot 63493) TTE: 0x800000023fdca012 pcib0: adding PROM IOTSB slot 6 (kernel slot 63494) TTE: 0x800000023fdcc012 pcib0: adding PROM IOTSB slot 7 (kernel slot 63495) TTE: 0x800000023fdce012 pcib0: adding PROM IOTSB slot 8 (kernel slot 63496) TTE: 0x800000023fdd0012 pcib0: adding PROM IOTSB slot 9 (kernel slot 63497) TTE: 0x800000023fdd2012 pcib0: adding PROM IOTSB slot 10 (kernel slot 63498) TTE: 0x800000023fdd4012 pcib0: adding PROM IOTSB slot 11 (kernel slot 63499) TTE: 0x800000023fdd6012 pcib0: adding PROM IOTSB slot 12 (kernel slot 63500) TTE: 0x800000023fdd8012 pcib0: adding PROM IOTSB slot 13 (kernel slot 63501) TTE: 0x800000023fdda012 pcib0: adding PROM IOTSB slot 14 (kernel slot 63502) TTE: 0x800000023fddc012 pcib0: adding PROM IOTSB slot 15 (kernel slot 63503) TTE: 0x800000023fdde012 pcib0: adding PROM IOTSB slot 16 (kernel slot 63504) TTE: 0x800000023fde0012 pcib0: adding PROM IOTSB slot 17 (kernel slot 63505) TTE: 0x800000023fde2012 pcib0: adding PROM IOTSB slot 18 (kernel slot 63506) TTE: 0x800000023fde4012 pcib0: adding PROM IOTSB slot 19 (kernel slot 63507) TTE: 0x800000023fde6012 pcib0: adding PROM IOTSB slot 20 (kernel slot 63508) TTE: 0x800000023fde8012 pcib0: adding PROM IOTSB slot 21 (kernel slot 63509) TTE: 0x800000023fdea012 pcib0: adding PROM IOTSB slot 22 (kernel slot 63510) TTE: 0x800000023fdec012 pcib0: adding PROM IOTSB slot 23 (kernel slot 63511) TTE: 0x800000023fdee012 pcib0: adding PROM IOTSB slot 24 (kernel slot 63512) TTE: 0x800000023fdf0012 pcib0: adding PROM IOTSB slot 25 (kernel slot 63513) TTE: 0x800000023fdf2012 pcib0: adding PROM IOTSB slot 26 (kernel slot 63514) TTE: 0x800000023fdf4012 pcib0: adding PROM IOTSB slot 27 (kernel slot 63515) TTE: 0x800000023fdf6012 pcib0: adding PROM IOTSB slot 28 (kernel slot 63516) TTE: 0x800000023fdf8012 pcib0: adding PROM IOTSB slot 29 (kernel slot 63517) TTE: 0x800000023fdfa012 pcib0: adding PROM IOTSB slot 30 (kernel slot 63518) TTE: 0x800000023fdfc012 pcib0: adding PROM IOTSB slot 31 (kernel slot 63519) TTE: 0x800000023fdfe012 pcib0: adding PROM IOTSB slot 32 (kernel slot 63520) TTE: 0x800000023fe00012 pcib0: adding PROM IOTSB slot 33 (kernel slot 63521) TTE: 0x800000023fe02012 pcib0: adding PROM IOTSB slot 34 (kernel slot 63522) TTE: 0x800000023fe04012 pcib0: adding PROM IOTSB slot 35 (kernel slot 63523) TTE: 0x800000023fe06012 pcib0: adding PROM IOTSB slot 36 (kernel slot 63524) TTE: 0x800000023fe08012 pcib0: adding PROM IOTSB slot 37 (kernel slot 63525) TTE: 0x800000023fe0a012 pcib0: adding PROM IOTSB slot 38 (kernel slot 63526) TTE: 0x800000023fe0c012 pcib0: adding PROM IOTSB slot 39 (kernel slot 63527) TTE: 0x800000023fe0e012 pcib0: adding PROM IOTSB slot 40 (kernel slot 63528) TTE: 0x800000023fe10012 pcib0: adding PROM IOTSB slot 41 (kernel slot 63529) TTE: 0x800000023fe12012 pcib0: adding PROM IOTSB slot 42 (kernel slot 63530) TTE: 0x800000023fe14012 pcib0: adding PROM IOTSB slot 43 (kernel slot 63531) TTE: 0x800000023fe16012 pcib0: adding PROM IOTSB slot 44 (kernel slot 63532) TTE: 0x800000023fe18012 pcib0: adding PROM IOTSB slot 45 (kernel slot 63533) TTE: 0x800000023fe1a012 pcib0: adding PROM IOTSB slot 46 (kernel slot 63534) TTE: 0x800000023fe1c012 pcib0: adding PROM IOTSB slot 47 (kernel slot 63535) TTE: 0x800000023fe1e012 pcib0: adding PROM IOTSB slot 48 (kernel slot 63536) TTE: 0x800000023fe20012 pcib0: adding PROM IOTSB slot 49 (kernel slot 63537) TTE: 0x800000023fe22012 pcib0: adding PROM IOTSB slot 50 (kernel slot 63538) TTE: 0x800000023fe24012 pcib0: adding PROM IOTSB slot 51 (kernel slot 63539) TTE: 0x800000023fe26012 pcib0: adding PROM IOTSB slot 52 (kernel slot 63540) TTE: 0x800000023fe28012 pcib0: adding PROM IOTSB slot 53 (kernel slot 63541) TTE: 0x800000023fe2a012 pcib0: adding PROM IOTSB slot 54 (kernel slot 63542) TTE: 0x800000023fe2c012 pcib0: adding PROM IOTSB slot 55 (kernel slot 63543) TTE: 0x800000023fe2e012 pcib0: adding PROM IOTSB slot 56 (kernel slot 63544) TTE: 0x800000023fe30012 pcib0: adding PROM IOTSB slot 57 (kernel slot 63545) TTE: 0x800000023fe32012 pcib0: adding PROM IOTSB slot 58 (kernel slot 63546) TTE: 0x800000023fe34012 pcib0: adding PROM IOTSB slot 59 (kernel slot 63547) TTE: 0x800000023fe36012 pcib0: adding PROM IOTSB slot 60 (kernel slot 63548) TTE: 0x800000023fe38012 pcib0: adding PROM IOTSB slot 61 (kernel slot 63549) TTE: 0x800000023fe3a012 pcib0: adding PROM IOTSB slot 62 (kernel slot 63550) TTE: 0x800000023fe3c012 pcib0: adding PROM IOTSB slot 63 (kernel slot 63551) TTE: 0x800000023fe3e012 pcib0: adding PROM IOTSB slot 64 (kernel slot 63552) TTE: 0x800000023fe40012 pcib0: adding PROM IOTSB slot 65 (kernel slot 63553) TTE: 0x800000023fe42012 pcib0: adding PROM IOTSB slot 66 (kernel slot 63554) TTE: 0x800000023fe44012 pcib0: adding PROM IOTSB slot 67 (kernel slot 63555) TTE: 0x800000023fe46012 pcib0: adding PROM IOTSB slot 68 (kernel slot 63556) TTE: 0x800000023fe48012 pcib0: adding PROM IOTSB slot 69 (kernel slot 63557) TTE: 0x800000023fe4a012 pcib0: adding PROM IOTSB slot 70 (kernel slot 63558) TTE: 0x800000023fe4c012 pcib0: adding PROM IOTSB slot 71 (kernel slot 63559) TTE: 0x800000023fe4e012 pcib0: adding PROM IOTSB slot 72 (kernel slot 63560) TTE: 0x800000023fe50012 pcib0: adding PROM IOTSB slot 73 (kernel slot 63561) TTE: 0x800000023fe52012 pcib0: adding PROM IOTSB slot 74 (kernel slot 63562) TTE: 0x800000023fe54012 pcib0: adding PROM IOTSB slot 75 (kernel slot 63563) TTE: 0x800000023fe56012 pcib0: adding PROM IOTSB slot 76 (kernel slot 63564) TTE: 0x800000023fe58012 pcib0: adding PROM IOTSB slot 77 (kernel slot 63565) TTE: 0x800000023fe5a012 pcib0: adding PROM IOTSB slot 78 (kernel slot 63566) TTE: 0x800000023fe5c012 pcib0: adding PROM IOTSB slot 79 (kernel slot 63567) TTE: 0x800000023fe5e012 pcib0: adding PROM IOTSB slot 80 (kernel slot 63568) TTE: 0x800000023fe60012 pcib0: adding PROM IOTSB slot 81 (kernel slot 63569) TTE: 0x800000023fe62012 pcib0: adding PROM IOTSB slot 82 (kernel slot 63570) TTE: 0x800000023fe64012 pcib0: adding PROM IOTSB slot 83 (kernel slot 63571) TTE: 0x800000023fe66012 pcib0: adding PROM IOTSB slot 84 (kernel slot 63572) TTE: 0x800000023fe68012 pcib0: adding PROM IOTSB slot 85 (kernel slot 63573) TTE: 0x800000023fe6a012 pcib0: adding PROM IOTSB slot 86 (kernel slot 63574) TTE: 0x800000023fe6c012 pcib0: adding PROM IOTSB slot 87 (kernel slot 63575) TTE: 0x800000023fe6e012 pcib0: adding PROM IOTSB slot 88 (kernel slot 63576) TTE: 0x800000023fe70012 pcib0: adding PROM IOTSB slot 89 (kernel slot 63577) TTE: 0x800000023fe72012 pcib0: adding PROM IOTSB slot 90 (kernel slot 63578) TTE: 0x800000023fe74012 pcib0: adding PROM IOTSB slot 91 (kernel slot 63579) TTE: 0x800000023fe76012 pcib0: adding PROM IOTSB slot 92 (kernel slot 63580) TTE: 0x800000023fe78012 pcib0: adding PROM IOTSB slot 93 (kernel slot 63581) TTE: 0x800000023fe7a012 pcib0: adding PROM IOTSB slot 94 (kernel slot 63582) TTE: 0x800000023fe7c012 pcib0: adding PROM IOTSB slot 95 (kernel slot 63583) TTE: 0x800000023fe7e012 pcib0: adding PROM IOTSB slot 96 (kernel slot 63584) TTE: 0x800000023fe80012 pcib0: adding PROM IOTSB slot 97 (kernel slot 63585) TTE: 0x800000023fe82012 pcib0: adding PROM IOTSB slot 98 (kernel slot 63586) TTE: 0x800000023fe84012 pcib0: adding PROM IOTSB slot 99 (kernel slot 63587) TTE: 0x800000023fe86012 pcib0: adding PROM IOTSB slot 100 (kernel slot 63588) TTE: 0x800000023fe88012 pcib0: adding PROM IOTSB slot 101 (kernel slot 63589) TTE: 0x800000023fe8a012 pcib0: adding PROM IOTSB slot 102 (kernel slot 63590) TTE: 0x800000023fe8c012 pcib0: adding PROM IOTSB slot 103 (kernel slot 63591) TTE: 0x800000023fe8e012 pcib0: adding PROM IOTSB slot 104 (kernel slot 63592) TTE: 0x800000023fe90012 pcib0: adding PROM IOTSB slot 105 (kernel slot 63593) TTE: 0x800000023fe92012 pcib0: adding PROM IOTSB slot 106 (kernel slot 63594) TTE: 0x800000023fe94012 pcib0: adding PROM IOTSB slot 107 (kernel slot 63595) TTE: 0x800000023fe96012 pcib0: adding PROM IOTSB slot 108 (kernel slot 63596) TTE: 0x800000023fe98012 pcib0: adding PROM IOTSB slot 109 (kernel slot 63597) TTE: 0x800000023fe9a012 pcib0: adding PROM IOTSB slot 110 (kernel slot 63598) TTE: 0x800000023fe9c012 pcib0: adding PROM IOTSB slot 111 (kernel slot 63599) TTE: 0x800000023fe9e012 pcib0: adding PROM IOTSB slot 112 (kernel slot 63600) TTE: 0x800000023fea0012 pcib0: adding PROM IOTSB slot 113 (kernel slot 63601) TTE: 0x800000023fea2012 pcib0: adding PROM IOTSB slot 114 (kernel slot 63602) TTE: 0x800000023fea4012 pcib0: adding PROM IOTSB slot 115 (kernel slot 63603) TTE: 0x800000023fea6012 pcib0: adding PROM IOTSB slot 116 (kernel slot 63604) TTE: 0x800000023fea8012 pcib0: adding PROM IOTSB slot 117 (kernel slot 63605) TTE: 0x800000023feaa012 pcib0: adding PROM IOTSB slot 118 (kernel slot 63606) TTE: 0x800000023feac012 pcib0: adding PROM IOTSB slot 119 (kernel slot 63607) TTE: 0x800000023feae012 pcib0: adding PROM IOTSB slot 120 (kernel slot 63608) TTE: 0x800000023feb0012 pcib0: adding PROM IOTSB slot 121 (kernel slot 63609) TTE: 0x800000023feb2012 pcib0: adding PROM IOTSB slot 122 (kernel slot 63610) TTE: 0x800000023feb4012 pcib0: adding PROM IOTSB slot 123 (kernel slot 63611) TTE: 0x800000023feb6012 pcib0: adding PROM IOTSB slot 124 (kernel slot 63612) TTE: 0x800000023feb8012 pcib0: adding PROM IOTSB slot 125 (kernel slot 63613) TTE: 0x800000023feba012 pcib0: adding PROM IOTSB slot 126 (kernel slot 63614) TTE: 0x800000023febc012 pcib0: adding PROM IOTSB slot 127 (kernel slot 63615) TTE: 0x800000023febe012 pcib0: bus range 0 to 0; PCI bus 0 initalizing intr_countp pcib0: [FILTER] pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x108e, dev=0xa801, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x1533, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x000f, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D3 current D0 found-> vendor=0x10b9, dev=0x7101, revid=0x00 domain=0, bus=0, slot=6, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x5451, revid=0x02 domain=0, bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x900, size 8, port disabled map[14]: type Memory, range 32, base 0x100000, size 12, memory disabled found-> vendor=0x10b9, dev=0x5237, revid=0x03 domain=0, bus=0, slot=10, func=0 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0x1000000, size 12, memory disabled found-> vendor=0x10b9, dev=0x5237, revid=0x03 domain=0, bus=0, slot=11, func=0 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0x2000000, size 12, enabled found-> vendor=0x10b9, dev=0x5229, revid=0xc4 domain=0, bus=0, slot=13, func=0 class=01-01-ff, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xa00, size 3, port disabled map[14]: type I/O Port, range 32, base 0xa18, size 2, enabled map[18]: type I/O Port, range 32, base 0xa10, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa08, size 2, enabled map[20]: type I/O Port, range 32, base 0xa20, size 4, enabled found-> vendor=0x1002, dev=0x4752, revid=0x27 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0082, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x3000000, size 24, enabled map[14]: type I/O Port, range 32, base 0xb00, size 8, port disabled map[18]: type Memory, range 32, base 0x102000, size 12, enabled isab0: at device 7.0 on pci0 pcib0: could not route pin 1 for device 7.0 isa0: could not map ISA interrupt 1 for node 0xf0097238: parallel isa0: on isab0 pci0: at device 6.0 (no driver attached) pcm0: port 0x900-0x9ff mem 0x100000-0x100fff at device 8.0 on pci0 pcm0: pcm0: Codec features headphone, 6 bit master volume, Analog Devices Phat Stereo pcm0: Primary codec extended features variable rate PCM pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: M1533 0x7e: 0x81 -> 0x81 pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap c0000000, 10000; 0xc0c86000 -> c0000000 pcm0: sndbuf_setmap c0012000, 10000; 0xc0ca6000 -> c0012000 ohci0: mem 0x1000000-0x1000fff at device 10.0 on pci0 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x2000000-0x2000fff at device 11.0 on pci0 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 atapci0: port 0xa00-0xa07,0xa18-0xa1b,0xa10-0xa17,0xa08-0xa0b,0xa20-0xa2f at device 13.0 on pci0 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata2: reset tp1 mask=03 ostat0=50 ostat1=50 ata2: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 ata2: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=50 devices=0x3 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: reset tp1 mask=03 ostat0=00 ostat1=01 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=00 stat1=01 devices=0x10000 ata3: [MPSAFE] ata3: [ITHREAD] machfb0: port 0xb00-0xbff mem 0x3000000-0x3ffffff,0x102000-0x102fff at device 2.0 on pci0 machfb0: console machfb0: 16 MB aperture at 0xfddcc000 not swapped machfb0: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP machfb0: resolution 1280x1024 at 8 bpp jbusppm0: mem 0x4000f000000-0x4000f000007,0x4000f410050-0x4000f41005f on nexus0 jbusppm0: master I/O bridge jbusppm0: running at full speed pcib1: mem 0x4000ff00000-0x4000ff0afff,0x4000fc10000-0x4000fc1701f,0x7f600000000-0x7f6000000ff,0x4000ff80000-0x4000ff8ffff irq 2035,2032,2033,2036,2019 on nexus0 pcib1: Tomatillo, version 4, IGN 0x1f, bus B, 66MHz pcib1: DVMA map: 0xc0000000 to 0xdfffffff 65536 entries pcib1: PROM IOTSB size: 1 (2048 entries) pcib1: bus range 0 to 0; PCI bus 0 pcib1: [FILTER] pcib1: [FILTER] pcib1: [FILTER] pcib1: [FILTER] pci1: on pcib1 pci1: domain=1, physical bus=0 found-> vendor=0x108e, dev=0xa801, revid=0x00 domain=1, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x14e4, dev=0x1647, revid=0x00 domain=1, bus=0, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0x200000, size 16, memory disabled bge0: mem 0x200000-0x20ffff at device 2.0 on pci1 bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0016, rev. 2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:03:ba:d9:a0:07 bge0: [MPSAFE] bge0: [ITHREAD] nexus0: mem 0x4000fc64000-0x4000fc6400f type i2c (no driver attached) syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x300> syscons0: fb0, terminal emulator: scteken (teken terminal) (null) failed to probe at iomem 0xf0000000-0xf00fffff on isa0 rtc0: at port 0x70-0x71 on isa0 rtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ct_to_ts([2010-09-06 13:57:13]) = 1283781433.000000000 rtc0: current time: 1283781433.000000000 (null) failed to probe at port 0x320-0x321 irq 46 on isa0 (null) failed to probe at port 0x800-0x82f irq 32 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 44 on isa0 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 44 on isa0 uart1: [FILTER] uart1: fast interrupt (null) failed to probe at port 0-0xffff on isa0 ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: at port 0x378-0x37f,0-0x4ff drq 1 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/1 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Polled port procfs registered Timecounter "tick" frequency 1503000000 Hz quality 1000 Timecounter "stick" frequency 12000000 Hz quality 1000 Event timer "tick" frequency 1503000000 Hz quality 1000 Starting kernel event timers: tick @ 2000Hz, NONE @ 0Hz Timecounters tick every 1.000 msec lo0: bpf attached ata2: Identifying devices: 00000003 ata2: New devices: 00000003 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ata2-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting UDMA100 ad0: 76319MB at ata2-master UDMA100 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad1: setting UDMA100 ad1: 76319MB at ata2-slave UDMA100 ad1: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue ata3: Identifying devices: 00010000 ata3: New devices: 00010000 GEOM: ad0: adding VTOC8 information. GEOM: new disk ad1 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting UDMA33 acd0: CDRW drive at ata3 as master acd0: read 8958KB/s (8958KB/s) write 8958KB/s (8958KB/s), 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XY] coordinates ID=0 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata3:0:0:0): SCSI status error (probe0:ata3:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (probe0:ata3:0:0:0): Error 22, Unretryable error (probe0:ata3:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata3:0:0:0): SCSI status error (probe0:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (probe0:ata3:0:0:0): Error 6, Unretryable error pass0 at ata3 bus 0 scbus1 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 WARNING: WITNESS option enabled, expect reduced performance. (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata3:0:0:0): Error 6, Unretryable error cd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata3:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus1 ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 kbd0: ukbd0, generic (0), config:0x0, flags:0x1d0000 Trying to mount root from ufs:/dev/ad0a ct_to_ts([2010-09-06 13:57:16]) = 1283781436.000000000 start_init: trying /sbin/init bge0: link UP bge0: link state changed to UP ts_to_ct(1283781463.000000000) = [2010-09-06 13:57:43] On r212061 (not working): GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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 #0 r212061: Fri Sep 3 09:32:25 BST 2010 root@mech-anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc08ee000. real memory = 2147483648 (2048 MB) avail memory = 2079604736 (1983 MB) machine: SUNW,Sun-Blade-1500-S cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) mask=0x34 maxtl=5 maxwin=7 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: random: nfslock: pseudo-device mem: openfirm: nexus0: nexus0: mem 0x40000000000-0x40000000007 type memory-controller (no driver attached) pcib0: mem 0x4000f600000-0x4000f60afff,0x4000f410000-0x4000f41701f,0x7fe00000000-0x7fe000000ff,0x4000f780000-0x4000f78ffff irq 1970,1968,1969,1972,1953 on nexus0 pcib0: Tomatillo, version 4, IGN 0x1e, bus A, 33MHz Timecounter "pcib0" frequency 167000000 Hz quality -100 pcib0: DVMA map: 0xc0000000 to 0xdfffffff 65536 entries pcib0: PROM IOTSB size: 1 (2048 entries) pcib0: adding PROM IOTSB slot 0 (kernel slot 63488) TTE: 0x800000023fdc0012 pcib0: adding PROM IOTSB slot 1 (kernel slot 63489) TTE: 0x800000023fdc2012 pcib0: adding PROM IOTSB slot 2 (kernel slot 63490) TTE: 0x800000023fdc4012 pcib0: adding PROM IOTSB slot 3 (kernel slot 63491) TTE: 0x800000023fdc6012 pcib0: adding PROM IOTSB slot 4 (kernel slot 63492) TTE: 0x800000023fdc8012 pcib0: adding PROM IOTSB slot 5 (kernel slot 63493) TTE: 0x800000023fdca012 pcib0: adding PROM IOTSB slot 6 (kernel slot 63494) TTE: 0x800000023fdcc012 pcib0: adding PROM IOTSB slot 7 (kernel slot 63495) TTE: 0x800000023fdce012 pcib0: adding PROM IOTSB slot 8 (kernel slot 63496) TTE: 0x800000023fdd0012 pcib0: adding PROM IOTSB slot 9 (kernel slot 63497) TTE: 0x800000023fdd2012 pcib0: adding PROM IOTSB slot 10 (kernel slot 63498) TTE: 0x800000023fdd4012 pcib0: adding PROM IOTSB slot 11 (kernel slot 63499) TTE: 0x800000023fdd6012 pcib0: adding PROM IOTSB slot 12 (kernel slot 63500) TTE: 0x800000023fdd8012 pcib0: adding PROM IOTSB slot 13 (kernel slot 63501) TTE: 0x800000023fdda012 pcib0: adding PROM IOTSB slot 14 (kernel slot 63502) TTE: 0x800000023fddc012 pcib0: adding PROM IOTSB slot 15 (kernel slot 63503) TTE: 0x800000023fdde012 pcib0: adding PROM IOTSB slot 16 (kernel slot 63504) TTE: 0x800000023fde0012 pcib0: adding PROM IOTSB slot 17 (kernel slot 63505) TTE: 0x800000023fde2012 pcib0: adding PROM IOTSB slot 18 (kernel slot 63506) TTE: 0x800000023fde4012 pcib0: adding PROM IOTSB slot 19 (kernel slot 63507) TTE: 0x800000023fde6012 pcib0: adding PROM IOTSB slot 20 (kernel slot 63508) TTE: 0x800000023fde8012 pcib0: adding PROM IOTSB slot 21 (kernel slot 63509) TTE: 0x800000023fdea012 pcib0: adding PROM IOTSB slot 22 (kernel slot 63510) TTE: 0x800000023fdec012 pcib0: adding PROM IOTSB slot 23 (kernel slot 63511) TTE: 0x800000023fdee012 pcib0: adding PROM IOTSB slot 24 (kernel slot 63512) TTE: 0x800000023fdf0012 pcib0: adding PROM IOTSB slot 25 (kernel slot 63513) TTE: 0x800000023fdf2012 pcib0: adding PROM IOTSB slot 26 (kernel slot 63514) TTE: 0x800000023fdf4012 pcib0: adding PROM IOTSB slot 27 (kernel slot 63515) TTE: 0x800000023fdf6012 pcib0: adding PROM IOTSB slot 28 (kernel slot 63516) TTE: 0x800000023fdf8012 pcib0: adding PROM IOTSB slot 29 (kernel slot 63517) TTE: 0x800000023fdfa012 pcib0: adding PROM IOTSB slot 30 (kernel slot 63518) TTE: 0x800000023fdfc012 pcib0: adding PROM IOTSB slot 31 (kernel slot 63519) TTE: 0x800000023fdfe012 pcib0: adding PROM IOTSB slot 32 (kernel slot 63520) TTE: 0x800000023fe00012 pcib0: adding PROM IOTSB slot 33 (kernel slot 63521) TTE: 0x800000023fe02012 pcib0: adding PROM IOTSB slot 34 (kernel slot 63522) TTE: 0x800000023fe04012 pcib0: adding PROM IOTSB slot 35 (kernel slot 63523) TTE: 0x800000023fe06012 pcib0: adding PROM IOTSB slot 36 (kernel slot 63524) TTE: 0x800000023fe08012 pcib0: adding PROM IOTSB slot 37 (kernel slot 63525) TTE: 0x800000023fe0a012 pcib0: adding PROM IOTSB slot 38 (kernel slot 63526) TTE: 0x800000023fe0c012 pcib0: adding PROM IOTSB slot 39 (kernel slot 63527) TTE: 0x800000023fe0e012 pcib0: adding PROM IOTSB slot 40 (kernel slot 63528) TTE: 0x800000023fe10012 pcib0: adding PROM IOTSB slot 41 (kernel slot 63529) TTE: 0x800000023fe12012 pcib0: adding PROM IOTSB slot 42 (kernel slot 63530) TTE: 0x800000023fe14012 pcib0: adding PROM IOTSB slot 43 (kernel slot 63531) TTE: 0x800000023fe16012 pcib0: adding PROM IOTSB slot 44 (kernel slot 63532) TTE: 0x800000023fe18012 pcib0: adding PROM IOTSB slot 45 (kernel slot 63533) TTE: 0x800000023fe1a012 pcib0: adding PROM IOTSB slot 46 (kernel slot 63534) TTE: 0x800000023fe1c012 pcib0: adding PROM IOTSB slot 47 (kernel slot 63535) TTE: 0x800000023fe1e012 pcib0: adding PROM IOTSB slot 48 (kernel slot 63536) TTE: 0x800000023fe20012 pcib0: adding PROM IOTSB slot 49 (kernel slot 63537) TTE: 0x800000023fe22012 pcib0: adding PROM IOTSB slot 50 (kernel slot 63538) TTE: 0x800000023fe24012 pcib0: adding PROM IOTSB slot 51 (kernel slot 63539) TTE: 0x800000023fe26012 pcib0: adding PROM IOTSB slot 52 (kernel slot 63540) TTE: 0x800000023fe28012 pcib0: adding PROM IOTSB slot 53 (kernel slot 63541) TTE: 0x800000023fe2a012 pcib0: adding PROM IOTSB slot 54 (kernel slot 63542) TTE: 0x800000023fe2c012 pcib0: adding PROM IOTSB slot 55 (kernel slot 63543) TTE: 0x800000023fe2e012 pcib0: adding PROM IOTSB slot 56 (kernel slot 63544) TTE: 0x800000023fe30012 pcib0: adding PROM IOTSB slot 57 (kernel slot 63545) TTE: 0x800000023fe32012 pcib0: adding PROM IOTSB slot 58 (kernel slot 63546) TTE: 0x800000023fe34012 pcib0: adding PROM IOTSB slot 59 (kernel slot 63547) TTE: 0x800000023fe36012 pcib0: adding PROM IOTSB slot 60 (kernel slot 63548) TTE: 0x800000023fe38012 pcib0: adding PROM IOTSB slot 61 (kernel slot 63549) TTE: 0x800000023fe3a012 pcib0: adding PROM IOTSB slot 62 (kernel slot 63550) TTE: 0x800000023fe3c012 pcib0: adding PROM IOTSB slot 63 (kernel slot 63551) TTE: 0x800000023fe3e012 pcib0: adding PROM IOTSB slot 64 (kernel slot 63552) TTE: 0x800000023fe40012 pcib0: adding PROM IOTSB slot 65 (kernel slot 63553) TTE: 0x800000023fe42012 pcib0: adding PROM IOTSB slot 66 (kernel slot 63554) TTE: 0x800000023fe44012 pcib0: adding PROM IOTSB slot 67 (kernel slot 63555) TTE: 0x800000023fe46012 pcib0: adding PROM IOTSB slot 68 (kernel slot 63556) TTE: 0x800000023fe48012 pcib0: adding PROM IOTSB slot 69 (kernel slot 63557) TTE: 0x800000023fe4a012 pcib0: adding PROM IOTSB slot 70 (kernel slot 63558) TTE: 0x800000023fe4c012 pcib0: adding PROM IOTSB slot 71 (kernel slot 63559) TTE: 0x800000023fe4e012 pcib0: adding PROM IOTSB slot 72 (kernel slot 63560) TTE: 0x800000023fe50012 pcib0: adding PROM IOTSB slot 73 (kernel slot 63561) TTE: 0x800000023fe52012 pcib0: adding PROM IOTSB slot 74 (kernel slot 63562) TTE: 0x800000023fe54012 pcib0: adding PROM IOTSB slot 75 (kernel slot 63563) TTE: 0x800000023fe56012 pcib0: adding PROM IOTSB slot 76 (kernel slot 63564) TTE: 0x800000023fe58012 pcib0: adding PROM IOTSB slot 77 (kernel slot 63565) TTE: 0x800000023fe5a012 pcib0: adding PROM IOTSB slot 78 (kernel slot 63566) TTE: 0x800000023fe5c012 pcib0: adding PROM IOTSB slot 79 (kernel slot 63567) TTE: 0x800000023fe5e012 pcib0: adding PROM IOTSB slot 80 (kernel slot 63568) TTE: 0x800000023fe60012 pcib0: adding PROM IOTSB slot 81 (kernel slot 63569) TTE: 0x800000023fe62012 pcib0: adding PROM IOTSB slot 82 (kernel slot 63570) TTE: 0x800000023fe64012 pcib0: adding PROM IOTSB slot 83 (kernel slot 63571) TTE: 0x800000023fe66012 pcib0: adding PROM IOTSB slot 84 (kernel slot 63572) TTE: 0x800000023fe68012 pcib0: adding PROM IOTSB slot 85 (kernel slot 63573) TTE: 0x800000023fe6a012 pcib0: adding PROM IOTSB slot 86 (kernel slot 63574) TTE: 0x800000023fe6c012 pcib0: adding PROM IOTSB slot 87 (kernel slot 63575) TTE: 0x800000023fe6e012 pcib0: adding PROM IOTSB slot 88 (kernel slot 63576) TTE: 0x800000023fe70012 pcib0: adding PROM IOTSB slot 89 (kernel slot 63577) TTE: 0x800000023fe72012 pcib0: adding PROM IOTSB slot 90 (kernel slot 63578) TTE: 0x800000023fe74012 pcib0: adding PROM IOTSB slot 91 (kernel slot 63579) TTE: 0x800000023fe76012 pcib0: adding PROM IOTSB slot 92 (kernel slot 63580) TTE: 0x800000023fe78012 pcib0: adding PROM IOTSB slot 93 (kernel slot 63581) TTE: 0x800000023fe7a012 pcib0: adding PROM IOTSB slot 94 (kernel slot 63582) TTE: 0x800000023fe7c012 pcib0: adding PROM IOTSB slot 95 (kernel slot 63583) TTE: 0x800000023fe7e012 pcib0: adding PROM IOTSB slot 96 (kernel slot 63584) TTE: 0x800000023fe80012 pcib0: adding PROM IOTSB slot 97 (kernel slot 63585) TTE: 0x800000023fe82012 pcib0: adding PROM IOTSB slot 98 (kernel slot 63586) TTE: 0x800000023fe84012 pcib0: adding PROM IOTSB slot 99 (kernel slot 63587) TTE: 0x800000023fe86012 pcib0: adding PROM IOTSB slot 100 (kernel slot 63588) TTE: 0x800000023fe88012 pcib0: adding PROM IOTSB slot 101 (kernel slot 63589) TTE: 0x800000023fe8a012 pcib0: adding PROM IOTSB slot 102 (kernel slot 63590) TTE: 0x800000023fe8c012 pcib0: adding PROM IOTSB slot 103 (kernel slot 63591) TTE: 0x800000023fe8e012 pcib0: adding PROM IOTSB slot 104 (kernel slot 63592) TTE: 0x800000023fe90012 pcib0: adding PROM IOTSB slot 105 (kernel slot 63593) TTE: 0x800000023fe92012 pcib0: adding PROM IOTSB slot 106 (kernel slot 63594) TTE: 0x800000023fe94012 pcib0: adding PROM IOTSB slot 107 (kernel slot 63595) TTE: 0x800000023fe96012 pcib0: adding PROM IOTSB slot 108 (kernel slot 63596) TTE: 0x800000023fe98012 pcib0: adding PROM IOTSB slot 109 (kernel slot 63597) TTE: 0x800000023fe9a012 pcib0: adding PROM IOTSB slot 110 (kernel slot 63598) TTE: 0x800000023fe9c012 pcib0: adding PROM IOTSB slot 111 (kernel slot 63599) TTE: 0x800000023fe9e012 pcib0: adding PROM IOTSB slot 112 (kernel slot 63600) TTE: 0x800000023fea0012 pcib0: adding PROM IOTSB slot 113 (kernel slot 63601) TTE: 0x800000023fea2012 pcib0: adding PROM IOTSB slot 114 (kernel slot 63602) TTE: 0x800000023fea4012 pcib0: adding PROM IOTSB slot 115 (kernel slot 63603) TTE: 0x800000023fea6012 pcib0: adding PROM IOTSB slot 116 (kernel slot 63604) TTE: 0x800000023fea8012 pcib0: adding PROM IOTSB slot 117 (kernel slot 63605) TTE: 0x800000023feaa012 pcib0: adding PROM IOTSB slot 118 (kernel slot 63606) TTE: 0x800000023feac012 pcib0: adding PROM IOTSB slot 119 (kernel slot 63607) TTE: 0x800000023feae012 pcib0: adding PROM IOTSB slot 120 (kernel slot 63608) TTE: 0x800000023feb0012 pcib0: adding PROM IOTSB slot 121 (kernel slot 63609) TTE: 0x800000023feb2012 pcib0: adding PROM IOTSB slot 122 (kernel slot 63610) TTE: 0x800000023feb4012 pcib0: adding PROM IOTSB slot 123 (kernel slot 63611) TTE: 0x800000023feb6012 pcib0: adding PROM IOTSB slot 124 (kernel slot 63612) TTE: 0x800000023feb8012 pcib0: adding PROM IOTSB slot 125 (kernel slot 63613) TTE: 0x800000023feba012 pcib0: adding PROM IOTSB slot 126 (kernel slot 63614) TTE: 0x800000023febc012 pcib0: adding PROM IOTSB slot 127 (kernel slot 63615) TTE: 0x800000023febe012 pcib0: bus range 0 to 0; PCI bus 0 initalizing intr_countp pcib0: [FILTER] pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x108e, dev=0xa801, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x1533, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x000f, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D3 current D0 found-> vendor=0x10b9, dev=0x7101, revid=0x00 domain=0, bus=0, slot=6, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x5451, revid=0x02 domain=0, bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x900, size 8, port disabled map[14]: type Memory, range 32, base 0x100000, size 12, memory disabled found-> vendor=0x10b9, dev=0x5237, revid=0x03 domain=0, bus=0, slot=10, func=0 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0x1000000, size 12, memory disabled found-> vendor=0x10b9, dev=0x5237, revid=0x03 domain=0, bus=0, slot=11, func=0 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0x2000000, size 12, enabled found-> vendor=0x10b9, dev=0x5229, revid=0xc4 domain=0, bus=0, slot=13, func=0 class=01-01-ff, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xa00, size 3, port disabled map[14]: type I/O Port, range 32, base 0xa18, size 2, enabled map[18]: type I/O Port, range 32, base 0xa10, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa08, size 2, enabled map[20]: type I/O Port, range 32, base 0xa20, size 4, enabled found-> vendor=0x1002, dev=0x4752, revid=0x27 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0082, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x3000000, size 24, enabled map[14]: type I/O Port, range 32, base 0xb00, size 8, port disabled map[18]: type Memory, range 32, base 0x102000, size 12, enabled isab0: at device 7.0 on pci0 pcib0: could not route pin 1 for device 7.0 isa0: could not map ISA interrupt 1 for node 0xf0097238: parallel isa0: on isab0 pci0: at device 6.0 (no driver attached) pcm0: port 0x900-0x9ff mem 0x100000-0x100fff at device 8.0 on pci0 pcm0: pcm0: Codec features headphone, 6 bit master volume, Analog Devices Phat Stereo pcm0: Primary codec extended features variable rate PCM pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: M1533 0x7e: 0x81 -> 0x81 pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap c0000000, 10000; 0xc0c86000 -> c0000000 pcm0: sndbuf_setmap c0012000, 10000; 0xc0ca6000 -> c0012000 ohci0: mem 0x1000000-0x1000fff at device 10.0 on pci0 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x2000000-0x2000fff at device 11.0 on pci0 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 atapci0: port 0xa00-0xa07,0xa18-0xa1b,0xa10-0xa17,0xa08-0xa0b,0xa20-0xa2f at device 13.0 on pci0 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata2: reset tp1 mask=03 ostat0=50 ostat1=50 ata2: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 ata2: stat0=0x90 err=0x90 lsb=0x90 msb=0x90 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=50 devices=0x3 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: reset tp1 mask=03 ostat0=00 ostat1=01 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=00 stat1=01 devices=0x10000 ata3: [MPSAFE] ata3: [ITHREAD] machfb0: port 0xb00-0xbff mem 0x3000000-0x3ffffff,0x102000-0x102fff at device 2.0 on pci0 machfb0: console machfb0: 16 MB aperture at 0xfddcc000 not swapped machfb0: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP machfb0: resolution 1280x1024 at 8 bpp jbusppm0: mem 0x4000f000000-0x4000f000007,0x4000f410050-0x4000f41005f on nexus0 jbusppm0: master I/O bridge jbusppm0: running at full speed pcib1: mem 0x4000ff00000-0x4000ff0afff,0x4000fc10000-0x4000fc1701f,0x7f600000000-0x7f6000000ff,0x4000ff80000-0x4000ff8ffff irq 2035,2032,2033,2036,2019 on nexus0 pcib1: Tomatillo, version 4, IGN 0x1f, bus B, 66MHz pcib1: DVMA map: 0xc0000000 to 0xdfffffff 65536 entries pcib1: PROM IOTSB size: 1 (2048 entries) pcib1: bus range 0 to 0; PCI bus 0 pcib1: [FILTER] pcib1: [FILTER] pcib1: [FILTER] pcib1: [FILTER] pci1: on pcib1 pci1: domain=1, physical bus=0 found-> vendor=0x108e, dev=0xa801, revid=0x00 domain=1, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x14e4, dev=0x1647, revid=0x00 domain=1, bus=0, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0x200000, size 16, memory disabled bge0: mem 0x200000-0x20ffff at device 2.0 on pci1 bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0016, rev. 2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:03:ba:d9:a0:07 bge0: [MPSAFE] bge0: [ITHREAD] nexus0: mem 0x4000fc64000-0x4000fc6400f type i2c (no driver attached) syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x300> syscons0: fb0, terminal emulator: scteken (teken terminal) (null) failed to probe at iomem 0xf0000000-0xf00fffff on isa0 rtc0: at port 0x70-0x71 on isa0 rtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ct_to_ts([2010-09-06 13:51:20]) = 1283781080.000000000 rtc0: current time: 1283781080.000000000 (null) failed to probe at port 0x320-0x321 irq 46 on isa0 (null) failed to probe at port 0x800-0x82f irq 32 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 44 on isa0 uart0: [FILTER] uart0: fast interrupt uart1: at port 0x2e8-0x2ef irq 44 on isa0 uart1: [FILTER] uart1: fast interrupt (null) failed to probe at port 0-0xffff on isa0 ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: at port 0x378-0x37f,0-0x4ff drq 1 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/1 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Polled port procfs registered Timecounter "tick" frequency 1503000000 Hz quality 1000 Timecounter "stick" frequency 12000000 Hz quality 1000 Event timer "tick" frequency 1503000000 Hz quality 1000 Starting kernel event timers: tick @ 2000Hz, NONE @ 0Hz Timecounters tick every 1.000 msec lo0: bpf attached ata2: Identifying devices: 00000003 ata2: New devices: 00000003 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ata2-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting UDMA100 ad0: 76319MB at ata2-master UDMA100 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad1: setting UDMA100 ad1: 76319MB at ata2-slave UDMA100 ad1: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue ata3: Identifying devices: 00010000 ata3: New devices: 00010000 GEOM: ad0: adding VTOC8 information. GEOM: new disk ad1 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting UDMA33 acd0: CDRW drive at ata3 as master acd0: read 8958KB/s (8958KB/s) write 8958KB/s (8958KB/s), 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XY] coordinates ID=0 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata3:0:0:0): SCSI status error (probe0:ata3:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (probe0:ata3:0:0:0): Error 22, Unretryable error (probe0:ata3:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata3:0:0:0): SCSI status error (probe0:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (probe0:ata3:0:0:0): Error 6, Unretryable error pass0 at ata3 bus 0 scbus1 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 WARNING: WITNESS option enabled, expect reduced performance. (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata3:0:0:0): Error 6, Unretryable error cd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata3:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus1 ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 kbd0: ukbd0, generic (0), config:0x0, flags:0x1d0000 Trying to mount root from ufs:/dev/ad0a ct_to_ts([2010-09-06 13:51:23]) = 1283781083.000000000 start_init: trying /sbin/init bge0: link state changed to UP many thanks 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 Sep 6 13:07:13 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 9DC5F106566C for ; Mon, 6 Sep 2010 13:07:13 +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 597438FC15 for ; Mon, 6 Sep 2010 13:07:13 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OsbPk-0003qh-2M; Mon, 06 Sep 2010 14:07:12 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OsbPj-0001d0-Ty; Mon, 06 Sep 2010 14:07:11 +0100 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 o86D7B3h051677; Mon, 6 Sep 2010 14:07:11 +0100 (BST) (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 o86D7BLP051672; Mon, 6 Sep 2010 14:07:11 +0100 (BST) (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 Sep 2010 14:07:11 +0100 From: Anton Shterenlikht To: pluknet Message-ID: <20100906130711.GA49681@mech-cluster241.men.bris.ac.uk> References: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:07:13 -0000 On Mon, Sep 06, 2010 at 05:03:31PM +0400, pluknet wrote: > On 6 September 2010 16:50, Anton Shterenlikht wrote: > > On sparc64 after updating to r212060, libz.so.5 came up > > as old library. I rebuit all ports to use > > libz.so.6 instead, but libchk still shows that > > > > Binaries that are linked with: /lib/libz.so.5 > >        /usr/sbin/dtrace > >        /usr/sbin/lockstat > > > > What did I do wrong that resulted in these 2 > > programs still linked against the old version > > of libz? > > > > Hi, Anton. > > After r210693, these utilities are built for i386 and amd64 only. > Thereby you have stale binaries installed from older sources. oh, I see. There is an ongoing thread on DTrace in -current. It's probably related to my issue? many thanks 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 Sep 6 13:12: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 09F9210656AA for ; Mon, 6 Sep 2010 13:12:10 +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 4B0198FC08 for ; Mon, 6 Sep 2010 13:12:09 +0000 (UTC) Received: from [41.154.88.19] (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 1OsbUU-00036q-GV; Mon, 06 Sep 2010 15:12:07 +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 1OsbUR-0001Wr-6Q; Mon, 06 Sep 2010 15:12:03 +0200 Message-Id: To: Randy Bush From: Ian FREISLICH In-Reply-To: References: <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> X-Attribution: BOFH Date: Mon, 06 Sep 2010 15:12:03 +0200 Cc: freebsd-current@freebsd.org Subject: Re: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:12:10 -0000 Randy Bush wrote: > Ian FREISLICH wrote: > > Peter Reo Molnar wrote: > > > Hello, > > > > > > I tried setup NAT with IPFW, compiled my kernel and I found that there > > > is very slow connection. > > > After I disabled NAT and IPFW then speed was increased. > > > > > > 64-bit FreeBSD 9-CURRENT : > > > With IPFW: 1.2 MB/sec > > > Without IPFW: 33 MB/sec > > > > > > > > > my ipfw work with i386 (stable) without speed decreasing: > > > > > > fw.test.conf: > > > -f flush > > > add 00050 divert 8668 ip4 from any to any via re0 > > > add 00100 allow ip from any to any via lo0 > > > add 00200 deny ip from any to 127.0.0.0/8 > > > add 00300 deny ip from 127.0.0.0/8 to any > > > > This looks like you're using the old style NAT - divert to userland. > > That has always performed poorly. Perhaps not as poorly as this > > though. How much CPU is natd consuming? > > > > Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS > > TRANSLATION' section in the ipfw manual. It's worth a try. > > i never managed to figure out how to convert my pppoe nat config to ipfw > natting. > > foo: > set device PPPoE:vr0 > set MTU 1454 > accept CHAP > enable lqr > add default HISADDR > nat enable yes > nat port tcp 192.168.0.33:51332 51332 > nat port udp 192.168.0.33:51332 51332 > set authname blogovitch > set authkey vitchoblog > > loop: > set log phase chat connect lcp ipcp command > set device localhost:pptp > set dial > set login > set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255 > > clue bat solicited I should have prefaced this with "last used ipfw in 2005". One of the reasons for this was poor NAT performance because of all the kernel-user and back again copies. I've always done it your way for 2 reasons: 1. In this country, PPPoE means you're using ADSL or some broadband connection, and you can't get them fast enough that filling your line will use more than 1% CPU doing NAT in userland. 2. The broadband in this country assigns a dynamic IP address and until recently reset the connection every 24h, so your NAT had to be aware of these changes and restart itself. You can use the ppp.linkup and ppp.linkdown files to make scripts for your ppp profiles to add and delete NAT rules and restart natd. For instance I used to run a PPP over UDP tunnel over my PPPoE connection to get a static IP address at home. The ppp profile that was always on was called adsl. I had a seperate profile called tunnel that would start only when the adsl profile had link: ppp.linkup --- adsl: ! sh -c "pppctl -p pass 127.0.0.1:3001 quit all; sleep 30; /usr/sbin/ppp -unit 1 -quiet -ddial tunnel" --- ppp.linkdown --- [brane] /etc/ppp # cat ppp.linkdown adsl: ! sh -c "pppctl -p pass 127.0.0.1:3001 quit all" --- I'm sure you could coax these scripts to do what you want, but unless you have more than 50mbps I doubt it's worth the effort. pf just makes so much more sense for NAT, but it suffers the same static addressing problem: nat on vlan2 from { 41.154.7.0/24 } -> 41.161.16.1 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:27: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 EED6E1065707 for ; Mon, 6 Sep 2010 13:27:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D6F1D8FC26 for ; Mon, 6 Sep 2010 13:27:36 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OsbjS-0005lo-FD; Mon, 06 Sep 2010 13:27:34 +0000 Date: Mon, 06 Sep 2010 22:27:34 +0900 Message-ID: From: Randy Bush To: Ian FREISLICH In-Reply-To: References: <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: significantly slow IPFW + NATD + amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:27:37 -0000 > I'm sure you could coax these scripts to do what you want, but > unless you have more than 50mbps I doubt it's worth the effort. i live in a first world country. 100/100 for 3250yen/mo (that's about 35usd. randy From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:28: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 6CE4F1065794; Mon, 6 Sep 2010 13:28:07 +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 8191F8FC22; Mon, 6 Sep 2010 13:28:06 +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 QAA02987; Mon, 06 Sep 2010 16:28:03 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84EC62.6020205@freebsd.org> Date: Mon, 06 Sep 2010 16:28:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> In-Reply-To: <20100906131203.GA80251@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:28:07 -0000 on 06/09/2010 16:12 Jeremy Chadwick said the following: > Great, thanks! I'll be testing this out on two separate systems, both > RELENG_8: > > - Supermicro X7SBA + Intel C2D E8400 (stepping 10) > - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) > > I'll make sure to provide what the topology looks like before and after. > Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant [snip] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 14:32: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 41B9510656B4 for ; Mon, 6 Sep 2010 14:32:17 +0000 (UTC) (envelope-from jhellenthal@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 E72C88FC12 for ; Mon, 6 Sep 2010 14:32:16 +0000 (UTC) Received: by qwg5 with SMTP id 5so4218827qwg.13 for ; Mon, 06 Sep 2010 07:32:16 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=PtsZ8cCvvPuUQi1uBzVbya69etaZaPwRS8c+ZQF2alw=; b=JUiZl1+6INwbQWt8eeUbof2guJ0+T6V9fngYXq77SK8iMTXLl0y9GNQevvvPZ/ojRq Zs95yJcuJRNO5ngmh6qf2AZcPpYiT1mx/bG/vaQaviJpWUCgxRcgvzuE/m3+hV55RbJp RLSjlWdn+yQWiAXLD1GCZNEV8gXTN0eFsR9Vc= 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:x-enigmail-version:content-type :content-transfer-encoding; b=s73VrvdSqOADm1Jsb7isWw+v1tjTa7hUVa78DddsSmDD7J9wQNLcnVegjldg3xX+Z9 esNlXFTTal3RsUpLdsDMXL/vOznUApdFonldn1XAO8DvVllL/rFAL0jJyfc/pEATShv8 O0E0vAO0apNE6oaFxoNtJgphwafay+2Wd8kpE= Received: by 10.224.62.217 with SMTP id y25mr54627qah.193.1283783535846; Mon, 06 Sep 2010 07:32:15 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id f15sm5665708qcr.25.2010.09.06.07.32.13 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 07:32:14 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C84FB6B.4020408@DataIX.net> Date: Mon, 06 Sep 2010 10:32:11 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: pluknet References: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:32:17 -0000 On 09/06/2010 09:03, pluknet wrote: > On 6 September 2010 16:50, Anton Shterenlikht wrote: >> On sparc64 after updating to r212060, libz.so.5 came up >> as old library. I rebuit all ports to use >> libz.so.6 instead, but libchk still shows that >> >> Binaries that are linked with: /lib/libz.so.5 >> /usr/sbin/dtrace >> /usr/sbin/lockstat >> >> What did I do wrong that resulted in these 2 >> programs still linked against the old version >> of libz? >> > > Hi, Anton. > > After r210693, these utilities are built for i386 and amd64 only. > Thereby you have stale binaries installed from older sources. > Lol this is the first I have read about this & comes as quite the surprise that its not being built on top of the platform/arch that it was designed to work on. Given this is FreeBSD and !*Solaris its understandable to a certain point but still... -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 14:47: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 89E2B10656A5 for ; Mon, 6 Sep 2010 14:47:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA6B8FC16 for ; Mon, 6 Sep 2010 14:47:45 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D617046B91; Mon, 6 Sep 2010 10:47:44 -0400 (EDT) Date: Mon, 6 Sep 2010 15:47:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: jhell In-Reply-To: <4C84FB6B.4020408@DataIX.net> Message-ID: References: <20100906125004.GA45452@mech-cluster241.men.bris.ac.uk> <4C84FB6B.4020408@DataIX.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pluknet , Anton Shterenlikht , freebsd-current@freebsd.org Subject: Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:47:45 -0000 On Mon, 6 Sep 2010, jhell wrote: >> After r210693, these utilities are built for i386 and amd64 only. Thereby >> you have stale binaries installed from older sources. > > Lol this is the first I have read about this & comes as quite the surprise > that its not being built on top of the platform/arch that it was designed to > work on. Given this is FreeBSD and !*Solaris its understandable to a certain > point but still... I for one eagerly look forward to the day where we can get DTrace working on MIPs, which is a widely-used architecture in the network device / appliance / etc community. Robert From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:25: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 B9C6610656DA for ; Mon, 6 Sep 2010 13:25:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 76F398FC1D for ; Mon, 6 Sep 2010 13:25:20 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id 3QYR1f0031ap0As52RC5i7; Mon, 06 Sep 2010 13:12:05 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id 3RC41f0083LrwQ23iRC5zF; Mon, 06 Sep 2010 13:12:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8E1559B425; Mon, 6 Sep 2010 06:12:03 -0700 (PDT) Date: Mon, 6 Sep 2010 06:12:03 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906131203.GA80251@icarus.home.lan> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84E4E1.8010709@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 06 Sep 2010 16:19:56 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:25:21 -0000 On Mon, Sep 06, 2010 at 03:56:01PM +0300, Andriy Gapon wrote: > on 06/09/2010 15:23 Jeremy Chadwick said the following: > > On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: > >> on 29/08/2010 12:25 Andriy Gapon said the following: > >>> The below patch is against sources in FreeBSD tree, it should be applied > >>> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > >>> on the desired architecture: > >>> http://people.freebsd.org/~avg/intel-cpu-topo.diff > >> > >> I see that I am not getting as many testers as I expected, so I am going to commit > >> the patch. > >> > >> You still have a short while to either objectively object to the patch or to > >> voluntary test it :-) > > > > I would gladly assist in testing this, except there doesn't appear to be > > an authoritative statement that it will apply to RELENG_8; when I see > > WIP, I assume -CURRENT/HEAD only. > > patch -C is much better than any statement :) > > > Let me know, since all the systems I have are Intel multi-core. > > Yes, the patch should be applicable to stable/8 without any issues. Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 16:33: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 7C13F10656CB; Mon, 6 Sep 2010 16:33:26 +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 733D38FC18; Mon, 6 Sep 2010 16:33:25 +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 TAA05715; Mon, 06 Sep 2010 19:33:21 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C8517D1.3050603@freebsd.org> Date: Mon, 06 Sep 2010 19:33:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> In-Reply-To: <20100906162230.GA1444@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:33:26 -0000 on 06/09/2010 19:22 Jeremy Chadwick said the following: > On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: >> on 06/09/2010 16:12 Jeremy Chadwick said the following: >>> Great, thanks! I'll be testing this out on two separate systems, both >>> RELENG_8: >>> >>> - Supermicro X7SBA + Intel C2D E8400 (stepping 10) >>> - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) >>> >>> I'll make sure to provide what the topology looks like before and after. >>> Is CPU-relevant dmesg output sufficient? >> >> If you mean something like the below, then yes. Thanks! >> [...] > > All done. Good news (I think): there's no difference in the CPU-related > topology on either system with your patch, aside from kernel build date. > The topologies are still detected correctly. In case you want them: > Thanks a lot for the test! [test results snipped] > All other systems I have are C2D and C2Q-based, but I can't easily test > on those given their production roles. If there's a particular Intel > processor family/model you're interested in, let me know and I can dig > around to see if I have access to one. No particular models in mind. If you have systems with more complex topologies, like multiple physical packages or HTT enabled, I will be interested in seeing test results for those. Thanks again. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 16:36:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C38091065697; Mon, 6 Sep 2010 16:36:02 +0000 (UTC) Date: Mon, 6 Sep 2010 16:36:02 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100906163602.GA27903@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: system locks up after a few unsuccessful attempts to create a snapshot of / X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:36:02 -0000 hi there, i was trying to create a snapshot of my root fs. the commands i used were 1) mksnap_ffs /.snap/snap1 and 2) mount -u -o snapshot /.snap/snap1 / both command failed with EAGAIN and the following was output to the console: Sep 6 18:05:56 otaku kernel: fsync: giving up on dirty Sep 6 18:05:56 otaku kernel: 0xffffff000552dd20: tag devfs, type VCHR Sep 6 18:05:56 otaku kernel: usecount 1, writecount 0, refcount 1372 mountedhere 0xffffff0005650a00 Sep 6 18:05:56 otaku kernel: flags () Sep 6 18:05:56 otaku kernel: v_object 0xffffff000568fbd0 ref 0 pages 5486 Sep 6 18:05:56 otaku kernel: lock type devfs: EXCL by thread 0xffffff006b473840 (pid 48144) Sep 6 18:05:56 otaku kernel: dev ufs/rootfs Sep 6 18:08:19 otaku sudo: arundel : TTY=pts/0 ; PWD=/usr/src/sbin/mksnap_ffs ; USER=root ; COMMAND=/sbin/mksnap_ffs /.snap/snapshot1 Sep 6 18:08:29 otaku sudo: arundel : TTY=pts/0 ; PWD=/usr/src/sbin/mksnap_ffs ; USER=root ; COMMAND=/sbin/mksnap_ffs /.snap/snapshot1 Sep 6 18:09:13 otaku kernel: fsync: giving up on dirty Sep 6 18:09:14 otaku kernel: 0xffffff000552dd20: tag devfs, type VCHR Sep 6 18:09:14 otaku kernel: usecount 1, writecount 0, refcount 1373 mountedhere 0xffffff0005650a00 Sep 6 18:09:14 otaku kernel: flags () Sep 6 18:09:14 otaku kernel: v_object 0xffffff000568fbd0 ref 0 pages 5482 Sep 6 18:09:14 otaku kernel: lock type devfs: EXCL by thread 0xffffff0059000840 (pid 48159) Sep 6 18:09:14 otaku kernel: dev ufs/rootfs Sep 6 18:09:14 otaku kernel: fsync: giving up on dirty Sep 6 18:09:14 otaku kernel: 0xffffff000552dd20: tag devfs, type VCHR Sep 6 18:09:14 otaku kernel: usecount 1, writecount 0, refcount 1373 mountedhere 0xffffff0005650a00 Sep 6 18:09:14 otaku kernel: flags () Sep 6 18:09:14 otaku kernel: v_object 0xffffff000568fbd0 ref 0 pages 5482 Sep 6 18:09:14 otaku kernel: lock type devfs: EXCL by thread 0xffffff0059000840 (pid 48159) Sep 6 18:09:14 otaku kernel: dev ufs/rootfs Sep 6 18:11:50 otaku sudo: arundel : TTY=pts/6 ; PWD=/usr/home/arundel ; USER=root ; COMMAND=/sbin/mount -u -o snapshot /.snap/snap1 / Sep 6 18:12:33 otaku kernel: fsync: giving up on dirty Sep 6 18:12:34 otaku kernel: 0xffffff000552dd20: tag devfs, type VCHR Sep 6 18:12:34 otaku kernel: usecount 1, writecount 0, refcount 1383 mountedhere 0xffffff0005650a00 Sep 6 18:12:34 otaku kernel: flags () Sep 6 18:12:34 otaku kernel: v_object 0xffffff000568fbd0 ref 0 pages 5514 Sep 6 18:12:34 otaku kernel: lock type devfs: EXCL by thread 0xffffff006bd6f000 (pid 48194) Sep 6 18:12:34 otaku kernel: dev ufs/rootfs Sep 6 18:12:34 otaku kernel: fsync: giving up on dirty Sep 6 18:12:34 otaku kernel: 0xffffff000552dd20: tag devfs, type VCHR Sep 6 18:12:34 otaku kernel: usecount 1, writecount 0, refcount 1383 mountedhere 0xffffff0005650a00 Sep 6 18:12:34 otaku kernel: flags () Sep 6 18:12:34 otaku kernel: v_object 0xffffff000568fbd0 ref 0 pages 5514 Sep 6 18:12:34 otaku kernel: lock type devfs: EXCL by thread 0xffffff006bd6f000 (pid 48194) Sep 6 18:12:34 otaku kernel: dev ufs/rootfs after about 4 attempts my system stopped responding. after a reboot both commands succeed without any issues. i'm running HEAD (r212123; amd64). otaku% mount -p /dev/ufs/rootfs / ufs noatime 1 1 devfs /dev devfs rw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs /usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 otaku% tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs otaku% df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/rootfs 218G 186G 14G 93% / devfs 1.0K 1.0K 0B 100% /dev devfs 1.0K 1.0K 0B 100% /usr/compat/linux/dev linprocfs 4.0K 4.0K 0B 100% /usr/local/gentoo-stage3/proc linsysfs 4.0K 4.0K 0B 100% /usr/local/gentoo-stage3/sys devfs 1.0K 1.0K 0B 100% /usr/local/gentoo-stage3/dev cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 16:22: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 C0F9A10656A6 for ; Mon, 6 Sep 2010 16:22:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id A12768FC18 for ; Mon, 6 Sep 2010 16:22:32 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 3Taq1f0031zF43QA2UNYy0; Mon, 06 Sep 2010 16:22:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.emeryville.ca.mail.comcast.net with comcast id 3UNX1f0013LrwQ28kUNXC8; Mon, 06 Sep 2010 16:22:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C8BE29B423; Mon, 6 Sep 2010 09:22:30 -0700 (PDT) Date: Mon, 6 Sep 2010 09:22:30 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906162230.GA1444@icarus.home.lan> References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84EC62.6020205@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 06 Sep 2010 16:36:47 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:22:32 -0000 On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: > on 06/09/2010 16:12 Jeremy Chadwick said the following: > > Great, thanks! I'll be testing this out on two separate systems, both > > RELENG_8: > > > > - Supermicro X7SBA + Intel C2D E8400 (stepping 10) > > - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) > > > > I'll make sure to provide what the topology looks like before and after. > > Is CPU-relevant dmesg output sufficient? > > If you mean something like the below, then yes. Thanks! > [...] All done. Good news (I think): there's no difference in the CPU-related topology on either system with your patch, aside from kernel build date. The topologies are still detected correctly. In case you want them: Supermicro X7SBA Intel C2D E8400 (stepping 10) =============================== 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 8.1-STABLE #0: Mon Sep 6 09:06:52 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4112097280 (3921 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 Supermicro X7SBL-LN2 Intel C2D E6600 (stepping 6) ============================== 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 8.1-STABLE #1: Mon Sep 6 07:59:49 PDT 2010 root@gujoja.home.lan:/usr/obj/usr/src/sys/X7SBL_RELENG_8_amd64 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8261648384 (7878 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 All other systems I have are C2D and C2Q-based, but I can't easily test on those given their production roles. If there's a particular Intel processor family/model you're interested in, let me know and I can dig around to see if I have access to one. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 17: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 473DC10656AE; Mon, 6 Sep 2010 17:12:31 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEBFD8FC12; Mon, 6 Sep 2010 17:12:30 +0000 (UTC) Received: by iwn34 with SMTP id 34so5038316iwn.13 for ; Mon, 06 Sep 2010 10:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.149.3 with SMTP id r3mr6355954ibv.109.1283793150285; Mon, 06 Sep 2010 10:12:30 -0700 (PDT) Received: by 10.231.149.8 with HTTP; Mon, 6 Sep 2010 10:12:30 -0700 (PDT) In-Reply-To: <4C8517D1.3050603@freebsd.org> References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> <4C8517D1.3050603@freebsd.org> Date: Mon, 6 Sep 2010 19:12:30 +0200 Message-ID: From: Olivier Smedts To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:12:31 -0000 2010/9/6 Andriy Gapon : > on 06/09/2010 19:22 Jeremy Chadwick said the following: >> On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: >>> on 06/09/2010 16:12 Jeremy Chadwick said the following: >>>> Great, thanks! =A0I'll be testing this out on two separate systems, bo= th >>>> RELENG_8: >>>> >>>> - Supermicro X7SBA =A0 =A0 + Intel C2D E8400 (stepping 10) >>>> - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) >>>> >>>> I'll make sure to provide what the topology looks like before and afte= r. >>>> Is CPU-relevant dmesg output sufficient? >>> >>> If you mean something like the below, then yes. =A0Thanks! >>> [...] >> >> All done. =A0Good news (I think): there's no difference in the CPU-relat= ed >> topology on either system with your patch, aside from kernel build date. >> The topologies are still detected correctly. =A0In case you want them: >> > > Thanks a lot for the test! Here is mine : no difference before and after the patch : FreeBSD 8.1-STABLE #0 r212258M: Mon Sep 6 18:36:00 CEST 2010 root@q.gid0.org:/usr/obj/usr/src/sys/QUAD amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2999.87-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x10677 Family =3D 6 Model =3D 17 St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2029350912 (1935 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 The only thing I noticed is this, after the patch : ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from zfs:tank/freebsd Before the patch, all the "SMP: AP CPU #X Launched!" were correctly displayed, with carriage returns. Yes, I use "options PRINTF_BUFR_SIZE=3D128". And I don't know if that's related to the patch. Cheers, Olivier > > [test results snipped] > >> All other systems I have are C2D and C2Q-based, but I can't easily test >> on those given their production roles. =A0If there's a particular Intel >> processor family/model you're interested in, let me know and I can dig >> around to see if I have access to one. > > No particular models in mind. > If you have systems with more complex topologies, like multiple physical = packages > or HTT enabled, I will be interested in seeing test results for those. > Thanks again. > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 19:09: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 AC64610656DD; Mon, 6 Sep 2010 19:09:40 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5BD8FC26; Mon, 6 Sep 2010 19:09:38 +0000 (UTC) Received: by ewy4 with SMTP id 4so2384640ewy.13 for ; Mon, 06 Sep 2010 12:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=Lwyal03M6wxtSuY7QZqWEV9UqtOY4G0+BVrnZaPZP14=; b=SO4pQmwL3WPwu1ziJv6XElVmHPI6TuklRZxKWDefOAM7gvhOXoeuR4Qwuyuh8CJNX2 SWiglzdAKvhY5sgVoSDKlLU1keaRDcjBMMoK80eMu/6pne9t9fKWIOs03JDv61Iqj8vK VihvUzS/JQSepcfR3PPwjG92WT98Y5EO0souM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=PCaQZ2GyXkAdzNVcpZip9xjMN+KlKfHfXT5Q/BJVRdClSH99hcmTV9k22rOk6t1Njh HgED2iS2TkR4FR2XjXgybA7dWS7a54kiTheypo0oEXTei92zt74a2VLRmxqSHadTdRFI lATBkO0aMJQe8f5ayQXRKkHDYQPa/SIdITyrU= Received: by 10.213.114.5 with SMTP id c5mr1639457ebq.91.1283798324850; Mon, 06 Sep 2010 11:38:44 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id z55sm8486669eeh.15.2010.09.06.11.38.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 11:38:44 -0700 (PDT) Date: Mon, 6 Sep 2010 21:38:38 +0300 From: Gleb Kurtsou To: freebsd-current@FreeBSD.org Message-ID: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stass@FreeBSD.org, pho@FreeBSD.org, jeff@FreeBSD.org, attilio@FreeBSD.org, kan@FreeBSD.org, kib@FreeBSD.org, tegge@FreeBSD.org, giovanni.trematerra@gmail.com Subject: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:09:40 -0000 Hello, I would like to ask for feedback on a kernel level stacked cryptographic filesystem. It has started as Summer Of Code'2009 project and matured a lot since then. I've recently added support for sparse files and switched to XTS encryption mode. I've been using it to encrypt my home directory for almost a year already, and use fsx, dbench and blogbench for testing. So it should be fairly stable. Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and 8-STABLE supported. Please email me separately if you're willing to help testing on big endian machine, XTS code doesn't look endian correct. At this point all of the project goals complete and I'd like it to get wider coverage in terms of tests and reviews and hope to see it commited to HEAD soon. Installation instructions: 1a. Clone git repository: # git clone git://github.com/glk/pefs.git pefs # cd pefs 1b. Or download latest snapshot from github: http://github.com/glk/pefs/archives/master 2. Build and install: # make obj all # make install 3. Mount pefs filesystem: # pefs mount ~/Private ~/Private 4. Enter passphrase: # pefs addkey ~/Private 5. Test it and report back. There is also a man page available. 6. Example how to save your key in keychain database. pefs has to be mounted and key specified to make fs writable, create keychain with single entry (keychain -Z option): # pefs addchain -Z ~/Private Don't encrypt .pefs.db: # mv ~/Private/.pefs.db /tmp # umount ~/Private # mv /tmp/.pefs.db ~/Private # pefs mount ~/Private ~/Private Use -c option to verify key is in database # pefs addkey -c ~/Private 7. You can setup pam_pefs (not compiled by default) to add key to home directory and authenticate against keychain database on login, e.g. by adding the following line to /etc/pam.d/system before pam_unix.so: auth sufficient pam_pefs.so try_first_pass The following is a list of its most important features: * Kernel level file system, no user level daemons needed. Transparently runs on top of existing file systems. * Random per file tweak value used for encryption, which guaranties different cipher texts for the same encrypted files. * Saves metadata only in encrypted file name, but not in file itself. * Supports arbitrary number of keys per file system, default directory key, mixing files encrypted with different keys in same directory. * Allows defining key chains, can be used to add/delete several keys by specifying only master key. * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, PKCS#5v2 and HKDF for key generation. Github repository: http://github.com/glk/pefs More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs Thanks, Gleb. From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 20:26: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 5EA5A10656A3 for ; Mon, 6 Sep 2010 20:26:42 +0000 (UTC) (envelope-from listas@secover.com.br) Received: from hm1315-19.locaweb.com.br (hm1315-19.locaweb.com.br [201.76.49.149]) by mx1.freebsd.org (Postfix) with ESMTP id CC6718FC13 for ; Mon, 6 Sep 2010 20:26:41 +0000 (UTC) Received: from hm2084.locaweb.com.br (189.126.112.73) by hm1315-38.locaweb.com.br (PowerMTA(TM) v3.5r15) id hgl7820nvfo6 for ; Mon, 6 Sep 2010 17:26:28 -0300 (envelope-from ) Received: from [189.126.112.73] (localhost [127.0.0.1]) by hm2084.locaweb.com.br (Postfix) with ESMTP id AF97E440133; Mon, 6 Sep 2010 17:26:28 -0300 (BRT) Received: from cl03.mobimail.com (hm2443.locaweb.com.br [187.45.209.25]) by hm2084.locaweb.com.br (Postfix) with ESMTP id A3A63440263; Mon, 6 Sep 2010 17:26:26 -0300 (BRT) Received: from [189.105.97.73] (account listas@secover.com.br HELO [192.168.1.2]) by hm2443.cl03.mobimail.com (CommuniGate Pro SMTP 5.2.16) with ESMTPSA id 95341208; Mon, 06 Sep 2010 17:26:21 -0300 Message-ID: <4C854E6A.1030504@secover.com.br> Date: Mon, 06 Sep 2010 17:26:18 -0300 From: Anderson Eduardo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Luigi Rizzo References: <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> In-Reply-To: <20100905155311.GA48095@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checked: YES, Locaweb Anti-spam Cc: freebsd-current@freebsd.org Subject: Re: Using ipfw table names instead of numbers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 20:26:42 -0000 Em 5/9/2010 12:53, Luigi Rizzo escreveu: > On Sat, Sep 04, 2010 at 10:58:44AM -0300, Anderson Eduardo wrote: >> Hello developers, >> >> I use the ipfw firewall with many tables and, I would like of able to >> use it with name/alias instead of just numbers. >> >> E.g: >> >> lab# ipfw table 1 name lanetwork >> Setting table 1 to lanetwork >> lab# ipfw table lanetwork add 192.168.0.0/24 >> lab# ipfw table lanetwork list >> 192.168.0.0/24 0 >> lab# >> >> I think a good idea a patch to do that. > > if you have a patch feel free to post it. > the main issue is that internally, for efficiency reason, > the name must be translated to a number anyways, so before implementing > it one must decide where the name-number translation table is stored > and how it is managed > The same applies to any name vs. number issue in ipfw/dummynet > Service, protocol and host names solve these issues because there > is a well defined place for the translation table. But, for instance, > hostname mappings are static (translated at rule insertion time) > whereas one might want a more dynamic behaviour (e.g. refresh > whenever the DNS response expires). > > cheers > luigi Luigi, I did some changes just in user-land, I didn't touch in kernel. I will check if I can do that, I'm not a good developer. Thanks. --=20 Anderson Eduardo Diretor Geral Tel.: +55 (71) 3641-6450 Secover - Servi=E7os em Tecnologia e Seguran=E7a da Informa=E7=E3o http://www.secover.com.br From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 22:08: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 6757010656A8; Mon, 6 Sep 2010 22:08:57 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [IPv6:2a01:4f8:100:1043::2]) by mx1.freebsd.org (Postfix) with ESMTP id 26DA88FC0C; Mon, 6 Sep 2010 22:08:57 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 83EB11165A9; Tue, 7 Sep 2010 00:08:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VRMIP7zR+tUL; Tue, 7 Sep 2010 00:08:54 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 5272A1165A3; Tue, 7 Sep 2010 00:08:54 +0200 (CEST) Message-ID: <4C856677.6020004@FreeBSD.org> Date: Tue, 07 Sep 2010 00:08:55 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <20100831215915.GE1932@garage.freebsd.pl> <4C84D581.6060205@FreeBSD.org> In-Reply-To: <4C84D581.6060205@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 22:08:57 -0000 To avoid user and developer confusion, my patch was just a chain of pjd's patch + pjd's atomic.h fix + my v19 boot patch. I have removed (= split) the chained patch in my posting and altered my blog article with updated build instructions that actually just summarize what has been written on this list. Thanks for understanding! Dòa 6. 9. 2010 13:50, Martin Matuska wrote / napísal(a): > Hi everyone, > I have put together a slightly improved patch of Pawel's that compiles > correctly and supports booting from ZFS v19 pools. > > You can download the patch here: > http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch > > For users who don't want to compile I have created a mfsBSD ISO image > with a zfs-only install of 9-CURRENT-amd64: > http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso > > You can read more about all of this here: > http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html > > More information about ZFS pool and filesystem versions: > http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html > > Thanks to everybody participating in testing, > mm From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 23:03: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 DABD910656F0; Mon, 6 Sep 2010 23:03:31 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43A6F8FC25; Mon, 6 Sep 2010 23:03:29 +0000 (UTC) Received: by ewy4 with SMTP id 4so2428591ewy.13 for ; Mon, 06 Sep 2010 16:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=XtdptLSGyyeQ1c5fvHuHXUQ6u3310n82U/yuVOjJUXc=; b=AXQz9/6Zc7CY7MUjoF4vajv1GZg/Y06Xu/3lCPEFWzurzP5PNDe6Qq6s/0PkCn5H/I b0mxgyEFrzRRJ7GBTdNiWwTfTIGpgZfDmW5/qq4ZRBhPKw82s8QDIdJaM78aXqUVURP/ ViRTdNXXB9fsfKmWJ2S5XmS8UNlGuu9Ppq6Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PiBPuElTvL61u0O67OXd2ydSsq7mpEpWsJqSfw2FkHm0yPMpZp56TDvFuZ3Tc1eema pRfipSmQrzMlJSzBu0pnp3BClsFEr3EYUw9mdxRFbO/yb4LdsPrZHyQ4vxccYPMRgY6E N/U3IlnOrpF8XVdkMJI6B6IoaF7t4FY+4JY/E= Received: by 10.213.17.199 with SMTP id t7mr2661953eba.41.1283814208625; Mon, 06 Sep 2010 16:03:28 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id u9sm8822953eeh.11.2010.09.06.16.03.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 16:03:27 -0700 (PDT) Date: Tue, 7 Sep 2010 02:03:22 +0300 From: Gleb Kurtsou To: freebsd-current@FreeBSD.org Message-ID: <20100906230322.GA5457@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100906183838.GA3460@tops> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stas@FreeBSD.org, kan@FreeBSD.org, pho@FreeBSD.org, jeff@FreeBSD.org, attilio@FreeBSD.org, kib@FreeBSD.org, tegge@FreeBSD.org, giovanni.trematerra@gmail.com Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:03:32 -0000 Sorry for replying to myself, I've realized I put wrong download link: http://github.com/downloads/glk/pefs/pefs-2010-09-06.tar.gz On (06/09/2010 21:38), Gleb Kurtsou wrote: > Hello, > > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a > lot since then. I've recently added support for sparse files and > switched to XTS encryption mode. > > I've been using it to encrypt my home directory for almost a year > already, and use fsx, dbench and blogbench for testing. So it should be > fairly stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > and 8-STABLE supported. > > Please email me separately if you're willing to help testing on big > endian machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get > wider coverage in terms of tests and reviews and hope to see it commited > to HEAD soon. > > > Installation instructions: > > 1a. Clone git repository: > # git clone git://github.com/glk/pefs.git pefs > # cd pefs > > 1b. Or download latest snapshot from github: > http://github.com/glk/pefs/archives/master Or use direct download link: http://github.com/downloads/glk/pefs/pefs-2010-09-06.tar.gz > > 2. Build and install: > # make obj all > # make install > > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private > > 4. Enter passphrase: > # pefs addkey ~/Private > > 5. Test it and report back. There is also a man page available. > > 6. Example how to save your key in keychain database. > > pefs has to be mounted and key specified to make fs writable, create > keychain with single entry (keychain -Z option): > # pefs addchain -Z ~/Private > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db ~/Private > # pefs mount ~/Private ~/Private > Use -c option to verify key is in database > # pefs addkey -c ~/Private > > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass > > > The following is a list of its most important features: > > * Kernel level file system, no user level daemons needed. > Transparently runs on top of existing file systems. > * Random per file tweak value used for encryption, which guaranties > different cipher texts for the same encrypted files. > * Saves metadata only in encrypted file name, but not in file itself. > * Supports arbitrary number of keys per file system, default directory > key, mixing files encrypted with different keys in same directory. > * Allows defining key chains, can be used to add/delete several keys > by specifying only master key. > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. > > > Github repository: http://github.com/glk/pefs > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > Thanks, > Gleb. > From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 03:28: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 E3ADC10656C2; Tue, 7 Sep 2010 03:28:17 +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 AD8348FC15; Tue, 7 Sep 2010 03:28:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o873SGpB090768; Mon, 6 Sep 2010 23:28:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o873SGI9090754; Tue, 7 Sep 2010 03:28:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 7 Sep 2010 03:28:16 GMT Message-Id: <201009070328.o873SGI9090754@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: Tue, 07 Sep 2010 03:28:18 -0000 TB --- 2010-09-07 01:39:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-07 01:39:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-09-07 01:39:25 - cleaning the object tree TB --- 2010-09-07 01:40:08 - cvsupping the source tree TB --- 2010-09-07 01:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-09-07 01:40:51 - building world TB --- 2010-09-07 01:40:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 01:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 01:40:51 - TARGET=ia64 TB --- 2010-09-07 01:40:51 - TARGET_ARCH=ia64 TB --- 2010-09-07 01:40:51 - TZ=UTC TB --- 2010-09-07 01:40:51 - __MAKE_CONF=/dev/null TB --- 2010-09-07 01:40:51 - cd /src TB --- 2010-09-07 01:40:51 - /usr/bin/make -B buildworld >>> World build started on Tue Sep 7 01:40:51 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Sep 7 03:09:57 UTC 2010 TB --- 2010-09-07 03:09:57 - generating LINT kernel config TB --- 2010-09-07 03:09:57 - cd /src/sys/ia64/conf TB --- 2010-09-07 03:09:57 - /usr/bin/make -B LINT TB --- 2010-09-07 03:09:57 - building LINT kernel TB --- 2010-09-07 03:09:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 03:09:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 03:09:57 - TARGET=ia64 TB --- 2010-09-07 03:09:57 - TARGET_ARCH=ia64 TB --- 2010-09-07 03:09:57 - TZ=UTC TB --- 2010-09-07 03:09:57 - __MAKE_CONF=/dev/null TB --- 2010-09-07 03:09:57 - cd /src TB --- 2010-09-07 03:09:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Sep 7 03:09:57 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_kern.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_map.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_mmap.c /src/sys/vm/vm_mmap.c: In function 'munmap': /src/sys/vm/vm_mmap.c:601: error: 'uintptr' undeclared (first use in this function) /src/sys/vm/vm_mmap.c:601: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_mmap.c:601: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-07 03:28:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-07 03:28:16 - ERROR: failed to build lint kernel TB --- 2010-09-07 03:28:16 - 4763.09 user 1049.42 system 6531.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 05:32: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 C7A3910656E3; Tue, 7 Sep 2010 05:32: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 955BB8FC13; Tue, 7 Sep 2010 05:32:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o875WHm5075285; Tue, 7 Sep 2010 01:32:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o875WHhD075267; Tue, 7 Sep 2010 05:32:17 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 7 Sep 2010 05:32:17 GMT Message-Id: <201009070532.o875WHhD075267@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: Tue, 07 Sep 2010 05:32:18 -0000 TB --- 2010-09-07 03:28:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-07 03:28:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-07 03:28:16 - cleaning the object tree TB --- 2010-09-07 03:29:01 - cvsupping the source tree TB --- 2010-09-07 03:29:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-07 03:33:41 - building world TB --- 2010-09-07 03:33:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 03:33:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 03:33:41 - TARGET=powerpc TB --- 2010-09-07 03:33:41 - TARGET_ARCH=powerpc TB --- 2010-09-07 03:33:41 - TZ=UTC TB --- 2010-09-07 03:33:41 - __MAKE_CONF=/dev/null TB --- 2010-09-07 03:33:41 - cd /src TB --- 2010-09-07 03:33:41 - /usr/bin/make -B buildworld >>> World build started on Tue Sep 7 03:33:42 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Sep 7 05:19:15 UTC 2010 TB --- 2010-09-07 05:19:15 - generating LINT kernel config TB --- 2010-09-07 05:19:15 - cd /src/sys/powerpc/conf TB --- 2010-09-07 05:19:15 - /usr/bin/make -B LINT TB --- 2010-09-07 05:19:15 - building LINT kernel TB --- 2010-09-07 05:19:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 05:19:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 05:19:15 - TARGET=powerpc TB --- 2010-09-07 05:19:15 - TARGET_ARCH=powerpc TB --- 2010-09-07 05:19:15 - TZ=UTC TB --- 2010-09-07 05:19:15 - __MAKE_CONF=/dev/null TB --- 2010-09-07 05:19:15 - cd /src TB --- 2010-09-07 05:19:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Sep 7 05:19:15 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_kern.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_map.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_mmap.c /src/sys/vm/vm_mmap.c: In function 'munmap': /src/sys/vm/vm_mmap.c:601: error: 'uintptr' undeclared (first use in this function) /src/sys/vm/vm_mmap.c:601: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_mmap.c:601: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-07 05:32:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-07 05:32:17 - ERROR: failed to build lint kernel TB --- 2010-09-07 05:32:17 - 5195.23 user 1252.84 system 7440.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 06:02:20 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 A422010656A7; Tue, 7 Sep 2010 06:02:20 +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 B29658FC1E; Tue, 7 Sep 2010 06:02:19 +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 JAA15404; Tue, 07 Sep 2010 09:02:14 +0300 (EEST) (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 1OsrG2-000Mfc-CJ; Tue, 07 Sep 2010 09:02:14 +0300 Message-ID: <4C85D566.1040006@freebsd.org> Date: Tue, 07 Sep 2010 09:02:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Olivier Smedts References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> <4C8517D1.3050603@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 06:02:20 -0000 on 06/09/2010 20:12 Olivier Smedts said the following: > Here is mine : no difference before and after the patch : Thanks! [snip] > The only thing I noticed is this, after the patch : > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-7 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) > SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > Trying to mount root from zfs:tank/freebsd > > > Before the patch, all the "SMP: AP CPU #X Launched!" were correctly > displayed, with carriage returns. Yes, I use "options > PRINTF_BUFR_SIZE=128". And I don't know if that's related to the > patch. No, it's not related, it's a probabilistic thing. Those "Launched!" messages are printed from threads running on freshly started APs and thus are executed truly parallel to BSP. BTW, is the above snippet from /var/log/messages or from actual console (e.g. ttyv0)? If it's from message, then could you please check how it looks on the console? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 11:02: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 D316610656D2 for ; Tue, 7 Sep 2010 11:02:55 +0000 (UTC) (envelope-from etnapierala@googlemail.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 60FA88FC13 for ; Tue, 7 Sep 2010 11:02:55 +0000 (UTC) Received: by wwb18 with SMTP id 18so372779wwb.31 for ; Tue, 07 Sep 2010 04:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=HQmdr4fJAf9rTBIKGWQSzz2zy5RJ4q4NfUXTi92vSPQ=; b=kJBlkLFQH3LusYgAAKs/2x1952SLmwUKEN/PsTMleiVDyFfTPERIpzTswquNZKRGnh Hol+hiC3cLm2tOzaf8+cjXPsjdA3Y+Gr82PI+5HoeViftoUJOVlQzMAu0eDDwy0WPIu5 6cw069MhasjAUUOTXtzeOZuJ1NG6tZjnN6jF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=j65/b1y+fb28OLuHhozfeuXpu1fAPxF7/AvQvBS2fRYKr4s7WZ91nSqb1qZPkxHRLb ysPPL+1dmij2jjw4k4Ao6Uh+kP0CoVRkF3doDyp1z9g2478wB/ggfohjivHerDWLbpP8 I3GtqCzaXerC4n2/lsNZndrNnQBS4I7+IhDDs= Received: by 10.216.28.204 with SMTP id g54mr32670wea.73.1283856276853; Tue, 07 Sep 2010 03:44:36 -0700 (PDT) Received: from enapierala.whl (58.wheelsystems.com [83.12.187.58]) by mx.google.com with ESMTPS id v16sm4042561weq.32.2010.09.07.03.44.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 03:44:35 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <86mxrwow84.fsf@gmail.com> Date: Tue, 7 Sep 2010 12:44:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100831215915.GE1932@garage.freebsd.pl> <86mxrwow84.fsf@gmail.com> To: Anonymous X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 11:02:55 -0000 Wiadomo=B6=E6 napisana przez Anonymous w dniu 2010-09-05, o godz. 20:56: > Pawel Jakub Dawidek writes: >=20 >> Hello. >>=20 >> I'd like to give you ZFS v28 for testing. If you are neither brave = nor >> mad, you can stop here. > [...] >> So test whatever you can and report back. Look for regressions, >=20 >> strange behaviour, >=20 > I wonder why new files tend to have different ACLs than old ones. >=20 > $ ls -lh foo > -rw-r--r-- 1 holo holo 17K Aug 19 11:43 foo > $ cp foo bar > $ ls -lh bar > -rw-r--r--+ 1 holo holo 17K Sep 5 21:20 bar > $ getfacl foo bar > # file: foo > # owner: holo > # group: holo > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:-wxp----------:------:deny > group@:r-------------:------:allow > everyone@:-wxp---A-W-Co-:------:deny > everyone@:r-----a-R-c--s:------:allow See = http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbau= m. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 11:21: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 EBCAC10656E2 for ; Tue, 7 Sep 2010 11:21:25 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 77C128FC13 for ; Tue, 7 Sep 2010 11:21:25 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o87BKj5L004080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Sep 2010 21:20:48 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o87BKhiC071895; Tue, 7 Sep 2010 21:20:44 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o87BKe2v071894; Tue, 7 Sep 2010 21:20:40 +1000 (EST) (envelope-from peter) Date: Tue, 7 Sep 2010 21:20:40 +1000 From: Peter Jeremy To: Ian FREISLICH Message-ID: <20100907112040.GA71734@server.vk2pj.dyndns.org> References: <20100830110932.23425932@ernst.jennejohn.org> <4C7B82EA.2040104@FreeBSD.org> <20100830121148.11926306@ernst.jennejohn.org> <20100831102918.4f5404cc@ernst.jennejohn.org> <4C7CC1DE.1080907@FreeBSD.org> <4C7E2E8A.3030709@FreeBSD.org> <4C7EA696.3030901@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-Current Subject: Re: One-shot-oriented event timers management X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 11:21:26 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: >It's a compaq mini-110: >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) Hmmm... I have a N270 in an Aspire One. >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= 100/625 That's rather more frequencies than I would expect. Do you have acpi_throttle enabled? If so, you might like to disable it - it's not particularly effective (and caused regular hands on my AMD Turion laptop). >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 I'm also intrigued as to where C4 comes from. I have: dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 --=20 Peter Jeremy --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkyGIAgACgkQ/opHv/APuIeN6gCgnK4t4ao1ukgglASUkIwE+bqC Aa0AnAuXIfGlOF16JbxIyUyprRFXDf43 =/a+H -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 11:41: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 2266610656D3 for ; Tue, 7 Sep 2010 11:41:07 +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 6193A8FC1C for ; Tue, 7 Sep 2010 11:41:06 +0000 (UTC) Received: from [41.154.88.19] (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 1OswXv-0008TN-6o; Tue, 07 Sep 2010 13:41:03 +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 1OswXR-000313-HY; Tue, 07 Sep 2010 13:40:33 +0200 Message-Id: To: Peter Jeremy From: Ian FREISLICH In-Reply-To: <20100907112040.GA71734@server.vk2pj.dyndns.org> References: <20100907112040.GA71734@server.vk2pj.dyndns.org> <20100830110932.23425932@ernst.jennejohn.org> <4C7B82EA.2040104@FreeBSD.org> <20100830121148.11926306@ernst.jennejohn.org> <20100831102918.4f5404cc@ernst.jennejohn.org> <4C7CC1DE.1080907@FreeBSD.org> <4C7E2E8A.3030709@FreeBSD.org> <4C7EA696.3030901@FreeBSD.org> X-Attribution: BOFH Date: Tue, 07 Sep 2010 13:40:33 +0200 Cc: FreeBSD-Current Subject: Re: One-shot-oriented event timers management X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 11:41:07 -0000 Peter Jeremy wrote: > On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: > >It's a compaq mini-110: > >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) > > Hmmm... I have a N270 in an Aspire One. > > >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= > 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= > 100/625 > > That's rather more frequencies than I would expect. Do you have > acpi_throttle enabled? If so, you might like to disable it - it's not > particularly effective (and caused regular hands on my AMD Turion > laptop). No acpi_throttle in my sysctl mib: [mini] ~ $ sysctl -a |grep acpi_throttle [mini] ~ $ I can set all of these frequencies. They don't really save any power, they just make the system slow. > >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 > > I'm also intrigued as to where C4 comes from. I have: > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 And I can set C4. But the acpi battery method can't determine the discharge rate so I don't know if it actually reduces power either. [mini] ~ $ acpiconf -i 0 Design capacity: 5100 mAh Last full capacity: 4952 mAh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 496 mAh Capacity (low): 347 mAh Low/warn granularity: 0 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: Type: LION OEM info: Hewlett-Packard State: discharging Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage: 12363 mV It might have something to do with the hardware verdor or bios vendor. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 13:28: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 4580D10656DF for ; Tue, 7 Sep 2010 13:28:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F057F8FC15 for ; Tue, 7 Sep 2010 13:28:33 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 988BE46BA2; Tue, 7 Sep 2010 09:28:33 -0400 (EDT) Date: Tue, 7 Sep 2010 14:28:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Kurtsou In-Reply-To: <20100906183838.GA3460@tops> Message-ID: References: <20100906183838.GA3460@tops> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:28:34 -0000 On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a lot > since then. I've recently added support for sparse files and switched to XTS > encryption mode. > > I've been using it to encrypt my home directory for almost a year already, > and use fsx, dbench and blogbench for testing. So it should be fairly > stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > 8-STABLE supported. > > Please email me separately if you're willing to help testing on big endian > machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get wider > coverage in terms of tests and reviews and hope to see it commited to HEAD > soon. Hi Gleb: This sounds like really exciting work! Do you have much in the way of formal documentation of your crypto design at this point? I'd like to point some of the local crypto gurus at Cambridge at it to do some analysis of your approach. However, as they rightly point out, reverse engineering crypto from code is rather a high barrier of entry for a crypto review, so detailed documentation of the approach and a formal format description would be much prefered :-). Thanks, Robert > > > Installation instructions: > > 1a. Clone git repository: > # git clone git://github.com/glk/pefs.git pefs > # cd pefs > > 1b. Or download latest snapshot from github: > http://github.com/glk/pefs/archives/master > > 2. Build and install: > # make obj all > # make install > > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private > > 4. Enter passphrase: > # pefs addkey ~/Private > > 5. Test it and report back. There is also a man page available. > > 6. Example how to save your key in keychain database. > > pefs has to be mounted and key specified to make fs writable, create > keychain with single entry (keychain -Z option): > # pefs addchain -Z ~/Private > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db ~/Private > # pefs mount ~/Private ~/Private > Use -c option to verify key is in database > # pefs addkey -c ~/Private > > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass > > > The following is a list of its most important features: > > * Kernel level file system, no user level daemons needed. > Transparently runs on top of existing file systems. > * Random per file tweak value used for encryption, which guaranties > different cipher texts for the same encrypted files. > * Saves metadata only in encrypted file name, but not in file itself. > * Supports arbitrary number of keys per file system, default directory > key, mixing files encrypted with different keys in same directory. > * Allows defining key chains, can be used to add/delete several keys > by specifying only master key. > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. > > > Github repository: http://github.com/glk/pefs > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > Thanks, > Gleb. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 14:27: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 B39C310656BC for ; Tue, 7 Sep 2010 14:27:32 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 376468FC16 for ; Tue, 7 Sep 2010 14:27:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Osz8y-0001qd-Md for freebsd-current@freebsd.org; Tue, 07 Sep 2010 16:27:28 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 16:27:28 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 16:27:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 07 Sep 2010 16:27:19 +0200 Lines: 48 Message-ID: References: <20100906183838.GA3460@tops> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <20100906183838.GA3460@tops> X-Enigmail-Version: 1.0.1 Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:27:32 -0000 On 09/06/10 20:38, Gleb Kurtsou wrote: > Hello, > > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a > lot since then. I've recently added support for sparse files and > switched to XTS encryption mode. I've tried it and so far it works :) > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private I see you've used the same example in the man page. Maybe it would be better for educational purposes to use two separate directories, e.g. ~/Private and ~/Decrypted to avoid confusion by new users (of course not all examples need to use this). > 6. Example how to save your key in keychain database. This is probably in line with what rwatson said (and would be covered by the same document): can you describe what keychains actually do? > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass So, this would bypass passwd and let the user in if his password authenticates against the "keychain database" in his home directory? Will it automagically pefs-mount his home directory? > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. I do have an request: since you are already using kernel crypto support, it would be simple to just throw Blowfish in :) If for nothing else, consider it a gift to those who are fond of Blowfish's large key sizes (upto 448 bits). Actually, it would probably be seen as a reflection of consistency to implement the same algorithms that geli(8) implements. geli doesn't implement XTS yet - if your XTS code proves to be stable it would be a good thing to include it as standard and then use it from geli. I see you've copied SHA2 code to the pefs code. What is wrong with just using the kernel's SHA2 implementation? From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 15:05: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 24F631065694 for ; Tue, 7 Sep 2010 15:05:14 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D39CC8FC17 for ; Tue, 7 Sep 2010 15:05:13 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OszjT-0000jc-QP for freebsd-current@freebsd.org; Tue, 07 Sep 2010 17:05:11 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 17:05:11 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 17:05:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 07 Sep 2010 17:04:56 +0200 Lines: 7 Message-ID: References: <20100906183838.GA3460@tops> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <20100906183838.GA3460@tops> X-Enigmail-Version: 1.0.1 Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:05:14 -0000 On 09/06/10 20:38, Gleb Kurtsou wrote: > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > and 8-STABLE supported. You probably didn't test it, but I've tried pefs on top of ext2fs (I use ext2fs to share data between OSes) and it quickly panicked. From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 15:27: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 A19B610656EE for ; Tue, 7 Sep 2010 15:27:06 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB98FC21 for ; Tue, 7 Sep 2010 15:27:05 +0000 (UTC) Received: by ewy4 with SMTP id 4so2702833ewy.13 for ; Tue, 07 Sep 2010 08:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=vltXxg6DEsT7MGUBSZ/e2BW6hl6IKteCaC1YE6mBP3s=; b=URz5HnF4yoaemcU9Y8+HCOayAk84OQfqDqT3Q8LXnDMXYJ3XE0PqXbSEe/JOzj0PgA Yscc9IWaw1Y2/mS5+2D/QSt1hunSdyJ1aV0TtA+6EBcHMrswkLxRriafCQ7L/zwW0ANv dUSSbyO2E17MKjq100DYjwQckLPWZWQgx9uBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=R9fLT2LP1tsJhUi6Cm+cvSQkO5Ja8yc9sBRTwbJ9CCS/ZKyz1uY0NminElJpFdmcHc gx8NorQKhdbfDtBAHWqBU49cLJK0O5aA5dRwQcOAUJ9m1vyCauxZa/IM4DLEnNnvEgkV iuunKSq0oucQItG7KTtUo/nXg9c5EstzHoRUc= Received: by 10.213.20.132 with SMTP id f4mr289885ebb.19.1283873224778; Tue, 07 Sep 2010 08:27:04 -0700 (PDT) Received: from localhost ([91.187.0.251]) by mx.google.com with ESMTPS id v59sm10074556eeh.10.2010.09.07.08.27.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 08:27:03 -0700 (PDT) Date: Tue, 7 Sep 2010 18:26:58 +0300 From: Gleb Kurtsou To: Robert Watson Message-ID: <20100907152658.GA2054@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:27:06 -0000 On (07/09/2010 14:28), Robert Watson wrote: > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > since then. I've recently added support for sparse files and switched to XTS > > encryption mode. > > > > I've been using it to encrypt my home directory for almost a year already, > > and use fsx, dbench and blogbench for testing. So it should be fairly > > stable. > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > 8-STABLE supported. > > > > Please email me separately if you're willing to help testing on big endian > > machine, XTS code doesn't look endian correct. > > > > At this point all of the project goals complete and I'd like it to get wider > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > soon. > > Hi Gleb: > > This sounds like really exciting work! Do you have much in the way of formal > documentation of your crypto design at this point? I'd like to point some of > the local crypto gurus at Cambridge at it to do some analysis of your > approach. However, as they rightly point out, reverse engineering crypto from > code is rather a high barrier of entry for a crypto review, so detailed > documentation of the approach and a formal format description would be much > prefered :-). Hello Robert, I've updated my older blog post on pefs crypto design, it's not formal but hope it helps. If there is anything else you might need, I'd be happy to help: http://glebkurtsou.blogspot.com/2009/09/pefs-crypto-primitives.html Thanks, Gleb > > Thanks, > > Robert > > > > > > > > Installation instructions: > > > > 1a. Clone git repository: > > # git clone git://github.com/glk/pefs.git pefs > > # cd pefs > > > > 1b. Or download latest snapshot from github: > > http://github.com/glk/pefs/archives/master > > > > 2. Build and install: > > # make obj all > > # make install > > > > 3. Mount pefs filesystem: > > # pefs mount ~/Private ~/Private > > > > 4. Enter passphrase: > > # pefs addkey ~/Private > > > > 5. Test it and report back. There is also a man page available. > > > > 6. Example how to save your key in keychain database. > > > > pefs has to be mounted and key specified to make fs writable, create > > keychain with single entry (keychain -Z option): > > # pefs addchain -Z ~/Private > > Don't encrypt .pefs.db: > > # mv ~/Private/.pefs.db /tmp > > # umount ~/Private > > # mv /tmp/.pefs.db ~/Private > > # pefs mount ~/Private ~/Private > > Use -c option to verify key is in database > > # pefs addkey -c ~/Private > > > > 7. You can setup pam_pefs (not compiled by default) to add key to home > > directory and authenticate against keychain database on login, e.g. by > > adding the following line to /etc/pam.d/system before pam_unix.so: > > > > auth sufficient pam_pefs.so try_first_pass > > > > > > The following is a list of its most important features: > > > > * Kernel level file system, no user level daemons needed. > > Transparently runs on top of existing file systems. > > * Random per file tweak value used for encryption, which guaranties > > different cipher texts for the same encrypted files. > > * Saves metadata only in encrypted file name, but not in file itself. > > * Supports arbitrary number of keys per file system, default directory > > key, mixing files encrypted with different keys in same directory. > > * Allows defining key chains, can be used to add/delete several keys > > by specifying only master key. > > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > > PKCS#5v2 and HKDF for key generation. > > > > > > Github repository: http://github.com/glk/pefs > > > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > > > Thanks, > > Gleb. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 15:52: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 D7F2610656BB for ; Tue, 7 Sep 2010 15:52:51 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 93AFD8FC12 for ; Tue, 7 Sep 2010 15:52:51 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ot0TW-0005Ho-LA for freebsd-current@freebsd.org; Tue, 07 Sep 2010 17:52:46 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 17:52:46 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 17:52:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Tue, 7 Sep 2010 15:52:36 +0000 (UTC) Organization: http://saper.info Lines: 21 Message-ID: References: <4C770BB9.2070900@delphij.net> <201008270934.56323.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Tue, 07 Sep 2010 16:13:37 +0000 Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:52:51 -0000 Dnia 27.08.2010 John Baldwin napisaÅ‚/a: > On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: >> Hi, >> >> The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and >> FreeBSD/amd64 on amd64. >> >> Comments welcome! I'll commit it in by the weekend if there is no >> objection on this. > > As others have noted, the 'x86' is on purpose, and I would rather it continue > to do that rather than this change. Not sure about it, the loader and boot block are 32-bit code, aren't they? (That actually made me to hack some patches to make ficl 64-bit, but that's another story). So I think i386 is better designation for pure 32-bit code I think. -- << Marcin Cieslak // saper@saper.info >> From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 17:17:58 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 C627E10656D5; Tue, 7 Sep 2010 17:17:58 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 882EE8FC17; Tue, 7 Sep 2010 17:17:58 +0000 (UTC) Received: by pxi17 with SMTP id 17so1675973pxi.13 for ; Tue, 07 Sep 2010 10:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=URvQOmw3WfFWL2bmRSEiIRdkWH5bcirb8UBnY2XqNY4=; b=iYytzxNsJq2vKRC519ti0gJkRWXQk1boNUxIkPUhqpkW+gsVCcVwy8zY47asWqSUqu zeAfzEj7t7RcTadvVrIVmyD1net20rDoT/ILruY+ZWvIDYgZ4SO2gO/n6rl5VkE6Yh/v qErwJWWU7jgsp8fX2X0SghiSIQF+46xzB4ffc= 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=ptoXcOSIr8So+3WwR2dK71f1hI1LTjbTDN4FKHbg4Q9g/zH2JlhahntYSGpzXPNPkB qOUzgFSvFe8dZBUBFnqWfeModujVfG53jbKcJ5ZK/MltGgb6684JM5JCE6TJyYimpbn5 +3cOEHRA83QlkeMtlzNLcjZNttURir6viDlvQ= MIME-Version: 1.0 Received: by 10.142.9.35 with SMTP id 35mr39553wfi.169.1283878067388; Tue, 07 Sep 2010 09:47:47 -0700 (PDT) Received: by 10.231.12.6 with HTTP; Tue, 7 Sep 2010 09:47:46 -0700 (PDT) Received: by 10.231.12.6 with HTTP; Tue, 7 Sep 2010 09:47:46 -0700 (PDT) In-Reply-To: <4C856677.6020004@FreeBSD.org> References: <20100831215915.GE1932@garage.freebsd.pl> <4C84D581.6060205@FreeBSD.org> <4C856677.6020004@FreeBSD.org> Date: Tue, 7 Sep 2010 12:47:46 -0400 Message-ID: From: matt donovan To: Martin Matuska Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:17:58 -0000 The atomic.h patch does not apply anymore and buildworld fails without it. At work so can't post results On Sep 6, 2010 6:09 PM, "Martin Matuska" wrote: > To avoid user and developer confusion, my patch was just a chain of > pjd's patch + pjd's atomic.h fix + my v19 boot patch. > > I have removed (=3D split) the chained patch in my posting and altered my > blog article with updated build instructions that actually just > summarize what has been written on this list. > > Thanks for understanding! > > D=C5=88a 6. 9. 2010 13:50, Martin Matuska wrote / nap=C3=ADsal(a): >> Hi everyone, >> I have put together a slightly improved patch of Pawel's that compiles >> correctly and supports booting from ZFS v19 pools. >> >> You can download the patch here: >> http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch >> >> For users who don't want to compile I have created a mfsBSD ISO image >> with a zfs-only install of 9-CURRENT-amd64: >> http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso >> >> You can read more about all of this here: >> http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html >> >> More information about ZFS pool and filesystem versions: >> http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html >> >> Thanks to everybody participating in testing, >> mm > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 17:46:44 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 231771065696 for ; Tue, 7 Sep 2010 17:46:44 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3D48FC13 for ; Tue, 7 Sep 2010 17:46:44 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o87HjvFu029664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 10:45:57 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7D0C41CC3A; Tue, 7 Sep 2010 10:45:57 -0700 (PDT) To: Ian FREISLICH In-reply-to: Your message of "Tue, 07 Sep 2010 13:40:33 +0200." Date: Tue, 07 Sep 2010 10:45:57 -0700 From: "Kevin Oberman" Message-Id: <20100907174557.7D0C41CC3A@ptavv.es.net> Cc: FreeBSD-Current , Peter Jeremy Subject: Re: One-shot-oriented event timers management X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:46:44 -0000 > From: Ian FREISLICH > Date: Tue, 07 Sep 2010 13:40:33 +0200 > Sender: owner-freebsd-current@freebsd.org > > Peter Jeremy wrote: > > On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: > > >It's a compaq mini-110: > > >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) > > > > Hmmm... I have a N270 in an Aspire One. > > > > >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= > > 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= > > 100/625 > > > > That's rather more frequencies than I would expect. Do you have > > acpi_throttle enabled? If so, you might like to disable it - it's not > > particularly effective (and caused regular hands on my AMD Turion > > laptop). > > No acpi_throttle in my sysctl mib: > [mini] ~ $ sysctl -a |grep acpi_throttle > [mini] ~ $ > > I can set all of these frequencies. They don't really save any > power, they just make the system slow. > > > >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 > > > > I'm also intrigued as to where C4 comes from. I have: > > > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > And I can set C4. But the acpi battery method can't determine the > discharge rate so I don't know if it actually reduces power either. > > [mini] ~ $ acpiconf -i 0 > Design capacity: 5100 mAh > Last full capacity: 4952 mAh > Technology: secondary (rechargeable) > Design voltage: 10800 mV > Capacity (warn): 496 mAh > Capacity (low): 347 mAh > Low/warn granularity: 0 mAh > Warn/full granularity: 100 mAh > Model number: Primary > Serial number: > Type: LION > OEM info: Hewlett-Packard > State: discharging > Remaining capacity: 100% > Remaining time: unknown > Present rate: unknown > Voltage: 12363 mV > > It might have something to do with the hardware verdor or bios vendor. Throttling is currently (unfortunately) on by default. You need to turn it off by adding: hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" to your /boot/loader.conf file. You really only want EST or equivalent. I'd love to see throttling/TCC removed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 17:52: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 5994810656D8 for ; Tue, 7 Sep 2010 17:52:31 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D967E8FC15 for ; Tue, 7 Sep 2010 17:52:30 +0000 (UTC) Received: by ewy4 with SMTP id 4so2857391ewy.13 for ; Tue, 07 Sep 2010 10:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=mpDLBZ0MOPwoAvMV5ahcN/xZYgsqJuKqaU1EexGt30w=; b=FAE9drirKoj/UGKSoAdUE9OpdcKWUtnA8EK0oujfQ+yK+ZI6Ra+WXCLfDCWHDMrfLN IyVclSW5lM4gN19ILTLII0ua7mFAgJLu51tBcvIqOtF4lyO7AtkrmAK8ObF6FZfmaYeX QYYLeRPR3RnkBOOp29AyYeRgDolWnMPtK/pyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=G620t86YJ/QDf0eYN91lDnVju6+hNXDIVBnaJmSs03T/om/VS0YGAzaTqwHSzLTTid 6Bqj9W49k7xp/7+gnSEci7TOnK781537XpmTaNH0aPEpsNWFdisH3/thLSwdAKPa/lhB cJxTrkHu6xtE7ih9oKomeXey4zuNvRfwMph88= Received: by 10.213.35.146 with SMTP id p18mr123726ebd.40.1283881949769; Tue, 07 Sep 2010 10:52:29 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id u9sm10289400eeh.17.2010.09.07.10.52.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 10:52:29 -0700 (PDT) Date: Tue, 7 Sep 2010 20:52:07 +0300 From: Gleb Kurtsou To: Thomas Vogt Message-ID: <20100907175207.GB1793@tops> References: <20100906183838.GA3460@tops> <20100906230322.GA5457@tops> <4C86246B.9020802@bsdunix.ch> <20100907135326.GA1712@tops> <4C864D18.2010504@bsdunix.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C864D18.2010504@bsdunix.ch> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: pam_pefs setup (Re: RFC: pefs - stacked cryptographic filesystem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:52:31 -0000 On (07/09/2010 16:32), Thomas Vogt wrote: [...] > > I've an issue with pam_pefs: > > ===> lib/libpam/modules/pam_pefs (install) > install -C -o root -g wheel -m 444 libpam_pefs.a /usr/lib > install -C -o root -g wheel -m 444 libpam_pefs_p.a /usr/lib > install -o root -g wheel -m 444 pam_pefs.8.gz /usr/share/man/man8 > > I do not see any pam_pefs.so which makes login not possible if > pam.d/system is modified as mentioned in your description: > > auth sufficient pam_pefs.so try_first_pass Sorry, I don't quite understand you here. Don't hesitate contacting me again if didn't understand you correctly. I've also missed one more line, which actually adds the key: session optional pam_pefs.so Setup I've posted makes possible to login using pefs key or standard pam_unix.so password. Here is my /etc/pam.d/system file: # auth auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient pam_pefs.so try_first_pass auth required pam_unix.so no_warn try_first_pass nullok # account account required pam_login_access.so account required pam_unix.so # session session optional pam_pefs.so session required pam_lastlog.so no_fail # password password required pam_unix.so no_warn try_first_pass I have "stronger" password for pefs, while traditional password is "weaker" and easier to type. I use pefs password to login only the first time and add key my home directory. Please note that your home directory has to be mounted, I mount it in /etc/rc.local, but don't add any keys. pam_pefs adds the key. Also note that it has to be exactly your home directory (/home/gleb in my case), to prevent possible attacks. And keychain database has to be created, so that pam_pefs knows how to verify the key. Details on how to create it available in my original email. That's rather inconvenient procedure, but you need to do it just once, it's so complicated because pefs is read-only if no key specified, but database should not be encrypted to make it accessible by pam_pefs: > 3. Mount pefs filesystem: > # pefs mount /home/ME /home/ME > > 4. Enter passphrase: > # pefs addkey /home/ME > > # pefs addchain -Z /home/ME > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db /home/ME > # pefs mount /home/ME /home/ME > Use -c option to verify key is in database > # pefs addkey -c /home/ME I'll try to make it easier, I didn't actually expect anyone to try it, and just mentioned it without providing instructions not to write long setup procedure. You can also try adding debug option to pam_pefs.so config if something goes wrong. I don't remember details but pefs/Makefile contains the following comment by me: # Should be built from sources tree # SUBDIR+= lib/libpam/modules/pam_pefs But if you are able to build it, it should be fine. Thanks, Gleb. > > Regards, > Thomas From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 17:57: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 97A2310656DB; Tue, 7 Sep 2010 17:57:40 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8283D8FC18; Tue, 7 Sep 2010 17:57:40 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o87Hvc8i005835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 10:57:38 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 889611CC3A; Tue, 7 Sep 2010 10:57:38 -0700 (PDT) To: Robert Watson In-reply-to: Your message of "Tue, 07 Sep 2010 14:28:33 BST." Date: Tue, 07 Sep 2010 10:57:38 -0700 From: "Kevin Oberman" Message-Id: <20100907175738.889611CC3A@ptavv.es.net> Cc: Gleb Kurtsou , freebsd-current@FreeBSD.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:57:40 -0000 On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a lot > since then. I've recently added support for sparse files and switched to XTS > encryption mode. > > I've been using it to encrypt my home directory for almost a year already, > and use fsx, dbench and blogbench for testing. So it should be fairly > stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > 8-STABLE supported. > > Please email me separately if you're willing to help testing on big endian > machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get wider > coverage in terms of tests and reviews and hope to see it commited to HEAD > soon. I've got to ask a probably dumb question...how is this better then geli encrypted objects? I've used them for sometime with excellent results. Or does it provide functionality that geli does not? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 18:03: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 739CD10656C0 for ; Tue, 7 Sep 2010 18:03:31 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 013468FC1B for ; Tue, 7 Sep 2010 18:03:30 +0000 (UTC) Received: by eyx24 with SMTP id 24so2871301eyx.13 for ; Tue, 07 Sep 2010 11:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Yiw9foUyLezE6nkns8HzgyucCEOaT79/rJZ0kPwpjvI=; b=qm+CPSb5q3H3IiM7HKLgrHMO/e+oehOcSyy6Z9xLYzDCpdQC2Hl2PPqym+1mElX5in r1hw6OtPbtVtEVfsXMdgvRViZd5Btc1WvSJc+dMLilFzKf/O0567Vbkth4F5CcqXKR33 XgF9y+8ag3MAuNElgesE6a1FYIPkSQtQAUTcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GIQtswil8o6Fpks8ms88DLjh828WquKUFNstn/Ax5+yZn+No3V9GRuHNl5Iib6kJVe kBoniRL3BXQldRwTbmGocywv6ZS4Vi+chJRQbbFnUzKLAXwp1HBbD9iapmvIYMSDPOVS qW26FtVwgLde/GKP82/Nsl+h7GmHKghL4/UD8= Received: by 10.213.35.135 with SMTP id p7mr145666ebd.64.1283882609858; Tue, 07 Sep 2010 11:03:29 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v8sm10307833eeh.2.2010.09.07.11.03.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:03:29 -0700 (PDT) Date: Tue, 7 Sep 2010 21:03:24 +0300 From: Gleb Kurtsou To: freebsd-current@FreeBSD.org Message-ID: <20100907180303.GC1793@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100906183838.GA3460@tops> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 18:03:31 -0000 Thanks to Peter Holm and Thomas Vogt for finding several bugs: * Compilation with DIAGNOSTIC option * Vnode reference and lock leak in pefs_rename() I've uploaded new version to test: http://github.com/downloads/glk/pefs/pefs-2010-09-07.tar.gz Github repository is also updated. Also note, that if you have extra debugging options like DEBUG_LOCKS in your kernel config pefs module has to be build with same options. I set KERNBUILDDIR to my kernel build directory to make it work: # uname -v FreeBSD 9.0-CURRENT #25 r212049+d758796: Tue Aug 31 22:09:45 EEST 2010 root@tops:/usr/obj/freebsd-src/local/sys/TOPS # export KERNBUILDDIR=/usr/obj/freebsd-src/local/sys/TOPS # cd pefs/sys/modules/pefs # make clean # make && make install Thanks, Gleb. On (06/09/2010 21:38), Gleb Kurtsou wrote: > Hello, > > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a > lot since then. I've recently added support for sparse files and > switched to XTS encryption mode. > > I've been using it to encrypt my home directory for almost a year > already, and use fsx, dbench and blogbench for testing. So it should be > fairly stable. > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > and 8-STABLE supported. > > Please email me separately if you're willing to help testing on big > endian machine, XTS code doesn't look endian correct. > > At this point all of the project goals complete and I'd like it to get > wider coverage in terms of tests and reviews and hope to see it commited > to HEAD soon. > > > Installation instructions: > > 1a. Clone git repository: > # git clone git://github.com/glk/pefs.git pefs > # cd pefs > > 1b. Or download latest snapshot from github: > http://github.com/glk/pefs/archives/master > > 2. Build and install: > # make obj all > # make install > > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private > > 4. Enter passphrase: > # pefs addkey ~/Private > > 5. Test it and report back. There is also a man page available. > > 6. Example how to save your key in keychain database. > > pefs has to be mounted and key specified to make fs writable, create > keychain with single entry (keychain -Z option): > # pefs addchain -Z ~/Private > Don't encrypt .pefs.db: > # mv ~/Private/.pefs.db /tmp > # umount ~/Private > # mv /tmp/.pefs.db ~/Private > # pefs mount ~/Private ~/Private > Use -c option to verify key is in database > # pefs addkey -c ~/Private > > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass > > > The following is a list of its most important features: > > * Kernel level file system, no user level daemons needed. > Transparently runs on top of existing file systems. > * Random per file tweak value used for encryption, which guaranties > different cipher texts for the same encrypted files. > * Saves metadata only in encrypted file name, but not in file itself. > * Supports arbitrary number of keys per file system, default directory > key, mixing files encrypted with different keys in same directory. > * Allows defining key chains, can be used to add/delete several keys > by specifying only master key. > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. > > > Github repository: http://github.com/glk/pefs > > More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs > > Thanks, > Gleb. > From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 18:40: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 CB36510656C3 for ; Tue, 7 Sep 2010 18:40:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA368FC21 for ; Tue, 7 Sep 2010 18:40:50 +0000 (UTC) Received: by qyk4 with SMTP id 4so5892394qyk.13 for ; Tue, 07 Sep 2010 11:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Qhf6LhCnZe6BRqba+LytY/61crmgmrAK8ECGiNoxn/E=; b=rAcHp0PcwFzLU/F158QDvUpOLBtlnyQYe7R2WUr81LpkMgPB5Kt9VNWcTdqp4G2+Mi tdxvpyuGJ1L/T5EbBUILYEYggqhiwIdPWxXrpKtRLT0VmUPoweBVsh5fiHbXgoSNinn9 JKfAxkD4GRdjxFzDM6to3JxIlfyRu4I1jjsuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Gf0wtlS+tm8YGI57XeSt1x6dtdLg1ED4/J8HGNPbXH5wyx8ooFJgZCx9LY28bGM8Yh WshGfyW8e/7/agS8+pmA2QYKcuTlKsjSIgzcRURbvyfolOtoGGoA3tz1Z7pKQSYSL+Px yGZWxeIQgD/ovb1uiOC8F2iceLB5DNBv/y2rw= Received: by 10.229.228.195 with SMTP id jf3mr5123559qcb.14.1283884849299; Tue, 07 Sep 2010 11:40:49 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l13sm7346452qck.7.2010.09.07.11.40.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:40:47 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 7 Sep 2010 11:40:28 -0700 From: Pyun YongHyeon Date: Tue, 7 Sep 2010 11:40:28 -0700 To: Anton Shterenlikht Message-ID: <20100907184028.GF1439@michelle.cdnetworks.com> References: <20100902100014.GA26562@mech-cluster241.men.bris.ac.uk> <20100902170316.GA28362@mech-cluster241.men.bris.ac.uk> <20100902183603.GD21940@michelle.cdnetworks.com> <20100903084204.GA35820@mech-cluster241.men.bris.ac.uk> <20100903182534.GM21940@michelle.cdnetworks.com> <20100906130437.GA46535@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100906130437.GA46535@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: bge(4) problem on sparc64 between r204991M and r212097 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 18:40:50 -0000 On Mon, Sep 06, 2010 at 02:04:37PM +0100, Anton Shterenlikht wrote: > On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote: > > On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote: > > > On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote: > > > > On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote: > > > > > On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote: > > > > > > I just updated world and kernel from r204991M to r212097 on sparc64. > > > > > > > > > > > > Now I can't ping my gateway. If I boot kernel.old, then > > > > > > the network works fine. As far as I could see mergemaster > > > > > > didn't update any network files. > > > > > > > > > > > > Please advise > > > > > > > > > > > > In the meantime I'll try intermediate revisions. > > > > > > > > > > I narrowed down the problem to between r212050 and r212080. > > > > > Will continue tomorrow. > > > > > > > > > > > > > Thanks for reporting. There was a big change in r212061, so try > > > > backing out that revision and see whether this makes differences > > > > or not. > > > > > > yes, r212061 is the offending revision, r212060 works fine. > > > Please let me know if you want any further information. > > > > Thanks for narrowing down guilty revision. Would you show me > > verbose boot message? > > First here's diff between dmesg outputs from r212060 and r212061: > [...] > This is full dmesg from r212060, below that is r212061. > [...] Thanks. It seems there was a bug in r212061. I committed fix for that in r212302. Would you give it try and let me know how it goes on your box? From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 18:46: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 32D7E10656A4; Tue, 7 Sep 2010 18:46:26 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9038FC17; Tue, 7 Sep 2010 18:46:25 +0000 (UTC) Received: by ewy4 with SMTP id 4so2902849ewy.13 for ; Tue, 07 Sep 2010 11:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=k6WNfQ5ZWZzsWdzYWeiMBMoiJIBNFCZLUknp3lKaOtU=; b=hM+eXpUyyM+YiUvdwOars14au+Krr3FnO+nGxTtY0d6fFyz1MtwiKzNJTmSTu80zhg PgU8s/2f1D+HbFtErbUF+lmn6E/+eKtZ5KgCLdgbbFEGKmByNxg7F6yjBgtw6Hxsp9Vt fz6JxN/NVzcoSvkXTfoR1ja/gyFF0QXq1Okco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JYINIZqDL7a0Hlxda5nD2ZnpOyZrl15diGhYomDbYheMc2sfpOo+3DoykFmYuRL6cW GQQUAzEMNevXTe07rtqWIR1/oG8AwVKvO6AeEjJitruOy6dhliBQReGeHSZUbGgpS8qT URIQylah+uFIIE2SWQVXBB38thQ9Fy53Jxppo= Received: by 10.213.47.70 with SMTP id m6mr112986ebf.63.1283885184286; Tue, 07 Sep 2010 11:46:24 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v59sm10370105eeh.4.2010.09.07.11.46.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:46:23 -0700 (PDT) Date: Tue, 7 Sep 2010 21:46:18 +0300 From: Gleb Kurtsou To: Kevin Oberman Message-ID: <20100907184618.GA2611@tops> References: <20100907175738.889611CC3A@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100907175738.889611CC3A@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, Robert Watson Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 18:46:26 -0000 On (07/09/2010 10:57), Kevin Oberman wrote: > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > since then. I've recently added support for sparse files and switched to XTS > > encryption mode. > > > > I've been using it to encrypt my home directory for almost a year already, > > and use fsx, dbench and blogbench for testing. So it should be fairly > > stable. > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > 8-STABLE supported. > > > > Please email me separately if you're willing to help testing on big endian > > machine, XTS code doesn't look endian correct. > > > > At this point all of the project goals complete and I'd like it to get wider > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > soon. > > I've got to ask a probably dumb question...how is this better then geli > encrypted objects? I've used them for sometime with excellent results. > > Or does it provide functionality that geli does not? If geli works for you I'd suggest you continue using geli, geli design is order of magnitude simpler due to being block device but not a filesystem. Besides geli provides data authentication, which is very important, and something that can't be easily implemented in stacked filesystem. Pros of stacked filesystem approach: * You don't have to create separate filesystem (use separate partition), just encrypt part of existing filesystem * It's easier to create/manage snapshots/backups (imho) * Ability to use multiple keys, each directory can have its own key, files with different keys can be mixed in one directory, etc. You don't have to create another filesystem and claim that you don't know password for this one if you're asked to provide it, in case you have something to hide ;) Cons: * pefs maximum file name length is ~180 bytes, but not 255 * Stacked filesystem is likely to be slower due to extra overhead I don't really know what makes one better then other, it has only on thing in common - encryption - everything else is different. It depends on how you intend to use it. I was using geli myself, the only problem I had was that at some point I realized that initial partition size was too small :) But that more or less applies to both approaches. E.g. non-standard example where stacked filesystem may be preferred is to use it for encrypted crash dumps: if dump available on dumpdev mount /var/crash as pefs; ask user for password, or automatically add random one and let user to save it later after boot. Crash dumps are encrypted without extra cost of setting up partition, geli, etc. Thanks, Gleb. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 19:03:02 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 6781810656C7; Tue, 7 Sep 2010 19:03:02 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id C299E8FC16; Tue, 7 Sep 2010 19:03:01 +0000 (UTC) Received: by eyx24 with SMTP id 24so2919651eyx.13 for ; Tue, 07 Sep 2010 12:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=c1utZTojwuO6hCVdFTiNN+ZFqlS57AJkKEHNjTNsPYI=; b=VWXUze5KFii04jVwgwDYbPddMuVW5w7elExd3O0xt2kEumWflUU2S9BvvIDz1ep24u s5fs9YFpieFxbcQbyiUcodigNhMoWzB0iZjHUr4624yctjs1ywkaVUMc+aIFvOsq+5Fq Jg4pzC3VMipUhdaDHoS4Movhqp5XGrxTtsGf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=U4eCZHyegT5h9d9YGtML/8ENX/dmNVy+5yHybiGdfKyXhYFlLkhZwT7vey1tQXAab8 J1cuYwf41FFuX4DdEp7h75aR/BsdcffJuQb+hvoIf1pwavasPDVhl0srpgIej5jxXDUB HrwnmUwn3eIpUp3PWKgZRCdO/SIummGkNn2CE= Received: by 10.213.3.14 with SMTP id 14mr163809ebl.51.1283886180641; Tue, 07 Sep 2010 12:03:00 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id a48sm10390221eei.19.2010.09.07.12.02.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 12:02:59 -0700 (PDT) Date: Tue, 7 Sep 2010 22:02:55 +0300 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20100907190255.GA2804@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:03:02 -0000 On (07/09/2010 17:04), Ivan Voras wrote: > On 09/06/10 20:38, Gleb Kurtsou wrote: > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT > > and 8-STABLE supported. > > You probably didn't test it, but I've tried pefs on top of ext2fs (I use > ext2fs to share data between OSes) and it quickly panicked. I've tried it once, it paniced. msdosfs is known to work, but I'd say it shouldn't :) I'll look at it tomorrow, thanks for pointing it. If you are going to use it note that lower filesystem should be case sensitive, the same applies to ZFS. Thanks, Gleb. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 20:28:18 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 DF7F410656B5; Tue, 7 Sep 2010 20:28:17 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1A08FC1E; Tue, 7 Sep 2010 20:28:16 +0000 (UTC) Received: by eyx24 with SMTP id 24so2978521eyx.13 for ; Tue, 07 Sep 2010 13:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=3TRteP0OxHiUHJxJhjySDVZ0wxp0EJ2oATtM42RegwA=; b=A34iVJcWNN5TrN5rb/QWpBqmoLWg0Bp1iRmU9RA7e/Ur+147w/498F+/2bZAuzV2Mr rM4KYIj4wQdLIKQx6GFregVWp+Y5vz5ciawtF7LdDaR0rG7GB6PPOg6WXLrfEvcDEFQ2 sa6cIcGwaU6YyOWWeCUT+DyEfCEkBHoayf7vQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=DOthkPRqMCxcTHhM6StRy0hI5x8McKHmqbQZjHf+t/9kYreA5iqTReN5/g7KGGqCMv OK6m5ltfn64uwAsSuc8wxc9dsAc59ws1n2lF7f6LJyUb2sijVXie4lhDxbbYofdI2/Rx Sx2FvynoPYnDIIbAkm+bQo+zW8C+F1Knsn960= Received: by 10.213.45.194 with SMTP id g2mr36579ebf.0.1283889913302; Tue, 07 Sep 2010 13:05:13 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id u9sm10487472eeh.11.2010.09.07.13.05.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 13:05:12 -0700 (PDT) Date: Tue, 7 Sep 2010 23:05:07 +0300 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20100907200507.GB2804@tops> References: <20100906183838.GA3460@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 20:28:18 -0000 On (07/09/2010 16:27), Ivan Voras wrote: > On 09/06/10 20:38, Gleb Kurtsou wrote: > > Hello, > > > > I would like to ask for feedback on a kernel level stacked cryptographic > > filesystem. It has started as Summer Of Code'2009 project and matured a > > lot since then. I've recently added support for sparse files and > > switched to XTS encryption mode. > > I've tried it and so far it works :) > > > 3. Mount pefs filesystem: > > # pefs mount ~/Private ~/Private > > I see you've used the same example in the man page. Maybe it would be > better for educational purposes to use two separate directories, e.g. > ~/Private and ~/Decrypted to avoid confusion by new users (of course not > all examples need to use this). Actually I've used the same directory solely for educational purposes -- there is just one directory, it's either encrypted or not. Users should think of it as of nullfs on steroids, but that doesn't sound acceptable for man page. Seriously, any help on documentation is more than welcome. I'm not good at writing it, and there is too much to document. We could discuss all the details privately to write a decent man page, if you have time to help. > > 6. Example how to save your key in keychain database. > > This is probably in line with what rwatson said (and would be covered by > the same document): can you describe what keychains actually do? Yes. I was thinking about 6 and 7 as of feature list, so no documentation or instructions. Keychains are mentioned in man page, but once again documentation is far from being good. Help wanted. Most important fact is that keychains have nothing to do with filesystem, it's solely userspace utility concept. Chain is a series of keys (keychain db entries). Each db entry consists of two keys: parent key and child key. Child key may be zero, i.e. end of chain marker, (created by addchain -Z). Keychain database itself is a dictionary of the following form: db[parent_key] = child_key Consider the following database: db[k0] = 0 (zero child key) db[k1] = k2 db[k2] = k3 db[k3] = 0 k0 is special. Its child key is zero (end of chain). Chain would consist only of one key: k0 If user enters k1, the following chain can be retrieved from the database: k1 k2 k3. All three keys are then added to filesystem. In case of k2 chain is k2 k3. All entries stored encrypted in a way that child entry can be decrypted only by parent key. Using key chains one can emulate access levels. (Don't miss 'pefs randomchain' command which was invented especially to make some fun for those trying to look at your data) > > 7. You can setup pam_pefs (not compiled by default) to add key to home > > directory and authenticate against keychain database on login, e.g. by > > adding the following line to /etc/pam.d/system before pam_unix.so: > > > > auth sufficient pam_pefs.so try_first_pass > > So, this would bypass passwd and let the user in if his password > authenticates against the "keychain database" in his home directory? Exactly, that's the way I use it. More detailed description available here: http://marc.info/?l=freebsd-current&m=128388197901390&w=2 > Will it automagically pefs-mount his home directory? No, not mounting pefs is intentional. It automagically adds keys to already mounted pefs filesystem. > > > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > > PKCS#5v2 and HKDF for key generation. > > I do have an request: since you are already using kernel crypto support, > it would be simple to just throw Blowfish in :) If for nothing else, > consider it a gift to those who are fond of Blowfish's large key sizes > (upto 448 bits). XTS requires 128 bit block cipher. One can use Blowfish to encrypt two 64 bit subblocks, but one would need to mix these blocks somehow, that what XTS does :) A bit tricky to implement. Adding serpent or twofish should be easy. > Actually, it would probably be seen as a reflection of consistency to > implement the same algorithms that geli(8) implements. geli doesn't > implement XTS yet - if your XTS code proves to be stable it would be a > good thing to include it as standard and then use it from geli. The problem is 128 bit block in XTS, in my opinion hacking XTS to add support for algorithms with other block sizes is a very bad idea. There are more than enough modern algorithms that can be used instead. Not sure how far "reflection of consistency" extends but pefs is very likely not to support modes other then XTS, because for now it's the only widespread standard mode of operation with arbitrary sector size and arbitrary offset encryption. > I see you've copied SHA2 code to the pefs code. What is wrong with just > using the kernel's SHA2 implementation? That was accidental, or there was a reason I've already forgotten about. Anyway it's just a copy from kernel, my intention was to make it easier to test by users. There's hmac which is one-to-one copy from geli. I've extracted it because now both geli and pefs use same code. Thanks, Gleb. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 21:08: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 7285810656E1 for ; Tue, 7 Sep 2010 21:08:06 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 224078FC08 for ; Tue, 7 Sep 2010 21:08:05 +0000 (UTC) Received: by qyk4 with SMTP id 4so6061330qyk.13 for ; Tue, 07 Sep 2010 14:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=yih3FeKp+n00gnbyI3wgse2DOrcTNekHNMLG5g1Yh9c=; b=PCiaR0EaXUkgv6uEnRJMkOfMOTL2Y9c+R0L/BvRq2OH8bn+imK3imjHrBC7tBPIGjI eRFhxq0t2xLQnifBlm1gx3SbHx5YtHUjwxpxhU2cnOs8S9tY+mKMUZ66BLJPV1DE5Fgd HR4k4Wfh++j/jiXeyBZPOMvDz+VjX7+maXbZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=cWi97GDbWCMdxnukVJ8iD4rd9nCEBBpTHBcd4DCStHqvR2MUhda06Bjf+q1e2RmXZ7 Kv0ynpa0m4+CgKKXTaW1+4JVc5uBQwhutHAU4S4k5Zg9FSjUlkGNeq12LmocLkbvnguQ oviOXTMY5edOq7+YNgvQaUs/ShX9CPPS6NtMY= Received: by 10.229.79.75 with SMTP id o11mr901955qck.96.1283893684239; Tue, 07 Sep 2010 14:08:04 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.222.81 with HTTP; Tue, 7 Sep 2010 14:07:44 -0700 (PDT) In-Reply-To: <20100907200507.GB2804@tops> References: <20100906183838.GA3460@tops> <20100907200507.GB2804@tops> From: Ivan Voras Date: Tue, 7 Sep 2010 23:07:44 +0200 X-Google-Sender-Auth: MOQaUur2yLeobegkPfEV20g-Iec Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 21:08:06 -0000 On 7 September 2010 22:05, Gleb Kurtsou wrote: > On (07/09/2010 16:27), Ivan Voras wrote: >> On 09/06/10 20:38, Gleb Kurtsou wrote: >> > Hello, >> > >> > I would like to ask for feedback on a kernel level stacked cryptograph= ic >> > filesystem. It has started as Summer Of Code'2009 project and matured = a >> > lot since then. I've recently added support for sparse files and >> > switched to XTS encryption mode. >> >> I've tried it and so far it works :) >> >> > 3. Mount pefs filesystem: >> > # pefs mount ~/Private ~/Private >> >> I see you've used the same example in the man page. Maybe it would be >> better for educational purposes to use two separate directories, e.g. >> ~/Private and ~/Decrypted to avoid confusion by new users (of course not >> all examples need to use this). > Actually I've used the same directory solely for educational purposes -- > there is just one directory, it's either encrypted or not. The other directory is a mount point - this is what I was aiming at. > If user enters k1, the following chain can be retrieved from the > database: k1 k2 k3. All three keys are then added to filesystem. > > In case of k2 chain is k2 k3. > > All entries stored encrypted in a way that child entry can be decrypted > only by parent key. > > Using key chains one can emulate access levels. I don't know if it is cryptographically sound but it seems like too much trouble :) >> > 7. You can setup pam_pefs (not compiled by default) to add key to home >> > directory and authenticate against keychain database on login, e.g. by >> > adding the following line to /etc/pam.d/system before pam_unix.so: >> > >> > auth =C2=A0 =C2=A0 =C2=A0 =C2=A0sufficient =C2=A0 =C2=A0 =C2=A0pam_pef= s.so =C2=A0 =C2=A0 try_first_pass >> >> So, this would bypass passwd and let the user in if his password >> authenticates against the "keychain database" in his home directory? > Exactly, that's the way I use it. More detailed description available > here: http://marc.info/?l=3Dfreebsd-current&m=3D128388197901390&w=3D2 > >> Will it automagically pefs-mount his home directory? > No, not mounting pefs is intentional. It automagically adds keys to > already mounted pefs filesystem. Ok, so for example on a desktop client, a pefs-protected home directory would always be mounted from fstab, and then decrypted on login. Makes sense. From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 02:25: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 A5AD31065697 for ; Wed, 8 Sep 2010 02:25:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A7A4D8FC14 for ; Wed, 8 Sep 2010 02:25:21 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o881tDFf025269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 11:25:18 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-59-661035199; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <20100907175207.GB1793@tops> Date: Wed, 8 Sep 2010 11:25:13 +0930 Message-Id: References: <20100906183838.GA3460@tops> <20100906230322.GA5457@tops> <4C86246B.9020802@bsdunix.ch> <20100907135326.GA1712@tops> <4C864D18.2010504@bsdunix.ch> <20100907175207.GB1793@tops> To: Gleb Kurtsou X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Thomas Vogt Subject: Re: pam_pefs setup (Re: RFC: pefs - stacked cryptographic filesystem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 02:25:22 -0000 --Apple-Mail-59-661035199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08/09/2010, at 3:22, Gleb Kurtsou wrote: > Please note that your home directory has to be mounted, I mount it in > /etc/rc.local, but don't add any keys. pam_pefs adds the key. Also = note > that it has to be exactly your home directory (/home/gleb in my case), = to > prevent possible attacks. And keychain database has to be created, so > that pam_pefs knows how to verify the key. Have you considered something similar to pam_mount? = (http://pam-mount.sourceforge.net/) ie pam_pefs could mount your home directory itself and unmount it on = logout. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail-59-661035199-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 04:44: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 4F5F910656C1; Wed, 8 Sep 2010 04:44:30 +0000 (UTC) (envelope-from bw@exodus.desync.com) Received: from exodus.desync.com (exodus.desync.com [IPv6:2607:f178::164]) by mx1.freebsd.org (Postfix) with ESMTP id 035518FC14; Wed, 8 Sep 2010 04:44:29 +0000 (UTC) Received: from exodus.desync.com (localhost [127.0.0.1]) by exodus.desync.com (8.14.4/8.14.4) with ESMTP id o884huW0012877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2010 00:44:13 -0400 (EDT) (envelope-from bw@exodus.desync.com) Received: (from bw@localhost) by exodus.desync.com (8.14.4/8.14.4/Submit) id o884hsrh012876; Wed, 8 Sep 2010 00:43:54 -0400 (EDT) (envelope-from bw) Date: Wed, 8 Sep 2010 00:43:53 -0400 From: ben wilber To: Andre Oppermann Message-ID: <20100908044353.GA12865@exodus.desync.com> References: <20100831231314.GA9637@exodus.desync.com> <4C7E4DC0.5040608@freebsd.org> <137CFFE2-6783-449E-A2EC-8415F9287D97@desync.com> <4C80AD79.8070307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C80AD79.8070307@freebsd.org> X-Angst-Level: High Cc: FreeBSD Current Subject: Re: TSO panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 04:44:30 -0000 On Fri, Sep 03, 2010 at 10:10:33AM +0200, Andre Oppermann wrote: > On 02.09.2010 00:11, ben wilber wrote: > > On Sep 1, 2010, at 8:57 AM, Andre Oppermann wrote: > > > >> On 01.09.2010 01:13, ben wilber wrote: > >>> Hi, > >>> > >>> I just upgraded from r210042 to r212073 and keep getting the panic > >>> introduced in r211317: > >>> > >>> panic: tcp_output: len<= tso_segsz > >> > >> Please try the attached patch and report back whether it > >> fixes the issue. > > > > The system ran for 8 hours or so before I received the same panic. Previously, it would panic within 20 minutes. > > Attached is an updated patch that should fix the panic. > Please try. Running for almost three days now with no problem. Looks good! From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 10:10:18 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 71A9A106567A for ; Wed, 8 Sep 2010 10:10:18 +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 29AE48FC08 for ; Wed, 8 Sep 2010 10:10:17 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OtHbc-0004b6-M7; Wed, 08 Sep 2010 11:10:16 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OtHbc-0005eE-DZ; Wed, 08 Sep 2010 11:10:16 +0100 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 o88AAGxL046095; Wed, 8 Sep 2010 11:10:16 +0100 (BST) (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 o88AAGoE046094; Wed, 8 Sep 2010 11:10:16 +0100 (BST) (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: Wed, 8 Sep 2010 11:10:15 +0100 From: Anton Shterenlikht To: Pyun YongHyeon Message-ID: <20100908101014.GB39173@mech-cluster241.men.bris.ac.uk> References: <20100902100014.GA26562@mech-cluster241.men.bris.ac.uk> <20100902170316.GA28362@mech-cluster241.men.bris.ac.uk> <20100902183603.GD21940@michelle.cdnetworks.com> <20100903084204.GA35820@mech-cluster241.men.bris.ac.uk> <20100903182534.GM21940@michelle.cdnetworks.com> <20100906130437.GA46535@mech-cluster241.men.bris.ac.uk> <20100907184028.GF1439@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100907184028.GF1439@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: bge(4) problem on sparc64 between r204991M and r212097 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 10:10:18 -0000 On Tue, Sep 07, 2010 at 11:40:28AM -0700, Pyun YongHyeon wrote: > On Mon, Sep 06, 2010 at 02:04:37PM +0100, Anton Shterenlikht wrote: > > On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote: > > > On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote: > > > > On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote: > > > > > On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote: > > > > > > On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote: > > > > > > > I just updated world and kernel from r204991M to r212097 on sparc64. > > > > > > > > > > > > > > Now I can't ping my gateway. If I boot kernel.old, then > > > > > > > the network works fine. As far as I could see mergemaster > > > > > > > didn't update any network files. > > > > > > > > > > > > > > Please advise > > > > > > > > > > > > > > In the meantime I'll try intermediate revisions. > > > > > > > > > > > > I narrowed down the problem to between r212050 and r212080. > > > > > > Will continue tomorrow. > > > > > > > > > > > > > > > > Thanks for reporting. There was a big change in r212061, so try > > > > > backing out that revision and see whether this makes differences > > > > > or not. > > > > > > > > yes, r212061 is the offending revision, r212060 works fine. > > > > Please let me know if you want any further information. > > > > > > Thanks for narrowing down guilty revision. Would you show me > > > verbose boot message? > > > > First here's diff between dmesg outputs from r212060 and r212061: > > > > [...] > > > This is full dmesg from r212060, below that is r212061. > > > > [...] > > Thanks. It seems there was a bug in r212061. I committed fix for > that in r212302. Would you give it try and let me know how it goes > on your box? r212302 works well many thanks 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 Wed Sep 8 10:49:46 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 149D910656F0; Wed, 8 Sep 2010 10:49:46 +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 CB63C8FC15; Wed, 8 Sep 2010 10:49:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o88AniJa011932; Wed, 8 Sep 2010 06:49:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o88AnieU011929; Wed, 8 Sep 2010 10:49:44 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Sep 2010 10:49:44 GMT Message-Id: <201009081049.o88AnieU011929@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 Sep 2010 10:49:46 -0000 TB --- 2010-09-08 10:15:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-08 10:15:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-09-08 10:15:01 - cleaning the object tree TB --- 2010-09-08 10:16:13 - cvsupping the source tree TB --- 2010-09-08 10:16:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-09-08 10:49:44 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-08 10:49:44 - ERROR: unable to cvsup the source tree TB --- 2010-09-08 10:49:44 - 2.05 user 53.79 system 2083.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 10:55: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 CA7521065694; Wed, 8 Sep 2010 10:55: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 843638FC14; Wed, 8 Sep 2010 10:55:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o88AtvUC050940; Wed, 8 Sep 2010 06:55:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o88Atvu8050938; Wed, 8 Sep 2010 10:55:57 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Sep 2010 10:55:57 GMT Message-Id: <201009081055.o88Atvu8050938@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 Sep 2010 10:55:58 -0000 TB --- 2010-09-08 10:15:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-08 10:15:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-09-08 10:15:01 - cleaning the object tree TB --- 2010-09-08 10:16:32 - cvsupping the source tree TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 11:45: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 3230F10656E2 for ; Wed, 8 Sep 2010 11:45:53 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A87218FC08 for ; Wed, 8 Sep 2010 11:45:52 +0000 (UTC) Received: by ewy4 with SMTP id 4so3300129ewy.13 for ; Wed, 08 Sep 2010 04:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=XJ4SEgGDIeQde+cyBhwqMs/mtP7S+x7I9WqTYt4JrgQ=; b=kfqIsVTziNZ4A8WMfbOl40MzCYs18Foyr+QmufZtBEId3FYWMiL8Rw7DFfPyYsgQ9x Hg5FB4D0/1iv2kCe+NbwTfjjUAhR+fu6JEAziJS/tcH1Zu7nPY7spaO4xlK2CZ04CQLU BSioXxVThLjJFz0udDpxYwcnyjGlbVuZGOpkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Y/B/YkvXdBt7jygXkY64vAe+HmQ6zsdG9a8BhXIs2SfKRJ1U8jpqt9/h1LLw0jCSGH RThmYmytWititUe5WMdWCjJKx4c2RwQMopx3+iik1amOLT4FoDWHnKq/Ccv9jMMEvAYb pWC/fsXZ4t9u8czVD8nYsY0KAab0zkJWU7Of4= Received: by 10.14.13.206 with SMTP id b54mr95991eeb.26.1283946350445; Wed, 08 Sep 2010 04:45:50 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v59sm11764376eeh.16.2010.09.08.04.45.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 04:45:48 -0700 (PDT) Date: Wed, 8 Sep 2010 14:45:43 +0300 From: Gleb Kurtsou To: Daniel O'Connor Message-ID: <20100908114543.GA2312@tops> References: <20100906183838.GA3460@tops> <20100906230322.GA5457@tops> <4C86246B.9020802@bsdunix.ch> <20100907135326.GA1712@tops> <4C864D18.2010504@bsdunix.ch> <20100907175207.GB1793@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Thomas Vogt Subject: Re: pam_pefs setup (Re: RFC: pefs - stacked cryptographic filesystem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 11:45:53 -0000 On (08/09/2010 11:25), Daniel O'Connor wrote: > > On 08/09/2010, at 3:22, Gleb Kurtsou wrote: > > Please note that your home directory has to be mounted, I mount it in > > /etc/rc.local, but don't add any keys. pam_pefs adds the key. Also note > > that it has to be exactly your home directory (/home/gleb in my case), to > > prevent possible attacks. And keychain database has to be created, so > > that pam_pefs knows how to verify the key. > > Have you considered something similar to pam_mount? (http://pam-mount.sourceforge.net/) > > ie pam_pefs could mount your home directory itself and unmount it on logout. I knew about pam_mount before starting pam_pefs and my intent was to keep pam_pefs as simple as possible. Unlike some other stacked cryptographic filesystems, pefs can be mounted in read-only mode without providing a key. pam_mount can be used together with pam_pefs to mount/unmount filesystem on login/logout if needed. pam_mount is more generic then pam_pefs. At the moment pam_pefs doesn't remove key on logout because it is a bit tricky if there are several keys installed. I'm also against the idea of keeping keys installed by current session during the session to remove them on logout. Key chains for different sessions may overlap. I'd suggest to use pam_mount to unmount filesystem on logout in such scenario. Thanks, Gleb. > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 12:22:16 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 8F10710656E0; Wed, 8 Sep 2010 12:22:16 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7AD8FC0A; Wed, 8 Sep 2010 12:22:15 +0000 (UTC) Received: by vws7 with SMTP id 7so5886895vws.13 for ; Wed, 08 Sep 2010 05:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.47.158 with SMTP id n30mr625288vcf.211.1283946914666; Wed, 08 Sep 2010 04:55:14 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Wed, 8 Sep 2010 04:55:14 -0700 (PDT) X-Originating-IP: [71.1.133.114] In-Reply-To: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> Date: Wed, 8 Sep 2010 04:55:14 -0700 Message-ID: From: Rob Farmer To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 12:22:16 -0000 On Wed, Sep 8, 2010 at 03:55, FreeBSD Tinderbox wro= te: > TB --- 2010-09-08 10:15:01 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2010-09-08 10:15:01 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2010-09-08 10:15:01 - cleaning the object tree > TB --- 2010-09-08 10:16:32 - cvsupping the source tree > TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.fre= ebsd.org /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit code = =A01 > TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree > TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > Is it possible to either have the tinderbox try multiple cvsup servers or just not send a message if cvsup fails? Counting all branches and all archs, there have been around 50 "ERROR: unable to cvsup the source tree" mails in the last week. --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 12:58:19 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 0F30910656CD for ; Wed, 8 Sep 2010 12:58:19 +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 D27128FC16 for ; Wed, 8 Sep 2010 12:58:18 +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 7577846BA9; Wed, 8 Sep 2010 08:58:18 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78BB48A03C; Wed, 8 Sep 2010 08:58:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 8 Sep 2010 08:55:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C770BB9.2070900@delphij.net> <201008270934.56323.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201009080855.09578.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 08 Sep 2010 08:58:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Marcin Cieslak Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:58:19 -0000 On Tuesday, September 07, 2010 11:52:36 am Marcin Cieslak wrote: > Dnia 27.08.2010 John Baldwin napisa=C5=82/a: > > On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: > >> Hi, > >>=20 > >> The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > >> FreeBSD/amd64 on amd64. > >>=20 > >> Comments welcome! I'll commit it in by the weekend if there is no > >> objection on this. > > > > As others have noted, the 'x86' is on purpose, and I would rather it co= ntinue=20 > > to do that rather than this change. >=20 > Not sure about it, the loader and boot block are 32-bit code, aren't they? > (That actually made me to hack some patches to make ficl 64-bit, but that= 's > another story). >=20 > So I think i386 is better designation for pure 32-bit code I think. It actually is not pure 32-bit as there is a small bit of 64-bit code to transfer from the loader to the kernel in the loader. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 13:23:37 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 DB68810656E7; Wed, 8 Sep 2010 13:23:37 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id AA75B8FC16; Wed, 8 Sep 2010 13:23:37 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id 5CB6A4B7825; Wed, 8 Sep 2010 21:07:00 +0800 (CST) Date: Wed, 8 Sep 2010 21:07:00 +0800 From: Denny Lin To: Rob Farmer Message-ID: <20100908130700.GA53378@mail.hs.ntnu.edu.tw> References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 13:23:37 -0000 On Wed, Sep 08, 2010 at 04:55:14AM -0700, Rob Farmer wrote: > On Wed, Sep 8, 2010 at 03:55, FreeBSD Tinderbox wrote: > > TB --- 2010-09-08 10:15:01 - tinderbox 2.6 running on freebsd-current.sentex.ca > > TB --- 2010-09-08 10:15:01 - starting HEAD tinderbox run for amd64/amd64 > > TB --- 2010-09-08 10:15:01 - cleaning the object tree > > TB --- 2010-09-08 10:16:32 - cvsupping the source tree > > TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile > > TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit code  1 > > TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree > > TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real > > Is it possible to either have the tinderbox try multiple cvsup servers > or just not send a message if cvsup fails? Counting all branches and > all archs, there have been around 50 "ERROR: unable to cvsup the > source tree" mails in the last week. I don't think Tinderbox supports multiple CVSup servers at the moment. It seems like a desirable feature. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 14:39: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 9B20E10656CD; Wed, 8 Sep 2010 14:39:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE2F8FC0A; Wed, 8 Sep 2010 14:39:26 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o88EdJG8098180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2010 10:39:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o88EdHwh064108; Wed, 8 Sep 2010 10:39:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009081439.o88EdHwh064108@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Sep 2010 10:39:23 -0400 To: Denny Lin , Rob Farmer From: Mike Tancsa In-Reply-To: <20100908130700.GA53378@mail.hs.ntnu.edu.tw> References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:39:27 -0000 At 09:07 AM 9/8/2010, Denny Lin wrote: >On Wed, Sep 08, 2010 at 04:55:14AM -0700, Rob Farmer wrote: > > > TB --- 2010-09-08 10:16:32 - /usr/bin/csup=20 > -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile > > > TB --- 2010-09-08 10:55:57 - WARNING:=20 > /usr/bin/csup returned exit code =C2 1 > > > TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree > > > TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real > > > > Is it possible to either have the tinderbox try multiple cvsup servers > > or just not send a message if cvsup fails? Counting all branches and > > all archs, there have been around 50 "ERROR: unable to cvsup the > > source tree" mails in the last week. > >I don't think Tinderbox supports multiple CVSup servers at the moment. >It seems like a desirable feature. Normally they are pointed to a local mirror here=20 at Sentex. However, that server was having=20 hardware problems which I think we have isolated=20 and resolved now. I will repoint this tinderbox to the local site again. Perhaps as an interim measure a local procmail=20 rule to filter out cvsup failures from going to the list ? ---Mike >-- >Denny Lin >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 15:51: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 10CF810656B2 for ; Wed, 8 Sep 2010 15:51:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C2B448FC19 for ; Wed, 8 Sep 2010 15:51:58 +0000 (UTC) Received: by yxn35 with SMTP id 35so113713yxn.13 for ; Wed, 08 Sep 2010 08:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=pujKQgDyIiFe33s0+qadVic1Kyc5QGyOptRH1WPxQCU=; b=As5GO8IWZKvlGjWWxPCEA2WLv8XL/gESmoSk55ss+K+dN6RBYwx9/DKkqIfhGnsjy9 xPHOifTOm3XEXKnkYUUbuFBy3fjPjpwZElg4eoakrrpP5WHA6FccRb3A3LfQa2gl7D0a HQ00S9/9Me/G6ia7EtFI+aJQ3l0agecgy1yWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=aRu91eVEOCGtCjEWfFm58NWfVaGgNyAGxn7ZClGzFM5xnPDI0GUis7EPd6WeRCdcrl wX4wRNos9BRfzUgqzQDLb8cCbBq9sDCtwfN0pnpP+QxHS2CQAsrlLiunnLQkWPNpnFAn c/mjmCsL1iRXB2AYVoodYhiN1/okPlElFgeYI= MIME-Version: 1.0 Received: by 10.100.93.12 with SMTP id q12mr98143anb.183.1283961117776; Wed, 08 Sep 2010 08:51:57 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 08:51:57 -0700 (PDT) Date: Wed, 8 Sep 2010 08:51:57 -0700 X-Google-Sender-Auth: GxOFdEc4gdMCClBAd5B95Xros-s Message-ID: From: mdf@FreeBSD.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:51:59 -0000 Looking at the uses of kvprintf(9), only [v]sprintf(9) doesn't have a callback function. It seems a little sketchy to me to be doing unsafe sprintf in the kernel anyways. Should we (and by we, I mean me) deprecate sprintf(9) and convert the existing 1200+ uses to strcpy(9) for fixed strings (also potentially bad, but a different beast), or snprintf(9) where the size of the buffer is known? It seems like a large project, but OTOH sprintf(9) is mighty unsafe in the kernel. It's disapproved of for user-space as being unsafe for security reasons as well, but the potential downsides aren't the same, and we'll never clean up ports anyways. :-) Thoughts? matthew From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 16:19: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 82792106566B; Wed, 8 Sep 2010 16:19:04 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7AE8FC15; Wed, 8 Sep 2010 16:19:04 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o88GJ3VN006624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:19:04 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C79C81CC3C; Wed, 8 Sep 2010 09:19:03 -0700 (PDT) To: Gleb Kurtsou In-reply-to: Your message of "Tue, 07 Sep 2010 21:46:18 +0300." <20100907184618.GA2611@tops> Date: Wed, 08 Sep 2010 09:19:03 -0700 From: "Kevin Oberman" Message-Id: <20100908161903.C79C81CC3C@ptavv.es.net> Cc: freebsd-current@FreeBSD.org, Robert Watson Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:19:04 -0000 > Date: Tue, 7 Sep 2010 21:46:18 +0300 > From: Gleb Kurtsou > > On (07/09/2010 10:57), Kevin Oberman wrote: > > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > > > I would like to ask for feedback on a kernel level stacked cryptographic > > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > > since then. I've recently added support for sparse files and switched to XTS > > > encryption mode. > > > > > > I've been using it to encrypt my home directory for almost a year already, > > > and use fsx, dbench and blogbench for testing. So it should be fairly > > > stable. > > > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > > 8-STABLE supported. > > > > > > Please email me separately if you're willing to help testing on big endian > > > machine, XTS code doesn't look endian correct. > > > > > > At this point all of the project goals complete and I'd like it to get wider > > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > > soon. > > > > I've got to ask a probably dumb question...how is this better then geli > > encrypted objects? I've used them for sometime with excellent results. > > > > Or does it provide functionality that geli does not? > > If geli works for you I'd suggest you continue using geli, geli design > is order of magnitude simpler due to being block device but not a > filesystem. Besides geli provides data authentication, which is very > important, and something that can't be easily implemented in stacked > filesystem. > > Pros of stacked filesystem approach: > * You don't have to create separate filesystem (use separate partition), > just encrypt part of existing filesystem > * It's easier to create/manage snapshots/backups (imho) > * Ability to use multiple keys, each directory can have its own key, > files with different keys can be mixed in one directory, etc. You > don't have to create another filesystem and claim that you don't know > password for this one if you're asked to provide it, in case you have > something to hide ;) > > Cons: > * pefs maximum file name length is ~180 bytes, but not 255 > * Stacked filesystem is likely to be slower due to extra overhead > > I don't really know what makes one better then other, it has only on > thing in common - encryption - everything else is different. It depends > on how you intend to use it. > > I was using geli myself, the only problem I had was that at some point I > realized that initial partition size was too small :) But that more or > less applies to both approaches. > > E.g. non-standard example where stacked filesystem may be preferred is > to use it for encrypted crash dumps: if dump available on dumpdev > mount /var/crash as pefs; ask user for password, or automatically add > random one and let user to save it later after boot. Crash dumps are > encrypted without extra cost of setting up partition, geli, etc. Thanks, Gleb. This explains it quite well and, yes, I will be sticking to geli as it meets my current needs (full disk encryption) quite well. I can see a potential use for pefs down the road, though. Thanks for all of your work on this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 16:32: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 39D0D10656B5; Wed, 8 Sep 2010 16:32:14 +0000 (UTC) (envelope-from rink@gloom.codethulu.net) Received: from mx1.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.freebsd.org (Postfix) with ESMTP id EACF98FC08; Wed, 8 Sep 2010 16:32:13 +0000 (UTC) Received: from anathema.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id 99C1F3782C42; Wed, 8 Sep 2010 18:15:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at codethulu.net Received: from mx1.codethulu.net ([77.243.236.173]) by anathema.codethulu.net (anathema.codethulu.net [77.243.236.173]) (amavisd-new, port 10024) with ESMTP id usAHiAeEzax6; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Received: from gloom.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id 77E9A378258D; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Received: by gloom.codethulu.net (Postfix, from userid 1000) id 6AD5A6D455; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Date: Wed, 8 Sep 2010 18:15:31 +0200 From: Rink Springer To: mdf@FreeBSD.org Message-ID: <20100908161531.GJ37467@rink.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:32:14 -0000 Hi, On Wed, Sep 08, 2010 at 08:51:57AM -0700, mdf@FreeBSD.org wrote: > It seems like a large project, but OTOH sprintf(9) is mighty unsafe in > the kernel. It's disapproved of for user-space as being unsafe for > security reasons as well, but the potential downsides aren't the same, > and we'll never clean up ports anyways. :-) Deprecating it may be usable, yet I don't believe we can easily enforce such a policy [1]. Have you looked at how many (potentially) unsecure uses there are in the kernel, to give an idea how useful such an effort would be? [1] Unless we'd go through things like Visual Studio's #define strcpy __strcpy_unsafe_use_string_cb_copy stuff... Regards, -- Rink P.W. Springer - http://rink.nu "The power of accurate observation is commonly called cynicism by those who have not got it." - George Bernard Shaw From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 16:39: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 4B8FD10656D9; Wed, 8 Sep 2010 16:39:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 106368FC08; Wed, 8 Sep 2010 16:39:07 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 189A53F5B7; Wed, 8 Sep 2010 16:39:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88Gd6qM067158; Wed, 8 Sep 2010 16:39:06 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 08:51:57 MST." Date: Wed, 08 Sep 2010 16:39:06 +0000 Message-ID: <67157.1283963946@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:39:08 -0000 In message , mdf@ FreeBSD.org writes: >It seems like a large project, but OTOH sprintf(9) is mighty unsafe in >the kernel. Well, it is only unsafe if people used it without knowing what they are doing, so I think a wholesale automated replacement is both unwarranted and inadvisable. I can recommend the following macro for the static buffer cases, it checks if people know what they are doing with an assert. #define bprintf(buf, fmt, ...) \ do { \ assert(snprintf(buf, sizeof buf, fmt, __VA_ARGS__) \ < sizeof buf); \ } while (0) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 17:01: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 AED8F1065694; Wed, 8 Sep 2010 17:01:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7430C8FC0C; Wed, 8 Sep 2010 17:01:31 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6FB403F592; Wed, 8 Sep 2010 17:01:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88H1Uck067331; Wed, 8 Sep 2010 17:01:30 GMT (envelope-from phk@critter.freebsd.dk) To: Ryan Stone From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 12:47:41 -0400." Date: Wed, 08 Sep 2010 17:01:30 +0000 Message-ID: <67330.1283965290@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: mdf@freebsd.org, freebsd-current@freebsd.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 17:01:31 -0000 In message , Ryan Stone writes: >> #define bprintf(buf, fmt, ...)                                          \ >>        do {                                                            \ >>                assert(snprintf(buf, sizeof buf, fmt, __VA_ARGS__)      \ >>                    < sizeof buf);                                      \ >>        } while (0) > >Anyone using this macro is in for a nasty surprise when they compile >with -DNDEBUG. First, I think they will figure out pretty fast that it is a bad idea. Second, -DNDEBUG has always been and still is a mistake. That is why we have an explicit DIAGNOSTIC for the kernel. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 17:13: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 660C010656C1 for ; Wed, 8 Sep 2010 17:13:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B4FF8FC17 for ; Wed, 8 Sep 2010 17:13:48 +0000 (UTC) Received: by gyg4 with SMTP id 4so183514gyg.13 for ; Wed, 08 Sep 2010 10:13:48 -0700 (PDT) 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=INHYblSdZidHVBFnX1pW7O3ao8Qnwx4/I9UePz5HRBM=; b=BtFfckP9ZzbooPWshIR/JgQSXD5W1OqUYbqY9ax91Mupyj7F3x2jKrXP/kM55qJ/jb HscrrD+9I23qDVi/EJidt9Q1cpxyyG34whvPwTY6+5GAvoNiN6RqqBWUdxWoSIAxBuhJ zprVVg64sisqx4zFSbfKGM0YpY2pD46AkDdQo= 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=w9LKAHxq+O9EusxN2dVHjxGVfcN+w35q/12JAFD3dVxRGvBn5MX5DmzEs4BI2tKAI6 t6ls/xfma9E7IHJasWRQdTWkzGksndBfujOJU+neTkopK/W7lrkfAL0M7mFKZMr/Lh/p 3ITqk8z7eTp9r7dsyXXvhvqxSFNauEaQGR6+E= MIME-Version: 1.0 Received: by 10.101.155.28 with SMTP id h28mr189414ano.24.1283966011043; Wed, 08 Sep 2010 10:13:31 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 10:13:30 -0700 (PDT) In-Reply-To: <20100908161531.GJ37467@rink.nu> References: <20100908161531.GJ37467@rink.nu> Date: Wed, 8 Sep 2010 10:13:30 -0700 X-Google-Sender-Auth: CWUpLeMjvE9W2u0iZVVOjr-Aiq4 Message-ID: From: mdf@FreeBSD.org To: Rink Springer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 17:13:49 -0000 On Wed, Sep 8, 2010 at 9:15 AM, Rink Springer wrote: > Hi, > > On Wed, Sep 08, 2010 at 08:51:57AM -0700, mdf@FreeBSD.org wrote: >> It seems like a large project, but OTOH sprintf(9) is mighty unsafe in >> the kernel. =A0It's disapproved of for user-space as being unsafe for >> security reasons as well, but the potential downsides aren't the same, >> and we'll never clean up ports anyways. :-) > > Deprecating it may be usable, yet I don't believe we can easily enforce > such a policy [1]. If the kernel sources don't use it then the prototype can be removed. > Have you looked at how many (potentially) unsecure > uses there are in the kernel, to give an idea how useful such an effort > would be? I presume all the kernel uses are safe at the moment, but it's an error prone construction. As of this morning grep found 1277 occurrences of sprintf(9) in sys/ and 23 occurrences of vsprintf(9) in sys/. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 17:17:13 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 C488410656A9; Wed, 8 Sep 2010 17:17:13 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F34D8FC12; Wed, 8 Sep 2010 17:17:12 +0000 (UTC) Received: by ewy4 with SMTP id 4so294407ewy.13 for ; Wed, 08 Sep 2010 10:17:12 -0700 (PDT) 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=jO7IVJqXZU+MwooUgS16+2d4G5sjlCwnobJLbvlAOxE=; b=VZ40IIO6OjrUXZ3EA15k6P879pFhB8ZIrTHuFxt1fsMULdI0Ze8Yemc1EQf/W1ncfi a2tcTmtXzfyxpWDlYV6OOKdZdKPy9KtrJ+0tP6NILz3YjEX3164FslHVzZ2u26KnkPhi D3D2qmd1Z5Af3L+Na5Svs1E3Za0zdkV0kIAR0= 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=HVuptN088Kf7m+cVhrbUUx2ncatgnjVtVEj5daNEgVQlmAQQuhgpPOosNfCSe8RDaP x17kWQUBYt/PlzOffzNUhXwSyh9gFUht1DkLa547rVrxQDl103GZpJIR+/zRalAAh3UN LDkoCn2d7fMlqANfhPOrjO6AQTvbL10dtr8zg= MIME-Version: 1.0 Received: by 10.213.15.135 with SMTP id k7mr87836eba.15.1283964461469; Wed, 08 Sep 2010 09:47:41 -0700 (PDT) Received: by 10.213.28.19 with HTTP; Wed, 8 Sep 2010 09:47:41 -0700 (PDT) In-Reply-To: <67157.1283963946@critter.freebsd.dk> References: <67157.1283963946@critter.freebsd.dk> Date: Wed, 8 Sep 2010 12:47:41 -0400 Message-ID: From: Ryan Stone To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Cc: mdf@freebsd.org, freebsd-current@freebsd.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 17:17:13 -0000 PiAjZGVmaW5lIGJwcmludGYoYnVmLCBmbXQsIC4uLikgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKBcCj4goCCgIKAgoGRvIHsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBcCj4goCCgIKAgoCCgIKAgoCCgYXNz ZXJ0KHNucHJpbnRmKGJ1Ziwgc2l6ZW9mIGJ1ZiwgZm10LCBfX1ZBX0FSR1NfXykgoCCgIKBcCj4g oCCgIKAgoCCgIKAgoCCgIKAgoDwgc2l6ZW9mIGJ1Zik7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKBcCj4goCCgIKAgoH0gd2hpbGUgKDApCgpBbnlvbmUgdXNpbmcgdGhpcyBt YWNybyBpcyBpbiBmb3IgYSBuYXN0eSBzdXJwcmlzZSB3aGVuIHRoZXkgY29tcGlsZQp3aXRoIC1E TkRFQlVHLgo= From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 19:19: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 EEF0910656A6 for ; Wed, 8 Sep 2010 19:19:52 +0000 (UTC) (envelope-from maksim.yevmenkin@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 89C128FC12 for ; Wed, 8 Sep 2010 19:19:52 +0000 (UTC) Received: by wyb33 with SMTP id 33so458536wyb.13 for ; Wed, 08 Sep 2010 12:19:51 -0700 (PDT) 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=5dyT/HocRCo5+B7UFmquZtet19Ag2aW5w2/Li0pmaxo=; b=OQf4/RXGqVbk++A2gRHTeCLsw4yaonWte2hodu97ZyTBWsyo/ixMrPV2GNzlSx31Oq 5he68Sddc7REfTVdJKI0+t44VkwwS7Z/8nhQfn+beVrsAPQPHhbblLUVNBbZ1gOqRzkq gXvNNuHT7OZ9s92pK4EIrbEdmmR930Wn5AUZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aUrcF+CrUD4Q1QynC2ig0hhfeUtsEP/6eSghQoWxrG65Luj8jxRm59essvt6uyEQPi H4RcdXEHTpLCuEOLTWkMAJezdXLTTUEJXU6uJyz7bDn0NwXRn7cOWIwXKL51EJJJw78e 4GZOTZ6dO3HHGh3V/KtQAZ1S770W8KeiPNo9o= MIME-Version: 1.0 Received: by 10.227.156.12 with SMTP id u12mr26278wbw.213.1283972271016; Wed, 08 Sep 2010 11:57:51 -0700 (PDT) Received: by 10.216.27.204 with HTTP; Wed, 8 Sep 2010 11:57:50 -0700 (PDT) Date: Wed, 8 Sep 2010 11:57:50 -0700 Message-ID: From: Maksim Yevmenkin To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: silly libusbhid question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:19:53 -0000 hello, [trying current@ first to get wider audience :)] so, i have a somewhat silly question about libusbhid. please consider the following code hid_data_t d; hid_item_t h; for (d = hid_start_parse(desc, 1 << hid_input, -1); hid_get_item(d, &h) > 0; ) { ... } hid_end_parse(d); the idea is/was to parse and iterate over hid descriptor desc in a such a way that only "hid_input" items are returned. as it turns out, this code will also pick up "hid_collection" items as well, i.e. "h.kind" is set to "hid_collection". is this a bug or a feature? thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 20:40:11 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 32D4910656E9 for ; Wed, 8 Sep 2010 20:40:11 +0000 (UTC) (envelope-from weongyo.jeong@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 B57DD8FC1D for ; Wed, 8 Sep 2010 20:40:10 +0000 (UTC) Received: by fxm4 with SMTP id 4so518205fxm.13 for ; Wed, 08 Sep 2010 13:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mail-followup-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem; bh=OedPQQ9BXqTI0en65ze8T5IP4KLS6c7TzhI9HuoSICM=; b=QXYEVo5rySfwiuHVL2U9kNRziyy5U6j+7CgmnYV9sLJXxG5cUE1TUhGJoc7cIXA6RN w25yB4rx5eXx/hR6C8XJb8yNDcGIx7MYWBgRCW8v1ih5W679yFld0Kv9U44mvWboK5Gb J8HyzM6Py48t263fRp3t0EoT9bXwJsaA1MMMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=GZuOUX+YrnoSzmD4fT+ho1+h7di5mBZEut1gKSt/54lvycl+ZszXZPqu956cquEckO 9LSmV1OsAjv0kH6ysp1BwX8+Gyatv3cK0kCOOeKOfPY8tBv4M8RfSY7rzwK9hfw0F684 GouyPXmsXYPnHPjIXhDmlygRkzA16gTMPtA9c= Received: by 10.223.116.20 with SMTP id k20mr73755faq.97.1283976858638; Wed, 08 Sep 2010 13:14:18 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id b36sm306802faq.11.2010.09.08.13.14.16 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 13:14:17 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Wed, 8 Sep 2010 13:14:19 -0700 From: Weongyo Jeong Date: Wed, 8 Sep 2010 13:14:19 -0700 To: current@freebsd.org Message-ID: <20100908201419.GF1328@weongyo> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Subject: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong 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 Sep 2010 20:40:11 -0000 Hello, I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag when it's initialized so I always encounters the following LOR lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 usbd_do_request_flags() at usbd_do_request_flags+0xe5 axe_cmd() at axe_cmd+0xc7 axe_setmulti_locked() at axe_setmulti_locked+0x70 axe_setmulti() at axe_setmulti+0x3e axe_ioctl() at axe_ioctl+0x132 if_addmulti() at if_addmulti+0x19b in_joingroup_locked() at in_joingroup_locked+0x1bc in_joingroup() at in_joingroup+0x52 in_control() at in_control+0x1144 ifioctl() at ifioctl+0x1118 kern_ioctl() at kern_ioctl+0xbe ioctl() at ioctl+0xfd syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 when I uses the following code at driver's ioctl routine: case SIOCADDMULTI: case SIOCDELMULTI: axe_setmulti(sc, 0); break; It means that USB driver always should defer SIOCADDMULTI / SIOCDELMULTI handling to the other process context to avoid LOR. My question is that is it safe if the multicasting operations for USB device happens without IN_MULTI_LOCK? Or is there any race cases if the task is deferred? Or is it OK like the following code? case SIOCADDMULTI: case SIOCDELMULTI: IN_MULTI_UNLOCK(); axe_setmulti(sc, 0); IN_MULTI_LOCK(); break; regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 03:04:38 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 2CF3D10656E5; Thu, 9 Sep 2010 03:04:38 +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 D73428FC1C; Thu, 9 Sep 2010 03:04:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8934aEl036954; Wed, 8 Sep 2010 23:04:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8934aoL036953; Thu, 9 Sep 2010 03:04:36 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 03:04:36 GMT Message-Id: <201009090304.o8934aoL036953@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: Thu, 09 Sep 2010 03:04:38 -0000 TB --- 2010-09-09 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 02:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-09-09 02:00:00 - cleaning the object tree TB --- 2010-09-09 02:00:33 - cvsupping the source tree TB --- 2010-09-09 02:00:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-09-09 02:06:12 - building world TB --- 2010-09-09 02:06:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 02:06:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 02:06:12 - TARGET=arm TB --- 2010-09-09 02:06:12 - TARGET_ARCH=arm TB --- 2010-09-09 02:06:12 - TZ=UTC TB --- 2010-09-09 02:06:12 - __MAKE_CONF=/dev/null TB --- 2010-09-09 02:06:12 - cd /src TB --- 2010-09-09 02:06:12 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 02:06: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/ofwdump (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofwdump.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofw_util.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ofwdump ofwdump.o ofw_util.o gzip -cn /src/usr.sbin/ofwdump/ofwdump.8 > ofwdump.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 03:04:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 03:04:36 - ERROR: failed to build world TB --- 2010-09-09 03:04:36 - 2258.51 user 830.32 system 3876.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 03:49: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 94AEE10656A8; Thu, 9 Sep 2010 03:49: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 3C4AB8FC17; Thu, 9 Sep 2010 03:49:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o893nqHn022050; Wed, 8 Sep 2010 23:49:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o893nqM5022034; Thu, 9 Sep 2010 03:49:52 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 03:49:52 GMT Message-Id: <201009090349.o893nqM5022034@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: Thu, 09 Sep 2010 03:49:53 -0000 TB --- 2010-09-09 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 02:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-09-09 02:00:00 - cleaning the object tree TB --- 2010-09-09 02:00:00 - cvsupping the source tree TB --- 2010-09-09 02:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-09-09 02:01:00 - building world TB --- 2010-09-09 02:01:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 02:01:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 02:01:00 - TARGET=pc98 TB --- 2010-09-09 02:01:00 - TARGET_ARCH=i386 TB --- 2010-09-09 02:01:00 - TZ=UTC TB --- 2010-09-09 02:01:00 - __MAKE_CONF=/dev/null TB --- 2010-09-09 02:01:00 - cd /src TB --- 2010-09-09 02:01:00 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 02:01:00 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/ntp/doc/ntpd.8 > ntpd.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdate.8 > ntpdate.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdc.8 > ntpdc.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpq.8 > ntpq.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntptime.8 > ntptime.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 03:49:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 03:49:52 - ERROR: failed to build world TB --- 2010-09-09 03:49:52 - 4794.72 user 1166.43 system 6591.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 03: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 C908410657D0; Thu, 9 Sep 2010 03:50:20 +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 675678FC21; Thu, 9 Sep 2010 03: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.3) with ESMTP id o893oJuw024747; Wed, 8 Sep 2010 23:50:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o893oJna024746; Thu, 9 Sep 2010 03:50:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 03:50:19 GMT Message-Id: <201009090350.o893oJna024746@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: Thu, 09 Sep 2010 03:50:20 -0000 TB --- 2010-09-09 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 02:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-09-09 02:00:00 - cleaning the object tree TB --- 2010-09-09 02:01:13 - cvsupping the source tree TB --- 2010-09-09 02:01:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-09-09 02:01:39 - building world TB --- 2010-09-09 02:01:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 02:01:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 02:01:39 - TARGET=i386 TB --- 2010-09-09 02:01:39 - TARGET_ARCH=i386 TB --- 2010-09-09 02:01:39 - TZ=UTC TB --- 2010-09-09 02:01:39 - __MAKE_CONF=/dev/null TB --- 2010-09-09 02:01:39 - cd /src TB --- 2010-09-09 02:01:39 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 02:01:39 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/ntp/doc/ntpd.8 > ntpd.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdate.8 > ntpdate.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdc.8 > ntpdc.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpq.8 > ntpq.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntptime.8 > ntptime.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 03:50:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 03:50:19 - ERROR: failed to build world TB --- 2010-09-09 03:50:19 - 4828.91 user 1165.52 system 6619.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 03:50:30 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 8822310657C5; Thu, 9 Sep 2010 03:50:30 +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 BFB448FC1F; Thu, 9 Sep 2010 03:50:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o893oTjg025152; Wed, 8 Sep 2010 23:50:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o893oTvh025149; Thu, 9 Sep 2010 03:50:29 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 03:50:29 GMT Message-Id: <201009090350.o893oTvh025149@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: Thu, 09 Sep 2010 03:50:30 -0000 TB --- 2010-09-09 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 02:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-09-09 02:00:00 - cleaning the object tree TB --- 2010-09-09 02:00:00 - cvsupping the source tree TB --- 2010-09-09 02:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-09-09 02:01:00 - building world TB --- 2010-09-09 02:01:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 02:01:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 02:01:00 - TARGET=amd64 TB --- 2010-09-09 02:01:00 - TARGET_ARCH=amd64 TB --- 2010-09-09 02:01:00 - TZ=UTC TB --- 2010-09-09 02:01:00 - __MAKE_CONF=/dev/null TB --- 2010-09-09 02:01:00 - cd /src TB --- 2010-09-09 02:01:00 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 02:01:00 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/ntp/doc/ntpd.8 > ntpd.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdate.8 > ntpdate.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdc.8 > ntpdc.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpq.8 > ntpq.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntptime.8 > ntptime.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 03:50:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 03:50:29 - ERROR: failed to build world TB --- 2010-09-09 03:50:29 - 4853.55 user 1146.02 system 6628.33 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 04:32:26 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 B393310656D5; Thu, 9 Sep 2010 04:32: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 526D58FC0C; Thu, 9 Sep 2010 04:32:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o894WPe1046206; Thu, 9 Sep 2010 00:32:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o894WPGG046201; Thu, 9 Sep 2010 04:32:25 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 04:32:25 GMT Message-Id: <201009090432.o894WPGG046201@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: Thu, 09 Sep 2010 04:32:26 -0000 TB --- 2010-09-09 03:04:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 03:04:37 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-09-09 03:04:37 - cleaning the object tree TB --- 2010-09-09 03:05:20 - cvsupping the source tree TB --- 2010-09-09 03:05:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-09-09 03:06:08 - building world TB --- 2010-09-09 03:06:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 03:06:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 03:06:08 - TARGET=ia64 TB --- 2010-09-09 03:06:08 - TARGET_ARCH=ia64 TB --- 2010-09-09 03:06:08 - TZ=UTC TB --- 2010-09-09 03:06:08 - __MAKE_CONF=/dev/null TB --- 2010-09-09 03:06:08 - cd /src TB --- 2010-09-09 03:06:08 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 03:06:09 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/ntp/doc/ntpd.8 > ntpd.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdate.8 > ntpdate.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdc.8 > ntpdc.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpq.8 > ntpq.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntptime.8 > ntptime.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 04:32:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 04:32:25 - ERROR: failed to build world TB --- 2010-09-09 04:32:25 - 3777.86 user 900.98 system 5268.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 04:51:15 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 DEBB8106564A; Thu, 9 Sep 2010 04:51:15 +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 80B288FC1E; Thu, 9 Sep 2010 04:51:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o894pEZg045855; Thu, 9 Sep 2010 00:51:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o894pE1u045854; Thu, 9 Sep 2010 04:51:14 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 04:51:14 GMT Message-Id: <201009090451.o894pE1u045854@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: Thu, 09 Sep 2010 04:51:16 -0000 TB --- 2010-09-09 03:49:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 03:49:52 - starting HEAD tinderbox run for mips/mips TB --- 2010-09-09 03:49:52 - cleaning the object tree TB --- 2010-09-09 03:50:17 - cvsupping the source tree TB --- 2010-09-09 03:50:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-09-09 03:51:15 - building world TB --- 2010-09-09 03:51:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 03:51:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 03:51:15 - TARGET=mips TB --- 2010-09-09 03:51:15 - TARGET_ARCH=mips TB --- 2010-09-09 03:51:15 - TZ=UTC TB --- 2010-09-09 03:51:15 - __MAKE_CONF=/dev/null TB --- 2010-09-09 03:51:15 - cd /src TB --- 2010-09-09 03:51:15 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 03:51:15 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/ntp/doc/ntpd.8 > ntpd.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdate.8 > ntpdate.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpdc.8 > ntpdc.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntpq.8 > ntpq.8.gz gzip -cn /src/usr.sbin/ntp/doc/ntptime.8 > ntptime.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 04:51:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 04:51:14 - ERROR: failed to build world TB --- 2010-09-09 04:51:14 - 2327.07 user 829.72 system 3682.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 05:04:17 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 2DFBC10656C0; Thu, 9 Sep 2010 05:04:17 +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 DD05B8FC0A; Thu, 9 Sep 2010 05:04:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o89544Bd039198; Thu, 9 Sep 2010 01:04:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o89544Uv039194; Thu, 9 Sep 2010 05:04:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 05:04:04 GMT Message-Id: <201009090504.o89544Uv039194@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: Thu, 09 Sep 2010 05:04:17 -0000 TB --- 2010-09-09 03:50:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 03:50:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-09 03:50:29 - cleaning the object tree TB --- 2010-09-09 03:51:47 - cvsupping the source tree TB --- 2010-09-09 03:51:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-09 03:52:19 - building world TB --- 2010-09-09 03:52:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 03:52:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 03:52:19 - TARGET=powerpc TB --- 2010-09-09 03:52:19 - TARGET_ARCH=powerpc64 TB --- 2010-09-09 03:52:19 - TZ=UTC TB --- 2010-09-09 03:52:19 - __MAKE_CONF=/dev/null TB --- 2010-09-09 03:52:19 - cd /src TB --- 2010-09-09 03:52:19 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 03:52:20 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/ofwdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofwdump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofw_util.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ofwdump ofwdump.o ofw_util.o gzip -cn /src/usr.sbin/ofwdump/ofwdump.8 > ofwdump.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 05:04:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 05:04:04 - ERROR: failed to build world TB --- 2010-09-09 05:04:04 - 2969.58 user 899.73 system 4414.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 05:31: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 0E69E10656AD; Thu, 9 Sep 2010 05:31: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 C3AD48FC19; Thu, 9 Sep 2010 05:31:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o895VufU024380; Thu, 9 Sep 2010 01:31:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o895Vuk7024379; Thu, 9 Sep 2010 05:31:56 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 05:31:56 GMT Message-Id: <201009090531.o895Vuk7024379@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: Thu, 09 Sep 2010 05:31:58 -0000 TB --- 2010-09-09 03:50:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 03:50:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-09 03:50:19 - cleaning the object tree TB --- 2010-09-09 03:51:22 - cvsupping the source tree TB --- 2010-09-09 03:51:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-09 03:52:03 - building world TB --- 2010-09-09 03:52:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 03:52:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 03:52:03 - TARGET=powerpc TB --- 2010-09-09 03:52:03 - TARGET_ARCH=powerpc TB --- 2010-09-09 03:52:03 - TZ=UTC TB --- 2010-09-09 03:52:03 - __MAKE_CONF=/dev/null TB --- 2010-09-09 03:52:03 - cd /src TB --- 2010-09-09 03:52:03 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 03:52:03 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/ofwdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofwdump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofw_util.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ofwdump ofwdump.o ofw_util.o gzip -cn /src/usr.sbin/ofwdump/ofwdump.8 > ofwdump.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 05:31:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 05:31:56 - ERROR: failed to build world TB --- 2010-09-09 05:31:56 - 4480.47 user 1084.27 system 6096.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 05:36:13 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 4C33410656A6; Thu, 9 Sep 2010 05:36:12 +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 0C0A48FC0C; Thu, 9 Sep 2010 05:36:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o895aAv1035296; Thu, 9 Sep 2010 01:36:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o895aAdH035295; Thu, 9 Sep 2010 05:36:10 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 05:36:10 GMT Message-Id: <201009090536.o895aAdH035295@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: Thu, 09 Sep 2010 05:36:13 -0000 TB --- 2010-09-09 04:32:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 04:32:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-09-09 04:32:25 - cleaning the object tree TB --- 2010-09-09 04:33:03 - cvsupping the source tree TB --- 2010-09-09 04:33:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-09-09 04:33:37 - building world TB --- 2010-09-09 04:33:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 04:33:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 04:33:37 - TARGET=sparc64 TB --- 2010-09-09 04:33:37 - TARGET_ARCH=sparc64 TB --- 2010-09-09 04:33:37 - TZ=UTC TB --- 2010-09-09 04:33:37 - __MAKE_CONF=/dev/null TB --- 2010-09-09 04:33:37 - cd /src TB --- 2010-09-09 04:33:37 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 04:33: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/ofwdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofwdump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/ofwdump/ofw_util.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ofwdump ofwdump.o ofw_util.o gzip -cn /src/usr.sbin/ofwdump/ofwdump.8 > ofwdump.8.gz ===> usr.sbin/pc-sysinstall (all) ===> usr.sbin/pc-sysinstall/backend (all) make: don't know how to make installimage.sh. Stop *** Error code 2 Stop in /src/usr.sbin/pc-sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 05:36:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 05:36:10 - ERROR: failed to build world TB --- 2010-09-09 05:36:10 - 2674.52 user 797.28 system 3824.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 07:00: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 1165C10656AC for ; Thu, 9 Sep 2010 07:00:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3018FC17 for ; Thu, 9 Sep 2010 07:00:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=Nfp3MZa29RopV9PSMgo46OtSaaUquDJpaM5eTxVUGhg= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=FFco8cedzDY532IaSpMA:9 a=BAcFWgyJ-8klfLJlvR_54vgGWcUA:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 18336923; Thu, 09 Sep 2010 09:00:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 9 Sep 2010 08:56:48 +0200 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'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009090856.48132.hselasky@c2i.net> Cc: Maksim Yevmenkin Subject: Re: silly libusbhid question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 07:00:52 -0000 On Wednesday 08 September 2010 20:57:50 Maksim Yevmenkin wrote: > hello, > > [trying current@ first to get wider audience :)] > > so, i have a somewhat silly question about libusbhid. please consider > the following code > > hid_data_t d; > hid_item_t h; > > for (d = hid_start_parse(desc, 1 << hid_input, -1); hid_get_item(d, &h) > > 0; ) { ... > } > hid_end_parse(d); > > the idea is/was to parse and iterate over hid descriptor desc in a > such a way that only "hid_input" items are returned. as it turns out, > this code will also pick up "hid_collection" items as well, i.e. > "h.kind" is set to "hid_collection". is this a bug or a feature? > > thanks, > max In kernel and userspace this is currently a feature in the HID libraries. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 07:03:54 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 0437F10656CF for ; Thu, 9 Sep 2010 07:03:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8D31D8FC15 for ; Thu, 9 Sep 2010 07:03:53 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=76g0mb+DR0sl/0/6h7VD3WCdlo715fdkyhgvIVPBhDQ= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=kW0qIUYWrkW_zGeRG6cA:9 a=xFdMpmzwO-HihZZ5b2Dt_Y8aS1wA:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 17888133; Thu, 09 Sep 2010 09:03:34 +0200 To: freebsd-current@freebsd.org From: Hans Petter Selasky 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' Date: Thu, 9 Sep 2010 08:59:50 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009090859.50251.hselasky@c2i.net> Cc: Maksim Yevmenkin Subject: Re: silly libusbhid question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 07:03:54 -0000 > In kernel and userspace this is currently a feature in the HID libraries. And I agree that maybe this should be changed. Before changing anything please grep the kernel sources for this function and check that no callers are using this feature, or add this missing 1 << hid_collection mask. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:07: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 529A010656E0 for ; Thu, 9 Sep 2010 14:07:47 +0000 (UTC) (envelope-from maksim.yevmenkin@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 DE86C8FC1E for ; Thu, 9 Sep 2010 14:07:46 +0000 (UTC) Received: by wyb33 with SMTP id 33so1707170wyb.13 for ; Thu, 09 Sep 2010 07:07:45 -0700 (PDT) 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=u+pka04t0k0RV3ETCK9lSGQEA2abZdjqlxzxctfJpFg=; b=ujUnkAwTnJBdogbSX2MQsnx8R2hU/WoBILE4tcsW1gkBGMYgWPQN6rKRBkQd9JsOiK lbSv710Nm3j8uUtOSafg7vfDTTTlUIrakRa7RKKDXrfuJsifnvsNPUtFY7xPnWBi50so oAem9nIWHDKzTXnAVE/5yuEWs3ST2SUqaveHw= 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=YHldiIQuvOpTT7waqy0YkT8zeHK1l9mkxvXbvibFPzG4jCZwg2NJImhef0PF83JLba VpM+Kc6SXP+0eaKr0kaLyxiHU8vwU0mwLUycjjGQwKXotaP069aEIdfQgdQcWstmp/6F O2gkbhKJMA9klun10fp/V4DnML5JYxANbV0vA= MIME-Version: 1.0 Received: by 10.227.72.213 with SMTP id n21mr37997wbj.66.1284041265768; Thu, 09 Sep 2010 07:07:45 -0700 (PDT) Received: by 10.216.27.204 with HTTP; Thu, 9 Sep 2010 07:07:45 -0700 (PDT) In-Reply-To: <201009090859.50251.hselasky@c2i.net> References: <201009090859.50251.hselasky@c2i.net> Date: Thu, 9 Sep 2010 07:07:45 -0700 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: silly libusbhid question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:07:47 -0000 On Wed, Sep 8, 2010 at 11:59 PM, Hans Petter Selasky wrote: > >> In kernel and userspace this is currently a feature in the HID libraries. > > And I agree that maybe this should be changed. Before changing anything please > grep the kernel sources for this function and check that no callers are using > this feature, or add this missing 1 << hid_collection mask. thanks for the answer! i was not going to change anything, not immediately at least :) someone pointed me at a bluetooth mouse with a somewhat "interesting" hid descriptor, i.e. hid descriptor = { 0x05 0x01 0x09 0x02 0xa1 0x01 0x85 0x03 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x05 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x05 0x81 0x02 0x75 0x03 0x95 0x01 0x81 0x01 0x05 0x01 0x09 0x30 0x09 0x31 0x16 0x00 0x80 0x26 0xff 0x7f 0x75 0x10 0x95 0x02 0x81 0x06 0xa1 0x02 0x85 0x03 0x05 0x01 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01 0x81 0x06 0xc0 0xa1 0x02 0x85 0x03 0x05 0x0c 0x0a 0x38 0x02 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01 0x81 0x06 0xc0 0xc0 0xc0 } which (if i did everything right) decodes to Collection page=Generic_Desktop usage=Mouse Collection page=Generic_Desktop usage=Pointer Input id=3 size=1 count=1 page=Button usage=Button_1 Variable, logical range 0..1 Input id=3 size=1 count=1 page=Button usage=Button_2 Variable, logical range 0..1 Input id=3 size=1 count=1 page=Button usage=Button_3 Variable, logical range 0..1 Input id=3 size=1 count=1 page=Button usage=Button_4 Variable, logical range 0..1 Input id=3 size=1 count=1 page=Button usage=Button_5 Variable, logical range 0..1 Input id=3 size=16 count=1 page=Generic_Desktop usage=X Variable Relative, logical range -32768..32767 Input id=3 size=16 count=1 page=Generic_Desktop usage=Y Variable Relative, logical range -32768..32767 Collection page=Generic_Desktop usage=Y Input id=3 size=8 count=1 page=Generic_Desktop usage=Wheel Variable Relative, logical range -127..127 End collection Collection page=Generic_Desktop usage=Wheel Input id=3 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, logical range -127..127 End collection End collection End collection please notice two nested collections one with usage "Y" and another with usage "Wheel". the problem is that when for (d = hid_start_parse(desc, 1 << hid_input, -1); hid_get_item(d, &h) > 0; ) { switch(page) { case Generic_Desktop: switch(usage) { case X: break; case Y: break; case Wheel: break; } break; } } hid_end_parse(d); code used to parse the descriptor and extract data from input reports, "page" and "usage" on collection items override data from real input items :( so it looks like we are getting two "X" and two "Wheel" values -- one from real input item (which comes first) and then one from collection item (which comes after and has garbage value in it). in any case, workaround is quite simple (please see my latest commit to bthidd(8)), i.e. just check h.kind and make sure it set to hid_input. thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:29:13 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 4A80A10656B9; Thu, 9 Sep 2010 14:29:13 +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 1A46C8FC12; Thu, 9 Sep 2010 14:29:13 +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 8BD0946B03; Thu, 9 Sep 2010 10:29:12 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F5258A03C; Thu, 9 Sep 2010 10:29:06 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Weongyo Jeong Date: Thu, 9 Sep 2010 09:36:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100908201419.GF1328@weongyo> In-Reply-To: <20100908201419.GF1328@weongyo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009090936.19412.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 10:29:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:29:13 -0000 On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > Hello, > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > when it's initialized so I always encounters the following LOR > > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_xlock() at _sx_xlock+0x55 > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > axe_cmd() at axe_cmd+0xc7 > axe_setmulti_locked() at axe_setmulti_locked+0x70 > axe_setmulti() at axe_setmulti+0x3e > axe_ioctl() at axe_ioctl+0x132 > if_addmulti() at if_addmulti+0x19b > in_joingroup_locked() at in_joingroup_locked+0x1bc > in_joingroup() at in_joingroup+0x52 > in_control() at in_control+0x1144 > ifioctl() at ifioctl+0x1118 > kern_ioctl() at kern_ioctl+0xbe > ioctl() at ioctl+0xfd > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > > when I uses the following code at driver's ioctl routine: > > case SIOCADDMULTI: > case SIOCDELMULTI: > axe_setmulti(sc, 0); > break; > > It means that USB driver always should defer SIOCADDMULTI / > SIOCDELMULTI handling to the other process context to avoid LOR. > > My question is that is it safe if the multicasting operations for USB > device happens without IN_MULTI_LOCK? Or is there any race cases if the > task is deferred? Why is USB using an sx lock instead of a mutex? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:29:13 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 4A80A10656B9; Thu, 9 Sep 2010 14:29:13 +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 1A46C8FC12; Thu, 9 Sep 2010 14:29:13 +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 8BD0946B03; Thu, 9 Sep 2010 10:29:12 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F5258A03C; Thu, 9 Sep 2010 10:29:06 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Weongyo Jeong Date: Thu, 9 Sep 2010 09:36:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100908201419.GF1328@weongyo> In-Reply-To: <20100908201419.GF1328@weongyo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009090936.19412.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 10:29:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:29:13 -0000 On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > Hello, > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > when it's initialized so I always encounters the following LOR > > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_xlock() at _sx_xlock+0x55 > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > axe_cmd() at axe_cmd+0xc7 > axe_setmulti_locked() at axe_setmulti_locked+0x70 > axe_setmulti() at axe_setmulti+0x3e > axe_ioctl() at axe_ioctl+0x132 > if_addmulti() at if_addmulti+0x19b > in_joingroup_locked() at in_joingroup_locked+0x1bc > in_joingroup() at in_joingroup+0x52 > in_control() at in_control+0x1144 > ifioctl() at ifioctl+0x1118 > kern_ioctl() at kern_ioctl+0xbe > ioctl() at ioctl+0xfd > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > > when I uses the following code at driver's ioctl routine: > > case SIOCADDMULTI: > case SIOCDELMULTI: > axe_setmulti(sc, 0); > break; > > It means that USB driver always should defer SIOCADDMULTI / > SIOCDELMULTI handling to the other process context to avoid LOR. > > My question is that is it safe if the multicasting operations for USB > device happens without IN_MULTI_LOCK? Or is there any race cases if the > task is deferred? Why is USB using an sx lock instead of a mutex? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 16:36: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 1D14B10656B6 for ; Thu, 9 Sep 2010 16:36:09 +0000 (UTC) (envelope-from gordon.tetlow@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 C7E468FC12 for ; Thu, 9 Sep 2010 16:36:08 +0000 (UTC) Received: by iwn34 with SMTP id 34so1447825iwn.13 for ; Thu, 09 Sep 2010 09:36:08 -0700 (PDT) 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:content-type; bh=q2DQGnZsT04M2hdxOU5+S6K7W1p+8rI6VEuOm4D231A=; b=fK7yaXMjCZe2ufQc/0PfzEKTU6dEALDiEjWK/9dKf+vkMrbAjfpqzMHaYwfl+3GH9P HXz/QHF4eD3TP2osre4m8Yp5eq4/8lcxzHRj1DKsKxPgSzSCGnzIgPQBrSfSUm8ndXpo bG6KEfmHnGnONnO4qNe40toxRcbE/OMCDXf4g= 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:content-type; b=WNyUHlLUyTjZs39eFgrRr5Plkjcfnvn/sZK6oYWa5Wr1hKntoIs1fij1lRt7X02T25 wIXh8K7DOk4hID+eGmGPAic2Q9vgbsQwtva5UkM+PJH8zwQdkn1h+UIC7aDsrVwi/dUm jjfTEB+zVgSbZkqaxVoJ4OUF4tChbB9bIlAxE= MIME-Version: 1.0 Received: by 10.231.191.147 with SMTP id dm19mr11880836ibb.6.1284050167907; Thu, 09 Sep 2010 09:36:07 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Thu, 9 Sep 2010 09:36:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Sep 2010 09:36:07 -0700 X-Google-Sender-Auth: T29WIxA6J0M3rc6Bm8bUc2oohRs Message-ID: From: Gordon Tetlow To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:36:09 -0000 On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow wrote: > All, > > I sat down and rewrote the man tools from a relatively old codebase to a > single shell script. My original motivation was to allow multiple > configuration files so port installations did not have to mess with > /etc/manpath.config (like perl for example) when needing to manipulate the > manpath. After looking at the existing code, I figured I could rewrite it as > a shell script relatively easily. > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > /usr/bin/whatis) > http://people.freebsd.org/~gordon/man.sh > > Features of the new code: > > 1. BSD licensed (old code is GPL). > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > (purposefully changed the manpath.config file since it is a different > syntax). > 3. Allows ports to override the toolset used to display the manpage based > on language. This was done to try to merge the functionality of the > japanese/man port into the base system as much as possible. > > I've tried to make this mirror the functionality, directory search order, > and arguments as the current base implementation. > > This brings me to my next point. I need some testers willing to try this > out. It would be particularly great if I could get some foreign language > testers with localized manpage installations. If something doesn't work the > way you expect, please contact me and I can help debug it (using man -ddd > will generally give me the debug information I need). > I have a new set for testing: http://people.freebsd.org/~gordon/man.shar This is going to be my final set before I commit it into the tree, barring any showstoppers. Now includes manpage documentation for the various parts of the new utilities. To install: # sh man.shar # make # make -DBINDIR=/usr/bin install Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages would be appreciated. I'm new to manpage authoring and could use a review. Please let me know if you have any questions. Thanks, Gordon From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 17:41:48 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 5C4E010656DC for ; Thu, 9 Sep 2010 17:41:48 +0000 (UTC) (envelope-from weongyo.jeong@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 D6B488FC0C for ; Thu, 9 Sep 2010 17:41:47 +0000 (UTC) Received: by fxm4 with SMTP id 4so1265559fxm.13 for ; Thu, 09 Sep 2010 10:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=M+IKw3sJL0pgZ7n5k/U4zWRx6B8xly5A8jvke2vTaXA=; b=tDR9ld0C9ehZEx1vDInOW+1ecaGUDpLg8m8UMfMXTjMc3BqlJdLz8ISm01CnatnBFe atZ4YEJl3MCIDPURfFj3A7C1jXHQ8aguQ5yElNZ1tZYgKa3TLVZvYrtqN8Nvgqut0ICl kc0OgWtjEhfUnCU8z302XiBOyyasBLDGOmjqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=EFrJwzadxM7vosmURzALG5U+zYO2mAH1bu1nkJNPr+bLiPTtWau1Lq6+Hxy9wg2B8p wg3s7XH4QOf0OC8N8fTaVituZButQmBm8AedgXqASyxtTddKUseP6vPxYHXvn3B5x9a2 pd2OGJjhqYG7mk9qR9MASAOf7OlsPBJTeV5Gs= Received: by 10.223.121.7 with SMTP id f7mr91370far.13.1284054106236; Thu, 09 Sep 2010 10:41:46 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id b36sm848601faq.11.2010.09.09.10.41.43 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 10:41:45 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Thu, 9 Sep 2010 10:41:46 -0700 From: Weongyo Jeong Date: Thu, 9 Sep 2010 10:41:46 -0700 To: John Baldwin Message-ID: <20100909174146.GG1328@weongyo> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org, current@freebsd.org References: <20100908201419.GF1328@weongyo> <201009090936.19412.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009090936.19412.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong 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 Sep 2010 17:41:48 -0000 On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > Hello, > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > when it's initialized so I always encounters the following LOR > > > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > netinet/in_mcast.c:1095 > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_xlock() at _sx_xlock+0x55 > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > axe_cmd() at axe_cmd+0xc7 > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > axe_setmulti() at axe_setmulti+0x3e > > axe_ioctl() at axe_ioctl+0x132 > > if_addmulti() at if_addmulti+0x19b > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > in_joingroup() at in_joingroup+0x52 > > in_control() at in_control+0x1144 > > ifioctl() at ifioctl+0x1118 > > kern_ioctl() at kern_ioctl+0xbe > > ioctl() at ioctl+0xfd > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > when I uses the following code at driver's ioctl routine: > > > > case SIOCADDMULTI: > > case SIOCDELMULTI: > > axe_setmulti(sc, 0); > > break; > > > > It means that USB driver always should defer SIOCADDMULTI / > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > My question is that is it safe if the multicasting operations for USB > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > task is deferred? > > Why is USB using an sx lock instead of a mutex? Frankly speaking I also don't know why hps@ uses sx lock. That is one of things I'd like to change it. Just looking the comment at usb_request.c@441: /* * Grab the default sx-lock so that serialisation * is achieved when multiple threads are involved: */ sx_xlock(&udev->ctrl_sx); I think he might want to hold the lock even if the thread is going into sleep. It might be for serialization. However even if we succeed to change the lock from sx to mutex, it's hard to avoid the requests going into the sleep. It means USB stack should call like below: mtx_sleep(chan, IN_MULTI_LOCK, ...); to avoid the kernel's complain (would be `sleep with holding non-sleepable lock'). What I'd like to say is that the sleeping is big problem if mutex is used that it'd be worse when multiple mutex locks are used. So I'm looking for a fundamental solution to solve this problem. Welcomes any ideas. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 18:08: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 943AF1065670; Thu, 9 Sep 2010 18:08:53 +0000 (UTC) (envelope-from weongyo.jeong@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 EB5AE8FC0A; Thu, 9 Sep 2010 18:08:52 +0000 (UTC) Received: by fxm4 with SMTP id 4so1297214fxm.13 for ; Thu, 09 Sep 2010 11:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=M+IKw3sJL0pgZ7n5k/U4zWRx6B8xly5A8jvke2vTaXA=; b=tDR9ld0C9ehZEx1vDInOW+1ecaGUDpLg8m8UMfMXTjMc3BqlJdLz8ISm01CnatnBFe atZ4YEJl3MCIDPURfFj3A7C1jXHQ8aguQ5yElNZ1tZYgKa3TLVZvYrtqN8Nvgqut0ICl kc0OgWtjEhfUnCU8z302XiBOyyasBLDGOmjqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=EFrJwzadxM7vosmURzALG5U+zYO2mAH1bu1nkJNPr+bLiPTtWau1Lq6+Hxy9wg2B8p wg3s7XH4QOf0OC8N8fTaVituZButQmBm8AedgXqASyxtTddKUseP6vPxYHXvn3B5x9a2 pd2OGJjhqYG7mk9qR9MASAOf7OlsPBJTeV5Gs= Received: by 10.223.121.7 with SMTP id f7mr91370far.13.1284054106236; Thu, 09 Sep 2010 10:41:46 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id b36sm848601faq.11.2010.09.09.10.41.43 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 10:41:45 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Thu, 9 Sep 2010 10:41:46 -0700 From: Weongyo Jeong Date: Thu, 9 Sep 2010 10:41:46 -0700 To: John Baldwin Message-ID: <20100909174146.GG1328@weongyo> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org, current@freebsd.org References: <20100908201419.GF1328@weongyo> <201009090936.19412.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009090936.19412.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong 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 Sep 2010 18:08:53 -0000 On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > Hello, > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > when it's initialized so I always encounters the following LOR > > > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > netinet/in_mcast.c:1095 > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_xlock() at _sx_xlock+0x55 > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > axe_cmd() at axe_cmd+0xc7 > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > axe_setmulti() at axe_setmulti+0x3e > > axe_ioctl() at axe_ioctl+0x132 > > if_addmulti() at if_addmulti+0x19b > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > in_joingroup() at in_joingroup+0x52 > > in_control() at in_control+0x1144 > > ifioctl() at ifioctl+0x1118 > > kern_ioctl() at kern_ioctl+0xbe > > ioctl() at ioctl+0xfd > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > when I uses the following code at driver's ioctl routine: > > > > case SIOCADDMULTI: > > case SIOCDELMULTI: > > axe_setmulti(sc, 0); > > break; > > > > It means that USB driver always should defer SIOCADDMULTI / > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > My question is that is it safe if the multicasting operations for USB > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > task is deferred? > > Why is USB using an sx lock instead of a mutex? Frankly speaking I also don't know why hps@ uses sx lock. That is one of things I'd like to change it. Just looking the comment at usb_request.c@441: /* * Grab the default sx-lock so that serialisation * is achieved when multiple threads are involved: */ sx_xlock(&udev->ctrl_sx); I think he might want to hold the lock even if the thread is going into sleep. It might be for serialization. However even if we succeed to change the lock from sx to mutex, it's hard to avoid the requests going into the sleep. It means USB stack should call like below: mtx_sleep(chan, IN_MULTI_LOCK, ...); to avoid the kernel's complain (would be `sleep with holding non-sleepable lock'). What I'd like to say is that the sleeping is big problem if mutex is used that it'd be worse when multiple mutex locks are used. So I'm looking for a fundamental solution to solve this problem. Welcomes any ideas. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:17:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A33FA10656CC; Thu, 9 Sep 2010 19:17:50 +0000 (UTC) Date: Thu, 9 Sep 2010 19:17:50 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100909191750.GA58228@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:17:50 -0000 hi there, except for arm most archs seem to enforce uart support in conf/DEFAULTS. is this really necessary? shouldn't DEFAULTS only contain vital devices/options without a kernel on a specific arch won't function at all? cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:41:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3228210656EB; Thu, 9 Sep 2010 19:41:09 +0000 (UTC) Date: Thu, 9 Sep 2010 19:41:09 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100909194109.GA64914@freebsd.org> References: <20100909191750.GA58228@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909191750.GA58228@freebsd.org> Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:41:09 -0000 On Thu Sep 9 10, Alexander Best wrote: > hi there, > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > this really necessary? shouldn't DEFAULTS only contain vital devices/options > without a kernel on a specific arch won't function at all? jhb just explained to me, that the uart entry in DEFAULTS is not a controller or something like that, but the uart backend to use *if* uart gets defined in the kernel config. sorry for the noise folks. cheers. alex > > cheers. > alex > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:50:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D3A4210656E8; Thu, 9 Sep 2010 19:50:45 +0000 (UTC) Date: Thu, 9 Sep 2010 19:50:45 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100909195045.GA68352@freebsd.org> References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20100909194109.GA64914@freebsd.org> Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:50:45 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu Sep 9 10, Alexander Best wrote: > On Thu Sep 9 10, Alexander Best wrote: > > hi there, > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > without a kernel on a specific arch won't function at all? > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > or something like that, but the uart backend to use *if* uart gets defined in > the kernel config. > > sorry for the noise folks. however i found some missing comments and incorrect syntax which i fixed. see the attached patch. cheers. alex > > cheers. > alex > > > > > cheers. > > alex > > > > -- > > a13x > > -- > a13x -- a13x --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="DEFAULTS.diff" diff --git a/sys/amd64/conf/DEFAULTS b/sys/amd64/conf/DEFAULTS index 1fb52b3..e942c1a 100644 --- a/sys/amd64/conf/DEFAULTS +++ b/sys/amd64/conf/DEFAULTS @@ -5,10 +5,10 @@ machine amd64 -# Bus support. +# Bus support device isa -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices device io # I/O device diff --git a/sys/arm/conf/DEFAULTS b/sys/arm/conf/DEFAULTS index 591a0a1..5e1512f 100644 --- a/sys/arm/conf/DEFAULTS +++ b/sys/arm/conf/DEFAULTS @@ -5,7 +5,9 @@ machine arm -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_MBR diff --git a/sys/i386/conf/DEFAULTS b/sys/i386/conf/DEFAULTS index 32e77e4..b780472 100644 --- a/sys/i386/conf/DEFAULTS +++ b/sys/i386/conf/DEFAULTS @@ -5,14 +5,14 @@ machine i386 -# Bus support. +# Bus support device isa options ISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices device io # I/O device diff --git a/sys/ia64/conf/DEFAULTS b/sys/ia64/conf/DEFAULTS index 2cb2330..88119b0 100644 --- a/sys/ia64/conf/DEFAULTS +++ b/sys/ia64/conf/DEFAULTS @@ -5,16 +5,17 @@ machine ia64 -# Bus support. +# Bus support device acpi # ACPI support -# Pseudo devices. -device io # I/O & EFI runtime device +# Pseudo devices device mem # Memory and kernel memory devices +device io # I/O & EFI runtime device # UART chips on this platform device uart_ns8250 +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_GPT options GEOM_PART_MBR diff --git a/sys/mips/conf/DEFAULTS b/sys/mips/conf/DEFAULTS index dc480ce..59e4442 100644 --- a/sys/mips/conf/DEFAULTS +++ b/sys/mips/conf/DEFAULTS @@ -5,9 +5,12 @@ machine mips -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# UART chips on this platform device uart_ns8250 +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_MBR diff --git a/sys/pc98/conf/DEFAULTS b/sys/pc98/conf/DEFAULTS index f30501e..527b861 100644 --- a/sys/pc98/conf/DEFAULTS +++ b/sys/pc98/conf/DEFAULTS @@ -6,14 +6,14 @@ machine pc98 i386 options PC98 -# Bus support. +# Bus support device isa options ISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices device io # I/O device diff --git a/sys/powerpc/conf/DEFAULTS b/sys/powerpc/conf/DEFAULTS index 658c221..195a78f 100644 --- a/sys/powerpc/conf/DEFAULTS +++ b/sys/powerpc/conf/DEFAULTS @@ -3,12 +3,15 @@ # # $FreeBSD$ -# Pseudo devices. +machine powerpc powerpc + +# Pseudo devices device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 device uart_z8530 +# Default partitioning schemes options GEOM_PART_APM options GEOM_PART_MBR diff --git a/sys/powerpc/conf/GENERIC b/sys/powerpc/conf/GENERIC index 891d9aa..36f3d66 100644 --- a/sys/powerpc/conf/GENERIC +++ b/sys/powerpc/conf/GENERIC @@ -21,8 +21,6 @@ cpu AIM ident GENERIC -machine powerpc powerpc - makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols # Platform support diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS index 38b2408..2e60c94 100644 --- a/sys/sparc64/conf/DEFAULTS +++ b/sys/sparc64/conf/DEFAULTS @@ -5,7 +5,7 @@ machine sparc64 -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices # UART chips on this platform @@ -17,5 +17,5 @@ device uart_z8530 options GEOM_PART_BSD options GEOM_PART_VTOC8 -# Let sunkbd emulate an AT keyboard by default. +# Let sunkbd emulate an AT keyboard by default options SUNKBD_EMULATE_ATKBD diff --git a/sys/sun4v/conf/DEFAULTS b/sys/sun4v/conf/DEFAULTS index 87a55ec..4c21bc9 100644 --- a/sys/sun4v/conf/DEFAULTS +++ b/sys/sun4v/conf/DEFAULTS @@ -5,7 +5,7 @@ machine sun4v sparc64 -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices # Default partitioning schemes --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:55:44 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 1E15810656D9 for ; Thu, 9 Sep 2010 19:55:44 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBE38FC0A for ; Thu, 9 Sep 2010 19:55:43 +0000 (UTC) Received: by ewy4 with SMTP id 4so1419792ewy.13 for ; Thu, 09 Sep 2010 12:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=ErZBTbmR+hQ13kqa9FlymjfSz1zBZY/4X3WZlW/4Nck=; b=E4Q17ZsjJnwMfZF0MBEbtMyOGrhLrt+XAr+BBeL3Mv8rBK8LujbMGJNdIF97242E6g 1jtl5Hm/wQiLDVVFtZqArV4oeBsfqN/lAe1TEWfjTpuNAeyRAZFC8eYU3bfbff0rfmSd 9YEVcYjpZRbqGdSt59uiZqgJbdRyderdaMZPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=C7iRaWN3u1dMrreIVy5RNJNG5akhj4sQPH1tfHrlQnrwPH82Wm/CDlftI0raMTlXqq c+RWCRKTEejIGjuZffFm67wu75xYPz3jo3UiIj83y57wFqPArp0WVzlulalxYU0b9D93 iKGmMiHfPI9yTpwzB3zXtufs4E/zSBgZa1wJg= Received: by 10.213.47.70 with SMTP id m6mr309021ebf.63.1284062142434; Thu, 09 Sep 2010 12:55:42 -0700 (PDT) Received: from localhost (tor-exit-proxy1-readme.formlessnetworking.net [208.53.142.37]) by mx.google.com with ESMTPS id u9sm2561043eeh.5.2010.09.09.12.55.39 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 12:55:40 -0700 (PDT) From: Anonymous To: Gordon Tetlow References: <86sk2b79oi.fsf@gmail.com> Date: Thu, 09 Sep 2010 23:48:37 +0400 In-Reply-To: (Gordon Tetlow's message of "Thu, 19 Aug 2010 00:45:46 -0700") Message-ID: <868w3aem0a.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 19:55:44 -0000 Gordon Tetlow writes: > Gordon Tetlow writes: >> Anonymous writes: >>> It doesn't search in bin/../man nor in bin/.man. For example, >>> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/ >>> manpath.config >>> is default one and contains /usr/local/man which does not >>> exist here. >> >> Guess I missed that pretty badly in my port. I'll go back and >> retool the logic for this but that'll take a bit of time. > > Added. Latest version at http://people.freebsd.org/~gordon/man.sh The order is still bogus compared to gnu man. If I don't like our ancient GNU tools and altered PATH in order to prefer ones from ports then I certainly don't want to view old manpages, too. The base manpath should be appended *after* any PATH substitutions. $ man -aw gperf # man.sh /usr/share/man/en.UTF-8/man1/gperf.1.gz /usr/share/man/man1/gperf.1.gz LOCALBASE/man/man1/gperf.1.gz $ man -aw gperf # gnu man LOCALBASE/man/man1/gperf.1.gz /usr/share/man/en.UTF-8/man1/gperf.1.gz > $ echo $PATH > LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin And it doesn't show anything when there are no arguments, not even returning with exit code > 0. $ man # man.sh $ man # gnu man What manual page do you want? zsh: exit 1 man > It's a slightly different heuristic than the existing man > implementation since I don't support the notion of MANPATH_MAP. > Here's the order: > > Default manpaths (/usr/share/man:/usr/share/openssl/man:/usr/local/ > man) > Parse $PATH (path/man:path/MAN:(if ending in /bin)path/../man) > Parse config files From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:19: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 3D73910656C5; Thu, 9 Sep 2010 20:19:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 011098FC08; Thu, 9 Sep 2010 20:19:32 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 577D61DD685; Thu, 9 Sep 2010 22:19:31 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 402FC172E5; Thu, 9 Sep 2010 22:19:31 +0200 (CEST) Date: Thu, 9 Sep 2010 22:19:31 +0200 From: Jilles Tjoelker To: Anonymous Message-ID: <20100909201931.GB48144@stack.nl> References: <86sk2b79oi.fsf@gmail.com> <868w3aem0a.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868w3aem0a.fsf@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Gordon Tetlow , freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 20:19:32 -0000 On Thu, Sep 09, 2010 at 11:48:37PM +0400, Anonymous wrote: > Gordon Tetlow writes: > > Gordon Tetlow writes: > >> Anonymous writes: > >>> It doesn't search in bin/../man nor in bin/.man. For example, > >>> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/ > >>> manpath.config > >>> is default one and contains /usr/local/man which does not > >>> exist here. > >> Guess I missed that pretty badly in my port. I'll go back and > >> retool the logic for this but that'll take a bit of time. > > Added. Latest version at http://people.freebsd.org/~gordon/man.sh > The order is still bogus compared to gnu man. If I don't like our > ancient GNU tools and altered PATH in order to prefer ones from ports > then I certainly don't want to view old manpages, too. The base manpath > should be appended *after* any PATH substitutions. That is appropriate, but to avoid breaking the more common setup with /usr/bin before /usr/local/bin, search_path needs to map the PATH directories /bin and /usr/bin to the man directory /usr/share/man. GNU man does the same, but it is written into /etc/manpath.config. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:51:15 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 1F47A10656CC; Thu, 9 Sep 2010 21:51:15 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE93F8FC15; Thu, 9 Sep 2010 21:51:14 +0000 (UTC) Received: by vws7 with SMTP id 7so2071481vws.13 for ; Thu, 09 Sep 2010 14:51:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.123.42 with SMTP id n42mr357064vcr.188.1284069073702; Thu, 09 Sep 2010 14:51:13 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Thu, 9 Sep 2010 14:51:13 -0700 (PDT) X-Originating-IP: [71.1.133.114] Date: Thu, 9 Sep 2010 14:51:13 -0700 Message-ID: From: Rob Farmer To: Pawel Jakub Dawidek , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: System reboots building mysql51-client with ZFS v28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 21:51:15 -0000 I am running a fairly recent current with the new ZFS patches: FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r212312M: Wed Sep 8 02:03:34 PDT 2010 rfarmer@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ amd64 When I try to build databases/mysql51-client from ports, the configure script runs for a while then prints: WARNING: Adding fix for interrupted reads Then the system reboots. The kernel doesn't panic or anything - the screen goes blank for about 5 seconds and the BIOS starts again. I have WITNESS and all the standard debugging stuff for current, plus the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo, 4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs /boot, everything else is zfs (one drive, no mirroring, no snapshots, nothing complex). Port is up to date: # $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25 09:07:27 ale Exp $ Not sure if this is ZFS related or not. What can I do to collect some useful information here? This can be reproduced reliably. Thanks, -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:56:18 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 7E992106575C; Thu, 9 Sep 2010 21:56:18 +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 26CDB8FC16; Thu, 9 Sep 2010 21:56:18 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id B5305A6B0C5; Fri, 10 Sep 2010 05:56:16 +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 l2Av7Zzc6nBX; Fri, 10 Sep 2010 05:56:10 +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 6DE0EA6A722; Fri, 10 Sep 2010 05:56:09 +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=TiPpj36S1OyTBiqmkjeMgHOuvwOCz28LaIKN2pX2hc9e/1a58O2ccSH7BRVQtn6n1 ApumjHJ5IggSdGRLNWQtA== Message-ID: <4C8957F5.8010405@delphij.net> Date: Thu, 09 Sep 2010 14:56:05 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Rob Farmer References: 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@freebsd.org, Pawel Jakub Dawidek Subject: Re: System reboots building mysql51-client with ZFS v28 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: Thu, 09 Sep 2010 21:56:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/09/09 14:51, Rob Farmer wrote: > I am running a fairly recent current with the new ZFS patches: > > FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > r212312M: Wed Sep 8 02:03:34 PDT 2010 > rfarmer@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ amd64 > > When I try to build databases/mysql51-client from ports, the configure > script runs for a while then prints: > WARNING: Adding fix for interrupted reads > > Then the system reboots. The kernel doesn't panic or anything - the > screen goes blank for about 5 seconds and the BIOS starts again. I > have WITNESS and all the standard debugging stuff for current, plus > the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS > patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo, > 4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs > /boot, everything else is zfs (one drive, no mirroring, no snapshots, > nothing complex). > > Port is up to date: > # $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25 > 09:07:27 ale Exp $ > > Not sure if this is ZFS related or not. What can I do to collect some > useful information here? This can be reproduced reliably. Just a guess - are you compiling under X? If so what about if you compile under text mode? 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) iQEcBAEBCAAGBQJMiVf1AAoJEATO+BI/yjfB3pEH+wfej2GHUwBj3F4yPZjnUiTZ B1X0FwzeWQWyRfl/FxF3X0LSH6s5Dc2y+QUd5e22yVfwUDV449+R53deCZesCtxm IWabVgQKFJQF3rgdnC+fAy2kY5kaMGH/s/Ifq2GJcx8YnVLBPKQRcKHgHKAJ05l6 0G/Mr8YfGBXS7UvQJvSGqnfhLJjufBEe6dk/NTl2zguPAgWeo2z9e0xud9LYXBbH RYGtFHzIxsvzTau4q8JVyvl6Uc5gNxvutNpOxwtWhX2lwbeqv2U+w1O9JjDCXP+e 5zLH3hffk0wKysEXPVx+ltkFzjCUCuNYIYDuvBX3V8QsYE7s4PT/J3Rmc2gX6fE= =mnSc -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:01: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 6F03910656EF; Thu, 9 Sep 2010 22:01:52 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0388FC21; Thu, 9 Sep 2010 22:01:51 +0000 (UTC) Received: by vws7 with SMTP id 7so2083910vws.13 for ; Thu, 09 Sep 2010 15:01:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.207 with SMTP id w15mr216726vcf.75.1284069710247; Thu, 09 Sep 2010 15:01:50 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Thu, 9 Sep 2010 15:01:50 -0700 (PDT) X-Originating-IP: [71.1.133.114] In-Reply-To: <4C8957F5.8010405@delphij.net> References: <4C8957F5.8010405@delphij.net> Date: Thu, 9 Sep 2010 15:01:50 -0700 Message-ID: From: Rob Farmer To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: System reboots building mysql51-client with ZFS v28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 22:01:52 -0000 On Thu, Sep 9, 2010 at 14:56, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/09/09 14:51, Rob Farmer wrote: >> I am running a fairly recent current with the new ZFS patches: >> >> FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0 >> r212312M: Wed Sep =A08 02:03:34 PDT 2010 >> rfarmer@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ =A0amd64 >> >> When I try to build databases/mysql51-client from ports, the configure >> script runs for a while then prints: >> WARNING: Adding fix for interrupted reads >> >> Then the system reboots. The kernel doesn't panic or anything - the >> screen goes blank for about 5 seconds and the BIOS starts again. I >> have WITNESS and all the standard debugging stuff for current, plus >> the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS >> patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo, >> 4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs >> /boot, everything else is zfs (one drive, no mirroring, no snapshots, >> nothing complex). >> >> Port is up to date: >> # $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25 >> 09:07:27 ale Exp $ >> >> Not sure if this is ZFS related or not. What can I do to collect some >> useful information here? This can be reproduced reliably. > > Just a guess - are you compiling under X? =A0If so what about if you > compile under text mode? Nope - this is a new install and X isn't running yet. It is installed, but not started yet. I ran across this building dependencies for KDE (why a desktop requires MySQL server is beyond me, but anyways). --=20 Rob Farmer > > Cheers, > - -- > Xin LI =A0 =A0http://www.delphij.net/ > FreeBSD - The Power to Serve! =A0 =A0 =A0 =A0 =A0Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (FreeBSD) > > iQEcBAEBCAAGBQJMiVf1AAoJEATO+BI/yjfB3pEH+wfej2GHUwBj3F4yPZjnUiTZ > B1X0FwzeWQWyRfl/FxF3X0LSH6s5Dc2y+QUd5e22yVfwUDV449+R53deCZesCtxm > IWabVgQKFJQF3rgdnC+fAy2kY5kaMGH/s/Ifq2GJcx8YnVLBPKQRcKHgHKAJ05l6 > 0G/Mr8YfGBXS7UvQJvSGqnfhLJjufBEe6dk/NTl2zguPAgWeo2z9e0xud9LYXBbH > RYGtFHzIxsvzTau4q8JVyvl6Uc5gNxvutNpOxwtWhX2lwbeqv2U+w1O9JjDCXP+e > 5zLH3hffk0wKysEXPVx+ltkFzjCUCuNYIYDuvBX3V8QsYE7s4PT/J3Rmc2gX6fE=3D > =3DmnSc > -----END PGP SIGNATURE----- > From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:12: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 B83C8106571E for ; Thu, 9 Sep 2010 22:12:21 +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 7CC528FC0A for ; Thu, 9 Sep 2010 22:12:21 +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 o89MCL0B001753 for ; Thu, 9 Sep 2010 15:12:21 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o89MCLm8001752 for freebsd-current@freebsd.org; Thu, 9 Sep 2010 15:12:21 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Sep 2010 15:12:21 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20100909221221.GA1585@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: SU+J deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 22:12:21 -0000 My system locked up without panicking. Neither access from the console nor via ssh from another terminal worked. The only recourse was a power cycle. % uname -a FreeBSD troutmask.apl.washington.edu 9.0-CURRENT r211766M: Tue Aug 24 14:52:25 PDT 2010 kargl@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 Upon rebooting, I entered single user mode. The hand transcribed session is # fsck -y ** SU+J Recovering /dev/ad6s1f ** Reading 33554422 byte journal from inode 4 RECOVER? yes ** Building recovery table ** Resolving unreferenced inode list ** Processing journal entries Bad cg number 6296367 UNEXPECTED SU+J INCONSISTENCY FALLBACK TO FULL FSCK? yes ** Skipping journal, falling through to full fsck ** Last Mounted on /usr ** Phase 1 - Check Block and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=38437143 OWNER=sgk MODE=100600 SIZE=536576 MTIME=Sep 9 14:30 2010 RECONNECT? yes No lost+found DIRECTORY CREATE? yes ** Phase 5 - Check cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes 1188338 files, 76416941 used, 150441439 free At point, 'fsck -y' proceeded to clean up the other filesystems and I rebooted. Note, OWNER=sgk was hammering the filesystem by running the GCC testsuite to test the recent libelf changes. The only file moved to lost+found is troutmask:root[204] cd lost+found/ troutmask:root[205] ls #38437143 troutmask:root[206] file #38437143 #38437143: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from '-1.exe' which is from GCC testing. This is the 2nd such lock up in the past 2 weeks. If there are any kernel options that will help aid in debugging this problem, I'll turn them on. Just ask. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:14:11 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 9BB601065723; Thu, 9 Sep 2010 22:14:11 +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 64DAF8FC1D; Thu, 9 Sep 2010 22:14:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o89MEAXW077235; Thu, 9 Sep 2010 18:14:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o89MEA0b077227; Thu, 9 Sep 2010 22:14:10 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 22:14:10 GMT Message-Id: <201009092214.o89MEA0b077227@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: Thu, 09 Sep 2010 22:14:11 -0000 TB --- 2010-09-09 20:57:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 20:57:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-09-09 20:57:00 - cleaning the object tree TB --- 2010-09-09 20:57:21 - cvsupping the source tree TB --- 2010-09-09 20:57:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-09-09 20:57:57 - building world TB --- 2010-09-09 20:57:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 20:57:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 20:57:57 - TARGET=sparc64 TB --- 2010-09-09 20:57:57 - TARGET_ARCH=sparc64 TB --- 2010-09-09 20:57:57 - TZ=UTC TB --- 2010-09-09 20:57:57 - __MAKE_CONF=/dev/null TB --- 2010-09-09 20:57:57 - cd /src TB --- 2010-09-09 20:57:57 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 20:57:57 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 9 22:07:14 UTC 2010 TB --- 2010-09-09 22:07:14 - generating LINT kernel config TB --- 2010-09-09 22:07:14 - cd /src/sys/sparc64/conf TB --- 2010-09-09 22:07:14 - /usr/bin/make -B LINT TB --- 2010-09-09 22:07:14 - building LINT kernel TB --- 2010-09-09 22:07:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 22:07:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 22:07:14 - TARGET=sparc64 TB --- 2010-09-09 22:07:14 - TARGET_ARCH=sparc64 TB --- 2010-09-09 22:07:14 - TZ=UTC TB --- 2010-09-09 22:07:14 - __MAKE_CONF=/dev/null TB --- 2010-09-09 22:07:14 - cd /src TB --- 2010-09-09 22:07:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 9 22:07:14 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mpt/mpt_user.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/msk/if_msk.c /src/sys/dev/msk/if_msk.c: In function 'mskc_reset': /src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) /src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported only once /src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.) /src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr': /src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 22:14:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 22:14:10 - ERROR: failed to build lint kernel TB --- 2010-09-09 22:14:10 - 3074.12 user 961.33 system 4629.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22: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 BC10510656E7; Thu, 9 Sep 2010 22:15:08 +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 62A718FC15; Thu, 9 Sep 2010 22:15:08 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 6520BA6B0D4; Fri, 10 Sep 2010 06:15:07 +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 RGQ1jKNdnNuA; Fri, 10 Sep 2010 06:15:00 +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 95CCEA6A722; Fri, 10 Sep 2010 06:14:48 +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=w/ipIlomObJb4+UN7yTGZhYPpOnUy75zgjM3UGCn7ah0wsCxzl1BfhMvAu3F6ZnH6 vR1vAAZD3bro6ozNZ2zww== Message-ID: <4C895C53.2070602@delphij.net> Date: Thu, 09 Sep 2010 15:14:43 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Rob Farmer References: <4C8957F5.8010405@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: Pawel Jakub Dawidek , freebsd-current@freebsd.org, d@delphij.net Subject: Re: System reboots building mysql51-client with ZFS v28 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: Thu, 09 Sep 2010 22:15:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Rob, On 2010/09/09 15:01, Rob Farmer wrote: [...] >> Just a guess - are you compiling under X? If so what about if you >> compile under text mode? > > Nope - this is a new install and X isn't running yet. It is installed, > but not started yet. I ran across this building dependencies for KDE > (why a desktop requires MySQL server is beyond me, but anyways). I just tried to compile MySQL 5.1 client but it passed on my test system (the compile time option is slightly different as the VFS debugging is not yet enabled). I'll do another round of test with these VFS options enabled. 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) iQEcBAEBCAAGBQJMiVxTAAoJEATO+BI/yjfBrdwIALykmtHrgpaARlkBxAzzQFdu +Ab0gvTBVrWMsyRHYqZgVhcD35ft80ItqYZOwH86/y1pqrvYTGXaexDMXDjwaG3/ 9C7G73ZiKPWeEH7v0u1rInh8Ajz4+ZHjtpVRLBobk0Ef2F8pCU/0Yy3aLxa3z4Z4 C2ej6oA/jznqnk+76Iu+RyURV7Nb460uRYK5hB6iSSGDsYvdUYCUp0fFPHe3w5N4 aqhIZyGTo5MF/fgEmSXyWIHYvjiaj6IGSDILY0ju15HJajGmmkvSOo5wmxZWGGYH jzskx5yUuv4ZAhZPCNeWPAgR2rWidgQ1k+95NZO7IvrXfMbUxh1oOe+fU31ukNc= =jxCL -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:16: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 9CE28106564A; Thu, 9 Sep 2010 22:16: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 66AB48FC17; Thu, 9 Sep 2010 22:16:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o89MGrD4089208; Thu, 9 Sep 2010 18:16:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o89MGrXu089207; Thu, 9 Sep 2010 22:16:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 22:16:53 GMT Message-Id: <201009092216.o89MGrXu089207@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: Thu, 09 Sep 2010 22:16:54 -0000 TB --- 2010-09-09 20:23:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 20:23:24 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-09 20:23:24 - cleaning the object tree TB --- 2010-09-09 20:23:47 - cvsupping the source tree TB --- 2010-09-09 20:23:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-09 20:24:10 - building world TB --- 2010-09-09 20:24:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 20:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 20:24:10 - TARGET=powerpc TB --- 2010-09-09 20:24:10 - TARGET_ARCH=powerpc TB --- 2010-09-09 20:24:10 - TZ=UTC TB --- 2010-09-09 20:24:10 - __MAKE_CONF=/dev/null TB --- 2010-09-09 20:24:10 - cd /src TB --- 2010-09-09 20:24:10 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 20:24:11 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 9 22:10:31 UTC 2010 TB --- 2010-09-09 22:10:31 - generating LINT kernel config TB --- 2010-09-09 22:10:31 - cd /src/sys/powerpc/conf TB --- 2010-09-09 22:10:31 - /usr/bin/make -B LINT TB --- 2010-09-09 22:10:31 - building LINT kernel TB --- 2010-09-09 22:10:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 22:10:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 22:10:31 - TARGET=powerpc TB --- 2010-09-09 22:10:31 - TARGET_ARCH=powerpc TB --- 2010-09-09 22:10:31 - TZ=UTC TB --- 2010-09-09 22:10:31 - __MAKE_CONF=/dev/null TB --- 2010-09-09 22:10:31 - cd /src TB --- 2010-09-09 22:10:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 9 22:10:32 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mpt/mpt_user.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/msk/if_msk.c /src/sys/dev/msk/if_msk.c: In function 'mskc_reset': /src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) /src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported only once /src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.) /src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr': /src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 22:16:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 22:16:53 - ERROR: failed to build lint kernel TB --- 2010-09-09 22:16:53 - 4857.24 user 1186.71 system 6808.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:28: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 161761065679; Thu, 9 Sep 2010 22:28:16 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC4B8FC12; Thu, 9 Sep 2010 22:28:15 +0000 (UTC) Received: by vws7 with SMTP id 7so2113657vws.13 for ; Thu, 09 Sep 2010 15:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.207 with SMTP id w15mr236220vcf.75.1284071294548; Thu, 09 Sep 2010 15:28:14 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Thu, 9 Sep 2010 15:28:14 -0700 (PDT) X-Originating-IP: [71.1.133.114] In-Reply-To: <4C895C53.2070602@delphij.net> References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@delphij.net> Date: Thu, 9 Sep 2010 15:28:14 -0700 Message-ID: From: Rob Farmer To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: System reboots building mysql51-client with ZFS v28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 22:28:16 -0000 On Thu, Sep 9, 2010 at 15:14, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, Rob, > > On 2010/09/09 15:01, Rob Farmer wrote: > [...] >>> Just a guess - are you compiling under X? =A0If so what about if you >>> compile under text mode? >> >> Nope - this is a new install and X isn't running yet. It is installed, >> but not started yet. I ran across this building dependencies for KDE >> (why a desktop requires MySQL server is beyond me, but anyways). > > I just tried to compile MySQL 5.1 client but it passed on my test system > (the compile time option is slightly different as the VFS debugging is > not yet enabled). =A0I'll do another round of test with these VFS options > enabled. Ok - so I shut the system down for about 15 minutes and then tried again and it worked. So maybe it was heat or something - I had reproduced it about 5 times back to back at the exact same spot. I didn't think this laptop had cooling problems but I will keep a closer eye on it in the future. Sorry about the noise. --=20 Rob Farmer > > Cheers, > - -- > Xin LI =A0 =A0http://www.delphij.net/ > FreeBSD - The Power to Serve! =A0 =A0 =A0 =A0 =A0Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (FreeBSD) > > iQEcBAEBCAAGBQJMiVxTAAoJEATO+BI/yjfBrdwIALykmtHrgpaARlkBxAzzQFdu > +Ab0gvTBVrWMsyRHYqZgVhcD35ft80ItqYZOwH86/y1pqrvYTGXaexDMXDjwaG3/ > 9C7G73ZiKPWeEH7v0u1rInh8Ajz4+ZHjtpVRLBobk0Ef2F8pCU/0Yy3aLxa3z4Z4 > C2ej6oA/jznqnk+76Iu+RyURV7Nb460uRYK5hB6iSSGDsYvdUYCUp0fFPHe3w5N4 > aqhIZyGTo5MF/fgEmSXyWIHYvjiaj6IGSDILY0ju15HJajGmmkvSOo5wmxZWGGYH > jzskx5yUuv4ZAhZPCNeWPAgR2rWidgQ1k+95NZO7IvrXfMbUxh1oOe+fU31ukNc=3D > =3DjxCL > -----END PGP SIGNATURE----- > From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:29:46 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 CF0EF1065675; Thu, 9 Sep 2010 22:29:46 +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 7ECC18FC17; Thu, 9 Sep 2010 22:29:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o89MTjwv052362; Thu, 9 Sep 2010 18:29:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o89MTjTs052361; Thu, 9 Sep 2010 22:29:45 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 22:29:45 GMT Message-Id: <201009092229.o89MTjTs052361@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: Thu, 09 Sep 2010 22:29:47 -0000 TB --- 2010-09-09 21:15:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 21:15:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-09-09 21:15:35 - cleaning the object tree TB --- 2010-09-09 21:16:03 - cvsupping the source tree TB --- 2010-09-09 21:16:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-09-09 21:16:35 - building world TB --- 2010-09-09 21:16:35 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 21:16:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 21:16:35 - TARGET=sun4v TB --- 2010-09-09 21:16:35 - TARGET_ARCH=sparc64 TB --- 2010-09-09 21:16:35 - TZ=UTC TB --- 2010-09-09 21:16:35 - __MAKE_CONF=/dev/null TB --- 2010-09-09 21:16:35 - cd /src TB --- 2010-09-09 21:16:35 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 21:16: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 9 22:24:00 UTC 2010 TB --- 2010-09-09 22:24:00 - generating LINT kernel config TB --- 2010-09-09 22:24:00 - cd /src/sys/sun4v/conf TB --- 2010-09-09 22:24:00 - /usr/bin/make -B LINT TB --- 2010-09-09 22:24:00 - building LINT kernel TB --- 2010-09-09 22:24:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 22:24:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 22:24:00 - TARGET=sun4v TB --- 2010-09-09 22:24:00 - TARGET_ARCH=sparc64 TB --- 2010-09-09 22:24:00 - TZ=UTC TB --- 2010-09-09 22:24:00 - __MAKE_CONF=/dev/null TB --- 2010-09-09 22:24:00 - cd /src TB --- 2010-09-09 22:24:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 9 22:24:00 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mpt/mpt_user.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/msk/if_msk.c /src/sys/dev/msk/if_msk.c: In function 'mskc_reset': /src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) /src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported only once /src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.) /src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr': /src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 22:29:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 22:29:45 - ERROR: failed to build lint kernel TB --- 2010-09-09 22:29:45 - 3042.69 user 921.43 system 4450.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:33:18 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 A2680106566B; Thu, 9 Sep 2010 22:33:18 +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 349EE8FC1A; Thu, 9 Sep 2010 22:33:18 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 2DBF3A56B76; Fri, 10 Sep 2010 06:33:17 +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 btLAGdT64C78; Fri, 10 Sep 2010 06:33:06 +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 E429FA56304; Fri, 10 Sep 2010 06:33:04 +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=avHd7wWo7F1g7evwfphTDQzHOKeaP0M9P5F90RdaC/zIa8+1J5ShvtZPwOk9EKqmZ 0kXp7Gg66/jUNnYnQsQiA== Message-ID: <4C89609D.2070201@delphij.net> Date: Thu, 09 Sep 2010 15:33:01 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Rob Farmer References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@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: Pawel Jakub Dawidek , freebsd-current@freebsd.org, d@delphij.net Subject: Re: System reboots building mysql51-client with ZFS v28 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: Thu, 09 Sep 2010 22:33:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/09/09 15:28, Rob Farmer wrote: > On Thu, Sep 9, 2010 at 15:14, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi, Rob, >> >> On 2010/09/09 15:01, Rob Farmer wrote: >> [...] >>>> Just a guess - are you compiling under X? If so what about if you >>>> compile under text mode? >>> >>> Nope - this is a new install and X isn't running yet. It is installed, >>> but not started yet. I ran across this building dependencies for KDE >>> (why a desktop requires MySQL server is beyond me, but anyways). >> >> I just tried to compile MySQL 5.1 client but it passed on my test system >> (the compile time option is slightly different as the VFS debugging is >> not yet enabled). I'll do another round of test with these VFS options >> enabled. > > Ok - so I shut the system down for about 15 minutes and then tried > again and it worked. > > So maybe it was heat or something - I had reproduced it about 5 times > back to back at the exact same spot. I didn't think this laptop had > cooling problems but I will keep a closer eye on it in the future. Oh... If it's so reproducible like this way then I'm more inclined to believe that it's a software issue. I'll try to see if I can reproduce the problem myself anyways, thanks for letting us know :) 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) iQEcBAEBCAAGBQJMiWCdAAoJEATO+BI/yjfB1swIAI3tpByC9UjdTvk5i+JKno8U NpYg9tTJDuGbgLW4sEMNpBF42OK9nEFpXnFF3S47m+7BjzLNkwAzUFuLmcvVGcTn J1MgUnQlwrOFKCQSZRTWdHirtojsFjKvDBauT2vLBds1AHmBmLAkZdOptqEsOnhS D7eRb9O7WBrhyZDk60Eup+ucbFNTxxHsOLuBOphQEviUjHx0JJFDGyaMyomqmk+j k4UWAf2ZAqxW1FTkCEoFun9jEGDiHGmH5RnAxpKV9AzFsrWhqG68nSS/260JJ6G6 G0Sq+Y8TsHoRMiMiBHtV8bqhCDqpaTqovIgGZaefV7oQqGbKGzoXFQ32Lhaheic= =oD2H -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:38:19 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 7E148106564A; Thu, 9 Sep 2010 22:38:19 +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 4AD718FC14; Thu, 9 Sep 2010 22:38:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o89McIua075899; Thu, 9 Sep 2010 18:38:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o89McI1w075898; Thu, 9 Sep 2010 22:38:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Sep 2010 22:38:18 GMT Message-Id: <201009092238.o89McI1w075898@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: Thu, 09 Sep 2010 22:38:19 -0000 TB --- 2010-09-09 20:49:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-09 20:49:37 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-09 20:49:37 - cleaning the object tree TB --- 2010-09-09 20:50:05 - cvsupping the source tree TB --- 2010-09-09 20:50:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-09 20:50:51 - building world TB --- 2010-09-09 20:50:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 20:50:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 20:50:51 - TARGET=powerpc TB --- 2010-09-09 20:50:51 - TARGET_ARCH=powerpc64 TB --- 2010-09-09 20:50:51 - TZ=UTC TB --- 2010-09-09 20:50:51 - __MAKE_CONF=/dev/null TB --- 2010-09-09 20:50:51 - cd /src TB --- 2010-09-09 20:50:51 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 9 20:50: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Sep 9 22:32:26 UTC 2010 TB --- 2010-09-09 22:32:26 - generating LINT kernel config TB --- 2010-09-09 22:32:26 - cd /src/sys/powerpc/conf TB --- 2010-09-09 22:32:26 - /usr/bin/make -B LINT TB --- 2010-09-09 22:32:26 - building LINT kernel TB --- 2010-09-09 22:32:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-09 22:32:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-09 22:32:26 - TARGET=powerpc TB --- 2010-09-09 22:32:26 - TARGET_ARCH=powerpc64 TB --- 2010-09-09 22:32:26 - TZ=UTC TB --- 2010-09-09 22:32:26 - __MAKE_CONF=/dev/null TB --- 2010-09-09 22:32:26 - cd /src TB --- 2010-09-09 22:32:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 9 22:32:27 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mpt/mpt_user.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/msk/if_msk.c /src/sys/dev/msk/if_msk.c: In function 'mskc_reset': /src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) /src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported only once /src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.) /src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr': /src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-09 22:38:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-09 22:38:18 - ERROR: failed to build lint kernel TB --- 2010-09-09 22:38:18 - 4503.29 user 1297.73 system 6521.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:57: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 071E0106564A for ; Thu, 9 Sep 2010 22:57:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A09848FC14 for ; Thu, 9 Sep 2010 22:57:00 +0000 (UTC) Received: (qmail 5145 invoked by uid 399); 9 Sep 2010 22:56:59 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Sep 2010 22:56:59 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C89663D.5050007@FreeBSD.org> Date: Thu, 09 Sep 2010 15:57:01 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> In-Reply-To: <201009081439.o88EdHwh064108@lava.sentex.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 22:57:01 -0000 On 9/8/2010 7:39 AM, Mike Tancsa wrote: > At 09:07 AM 9/8/2010, Denny Lin wrote: >> On Wed, Sep 08, 2010 at 04:55:14AM -0700, Rob Farmer wrote: >> > > TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h >> cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile >> > > TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit >> code  1 >> > > TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree >> > > TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real >> > >> > Is it possible to either have the tinderbox try multiple cvsup servers >> > or just not send a message if cvsup fails? Counting all branches and >> > all archs, there have been around 50 "ERROR: unable to cvsup the >> > source tree" mails in the last week. >> >> I don't think Tinderbox supports multiple CVSup servers at the moment. >> It seems like a desirable feature. > > Normally they are pointed to a local mirror here at Sentex. However, > that server was having hardware problems which I think we have isolated > and resolved now. I will repoint this tinderbox to the local site again. The best way to handle this would be to have messages about csup failing to be directed only to those who are actually able to fix the problem. Assuming that the cvsup server is always going to work is contrary to both history and good system administration practices. :) > Perhaps as an interim measure a local procmail rule to filter out cvsup > failures from going to the list ? That's a particularly unhelpful response. Not only is it borderline rude to attempt to shift the responsibility for this to the users, it's a violation of the robustness principle. Perhaps more importantly though, the amount of tinderbox spam we already receive as a result of developers inadequately testing their work is bad enough, but the extra spam about csup failures is causing the whole tinderbox feature to be increasingly useless since more and more people are simply filtering the messages. Such filters, once added, are rather unlikely to be removed. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 23:05:02 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 A7CC31065693; Thu, 9 Sep 2010 23:05:02 +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 3A0908FC13; Thu, 9 Sep 2010 23:05:02 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3E752A57D35; Fri, 10 Sep 2010 07:05:01 +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 ewGfsLJXgmeN; Fri, 10 Sep 2010 07:04:56 +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 92FDBA56B76; Fri, 10 Sep 2010 07:04:54 +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=wUj94GZaUQ5cfVruqHaWEX44/qiIFKcbtH0Q7KCTDxwEeGaIb7swP5vRO6SNyWe4L iLSHP3HtNxpwZX0G4pIvw== Message-ID: <4C896813.2040706@delphij.net> Date: Thu, 09 Sep 2010 16:04:51 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: d@delphij.net References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@delphij.net> <4C89609D.2070201@delphij.net> In-Reply-To: <4C89609D.2070201@delphij.net> 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: Rob Farmer , Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: System reboots building mysql51-client with ZFS v28 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: Thu, 09 Sep 2010 23:05:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/09/09 15:33, Xin LI wrote: > On 2010/09/09 15:28, Rob Farmer wrote: >> On Thu, Sep 9, 2010 at 15:14, Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Hi, Rob, >>> >>> On 2010/09/09 15:01, Rob Farmer wrote: >>> [...] >>>>> Just a guess - are you compiling under X? If so what about if you >>>>> compile under text mode? >>>> >>>> Nope - this is a new install and X isn't running yet. It is installed, >>>> but not started yet. I ran across this building dependencies for KDE >>>> (why a desktop requires MySQL server is beyond me, but anyways). >>> >>> I just tried to compile MySQL 5.1 client but it passed on my test system >>> (the compile time option is slightly different as the VFS debugging is >>> not yet enabled). I'll do another round of test with these VFS options >>> enabled. > >> Ok - so I shut the system down for about 15 minutes and then tried >> again and it worked. > >> So maybe it was heat or something - I had reproduced it about 5 times >> back to back at the exact same spot. I didn't think this laptop had >> cooling problems but I will keep a closer eye on it in the future. > > Oh... If it's so reproducible like this way then I'm more inclined to > believe that it's a software issue. I'll try to see if I can reproduce > the problem myself anyways, thanks for letting us know :) Ok mine went through with these recommended debugging options. Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in /sys/kern/subr_witness.c. I'm not sure if it's related but without that I used get a few panics in the past. 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) iQEcBAEBCAAGBQJMiWgSAAoJEATO+BI/yjfBtk8IAKBlemR61Hl5mThqejeXzbTy QLaohvohm5Q3gu/YrtP79/xJ0fmGGE5WdbbpKJns4xPo9OzGJZ3Hbkx96H6a0R0j 9X73xh0zVfsbKHlg5VqxrTR8HU1QwEHJ6PWmTds+tQXzN3t6Et+85tlXS7jc6agW T6wbdNocZEqI26N6FoKGCyTMo3N7fRAVN4+z7xudIVQ3DYAEYD30ku/oQzMpxeYA rZmYdP8Nwu90g/NHI1IgwECiQRAvQAukzOZbi/LvNMEdy4GzVjT5zQU22KHGAd4v RssppVJVYUxxRlxSFevc0gQLGnhJ4loiQggo5afhlsGJ60kOrF4MPmW9jx3iZNY= =k7y7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 23:12: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 3D458106564A; Thu, 9 Sep 2010 23:12:25 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4C3B8FC13; Thu, 9 Sep 2010 23:12:24 +0000 (UTC) Received: by vws7 with SMTP id 7so2159066vws.13 for ; Thu, 09 Sep 2010 16:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.157.139 with SMTP id b11mr1146vcx.11.1284073943728; Thu, 09 Sep 2010 16:12:23 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Thu, 9 Sep 2010 16:12:23 -0700 (PDT) X-Originating-IP: [71.1.133.114] In-Reply-To: <4C896813.2040706@delphij.net> References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@delphij.net> <4C89609D.2070201@delphij.net> <4C896813.2040706@delphij.net> Date: Thu, 9 Sep 2010 16:12:23 -0700 Message-ID: From: Rob Farmer To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: System reboots building mysql51-client with ZFS v28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:12:25 -0000 On Thu, Sep 9, 2010 at 16:04, Xin LI wrote: > Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in > /sys/kern/subr_witness.c. =A0I'm not sure if it's related but without tha= t > I used get a few panics in the past. I have no idea what that does. Is it something you would recommend for general ZFS use on current? (I assume it only matters when WITNESS is enabled) --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 23:15: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 DD0B2106564A; Thu, 9 Sep 2010 23:15:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D87D8FC12; Thu, 9 Sep 2010 23:15:48 +0000 (UTC) Received: by gwb15 with SMTP id 15so708045gwb.13 for ; Thu, 09 Sep 2010 16:15:48 -0700 (PDT) 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=Zzetu1UKSSzUE/iBlFntGw5Leg7Yaf6JQnR0tSM9PR0=; b=bHPvdYpzbz1rO3tNAtWtgAH64WmMK9sMggu21qEInrpUphzRT9AiN8br/8xJIdUbno jGPm/5pXqDOLAXGncGLfHdiB1FKE4NZLw3xwpkocKwaJh4q9WHUfOKKJdFvyDsKouKxm IBKLlxk6cpzZlCvRXX6o4PSvDojzz+3Rtt3Qk= 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=EHK8bGseHnc986Z2V7jWxsietqrFB1lOf5XbskLvBNs4Hzaj8XQpDTqqZkvZuvoFRd u+CMOfe+3TZ8b56lccDKNmBYdGWbP9HqVKqu0Ay8ricAUo8ZmIr0Et5FOmm3HcGo3qMk dsu0k3/Q3VVx7xJ3M92ghH9efIsslZT1snIS4= MIME-Version: 1.0 Received: by 10.100.50.33 with SMTP id x33mr911742anx.79.1284074148327; Thu, 09 Sep 2010 16:15:48 -0700 (PDT) Received: by 10.100.126.20 with HTTP; Thu, 9 Sep 2010 16:15:48 -0700 (PDT) In-Reply-To: <4C896813.2040706@delphij.net> References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@delphij.net> <4C89609D.2070201@delphij.net> <4C896813.2040706@delphij.net> Date: Thu, 9 Sep 2010 16:15:48 -0700 Message-ID: From: Matthew Fleming To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Farmer , Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: System reboots building mysql51-client with ZFS v28 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:15:50 -0000 On Thu, Sep 9, 2010 at 4:04 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/09/09 15:33, Xin LI wrote: >> On 2010/09/09 15:28, Rob Farmer wrote: >>> On Thu, Sep 9, 2010 at 15:14, Xin LI wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> Hi, Rob, >>>> >>>> On 2010/09/09 15:01, Rob Farmer wrote: >>>> [...] >>>>>> Just a guess - are you compiling under X? =A0If so what about if you >>>>>> compile under text mode? >>>>> >>>>> Nope - this is a new install and X isn't running yet. It is installed= , >>>>> but not started yet. I ran across this building dependencies for KDE >>>>> (why a desktop requires MySQL server is beyond me, but anyways). >>>> >>>> I just tried to compile MySQL 5.1 client but it passed on my test syst= em >>>> (the compile time option is slightly different as the VFS debugging is >>>> not yet enabled). =A0I'll do another round of test with these VFS opti= ons >>>> enabled. >> >>> Ok - so I shut the system down for about 15 minutes and then tried >>> again and it worked. >> >>> So maybe it was heat or something - I had reproduced it about 5 times >>> back to back at the exact same spot. I didn't think this laptop had >>> cooling problems but I will keep a closer eye on it in the future. >> >> Oh... =A0If it's so reproducible like this way then I'm more inclined to >> believe that it's a software issue. =A0I'll try to see if I can reproduc= e >> the problem myself anyways, thanks for letting us know :) > > Ok mine went through with these recommended debugging options. > > Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in > /sys/kern/subr_witness.c. =A0I'm not sure if it's related but without tha= t > I used get a few panics in the past. As of r212370 on CURRENT this is no longer necessary, as the sbuf_printf() will drain to the sysctl struct. The define and its use are gone. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 23:21: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 A4B44106564A; Thu, 9 Sep 2010 23:21:56 +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 368FE8FC0A; Thu, 9 Sep 2010 23:21:56 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1A865A58548; Fri, 10 Sep 2010 07:21:55 +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 NBLLkwRW9swr; Fri, 10 Sep 2010 07:21:49 +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 8D7A1A57D35; Fri, 10 Sep 2010 07:21:47 +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=jxz8LT2O6BXsUNxkvbujFGb+jRtHoDG81rgkLD/EEQq39qNK2NuzWfr9y2hKiI8V5 KhL/DcE46D/tr3tpK7G7A== Message-ID: <4C896C08.504@delphij.net> Date: Thu, 09 Sep 2010 16:21:44 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Matthew Fleming References: <4C8957F5.8010405@delphij.net> <4C895C53.2070602@delphij.net> <4C89609D.2070201@delphij.net> <4C896813.2040706@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: Pawel Jakub Dawidek , Rob Farmer , d@delphij.net, freebsd-current@freebsd.org Subject: Re: System reboots building mysql51-client with ZFS v28 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: Thu, 09 Sep 2010 23:21:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/09/09 16:15, Matthew Fleming wrote: > On Thu, Sep 9, 2010 at 4:04 PM, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 2010/09/09 15:33, Xin LI wrote: >>> On 2010/09/09 15:28, Rob Farmer wrote: >>>> On Thu, Sep 9, 2010 at 15:14, Xin LI wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> Hi, Rob, >>>>> >>>>> On 2010/09/09 15:01, Rob Farmer wrote: >>>>> [...] >>>>>>> Just a guess - are you compiling under X? If so what about if you >>>>>>> compile under text mode? >>>>>> >>>>>> Nope - this is a new install and X isn't running yet. It is installed, >>>>>> but not started yet. I ran across this building dependencies for KDE >>>>>> (why a desktop requires MySQL server is beyond me, but anyways). >>>>> >>>>> I just tried to compile MySQL 5.1 client but it passed on my test system >>>>> (the compile time option is slightly different as the VFS debugging is >>>>> not yet enabled). I'll do another round of test with these VFS options >>>>> enabled. >>> >>>> Ok - so I shut the system down for about 15 minutes and then tried >>>> again and it worked. >>> >>>> So maybe it was heat or something - I had reproduced it about 5 times >>>> back to back at the exact same spot. I didn't think this laptop had >>>> cooling problems but I will keep a closer eye on it in the future. >>> >>> Oh... If it's so reproducible like this way then I'm more inclined to >>> believe that it's a software issue. I'll try to see if I can reproduce >>> the problem myself anyways, thanks for letting us know :) >> >> Ok mine went through with these recommended debugging options. >> >> Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in >> /sys/kern/subr_witness.c. I'm not sure if it's related but without that >> I used get a few panics in the past. > > As of r212370 on CURRENT this is no longer necessary, as the > sbuf_printf() will drain to the sysctl struct. The define and its use > are gone. Oh that's great, I'll update my code and revert the local workaround. 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) iQEcBAEBCAAGBQJMiWwIAAoJEATO+BI/yjfBaAQH/R07HAVd/GaW0nVLAdR0nHeE wOkoJpbudwZjrgLzR0mmdWuKVW3KIqH6o4K9wHPKrLCk7EEqcZXiBdeB3jDHSAGt cywskjouvgpFDXabgTvdUUHyah9STLInG0l6zGoy8NLdUHW3K9GaTuDQg5750QRQ UWOUyJ3t5h8fucJUIwWEtT3NOlRtMwnudS96AVvEiqtq2e5a0BBzU4XqeNwIlQGi f8OSfQljJlmsZbgzmukAhimr5YcqpR19qxJkAYDeLEuG6xNrRkXolO9vb0X1+DDm y3QCQ73+eY6Vt227euqHTir1In9/5RQNQ7Ylc89S1xaKEZKehiZhXsLn/ddwURc= =+vf6 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 02:41:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 30767106566C; Fri, 10 Sep 2010 02:41:03 +0000 (UTC) Date: Fri, 10 Sep 2010 02:41:03 +0000 From: Alexander Best To: Gordon Tetlow Message-ID: <20100910024103.GA77780@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 02:41:03 -0000 On Thu Sep 9 10, Gordon Tetlow wrote: > On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow wrote: > > > All, > > > > I sat down and rewrote the man tools from a relatively old codebase to a > > single shell script. My original motivation was to allow multiple > > configuration files so port installations did not have to mess with > > /etc/manpath.config (like perl for example) when needing to manipulate the > > manpath. After looking at the existing code, I figured I could rewrite it as > > a shell script relatively easily. > > > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > > /usr/bin/whatis) > > http://people.freebsd.org/~gordon/man.sh > > > > Features of the new code: > > > > 1. BSD licensed (old code is GPL). > > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > > (purposefully changed the manpath.config file since it is a different > > syntax). > > 3. Allows ports to override the toolset used to display the manpage based > > on language. This was done to try to merge the functionality of the > > japanese/man port into the base system as much as possible. > > > > I've tried to make this mirror the functionality, directory search order, > > and arguments as the current base implementation. > > > > This brings me to my next point. I need some testers willing to try this > > out. It would be particularly great if I could get some foreign language > > testers with localized manpage installations. If something doesn't work the > > way you expect, please contact me and I can help debug it (using man -ddd > > will generally give me the debug information I need). > > > > I have a new set for testing: > http://people.freebsd.org/~gordon/man.shar > > This is going to be my final set before I commit it into the tree, barring > any showstoppers. Now includes manpage documentation for the various parts > of the new utilities. To install: > # sh man.shar > # make > # make -DBINDIR=/usr/bin install > > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages > would be appreciated. I'm new to manpage authoring and could use a review. you forgot the AUTHORS section in all of the man pages. ;) it's always nice to see who wrote the code by reading the man pages and not having to look at the source itself imho. cheers. alex > > Please let me know if you have any questions. > > Thanks, > Gordon -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 02:48:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 12FFF1065675; Fri, 10 Sep 2010 02:48:20 +0000 (UTC) Date: Fri, 10 Sep 2010 02:48:20 +0000 From: Alexander Best To: Gordon Tetlow Message-ID: <20100910024820.GA79407@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 02:48:20 -0000 On Thu Sep 9 10, Gordon Tetlow wrote: > On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow wrote: > > > All, > > > > I sat down and rewrote the man tools from a relatively old codebase to a > > single shell script. My original motivation was to allow multiple > > configuration files so port installations did not have to mess with > > /etc/manpath.config (like perl for example) when needing to manipulate the > > manpath. After looking at the existing code, I figured I could rewrite it as > > a shell script relatively easily. > > > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > > /usr/bin/whatis) > > http://people.freebsd.org/~gordon/man.sh > > > > Features of the new code: > > > > 1. BSD licensed (old code is GPL). > > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > > (purposefully changed the manpath.config file since it is a different > > syntax). > > 3. Allows ports to override the toolset used to display the manpage based > > on language. This was done to try to merge the functionality of the > > japanese/man port into the base system as much as possible. > > > > I've tried to make this mirror the functionality, directory search order, > > and arguments as the current base implementation. > > > > This brings me to my next point. I need some testers willing to try this > > out. It would be particularly great if I could get some foreign language > > testers with localized manpage installations. If something doesn't work the > > way you expect, please contact me and I can help debug it (using man -ddd > > will generally give me the debug information I need). > > > > I have a new set for testing: > http://people.freebsd.org/~gordon/man.shar > > This is going to be my final set before I commit it into the tree, barring > any showstoppers. Now includes manpage documentation for the various parts > of the new utilities. To install: > # sh man.shar > # make > # make -DBINDIR=/usr/bin install > > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages > would be appreciated. I'm new to manpage authoring and could use a review. i also did some naive benchmarking using 'cat' as pager and your script is just as fast as the current man binary. good work. :) i was a bit surprised about how people complained about the new BSD grep being slower than gnu grep. so the lesson we learnt is: never make things slower as they are. ;) cheers. alex > > Please let me know if you have any questions. > > Thanks, > Gordon -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 02:50: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 AA3EE1065672; Fri, 10 Sep 2010 02:50: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 5F4C08FC17; Fri, 10 Sep 2010 02:50:50 +0000 (UTC) Received: from bigwig.baldwin.cx (unknown [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1511646B17; Thu, 9 Sep 2010 14:33:56 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CED18A03C; Thu, 9 Sep 2010 14:32:52 -0400 (EDT) From: John Baldwin To: Weongyo Jeong Date: Thu, 9 Sep 2010 14:32:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100908201419.GF1328@weongyo> <201009090936.19412.jhb@freebsd.org> <20100909174146.GG1328@weongyo> In-Reply-To: <20100909174146.GG1328@weongyo> MIME-Version: 1.0 Message-Id: <201009091432.52066.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 14:32:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 02:50:50 -0000 On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > Hello, > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > when it's initialized so I always encounters the following LOR > > > > > > lock order reversal: (sleepable after non-sleepable) > > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > > netinet/in_mcast.c:1095 > > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > _witness_debugger() at _witness_debugger+0x2e > > > witness_checkorder() at witness_checkorder+0x807 > > > _sx_xlock() at _sx_xlock+0x55 > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > axe_cmd() at axe_cmd+0xc7 > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > axe_setmulti() at axe_setmulti+0x3e > > > axe_ioctl() at axe_ioctl+0x132 > > > if_addmulti() at if_addmulti+0x19b > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > in_joingroup() at in_joingroup+0x52 > > > in_control() at in_control+0x1144 > > > ifioctl() at ifioctl+0x1118 > > > kern_ioctl() at kern_ioctl+0xbe > > > ioctl() at ioctl+0xfd > > > syscallenter() at syscallenter+0x1aa > > > syscall() at syscall+0x4c > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > case SIOCADDMULTI: > > > case SIOCDELMULTI: > > > axe_setmulti(sc, 0); > > > break; > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > My question is that is it safe if the multicasting operations for USB > > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > > task is deferred? > > > > Why is USB using an sx lock instead of a mutex? > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > of things I'd like to change it. > > Just looking the comment at usb_request.c@441: > > /* > * Grab the default sx-lock so that serialisation > * is achieved when multiple threads are involved: > */ > sx_xlock(&udev->ctrl_sx); > > I think he might want to hold the lock even if the thread is going into > sleep. It might be for serialization. > > However even if we succeed to change the lock from sx to mutex, it's > hard to avoid the requests going into the sleep. It means USB stack > should call like below: > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > to avoid the kernel's complain (would be `sleep with holding > non-sleepable lock'). > > What I'd like to say is that the sleeping is big problem if mutex is > used that it'd be worse when multiple mutex locks are used. > > So I'm looking for a fundamental solution to solve this problem. > Welcomes any ideas. It is probably fine to just schedule a task to do the actual work of axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in your task handler as long as your handler holds the appropriate lock (if_maddr_rlock() IIRC) when walking the interface's multicast address list. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 03:22: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 A6B89106566B for ; Fri, 10 Sep 2010 03:22:06 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED8A8FC15 for ; Fri, 10 Sep 2010 03:22:05 +0000 (UTC) Received: by gxk24 with SMTP id 24so1089148gxk.13 for ; Thu, 09 Sep 2010 20:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=4E1ppKL/6RXuE2NnmWy0yH2jhAY8pU24L1R0LdgPuhw=; b=savQkrxFFkcAJ8kzvBOri1V3fzXr37ohsDILPTfFC31kUcYx6m4+4cRc1OpoQyq1A7 az7Tg+yt51N45NGnt/Vq0thg6w4y+rHzSyseDSIGmGX7N8nz8B3xK+EIErQy5uaTgt7o jETk6f4PvqieWYjp0YCcwN0asBqOmUN98Fy3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=CnmPGcfBQx46ejMSC7uYETadDaPJx+0oZgp4UKHBGMfYomKQ8gIy9wGrg434hfQYoF lcUQKpYTZDckWlKrb9ABBUFUfZb7ni58f8M1LBvIfKG8fRtNVNZNdfYcmuGhUTJPwYdq p3eJYq8X9LrGsWNWKc33dGG9jcR8fRsKW3cSc= Received: by 10.151.100.10 with SMTP id c10mr151304ybm.197.1284088924751; Thu, 09 Sep 2010 20:22:04 -0700 (PDT) Received: from localhost (tor-exit-proxy7-readme.formlessnetworking.net [208.53.142.43]) by mx.google.com with ESMTPS id m11sm2131482ybn.16.2010.09.09.20.22.02 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 20:22:03 -0700 (PDT) From: Anonymous To: Gordon Tetlow References: Date: Fri, 10 Sep 2010 07:17:23 +0400 In-Reply-To: (Gordon Tetlow's message of "Wed, 18 Aug 2010 00:11:20 -0700") Message-ID: <86d3smb83g.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 03:22:06 -0000 Gordon Tetlow writes: > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > (purposefully changed the manpath.config file since it is a different > syntax). Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local as the only place installed packages may reside in, only default one. From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:48: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 72DE1106566B; Fri, 10 Sep 2010 06:48:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDA08FC12; Fri, 10 Sep 2010 06:48:49 +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 JAA15410; Fri, 10 Sep 2010 09:48:47 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OtxPj-0008Ca-6I; Fri, 10 Sep 2010 09:48:47 +0300 Message-ID: <4C89D4CD.7000301@icyb.net.ua> Date: Fri, 10 Sep 2010 09:48:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> <4C89663D.5050007@FreeBSD.org> In-Reply-To: <4C89663D.5050007@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: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 06:48:50 -0000 on 10/09/2010 01:57 Doug Barton said the following: > On 9/8/2010 7:39 AM, Mike Tancsa wrote: >> Perhaps as an interim measure a local procmail rule to filter out cvsup >> failures from going to the list ? > > That's a particularly unhelpful response. Not only is it borderline rude to > attempt to shift the responsibility for this to the users, it's a violation of > the robustness principle. My impression that the suggestion was to do the filtering on the sending end, not the recipients' end. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 07:54: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 F122B106564A; Fri, 10 Sep 2010 07:54:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id AA0E98FC08; Fri, 10 Sep 2010 07:54:41 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o8A7sXCt025807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 03:54:33 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o8A7sXLt078290; Fri, 10 Sep 2010 03:54:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009100754.o8A7sXLt078290@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Sep 2010 03:54:24 -0400 To: Doug Barton , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <4C89663D.5050007@FreeBSD.org> References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> <4C89663D.5050007@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 07:54:42 -0000 At 06:57 PM 9/9/2010, Doug Barton wrote: >>Normally they are pointed to a local mirror here at Sentex. However, >>that server was having hardware problems which I think we have isolated >>and resolved now. I will repoint this tinderbox to the local site again. > >The best way to handle this would be to have messages about csup >failing to be directed only to those who are actually able to fix >the problem. Assuming that the cvsup server is always going to work >is contrary to both history and good system administration practices. :) > >>Perhaps as an interim measure a local procmail rule to filter out cvsup >>failures from going to the list ? > >That's a particularly unhelpful response. Not only is it borderline >rude to attempt to shift the responsibility for this to the users, >it's a violation of the robustness principle. I meant "local procmail rule" as in local to the tinderboxes so that des and myself and others who admin the boxes only get such messages. I didnt want to make such changes without des' approval and was waiting for his input... ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 12:00: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 A5F0D10656DE; Fri, 10 Sep 2010 12:00:21 +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 74C0B8FC15; Fri, 10 Sep 2010 12:00:21 +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 18A3D46B9D; Fri, 10 Sep 2010 08:00:21 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3BD88A03C; Fri, 10 Sep 2010 08:00:09 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 10 Sep 2010 07:47:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> <20100909195045.GA68352@freebsd.org> In-Reply-To: <20100909195045.GA68352@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009100747.39964.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 10 Sep 2010 08:00:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:00:21 -0000 On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > On Thu Sep 9 10, Alexander Best wrote: > > On Thu Sep 9 10, Alexander Best wrote: > > > hi there, > > > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > > without a kernel on a specific arch won't function at all? > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > > or something like that, but the uart backend to use *if* uart gets defined in > > the kernel config. > > > > sorry for the noise folks. > > however i found some missing comments and incorrect syntax which i fixed. > > see the attached patch. I think the ia64 ordering for 'io and mem' is probably more correct (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. The powerpc 'machine' changes are wrong I think as it would break GENERIC64 and powerpc64 kernel configs in general. Nathan purposefully removed 'machine' from the powerpc DEFAULTS. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 12:27:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 62C551065674; Fri, 10 Sep 2010 12:27:48 +0000 (UTC) Date: Fri, 10 Sep 2010 12:27:48 +0000 From: Alexander Best To: John Baldwin Message-ID: <20100910122748.GA1834@freebsd.org> References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> <20100909195045.GA68352@freebsd.org> <201009100747.39964.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009100747.39964.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 12:27:48 -0000 On Fri Sep 10 10, John Baldwin wrote: > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > On Thu Sep 9 10, Alexander Best wrote: > > > On Thu Sep 9 10, Alexander Best wrote: > > > > hi there, > > > > > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > > > without a kernel on a specific arch won't function at all? > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > > > or something like that, but the uart backend to use *if* uart gets defined in > > > the kernel config. > > > > > > sorry for the noise folks. > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > see the attached patch. > > I think the ia64 ordering for 'io and mem' is probably more correct > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > and powerpc64 kernel configs in general. Nathan purposefully removed > 'machine' from the powerpc DEFAULTS. thanks for the feedback. i'll hack in the changes and will send out a new patch on monday or so. :) cheers. alex > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:02: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 5C063106566B for ; Fri, 10 Sep 2010 14:02:34 +0000 (UTC) (envelope-from tgen@deepbone.net) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id DD43B8FC16 for ; Fri, 10 Sep 2010 14:02:33 +0000 (UTC) Received: from cpbrm-ews04.kpnxchange.com ([10.94.84.135]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 15:50:29 +0200 Received: from CPSMTPM-EML106.kpnxchange.com ([195.121.3.10]) by cpbrm-ews04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 15:50:29 +0200 Received: from smtp.deepbone.net ([84.83.37.40]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Fri, 10 Sep 2010 15:50:29 +0200 Received: from [10.64.3.36] (unknown [10.64.1.10]) (Authenticated sender: tgen) by smtp.deepbone.net (Postfix) with ESMTPSA id E0CC939819 for ; Fri, 10 Sep 2010 13:50:28 +0000 (UTC) Message-ID: <4C8A379E.6080909@deepbone.net> Date: Fri, 10 Sep 2010 13:50:22 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100527 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBD88453504D60DE655A043C" X-OriginalArrivalTime: 10 Sep 2010 13:50:29.0239 (UTC) FILETIME=[21117870:01CB50EF] X-RcptDomain: freebsd.org Subject: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:02:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBBD88453504D60DE655A043C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, the kernel hangs at some point when math/atlas tries to run some tests (presumably the ones to profile the code and optimise). The kernel spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. After that, the system is no longer responsive, and eventually panic()s because some spinlock has been held too long in the pmap TLB invalidate code. Couldn't get a dump, because I had no dumpdev configured. Anyone else see this problem? I'm trying to reproduce it by building other ports (it has survived gcc44, gcc45, llvm and clang so far), but only math/atlas seems to trigger it. Cheers, --=20 Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net --------------enigBBD88453504D60DE655A043C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMijekAAoJEKE55rmjwpbTF9EH/2c9cpguN9qYOmsrZhpYD9MG UrXu4oYmPaRonXOvPmTCXcJeX7VxwIZz5E7dADpIYQzA7f13nMzhZ3Jbz4TGKlpc WpXwIMIFLbex1opQ/GSiX2XWqofqB+jJiTNCTBYKSZXDWEWqreYYdjnPurnbo3bI nPPIpRae5nqAGrRY28LhnNXGct2LvlHhZhJIzD7jTdgyTiZAqIrWo3Df+NLfKfRD v0D6ULiN2Qm+OlXmNTgBG4WSp2QInHGzd9dk4v9K/T62tcTCU1Ruzr89Ibw3ljhs uIKoMi8ICMEZ6N1GawkFvTCGj+sjIi5EPlWP+q+dratPRPqpNzCvUmqKzFbNTcU= =mjL4 -----END PGP SIGNATURE----- --------------enigBBD88453504D60DE655A043C-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:31: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 6C6431065679 for ; Fri, 10 Sep 2010 14:31:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 307458FC1E for ; Fri, 10 Sep 2010 14:31:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:6c87:9302:5653:307d] (unknown [IPv6:2001:7b8:3a7:0:6c87:9302:5653:307d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 197525C61; Fri, 10 Sep 2010 16:31:38 +0200 (CEST) Message-ID: <4C8A414C.6000603@FreeBSD.org> Date: Fri, 10 Sep 2010 16:31:40 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100910 Lanikai/3.1.4pre MIME-Version: 1.0 To: "Thomas E. Spanjaard" References: <4C8A379E.6080909@deepbone.net> In-Reply-To: <4C8A379E.6080909@deepbone.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:31:39 -0000 On 2010-09-10 15:50, Thomas E. Spanjaard wrote: > While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, > the kernel hangs at some point when math/atlas tries to run some tests > (presumably the ones to profile the code and optimise). The kernel > spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ > 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. It's probably running profiled executables (e.g. compiled with -pg)? This can lead to the above messages, and apparently also to deadlocks. I am not sure what to do about it though, except confirm that this is very likely your problem... From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:40: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 2D5801065675; Fri, 10 Sep 2010 14:40:41 +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 8466B8FC24; Fri, 10 Sep 2010 14:40:40 +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 o8AEeQrD090984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 17:40:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8AEeQ1e061529; Fri, 10 Sep 2010 17:40:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8AEePii061528; Fri, 10 Sep 2010 17:40:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Sep 2010 17:40:25 +0300 From: Kostik Belousov To: Dimitry Andric Message-ID: <20100910144025.GQ2465@deviant.kiev.zoral.com.ua> References: <4C8A379E.6080909@deepbone.net> <4C8A414C.6000603@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v+Mbu5iuT/5Blw/K" Content-Disposition: inline In-Reply-To: <4C8A414C.6000603@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=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: "Thomas E. Spanjaard" , freebsd-current@freebsd.org Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:40:41 -0000 --v+Mbu5iuT/5Blw/K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2010 at 04:31:40PM +0200, Dimitry Andric wrote: > On 2010-09-10 15:50, Thomas E. Spanjaard wrote: > >While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, > >the kernel hangs at some point when math/atlas tries to run some tests > >(presumably the ones to profile the code and optimise). The kernel > >spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ > >127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. >=20 > It's probably running profiled executables (e.g. compiled with -pg)? > This can lead to the above messages, and apparently also to deadlocks. >=20 > I am not sure what to do about it though, except confirm that this is > very likely your problem... Try this. diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c index 6b005de..7f0c781 100644 --- a/sys/kern/kern_clocksource.c +++ b/sys/kern/kern_clocksource.c @@ -65,6 +65,7 @@ inline static int doconfigtimer(int i); static void configtimer(int i); =20 static struct eventtimer *timer[2] =3D { NULL, NULL }; +static int blocked_timer[2]; static int timertest =3D 0; static int timerticks[2] =3D { 0, 0 }; static int profiling_on =3D 0; @@ -91,6 +92,22 @@ static DPCPU_DEFINE(tc, configtimer); (((uint64_t)0x8000000000000000 + ((bt)->frac >> 2)) / \ ((bt)->frac >> 1)) =20 +static void +block_timer(int i) +{ + + critical_enter(); + atomic_add_acq_int(&blocked_timer[i], 1); +} + +static void +unblock_timer(int i) +{ + + atomic_add_rel_int(&blocked_timer[i], -1); + critical_exit(); +} + /* Per-CPU timer1 handler. */ static int hardclockhandler(struct trapframe *frame) @@ -246,6 +263,8 @@ doconfigtimer(int i) atomic_store_rel_int(*conf + i, 0); return (1); } + if (atomic_load_acq_int(&blocked_timer[i]) > 0) + return (1); return (0); } =20 @@ -366,9 +385,7 @@ cpu_initclocks_bsp(void) profhz =3D round_freq(timer[1], stathz * 64); } tick =3D 1000000 / hz; - ET_LOCK(); cpu_restartclocks(); - ET_UNLOCK(); } =20 /* Start per-CPU event timers on APs. */ @@ -376,12 +393,10 @@ void cpu_initclocks_ap(void) { =20 - ET_LOCK(); if (timer[0]->et_flags & ET_FLAGS_PERCPU) et_start(timer[0], NULL, &timerperiod[0]); if (timer[1] && timer[1]->et_flags & ET_FLAGS_PERCPU) et_start(timer[1], NULL, &timerperiod[1]); - ET_UNLOCK(); } =20 /* Reconfigure and restart event timers after configuration changes. */ @@ -411,9 +426,11 @@ cpu_restartclocks(void) timer2hz =3D round_freq(timer[1], timer2hz); } timer1hz =3D round_freq(timer[0], timer1hz); +#ifdef notyet printf("Starting kernel event timers: %s @ %dHz, %s @ %dHz\n", timer[0]->et_name, timer1hz, timer[1] ? timer[1]->et_name : "NONE", timer2hz); +#endif /* Restart event timers. */ FREQ2BT(timer1hz, &timerperiod[0]); configtimer(0); @@ -422,7 +439,9 @@ cpu_restartclocks(void) timerticks[1] =3D 0; FREQ2BT(timer2hz, &timerperiod[1]); configtimer(1); +#ifdef notyet timertest =3D 1; +#endif } } =20 @@ -433,7 +452,11 @@ cpu_startprofclock(void) =20 ET_LOCK(); profiling_on =3D 1; + block_timer(0); + block_timer(1); cpu_restartclocks(); + unblock_timer(1); + unblock_timer(0); ET_UNLOCK(); } =20 @@ -444,7 +467,11 @@ cpu_stopprofclock(void) =20 ET_LOCK(); profiling_on =3D 0; + block_timer(0); + block_timer(1); cpu_restartclocks(); + unblock_timer(1); + unblock_timer(0); ET_UNLOCK(); } =20 @@ -461,10 +488,11 @@ sysctl_kern_eventtimer_timer1(SYSCTL_HANDLER_ARGS) snprintf(buf, sizeof(buf), "%s", et->et_name); ET_UNLOCK(); error =3D sysctl_handle_string(oidp, buf, sizeof(buf), req); + if (error !=3D 0 || req->newptr =3D=3D NULL) + return (error); ET_LOCK(); et =3D timer[0]; - if (error !=3D 0 || req->newptr =3D=3D NULL || - strcmp(buf, et->et_name) =3D=3D 0) { + if (strcmp(buf, et->et_name) =3D=3D 0) { ET_UNLOCK(); return (error); } @@ -473,12 +501,14 @@ sysctl_kern_eventtimer_timer1(SYSCTL_HANDLER_ARGS) ET_UNLOCK(); return (ENOENT); } + block_timer(0); timer1hz =3D 0; configtimer(0); et_free(timer[0]); timer[0] =3D et; et_init(timer[0], timer1cb, NULL, NULL); cpu_restartclocks(); + unblock_timer(0); ET_UNLOCK(); return (error); } @@ -501,10 +531,11 @@ sysctl_kern_eventtimer_timer2(SYSCTL_HANDLER_ARGS) snprintf(buf, sizeof(buf), "%s", et->et_name); ET_UNLOCK(); error =3D sysctl_handle_string(oidp, buf, sizeof(buf), req); + if (error !=3D 0 || req->newptr =3D=3D NULL) + return (error); ET_LOCK(); et =3D timer[1]; - if (error !=3D 0 || req->newptr =3D=3D NULL || - strcmp(buf, et ? et->et_name : "NONE") =3D=3D 0) { + if (strcmp(buf, et ? et->et_name : "NONE") =3D=3D 0) { ET_UNLOCK(); return (error); } @@ -513,6 +544,7 @@ sysctl_kern_eventtimer_timer2(SYSCTL_HANDLER_ARGS) ET_UNLOCK(); return (ENOENT); } + block_timer(1); if (timer[1] !=3D NULL) { timer2hz =3D 0; configtimer(1); @@ -522,6 +554,7 @@ sysctl_kern_eventtimer_timer2(SYSCTL_HANDLER_ARGS) if (timer[1] !=3D NULL) et_init(timer[1], timer2cb, NULL, NULL); cpu_restartclocks(); + unblock_timer(1); ET_UNLOCK(); return (error); } diff --git a/sys/kern/kern_et.c b/sys/kern/kern_et.c index 6a56b1d..94e1466 100644 --- a/sys/kern/kern_et.c +++ b/sys/kern/kern_et.c @@ -38,7 +38,7 @@ SLIST_HEAD(et_eventtimers_list, eventtimer); static struct et_eventtimers_list eventtimers =3D SLIST_HEAD_INITIALIZER(e= t_eventtimers); =20 struct mtx et_eventtimers_mtx; -MTX_SYSINIT(et_eventtimers_init, &et_eventtimers_mtx, "et_mtx", MTX_SPIN); +MTX_SYSINIT(et_eventtimers_init, &et_eventtimers_mtx, "et_mtx", MTX_DEF); =20 SYSCTL_NODE(_kern, OID_AUTO, eventtimer, CTLFLAG_RW, 0, "Event timers"); SYSCTL_NODE(_kern_eventtimer, OID_AUTO, et, CTLFLAG_RW, 0, ""); diff --git a/sys/sys/timeet.h b/sys/sys/timeet.h index bc713d6..87392a2 100644 --- a/sys/sys/timeet.h +++ b/sys/sys/timeet.h @@ -83,8 +83,8 @@ struct eventtimer { }; =20 extern struct mtx et_eventtimers_mtx; -#define ET_LOCK() mtx_lock_spin(&et_eventtimers_mtx) -#define ET_UNLOCK() mtx_unlock_spin(&et_eventtimers_mtx) +#define ET_LOCK() mtx_lock(&et_eventtimers_mtx) +#define ET_UNLOCK() mtx_unlock(&et_eventtimers_mtx) =20 /* Driver API */ int et_register(struct eventtimer *et); diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index f479bbe..7811441 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -500,9 +500,11 @@ lapic_et_start(struct eventtimer *et, } while (lapic_timer_divisor <=3D 128); if (lapic_timer_divisor > 128) panic("lapic: Divisor too big"); +#ifdef notyet if (bootverbose) printf("lapic: Divisor %lu, Frequency %lu Hz\n", lapic_timer_divisor, value); +#endif et->et_frequency =3D value; et->et_min_period.sec =3D 0; et->et_min_period.frac =3D --v+Mbu5iuT/5Blw/K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyKQ1kACgkQC3+MBN1Mb4hqiwCgof9TYCaBytdtm0dIOZaYmliT u24AoI/Fg/27D5LKV1yPP5hlAO+4mZTE =xEOU -----END PGP SIGNATURE----- --v+Mbu5iuT/5Blw/K-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:15: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 171FE106564A for ; Fri, 10 Sep 2010 15:15:23 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A03038FC1E for ; Fri, 10 Sep 2010 15:15:22 +0000 (UTC) Received: by bwz20 with SMTP id 20so2726131bwz.13 for ; Fri, 10 Sep 2010 08:15:21 -0700 (PDT) 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=YRTt8qdXRI/b7FO+0Pb2JLZ+NhSwi+7bVKdfl9Di4gI=; b=XwNBIqqexZzxPpkIVeug2WN767nrGo9yL0HusChvPV1kQAqp3Xs9Yd/K+1nNhs52eg vdkDDYLQnSyX+3syMpxiBzFGiomUYQcLkdtRSSxduJa7Y/rJCQsqbqV1eIEiPPcpcg/s ThQfBFx1N2q5RBMN2jkEUXhcTP9eiyM9jTB/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gEkdGw+VX2HElntfGt72FPLJ+DJYv+h52joXKfIUts9B1+51VeKYm1jKW5ulcnUcik KXclvZO0Co0Ae7TUx09dVYgOM9yFmDiQfW3uHvYmfXaodW6C/fV1js8UA9XvwxWKCGud wAVmYPr8ziUDfQgAk5WuqnuVhoVSybOQbSWvo= MIME-Version: 1.0 Received: by 10.204.117.13 with SMTP id o13mr639060bkq.48.1284129950946; Fri, 10 Sep 2010 07:45:50 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Fri, 10 Sep 2010 07:45:50 -0700 (PDT) Date: Fri, 10 Sep 2010 16:45:50 +0200 Message-ID: From: David DEMELIER To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:15:23 -0000 Hi folks, I personally agree that a DHCP client must exists in base, and for this purpose we have dhclient. However soon I will have a new small machine that will only work as bind and dhcpd server. I was surprised to see that there is no DHCP server in base, obviously it's not difficult to fetch the net/isc-dhcp31-server package but for people that would like to setup a new server on FreeBSD quickly they will take some time to learn how packages framework works or ports and it can be annoying. Since the size of the net/isc-dhcp31-server port is really small I think it would be really useful to get it by default on a FreeBSD install. Information for isc-dhcp31-server-3.1.3_1: Package Size: 1232 (1K-blocks) What do you think? With kind regards, -- Demelier David From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:31: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 2BE3F1065673 for ; Fri, 10 Sep 2010 15:31:23 +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 A93F48FC1A for ; Fri, 10 Sep 2010 15:31:22 +0000 (UTC) Received: by fxm4 with SMTP id 4so2104007fxm.13 for ; Fri, 10 Sep 2010 08:31:21 -0700 (PDT) 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:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=WSQ1akvluoW6V1jiPV3GjDx4hO8t/NU5v+mKGvsvsmg=; b=SxfY/i2AZteR0GNWj7M+fGdXHFmEG14Rqmn0Irq/zYEQ7g+hixMnli60JZG4RFkZ2R +n9IwIdeFfx38yNqXfrNr07UFFAVBGg+zImqL4081QVSvGWUCM1aFo1DT+0TYWNQbPwK g2whCIUp4Z7WbPYg33ilJqgCyhhkV8xqX/OSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Z6JBlrU59RwYb1YNi9hheKgM3ImdrhrL4aruLxDoeuPI8acloAVdrVsetJQcjwKRUV Pf3WoiuVZkfduphy1Q7Cp3lRSc692umyTxjdtX5Caf8V+WlFm9ifIVHW8Z96r+X4stC9 LizWnHbCnUVN6HSOU4uDEWdE8B70i+sX7lqHE= Received: by 10.204.65.71 with SMTP id h7mr626761bki.175.1284132681294; Fri, 10 Sep 2010 08:31:21 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm2092444bkx.20.2010.09.10.08.31.18 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 08:31:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8A4F37.6000103@FreeBSD.org> Date: Fri, 10 Sep 2010 18:31:03 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "Thomas E. Spanjaard" , FreeBSD-Current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:31:23 -0000 Hi. Thomas E. Spanjaard wrote: > While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, > the kernel hangs at some point when math/atlas tries to run some tests > (presumably the ones to profile the code and optimise). The kernel > spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ > 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. > After that, the system is no longer responsive, and eventually panic()s > because some spinlock has been held too long in the pmap TLB invalidate > code. Couldn't get a dump, because I had no dumpdev configured. > > Anyone else see this problem? I'm trying to reproduce it by building > other ports (it has survived gcc44, gcc45, llvm and clang so far), but > only math/atlas seems to trigger it. It is reported deadlock between event timers and some IPI senders, like TLB invalidation, during switching to/from profiling clock rate. In forthcoming version of event timer patch this problem should not happen. You can get latest version of the patch here: http://people.freebsd.org/~mav/timers_oneshot13.patch -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:39: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 DDD6B1065693 for ; Fri, 10 Sep 2010 15:39:55 +0000 (UTC) (envelope-from tgen@deepbone.net) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 67E7E8FC20 for ; Fri, 10 Sep 2010 15:39:54 +0000 (UTC) Received: from cpbrm-ews28.kpnxchange.com ([10.94.84.159]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 17:39:53 +0200 Received: from CPSMTPM-EML109.kpnxchange.com ([195.121.3.13]) by cpbrm-ews28.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 17:39:53 +0200 Received: from smtp.deepbone.net ([84.83.37.40]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Fri, 10 Sep 2010 17:39:53 +0200 Received: from [10.64.3.36] (unknown [10.64.1.10]) (Authenticated sender: tgen) by smtp.deepbone.net (Postfix) with ESMTPSA id 3AF7339819 for ; Fri, 10 Sep 2010 15:39:53 +0000 (UTC) Message-ID: <4C8A5143.2030608@deepbone.net> Date: Fri, 10 Sep 2010 15:39:47 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100527 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C8A379E.6080909@deepbone.net> <4C8A414C.6000603@FreeBSD.org> <20100910144025.GQ2465@deviant.kiev.zoral.com.ua> In-Reply-To: <20100910144025.GQ2465@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1A9388568D9157B6A0B518E" X-OriginalArrivalTime: 10 Sep 2010 15:39:53.0454 (UTC) FILETIME=[69A530E0:01CB50FE] X-RcptDomain: freebsd.org Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:39:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1A9388568D9157B6A0B518E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/10/2010 14:40, Kostik Belousov wrote: > On Fri, Sep 10, 2010 at 04:31:40PM +0200, Dimitry Andric wrote: >> On 2010-09-10 15:50, Thomas E. Spanjaard wrote: >>> While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r2124= 11, >>> the kernel hangs at some point when math/atlas tries to run some test= s >>> (presumably the ones to profile the code and optimise). The kernel >>> spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ >>> 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back aga= in. >> It's probably running profiled executables (e.g. compiled with -pg)? >> This can lead to the above messages, and apparently also to deadlocks.= >> I am not sure what to do about it though, except confirm that this is >> very likely your problem... > Try this. Your patch indeed lets me build math/atlas. Thanks! Oh, and next time, just add it as an attachment, makes it easier :P. Cheers, --=20 Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net --------------enigE1A9388568D9157B6A0B518E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMilFJAAoJEKE55rmjwpbTsmYH/RBcGXD6qTRX6KtuGeb2SnRz 3+Xl2YO+0dqCMnS8UcB3IlJe+EjNpRyFDdW4Zm4K/g9bTf+idERdrDJMg7IG6naV OYqXpgNjtdu+tGkXaHRkMxMP4T0W8jT7mDdyqV39OYaKbt8nOt3v/Q2ead9dKxVL QNsvYRrflpzxgmgvt0k/3M9J6JsWuRIL24I9rslu2d985j0rT4AHVVOBcNrUeYvE 4kOlbgg8pUA2BvsNopxPW7iIYw9D8RelsW1qAHjtmpbTr2Qil8XsXyqWg4nQ0oQg n/2m0IRmqxeF+NAb80o5bjAfxx8pz4vmMVQ53YCtQwkpZiTiq7zFN+WkWqyorWw= =4UL7 -----END PGP SIGNATURE----- --------------enigE1A9388568D9157B6A0B518E-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:41:15 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 6D4491065693 for ; Fri, 10 Sep 2010 15:41:15 +0000 (UTC) (envelope-from tgen@deepbone.net) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id EC4E18FC0A for ; Fri, 10 Sep 2010 15:41:14 +0000 (UTC) Received: from cpbrm-ews15.kpnxchange.com ([10.94.84.146]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 17:41:13 +0200 Received: from CPSMTPM-EML108.kpnxchange.com ([195.121.3.12]) by cpbrm-ews15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 17:41:13 +0200 Received: from smtp.deepbone.net ([84.83.37.40]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Fri, 10 Sep 2010 17:41:12 +0200 Received: from [10.64.3.36] (unknown [10.64.1.10]) (Authenticated sender: tgen) by smtp.deepbone.net (Postfix) with ESMTPSA id C7A0239819 for ; Fri, 10 Sep 2010 15:41:12 +0000 (UTC) Message-ID: <4C8A5198.1000008@deepbone.net> Date: Fri, 10 Sep 2010 15:41:12 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100527 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C8A4F37.6000103@FreeBSD.org> In-Reply-To: <4C8A4F37.6000103@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2D89C1D7CC2758CD637F2F17" X-OriginalArrivalTime: 10 Sep 2010 15:41:12.0857 (UTC) FILETIME=[98F92090:01CB50FE] X-RcptDomain: freebsd.org Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:41:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D89C1D7CC2758CD637F2F17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/10/2010 15:31, Alexander Motin wrote: > It is reported deadlock between event timers and some IPI senders, like= > TLB invalidation, during switching to/from profiling clock rate. In > forthcoming version of event timer patch this problem should not happen= =2E > You can get latest version of the patch here: > http://people.freebsd.org/~mav/timers_oneshot13.patch I'll try your patch as well after math/atlas has finished building. I assume it applies cleanly to head, and this one is most likely to end up being committed? Cheers, --=20 Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net --------------enig2D89C1D7CC2758CD637F2F17 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMilGYAAoJEKE55rmjwpbTOXIH/2wlJXFivDl3JJ13zBoe5vIv 6eMGUbrbdEbPRSaTnd2msPOA6Qheeswoz3qVyAd6P3HVQKMYM6RuMzK+cTK8Glk/ Pengh0QZ/nHwVs26f8Kstltl7S5tr6smhp9WqHgGhB9eV9p7YlrXDRPmuqzejqiI p5VpfgnX/bzbPPEt65KIdYfnCqbCWg0LSP/Ldak0wr8uXhh2I9AXHe/yryGQQqTo R5xxqmg/mqF3TmhcxTgpLnFdqTNcGytnfVlHEdGyS6Z46Is+Odtt24zhgWSBWswz btRe+Ue7QADqxviXsVMXlcwtyye6Yno34v4KgWPbsdwj9COTaRow5k1mKrCbZh4= =SdFH -----END PGP SIGNATURE----- --------------enig2D89C1D7CC2758CD637F2F17-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:56: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 697FB106566C for ; Fri, 10 Sep 2010 15:56:24 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 938548FC1D for ; Fri, 10 Sep 2010 15:56:23 +0000 (UTC) Received: (qmail 42475 invoked from network); 10 Sep 2010 15:29:41 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 10 Sep 2010 15:29:41 -0000 Message-ID: <4C8A4EE4.2050503@FreeBSD.org> Date: Fri, 10 Sep 2010 17:29:40 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: David DEMELIER References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 15:56:24 -0000 David DEMELIER ha scritto: > I was surprised to see that there is no DHCP server in base, obviously > it's not difficult to fetch the net/isc-dhcp31-server package but for > people that would like to setup a new server on FreeBSD quickly they > will take some time to learn how packages framework works or ports and > it can be annoying. If you (people) don't know how to use ports/packages probably you shouldn't use FreeBSD. And I hardly think that installing a port requires more knowledge than correctly configuring a DHCP server. Then, why 3.1 and not 4.1? Why not bundling also apache? etc., etc. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:11: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 C16AF106566C for ; Fri, 10 Sep 2010 16:11:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4F48FC1B for ; Fri, 10 Sep 2010 16:11:39 +0000 (UTC) Received: by bwz20 with SMTP id 20so2790428bwz.13 for ; Fri, 10 Sep 2010 09:11:39 -0700 (PDT) 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:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+12mtXAj61V+qqDS9RA8MX2iwmaRTuTsAsvV7ebiFqE=; b=ujjt20w8QpkORB+862K/RwRqDVbIq0OyIwIEHmXsHWOtAOamSNTXme7SXXhBhJ2bKU UoTjGQ5JRF0Tc2ye5o7cpFxqXgHoAHcfZ3SSvEsQ9BI2eFXvPAWbBOAAZro/hP0iJ2hz 1KLNbFUo8mECQTuIKdj+MVy+JqiblSUNMHkV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YuEWWqOOq1MSLcZSY0MOlDnopLKuqE8mc3FVyDSOpSkaJDk5wVh+c7ArgltISedPNF jRG3U97EpBHQoln4UqSOkvZD+5E14ej6oQp3f9n9CT4+rYEwUkwJjjz1LW3Q9GrDj0I8 oQC6D7Ji6E3FyBCvs2jP8hfm0gF1kh435fXzM= Received: by 10.204.102.197 with SMTP id h5mr736485bko.24.1284135092500; Fri, 10 Sep 2010 09:11:32 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d27sm2125430bku.22.2010.09.10.09.11.30 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 09:11:31 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8A58A2.9000405@FreeBSD.org> Date: Fri, 10 Sep 2010 19:11:14 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "Thomas E. Spanjaard" , FreeBSD-Current References: <4C8A4F37.6000103@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Eventtimers b0rking w/ math/atlas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:11:40 -0000 Thomas E. Spanjaard wrote: > On 09/10/2010 15:31, Alexander Motin wrote: >> It is reported deadlock between event timers and some IPI senders, like >> TLB invalidation, during switching to/from profiling clock rate. In >> forthcoming version of event timer patch this problem should not happen. >> You can get latest version of the patch here: >> http://people.freebsd.org/~mav/timers_oneshot13.patch > > I'll try your patch as well after math/atlas has finished building. I > assume it applies cleanly to head, and this one is most likely to end up > being committed? This version should be good enough. I am running it on all I have. Now I need to optimize some surrounding things and the next version has a good chances to get into HEAD soon. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:28: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 8238F106564A for ; Fri, 10 Sep 2010 16:28:25 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3785E8FC19 for ; Fri, 10 Sep 2010 16:28:25 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o8AGSNU9070926 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2010 09:28:24 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C8A5CA0.1050700@feral.com> Date: Fri, 10 Sep 2010 09:28:16 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Fri, 10 Sep 2010 09:28:24 -0700 (PDT) Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:28:25 -0000 I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:41: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 10187106566C for ; Fri, 10 Sep 2010 16:41:16 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id C26BD8FC16 for ; Fri, 10 Sep 2010 16:41:15 +0000 (UTC) Received: from hrndva-omtalb.mail.rr.com ([10.128.143.51]) by hrndva-qmta04.mail.rr.com with ESMTP id <20100910162505645.JCCC23474@hrndva-qmta04.mail.rr.com> for ; Fri, 10 Sep 2010 16:25:05 +0000 X-Authority-Analysis: v=1.1 cv=B7Pj8GqnuGREL1Ssc7DCARZD8q26a0DDU4WStOn6m+0= c=1 sm=0 a=IkcTkHD0fZMA:10 a=OMaL7NPZKRlF0iNpa8vKQw==:17 a=xLGr_N19OWKB513NkF4A:9 a=1H0LXzmcOilwMc20pSsDI_DTXpYA:4 a=QEXdDO2ut3YA:10 a=OMaL7NPZKRlF0iNpa8vKQw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.68.139.23 Received: from [74.68.139.23] ([74.68.139.23:42438] helo=localhost) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id B0/16-03586-3AB5A8C4; Fri, 10 Sep 2010 16:24:03 +0000 Date: Fri, 10 Sep 2010 12:24:03 -0400 From: Scott Robbins To: Alex Dupre Message-ID: <20100910162403.GA47849@mail.scottro.net> References: <4C8A4EE4.2050503@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C8A4EE4.2050503@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: David DEMELIER , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:41:16 -0000 On Fri, Sep 10, 2010 at 05:29:40PM +0200, Alex Dupre wrote: > David DEMELIER ha scritto: > > I was surprised to see that there is no DHCP server in base, obviously > > it's not difficult to fetch the net/isc-dhcp31-server package but for > > people that would like to setup a new server on FreeBSD quickly they > > will take some time to learn how packages framework works or ports and > > it can be annoying. > As someone who changed from FreeBSD to CentOS, due to a job change, let me say that one of the things I greatly prefer about FreeBSD is that they *don't* make very many assumptions about what the user needs, whereas far too many Linux distributions do the opposite, not only throwing in too much, but often making it difficult to work around what they've decided you need. :) So, I would respectfully disagree. It's easy enough to add a dhcp server if desired, and this way, you don't annoy all the people who DON'T want it. Sincerely, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willow: Why couldn't he be possessed by a puppy, or some ducks? From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 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 5A416106566B for ; Fri, 10 Sep 2010 16:54:47 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD5F08FC1A for ; Fri, 10 Sep 2010 16:54:46 +0000 (UTC) Received: by bwz20 with SMTP id 20so2838608bwz.13 for ; Fri, 10 Sep 2010 09:54:45 -0700 (PDT) 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=7ImUDzh8e8SgJPoNWoW+Aa8FnVbNwgnarhVZiYhEk20=; b=WVBr4aA6j9KZlpWx4WdMlcKbPdAPRPWl5Ips1QQaoBVqZ6xiItyeU28iIh9jeN6nfz p2XqJEPrxjFsZVeSrmTYjDLZhRn2zfKeowD3jiHgvq5vwguvBTVB/B8bQxokSfV5SiCC i9bEkCCixEYFRGGIjiDg/qutLpAbZb06065CM= 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=ubY07OQ5A4HvtOQY+UnUklm0aAk+bb1N8/Px/0jHJGeWXP0by7Oz15r6pP4YdAKE5G R1v+vfNyVN1GAhzh/V7kr3i+aeFdKi5MfWiCh8ZBSoMqhlD/EYqfYMkczlEHukdP1kEK Jzfixl5XtxAr8BiPu0is1h0Ul5neYBzkPqT3g= MIME-Version: 1.0 Received: by 10.204.153.10 with SMTP id i10mr769610bkw.1.1284137685583; Fri, 10 Sep 2010 09:54:45 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Fri, 10 Sep 2010 09:54:45 -0700 (PDT) In-Reply-To: <4C8A5CA0.1050700@feral.com> References: <4C8A5CA0.1050700@feral.com> Date: Fri, 10 Sep 2010 18:54:45 +0200 Message-ID: From: David DEMELIER To: Matthew Jacob Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:54:47 -0000 2010/9/10 Matthew Jacob : > =C2=A0I think not. You are given the opportunity to install prebuilt pack= ages at > install time, and with a modest amount of effort can install prebuilt > packages afterwards. > > IMO, such as it is, there should be *less* in the base system than there > currently is and more in ports. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? And what about bind too? A lot of user do not needs it, by the way there is already src.conf(5) to enable or disable modules, then a WITHOUT_DHCPD would be useful. Cheers. --=20 Demelier David From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:02: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 127F7106566B for ; Fri, 10 Sep 2010 18:02:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id AD2498FC14 for ; Fri, 10 Sep 2010 18:02:58 +0000 (UTC) Received: (qmail 9782 invoked by uid 399); 10 Sep 2010 18:02:57 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Sep 2010 18:02:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8A72D2.1010507@FreeBSD.org> Date: Fri, 10 Sep 2010 11:02:58 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Mike Tancsa References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> <4C89663D.5050007@FreeBSD.org> <201009100754.o8A7sXLt078290@lava.sentex.ca> In-Reply-To: <201009100754.o8A7sXLt078290@lava.sentex.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 18:02:59 -0000 On 9/10/2010 12:54 AM, Mike Tancsa wrote: > At 06:57 PM 9/9/2010, Doug Barton wrote: > >>> Normally they are pointed to a local mirror here at Sentex. However, >>> that server was having hardware problems which I think we have isolated >>> and resolved now. I will repoint this tinderbox to the local site again. >> >> The best way to handle this would be to have messages about csup >> failing to be directed only to those who are actually able to fix the >> problem. Assuming that the cvsup server is always going to work is >> contrary to both history and good system administration practices. :) >> >>> Perhaps as an interim measure a local procmail rule to filter out cvsup >>> failures from going to the list ? >> >> That's a particularly unhelpful response. Not only is it borderline >> rude to attempt to shift the responsibility for this to the users, >> it's a violation of the robustness principle. > > I meant "local procmail rule" as in local to the tinderboxes so that des > and myself and others who admin the boxes only get such messages. I > didnt want to make such changes without des' approval and was waiting > for his input... In that case I apologize for the misunderstanding. I've used procmail for many years on the receiving end but was not aware of the ability to use it in the manner you suggested. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:22: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 0EE4B1065675; Fri, 10 Sep 2010 18:22:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id B98F28FC17; Fri, 10 Sep 2010 18:22:47 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o8AIMMUH061645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 14:22:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o8AIML7Y081437; Fri, 10 Sep 2010 14:22:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009101822.o8AIML7Y081437@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Sep 2010 14:22:13 -0400 To: Doug Barton From: Mike Tancsa In-Reply-To: <4C8A72D2.1010507@FreeBSD.org> References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> <4C89663D.5050007@FreeBSD.org> <201009100754.o8A7sXLt078290@lava.sentex.ca> <4C8A72D2.1010507@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-current@FreeBSD.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 18:22:48 -0000 At 02:02 PM 9/10/2010, Doug Barton wrote: >In that case I apologize for the misunderstanding. I've used >procmail for many years on the receiving end but was not aware of >the ability to use it in the manner you suggested. Have the tinderbox send just one email to a local account, then use procmailrc to figure out where to send copies. ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:24: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 4B04B10656A5 for ; Fri, 10 Sep 2010 18:24:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D13158FC26 for ; Fri, 10 Sep 2010 18:24:51 +0000 (UTC) Received: (qmail 10287 invoked by uid 399); 10 Sep 2010 18:24:51 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Sep 2010 18:24:51 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8A77F5.2070304@FreeBSD.org> Date: Fri, 10 Sep 2010 11:24:53 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Mike Tancsa References: <201009081055.o88Atvu8050938@freebsd-current.sentex.ca> <20100908130700.GA53378@mail.hs.ntnu.edu.tw> <201009081439.o88EdHwh064108@lava.sentex.ca> <4C89663D.5050007@FreeBSD.org> <201009100754.o8A7sXLt078290@lava.sentex.ca> <4C8A72D2.1010507@FreeBSD.org> <201009101822.o8AIML7Y081437@lava.sentex.ca> In-Reply-To: <201009101822.o8AIML7Y081437@lava.sentex.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 18:24:52 -0000 On 9/10/2010 11:22 AM, Mike Tancsa wrote: > At 02:02 PM 9/10/2010, Doug Barton wrote: > >> In that case I apologize for the misunderstanding. I've used procmail >> for many years on the receiving end but was not aware of the ability >> to use it in the manner you suggested. > > Have the tinderbox send just one email to a local account, then use > procmailrc to figure out where to send copies. Ah, well, see? That's even more creative than I was giving you credit for. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:36: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 2B12C106564A for ; Fri, 10 Sep 2010 18:36:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C65F88FC0A for ; Fri, 10 Sep 2010 18:36:58 +0000 (UTC) Received: (qmail 26544 invoked by uid 399); 10 Sep 2010 18:36:57 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Sep 2010 18:36:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8A7ACB.9070408@FreeBSD.org> Date: Fri, 10 Sep 2010 11:36:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: David DEMELIER References: <4C8A5CA0.1050700@feral.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Matthew Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 18:36:59 -0000 On 9/10/2010 9:54 AM, David DEMELIER wrote: > 2010/9/10 Matthew Jacob: >> I think not. You are given the opportunity to install prebuilt packages at >> install time, and with a modest amount of effort can install prebuilt >> packages afterwards. >> >> IMO, such as it is, there should be *less* in the base system than there >> currently is and more in ports. I agree with Matt on this one, although that shouldn't be a surprise since I'm on record saying it often. :) > In this case there are some parts in base/ that could live in ports/ > instead of the base directory such as hostapd(8), maybe nobody want to > make a usable wireless access point? Unfortunately arguing to include something new in the base because something else that you don't agree with is already there is not a valid method. The bar is a lot higher for adding things than keeping things (for better or worse). > And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* However, all that is likely to change at some point in the future (as in, years from now) when BIND 10 becomes the only and/or most viable option since it requires a lot of stuff that we are unlikely to ever import into the base (like boost, python, etc.). So there is hope for you anti-BIND folks yet! :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:35: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 332BF1065673 for ; Fri, 10 Sep 2010 19:35:53 +0000 (UTC) (envelope-from fjwcash@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 B45508FC08 for ; Fri, 10 Sep 2010 19:35:52 +0000 (UTC) Received: by fxm4 with SMTP id 4so2347234fxm.13 for ; Fri, 10 Sep 2010 12:35:51 -0700 (PDT) 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:content-type; bh=3xz2Mf7z55R//kkctEUkMcR0FkW5difVxdVy2PRy7Ic=; b=Ezpzpt4I2IL8ay2VaxO6VSwYww7hK37kz5WwhmCtBaxDzH7VpzMZhfpgnHOuyax7dN 71Le8jt3s3EeiRfzJIx59iJdxwWdEXmkv1klHasXfUUWh3kEXiYAKjNa4brlQWJ+3F04 lU2xSxmLD+9RsFhgvnHmOQTTixuNdv1U+yOhg= 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 :content-type; b=Mg90aXLvRe5MYzUb9TWFEZlSfUWuMQiQuvkDpk9Lfw8g1HQTm2M+NxrN38zsizziY5 1ouJ1cWrHlZY9dKy1Ir1rVipkciCwb46XF/0U3LV3JrNEK/zJUzZs89zcv1LTGB8HaK4 Edixx4go/+nxOLRw0t4CVEulERPM3PqiYlk1Y= MIME-Version: 1.0 Received: by 10.223.114.74 with SMTP id d10mr831158faq.1.1284147351478; Fri, 10 Sep 2010 12:35:51 -0700 (PDT) Received: by 10.223.110.69 with HTTP; Fri, 10 Sep 2010 12:35:51 -0700 (PDT) In-Reply-To: <4C8A7ACB.9070408@FreeBSD.org> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> Date: Fri, 10 Sep 2010 12:35:51 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:35:53 -0000 On Fri, Sep 10, 2010 at 11:36 AM, Doug Barton wrote: > On 9/10/2010 9:54 AM, David DEMELIER wrote: >> And what about bind too? > > As I've said many times, I'm ready to have it out when there is consensus to > do so. The usual discussion goes like this: > > 1. Get BIND out of the base! > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. > 3. Oh, well, we like those, so keep them, but get rid of the rest! > 4. BIND is library based, so 90% of the work to make the command line tools > is building the libs, after which building the server and its accessories is > trivial work. > 5. Oh, well, then make knobs to disable the server! > 6. That's already done. > 7. Oh, well, never mind then *mumble mumble* Possibly off-topic for this particular thread, but the above reminded me of what DragonflyBSD just went through, as they removed BIND from their base install: importing a smaller codeset that provides the same functionality as the BIND tools[1]. However, that may or may not be a net gain, as then you need someone to maintain those non-BIND tools. But, if one looks at the Perl situation when it was removed from base, couldn't one remove BIND, but have the package listed as mandatory install, the way Perl was for awhile (or maybe still is)? This is also something that DragonflyBSD does, using pkgsrc packages for things they want installed by default, but that they don't want to maintain as part of their source tree. Of course, then you have to train everyone to use /usr/local/etc/named instead of /etc/named. :) (But, it's that what major version updates and .0 releases are for?) [1] http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg00003.html -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:37: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 A3D43106566B; Fri, 10 Sep 2010 19:37:57 +0000 (UTC) (envelope-from kimelto@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 4662D8FC19; Fri, 10 Sep 2010 19:37:57 +0000 (UTC) Received: by qwg5 with SMTP id 5so1943277qwg.13 for ; Fri, 10 Sep 2010 12:37:56 -0700 (PDT) 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=HaN3Ib/UKIQAA9Z0CQzzwVFbD/a8uYp/yKB04o8DHac=; b=nebrUHzy375oSDaVBc8GCj1xpqVc2mCcEgLHmBfqmeJbFe3vk8u7gXJJBnZHNT5nFz EMMw5eOOTUmLC6QDItIn4QBTnPd1SJWGaziyerCX9kD3nWbvpcyNBzZRIuZyxsrVDvDx c8K+jSbjiGeTujSbB6ktDyLb8fnt/1Lr9GBuA= 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=goKVsbA4kHtYePFjNeqBSmGa+KC2kq+U/Q6NwWEM3pIIFMWS39pNKZETCwoAKhtLAy WmVx6XnZdv2vJjAHU6nucqNXUe6tJRYEoGzEPJwWvWo7mmFkiVaSY0LjZZkcpB4lZN5Z V0V60/lQke8I1zaVSUmM0LofRayR9hyhXAXTY= MIME-Version: 1.0 Received: by 10.229.181.205 with SMTP id bz13mr836512qcb.137.1284145607867; Fri, 10 Sep 2010 12:06:47 -0700 (PDT) Received: by 10.229.233.1 with HTTP; Fri, 10 Sep 2010 12:06:45 -0700 (PDT) In-Reply-To: <4C8A7ACB.9070408@FreeBSD.org> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> Date: Fri, 10 Sep 2010 21:06:45 +0200 Message-ID: From: Julien Laffaye To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: David DEMELIER , freebsd-current@freebsd.org, Matthew Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 19:37:57 -0000 On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton wrote: > As I've said many times, I'm ready to have it out when there is consensus to > do so. The usual discussion goes like this: > > 1. Get BIND out of the base! > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. Don't know if it meet our requirements, though. [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg00003.html From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 20:28: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 007A11065672; Fri, 10 Sep 2010 20:28:57 +0000 (UTC) (envelope-from weongyo.jeong@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 5AFAE8FC08; Fri, 10 Sep 2010 20:28:55 +0000 (UTC) Received: by wyb33 with SMTP id 33so3763879wyb.13 for ; Fri, 10 Sep 2010 13:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=pz8YnX9Pm9ap+CR/qDC/J8aXBIdqAnWcxDBo3dcCug4=; b=Vh/C83slj5Biqw58BHHaR5mmlaklipck8mIZYuCcCsKdsQEDBCXXdkalQGa6wB8EMd /jqN0hv1yJCE+uFMUFdzpZe3/0j8PWn75idQJQbfyojBCOYcA23rcqrgoUr0BloEfDWA 0B95RQheyNL47+skakJ5cCf6s8zfj32VhS3Iw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=ZCYDjiHmfTmSfgxyuVD1a7PlHpOZkmLfRMI/kA655e28c9EAWW+m7gM3Sj+5kW0Fo7 iRSUWSAYp/J0nnJ1uLAgHSsJp84iLctwl3wpMyNSGJNqROBwexxZRGAUibAefljzbNec KTIMLfcYuaiwjRe9xBvdYQu5kD6VSwn4jqhCg= Received: by 10.227.141.77 with SMTP id l13mr339487wbu.77.1284150534216; Fri, 10 Sep 2010 13:28:54 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id b23sm2586922wbb.4.2010.09.10.13.28.51 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 13:28:52 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Fri, 10 Sep 2010 13:28:58 -0700 From: Weongyo Jeong Date: Fri, 10 Sep 2010 13:28:58 -0700 To: John Baldwin Message-ID: <20100910202858.GI1328@weongyo> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org References: <20100908201419.GF1328@weongyo> <201009090936.19412.jhb@freebsd.org> <20100909174146.GG1328@weongyo> <201009091432.52066.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009091432.52066.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong 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 Sep 2010 20:28:57 -0000 On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > Hello, > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > when it's initialized so I always encounters the following LOR > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > > > netinet/in_mcast.c:1095 > > > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > _witness_debugger() at _witness_debugger+0x2e > > > > witness_checkorder() at witness_checkorder+0x807 > > > > _sx_xlock() at _sx_xlock+0x55 > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > axe_cmd() at axe_cmd+0xc7 > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > axe_setmulti() at axe_setmulti+0x3e > > > > axe_ioctl() at axe_ioctl+0x132 > > > > if_addmulti() at if_addmulti+0x19b > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > in_joingroup() at in_joingroup+0x52 > > > > in_control() at in_control+0x1144 > > > > ifioctl() at ifioctl+0x1118 > > > > kern_ioctl() at kern_ioctl+0xbe > > > > ioctl() at ioctl+0xfd > > > > syscallenter() at syscallenter+0x1aa > > > > syscall() at syscall+0x4c > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > case SIOCADDMULTI: > > > > case SIOCDELMULTI: > > > > axe_setmulti(sc, 0); > > > > break; > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > My question is that is it safe if the multicasting operations for USB > > > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > > > task is deferred? > > > > > > Why is USB using an sx lock instead of a mutex? > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > of things I'd like to change it. > > > > Just looking the comment at usb_request.c@441: > > > > /* > > * Grab the default sx-lock so that serialisation > > * is achieved when multiple threads are involved: > > */ > > sx_xlock(&udev->ctrl_sx); > > > > I think he might want to hold the lock even if the thread is going into > > sleep. It might be for serialization. > > > > However even if we succeed to change the lock from sx to mutex, it's > > hard to avoid the requests going into the sleep. It means USB stack > > should call like below: > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > to avoid the kernel's complain (would be `sleep with holding > > non-sleepable lock'). > > > > What I'd like to say is that the sleeping is big problem if mutex is > > used that it'd be worse when multiple mutex locks are used. > > > > So I'm looking for a fundamental solution to solve this problem. > > Welcomes any ideas. > > It is probably fine to just schedule a task to do the actual work of > axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in > your task handler as long as your handler holds the appropriate lock > (if_maddr_rlock() IIRC) when walking the interface's multicast address list. OK. I'll try to use a task handler for this case. One thing, just for curious. Why the lower layer (in this case it might be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? If it calls ioctl without holding the lock, all drivers (specially all USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to implement their own taskqueue or process context. It looks to me that calling ioctl interface with holding IN_MULTI_LOCK is useless if the drivers hold if_maddr_rlock(ifp) lock properly though I could miss something important. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 20:57: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 E2969106566B for ; Fri, 10 Sep 2010 20:57:07 +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 8D6F08FC13 for ; Fri, 10 Sep 2010 20:57:07 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C4568A5FB83; Sat, 11 Sep 2010 04:57:03 +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 fWdrC3H5lx7v; Sat, 11 Sep 2010 04:56:50 +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 B953AA5FA80; Sat, 11 Sep 2010 04:56:47 +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:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=MENiMeBCc8fxfCqZl7l1yHC6pXnxKngBj7JpMtYuaJUevUVFGIp29/eGqZYUXyQC/ Ufyz0J0RU1UVIMFYVQcuw== Message-ID: <4C8A9B8B.1000006@delphij.net> Date: Fri, 10 Sep 2010 13:56:43 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100909 Thunderbird/3.0.7 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: g_event spinning 100% when doing 'gpart add' 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: Fri, 10 Sep 2010 20:57:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On a brand new system I'm trying to allocate new GPT partition with: gpart create -s gpt ada0 gpart add -t freebsd-zfs ada0 And gpart hangs with "g_waitfor_event" with "g_event" spinning 100% of CPU. Any thoughts? The system is FreeBSD/amd64 on Atom D510 with reasonably new FreeBSD -CURRENT code. 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) iQEcBAEBCAAGBQJMipuLAAoJEATO+BI/yjfBxKoH/25/aQYEbDbYu9rXbsTpUdgw tpHhEYqePJfe9u+Xx4ivFEnasOdIsyWcVVYcuGkdXw6gtYFBK3Zvz21au3AeexeI JIj+v8go5nLy4zQ67CAzkUo4bpmr8g+yiknJzNXD1OtDFaRM/D2NT3SqZbpLAf8i Y4mq2u1Drv1CYnBPTzwgaUd+CKDcV1NtK6MDUOCWAZQLP3z1/iUKn0j385AWSKjC GKHcr4A8NvaNu9otgWBK46UmfzFy8wnhMLW5tu8Sh8OpXFX9HsgTjnGdX/dfBN3A rdjI4ItHj0wZ8iHLLD+y4orYl9cnFUHVJwUaFaBF9WcIWudEC4Tw5yoLXDzK29E= =RqkR -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 21:17:58 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 8B26F106564A; Fri, 10 Sep 2010 21:17:58 +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 5B4318FC17; Fri, 10 Sep 2010 21:17:58 +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 0CB3046B0C; Fri, 10 Sep 2010 17:17:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5FF9A8A03C; Fri, 10 Sep 2010 17:17:49 -0400 (EDT) From: John Baldwin To: Weongyo Jeong Date: Fri, 10 Sep 2010 17:17:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100908201419.GF1328@weongyo> <201009091432.52066.jhb@freebsd.org> <20100910202858.GI1328@weongyo> In-Reply-To: <20100910202858.GI1328@weongyo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009101717.39508.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 10 Sep 2010 17:17:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 21:17:58 -0000 On Friday, September 10, 2010 4:28:58 pm Weongyo Jeong wrote: > On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > > Hello, > > > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > > when it's initialized so I always encounters the following LOR > > > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > > > > netinet/in_mcast.c:1095 > > > > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > > > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > > KDB: stack backtrace: > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > _witness_debugger() at _witness_debugger+0x2e > > > > > witness_checkorder() at witness_checkorder+0x807 > > > > > _sx_xlock() at _sx_xlock+0x55 > > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > > axe_cmd() at axe_cmd+0xc7 > > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > > axe_setmulti() at axe_setmulti+0x3e > > > > > axe_ioctl() at axe_ioctl+0x132 > > > > > if_addmulti() at if_addmulti+0x19b > > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > > in_joingroup() at in_joingroup+0x52 > > > > > in_control() at in_control+0x1144 > > > > > ifioctl() at ifioctl+0x1118 > > > > > kern_ioctl() at kern_ioctl+0xbe > > > > > ioctl() at ioctl+0xfd > > > > > syscallenter() at syscallenter+0x1aa > > > > > syscall() at syscall+0x4c > > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > > > case SIOCADDMULTI: > > > > > case SIOCDELMULTI: > > > > > axe_setmulti(sc, 0); > > > > > break; > > > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > > > My question is that is it safe if the multicasting operations for USB > > > > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > > > > task is deferred? > > > > > > > > Why is USB using an sx lock instead of a mutex? > > > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > > of things I'd like to change it. > > > > > > Just looking the comment at usb_request.c@441: > > > > > > /* > > > * Grab the default sx-lock so that serialisation > > > * is achieved when multiple threads are involved: > > > */ > > > sx_xlock(&udev->ctrl_sx); > > > > > > I think he might want to hold the lock even if the thread is going into > > > sleep. It might be for serialization. > > > > > > However even if we succeed to change the lock from sx to mutex, it's > > > hard to avoid the requests going into the sleep. It means USB stack > > > should call like below: > > > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > > > to avoid the kernel's complain (would be `sleep with holding > > > non-sleepable lock'). > > > > > > What I'd like to say is that the sleeping is big problem if mutex is > > > used that it'd be worse when multiple mutex locks are used. > > > > > > So I'm looking for a fundamental solution to solve this problem. > > > Welcomes any ideas. > > > > It is probably fine to just schedule a task to do the actual work of > > axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in > > your task handler as long as your handler holds the appropriate lock > > (if_maddr_rlock() IIRC) when walking the interface's multicast address list. > > OK. I'll try to use a task handler for this case. > > One thing, just for curious. Why the lower layer (in this case it might > be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? > If it calls ioctl without holding the lock, all drivers (specially all > USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to > implement their own taskqueue or process context. > > It looks to me that calling ioctl interface with holding IN_MULTI_LOCK > is useless if the drivers hold if_maddr_rlock(ifp) lock properly though > I could miss something important. It would introduce races in the multicast code to drop the lock around the ioctl which would complicate it a good bit. Non-USB ethernet drivers just use plain locks which handle this situation just fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 21:19: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 B05361065670; Fri, 10 Sep 2010 21:19:28 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 204F18FC1B; Fri, 10 Sep 2010 21:19:27 +0000 (UTC) Received: by fxm4 with SMTP id 4so2427754fxm.13 for ; Fri, 10 Sep 2010 14:19:27 -0700 (PDT) Received: by 10.223.121.7 with SMTP id f7mr895586far.13.1284151742542; Fri, 10 Sep 2010 13:49:02 -0700 (PDT) Received: from rnote.ddteam.net (218-139-132-95.pool.ukrtel.net [95.132.139.218]) by mx.google.com with ESMTPS id h12sm1569935faa.37.2010.09.10.13.49.00 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 13:49:01 -0700 (PDT) Date: Fri, 10 Sep 2010 23:48:30 +0300 From: Aleksandr Rybalko To: Julien Laffaye Message-Id: <20100910234830.87641e07.ray@ddteam.net> In-Reply-To: References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@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: David DEMELIER , Doug Barton , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 21:19:28 -0000 On Fri, 10 Sep 2010 21:06:45 +0200 Julien Laffaye wrote: > On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton wrote: > > As I've said many times, I'm ready to have it out when there is consensus to > > do so. The usual discussion goes like this: > > > > 1. Get BIND out of the base! > > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. > > DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. > Don't know if it meet our requirements, though. > > [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg00003.html > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Hi, another argument about hostapd :) if have access point we must have way to assign IP for AP clients. Last spring I made firmware based on FreeBSD for router with only 4MB NOR flash (D-Link DIR-320). Since this device is router I must be able to serve DHCP. And current implementation of dhcpclient, that we have, is same isc-dhcp, and I replace system dhcpclient with ports one+dhcpd but with small patch that put basic dhcp utils onto libdhcp.so. So: 1. We already have code for libdhcp in base. 2. We already use isc-dhcp as dhcpclient. 3. We already build small-size embedded routers firmware with DHCP server. 4. We have hostap and other router/AP functionality. So why not include dhcpd in base now? -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 22:04:14 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 074201065670 for ; Fri, 10 Sep 2010 22:04:14 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id B7A318FC1E for ; Fri, 10 Sep 2010 22:04:13 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id o8AM4DWV087700 for ; Fri, 10 Sep 2010 16:04:13 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id o8AM4D5n087699 for current@FreeBSD.org; Fri, 10 Sep 2010 16:04:13 -0600 (MDT) (envelope-from ken) Date: Fri, 10 Sep 2010 16:04:13 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Message-ID: <20100910220413.GA87677@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: LSI 6Gb SAS driver committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 22:04:14 -0000 I sent this out to the -scsi list earlier today. Testers would be appreciated for the 6Gb LSI SAS driver. Please follow up to me or the -scsi list. Thanks, Ken ----- Forwarded message from "Kenneth D. Merry" ----- Date: Fri, 10 Sep 2010 09:04:38 -0600 From: "Kenneth D. Merry" To: scsi@freebsd.org Subject: LSI 6Gb SAS driver committed Hey folks, I have commited the mps driver (LSI Logic 6Gb SAS controller driver) to the FreeBSD perforce server (//depot/projects/mps/... and FreeBSD-current. The driver works with SAS and SATA drives, directly attached or attached through expanders. Basic error recovery works as well (i.e. timeouts and aborts). There are some known issues, including: - No support for integrated RAID (IR) arrays. - Devices tend to disappear and come back in one of my configurations. I also see some phantom devices, and events that don't make sense: mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 (da2:mps0:0:6:0): SCSI command timeout on device handle 0x0017 SMID 90 mps0: mpssas_abort_complete: abort request on handle 0x17 SMID 90 complete mps0: Unhandled event 0x0 (probe2:mps0:0:2:0): AutoSense failed mps0: Unhandled event 0x0 (da10:mps0:0:0:0): unsupportable block size 0 (da10:mps0:0:0:0): lost device (da10:mps0:0:0:0): removing device entry (da2:mps0:0:6:0): lost device (da2:mps0:0:6:0): removing device entry da2 at mps0 bus 0 scbus0 target 6 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 150.000MB/s transfers da2: Command Queueing enabled da2: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 - Sometimes you'll run into a device that fails part of the probe on boot, and you'll end up running into the run_interrupt_driven_config_hooks timeout. You see some aborts during probe, and then the 5 minute probe timeout kicks in and panics the kernel. For instance: (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 81 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 81 complete run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 214 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 214 complete run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 281 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 281 complete run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 348 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 348 complete run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 415 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 415 complete panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3d: movq $0,0x4c70b0(%rip) db> - ioctl support isn't complete, and there is no userland utility. - There is no man page. The driver is in the tree at this point to allow people to test it out, report any problems, and hopefully contribute bug fixes. LSI has some developers working on this driver, and we hope to get them to put some of their work-in-progress in the FreeBSD Perforce repo. So, in view of that, if you make any changes to the driver, please make them in the FreeBSD Perforce repository first (in //depot/projects/mps/...) and then merge them into FreeBSD-current. Thanks to Scott Long for writing the driver, and to Yahoo and Spectra Logic for sponsoring the work. Ken -- Kenneth Merry ken@FreeBSD.ORG ----- End forwarded message ----- -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 23:14: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 974C21065672; Fri, 10 Sep 2010 23:14:37 +0000 (UTC) (envelope-from jhellenthal@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 2C9D88FC27; Fri, 10 Sep 2010 23:14:36 +0000 (UTC) Received: by qwg5 with SMTP id 5so2130409qwg.13 for ; Fri, 10 Sep 2010 16:14:36 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=UR/McMYZBGod7lzQeg+W2B4IyNenvehgvR+z/VJ/fzo=; b=Ip9IT5dcuncm8BRDWf+K7DO3QEPQ52Z433viBjsdy8e7ZJ2MLEs2MDfincLIIdiV9V BpCYMDGrpakAdHGOJo3GGYdYCiT98q3tXVo6nTOMbQjjLzQ1utZNhlttuIG6fHZuOI1h EU5i0RqHXBCuETZcDMACRucZERtlUPHLnwPgQ= 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:x-enigmail-version:content-type :content-transfer-encoding; b=U16QYsux0xZpBgudy679tObUi9RsoPUPuKeGcSJE0NpAY/9bfdgU58ORi0G6qtfoGt W1b9T8+I3pf1Bf80OZK9HNPB4it6LTryojEzpW2ZpQgxPt0FCsyjkHdlrToKtozJWj7k hK84c2kKevmsrAycbCCKRdD0qNxwflzX7GV2w= Received: by 10.229.51.206 with SMTP id e14mr506641qcg.232.1284160475773; Fri, 10 Sep 2010 16:14:35 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id r36sm3263461qcs.39.2010.09.10.16.14.33 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 16:14:34 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C8ABBD8.4020109@DataIX.net> Date: Fri, 10 Sep 2010 19:14:32 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Doug Barton References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> In-Reply-To: <4C8A7ACB.9070408@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David DEMELIER , freebsd-current@freebsd.org, Matthew Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:14:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/10/2010 14:36, Doug Barton wrote: > On 9/10/2010 9:54 AM, David DEMELIER wrote: >> 2010/9/10 Matthew Jacob: >>> I think not. You are given the opportunity to install prebuilt >>> packages at install time, and with a modest amount of effort can >>> install prebuilt packages afterwards. >>> >>> IMO, such as it is, there should be *less* in the base system >>> than there currently is and more in ports. > > I agree with Matt on this one, although that shouldn't be a surprise > since I'm on record saying it often. :) > >> In this case there are some parts in base/ that could live in >> ports/ instead of the base directory such as hostapd(8), maybe >> nobody want to make a usable wireless access point? > > Unfortunately arguing to include something new in the base because > something else that you don't agree with is already there is not a > valid method. The bar is a lot higher for adding things than keeping > things (for better or worse). > >> And what about bind too? > > As I've said many times, I'm ready to have it out when there is > consensus to do so. The usual discussion goes like this: > > 1. Get BIND out of the base! 2. If we remove it, the command line > tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, > so keep them, but get rid of the rest! 4. BIND is library based, so > 90% of the work to make the command line tools is building the libs, > after which building the server and its accessories is trivial work. > 5. Oh, well, then make knobs to disable the server! 6. That's already > done. 7. Oh, well, never mind then *mumble mumble* > > However, all that is likely to change at some point in the future > (as in, years from now) when BIND 10 becomes the only and/or most > viable option since it requires a lot of stuff that we are unlikely > to ever import into the base (like boost, python, etc.). So there is > hope for you anti-BIND folks yet! :) > > > Doug > This is where I say: I believe it would be the correct route to move toward a base package system for things like BIND DHCP... the common stuff that people would like to see in base but not really a conceptional sound idea. My theory behind this goes like this: Make a base package for bind-server, bind-utils, bind-tools or whatever you want to call them with the --package-root defined as /. Do this for ports/lang etc... type of stuff and ship them with the install CD/DVD's. If the user wants the base port then there is no harm done and they can trivially add it. This would leave room for other base system options to include too without having to permanently move things in and out of base because supporting them in-tree does not make sense or other reasons. Specifically I like this type of idea due to not needing to have a compiler (GCC) installed at all times. It could simply be added and removed from the base system by package or installed from ports and allow the end user to choose what they want when they want it. Stuff like GCC, BIND, DHCP Servers & other languages for this make sense. Why Not ? Regards, PS: I'll coin this idea (base-board-ports) .02 - -- jhell,v -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMirvXAAoJEJBXh4mJ2FR+SocH/3pK3s8L9bOb12a6IhhrKSdI mJZeFSyMdx3n4olIkd1VhYA2O6Qsl6hUBASitpbiJ3/9Vz/BAcCW2JE+Ub0rDwZT SG7vk0aaCtjFEBk5xdLM52iDKIGs5uNaKxYQMot0KX4pi/Obm7Pf8AGmQpc8RnSd PBbUX5T0kzbStPE59tQA9gW2UcTxKtx2up+Pzns8mYvUEb+dgEuwPo2rE10aZKuK lnfoZ2LclmQg1KmvzZATrRUxFjHdJQqD4PgPFGEAAWVDlzAFnwQhBufYtyT71lqZ 0T+XW5WQUo6WjjtweyV6uhfPeJUuk+DqkmDGw8oJIRfqYOm3yetSKiOoAgmJ9Qo= =brrR -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 23:16: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 E1EB2106566B; Fri, 10 Sep 2010 23:16:45 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 75DD28FC1E; Fri, 10 Sep 2010 23:16:45 +0000 (UTC) Received: by qyk4 with SMTP id 4so3615505qyk.13 for ; Fri, 10 Sep 2010 16:16:44 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=/ej5Fx8NxWTCtQ3btIgIa2MaRHTuesL6fpNRLYHMdjo=; b=QoiEvZpFDPx0QnaAMpSLN0AdP0vAXRqIvd25rKjXPrAEiyQHxFbXo2LaYem4h9oXR3 GxNh65dOpJLy1euGVgRGQst3Xa/WmLz2hMT41pI61C+CMoieSnQ5ok0ZAWgoKhDCmuba sINah3HA2UBA1C2w3RPU/yneXw+yurgnECplg= 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:x-enigmail-version:content-type :content-transfer-encoding; b=jJ02rB/EdQA/Rj4nazSI+AkCN5OIpAd3XSV/OIqXRYbqYDF5Cni0wj084ZtjAvSyUg 19VC8/iAqbRMFf9IGQqja6CmbzpDTq39fuPKEKPJc2sfoH8dJ5uX2ajUHIYvi2juDLMi FM87VS591c6qlchJS0YUwazyn6S1ywQ/BtUWQ= Received: by 10.224.37.19 with SMTP id v19mr855368qad.66.1284160604687; Fri, 10 Sep 2010 16:16:44 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id r1sm3267205qcq.34.2010.09.10.16.16.42 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 16:16:43 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C8ABC59.9060704@DataIX.net> Date: Fri, 10 Sep 2010 19:16:41 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Doug Barton References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <4C8ABBD8.4020109@DataIX.net> In-Reply-To: <4C8ABBD8.4020109@DataIX.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David DEMELIER , freebsd-current@freebsd.org, Matthew Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:16:46 -0000 On 09/10/2010 19:14, jhell wrote: > On 09/10/2010 14:36, Doug Barton wrote: >> On 9/10/2010 9:54 AM, David DEMELIER wrote: >>> 2010/9/10 Matthew Jacob: >>>> I think not. You are given the opportunity to install prebuilt >>>> packages at install time, and with a modest amount of effort can >>>> install prebuilt packages afterwards. >>>> >>>> IMO, such as it is, there should be *less* in the base system >>>> than there currently is and more in ports. > >> I agree with Matt on this one, although that shouldn't be a surprise >> since I'm on record saying it often. :) > >>> In this case there are some parts in base/ that could live in >>> ports/ instead of the base directory such as hostapd(8), maybe >>> nobody want to make a usable wireless access point? > >> Unfortunately arguing to include something new in the base because >> something else that you don't agree with is already there is not a >> valid method. The bar is a lot higher for adding things than keeping >> things (for better or worse). > >>> And what about bind too? > >> As I've said many times, I'm ready to have it out when there is >> consensus to do so. The usual discussion goes like this: > >> 1. Get BIND out of the base! 2. If we remove it, the command line >> tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, >> so keep them, but get rid of the rest! 4. BIND is library based, so >> 90% of the work to make the command line tools is building the libs, >> after which building the server and its accessories is trivial work. >> 5. Oh, well, then make knobs to disable the server! 6. That's already >> done. 7. Oh, well, never mind then *mumble mumble* > >> However, all that is likely to change at some point in the future >> (as in, years from now) when BIND 10 becomes the only and/or most >> viable option since it requires a lot of stuff that we are unlikely >> to ever import into the base (like boost, python, etc.). So there is >> hope for you anti-BIND folks yet! :) > > >> Doug > > > This is where I say: I believe it would be the correct route to move > toward a base package system for things like BIND DHCP... the common > stuff that people would like to see in base but not really a > conceptional sound idea. > > My theory behind this goes like this: Make a base package for > bind-server, bind-utils, bind-tools or whatever you want to call them > with the --package-root defined as /. Do this for ports/lang etc... type > of stuff and ship them with the install CD/DVD's. If the user wants the > base port then there is no harm done and they can trivially add it. This > would leave room for other base system options to include too without > having to permanently move things in and out of base because supporting > them in-tree does not make sense or other reasons. > > Specifically I like this type of idea due to not needing to have a > compiler (GCC) installed at all times. It could simply be added and > removed from the base system by package or installed from ports and > allow the end user to choose what they want when they want it. Stuff > like GCC, BIND, DHCP Servers & other languages for this make sense. Why > Not ? > > > Regards, > > PS: I'll coin this idea (base-board-ports) > > .02 > This is also a conversation for another thread. So please do not let it distract you. -- jhell,v From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 23:16: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 34D9D106570C for ; Fri, 10 Sep 2010 23:16:57 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f08:679::2]) by mx1.freebsd.org (Postfix) with ESMTP id DA5328FC0C for ; Fri, 10 Sep 2010 23:16:56 +0000 (UTC) Received: by muon.cran.org.uk (Postfix, from userid 1002) id 432075F16; Fri, 10 Sep 2010 23:16:49 +0000 (UTC) Date: Fri, 10 Sep 2010 23:16:49 +0000 From: Bruce Cran To: freebsd-current@freebsd.org Message-ID: <20100910231649.GA38476@muon.cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: LAPIC timer reported as 0 Hz during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 23:16:57 -0000 Looking through a dmesg from today I noticed that the LAPIC timer is being reported as running at 0 Hz: Event timer "LAPIC" frequency 0 Hz quality 500 But the correct frequency is still being used in the kernel: kern.eventtimer.et.LAPIC.frequency=67470437 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 00:33: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 28302106566C for ; Sat, 11 Sep 2010 00:33:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C07F78FC0C for ; Sat, 11 Sep 2010 00:33:22 +0000 (UTC) Received: (qmail 16213 invoked by uid 399); 11 Sep 2010 00:33:20 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Sep 2010 00:33:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8ACE52.8060000@FreeBSD.org> Date: Fri, 10 Sep 2010 17:33:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Aleksandr Rybalko References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> In-Reply-To: <20100910234830.87641e07.ray@ddteam.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David DEMELIER , Julien Laffaye , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 00:33:23 -0000 On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > Hi, > > another argument about hostapd :) if have access point we must have > way to assign IP for AP clients. To start with, your assumption is wrong. DHCPd is not *actually* a requirement, although I admit that practically it is. > Last spring I made firmware based on FreeBSD for router with only 4MB > NOR flash (D-Link DIR-320). In this category (micro-miniaturization) you're already in the "significant customization needed" area, which means that general arguments about "the base" don't apply. > Since this device is router I must be > able to serve DHCP. And current implementation of dhcpclient, that we > have, is same isc-dhcp, and I replace system dhcpclient with ports > one+dhcpd but with small patch that put basic dhcp utils onto > libdhcp.so. Your argument is creative and well thought out, but I personally don't find it persuasive. Counter arguments that come immediately to mind are: 1. The DHCP server is not going to benefit any but a small minority of FreeBSD users. 2. The software is already available in the ports tree, and adding a port/package of it really is not an overwhelming burden. More generally, the main reason I want to keep more stuff out of the base, and remove some of the stuff that's in there now, is that it makes maintenance difficult across FreeBSD branches. We have a general policy that if we have a major version N of something in a release branch that we don't upgrade that major version without a really good reason to avoid POLA surprises for our users. Once again using BIND as an example, this has led to a really old and past-EOL version of BIND in FreeBSD 6 which I've only gotten away with because anyone doing serious DNS work nowadays has to upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want to repeat it. The problems get worse and/or more complex with the more 3rd party stuff you start including in the base. In part because of the product lifecycle issues that are similar to BIND's, but also due to the possibility of licensing issues (such as with gcc and/or other GPL software) and other more esoteric factors. Even with home-grown stuff like our pkg_* tools we have problems because when we want to introduce new features (or deprecate old ones) there is currently a _minimum_ 3-year cycle we have to follow in order to make sure that the new feature is/is not available on all supported versions of FreeBSD. That's the main motivation behind my continuing to repeat the suggestion to move those tools specifically into the ports tree so that we can better support innovation in our ports/packages system. In my view what we've needed to do for a long time now is to seriously strip down the notion of what "the base" should be to those items that are needed to work together for a specific API/ABI/AKI release, and move everything else into the ports tree. (Obviously there would be some exemptions made for really basic/vital stuff like ls, etc.) We can do this in a way that finds a middle ground between the linux model where literally everything is a package and the traditional BSD model of providing a "complete system," which is hardly ever true since I've never been involved with any FreeBSD system administration where there were absolutely no ports/packages installed at all. Such a system could also be streamlined by creating a ports virtual category (something like "system") the packages for which could be included in the install media as long as we are judicious about what goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. could all be in that category, and all we'd have to do to make that work is to very slightly expand the list of questions that sysinstall already asks. So this is a much longer version of my previous response which hopefully gives you more background about why it's a bad idea to add *any* more 3rd party stuff to the base. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 01:44: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 08C061065670 for ; Sat, 11 Sep 2010 01:44:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B42CE8FC08 for ; Sat, 11 Sep 2010 01:44:51 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OuF96-0003do-T5 for freebsd-current@freebsd.org; Sat, 11 Sep 2010 03:44:49 +0200 Received: from 142-076-ppp.kubtelecom.ru ([142-076-ppp.kubtelecom.ru]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2010 03:44:48 +0200 Received: from yuri.pankov by 142-076-ppp.kubtelecom.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2010 03:44:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Yuri Pankov Date: Sat, 11 Sep 2010 01:44:40 +0000 (UTC) Lines: 22 Message-ID: References: <4C8A9B8B.1000006@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 213.132.76.142 (Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100908 Firefox/3.6.8) Subject: Re: g_event spinning 100% when doing 'gpart add' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 01:44:52 -0000 Xin LI delphij.net> writes: > > > Hi, > > On a brand new system I'm trying to allocate new GPT partition with: > > gpart create -s gpt ada0 > gpart add -t freebsd-zfs ada0 > And gpart hangs with "g_waitfor_event" with "g_event" spinning 100% of CPU. > > Any thoughts? The system is FreeBSD/amd64 on Atom D510 with reasonably > new FreeBSD -CURRENT code. > > Cheers, Probably result of kernel built with DEBUG_LOCKS and world without -DDEBUG_LOCKS. HTH, Yuri From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 01:57:29 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 6882B106566B for ; Sat, 11 Sep 2010 01:57:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 21EF28FC0A for ; Sat, 11 Sep 2010 01:57:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OuFLL-0006po-6l for freebsd-current@freebsd.org; Sat, 11 Sep 2010 03:57:27 +0200 Received: from 142-076-ppp.kubtelecom.ru ([142-076-ppp.kubtelecom.ru]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2010 03:57:27 +0200 Received: from yuri.pankov by 142-076-ppp.kubtelecom.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2010 03:57:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Yuri Pankov Date: Sat, 11 Sep 2010 01:57:19 +0000 (UTC) Lines: 9 Message-ID: References: <4C8A9B8B.1000006@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 213.132.76.142 (Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100908 Firefox/3.6.8) Subject: Re: g_event spinning 100% when doing 'gpart add' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 01:57:29 -0000 Nevermind me. That's what I thought why I was getting the same gpart behavior switching between kernels, with and without DEBUG_LOCKS. Sorry about that. Same here, gpart hangs on: 3826 gpart CALL __sysctl(0x7fffffffa250,0x3,0,0x7fffffffa268,0,0) 3826 gpart SCTL "kern.geom.confxml" Yuri From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 05:19:13 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 1A66C106567A for ; Sat, 11 Sep 2010 05:19:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 974B18FC12 for ; Sat, 11 Sep 2010 05:19:12 +0000 (UTC) Received: by bwz20 with SMTP id 20so3449512bwz.13 for ; Fri, 10 Sep 2010 22:19:11 -0700 (PDT) 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:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=9RNi+QsTHQ2p8n6xxSN9UGnZ2UspDzt4iJeY1et9xuA=; b=Vof8mQmN6jlBcq02PxEgcVkHemKQv69dnshWzqXwai7KuxiwzaHvJmyn00irtk35Lz /itnv+QVc8gfmHJVS8LbzpbQ4QXfYsmOANyAPU6n2Dw6lPQuwQFrs+VsmzI41AjU5wr0 Vq844Y6X1QRwHooT3vpziGfNPmfkA6BmBsW2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=I/3qsKNuA6/0xt7CSIgvsmcXiYgwr+TbAGfDtgHceyOicTPNEHddlPr1ghsUnduxKi oQQWgCFk820NtEJKxb1nsSAd+4Jo8lgiXTgct2LX22ceXZpJ6HWrAFUxUNFz6SSKij/n HRkliEv3wzNFV5lLTTb+JVxuYvdK2z+yXkpyA= Received: by 10.204.76.130 with SMTP id c2mr1217808bkk.81.1284182351399; Fri, 10 Sep 2010 22:19:11 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x13sm2576926bki.12.2010.09.10.22.19.08 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 22:19:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8B113B.6040607@FreeBSD.org> Date: Sat, 11 Sep 2010 08:18:51 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Cran , FreeBSD-Current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: LAPIC timer reported as 0 Hz during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 05:19:13 -0000 Bruce Cran wrote: > Looking through a dmesg from today I noticed that the LAPIC timer is being > reported as running at 0 Hz: > > Event timer "LAPIC" frequency 0 Hz quality 500 Frequency of LAPIC timer is not reported instantly. It requires calibration to be discovered. Calibration requires time. To reduce boot time I am not calibrating LAPIC timer until it is used first time. With presence of HPET timer there is high chance that LAPIC timer will never be calibrated on significant part of systems. It is not a bug. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 05:33: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 107CF106566B; Sat, 11 Sep 2010 05:33:17 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id EEF8B8FC16; Sat, 11 Sep 2010 05:33:16 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o8B5XB94023818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 22:33:11 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2BDC81CC3A; Fri, 10 Sep 2010 22:33:11 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Fri, 10 Sep 2010 17:33:22 PDT." <4C8ACE52.8060000@FreeBSD.org> Date: Fri, 10 Sep 2010 22:33:11 -0700 From: "Kevin Oberman" Message-Id: <20100911053311.2BDC81CC3A@ptavv.es.net> Cc: David DEMELIER , Aleksandr Rybalko , Julien Laffaye , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 05:33:17 -0000 > Date: Fri, 10 Sep 2010 17:33:22 -0700 > From: Doug Barton > Sender: owner-freebsd-current@freebsd.org > > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > Hi, > > > > another argument about hostapd :) if have access point we must have > > way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. It is not. I routinely use hostapd for access for my iPod. I use static addressing and don't run dhcpd. > > Since this device is router I must be > > able to serve DHCP. And current implementation of dhcpclient, that we > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > one+dhcpd but with small patch that put basic dhcp utils onto > > libdhcp.so. Again, I tend to not make much use of DHCP except when traveling. If I am on a "known" network at work or home, I static address everything (including the iPod and my laptop). I don't need (or run) dhcpd for my use. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:35: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 57B15106566B for ; Sat, 11 Sep 2010 07:35:41 +0000 (UTC) (envelope-from gordon.tetlow@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 1BE748FC0C for ; Sat, 11 Sep 2010 07:35:40 +0000 (UTC) Received: by iwn34 with SMTP id 34so3435325iwn.13 for ; Sat, 11 Sep 2010 00:35:40 -0700 (PDT) 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; bh=ac4nGG1ZpDOxJbAaHGeFN011TRVMsCgxhTX54IQgWcg=; b=tCTvvz1Lt+N0Qbd9tAuKNvdcH0MHxfOR/h1vwVb449w4q7wjjg4hsr72rXMfh9sqN+ eR0WwTAfO9pMs6OaXc7bA9SNzgfIy//VmM8BSCjlZofib8pB+HG0hW9CAc7AfkxIGPNR mgf4nhPQhPWd/CuGuczdtpsPlex1b6V6TnuPo= 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; b=qhvjEfttovKU+EHc8gQnyN0cSbHGnBaq0WM8qV1ulQF1UykzHNyMDmRVxLcS4M7Fh1 k6AI4AKHgFa+OYY0Sdg1wAk3RM6XxlS+PPNhKOV87rHKD4FktzlZhS3Kq9EIG8jcVE6l phSraWs4PE7ShWIqoG3BPCbOUZ6thWFibEVsw= MIME-Version: 1.0 Received: by 10.231.19.3 with SMTP id y3mr2231775iba.156.1284190540570; Sat, 11 Sep 2010 00:35:40 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Sat, 11 Sep 2010 00:35:40 -0700 (PDT) In-Reply-To: <86d3smb83g.fsf@gmail.com> References: <86d3smb83g.fsf@gmail.com> Date: Sat, 11 Sep 2010 00:35:40 -0700 X-Google-Sender-Auth: hFi08PPgc6DUUv6ZFxRKizRUqw4 Message-ID: From: Gordon Tetlow To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 07:35:41 -0000 On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: > Gordon Tetlow writes: > > > 2. Imports configuration from /usr/local/etc/man.d/*.conf and > /etc/man.conf > > (purposefully changed the manpath.config file since it is a different > > syntax). > > Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local > as the only place installed packages may reside in, only default one. > That variable is not easily found in shell. I'm open to suggestions on how to figure it out. I suppose I could try something like make -V LOCALBASE since it would be in /etc/make.conf if it is set. Another alternative would be to parse the PATH and look for ../etc/man.d for each path component. That would be even more generic (and allow for the user to customize it potentially). Thoughts? Gordon From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:41:29 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 611BD106566C for ; Sat, 11 Sep 2010 07:41:29 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id E2C9A8FC0A for ; Sat, 11 Sep 2010 07:41:28 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A407AA09FC; Sat, 11 Sep 2010 07:41:27 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sat, 11 Sep 2010 09:41:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <766041FD-DAE2-484A-AA8F-60DA99A86B9C@lassitu.de> References: <86d3smb83g.fsf@gmail.com> To: Gordon Tetlow X-Mailer: Apple Mail (2.1081) Cc: Anonymous , freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 07:41:29 -0000 Am 11.09.2010 um 09:35 schrieb Gordon Tetlow: > On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: >=20 >> Gordon Tetlow writes: >>=20 >>> 2. Imports configuration from /usr/local/etc/man.d/*.conf and >> /etc/man.conf >>> (purposefully changed the manpath.config file since it is a = different >>> syntax). >>=20 >> Hmm, and if LOCALBASE !=3D /usr/local? hier(7) does not specify = /usr/local >> as the only place installed packages may reside in, only default one. >>=20 >=20 > That variable is not easily found in shell. I'm open to suggestions on = how > to figure it out. I suppose I could try something like make -V = LOCALBASE > since it would be in /etc/make.conf if it is set. Another alternative = would > be to parse the PATH and look for ../etc/man.d for each path = component. That > would be even more generic (and allow for the user to customize it > potentially). Take it from /etc/man.conf, like the rc.d paths are resolved? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:56:32 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 7278E106564A; Sat, 11 Sep 2010 07:56:32 +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 3C4C48FC0A; Sat, 11 Sep 2010 07:56:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8B7uV5Y062024; Sat, 11 Sep 2010 03:56:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8B7uVC3062023; Sat, 11 Sep 2010 07:56:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 Sep 2010 07:56:31 GMT Message-Id: <201009110756.o8B7uVC3062023@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: Sat, 11 Sep 2010 07:56:32 -0000 TB --- 2010-09-11 05:50:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-11 05:50:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-11 05:50:11 - cleaning the object tree TB --- 2010-09-11 05:50:54 - cvsupping the source tree TB --- 2010-09-11 05:50:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-11 05:51:44 - building world TB --- 2010-09-11 05:51:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 05:51:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 05:51:44 - TARGET=powerpc TB --- 2010-09-11 05:51:44 - TARGET_ARCH=powerpc TB --- 2010-09-11 05:51:44 - TZ=UTC TB --- 2010-09-11 05:51:44 - __MAKE_CONF=/dev/null TB --- 2010-09-11 05:51:44 - cd /src TB --- 2010-09-11 05:51:44 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 11 05:51:45 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Sep 11 07:42:35 UTC 2010 TB --- 2010-09-11 07:42:35 - generating LINT kernel config TB --- 2010-09-11 07:42:35 - cd /src/sys/powerpc/conf TB --- 2010-09-11 07:42:35 - /usr/bin/make -B LINT TB --- 2010-09-11 07:42:35 - building LINT kernel TB --- 2010-09-11 07:42:35 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 07:42:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 07:42:35 - TARGET=powerpc TB --- 2010-09-11 07:42:35 - TARGET_ARCH=powerpc TB --- 2010-09-11 07:42:35 - TZ=UTC TB --- 2010-09-11 07:42:35 - __MAKE_CONF=/dev/null TB --- 2010-09-11 07:42:35 - cd /src TB --- 2010-09-11 07:42:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 07:42:35 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/uart/uart_cpu_powerpc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_clocksource.c /src/sys/kern/kern_clocksource.c: In function 'timer2cb': /src/sys/kern/kern_clocksource.c:174: error: 'IPI_STATCLOCK' undeclared (first use in this function) /src/sys/kern/kern_clocksource.c:174: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_clocksource.c:174: error: for each function it appears in.) /src/sys/kern/kern_clocksource.c: In function 'configtimer': /src/sys/kern/kern_clocksource.c:281: error: 'IPI_STATCLOCK' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-11 07:56:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-11 07:56:31 - ERROR: failed to build lint kernel TB --- 2010-09-11 07:56:31 - 5236.97 user 1290.70 system 7579.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 08:14:14 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 34BF51065673; Sat, 11 Sep 2010 08:14:14 +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 07C358FC1F; Sat, 11 Sep 2010 08:14:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8B8EDFB043586; Sat, 11 Sep 2010 04:14:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8B8EDGw043585; Sat, 11 Sep 2010 08:14:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 Sep 2010 08:14:13 GMT Message-Id: <201009110814.o8B8EDGw043585@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: Sat, 11 Sep 2010 08:14:14 -0000 TB --- 2010-09-11 06:11:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-11 06:11:11 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-11 06:11:11 - cleaning the object tree TB --- 2010-09-11 06:12:01 - cvsupping the source tree TB --- 2010-09-11 06:12:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-11 06:12:32 - building world TB --- 2010-09-11 06:12:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 06:12:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 06:12:32 - TARGET=powerpc TB --- 2010-09-11 06:12:32 - TARGET_ARCH=powerpc64 TB --- 2010-09-11 06:12:32 - TZ=UTC TB --- 2010-09-11 06:12:32 - __MAKE_CONF=/dev/null TB --- 2010-09-11 06:12:32 - cd /src TB --- 2010-09-11 06:12:32 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 11 06:12:32 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Sep 11 08:00:55 UTC 2010 TB --- 2010-09-11 08:00:55 - generating LINT kernel config TB --- 2010-09-11 08:00:55 - cd /src/sys/powerpc/conf TB --- 2010-09-11 08:00:55 - /usr/bin/make -B LINT TB --- 2010-09-11 08:00:55 - building LINT kernel TB --- 2010-09-11 08:00:55 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 08:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 08:00:55 - TARGET=powerpc TB --- 2010-09-11 08:00:55 - TARGET_ARCH=powerpc64 TB --- 2010-09-11 08:00:55 - TZ=UTC TB --- 2010-09-11 08:00:55 - __MAKE_CONF=/dev/null TB --- 2010-09-11 08:00:55 - cd /src TB --- 2010-09-11 08:00:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 08:00:55 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/uart/uart_cpu_powerpc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_clocksource.c /src/sys/kern/kern_clocksource.c: In function 'timer2cb': /src/sys/kern/kern_clocksource.c:174: error: 'IPI_STATCLOCK' undeclared (first use in this function) /src/sys/kern/kern_clocksource.c:174: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_clocksource.c:174: error: for each function it appears in.) /src/sys/kern/kern_clocksource.c: In function 'configtimer': /src/sys/kern/kern_clocksource.c:281: error: 'IPI_STATCLOCK' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-11 08:14:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-11 08:14:13 - ERROR: failed to build lint kernel TB --- 2010-09-11 08:14:13 - 4890.38 user 1443.13 system 7381.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:26: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 466A1106564A for ; Sat, 11 Sep 2010 07:26:05 +0000 (UTC) (envelope-from gordon.tetlow@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 06D158FC12 for ; Sat, 11 Sep 2010 07:26:04 +0000 (UTC) Received: by iwn34 with SMTP id 34so3428758iwn.13 for ; Sat, 11 Sep 2010 00:26:04 -0700 (PDT) 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; bh=BGq2HVLD04uUOD8vj9aWDZEqn7cMbdzhVvxraPLn8jY=; b=cKQe0eMss29yVOOsaPHSI69rHPXu21HMbdyUuhNwoen94e/6wlkPkPV2z31NIqMlOo u6jUYZ7IJHFPkpdPML/EtsxENme217gHVf8p772h4cG4AGi0UxE+fW37PkUuej7m/eRl qO/+uHNuDQheEW4m1N3XCILrpgoCPsqAQDKf4= 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; b=Nj2RzpYSB0jLc0yuFBHQCNz3bguj05rnOviw5fU2s9KfFTWwKrbgutzBl3CvzIy9g+ gmomzkXg7TFAmgNLW7fmactFeQS3/XZzHYljuR7ti3wjg1Dtb40KowcCy256TsN2inEi 6pRB8H1eSrcdz98bdv91Q9tgBKrBjIOniRRxk= MIME-Version: 1.0 Received: by 10.231.157.212 with SMTP id c20mr2249144ibx.186.1284189964436; Sat, 11 Sep 2010 00:26:04 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Sat, 11 Sep 2010 00:26:04 -0700 (PDT) In-Reply-To: <868w3aem0a.fsf@gmail.com> References: <86sk2b79oi.fsf@gmail.com> <868w3aem0a.fsf@gmail.com> Date: Sat, 11 Sep 2010 00:26:04 -0700 X-Google-Sender-Auth: 9yhgucrIKniFrZ1Ci_V1dmBlrNc Message-ID: From: Gordon Tetlow To: Anonymous X-Mailman-Approved-At: Sat, 11 Sep 2010 11:01:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 07:26:05 -0000 On Thu, Sep 9, 2010 at 12:48 PM, Anonymous wrote: > The order is still bogus compared to gnu man. If I don't like our > ancient GNU tools and altered PATH in order to prefer ones from ports > then I certainly don't want to view old manpages, too. The base manpath > should be appended *after* any PATH substitutions. > > $ man -aw gperf # man.sh > /usr/share/man/en.UTF-8/man1/gperf.1.gz > /usr/share/man/man1/gperf.1.gz > LOCALBASE/man/man1/gperf.1.gz > > $ man -aw gperf # gnu man > LOCALBASE/man/man1/gperf.1.gz > /usr/share/man/en.UTF-8/man1/gperf.1.gz > > > $ echo $PATH > > > LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin > Fixed this up to no longer add an unconditional system search path. While I'm not planning on supporting MANPATH_MAP, I have added special casing for /bin and /usr/bin as encountered in PATH. > And it doesn't show anything when there are no arguments, not even > returning with exit code > 0. > > $ man # man.sh > > $ man # gnu man > What manual page do you want? > zsh: exit 1 man > Added. Updated drop location at: http://people.freebsd.org/~gordon/man.shar Thanks for the feedback, Gordon From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:27:29 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 72892106566B for ; Sat, 11 Sep 2010 07:27:29 +0000 (UTC) (envelope-from gordon.tetlow@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 267D38FC19 for ; Sat, 11 Sep 2010 07:27:29 +0000 (UTC) Received: by iwn34 with SMTP id 34so3429698iwn.13 for ; Sat, 11 Sep 2010 00:27:28 -0700 (PDT) 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; bh=U+UbSA5uNDxp+eXOtFmm3gaZZoKXREwp2uTio4waMIs=; b=ZwmUCeF7zFDYgWJD9hcAY8ohCl8KJESMMfEqUE8BmXWhZDwhEqoeT5m6mKSF56wor+ HIHla19owQ68gfqYIdoLkH2vQlMHPzRATM95WSpqboBr8QZXW0syrSwZrZ3rs8CfuA1G QeMXHYCZkzrjrQ71UYBUQKDXNldpPxcTYnB2o= 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; b=ixDPnxodIdk6pK0X5V7OYcBUlbfj5XaVucbEwR012t2cM/5DB+IT44OE5fK/iefZlO tUDz+D+ygagY2EPYnuyqNap0K4+xKwBzDY8zNyAsMhqIGY774jxaIs8asXSo3bTeM0AF sTJnLw6uoGtCiW95SAMCPXRVqaeRdmMZRAwMA= MIME-Version: 1.0 Received: by 10.231.31.135 with SMTP id y7mr2154635ibc.139.1284190048698; Sat, 11 Sep 2010 00:27:28 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Sat, 11 Sep 2010 00:27:28 -0700 (PDT) In-Reply-To: <20100910024103.GA77780@freebsd.org> References: <20100910024103.GA77780@freebsd.org> Date: Sat, 11 Sep 2010 00:27:28 -0700 X-Google-Sender-Auth: 6Gaju9GGPmgnn1WAAGSRPv4OfKY Message-ID: From: Gordon Tetlow To: Alexander Best X-Mailman-Approved-At: Sat, 11 Sep 2010 11:05:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 07:27:29 -0000 On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best wrote: > > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages > > would be appreciated. I'm new to manpage authoring and could use a > review. > > you forgot the AUTHORS section in all of the man pages. ;) it's always nice > to > see who wrote the code by reading the man pages and not having to look at > the > source itself imho. > It felt weird to promote myself like that. I might add it. There is certainly precedent for either way. Gordon From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 13:06: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 CB9D310656B1; Sat, 11 Sep 2010 13:06:34 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E68FC17; Sat, 11 Sep 2010 13:06:33 +0000 (UTC) Received: by fxm4 with SMTP id 4so2734882fxm.13 for ; Sat, 11 Sep 2010 06:06:33 -0700 (PDT) Received: by 10.223.121.147 with SMTP id h19mr1421811far.76.1284210392829; Sat, 11 Sep 2010 06:06:32 -0700 (PDT) Received: from rnote.ddteam.net (218-139-132-95.pool.ukrtel.net [95.132.139.218]) by mx.google.com with ESMTPS id a7sm1870321faa.21.2010.09.11.06.06.30 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Sep 2010 06:06:31 -0700 (PDT) Date: Sat, 11 Sep 2010 16:06:02 +0300 From: Aleksandr Rybalko To: Doug Barton Message-Id: <20100911160602.23deab03.ray@ddteam.net> In-Reply-To: <4C8ACE52.8060000@FreeBSD.org> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@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: David DEMELIER , Julien Laffaye , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 13:06:34 -0000 On Fri, 10 Sep 2010 17:33:22 -0700 Doug Barton wrote: > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > Hi, > > > > another argument about hostapd :) if have access point we must have > > way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. > > > Last spring I made firmware based on FreeBSD for router with only 4MB > > NOR flash (D-Link DIR-320). > > In this category (micro-miniaturization) you're already in the > "significant customization needed" area, which means that general > arguments about "the base" don't apply. > > > Since this device is router I must be > > able to serve DHCP. And current implementation of dhcpclient, that we > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > one+dhcpd but with small patch that put basic dhcp utils onto > > libdhcp.so. > > Your argument is creative and well thought out, but I personally don't > find it persuasive. Counter arguments that come immediately to mind are: > 1. The DHCP server is not going to benefit any but a small minority of > FreeBSD users. > 2. The software is already available in the ports tree, and adding a > port/package of it really is not an overwhelming burden. > > More generally, the main reason I want to keep more stuff out of the > base, and remove some of the stuff that's in there now, is that it makes > maintenance difficult across FreeBSD branches. We have a general policy > that if we have a major version N of something in a release branch that > we don't upgrade that major version without a really good reason to > avoid POLA surprises for our users. Once again using BIND as an example, > this has led to a really old and past-EOL version of BIND in FreeBSD 6 > which I've only gotten away with because anyone doing serious DNS work > nowadays has to upgrade to at least 9.6 anyway. But it's an ugly > situation, and I don't want to repeat it. > > The problems get worse and/or more complex with the more 3rd party stuff > you start including in the base. In part because of the product > lifecycle issues that are similar to BIND's, but also due to the > possibility of licensing issues (such as with gcc and/or other GPL > software) and other more esoteric factors. > > Even with home-grown stuff like our pkg_* tools we have problems because > when we want to introduce new features (or deprecate old ones) there is > currently a _minimum_ 3-year cycle we have to follow in order to make > sure that the new feature is/is not available on all supported versions > of FreeBSD. That's the main motivation behind my continuing to repeat > the suggestion to move those tools specifically into the ports tree so > that we can better support innovation in our ports/packages system. > > In my view what we've needed to do for a long time now is to seriously > strip down the notion of what "the base" should be to those items that > are needed to work together for a specific API/ABI/AKI release, and move > everything else into the ports tree. (Obviously there would be some > exemptions made for really basic/vital stuff like ls, etc.) We can do > this in a way that finds a middle ground between the linux model where > literally everything is a package and the traditional BSD model of > providing a "complete system," which is hardly ever true since I've > never been involved with any FreeBSD system administration where there > were absolutely no ports/packages installed at all. > > Such a system could also be streamlined by creating a ports virtual > category (something like "system") the packages for which could be > included in the install media as long as we are judicious about what > goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. > could all be in that category, and all we'd have to do to make that work > is to very slightly expand the list of questions that sysinstall already > asks. > > So this is a much longer version of my previous response which hopefully > gives you more background about why it's a bad idea to add *any* more > 3rd party stuff to the base. > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > Hi, I fully agree with a small exception: Base dhclient -rwxr-xr-x 1 ray wheel 109296 Sep 11 15:53 dhclient Modified isc-dhcp -rwxr-xr-x 1 ray wheel 65316 Jun 4 12:33 dhclient -rwxr-xr-x 1 ray wheel 74768 Jun 4 12:33 dhcpd -rwxr-xr-x 1 ray wheel 12624 Jun 4 12:33 dhcrelay -rwxr-xr-x 1 ray wheel 128752 Jun 4 12:33 libdhcp.so 3 tools basically use same code (I move this code in libdhcp) Now in base already most of this code (Thought this is 70-80%%), why not pick up the remaining 20-30%% that add two useful tools. Maybe better way is writing BSD licensed client/server/relay? Thanks -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14:01: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 F04EB106566C for ; Sat, 11 Sep 2010 14:01:50 +0000 (UTC) (envelope-from swell.k@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 9B93D8FC29 for ; Sat, 11 Sep 2010 14:01:50 +0000 (UTC) Received: by qwg5 with SMTP id 5so2538826qwg.13 for ; Sat, 11 Sep 2010 07:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :in-reply-to:references:user-agent:date:message-id:mime-version :content-type; bh=yUVCEKzp3lOmQujtt676eI0Sj6TK86PdAxgqHVkwBnY=; b=tpeAKQJHVeD5N0jIF6R4vNNMc7Hsu59va5PHgjdN385gQTgxU4QwG2HkpUhWbtJnTE tYLFSsdvqa/iYY+dcXOwogVSoeRShnJgmNsH8dTX7F1qzntZ4WvVDMkcf6QKj/TYQxD3 22nb+cKXGNOxHu9XVkWNKsjKCq3bWCJm7EboA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; b=NoAn2Sy+QAN/BcBxMievcCy8ZRQ0cYKd3UNxlNuxQTk3G0WvWtzK+VRBoe28GHYpAT Ol+kRKVK2StgqX19o/BCkgyFDyRF7zrd0CvoXaL7LZdz9b3NgyduM3MqXcuqn8X3L2E7 y+y6RfoOz83LRnOU8RBZF1VkFRXQku9omn5Q0= Received: by 10.229.182.141 with SMTP id cc13mr1739668qcb.56.1284213709720; Sat, 11 Sep 2010 07:01:49 -0700 (PDT) Received: from localhost (pool-108-11-203-231.hrbgpa.fios.verizon.net [108.11.203.231]) by mx.google.com with ESMTPS id t1sm4000664qcs.21.2010.09.11.07.01.46 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Sep 2010 07:01:48 -0700 (PDT) From: Anonymous To: Gordon Tetlow In-Reply-To: <766041FD-DAE2-484A-AA8F-60DA99A86B9C@lassitu.de> (Stefan Bethke's message of "Sat, 11 Sep 2010 09:41:25 +0200") References: <86d3smb83g.fsf@gmail.com> <766041FD-DAE2-484A-AA8F-60DA99A86B9C@lassitu.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) Date: Sat, 11 Sep 2010 17:57:13 +0400 Message-ID: <86r5h0peme.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 14:01:51 -0000 Stefan Bethke writes: > Am 11.09.2010 um 09:35 schrieb Gordon Tetlow: > >> On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: >> >>> Gordon Tetlow writes: >>> >>>> 2. Imports configuration from /usr/local/etc/man.d/*.conf and >>> /etc/man.conf >>>> (purposefully changed the manpath.config file since it is a different >>>> syntax). >>> >>> Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local >>> as the only place installed packages may reside in, only default one. >>> >> >> That variable is not easily found in shell. I'm open to suggestions on how >> to figure it out. I suppose I could try something like make -V LOCALBASE Nah, don't bring make(1) dependency. The user may have WITHOUT_MAKE in his src.conf. So, just use LOCALBASE from environment if it's defined. >> since it would be in /etc/make.conf if it is set. Another alternative would >> be to parse the PATH and look for ../etc/man.d for each path component. That How about let user control search_path behaviour? PATH_MAN_SUB bin/../man PATH_MAN_SUB bin/../.man # e.g. for ~/.bin + ~/.man PATH_MAN_SUB /usr/bin/../share/man PATH_CONF_SUB bin/../etc/man.d It's a bit more flexible than MANPATH_MAP ever was. BTW, if you care about aesthetics ../../../../ can be eleminated with realpath(1). >> would be even more generic (and allow for the user to customize it >> potentially). > > Take it from /etc/man.conf, like the rc.d paths are resolved? This'll work, too. I already have to set a bunch of variables in rc.conf because rc.d avoids LOCALBASE as some kind of curse. While environ(7) exist just for that, make using non-default configuration more easy. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14:11: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 6CC401065670 for ; Sat, 11 Sep 2010 14:11:05 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id F10148FC21 for ; Sat, 11 Sep 2010 14:11:04 +0000 (UTC) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 662286BE1F50; Sat, 11 Sep 2010 21:52:54 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1284213174; bh=gzmbZbcRn5Y7xNBAoc2WfVlmPQF3j0E7NEjtFvl9L9c=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=Vz5cPcfxC053lPXs8Pl1/ftwANUUClkyvdBGmnMR/C41t5GW7pyfrF/EMoOcwJQm/ gW+tyxKVh40xYH2T6L8RATr9PFbncSv3m+Z+96Tl6rqMmn69PR62/sgUqfW2cZ//Co SB02tU9aKDgNhW8nNB1lShkoQPA5u8u+MEvLWQE0= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 65CFA6BE1F4C for ; Sat, 11 Sep 2010 21:52:54 +0800 (CST) Date: Sat, 11 Sep 2010 21:52:54 +0800 (CST) From: Tai-hwa Liang To: freebsd-current@freebsd.org Message-ID: <10091121072416.9831@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: bonnie++ failed on locally mounted NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 14:11:05 -0000 Searching PR database for 'drastic I/O error' returns kern/33203, which seems a little bit irrelevant as there is no 'bad cookie' error in -CURRENT. cur /tmp> uname -a FreeBSD cur.local.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Sat Aug 14 07:25:01 CST 2010 root@cur.local.domain:/usr/src/sys/i386/compile/cur i386 cur /tmp> cat /etc/exports /home/test -maproot=root cur /tmp> sudo mount localhost:/home/test /mnt/nfs && cd /mnt/nfs && mount /dev/ad0s2a on / (ufs, NFS exported, local) devfs on /dev (devfs, local, multilabel) /dev/ad0s2e on /var (ufs, local, soft-updates) /dev/ad0s2d.journal on /usr (ufs, asynchronous, NFS exported, local) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad0s2f.eli on /home (ufs, NFS exported, local, soft-updates) localhost:/home/test on /mnt/nfs (nfs) cur /mnt/nfs> bonnie++ Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty Cleaning up test directory after error. Exit 1 cur /mnt/nfs> Reproducible with RELENG_7, RELENG_8 and -CURRENT. However, running bonnie++ on local file system such like UFS won't fail. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14:32: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 72AD7106566C for ; Sat, 11 Sep 2010 14:32:57 +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 1E3A28FC12 for ; Sat, 11 Sep 2010 14:32:56 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o8BEWgQE028660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Sep 2010 16:32:42 +0200 (CEST) (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 o8BEWd1B076854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Sep 2010 16:32:39 +0200 (CEST) (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 o8BEWdDx096946; Sat, 11 Sep 2010 16:32:39 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o8BEWLNl096945; Sat, 11 Sep 2010 16:32:21 +0200 (CEST) (envelope-from ticso) Date: Sat, 11 Sep 2010 16:32:21 +0200 From: Bernd Walter To: Kevin Oberman Message-ID: <20100911143221.GU72692@cicely7.cicely.de> References: <4C8ACE52.8060000@FreeBSD.org> <20100911053311.2BDC81CC3A@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100911053311.2BDC81CC3A@ptavv.es.net> 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: Aleksandr Rybalko , Julien Laffaye , freebsd-current@freebsd.org, David DEMELIER , Doug Barton , Matthew Jacob Subject: Re: DHCP server in base 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: Sat, 11 Sep 2010 14:32:57 -0000 On Fri, Sep 10, 2010 at 10:33:11PM -0700, Kevin Oberman wrote: > > Date: Fri, 10 Sep 2010 17:33:22 -0700 > > From: Doug Barton > > Sender: owner-freebsd-current@freebsd.org > > > > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > > > Hi, > > > > > > another argument about hostapd :) if have access point we must have > > > way to assign IP for AP clients. > > > > To start with, your assumption is wrong. DHCPd is not *actually* a > > requirement, although I admit that practically it is. > > It is not. I routinely use hostapd for access for my iPod. I use > static addressing and don't run dhcpd. With IPv6 you can additionally use stateles autoconfiguration. The requirement for autoconfiguration with DHCP is a problem of IPv4, which won't have a long future for mainstream purspose anymore. Nevertheless there must be a decision about base and not-base and this point will always be questionable to some. I'm also not very strict about bind - it is handy to have dig available, but at the same time it is handy to have whois available, but the whois in base isn't good enough anymore for most cases. A DHCP client however can be required for initial network configuration to retrieve further packages. dig and co can be handy to debug initial network problems, but there are other tools in base for those problems. But to repeat a point which was already made: Someone who can configure a DHCP server really shouldn't have problems to install a package - installing packages or ports is so basic for an operationg system that this is likely one of the first things to learn. Additionally there are ready made systems based on FreeBSD for special purpose, which probably come with the required tools. > > > Since this device is router I must be > > > able to serve DHCP. And current implementation of dhcpclient, that we > > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > > one+dhcpd but with small patch that put basic dhcp utils onto > > > libdhcp.so. DHCP servers don't have to live on routers and there are many reasons to have them installed somewhere else. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14:33: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 39254106564A for ; Sat, 11 Sep 2010 14:33:50 +0000 (UTC) (envelope-from swell.k@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 EE7A08FC1C for ; Sat, 11 Sep 2010 14:33:49 +0000 (UTC) Received: by iwn34 with SMTP id 34so3771032iwn.13 for ; Sat, 11 Sep 2010 07:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=1fMvht/Rs8+chzvENR2V8ymWFsdzMpCZJqbKs19xzdc=; b=GQWCk0vdk1DqEHhY7njEpwK7E/WkwiI5FfFZpj99+maMAgEwnlCHrfOO4nFUW0nHgv PtYiuwVeyOyKNMdteQMkMNlay6ZcTatemA56YPFO47042teKqK5qIu55GwhqSxExusVR YdeAnTGAd2ojKrsO2OFYy4RieqHwlTwUDRH20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=YWFcqMVZtA3BIJy3BFYwSsEqL9uIJE6C9W+jWpAeK1g9WK6/QBrFPGL/cYghzHQHxU 7hAkkkMFLa4ixwZFuiLqnHYkQlpnI9PmjDSwcNuVQFmq5S8B7aX/Vbh2HjnrJEU8AwzS B1R9n+ZHSP1Y6+aY9+CpCBw+tWm61F+5Hp+do= Received: by 10.231.173.9 with SMTP id n9mr2799626ibz.146.1284215629361; Sat, 11 Sep 2010 07:33:49 -0700 (PDT) Received: from localhost (tor-exit-proxy3-readme.formlessnetworking.net [208.53.142.39]) by mx.google.com with ESMTPS id h8sm3703856ibk.21.2010.09.11.07.33.46 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Sep 2010 07:33:48 -0700 (PDT) From: Anonymous To: Gordon Tetlow References: <86d3smb83g.fsf@gmail.com> <766041FD-DAE2-484A-AA8F-60DA99A86B9C@lassitu.de> <86r5h0peme.fsf@gmail.com> Date: Sat, 11 Sep 2010 18:29:21 +0400 In-Reply-To: <86r5h0peme.fsf@gmail.com> (Anonymous's message of "Sat, 11 Sep 2010 17:57:13 +0400") Message-ID: <86k4msmjzy.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 14:33:50 -0000 Anonymous writes: > PATH_MAN_SUB bin/../man > PATH_MAN_SUB bin/../.man # e.g. for ~/.bin + ~/.man > PATH_MAN_SUB /usr/bin/../share/man Oops, that would be non-trivial substitution. It's more like PATH_MAN_ADD bin ../man PATH_MAN_ADD .bin ../.man PATH_MAN_ADD /usr/bin ../share/man And the code for third example would look smth like # set by PATH_MAN_ADD first and second argument from=/usr/bin to=../share/man case "$path" in *$from) p="$path/$to" p=$(realpath $p) add_to_manpath "$p" ;; esac From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 16:49:02 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 4CB51106566C; Sat, 11 Sep 2010 16:49:01 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 01:48:55 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org, freebsd-acpi@FreeBSD.org Message-Id: <20100912014855.984a89ed.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__12_Sep_2010_01_48_55_+0900_PkMnm9kVnw=SlyEC" Cc: nork@FreeBSD.org Subject: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 16:49:02 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__12_Sep_2010_01_48_55_+0900_PkMnm9kVnw=SlyEC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi ACPI specialists! I noticed that CPU cooling doesn't work with testing mav@'s timers_oneshot*.patch, so I got following results: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/3 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 24us dev.cpu.1.cx_supported: C1/3 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 485us dev.cpu.2.cx_supported: C1/3 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 155us dev.cpu.3.cx_supported: C1/3 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 590us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I did enable ACPI debug on /boot/loader.conf like following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - debug.acpi.layer="ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_INFO" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I got a result of dmesg, like attached 'dmesg.txt'. I researched that sys/dev/acpica/acpi_cpu.c, but I couldn't understand what's happen. I think that CF-R9's ASL has a _CRT issue, but I couldn't find it in ASL file:-(. What do I do? -- Norikatsu Shigemura --Multipart=_Sun__12_Sep_2010_01_48_55_+0900_PkMnm9kVnw=SlyEC Content-Type: text/plain; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: 7bit ACPI set debug layer 'ACPI_ALL_DRIVERS' level 'ACPI_LV_INFO' 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 #0: Sun Sep 12 01:17:32 JST 2010 nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 Table 'FACP' at 0xda9aea98 Table 'APIC' at 0xda9aef18 Table 'MCFG' at 0xda9b0f18 Table 'HPET' at 0xda9b0e98 Table 'ASF!' at 0xda9af918 Table 'SLIC' at 0xda98ae18 Table 'SSDT' at 0xda9a9018 Table 'SSDT' at 0xda9a8c18 Table 'SSDT' at 0xda9a7c98 Table 'DMAR' at 0xda9a8f18 Table 'TCPA' at 0xda9b0e18 Table 'SSDT' at 0xda973a98 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80be1000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80be13b0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80be1a58. Preloaded elf obj module "/boot/kernel/krpc.ko" at 0xffffffff80be2088. Preloaded elf obj module "/boot/kernel/if_iwn.ko" at 0xffffffff80be26b0. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80be2c58. Preloaded elf obj module "/boot/kernel/acpi_panasonic.ko" at 0xffffffff80be2cb8. Calibrating TSC clock ... TSC clock: 1197028710 Hz CPU: Intel(R) Core(TM) i7 CPU U 640 @ 1.20GHz (1197.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4303355904 (4104 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000c12000 - 0x00000000d254ffff, 3516129280 bytes (858430 pages) 0x00000000da969000 - 0x00000000da96dfff, 20480 bytes (5 pages) 0x00000000daa04000 - 0x00000000db3fffff, 10469376 bytes (2556 pages) 0x0000000100000000 - 0x0000000117feffff, 402587648 bytes (98288 pages) avail memory = 3907776512 (3726 MB) Event timer "LAPIC" frequency 0 Hz quality 600 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000023000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf0410 00024 (v02 MATBIO) ACPI: XSDT 0xda9afe18 00084 (v01 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: FACP 0xda9aea98 000F4 (v04 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDA9C1F40/0x00000000DA9D5D40, using 32 (20100806/tbfadt-586) ACPI: DSDT 0xda957018 119B4 (v01 MATBIO CFR9-1 00000000 INTL 20061109) ACPI: FACS 0xda9c1f40 00040 ACPI: APIC 0xda9aef18 0008C (v02 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: MCFG 0xda9b0f18 0003C (v01 MATBIO CFR9-1 06222004 MSFT 00000097) ACPI: HPET 0xda9b0e98 00038 (v01 MATBIO CFR9-1 06222004 AMI. 00000003) ACPI: ASF! 0xda9af918 00063 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: SLIC 0xda98ae18 00176 (v01 MATBIO CFR9-1 06222004 AMI 00010013) ACPI: SSDT 0xda9a9018 009F1 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: SSDT 0xda9a8c18 00259 (v01 PmRef Cpu0Tst 00003000 INTL 20061109) ACPI: SSDT 0xda9a7c98 0020F (v01 PmRef ApTst 00003000 INTL 20061109) ACPI: DMAR 0xda9a8f18 000B8 (v01 INTEL CP_DALE 00000001 INTL 00000001) ACPI: TCPA 0xda9b0e18 00032 (v02 MATBIO CFR9-1 00000001 MSFT 01000013) ACPI: SSDT 0xda973a98 002EF (v01 SataRe SataTabl 00001000 INTL 20061109) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> random: cpuctl: access to MSR registers/cpuid info. VESA: INT 0x10 vector 0xc000:0x0014 VESA: information block 0000 56 45 53 41 00 03 00 01 00 02 01 00 00 00 40 00 0010 00 02 ff 01 00 01 3e 01 00 02 50 01 00 02 7c 01 0020 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0110 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0120 20 43 68 69 70 73 65 74 20 41 63 63 65 6c 65 72 0130 61 74 65 64 20 56 47 41 20 42 49 4f 53 00 49 6e 0140 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 0150 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0160 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0170 20 43 6f 6e 74 72 6f 6c 6c 65 72 00 48 61 72 64 0180 77 61 72 65 20 56 65 72 73 69 6f 6e 20 30 2e 30 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 9 mode(s) found VESA: v3.0, 32704k memory, flags:0x1, mode table:0xffffff8000079040 (2000040) VESA: Intel(R)Ironlake Mobile Graphics Chipset Accelerated VGA BIOS VESA: Intel Corporation Intel(R)Ironlake Mobile Graphics Controller Hardware Version 0.0 io: kbd: new array size 4 kbd1 at kbdmux0 mem: crypto: null: smbios0: at iomem 0xf0440-0xf045e on motherboard smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: on motherboard crypto: assign aesni0 driver id 0, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 1, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI Error (dswload-0772): [DD02] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI: Executed 5 blocks of module-level executable AML code AcpiOsDerivePciId: \\_SB_.PCI0.SBUS.SMPB -> bus 0 dev 31 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.CPBG.IMCH.PBUS -> bus 63 dev 0 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC1 -> bus 0 dev 31 func 0 acpi0: reservation of e0000, 20000 (3) failed ACPI timer: 0/15 0/15 0/15 0/15 0/15 0/15 0/16 0/15 0/16 0/16 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) PROCESSOR-0696 [241753] cpu_cx_cst : acpi_cpu0: C2[1] not available. PROCESSOR-0730 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency cpu1: on acpi0 PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) PROCESSOR-0696 [254000] cpu_cx_cst : acpi_cpu1: C2[1] not available. PROCESSOR-0730 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency cpu2: on acpi0 PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 PROCESSOR-0696 [255657] cpu_cx_cst : acpi_cpu2: C2[1] not available. PROCESSOR-0730 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency cpu3: on acpi0 PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 4 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0044, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0046, revid=0x12 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0000000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xe0b0, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10ea, revid=0x06 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4800000, size 17, enabled map[14]: type Memory, range 32, base 0xf4829000, size 12, enabled map[18]: type I/O Port, range 32, base 0xe040, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3b3c, revid=0x06 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4828000, size 10, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b56, revid=0x06 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4820000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3b42, revid=0x06 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b46, revid=0x06 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b48, revid=0x06 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b34, revid=0x06 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4827000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xa6 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b07, revid=0x06 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b2f, revid=0x06 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0xe090, size 3, enabled map[14]: type I/O Port, range 32, base 0xe080, size 2, enabled map[18]: type I/O Port, range 32, base 0xe070, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe060, size 2, enabled map[20]: type I/O Port, range 32, base 0xe020, size 5, enabled map[24]: type Memory, range 32, base 0xf4826000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b30, revid=0x06 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 map[10]: type Memory, range 64, base 0xf4825000, size 8, enabled map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b32, revid=0x06 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf4824000, size 12, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xe0b0-0xe0b7 mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory em0: port 0xe040-0xe05f mem 0xf4800000-0xf481ffff,0xf4829000-0xf4829fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:d3:89:b8:6e ehci0: mem 0xf4828000-0xf48283ff irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac0: mem 0xf4820000-0xf4823fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 51 hdac0: using IRQ 257 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf4600000-0xf47fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xf4400000-0xf45fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x422c, revid=0x35 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4400000, size 13, enabled pcib2: requested memory range 0xf4400000-0xf4401fff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf4400000-0xf4401fff irq 18 at device 0.0 on pci2 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 52 iwn0: using IRQ 258 for MSI iwn0: MIMO 2T2R, MoW, address 00:23:14:21:69:00 iwn0: [MPSAFE] iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 11 pcib3: I/O decode 0xa000-0xbfff pcib3: memory decode 0xf0400000-0xf43fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1180, dev=0xe476, revid=0x00 domain=0, bus=3, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c01000, size 12, enabled pcib3: requested memory range 0xf2c01000-0xf2c01fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x1180, dev=0xe822, revid=0x02 domain=0, bus=3, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c00000, size 8, enabled pcib3: requested memory range 0xf2c00000-0xf2c000ff: good pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 cbb0: mem 0xf2c01000-0xf2c01fff irq 19 at device 0.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xe4761180 0x00100007 0x06070000 0x00820000 0x10: 0xf2c01000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x04000113 0x40: 0x833810f7 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00710010 0x0590ffc0 0x000b2810 0x01076c11 0x90: 0x10110142 0x00000000 0xfe038001 0x48004000 0xa0: 0x00809805 0x00000000 0x00000000 0x00000000 0xb0: 0x30040001 0x00000000 0x08c608c6 0x00000000 0xc0: 0x00003000 0x00000001 0x5e000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x90000000 0xe0: 0x00020000 0x00000000 0x00000000 0x833810f7 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 sdhci0: mem 0xf2c00000-0xf2c000ff irq 16 at device 0.1 on pci3 sdhci0-slot0: 50MHz HS 4bits 3.3V DMA sdhci0-slot0: ============== REGISTER DUMP ============== sdhci0-slot0: Sys addr: 0x00000000 | Version: 0x00000400 sdhci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci0-slot0: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci0-slot0: Caps: 0x01e032b2 | Max curr: 0x00000040 sdhci0-slot0: =========================================== sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] ehci1: mem 0xf4827000-0xf48273ff irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 12 pcib4: subordinate bus 12 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci12: on pcib4 pci12: domain=0, physical bus=12 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe090-0xe097,0xe080-0xe083,0xe070-0xe077,0xe060-0xe063,0xe020-0xe03f mem 0xf4826000-0xf48267ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 55 ahci0: using IRQ 259 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: ichsmb0: port 0xe000-0xe01f mem 0xf4825000-0xf48250ff irq 18 at device 31.3 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 56 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) pcib5: on acpi0 pcib5: could not get PCI interrupt routing table for \\_SB_.CPBG - AE_NOT_FOUND pci63: on pcib5 pci63: domain=0, physical bus=63 found-> vendor=0x8086, dev=0x2c62, revid=0x02 domain=0, bus=63, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d01, revid=0x02 domain=0, bus=63, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d10, revid=0x02 domain=0, bus=63, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d11, revid=0x02 domain=0, bus=63, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d12, revid=0x02 domain=0, bus=63, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d13, revid=0x02 domain=0, bus=63, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi_panasonic0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 900 msi: routing MSI-X IRQ 260 to local APIC 0 vector 57 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 261 to local APIC 0 vector 58 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 262 to local APIC 0 vector 59 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 263 to local APIC 0 vector 60 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 264 to local APIC 0 vector 61 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 265 to local APIC 0 vector 62 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 266 to local APIC 0 vector 63 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 267 to local APIC 0 vector 64 hpet0: [MPSAFE] hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 65 atrtc0: [MPSAFE] atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [MPSAFE] attimer0: [FILTER] ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 66 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi0: wakeup code va 0xffffff8071a1a000 pa 0x4000 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer ichwd0: Intel QM57 watchdog timer (ICH10 or equivalent) ichwd0: timer disabled atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Tj(target) value 105 does not seem right. coretemp0: Setting TjMax=100 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Tj(target) value 105 does not seem right. coretemp1: Setting TjMax=100 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Tj(target) value 105 does not seem right. coretemp2: Setting TjMax=100 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Tj(target) value 105 does not seem right. coretemp3: Setting TjMax=100 est3: on cpu3 p4tcc3: on cpu3 Device configuration finished. ZFS filesystem version 4 ZFS storage pool version 15 Timecounter "TSC" frequency 1197028710 Hz quality -100 lapic: Divisor 2, Frequency 66501575 Hz Timecounters tick every 1.000 msec crypto: Linux ELF exec handler installed IPsec: Initialized Security Association Processing. lo0: bpf attached hdac0: Probing codec #0... hdac0: HDA Codec #0: Conexant (Unknown) hdac0: HDA Codec ID: 0x14f15068 hdac0: Vendor: 0x14f1 hdac0: Device: 0x5068 hdac0: Revision: 0x03 hdac0: Stepping: 0x02 hdac0: PCI Subvendor: 0x833810f7 hdac0: Found audio FG nid=1 startnode=16 endnode=38 total=22 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: Patched pins configuration: hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (15) out: hdac0: Pin nid=25 seq=0 hdac0: Association 1 (15) in: hdac0: Pin nid=26 seq=0 hdac0: Association 2 (15) out: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (15) hdac0: Pin 25 traced to DAC 16 hdac0: Association 0 (15) trace succeeded hdac0: Tracing association 1 (15) hdac0: Pin 26 traced to ADC 20 hdac0: Association 1 (15) trace succeeded hdac0: Tracing association 2 (15) hdac0: Pin 31 traced to DAC 17 hdac0: Association 2 (15) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 17 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 19 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x000f0707 hdac0: mute=0 step=7 size=15 offset=7 hdac0: hdac0: nid: 20 hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x022110f0 hdac0: Pin control: 0x000000c0 HP OUT hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 26 hdac0: Name: pin: Mic (Black Jack) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001324 hdac0: PDC IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02a110f0 hdac0: Pin control: 0x00000024 IN VREFs hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00011334 hdac0: PDC OUT IN VREF[ 50 80 HIZ ] EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000024 hdac0: PDC IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 31 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400501 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x901701f0 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + <- nid=17 [audio output] (selected) hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=18 [audio output] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=33 [audio output] [DISABLED] hdac0: hdac0: nid: 35 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040040b hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: Input amp: 0x002f0400 hdac0: mute=0 step=4 size=47 offset=0 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020050b hdac0: PWR STEREO hdac0: Input amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: ADC: 20 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=25 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=20 [audio input] pcm0: | pcm0: + <- nid=23 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=24 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 7 (nid 23 out): 0/40dB (5 steps) pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 3 (nid 19 out): -28/0dB (8 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) + mute pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 3b60000, 4000; 0xffffff8071a46000 -> 3b60000 pcm0: sndbuf_setmap 3b70000, 4000; 0xffffff8071a56000 -> 3b70000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 17 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=31 [pin: Speaker (Fixed)] pcm1: | pcm1: + <- nid=17 [audio output] [src: pcm] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 3b90000, 4000; 0xffffff8071a66000 -> 3b90000 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 acpi_acad0: acline initialization start battery0: battery initialization start ada0 at ahcich0 bus 0 scbus0 target 0 lun 0GEOM: new disk ada0 ada0: ATA-7 SATA 2.x device ada0: Serial Number DC01S00951SE951A2260 ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number DC01S00951SE951A2260 pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass0: Command Queueing enabled llaappiicc54:: CCMMCIC Iu numnamsaksekedd SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x05000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (GEOM: ada0: partition 4 does not start on a track boundary.ISA IRQ 9acpi_acad0: GEOM: ada0: partition 4 does not end on a track boundary.On Line) to lapic 4 vector 48 acpi_acad0: GEOM: ada0: partition 3 does not start on a track boundary.acline initialization done, tried 1 times GEOM: ada0: partition 3 does not end on a track boundary. GEOM: ada0: partition 2 does not start on a track boundary. ioapic0: routing intpin 12 ( GEOM: ada0: partition 2 does not end on a track boundary.ISA IRQ 12 GEOM: ada0: partition 1 does not start on a track boundary.) to lapic 5 vector 48 GEOM: ada0: partition 1 does not end on a track boundary. ioapic0: routing intpin 18 ( PCI IRQ 18) to lapic 1 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 4 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 5 vector 49 msi: Assigning MSI IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI IRQ 258 to local APIC 4 vector 50 msi: Assigning MSI IRQ 259 to local APIC 5 vector 50 msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 51 msi: Assigning MSI-X IRQ 262 to local APIC 4 vector 51 msi: Assigning MSI-X IRQ 263 to local APIC 5 vector 51 Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered Trying to mount root from zfs:zoot/system ct_to_ts([2010-09-12 01:27:45]) = 1284254865.000000000 start_init: trying /sbin/init procfs registered em0: Link is up 1000 Mbps Full Duplex PROCESSOR-0696 [382222] cpu_cx_cst : acpi_cpu0: C2[1] not available. PROCESSOR-0696 [382704] cpu_cx_cst : acpi_cpu1: C2[1] not available. PROCESSOR-0696 [383191] cpu_cx_cst : acpi_cpu2: C2[1] not available. PROCESSOR-0696 [383832] cpu_cx_cst : acpi_cpu3: C2[1] not available. ts_to_ct(1284254882.535562257) = [2010-09-12 01:28:02] battery0: battery initialization failed, giving up acpi_tz1: temperature 89.0C: decreasing clock speed from 1200 MHz to 1066 MHz acpi_tz1: temperature 89.0C: decreasing clock speed from 1066 MHz to 933 MHz acpi_tz1: temperature 89.0C: decreasing clock speed from 933 MHz to 799 MHz acpi_tz1: temperature 89.0C: decreasing clock speed from 799 MHz to 699 MHz acpi_tz1: temperature 89.0C: decreasing clock speed from 699 MHz to 582 MHz acpi_tz1: temperature 90.0C: decreasing clock speed from 582 MHz to 499 MHz acpi_tz1: temperature 90.0C: decreasing clock speed from 499 MHz to 416 MHz acpi_tz1: temperature 90.0C: decreasing clock speed from 416 MHz to 333 MHz acpi_tz1: temperature 90.0C: decreasing clock speed from 333 MHz to 249 MHz acpi_tz1: temperature 89.0C: decreasing clock speed from 249 MHz to 166 MHz acpi_tz1: temperature 91.0C: decreasing clock speed from 166 MHz to 83 MHz --Multipart=_Sun__12_Sep_2010_01_48_55_+0900_PkMnm9kVnw=SlyEC Content-Type: application/octet-stream; name="nork-CFR9.asl.bz2" Content-Disposition: attachment; filename="nork-CFR9.asl.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWU3PEOMBV/f/gH78RER0d//3P////7////pgnH96p92dR89rucGlBvuB72ewATZS hctErkBo9t2tr1Q0az66633ndXX2h0FzDt1wPus7l57wPWQaNq9QoAPntik+0Nvbu+57nm7c5cen uvbmmHW7dLtRuvOYqhRQp9G85943fQeesZpPXfe7WPbgdAJUpLYMCRSFJrPTevdTNunr22ee+70p b7h9zZ6vG8n13s65nHPlznbHrrx0d3UfeypJIew23dZTYyU+0oANrW1z33c92eY9t3TutPPbqe77 zp5svZ2wbj7uOsK07297UV27biHs9ALpaa02rRMaohffbZvuru99dvu8nk9St3u+75On1r17lJvu x331sdvs930d9asPriPvffZvsnuAsDdqDu+b3re3e+H0bc8e6711ogL7u+9dbfIb6b71K6T17hvX zbwj19PX2+nGT1fBN3NpZVufc9e57dV19IPtAD2+Ox96fbcS1Qlx4pnJ9sHwmPfad9Hdrztup9Ke R7n3PIkF5gBool81mqBCgEoQmTTRoBAEENNBNNNEaTJqfqamnqPQgYjQyGmgJQCCCaBAQAhlTNDU 9BT1NNAAZNB6gAABI1EiRBqaTTU08mjRNDEZPSeiGmQAMgAAAAJPVKSEpqn5Mjag1PVPQQzUaaHq DQ0NAAAAAAARJECATTQAIYhMTQTICT9U2k9NTSM9FD9KGniQeoFRJCCaE0BoUxlGmjSmnqYno0no 0jTT9T1TyjQMnpGQGj4+0SWJ7qfniWSUKWRBKKWDGio2LGijENjK+fbaKSYVSUixKkqySIVsZkmq pndqpiwq5Fq1RVlSEgirVIUXKyWwJZIWExJEkxUSEDwkTFSJlg2o+yiJ/eEgAfaBif7lQf+xh/T1 9Ps9wtvs1V/p9fnhl9NMvl8+P3Oy/4do1gtk2JwpiIk3QwUXV/CfXruiGsKa6WstNfR4ZeW8HOwQ PgJCWSSQpAVakBYsJI/P5d7c93/7JoqlqWCrWxrKSNaiy2q94y/K6/L1ktWm9MpGqYo8Hf3JxaqG 8lKKs6TG+UaZXm3vL1rKt69RbznTt15abxgql52wRJrddZroo3c8tnVseOc5KWsVWtIJQspQpgRH BLbVMzKkhdkTNqBtxMrkgrDBoWySHxUkhIqLgjAkcyFQkR5uFWc5RhKhemjXn19q8bx6ngenEExm NR3XRjGMkNbP+++kHp4+NgHSqcze7IEjIkSliskmQtqY8QVtI1so0UCwkaEaMNDBbbSQWtlQoWKR lZGiAlCLUaCqQao4ALeVFa0VGhU20nd2qkm6Vusc7Biy2oWUTTRlzy3nYlmtVJ511TSzSqUilS1u cs612ru1Tdq7OVuJi0l0w1NeXl5JbaSQJFIqkUiFVFpKqMJpdqYtXjqrreU6I8uxKkxKUpSqM810 h5K8uVzVSSeNkSqBZRIq+1UkKKZVRrfY1tty1t8ERqloyABtlkaK345boGZGtSaJC0lEloZtkt9j ba6GMaXx25rFERo/FK9nkt6Wrhb6Zq6Ey0aELpbkSlC2ULSkLSX3EJy+8XmemmXFNcyNEcy1hUT9 rQoKWdoSOrO4AaqQODihgww6t2HThk2VpXCrmFUxphXDDZU2VsrT2sTSmzkw05MOFTdWyt1TZWlY rFTkrFaVwqcK2VOSt1Sq4VitlTCo3aNmkjYpsjZw0kbKbGyOGkjuSUH9k7sdRxqepPCxViSqQhbJ BF9Cogv/z33RW0EW0CoKj/tERaICiwRtJhDTIlJprM29S6Eiyw4ntZlFDKzGEy26ixNSRpWZqqhI 9MgjUGJU2TFzGyQpJURDAMASKS0tYDRQGvRrtzbdd0pcpsurrbFotI12ouyrrVlqyuEdaoN13aOX a7q63I7N1GuoOWVdnltqyUq5vLmtyTandXNokmZdWXS3TU2qKmxk0KaReW3V5Ct46XbeWS8rkpbJ aQti2NY1isVjaNotFtjUaioqNjYsWNGiijGIhu7weLMawhKdy5HACXC1bpbZYWuKFKjrdU7bsqQF mAFpmYwoFlIyJBKqQLKFCEqpSRqFslo2q0UtkjJEzJGMuVJaqFLRosrAxiKXSkNsvLtXGMYvK3Sl ZUrdfKa2tRtBbZZqZEiX2gpii0RVIlKtGSouprZLFppGyWoAA2fl61zxt2alVK2syKoSslhJlwtA 5Se3MUvpTIMpLYklRi22mpVlSs1KMa5q74evX1eV7JpNYtUVtijajVku+vi8vO3urXgUsMkuchKM QyLlynnbp8V/I/U1+ZtrYc26TiySqi0igosRKUqJDptCrExGC8/Vh1a927t9n7NwoLu05C9itju4 1q14gcoBI5C00iwikisnadh//UdU2JZ8Ya04LS0ua31IjhOKTbZuTvUeeAAB687h6enXr22r3pt4 jbjNioqylUWRIIpAVNaMtidUk2v6NSD8G0NlJV1EuNCqrIlrT4IkaYNEpbZQyZJtLVduA526ru3d tuZWs1p1M1UGxbou6LVytzabS81blY1RYTUYTULlkWRUWC3S64ea3JlpLV10QW3VW9tckNBgJRt0 WwaCIMGhahZYUgxttCjFCMFqGWwg0UhKJqeLtjYXdWuERERFFad25bFbVGTmtyIc6225uADaDABM ADaDAAAqnO3dXd067VNBrFIA82lppzydJx3W34Ots2AYNtFplqVKDW0Vfeta41NTUqmSUaLZBlVM Bglq21IWnfzhiVFUUqSzUbRrBY02ISWsmMUSYpKey4ZkNta+6vzV38Ct6Y2DWitR9/Ay9/SwdveU FJFF7qs9865VlW/FIKggbCiD5MZLXq9HsdzZDe0VSyFkosnKqNzlm+2t3fZtqXZsM0WxtLLMWBBJ BIIySWRtrIi2JaStvXjQbBcIpgpMstWrVqbQEsCW45ZbI4BpA0NLZqMIDa5tdV2rttTDKbGtFFih bFsMLCLhDGLCTLtcYFu3bXneS+V2tJajWhiVsTRCMEILFV5VQrAmQMRHdF3wbeSqam1Ja/6S5Yr4 nS0zYYHMc5CgIHeByN6KctU5zUPAWOBR1cvsPneeAAAJAkAAAAAAta6qvebvA7uO5Z17V688O82L GijEK+uiUfb87zysqvO+zbeVdJqTGxGaWsjFbtJNJNIlppZKLYRV2kqu3NmxrbKlUrZ3VdPOuhsh UtJNqKbKd3XcdtpE34P2XWyY1Kmtk1X2r4mWRFhGQWCbA/joag3BqcpIZLAKhr2BqrpVFS34NLBa 9Rmr1N282jbEtWls3YtttkaVKVo7KmNlVTZphw4NNlTZuph/kD5xyh5n86jfO2SO9vRbadurOZ58 +nR3vA1UBbrdQEA6rEkgIbfGEQkMRCEgm/BGwrdUUPD/TghXNcRQXAVTDxw78ACCTdIiWCJCJ1hJ +1Ug1EVrNa32I2tVt6iaQ0GaYqpJtbdiUR5/3RahX3ny7Nh/TZIG4kKEPu1bv8ZaYP/TD/rRjX9K DAP54rhx+dhLed9mf7FoGVPXKbYRIT7VEoiaycxaFSAI1vJAH1RHJkmFErgBcB4v++z7ff8ff6zL 9cFHW0jdbOd2EZO/D4TnOc/WUsMNsMsK1eOrYKKKZOI/f5HIQByoMCn8jzQf4KkfJUf+iFOWMHE/ 4XIUumKa5h/txwMcH3p4eibcC6l2i0QNt6QIRKqRyo5O2JMrdywmq5tsNWJF4wkQcYra7jiXsREw grhBaiAgVa9hoFSVmSXBAiGFgThJpyUKpAr+QhJJLP7EBCw50KLwARbOGYBi4mWFyJhgT5QkyPQj TgRy5Jj5mFAiE86G02gPIjAeSwhLI706u7ozRtAEKiaQaigV3yAwvC7ZLSYdUd9Eyj4g8LLS36Kw OWT1MuZcL1hGluHa06Kah7oBgnKNtDSisVIqwa8kN8/acvVg20+TOjYFL535RhRBI/FiKGSlOpsz gF1M3t0y26uQ8I6jDJUT/H6vo15W1wqrH9uF7uKqqqqqqqtttgHgsz3RPKmdlQkkOj2B3yBNPHAM 3UsdwDEShnQVSW20NnvSM2dAkGWW0tuhqTaIUzWdVAoNNpa0a0a0a0a0a0bBkhgNoHWdTreUnu8e /9Q1rvF6O6zu6ZI0aGppMUuYYSluU8oayF4x8zBq0sWbFrEFqDAMZgTMD3eeIYLeVFThHQjkxYJc omvLwNvfV8F2+BPaect9tDYeoFZI14Jh3OBvr6jThZ0Isu4b78mBs3kTe86IY3HCUy98zL3CIc12 yLoYkEAGBYIYEDAcGVJ7dhylks5ZLy8AyHUw5hI0BdnbC5HLGQGh2YV1uA8CyKJDqsXiBQPPIVxM 76p5jBPTQkJCQkJCQ01Q9paEqqqqqqqq2reSBzWcJe217nPu+SqYuSbNCzUrG5a4c0oNI4AjCRFk gShbbZ4ZXzJAKGIwkh3lqttYLWFEokUwMn9p9gQ4WddD6ErIWwLTshKC0ZbLT1ciXEHEtuZIYYWG S3bVpqdOZ5lbBsPZ0mnbkuWmDNmxmwO4HKnZzrm9F5bwDJk++xt23hhQOjTbdV3zKcAhnKWgIJZD C7XXlu1XwrsgrxrXy20tpDaMsFKpYXliAwqastJJiXVUAAdU2qriIhtth1mFkl5h0aTmIFgUhwED rMlbaRobrJLYGFyhJlzcA0AFtD1QDbYE8wCKA3CLmdMFOj/118r7Q2w6qEpbrtppVWeCxts9Xfw3 u8M925N9NlbUbooqQcxd5G9beroxEu7bcbYS7jTgxXfjslRIBBtAu5EcSUGq6DcIuADFABAAUEu6 coSCSHaWsQJtNFMKGPEp0vCro6DKys609mXXtKJIqUJLuB58vW2+XnbXstp3twAAAAWkKBouT2cn ldnCQDqSCnQWvkTMO+PVPBqViUoNKSgcCnYplzFUxQhKUenJCmRRstLgTDSTUKvRgEcOxEQEcVVV VVVVVW22wniS5iQLsYZ60js5h1rJ2Vk5IyUIUVBsmklH7bG6qqqqqq5mZjJDo9zoj2tm7idrq1dJ mVRVvK222xz1wg+e+LDmq2rvqA3bTRtttAAAA25mfI9d3d3nxV52/Nblne1T4vOe27yIiIifGret weRWy0MkW0BsSm0j4ks4XzPMdvO0Op20zaeDaiZw5DDqm8OsUVioKwVIrIqA5j1DInkV2lbSXoRN OjDBEZ7IzxGWJnbIWWwqSKAW1gAyQkeQqaIgdwwkfhlPATaRvqdZKk677W636Wly5aXHBVlWWlpa WngZI6QGSMN1W1W1W1VOteaECdFwVFRUoTRgUC9dTDMRcS4nNcLdxVnRTqgTKA9bzQ6MWLPPPLXu iIxjPXWL39rV3usdN+C6mWbQjSQUUliUlJBZbUrZLaUWm2lSvHv51siwpKVDIjClJMSUvcPzwP3K +MQP4HmkGLCRuDgEDT8uayog/oRPy4nCwiFWCQmUiPnQRNIgrrvQvNDwgLIF4j6RPjehELRaijaA o0QSoKpgMUbREwgDUVECOEMJfH0+OOOrMf3RN2f2bhdpEADAUH8PUsL8oqPqY0ouKJF0EON7DIF0 lgRYKWj9f8WCSRqef4Mj7aPPQ9JjcJEEO0DxggShKVSAWir7YiJ3weEXggWxAsq4eVCocgICGVVy AiqmhETjEek+fCwiOCRMWihQkQ1i66H9II3iDYN9Az0yrntAIUDFJLqf68KPSAhokUQNkQF5zbIx SCyQgqc/8BboIq4xU1orP6wWkVgqqHRAXCIcheYMrCOvEoQA+sFAOURXJi47BFaVSn9XI54EUiEL ql57ygpXKAiheFkIikgj2YqysxYI9mOBuC6mUQROHH/Tz6j/X7Ph4nxt7/5Vfo9/yvr1YzbswNoG 9VF9sOM9v6vhvOrpE/RQgEQFEM/1Z55ElPDyl62WYK3L9n4NMf2sF63j2srH73Q7sWe743fqiiWL 9njUkq3OX6LEW5h8LEVdwGbUHkMIsa/o9fD9c/e/mJSm/kP4VP2k5OWWW2v8eT8mAgQsgJFBABD2 Ar5cx/4/h4Ufx5Ydn8yWhzYez65dnd3t8Ydu1E8oNFRVH2N4YMYWNYs6N4x6H8nkFDpbNyQo2ywn jV28BlVUsaNs7con7t/rmW0QsVRRXpzRv8kWlm0tM+M7ia5XK5yn4zmxxjSEvfZKyo+7+hmT/HNJ 2zd8tW3Th0dfTh/PT9NOOvkdBaQazr0zo3TMqBJVAOlUwVwoCMqD+wH9fByhKBVtMs4vDZ9eWQzJ wIIiKlg30W9URVRBzW47wR1t93WP8bODq8h9vRq/42dJMsNejgB7bScAU9SszBeTCQJAgRWEOl32 tCWXQ6Zs7p2VQZTqi15+Ns4deygMX+Ea59fusabZfi1nhtxRVUP1RB2qot5V/rJkrl0x7eXvt1vd 0ZsM7JTioTUA/RcVLeWL7bq21rXQppG9xOb5znOMc82X5xcFDoL1JTETH2PwE9b+api3zfmxA/aM OaCU39VmzyZF6MkYa/vdvE05x7J8N4ebE4SNWEa5Dsr8ddd5SPCLxurLiJfRcbRaJXTLCZbNQyy7 CTmYjRfTffTXbGsRBdEHdz7u09GgHwzJmURGEoRe7gHhHeFhLuMdC2UU46Bq75JJJWzOubXZ3Y0Q VceDkAV7G2GUU4lkf6hjraNlyueXQm5k8hhjbWREnwz1HKsqqqrKtXYJHc5igjhlXcREnTWEV1U0 oBCSMgEY2ti4iK3e+cxzVedpnw43nObV50VVP6ff971y5gKiid2ydBTQvcF5iMWmBgVIkTU7GR0O hkamRfnmiK9K5Fow1N+PqusW1v2pquLECIzKV1kWgeclMIsN4DkmoTRykXsArX4h59GSdwO3GTqv abQqV/KAagiVBhYa78hltLHbDv6zprf++/LXh54Py9s+ZRAHe5hH5aOzdp27707du0YxjGMd7luY ZFmpp/Yx/Mm3we8JKI+LZjw9jhPg6ZuqYdQHyf0Xgg725IjcPLZ0NblGfv97WgWy1LV62qCu3aIX zaVKaP2/n+9otZbJz3gToQMuzt9uJEeezu8zptsIVyuiIfGpcC6dOXbu3bbYdkvTrcnPeJlFstqq q1bEOYOFBqmUTtGceGhbXWfSseCnljjNy078t/lNVPOKs7u+eAe52SUBU9tkWQh8a/bSjkplVPQv Mwzs2AsQI3208778JIZoqBzpLs/QVTrn2AxDS++gTRLa1xtL9BEkEXYjxs99tcwRVCZBLuWula0c 53XlpvVq1b+RZ7Pt9GegmHZQwgOcPP54zLbfy6kTodctthSFCrRqTwpSm/lMEtTU9ooePj29G9bm NemdDWjCGLwORyuB5EDOBzKSRemChxWBaIgETvIFQIgBIHbFdUTqWDkfNYnrs8PlxPIM49I1YDXW uwHK5opCFhZkaAXvEkgyFoiIAUqpev0X3/r7vf2+xNq7C0kIenssVDXe9ey7cibQ2YB54GEDtoLz wuAHCXKN9kExgF6xJnpgtmJ5uNaolKIl15Ym7QpoqHsfCJ6iN9rt30+dl+hNLlehy+bnOGLr1dwe 7li2j4Or++LjmXCMSUDgLcSVhFMxkHUQ3tLoh5L/t1g7XQE70hvtt4dao7GzGmG550DTVejWSEtq 1W9b8YymT395rUnSzTQY6gdHcES0ba5ufG8JpcxbP3St6sNYTxe9ARUfqxxw7ralzxz6ddree7h0 dOCYqSMTziUpIxTlR2dPX4SSSSSSSTqmRvgHINZrtu1l7GrH0Ao9mmHEnusnOFj60LQtWMUbt3js 6ujr9nz9+oA1kFvFOxSO0kiLlHAgvbFE/SCOEEDDd2eN+33nUG3kPNS0vE260xvXXs4+3lYiWCmc qiCuKOWHZIHOAGGkdHWWmzIyh6qMEzwRzqZZZZUjGMYxjHrKsmMVn3ZyrZWl25ff42/OflgucMFR BCqqoIqqoCe5q1vrhUkkdmZfoVbAf4ObGlKU21lKUpSlKUjZRAM5/3Garpig1j4YjjB6Ag3IlgX2 Gz9lyqgpgCrWxz589MYDIGDJCKMcjQz52FjtwlmWDAWAWt19PGd4EARLdHt3lah5NEmvG3Lly5a+ eLzz2gbCtoEtIsdsCgx3u93u93u/v6OgqH4rCPw/FkEzv9yRgYGBgYGBgYHvOx7i46mp0MMMMMMM KUpSlNPdAA8PZxxxxxxx0wFZLR17iJpZuERh2gj4zP29ddpPNYbEZSFvi94zaouWOOV+GW4k06Iq Ln1AcAf3htlY+uEmq6ta1rGMYxjbndJQHAZDKqqKqqiqqiqKvwPEgCYK319IpAjXMAY9cWAkRJsH iAqJxgHOeILQF35kk16Fxc+7SwPZhFo5rWqu2/OToEu4Ft1rHu6k0cBUCptKSp4jXPr1LULQM3UR sazuKDgQDX28Pv/be4HXj7peqjfxupeKgiJskz3ocL2gp12fnZa6M1IfbkJMBI+WnMCL2ZjlwbPl IByFIseOXjw6ysSxyyAd8ETBuovERIEhMhODrcFVcXm6iPxsHbBizx6smRxeb6cciNzsL9+/Pnv7 9NNK3dAUhuoicCR+RLVazkfVDZDYxEmVKrF9kPnYx5ZNtVruvbqbb0Xft0MzYs6s4/SOm2fXre/j FTHgJWoKiuMnR1FUtCBkRERJhIJGEySaCgySREAfl17/m/D9XfP7vx/TtW+4vNLH6mLRE1sC8Fgr Yw/BDfl9fx52ms2etAHRgqx4WhYqqhvGDki4lLW8qCPCHJmxjTjpHjy6znNmbOc5znOc5ztmDVZn WdZhUlaNoch9WcWL3vtbaLWd7/PX9W1wJ5qAuGQNxUVUDDCAz9zJAQyIwWYBxhZ7wCOYqjvhVdbW PThhA88YQAne1FXS7SemnnaB90pNOaFzBQC1znxjSlIgREshYLJYtDnj4+Tp6YpdL6EUveoREU0W Nai19tttt+/hxq4Cta1rWta1rWla1sUqvAK8MIa6Y5Qr+QESQCp2Fz2v23giM6Va9rWta176qyrw +ZmztksAzu9K4sNGc2zjtz5du21bW2vtjbO2222+pvcYrebkRDDFGw4odeez4BETJkfkB3x5OafE VOJY2Au6ulrIZv7i1LbdxAcFB+/GZ6eNd/oIQAD+F901uZEkjkJlisjht5Bm89vyifvt0jrBLlw6 V6dFiqMiqwKr9MZi0HF6mLWtzt0siIk4xiKXG2cqYy9M59KCxuEOF7nXXGy+uFw9M8ujsSqo7Ye7 VWMam9quVh/dnjbL4mt4lrxW1Wxtvtxe+M6RedNNInhhe6r7sKwh2IlMHESx0bil9arGeNrlmVdE MWoKLQ2FYWVZmZUXi4wTJJupFjYY2LJpVIi3xs412QMzlEZtbxbjXbCWnONNuH5WhEulxRlVEuBT t1Zl5ZRGROcWdOdJr8IERCUy7kmFIRm/HWJFjzUdHy6OwC5+WOvOxRXxA5DqHvUGW/JbKDz9mwky XyWhQB8NJejXXS4bxW0GS1VVrlXAV+B9OCiyBo6AO58qKVdmZrO7vtEREbTMzM7VVVVVrfZEQ53L umC+VAVw+YjMqUTYP4hv8XaX1AdgIHqvl5b703qt5ZmD2QEV1IHYpg9oKIiEuzdE49nNqaxnMttK sttmss0/rK1a/pZXu97taXiUUOW8mA2YhfMAOX32CFFWypqqCjowALf3sQQABkJzIamWPP5R1wPw ZL1Xukrx3iux1YuWeJgeeF6GXj1wtSYW1QSgfy+8PwWoqJTFJHk5cRcL7666zbPTs233v8z6SLkx hlojK/eQRG0fh9/Nv4Mlp8DiYKkbMoMtrIsywy1zMsuOWTFIJZbMMa5lkljZBsgqTLUobQav1dOa bc8gx+IaXuby1KyMhIOe8pR1Rru1fBjXaUeRVaXmWIMCsiKLKze03VPaqUrrNK22VN/PkN6/F0Zl hyHh0ZpPiSfqJLFElpHGJRaFGHChyCCBz8yByCwxYok4acMNMKUTsTDo06NE7OCU6KaYYVG7Rs2N jZGzhs2NjZHDmQ9PT6fq+n4+v8Xy+SreISQhAvk89pk8a14Z6Lx9MSPrUab17FCuysRwaNRjGYjS o0aK00wxU0qYaYjUjF0qYpVVhTTSsaaY0rRa00xppjS7xI4UZ169VlXLrYhupOHO9WiGyk433u+Y 7mNyThSNtYFsQE1m8osQAYQVNxoXy/dNfQnPx9Pyq5wxVQxgqWgKXgGqfqtnnjniDvl4JfpoSrzP V26L1jVuPDNaVp0nLWfTu3RdVTHmqePTHALXY0rMvY7JtIVKqLIqkiqSKEgDIsWrJ0xnhXci71z4 UK3ViNjRqMYzEaVGjRWmmGKmlTDTEakYulTFKqsKaaVjTTGlaTQ4w44w5A606iqaqhNFx5ka5q1y RRSSRwhmaM8T0tytvXKOzdSZ3zyrSqqqqrGTqdUUjCQhCMNocYdF9OborLnKG4VCU57tMOe5xxyr ry6V0jq2D0dgsKiFrbab41qqqqqxRg7jDOqshkasvHgFlbddVleSlxFEu2JIW9xs8GfCxtNZbE3n AdiGd6kWoysS3yBEBN5t08NuPJakkkfBtWqLyiFoBhzUtSRvWlbyWvO99vgk3bJ3JR7QHsh4wy2w 2u3cNmVxLliVYl+gNl8lDVKkkkkk6NBaXXKmuaVwkdxu0zk6Vxtuot4ySVOGpNSVbsUuVWTIDEPc Q4rThwtjbjW6uWeOXCta10A0heLkGw4+RxhR1IFHiH0ZKVFVFsBkCySUctMNMQhA1B+ZRU+QLr01 Ei0tarClbLrSCuQFc5Rw5rVZYsomp8vLceSLSZUqUNS8/M/hDq9xxSSG3z+V6lmXva8C0uSIyoBn XQxUXNNNMMiqjIIpsOcW9d+bvpE3OfPZ8ZXQcXHq7u7u7u7vEBdcLZU0nSNcNWXy7u7hjMmusk6U 9Xu8xEQhGjGUuwqIAqiClhSXso7om4TKZC2e8uDXcLXiHPve365+CT5/pe993x+H7LlJAJJn+o1f qSHVVfhK4Vnn+XVv4C5hjSJ9M/fjS2QQQV7Ij/NCz2VQwGWbFr3ge/BrMMlJ/t6cufeOhksNXC3T uDo+a2Fl9m2lpjHPooZFD8y6igh7piYmhcfq6omJjloxotA0zfF4iSyLuOFj3ubDwh5ePfmL18+f KVKUpGlL4xjGMY3174Or49/zd356O7ZZZZZZdcZ6+TNSlKUpSlYxjGMY3aHxunOc5znXPPW/v59n 9Dmbz2g2M05OCRIzLDM7lgve9XDGpLwLMnXXStvNyQ6r+ks+/XHTfxxt73xbl5ZbcHvOlWnJg0zz 1jXV7Rr9kU220xpV93jDh2d8H3fOktOWXk98bL8a5YRXRek5ls57Y+7g90oSiPHOosGsps5zvC/T x5+XPOc5s0pSlKUYyunOdttpG5pkpShKUYztnOc5znO6/LXWta1rWta1rWta1rWta1rWta1rWtll llllla1rWta1rWta1rWta1rWta1rWta1rWta1rZZZZZZZWta1rWta1qzNWta1rWta1rWta1rWtYx jGMYxrWta1rWta1rWuGEeizZvZt4b7sa+HKWclyZeEXQ4YQsxbgI/djoePL6mTUYT9p+38DmwBDM gCaEzhC+4O5tdMsthltKHeaTRrvHZrffCA+0lJRm2pAdTvhUT08PO/xDKN/PSBM9unt+Xy8vL39f lnGGZsYxMzMzeqpmbfz28UPQLVXkpJHGNttuN/K973ve97+aIa+n3CDdFAlRFFHaoiPESzn5Mzho 7bMmdvCc7NNNtdZwe9+mnC+/Ke2dL7uW9Glx7RtFomYdVvvbfGLWxerb77xWmumrvby8PLp06ZYP 000dWdptpOPEghBRVFUVRcrr5Y0kPnpZtHHba6sunDcC25AcAbCavFriQdHzshdw3aWTMRu1pdjs qEK662TFu3fx8vHx8bWiIiId3ta1Wta1rWta1jlfHCc5znPXDBVrj1dlWsXD0XogQhjjjkEAULhI 76iPDAzzdKlKUjGRKrB97gxeiOdWA43HnFeAYVwVPrkGjBZzLIx5raueOfn06ZTF73ve95mZmdtl 008LmNa0DWydL1HJpAlEVEFo5xylll2BA4QVB4ijhRD/Yoov9E0g5ltzJ33ZylGuN857+mWBnqIi QthFLlhUoR3jwmGznvjw39Xdp1zsm3LVtvAmdFTcVTJJv6qqqqzde6ml7umvKazXn2Ngq+NFQHUW sc+nh4aeODg1Nn1BtZI4rJYlTY6syq9FiGWObaV8VSyD8s87O71QHu8/GfZ0+PlisbXjnfvvyMBi i4jCdVOuvlLkK7OWBTTHWefjFY48uXfazc7XPANajl1JI6VSqoogJzCHLr4ishvvtxvx57ZJotxI vErAYaMB6Pe6V+CtpDCy+cvnn5XCaoupVFFykF0KZaYZSLbVGsGMVDXSjh5wYtUQkrLsuFRkzk6D y/fyQGIUtjEcWxrllfdLeo6I8Lr2qumWjubMKomSmqpgt63tT9fLtKd9qRlx4ZEBZCAlDCG22Myw 1JhNS9SC3suYlyJYQA1a0fwpSZAlQwGBa5VhjOI7i0L8C4a9rxZEbMmuxxe+SEnY5wamXfnz5b78 +WDXOxq247YNi0eEwi7uyBlYzhoNJBXYs7JECCNN2F5SiZdJNCKTHLlPLWse3fVHTUWRZhSlIUpc RIkXUQA1AfCaAVOKRKmAq1FwKadrbRVWd1I5W5ZfG+tpUiXI/qrUU1z1MX2lpdt7UNt7C+U7KQIg SdwUZIpiG8VdB8XNjvvjvvcZy0ymXSfeJ8+DpJbjKh+uoCOmbV2HlhlbcuXf3IW3QhGrjnwhet2W 2221lIWUKEEMVTTZ7ocr7JQQ35JjDtkWYeJfsP5nLfu9Vre0eEMnYXtZnwcQGGHk2a9WTQ0GMw6v xTJyIpyV1hOSuipajqiI/Q3TZzGcBuwsxC0yDKjbGj8xh6SE9mWQlULS3To2/lvfAsphYFSOrJ7F 5UwdzmMncuxy7FnCEpmTMM6LqzakOnNUggZjvDvsaOj6KS7KQ3QVRfQrQdeSkjhL7Z01lPqYSx43 N6FYDPZVvvvvvvkSlFWWTIypgDVOMEQAs1bTS2m3iXwuzNnOc5zoaY9uOwrt0QbJWtW8cqNEeyoi HZnmWiId3fvlEM+ApWB4NB5dqxYdDkOAI9gGAgux1M8TnYKeS4Gus03Xhcx0gxJWag6+HG8f4a0S qherJ6WUW3TREVCWJDKufahwtMKmGzTFO30GTFAyJgREDtUPd7ZGR0AyZA8URzn+ybJFsZLhGxRQ LJdJ2+e3PF/OfH0lKb4vDz5P57UDh68AfTp8eZp7867dNrQYejl4+2vkt64xHljTx08xQPYvljye vH246efWHSWg0eBV99ph+Z+SDgaBfxeu9o/SjtvKcS2Kn0+zj5ezzvdrIjuLzbk+2Q8iRoG9fO9z r40vekiJ5mEV10Z3UQ1mBChhBlggXMfve3zVadfv+H0hoy44KOEKeDK2fVSx7voe13Hn+rxXVfNW XBW3K6sMzMzMzMqqq74vOtvWK+/k7pMv0APij90h39KHwliqTniGTIf9nZ1tXBcFZVVdCdMRtEsf i0ZPs+aAqgSLIMiSBIyGNcGuvq8Xh5X7C7uNPGSSLnyVOJOHfZOo5BwUWKxSysKJCirCqrLShbC7 IbwB7vQ/kcw7Mfzm4DVVVFaA1hWdrga7rdW2cmV6qaDLDp4KoCigQ7pwqW+Vd1MbVc1NSigNwLAM BZXRAksdD5HkfA20Fzrd7q+WWWFcK4VrWqGuUwdBFwbQHHIzGFimI4i/wcyLfnY7lIEDOZIgE76v eGc9ozBEM1DBRBGh4QDNcdUsIWidVuiwbC9DrtXL9wZ2FPEa3cj1FZgjpCayd55wKljVUVVDZOrC XBDFrbh5HxYhaXEShaUnfbpUgHpQObwUqiL0CbLeA9MWEc0zdnL61or99ur8lC6oAinNkQ8BTXe/ PkRER4TZsWIiIpbO3li/2CDTpy7R5XK3vhsDnyyvj62LVnGa0xas14uXG/jTCiqt1V85n7YNxAFU IW6p8SAfC+j4pgItBdvZYQkxHR1l+ePDhKUpSlKUoxjGMYxw9PGadMO+A1Zc7kdPR2dtvj8uuohb 1sZGYBmbwmjVmuO9/brPJ+zq9LNos61DxMYCPdkp2hWXyABg7ao/LI3JJcoIl6mTmtmwdnoFoovS glH7xyXqsYMlk+eWArQIDIaZ7Mw6EBg/QR84a3n0bBcYXG9C2qq+AuHQJ/IMQETaJEIxWDECLEIx COJQSRDLconHZ18S3ZxznjrtJOz30GFgee+/skwpJm5cGRkSTMzAbCSNlTNi8a0VubXOtlpUq0ui /T7v4n9rxO/8vmAzHFp3WGbY+f7iyyGWW8tt4+XIbBvasq7r9+0BLDJ+DNZ29uJf4iI30XrhnkZ+ b7Xb2L3U7kjyvJe5yehBkRsvm4wgj+VeXLlyiHq2dsFVhmgBkiZsiiqL84HQX4ma1FEVxVGI4Oq9 br9hz3vsN/BV8eara9r4iIiMGMKt8Ktzv+y4Pc8l/RlPTKOyrenQwOXQnrrgQMczM6EQtsskHxD4 iH9oghPbt4fo6hpBPaIV0UvTNhBlEHZPyvz+P5cufTtnhm0Gcc3ucqk845yde5jq2FEwN7rOyavA 7QzuqIuYGdEERbNqK25u70evPL1aXp1jXk0WGtmsshq7ayRoUT/GD04+p9LzNWxhmHIi/B6SHFpI YYVX3dxvDkvjMy1f1lHApNVljH7iHax/DRxDZ+b09xYjIqiop5fn/nQ/NQFgZk8A6Jo/2olT9sen w+F2tA9HOvYdAeO5wZHcCoiQET7gUFDewciAnGbpO8cvHz92md380/KoF44VCionjptbc9x305yB yH6W0FFvUkkk7OmwcISElzKYxjGMdfc3OXPq/cAAAAPPa9L8nz8/s3+C/tW359elfLgH36vv1cBw QGQOiBcgddI+Lj07t5hSeTHxEO/iIQ3+Gabof5eZqSwNAJIP6WBogkFYvMiH/3GQQDw+v256sLYX vfJMEUX4rooIllEFSkYQT5aBAiRf149fZ4VVVVVVVVVVVVVVVVVWOOby2mx+4VgUTYkFQIgCGzZs 2bNmzHHGqqrhXMETKGHxjGMVVVVVkQLohe/HPSZmalvGdoiWzjjjd8HEg4khUHpSUOXLZDfpkHr+ 6RH9UJIf2Qf0/ht/EfWzFqaZpf0/M/cfuQf3SRMwlwrCZJIyMDEUikSRRIpJNhf+e4QRF/ze6Pb3 +zz1tt+XNey6baS2S0lslSWktJZLJaSWltKW0oKM6Wj8oCeMBvjax+XpThQmZuQtA2lZX2h/gZ7I N4DJ+MHKSecal58TbHeS2GFJ+2P/Kw7Ov0/l5OFAvdQL4qYv2vu9LnfKd3AC230rKWuET6xHsgvK KFQVwTXBCRNDd3/dr+TbHJ76TkiOdGJaZgMqYW9sHBYZBkSFqFfnH798OJz/T+j9DERP5m25uKBT ibQKBehgGl3f136iXGdUxd/GwEIWg8sZJJN7YOjAoQZcojiUKm2CpZJGCHF9bD20y2GEtoRkvKZY TDRAkbEidNYQMyXiLIJoTk2KYQwtXNC7CR0sRHv4yqtB7K3sjUUc01MizWN8zdZH9A8NsDUKNTfR /X06fgqdald1OrDblTELS0+Ol4A+rGG4x7QKU3BlMpA/WyICyNITostN6AQ3waeYUsiiBINDMDMY wxCxdOJz43zBIqtiYqSFqKtno+LH8+MKYoBiebKkToqJRP1ERBTYflaDkQS7nL1REH9goLdqAVVE jUrfG9jOy41xtLQva+eBgsX1gZ8KExgCWgCgc0Rd+7de1sN/NkKBjEMjYVaDIpIbtYu0LO6awQ8U eiEFE4ioglwTpGet9cbdFxUxttsdQjS66dLqKhgoXkh0Nz+XiZD5z7/b7X+ybFy0w2111z77bZ5n HYbt2A+6jlsxpJwuOe3vA9oTuMCvNloxlhT3/UgSbtLVQ5W0fZmEwQbKH06A89kMiY0OKykQZSJd 6AfPr15peo9zB1EF4u4qr3VokYYH5ANAvHaJoVsPQnRUGXaR30ZLOrFmw5CCOdG9haUlU5XpI6hL QNVDAe4RmGF0Itu+Kj1VQW6Uc9YopbLFmAFu/B7b7alPXy8wzqUvE9ZGwEDPQ7eBtbaEhUBEIQ6g vX+USWRkBks86+19vnYEvSz4bSHksV9nHEUnjiHIwbMwLAysyM0nVHSUUBpDvUf0DRzsNeBEahj1 Td0F3seZBQL5+Uxc21xFbeBn4xs24rJldqVy7uekk2KpVc5Z1HYCFt4fYAETr3qtmT3YaI7M3tZl VVVVWgwLLZ5E6B2ns/PNsURBEFLkoFyOo+xxBHCb+nuCSUVOlCDijq7Bw5AmqiQL9coPG+T2pscB g+Qtm5YVYhC5KRtAqmgRGQF9mdCVUmIriIIi+qKr6xXlEbHn6l9uftyDIkIbqKkkZjVSVRSRfjFx giT47YLYidFbVLYasQtQdLEt3eVaYmOLhb+lhcrdVloIiAu+VBSCZwDLrocMsN0lrZDv8uO/jDBU TTLm0ri4COxgqcZMylDPADAERFw4X87V1USgrhyqxOcZUb2QRtIMqqIWyZmdKVPBBMoQRYTt8c8N /Otla60MPJjaFTE54RLXVQQIsYeUVUQT+P+ir21BWtYkn3WbuuydbpslWpAcqOYUSBCIEQQvpF6l EERL1UQAntmJmRAGZkQIqCsyC+uJkIeDreTPakjawTDEPrsEagUKVYzEwSrUsg3TGKqFWQZCsS1i UMg93XayKe3Xqy3i3S1yW0j+W30eSpRq7SBVnKUj21SSPbEakCTdQB2xjm5YSBvUDz+j6OMru6uE td0qRGz44I2h49s0d/aEZJv0+XG4T28ZYUsqJACBx77Dq6aQd4Y0siIcYtJEBo8XbZetH0XN4Tty x46xGlha1YnNRVXn59Zc0zcWAg5FIFyFkMyVew6whLJRUKCKHy12TO/Xdm8ys4qYaUU6UKOLEJ27 +vJsWosOTOWandjb6aenTFWLA1kh4Ofa3VpISc6cN8dKMWCuEOUTAYOzBzzL2jVUqSMIGVkMSwyJ 3bK0ljrBfDkBhOnPIhIgZ1qms2WLGEDtZvSPCwxUkPVQ9no2nTk3rWKyHNqX6u/79uu8Dw1e96er u4RwtC6wIN2dA2IInCLv33qGdw3y0YTRR6M6Czt1ADYA45GmKaRwvstRBTyl9t9pDPMxZJC0hSGJ v58OqKb9t7OZpmj13DVFXdMSAAb4G3dd0yMGQeEW7EAhDfdDWWi88K1aCqGTITWDKhBERCWvTlWu DWyBHLaRUYGjqZ24cnCYpIc+mtK+3fUQjSiSdZ6JTIkSVdqkOXLjOW+84OVGSF0wcKG+sRpZs77O ITRJiVefDXjFSL06bbbWnGVastrWPTXVYcbY0rcs9G0KQvJEDsYGN6QuYmyzstSMRHV9J7N2m2LJ BmVcET/T/A/z66IHDh7uvDXovSzo7/Dup24c3RUsfZ8Pqf8X7p/LEn5KkRP1Mofy4fzFfpWSKWrF WSmlrMlRoWpZKa1nJMkyFEHK8FDJoMlhkFywWGxFt7NqvdbeNoFi0atGmm3y93FtJOFcUqxrgYNW JG9/s2mJz4zMyRN5ppracyFgn7r0BW0uIVSpzqpKqKpdHptuduttcvAtKULSyULFCx+q4HCFV/aq bqxUxU2KSYY/nqOVFkYRVjBhIojCMYgYoK3wETQ662+K973m2ZFMaoJG1G0lmim1hV6e+p7s3XlJ vPKbemZtlENpktMkla2MrZITa8IbbLYtlSl02VXat28jdaqrINyE201VlqrNNNa001369VfFTepN rRbbVi0llazNeeXvvXpBNUJXi8lSa8qsVkQ5buRxDY4U4kloQWJViQ1e/tbzzLMqJey2+Pj289s0 JCUi2wStmns23GVefHXjbUlspKEsCY8eBgTeBRlhJLKQ5zmmyEKVUqxRJLFESVSLIWXdwMApSFJZ KS5jCYEiLKS3rvk5Dvo6htEpWG5LLhJZaQzO9mwVKXW2u0ZIjDa0qiUlJS2Q6O2BhSXhShULOBAW S28SJkkhSMB6RCQyWygINpZSWsmd5MhNFjSFLuHzlyS6xkEKO3JYnMgZmjklS4wMuIgyZumagW2W hYFOighSl7hWQ3iZKZOjJMmG4GQpbaZnNncONpcihYWnA6Otm2yw2tImIZNZGyW7YU1g0mUTYwMl JC8QP922pM4dYYXnEMpKUvM3Ybo8oZZCgWS2S4ynRuTS0shdZGyyJmAZMZGllmVxCU0QHXuzlkMo yylodEUxjALJTkA6NybSylYmhsGXmbru3UxijJ6vJszUN8yQm5zZlVFhanBAUK1qtOnsrmr403CX i7A01oWlsPLRwpIDdyAzCpEUlKlxa6Y2QEk2UqVQpRtmVRdYmizteksbsxlrdcRanR4EocATyLlH kQM4MZYER2GEmi2rcXVhpSyk2CRs0NEpgRpECgWkHQLKyISMkhH/v1U20J+HhTAQgH6fX6fwvNOJ 9TEM49yL31/xLyjzh26z3nsf96iH6sRv51+K4LU/lFr4L+n2LfxpMNBYoLBf0GZyKUq+dm8oEKU0 sI0r/TtSLfXb+TTlUALp2UGRysj9ZrLC95YDjRkZJ2v6dA9Czuiri7TeFFl10uEtCquFmgh/ZWha pI8imgmZwOBucM6rGEJbmKS8WS8UqJ98tGGeGZZPwWEaoAeDEKA2B8ljZJ+MqEBaB3PFQZUrwhPz 9JzabIjCrhUwAqB5xYMG9ovtee2rf4omvIADlAjVFsUoQaMDDvshYijgQRxngQRP4GfNrkoBcoJz /x2Oupy7Fw6NkO/f+e+n8L2MPPtxz3t8fHvXTPnV1ePZrOsnGeDcAdpDBtOuuutLvMFOSeHYzOmz ShGc0Mcn3LKUpuS4+JBb5TZ8YM5ai6h8HdVTCpeSzjAsMyAkKLZjkEUoVgZTwRY8Uzooo7jaidZX TCDePO4QFFAAoGFE0iHYE+ohwzRCP2FYPTDol0h5/kbasrrzZSfRZ6aNKqd9YCyKKqnRmI85YvlB kQWxlABo+fYBE94GRpYSv9GSBvU6xuq2OH/ir/fsgiHAQcpMERtp7h4UQDbK4p8gPibHxB1+J5ui FO34gpavsr23X4QCPGkndFfbu/n6YNji720/dHOdPKtlUfRrwjIiFoBPWJVelrEC3ztVuawA2/sv oM+nGgQ5ueuaCY4LXNz5WHG9cUn0HZt4T9uH74KlFLm/c94UVEHlL4wdegWfDBdc3zTAQ7cGR4Ig uv4umy2QNt6mSOt1f8ANGAt6sBdUQMrjMU70yQLi7mwy5w/oe8HAlFJrRUWdKQdLjpta2vrkgZbA xE2zXN6qXVKI9ECbfPfliF9+m+/VOIBxYCSpS2b2x9Y9I2hSnJz6aqIUUioX8GLMHlmm/a53701k 7nx7ZtPCU2SiiTvc04ZZMhvkNG2CiErXuHA/NFANQN+z1+XTnOpHBzmQyzbtz4vYyZbQCnIQ50xp sIafVo2Bwzjx09Ou5r86w9DjnpmOEdahP859leFkduHWQr3LpSwVNa6bvXQ65r0czc2dGHSFneDr fYHVGSt4iIb2a++wVCTdGqQZ6h+hXtnn8svdFO6GufmR786PkKh4fFj6+Z43doFNlVdXKoIv3HxH ElkzVZkCf5TPO6OVBQRXSBRriG4lkwwKsdH2ZmBd4GNZnA1lm7D7iVagdWykR1QG5FMuehtLKgCq 4p0T3Y2/TTSZarWkeyJYDrSfs5tqILN+vXk7cYbQjzLpCemVjOWbbITGRz3xu8vTVcq3i0LZ+579 5ZbTYpQfxGcgqIvxLorgrM1qIHz/LgZHTM3cFxF3xt+U2Mt8dK8uWn5a99ON8niMXrm2D7czeN82 Tl2vZ/RHQZ0OxYPxwbVerqwgJcRjX2aelCAkYqWe4uIiVll7t2z4cK7SstqKuBmJuU19WIF1HIJj h6DmseOZFxYsiwuMcoZWIpqlo5G8BGu22UXcfkq0bxkiJcXXLCVuQ6uPQYrthT1fPWbaTGaQS10y LHsyrKNourAohxkjk9IxC4wYQnVW3o2/STPXt21q6/ld0SJdthMiZ0sv6j9Plb8c2zo7Yjr25NwE Tly2MUREWrKHUDVo22tWNMNa6TEcEpzbHGeZfpGKztdjmFcPO3EBX7TQMVHosil1GxhEvPv+JKUo lsrs9rrhv6S6YXY1dd7dgomfwd/2R1iFugcExDL8UBRxFLqlq27FWQ4g+0/FZ0ufZI9jXz949vT4 bq/wXor3XnQ6WcYjmTo0PrwPBV4NgqqIXqIB5OPq/1UceyxlyD64e2AEFEWXNfgfH1f1r47zRVFU HL4L5Qzb/Kzlb5FsGjhDGHHKjGTabTQveRDngVDXlkLjI1cYevx4+H0c99+F5+K/LqmGha+Vg7go gJazCAjYiM5wFODvYV8FXloYGmIfjI9uH3VrvvXlptz65e+/Z4mmE4bDqxupYdKHMHCrc/src4HF 1RekovLHa9a7b66XE8BVcQlqZ207C6FTByQcxquGiZYYSsd21dqwquBLS27z+wEkDTzmpjMRIHfv BCxQfuyDEfutcfL7u/8PUD4eBcVw+UOV/hedUcWah9x67ANcboJAhCCjcQgVBNl/n42nLD04QI/s QDnWLrlv29UHhSSYho/QiCqKaL81JVJZY8Lz2pqw7j8edvVQ8KRKsw2L+tcelhP358BTOk+quv4e yuWv66Qthhseg69O/G669bSpjLMzbju43Z/zgGh4OZyEmjJZSW5QZiUQxwHYOeiOZfk3xggB7APf jlf4Aex2uSrv16UbhKdljHsu7JoUBAPvgHZNsfJN/egyGX3hvxG0Pt+mqweeAUgl52eHOGWsm2qx UUHunwhqm8wWnSKXsB9LXh9piUu43HiZ3c9KH7SN4KYRLywqDiiMuzKvscflSy8+dc5hXsb8OXhB lHPc+iELHDDZLrrPQLa0bwohGys+ZIWLWhXws4Th7CAStrRznj33IXmtQtPZ9LDClNL9dK154qlx dFrrrWuudBOUxjJ147m5lfno2+I0GJHCuI7LMwMiVFXMqRyo4zVETw4sRhMdYozP5gzy8WeNzjVL Y2TXHkgmuq2zVWHOHaydYCypRkD7kB9FQHY9vQdsDqg4kLRX35VlWGuF/jTReL9qnbqwwoKbaRFQ OisKao34W2u1v98HiGKjX+0xAZJfC/is8X00FW6xbrBkWfqKllF2iOuvfF2siCe5wwortbKTVW4j YDAiNHB5njTB/v4j6Uw3pIvVIKIzsjW2CEFLrq4GWQhYEVA8Z+56vRdp5/DOcQIyVu76u5ZOK+Y5 SZVw59XnLOVo/ACTALKBlMzG7ttGNti6levZD7Bnnbbb0e4ej0NwYFy358IwV9NiLffwZzHfYE+J AICHdBkf09Pjpt2ZY76QPj8KDZjWuCtQ+Bco1ms7CzlHwgouqaKDCidtqUYk9GlPwsFnPiyswt6e Njs9ITUDTuXlxheDzv8JJPHGl3bTHbhiqXF0V5Opat1znnjk8B3Y2PKIgVRVE7d2OSgqjqQoOTzf hOJkq4wvwyTFslobJfST8scVc9VYdTh7J+qBJA62eaSUQoqQOb1ssekG9Rx5ASu9bM5WzuXlpmee cgiol8nLMCcjbD0tCSyZcLTh+Te7KSRkwMts/WmztrOapK1db1y/B97nZFe+HG69uxCDRLg2OXDV vt4XQvhh3baHrMs0AzjK1crSyeykSKhFlVmZmUZWZWK0ybFU2pazbWi6ivlNoH1nXp4+/y279Nu9 +sPzrwxVn8nmE76JQFWEPHx8WcN1EPuyFY/A8i6mPnn7ens45zVoL6edO2GUQUD1gyqPIuUfkdnD badaPH82NsRhvWUxZLvDtb6+WN69H++6Qge3cxhkizoAmFClGFCFEjBCs4jxGbd55uQYLHEHpuw3 icAvM6h63pGmN9tdMt+OE7nIpFXepSi0pTjcOtB3JQy1wGcxdrWdU4ZkZsMzyRSpYTra+uMc5INO eGF2qRdllaFiq4dbfCU/VA+hZTehPF0j2wv4fDf6b3sYw7ifT597SUpXiq3iBujCc+TTYpnGny5+ LyICWEqz3dj3eZx05Tgth2V/mAxbHSecjMq2vDaHMtqB9FowWu7Lxi1b9NbLfD4W2AOixCFVmw0Q zM6IhYjoEMunq9oZbJhXBFPt/OS5oXTygStvyk+XTyKUpRRRRRRQUUU94Z89TSGPDXRsLoS6Qnu0 le7mUW0T2+eCV9/Jz1Dz14dbL1tLvC1CKnosGg952IDHvoepe5myHb7LNphEhE27jZuokzv645E9 xfLOQu8mQU1fmpCyPielDvQywCfvWdk8bc9d8bc8Gco6rUlSml98Im9CA5HMzKoZX8MRnPa4XCsq sYFKRoq+zGAs64zo07GcaJwMKyzzzkUVXDrp+9AsQPMU4frdFRymK+tmVIQ70CU3k1HPj5P9nkZ8 JQWbE1S6/2bVv6zJzdwl7NMbYGE5zdS6fre7K2220x1yvesYxb4+meMpBZKT0dMQlua42IkpaYgb 4a2ylLLbHK74EY5M1oqoKJREFZDyyXi4Dg/EDOT54LDXLWyJiZPeBB8824upHWNOMPafIVBqejOq kHMmYCoJ65c83obmiibdW6peZy2IrqhrnvNCV2QwMaPj7jIsZxCDBV7qg7sjCia6rrOBvFSnmXXk sT99xik+gtkR8crqZk9IOuOkwypojWVdKG2IA6sZOksqGO4mdkRS8XDcSHv3zrqjbqKoy1QkGbYy YVBIFhfkUVN/CIiIsRwdegfWU1rHPfr4beXXkxcbrdSTUuufYcchmUuVmFtozlTCkMJFxaPDgqip o5rit+vFHGb5eLKmEUxTSt1SbR0SEETg5shsq9To8Q2t74gQ+JqUxsqIJ3FEE5FDD6sWVC0BhL53 42Ty58REQG301FWP1+ZbYjmakRKQTU1o4e0oU6bgY+Pj8/h8roCYDAouXYft1eDq516R91s7ZZ5H teUukMvutg5LcjS7XpvdaILal10OnTbU5mtYsK7Xh3JsoHhE2ShVzeHM8rHnxQGLJjEOR2RVVpnj x8AOvfjBhMYYdXeIEiIdyG+1r03IS1RdnbJJJZP7v8uvr5dW0rk9fRlhz3mE6GlrPir+vRN/bVE9 9GeqJjc1zhz3irfszvIYB6gQzoDK0kx3lQxwEtPVwaNlFBOsoPWNvLTPdru91fbNq3Ouit1110LB CMokh5GTWxs6yyOOIg/sgyiWH8baROm2jgJhmpvKeXK5d0C3ESKT7saY9dryjsDplXEsUEvIqRfO D2e1jPAy28X3ZaYTjZTDpWK18xSQVSSiZhncHkqI63QeBvAhDK+eOK6Pc8zLaXxuOHh7+fPzc7Zj 6Kn+Vn15Xa+4T/n/d4+eLvPMh/j+L2/r3/VLL/7SIH91BRO+ituP4QbxNz+H2vAhZK/5Jz/6HZyF fGcYN6Qo/laXGoeXc/3TCkQxzVXeIHbHfeaP3KDwIBEOFI1B/tOs2b4phPd4fCqr8PE1TX/Epxf1 /L6z6YP0PED4lsPbRgYHR/DPBRmmf12fG+GKrJWNU7MCWKWJRVscrhgM2KJhnfLaVVHE0OKhCyX+ v9qacdvT3aeJ+uh48W0y4bZ8OXH6TWZcAooL1o50eNgO6XQDpdXGwibYom6O+O+HCG7bRjuoQs6H Dqr0MMs8H4qAKFbq33wrGwcMaIi4qrJo7bupUXm6HWqflctdJJrtH9hTYPSMxqo1YqpGPMSoboUk jIQebMptCGoyLWnPtT8LFwM6qJITFFF9n9mV5wxg4b8fLnjJH/mufbCfPNC8vsj/TABBE/gAGH9d y5gcXZfvAX9FTMIDEP7DqYhVdFVXKc8cpY4F3LhkzLoIiB/VaotSwOGGMmPEyYf6JBVXqGgB6Ymy iqL2qm38UrcIjksyk53XU5uh3g7+A+Bqg+UwDVFoKIMqCA47ccRt74metDZO5C1Z55jlrOYOdha8 ZGRkZExjFQAAFevjh8u5+tb7Vj1b5oQ6WrLkvG1N7dpX5MjlekVYIcV0NcI85FoJsLbLMS4TAwUs GGl77O+X+L3vie9FbfsfR+r+5+qOa67i42OSYxZPres/b7JD0oCikVFSywqVFkqWVKX9qxl2m+nt hN9jOE1MNWLqLwWKpkCG0GqEwilSEtlYtCG7WyWAZqGa5ToKUshkISyEyh8eva3d5be7e0R3GqNq gAtooXhbY3Ru5/PFndOAHxUSUCllpEam0qsbW0pq0aiqky1UtnGBz4YhsihalsiVFAgMBjsXgfHw nxAeerjeMhby9DDt+GVn6fsNHfPv4L9oG9ggmH1pb9K/J0IfKRBEUuBAeOsfIVR6aaaa0fljbONt OM884XRfyfL2rry/rzRfju/D/SSsrxXNlwyfjja63H8fT7le/Ez5rk/QUNmk7Pk2GmeL47jb3Xbp AJEeUiFIqkSFsWKiVCcD8hM6HQvCjflG7JvWVsfp+B8FVQRRYlclNEqqyc343kOjUplYp6KGl0tp 6egWkOW9d+DXXUEtG+4uodaUIWHsmK3YfCe9w1yIaEi20LDmv1f6JpcZ20YgS3e8CbAL11hbuVbe JwI2D7Ofer+OtTw9DQjpjnO0TkmvQ1pjja5NO8lzIOOwOUzdJE9qIbi2f6RBr5hxclUSkFO63ZKq s7ZeObnK512b1aImhRFc4Uf7gPf4/GVVEmNULXoHyjvy0tJLYWiT3eXDwZjX8Lp5OiGv8IYPzD9f k9Hem4tR+Kwsqcv4GSTm70eZkHn8NgMxD84iEEczRdm4dZy93w+XxX5OHD5I3WQlJ1pCPp2+fo5n r7YA8RDMdIAcM5FWvwlRCLCZvnv16z1KqxSp9Yb+H6hnz0ERC90BZ0VegPC76O7u4aGK8JaL+ohv x3sXhbBYVgta6cNeGlMBKLxBlU5KIknhst+0wguOjuGAiF7FdY1A5aE8tIU45831OMgHlzOO2yB0 69gS3PVbG7JwKQ/PCTxVVrRVuQCCJdMtwVYg8rm+CSsBy7/QM90GEPRUdY9sjB315CSgFwUjR1zo iCBfFWZ0iwA4jCc12RS1Fq0tWlF+g45nd53tz678HbUsaI3nbEuQ+HusZn/XLN16xwtcZoJYthgN E9pwChJZK7sSZ6cIB5+gc77iT1nHdiI62iHEi+8ydXykqAiGQoqfAfh4+f82jKKqgA/VVfZlT6N4 pCMYxjSZ87qqVIiAQy7EN1V9yDL1RtNpjzjrz1hwE4kWaGZpe0ZQMlQJooq2wgoOBVUU6oEt3xg1 lTKLeIIn8TItLZgDujkA5In7D8gKddEnE7cDQiSBAWQ3yxcvZ4WqxOFMigIfUGm8O+FwGdm8gyfd Xtqjxx2wo6tU20W7MpNrhsvvMKiGWGchJvkRUUuMGcHAClB/E7AYoRDlCuSw3C8gTDGtcHlhQQ5b M9BXCqWbZJgrf4XXh/fcyHKKD1kSoCSLJFpaWlr0jPP0T2E9bxTeeuB4fqR4bNakHn6iQDl2UWA2 11/qXpCLajd3VjJIKBkOoGy+Ln53RKF22MePTJhCP4j6wh+4Fugh0XX3GQnd7KF4SwVncvzbLitu sBgH4Zd5kh8fwd2rnOFoOu377olE2bvK6JzSwFg/dQGQugv1fsPa853yT2nhftC/wt3FsPBZuaCg 6akRT16QT18XSPs+gOuLPY48J0pf9b8CoChuIXS4l0S6XR3HGGoZniipmZmZmZmIZmZmYVZXNui8 AiE2dPyFUwMH4gTd/y44DWp34XUjp8vrgKYfB2v0VW+OOOOOOOddpnEKq5XLfzOQiWG+LJwoHd44 444vMzM2twZ/WCr/NqDL0N5gTxxixSprttttqbzVVVhPMRUTIu23j+Zkc5nkWI9DbA/RODdo764w 2D1g4ATffd9Yb44UMTHDrPSJiY0MTEyMDI4nEvlsKI+ucjrz6RT8BXqSVvljvQYNmUJJEt7QyT2w 0gNcNu27gaLSY2oGSsKAtp7MhyhLxDyuWBcTZvCeQb1QL0lKqllBnYt6y8qIssSlyhCYEVSCLBZr 8UnKIDpUc0sXPwyOr4GsudsafofGFFe/XzfYGueWTmUBwXpjQmMBJE3wRMF957fk6N/CjnAxMkSb jDH7pCD08kK1RkZGRkZGQ2MvcqiqqqqqqqqwtQ4bh0aprMNi1DsAaztz0Dvzz9VvofZYePgsPHMq jMy21Mxltsd1wV3XBu64LuuDu32r4fRq/zT3j1ezvzJ22xpjspVKpVKpVlqqSs4nzxZ9asFeCXAq Ifjja40czvURFW41mqqGrNAAAACtIg2AbIgAoBbJSACIBVJSDYBUlIRZJJIBCMFdbQFRUAO14ioT mcpKBYVsusAK3KMO/EyS+0tqIMiYq/7F6Jkdr2RUaS0g2E+mZ12epZaL9V56e4TsE+pYXAA/MUDv B9htMVw/4C7VU/by7x/EDVa1q/r+Z+4zRNSECSM5OiEPgkqkjWYFrWyVTNOqqTG1G0lxFqZJ/W5H JvyRVyfADfM9fwPI/KH1gd+69XL87f77oEYdwHj/TvZ+f4NCBRpA/4gZgljixsft4/fTzP7prcCy DLSC9xmYgA81R7ei6ZvNNMlAzT57O2uayWy/r1w2y2llSetq3cd7XX2X33/k5zn04ZCOsssc5zvn zz+86FvEBStZ7l99+S8Ns1HqsRncbjhLf8hkRBX8uNuSPYG42O4SHDlFxKOYPnVSt+8/Zx8cNuXv 9A3Pt/FRDGNMkkkkgAAAAW00wgTYYSAr6ejUJBInrH5/Qo97kVr6tdibKVA0OtTyMUENgPIHuufN 5qctmOT/QPBoiWKApDecZAka5gDearD71XQEtFa3MF0xMM2NS009PT9dg6EZZy+36w9t3bVe+9Ou fxBlyicViMMsTjDIAAAAAAAGAAwAA7iuCAAAAAAABgAMAAO4rgGDRbaDKjFKVFEURZEUolZLdTqc uhkjs7fFu8VGt+Ca/esB/TUdnLdbKPOCN3WWolVY4ErSqDDs7VpxOPLv1bZJJJJJIsWv2O5PsV5G 85ADuOdTioCbRFPREPRX0XJP/AaFfniUV4p+EkTUm2xVv7srv37sKbSaTbmNIWsYAA2zzrarm23K 5WK67tTTRbWVLOXUa5lUMoMuLksDFjEpJJhQhBD8RPn8QQQEPM+87/T4/PxOp5uAtt+T18meeP2u V/xvg+WEleAIQbNkHhW+rodlI/Q/0zndEpVu4U8SGUkb5/P9526jD0KfPPd7uaTqjApS2qt4IvCw Z4t5Uej5wES2uW+O6z2ML/wyvz/GU9M1a93wE5GtcG585/OQnRBwtnz4bvCB1t5PCDmCDmGHMMKK KKejDM/pBHRhhRTtq1KHGOnLN9MWzUUhjSGEaAiFEOzHrsHdHvmM7c+6uzuwx2JlNsnlirmPVS7b jSvJb2izZXp9hVHilt5XXtnfvX8KAgVv2yyysDKxMVeoqC9wRHIxllWtf9KS8CUoUHOmnZPZuD2T K5jN9Wlgvd44bYvVQ+09d6Df9RiEpxH8T7MAMV4Yff0hiZSF88lzTqgDARCLPOpG9Gkyaj2DZIy+ huuGVVoQQEPZtTM0GFTp8q6+soiGs0UUUeAeBsYBLkjBYUPeKYNT2FnKNC5oGhoZBLkjBYUNBTBo aDg5JoWNDJQhIpkguOFFzQcRixgksYKEJFMEGBwouYHIFChQgsYLFwuYLAlixQ5gUMChJJgowGDB YEsWKHC4pZRVDAog1UYLFzBVWJLDjmBSVFUMCiDRJgsYMFVYksOXt6d3IjvSReA661y8RkIPx+x1 Q+CZ+NJldfed+OC43PXsZHv/ab23uz9wCbBKH2+GPkbZj6p7RdMOEE/d+wR/dBJA+sT6QiSEBOc/ KjytZ/JO8s1g5w/LG7MMpZZgBcxI4XC4GmX5AZ7fggaxP7RYHSYh/9L5I8A7eU6fX2ff4n0ShMre V8y98av4XzFcAud8HxpOFvdZO8IQAiF0CaiR1PT13JSjKBfO7V46kZIZgmVCzgwgsIKstW/O0ZUT BgVvmv8E76V8m99Bn+M4dyAzDDMMmCgi1E20A0hmpRrVfSmIliUBxBzqJvB0q+qFieo6c1xeoVSf eHT9nPT9Pl7Pn8fG5RIiWxjGX3fSzHwvCc5znTrCEIUpbaSrNwAb57Z0nE66ojR009zC88WpUGgM IhLdsTwkKlA+sPYajfq131YyeQob9QWbkTQ2JnEsYC0lolq+NZJieP2kAHjrHWZECPNkU8xHlY8r Y713LrfRbAtluGBzjfmtUtVS4Jeyugepfz1/I2l0+hKUMtYkqROoh6399r8zw9m/F34ib1rWofw2 0SDfKlpOg9HgWTe+pU8K44zoXQEsC+SiJgEpHCwp+VP7Y76bvbbeOXAAdyHlt9SM0TbM89p+39xv eujj4pLXbjtpLzWmquirDFQnSE8FSixSu97PHcHjPtSZ+zQwOBZSdEhjSkTV6qgoqKqiqKKLFJPv 6akuGFc+RchCEIQ5TazX8hqwrt0rahNY9kjJ4HYY+CXnP/UaPzQSavFUSCadgnonlIjTjd2/qGfT 7awazWPP8Vl49UuWw+bTS8sHTxXD9vJuGVv75EPXM6fcB/QBZACgO5SEkT6fTugmErSjG8WDb2e8 VUBRfEGYenCNtr2ZpDmOraA5En+IA9HYcTlXReNVRclWYRtRXz66Xt+EPe9te3R7IIiIjzTBUE9t SHZygfgmmhim0i51HCGlo2BWSgdGNueKmHVHDALJzdOsyYTmNmcsgUomTTg7AxklJKyQD8Z7xhoE 0OTDI4UsMgEwGMilEAoOW1kznuy72bJLISWmGpuu7q5t2l7sAOwAvld3ZlxELgiWkxhkMlRngzec M43YDBzmZ5iQ6KcgdMvNuEoQthOCBzENKIKJxAdLhgXiDy8vou12ml8d5t+DbWFKEyKtqVUsKWxC o5Mn6BfJ4/w3ysfs9KlVYquQHrFdcAqK3T4AphEQuDEQfLOytkb6qEN3A4GvEyBJwtJ9mxPACvKu KKfh4afaCe2yTeLhz0dN9LgXf7ylKX/b7XBci+xaC61zy2+ulomN2rZZZRsFoI0Vr6rW15e7G+cB LR6TEvtvvzz+pdcXXjUolUOx9PA6dHvUVVUVRTuiWIMvinx1Pp3LhcuYmXKNcTLllxjZVjZcyZTL ltePaaOcc5Obl2HYdxRSD63TIB5ctuC2ejV9uHpnkSX0QzGSeO/kNlVumYlrGCbJFSIyKjCSAsgo MkmpK1qAADa1r1e0Q3GHXeQwMYiBIhIkY07KtHPIrWG/4VW2defDuHxTWNSHVSllUsWHHeerDb21 J1/HL99rWtdte17Wta5i9Q8vLZ1qJICEhtoraKisWiy/Cyso1jLJIsAiPRpoey6pduwlHQEiIB2c 5knQZS6xx2btNY3FDWaLVo4GXWZ41h1yS1/zUU+eggn8YDUdYI5IH4buMn3gZZYoktZVKlqsNVSl qyW2sGwm22i2r9PbrbVGaVpU2KTapEmmbVuVtyq2TM2NthKrKNto0lVShVRqprKCLVmaVWm1lVNK 1E3utXZt+lzS0UmZCKlkpWNk38o2LGtvr/par58DkB5Paq0WC8t59eOIwfhkjfE68hQ9IWQPzn7R R5OKX+nsbGW13bdJVNGXIAn3u6KoXUOyznslw5u927s73YGOJVhvvzcwBNHoVfbV8+vGo1FRUvXv +63a7oO6h1QLbiuXmVRy1OlHDjEb55oM/1tFERKCbsRDPSUhoZw2b3H3QHJTzzoiBAikUJ+Eh44L T26quKXFNhEcjXDSX5pZsZ2UMrw7Ij7fpUzv+fTlOTx3dw6teGRal7YN98hvUgkDg2IqCMsjFEAn AuuGLJm9DIVuzPL+iEA0F17d27bcg5mp489RhZiW8NR/wzUQ/ITv1fkk+tF8XwPq+zBflirCza2G ViyrVgQNQMvzUHYUq1BtLAa2iXLgFopC3LhtEwGQtjWhTUqVgNhWy2rZm4wYGDTdobEyqVVoqj5p MbRG1Yja5MM4skOBpibl0KhqKpeEm/YPy2JJ52SCdqkWkWktSuWLyYa59Ca0kQgGGGfDoU6lOo7q O0e4JJKqUp4kUoYYZkQ+a/O1Op92CsRgDE2iUqD/OyJKJz58ScWnuShOOFAYySSSSSQtb0MCYlcU B9evO6cyIjtbKBlTuzZBJyfO1rf3aAXRDXr1daDc8fDQ0O6WyWvxxkTFienGN3q9/qv29XegAD8n 3XMqz6c+l+hem3WNmt1uXcwJjTLTJJJKDRFtHcy+dN0S7ZqKmp6GqSuxZ4xLfvn3zSEwA5ePvAJt NsKAWRjtxx+QDUwsUtoJdIOQLSzDwBraA1ZT2veSt56lXvcu7UumpJS3iIcAUQSgbmmgyYSzKEy1 F5alvag/kvaqPYbYASCUkCRQYEhA5115GeN3czFVtttt2nlcssweJjE5TWIsRSgbS2222lpXBRSE kKJD1Mt3EBeeM1/Cw9cATaBf4+XRWBbBt9TWLIr6C5/SeXz8TaftaD6PMBBiECIbqjtXF480kPnk 4QwIYEOXO5p0RZQAu9AY4pb4CnMPRXt3Wup3ZctenHVQfe/b9F/xESQCLEehD5fS75ZlZVVYrJM1 9WtbTAq5g2kl+wgDlu7g67ZhTAtIyjEaM0WaNNFpmSVRyjJhluQ4eksgK2WklmJPIDnwHXPrfna5 BNWuMubckuQxDnPwzwEDvIW6YHYFDz3Z9Ai3ShrEgGF1TBAuFsWfv20pWdOeJM7WTa9/579eWvn+ j0AAAAfftXfS/Z97949hj8bfhJIeHQ2GH13Z4DjsjsQPgbK2edes2O2tmLN7pedLZaYy0V4D1vVF x9i3F6prJSoztVD5LNCzbYt1UMLgLhzVZzYaYiTSiOhCltIxJhnBGbVxbe/rWXcStWaubmrs3NY1 FSClCvZ9JDbj+uGrVKtCpoKmjITEthMGsZmyPXbUnEqru3KuSDUqqaairiQ1Kqmmkq4ialVTTUlX ETVTTQq5E1LVxF98fPujM0TeWr8tLv3KNeRyfVtGR8qg+WiMWG57jAbZc+/ca1XFMTbB7dJRtwcy HcOmnYdl6v1i23xbyWCB/d3B7Aj1REA4cv1ZDpA3Pz28J3jeKKBzgOz5mnTOZXrMTp0cxO7wOmqq cJMOuB7APLJA/GsVgrBWCsFYKwfQXktssuFsjbSYrxCodVG8ZqkkkkhrTt6uu+hoyc0A8ASEQ2g7 cGVWIkuyXLq0EMnpe0k4OGAnRzV1CHMCW3yuiatEbhasnGbZMHuiNoQfw0EMlb82/TqNsZxn2wUA MOmRkO4lMXfR3jGMQB35v2O/avvt/E7ve9N8Ni4Gkuxut136u/fkYJ2CFKm1bWCreKIZ71wPW/w7 IishYomCpPpVhA0QEAGid2OoEfpWtb4+bGMYxjGKgALbbT6p58k4Y4RuO6TCdmiPKRqRbq7S/NvH 17Vefj9wPe7vO4AJAAAD9bdwAH031Xu0b3/i/n2pxyoaqdmV14VmMGBr5wkQmCdCgcQPLgOu4RJo YoVNVjiMDotad18IPN+fxJVVJUqEGBApVXV1kw5tRU1SjcuC8sbi1BmfT09fPZxZTCoq2LV4wpmE TwRISntk1kaCtEXYXVqK0EFiUA3pAO8n/v+b6FhdUETeB9wvL1BPzOR4FqKLNgEuIE55T0NI9HW1 3fP4Hhl5+UwPMVCmOVbCgo2Le3KJttAFlNFA0qIgEQiHLBa1EqiMJpRUhIpqYkkwGxtz24pr1i1j MklORpqIIJohqgljJFKtKyqKqsrKpbS2lVasUqrVUqrVUqrVUtrVipUqtrUpSlLppsAERJIiISIj AERABKElKSU3cFtRbVVUW1FtVtVtVVVRWKi4eRDQ3x5yhgAH06dYH2xvkbBCyJ3FLi6S85+nytUx a1rZ0bFYxbGKqnqqta1rWta1rWta1rYgRFNfg4ZjPvPeEaKtCFbCxCqq9eDzdT8Zue+3Pobu+xTr 3G7kbCUtZqrUQoes+HSfvKc7W/2c2vZPvWKzGLFZjFisxhYUWJYUWJYUWJYU+HD7QoiiKIoiIiic nQQ7sAng6OjT6IHxzXJ4lcEbFg7AIWBtiIbs68ZNdJY6yO5Gic2WTGW20tSa97Uelfd7txOSKbFA k3IOalvp+799Wta0q1rWtcHjBcfj87HN0cRFfU/WJ+nAW4kf3v5qv9qA/ifA8TeFshcxpZG6obN0 2k2g1H8Ro0aJp+jYl4g3mgVIwEyTmzcNt2QRnEckE4BQy3NyZLLQlsy4YYGkx60zm6JaXGiLIJqS 3QuWxpm91sNAmZwXoA/EOSHaULAfjzMnYFGTcA50TUNbY2G+S5ls5JNDA2cHRl2EZiIYBBD89XjP 3wRP3gLy6ZO0Z7O1PkgHoevw/Z/a/CWgQfLiLf9Moh9qSCxd9I2r+dtKIM4PxY0NSp05cvyW2t23 EZqxYCAKcE1AfPJbjpMpRhhmYb7MS+PycMqGSClYMIklHTnljZaLKsN+ZjPLnOBuPDpJ6qs02ndW 7lu4hWziSN3j5o37jpTzsx34dLbGlq6uutQ0FTbhkTmZhuGTdPzPmNw6ZzBpjFazJhlTlzX840rv kxfZH1R9D8+Pl5uHeGTM4EKVVE2LpmunIDOTXm6BOm+ClmKAwap0NfH2Ui/L8Mu/VEonHLExHA9V ezjSiBgKQOoqA8DgyOVWqEAPrdOKzGb6ol7Dnm1Ch39Qr4bHRL7aFEGgqAjDsygI43khPS6tZB+0 5KGRwpoqqIJC6p6ztmsuXt0YTq1ZESFJVilItknwOD0J66+nnrRb3Lj1WDuyHj0tZ2ruxaLaJSGy bJttiud5rbTK6gd1Thyky+w9BGuPY+Gj0jaEzmc4pb3eQFgtC4nNj3jtuJvDBrIXtINzjqXDqtXj qVceLvzRfvP3DZMTLll3sjbbIeAgTVVUXDVBC6lwOU/JDLeLvBTtOu3DWsSNIe5TSCTZX09deTW+ de2k2MYxjG/J661vHwTJfeHQ7L7MAHzgntiXJ4SSSSSSXGkSli96715Z/t4HYLoE/YfvQ8IqYRfK olL/G/J+mr926kJrBU0oMUVi1Myqgkps0VbGg2ZrEjYYVM1KWkplmbMzMrLLSSiVmqwm1RqYACWV Urb9WrtV+mpfNJPL0+5mZmbaWCLZkCI2O6t4LwH1FCFRE/1+udgIcXTLJcwNLtEDbD8wcEN504T5 nMQOoIMLCie7ow4aROvPjjiBoGd4E37w8hYQvKDGxttLunOd8hzgw50spUeg6zQNtjSyy1Atx7l3 gvrPuHZNk0Jwb3lmQIBoQlhcKzbpZcHzcskyHFzWYFDDxermwLNvNNJbhuCYnTbcOrLmUyBELIRR hIS9l3JQ2dGHXA5igUuMw5CIAZvneW6gKXkgMIHAQ08eZzweB5A7vgE8FsiYFgGjCHNQOPCckCt0 kymEjmklLTMwzKSmGCEMxgOUZ1cJVTTKNwZJrFxRPce73fCSz5rEsy8HyAnvYfVpvVHgWktA++fF h9ntLCO61FaFH2u2W/XoZJD7mNTRpez55boJocpHB1VVVVVVYunJTVRnW9NKzpoaQaNjMXWROVsU 74z9ftwgsG+xkxq+bVGcw9CIBzxk2uyDBQ0WG9CiJ8OnWHLQvR5vLA7OUe+9DuKUYo2sSDZ2RuQr EtkqdE1b9N2dw+UJxAwO/q6iNcOy196lFBExDmiXCHDlhpVV9jR2y0XTR+vTJrsGzVyULGwzN4Xy 5ah/mPKUC4C44KEfivHLC/OTumMT5KKj+ThHiKjgEzCfC14hUke95+Ob+SJaSYxw7+Ftse0aZq22 K8RBMkFROFn1cougTM3cM6YUc97c3D4XIkbUDYv9BnGsEVTQIiKiJbuLPY6xe5rOqJhtVVHgXPev yGH9bzbX3NX4mt9M2vmskkaznJj42LHP1BaHuE9fG2YjwaQ8Pa91zYzHWnlFJCKgHDaSAWmaXWDJ KQEfvjmomgmJvFNOZSRpEPLo3mk4uWQB+vcAfFBOgrACIH+X5fNSwPjzKidoMBA9TknAR8+jvo7q RFz6hGbxNVdSlxC6ugcjcWQ79ARkS4sV3s7lkTLABPx/fj1EiiDF1qt0zlKzC5RJiTEuYHeCvZhm GQzNyjztfcWtLYiTVVBehIp9nVqL86TBy4G9UrEwhVSprK5B6moIUGDcNctnxr1SPVxMFUXz0zy2 kYF7r48UhYXm7NZ7tK8zDIPzncbIkjpl6LzEIMfWijPI+xDxZYWxsv1ipClkiwon4KF17OqBf2k9 vLgDdhAxFhQ+awXGltYW6xeZbrZbC0tlwxzTHwzE+VwYLEeWrp1G0gvigz2P70+02vYbE3IbNXs2 6wLGY8y5ULli2Fgu+n0tJSJCAFBqXz6w6xO8WFFotWlVYkk1pD4x8Q3g3sJaRKiyypP1Sf2vtbRC 4HVmZ2vE0vpa5BkRlltZW1mUxiIey9ZrXmm2uSV6rLpiKMYjV0re7Wvbzh73bxW7y7Xu0aNAGK1Z raLaU1ZTWUhKHOW4ZKWUspZigdcOXpuyE+C/NZ0dM4sbMpFPHeXnCQtg2NKBaHhyXAW0wvihmDND EmS80Nwmy7obhvWel6lrzCYTCYZhmGS21ANwmS7obhpQh0KaAawyWFLBJWz1H/l/EWfLcH8v9Ija lM+1R5T5uHye/q1gvYdSL4kJBxp/liKj7P0x87pRnqr0u+6A+nl7seb78UAwAdZnYBtAZh8ywo2g H88q4fh6ePjujpAqLUPt7/341RtIiZAyjFMWW2kpYt8akOb7P6HjyCJDD8IKE6vpyLqaprIpIkkC JMhTtCyDCCD07TnIkCKey9+f+P+HaB/h/V/5ktbvwt4eWz/2kDH9X9cNe3i9eoGkW2F+IGfn8NM6 xLrZaJXO7CJ3/YE+6eDt2vHug5o/X6dncOXuR70SEn977UQMw/t/r/2Dn2gvVrOiqo5pu7Kx5v6i KC/MEs/p/RUBPxgyKgMiqQiqsiD3oV7aFVQYeX+wAoHgPb94Ionx/h4H4CgHgi6/BD8UDiAa3LYv 9yBzrD7w4mXqfX8T9LoJgZgI7iCqdO/cDiLwQHAFiEZoggeXx8e6fA8n/E+d3tg4y+MvT0t+cJU9 75RlECFb7sFpUuc5999Z4Ye0jVrcZvLvWuMpYF1GAdxCj7nrPv/d9g0BEtPVBAKZ3yETJAEyfDW/ GVlZO33eQ3fo/be2N8KSpC9yxndZfFzUWmyIgAgn4ciyt8dv0QBNMOG3m4cNDTkCLx07lR5+kXkB lugGU47aEzxUHVYRQXYry3FyyK4fU9qo5HOvSGJCpKtLUqxactkQ2kNjNpI/iCV7YRJVlh0gpM+q GSktlVS2RhiMQsatUhZMhYtUKVGPCyJJJjCUZALbGJBLASNyInl3evWtbyWubXCtdtZsMlzGtJTS WrmVRg0xVEmUKd22utcFTKl76rrsm8pV2Ra7Uz1SrPOeUTUi6ebVaFhAEl9/ZSqiHR2dmnKTtrPr tjnpMNOk3YdWPTG2C+dsbRKtPuH2tTeIHmCFuYyIIgwignTmAuAkULmGcV27txzbALXy4X6AEQnD urjnliKPUcCCQXSKplxxsbdJfmDmggpl0b/1l1DMUdgahYUeggpcIqidAWPwwjEg/fkLAUSwsWLJ ESWm21aWUsqplLMVmyTMGBFEO32dkLEUYuRCoog5EFS7eluW18LkkPHaksbqk66AANBCNkkjEQCR IWxagltjyGQw5dRaFhS41ogdEMqpCi6uaJhs2JGWSG2yWzZWqFDzrapO25GaatLUSqFnCVZEaLAo rUCgRJZDqzJDaNNwgkgwimZVgLKUspVH0AhSDBAKQQsgyS0sI1MRIBaqySwqhUQHMzANBFerI/zE NCKSIxE1GscSI2uWLlkgnzzEsrh08sdIqhwd0g+hw6dLIvXrOL+9sucwOdl3c7F9sa//uaIanBEE eSh1CYCc4vaZA0gmIpqhPx2H2idqj8+Gp3LBAXs7Tlr6uvt/nhtV+ggnNqBPDz6QBEAwQB4IksFu 6VgJZYdIp062Zy0QQ3Thyfg82gJEXxrl/AFToAwRH4V5IHmgoXWrCPuMwB+0Uf1oJc9weOtBTjBP VVT6b6S8h8Yj0Q8j4QjafWWlkD8CtWO617kma678NiPCCcxHQJB8myfsKKmnQc0j0CJzCdXSInUq MA6EEgIRSCcQMVUHah1ICgYqqCYoHLgCLYFN/JRCSQUHy+SIP1ZAjrRiVaba22jW0qVktSEFRBF+ Hnh2+Hodk87PfBn+5/vvab4rJwHk9w/0xm5ZxtAvo6nf0pZetfRsGg6lP0ylbjQpe1TEBAk19b3z hTYM5s1Q/G1c52aWEEPZp0NrN+sQQ7oiICfAB6cqNFUGlFPYoq2IAz2IALVtBFBbgq8iCWA95git CjABwBLkJxfjCRwoeDvV84PFH8ck+1/BsiD9JJvzgkHQSfb2CQfXJt3qT8pC67HwxLiag+R+aChf UIgaIC9IDuufU+IC1bcqnfmC5ai248EhAYjIiEESJI/c8BeO9DgIa+H1MRV2fTrNEBhiJZEVCVUi Q+Uldf3wn+V7iRyP0Qemj2ons6erSTyrvbEdUdpCe2RwEQNQeL3CoKy7qGwBYMBiKinsinR7rIGd 0ABHQE5xcDy7kE3i5oKHtRdBGSl3In5XL/l+Qo777lRQP7OrtAETgKKHObxRQ18gN+Civ64rQjT1 7IcNWLibQRRM1UoAe2+RhcUbHYdIGoReqJJXD3LJCrIgygqyrRSbTaUbWqTaspbFUE2VotJsibVj GotFmRVZFCf0HPAtIIZwFKFig4DVzI0wPyUehFAdrZVyQxDAQUlCHyC5EU0qhII2dBQDAEGrH/Qp VdY4ga1U4eg6K6Ig6wdQGexq6GAuraAbUDmgqifvX7AIonmHd60qAI4AWoQa80BQO5VfbLC88O0u htFBIgH7TwoByPcUhSo0B9viCHxUVgoAh8SZe8Udi7BeIIAGu2pUZwQOQ7BDqFNA7errsFwIdio/ 5qlg8kB5GCidIooTjqweB3qKKZLYEMwZEWIrSpTqMySlJVkJQUWBFCEGLEhSLFEgHJEDvV9RboDu Q1KjvyUVogIgbiIgrEiKAw9XaAjmKpAXJA5aAJ1bgBhEepInZAk2CQbvDwePvROoeHJ4uAKglDIq imwDbFdVl391OUSaBQiUKOePWB7VggYrEPMQggZOSxMoY1ecL3BwFwUwYJzLoBuEHyR1kURSVEi2 IVYFhu6Ij6JJCfHY4dpURXVsk2chyETLCSqPWdwjmF/cAc2eQsYEUTV7A4XjtFqqlH0S0sFBIlky tJNskJEoAU3BhQKSLsqSxAaNGzq6UNiZMLfMWaVqDIrZNSt63wbJN5vCaAyNI3kmQyRdGFwyDQ3u 6HUD2HcDLEig3AxDJRSMVTNC4KIa34IkUTFQ2qxaEEogpvbZoaxG5QUxZAqzMwj8ybz1wPgsSKqb QA1oCgUjrQFw0sL4tUgPIUUO54+RH8zch6EgQv5Yg4kb67RJCGiBqP91FFM0QN4vsESy6C+8UUPM RXkAeryzNP9x6DGKj4KqCdxtTpOd2uO7idIic4pQh5mqgRbCQFMUD7oA/nZQU7aERUQKOsWlPgQR jkoNBZFbDwF3oghsEj4qsGQCICcKsQCA3grDeAe1U6BHnQNiio/u/tSD+OSQn3rUSJJ95VRAYlEk k++qRDUsCH7JETRLJIP2SRpUSftGrD4I/5o/YfycbilXndWxOCR/oHy9/4/x+zyQPIE8kETsIScy IBzCi7gHmOOQ/4kFSLmoP98EXKdIRGUWgWwHSJJGWJaQtWkOhB939X+v8P3Z9ziJzUTxQadhkk94 3Fk80eSfAz5+s9RysSWwPURlQeqJkliyvUJngidh2dm7ZyEhOUQGo5TP/4u5IpwoSCbniHGA --Multipart=_Sun__12_Sep_2010_01_48_55_+0900_PkMnm9kVnw=SlyEC-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 17:31:54 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 4A185106564A for ; Sat, 11 Sep 2010 17:31:54 +0000 (UTC) (envelope-from mdf356@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 0E0D18FC12 for ; Sat, 11 Sep 2010 17:31:53 +0000 (UTC) Received: by iwn34 with SMTP id 34so3931744iwn.13 for ; Sat, 11 Sep 2010 10:31:53 -0700 (PDT) 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=/RltPhpOZ8JpcYHLKsFgTXIxcFUIjXEwC64N6WgNMho=; b=L8YIi5Zf6S87hSMn9fiei6Eu8MMPe16ccHWg2spHafQ2/mWecO4gimFYtCElz1kmbX cV+UXORNG5Y0xpAn0gVQstlFGMpB/0OvXAdJmnNWp7GkpacTAWfqYbDYV2Ls2hc8XkEV ip0sitJmkdL+CzGX6GFgqIdJ08ViHpoDHPFrk= 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=m7bumFILUluw73YVBYu6iG/VAkp62s/maTUUY5NYad7dW4SYKB4VslaXcIy8XFnWKw qwFwJn+wu/eYePJORAiEAVVedL/LtahjkxoFn3zp11a244SPrJpvAIEg+LDyjKzy2BVX PsZwwX8HyJinNjpY7ok3Wp/zucEkLwcF2AG+Q= MIME-Version: 1.0 Received: by 10.231.193.135 with SMTP id du7mr2975443ibb.176.1284226313226; Sat, 11 Sep 2010 10:31:53 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.130.34 with HTTP; Sat, 11 Sep 2010 10:31:53 -0700 (PDT) In-Reply-To: References: <4C8A9B8B.1000006@delphij.net> Date: Sat, 11 Sep 2010 10:31:53 -0700 X-Google-Sender-Auth: yo9zOnTjs5lx_3Qn69Ngi1iNHCg Message-ID: From: mdf@FreeBSD.org To: Yuri Pankov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: g_event spinning 100% when doing 'gpart add' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:31:54 -0000 On Fri, Sep 10, 2010 at 6:57 PM, Yuri Pankov wrote: > Nevermind me. That's what I thought why I was getting the same gpart beha= vior > switching between kernels, with and without DEBUG_LOCKS. Sorry about that= . > > Same here, gpart hangs on: > 3826 gpart =A0 =A0CALL =A0__sysctl(0x7fffffffa250,0x3,0,0x7fffffffa268,0,= 0) > 3826 gpart =A0 =A0SCTL =A0"kern.geom.confxml" When I was doing my sbuf changes I temporarily had a patch to change these sysctls to use the new drains. I couldn't get any output from the three kern.geom.conf{txt,dot,xml} sysctls (they didn't hang but the output was empty) so I reverted those parts before committing. I doubt my changes affected this, but I will check on Monday when I'm back at work to see if the lack of output is due to my changes or predates me. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 17:51:23 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 ESMTP id 51A0C106564A; Sat, 11 Sep 2010 17:51:22 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 02:51:16 +0900 From: Norikatsu Shigemura To: rnoland@FreeBSD.org Message-Id: <20100912025116.0e1fcc96.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: freebsd-current@FreeBSD.org, nork@FreeBSD.org Subject: Intel HD Graphics support ready? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 17:51:23 -0000 Hi rnoland. Do you have any schedule to support Intel HD Graphics on Core i series like Clarkdale/Arrandle? I'm waiting for your patch:-). Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 18:48: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 5A751106566C; Sat, 11 Sep 2010 18:48:10 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 318758FC1A; Sat, 11 Sep 2010 18:48:09 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-38-142.dsl.snfc21.pacbell.net [71.139.38.142]) by mail.root.org (Postfix) with ESMTP id BC53B5251; Sat, 11 Sep 2010 18:30:37 +0000 (UTC) Message-ID: <4C8BCAC5.5050008@root.org> Date: Sat, 11 Sep 2010 11:30:29 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Norikatsu Shigemura References: <20100912014855.984a89ed.nork@FreeBSD.org> In-Reply-To: <20100912014855.984a89ed.nork@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 18:48:10 -0000 Norikatsu Shigemura wrote: > Hi ACPI specialists! > > I noticed that CPU cooling doesn't work with testing mav@'s > timers_oneshot*.patch, so I got following results: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% last 24us > dev.cpu.1.cx_supported: C1/3 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% last 485us > dev.cpu.2.cx_supported: C1/3 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% last 155us > dev.cpu.3.cx_supported: C1/3 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% last 590us I think the problem is here. > cpu0: on acpi0 > PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 > ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) > ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) > PROCESSOR-0696 [241753] cpu_cx_cst : acpi_cpu0: C2[1] not available. > PROCESSOR-0730 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency > cpu1: on acpi0 > PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 > ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) > ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) > PROCESSOR-0696 [254000] cpu_cx_cst : acpi_cpu1: C2[1] not available. > PROCESSOR-0730 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency > cpu2: on acpi0 > PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 > PROCESSOR-0696 [255657] cpu_cx_cst : acpi_cpu2: C2[1] not available. > PROCESSOR-0730 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency > cpu3: on acpi0 > PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 > PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. > PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency I think the issue is that C2 is not available for some reason and thus C3 can't be used either. The way to tell is to use acpidump and look for the CPU objects' _CST fields. -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:32: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 14C9B10656F1 for ; Sat, 11 Sep 2010 21:32:32 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D3D458FC0A for ; Sat, 11 Sep 2010 21:32:31 +0000 (UTC) Received: from [10.123.2.180] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o8BLAsGI010580 for ; Sat, 11 Sep 2010 21:10:55 GMT (envelope-from tim@kientzle.com) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Sep 2010 14:10:54 -0700 Message-Id: <217AB0A7-0F3E-42EB-8019-9EFCDCBBBB56@kientzle.com> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 21:32:32 -0000 I just tried adding nfsv4_server_enable=3D"YES" to my rc.conf and found that after I rebooted the server, my FreeBSD 8 = client (still using NFSv3) couldn't connect because there was no RPC = mapping for nfs. Removing the option above and rebooting the server makes it work again. Server is GENERIC 9-CURRENT r211027 Client is GENERIC 8-STABLE r211321 From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:51: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 3F614106564A; Sat, 11 Sep 2010 21:51:12 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id F02A18FC15; Sat, 11 Sep 2010 21:51:11 +0000 (UTC) Received: by pxi17 with SMTP id 17so1796374pxi.13 for ; Sat, 11 Sep 2010 14:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=WEi8dlJtd+blcGGy+spjG7ZiR6KWsWKTNGHO0Mp9B4s=; b=dCu6zS07Wdido3JiLewrqJBaXTw3x14ny2MiUGB9OUGwXaSDKQCHsLT4Ztvh/3QG2I Qz1wcxixMjgHo+PgXvymGX/AoqSermZEBNrVY/W5FbYKnihuS8EwYVS4G9nD/2CEsmNA wFoKef1DQLfqQAq72Kq1+0vFfmZ1wnrP1rSQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=hCs7hmupk2LLNkpyKONP6cmUme+0hkNmhkIkMEWHMaZabql7aFMlKZVO7vrkqgx24I cukg+od/X3UoYkxS2e/hb+1oB2cyHv9yMTXF21CtKfLn7jK7tERW2XwZKTuzRDbJFjtQ 5npJI+jF8SuSua8B5tmIK3GGPICB53qgEmiTY= Received: by 10.142.248.12 with SMTP id v12mr1365750wfh.105.1284241871378; Sat, 11 Sep 2010 14:51:11 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 9sm5593714wfd.0.2010.09.11.14.51.09 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Sep 2010 14:51:09 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 11 Sep 2010 14:51:19 -0700 From: Weongyo Jeong Date: Sat, 11 Sep 2010 14:51:19 -0700 To: John Baldwin Message-ID: <20100911215119.GJ1328@weongyo> Mail-Followup-To: John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org References: <20100908201419.GF1328@weongyo> <201009091432.52066.jhb@freebsd.org> <20100910202858.GI1328@weongyo> <201009101717.39508.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009101717.39508.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, Weongyo Jeong Subject: Re: about in_multi_mtx @ netinet/in_mcast.c:1095 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong 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 Sep 2010 21:51:12 -0000 On Fri, Sep 10, 2010 at 05:17:39PM -0400, John Baldwin wrote: > On Friday, September 10, 2010 4:28:58 pm Weongyo Jeong wrote: > > On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > > > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > > > Hello, > > > > > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > > > when it's initialized so I always encounters the following LOR > > > > > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > > > 1st 0xffffffff80d0b560 in_multi_mtx (in_multi_mtx) @ > > > > > netinet/in_mcast.c:1095 > > > > > > 2nd 0xffffff00014e3850 USB device SX lock (USB device SX lock) @ > > > > > > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > _witness_debugger() at _witness_debugger+0x2e > > > > > > witness_checkorder() at witness_checkorder+0x807 > > > > > > _sx_xlock() at _sx_xlock+0x55 > > > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > > > axe_cmd() at axe_cmd+0xc7 > > > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > > > axe_setmulti() at axe_setmulti+0x3e > > > > > > axe_ioctl() at axe_ioctl+0x132 > > > > > > if_addmulti() at if_addmulti+0x19b > > > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > > > in_joingroup() at in_joingroup+0x52 > > > > > > in_control() at in_control+0x1144 > > > > > > ifioctl() at ifioctl+0x1118 > > > > > > kern_ioctl() at kern_ioctl+0xbe > > > > > > ioctl() at ioctl+0xfd > > > > > > syscallenter() at syscallenter+0x1aa > > > > > > syscall() at syscall+0x4c > > > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > > > > > case SIOCADDMULTI: > > > > > > case SIOCDELMULTI: > > > > > > axe_setmulti(sc, 0); > > > > > > break; > > > > > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > > > > > My question is that is it safe if the multicasting operations for > USB > > > > > > device happens without IN_MULTI_LOCK? Or is there any race cases if > the > > > > > > task is deferred? > > > > > > > > > > Why is USB using an sx lock instead of a mutex? > > > > > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > > > of things I'd like to change it. > > > > > > > > Just looking the comment at usb_request.c@441: > > > > > > > > /* > > > > * Grab the default sx-lock so that serialisation > > > > * is achieved when multiple threads are involved: > > > > */ > > > > sx_xlock(&udev->ctrl_sx); > > > > > > > > I think he might want to hold the lock even if the thread is going into > > > > sleep. It might be for serialization. > > > > > > > > However even if we succeed to change the lock from sx to mutex, it's > > > > hard to avoid the requests going into the sleep. It means USB stack > > > > should call like below: > > > > > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > > > > > to avoid the kernel's complain (would be `sleep with holding > > > > non-sleepable lock'). > > > > > > > > What I'd like to say is that the sleeping is big problem if mutex is > > > > used that it'd be worse when multiple mutex locks are used. > > > > > > > > So I'm looking for a fundamental solution to solve this problem. > > > > Welcomes any ideas. > > > > > > It is probably fine to just schedule a task to do the actual work of > > > axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in > > > your task handler as long as your handler holds the appropriate lock > > > (if_maddr_rlock() IIRC) when walking the interface's multicast address > list. > > > > OK. I'll try to use a task handler for this case. > > > > One thing, just for curious. Why the lower layer (in this case it might > > be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? > > If it calls ioctl without holding the lock, all drivers (specially all > > USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to > > implement their own taskqueue or process context. > > > > It looks to me that calling ioctl interface with holding IN_MULTI_LOCK > > is useless if the drivers hold if_maddr_rlock(ifp) lock properly though > > I could miss something important. > > It would introduce races in the multicast code to drop the lock around the > ioctl which would complicate it a good bit. Non-USB ethernet drivers just use > plain locks which handle this situation just fine. OK I see. Thank you for explanation. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23:14:11 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 ESMTP id 0E584106566C; Sat, 11 Sep 2010 23:14:10 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 08:14:09 +0900 From: Norikatsu Shigemura To: Nate Lawson Message-Id: <20100912081409.9f4d74d0.nork@FreeBSD.org> In-Reply-To: <4C8BCAC5.5050008@root.org> References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.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: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:14:12 -0000 Hi nate. On Sat, 11 Sep 2010 11:30:29 -0700 Nate Lawson wrote: > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. I attached acpidump -dt (nork-CFR9.asl.bz2) on previous mail, and I couldn't find _CST, too. And I added more ACPI debug option, ACPI_DB_INFO. I got following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - cpu0: on acpi0 PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) PROCESSOR-0696 [241753] cpu_cx_cst : acpi_cpu0: C2[1] not available. PROCESSOR-0730 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency cpu1: on acpi0 PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) PROCESSOR-0696 [254000] cpu_cx_cst : acpi_cpu1: C2[1] not available. PROCESSOR-0730 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency cpu2: on acpi0 PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 PROCESSOR-0696 [255657] cpu_cx_cst : acpi_cpu2: C2[1] not available. PROCESSOR-0730 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency cpu3: on acpi0 PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - According to acpidump -dt, I could find CPU0CST table, but not found _CST. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Scope (\) { Name (SSDT, Package (0x0C) { : "CPU0CST ", 0xDA9AB618, 0x000005CD, : }) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hum... ACPI CA 20100806 has a bug? Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23:20:02 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 CA4471065698 for ; Sat, 11 Sep 2010 23:20:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8127B8FC0C for ; Sat, 11 Sep 2010 23:20:02 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAAari0yDaFvO/2dsb2JhbACDGJ8hrTORIIEigyd0BIog X-IronPort-AV: E=Sophos;i="4.56,353,1280721600"; d="scan'208";a="91549240" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Sep 2010 19:20:01 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 927B8B3F36; Sat, 11 Sep 2010 19:20:01 -0400 (EDT) Date: Sat, 11 Sep 2010 19:20:01 -0400 (EDT) From: Rick Macklem To: Tim Kientzle Message-ID: <579405651.776013.1284247201493.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <217AB0A7-0F3E-42EB-8019-9EFCDCBBBB56@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Sep 2010 23:20:02 -0000 > I just tried adding > > nfsv4_server_enable="YES" > > to my rc.conf and found that after I rebooted the server, my FreeBSD 8 > client (still using NFSv3) couldn't connect because there was no RPC > mapping for nfs. > > Did you specify both of these in rc.conf? nfs_server_enable="YES" nfsv4_server_enable="YES" You need to specify both of them (and nfsuserd="YES" if you going to use NFSv4). See "man nfsv4" for more. If you did specify both, then do a "ps axHl" to see what didn't start up. There should be: rpcbind mountd nfsd and for NFSv4 to work nfsuserd You can also look in /var/log/messages to see if any of the daemons are complaining about something. rick