From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 04:33:15 2012 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 230CD1065670; Sun, 24 Jun 2012 04:33:15 +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 DFB698FC08; Sun, 24 Jun 2012 04:33:14 +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 q5O4X8WA080037; Sat, 23 Jun 2012 22:33:08 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q5O4X8Wq080036; Sat, 23 Jun 2012 22:33:08 -0600 (MDT) (envelope-from ken) Date: Sat, 23 Jun 2012 22:33:08 -0600 From: "Kenneth D. Merry" To: Alexander Motin Message-ID: <20120624043308.GA78807@nargothrond.kdm.org> References: <4FE4A239.5030000@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE4A239.5030000@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: FreeBSD current Subject: Re: minor GEOM disk API change coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jun 2012 04:33:15 -0000 On Fri, Jun 22, 2012 at 19:50:01 +0300, Alexander Motin wrote: > Hi. > > I understand problem you are going to fix and I think your patch should > do it. What I don't very like is addition of new GEOM method. Now GEOM > doesn't need it because all internal open/close operations and provider > destructions there protected by the topology SX lock. Unluckily that > lock doesn't cover g_wither_provider(), called by disk_gone() while > holding CAM SIM lock. If not that SIM lock, it would be enough to just > grab and drop GEOM topology lock to ensure that no new open() calls will > follow. Indirect way to do it could be to post GEOM event that would > drop the reference as soon as it will be handled and can obtain the > topology lock. Unluckily it uses malloc() for event storage and also can > be unreliable if called from under the SIM mutex lock. So it seems many > things would be much easier if it was possible to drop SIM lock inside > periph invalidate method, but now it is unsafe > > That is not an objection, just some thoughts about. Yeah, there are things in CAM (and GEOM) that need to be cleaned up. I wouldn't have added a GEOM method if there were a reasonable way around it, but as you pointed out, there isn't right now. I committed the patch, and plan to merge it to stable/9. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 04:52:38 2012 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 E4E7A1065672; Sun, 24 Jun 2012 04:52:37 +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 830E08FC14; Sun, 24 Jun 2012 04:52:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O4qV6I053004; Sun, 24 Jun 2012 00:52:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O4qVVX053003; Sun, 24 Jun 2012 04:52:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 04:52:31 GMT Message-Id: <201206240452.q5O4qVVX053003@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, 24 Jun 2012 04:52:38 -0000 TB --- 2012-06-24 04:51:29 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 04:51:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 04:51:29 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-06-24 04:51:29 - cleaning the object tree TB --- 2012-06-24 04:51:29 - cvsupping the source tree TB --- 2012-06-24 04:51:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-06-24 04:52:06 - building world TB --- 2012-06-24 04:52:06 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 04:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 04:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 04:52:06 - SRCCONF=/dev/null TB --- 2012-06-24 04:52:06 - TARGET=sparc64 TB --- 2012-06-24 04:52:06 - TARGET_ARCH=sparc64 TB --- 2012-06-24 04:52:06 - TZ=UTC TB --- 2012-06-24 04:52:06 - __MAKE_CONF=/dev/null TB --- 2012-06-24 04:52:06 - cd /src TB --- 2012-06-24 04:52:06 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 04:52:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 04:52:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 04:52:31 - ERROR: failed to build world TB --- 2012-06-24 04:52:31 - 11.95 user 4.70 system 61.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:21:20 2012 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 EC235106567C; Sun, 24 Jun 2012 07:21: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 8A12A8FC0C; Sun, 24 Jun 2012 07:21:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7LJoK095264; Sun, 24 Jun 2012 03:21:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7LJCf095263; Sun, 24 Jun 2012 07:21:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:21:19 GMT Message-Id: <201206240721.q5O7LJCf095263@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, 24 Jun 2012 07:21:21 -0000 TB --- 2012-06-24 07:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-24 07:20:00 - cleaning the object tree TB --- 2012-06-24 07:20:00 - cvsupping the source tree TB --- 2012-06-24 07:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-24 07:20:59 - building world TB --- 2012-06-24 07:20:59 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:20:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:20:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:20:59 - SRCCONF=/dev/null TB --- 2012-06-24 07:20:59 - TARGET=arm TB --- 2012-06-24 07:20:59 - TARGET_ARCH=arm TB --- 2012-06-24 07:20:59 - TZ=UTC TB --- 2012-06-24 07:20:59 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:20:59 - cd /src TB --- 2012-06-24 07:20:59 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:21:00 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/arm.arm/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:21:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:21:19 - ERROR: failed to build world TB --- 2012-06-24 07:21:19 - 10.95 user 4.48 system 78.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:21:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A76031065782; Sun, 24 Jun 2012 07:21:56 +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 4E6888FC08; Sun, 24 Jun 2012 07:21:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7LtDb096398; Sun, 24 Jun 2012 03:21:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7LtOo096397; Sun, 24 Jun 2012 07:21:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:21:55 GMT Message-Id: <201206240721.q5O7LtOo096397@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, 24 Jun 2012 07:21:56 -0000 TB --- 2012-06-24 07:21:19 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:21:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:21:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-06-24 07:21:19 - cleaning the object tree TB --- 2012-06-24 07:21:19 - cvsupping the source tree TB --- 2012-06-24 07:21:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-06-24 07:21:40 - building world TB --- 2012-06-24 07:21:40 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:21:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:21:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:21:40 - SRCCONF=/dev/null TB --- 2012-06-24 07:21:40 - TARGET=ia64 TB --- 2012-06-24 07:21:40 - TARGET_ARCH=ia64 TB --- 2012-06-24 07:21:40 - TZ=UTC TB --- 2012-06-24 07:21:40 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:21:40 - cd /src TB --- 2012-06-24 07:21:40 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:21:41 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:21:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:21:55 - ERROR: failed to build world TB --- 2012-06-24 07:21:55 - 11.05 user 4.23 system 36.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:22:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0569F1065672; Sun, 24 Jun 2012 07:22: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 9CD5F8FC17; Sun, 24 Jun 2012 07:22:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7MZab097389; Sun, 24 Jun 2012 03:22:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7MZ6U097388; Sun, 24 Jun 2012 07:22:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:22:35 GMT Message-Id: <201206240722.q5O7MZ6U097388@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, 24 Jun 2012 07:22:36 -0000 TB --- 2012-06-24 07:21:55 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:21:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:21:55 - starting HEAD tinderbox run for mips/mips TB --- 2012-06-24 07:21:55 - cleaning the object tree TB --- 2012-06-24 07:21:55 - cvsupping the source tree TB --- 2012-06-24 07:21:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-06-24 07:22:20 - building world TB --- 2012-06-24 07:22:20 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:22:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:22:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:22:20 - SRCCONF=/dev/null TB --- 2012-06-24 07:22:20 - TARGET=mips TB --- 2012-06-24 07:22:20 - TARGET_ARCH=mips TB --- 2012-06-24 07:22:20 - TZ=UTC TB --- 2012-06-24 07:22:20 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:22:20 - cd /src TB --- 2012-06-24 07:22:20 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:22:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/mips.mips/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:22:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:22:35 - ERROR: failed to build world TB --- 2012-06-24 07:22:35 - 11.27 user 3.91 system 39.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:26:20 2012 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 50C80106566B; Sun, 24 Jun 2012 07:26: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 E3F448FC12; Sun, 24 Jun 2012 07:26:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7QJ19010649; Sun, 24 Jun 2012 03:26:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7QJvF010639; Sun, 24 Jun 2012 07:26:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:26:19 GMT Message-Id: <201206240726.q5O7QJvF010639@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, 24 Jun 2012 07:26:20 -0000 TB --- 2012-06-24 07:22:35 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:22:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:22:35 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-06-24 07:22:35 - cleaning the object tree TB --- 2012-06-24 07:22:35 - cvsupping the source tree TB --- 2012-06-24 07:22:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-06-24 07:22:54 - building world TB --- 2012-06-24 07:22:54 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:22:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:22:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:22:54 - SRCCONF=/dev/null TB --- 2012-06-24 07:22:54 - TARGET=powerpc TB --- 2012-06-24 07:22:54 - TARGET_ARCH=powerpc TB --- 2012-06-24 07:22:54 - TZ=UTC TB --- 2012-06-24 07:22:54 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:22:54 - cd /src TB --- 2012-06-24 07:22:54 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:22:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/powerpc.powerpc/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/powerpc.powerpc/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:26:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:26:19 - ERROR: failed to build world TB --- 2012-06-24 07:26:19 - 156.59 user 16.24 system 223.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:31:47 2012 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 4FE4F1065676; Sun, 24 Jun 2012 07:31: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 EA2608FC16; Sun, 24 Jun 2012 07:31:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7VkKa028772; Sun, 24 Jun 2012 03:31:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7VkkP028767; Sun, 24 Jun 2012 07:31:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:31:46 GMT Message-Id: <201206240731.q5O7VkkP028767@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, 24 Jun 2012 07:31:47 -0000 TB --- 2012-06-24 07:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-06-24 07:20:00 - cleaning the object tree TB --- 2012-06-24 07:20:00 - cvsupping the source tree TB --- 2012-06-24 07:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-06-24 07:28:21 - building world TB --- 2012-06-24 07:28:21 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:28:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:28:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:28:21 - SRCCONF=/dev/null TB --- 2012-06-24 07:28:21 - TARGET=i386 TB --- 2012-06-24 07:28:21 - TARGET_ARCH=i386 TB --- 2012-06-24 07:28:21 - TZ=UTC TB --- 2012-06-24 07:28:21 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:28:21 - cd /src TB --- 2012-06-24 07:28:21 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:28:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/i386.i386/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/i386.i386/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:31:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:31:46 - ERROR: failed to build world TB --- 2012-06-24 07:31:46 - 161.84 user 18.63 system 706.03 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:31:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E208210656E1; Sun, 24 Jun 2012 07:31:55 +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 809318FC1D; Sun, 24 Jun 2012 07:31:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7Vsm5029208; Sun, 24 Jun 2012 03:31:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7Vsct029207; Sun, 24 Jun 2012 07:31:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:31:54 GMT Message-Id: <201206240731.q5O7Vsct029207@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, 24 Jun 2012 07:31:56 -0000 TB --- 2012-06-24 07:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-06-24 07:20:00 - cleaning the object tree TB --- 2012-06-24 07:20:00 - cvsupping the source tree TB --- 2012-06-24 07:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-06-24 07:28:28 - building world TB --- 2012-06-24 07:28:28 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:28:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:28:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:28:28 - SRCCONF=/dev/null TB --- 2012-06-24 07:28:28 - TARGET=pc98 TB --- 2012-06-24 07:28:28 - TARGET_ARCH=i386 TB --- 2012-06-24 07:28:28 - TZ=UTC TB --- 2012-06-24 07:28:28 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:28:28 - cd /src TB --- 2012-06-24 07:28:28 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:28:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/pc98.i386/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/pc98.i386/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:31:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:31:54 - ERROR: failed to build world TB --- 2012-06-24 07:31:54 - 162.19 user 18.50 system 714.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:31:59 2012 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 0A3D610656B4; Sun, 24 Jun 2012 07:31: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 A26BB8FC1E; Sun, 24 Jun 2012 07:31:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7VwCC029336; Sun, 24 Jun 2012 03:31:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7Vwxp029335; Sun, 24 Jun 2012 07:31:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:31:58 GMT Message-Id: <201206240731.q5O7Vwxp029335@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, 24 Jun 2012 07:31:59 -0000 TB --- 2012-06-24 07:26:19 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:26:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:26:19 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-06-24 07:26:19 - cleaning the object tree TB --- 2012-06-24 07:26:19 - cvsupping the source tree TB --- 2012-06-24 07:26:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-06-24 07:28:31 - building world TB --- 2012-06-24 07:28:31 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:28:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:28:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:28:31 - SRCCONF=/dev/null TB --- 2012-06-24 07:28:31 - TARGET=powerpc TB --- 2012-06-24 07:28:31 - TARGET_ARCH=powerpc64 TB --- 2012-06-24 07:28:31 - TZ=UTC TB --- 2012-06-24 07:28:31 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:28:31 - cd /src TB --- 2012-06-24 07:28:31 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:28:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/powerpc.powerpc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/powerpc.powerpc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:31:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:31:58 - ERROR: failed to build world TB --- 2012-06-24 07:31:58 - 161.68 user 19.07 system 338.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 07:32:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B93EC106568E; Sun, 24 Jun 2012 07:32:44 +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 5F1D68FC0C; Sun, 24 Jun 2012 07:32:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5O7WhdM030525; Sun, 24 Jun 2012 03:32:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5O7WhfF030524; Sun, 24 Jun 2012 07:32:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Jun 2012 07:32:43 GMT Message-Id: <201206240732.q5O7WhfF030524@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, 24 Jun 2012 07:32:44 -0000 TB --- 2012-06-24 07:31:46 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-24 07:31:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-24 07:31:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-06-24 07:31:46 - cleaning the object tree TB --- 2012-06-24 07:31:59 - cvsupping the source tree TB --- 2012-06-24 07:31:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-06-24 07:32:27 - building world TB --- 2012-06-24 07:32:27 - CROSS_BUILD_TESTING=YES TB --- 2012-06-24 07:32:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-24 07:32:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-24 07:32:27 - SRCCONF=/dev/null TB --- 2012-06-24 07:32:27 - TARGET=sparc64 TB --- 2012-06-24 07:32:27 - TARGET_ARCH=sparc64 TB --- 2012-06-24 07:32:27 - TZ=UTC TB --- 2012-06-24 07:32:27 - __MAKE_CONF=/dev/null TB --- 2012-06-24 07:32:27 - cd /src TB --- 2012-06-24 07:32:27 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 24 07:32:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_cntl.c -o elf_cntl.o cc -O2 -pipe -I/src/lib/libelf -I/src/lib/libelf/../../sys -DLIBELF_TEST_HOOKS -std=gnu99 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/lib/libelf/elf_end.c -o elf_end.o In file included from /src/lib/libelf/elf_end.c:34: /usr/include/stdlib.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wchar_t' /usr/include/stdlib.h:99: error: expected ')' before '*' token /usr/include/stdlib.h:100: error: expected ')' before '*' token /usr/include/stdlib.h:114: error: expected declaration specifiers or '...' before 'wchar_t' /usr/include/stdlib.h:115: error: expected ';', ',' or ')' before '*' token *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-24 07:32:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-24 07:32:43 - ERROR: failed to build world TB --- 2012-06-24 07:32:43 - 11.07 user 4.37 system 57.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 18:02:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C8A01065678 for ; Sun, 24 Jun 2012 18:02:14 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3638FC1D for ; Sun, 24 Jun 2012 18:02:14 +0000 (UTC) Received: from [78.35.156.10] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Sir7x-0003uB-W5 for freebsd-current@freebsd.org; Sun, 24 Jun 2012 20:01:38 +0200 Date: Sun, 24 Jun 2012 19:59:51 +0200 From: Fabian Keil Cc: freebsd-current@freebsd.org Message-ID: <20120624195951.25f3e5f5@fabiankeil.de> In-Reply-To: <20110820230510.4363cefc@fabiankeil.de> References: <20110820230510.4363cefc@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/zodQKKVJ9MSr8yi=/JT9SpM"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: dtrace walltimestamp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jun 2012 18:02:14 -0000 --Sig_/zodQKKVJ9MSr8yi=/JT9SpM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > At least on my system, timestamp offsets can only can be relied > on with either kern.timecounter.hardware=3DTSC or with C3 > states disabled, though. >=20 > Measuring the elapsed time (in ms) between events that happen > in roughly 1 second intervals with kern.timecounter.hardware=3DHPET > and dev.cpu.0.cx_lowest=3DC2: >=20 > elapsed > value ------------- Distribution ------------- count > 990 | 0 > 1000 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 57 > 1010 | 0 > 1020 | 0 > 1030 |@ 1 > 1040 | 0 >=20 > elapsed avg 1007 >=20 > And doing the same with dev.cpu.0.cx_lowest=3DC3: >=20 > elapsed > value ------------- Distribution ------------- count > 40 | 0 > 50 |@@@@@@@@@@@@@@@@@@@ 28 > 60 |@@@@@@@ 10 > 70 |@@@ 5 > 80 |@ 1 > 90 | 0 > 100 |@ 2 > 110 |@ 2 > 120 |@ 2 > 130 | 0 > 140 |@ 1 > 150 |@ 1 > 160 |@ 1 > 170 |@ 1 > 180 | 0 > 190 | 0 > 200 | 0 > 210 | 0 > 220 |@ 1 > 230 |@ 1 > 240 | 0 > 250 | 0 > 260 | 0 > 270 | 0 > 280 | 0 > 290 |@ 1 > 300 |@ 1 > 310 | 0 > 320 |@ 1 > 330 | 0 >=20 > elapsed avg 90 Copying over some code from mips seems to fix this: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Damd64/169379 Fabian --Sig_/zodQKKVJ9MSr8yi=/JT9SpM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/nVZwACgkQBYqIVf93VJ38+gCfUugCgXyuI4PtlVsodqZITO6t MYkAnRHEjbdw+DGE7D+H5jRkq9bSYCRd =3m5i -----END PGP SIGNATURE----- --Sig_/zodQKKVJ9MSr8yi=/JT9SpM-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 23:06:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5835B106566B for ; Sun, 24 Jun 2012 23:06:54 +0000 (UTC) (envelope-from prvs=1522171aa5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DAF558FC1A for ; Sun, 24 Jun 2012 23:06:53 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 25 Jun 2012 00:06:37 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020454234.msg for ; Mon, 25 Jun 2012 00:06:35 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1522171aa5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <1D329163D5A14F42A0D30EF1FB481979@multiplay.co.uk> From: "Steven Hartland" To: Date: Mon, 25 Jun 2012 00:07:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: mountd starts to early when exporting fs marked as late (patch included) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jun 2012 23:06:54 -0000 We added some new mount points recently and on reboot they failed to come up after investigating we found that mountd runs too early in the boot process to be able export filesystems that are marked as late in /etc/fstab. Our fix was simply to mark mountd as requiring mountlate and all was well. I can't think of any reason why this would cause problems so would like the patch to be considered. The PR has all the details and the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=169373 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sun Jun 24 23:20:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B0D191065670 for ; Sun, 24 Jun 2012 23:20:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BF390152F93; Sun, 24 Jun 2012 23:20:16 +0000 (UTC) Message-ID: <4FE7A0B0.4000703@FreeBSD.org> Date: Sun, 24 Jun 2012 16:20:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steven Hartland References: <1D329163D5A14F42A0D30EF1FB481979@multiplay.co.uk> In-Reply-To: <1D329163D5A14F42A0D30EF1FB481979@multiplay.co.uk> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: mountd starts to early when exporting fs marked as late (patch included) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jun 2012 23:20:19 -0000 On 06/24/2012 16:07, Steven Hartland wrote: > We added some new mount points recently and on reboot they failed to > come up after investigating we found that mountd runs too early in > the boot process to be able export filesystems that are marked as > late in /etc/fstab. > > Our fix was simply to mark mountd as requiring mountlate and all > was well. I can't think of any reason why this would cause problems > so would like the patch to be considered. > > The PR has all the details and the patch. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=169373 I re-routed that PR to freebsd-rc@. -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 00:14:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19CB2106568A; Mon, 25 Jun 2012 00:14:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id BC3188FC20; Mon, 25 Jun 2012 00:14:42 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B5CCCE655A; Mon, 25 Jun 2012 01:15:47 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=UYEHX/+7gehl hSq/5UyjCEFP5I8=; b=GcdwbewrKfMi25btFFxAFSC5+WxVFfbjEL5EU1jz+eIc EQCc8qr/oRREl/7PENGDgi+r4oafl/aiG7aMHJacFIB5PAoKAfPmyuGwEt0Xppvn lRl3Wpw4T7+6uvsW41Yjrf3yW1lgCPxaO9K0AJQf1Aj11q6CFykNF/T+e1Kb3Kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=IBwWSK 6Xm3XoTnJczk3JOeFxZdojmiaaULoOZegcA67yNCFgM7ec4p1HD2WKfh6T7oBpJp sov5m+3ueq7GomOYwvWSI3nSjyqB3NP9PbBMuQsUTXgsNYjCW9fBy5VDIZ0Hl8Dk 3mQDOu9HTpuC0ldPc1EBexdgL9klf/Aug8aUQ= Received: from [192.168.2.12] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 74EA2E64EF; Mon, 25 Jun 2012 01:15:47 +0100 (BST) Message-ID: <4FE7AD6E.7000301@cran.org.uk> Date: Mon, 25 Jun 2012 01:14:38 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> In-Reply-To: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron@FreeBSD.ORG, bapt@freebsd.org, freebsd-current@freebsd.org, McDowell , Nathan Whitehorn Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jun 2012 00:14:46 -0000 On 21/06/2012 00:40, Devin Teske wrote: > If you have the time and/or energy, please test and report any issues that you experience. I've noticed a few typos and other minor issues: In bsdconfig(8): Contains a link to itself under SEE ALSO. "bsdconfig takes a commands as an argument" - should be "command". bsdconfig mouse: Typo "se Configuration menu". "Please Specify the mouse daemon flags" - don't need upper-case S. bsdconfig hostname: The example should probably be in the example.com domain. bsdconfig netdev: "Select a TCP/IP network interface to configure" doesn't need "TCP/IP". bsdconfig nameservers: "Please enter the new TCP/IP address of the DNS nameserver" should just be "IP address". "TCP/IP" is being used where just "IP" was needed in other places too. 'bsdconfig command -h' doesn't always work: > bsdconfig hostname -h Illegal option -h -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 02:03:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F8451065677; Mon, 25 Jun 2012 02:03:36 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 177AD8FC08; Mon, 25 Jun 2012 02:03:35 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5P23R8V003769; Mon, 25 Jun 2012 10:03:27 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340589808.2192.1.camel@nsl> From: Kevin Lo To: freebsd-current , freebsd-fs@freebsd.org Date: Mon, 25 Jun 2012 10:03:28 +0800 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: Subject: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 02:03:36 -0000 I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Kevin From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 02:19:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4067D1065674; Mon, 25 Jun 2012 02:19:16 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id C31E08FC0A; Mon, 25 Jun 2012 02:19:15 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.5/8.14.5) with ESMTP id q5P2IcUr001543 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Sun, 24 Jun 2012 19:18:39 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201206250218.q5P2IcUr001543@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Jun 2012 19:18:32 -0700 To: mjacob@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: q5P2IcUr001543 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org Subject: isp Tape Drive no longer detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jun 2012 02:19:16 -0000 As of today my tape drive is no longer detected. I think the isp driver does not load dmesg: firmware: 'isp_1040' version 1: 22944 bytes loaded at 0xc0a20d60 ispfw: registered firmware firmware: 'isp_1040_it' version 1: 32942 bytes loaded at 0xc0a26700 ispfw: registered firmware firmware: 'isp_1080' version 1: 31350 bytes loaded at 0xc0a2e7c0 ispfw: registered firmware firmware: 'isp_1080_it' version 1: 40644 bytes loaded at 0xc0a36240 ispfw: registered firmware firmware: 'isp_12160' version 1: 28050 bytes loaded at 0xc0a40120 ispfw: registered firmware firmware: 'isp_12160_it' version 1: 40604 bytes loaded at 0xc0a46ec0 ispfw: registered firmware firmware: 'isp_2100' version 1: 76770 bytes loaded at 0xc0a50d60 ispfw: registered firmware firmware: 'isp_2200' version 1: 77214 bytes loaded at 0xc0a63960 ispfw: registered firmware firmware: 'isp_2300' version 1: 106640 bytes loaded at 0xc0a76700 ispfw: registered firmware firmware: 'isp_2322' version 1: 120466 bytes loaded at 0xc0a907a0 ispfw: registered firmware firmware: 'isp_2400' version 1: 179908 bytes loaded at 0xc0ab19a0 ispfw: registered firmware firmware: 'isp_2400_multi' version 1: 198628 bytes loaded at 0xc0aea800 ispfw: registered firmware firmware: 'isp_2500' version 1: 142704 bytes loaded at 0xc0b28ae0 ispfw: registered firmware firmware: 'isp_2500_multi' version 1: 169352 bytes loaded at 0xc0b5a9e0 ispfw: registered firmware isp0: port 0x1000-0x10ff mem 0xfc514000-0xfc514fff irq 18 at device 9.0 on pci5 isp0: using Memory space register mapping isp0: loaded firmware isp_1080 isp0: bus 0 is in Single-Ended Mode isp0: Register Test Failed at Register 6: should have 0x7f7f but got 0x0000 device_attach: isp0 attach returned 6 The last time I used the tape was 6/15/2012. Any ideas ? Thanks Manfred ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 02:35:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23D7F1065676 for ; Mon, 25 Jun 2012 02:35: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 B570D8FC08 for ; Mon, 25 Jun 2012 02:35:24 +0000 (UTC) Received: from [192.168.135.100] (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q5P2VV7x097758 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 24 Jun 2012 19:31:32 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4FE7CD7E.4040506@feral.com> Date: Sun, 24 Jun 2012 19:31:26 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201206250218.q5P2IcUr001543@pozo.com> In-Reply-To: <201206250218.q5P2IcUr001543@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sun, 24 Jun 2012 19:31:32 -0700 (PDT) Subject: Re: isp Tape Drive no longer detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 02:35:25 -0000 On 6/24/2012 7:18 PM, Manfred Antar wrote: > As of today my tape drive is no longer detected. I think the isp driver does not load What? Somebody is using a tape drive still? And parallel SCSI? *gasp* Yes, sorry, my bad. Looks like my extending register tests for the 2400 has killed things for the 1040. Expect a change tonite sometime- apologies. From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 02:39:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88DB01065686 for ; Mon, 25 Jun 2012 02:39:39 +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 57E108FC12 for ; Mon, 25 Jun 2012 02:39:39 +0000 (UTC) Received: from [192.168.135.100] (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q5P2dcKN097955 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jun 2012 19:39:39 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4FE7CF66.6000502@feral.com> Date: Sun, 24 Jun 2012 19:39:34 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Manfred Antar , freebsd-current@freebsd.org References: <201206250218.q5P2IcUr001543@pozo.com> In-Reply-To: <201206250218.q5P2IcUr001543@pozo.com> Content-Type: multipart/mixed; boundary="------------070104040107010403090409" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sun, 24 Jun 2012 19:39:39 -0700 (PDT) Cc: Subject: Re: isp Tape Drive no longer detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matt Jacob List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 02:39:39 -0000 This is a multi-part message in MIME format. --------------070104040107010403090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Actually, can you try this patch please? I won't be able to get to my lab and get a working 1040 card into a system until tomorrow. --------------070104040107010403090409 Content-Type: text/plain; charset=windows-1252; name="isp.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="isp.c.patch" diff -r 5aba1b04ddd5 isp.c --- a/isp.c Sun Jun 24 10:22:10 2012 -0700 +++ b/isp.c Sun Jun 24 19:36:06 2012 -0700 @@ -710,8 +710,11 @@ 0x6666, 0x6677, 0x1122, 0x33ff, 0x0000, 0x0001, 0x1000, 0x1010, }; + int nmbox = ISP_NMBOX(isp); + if (IS_SCSI(isp)) + nmbox = 6; MBSINIT(&mbs, MBOX_MAILBOX_REG_TEST, MBLOGALL, 0); - for (i = 1; i < ISP_NMBOX(isp); i++) { + for (i = 1; i < nmbox; i++) { mbs.param[i] = patterns[i]; } isp_mboxcmd(isp, &mbs); @@ -719,7 +722,7 @@ ISP_RESET0(isp); return; } - for (i = 1; i < ISP_NMBOX(isp); i++) { + for (i = 1; i < nmbox; i++) { if (mbs.param[i] != patterns[i]) { ISP_RESET0(isp); isp_prt(isp, ISP_LOGERR, "Register Test Failed at Register %d: should have 0x%04x but got 0x%04x", i, patterns[i], mbs.param[i]); --------------070104040107010403090409-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 25 09:56:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC4461065675; Mon, 25 Jun 2012 09:56:17 +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 35F258FC0A; Mon, 25 Jun 2012 09:56:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5P9tohC030514; Mon, 25 Jun 2012 12:55:50 +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.5/8.14.5) with ESMTP id q5P9togc024592; Mon, 25 Jun 2012 12:55:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5P9tmme024591; Mon, 25 Jun 2012 12:55:48 +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: Mon, 25 Jun 2012 12:55:48 +0300 From: Konstantin Belousov To: Kevin Lo Message-ID: <20120625095548.GD2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T2hvUJ3zJitSqYsX" Content-Disposition: inline In-Reply-To: <1340589808.2192.1.camel@nsl> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 09:56:17 -0000 --T2hvUJ3zJitSqYsX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > I've observed a panic in recent -current several times but I only > have a picture of the backtrace: > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg >=20 > Does this look at all familiar to anyone? Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address in your kernel ? The screenshot looks strange. The instruction on which the kernel trapped is int 0x28 which should not appear in the compiled code. --T2hvUJ3zJitSqYsX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/oNaQACgkQC3+MBN1Mb4jEoACguhbK+poJaPgsHk5VU5r6i6TK lhoAoNJir2lbjmIPOWnbpLrD06ggtfKj =arSr -----END PGP SIGNATURE----- --T2hvUJ3zJitSqYsX-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 00:03:59 2012 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 6536A106566C; Tue, 26 Jun 2012 00:03:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBFE8FC15; Tue, 26 Jun 2012 00:03:55 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1348554wib.13 for ; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nsPADtjgVm4Fw31DHzhjPLpVSGWGUh6cMauzgwvGaak=; b=ZDOnXtVUzBKOtkSR/+2250cXvpR/TdL6OtZ3G0XoJc+9Y56g5mcI5sQbZbM+3gVxgu Nlz24O9zx8GL7Qy7pZggXlBz5vK+StgRg9f5xyGdGlpboA8Zw/Rm7Y687J5OR0FBVgRK 31O/NVVtq/f8ivhOwvon5+Zis6M2yCvSS8NUuFPg2kDm9aAvvVlJbyhCD9WY7VSxaBdb l5hpPmC2pa2e9nc7dtH6agxXpXYFn/gQsexiWQ4hdd7aTSgh2d2jMaKJ4HdGzl6sIaS+ KSGV5wteWgpS7x6CuJpUFpcDz3OX0z00O29zAmdvv009E7jVJRX3fynSTfmBGB4h6zAx PtTA== MIME-Version: 1.0 Received: by 10.216.196.166 with SMTP id r38mr6526517wen.161.1340669034277; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) Date: Mon, 25 Jun 2012 20:03:54 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: bp@FreeBSD.org, kby@FreeBSD.org Subject: sysctl 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, 26 Jun 2012 00:03:59 -0000 Hi folks, I find myself in a situation where I need to directly explore the sysctl(8) tree from my program. The tricky part is this: from `src/sbin/sysctl.c': /* * These functions uses a presently undocumented interface to the kernel * to walk the tree and get the type so it can print the value. * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. */ AFAIT, the whole interface used by sysctl(8) to explore the sysctl tree (ie. list, name, get description) is undocumented. This comment has been there for about, well... 17 years. No matter to say that it is highly unlikely anyone is ever gonna design that perfect interface. Right now, I am left with no choice but to figure out how that stuff work, which I foresee will be a real PITA. No choice ? Well, not so much. About 12 years ago a filesystem interface was written for sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris Popov. Unfortunately, time passed and no code is any longer publicly available. URLs are either no longer valid or password-protected. This interface would just be perfect for my use-case. No need to spend time decoding a prehistoric interface, no need to craft custom accessors. I would just have to use standard POSIX file interface... if the code was available. I was hoping some of the people on this list would either, have the scfs(4) code on their drives/tapes, or have a way to contact the original author(s) and thus have a chance to get that code ? Thanks in advance, - Arnaud ps: I know the code will certainly have to be fixed, but that is still the best option I've got so far. From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 00:13:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4E7F106566C; Tue, 26 Jun 2012 00:13:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 211B58FC2B; Tue, 26 Jun 2012 00:13:24 +0000 (UTC) Received: by obbun3 with SMTP id un3so9218258obb.13 for ; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HC4/mWNQSj8y7inIacE/Rtv6FSU3ix2/YnsbqqO5w4c=; b=e79oAgb3yXNLvwLvgrLvCfTTJE/qqv94Ji+ImorM+JLlY31t46mh7Q6g+PNsuWEzdD aeqJUFg8zdf+UqsYcl7dhqcpurhtXeiYMA+QFCTbrsWDk+TW3nJyPQOUI+QmnpHxdd47 RJcCJcC8lTG1vSSi4ZowzmaJ7SWcQu9W1XNiXxWS9KfCWWCXcUVTNaaeNRfUZ5KRfvfN uRJ9SOcoxtBe36qBa9fuESInq/OHb5zUX+tt8z/dOyheTT1EFLxm93kTpIh9IEdHKvAo v5e/sQ2VF5Uv8/BhHjTdJBEIYcOIamHlJZ/GjjtO+ofGGJaEVbXKElvWEEMyDwGbMJln BiUQ== MIME-Version: 1.0 Received: by 10.60.20.136 with SMTP id n8mr3891674oee.54.1340669603645; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) Received: by 10.76.95.194 with HTTP; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 17:13:23 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 00:13:27 -0000 On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > > from `src/sbin/sysctl.c': > /* > =A0* These functions uses a presently undocumented interface to the kerne= l > =A0* to walk the tree and get the type so it can print the value. > =A0* This interface is under work and consideration, and should probably > =A0* be killed with a big axe by the first person who can find the time. > =A0* (be aware though, that the proper interface isn't as obvious as it > =A0* may seem, there are various conflicting requirements. > =A0*/ > > AFAIT, the whole interface used by sysctl(8) to explore the sysctl > tree (ie. list, name, get description) is undocumented. This comment > has been there for about, well... 17 years. No matter to say that it > is highly unlikely anyone is ever gonna design that perfect interface. > Right now, I am left with no choice but to figure out how that stuff > work, which I foresee will be a real PITA. No choice ? Well, not so > much. About 12 years ago a filesystem interface was written for > sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris > Popov. Unfortunately, time passed and no code is any longer publicly > available. URLs are either no longer valid or password-protected. > > This interface would just be perfect for my use-case. No need to spend > time decoding a prehistoric interface, no need to craft custom > accessors. I would just have to use standard POSIX file interface... > if the code was available. > > I was hoping some of the people on this list would either, have the > scfs(4) code on their drives/tapes, or have a way to contact the > original author(s) and thus have a chance to get that code ? > > Thanks in advance, > =A0- Arnaud > > ps: I know the code will certainly have to be fixed, but that is still > the best option I've got so far. Alternatively, the interface could just be documented (from sys/kern/kern_sysctl.c): /* * "Staff-functions" * * These functions implement a presently undocumented interface * used by the sysctl program to walk the tree, and get the type * so it can print the value. * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. * * {0,0} printf the entire MIB-tree. * {0,1,...} return the name of the "..." OID. * {0,2,...} return the next OID. * {0,3} return the OID of the name in "new" * {0,4,...} return the kind & format info for the "..." OID. * {0,5,...} return the description the "..." OID. */ I know 2 closed-source versions that have wholesale stolen/"borrowed" the code from sysctl(3), and I adapted the sysctl(8) code for my own uses for the cython derivative I made here [1]. Thanks, -Garrett 1. http://sourceforge.net/projects/sysctl/ From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 00:30:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24CF0106564A; Tue, 26 Jun 2012 00:30:40 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 20F058FC17; Tue, 26 Jun 2012 00:30:38 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4456920wgb.31 for ; Mon, 25 Jun 2012 17:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CMjyb/C03tq4mutcOl7Z1kNGauwMRIJH2XKOKgdAEyw=; b=eYg72kLMxxNz22BVwOGKt3lVaNM585rSks1ApNRbc6TK/j4FBkSlWDR1yOkaqHBfCu OG7kSctGiL69WkEq2lyc0mq9M2Q7fpoAiebxNCcESETxeFshVDsO00sgurwVBkLlhoEq 6+j2BAA2SvgpAugPffmAZaz9oj5Di89mqrrayawigLqnJ6MUuALNwQWs5z5LdWTYSfa6 oxSceVM2i3eLqEvGVq1RncucyadNFeufd6DCh6lSSRi4LogfbtPgy7Itrd+PxkTaPQjM KIeDID0jRdZtwBMLKPoN0T5fh0FjkZk97uO3R9M8ZCfVOL8TVa0NH81hYBrIWW6LVSXs JQ/Q== MIME-Version: 1.0 Received: by 10.180.102.228 with SMTP id fr4mr28245560wib.6.1340670638150; Mon, 25 Jun 2012 17:30:38 -0700 (PDT) Received: by 10.223.88.155 with HTTP; Mon, 25 Jun 2012 17:30:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 19:30:37 -0500 Message-ID: From: Adam Vande More To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 00:30:40 -0000 On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > There is this: http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 00:56:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3E4A1065675; Tue, 26 Jun 2012 00:56:04 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id E41AF8FC1A; Tue, 26 Jun 2012 00:56:03 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1370161wib.13 for ; Mon, 25 Jun 2012 17:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QgeuBGUjLNwUDnuLxZBzvHrr4KThw7B1+6YkTULL5TY=; b=JwR8HOXZ58ng96LqGYQSJc6fJyngqGIMcEg/b/dbBYw5C/R63yFj7kQ3KP3f4cGVT8 BR5sTsvTSzz5aEi3C1fnOxqSnr/CvWDo/V8MtA3aDo/f7+Eevb8DH3nCUPJT9BgaKK0R QUi9AoTtQTTMd3ffUR35fGKnC/Ik0WE0OPU31aPKLoYORsrf6KgHnwcfrAlWOSDLZu+N HHGply7vjlM0nzbtfvAC1/ADEKtRetDxKQIk34gOxQe9VxFjNd6AfwPr0ey3HYiCLUI1 0Cn8tofNuPnEg3NhROyEfo1/CBNyXL9OgJQuahXNklzY8kZbNToYtcPBpV6/KZNne9hV iMKQ== MIME-Version: 1.0 Received: by 10.180.14.165 with SMTP id q5mr28307170wic.8.1340672163041; Mon, 25 Jun 2012 17:56:03 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 17:56:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 20:56:02 -0400 Message-ID: From: Arnaud Lacombe To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 00:56:04 -0000 Hi, On Mon, Jun 25, 2012 at 8:30 PM, Adam Vande More wrote: > On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: >> >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: > > There is this: > > http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ > yes, `kernfs' is mentioned in some of the thread about a sysctl filesystem as a potential code base, and has been used in such purpose. However, if I can avoid to re-design that wheel too, by getting access to scfs(4) code, I will. - Arnaud > -- > Adam Vande More From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 01:24:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8631106564A; Tue, 26 Jun 2012 01:24:28 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E4A6A8FC1A; Tue, 26 Jun 2012 01:24:27 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4481954wgb.31 for ; Mon, 25 Jun 2012 18:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RjX88LddFI9Y7cutb20kzrPYlzQ+zN19w6SaQdgeSao=; b=W0eIewdw4kIpZ2SQRLjvaRykIXPseKuw5GmZr7+KcDIwgOFyeCrnnbfRMql95B0TE5 M2A7XWRqU80uxVQwCCSpN3N4+IwqLpDwTFMn7A7bdjAOCyokqa7ml2za9LevNMSd7PSI NsmJqmYxSgJ6POsCGHyN0RH9Sjktqv6pAeT5YPGlJGWtFgRTPYeHnfFiBoOT3sF+4TVg yFffme1yTFFUR4gbHMEcTudibgoVFYIdf7Tr4zGJQwdsljs64JkzMddDm5yv/J4uDyl4 4cvIl11/yClvcXDa4926QMHPq1Q/eaE/i7UWxvNbM3AvfsLJBwy8+kBzbCb0KPk8hakX hdeA== MIME-Version: 1.0 Received: by 10.216.196.166 with SMTP id r38mr6612952wen.161.1340673866890; Mon, 25 Jun 2012 18:24:26 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 18:24:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 21:24:26 -0400 Message-ID: From: Arnaud Lacombe To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 01:24:29 -0000 On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper wrote: > On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrot= e: >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: >> >> from `src/sbin/sysctl.c': >> /* >> =A0* These functions uses a presently undocumented interface to the kern= el >> =A0* to walk the tree and get the type so it can print the value. >> =A0* This interface is under work and consideration, and should probably >> =A0* be killed with a big axe by the first person who can find the time. >> =A0* (be aware though, that the proper interface isn't as obvious as it >> =A0* may seem, there are various conflicting requirements. >> =A0*/ >> >> AFAIT, the whole interface used by sysctl(8) to explore the sysctl >> tree (ie. list, name, get description) is undocumented. This comment >> has been there for about, well... 17 years. No matter to say that it >> is highly unlikely anyone is ever gonna design that perfect interface. >> Right now, I am left with no choice but to figure out how that stuff >> work, which I foresee will be a real PITA. No choice ? Well, not so >> much. About 12 years ago a filesystem interface was written for >> sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris >> Popov. Unfortunately, time passed and no code is any longer publicly >> available. URLs are either no longer valid or password-protected. >> >> This interface would just be perfect for my use-case. No need to spend >> time decoding a prehistoric interface, no need to craft custom >> accessors. I would just have to use standard POSIX file interface... >> if the code was available. >> >> I was hoping some of the people on this list would either, have the >> scfs(4) code on their drives/tapes, or have a way to contact the >> original author(s) and thus have a chance to get that code ? >> >> Thanks in advance, >> =A0- Arnaud >> >> ps: I know the code will certainly have to be fixed, but that is still >> the best option I've got so far. > > Alternatively, the interface could just be documented (from > sys/kern/kern_sysctl.c): > > /* > =A0* "Staff-functions" > =A0* > =A0* These functions implement a presently undocumented interface > =A0* used by the sysctl program to walk the tree, and get the type > =A0* so it can print the value. > =A0* This interface is under work and consideration, and should probably > =A0* be killed with a big axe by the first person who can find the time. > =A0* (be aware though, that the proper interface isn't as obvious as it > =A0* may seem, there are various conflicting requirements. > =A0* > =A0* {0,0} =A0 =A0 =A0 =A0printf the entire MIB-tree. > =A0* {0,1,...} =A0 =A0return the name of the "..." OID. > =A0* {0,2,...} =A0 =A0return the next OID. > =A0* {0,3} =A0 =A0 =A0 =A0return the OID of the name in "new" > =A0* {0,4,...} =A0 =A0return the kind & format info for the "..." OID. > =A0* {0,5,...} =A0 =A0return the description the "..." OID. > =A0*/ > > I know 2 closed-source versions that have wholesale stolen/"borrowed" > the code from sysctl(3), and I adapted the sysctl(8) code for my own > uses for the cython derivative I made here [1]. > I guess I will have no choice but to write a third... - Arnaud > Thanks, > -Garrett > > 1. http://sourceforge.net/projects/sysctl/ From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 01:38:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDBE71065672; Tue, 26 Jun 2012 01:38:40 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A16838FC0A; Tue, 26 Jun 2012 01:38:40 +0000 (UTC) Received: by obbun3 with SMTP id un3so9330679obb.13 for ; Mon, 25 Jun 2012 18:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Q8fBzxZzGtWc3QDkkupNqvJXl59w497mRcDkkUqiUu0=; b=O97CsdzHfcTVRxL8A5DyGciO9rVtj2PQoJpIKHkHpkuww9sZf4s/Ye2IuL3jlC8M5u mFxlzwZcHHTBxhwCVPqukEdIpTPrmFxPtNxCCGwLOTuY0E9IRHkN5fX+WQk2PL6yAkTV xoyGZIO3Mqh7aNwXQCvCseUNpc12fCE1auHofcCThV7n6r7ewn9K8oZylFMjKpUVAfN2 atW1fqiicBcnJXcaxX11yjGWzDKbfEZbWMqzjpkH/8X18XSO5ktBmKq47JVvbauxQHLm Zzd821CpQuJQ7uJKu62vwO+qbUwRKehVbQwS5X8bkk3h5ecYsCXck/U7dp5N4DSSUZkK SXsg== MIME-Version: 1.0 Received: by 10.182.77.170 with SMTP id t10mr14396959obw.70.1340674719951; Mon, 25 Jun 2012 18:38:39 -0700 (PDT) Received: by 10.76.68.74 with HTTP; Mon, 25 Jun 2012 18:38:39 -0700 (PDT) In-Reply-To: <20120625095548.GD2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> Date: Tue, 26 Jun 2012 09:38:39 +0800 Message-ID: From: Marcelo Araujo To: Konstantin Belousov X-Mailman-Approved-At: Tue, 26 Jun 2012 02:13:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Kevin Lo , freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 01:38:41 -0000 Hello Kevin, May you rebuild your kernel with some options that will make the dump of the crash easier to send to people? Try to follow these steps: 1) Configure KERNEL with the folowing options: options KDB options GDB options DDB 2) Configure rc.conf: dumpdev="/dev/ad0s1b" #Your swap slice. dumpdir="/var/crash" #By default. crashinfo_enable="YES" crashinfo_program="/usr/sbin/crashinfo" 3) When the FreeBSD crash, it won't rebut, but will be stop on a gdb prompt. 3.1) gdb> continue 3.2) gdb> dump 4) kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 5) kgdb> backtrace 6) kgdb> up 4 7) kgdb> up 6 --> Up to line number 4. 7 --> Up to the next line. Best Regards, - Araujo 2012/6/25 Konstantin Belousov > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > I've observed a panic in recent -current several times but I only > > have a picture of the backtrace: > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > Does this look at all familiar to anyone? > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > in your kernel ? > > The screenshot looks strange. The instruction on which the kernel trapped > is int 0x28 which should not appear in the compiled code. > -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 02:51:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DE41106564A; Tue, 26 Jun 2012 02:51:47 +0000 (UTC) (envelope-from borisxm@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8357B8FC08; Tue, 26 Jun 2012 02:51:46 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so3251665wib.1 for ; Mon, 25 Jun 2012 19:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ui0u/AJxljlEVS4UCoooaFtYHuPeFV8mFyS1CgUKVc8=; b=x+Q5gH1pxZ+bF09RO5d9KPe6kFM8dHVywLquAxpksrUJ2Fn9euqKoaaOXyQmXcvpt4 H1W//a5Us+Wz4AfdeeI3+FuKLHGxW1AjTJCfnPy3xq31tyOOeRb0cv1oKhEL4+hY2orC ZNXpL96JEuyD87QWD1Z4yd6sTGXmrmYcQyepDR9JGTm2U79gS1CQtKWKt+YAQZwp0BCc WiL01HTnLti6waNzkvHgvPARTwfA0efq/sBzOsw/B+ymeCegnrnP4J5D6gMUHf4tCl1W EkAP1bBWCtVNYvE+2e8w3MjN/ng1ru/Li1xu9GIZyhxr2hRLcnaPwNitpyKUNzlxZZqs AQGg== Received: by 10.181.13.142 with SMTP id ey14mr190070wid.19.1340679099296; Mon, 25 Jun 2012 19:51:39 -0700 (PDT) Received: from 10.0.22.54 ([178.88.204.75]) by mx.google.com with ESMTPS id bc2sm2997284wib.0.2012.06.25.19.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 19:51:38 -0700 (PDT) Sender: Boris Popov Message-ID: <4FE923B6.7080108@freebsd.org> Date: Tue, 26 Jun 2012 08:51:34 +0600 From: Boris Popov User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adam Vande More , FreeBSD Current , kby@freebsd.org, FreeBSD Hackers Subject: Re: sysctl 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, 26 Jun 2012 02:51:47 -0000 On 26.06.2012 6:56, Arnaud Lacombe wrote: > purpose. However, if I can avoid to re-design that wheel too, by > getting access to scfs(4) code, I will. It is interesting, that the old drive with this code are still alive. Most likely, FS related part will need serious attention because of numerous changes in the VFS subsystem. Here is the link: http://www.vertex.kz/scfs.tgz -- Boris Popov From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 04:38:34 2012 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 DB80A1065672; Tue, 26 Jun 2012 04:38:34 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3A52F8FC12; Tue, 26 Jun 2012 04:38:33 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5Q4cMTv064620; Tue, 26 Jun 2012 12:38:22 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340685505.2170.5.camel@nsl> From: Kevin Lo To: Konstantin Belousov Date: Tue, 26 Jun 2012 12:38:25 +0800 In-Reply-To: <20120625095548.GD2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 04:38:34 -0000 Konstantin Belousov wrote: > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > I've observed a panic in recent -current several times but I only > > have a picture of the backtrace: > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > Does this look at all familiar to anyone? > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > in your kernel ? Sure. > The screenshot looks strange. The instruction on which the kernel trapped > is int 0x28 which should not appear in the compiled code. # gdb tmpfs.ko (gdb) l *tmpfs_reg_resize+0x627 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005). 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c In tmpfs_subr.c: 999 if (m != NULL) { 1000 if ((m->oflags & VPO_BUSY) != 0 || 1001 m->busy != 0) { 1002 vm_page_sleep(m, "tmfssz"); 1003 goto retry; 1004 } 1005 MPASS(m->valid == VM_PAGE_BITS_ALL); 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU LL)) { Thanks! Kevin From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 05:11:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EACF6106566C; Tue, 26 Jun 2012 05:11:48 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E30EE8FC08; Tue, 26 Jun 2012 05:11:47 +0000 (UTC) Received: by werg1 with SMTP id g1so4270213wer.13 for ; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HXIyXNxPWehNMnPpuWvOA+P6WbB/R6z1LTVaUAOyses=; b=txUD/Xah7y9BUCrNzafG/BKknqYFpmkv/miXATshXGmy4HL8Z7dUCrVU7hyqNCfZyf lizFGC4KIxFMEttbh+dhM+v8FXR2qHdGGsC3zO973YILjG+ICrqAwTL0Y5yVn4nD6Cgx tVOYR5WmDJ8jwk/ObInrjL8QK/MVILJdv1+8ExYxPKmegkh6rKFZKlYOMC5ZPswjuTXd 1pfEmVE3pH5dyVy9bxPDvH+Litwx7aMrYhOxoPEKpskKxr8qFmQmLHz1pqnYUUplU6fv t2dkCzn+Nq9+971NWdj02OqWHY7+4mwszcL1cixrrI4nxm9eqQFtLpU1i9KdZ/6gw3MI yynQ== MIME-Version: 1.0 Received: by 10.180.82.198 with SMTP id k6mr29874530wiy.20.1340687506780; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) In-Reply-To: <4FE923B6.7080108@freebsd.org> References: <4FE923B6.7080108@freebsd.org> Date: Tue, 26 Jun 2012 01:11:46 -0400 Message-ID: From: Arnaud Lacombe To: Boris Popov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam Vande More , FreeBSD Current , kby@freebsd.org, FreeBSD Hackers Subject: Re: sysctl 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, 26 Jun 2012 05:11:49 -0000 Hi, On Mon, Jun 25, 2012 at 10:51 PM, Boris Popov wrote: > On 26.06.2012 6:56, Arnaud Lacombe wrote: >> purpose. However, if I can avoid to re-design that wheel too, by >> getting access to scfs(4) code, I will. > > =A0It is interesting, that the old drive with this code are still alive. > Most likely, FS related part will need serious attention because of > numerous changes in the VFS subsystem. Here is the link: > > http://www.vertex.kz/scfs.tgz > Outstanding ! I was pointed another implementation by Jakub Dawidek made in 2002, which seems more advanced. In any case, lots of KPI changed... I guess I found a new toy for this week :-) Thanks a lot, - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 06:35:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 816081065674; Tue, 26 Jun 2012 06:35:17 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 756328FC08; Tue, 26 Jun 2012 06:35:16 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4792664bkv.13 for ; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oas635gVhoVXywuZLkMWFDkCnlQ2BBE3NK5YRVsj5ZA=; b=T9V+a+arihBNJjbeasRIF14vFul68nomSqMR/8HNGsDAWZRNdhk4HDSImi0tE0Gu5a CX+sk1byx6vGN+Z+7zpNYyBxjmE2DpUWzZ4V/rJQNf3wrV/Ew1es4l8jRbbT6Te36esV 6No92uU2FdvKSr0EB8UdywcIG1jFJ19vxohIMHSRR54bjAV0WKu9IumUtQv2GJxuG+py iq4A3bUkdCuqDnhZvdvIuGrTmWbxCC2RpoAxW8oUur7IBhj+luyJthKN4ulfXaFpy4V3 wWbRIa04kf+yP7q2MsrNltSrrdPWfYtawnKNzigEkbfX09gvVBYWYrTweNGuOMGLSFop rZ2w== MIME-Version: 1.0 Received: by 10.204.156.155 with SMTP id x27mr4915393bkw.84.1340692515295; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 07:35:15 +0100 Message-ID: From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Arnaud Lacombe , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 06:35:17 -0000 On Jun 26, 2012 7:07 AM, "Wojciech Puchar" wrote: > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. Chris From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 08:59:28 2012 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 D2219106566C; Tue, 26 Jun 2012 08:59:28 +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 885928FC15; Tue, 26 Jun 2012 08:59:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 653D246B09; Tue, 26 Jun 2012 04:59:27 -0400 (EDT) Date: Tue, 26 Jun 2012 09:59:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chris Rees In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar Subject: Re: sysctl 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, 26 Jun 2012 08:59:28 -0000 On Tue, 26 Jun 2012, Chris Rees wrote: >> as well as we don't depend of /proc for normal operation we shouldn't for > say /proc/sysctl >> >> improvements are welcome, better documentation is welcome, changes to > what is OK - isn't. > > /proc/sysctl might be useful. Just because Linux uses it doesn't make it a > bad idea. One of the problems we've encounted with synthetic file systems is that off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but not unreasonable) assumptions about the statistic content of files. This comes up frequently with procfs-like systems where the size of, say, memory map data can be considerably larger than the perhaps 128-byte, 256-byte, or even 8k buffers that might exist in a stock file access tool. Unless we change all of those tools to use buffers much bigger than they currently do, which even suggets changing the C library buffer to defaults for FILE *, that places an onus on the file system to provide persisting snapshots of data until it's sure that a user process is done -- e.g., over many system calls. sysctl is not immune to the requirement of atomicity, but it has explicit control over it: sysctl is a single system call, rather than an unbounded open-read-seek-repeat-etc cycle, and has been carefully crafted to provide this and other MIB-like properties, such as a basic data type model so that command line tools know how to render content rather than having to guess and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better match for accessing this sort of monitoring and control data than the POSIX file API, and would recommend against trying to move to a sysctl file system. Robert From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 10:24:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5246106566C; Tue, 26 Jun 2012 10:24:43 +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 3DBF38FC0C; Tue, 26 Jun 2012 10:24:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5QAOR28042867; Tue, 26 Jun 2012 13:24:27 +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.5/8.14.5) with ESMTP id q5QAOQYx054653; Tue, 26 Jun 2012 13:24:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5QAOPi6054652; Tue, 26 Jun 2012 13:24:25 +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: Tue, 26 Jun 2012 13:24:25 +0300 From: Konstantin Belousov To: Kevin Lo Message-ID: <20120626102424.GL2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZvISnaQ8JYKZply4" Content-Disposition: inline In-Reply-To: <1340685505.2170.5.camel@nsl> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:24:43 -0000 --ZvISnaQ8JYKZply4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > Konstantin Belousov wrote: > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > I've observed a panic in recent -current several times but I only > > > have a picture of the backtrace: > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > >=20 > > > Does this look at all familiar to anyone? > >=20 > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 addr= ess > > in your kernel ? >=20 > Sure. >=20 > > The screenshot looks strange. The instruction on which the kernel trapp= ed > > is int 0x28 which should not appear in the compiled code. >=20 > # gdb tmpfs.ko > (gdb) l *tmpfs_reg_resize+0x627 > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/= tmpfs_subr.c:1005). > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c >=20 > In tmpfs_subr.c: > 999 if (m !=3D NULL) { > 1000 if ((m->oflags & VPO_BUSY) !=3D 0 || > 1001 m->busy !=3D 0) { > 1002 vm_page_sleep(m, "tmfssz"); > 1003 goto retry; > 1004 } > 1005 MPASS(m->valid =3D=3D VM_PAGE_BITS_A= LL); > 1006 } else if (vm_pager_has_page(uobj, idx, NULL= , NU > LL)) { >=20 Hm, can you get a core and - obtain backtrace in kgdb; - print the *m content for the page that triggered the assertion ? The only possible 'new size' value for the truncation from open(2) is zero, so I do not understand why the asserted block was executed at all. --ZvISnaQ8JYKZply4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/pjdgACgkQC3+MBN1Mb4hFsgCeOI3iGrL11NcdF3tnpSzitJhl c9cAoLhqZmq1SyxQR4zwqIlQdL4uEX3O =Y8sb -----END PGP SIGNATURE----- --ZvISnaQ8JYKZply4-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 06:07:02 2012 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 76CDB106566B; Tue, 26 Jun 2012 06:07:02 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D44318FC0A; Tue, 26 Jun 2012 06:07:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5Q66wwQ003577; Tue, 26 Jun 2012 08:06:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5Q66wn3003574; Tue, 26 Jun 2012 08:06:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 08:06:58 +0200 (CEST) From: Wojciech Puchar To: Arnaud Lacombe In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 08:06:59 +0200 (CEST) X-Mailman-Approved-At: Tue, 26 Jun 2012 11:20:50 +0000 Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 06:07:02 -0000 as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 08:50:33 2012 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 DC5CF106564A; Tue, 26 Jun 2012 08:50:33 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 43D728FC15; Tue, 26 Jun 2012 08:50:32 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5Q8oSts001834; Tue, 26 Jun 2012 10:50:28 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5Q8oRYx001831; Tue, 26 Jun 2012 10:50:27 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 10:50:27 +0200 (CEST) From: Wojciech Puchar To: Chris Rees In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2456600518-377125759-1340700627=:1828" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 10:50:28 +0200 (CEST) X-Mailman-Approved-At: Tue, 26 Jun 2012 11:21:06 +0000 Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Arnaud Lacombe , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl 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, 26 Jun 2012 08:50:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2456600518-377125759-1340700627=:1828 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > > > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. > > /proc/sysctl might be useful.  Just because Linux uses it doesn't make it a bad idea. actually - i don't know since over 5 years what linux do. --2456600518-377125759-1340700627=:1828-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 12:50:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E57291065673; Tue, 26 Jun 2012 12:50:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id B18658FC19; Tue, 26 Jun 2012 12:50:49 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward1.mail.yandex.net (Yandex) with ESMTP id EDABC124170D; Tue, 26 Jun 2012 16:50:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340715048; bh=GXt6cLLBcdsmnDtZzOzY0JG7K7AXBOo3qkBQU4UkcX8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=RG8re+gV2O8Jx3iXAbs4BzMQK46lzG9HMVJA6nwAW+OCiY7PlTY1IoM9yeVQkN9Rj Qyzw6hZ24hlgB0hdlyyvGzuUN+jNxKzL5SpWX9mwaxingF743j9tw39LPHgvSrlHeO qIOX8Gf3js/SYE+IXGmdR0yx7cs8/7p+qD7dWS1c= Received: from smtp1.mail.yandex.net (localhost [127.0.0.1]) by smtp1.mail.yandex.net (Yandex) with ESMTP id 701C1AA0553; Tue, 26 Jun 2012 16:50:47 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp1.mail.yandex.net (nwsmtp/Yandex) with ESMTP id okAWnV8t-okAKNANs; Tue, 26 Jun 2012 16:50:47 +0400 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@FreeBSD.org X-Yandex-Rcpt-Suid: pjd@FreeBSD.org X-Yandex-Rcpt-Suid: steven.hartland@FreeBSD.org X-Yandex-Rcpt-Suid: olgeni@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340715047; bh=GXt6cLLBcdsmnDtZzOzY0JG7K7AXBOo3qkBQU4UkcX8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: X-Enigmail-Version:Content-Type; b=ZHrcm1h7xF3ZdCs4k+Gj5xmTzBYcPALbz02XjFUF/Xfy+iHMw+6GjHmB5N25ue7s2 yCeJXBUpVGrPKC7iZk0+AgjxD5lLB1dxFwR7K2qU+52126/F+sjfX+0Aef/jEBRDLw 7451LxxoQxnHX17qyIUvvsQ0+e/LH+NxB1lnC6xE= Message-ID: <4FE9B01C.30306@yandex.ru> Date: Tue, 26 Jun 2012 16:50:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-current , freebsd-hackers X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DF35FE7979D7795EBCBB2D2" Cc: Doug Rabson , Pawel Jakub Dawidek , Andriy Gapon Subject: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 12:50:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DF35FE7979D7795EBCBB2D2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors= , when it finds the "GEOM::" signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootc= ode' command, the kernel correctly modifies this partition record. So, this is= only for the first rescue step. 6. I have changed userboot interface. I guess there is none consumers exc= ept the one test program. But if it isn't that, i can make it compatible. Any comments are welcome. --=20 WBR, Andrey V. Elsukov --------------enig3DF35FE7979D7795EBCBB2D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6bAlAAoJEAHF6gQQyKF6yvwH/1+awIGkwRcAA/sKs1NGoEt7 85mZZ2t8KUKUy0Yjxe4p8doCVHQoeppBjEUChTW1yWncLWstOuoO/JQ8nUi8mlH5 WetoHH4dtShSuuaXB+N2dMv6g3ETyo0/uIMqX18V4FniLUXBwFjP2UnMc6JMJDkZ L7cUgTnvbeGU08GU9L6jDwA6xN/nwMSYN0U9fbGYbNhabtIL3JNb1MMsUAAwdijB a4EPPD3k4ZTOW/DBI+NQeYjpi3q0bEO1lmvEB/rSOq3ivMLxZHtV+Z9MMpEiPWTI q4eayZFalrT70RVjG/0Vxy3w0ISQcE5yfWMA0U2GLLt8k9kqPtePV8CH7pQXaHo= =1xLc -----END PGP SIGNATURE----- --------------enig3DF35FE7979D7795EBCBB2D2-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 12:59:48 2012 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 4F7A91065670; Tue, 26 Jun 2012 12:59:48 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B82F38FC15; Tue, 26 Jun 2012 12:59:47 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id EBB45997; Tue, 26 Jun 2012 14:59:39 +0200 (CEST) Date: Tue, 26 Jun 2012 14:57:37 +0200 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20120626125737.GA1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4FE9B01C.30306@yandex.ru> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 12:59:48 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: > Hi All, >=20 > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff >=20 > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h >=20 > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s >=20 > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootc= ode' > command, the kernel correctly modifies this partition record. So, this is= only > for the first rescue step. >=20 > 6. I have changed userboot interface. I guess there is none consumers exc= ept > the one test program. But if it isn't that, i can make it compatible. >=20 > Any comments are welcome. >=20 > --=20 > WBR, Andrey V. Elsukov >=20 >=20 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/pscEACgkQForvXbEpPzRnngCgzmPlaecRHxfJkLn4Q9MhzbmT +hsAoLf2biw+RP8N9qalavPbyhMnihnL =Yxgu -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 12:39:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C3C11065670; Tue, 26 Jun 2012 12:39:29 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id C35388FC18; Tue, 26 Jun 2012 12:39:28 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5QCdIbG001420; Tue, 26 Jun 2012 14:39:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5QCdI2d001417; Tue, 26 Jun 2012 14:39:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 14:39:17 +0200 (CEST) From: Wojciech Puchar To: Robert Watson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 14:39:18 +0200 (CEST) X-Mailman-Approved-At: Tue, 26 Jun 2012 13:08:12 +0000 Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Chris Rees Subject: Re: sysctl 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, 26 Jun 2012 12:39:29 -0000 > and/or get it wrong. sysctl has some file-system like properties, but on the > whole, it's not a file system -- it's much more like an SNMP MIB. > > While you can map anything into anything (including Turing machines), I think > the sysctl command line tool and API, despite its limitations, is a better me too. i REALLY appreciate the way FreeBSD do this. pseudo-filesystems are sometimes good but making them default method is bad. Current way is simple. Or actually - less complicated as i think for example - XML in system output is not. From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 14:01:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4676D1065677; Tue, 26 Jun 2012 14:01:46 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1308FC08; Tue, 26 Jun 2012 14:01:45 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward15.mail.yandex.net (Yandex) with ESMTP id 83B0E9E1DE8; Tue, 26 Jun 2012 18:01:43 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340719303; bh=1UHNgwa4LP2yCMa+FrgAboQCgWmOizJUFUMPXLdWctg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=nN2Kk6DnK1Bh2viN2Yis+wx5Xd8KI3VZL2fehYtdw5/VH5DF3xQJZIyP5RLBH4Uvh Ltoo9i7ZcVPPiWO6AWhMMefOwBUiBa+/cL1tLHi2zNvkYO3K0W2ObJCjIggs2zcSbJ iy61BRcfoFqcH/8/xEsDfzwfi5sTRLBIfMf14wSs= Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 21AD47E0554; Tue, 26 Jun 2012 18:01:43 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1gVi9xkS-1gVWLZ9I; Tue, 26 Jun 2012 18:01:42 +0400 X-Yandex-Rcpt-Suid: pjd@FreeBSD.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@FreeBSD.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340719303; bh=1UHNgwa4LP2yCMa+FrgAboQCgWmOizJUFUMPXLdWctg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=cqXEfn99WWFYPuQAYkyok+0JebVTngT18dfG4pfWr0eUx2ndPjbq/80IUfDmWTOt+ OBIa3T190cP/p4JOt+VQ1wlyR+gVtq4YsSqcUQbD9iwuVtrbt7H73YvMlxm66ZcdQk tVxjdY/Ue6Dq+34BBVc2dpPqZkmuFJWJCShxu9+c= Message-ID: <4FE9C0B6.5090106@yandex.ru> Date: Tue, 26 Jun 2012 18:01:26 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FE9B01C.30306@yandex.ru> <20120626125737.GA1372@garage.freebsd.pl> In-Reply-To: <20120626125737.GA1372@garage.freebsd.pl> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig21C87142E5DB97DE8655A57A" Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 14:01:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21C87142E5DB97DE8655A57A Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: > On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: >> Hi All, >> >> Some time ago i have started reading the code in the sys/boot. >> Especially i'm interested in the partition tables handling. >> I found several problems: >> 1. There are several copies of the same code in the libi386/biosdisk.c= >> and common/disk.c, and partially libpc98/biosdisk.c. >> 2. ZFS probing is very slow, because the ZFS code doesn't know how man= y >> disks and partitions the system has: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 >> 3. The GPT support doesn't check CRC and even doesn't know anything >> about the secondary GPT header/table. >=20 > Just a quick note here. At some point when I was adding GPT attributes > to allow for test starts I greatly improved, at least parts of, the GPT= > implementation. I did implement support for both CRC checksum > verification and fallback to backup GPT header when primary is broken. > And the code is still in sys/boot/common/gpt.c. So my question would be= > what do you mean by this sentence? Yes, gptboot does that, but the loader/zfsloader doesn't. So there might be a situation when gptboot does boot, but loader(8) can't. --=20 WBR, Andrey V. Elsukov --------------enig21C87142E5DB97DE8655A57A 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.19 (FreeBSD) iQEcBAEBAgAGBQJP6cDFAAoJEAHF6gQQyKF6lsMH/Rzco/vYsCHB6SbQqMVUGb6m ODVKakOz2jUD3e+62QQ/6sDOSiQHi1FCZ0Vil/+8fH8QdK877TzfVcGxZcyff5LU On4cNxwCZBQku8uMgjniBsG3mxczCgdVjCQWLr1ntUx7eENwg43YDQqhnJ6ybc94 mpu5NOre7D2kmEo0upc66hC48EXnfr8Uyx1xCjXM6VTFVNbFuLnZbHxTYcVKB6jR 4C65a/lZa6KRvnEtQMKQCFUIdvFuO9DkwjkUrTsdq+ILVn63YDusFVrjZ5SfCO6S s1MlOT41pGXToCoj4H0R6jsrY0oCddT0bK8QkDosA3gOQmQcr7wBLb5Zjm7Irbc= =swCT -----END PGP SIGNATURE----- --------------enig21C87142E5DB97DE8655A57A-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 14:04:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FF041065702; Tue, 26 Jun 2012 14:04:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id CF7CC8FC14; Tue, 26 Jun 2012 14:04:04 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id D2F3E9C7; Tue, 26 Jun 2012 16:04:02 +0200 (CEST) Date: Tue, 26 Jun 2012 16:02:00 +0200 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20120626140200.GB1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <20120626125737.GA1372@garage.freebsd.pl> <4FE9C0B6.5090106@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <4FE9C0B6.5090106@yandex.ru> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 14:04:05 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 06:01:26PM +0400, Andrey V. Elsukov wrote: > On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: > > On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: > >> Hi All, > >> > >> Some time ago i have started reading the code in the sys/boot. > >> Especially i'm interested in the partition tables handling. > >> I found several problems: > >> 1. There are several copies of the same code in the libi386/biosdisk.c > >> and common/disk.c, and partially libpc98/biosdisk.c. > >> 2. ZFS probing is very slow, because the ZFS code doesn't know how many > >> disks and partitions the system has: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 > >> 3. The GPT support doesn't check CRC and even doesn't know anything > >> about the secondary GPT header/table. > >=20 > > Just a quick note here. At some point when I was adding GPT attributes > > to allow for test starts I greatly improved, at least parts of, the GPT > > implementation. I did implement support for both CRC checksum > > verification and fallback to backup GPT header when primary is broken. > > And the code is still in sys/boot/common/gpt.c. So my question would be > > what do you mean by this sentence? >=20 > Yes, gptboot does that, but the loader/zfsloader doesn't. So there might > be a situation when gptboot does boot, but loader(8) can't. I see. I don't know if I'll find time for a proper review, but it is really great that you are working on cleaning up this huge mess. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --XF85m9dhOBO43t/C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/pwNgACgkQForvXbEpPzRNiACg9Jd2ghcjyMNO3acfJCWbqA5x CWIAoLBHIGoxWijoqp7QIb+fOtPETQj9 =+N3O -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 14:42:37 2012 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 C269B106566B; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 73FF68FC17; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) Received: by dadv36 with SMTP id v36so7381191dad.13 for ; Tue, 26 Jun 2012 07:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7AJwgmKFOM7Eiohc/nf00x94+/bvifmzChfGE9/yWFU=; b=Z3ofc0dzwk38pQpaiVWljo3lEI+0jQDCZRi1BJncFk29DR2+jOP1Nt5h8mM7/23DID x7We2PdsQ9J9abP5/qdkGXiC4hhdy/cGBPs2JvAoNU5BgU1Oai7FRawhpJkyKj6x21Vk OyDpWESeiNa7XmBlt7OEW3l9hC4dKwpKU5BMk7zgJ/kFJw65LTgJTau618cMf4NJiZaZ bhBLQpeUHIO2scAcqqp0pYt8BS7iII5AiETo7uq9zyxHqvoHa2E0acL3M/awufePS4OD KbRX2rBoDaKoYiV0MzUN6R6zIWnVmK5E1jDB5lDoF8ZHMqT/h8QIICpSXWLk0igNxxBQ AjcA== MIME-Version: 1.0 Received: by 10.68.233.132 with SMTP id tw4mr52711220pbc.61.1340721756876; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 07:42:36 -0700 X-Google-Sender-Auth: x2biu1q5mqcvOmqUfYXD82T2AFo Message-ID: From: mdf@FreeBSD.org To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar , Chris Rees Subject: Re: sysctl 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, 26 Jun 2012 14:42:38 -0000 On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote: > On Tue, 26 Jun 2012, Chris Rees wrote: > >>> as well as we don't depend of /proc for normal operation we shouldn't f= or >> >> say /proc/sysctl >>> >>> >>> improvements are welcome, better documentation is welcome, changes to >> >> what is OK - isn't. >> >> /proc/sysctl might be useful. =A0Just because Linux uses it doesn't make= it >> a bad idea. > > > One of the problems we've encounted with synthetic file systems is that > off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but = not > unreasonable) assumptions about the statistic content of files. =A0This c= omes > up frequently with procfs-like systems where the size of, say, memory map > data can be considerably larger than the perhaps 128-byte, 256-byte, or e= ven > 8k buffers that might exist in a stock file access tool. =A0Unless we cha= nge > all of those tools to use buffers much bigger than they currently do, whi= ch > even suggets changing the C library buffer to defaults for FILE *, that > places an onus on the file system to provide persisting snapshots of data > until it's sure that a user process is done -- e.g., over many system cal= ls. > > sysctl is not immune to the requirement of atomicity, but it has explicit > control over it: sysctl is a single system call, rather than an unbounded > open-read-seek-repeat-etc cycle, and has been carefully crafted to provid= e > this and other MIB-like properties, such as a basic data type model so th= at > command line tools know how to render content rather than having to guess > and/or get it wrong. =A0sysctl has some file-system like properties, but = on > the whole, it's not a file system -- it's much more like an SNMP MIB. > > While you can map anything into anything (including Turing machines), I > think the sysctl command line tool and API, despite its limitations, is a > better match for accessing this sort of monitoring and control data than = the > POSIX file API, and would recommend against trying to move to a sysctl fi= le > system. While I understand the problems you allude to, the sysctl(8) binary can protect itself from them. IMO the biggest problem with sysctls not being files is that it makes no sense from the core UNIX philosophy that everything is a file. Sockets and pipes and character devices and even unseekable things like stdout are files; why aren't these other objects that allow read, write, and have their own namespace? Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 15:46:43 2012 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 D3A5F1065670 for ; Tue, 26 Jun 2012 15:46:43 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 818B68FC0C for ; Tue, 26 Jun 2012 15:46:43 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 2FB09613D for ; Tue, 26 Jun 2012 11:46:34 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=AF5ZpcLzgYZRLbIqqjxNbdVApYJvxIIBWmTv6Q4wxnHqfhQIYgBZWbckiCk63cWW4 6DVW4oEVhPPINZ9dzNE3s1VuSOO5MrlMt/WzSXGS9o5dclMYBxsrII1Bff5glxi Message-ID: <4FE9D958.4000901@protected-networks.net> Date: Tue, 26 Jun 2012 11:46:32 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Removing an SDHC card causes a kernel panic on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:46:44 -0000 As follows, in "g_disk_providergone", a NULL pointer reference?: imb@toshi:/home/imb> sudo less /var/crash/core.txt.4 toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Tue Jun 26 08:59:01 EDT 2012 FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012 imb@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault [ .. ] Unread portion of the kernel message buffer: sdhci0-slot0: Card removed mmc0: detached Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc070a4bc stack pointer = 0x28:0xc6fb7c54 frame pointer = 0x28:0xc6fb7c54 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (g_event) trap number = 12 panic: page fault cpuid = 1 Uptime: 7m8s Physical memory: 3045 MB Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc07ae76c in kern_reboot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449 #2 0xc07aee41 in panic (fmt=0x104
) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637 #3 0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022 #4 0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936 #5 0xc0af29ef in trap (frame=0xc6fb7c14) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546 #6 0xc0adcbdc in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169 #7 0xc070a4bc in g_disk_providergone (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505 #8 0xc070f8ba in g_destroy_provider (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643 #9 0xc070fb6e in g_wither_washer () at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462 #10 0xc070cb62 in g_run_events () at /usr/home/imb/svn/head/sys/geom/geom_event.c:289 #11 0xc077bd8b in fork_exit (callout=0xc070de54 , arg=0x0, frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995 #12 0xc0adcc84 in fork_trampoline () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276 (kgdb) From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 17:23:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C50A1106566B for ; Tue, 26 Jun 2012 17:23:13 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 639128FC14 for ; Tue, 26 Jun 2012 17:23:13 +0000 (UTC) Received: (qmail 26638 invoked by uid 0); 26 Jun 2012 17:23:06 -0000 Received: from 173.37.0.44 (HELO ?173.37.0.44?) (173.37.0.44) by relay03.pair.com with SMTP; 26 Jun 2012 17:23:06 -0000 X-pair-Authenticated: 173.37.0.44 Message-ID: <4FE9EFF9.9080507@FreeBSD.org> Date: Tue, 26 Jun 2012 10:23:05 -0700 From: Mark Peek User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pfg@freebsd.org References: <1340474946.11584.YahooMailClassic@web113506.mail.gq1.yahoo.com> In-Reply-To: <1340474946.11584.YahooMailClassic@web113506.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [RFT] llquantize for FreeBSD's dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 17:23:13 -0000 On 6/23/12 11:09 AM, Pedro Giffuni wrote: > > > --- Sab 23/6/12, Fabian Keil ha scritto: > ... >>> My suggestion would be to instead try using the test >>> scripts in >>> >> cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/ >>> >>> err.D_LLQUANT_FACTORSMALL.d (for example) has >>> >>> @ = llquantize(0, 1, 0, 10, 10); >> >> The problem appears to be unrelated to the syntax change: >> >> fk@r500 >> /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize >> $sudo dtrace -s err.D_LLQUANT_FACTORSMALL.d >> Assertion failed: (!(arg & (UINT16_MAX << >> args[i].shift))), file >> > > It's a different assertion. > > Probably some difference between Solaris and BSD. > this is very useful, thanks! Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg & (UINT16_MAX << args[i].shift))); to assert(!(arg & ((uint64_t)UINT16_MAX << args[i].shift))); Mark From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 18:38:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C364106566B for ; Tue, 26 Jun 2012 18:38:58 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id 118A58FC17 for ; Tue, 26 Jun 2012 18:38:58 +0000 (UTC) Received: from [98.139.91.62] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 18:35:34 -0000 Received: from [98.139.91.54] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 18:35:34 -0000 Received: from [127.0.0.1] by omp1054.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 18:35:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880043.32824.bm@omp1054.mail.sp2.yahoo.com Received: (qmail 86193 invoked by uid 60001); 26 Jun 2012 18:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1340735734; bh=uxuhqyPSxwDXMaB6MEYTWy0HBhJOoUVrq7EKipZmhVM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KuwBNkpJfwtZ4ip7p5nahPEL9f4kSdppxcAfmvYAlMM4/or+v6naa/419TSVFDr+gtZA32K8omcJljW8sqDBMvGYlESDmbGzU35x9SdOr97VYPltMXFghxoooKukS1yfbN3eCcd6MBJmJY1sv4UKCACN28DunKTTbgTV/tX/0e8= X-YMail-OSG: FWKULuwVM1lUgPpKNV8oChH3if9J9BPsgXVbnca2LNIYVOI IGGuTTIwSNnHRGmWV..6Mjk3pYTlrkBA9aXiLzqGV5M6zj5cq4xZd.6GE0q9 zGbNeVFjC0ClWDLFs.FkJjyaEHxqC1b8zGKNyqG.ni1FG9BJBcUdtxEIkVap 4IrPdzSyi5DvInHjYLU1viMDBs41wxNUXpY5hoUZBD7pmsVGaajrTWTgrWOt SuNIl1twx2PuYFqf2lT9.lizT0exZJ_xdgwPrSNd2qdxJDtWgOYqhuetx1Oe FjOzXoLL6pzNAwTDJeL19SxSGI33YKddNI7IzYMyqbzXzpaOAitSH1OaJ8Rv Md5Hb5R10XFCa7jvlIS38d93HV.Ws2ElYZ_tO0XTLdqgbPAZLZla0mB3DKHA bMcJoUaXGqt5FSd7RLHEWvYVZmo.6_q1ByqXnpQ_3YGsmSX6_zEq0oeheYcS .Gmvj Received: from [200.118.157.7] by web113510.mail.gq1.yahoo.com via HTTP; Tue, 26 Jun 2012 11:35:34 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1340735734.53528.YahooMailClassic@web113510.mail.gq1.yahoo.com> Date: Tue, 26 Jun 2012 11:35:34 -0700 (PDT) From: Pedro Giffuni To: Mark Peek In-Reply-To: <4FE9EFF9.9080507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: gnn@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [RFT] llquantize for FreeBSD's dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 18:38:58 -0000 =0A=0A--- Mar 26/6/12, Mark Peek ha scritto:=0A=0A> >=0A> = > It's a different assertion.=0A> >=0A> > Probably some difference between = Solaris and BSD.=0A> > this is very useful, thanks!=0A> =0A> Try this, chan= ge the assert on line 1429 in file dt_cc.c=0A> from:=0A> =0A> assert(!(arg = & (UINT16_MAX << args[i].shift)));=0A> =0A> to=0A> =0A> assert(!(arg & ((ui= nt64_t)UINT16_MAX <<=0A> args[i].shift)));=0A> =0A=0AThis certainly looks c= orrect. Thanks Mark !=0A=0AI updated the patch:=0A=0Ahttp://people.freebsd.= org/~pfg/patches/patch-dtrace-llquantize=0A=0Acheers,=0A=0APedro. From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 19:06:18 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0FAA106566B; Tue, 26 Jun 2012 19:06:18 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by mx1.freebsd.org (Postfix) with ESMTP id 521C18FC1D; Tue, 26 Jun 2012 19:06:18 +0000 (UTC) Received: from [84.44.210.95] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Sjb5d-0003ad-4W; Tue, 26 Jun 2012 21:06:17 +0200 Date: Tue, 26 Jun 2012 21:06:06 +0200 From: Fabian Keil To: pfg@freebsd.org Message-ID: <20120626210606.632498e2@fabiankeil.de> In-Reply-To: <1340735734.53528.YahooMailClassic@web113510.mail.gq1.yahoo.com> References: <4FE9EFF9.9080507@FreeBSD.org> <1340735734.53528.YahooMailClassic@web113510.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/KhepE2o_8pVy__SoG_Oy.Cm"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: Mark Peek , freebsd-current@FreeBSD.org Subject: Re: [RFT] llquantize for FreeBSD's dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 19:06:18 -0000 --Sig_/KhepE2o_8pVy__SoG_Oy.Cm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Pedro Giffuni wrote: > --- Mar 26/6/12, Mark Peek ha scritto: > > Try this, change the assert on line 1429 in file dt_cc.c > > from: > >=20 > > assert(!(arg & (UINT16_MAX << args[i].shift))); > >=20 > > to > >=20 > > assert(!(arg & ((uint64_t)UINT16_MAX << > > args[i].shift))); > >=20 >=20 > This certainly looks correct. Thanks Mark ! >=20 > I updated the patch: >=20 > http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize Thanks a lot. Seems to work for me: fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquan= tize $for t in tst.*.d; do sudo dtrace -s $t > $t.myout; diff $t.out $t.myo= ut && echo success for $t; done success for tst.bases.d success for tst.basic.d success for tst.negorder.d success for tst.negvalue.d success for tst.normal.d success for tst.range.d success for tst.steps.d success for tst.trunc.d fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquan= tize $for t in err.*.d; do sudo dtrace -s $t dtrace: failed to compile script err.D_LLQUANT_FACTOREVEN.nodivide.d: line = 28: llquantize( ) factor (argument #1) must evenly divide the number of ste= ps per magnitude (argument #4), and the number of steps per magnitude must = evenly divide a power of the factor dtrace: failed to compile script err.D_LLQUANT_FACTOREVEN.notfactor.d: line= 28: llquantize( ) factor (argument #1) must evenly divide the number of st= eps per magnitude (argument #4), and the number of steps per magnitude must= evenly divide a power of the factor dtrace: failed to compile script err.D_LLQUANT_FACTORMATCH.d: line 29: llqu= antize( ) factor (argument #1) doesn't match previous declaration: expected= 10, found 3 dtrace: failed to compile script err.D_LLQUANT_FACTORNSTEPS.d: line 28: llq= uantize( ) factor (argument #1) must be less than or equal to the number of= linear steps per magnitude (argument #4) dtrace: failed to compile script err.D_LLQUANT_FACTORSMALL.d: line 28: llqu= antize( ) factor (argument #1) must be two or more dtrace: failed to compile script err.D_LLQUANT_FACTORTYPE.d: line 29: llqua= ntize( ) argument #1 (factor) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_FACTORVAL.d: line 28: llquan= tize( ) argument #1 (factor) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_HIGHMATCH.d: line 29: llquan= tize( ) high magnitude (argument #3) doesn't match previous declaration: ex= pected 10, found 11 dtrace: failed to compile script err.D_LLQUANT_HIGHTYPE.d: line 29: llquant= ize( ) argument #3 (high magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_HIGHVAL.d: line 28: llquanti= ze( ) argument #3 (high magnitude) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_LOWMATCH.d: line 29: llquant= ize( ) low magnitude (argument #2) doesn't match previous declaration: expe= cted 0, found 1 dtrace: failed to compile script err.D_LLQUANT_LOWTYPE.d: line 29: llquanti= ze( ) argument #2 (low magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_LOWVAL.d: line 28: llquantiz= e( ) argument #2 (low magnitude) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_MAGRANGE.d: line 28: llquant= ize( ) high magnitude (argument #3) must be greater than low magnitude (arg= ument #2) dtrace: failed to compile script err.D_LLQUANT_MAGTOOBIG.d: line 28: llquan= tize( ) factor (10) raised to power of high magnitude (100) overflows 64-bi= ts dtrace: failed to compile script err.D_LLQUANT_NSTEPMATCH.d: line 29: llqua= ntize( ) linear steps per magnitude (argument #4) doesn't match previous de= claration: expected 10, found 100 dtrace: failed to compile script err.D_LLQUANT_NSTEPTYPE.d: line 29: llquan= tize( ) argument #4 (linear steps per magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_NSTEPVAL.d: line 28: llquant= ize( ) argument #4 (linear steps per magnitude) must be an unsigned 16-bit = quantity Fabian --Sig_/KhepE2o_8pVy__SoG_Oy.Cm Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qCCoACgkQBYqIVf93VJ37twCeIGTaWwrMpUxhes6bH4JTuFMO VNEAoJP/R+W9WDebvaKy74DQGInWp2zo =CS2E -----END PGP SIGNATURE----- --Sig_/KhepE2o_8pVy__SoG_Oy.Cm-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 19:55:50 2012 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 49157106566B for ; Tue, 26 Jun 2012 19:55:50 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm8-vm0.bullet.mail.sp2.yahoo.com (nm8-vm0.bullet.mail.sp2.yahoo.com [98.139.91.194]) by mx1.freebsd.org (Postfix) with SMTP id 1DC608FC17 for ; Tue, 26 Jun 2012 19:55:50 +0000 (UTC) Received: from [72.30.22.92] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 19:52:47 -0000 Received: from [98.139.91.36] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 19:52:47 -0000 Received: from [127.0.0.1] by omp1036.mail.sp2.yahoo.com with NNFMP; 26 Jun 2012 19:52:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 881604.42396.bm@omp1036.mail.sp2.yahoo.com Received: (qmail 95180 invoked by uid 60001); 26 Jun 2012 19:52:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1340740367; bh=ZrSPH3fu+brPAEuVboUHed90EV4zAFoqZOJ3v0wvs+U=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yIpKk3L12Do7FPDfEqb7vDsjVmUezAa3Pxlp7o+1aj/6INsjU6s7CyI960oa0uEOCYjQ2eps+DFRgrybM+MV1ol+gl+6VDviTQPILOpz0Xeenp9onYaC0D6rvfBk/0C6x05Kbj3jw4xAIVXR8GRBbXsHLhYGapisEXJGWjvKf78= X-YMail-OSG: ZzH7RgwVM1lpKMak5pP9Ndmb5sVg67HGg.kVC2p_6oZWwe0 wz1oAL3rLy.VmvwuRfD9WLmKIG1B1YKkfOixGbNxqWCj2uBJLLWsEROGcce7 YkUSn.gqX5RBHRM_1n5VmgKNn2Lfj5I7CTEo2N4ANHvUIzIHdba1FqgP1urU H8EI71SbOR8Rk.pvpE9PeyW2XtNgY__gv9xiXSCsP3Kr8fSsARy6qpjrv7cW _jPS1CtpAV2jXBC6w6SOPTz7v8ae0MojHlw3bmuTvcGdPPUGTwPCKYxgRVrr hecB2wy8hKb7MO1tgdN_j3AmBi_0GGPyOojVjvQVpL1yJLcKTfoUCGx0yETq HlQr_ZTtsqSampvLSToxB5R4INrzjmt.eSgJHUzcRSZTEpOAqWbc4wvPqGyA n5WpwvxDPr4EHGIrSg90rjPrbV2p_HcS7kUm7jXrSCIqUqL5bINZPcteUmSL 9Sldd Received: from [200.118.157.7] by web113504.mail.gq1.yahoo.com via HTTP; Tue, 26 Jun 2012 12:52:47 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1340740367.88309.YahooMailClassic@web113504.mail.gq1.yahoo.com> Date: Tue, 26 Jun 2012 12:52:47 -0700 (PDT) From: Pedro Giffuni To: Fabian Keil In-Reply-To: <20120626210606.632498e2@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Peek , freebsd-current@FreeBSD.org Subject: Re: [RFT] llquantize for FreeBSD's dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:55:50 -0000 =0A=0A--- Mar 26/6/12, Fabian Keil ha scritt= o:=0A=0A> Pedro Giffuni wrote:=0A> =0A> > --- Mar 26/6/12= , Mark Peek =0A> ha scritto:=0A> =0A> > > Try this, change = the assert on line 1429 in file=0A> dt_cc.c=0A> > > from:=0A> > > =0A> > > = assert(!(arg & (UINT16_MAX <<=0A> args[i].shift)));=0A> > > =0A> > > to=0A>= > > =0A> > > assert(!(arg & ((uint64_t)UINT16_MAX <<=0A> > > args[i].shift= )));=0A> > > =0A> > =0A> > This certainly looks correct. Thanks Mark !=0A> = > =0A> > I updated the patch:=0A> > =0A> > http://people.freebsd.org/~pfg/p= atches/patch-dtrace-llquantize=0A> =0A> Thanks a lot. Seems to work for me:= =0A> =0A=0ANice!=0A=0AI don't use Dtrace though ... so I'll ask:=0A=0AAny o= bjections against committing it? :).=0A=0APedro.=0A=0A From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 20:42:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D306106567B; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2C88FC16; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68051B95A; Tue, 26 Jun 2012 16:42:40 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 26 Jun 2012 13:37:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206261337.11741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Jun 2012 16:42:40 -0400 (EDT) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 20:42:41 -0000 On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote: > Hi All, > > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff > > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h > > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' > command, the kernel correctly modifies this partition record. So, this is only > for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. > 6. I have changed userboot interface. I guess there is none consumers except > the one test program. But if it isn't that, i can make it compatible. One other consumer is in the bhyve branch. I think the 'kload' patches also use it. However, they can probably be adapted easily. [ Note, I haven't done a detailed review of the patch at all yet. ] -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 21:25:13 2012 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 05E421065672; Tue, 26 Jun 2012 21:25:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A65138FC0C; Tue, 26 Jun 2012 21:25:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4254BB84; Tue, 26 Jun 2012 23:25:11 +0200 (CEST) Date: Tue, 26 Jun 2012 23:23:08 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 21:25:13 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > 4. The gptboot now searches the backup GPT header in the previous secto= rs, > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > tries to do the same: > > common/gpt.c > > i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set i= t,=20 > but I've interpreted that as a way to see if the primary header is correc= t or=20 > not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... > [...] It seems to me that GPT tables created in this fashion (inside a GE= OM=20 > provider) will not work properly with partition editors for other OS's. = I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside of= a=20 > gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qKDsACgkQForvXbEpPzTuQQCg3kjmILCtG1x3GK+/ZmSRXGyr eQ0Anjd+C2ocL3sr5lOVZv+NlQ3+4s2Q =A8qf -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 21:35:41 2012 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 1E23D106564A; Tue, 26 Jun 2012 21:35:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 042868FC17; Tue, 26 Jun 2012 21:35:41 +0000 (UTC) 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 anubis.delphij.net (Postfix) with ESMTPSA id 9FD15C938; Tue, 26 Jun 2012 14:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1340746540; bh=Zy3CJ7zBU35YBgKu8ozxlchf8UEp0oQWFlgprAlGdpo=; h=Date:From:Reply-To:To:CC:Subject; b=pYlHET25JXunHtkbWCyexhyC79mWaLFJcvNQ/YBp3MT3DcuDjxKgv8VzgEj6zL/KS VfLxEidyfxQbZk8GlCIqMvKainQcmqcM1gu1MBFUEy3o1c1HtId8JqHsaWRn5UJHXf Y/IuiT7Wp8qkNbXscGed9vuihMrHqMsQznuSQkLE= Message-ID: <4FEA2B2C.40100@delphij.net> Date: Tue, 26 Jun 2012 14:35:40 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net, mm Subject: xzexe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:35:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Here is a small utility that uses xz(1) instead of gzip(1) for compressing executable, derived from the base system gzexe(1). http://people.freebsd.org/~delphij/misc/xzexe There is no plan at this time to put this into base system or a port unless people thinks it's useful. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP6issAAoJEG80Jeu8UPuzU14H/3rI6g8FJc+fFaW88LHc5Iwr psAzBWh/TFlyRvtcN6FmiCCTFy9nxi07P8hqd902Qa9yxRbKItD02hGehZCw/czM d5fHq5SXF2pJxZznae/TU4xrrZd3niCFJNQReO/bw5a6IooTgW26d6JaBrjGpUf2 eTLcVEzY6MS9DacUnHiwQAdWRdRIxr6ropBlKEIpkbvwNED+BAt9JOkjDP1YrZe5 M+gfzbEU3Lx+X1UBLmtah7zEF+Fwq89Y32KERrcadCvEOP0jqGrDM+njnq8eqk8a QK9wgxwg+SZLBGbYkVVtZEgIWKldxOBxEDwosizlrPPIJWbpOssc1k9lLsTlZ9U= =kl8S -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 21:41:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E931D106566B; Tue, 26 Jun 2012 21:41:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id BA8328FC12; Tue, 26 Jun 2012 21:41:37 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so319193wib.13 for ; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EJULjC4LRx83lPPCAVyN1VZ3wmJAs3iDoqR8+Yb2QUU=; b=M64njnVyOA8TMFrQjLP5RSGyNbAFlr1E6y55xU6WpPNkheIbSTGbYfrx4lLX6OtlnT UTqV/gDSZDlA+tV5cfd8FVfcpl3xOjGoXx4JLNZY1rqmf8K5NTNNnyPlzSVe1iJoCDdX J19pxSuc6Tppja0y6rS/FK+skGMuDOe5jHe7H/3Qpb+wzjvQimLXkPFzqT6EnnxMBFAt eSyV458Xhb5Pcl6tY7MA4L9/Q+wfeCArayRTTUBRQVeQR0xK7bnbec6oxOuTh9ODkHQ1 PahIOqpKneBN0lGhrD/24IhkMZD/aGcG65AbpsPFQqTfido6uSu3tkR5EMJETl2l6Sh/ CYWw== MIME-Version: 1.0 Received: by 10.180.79.166 with SMTP id k6mr36239762wix.8.1340746891280; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> Date: Tue, 26 Jun 2012 14:41:31 -0700 Message-ID: From: Kevin Oberman To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 21:41:39 -0000 On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrot= e: > On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: >> > 4. The gptboot now searches the backup GPT header in the previous sect= ors, >> > when it finds the "GEOM::" signature in the last sector. PMBR code als= o >> > tries to do the same: >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 common/gpt.c >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 i386/pmbr/pmbr.s >> >> GPT really wants the backup header at the last LBA. =C2=A0I know you can= set it, >> but I've interpreted that as a way to see if the primary header is corre= ct or >> not. [...] > > My interpretation is different: The way to verify if the header is valid > is to check its checksum, not to check if the backup header location in > the primary header points at the last LBA. > > Of course if primary header's checksum is incorrect it is hard to trust > that the backup header location is correct. And we need the backup > header when the primary header is invalid... > >> [...] It seems to me that GPT tables created in this fashion (inside a G= EOM >> provider) will not work properly with partition editors for other OS's. = =C2=A0I'm >> hesitant to encourage the use of this as I do think putting GPT inside o= f a >> gmirror violates the GPT spec. > > I don't think so. Most common case is to configure partitions on top of > a mirror. Mirroring partitions is less common. Mostly because of > hardware RAIDs being popular. You don't expect hardware RAID vendor to > mirror partitions. Partition editors for other OS's won't work, but only > because they don't support gmirror. If they wouldn't recognize and > support some hardware (or pseudo-hardware) RAIDs there will be the same > problem. > > In other words, IMHO, our problem is that FreeBSD's boot code doesn't > recognize/support gmirror's metadata. What Andrey is proposing is to > recognize the metadata and act accordingly - in case of a gmirror we > simply need to skip it. > > In the future we will have the same problem with graid - until we add > support for it to the boot code, we won't be able to boot from it. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixe= d. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 21:45:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A54B106566B; Tue, 26 Jun 2012 21:45:35 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id AC2898FC08; Tue, 26 Jun 2012 21:45:34 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 3CFFAB9A; Tue, 26 Jun 2012 23:45:33 +0200 (CEST) Date: Tue, 26 Jun 2012 23:43:31 +0200 From: Pawel Jakub Dawidek To: Kevin Oberman Message-ID: <20120626214330.GG1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nqkreNcslJAfgyzk" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jun 2012 21:45:35 -0000 --nqkreNcslJAfgyzk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 02:41:31PM -0700, Kevin Oberman wrote: > Long ago I saw a proposal to create a dedicated partition on GPT to > hold the metadata. With the large number of partitions available on > GPT, tying up one just for GEOM seems like a low price and it moves > the device GEOM out of the realm of FreeBSD unique and subject to > serious issues when/if a disk is shared with some other OS. I have > seen little comment on this and have never seen any argument that that > it could not work. >=20 > I think this is an issue that will continue to bite users unless it is fi= xed. I don't really see how dedicating a partition for metadata can work or is good idea, sorry. As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --nqkreNcslJAfgyzk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qLQEACgkQForvXbEpPzTlzQCdHI2jVnhsxBYTkouol8eq1q20 +QgAoIoNzb8kbd36nnE8J25zmBoL27XL =jd6L -----END PGP SIGNATURE----- --nqkreNcslJAfgyzk-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 26 23:46:14 2012 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 B58A8106564A; Tue, 26 Jun 2012 23:46:14 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC268FC0A; Tue, 26 Jun 2012 23:46:14 +0000 (UTC) X-AuditID: 12074422-b7f1f6d00000090b-4f-4fea48991856 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 54.F6.02315.9984AEF4; Tue, 26 Jun 2012 19:41:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q5QNfBGt006051; Tue, 26 Jun 2012 19:41:11 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5QNf8q7000063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2012 19:41:10 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q5QNf7Nu007992; Tue, 26 Jun 2012 19:41:07 -0400 (EDT) Date: Tue, 26 Jun 2012 19:41:07 -0400 (EDT) From: Benjamin Kaduk To: ken@freebsd.org In-Reply-To: <4FE9D958.4000901@protected-networks.net> Message-ID: References: <4FE9D958.4000901@protected-networks.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixCmqrDvT45W/wdpHXBYTrvxgslgwZS67 xapjT9gdmD1mfJrP4rFoykfGAKYoLpuU1JzMstQifbsErozjjcvYCp7KV2ybuJO1gbFPqouR k0NCwETi9Nt7bBC2mMSFe+uBbC4OIYF9jBLL2newQjgbGCX+NnxlB6kSEjjAJHGqvwYi0cAo 8fDjBmaQBIuAtsSJfZPAitgEVCRmvtkINlZEQFji9sqTYHFmAReJyas+gsWFgeyj308B9XJw cAqYSbT+9AEJ8wo4Sqx8ep0VYpepxJ/n25lAbFEBHYnV+6ewQNQISpyc+YQFYqSlxL+1v1gn MArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRlDIsrso7WD8 eVDpEKMAB6MSD28Eyyt/IdbEsuLK3EOMkhxMSqK8P5yAQnxJ+SmVGYnFGfFFpTmpxYcYJTiY lUR4f+sC5XhTEiurUovyYVLSHCxK4rzXUm76CwmkJ5akZqemFqQWwWRlODiUJHjXuwM1Chal pqdWpGXmlCCkmTg4QYbzAA1fBFLDW1yQmFucmQ6RP8WoKCXO2weSEABJZJTmwfXCUsorRnGg V4R574JU8QDTEVz3K6DBTECDOTa9ABlckoiQkmpgNGyYcjiTlfWtzuLP+24sz+N87NLI/IdH q3B9bbmq4X27f2V7T01qfXzzwY52c9szWRZX0vltVu5Vr9iyuvbqtrdeS44tuuU4Z7ecY/Dd kr2P75dK7+l99NHoEuu8TWtrs1x3dB36fyH+jc+kIo5JDYEBtaecV7b9a2uRCVC0WT9x35mD u9IslZVYijMSDbWYi4oTAUg3844EAwAA Cc: Michael Butler , current@freebsd.org Subject: Re: Removing an SDHC card causes a kernel panic on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 23:46:14 -0000 On Tue, 26 Jun 2012, Michael Butler wrote: > As follows, in "g_disk_providergone", a NULL pointer reference?: g_disk_providergone() is new in r237518 (by ken); ken cc'd. -Ben Kaduk > > imb@toshi:/home/imb> sudo less /var/crash/core.txt.4 > toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 > > Tue Jun 26 08:59:01 EDT 2012 > > FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD > 10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012 > imb@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI > i386 > > panic: page fault > > [ .. ] > > Unread portion of the kernel message buffer: > sdhci0-slot0: Card removed > mmc0: detached > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc070a4bc > stack pointer = 0x28:0xc6fb7c54 > frame pointer = 0x28:0xc6fb7c54 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (g_event) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 7m8s > Physical memory: 3045 MB > Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 > > Reading symbols from /boot/kernel/drm.ko...Reading symbols from > /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > Reading symbols from /boot/kernel/i915.ko...Reading symbols from > /boot/kernel/i915.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/i915.ko > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/modules/cuse4bsd.ko...done. > Loaded symbols for /boot/modules/cuse4bsd.ko > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > #0 doadump (textdump=1) at pcpu.h:244 > 244 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=1) at pcpu.h:244 > #1 0xc07ae76c in kern_reboot (howto=260) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449 > #2 0xc07aee41 in panic (fmt=0x104
) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637 > #3 0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022 > #4 0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936 > #5 0xc0af29ef in trap (frame=0xc6fb7c14) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546 > #6 0xc0adcbdc in calltrap () > at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169 > #7 0xc070a4bc in g_disk_providergone (pp=0xcb33ab80) > at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505 > #8 0xc070f8ba in g_destroy_provider (pp=0xcb33ab80) > at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643 > #9 0xc070fb6e in g_wither_washer () > at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462 > #10 0xc070cb62 in g_run_events () > at /usr/home/imb/svn/head/sys/geom/geom_event.c:289 > #11 0xc077bd8b in fork_exit (callout=0xc070de54 , > arg=0x0, > frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995 > #12 0xc0adcc84 in fork_trampoline () > at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276 > (kgdb) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 01:12:07 2012 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 566961065670; Wed, 27 Jun 2012 01:12:07 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id DCEE68FC12; Wed, 27 Jun 2012 01:12:06 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with ESMTP id q5R1BvJZ020524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jun 2012 20:11:57 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 26 Jun 2012 20:11:55 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <4FE7AD6E.7000301@cran.org.uk> Date: Tue, 26 Jun 2012 18:11:52 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <4FE7AD6E.7000301@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-26_05:2012-06-26, 2012-06-26, 1970-01-01 signatures=0 Cc: bapt@freebsd.org, freebsd-current@freebsd.org, Ron@FreeBSD.ORG, McDowell , Nathan Whitehorn , Devin Teske Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 01:12:07 -0000 Hi Bruce, On Jun 24, 2012, at 5:14 PM, Bruce Cran wrote: > On 21/06/2012 00:40, Devin Teske wrote: >> If you have the time and/or energy, please test and report any issues th= at you experience. >=20 > I've noticed a few typos and other minor issues: >=20 > In bsdconfig(8): > Contains a link to itself under SEE ALSO. > "bsdconfig takes a commands as an argument" - should be "command". >=20 Fixed. > bsdconfig mouse: > Typo "se Configuration menu". > "Please Specify the mouse daemon flags" - don't need upper-case S. >=20 Fixed. > bsdconfig hostname: > The example should probably be in the example.com domain. >=20 Replaced with "full.example.com" > bsdconfig netdev: > "Select a TCP/IP network interface to configure" doesn't need "TCP/IP". >=20 Done. > bsdconfig nameservers: > "Please enter the new TCP/IP address of the DNS nameserver" should just = be "IP address". "TCP/IP" is being used where just "IP" was needed in other= places too. >=20 Done. > 'bsdconfig command -h' doesn't always work: >=20 Enough people complained about this, that=85 it too is "fixed" (though I ar= gue that there's absolutely nothing wrong with having "-h" be invalid to ge= topts -- the end result is the same with exception to the "illegal option -= h" extra-line of output that everybody seems to complain about. Also mind y= ou, that much of the FreeBSD Operating System suffers from this ""bug"" > > bsdconfig hostname -h > Illegal option -h >=20 Like "tzsetup -h" and many others that are this way. I just can't win (inco= nsistencies everywhere in the system w/respect to this). --=20 Devin P.S. Fixes are in the up-coming 0.7.3 PORTVERSION of sysutils/bsdconfig. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 02:16:06 2012 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 C00861065670; Wed, 27 Jun 2012 02:16:06 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 562538FC0C; Wed, 27 Jun 2012 02:16:06 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5R2Fxax070894; Wed, 27 Jun 2012 10:16:00 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340763363.2147.1.camel@nsl> From: Kevin Lo To: Konstantin Belousov Date: Wed, 27 Jun 2012 10:16:03 +0800 In-Reply-To: <20120626102424.GL2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:16:06 -0000 Konstantin Belousov wrote: > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > Konstantin Belousov wrote: > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > I've observed a panic in recent -current several times but I only > > > > have a picture of the backtrace: > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > Does this look at all familiar to anyone? > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > in your kernel ? > > > > Sure. > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > is int 0x28 which should not appear in the compiled code. > > > > # gdb tmpfs.ko > > (gdb) l *tmpfs_reg_resize+0x627 > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005). > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > > In tmpfs_subr.c: > > 999 if (m != NULL) { > > 1000 if ((m->oflags & VPO_BUSY) != 0 || > > 1001 m->busy != 0) { > > 1002 vm_page_sleep(m, "tmfssz"); > > 1003 goto retry; > > 1004 } > > 1005 MPASS(m->valid == VM_PAGE_BITS_ALL); > > 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU > > LL)) { > > > Hm, can you get a core and > - obtain backtrace in kgdb; > - print the *m content for the page that triggered the assertion ? > > The only possible 'new size' value for the truncation from open(2) is zero, > so I do not understand why the asserted block was executed at all. Thanks for looking into it. Unfortunately I can't get a crash dump due to lack of disk space and memory. Kevin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 02:29:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71828106566C for ; Wed, 27 Jun 2012 02:29:16 +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 363F98FC12 for ; Wed, 27 Jun 2012 02:29:16 +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 q5R2TALo000183; Tue, 26 Jun 2012 20:29:10 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q5R2TAND000182; Tue, 26 Jun 2012 20:29:10 -0600 (MDT) (envelope-from ken) Date: Tue, 26 Jun 2012 20:29:09 -0600 From: "Kenneth D. Merry" To: Michael Butler Message-ID: <20120627022909.GA153@nargothrond.kdm.org> References: <4FE9D958.4000901@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: Benjamin Kaduk , current@freebsd.org Subject: Re: Removing an SDHC card causes a kernel panic on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:29:16 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: > On Tue, 26 Jun 2012, Michael Butler wrote: > > >As follows, in "g_disk_providergone", a NULL pointer reference?: > > g_disk_providergone() is new in r237518 (by ken); ken cc'd. Can you try the attached patch to sys/geom/geom_disk.c? Also, do you have full dmesg information for when the panic happened? It looks like disk_destroy() has already been called in this case, and I suppose that's likely to happen for any of the users of the GEOM disk class that haven't been updated with the reference count changes I made in da(4). (i.e. all of the rest of them.) Let me know whether this works for you. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="geom_disk.c.20120626.1.txt" ==== //depot/users/kenm/FreeBSD-test2/sys/geom/geom_disk.c#7 - /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.c ==== *** /tmp/tmp.75357.20 Tue Jun 26 20:25:44 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.c Tue Jun 26 20:25:29 2012 *************** *** 502,507 **** --- 502,515 ---- struct g_disk_softc *sc; sc = (struct g_disk_softc *)pp->geom->softc; + + /* + * If the softc is already NULL, then we've probably been through + * g_disk_destroy already; there is nothing for us to do anyway. + */ + if (sc == NULL) + return; + dp = sc->dp; if (dp->d_gone != NULL) --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 04:50:29 2012 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 C8752106566B; Wed, 27 Jun 2012 04:50:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id E40748FC16; Wed, 27 Jun 2012 04:50:28 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward5.mail.yandex.net (Yandex) with ESMTP id 3049C1202173; Wed, 27 Jun 2012 08:50:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772627; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=V0KMa3FlUKD5mTLAcU+DGAQJXYdIiIw66qZ4EYkP2ENJSLs/dCDYH+P5UPN7yWKDa UNSXrBrmWM2o9so7ozQBwzMu8QBAhj+T0rDHxc2y2fr6wUzcQzzTtrPDcREVWj8vwj +dBaRQtp3iER7uxC/cRlgLIXqLOY+9vaplEcU198= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id A54C95C03D0; Wed, 27 Jun 2012 08:50:26 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oQF8H3nW-oQFuT0r9; Wed, 27 Jun 2012 08:50:26 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@FreeBSD.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772626; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=SHkEl6mwykxDo2ZsiFh65M8SWNef1ho1iHRzLpO3kdj3UED58Q8OiuLhUDBo6yeEp 940qifykcM1LD2heDWry4ceIj6HnkjryD+G0Y/RsLjwHolF0iMHa1MBqTwMdBYhvpk 7WXif3IIHm6L4vki3NL0boSRicURNVGREWfQQPtI= Message-ID: <4FEA910C.4090305@yandex.ru> Date: Wed, 27 Jun 2012 08:50:20 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig43DFB080B9C277186794B58A" Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 04:50:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig43DFB080B9C277186794B58A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26.06.2012 21:37, John Baldwin wrote: >> 4. The gptboot now searches the backup GPT header in the previous sect= ors, >> when it finds the "GEOM::" signature in the last sector. PMBR code als= o >> tries to do the same: >> common/gpt.c >> i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > provider) will not work properly with partition editors for other OS's.= I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > gmirror violates the GPT spec. The standard says: "The following test must be performed to determine if a GPT is valid: =E2=80=A2 Check the Signature =E2=80=A2 Check the Header CRC =E2=80=A2 Check that the MyLBA entry points to the LBA that contains the = GUID Partition Table =E2=80=A2 Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the de= vice to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array." For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our l= oader for the better supporting of our technologies. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partit= ion editor, it might overwrite the last sector and might don't. >> 5. Also the pmbr image now contains one fake partition record. >> When several first sectors are damaged the kernel can't detect GPT >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(= 1) >> command, but the old pmbr image has an empty partition table and >> loader doesn't able to boot from GPT, when there is no partition recor= d >> in the PMBR. Now it will be able. When pmbr is installed via 'gpart=20 > bootcode' >> command, the kernel correctly modifies this partition record. So, this= is=20 > only >> for the first rescue step. >=20 > As I said earlier, I do not think this is appropriate and that instead > gpart should have an appropriate 'recover' command to install just the = pmbr on=20 > a disk and also create a correct entry in the MBR if needed while doing= so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEO= M class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpar= t(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool = to install zfsboot. --=20 WBR, Andrey V. Elsukov --------------enig43DFB080B9C277186794B58A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6pERAAoJEAHF6gQQyKF6pPkH/iWeqKnlQRc7jDKVoWb8iabJ 1lmJ+cv96Ypq+DoTVaRwrRCQIRt3z2E3l4IUVgKFnJODSZt6G2Grl7IjOwD5aZ90 fU7d5qIRWih3t+w6+zH9yFzPbzc4aq/CV/7fFlrtjXSaYFe7PqEYLFxtg32prGch Jd9kqSOq0mDnue0hPfTFHgHmG3gGh+eQ3Kffs6rDMEMMArMKP7xEunESAsfO7Rl8 2EBbnP2Wz8unzqwRO+Z2gAbyTHyNRjkVVs0mzsLiFseCxdPnIOkGMYLOx9bCOwNs AUASvIYDrB9waAK59NS8S3xnw8F/F81lT2i+GWvhvsNtQWMk5kXbLWjr1i9AmV4= =9ix4 -----END PGP SIGNATURE----- --------------enig43DFB080B9C277186794B58A-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 04:58:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2DF106564A; Wed, 27 Jun 2012 04:58:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id 93D3E8FC0A; Wed, 27 Jun 2012 04:58:28 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward5.mail.yandex.net (Yandex) with ESMTP id 8FF6F120012A; Wed, 27 Jun 2012 08:58:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340773107; bh=IOn+vWA5i0FuYEC3B+O4kVGcvgON9IREmvlGMKKFoww=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=TalgQTFGGYxzhR0PBVGdviYwRps6rVvezrCOCiBbq7kAdiTM/4e1t42L4fgLrUYwV NRKLcPURiD+NGxgmMOG0PlFpP4NMSQCxwBweG00BrrXwv89dILgBlArl6kGhHYWGt9 z7aKlEqsGWUyWMzcxHFUg8GUbuuyQOpdFaekhqD0= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 45072E2031B; Wed, 27 Jun 2012 08:58:27 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id wQYWhteA-wQYqscUG; Wed, 27 Jun 2012 08:58:26 +0400 X-Yandex-Rcpt-Suid: kob6558@gmail.com X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340773107; bh=IOn+vWA5i0FuYEC3B+O4kVGcvgON9IREmvlGMKKFoww=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=K3KEKMaRNPf+HlkJIokxpWE7L6fkVRTZjxsi7nmt/4KbfpFpJcv04lb3wgYX7nvpa O+SfIbmuyFmOYAoifEWeYK4Pqi1TjtO0zIZSHGbnFsBPr+VEpEf02De7FU8AiyEk3r Tz7nGNuK8EeBoI46qP/42zF1GOpXrXjmerbI05OM= Message-ID: <4FEA92EE.8090202@yandex.ru> Date: Wed, 27 Jun 2012 08:58:22 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Kevin Oberman References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD250C2D8C236335AFD7CB710" Cc: freebsd-hackers , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 04:58:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD250C2D8C236335AFD7CB710 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 27.06.2012 1:41, Kevin Oberman wrote: > Long ago I saw a proposal to create a dedicated partition on GPT to > hold the metadata. With the large number of partitions available on > GPT, tying up one just for GEOM seems like a low price and it moves > the device GEOM out of the realm of FreeBSD unique and subject to > serious issues when/if a disk is shared with some other OS. I have > seen little comment on this and have never seen any argument that that > it could not work. When you share some disk with another OS, it seems that much serious issue will be when other OS did some changes in your mirror without you knowing. I know about successful sharing of the disk between Windows and FreeBSD via graid on the Intel pseudo raid. Just use compatible techn= ologies. --=20 WBR, Andrey V. Elsukov --------------enigD250C2D8C236335AFD7CB710 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6pLyAAoJEAHF6gQQyKF6DqAH/jDCzuym1zHrJigHP3pal8HB QMRo4LF8f4OWR3EXTqFwnYhzHwpQgjUfSKsfN8vyA1QfHy4ZEBFt0Ms/+RSBA9Ec x4hsct9OeFuLCRlaSXYP+eyCSY/YMdute2M97l2Xd6j6Tzcb5FvOjh2HfdfD92Iw EiBRYjuTstSl2ZweV5ngreUt4KH2RAcdvKCtqpKW687Akc/uNi4nG2NBxjEjQnWM FXGXNMHHd6tjRTJIhm1OiWk/eKTUiZGMloW3PtwtGqTafC3yFg40W9lwNjwJJJS8 kOCwVG+3v+v45qj4BHYTrciovfolcIjEsAn8XLxOeqOpR1gBERzF4VwPZKuBWSU= =uJFg -----END PGP SIGNATURE----- --------------enigD250C2D8C236335AFD7CB710-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:06:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EE10106564A for ; Wed, 27 Jun 2012 05:06:36 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id DF61E8FC08 for ; Wed, 27 Jun 2012 05:06:35 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5R56W9U028768 for ; Tue, 26 Jun 2012 23:06:34 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Wed, 27 Jun 2012 12:06:30 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201206271206.30639.erichfreebsdlist@ovitrap.com> Subject: Panic on current from yesterday 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: Wed, 27 Jun 2012 05:06:36 -0000 Hi, I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. The panic regards /usr/src/sys/vm/uma_core/c line 2040. The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. How could I help you there? I would need some hand holding there as I am travelling at the moment and have only this machine with me without much documentation available. Moving back to this FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Thu Jun 21 14:29:15 WIT 2012 solves the problem for me. Erich From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:19:45 2012 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 A6FA6106564A; Wed, 27 Jun 2012 05:19:45 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id EDA328FC0A; Wed, 27 Jun 2012 05:19:44 +0000 (UTC) Received: from [188.174.54.18] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SjkfH-0001O2-Rs; Wed, 27 Jun 2012 07:19:44 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q5R5JgYa002487; Wed, 27 Jun 2012 07:19:42 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q5R5JfOU002486; Wed, 27 Jun 2012 07:19:41 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 27 Jun 2012 07:19:41 +0200 From: Matthias Apitz To: John Baldwin Message-ID: <20120627051941.GA2468@tinyCurrent> References: <20120615094837.GA1440@tiny.Sisis.de> <201206150818.22208.jhb@freebsd.org> <20120616085106.GA3213@tinyCurrent> <201206160811.40632.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201206160811.40632.jhb@freebsd.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.54.18 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: swills@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic's in 10-CURRENT r235646 in VMware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:19:45 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Saturday, June 16, 2012 a las 08:11:40AM -0400, John Baldwin escribió: > On Saturday, June 16, 2012 04:51:06 AM Matthias Apitz wrote: > > El día Friday, June 15, 2012 a las 08:18:22AM -0400, John Baldwin escribió: > > > > the panic says: > > > > mutex page lock not owned at /usr/src/sys/vm/vm_page.c:2060 > > > > > > > > I have a screen shoot here: > > > > http://www.unixarea.de/aurora-panic.gif > > > > > > > > Installed and started (via rc.conf) is the port open-vm-tools-425873,1; > > > > > > > > Thx > > > > > > > > matthias > > > > > > Can you get a stack trace? The attached patch file (to be replaced in open-vm-tools/files/patch-vmmemctl-os.c) solved the problem for me; thanks, John matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:27:43 2012 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 04E931065670 for ; Wed, 27 Jun 2012 05:27:43 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF2A48FC17 for ; Wed, 27 Jun 2012 05:27:42 +0000 (UTC) Received: by obbun3 with SMTP id un3so1204101obb.13 for ; Tue, 26 Jun 2012 22:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cJMVkOdwGZL28QczwCH4UyZNt/lT3xd3aKSmOwnkfG8=; b=TvFssRfmS8f92GJ+f19hGgyo8XKT+LprvWz9PoeUGOwKRb+BqKPs5Z2assUXKtvlav nO03ABOJaD1kS1y8gLJnhPjuHO77IGgt5NnZLsYm5glecKB09+9PtxZpFK024GeqEWaP RnXsqVRvh7HUOfyqG/1EHmHbHKYPQqda8kktUiOy+tX7GHL/jCm4Pkp2Uu2rN7qLWrgv Le8ZcSWrWAiIoAJOVHIXwc4ySxV4pUKuLjT8sRRjuuYx08yPh1TQy+zh2U59ZkK2Dpf8 u0qrO+n2HYCr1PZ/bK4P7JYTuP0w3UY9fdjExumd+IN/zbHSGDVeyIM2L2cBdcFSTiDN WhqQ== MIME-Version: 1.0 Received: by 10.60.2.105 with SMTP id 9mr18983732oet.65.1340774862172; Tue, 26 Jun 2012 22:27:42 -0700 (PDT) Received: by 10.60.14.42 with HTTP; Tue, 26 Jun 2012 22:27:42 -0700 (PDT) In-Reply-To: <201206271206.30639.erichfreebsdlist@ovitrap.com> References: <201206271206.30639.erichfreebsdlist@ovitrap.com> Date: Wed, 27 Jun 2012 09:27:42 +0400 Message-ID: From: Andrey Fesenko To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 05:27:43 -0000 On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky wrote: > Hi, > > I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. > > The panic regards /usr/src/sys/vm/uma_core/c line 2040. > > The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. > confirm faced with the same error FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:29:22 2012 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 7A0671065675; Wed, 27 Jun 2012 05:29:22 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id E28FA8FC1B; Wed, 27 Jun 2012 05:29:21 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5R5T9Um071536; Wed, 27 Jun 2012 13:29:09 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340774954.2147.3.camel@nsl> From: Kevin Lo To: Konstantin Belousov Date: Wed, 27 Jun 2012 13:29:14 +0800 In-Reply-To: <1340763363.2147.1.camel@nsl> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:29:22 -0000 Kevin Lo wrote: > Konstantin Belousov wrote: > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > Konstantin Belousov wrote: > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > I've observed a panic in recent -current several times but I only > > > > > have a picture of the backtrace: > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > > in your kernel ? > > > > > > Sure. > > > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > > is int 0x28 which should not appear in the compiled code. > > > > > > # gdb tmpfs.ko > > > (gdb) l *tmpfs_reg_resize+0x627 > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005). > > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > > > > In tmpfs_subr.c: > > > 999 if (m != NULL) { > > > 1000 if ((m->oflags & VPO_BUSY) != 0 || > > > 1001 m->busy != 0) { > > > 1002 vm_page_sleep(m, "tmfssz"); > > > 1003 goto retry; > > > 1004 } > > > 1005 MPASS(m->valid == VM_PAGE_BITS_ALL); > > > 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU > > > LL)) { > > > > > Hm, can you get a core and > > - obtain backtrace in kgdb; > > - print the *m content for the page that triggered the assertion ? > > > > The only possible 'new size' value for the truncation from open(2) is zero, > > so I do not understand why the asserted block was executed at all. > > Thanks for looking into it. Unfortunately I can't get a crash dump > due to lack of disk space and memory. I triggered the KASSERT on a different machine in the last hour. panic: Assertion (vp) !=NULL && (vp)->v_data != NULL failed at @/fs/tmpfs/tmpfs.h:527 The bad news is my coworker rebooted that machine after panic :-( Kevin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:51:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A0A5106564A; Wed, 27 Jun 2012 05:51:18 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id E57888FC1C; Wed, 27 Jun 2012 05:51:17 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 8862FE6561; Wed, 27 Jun 2012 06:52:20 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=msZQbSiF1zKo Bk6Z9+w2iSWKQPI=; b=uP1FbZaR7kERRou5893BY8nGL9rpEyBwxyb1pGZzJ/ef f46hxpD0iGrGweldS5vFgzXz06InjSHaMy0yHR9yekwJtBCOVQ7OH/lfqPtcHa/5 uoBhMoiE6g0N9P0RNjs2mlti9x7dLBgzjG7lYPcVKF1b0JAYSpSys8XUlKYUYO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=fb7onZ UEyPLelA9f8uKDdmQL4rllsdtp53vlkYGv5pV2AMkNj2NNVbOZeH0vtg4XI4RhRD 0o80NbR2hqER+ue1UaUFAtCs08Su0zW8uqIEETwgd1tIVzKUhZWiwLTl5PZ8J61l aDEm2FBNw0d7A90ZA6RbXjc0gB7lDrocCWzW4= Received: from [IPv6:2a01:348:102:2:6ccf:a960:b511:2e21] (unknown [IPv6:2a01:348:102:2:6ccf:a960:b511:2e21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 3C7BFE64EF; Wed, 27 Jun 2012 06:52:20 +0100 (BST) Message-ID: <4FEA9F18.5070001@cran.org.uk> Date: Wed, 27 Jun 2012 06:50:16 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <4FE7AD6E.7000301@cran.org.uk> <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> In-Reply-To: <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: bapt@freebsd.org, freebsd-current@freebsd.org, Devin Teske , Ron@FreeBSD.ORG, McDowell , Nathan Whitehorn Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 05:51:18 -0000 On 27/06/2012 02:11, Devin Teske wrote: > Like "tzsetup -h" and many others that are this way. I just can't win > (inconsistencies everywhere in the system w/respect to this). Not at all: bsdconfig claims to support -h whereas tzsetup doesn't: SYNOPSIS tzsetup [-nrs] [-C chroot_directory] [zoneinfo_file | zoneinfo_name] SYNOPSIS bsdconfig [-h] bsdconfig command [-h] bsdconfig [OPTIONS] [command [OPTIONS]] -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 05:53:53 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E209B106566C; Wed, 27 Jun 2012 05:53:53 +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 84BD38FC0C; Wed, 27 Jun 2012 05:53:52 +0000 (UTC) Received: from porto.starpoint.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 IAA12918; Wed, 27 Jun 2012 08:53:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SjlCI-000M3I-5C; Wed, 27 Jun 2012 08:53:50 +0300 Message-ID: <4FEA9FED.9040408@FreeBSD.org> Date: Wed, 27 Jun 2012 08:53:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> In-Reply-To: <4FEA910C.4090305@yandex.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 05:53:54 -0000 on 27/06/2012 07:50 Andrey V. Elsukov said the following: > Also we still haven't any tool to install zfsboot. Yeah, I think it would be nice if ZFS provided some interface (ioctl?) to properly write stuff to its special areas. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 06:05:00 2012 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 ADA951065673 for ; Wed, 27 Jun 2012 06:05:00 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 604248FC12 for ; Wed, 27 Jun 2012 06:05:00 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 5C2C014E7AC6; Wed, 27 Jun 2012 08:04:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6EuSI7mBte7l; Wed, 27 Jun 2012 08:04:51 +0200 (CEST) Received: from [84.225.78.140] (netacc-gpn-5-78-140.pool.telenor.hu [84.225.78.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AE02114E7A64; Wed, 27 Jun 2012 08:04:50 +0200 (CEST) Message-ID: <4FEAA280.2070705@FreeBSD.org> Date: Wed, 27 Jun 2012 08:04:48 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko Subject: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:05:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/qooAACgkQkC3QTyNzprELpgCgo1hBQzT/Ns2pnWe3kjn06oIU ddgAn2NyYkRY7vvPK84ZQFkPG9afL0ib =iAEI -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 06:11:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC9A41065676; Wed, 27 Jun 2012 06:11:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 90C118FC08; Wed, 27 Jun 2012 06:11:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SjlT4-0006ft-Qw>; Wed, 27 Jun 2012 08:11:10 +0200 Received: from e178010049.adsl.alicedsl.de ([85.178.10.49] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SjlT4-0000pY-LW>; Wed, 27 Jun 2012 08:11:10 +0200 Message-ID: <4FEAA3F8.4020906@zedat.fu-berlin.de> Date: Wed, 27 Jun 2012 08:11:04 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gabor Kovesdan References: <4FEAA280.2070705@FreeBSD.org> In-Reply-To: <4FEAA280.2070705@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D421C36DD651A0F21AD0DA5" X-Originating-IP: 85.178.10.49 Cc: FreeBSD Current , Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:11:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D421C36DD651A0F21AD0DA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/27/12 08:04, Gabor Kovesdan wrote: > Hi Folks, >=20 > as I announced before, the default sort in -CURRENT has been changed > to BSD sort. Since the import, the reported minor bugs have been > fixed and BSD sort has passed the portbuild test. If you encounter any > problems or incompatibility with the old GNU version, please report. >=20 > Gabor =2E.. so, can I delete the entry WITH_BSD_SORT=3Dyes in /etc/src.conf then? Regards, Oliver --------------enig4D421C36DD651A0F21AD0DA5 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.19 (FreeBSD) iQEcBAEBAgAGBQJP6qP+AAoJEOgBcD7A/5N8TO0H/0d/Mr15eKwug+KjCsMqmI6B w0IYj2RGjMCwxdJELtSgVjcVPC+smpsu0upgwh+yaD7mR00xQDqe5vFvmtx3poJN oEvil0VwW3x5xqqXlutIbeOpeyym5etw/gIkoWjBZNFcYwcvLs6ZJfVXdDhvkeb9 e9os+ug8Lm9Fraqry5jxOsHgS/lFdWotRvwoZ9ZnMYmyf4C0nWHBkh0kN/6s5FYO DrMdPQhvwFUKb5aiYhRfWvENmj3vSqi31ZThsIPPIdifrZWrnvvTMulpM8GjGZFh kni/oesgmihh3S5avErI//CPyzQf5JjcZGA3ZTl5bMgOwm9gokr017HHPX55K+c= =d3kB -----END PGP SIGNATURE----- --------------enig4D421C36DD651A0F21AD0DA5-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 06:18:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id EA396106564A; Wed, 27 Jun 2012 06:18:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5809C14F009; Wed, 27 Jun 2012 06:18:01 +0000 (UTC) Message-ID: <4FEAA599.9070107@FreeBSD.org> Date: Tue, 26 Jun 2012 23:18:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gabor Kovesdan References: <4FEAA280.2070705@FreeBSD.org> In-Reply-To: <4FEAA280.2070705@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:18:04 -0000 On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: > Hi Folks, > > as I announced before, the default sort in -CURRENT has been changed > to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? > Since the import, the reported minor bugs have been > fixed and BSD sort has passed the portbuild test. If you encounter any > problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 06:20:17 2012 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 B9BA71065676 for ; Wed, 27 Jun 2012 06:20:17 +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 0D7208FC08 for ; Wed, 27 Jun 2012 06:20:16 +0000 (UTC) Received: from porto.starpoint.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 JAA13149; Wed, 27 Jun 2012 09:20:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Sjlbn-000M51-BI; Wed, 27 Jun 2012 09:20:11 +0300 Message-ID: <4FEAA61A.30402@FreeBSD.org> Date: Wed, 27 Jun 2012 09:20:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrey Fesenko , Erich Dollansky References: <201206271206.30639.erichfreebsdlist@ovitrap.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 06:20:17 -0000 on 27/06/2012 08:27 Andrey Fesenko said the following: > On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky > wrote: >> Hi, >> >> I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. >> >> The panic regards /usr/src/sys/vm/uma_core/c line 2040. >> >> The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. >> > > confirm faced with the same error > FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 You haven't provided a full stack trace, but let me take a guess: http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167 Perhaps this could be useful. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 06:48:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D7361065673; Wed, 27 Jun 2012 06:48:56 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 99CA98FC14; Wed, 27 Jun 2012 06:48:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,481,1336363200"; d="scan'208";a="29561071" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 02:48:54 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Tue, 26 Jun 2012 23:48:54 -0700 From: Oleg Moskalenko To: 'Doug Barton' , Gabor Kovesdan Date: Tue, 26 Jun 2012 23:48:53 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1ULJ2cJkllmWK1Q6yjHt8LuolkWwAAdJCA Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> In-Reply-To: <4FEAA599.9070107@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Current Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:48:56 -0000 > -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Tuesday, June 26, 2012 11:18 PM > To: Gabor Kovesdan > Cc: FreeBSD Current; Oleg Moskalenko > Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: > > Hi Folks, > > > > as I announced before, the default sort in -CURRENT has been changed > > to BSD sort. >=20 > Has this been performance tested vs. the old one? If so, where are the > results? Of course it was performance-tested. As this is a totally different program= with different=20 algorithms, it has totally different performance profile on different tests= , comparing to the old sort. In the default compilation mode (single thread s= ort)=20 the performance is on the same level as the old sort (sometimes faster, som= etimes slower).=20 The new sort is often significantly faster in numeric sort tests. In "exper= imental" multi-threading=20 mode, the new sort is much faster than the old sort on multi-CPU systems. The sort speed comparison is not actually fair because the old sort cuts so= me corners and=20 has a number of bugs. The concrete figures do not have much sense because you change the sort fil= e and you get a totally=20 different performance ratio.=20 >=20 > > Since the import, the reported minor bugs have been > > fixed and BSD sort has passed the portbuild test. If you encounter > any > > problems or incompatibility with the old GNU version, please report. >=20 > Has this been thoroughly regression-tested against the old version, > option by option? Of course we have the regression tests. We have an overnight test that runs= through=20 probably 17 millions various sort option combinations. But we actually had= to compare=20 the new sort against a fresh GNU sort implementation (version 8.15), becaus= e the old BSD GNU sort=20 is very buggy and testing against the old GNU sort has no sense. Oleg From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 08:34:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C57F11065670; Wed, 27 Jun 2012 08:34:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6B9D21545A9; Wed, 27 Jun 2012 08:34:57 +0000 (UTC) Message-ID: <4FEAC5B1.30104@FreeBSD.org> Date: Wed, 27 Jun 2012 01:34:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Oleg Moskalenko References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Gabor Kovesdan Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:34:57 -0000 On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: > > >> -----Original Message----- From: Doug Barton >> [mailto:dougb@FreeBSD.org] Sent: Tuesday, June 26, 2012 11:18 PM >> To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: >> Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >> >> On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: >>> Hi Folks, >>> >>> as I announced before, the default sort in -CURRENT has been >>> changed to BSD sort. >> >> Has this been performance tested vs. the old one? If so, where are >> the results? > > Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. > As this is a totally different > program with different algorithms, it has totally different > performance profile on different tests, comparing to the old sort. In > the default compilation mode (single thread sort) the performance is > on the same level as the old sort (sometimes faster, sometimes > slower). The new sort is often significantly faster in numeric sort > tests. In "experimental" multi-threading mode, the new sort is much > faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? > The sort speed comparison is not actually fair because the old sort > cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) > The concrete figures do not have much sense because you change the > sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. >> Has this been thoroughly regression-tested against the old >> version, option by option? > > Of course we have the regression tests. We have an overnight test > that runs through probably 17 millions various sort option > combinations. This sounds great, but ... > But we actually had to compare the new sort against a > fresh GNU sort implementation (version 8.15), because the old BSD GNU > sort is very buggy and testing against the old GNU sort has no > sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 08:39:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EED9E1065672; Wed, 27 Jun 2012 08:39:08 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9348FC0C; Wed, 27 Jun 2012 08:39:08 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5R8d6og007955; Wed, 27 Jun 2012 02:39:07 -0600 From: Erich Dollansky To: Andriy Gapon Date: Wed, 27 Jun 2012 15:39:04 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> In-Reply-To: <4FEAA61A.30402@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206271539.04926.erichfreebsdlist@ovitrap.com> Cc: Andrey Fesenko , freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 08:39:09 -0000 Hi, On Wednesday 27 June 2012 13:20:10 Andriy Gapon wrote: > on 27/06/2012 08:27 Andrey Fesenko said the following: > > On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky > > wrote: > >> Hi, > >> > >> I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. > >> > >> The panic regards /usr/src/sys/vm/uma_core/c line 2040. > >> > >> The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. > >> > > > > confirm faced with the same error > > FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 > > You haven't provided a full stack trace, but let me take a guess: > http://article.gmane.org/gmane.os.freebsd.devel.cvs/477167 this is a direct hit. > Perhaps this could be useful. I assume that you do not need one then. Anyway, What would be a save way to get a trace to a disk as I do not have a backup system with me? Erich From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 08:42:49 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72051106566C for ; Wed, 27 Jun 2012 08:42:49 +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 BC7ED8FC17 for ; Wed, 27 Jun 2012 08:42:48 +0000 (UTC) Received: from porto.starpoint.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 LAA14485; Wed, 27 Jun 2012 11:42:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Sjnpk-000MDw-PR; Wed, 27 Jun 2012 11:42:44 +0300 Message-ID: <4FEAC783.6020308@FreeBSD.org> Date: Wed, 27 Jun 2012 11:42:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Erich Dollansky References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> <201206271539.04926.erichfreebsdlist@ovitrap.com> In-Reply-To: <201206271539.04926.erichfreebsdlist@ovitrap.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 08:42:49 -0000 on 27/06/2012 11:39 Erich Dollansky said the following: > Anyway, What would be a save way to get a trace to a disk as I do not have a > backup system with me? Assuming I understand the question correctly your options are: - remote console (serial/firewire/etc) from another machine - digital camera - produce a crash dump (possible only after a certain point in boot sequence) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 08:49:11 2012 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 55EFC1065687; Wed, 27 Jun 2012 08:49:11 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 045EC8FC14; Wed, 27 Jun 2012 08:49:10 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5R8n9CA009937; Wed, 27 Jun 2012 02:49:10 -0600 From: Erich Dollansky To: Andriy Gapon Date: Wed, 27 Jun 2012 15:49:08 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> In-Reply-To: <4FEAC783.6020308@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206271549.08192.erichfreebsdlist@ovitrap.com> Cc: freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 08:49:11 -0000 Hi, On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote: > on 27/06/2012 11:39 Erich Dollansky said the following: > > Anyway, What would be a save way to get a trace to a disk as I do not have a > > backup system with me? > > Assuming I understand the question correctly your options are: > - remote console (serial/firewire/etc) from another machine this is the problem as I do not have it here. > - digital camera So, this is really the only option then. The photos I really have. Would you still need them? I do not think so after seeing the other post. > - produce a crash dump (possible only after a certain point in boot sequence) I think that this was too early. Erich From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 09:09:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82D33106566C; Wed, 27 Jun 2012 09:09:51 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4568FC15; Wed, 27 Jun 2012 09:09:51 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="29572839" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 05:09:49 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Wed, 27 Jun 2012 02:09:49 -0700 From: Oleg Moskalenko To: 'Doug Barton' Date: Wed, 27 Jun 2012 02:09:48 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1UP728ja9mBd0aTX+CmU3Hs40vggAAqdBw Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> In-Reply-To: <4FEAC5B1.30104@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Current , Gabor Kovesdan Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:09:51 -0000 Doug, I'll post some performance figures, probably tomorrow. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. If some old scripts are relying on buggy behavior=20 (and I hope they are not) then the old scripts must be fixed. Period. The system cannot grow replicating the old bugs. All system scripts that I've seen are using pretty basic sort features. In = the basic area, the old sort and the new sort are 100% compatible. The incompatibilit= ies are=20 in more complex areas (numeric sorts and unusual key-based sorts). I am actually tested the new sort against the old GNU sort. There are some = incompatibilities.=20 All of them are due to the bugs of the old GNU sort. The new BSD sort progr= am is compatible with the new GNU sort, a much cleaner program than the old GN= U sort. Try to install the new GNU coreutils. If the scripts can work with the new = GNU sort=20 (version 8.15 and later) than they will work with the new BSD sort. There is a POSIX standard, and the program must be compatible with the POSI= X standard. Take care, Oleg > -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Wednesday, June 27, 2012 1:35 AM > To: Oleg Moskalenko > Cc: Gabor Kovesdan; FreeBSD Current > Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: > > > > > >> -----Original Message----- From: Doug Barton > >> [mailto:dougb@FreeBSD.org] Sent: Tuesday, June 26, 2012 11:18 PM > >> To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: > >> Re: [HEADS-UP] BSD sort is the default sort in -CURRENT > >> > >> On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: > >>> Hi Folks, > >>> > >>> as I announced before, the default sort in -CURRENT has been > >>> changed to BSD sort. > >> > >> Has this been performance tested vs. the old one? If so, where are > >> the results? > > > > Of course it was performance-tested. >=20 > Great, can you post the results somewhere? I understand what you're > saying below that there are situations where worse performance may need > explanation, but it would be helpful if we had the data to look at. >=20 > > As this is a totally different > > program with different algorithms, it has totally different > > performance profile on different tests, comparing to the old sort. In > > the default compilation mode (single thread sort) the performance is > > on the same level as the old sort (sometimes faster, sometimes > > slower). The new sort is often significantly faster in numeric sort > > tests. In "experimental" multi-threading mode, the new sort is much > > faster than the old sort on multi-CPU systems. >=20 > This sounds encouraging. Is there a knob to enable the threaded build? >=20 > > The sort speed comparison is not actually fair because the old sort > > cuts some corners and has a number of bugs. >=20 > Understood, but the existing sort is what we're changing away from, so > that's what we have to test against. What we don't want is a situation > where we are switching to the new sort by default without understanding > what the tradeoffs are. (IOW, we don't want a repeat of the situation > with grep.) >=20 > > The concrete figures do not have much sense because you change the > > sort file and you get a totally different performance ratio. >=20 > I'm assuming that you'd run the performance tests on various different > input files, and report the different results. >=20 > >> Has this been thoroughly regression-tested against the old > >> version, option by option? > > > > Of course we have the regression tests. We have an overnight test > > that runs through probably 17 millions various sort option > > combinations. >=20 > This sounds great, but ... >=20 > > But we actually had to compare the new sort against a > > fresh GNU sort implementation (version 8.15), because the old BSD GNU > > sort is very buggy and testing against the old GNU sort has no > > sense. >=20 > ... this not so much. The existing sort is what people have now, and > what they rely on, particularly for scripts. Comparing apples to > oranges > doesn't help us understand how things are going to be different with > the > new version. >=20 > Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 09:26:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75300106566C; Wed, 27 Jun 2012 09:26:33 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB448FC0C; Wed, 27 Jun 2012 09:26:32 +0000 (UTC) Received: by ggnm2 with SMTP id m2so828598ggn.13 for ; Wed, 27 Jun 2012 02:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hSD0LDw1qA5UZUQK5+iYCcS0Sy+8Bwe+rui+gn1Gdp0=; b=CICT9tmZEtrvRy/ZSCqxhR1uu1sa9xlqhTsuFR2s/EpcpiLJrzwiAz4lWY1wt8tm+y f6gT4vrjZ7A2xUrsysfwxHWc3BZwpec7eq6rWStcMxPqE4yyc9kfuJywjdREIc97B129 sFitnfpzO7kxdFYn0erOqfqxnm0elk9pVPWMcMuUsCY4nlP6S9KakXbNRYpi45KnMgLZ KtBlEOLEvswE92ujvVuwaFJ/zvfRyDO5adF/BlP/cc2Z0RXQnhrAacJrlF+atUaB/ghj I0rAVsCD25UeeWzi/YomieBK4OWN5XOsmjEGPt2MQc2IqxiCF1rvM80v08spzEad6ZHI 7yDw== MIME-Version: 1.0 Received: by 10.60.3.194 with SMTP id e2mr19746864oee.1.1340789192102; Wed, 27 Jun 2012 02:26:32 -0700 (PDT) Received: by 10.60.14.42 with HTTP; Wed, 27 Jun 2012 02:26:32 -0700 (PDT) In-Reply-To: <4FEAC783.6020308@FreeBSD.org> References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> Date: Wed, 27 Jun 2012 13:26:32 +0400 Message-ID: From: Andrey Fesenko To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Erich Dollansky , freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 09:26:33 -0000 On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon wrote: > on 27/06/2012 11:39 Erich Dollansky said the following: >> Anyway, What would be a save way to get a trace to a disk as I do not have a >> backup system with me? > > Assuming I understand the question correctly your options are: > - remote console (serial/firewire/etc) from another machine > - digital camera > - produce a crash dump (possible only after a certain point in boot sequence) > FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/AAAAAAAAD1c/Ix6X8dkyX9k/s868/IMG_4147.jpg In the VirtualBox this system boot no error. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 09:39:14 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 666D1106564A for ; Wed, 27 Jun 2012 09:39:14 +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 B086D8FC08 for ; Wed, 27 Jun 2012 09:39:13 +0000 (UTC) Received: from porto.starpoint.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 MAA15209; Wed, 27 Jun 2012 12:39:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SjoiL-000MHr-Th; Wed, 27 Jun 2012 12:39:09 +0300 Message-ID: <4FEAD4BD.8030209@FreeBSD.org> Date: Wed, 27 Jun 2012 12:39:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Erich Dollansky References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> <201206271549.08192.erichfreebsdlist@ovitrap.com> In-Reply-To: <201206271549.08192.erichfreebsdlist@ovitrap.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 09:39:14 -0000 on 27/06/2012 11:49 Erich Dollansky said the following: > Hi, > > On Wednesday 27 June 2012 15:42:43 Andriy Gapon wrote: >> on 27/06/2012 11:39 Erich Dollansky said the following: >>> Anyway, What would be a save way to get a trace to a disk as I do not have a >>> backup system with me? >> >> Assuming I understand the question correctly your options are: >> - remote console (serial/firewire/etc) from another machine > > this is the problem as I do not have it here. > >> - digital camera > > So, this is really the only option then. > > The photos I really have. Would you still need them? I do not think so after seeing the other post. Not really, I think that you've already confirmed that that is the same issue. I just listed possibilities for future reference. >> - produce a crash dump (possible only after a certain point in boot sequence) > > I think that this was too early. Yes. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 09:43:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EC6BF1065686; Wed, 27 Jun 2012 09:43:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C302E14DEC3; Wed, 27 Jun 2012 09:43:20 +0000 (UTC) Message-ID: <4FEAD5B8.2090301@FreeBSD.org> Date: Wed, 27 Jun 2012 02:43:20 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Oleg Moskalenko References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Gabor Kovesdan Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:43:37 -0000 On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: > Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. > But I do not agree with you that we have to reproduce the old sort bugs. > It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of "replace a core utility" project such as this one. > If some old scripts are relying on buggy behavior > (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. > The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. > All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. > In the basic > area, the old sort and the new sort are 100% compatible. The incompatibilities are > in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. > I am actually tested the new sort against the old GNU sort. There are some incompatibilities. > All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. > The new BSD sort program > is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a "we think we're ready to make the new sort the default, any last concerns?" message, but deal with where we are at and move forward. thanks, Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 10:02:08 2012 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 09ECC1065686 for ; Wed, 27 Jun 2012 10:02:08 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id AB2BE8FC1A for ; Wed, 27 Jun 2012 10:02:07 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id D0862109BD9 for ; Wed, 27 Jun 2012 12:02:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id td5fTh9k6xUX for ; Wed, 27 Jun 2012 12:02:01 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id 463FF109B78 for ; Wed, 27 Jun 2012 12:02:01 +0200 (CEST) Received: (from www@localhost) by hosting.syscare.sk (8.14.5/8.14.5/Submit) id q5RA215O088346; Wed, 27 Jun 2012 12:02:01 +0200 (CEST) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 27 Jun 2012 11:02:01 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <4FEAD5B8.2090301@FreeBSD.org> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> Message-ID: X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.7.2 Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:02:08 -0000 On 27.06.2012 10:43, Doug Barton wrote: > On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: >> Doug, I'll post some performance figures, probably tomorrow. > > That's great, thanks. > >> But I do not agree with you that we have to reproduce the old sort >> bugs. >> It makes no sense and I am not going to do that. Absolutely not. > > That isn't what I said. What I asked is for you to *test* the > existing > sort vs. the new one, and to report where the behavior is different. > That's a very basic part of any sort of "replace a core utility" > project > such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 10:43:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 370C6106564A for ; Wed, 27 Jun 2012 10:43:00 +0000 (UTC) (envelope-from mva@FreeBSD.org) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by mx1.freebsd.org (Postfix) with ESMTP id B5EB88FC1D for ; Wed, 27 Jun 2012 10:42:59 +0000 (UTC) Received: from [80.67.16.114] (helo=webmailfront01.ispgateway.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SjpfW-0002I1-78 for freebsd-current@freebsd.org; Wed, 27 Jun 2012 12:40:18 +0200 Received: from 83.246.65.144 ([83.246.65.144]) by webmail.df.eu (Horde Framework) with HTTP; Wed, 27 Jun 2012 12:40:18 +0200 Date: Wed, 27 Jun 2012 12:40:18 +0200 Message-ID: <20120627124018.Horde.-YicSElCcOxP6uMSLJO1nFA@webmail.df.eu> From: Marcus von Appen To: freebsd-current@freebsd.org References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:43:00 -0000 Daniel Gerzo : > On 27.06.2012 10:43, Doug Barton wrote: >> On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: >>> Doug, I'll post some performance figures, probably tomorrow. >> >> That's great, thanks. >> >>> But I do not agree with you that we have to reproduce the old sort bugs. >>> It makes no sense and I am not going to do that. Absolutely not. >> >> That isn't what I said. What I asked is for you to *test* the existing >> sort vs. the new one, and to report where the behavior is different. >> That's a very basic part of any sort of "replace a core utility" project >> such as this one. > > [ snip ] > > Doug, are you implying that if we were about to import a new version > of GNU sort, you would be asking for the same data? I believe we do > not make this kind of work with any vendor code that is being > updated in the base; I do not really understand why should Oleg or > anyone else do this work when the bsdsort is compatible with a > recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 10:44:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A5B7106566B; Wed, 27 Jun 2012 10:44:30 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1C18FC1F; Wed, 27 Jun 2012 10:44:30 +0000 (UTC) Received: by ggnm2 with SMTP id m2so879028ggn.13 for ; Wed, 27 Jun 2012 03:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0FmeF5p3NJWTnYOyLYD5Ih68SO+NVRIARYHqbydQ8Q=; b=il+9JjSHvhl30dd72uIJML/WS1v8+svEUfXVIBa+kKFBs6/ndXZQmFELjoyrjxqMey lMfRNqE/rTXxdIZ8Uq6zKEENZecHYgwrTm82xh9LNqVhg6BEbxfFl2LnIDoLfH0HhgEd B4DHbug5dV0NY/ZYqRfLgFaDv/UO0SuWBclwu7QAeYtP6I9qf+BjgbADOPxo1Ccc7Bpg oEWaqA1EnrLOc3lNXiUj37ZrCpyG/Uyp9pFkta1FVIx0OWfxustGK5XiDbE3psid7Wuw jB5t0X+ZmxMwU3Myxy00py5K6f0OO3ZsSDh+N4bkAFYDmwB27LeTYyKD+dVwSRmDZL3r C+Fw== MIME-Version: 1.0 Received: by 10.60.28.101 with SMTP id a5mr19679487oeh.69.1340793869692; Wed, 27 Jun 2012 03:44:29 -0700 (PDT) Received: by 10.60.14.42 with HTTP; Wed, 27 Jun 2012 03:44:29 -0700 (PDT) In-Reply-To: References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> Date: Wed, 27 Jun 2012 14:44:29 +0400 Message-ID: From: Andrey Fesenko To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Erich Dollansky , freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 10:44:30 -0000 On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko wrote: > On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon wrote: >> on 27/06/2012 11:39 Erich Dollansky said the following: >>> Anyway, What would be a save way to get a trace to a disk as I do not have a >>> backup system with me? >> >> Assuming I understand the question correctly your options are: >> - remote console (serial/firewire/etc) from another machine >> - digital camera >> - produce a crash dump (possible only after a certain point in boot sequence) >> > > FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 > > https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/AAAAAAAAD1c/Ix6X8dkyX9k/s868/IMG_4147.jpg > > In the VirtualBox this system boot no error. FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64 if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 10:59:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 635CA1065672; Wed, 27 Jun 2012 10:59:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DA1811556D1; Wed, 27 Jun 2012 10:58:56 +0000 (UTC) Message-ID: <4FEAE76F.8080008@FreeBSD.org> Date: Wed, 27 Jun 2012 03:58:55 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Daniel Gerzo References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:59:13 -0000 On 06/27/2012 03:02 AM, Daniel Gerzo wrote: > On 27.06.2012 10:43, Doug Barton wrote: >> On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: >>> Doug, I'll post some performance figures, probably tomorrow. >> >> That's great, thanks. >> >>> But I do not agree with you that we have to reproduce the old sort bugs. >>> It makes no sense and I am not going to do that. Absolutely not. >> >> That isn't what I said. What I asked is for you to *test* the existing >> sort vs. the new one, and to report where the behavior is different. >> That's a very basic part of any sort of "replace a core utility" project >> such as this one. > > [ snip ] > > Doug, are you implying that if we were about to import a new version of > GNU sort, you would be asking for the same data? If the compatibility with the existing version were so dramatically different as Oleg claims, then yes, that would be a basic element of the replacement project. > I believe we do not > make this kind of work with any vendor code that is being updated in the > base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. > I do not really understand why should Oleg or anyone else do this > work when the bsdsort is compatible with a recent version of GNU sort. The first question is, where is it not compatible with the existing sort that's already in the base. The second question is, how well does it perform vs. the existing sort. I think those are perfectly reasonable questions to ask, and frankly they should have been answered before the switch was made. We already went through this with BSD grep, I hope we can avoid a repeat. Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 11:07:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55BF41065686 for ; Wed, 27 Jun 2012 11:07:47 +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 9BA7C8FC0C for ; Wed, 27 Jun 2012 11:07:46 +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 OAA16490; Wed, 27 Jun 2012 14:07:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FEAE97C.4000206@FreeBSD.org> Date: Wed, 27 Jun 2012 14:07:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120610 Thunderbird/13.0 MIME-Version: 1.0 To: Andrey Fesenko References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Erich Dollansky , freebsd-current@FreeBSD.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 11:07:47 -0000 on 27/06/2012 13:44 Andrey Fesenko said the following: > On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko wrote: >> On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon wrote: >>> on 27/06/2012 11:39 Erich Dollansky said the following: >>>> Anyway, What would be a save way to get a trace to a disk as I do not have a >>>> backup system with me? >>> >>> Assuming I understand the question correctly your options are: >>> - remote console (serial/firewire/etc) from another machine >>> - digital camera >>> - produce a crash dump (possible only after a certain point in boot sequence) >>> >> >> FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 >> >> https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/AAAAAAAAD1c/Ix6X8dkyX9k/s868/IMG_4147.jpg >> >> In the VirtualBox this system boot no error. > > FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: Wed Jun > 27 13:51:55 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/GENERIC > amd64 > > if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no error > Thank you for the confirmation. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 12:05:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9C4F1065672; Wed, 27 Jun 2012 12:05:40 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D18E8FC1D; Wed, 27 Jun 2012 12:05:40 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q5RC5cuR005217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Jun 2012 13:05:39 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FEAF712.5070001@unsane.co.uk> Date: Wed, 27 Jun 2012 13:05:38 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FE113D0.7070908@unsane.co.uk> <201206200812.17644.jhb@freebsd.org> <4FE34ED7.9030209@unsane.co.uk> <201206211434.36699.jhb@freebsd.org> In-Reply-To: <201206211434.36699.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: -CURRENT Panic at boot at Revision: 237264 "mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 12:05:41 -0000 Hi, Just a quick ping to make sure this isnt forgotten. Would it help if I open a PR? regards, Vince On 21/06/2012 19:34, John Baldwin wrote: > On Thursday, June 21, 2012 12:41:59 pm Vincent Hoffman wrote: >> Hi again, >> The 2nd patch (to if.h and if_gif.c) also fixes the >> panic on boot. >> Thanks for the quick response as ever. > Great, thanks for testing! Randall, do you have any thoughts on these > patches? > >> Vince From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 12:22:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A779310657A9; Wed, 27 Jun 2012 12:22:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 75B5A8FC14; Wed, 27 Jun 2012 12:22:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB131B945; Wed, 27 Jun 2012 08:22:48 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 08:07:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> In-Reply-To: <4FEA910C.4090305@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206270807.23347.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:48 -0400 (EDT) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 12:22:49 -0000 On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote: > On 26.06.2012 21:37, John Baldwin wrote: > >> 4. The gptboot now searches the backup GPT header in the previous sect= ors, > >> when it finds the "GEOM::" signature in the last sector. PMBR code also > >> tries to do the same: > >> common/gpt.c > >> i386/pmbr/pmbr.s > >=20 > > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > > provider) will not work properly with partition editors for other OS's.= I'm=20 > > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > > gmirror violates the GPT spec. >=20 > The standard says: > "The following test must be performed to determine if a GPT is valid: > =E2=80=A2 Check the Signature > =E2=80=A2 Check the Header CRC > =E2=80=A2 Check that the MyLBA entry points to the LBA that contains the = GUID Partition Table > =E2=80=A2 Check the CRC of the GUID Partition Entry Array > If the GPT is the primary table, stored at LBA 1: > =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT > If the primary GPT is corrupt, software must check the last LBA of the de= vice to see if it has a > valid GPT Header and point to a valid GPT Partition Entry Array." Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. > If a user wants modify GPT in the disk editor from the another OS, > he can do it, and it should work. The result depends only from the partit= ion editor, > it might overwrite the last sector and might don't. I would not assume it would work at all. If it can't trust the primary GPT, it has to assume the alternate is at the last LBA. > >> 5. Also the pmbr image now contains one fake partition record. > >> When several first sectors are damaged the kernel can't detect GPT > >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(= 1) > >> command, but the old pmbr image has an empty partition table and > >> loader doesn't able to boot from GPT, when there is no partition record > >> in the PMBR. Now it will be able. When pmbr is installed via 'gpart=20 > > bootcode' > >> command, the kernel correctly modifies this partition record. So, this= is=20 > > only > >> for the first rescue step. > >=20 > > As I said earlier, I do not think this is appropriate and that instead > > gpart should have an appropriate 'recover' command to install just the = pmbr on=20 > > a disk and also create a correct entry in the MBR if needed while doing= so. >=20 > gpart(8) is only one of several geom(8)' tools to manage objects of a GEO= M class. > It only sends control requests to the kernel. If GPT is not detected, > there is no geom objects to manage. And we can't write bootcode with gpar= t(8). > I think that adding such functions to the gpart(8) is not good. Maybe, > the boot0cfg is the better tool for that. Also we still haven't any tool = to > install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' comma= nd does? Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even thou= gh there isn't a GPT object yet. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 12:22:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EC3E10657A9; Wed, 27 Jun 2012 12:22:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D58018FC19; Wed, 27 Jun 2012 12:22:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA784B9A0; Wed, 27 Jun 2012 08:22:51 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 27 Jun 2012 08:22:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> MIME-Version: 1.0 Message-Id: <201206270822.25672.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:51 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 12:22:53 -0000 On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote: > On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > > 4. The gptboot now searches the backup GPT header in the previous sectors, > > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > > tries to do the same: > > > common/gpt.c > > > i386/pmbr/pmbr.s > > > > GPT really wants the backup header at the last LBA. I know you can set it, > > but I've interpreted that as a way to see if the primary header is correct or > > not. [...] > > My interpretation is different: The way to verify if the header is valid > is to check its checksum, not to check if the backup header location in > the primary header points at the last LBA. > > Of course if primary header's checksum is incorrect it is hard to trust > that the backup header location is correct. And we need the backup > header when the primary header is invalid... Right, which is why this fails. > > [...] It seems to me that GPT tables created in this fashion (inside a GEOM > > provider) will not work properly with partition editors for other OS's. I'm > > hesitant to encourage the use of this as I do think putting GPT inside of a > > gmirror violates the GPT spec. > > I don't think so. Most common case is to configure partitions on top of > a mirror. Mirroring partitions is less common. Mostly because of > hardware RAIDs being popular. You don't expect hardware RAID vendor to > mirror partitions. Partition editors for other OS's won't work, but only > because they don't support gmirror. If they wouldn't recognize and > support some hardware (or pseudo-hardware) RAIDs there will be the same > problem. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. The same is even true of the "software" RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. My approach has been to only use gmirror with MBR so far, though I realize that doesn't work above 2TB (until recently one had to have a hardware RAID to get above 2TB anyway which made this last a moot point). I won't object to patch our tools to handle this, but I think it is a really bad idea that users will have a hard way to recover from when they are bitten by it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 12:45:50 2012 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 1EBCD106566B; Wed, 27 Jun 2012 12:45:50 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id 26D2A8FC0A; Wed, 27 Jun 2012 12:45:49 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 665711241787; Wed, 27 Jun 2012 16:45:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801147; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WeM8tCijMnGCFgFD8k2AbZ0wdOte7bbZ5so1L1VokQSW2RwIDw1cu1tgyu8hJ/hU8 v7PK20PKKYWxd4iWGQunHo/Oi0tP0bUY1Bhu3TIYklgh38W0FKgOUqarJ4Eh5CQxxQ WAWuu75zbA6IfDe/QtdYV3aAyZ4FSHdmAUPwi69A= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id ECC265C03D0; Wed, 27 Jun 2012 16:45:46 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jjF8mO0D-jkFKHr2u; Wed, 27 Jun 2012 16:45:46 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801146; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=gDSsrrIPivDByUjfLpQ8xPlKgqY0xsGvIUNufvG79RPHNDK02zD1RV3e4TOjL3Rez ZQJkOrPHZ95rj7SfBF5fVvs+1TIPwNuVYy6jxHlVC8Pu60gf/IMYdUkgYGMV7dO6vx MbknUl29y9liE5Kqtk+m5n2TRZnD2A+Ju0k+p2mc= Message-ID: <4FEB0079.7050008@yandex.ru> Date: Wed, 27 Jun 2012 16:45:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <201206270807.23347.jhb@freebsd.org> In-Reply-To: <201206270807.23347.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 12:45:50 -0000 On 27.06.2012 16:07, John Baldwin wrote: >> • Check the Signature >> • Check the Header CRC >> • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table >> • Check the CRC of the GUID Partition Entry Array >> If the GPT is the primary table, stored at LBA 1: >> • Check the AlternateLBA to see if it is a valid GPT >> If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a >> valid GPT Header and point to a valid GPT Partition Entry Array." > > Right, we break the last rule. If you want to use a partition editor > that doesn't grok gmirror (because you are using another OS's editor), > to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) >>> As I said earlier, I do not think this is appropriate and that instead >>> gpart should have an appropriate 'recover' command to install just the pmbr on >>> a disk and also create a correct entry in the MBR if needed while doing so. >> >> gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. >> It only sends control requests to the kernel. If GPT is not detected, >> there is no geom objects to manage. And we can't write bootcode with gpart(8). >> I think that adding such functions to the gpart(8) is not good. Maybe, >> the boot0cfg is the better tool for that. Also we still haven't any tool to >> install zfsboot. > > We can't write bootcode with gpart? What do you think the 'bootcode' command > does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. > Also, there is no reason we can't have a 'recover' command that attempts to > recover a corrupted table including repairing the PMBR. gpart(8) already > generates a full PMBR when you use 'gpart create' to create a GPT even though > there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 14:10:28 2012 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 5E399106566C; Wed, 27 Jun 2012 14:10:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 066A18FC14; Wed, 27 Jun 2012 14:10:28 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id DEE02EB8; Wed, 27 Jun 2012 16:10:20 +0200 (CEST) Date: Wed, 27 Jun 2012 16:08:17 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120627140817.GC1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <201206270822.25672.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sHrvAb52M6C8blB9" Content-Disposition: inline In-Reply-To: <201206270822.25672.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 14:10:28 -0000 --sHrvAb52M6C8blB9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: > > I don't think so. Most common case is to configure partitions on top of > > a mirror. Mirroring partitions is less common. Mostly because of > > hardware RAIDs being popular. You don't expect hardware RAID vendor to > > mirror partitions. Partition editors for other OS's won't work, but only > > because they don't support gmirror. If they wouldn't recognize and > > support some hardware (or pseudo-hardware) RAIDs there will be the same > > problem. >=20 > Hardware RAIDs hide the metadata from the disk that the BIOS (and disk > editors) see. Thus, putting a GPT on a hardware RAID volume works fine > as the logical volume is always seen by all OS's consistently. [...] Only if you won't connect this disk to a different controller. > [...] The same > is even true of the "software" RAID that graid supports since the metadata > is defined by the vendor and thus the logical volume is always seen other > OS's consistently. But is it seen without metadata by the boot loader? What I'm trying to say is that it is fair to expect from the user to not use gmirror-configured disk on different OS. If the user wants to use this disk in different OS then he has to use format that is recognized by both. Because gmirror is supported by FreeBSD we should improve the support by teaching boot loader about it. Pretending gmirror is special and recommending to mirror partitions with it instead of raw disks is not the solution. I really can't see how gmirror is different in this regard from any other software RAID or volume manager. If you try to use disk that contains unrecognized metadata the behaviour is undefined (but hopefully not a panic). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --sHrvAb52M6C8blB9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rE9EACgkQForvXbEpPzR3+gCg0WjbLvmRZAjPToMtNypIRg9M Pp0An0JP9JJkZp5Az6GiKR0KxzbaXXG/ =N78o -----END PGP SIGNATURE----- --sHrvAb52M6C8blB9-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 14:23:11 2012 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 618651065672; Wed, 27 Jun 2012 14:23:11 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 22C378FC1D; Wed, 27 Jun 2012 14:23:11 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 1018F6130; Wed, 27 Jun 2012 10:23:06 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=bYwCk2U2gXkC8zoC8FzNHm7TqXPHp3Mq23SSHPWjgf90+xSuVtbsj8zbjrLJVKkbj 9WzmJONaRLSKfDGqutf+vf7u0sSKrdYHnaUYZ8Vjdb4jvv2oXVr0G4pU94OfZfP Message-ID: <4FEB1743.506@protected-networks.net> Date: Wed, 27 Jun 2012 10:22:59 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4FE9D958.4000901@protected-networks.net> <20120627022909.GA153@nargothrond.kdm.org> In-Reply-To: <20120627022909.GA153@nargothrond.kdm.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benjamin Kaduk , current@freebsd.org Subject: Re: Removing an SDHC card causes a kernel panic on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:23:11 -0000 On 06/26/12 22:29, Kenneth D. Merry wrote: > On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: >> On Tue, 26 Jun 2012, Michael Butler wrote: >> >>> As follows, in "g_disk_providergone", a NULL pointer reference?: >> >> g_disk_providergone() is new in r237518 (by ken); ken cc'd. > > Can you try the attached patch to sys/geom/geom_disk.c? This fixes the panic :-) > > Also, do you have full dmesg information for when the panic happened? > > It looks like disk_destroy() has already been called in this case, and I > suppose that's likely to happen for any of the users of the GEOM disk class > that haven't been updated with the reference count changes I made in da(4). > (i.e. all of the rest of them.) > > Let me know whether this works for you. All I have is the following leading up to my removal of the card (and the restart afterwards): Jun 26 08:57:11 toshi kernel: sdhci0-slot0: Card inserted Jun 26 08:57:11 toshi kernel: mmc0: on sdhci0 Jun 26 08:57:11 toshi kernel: mmc0: Probing bus Jun 26 08:57:11 toshi kernel: mmc0: SD probe: OK (OCR: 0x00ff8000) Jun 26 08:57:11 toshi kernel: mmc0: Current OCR: 0x00ff8000 Jun 26 08:57:11 toshi kernel: mmc0: Probing cards Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CID 03534453553136478080d4290400a300) Jun 26 08:57:11 toshi kernel: mmc0: New card detected (CSD 400e00325b59000076b27f800a404000) Jun 26 08:57:11 toshi kernel: mmc0: Card at relative address 36832 added: Jun 26 08:57:11 toshi kernel: mmc0: card: SDHC SU16G 8.0 SN -2133579516 MFG 03/2010 by 3 SD Jun 26 08:57:11 toshi kernel: mmc0: bus: 4bit, 50MHz, high speed timing Jun 26 08:57:11 toshi kernel: mmc0: memory: 31116288 blocks, erase sector 8192 blocks Jun 26 08:57:12 toshi kernel: mmc0: setting transfer rate to 25.000MHz Jun 26 08:57:12 toshi kernel: mmcsd0: 14GB at mmc0 24.0MHz/4bit/65535-block Jun 26 08:57:12 toshi kernel: GEOM: new disk mmcsd0 Jun 26 08:57:12 toshi kernel: mmc0: setting bus width to 4 bits Jun 26 08:58:44 toshi syslogd: kernel boot file is /boot/kernel/kernel Jun 26 08:58:44 toshi kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jun 26 08:58:44 toshi kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 26 08:58:44 toshi kernel: The Regents of the University of California. All rights reserved. Jun 26 08:58:44 toshi kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 14:30:15 2012 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 8B6BC1065675 for ; Wed, 27 Jun 2012 14:30:15 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm17-vm0.bullet.mail.sp2.yahoo.com (nm17-vm0.bullet.mail.sp2.yahoo.com [98.139.91.212]) by mx1.freebsd.org (Postfix) with SMTP id 478588FC0C for ; Wed, 27 Jun 2012 14:30:15 +0000 (UTC) Received: from [98.139.91.69] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 14:30:15 -0000 Received: from [98.139.91.13] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 14:30:15 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 14:30:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 137173.80161.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 83552 invoked by uid 60001); 27 Jun 2012 14:30:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1340807414; bh=aAaq79ZpZpDQW1zJDj+vnbOgq469j9I8d1u6ZK9SqPo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VA0qcVUtanJ1ild+YcQClH5HN2PVQ3kQIgl8TddC9z6AuzEuz26FIISIoAZzNR/UG53fyrhnG9mEyIEF4BUminnvxFpJtUrlbAKZjF79sdNn0ZhpS8p7D9N5qbZ3+kF2DCFFT50zGnSq4H2V0/F8xfEKKqbsrFYV19hIBfoKDB0= X-YMail-OSG: D65XvV4VM1kyCTuFi6ERiDH5u9CrnlE3hhRI7uSDfOb1sxx _69Ptj2nD7amOwWZF9AT0UXppgFCRPCNvnlEUpWXW6PGPffBqL0_BR_kxi6u nIf2_q0ZpOC9y5ttV0plxBoRM9OtjyRSMQJnH3awXSZl1t7KuqlHKeLecX7w uXV78CfFtzflOIbNO2ozqW5qKj7xiqkgDn0waM6R_71yGHA6zNVpVpe8xwPo MUXGShUdZHJgyZ_NpZb6LR9yKt58ogQ.WOmM_nR1C5pyQcO2y4CZGjxq47SP 9Zw_85uR8EJ2NgfPzXpm8PUU.JO_K9ft8QvdQGw.3L8flyyeifZgjeKdbFTF cggcldM1G6LStJyUr5bb_VwwXEOQhIoB2IEuiK4Kmil3RLIqyawDoST0Enbx hr94oFks.twBUAjHq9SHOsZs0dbcG9bWV2VirQe6P8eYzXwOX4CFuMr5CZL4 B8bzE Received: from [200.118.157.7] by web113515.mail.gq1.yahoo.com via HTTP; Wed, 27 Jun 2012 07:30:13 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> Date: Wed, 27 Jun 2012 07:30:13 -0700 (PDT) From: Pedro Giffuni To: Doug Barton In-Reply-To: <4FEAE76F.8080008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:30:15 -0000 =0A=0A--- Mer 27/6/12, Doug Barton ha scritto:=0A...=0A= > =0A> > I believe we do not=0A> > make this kind of work with any vendor c= ode that is=0A> being updated in the=0A> > base;=0A> =0A> Au contraire, we = frequently avoid updating the old versions=0A> of things we have in the bas= e precisely because they are=0A> not bug-for-bug compatible with existing b= ehaviors that we=0A> count on.=0A>=0A=0A=0AReally?? I guess you are speakin= g for bind, because the idea=0Abehind updating and piece of software is pre= cisely shaking=0Abugs. New functionality counts but fixing bugs takes the= =0Apriority. We have three serious bug reports concerning=0AGNU sort and I = even submitted an update but no one cared=0Ato apply it.=0A=0AI would think= only the maintainer of the package has the=0Aauthority to make any request= in the lines of being=0Abug-for-bug compatible and in the case of GNU sort= and=0AGNU grep they are both unmaintained and replacements=0Aare welcome.= =0A=0APlease let's stop being an obstacle towards people=0Abringing real pr= ogress to FreeBSD!=0A=0APedro.=0A From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 14:56:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 199F81065670; Wed, 27 Jun 2012 14:56:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D14BD155B99; Wed, 27 Jun 2012 14:56:32 +0000 (UTC) Message-ID: <4FEB1F20.8010704@FreeBSD.org> Date: Wed, 27 Jun 2012 07:56:32 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: pfg@freebsd.org References: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> In-Reply-To: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:56:34 -0000 On 06/27/2012 07:30 AM, Pedro Giffuni wrote: > > > --- Mer 27/6/12, Doug Barton ha scritto: > ... >> >>> I believe we do not >>> make this kind of work with any vendor code that is >> being updated in the >>> base; >> >> Au contraire, we frequently avoid updating the old versions >> of things we have in the base precisely because they are >> not bug-for-bug compatible with existing behaviors that we >> count on. >> > > > Really?? I guess you are speaking for bind, Nope. > because the idea > behind updating and piece of software is precisely shaking > bugs. Nope. > I would think only the maintainer of the package has the > authority to make any request in the lines of being > bug-for-bug compatible You have a seriously wrong idea of "maintainer." The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. > and in the case of GNU sort and > GNU grep they are both unmaintained and replacements > are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. > Please let's stop being an obstacle towards people > bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 15:24:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6DD8106564A for ; Wed, 27 Jun 2012 15:24:24 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm22-vm1.bullet.mail.sp2.yahoo.com (nm22-vm1.bullet.mail.sp2.yahoo.com [98.139.91.223]) by mx1.freebsd.org (Postfix) with SMTP id AB8CC8FC1D for ; Wed, 27 Jun 2012 15:24:24 +0000 (UTC) Received: from [72.30.22.92] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 15:24:24 -0000 Received: from [98.139.91.47] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 15:23:24 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 27 Jun 2012 15:23:24 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 382543.5531.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 23302 invoked by uid 60001); 27 Jun 2012 15:23:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1340810604; bh=XOyStI7oC+H+j+R+jQsvLn0SLOeVJYhmS814m3+vKO4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0XDkynYPJaY48YEXidIgwmAS5lpShoOnejlwnHneYlMxyuXlLpxMPDEZHphQoNOligZjHEOwJdxkttIk2Lw1srXAnPfwPQb0geJo+ApD+PD4k/pEToiKB+r6PX350d66PXqNM4qPXNCZOIAG6Xqdx6ZhYQTtHyvQ9YZJQoRRccM= X-YMail-OSG: 5s_C3F0VM1mjO7u9MZ_nv7zYILlU6N55BTHPs_qZJTD6vAP Ov4D9vXNid41keLd_i1Ep4qmB2IXVO49CRxR2ON8hCBZrDkhFM97oEGjnSZb OzCe1rTSlIhegBUKYHP5Qvfp7mExzoGfN0O7pLCbA0gPjTX0QN63ngfhLXI. I2L0s32gavDUQUlImqlHyq1dMpSfcJMXu0_D1ZLMPWAl.fovqbFQn4ulA_bP .fBLUFr9bFz364SPcZKVI0NdpSxTBwwY6pJeNz75fIcG1UyffspOgwAkamDs EPyP5DOCrOh8huWJbzePA7I2QyLj1CVQUUKCJ4hqSVFCsjvOoRJs3kiA8cKn 59aSwtA355EtOCS0dYt_KmsIUTtkG7DmdzY.6PRbk.CGpcTpKA9I9eVpuX7z HJRl6RFSIMJV646_bHATqSR96j.lZZaWjKksSrUPVOAUCdZarGwbR7VsgOTY zY7.f Received: from [200.118.157.7] by web113515.mail.gq1.yahoo.com via HTTP; Wed, 27 Jun 2012 08:23:23 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1340810603.22476.YahooMailClassic@web113515.mail.gq1.yahoo.com> Date: Wed, 27 Jun 2012 08:23:23 -0700 (PDT) From: Pedro Giffuni To: Doug Barton In-Reply-To: <4FEB1F20.8010704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:24:24 -0000 =0A=0A--- Mer 27/6/12, Doug Barton ha scritto:=0A...=0A= > =0A> Nope.=0A> =0A> > I would think only the maintainer of the package ha= s=0A> the=0A> > authority to make any request in the lines of being=0A> > b= ug-for-bug compatible=0A> =0A> You have a seriously wrong idea of "maintain= er." The=0A> community owns the software, it's up to the community=0A> to d= ecide how it should work.=0A=0AYou have a serious wrong idea of ownership. = No one really=0Aowns the code and only few people actually take the time=0A= to take care of it.=0A=0A> Historically we have looked at the maintainer as= the person=0A> who volunteers to take care of code, not the person who has= =0A> the exclusive lock on it.=0A> =0A=0AThe maintainer, in this context, d= oesn't have to be a committer=0Abut it has to be someone that spends time f= ixing bugs or=0Aenhancing the code. You might think that because you use th= e=0Acode and are used to certain bug that you depend on that you=0Asomehow = have a say on how it shall behave in the future but that=0Ais simply an ill= usion.=0A=0A=0A> > and in the case of GNU sort and=0A> > GNU grep they are = both unmaintained and replacements=0A> > are welcome.=0A> =0A> Actually bot= h are maintained, it's just that we don't want=0A> to import the new GNU ve= rsions.=0A=0AOur forks of such packages are unmaintained. I did the work=0A= (TM) of updating GNU sort and no one cared to commit it.=0AOleg, took as re= ference the latest upstream sort=0Aimplementation.=0A=0A> And yes, having B= SD versions of these core tools is a=0A> nice goal, but it's not one we sho= uld pursue for its own=0A> sake.=0A> =0A=0AHaving something that we can mai= ntain is a goal we should=0Apursue for it's own sake.=0A=0A> > Please let's= stop being an obstacle towards people=0A> > bringing real progress to Free= BSD!=0A> =0A> In the case of grep, there were a fairly large number of=0A> = people who agreed that a BSD grep with orders of magnitude=0A> worse perfor= mance than the previous version was not=0A> something we, as a project, wer= e willing to=0A> stomach. Sufficiently such that the default was switched= =0A> back.=0A> =0A=0APerformance was an issue and in general it was a good= =0Adecision that even the coder involved agreed upon. Once=0Athe issue is w= ithin acceptable limits, and there has been=0Aprogress on this as I underst= and, BSD grep will be=0Aback.=0A=0ADon't expect BSD grep to support somethi= ng different than=0Aposix behaviour though.=0A=0A> So can we please stop pr= etending that it's me who's the=0A> problem, and start looking at these thi= ngs rationally?=0A> =0A=0AHow about rationally pointing out your issues wit= h the new=0ABSD sort? Any regression that you want to report?=0A=0APedro. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 15:27:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88D98106567B for ; Wed, 27 Jun 2012 15:27:34 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 12CF68FC0A for ; Wed, 27 Jun 2012 15:27:33 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q5RFRWCV012851 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2012 16:27:33 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FEB2664.6000300@unsane.co.uk> Date: Wed, 27 Jun 2012 16:27:32 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-current@freebsd.org" References: <4FE62269.2030706@unsane.co.uk> In-Reply-To: <4FE62269.2030706@unsane.co.uk> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <4FE62269.2030706@unsane.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Occassional "permission denied" in the middle of a large transfer over 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: Wed, 27 Jun 2012 15:27:34 -0000 Hi, After only one off-list reply from the author of kern/136865 (see below) after asking -questions, I thought it worth asking -CURRENT. Basically: I seem to have run into the problems described in this old thread. http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html tl:dr mountd may give incorrect permission denied errors when it is refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to mountd on any mount operation, which implies that any manual mount request would cause the problem. Currently I have still only tested on 8.3-RELEASE but the svn log doesnt seem to mention a fix since then. I'm currently taking a VM up to -CURRENT to test. Looking though old PRs I see the following related. kern/131342 kern/136865 (with patch for 7.2 and links to http://nfse.sourceforge.net/ for -CURRENT ) Does anyone who is qualified (sadly not me) feel like looking at the code to see if its suitable for inclusion in part/whole as not having NFS transfers interrupted by local mount operations on the nfs server would be very handy :) thanks, Vince From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 15:42:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 638E11065673; Wed, 27 Jun 2012 15:42:50 +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 F31338FC1E; Wed, 27 Jun 2012 15:42:48 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5RFgaqf038076; Wed, 27 Jun 2012 18:42:36 +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.5/8.14.5) with ESMTP id q5RFgZVa091454; Wed, 27 Jun 2012 18:42:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5RFgYQA091453; Wed, 27 Jun 2012 18:42:34 +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: Wed, 27 Jun 2012 18:42:33 +0300 From: Konstantin Belousov To: Kevin Lo Message-ID: <20120627154233.GO2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> <1340774954.2147.3.camel@nsl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gZyN7ilQ5rV5bB+g" Content-Disposition: inline In-Reply-To: <1340774954.2147.3.camel@nsl> 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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:42:50 -0000 --gZyN7ilQ5rV5bB+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote: > Kevin Lo wrote: > > Konstantin Belousov wrote: > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > I've observed a panic in recent -current several times but I on= ly > > > > > > have a picture of the backtrace: > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > >=20 > > > > > > Does this look at all familiar to anyone? > > > > >=20 > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x62= 7 address > > > > > in your kernel ? > > > >=20 > > > > Sure. > > > >=20 > > > > > The screenshot looks strange. The instruction on which the kernel= trapped > > > > > is int 0x28 which should not appear in the compiled code. > > > >=20 > > > > # gdb tmpfs.ko > > > > (gdb) l *tmpfs_reg_resize+0x627 > > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/= tmpfs/tmpfs_subr.c:1005). > > > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > >=20 > > > > In tmpfs_subr.c: > > > > 999 if (m !=3D NULL) { > > > > 1000 if ((m->oflags & VPO_BUSY) != =3D 0 || > > > > 1001 m->busy !=3D 0) { > > > > 1002 vm_page_sleep(m, "tmfs= sz"); > > > > 1003 goto retry; > > > > 1004 } > > > > 1005 MPASS(m->valid =3D=3D VM_PAGE_= BITS_ALL); > > > > 1006 } else if (vm_pager_has_page(uobj, idx= , NULL, NU > > > > LL)) { > > > >=20 > > > Hm, can you get a core and > > > - obtain backtrace in kgdb; > > > - print the *m content for the page that triggered the assertion ? > > >=20 > > > The only possible 'new size' value for the truncation from open(2) is= zero, > > > so I do not understand why the asserted block was executed at all. > >=20 > > Thanks for looking into it. Unfortunately I can't get a crash dump=20 > > due to lack of disk space and memory. >=20 > I triggered the KASSERT on a different machine in the last hour. It is not 'the' KASSERT, it is something different. Are you sure that you do not have some systematic build issues on your machines ? Although I do not think that tmpfs is 'ready for production use' for arbitrary low value of this statement, there is no steady flow of similar reports from other users. This makes me somewhat suspicious that either you might have inconsistent build issues, or unrelated memory corruption problems. >=20 > panic: Assertion (vp) !=3DNULL && (vp)->v_data !=3D NULL failed at=20 > @/fs/tmpfs/tmpfs.h:527 >=20 > The bad news is my coworker rebooted that machine after panic :-( >=20 > Kevin --gZyN7ilQ5rV5bB+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/rKekACgkQC3+MBN1Mb4hYwgCfYWOIBPD9WwnenIfhB12y4He+ uuYAoNvto31Rpl2RKFa+YaYOEpdhVsZ/ =jwy7 -----END PGP SIGNATURE----- --gZyN7ilQ5rV5bB+g-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 15:59:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EA2A1065672; Wed, 27 Jun 2012 15:59:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id E0C4D8FC18; Wed, 27 Jun 2012 15:59:06 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D777BE6561; Wed, 27 Jun 2012 17:00:15 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=ynNc0q7z5iEE q9G0WEPvGnv8nqw=; b=Sia1O7WZ5VAD2WNTdd7I3FlSD66O4ghdDTk5EtjGXCB0 b/2fNddB4HQzNSROCu1zSlVXP+iShxMGJvc7qnsNHZwNxgyJZ2GvG3vIzEsoXq32 F3dFeiF9oHlhNff9XfOg/b42hb2QRGMPbO/JBOiG0IqbAiKi5VLrEAZS0HKjFsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=QuLbZY DHwFIZbfV25qcHQ3y5Bbr1ZslZx5TMeg494xNvRpBJauDC0QPkKDZukdD0bIZbKm J8taOfW9+wPAmwcN6l9wqp/1pODJhJ2F29HWKZu8OEXnYXiiCLESX/gL9DGFqeQo 7plt5q0js8Fc8BH99wZKtHf0zWcj1GftkhLoo= Received: from [IPv6:2a01:348:102:2:6ccf:a960:b511:2e21] (unknown [IPv6:2a01:348:102:2:6ccf:a960:b511:2e21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 9A36FE6403; Wed, 27 Jun 2012 17:00:15 +0100 (BST) Message-ID: <4FEB2D93.2010906@cran.org.uk> Date: Wed, 27 Jun 2012 16:58:11 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <4FE7AD6E.7000301@cran.org.uk> <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> In-Reply-To: <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: bapt@freebsd.org, Ron@freebsd.org, Devin Teske , freebsd-current@freebsd.org, McDowell , Nathan Whitehorn Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 15:59:07 -0000 On 27/06/2012 02:11, Devin Teske wrote: > Fixed. Thanks! The mouse daemon flags text still seems to have an upper-case 'S' ('Please Specify'). -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 16:05:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 960D91065670; Wed, 27 Jun 2012 16:05:13 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBE88FC0C; Wed, 27 Jun 2012 16:05:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="29628410" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 12:04:50 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 27 Jun 2012 09:04:50 -0700 From: Oleg Moskalenko To: 'Doug Barton' Date: Wed, 27 Jun 2012 09:04:50 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1USWUX7JYWBXz9SyiXYp0W0yozlQAMbLBQ Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB72@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> In-Reply-To: <4FEAD5B8.2090301@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Current , Gabor Kovesdan Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:05:13 -0000 > -----Original Message----- >=20 > > But I do not agree with you that we have to reproduce the old sort > bugs. > > It makes no sense and I am not going to do that. Absolutely not. >=20 > That isn't what I said. What I asked is for you to *test* the existing > sort vs. the new one, and to report where the behavior is different. > That's a very basic part of any sort of "replace a core utility" > project > such as this one. The problem is that the sort program has huge number of possible options co= mbination.=20 I can list some, but I cannot promise to catch all of them. It would be eno= rmous=20 work.=20 >=20 > > If some old scripts are relying on buggy behavior > > (and I hope they are not) then the old scripts must be fixed. Period. >=20 > With respect, that's not your decision (or mine for that matter). We > first need the data, then as a project we decide how many old bugs we > want to be compatible with, if any. This is an incorrect approach. You never want "old bugs we want to be compa= tible with"=20 in a clean POSIX-compliant system. >=20 > > The system cannot grow replicating the old bugs. >=20 > And the project cannot grow if we lose users due to gratuitous > differences in core utilities. There are users that we are loosing because the utilities do not work as ex= pected. For example, a common complain is about a situation like that:=20 try run a trivial command like " $ ls -l /usr/bin | env LANG=3Den_US.UTF-8 = sort -n -k 5"=20 and see what it yields for the old BSD/GNU sort. I suspect that when you ar= e talking about=20 the old sort compatibility you are really do not know what you are talking = about. Once you start digging, you prospective may change. >=20 > > All system scripts that I've seen are using pretty basic sort > features. >=20 > The system scripts are only a tiny fraction of how FreeBSD users use > sort. This is even stronger emphasizes the need in a standard-compliant implement= ation. >=20 > > In the basic > > area, the old sort and the new sort are 100% compatible. The > incompatibilities are > > in more complex areas (numeric sorts and unusual key-based sorts). >=20 > So here's one to add to your regression test. I use the following to > sort IPv4 addresses in a list: >=20 > sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 >=20 > When used with GNU sort that will sort a list of IPv4 addresses into a > humanly-recognizable numeric order. Please ensure that this works the > same way with the new sort. First, this is a pretty trivial use case. Don't expect anything different=20 in the trivial cases. I think that 99% of users will never see the differen= ce=20 between the old sort and the new sort - for a usual non-expert usage=20 the two are almost always compatible. Second, do you really think that I ne= ed=20 lecturing which use cases to test ? >=20 > > I am actually tested the new sort against the old GNU sort. There are > some incompatibilities. > > All of them are due to the bugs of the old GNU sort. >=20 > Please list all of those explicitly. see above. >=20 > > The new BSD sort program > > is compatible with the new GNU sort, a much cleaner program than the > old GNU sort. >=20 > That's good, but not really relevant to the users of what we have in > the > base now. I bet many of them are installing the new GNU coreutils exactly for the=20 reasons of better performance and compatibility. >=20 > I realize that these questions may seem discouraging, but they need to > be answered. It would have been nice if Gabor had posted a "we think > we're ready to make the new sort the default, any last concerns?" > message, but deal with where we are at and move forward. He actually did. You probably missed the messages. Thanks, Oleg From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 16:06:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13FD1106564A for ; Wed, 27 Jun 2012 16:06:46 +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 D03C98FC18 for ; Wed, 27 Jun 2012 16:06:45 +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 q5RG6jqh002261; Wed, 27 Jun 2012 10:06:45 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q5RG6hfm002260; Wed, 27 Jun 2012 10:06:43 -0600 (MDT) (envelope-from ken) Date: Wed, 27 Jun 2012 10:06:43 -0600 From: "Kenneth D. Merry" To: Michael Butler Message-ID: <20120627160643.GA2225@nargothrond.kdm.org> References: <4FE9D958.4000901@protected-networks.net> <20120627022909.GA153@nargothrond.kdm.org> <4FEB1743.506@protected-networks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FEB1743.506@protected-networks.net> User-Agent: Mutt/1.4.2i Cc: Benjamin Kaduk , current@freebsd.org Subject: Re: Removing an SDHC card causes a kernel panic on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:06:46 -0000 On Wed, Jun 27, 2012 at 10:22:59 -0400, Michael Butler wrote: > On 06/26/12 22:29, Kenneth D. Merry wrote: > > On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: > >> On Tue, 26 Jun 2012, Michael Butler wrote: > >> > >>> As follows, in "g_disk_providergone", a NULL pointer reference?: > >> > >> g_disk_providergone() is new in r237518 (by ken); ken cc'd. > > > > Can you try the attached patch to sys/geom/geom_disk.c? > > This fixes the panic :-) Great! I just committed it. > > Also, do you have full dmesg information for when the panic happened? > > > > It looks like disk_destroy() has already been called in this case, and I > > suppose that's likely to happen for any of the users of the GEOM disk class > > that haven't been updated with the reference count changes I made in da(4). > > (i.e. all of the rest of them.) > > > > Let me know whether this works for you. > > All I have is the following leading up to my removal of the card (and > the restart afterwards): Thanks! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 16:06:56 2012 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 39A01106578D; Wed, 27 Jun 2012 16:06:56 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id CCAE58FC15; Wed, 27 Jun 2012 16:06:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200250407" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 12:06:54 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 27 Jun 2012 09:06:54 -0700 From: Oleg Moskalenko To: 'Marcus von Appen' , "freebsd-current@freebsd.org" Date: Wed, 27 Jun 2012 09:06:53 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1UUc36KNdt8omCTouYfX8XNU9/rQALPitA Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB73@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> <20120627124018.Horde.-YicSElCcOxP6uMSLJO1nFA@webmail.df.eu> In-Reply-To: <20120627124018.Horde.-YicSElCcOxP6uMSLJO1nFA@webmail.df.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:06:56 -0000 TWFyY3VzLCBJJ2xsIHByb3ZpZGUgc29tZSBpbmNvbXBhdGliaWxpdGllcyBkZXNjcmlwdGlvbiwg YXMgbWFueSBhcyBJIGNhbiBkby4NCg0KVGhhbmtzDQpPbGVnDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIFtt YWlsdG86b3duZXItZnJlZWJzZC0NCj4gY3VycmVudEBmcmVlYnNkLm9yZ10gT24gQmVoYWxmIE9m IE1hcmN1cyB2b24gQXBwZW4NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDEyIDM6NDAg QU0NCj4gVG86IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZw0KPiBTdWJqZWN0OiBSZTogW0hF QURTLVVQXSBCU0Qgc29ydCBpcyB0aGUgZGVmYXVsdCBzb3J0IGluIC1DVVJSRU5UDQo+IA0KPiBE YW5pZWwgR2Vyem8gPGRhbmdlckBmcmVlYnNkLm9yZz46DQo+IA0KPiA+IE9uIDI3LjA2LjIwMTIg MTA6NDMsIERvdWcgQmFydG9uIHdyb3RlOg0KPiA+PiBPbiAwNi8yNy8yMDEyIDAyOjA5IEFNLCBP bGVnIE1vc2thbGVua28gd3JvdGU6DQo+ID4+PiBEb3VnLCBJJ2xsIHBvc3Qgc29tZSBwZXJmb3Jt YW5jZSBmaWd1cmVzLCBwcm9iYWJseSB0b21vcnJvdy4NCj4gPj4NCj4gPj4gVGhhdCdzIGdyZWF0 LCB0aGFua3MuDQo+ID4+DQo+ID4+PiBCdXQgSSBkbyBub3QgYWdyZWUgd2l0aCB5b3UgdGhhdCB3 ZSBoYXZlIHRvIHJlcHJvZHVjZSB0aGUgb2xkIHNvcnQNCj4gYnVncy4NCj4gPj4+IEl0IG1ha2Vz IG5vIHNlbnNlIGFuZCBJIGFtIG5vdCBnb2luZyB0byBkbyB0aGF0LiBBYnNvbHV0ZWx5IG5vdC4N Cj4gPj4NCj4gPj4gVGhhdCBpc24ndCB3aGF0IEkgc2FpZC4gV2hhdCBJIGFza2VkIGlzIGZvciB5 b3UgdG8gKnRlc3QqIHRoZQ0KPiBleGlzdGluZw0KPiA+PiBzb3J0IHZzLiB0aGUgbmV3IG9uZSwg YW5kIHRvIHJlcG9ydCB3aGVyZSB0aGUgYmVoYXZpb3IgaXMgZGlmZmVyZW50Lg0KPiA+PiBUaGF0 J3MgYSB2ZXJ5IGJhc2ljIHBhcnQgb2YgYW55IHNvcnQgb2YgInJlcGxhY2UgYSBjb3JlIHV0aWxp dHkiDQo+IHByb2plY3QNCj4gPj4gc3VjaCBhcyB0aGlzIG9uZS4NCj4gPg0KPiA+IFsgc25pcCBd DQo+ID4NCj4gPiBEb3VnLCBhcmUgeW91IGltcGx5aW5nIHRoYXQgaWYgd2Ugd2VyZSBhYm91dCB0 byBpbXBvcnQgYSBuZXcgdmVyc2lvbg0KPiA+IG9mIEdOVSBzb3J0LCB5b3Ugd291bGQgYmUgYXNr aW5nIGZvciB0aGUgc2FtZSBkYXRhPyBJIGJlbGlldmUgd2UgZG8NCj4gPiBub3QgbWFrZSB0aGlz IGtpbmQgb2Ygd29yayB3aXRoIGFueSB2ZW5kb3IgY29kZSB0aGF0IGlzIGJlaW5nDQo+ID4gdXBk YXRlZCBpbiB0aGUgYmFzZTsgSSBkbyBub3QgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IHNob3VsZCBP bGVnIG9yDQo+ID4gYW55b25lIGVsc2UgZG8gdGhpcyB3b3JrIHdoZW4gdGhlIGJzZHNvcnQgaXMg Y29tcGF0aWJsZSB3aXRoIGENCj4gPiByZWNlbnQgdmVyc2lvbiBvZiBHTlUgc29ydC4NCj4gDQo+ IFNlY29uZGVkIGZvciAtQ1VSUkVOVC4gSSB0aGluaywgd2Ugc2hvdWxkIGF0IGxlYXN0IHByb3Zp ZGUgc29tZSBicmllZg0KPiBkb2N1bWVudCwgd2hhdHNvZXZlciBvbiBpbmNvbXBhdGliaWxpdGll cyB3aXRoIHRoZSBzb3J0IGltcGxlbWVudGF0aW9uDQo+IHRoYXQNCj4gaXMgY3VycmVudGx5IGFj dGl2ZSBpbiBSRUxFTkdfOSwgbm8gbWF0dGVyIGhvdyBidWdneSBpdCBpcy4NCj4gDQo+IFRoaXMg YWxsb3dzIGFkb3B0ZXJzIGFuZCBwZW9wbGUsIHdobyBoYXZlIHRvIG1pZ3JhdGUgdGhlaXIgcHJv ZHVjdGlvbg0KPiBzeXN0ZW1zDQo+IHRvIGlkZW50aWZ5IGFuZCBxdWFudGlmeSB0aGUgYXJlYXMg dG8gY2hhbmdlIGFuZCBwZXJmb3JtIHNvbWUgcmlzaw0KPiBtYW5hZ2VtZW50Lg0KPiBUaGlzIGFs c28gYWxsb3dzIHRoZW0gdG8gbW92ZSBtb3JlIHF1aWNrbHkgdG8gdGhlIG5ldyByZWxlYXNlLCBz aW5jZQ0KPiB0aGV5DQo+IGNhbiBzdGFydCB3aXRoIHRoZSBuZWNlc3NhcnkgY2hhbmdlcyBlYXJs aWVyIGFuZCBwbGFuIGFoZWFkLg0KPiANCj4gV2UgcHJvdmlkZSBzdWNoIGNoYW5nZXMgdXN1YWxs eSBpbiB0aGUgcmVsZWFzZSBub3RlcyBmb3IgdmFyaW91cyB0b29scywNCj4gd2UNCj4gdXBkYXRl ZCBhbmQgSSB0aGluayB0aGF0IGdpdmluZyBvdXQgc3VjaCBhIGRvY3VtZW50IGVhcmxpZXIgd2ls bCBiZQ0KPiBleHRyZW1lbHkNCj4gYmVuZWZpdGlhbCBmb3IgY29tcGFuaWVzLCB3aGljaCBoYXZl IHRvIGRlYWwgd2l0aCBtb3JlIHRoYW4gb25lIG9yIHR3bw0KPiBzZXJ2ZXJzIHJ1bm5pbmcgRnJl ZUJTRCwgZXNwZWNpYWxseSBpZiB3ZSBrbm93IHRoYXQgdGhlIGN1cnJlbnRseQ0KPiBzaGlwcGVk DQo+IGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5IGFuZCBwZW9wbGUgbW9zdCBsaWtlbHkgd2lsbCBo YXZlIHRoZWlyIG93bg0KPiB3b3JrYXJvdW5kcw0KPiBmb3IgdGhhdC4NCj4gDQo+IENoZWVycw0K PiBNYXJjdXMNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVu dA0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LQ0K PiB1bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 16:20:10 2012 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 897E6106564A; Wed, 27 Jun 2012 16:20:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02E508FC15; Wed, 27 Jun 2012 16:20:09 +0000 (UTC) Message-ID: <4FEB32B9.10802@FreeBSD.org> Date: Wed, 27 Jun 2012 12:20:09 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAA61A.30402@FreeBSD.org> <201206271539.04926.erichfreebsdlist@ovitrap.com> <4FEAC783.6020308@FreeBSD.org> <4FEAE97C.4000206@FreeBSD.org> In-Reply-To: <4FEAE97C.4000206@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Erich Dollansky , Andrey Fesenko , freebsd-current@freebsd.org Subject: Re: Panic on current from yesterday 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: Wed, 27 Jun 2012 16:20:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote: > on 27/06/2012 13:44 Andrey Fesenko said the following: >> On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko >> wrote: >>> On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon >>> wrote: >>>> on 27/06/2012 11:39 Erich Dollansky said the following: >>>>> Anyway, What would be a save way to get a trace to a disk >>>>> as I do not have a backup system with me? >>>> >>>> Assuming I understand the question correctly your options >>>> are: - remote console (serial/firewire/etc) from another >>>> machine - digital camera - produce a crash dump (possible >>>> only after a certain point in boot sequence) >>>> >>> >>> FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237631 >>> >>> https://lh4.googleusercontent.com/-WRY8xDPlJk4/T-rQt79wm7I/AAAAAAAAD1c/Ix6X8dkyX9k/s868/IMG_4147.jpg >>> >>> >>> In the VirtualBox this system boot no error. >> >> FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237635M: >> Wed Jun 27 13:51:55 MSK 2012 >> root@bsdx220:/usr/obj/usr/src/sys/GENERIC amd64 >> >> if use patch http://people.freebsd.org/~jkim/evxfgpe.diff boot no >> error >> > > Thank you for the confirmation. > Committed as r237652: http://svnweb.freebsd.org/base?view=revision&revision=237652 I really wanted to get confirmation from ACPICA developers first but I had no choice. :-( Sorry for the delay, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/rMrkACgkQmlay1b9qnVOg5gCeNcFWPjIcqTN3DyQttmtLC5bN EskAn083+eY8WWer4AFhYtT5pkmkmV+F =PKC4 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:12:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EB581065670; Wed, 27 Jun 2012 17:12:54 +0000 (UTC) (envelope-from mezz.freebsd@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 B744E8FC0A; Wed, 27 Jun 2012 17:12:53 +0000 (UTC) Received: by yenl8 with SMTP id l8so1347167yen.13 for ; Wed, 27 Jun 2012 10:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UKGohNsozKEb0J+uL6a9Z5aZFjYIP7EHY5xJtLKB9gw=; b=CSMCyzVPI7XLbZBqlgFNaj176kkJSfxo51q7ZezVrPqd0iKaMgGBtlXgpWgzA1fSEG L8tePjqUh4LObhTE7Ysbr6CR0oNktCPSxLJk7WFxPlPIeBUD04tjpcbYsFe/tI/j12KQ r6/r2mYdRDDwdRIK+pZtO5EGCyj5Vl0zo1AkiwOK0cDRLNhPVrq0s8JOSRWiuNMCfauY BU7CHJP+OcvlpAyP5om/CinzAV7DX3AF/uYeC4r5QBATNCAED9Z0roxEtpnW6HwU1oV8 +cFhuQ1P7/j8PbCwZqKB0QAlCFZ7TxXvTmKHhYnig0xxL3+SzUWLFN0XMBujKwAmBE+B ro/Q== MIME-Version: 1.0 Received: by 10.236.173.135 with SMTP id v7mr23517655yhl.19.1340817172959; Wed, 27 Jun 2012 10:12:52 -0700 (PDT) Received: by 10.101.85.17 with HTTP; Wed, 27 Jun 2012 10:12:52 -0700 (PDT) In-Reply-To: <4FEB1F20.8010704@FreeBSD.org> References: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> <4FEB1F20.8010704@FreeBSD.org> Date: Wed, 27 Jun 2012 12:12:52 -0500 Message-ID: From: Jeremy Messenger To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: pfg@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:12:54 -0000 On Wed, Jun 27, 2012 at 9:56 AM, Doug Barton wrote: > On 06/27/2012 07:30 AM, Pedro Giffuni wrote: >> >> >> --- Mer 27/6/12, Doug Barton ha scritto: >> ... >>> >>>> I believe we do not >>>> make this kind of work with any vendor code that is >>> being updated in the >>>> base; >>> >>> Au contraire, we frequently avoid updating the old versions >>> of things we have in the base precisely because they are >>> not bug-for-bug compatible with existing behaviors that we >>> count on. >>> >> >> >> Really?? I guess you are speaking for bind, > > Nope. > >> because the idea >> behind updating and piece of software is precisely shaking >> bugs. > > Nope. > >> I would think only the maintainer of the package has the >> authority to make any request in the lines of being >> bug-for-bug compatible > > You have a seriously wrong idea of "maintainer." The community owns the > software, it's up to the community to decide how it should work. > Historically we have looked at the maintainer as the person who > volunteers to take care of code, not the person who has the exclusive > lock on it. > >> and in the case of GNU sort and >> GNU grep they are both unmaintained and replacements >> are welcome. > > Actually both are maintained, it's just that we don't want to import the > new GNU versions. And yes, having BSD versions of these core tools is a > nice goal, but it's not one we should pursue for its own sake. > >> Please let's stop being an obstacle towards people >> bringing real progress to FreeBSD! > > In the case of grep, there were a fairly large number of people who > agreed that a BSD grep with orders of magnitude worse performance than > the previous version was not something we, as a project, were willing to > stomach. Sufficiently such that the default was switched back. > > So can we please stop pretending that it's me who's the problem, and > start looking at these things rationally? Doug, I think you need to give it a chance. I do not see any problem for anyone to switch the default and if the problems discover then switch the default back. It's a bleeding edge branch where more people can test it. The issue with grep was very harmeless and it was not difficult to switch the default between GNU and BSD. It's not like they threw GNU grep/sort away quickly. How come that I haven't heard anything from you about the jemalloc update? If you did then I must have missed it. It was very clearly that it was not test and he doesn't handle it very well, but got fixed evenly with the multi-commit. It was worst than grep/sort and other projects. If you are wondering why it's you. Because lately you are starting to whine a lot without give the things chance. If we are doing your way and nothing will moving on. > Doug -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:18:12 2012 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 0718A106564A; Wed, 27 Jun 2012 17:18:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B7F0D8FC08; Wed, 27 Jun 2012 17:18:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q5RHHjjQ030960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jun 2012 12:18:06 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 27 Jun 2012 12:17:21 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <4FEB2D93.2010906@cran.org.uk> Date: Wed, 27 Jun 2012 10:17:19 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <4F649A3D-9F02-42F1-A942-1EE6C4390BEC@fisglobal.com> References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <4FE7AD6E.7000301@cran.org.uk> <41E39816-56FA-44DF-8083-0350BE70D416@fisglobal.com> <4FEB2D93.2010906@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-27_05:2012-06-27, 2012-06-27, 1970-01-01 signatures=0 Cc: bapt@freebsd.org, freebsd-current@freebsd.org, Ron@freebsd.org, McDowell McDowell , Nathan Whitehorn , Devin Teske Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:18:12 -0000 On Jun 27, 2012, at 8:58 AM, Bruce Cran wrote: > On 27/06/2012 02:11, Devin Teske wrote: >> Fixed. >=20 > Thanks! > The mouse daemon flags text still seems to have an upper-case 'S' ('Pleas= e Specify'). >=20 Oops, forgot that one. Thanks Bruce! Fixed. --=20 Devin NOTE: I probably won't be rushing to roll a new port version for this chang= e; just know that it will make it into the next snapshot (and has been made= to the tree that will be imported to HEAD later, if there aren't any other= issues reported by end-of-day). _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:30:56 2012 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 3DABC106564A; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FDAA8FC1D; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A613B94B; Wed, 27 Jun 2012 13:30:55 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 27 Jun 2012 10:26:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206270822.25672.jhb@freebsd.org> <20120627140817.GC1372@garage.freebsd.pl> In-Reply-To: <20120627140817.GC1372@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206271026.02473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 13:30:55 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 17:30:56 -0000 On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote: > On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: > > > I don't think so. Most common case is to configure partitions on top of > > > a mirror. Mirroring partitions is less common. Mostly because of > > > hardware RAIDs being popular. You don't expect hardware RAID vendor to > > > mirror partitions. Partition editors for other OS's won't work, but only > > > because they don't support gmirror. If they wouldn't recognize and > > > support some hardware (or pseudo-hardware) RAIDs there will be the same > > > problem. > > > > Hardware RAIDs hide the metadata from the disk that the BIOS (and disk > > editors) see. Thus, putting a GPT on a hardware RAID volume works fine > > as the logical volume is always seen by all OS's consistently. [...] > > Only if you won't connect this disk to a different controller. Yes, but people do not expect to be able to yank a hardware RAID drive out and hook it up to a "raw" disk controller and have it work. > > [...] The same > > is even true of the "software" RAID that graid supports since the metadata > > is defined by the vendor and thus the logical volume is always seen other > > OS's consistently. > > But is it seen without metadata by the boot loader? Yes. The logical volume shows up as a BIOS disk device. > What I'm trying to say is that it is fair to expect from the user to not > use gmirror-configured disk on different OS. If the user wants to use > this disk in different OS then he has to use format that is recognized > by both. > > Because gmirror is supported by FreeBSD we should improve the support by > teaching boot loader about it. Pretending gmirror is special and > recommending to mirror partitions with it instead of raw disks is not > the solution. > > I really can't see how gmirror is different in this regard from any > other software RAID or volume manager. If you try to use disk that > contains unrecognized metadata the behaviour is undefined (but hopefully > not a panic). It is not gmirror I am complaining about, it is the non-standard use of GPT. Note that gmirror + MBR works fine without violating what little standard there is for the MBR. Using a dedicated GPT partition to hold the gmirrror metadata would work with GPT (but be a good bit harder to work with in terms of GEOM I realize). But as I said, I won't object to these patches. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:30:56 2012 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 DF0AB1065673; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEBA48FC1F; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 21DBDB953; Wed, 27 Jun 2012 13:30:56 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 10:28:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> In-Reply-To: <4FEB0079.7050008@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206271028.54477.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 13:30:56 -0400 (EDT) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 17:30:57 -0000 On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > On 27.06.2012 16:07, John Baldwin wrote: > >> =E2=80=A2 Check the Signature > >> =E2=80=A2 Check the Header CRC > >> =E2=80=A2 Check that the MyLBA entry points to the LBA that contains t= he GUID Partition Table > >> =E2=80=A2 Check the CRC of the GUID Partition Entry Array > >> If the GPT is the primary table, stored at LBA 1: > >> =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT > >> If the primary GPT is corrupt, software must check the last LBA of the= device to see if it has a > >> valid GPT Header and point to a valid GPT Partition Entry Array." > >=20 > > Right, we break the last rule. If you want to use a partition editor > > that doesn't grok gmirror (because you are using another OS's editor), > > to repair a GPT, it will do the wrong thing. >=20 > When we are in the FreeBSD, our loader can detect that device size > is lower than it see and it will work. When primary header is OK, then > other OSes should work with this GPT. When it isn't OK, you just can't > load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) > > We can't write bootcode with gpart? What do you think the 'bootcode' c= ommand > > does? >=20 > `gpart bootcode -b` reads file, creates ioctl request and sends this data= to > the GEOM_PART class. GEOM_PART receives the control request, checks the d= ata > and writes it to the provider. > `gpart bootcode -p` works like dd(1) and writes bootcode to the given par= tition. > gpart(8) haven't any knowledge about specific partitioning scheme. Correct, but in both cases it writes "bootcode". > > Also, there is no reason we can't have a 'recover' command that attempt= s to > > recover a corrupted table including repairing the PMBR. gpart(8) alrea= dy > > generates a full PMBR when you use 'gpart create' to create a GPT even = though > > there isn't a GPT object yet. >=20 > `gpart create` creates only ioctl control request to the GEOM_PART class. > GEOM_PART class creates new GPT geom object and this objects writes PMBR = and its > metadata to the provider. You can't add a new ioctl? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:37:29 2012 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 5E2DA106566B; Wed, 27 Jun 2012 17:37:29 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 337EF8FC1B; Wed, 27 Jun 2012 17:37:29 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHbGtc011695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:37:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <201206261337.11741.jhb@freebsd.org> Date: Wed, 27 Jun 2012 10:37:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 17:37:29 -0000 On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: >=20 > GPT really wants the backup header at the last LBA. I know you can = set it,=20 > but I've interpreted that as a way to see if the primary header is = correct or=20 > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > provider) will not work properly with partition editors for other = OS's. I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > gmirror violates the GPT spec. Agreed. While it is a nice trick to use the last sector for meta data, it does create 2 problems. 1 is mentioned above. The second is that when there's different metadata in the first *and* the last sector, you can't decide which is to take precedence without also looking at the other and know how to interpret it. We have not solved this second problem at all. We do get reports about the problems though. At best we're handwaving or kluging. I think it's unwise to depend on FreeBSD-specific extensions or features in industry-standard partitioning schemes and as such make the use of "foreign" tools hard if not impossible. A much more flexible approach is to support out-of-band configuration data. This allows us to mirror GPT disks without having to become non- standard as it removes the need to use the last sector for meta-data. The ability to construct GEOM hierarchies unambiguously is very important and our current approach has proven to not deliver on that. This is actually impacting existing FreeBSD consumers already, like Juniper. So, se should not go deeper into this rabbit hole. We should finally solve this problem for real... --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:44:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 1AF361065675 for ; Wed, 27 Jun 2012 17:44:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4EA0615FACE for ; Wed, 27 Jun 2012 17:39:34 +0000 (UTC) Message-ID: <4FEB4556.6030609@FreeBSD.org> Date: Wed, 27 Jun 2012 10:39:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> <4FEB1F20.8010704@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:44:34 -0000 I officially withdraw from the discussion. I hope it all works out well. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:45:49 2012 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 A11D2106564A; Wed, 27 Jun 2012 17:45:49 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 775888FC0A; Wed, 27 Jun 2012 17:45:49 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHjeki011729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:45:48 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120626214330.GG1399@garage.freebsd.pl> Date: Wed, 27 Jun 2012 10:45:35 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 17:45:49 -0000 On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > > As for sharing disk with other OS. If you share the disk with OS that > doesn't support gmirror, you shouldn't use gmirror in the first place. > You probably want to use only formats that are recognized by all your > OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:48:19 2012 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 0B7CC106564A; Wed, 27 Jun 2012 17:48:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B54D58FC08; Wed, 27 Jun 2012 17:48:18 +0000 (UTC) Received: by dadv36 with SMTP id v36so1883435dad.13 for ; Wed, 27 Jun 2012 10:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KlItTRxIy4QWb79V1CPvo1bTju2MHN/phZyBtFWsDWM=; b=ccVUDBZx1TEJj0bMMXycCgQe4K9pTDah4q/tBmd/HPtstjZIePJLsVLbXuRyChtru5 1hQ3JyCBGV7x0/7kcocf6+am38VkaATKnvdVwjoMoVqmzd5RSjdZ2fCn4Pq9mzwxboH6 k4MaWMmS12Z1ylysTdm6PlchpZaelnIIrFKE0VPQ4kcfXeYBRXgdgpbKwh6Aje2pnO6G LH816BevdfthJFqzU/SO1Ix77zTPOHQFw2n/SgJGOHkmjIz8/vxfdCDq5Zf9VE8iFODc J1LPW1XPQ+nNFcq4w5SL0K/TZRavKL/Srn2JAVpj54qR1k4wcJdmjdkC3gpfiqvjwUSf 6fjw== MIME-Version: 1.0 Received: by 10.68.222.163 with SMTP id qn3mr65878515pbc.135.1340819298461; Wed, 27 Jun 2012 10:48:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.195.102 with HTTP; Wed, 27 Jun 2012 10:48:18 -0700 (PDT) In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB72@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB72@SJCPMAILBOX01.citrite.net> Date: Wed, 27 Jun 2012 10:48:18 -0700 X-Google-Sender-Auth: Uev5uIo5Bs9LGHW0eGRgtuLArOI Message-ID: From: Adrian Chadd To: Oleg Moskalenko Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , Gabor Kovesdan , FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:48:19 -0000 Ah, I just tried sort on freebsd (5.3.0) versus sort on macosx 10.6 (5.93) - what a strange bug. We _could've_ fixed this with an import of the latest gnu sort and then migrated to a feature/bug compatible bsdsort, but I do see your point(s). :-) There's a fine line to walk between keeping POLA and making progress. Just be careful you don't stray too far to the Linux side of that. (And be careful of staying too close to the POLA side of it.) 2c, and great work! adrian From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:55:37 2012 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 BCBB11065676; Wed, 27 Jun 2012 17:55:37 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7748FC1C; Wed, 27 Jun 2012 17:55:37 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHtOiC011786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:55:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4FEA910C.4090305@yandex.ru> Date: Wed, 27 Jun 2012 10:55:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 17:55:37 -0000 On Jun 26, 2012, at 9:50 PM, Andrey V. Elsukov wrote: > If the primary GPT is corrupt, software must check the last LBA of the = device to see if it has a > valid GPT Header and point to a valid GPT Partition Entry Array." >=20 > For the FreeBSD an each GEOM provider can be treated as disk device. > So, i don't see anything criminal if we will add some quirks in the = our loader > for the better supporting of our technologies. You can't just re-interpret standards to match a context you know very = well isn't applicable and consequently redefine what the word "device" means. You're on a slippery slope and while you may not see it as a problem, = you do make it a problem for FreeBSD users. It's our users we should be = keeping in mind when we solve problems. > If a user wants modify GPT in the disk editor from the another OS, > he can do it, and it should work. The result depends only from the = partition editor, > it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation = destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) = for no apparent reason and without any kind of warning that what he/she is = doing is potentially harmful... That's the spirit! --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:56:34 2012 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 7985C106566C for ; Wed, 27 Jun 2012 17:56:34 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id C343E8FC0C for ; Wed, 27 Jun 2012 17:56:33 +0000 (UTC) Received: (qmail invoked by alias); 27 Jun 2012 17:56:27 -0000 Received: from p578be941.dip0.t-ipconnect.de (EHLO [192.168.0.100]) [87.139.233.65] by mail.gmx.net (mp020) with SMTP; 27 Jun 2012 19:56:27 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX1/Rq1Mo5g3RO4jRYQjmhz6IfgIeSMqkIGsL/VL67/ xDJ9IpCC9Ak2S1 Message-ID: <4FEB494A.80003@gmx.de> Date: Wed, 27 Jun 2012 19:56:26 +0200 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current References: <4FEAA280.2070705@FreeBSD.org> In-Reply-To: <4FEAA280.2070705@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Oleg Moskalenko , Gabor Kovesdan Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:56:34 -0000 On 2012-06-27 08:04, Gabor Kovesdan wrote: > Hi Folks, > > as I announced before, the default sort in -CURRENT has been changed > to BSD sort. Since the import, the reported minor bugs have been > fixed and BSD sort has passed the portbuild test. If you encounter any > problems or incompatibility with the old GNU version, please report. > > Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:43:07 2012 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 CA25E106566B for ; Wed, 27 Jun 2012 17:43:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87DFF8FC20 for ; Wed, 27 Jun 2012 17:43:07 +0000 (UTC) Received: by obbun3 with SMTP id un3so2300260obb.13 for ; Wed, 27 Jun 2012 10:43:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5wnhmaGDJccfOmOZ18GfGMdlwdn475s6prXfYRcVW9g=; b=koZHfyyflzbVDBlvMSdfrnRzaMg+tbjJj4AkhRtF9JlQAvmDZMkCQDWDZbeECXf5is 5T75Q4a6/yTJMp0lsMWZVBkiMorSJfXIaCVdoF5HIqhnFGqrl/g0WXXsoACRGq36Hr5w vBDRQsgdaS47w/STQVtvggEHmSRFC7hii/UtvV0NTom/9gs8KQJS8mXcfD0DKoIxEYNU HCd/x4SeqYeFI+jwom1oLqtaOUOm5QPu2HOTCwPEhXM7kI46I0Guc4V2fkOJzomcw+mq Qc8y6rx19wKDtJb7TgYaDL9qv/trRABZjIuFd0AP1RJlE28OPTpOtac4nrlx3prxulrV NZYQ== Received: by 10.60.27.6 with SMTP id p6mr21421727oeg.37.1340818987110; Wed, 27 Jun 2012 10:43:07 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id g3sm30124731oeb.5.2012.06.27.10.43.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 10:43:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FEB1F20.8010704@FreeBSD.org> Date: Wed, 27 Jun 2012 11:43:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61AEEA87-2AD8-4174-A282-B093EA12BBA6@bsdimp.com> References: <1340807413.83238.YahooMailClassic@web113515.mail.gq1.yahoo.com> <4FEB1F20.8010704@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmh9FWWYnwTgf2d+sOJ9w9p8VresmV9EKWUSzhnFAef0tiz6IHF3E+3EkwZ2p/kPx1UEW3d X-Mailman-Approved-At: Wed, 27 Jun 2012 18:07:19 +0000 Cc: pfg@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:43:07 -0000 On Jun 27, 2012, at 8:56 AM, Doug Barton wrote: > So can we please stop pretending that it's me who's the problem, and > start looking at these things rationally? What is your short list of issues? =46rom a high level there appear to = be none, but the devil is in the details, eh? =46rom earlier in the thread, bsdsort and gnu sort are compatible. old, = crunchy, unmaintained gnu sort that we have in the tree isn't compatible = with either new gnu sort nor bsdsort. this means it isn't compatible = with what the linux crowd is using, which is another consideration given = the number of shell scripts that originate there these days. Warner From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 18:22:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9C17106564A; Wed, 27 Jun 2012 18:22:45 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id DEB828FC08; Wed, 27 Jun 2012 18:22:44 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4F0E8FFA; Wed, 27 Jun 2012 20:22:43 +0200 (CEST) Date: Wed, 27 Jun 2012 20:20:39 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120627182038.GB1401@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Rabson , John Baldwin , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 18:22:45 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: > >=20 > > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > > provider) will not work properly with partition editors for other OS's.= I'm=20 > > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > > gmirror violates the GPT spec. >=20 > Agreed. Guys. This doesn't violate the GPT spec in any way. The spec is narrow-minded if it talks only about raw disks, but you should think about gmirror as pseudo-hardware RAID. That's all. If putting GPT on top of RAID array is spec violation, then I guess we just have to live with it. > While it is a nice trick to use the last sector for meta data, it does > create 2 problems. 1 is mentioned above. [...] It doesn't really matter where gmirror puts its metadata. If gmirror would keep its metadata in the first sector, gpart/gpt will find its metadata in the last sector and will complain about missing primary header. > [...] The second is that when there's > different metadata in the first *and* the last sector, you can't decide > which is to take precedence without also looking at the other and know > how to interpret it. We have not solved this second problem at all. We > do get reports about the problems though. At best we're handwaving or > kluging. This is different kind of problem. It took me a while to realize that, but now I know:) The real problem is that not all metadata formats are suitable for autodetection. That's all. The metadata I use in my GEOM classes play nice with autodetection. The solution is very easy - keep size of the disk device within metadata. This allows gmirror to figure out if it is configured on raw disk, last slice or last partition within last slice, etc. If GPT would keep disk size in its metadata the second problem you mentioned would not exist. And to be honest GPT kinda does that by having backup header's LBA stored in the primary header. And this is fine as long the primary header is valid. The same problem is with things like UFS labels. There is no way to properly support them using GEOM autodetection, because there is no provider size in UFS superblock. UFS superblock contains file system size, but it is not the same, as one can create smaller file system than the underlying disk device. > I think it's unwise to depend on FreeBSD-specific extensions or features > in industry-standard partitioning schemes and as such make the use of > "foreign" tools hard if not impossible. If you plan to use the given disk with FreeBSD only, what's the problem? Partitioning is not the end of the world. Even if you use "industry-standard partitioning schemes" what file system are you going to use to actually access your data? FAT? Of course if you do share your disk between various OSes then probably your best bet is to use MBR or GPT on raw disk and FAT file system. But if you use your disk with FreeBSD only, then I see no reason to not to leverage FreeBSD-specific features (be it gmirror, geli or zfs). > A much more flexible approach is to support out-of-band configuration > data. This allows us to mirror GPT disks without having to become non- > standard as it removes the need to use the last sector for meta-data. > The ability to construct GEOM hierarchies unambiguously is very > important and our current approach has proven to not deliver on that. > This is actually impacting existing FreeBSD consumers already, like > Juniper. So, se should not go deeper into this rabbit hole. We should > finally solve this problem for real... Marcel, nothing stops anyone from implementing GEOM mirror class that uses no on-disk metadata. GEOM is not a limiting factor here. GEOM does provide mechanism for autoconfiguration, but it is totally optional and GEOM class might choose not to use it. As an example you can take a look at two other GEOM classes of mine: gconcat(8) and gstripe(8). You can use 'label' subcommand to store metadata on component disks, which will take advantage of GEOM autodetection and autoconfiguration. You can also use 'create' subcommand to create ad hoc provider that stores no metadata and makes use of entire disks, which also means it won't be automatically created on next boot. For Juniper it might be more handy to use out-of-band configuration as you know the hardware you are running on, so you know where the disks are exactly, etc. My company build appliances too, so I have been there. For most of our users automatic configuration is simply better, as they can shuffle disks around and not wonder if the system will boot or not. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rTvYACgkQForvXbEpPzTZwwCgy+YI9gzwZnE6G1ZMgpOl1G0t qJcAoO/lUg0evhqdiMeX/AGhxIq2yahP =JS+Z -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 18:36:52 2012 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 D49301065670; Wed, 27 Jun 2012 18:36:52 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7C69D8FC16; Wed, 27 Jun 2012 18:36:52 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E71C346; Wed, 27 Jun 2012 20:36:50 +0200 (CEST) Date: Wed, 27 Jun 2012 20:34:47 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120627183446.GC1401@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 18:36:53 -0000 --p2kqVDKq5asng8Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 10:45:35AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > >=20 > > As for sharing disk with other OS. If you share the disk with OS that > > doesn't support gmirror, you shouldn't use gmirror in the first place. > > You probably want to use only formats that are recognized by all your > > OSes. >=20 > This statement is ridicuous by virtue of not being in touch with > reality and by making gmirror useless for such wide range of cases > that one can question why we have it at all. >=20 > Put differently: a mirroring class is a fairly basic and useful thing > to have. Limiting it's use is nothing but artificial and follows from > having to use the underlying provider to store metadata. This then > changes the view of the underlying providing to consumers above gmirror > in a way that makes the presence or absence of gmirror visible. > Solving the visibility problem makes gmirror useful all the time. > I see that as a better way of looking at it than simply blurting out > that you shouldn't use gmirror when certain awkward and artifical > conditions apply. I'm sorry, Marcel, but what you describe here has nothing to do with reality. To be able to implement realiable mirroring you have to use on-disk metadata. There is no way around that. You can implement non-redundant GEOM classes without using on-disk metadata, but out-of-band configuration in case of mirroring is simply naive. How do you detect that components are out of sync, for example? And when it comes to visablity. Are you suggesting that gmirror should present entire underlying provider to upper layers? Including its metadata? I hope not, because we went through that hell already (remember skipping first 16 sectors by UFS, as BSDlabel metadata might be there? The same for swap?). I think I did pretty good job by making the metadata as simple as possible - I use exactly one sector at the end of the target device. I'm really having a hard time to think of a simpler format. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rUkYACgkQForvXbEpPzQMtgCZAREkUfa4bpLIFZc7sfKY87Vu 6hcAoLp8W6xgJg6eViZG1ZU3RXsvEgrC =ZREU -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:02:43 2012 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 9EF441065782; Wed, 27 Jun 2012 19:02:42 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id B26FD8FC17; Wed, 27 Jun 2012 19:02:41 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,486,1336363200"; d="scan'208";a="200280882" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 15:02:37 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 27 Jun 2012 12:02:36 -0700 From: Oleg Moskalenko To: 'olli hauer' , FreeBSD Current Date: Wed, 27 Jun 2012 12:02:36 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1UjkbKNaLVd3jbR1S4dNedM6MLvwACOAbQ Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB7A@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEB494A.80003@gmx.de> In-Reply-To: <4FEB494A.80003@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gabor Kovesdan Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:02:43 -0000 Olli, Thanks for the feedback. We are working on some minor improvements and fixe= s, when we are done we will commit=20 them to the ports and to the base system. If you see any problems and inconsistencies, please let us know ASAP so we = can fix that. Regards, Oleg > -----Original Message----- > From: olli hauer [mailto:ohauer@gmx.de] > Sent: Wednesday, June 27, 2012 10:56 AM > To: FreeBSD Current > Cc: Gabor Kovesdan; Oleg Moskalenko > Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > On 2012-06-27 08:04, Gabor Kovesdan wrote: > > Hi Folks, > > > > as I announced before, the default sort in -CURRENT has been changed > > to BSD sort. Since the import, the reported minor bugs have been > > fixed and BSD sort has passed the portbuild test. If you encounter > any > > problems or incompatibility with the old GNU version, please report. > > > > Gabor >=20 > Thanks, I'm running textproc/bsdsort now a view weeks as BASE > replacement > on 8.3 and haven't seen any issues even on files with a view GB. >=20 > Are you planing to update the port with your latest version? >=20 >=20 > -- > Regards, > olli From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:05:33 2012 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 3A3891065670; Wed, 27 Jun 2012 19:05:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E72D98FC25; Wed, 27 Jun 2012 19:05:32 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJ5RUp012065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:05:31 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120627183446.GC1401@garage.freebsd.pl> Date: Wed, 27 Jun 2012 12:05:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <05236C69-0029-4FB1-ADFA-243D64AA3079@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> <20120627183446.GC1401@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:05:33 -0000 On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote: > > I'm sorry, Marcel, but what you describe here has nothing to do with > reality. To be able to implement realiable mirroring you have to use > on-disk metadata. There is no way around that. You can implement > non-redundant GEOM classes without using on-disk metadata, but > out-of-band configuration in case of mirroring is simply naive. How do > you detect that components are out of sync, for example? GEOM configuration and per-class runtime state are not to be treated the same. Out-of-band configuration is trivial. Per-class runtime state, like whether elements in a mirrored configuration are in sync or not is more difficult, but does not a priori require on-disk metadata as it's implemented now. You can have the configuration tell the GEOM where that state is being kept, so that you can put it in a partition on the disks involved, or even keep it independent from the disks, which then requires disks to be uniquely identifiable, for sure. But that's what GPT gives you anyway. But even without identification, you can invert the question from "how do I detect that components are out of sync" to "how do I prove they are in fact in sync". That question has a very simple O(n) answer. So, if time isn't a concern or your storage is small, you can always scan all sectors as such prove that the disks are in sync. The point being: the current implementation isn't the only one. Granted, it can easily be the simplest one or even the best one in some cases, but that's besides the point you were making. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:08:55 2012 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 6F9781065687; Wed, 27 Jun 2012 19:08:55 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 0076D8FC26; Wed, 27 Jun 2012 19:08:54 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 4D7FA5C3B; Wed, 27 Jun 2012 21:08:45 +0200 (CEST) Message-ID: <4FEB5A3C.5050900@borderworlds.dk> Date: Wed, 27 Jun 2012 21:08:44 +0200 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> In-Reply-To: <201206271028.54477.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:08:55 -0000 On 06/27/12 16:28, John Baldwin wrote: > On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > >> When we are in the FreeBSD, our loader can detect that device size >> is lower than it see and it will work. When primary header is OK, then >> other OSes should work with this GPT. When it isn't OK, you just can't >> load other OS :) > > Ah, yes. The solution to violating standards is to make sure you never > use standards-compliant software. That's a great argument. :) > > (Although not entirely uncommon. Standards aren't always perfect, but if > we had a way to not gratuitously violate them it would be nice to avoid > doing so.) To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? Whole disk (start) | GPT header | GPT partition of type freebsd-geom (start) | | gmirror device (start) | | | GPT header | | | | freebsd-boot | | | | freebsd-ufs | | | | freebsd-swap | | | GPT backup header | | gmirror metadata | | gmirror device (end) | GPT partition of type freebsd-geom (end) | GPT backup header Whole disk (end) Nothing but FreeBSD would understand the freebsd-geom partition type, so the inner GPT device should be valid and standards compliant. The boot loader would of course need to understand this setup but that shouldn't be impossible. Just a thought. It might be too complicated compared to the non-standards compliant way it works now which works quite well in practice though. -- Christian Laursen From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:12:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E56371065679; Wed, 27 Jun 2012 19:12:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9960F8FC17; Wed, 27 Jun 2012 19:12:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1c1d:425:65f1:4fac] (unknown [IPv6:2001:7b8:3a7:0:1c1d:425:65f1:4fac]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD8035C59; Wed, 27 Jun 2012 21:12:17 +0200 (CEST) Message-ID: <4FEB5B0E.8020009@FreeBSD.org> Date: Wed, 27 Jun 2012 21:12:14 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:12:25 -0000 On 2012-06-26 14:50, Andrey V. Elsukov wrote: > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. It would be nice if you could check it with clang now and again, before you finally merge this project into head. From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:12:26 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B782106566B; Wed, 27 Jun 2012 19:12:26 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D38688FC1E; Wed, 27 Jun 2012 19:12:25 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJCLDo012105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:12:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120627182038.GB1401@garage.freebsd.pl> Date: Wed, 27 Jun 2012 12:12:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17E70D3D-1F05-4EF2-9E66-CDCA65329EF2@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> <20120627182038.GB1401@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , John Baldwin , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:12:26 -0000 On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote: > On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: >>=20 >> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: >>>=20 >>> GPT really wants the backup header at the last LBA. I know you can = set it,=20 >>> but I've interpreted that as a way to see if the primary header is = correct or=20 >>> not. It seems to me that GPT tables created in this fashion (inside = a GEOM=20 >>> provider) will not work properly with partition editors for other = OS's. I'm=20 >>> hesitant to encourage the use of this as I do think putting GPT = inside of a=20 >>> gmirror violates the GPT spec. >>=20 >> Agreed. >=20 > Guys. This doesn't violate the GPT spec in any way. The spec is > narrow-minded if it talks only about raw disks, but you should think > about gmirror as pseudo-hardware RAID. I'm sorry, but this is a contradiction. If it doesn't violate the spec, then the spec is not narrow-minded on the grounds of what we're discussing. If the spec *is* narrow-minded then obviously it doesn't capture our scenario, which means that we're violating the spec. Clearly we're not discussing anything that falls well within the spec, or is undebatable. This makes the whole topic dangerous anyway. When you're in the grey area (this is only for argument's sake -- we're in violation for sure) you're opening yourself up to compatibility problems. Should we deliberately go there? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:14:02 2012 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 963C11065674 for ; Wed, 27 Jun 2012 19:14:02 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id E91EF8FC08 for ; Wed, 27 Jun 2012 19:14:01 +0000 (UTC) Received: (qmail invoked by alias); 27 Jun 2012 19:14:00 -0000 Received: from p578be941.dip0.t-ipconnect.de (EHLO [192.168.0.100]) [87.139.233.65] by mail.gmx.net (mp037) with SMTP; 27 Jun 2012 21:14:00 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX18vaUk+t/MvqcB+xqoJzPt0odq0BPwwTBW6eDiOu6 oBWYIGQyEk1Ey+ Message-ID: <4FEB5B77.5070407@gmx.de> Date: Wed, 27 Jun 2012 21:13:59 +0200 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current References: <4FEAA280.2070705@FreeBSD.org> <4FEB494A.80003@gmx.de> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB7A@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB7A@SJCPMAILBOX01.citrite.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Oleg Moskalenko , Gabor Kovesdan Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:14:02 -0000 On 2012-06-27 21:02, Oleg Moskalenko wrote: > Olli, > > Thanks for the feedback. We are working on some minor improvements and fixes, when we are done we will commit > them to the ports and to the base system. > > If you see any problems and inconsistencies, please let us know ASAP so we can fix that. > > Regards, > Oleg Hi Oleg, until now I haven't found any issues, and I'm already in love with the new '-h' parameter which is really useful for some reporting scripts :) Regards, olli > >> -----Original Message----- >> From: olli hauer [mailto:ohauer@gmx.de] >> Sent: Wednesday, June 27, 2012 10:56 AM >> To: FreeBSD Current >> Cc: Gabor Kovesdan; Oleg Moskalenko >> Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >> >> On 2012-06-27 08:04, Gabor Kovesdan wrote: >>> Hi Folks, >>> >>> as I announced before, the default sort in -CURRENT has been changed >>> to BSD sort. Since the import, the reported minor bugs have been >>> fixed and BSD sort has passed the portbuild test. If you encounter >> any >>> problems or incompatibility with the old GNU version, please report. >>> >>> Gabor >> >> Thanks, I'm running textproc/bsdsort now a view weeks as BASE >> replacement >> on 8.3 and haven't seen any issues even on files with a view GB. >> >> Are you planing to update the port with your latest version? >> >> >> -- >> Regards, >> olli > From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:14:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9097106568A; Wed, 27 Jun 2012 19:14:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BA2558FC14; Wed, 27 Jun 2012 19:14:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07B8DB95D; Wed, 27 Jun 2012 15:14:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 27 Jun 2012 15:10:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <20120626214330.GG1399@garage.freebsd.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206271510.39413.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 15:14:17 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Pawel Jakub Dawidek , Andriy Gapon , Marcel Moolenaar Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:14:18 -0000 On Wednesday, June 27, 2012 1:45:35 pm Marcel Moolenaar wrote: > > On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > > > > As for sharing disk with other OS. If you share the disk with OS that > > doesn't support gmirror, you shouldn't use gmirror in the first place. > > You probably want to use only formats that are recognized by all your > > OSes. > > This statement is ridicuous by virtue of not being in touch with > reality and by making gmirror useless for such wide range of cases > that one can question why we have it at all. > > Put differently: a mirroring class is a fairly basic and useful thing > to have. Limiting it's use is nothing but artificial and follows from > having to use the underlying provider to store metadata. This then > changes the view of the underlying providing to consumers above gmirror > in a way that makes the presence or absence of gmirror visible. > Solving the visibility problem makes gmirror useful all the time. > I see that as a better way of looking at it than simply blurting out > that you shouldn't use gmirror when certain awkward and artifical > conditions apply. I'm not sure we can force gmirror to be anything except FreeBSD-specific, but it would be nice to not make non-standard GPT tables while we are at it. The reason the metadata for things like Intel's onboard SATA RAID does work ok is because the metadata format is enforced by the vendor, so it is reasonable to assume that metadata format will work across other OS's. Anyway, I've said my piece and will let the matter drop from my end at this point. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:15:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D9AC106567A; Wed, 27 Jun 2012 19:15:13 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E338C8FC18; Wed, 27 Jun 2012 19:15:12 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJF2Eo012116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:15:09 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4FEB5A3C.5050900@borderworlds.dk> Date: Wed, 27 Jun 2012 12:14:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> To: Christian Laursen X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:15:13 -0000 On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > On 06/27/12 16:28, John Baldwin wrote: >> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>=20 >>> When we are in the FreeBSD, our loader can detect that device size >>> is lower than it see and it will work. When primary header is OK, = then >>> other OSes should work with this GPT. When it isn't OK, you just = can't >>> load other OS :) >>=20 >> Ah, yes. The solution to violating standards is to make sure you = never >> use standards-compliant software. That's a great argument. :) >>=20 >> (Although not entirely uncommon. Standards aren't always perfect, = but if >> we had a way to not gratuitously violate them it would be nice to = avoid >> doing so.) >=20 > To be standards compliant and allow whole-disk based mirroring to work = at the same time wouldn't nested GPT work like this? GPTs don't nest. > Nothing but FreeBSD would understand the freebsd-geom partition type, = so the inner GPT device should be valid and standards compliant. If it were standards compliant, it would be discoverable by non-FreeBSD. That clearly isn't the case -- hence it's not standards compliant. What for example if someone wanted to share the swap partition between Linux and FreeBSD? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 19:27:43 2012 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 BCBA41065670; Wed, 27 Jun 2012 19:27:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward6.mail.yandex.net (unknown [IPv6:2a02:6b8:0:202:22cf:30ff:fe6b:6ebc]) by mx1.freebsd.org (Postfix) with ESMTP id EF7938FC1D; Wed, 27 Jun 2012 19:27:42 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6.mail.yandex.net (Yandex) with ESMTP id 6BC5B1122011; Wed, 27 Jun 2012 23:27:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340825261; bh=OkIspLjKNGyDaXq1y54PSoQ1RwCOJlaxTYj6xdEDex8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=WEM/gdYAgPrvfgtzz2Ut57kWXpxwvT3h575FAUMWCrqRDbUauQXUZ+OHE9I/w6HXt DkXqPjTwurTeBjIDz+L5vsZAAuNArZxOPxrlGjfhAGZTmbmEhOwqYEi39z9YSp6+GW ODlC+gKC61OQhxQHPCx83+6QmBNc0aprTkC5o4qw= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id E141A1B604F8; Wed, 27 Jun 2012 23:27:40 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ReOCrCvP-ReOStuZF; Wed, 27 Jun 2012 23:27:40 +0400 X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340825260; bh=OkIspLjKNGyDaXq1y54PSoQ1RwCOJlaxTYj6xdEDex8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=eWuqWtCm5wixM4u9+w5Mht+fOE+tsyf0ejOwz+dW8gs9aNGc5piFB1qkicRFRxfcX hc4beO5f0yRROxtjbMaffb1yf33TEnBF7ep3B6vEWHGFydimWesxp4kvEu4qGGskNO VJYI9hHykSYemJzvLzQZh8waNbYVUj0ipqShUClI= Message-ID: <4FEB5EA1.7060903@yandex.ru> Date: Wed, 27 Jun 2012 23:27:29 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> In-Reply-To: <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83CA4CDA895588EA348A5B70" Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 19:27:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83CA4CDA895588EA348A5B70 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 27.06.2012 21:55, Marcel Moolenaar wrote: > You can't just re-interpret standards to match a context you know very = well > isn't applicable and consequently redefine what the word "device" means= =2E > You're on a slippery slope and while you may not see it as a problem, y= ou > do make it a problem for FreeBSD users. It's our users we should be kee= ping > in mind when we solve problems. >=20 >> If a user wants modify GPT in the disk editor from the another OS, >> he can do it, and it should work. The result depends only from the par= tition editor, >> it might overwrite the last sector and might don't. >=20 > Right. Another happy user that sees his/her FreeBSD installation destro= yed > or degraded (no mirroring, warning messages about corrupted GPT, etc) f= or > no apparent reason and without any kind of warning that what he/she is = doing > is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. You can just read the lists, articles about installing FreeBSD, forums, etc. We already have these users and i hope they will use FreeBSD as before. So, why can't add a simple quirk to make theirs system a bit more reliable? As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is "GEOM::" signature. It tries to read one previous sector and there is *valid* GPT header. It is valid, because it's CRC is valid, it's self_LBA is valid. For the *FreeBSD* users it is better to don't use this GPT and just complain "i'm sorry, can't boot". The other OSes can't, and we shouldn't. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. Ok, I can propose several ways to resolve this: * remove from the loader's GPT probing code restriction to necessarily have PMBR partition record in the MBR; * teach the boot0cfg command properly write the PMBR; * add new condition to mark GPT as corrupt when it has invalid PMBR. Thus, when you write PMBR with empty partition table with dd(1), the kernel will complain and you will be forced to run `gpart recover`. --=20 WBR, Andrey V. Elsukov --------------enig83CA4CDA895588EA348A5B70 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.19 (FreeBSD) iQEcBAEBAgAGBQJP616pAAoJEAHF6gQQyKF6+e4H/iJa1VBeTVo2y5XMs0n4jwSZ ESorJVjkq+erib5v25ww5YHD4B2302wYaSJUu4dSHtWvAv9WRbMz917GPnYegc8T PNGPOuVFUqBYcdlBbJFoPg+yZG+OdkLzjLrcQk3GCOpapBxTD5FNhGaWzwtZUhJ2 yD0wnmS1qwJKObiJxWQOgC9NoJJT06b033ss+aj8qERbE0Sh7jijDycG4rNDYI71 b5LbBXqU+YrmJRrWz4x9i1kKBe/O6XVgeNEW/wmhz7XuWQiCnJ7jiUknrsxYofP/ 7ybGIgZaQn+ZhC0AFkdiqxF5RW/sYsB+CIeOoGtZnG8zclgkdUJNsgv9L+BCdBs= =r5NN -----END PGP SIGNATURE----- --------------enig83CA4CDA895588EA348A5B70-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 20:14:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC3DB1065673; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 990018FC0A; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RKEDrR012391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 13:14:20 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB5EA1.7060903@yandex.ru> Date: Wed, 27 Jun 2012 13:14:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 20:14:24 -0000 On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote: > On 27.06.2012 21:55, Marcel Moolenaar wrote: >> You can't just re-interpret standards to match a context you know = very well >> isn't applicable and consequently redefine what the word "device" = means. >> You're on a slippery slope and while you may not see it as a problem, = you >> do make it a problem for FreeBSD users. It's our users we should be = keeping >> in mind when we solve problems. >>=20 >>> If a user wants modify GPT in the disk editor from the another OS, >>> he can do it, and it should work. The result depends only from the = partition editor, >>> it might overwrite the last sector and might don't. >>=20 >> Right. Another happy user that sees his/her FreeBSD installation = destroyed >> or degraded (no mirroring, warning messages about corrupted GPT, etc) = for >> no apparent reason and without any kind of warning that what he/she = is doing >> is potentially harmful... That's the spirit! >=20 > Ok. Let's return back to my patches. They don't add any new methods to > shoot in the foot. We are talking about the *FreeBSD loader*. > This is the program that starts FreeBSD kernel. It doesn't start other > OS. We already have many users who uses FreeBSD as a single system on > the machine. Many of them use GPT inside of some GEOM provider. Your patches are a continuation on a path that we're discussing isn't necessarily the path we should be on. While you don't make things worse from a compliance perspective, you make it worse by adding the non-compliant behaviour to more components. > As i understand there two parts where we haven't a consensus: >=20 > 1. You are against from: > Our loader detects that primary GPT header is damaged. It tries to = read > backup GPT header from the last LBA and it detects that there is > "GEOM::" signature. It tries to read one previous sector and there is > *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. > 2. You are against from having one fake PMBR entry by default in the > /boot/pmbr image. I don't understand what you're saying or what I'm being accused to be against. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 20:29:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03CB01065672; Wed, 27 Jun 2012 20:29:36 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id A71C88FC14; Wed, 27 Jun 2012 20:29:35 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id D7F5114E7AD5; Wed, 27 Jun 2012 22:29:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oltKpA5IlUoZ; Wed, 27 Jun 2012 22:29:34 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id EDB8614E7ACD; Wed, 27 Jun 2012 22:29:33 +0200 (CEST) Message-ID: <4FEB6D2B.4090508@FreeBSD.org> Date: Wed, 27 Jun 2012 22:29:31 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120604 Thunderbird/14.0a2 MIME-Version: 1.0 To: Doug Barton References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> In-Reply-To: <4FEAC5B1.30104@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko , FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:29:36 -0000 On 2012.06.27. 10:34, Doug Barton wrote: > Great, can you post the results somewhere? I understand what you're > saying below that there are situations where worse performance may need > explanation, but it would be helpful if we had the data to look at. If something is buggy than it is not comparable in terms of performance because usually those bugs are the exact problem of the better performance because of the negligence of some checks or aspects that were not well considered. > And the project cannot grow if we lose users due to gratuitous > differences in core utilities. There are more Linux users than FreeBSD users and they all use GNU sort. A great percent of FreeBSD users also manages Linux systems at work so they may also be using new GNU sort features. So in short, what people more usually expect is the behavior of the latest GNU version and POSIX-conformance, not an obsolete, buggy behavior. Losing users because something works better does not seem to be a real threat. But if this is a problem then we should stop fixing bugs and adding features at all since it may discourage someone from using FreeBSD. > In the case of grep, there were a fairly large number of people who > agreed that a BSD grep with orders of magnitude worse performance than > the previous version was not something we, as a project, were willing to > stomach. Sufficiently such that the default was switched back. These are relevant critics. But remember that it lived together with GNU grep so the switch back didn't have a great impact. It was slow but at least it worked. Recently the build is so regularly broken that it makes much more harm. With BSD sort, it is the same case, if there are problems that are hard to solve, we will switch back easily. Gabor From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 20:31:39 2012 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 C53E0106566C for ; Wed, 27 Jun 2012 20:31:39 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 736708FC0C for ; Wed, 27 Jun 2012 20:31:39 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id AB38214E7AD6; Wed, 27 Jun 2012 22:31:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FU2zFc34cbxe; Wed, 27 Jun 2012 22:31:38 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 38E3214E7AD5; Wed, 27 Jun 2012 22:31:38 +0200 (CEST) Message-ID: <4FEB6DA9.6080105@FreeBSD.org> Date: Wed, 27 Jun 2012 22:31:37 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120604 Thunderbird/14.0a2 MIME-Version: 1.0 To: "O. Hartmann" References: <4FEAA280.2070705@FreeBSD.org> <4FEAA3F8.4020906@zedat.fu-berlin.de> In-Reply-To: <4FEAA3F8.4020906@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:31:39 -0000 On 2012.06.27. 8:11, O. Hartmann wrote: > ... so, can I delete the entry > WITH_BSD_SORT=yes > in /etc/src.conf then? Yes. BSD sort will still be the default. And if you want default GNU sort, you can add WITH_GNU_SORT=yes. Gabor From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 20:48:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4854E1065674; Wed, 27 Jun 2012 20:48:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward19.mail.yandex.net (forward19.mail.yandex.net [IPv6:2a02:6b8:0:1402::4]) by mx1.freebsd.org (Postfix) with ESMTP id A02588FC0A; Wed, 27 Jun 2012 20:48:07 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward19.mail.yandex.net (Yandex) with ESMTP id D87DC11215B9; Thu, 28 Jun 2012 00:48:05 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340830086; bh=fpN5xy35M4eeleaFZ3TpM92u3EFVrXqcUDZiQR1AXz4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WLNhS25Kcw1+BJgM1x0EAYojavokukfK/wSGYeBCX38POdmElVRKJi69ZVz6+Sowh u4rB2zW9ScCq2J14+Wc4AsPSct/D0khNTqXnlLAldIl/oKdHHFIlkx4bGUI5XZxw/V 8uLAqjzR+xZsvdzZSqvEZs0PNgXSS93GHVhinKTo= Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 5AD0918A019A; Thu, 28 Jun 2012 00:48:05 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id m4V0IY66-m4Vab2EW; Thu, 28 Jun 2012 00:48:05 +0400 X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340830085; bh=fpN5xy35M4eeleaFZ3TpM92u3EFVrXqcUDZiQR1AXz4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=XxoeMQsw7zjOrNVK3xpMoLXmojQOK64dz55HMu4ynyurBFZ6+3oMv/DOPP4DnpvNK IDu7/5IHEQkAXvkmg87GfK/hjc4UX6n+4MLfws+XQMQTMu76CpnT/zoVsWXJ/ZyVQb fT9XcnMKFzfKhvLFKMrPqF9Dlzz3TiXb2ZiMjjlc= Message-ID: <4FEB7181.9000508@yandex.ru> Date: Thu, 28 Jun 2012 00:48:01 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 20:48:08 -0000 On 28.06.2012 00:14, Marcel Moolenaar wrote: >> Our loader detects that primary GPT header is damaged. It tries to read >> backup GPT header from the last LBA and it detects that there is >> "GEOM::" signature. It tries to read one previous sector and there is >> *valid* GPT header. > > How do you know it's valid? It's in a location that is not valid > to begin with. Validity is based on rules and you're violating the > the rules without defining exactly what we call valid given the > new rules. This may seem nitpicking, but having went through the > hassle of dealing with the broken way we created the dangerously > dedicated disk, I appreciate the importance of being anal when it > comes to something that lives on non-volatile storage and gets to > be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 21:12:02 2012 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 396291065672; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 06BE38FC0C; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RLBqNW012645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 14:11:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB7181.9000508@yandex.ru> Date: Wed, 27 Jun 2012 14:11:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <4FEB7181.9000508@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 21:12:02 -0000 On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote: > On 28.06.2012 00:14, Marcel Moolenaar wrote: >>> Our loader detects that primary GPT header is damaged. It tries to read >>> backup GPT header from the last LBA and it detects that there is >>> "GEOM::" signature. It tries to read one previous sector and there is >>> *valid* GPT header. >> >> How do you know it's valid? It's in a location that is not valid >> to begin with. Validity is based on rules and you're violating the >> the rules without defining exactly what we call valid given the >> new rules. This may seem nitpicking, but having went through the >> hassle of dealing with the broken way we created the dangerously >> dedicated disk, I appreciate the importance of being anal when it >> comes to something that lives on non-volatile storage and gets to >> be exposed to a world much larger than FreeBSD. > > So why do you not prevent to attach GEOM_PART_GPT to any providers that > are not the disk drive? This will be the right solution to all our > problems. Just don't create invalid GPT. It's not even the right solution, as it prevents legit nesting of gpart GEOMs *and* is fundamentally based on a flawed assumption that any non-disk GEOM underneath gpart yields an invalid GPT. Think gnop. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 21:39:08 2012 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 E3FFC106564A; Wed, 27 Jun 2012 21:39:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 96E688FC0C; Wed, 27 Jun 2012 21:39:08 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CF3503B080; Wed, 27 Jun 2012 21:39:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q5RLd0tL060048; Wed, 27 Jun 2012 21:39:01 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 27 Jun 2012 14:11:46 MST." <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 27 Jun 2012 21:39:00 +0000 Message-ID: <60047.1340833140@critter.freebsd.dk> Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jun 2012 21:39:09 -0000 I would like to point out that all other operating system which has had this precise problem, have solved it by adding a bootfs partition to hold the kernel+modules required to truly understand the disk-layout ? -- 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 Jun 27 23:12:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4422D106566B; Wed, 27 Jun 2012 23:12:00 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 069928FC27; Wed, 27 Jun 2012 23:11:59 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with ESMTP id q5RNBwp9024836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jun 2012 18:11:58 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 27 Jun 2012 18:11:58 -0500 From: Devin Teske Date: Wed, 27 Jun 2012 16:11:56 -0700 Message-ID: To: MIME-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-27_05:2012-06-27, 2012-06-27, 1970-01-01 signatures=0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Devin Teske , Ron McDowell Subject: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 23:12:00 -0000 Hi All, I'd like to announce that I intend to import bsdconfig(8) today. =3D=3D=3D Run-up=85 Q. What is bsdconfig(8)? A. dialog(1) based post-install configuration utility for configuring/manag= ing various aspects of FreeBSD. Q. What does it look like? A. No screenshots, but I do have a graphic illustrating the menu layout=85 http://druidbsd.sf.net/download/bsdconfig/bsdconfig-0.7.0-ic.svg Q. Why do we need this in base? A. Because this functionality was exactly produced by sysinstall(8) which h= as been deprecated (will not exist in FreeBSD 10). FreeBSD-9 is where bsdin= stall is being evaluated as a replacement for the install functionality of = sysinstall(8) meanwhile bsdconfig is to replace the configuration/managemen= t functionalities of sysinstall. Q. Did you discuss this with anyone? A. Everyone that would listen in the past 6 months as we run up to the 9.1 = code freeze. Q. Did anyone test this? A. Ron, myself, and about 8 others in the community did both high-level tes= ting, low-level review, and more over the past 6 months. Q. If it doesn't go well, can we back it out? A. Sure -- it's entirely self contained. src/usr.sbin/bsdconfig is the only= directory being touched (oh, and the Makefile in the parent directory to a= dd the new SUBDIR). Any other questions, don't hesitate to ask. =3D=3D=3D Heads-up=85 Code will land in src/usr.sbin/bsdconfig and _nowhere_ else. The code will be voluminous (~20k LOC across ~150 files including ~30 Makef= iles). The code is entirely in sh(1) (don't knock it until you've seen it). The code used in this tool and all sub-modules was developed primarily over= a 150-day period, but in reality contains code developed and revised over = the past 5 years, entirely BSD licensed! All code was written by Ron McDowell and myself. =3D=3D=3D If there are no complaints by End-Of-Day (EOD), I'll go ahead and import. --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 01:45:07 2012 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 D7A1F106564A for ; Thu, 28 Jun 2012 01:45:07 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2528FC0A for ; Thu, 28 Jun 2012 01:45:07 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,488,1336363200"; d="scan'208";a="200319243" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 21:45:05 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Wed, 27 Jun 2012 18:45:04 -0700 From: Oleg Moskalenko To: FreeBSD Current Date: Wed, 27 Jun 2012 18:45:04 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1Uo5g7GRfagTCSQTmFXyZMUcNVBAAKET7Q Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> In-Reply-To: <4FEB6D2B.4090508@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:45:08 -0000 Hi As promised, I am supplying an example of comparison between several sort p= rograms. The test file is a randomly generated 1,000,000 lines, each line contain a = single floating point number.=20 We are going to sort it three ways - as text, as -n numeric sort, and as -g= numeric sort, with 4 programs:=20 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times= are in seconds. Locale C. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TEXT SORT sys user real Old BSD/GNU sort: 0.0 1.692 2.008 New GNU sort: 0.0 2.279 1.605 New BSD sort, st: 0.0 1.964 2.300 New BSD sort, mt: 0.0 2.385 1.897 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NUMERIC SORT -n =20 sys user real Old BSD/GNU sort: 0.0 4.357 4.674 New GNU sort: 0.0 8.839 5.134 New BSD sort, st: 0.0 5.308 5.592 New BSD sort, mt: 0.0 4.581 2.489 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NUMERIC SORT -g sys user real Old BSD/GNU sort: 0.0 45.378 45.630 New GNU sort: ~450 ~121 ~300 New BSD sort, st: 0.33 4.334 5.992 New BSD sort, mt: 11.140 4.624 8.983 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Oleg From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 02:42:36 2012 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 719D9106566B; Thu, 28 Jun 2012 02:42:36 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id D5ACA8FC08; Thu, 28 Jun 2012 02:42:35 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5S2gRYg077995; Thu, 28 Jun 2012 10:42:27 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340851353.2151.7.camel@nsl> From: Kevin Lo To: Konstantin Belousov Date: Thu, 28 Jun 2012 10:42:33 +0800 In-Reply-To: <20120627154233.GO2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> <1340774954.2147.3.camel@nsl> <20120627154233.GO2337@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 02:42:36 -0000 Konstantin Belousov wrote: > On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote: > > Kevin Lo wrote: > > > Konstantin Belousov wrote: > > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > > Konstantin Belousov wrote: > > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > > I've observed a panic in recent -current several times but I only > > > > > > > have a picture of the backtrace: > > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > > > > in your kernel ? > > > > > > > > > > Sure. > > > > > > > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > > > > is int 0x28 which should not appear in the compiled code. > > > > > > > > > > # gdb tmpfs.ko > > > > > (gdb) l *tmpfs_reg_resize+0x627 > > > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005). > > > > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > > > > > > > > In tmpfs_subr.c: > > > > > 999 if (m != NULL) { > > > > > 1000 if ((m->oflags & VPO_BUSY) != 0 || > > > > > 1001 m->busy != 0) { > > > > > 1002 vm_page_sleep(m, "tmfssz"); > > > > > 1003 goto retry; > > > > > 1004 } > > > > > 1005 MPASS(m->valid == VM_PAGE_BITS_ALL); > > > > > 1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU > > > > > LL)) { > > > > > > > > > Hm, can you get a core and > > > > - obtain backtrace in kgdb; > > > > - print the *m content for the page that triggered the assertion ? > > > > > > > > The only possible 'new size' value for the truncation from open(2) is zero, > > > > so I do not understand why the asserted block was executed at all. > > > > > > Thanks for looking into it. Unfortunately I can't get a crash dump > > > due to lack of disk space and memory. > > > > I triggered the KASSERT on a different machine in the last hour. > It is not 'the' KASSERT, it is something different. > > Are you sure that you do not have some systematic build issues on your > machines ? Although I do not think that tmpfs is 'ready for production use' > for arbitrary low value of this statement, there is no steady flow of > similar reports from other users. This makes me somewhat suspicious that > either you might have inconsistent build issues, or unrelated memory > corruption problems. As I mentioned, I'm running -CURRENT on a number of systems. I haven't seen tmpfs panics on machines running FreeBSD 9. Kevin From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 03:46:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA83C1065670; Thu, 28 Jun 2012 03:46:44 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 52F7B8FC12; Thu, 28 Jun 2012 03:46:44 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5S3kahc002046; Wed, 27 Jun 2012 21:46:38 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Thu, 28 Jun 2012 10:46:34 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <201206271206.30639.erichfreebsdlist@ovitrap.com> <4FEAE97C.4000206@FreeBSD.org> <4FEB32B9.10802@FreeBSD.org> In-Reply-To: <4FEB32B9.10802@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206281046.34752.erichfreebsdlist@ovitrap.com> Cc: Andrey Fesenko , Andriy Gapon , Jung-uk Kim Subject: Re: Panic on current from yesterday 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: Thu, 28 Jun 2012 03:46:44 -0000 Hi, On Wednesday 27 June 2012 23:20:09 Jung-uk Kim wrote: > On 2012-06-27 07:07:40 -0400, Andriy Gapon wrote: > > on 27/06/2012 13:44 Andrey Fesenko said the following: > >> On Wed, Jun 27, 2012 at 1:26 PM, Andrey Fesenko > >> wrote: > >>> On Wed, Jun 27, 2012 at 12:42 PM, Andriy Gapon > >>> wrote: > Committed as r237652: > > http://svnweb.freebsd.org/base?view=revision&revision=237652 > I updated my sources around midnight (GMT) and compiled them again. The system then booted without any problems. Perfect! Erich From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 04:28:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0F51106566C; Thu, 28 Jun 2012 04:28:16 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7E818FC0A; Thu, 28 Jun 2012 04:28:15 +0000 (UTC) Received: by werg1 with SMTP id g1so1498791wer.13 for ; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nZkVvSNOCPSopeZn75d6Zb67MbFJL06UZolsShBu+Hs=; b=jWNJD7+ieMRhdS+0RyqS7b5B0V8JXth8Dnx7p1gmKzhiPY4YK5fI5Y6YU1sZYjasTT rgon7sQjX1efuifyAo7SO+ez5IJl8XJV7vQOB8rSLGz0+4aB4MtBcB4t8Jc/+fCBCzCz ZecuUikXddzksetCik42V/L3KQ9u4Y4kqXW1sC62adhvDaHIz8lcyc++rjA+OW9ddK5w GPe9OIdqvYzTbU18LH6jBdy8vRfYjt+c5DFz9vcqSJ2JbpgOjBhlDrJTISK5aVBI94rY 0RBpWEsK08aQ6ZhTW8nB3r9XdMu9WcC1drVCARFzeoZXBfdeYMBpJWuHruGYvfLDpzmW xL2g== MIME-Version: 1.0 Received: by 10.216.215.194 with SMTP id e44mr275286wep.61.1340857688567; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) In-Reply-To: <60047.1340833140@critter.freebsd.dk> References: <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> <60047.1340833140@critter.freebsd.dk> Date: Wed, 27 Jun 2012 21:28:08 -0700 Message-ID: From: Kevin Oberman To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , Marcel Moolenaar , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 04:28:17 -0000 On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp wrote: > > I would like to point out that all other operating system which has > had this precise problem, have solved it by adding a bootfs partition > to hold the kernel+modules required to truly understand the disk-layout ? I have seen some form of this solution suggested three times (once by me) and now by someone who I think I can safely states is pretty familiar with geom. So far I have seen no direct response and only a passing comment by jhb that it might be difficult. Sometimes standards need to be broken. Sometimes they such so badly that te entire industry ignores them. But, unless there i a good reason to ignore them, one should fully justify doing so, all the more so when there are obvious ways that non-compliance can lead to disaster. (Think of geli disk there some other software steps on the last block.) Moreover, I think I can see a legitimate case, though I have not tried it. Say I have a FreeBSD system with a large, unused space on the disk and it uses gmirror. I decide that I need to have the ability to occasionally boot Linux on this system (or, even Windows 8). For some reason, and I can think of several, I can't use a virtual system. I create a new partition for the second OS and install it. It knows nothing about the gmirror, so it just uses the disk it is installed on and never touches the metadata. Is this possible? Looks reasonable to me. I really, really feel uncomfortable about all of this. And when people start claiming that, by a very strained interpretation of what appears on the surface to be a clear specification, they are not violating the standard. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 05:27:29 2012 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 A52E4106564A; Thu, 28 Jun 2012 05:27:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1C43E8FC14; Thu, 28 Jun 2012 05:27:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Sk7GI-0000O5-Km>; Thu, 28 Jun 2012 07:27:26 +0200 Received: from e178021028.adsl.alicedsl.de ([85.178.21.28] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Sk7GI-0005UG-Es>; Thu, 28 Jun 2012 07:27:26 +0200 Message-ID: <4FEBEB37.5060502@zedat.fu-berlin.de> Date: Thu, 28 Jun 2012 07:27:19 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA05B439FD961D78A58367EF4" X-Originating-IP: 85.178.21.28 Cc: freebsd-current@freebsd.org, Ron McDowell , Devin Teske Subject: Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 05:27:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA05B439FD961D78A58367EF4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/28/12 01:11, Devin Teske wrote: > Hi All, >=20 > I'd like to announce that I intend to import bsdconfig(8) today. >=20 > =3D=3D=3D >=20 > Run-up=85 >=20 > Q. What is bsdconfig(8)? > A. dialog(1) based post-install configuration utility for configuring/m= anaging various aspects of FreeBSD. >=20 > Q. What does it look like? > A. No screenshots, but I do have a graphic illustrating the menu layout= =85 >=20 > http://druidbsd.sf.net/download/bsdconfig/bsdconfig-0.7.0-ic.svg >=20 > Q. Why do we need this in base? > A. Because this functionality was exactly produced by sysinstall(8) whi= ch has been deprecated (will not exist in FreeBSD 10). FreeBSD-9 is where= bsdinstall is being evaluated as a replacement for the install functiona= lity of sysinstall(8) meanwhile bsdconfig is to replace the configuration= /management functionalities of sysinstall. >=20 > Q. Did you discuss this with anyone? > A. Everyone that would listen in the past 6 months as we run up to the = 9.1 code freeze. >=20 > Q. Did anyone test this? > A. Ron, myself, and about 8 others in the community did both high-level= testing, low-level review, and more over the past 6 months. >=20 > Q. If it doesn't go well, can we back it out? > A. Sure -- it's entirely self contained. src/usr.sbin/bsdconfig is the = only directory being touched (oh, and the Makefile in the parent director= y to add the new SUBDIR). >=20 > Any other questions, don't hesitate to ask. >=20 > =3D=3D=3D >=20 > Heads-up=85 >=20 > Code will land in src/usr.sbin/bsdconfig and _nowhere_ else. >=20 > The code will be voluminous (~20k LOC across ~150 files including ~30 M= akefiles). >=20 > The code is entirely in sh(1) (don't knock it until you've seen it). >=20 > The code used in this tool and all sub-modules was developed primarily = over a 150-day period, but in reality contains code developed and revised= over the past 5 years, entirely BSD licensed! >=20 > All code was written by Ron McDowell and myself. >=20 > =3D=3D=3D >=20 > If there are no complaints by End-Of-Day (EOD), I'll go ahead and impor= t. >=20 What will happen with the old sysinstall? Well, I'm glad to read that FreeBSD makes a step forward, but maybe there are some people who want to be stick with the old sysinstall. While bsdconfig is flushed in from ports, sysinstall could be flushed out into the ports? If the question or suggestion sounds not rational, dump it ... Regards Oliver --------------enigA05B439FD961D78A58367EF4 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.19 (FreeBSD) iQEcBAEBAgAGBQJP6+s+AAoJEOgBcD7A/5N8r8kIANfc5VevJalYbCRz6SEAGL5R +L/yL8bH5G8z3cJhZOoMN3+wIjEUAxWYPdP0QK1vB9FBqhVTsFKNASFIXGbzKmCt JUvi5SzDwOH9ruWWXJaHw2vK/LoruwUuxYMeDWS/kd3YWJgcDRIHzPvChRT7c1No 3NU+CMqUx0xnz/OwI2GaXVFEvuYI80mEVH5FYrnRQOavmcFmScbIsaufPBd13wJK LAO3rpPA3B7TlSk3wzuhP0cvE9qKsj09SNJchRKGzC1tPONRlFi8ImymN/cySnKC /ZSbBT19OrFNOhJYtMXkUHpi8lt43tkWm/dO4poX78D6aFlqV9vucQFvEMNT2pM= =9/OM -----END PGP SIGNATURE----- --------------enigA05B439FD961D78A58367EF4-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 05:54:19 2012 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 905CA1065670 for ; Thu, 28 Jun 2012 05:54:19 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1F07E8FC08 for ; Thu, 28 Jun 2012 05:54:18 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1490968wib.13 for ; Wed, 27 Jun 2012 22:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=Qn9Zxv0dtu+SLdPljkA2qiybxCnrwEk5SIKnV5NKsGM=; b=kBhWPGun7yBIiG1yUgh4aMpPAc7opsC2DD9PfYpRZj09OogM90rCNklfl48ZX731NI 83U/u/nTWo5H/hZnDz98mOETIenswzp+oWnTKZGQhL3zww6+2congHh1prTA3ZaJumFl lzoSfAclJ/m2ExC35eYjnIL804dl6NwUwiCojSrcub6ggUskGhLefCJVoWKcLRS+tVbD nvUSnI2cVZzsFA5/7GkQnSPfE4ggmYzTwSXqI3R3S1LxUbzOFRyKwe8berewSvoX3L1D 92QpOIea+4PsP/ynThi2lNwmZ5m9yZK0CmNbz3N6j1bXPlHdPK+qajYGXQmMe2eaMtzn V5pg== Received: by 10.216.208.31 with SMTP id p31mr333113weo.134.1340862858069; Wed, 27 Jun 2012 22:54:18 -0700 (PDT) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id f10sm13104397wiw.1.2012.06.27.22.54.15 (version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 22:54:16 -0700 (PDT) Date: Thu, 28 Jun 2012 08:55:04 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Message-ID: <20120628085504.4affaa5a@laptop> In-Reply-To: <4FEBEB37.5060502@zedat.fu-berlin.de> References: <4FEBEB37.5060502@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 05:54:19 -0000 On Thu, 28 Jun 2012 07:27:19 +0200 "O. Hartmann" wrote: [skipped] > > What will happen with the old sysinstall? Well, I'm glad to read that svn log -v -r 225937 svn://svn.freebsd.org/base > FreeBSD makes a step forward, but maybe there are some people who want > to be stick with the old sysinstall. > > While bsdconfig is flushed in from ports, sysinstall could be flushed > out into the ports? > > If the question or suggestion sounds not rational, dump it ... > > Regards Oliver > -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 07:09:52 2012 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 073F11065678; Thu, 28 Jun 2012 07:09:52 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E32D8FC18; Thu, 28 Jun 2012 07:09:51 +0000 (UTC) Received: by lbon10 with SMTP id n10so3303179lbo.13 for ; Thu, 28 Jun 2012 00:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bI1dJBTf8/KyqZCzvryNuK4a/vTuJso/G6lOXbEGbp4=; b=B+k4VbJFzzCYjlHYB2kmjqTCcROstS1TNs0DHHnl6/0ssTRxLzk7xin0S/x8/2c9af QdxoUjdUE2XEva0anSZ/vFtIwSbOafSwUexKDSL+E1twyUz4+9aosRZfWYEgA2Acaqds +OtLOLl2SRJrfUOKTgbhk0+Dm/m6gAUUOwKC4NtUSDlKN89R3OnlhW7Rk3EWXpnQTqsP hA7XkBiURR7RoXjks+DkiQxYGmaOo+FHkFCUtR4qUVTLAvVyQsZeQjdYCPfKFfdHVhhm Fd+vxeflEZgNjZimqV+YpvwuEDy/lL3/04bKnWFcle9uN4JYfIAFRj8bSuXLtwWshhNs Jndg== Received: by 10.112.30.226 with SMTP id v2mr497073lbh.103.1340867389933; Thu, 28 Jun 2012 00:09:49 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id i4sm752391lbg.17.2012.06.28.00.09.48 (version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 00:09:49 -0700 (PDT) Date: Thu, 28 Jun 2012 10:09:48 +0300 From: Gleb Kurtsou To: Kevin Lo Message-ID: <20120628070948.GA1197@reks> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> <1340774954.2147.3.camel@nsl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1340774954.2147.3.camel@nsl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 07:09:52 -0000 On (27/06/2012 13:29), Kevin Lo wrote: > Kevin Lo wrote: > > Konstantin Belousov wrote: > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > I've observed a panic in recent -current several times but I only > > > > > > have a picture of the backtrace: > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > > > in your kernel ? > > > > > > > > Sure. > > > > > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > > > is int 0x28 which should not appear in the compiled code. Kevin, do you have fuse modules loaded? It looks much like memmory corruption issue. From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 08:25:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F3DA1065674; Thu, 28 Jun 2012 08:25:20 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id CA9EB8FC1C; Thu, 28 Jun 2012 08:25:19 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q5S8P5N8079387; Thu, 28 Jun 2012 16:25:06 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1340871912.2151.9.camel@nsl> From: Kevin Lo To: Gleb Kurtsou Date: Thu, 28 Jun 2012 16:25:12 +0800 In-Reply-To: <20120628070948.GA1197@reks> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> <1340774954.2147.3.camel@nsl> <20120628070948.GA1197@reks> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: Konstantin Belousov , freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 08:25:20 -0000 On å››, 2012-06-28 at 10:09 +0300, Gleb Kurtsou wrote: > On (27/06/2012 13:29), Kevin Lo wrote: > > Kevin Lo wrote: > > > Konstantin Belousov wrote: > > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > > Konstantin Belousov wrote: > > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > > I've observed a panic in recent -current several times but I only > > > > > > > have a picture of the backtrace: > > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > > > > > > > > > > Does this look at all familiar to anyone? > > > > > > > > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address > > > > > > in your kernel ? > > > > > > > > > > Sure. > > > > > > > > > > > The screenshot looks strange. The instruction on which the kernel trapped > > > > > > is int 0x28 which should not appear in the compiled code. > > Kevin, do you have fuse modules loaded? It looks much like memmory > corruption issue. No, I don't have that module loaded. # kldstat Id Refs Address Size Name 1 14 0xc0400000 bab9e8 kernel 2 1 0xc0fac000 1d58 msdosfs_iconv.ko 3 2 0xc0fae000 67a8 libiconv.ko 4 1 0xc728e000 9000 tmpfs.ko 5 1 0xc789b000 4000 uhid.ko From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 09:20:18 2012 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 79EF7106566C for ; Thu, 28 Jun 2012 09:20:18 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [84.201.186.23]) by mx1.freebsd.org (Postfix) with ESMTP id 245808FC16 for ; Thu, 28 Jun 2012 09:20:18 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 63F7AD02670 for ; Thu, 28 Jun 2012 13:19:55 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 47E7513402E5 for ; Thu, 28 Jun 2012 13:19:55 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id JsZSoWFG-JsZSX7JW; Thu, 28 Jun 2012 13:19:54 +0400 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org Message-ID: <4FEC21BA.5070606@passap.ru> Date: Thu, 28 Jun 2012 13:19:54 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> In-Reply-To: <4FEB5EA1.7060903@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 09:20:18 -0000 27.06.2012 23:27, Andrey V. Elsukov пишет: > 1. You are against from: > Our loader detects that primary GPT header is damaged. It tries to read > backup GPT header from the last LBA and it detects that there is > "GEOM::" signature. It tries to read one previous sector and there is > *valid* GPT header. Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is not found at last sector of the disk and this sector is a GPT header then look at the previous sector? > It is valid, because it's CRC is valid, it's > self_LBA is valid. For the*FreeBSD* users it is better to don't use > this GPT and just complain "i'm sorry, can't boot". The other OSes > can't, and we shouldn't. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 09:23:57 2012 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 ADD071065679 for ; Thu, 28 Jun 2012 09:23:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2-vm0.bullet.mail.ukl.yahoo.com (nm2-vm0.bullet.mail.ukl.yahoo.com [217.146.183.226]) by mx1.freebsd.org (Postfix) with SMTP id E6D748FC12 for ; Thu, 28 Jun 2012 09:23:56 +0000 (UTC) Received: from [217.146.183.211] by nm2.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [77.238.184.61] by tm4.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [127.0.0.1] by smtp130.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 X-Yahoo-Newman-Id: 477533.38404.bm@smtp130.mail.ukl.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aj1_ABcVM1m_bKiy7nT6Mb_DPxf6oducw7_286ALLjHzzwu qweB9qDvd8URveHB3u028SpgZY8BTFwjnP2Q_2SAmgIeN9Rv3TSaRwpzYcKu jBqc2487vOvgQ3Shk0w_P2BjMbjDYbydycicWTv1Y4XZ3ZnFbFZUs9XfJKhd KX1etpFsfCU4fF1S0ygy8amqbhL62zEHVEQJg6GTGLXXhH5kXJRXtv4jD3qS uIFsntB68FpA8DCj_okZedZjBNuVr3cJyri0uiCplRuhdBRX8whgmWUp_6EC .Wi_xnmM90h8QS_.lkPnEzTDIcIhJ7K._62M.0.ud5h668qjXpK4ORxLA0FO gyN5mhCa06v3K_7Gml_MJ8zm7ZAH4CzHLc6V_PbMu8639GnSI0.pKehW74TY LgxozpK42wrkMmLX58Msm X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp130.mail.ukl.yahoo.com with SMTP; 28 Jun 2012 09:23:44 +0000 GMT Message-ID: <4FEC22A0.9000109@freebsd.org> Date: Thu, 28 Jun 2012 11:23:44 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> In-Reply-To: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 09:23:57 -0000 Am 27.06.2012 21:14, schrieb Marcel Moolenaar: > > On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > >> On 06/27/12 16:28, John Baldwin wrote: >>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>> >>>> When we are in the FreeBSD, our loader can detect that device size >>>> is lower than it see and it will work. When primary header is OK, then >>>> other OSes should work with this GPT. When it isn't OK, you just can't >>>> load other OS :) >>> >>> Ah, yes. The solution to violating standards is to make sure you never >>> use standards-compliant software. That's a great argument. :) >>> >>> (Although not entirely uncommon. Standards aren't always perfect, but if >>> we had a way to not gratuitously violate them it would be nice to avoid >>> doing so.) >> >> To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? > > GPTs don't nest. It is not strictly necessary to use nested GPT to have GMIRROR et.al. and GPT co-exist. And I think this is possible without violation of any standard. Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: MBR or Primary GTP header <> GMIRROR Configuration and State <> (Spare area for Sec. GPT header) If creating a GMIRROR (or other GEOM that keeps state at the end of the provider) left at least the last 32KByte untouched (33 GPT sectors rounded up to a power of 2), GPT could use this spare space to store its Secondary Header. These sectors could be treated as part of the User Data area, i.e. logical addresses would be translated by GMIRROR to skip the GMIRROR configuration sector (which I'd enlarge to at least 4KB for alignment of "User Data 2"). This implies that the GMIRROR specification covers the whole provider (including the spare space but without the sectors holding the GMIRROR config, which are "mapped out"), since updates to the Secondary GPT must be performed on all mirrored devices. This is a complication of the current GMIRROR code, but could be added without impact on existing disk layouts. (I have not checked, whether backwards compatibility mandates introduction of a new GMIRROR class that supports such spare space after the GMIRROR config data, but I assume that there is enough spare space pre-initialized to 0 that can be used to add a flag that declares the 32 KByte beyond the end of the config data to be part of the mirror.) The only modifications required are: - If a GMIRROR is created, place the configuration sector 32 KByte before the end of the provider and mark it as "GPT compatible". (It is unknown at this point, whether GPT is to be used on the mirror at a later time.) - Tasting a provider should support looking for a valid GMIRROR (or GRAID) config sector not only at the end of the provider, but if that fails then also 32 KByte before the end of the provider. The GMIRROR is considered to be the provider for the GPT (i.e. the GMIRROR extends to 32 KByte beyond its config sector). - Creating partitions with MBR or GPT within a GMIRROR is possible without modification. The only difference is that the protected GMIRROR configuration sector is physically within the range of sectors used for the partition, but logically mapped out. The space available for partitioning is the provider size minus the size of the GMIRROR configuration, just as it used to be. - Readind and writing the mirror is allowed for all sectors in the User Data area, as in a "normal" GMIRROR. The only difference is the test for logical sectors in the last 32 KByte, for which the request is modified to be offset by a few sectors to skip the GMIRROR configuration sector. Requests that cover physical sectors before and behind these GMIRROR config sectors must be split. If instead of splitting off the final 32 KByte as "User Data 2", just the 33 sectors (of 512 Byte) required for GPT were assigned to that area, then there would never be requests that extend beyond the GMIRROR config sectors on GPT partitioned disks. But since such request were still possible if MBR partitions were used, code to treat such requests was still required in GMIRROR. There is one caveat, though: Creating a GMIRROR and then using an OS that does not know about FreeBSD to partition the disk would result in the GMIRROR configuration space being ignored. Another problem could be, that the available space in the GPT is the size of the disk minus the GMIRROR configuration sectors, i.e. there is a difference between the number of physical sectors on the disk and the number of sectors to be assigned to partitions by GPT. >> Nothing but FreeBSD would understand the freebsd-geom partition >> type, so the inner GPT device should be valid and standards >> compliant. > > If it were standards compliant, it would be discoverable by non-FreeBSD. > That clearly isn't the case -- hence it's not standards compliant. What > for example if someone wanted to share the swap partition between Linux > and FreeBSD? My suggested modification to GMIRROR would be compatible with other operating systems use of partitions on such devices. They'd just see individual GPT partitioned disks. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 09:41:58 2012 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 2EFCB106566B for ; Thu, 28 Jun 2012 09:41:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [IPv6:2a02:6b8:0:602::3]) by mx1.freebsd.org (Postfix) with ESMTP id 91CB48FC14 for ; Thu, 28 Jun 2012 09:41:57 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward3.mail.yandex.net (Yandex) with ESMTP id 3766DB41408 for ; Thu, 28 Jun 2012 13:41:55 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340876515; bh=hNsblxnOlgzjkE2rUUREYnfJtbVg/CwEgEXBEJaVq3Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ggj3/G2abZ6pnmPOYidg2eLF2sSHfEA3tnX2TTq7H9OMPfrEALbXlAcHN5dN3bI5q HbCmiJ9T1oXUUy5knIXEE4rK43ksvNVlrvy+xWj4o5Jc9Wb5ufuMyW96w8NMB4qgeh ejJ7XVfPdI6+BeifroKWtRK+Jz7iy/PMp/GX1610= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id 193CF5C03D0; Thu, 28 Jun 2012 13:41:55 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id fsFuP00J-fsFuGM7H; Thu, 28 Jun 2012 13:41:54 +0400 X-Yandex-Rcpt-Suid: bsam@passap.ru 1130000005322498 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340876515; bh=hNsblxnOlgzjkE2rUUREYnfJtbVg/CwEgEXBEJaVq3Y=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=fh3rdFGjrgsg33lKHK2i6Vv7MYKo3p2Oq7WVBOF0IyqDztysrDgpoIkSSj9KPXzG6 A8/59a05nsAbcIm3cloxfbjj577L6bce7HS78eNH69W7ndjMcDhstHY82GmXMHaZbn HidX938+5HirgPBNf3pWd70orO0TcnjkHIG6CN1Y= Message-ID: <4FEC26E2.7000206@yandex.ru> Date: Thu, 28 Jun 2012 13:41:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Boris Samorodov References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <4FEC21BA.5070606@passap.ru> In-Reply-To: <4FEC21BA.5070606@passap.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 09:41:58 -0000 On 28.06.2012 13:19, Boris Samorodov wrote: > 27.06.2012 23:27, Andrey V. Elsukov ÐÉÛÅÔ: > >> 1. You are against from: >> Our loader detects that primary GPT header is damaged. It tries to read >> backup GPT header from the last LBA and it detects that there is >> "GEOM::" signature. It tries to read one previous sector and there is >> *valid* GPT header. > > Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is > not found at last sector of the disk > and this sector is a GPT header then look at the previous sector? Then this sector contains GPT table. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 10:10:16 2012 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 4D5CF1065687 for ; Thu, 28 Jun 2012 10:10:16 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by mx1.freebsd.org (Postfix) with SMTP id A66FD8FC16 for ; Thu, 28 Jun 2012 10:10:15 +0000 (UTC) Received: from [77.238.189.234] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [217.146.188.173] by tm15.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [127.0.0.1] by smtp141.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 X-Yahoo-Newman-Id: 327864.28753.bm@smtp141.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4VkEvKYVM1kOK6KImTgspsbRlNNbHUI2PaO5OfXrk9CgX8S ZJaazTcRTQIBdQI3qrFpiQfr.nPWAVz80EfdgTvW_dRRyyXpmFJ7_ErmNn84 SoJvut9yOOt.qHHZqcWKs4tEtCyj5.d_BDyJVjtHIC4iGVio1t.UmpHNKeMo 6bAu5JYW0BgFXdunqD7wAnrwGtAJGLdEUqKgSQl834YBjsOpRJLEE9744yfD ascRayIHSgFabgmGrqjfflWiuZUSPFHAO.Z6ry.7w._GP4O9vk8OLgdkuJgV zxH6kLmG8rGnjQRQYvM7DjHuyQWvQXocLCpJoJ3QffoLZyVE5Yc4Na03bXGJ eyU_A8lHw81sqUzzvHOJBNkIS5svfR3VCwJfkr8hn83PUmosPOp6V7LV6YQP 3_5fvFtUqtuCDhV0.3g5Ux6MUFzdR4Edk2k4koFE- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp141.mail.ird.yahoo.com with SMTP; 28 Jun 2012 03:10:13 -0700 PDT Message-ID: <4FEC2D86.2040505@freebsd.org> Date: Thu, 28 Jun 2012 12:10:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> In-Reply-To: <4FEC22A0.9000109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 10:10:16 -0000 Sorry for following up to self, but ... I just noticed somebody else suggesting the same method (put GMIRROR configuration below Secondary GPT header), but I think there is a problem: If GMIRROR is used to mirror whole GPT partitioned drives, then you want the GPT sectors to be considered part of the mirror (to keep them identical when GPT partitions are created/modified on the mirrored disks). But the GMIRROR configuration must not be assigned to any GPT partition. Therefore it must be protected, either by hiding it (e.g. create a special partition to hold GEOM config data, just to reserve the space within GPT, since the configuration data will still be located by looking at specific sectors of the provider), or by skipping the sectors assigned to GEOM config data in the GEOM provider that interprets them (e.g. GMIRROR). The former only works if a GMIRROR (or GELI or whatever) is created on a disk that already has GPT headers (since these lead to the GEOM config data put before the Secondary GPT header and allow the GEOM config to be marked as a special partition in that header). The latter only works on disks without GPT headers, since the size of the provider will be smaller then the physical disk. Even with the last physical disks available for GPT, the GPT headers will probably not conform to the standard, since remapping of the sectors to hide the GMIRROR config will lead to different logical sector numbers for the secondary GPT header when looked at with or without GMIRROR loaded. I still think it is possible to find a layout, that does not violate the GPT standard (use last LBAs on disk, have self-referential information like own LBA address consistent with physical block numbers and block numbers presented to users of GMIRROR et.al.). Perhaps, GMIRROR could treat its configuration sector (that is placed at the sector just below the secondary GPT header) as read only. Requests may go to all sectors below and also to the area above the GMIRROR config sector used for the GPT header, to write it to all mirrored devices). But this is also ugly, since GPT must know to not assign the GMIRROR config sector to any partition (it is read- only for user requests, but writable on each individual drive in case of GMIRROR configuration or state changes, just as it is now). The reservation was best achieved by use of a specific GPT partition for the configuration data, for which GPT headers must exist, before the GMIRROR is created (or bith must be created at the same time, but that would mix GPT knowledge into GMIRROR). All of the above is ugly, U'm afraid :( Regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 11:06:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27377106566C for ; Thu, 28 Jun 2012 11:06:02 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [84.201.186.22]) by mx1.freebsd.org (Postfix) with ESMTP id C4C078FC14 for ; Thu, 28 Jun 2012 11:06:01 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward4h.mail.yandex.net (Yandex) with ESMTP id D26101B214A1 for ; Thu, 28 Jun 2012 15:05:36 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id A55A7170014D; Thu, 28 Jun 2012 15:05:36 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 5aKuddo3-5aKKLHun; Thu, 28 Jun 2012 15:05:36 +0400 X-Yandex-Rcpt-Suid: bu7cher@yandex.ru 25079121 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org Message-ID: <4FEC3A80.5070304@passap.ru> Date: Thu, 28 Jun 2012 15:05:36 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <4FEC21BA.5070606@passap.ru> <4FEC26E2.7000206@yandex.ru> In-Reply-To: <4FEC26E2.7000206@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 11:06:02 -0000 28.06.2012 13:41, Andrey V. Elsukov пишет: > On 28.06.2012 13:19, Boris Samorodov wrote: >> 27.06.2012 23:27, Andrey V. Elsukov пишет: >> >>> 1. You are against from: >>> Our loader detects that primary GPT header is damaged. It tries to read >>> backup GPT header from the last LBA and it detects that there is >>> "GEOM::" signature. It tries to read one previous sector and there is >>> *valid* GPT header. >> >> Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is >> not found at last sector of the disk >> and this sector is a GPT header then look at the previous sector? > > Then this sector contains GPT table. OK, then place GEOM sector before GPT table. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 11:36:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B37A106566C for ; Thu, 28 Jun 2012 11:36:55 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [IPv6:2a02:6b8:0:801::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADC18FC17 for ; Thu, 28 Jun 2012 11:36:54 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward13.mail.yandex.net (Yandex) with ESMTP id 54D08142461 for ; Thu, 28 Jun 2012 15:36:53 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 3FCA11B60648 for ; Thu, 28 Jun 2012 15:36:53 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ao7GBriP-ao7ebHD4; Thu, 28 Jun 2012 15:36:53 +0400 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org Message-ID: <4FEC41D2.8020605@passap.ru> Date: Thu, 28 Jun 2012 15:36:50 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> In-Reply-To: <4FEC2D86.2040505@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 11:36:55 -0000 28.06.2012 14:10, Stefan Esser пишет: > All of the above is ugly, U'm afraid :( One more try to overcome it. :-) We already have freebsd-boot partition at GPT scheme. Right? Then why not use it (dedicated file/part/etc.) to store geom FreeBSD information? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 10:35:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67DA5106566C; Thu, 28 Jun 2012 10:35:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B27208FC0A; Thu, 28 Jun 2012 10:35:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5SAZdvo002422; Thu, 28 Jun 2012 12:35:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5SAZcEi002419; Thu, 28 Jun 2012 12:35:38 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Jun 2012 12:35:38 +0200 (CEST) From: Wojciech Puchar To: Stefan Esser In-Reply-To: <4FEC22A0.9000109@freebsd.org> Message-ID: References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 28 Jun 2012 12:35:46 +0200 (CEST) X-Mailman-Approved-At: Thu, 28 Jun 2012 11:40:55 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , Marcel Moolenaar , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 10:35:55 -0000 > Just modify GEOM classes that keep state at the end of a partition to > leave some spare area *behind* the GEOM data. I.e.: > what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. even better - update bsdlabel to work with >2TB devices. MUCH better. From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 10:55:39 2012 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 122BC106566B; Thu, 28 Jun 2012 10:55:39 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [IPv6:2a02:6b8:0:602::4]) by mx1.freebsd.org (Postfix) with ESMTP id 679658FC0A; Thu, 28 Jun 2012 10:55:38 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 75F1C1BC14FD; Thu, 28 Jun 2012 14:55:36 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340880936; bh=kNMheJHUaEMTzvKPHev31tS7pLgT9l4B50lgjJkYYnE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CkA5JnuoI3UChLdemJ2QhpBMTB0TZZpNhYCfe9qlcP3b8OTBe8VCKVzIPt6fw3ye0 kX6aZByAvhBV939J6Q96VaviZLLXsH5hvwe/oFwnaXhxaMB9oCbuXuJmqNewHRqDF0 0MA441yjQCq87jEENuzKA9KC2vND7yPpbkjizw4I= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id C7AEDE20363; Thu, 28 Jun 2012 14:55:35 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id tZY43MQ9-tZYqhT8T; Thu, 28 Jun 2012 14:55:35 +0400 X-Yandex-Rcpt-Suid: wojtek@wojtek.tensor.gdynia.pl X-Yandex-Rcpt-Suid: se@freebsd.org X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: xi@borderworlds.dk X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340880935; bh=kNMheJHUaEMTzvKPHev31tS7pLgT9l4B50lgjJkYYnE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=Ex7NQ9z6k+E/bxRb3YkY7Ckx34LytIPQDsUocXq7d+JNUQZj2zE57wnwDgO7Rk2x0 nfEpLUnzSPtu9aECvySHRm7JXa3pCUtPn4W3hS03yiX1lW6L2/7n+8MxDPMYUB/wBF VaJygmE1O/t9KGhbe6+aEmEixiN/WDZDWneUQTs8= Message-ID: <4FEC3826.1090601@yandex.ru> Date: Thu, 28 Jun 2012 14:55:34 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Wojciech Puchar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Jun 2012 11:41:12 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-current , freebsd-hackers , Andriy Gapon , Marcel Moolenaar Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 10:55:39 -0000 On 28.06.2012 14:35, Wojciech Puchar wrote: >> Just modify GEOM classes that keep state at the end of a partition to >> leave some spare area *behind* the GEOM data. I.e.: >> > > what is really a problem aat all? > > just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. > usually not every partition needs to be mirrored. > > or mirror a whole and make gpart in it, it should still boot fine. I already reverted changes related to the GPT and GEOM metadata detection. > even better - update bsdlabel to work with >2TB devices. > MUCH better. DragonFlyBSD has disklabel64 partitioning scheme. Make a port is simple task. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 11:54:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E845106564A for ; Thu, 28 Jun 2012 11:54:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [IPv6:2a02:6b8:0:602::3]) by mx1.freebsd.org (Postfix) with ESMTP id E0ADE8FC18 for ; Thu, 28 Jun 2012 11:54:43 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward3.mail.yandex.net (Yandex) with ESMTP id 3F096B41AC6 for ; Thu, 28 Jun 2012 15:54:42 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340884482; bh=8x4b8lzKRGVvR8utRg+aqkLSMmwrSIrAX2ZN7gqi7mc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iwf2o+WOoPb72JLdRVoIR33aZEy11GK3FdBXZCKuTql8j2Z4fxIWI1fe47DUp97+w LU8eL8BNWeayV+sRqCNDHNFeV0wqoKOWFiHgd2vL4cXpyXOEDJzb5DGoGflz/+X2oJ b/i6C26Nxtj9RsjlbvaW6DzYrB6GvuYqlRfvrAyg= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 1F9A0E2056A; Thu, 28 Jun 2012 15:54:42 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id sfYqwODf-sfYeQHHA; Thu, 28 Jun 2012 15:54:41 +0400 X-Yandex-Rcpt-Suid: bsam@passap.ru 1130000005322498 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340884482; bh=8x4b8lzKRGVvR8utRg+aqkLSMmwrSIrAX2ZN7gqi7mc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=r4D90lQiYBed2BTJAfVIc9xu+p5b4OOYv3hv3ZgMmofhfrLbPkUy1INX//owEpln5 YOtjr10nAR8lowLEMwbl0rf8wEtXgKSrPbhFFirYRdyZc8h9vE8v1Hk7D87iT1rh6A iisSZ+wRCs39z24l9rRag1g1IHbftvrpJuX8zCjE= Message-ID: <4FEC4601.7080601@yandex.ru> Date: Thu, 28 Jun 2012 15:54:41 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Boris Samorodov References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <4FEC41D2.8020605@passap.ru> In-Reply-To: <4FEC41D2.8020605@passap.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 11:54:44 -0000 On 28.06.2012 15:36, Boris Samorodov wrote: > 28.06.2012 14:10, Stefan Esser ÐÉÛÅÔ: > >> All of the above is ugly, U'm afraid :( > > One more try to overcome it. :-) > > We already have freebsd-boot partition at GPT scheme. Right? > Then why not use it (dedicated file/part/etc.) to store > geom FreeBSD information? Recently i have ported LDM support to the FreeBSD. LDM uses 1Mbytes to store its database. All disks that are used by LDM have this database. When the disk is partitioned with MBR, LDM is stored in the last 1Mbyte. When the disk is partitioned with GPT, one partition is dedicated to this database. LDM is not just partitioning scheme, it is also LVM and can do RAID0-5. This is how Microsoft and Veritas have resolved this problem. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 13:25:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2A051065674 for ; Thu, 28 Jun 2012 13:25:08 +0000 (UTC) (envelope-from root@9du.org) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 90ACD8FC1A for ; Thu, 28 Jun 2012 13:25:08 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3335481pbb.13 for ; Thu, 28 Jun 2012 06:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type :x-gm-message-state; bh=znBYJGwHRIXe0+rnVhc32fJOfBUR3gm2JxI8K6QF9vU=; b=J2h1Bfac0c02+kg3HF13vEhIhh/8eKQF/NtY0qX459mKhVVrlIBlWe4S5RAitW5gYJ i/VNd+Goi4ohqiIdTt5LPyykkRBVTZlfOgDu5OrkYfBtQYWpRA7OslZECKM7zV1KmfTK G2+hTgWwBOSVdTtjwbcp8KDT2YZxotJnOzN9Ts7eGEAPaxi/zwfimZejDJ5Oz/5QH+x/ p8lk2Fv0C0ejcsiZ0fQR9WleizApBpTnbABYLpUW3nB88QBZ8Trj0jdwl/f4sdYDwWQy mXUocNMCUM+277Ak5PiTCnhnLrNu4fLJd0apxpzfSMvzx3HgiD2r2gqUj8+1bkFDo3ST EvSg== Received: by 10.68.236.129 with SMTP id uu1mr7884700pbc.77.1340889907715; Thu, 28 Jun 2012 06:25:07 -0700 (PDT) Received: from iso9000-2k3 ([111.194.61.146]) by mx.google.com with ESMTPS id se9sm2130786pbc.25.2012.06.28.06.25.03 (version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:25:06 -0700 (PDT) Date: Thu, 28 Jun 2012 21:24:59 +0800 From: "root@9du.org" To: freebsd-current , rizzo References: <20120628120031.460411065674@hub.freebsd.org> X-Priority: 3 X-GUID: 1454006C-AE5A-4611-B386-D8A57965F1FE X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <2012062821245416134218@9du.org> X-Gm-Message-State: ALoCoQlqaF0vsEng/sm9Hgxs2auexqu7u89UzAgFyYBvGKz4gzVKMTFuLUrn6I4qAF/M1UxmZAYL Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: about netmap NETMAP_HW_RING recv pcaket X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: root List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:25:08 -0000 aW4gcGt0LWdlbi5jIA0KdGlmcmVxLm5yX3JpbmdpZCA9IChnLm50aHJlYWRzID4gMSkgPyAoaSB8 IE5FVE1BUF9IV19SSU5HKSA6IDA7IA0KDQppbiBuZXRtYXAuYyANCmlmIChwcml2LT5ucF9xbGFz dCAhPSBORVRNQVBfSFdfUklORykgew0KbGltX3R4ID0gbGltX3J4ID0gcHJpdi0+bnBfcWxhc3Q7 DQp9DQouLi4uDQoNCmlmIG50aHJlYWRzIDIuYnV0IGhhdmUgOCBudW1fdHhfcmluZ3MuKGl4Z2Jl IGRlZmF1bHQgaXMgOCkNCmxvb2tzIGxpa2UNCnRocmVhZCAjMSBwcml2LT5ucF9xZmlyc3QgPSAw IHByaXYtPm5wX3FsYXN0ID0gMSANCnRocmVhZCAjMiBwcml2LT5ucF9xZmlyc3QgPSAxIHByaXYt Pm5wX3FsYXN0ID0gMg0KIA0KaWYgcGFja2V0IGluICBudW1fdHhfcmluZ3MgMi03IHdpbGwgYmUg bG9zdCBzb21lIHBhY2tldD8g From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 15:33:33 2012 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 D19CE106564A; Thu, 28 Jun 2012 15:33:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2408FC14; Thu, 28 Jun 2012 15:33:33 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SFXMPR036709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 08:33:28 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <4FEC2D86.2040505@freebsd.org> Date: Thu, 28 Jun 2012 08:33:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 15:33:33 -0000 On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > > All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the metadata is in its own partition, one can document the metadata layout and providing a reference implementation. That way one increases the chance that someone, somewhere may port support for it to some other OS. Lacking widespread support for the mirroring scheme, I think that the notion that one can safely and reliably mirror entire disks (read: mirror data not owned or controlled by FreeBSD) is a very questionable one -- all one has to do is boot some other OS and start modifying one of its partitions and you've failed to achieve the objective. My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. Whether or not people agree with this is besides the point. All I'm saying is that unique disk identifiers such as the "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) or the "DiskGUID" (an UUID written to offset 56 in the GPT header) cannot, in general, be mirrored across disks if OSes can see the mirrored disks as independent entities. One violates the spec on grounds of making the *unique* disk identifier non-unique by presenting OSes with multiple disks that have identical IDs. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 15:45:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB9D4106566C; Thu, 28 Jun 2012 15:45:59 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 77C878FC16; Thu, 28 Jun 2012 15:45:59 +0000 (UTC) Received: by obbun3 with SMTP id un3so4191115obb.13 for ; Thu, 28 Jun 2012 08:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=achtdJjX8vTi7VLbdOEblnTyp/aD8eATYlie9Gl2QmQ=; b=hSbfyf9bNMlKO2aMlnAjk2D5Hv09KgGgueeScqe3jcFAF0tbnxsjf55j1gSW/xwSb1 JcXVxaYlaOmpycpB8SwYQMJg1f16LKRZK29+t1TTDW4jGMvxehTn03wAbplQCv2/vP84 l9wLM2uZHWU4RJofVSuJJi5KEFOmEYhuWkXW6YUlItZZFYVSBX2KOvXrc46Jns81KjwO DpZEE2ddu43WgqoBZLr+RP1wSPew1orf8t84sVxOvikJbnI6RPCen84D6/AQaUpy7ipB b5jACCflWz30O+P9FHgbFCETolQI+VUzFRsauHoYVNztpKatFFlA1xcoauGssu93eAdw ZjVw== MIME-Version: 1.0 Received: by 10.182.17.42 with SMTP id l10mr3088342obd.52.1340898358710; Thu, 28 Jun 2012 08:45:58 -0700 (PDT) Received: by 10.60.14.42 with HTTP; Thu, 28 Jun 2012 08:45:58 -0700 (PDT) Date: Thu, 28 Jun 2012 19:45:58 +0400 Message-ID: From: Andrey Fesenko To: freebsd-x11@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Subject: GPU_KMS still not working CURRENT X220 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 15:45:59 -0000 I have lenovo thinkpad x220 # uname -a FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL amd64 # pciconf -lvb vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf0000000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled After # kldload i915kms screen is black, if # kldunload i915kms panic # kldstat Id Refs Address Size Name 1 23 0xffffffff80200000 15d3268 kernel 2 1 0xffffffff81a12000 a9f3 fuse.ko 3 1 0xffffffff81a1d000 690a4 i915kms.ko 4 1 0xffffffff81a87000 1ba2 iicbb.ko 5 4 0xffffffff81a89000 1dd7 iicbus.ko 6 1 0xffffffff81a8b000 1cd5 iic.ko 7 1 0xffffffff81a8d000 32271 drm2.ko # sysctl -a | grep hw.dri | less hw.dri.0.name: i915 0x9c hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.info.i915_capabilities: gen: 6 hw.dri.0.info.i915_gem_objects: 8 objects, 4636672 bytes hw.dri.0.info.i915_gem_gtt: 0xfffffe00084cca00: p 4KiB 0001 0001 0 0 snooped (LLC) (gtt offset: 00000000, size: 00001000) (p mappable) hw.dri.0.info.i915_gem_active: Active: hw.dri.0.info.i915_gem_flushing: Flushing: hw.dri.0.info.i915_gem_inactive: Inactive: hw.dri.0.info.i915_gem_pinned: Pinned: hw.dri.0.info.i915_gem_deferred_free: Deferred free: hw.dri.0.info.i915_gem_pageflip: No flip due on pipe A (plane A) hw.dri.0.info.i915_gem_request: No requests hw.dri.0.info.i915_gem_seqno: Current sequence (render ring): 0 hw.dri.0.info.i915_gem_fence_regs: Reserved fences = 0 hw.dri.0.info.i915_gem_interrupt: North Display Interrupt enable: 8c248080 hw.dri.0.info.i915_gem_hws: 0x00000000: 0x00000000 0x00000000 0x00000000 0x00000000 hw.dri.0.info.i915_gem_hws_blt: 0x00000000: 0x00000000 0x00000000 0x00000000 0x00000000 hw.dri.0.info.i915_gem_hws_bsd: 0x00000000: 0x00000000 0x00000000 0x00000000 0x00000000 hw.dri.0.info.i915_ringbuffer_data: 00000000 : 00000000 hw.dri.0.info.i915_ringbuffer_info: Ring render ring: hw.dri.0.info.i915_bsd_ringbuffer_data: 00000000 : 00000000 hw.dri.0.info.i915_bsd_ringbuffer_info: Ring gen6 bsd ring: hw.dri.0.info.i915_blt_ringbuffer_data: 00000000 : 00000000 hw.dri.0.info.i915_blt_ringbuffer_info: Ring blt ring: hw.dri.0.info.i915_error_state: no error state collected hw.dri.0.info.i915_rstdby_delays: w/ctx: 0, w/o ctx: 0 hw.dri.0.info.i915_cur_delayinfo: GT_PERF_STATUS: 0x00000d83 hw.dri.0.info.i915_delayfreq_table: P00VIDFREQ: 0x00000000 (VID: 0) hw.dri.0.info.i915_inttoext_table: INTTOEXT01: 0x00000000 hw.dri.0.info.i915_drpc_info: RC information accurate: yes hw.dri.0.info.i915_emon_status: Not supported hw.dri.0.info.i915_ring_freq_table: GPU freq (MHz) Effective CPU freq (MHz) hw.dri.0.info.i915_gfxec: GFXEC: 0 hw.dri.0.info.i915_fbc_status: FBC disabled: no outputs hw.dri.0.info.i915_sr_status: self-refresh: disabled hw.dri.0.info.i915_gem_framebuffer: fbcon size: 1366 x 768, depth 24, 32 bpp, obj 0xfffffe000846da00: p 4128KiB 0041 0000 0 0 uncached (gtt offset: 00064000, size: 00408000) (p mappable) hw.dri.0.info.i915_gen6_forcewake_count_info: forcewake count = 0 hw.dri.0.info.i915_swizzle_info: bit6 swizzle for X-tiling = bit9/bit10 hw.dri.0.info.i915_ppgtt_info: GFX_MODE: 0x00000a00 hw.dri.0.info.i915_gem_wired_pages: 1132 hw.dri.0.wedged: 0 hw.dri.0.max_freq: 1300 hw.dri.0.cache_sharing: 0 hw.dri.0.sync_exec: 0 hw.dri.0.fix_mi: 0 hw.dri.0.intr_pf: 0 hw.dri.0.busid: pci:0000:00:02.0 hw.dri.0.modesetting: 1 hw.dri.debug: 2 hw.dri.notyet: 0 hw.dri.vblank_offdelay: 5000 hw.dri.timestamp_precision: 20 # less /var/log/messages Jun 28 17:32:17 bsdx220 kernel: drmn0: on vgapci0 Jun 28 17:32:17 bsdx220 kernel: info: [drm] MSI enabled 1 message(s) Jun 28 17:32:17 bsdx220 kernel: info: [drm] AGP at 0xe0000000 256MB Jun 28 17:32:17 bsdx220 kernel: iicbus0: on iicbb0 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic0: on iicbus0 Jun 28 17:32:17 bsdx220 kernel: iic1: on iicbus1 Jun 28 17:32:17 bsdx220 kernel: iicbus2: on iicbb1 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic2: on iicbus2 Jun 28 17:32:17 bsdx220 kernel: iic3: on iicbus3 Jun 28 17:32:17 bsdx220 kernel: iicbus4: on iicbb2 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic4: on iicbus4 Jun 28 17:32:17 bsdx220 kernel: iic5: on iicbus5 Jun 28 17:32:17 bsdx220 kernel: iicbus6: on iicbb3 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic6: on iicbus6 Jun 28 17:32:17 bsdx220 kernel: iic7: on iicbus7 Jun 28 17:32:17 bsdx220 kernel: iicbus8: on iicbb4 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic8: on iicbus8 Jun 28 17:32:17 bsdx220 kernel: iic9: on iicbus9 Jun 28 17:32:17 bsdx220 kernel: iicbus10: on iicbb5 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic10: on iicbus10 Jun 28 17:32:17 bsdx220 kernel: iic11: on iicbus11 Jun 28 17:32:17 bsdx220 kernel: iicbus12: on iicbb6 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic12: on iicbus12 Jun 28 17:32:17 bsdx220 kernel: iic13: on iicbus13 Jun 28 17:32:17 bsdx220 kernel: iicbus14: on iicbb7 addr 0xff Jun 28 17:32:17 bsdx220 kernel: iic14: on iicbus14 Jun 28 17:32:17 bsdx220 kernel: iic15: on iicbus15 Jun 28 17:32:17 bsdx220 kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Jun 28 17:32:17 bsdx220 kernel: info: [drm] Driver supports precise vblank timestamp query. Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_detect_pch] Found CougarPoint PCH Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:init_vbt_defaults] Set default to SSC at 100MHz Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_parse_bios] Using VBT from OpRegion: $VBT SANDYBRIDGE-M d Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_su pport 1 lvds_use_ssc 0 lvds_ssc_freq 120 display_clock_mode 0 Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:parse_general_definitions] crt_ddc_bus_pin: 2 Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:drm_mode_debug_printmodeline] Modeline 0:"1366x768" 0 75200 1366 1414 1478 1582 768 772 779 792 0x8 0xa Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT tables: Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:drm_mode_debug_printmodeline] Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:parse_sdvo_device_mapping] No SDVO device info is found in VBT Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_modeset_init] 2 display pipes available. Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_crt_init] pch crt adpa set to 0xf40000 Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_setup_outputs] HDMIB 1 PCH_DP_B 1 HDMIC 1 HDMID 1 PCH_DP_C 1 PCH_DP_D 1 LVDS 1 Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_sdvo_read_byte] i2c transfer returned 2 Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_sdvo_init] No SDVO device found on SDVOB Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_dp_i2c_init] i2c_init DPDDC-B Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f Jun 28 17:32:17 bsdx220 kernel: [drm:KMS:pid844:intel_dp_i2c_aux_ch] aux_ch failed -60 From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 16:15:56 2012 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 6534B106566B; Thu, 28 Jun 2012 16:15:56 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C550A8FC0A; Thu, 28 Jun 2012 16:15:55 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2303706wgb.31 for ; Thu, 28 Jun 2012 09:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BIu2JuCAlQpgPJKW2LMdy8OAP+CSG2P9vuqVmzyIhTw=; b=odAc9gjEIDxo06GKT6EH9CYoMBq3Q8AF2Axzg0cYdW3A3cWMux2UbJpEaKSAq2nV18 ImOir1lSsxZ/xPA+4iyn9HpghFtDAu/96j7eLwF8E7C715fJcvOwz0NzlbPZZx/jxy5t JVjxeIcQYVWGU1zSl+HSPCWhz/xBEOroSA41e08s8yFEhpBPOC6Ia8huwzDTCDY0JiBj ibUATRFk19FH+vQ2qZoCZoRp8w8uR2/GZ6u8/05i1cKs+9Cb+v2qbjaKQCG0Gxr4aAPb UrH05KF+7fD1957n4RBLGb4U2X3wppCouG4upWSnFUIk5JowI1uGTXKYa+oMVj+b3v3A UUGg== MIME-Version: 1.0 Received: by 10.180.96.3 with SMTP id do3mr1295134wib.5.1340900154555; Thu, 28 Jun 2012 09:15:54 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Thu, 28 Jun 2012 09:15:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jun 2012 09:15:54 -0700 Message-ID: From: Kevin Oberman To: Andrey Fesenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@freebsd.org, freebsd-current Subject: Re: GPU_KMS still not working CURRENT X220 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 16:15:56 -0000 On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko wrote: > I have lenovo thinkpad x220 > > # uname -a > FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun > 28 08:41:40 MSK 2012 =C2=A0 =C2=A0 root@bsdx220:/usr/obj/usr/src/sys/MY_I= NTEL > amd64 > > # pciconf -lvb > vgapci0@pci0:0:2:0: =C2=A0 =C2=A0 class=3D0x030000 card=3D0x21da17aa chip= =3D0x01268086 > rev=3D0x09 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D '2nd Generation Core Processor Fami= ly Integrated > Graphics Controller' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D display > =C2=A0 =C2=A0subclass =C2=A0 =3D VGA > =C2=A0 =C2=A0bar =C2=A0 [10] =3D type Memory, range 64, base 0xf0000000, = size 4194304, enabled > =C2=A0 =C2=A0bar =C2=A0 [18] =3D type Prefetchable Memory, range 64, base= 0xe0000000, > size 268435456, enabled > =C2=A0 =C2=A0bar =C2=A0 [20] =3D type I/O Port, range 32, base 0x6000, si= ze 64, enabled > > After # kldload i915kms screen is black, if # kldunload i915kms panic Don't do this. It has been clearly stated that i915kms my not be unloaded and that attempting to unload it WILL panic the system. Also, don't load i945kms. This WILL lock up the system with a blank screen. The modules required are autoloaded during Xorg initialization. Just make absolutely sure that you have the latest version of xf-video-intel. (If you installed a rather early version of the KMS code, it is possible that you have two xf-video.intel* ports in your tree, thought I don't expect this is the case. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 17:27:40 2012 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 0CDAB1065672; Thu, 28 Jun 2012 17:27:40 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 70EB08FC08; Thu, 28 Jun 2012 17:27:39 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id CB4E049A; Thu, 28 Jun 2012 19:27:31 +0200 (CEST) Date: Thu, 28 Jun 2012 19:25:27 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120628172526.GA1438@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 17:27:40 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > >=20 > > All of the above is ugly, U'm afraid :( >=20 > Indeed. The only sane way is to put the metadata in a partition of its ow= n. > Every compliant OS will respect that and consequently will not scribble o= ver > the data unintentionally. Any other scheme that puts valuable data in some > undocumented or unregistered location is violating the GPT spec right away > and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/sk4UACgkQForvXbEpPzRESwCgwGF+RxCLlootXW4lu+j8Owmt YEcAnA7XjZwxeS2poA25AtIptQHTPZco =CaJC -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 18:07:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6002D1065674 for ; Thu, 28 Jun 2012 18:07:42 +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 209E98FC0A for ; Thu, 28 Jun 2012 18:07:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D05407300A; Thu, 28 Jun 2012 20:26:50 +0200 (CEST) Date: Thu, 28 Jun 2012 20:26:50 +0200 From: rizzo To: "root@9du.org" Message-ID: <20120628182650.GA24536@onelab2.iet.unipi.it> References: <20120628120031.460411065674@hub.freebsd.org> <2012062821245416134218@9du.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2012062821245416134218@9du.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current Subject: Re: about netmap NETMAP_HW_RING recv pcaket X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 18:07:42 -0000 On Thu, Jun 28, 2012 at 09:24:59PM +0800, root@9du.org wrote: > in pkt-gen.c > tifreq.nr_ringid = (g.nthreads > 1) ? (i | NETMAP_HW_RING) : 0; > > in netmap.c > if (priv->np_qlast != NETMAP_HW_RING) { > lim_tx = lim_rx = priv->np_qlast; > } > .... > > if nthreads 2.but have 8 num_tx_rings.(ixgbe default is 8) > looks like > thread #1 priv->np_qfirst = 0 priv->np_qlast = 1 > thread #2 priv->np_qfirst = 1 priv->np_qlast = 2 > > if packet in num_tx_rings 2-7 will be lost some packet? if you decide to attach to individual rings then it is up to you to bind enough threads as there are rings. pkt-gen.c is only a test program, not all combinations of options are necessary meaningful cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 19:16:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A7EB106566B for ; Thu, 28 Jun 2012 19:16:09 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8318FC12 for ; Thu, 28 Jun 2012 19:16:08 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q5SJG6eR003892 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 28 Jun 2012 20:16:07 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FECAD2C.8070402@unsane.co.uk> Date: Thu, 28 Jun 2012 20:14:52 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-current@freebsd.org" References: <4FE62269.2030706@unsane.co.uk> <4FEB2664.6000300@unsane.co.uk> In-Reply-To: <4FEB2664.6000300@unsane.co.uk> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Occassional "permission denied" in the middle of a large transfer over 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: Thu, 28 Jun 2012 19:16:09 -0000 Just a note to say I have tested this on -CURRENT with the new nfs server and it is still the case. On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar /var/nfsen/profiles-data/ ; date Thu Jun 28 20:12:36 BST 2012 tar: Removing leading '/' from member names tar: Write error Thu Jun 28 20:12:38 BST 2012 [root@seaurchin /mnt/nfs/vm]# on the Server [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 /mnt/tmp/ ; umount /mnt/tmp ; done FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 19:13:26 BST 2012 toor@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 Thu Jun 28 20:12:38 BST 2012 ^C [root@fbsd /var/tmp]# any suggestions welcome. Vince On 27/06/2012 16:27, Vincent Hoffman wrote: > Hi, > After only one off-list reply from the author of kern/136865 (see below) > after asking -questions, I thought it worth asking -CURRENT. > Basically: > > I seem to have run into the problems described in this old thread. > http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html > > tl:dr mountd may give incorrect permission denied errors when it is > refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to > mountd on any mount operation, which implies that any manual mount > request would cause the problem. > > Currently I have still only tested on 8.3-RELEASE but the svn log doesnt > seem to mention a fix since then. I'm currently taking a VM up to > -CURRENT to test. > > Looking though old PRs I see the following related. > kern/131342 > kern/136865 (with patch for 7.2 and links to > http://nfse.sourceforge.net/ for -CURRENT ) > > Does anyone who is qualified (sadly not me) feel like looking at the > code to see if its suitable for inclusion in part/whole as not having > NFS transfers interrupted by local mount operations on the nfs server > would be very handy :) > > > thanks, Vince > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 19:49:31 2012 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 34A15106564A; Thu, 28 Jun 2012 19:49:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B525B8FC17; Thu, 28 Jun 2012 19:49:30 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C40B.dip.t-dialin.net [87.150.196.11]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 97E3C8443FE; Thu, 28 Jun 2012 21:49:09 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id F07C010A1; Thu, 28 Jun 2012 21:49:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1340912947; bh=Ry6lmCgOb82JHvW7IUERwucQLMP+5OvljheL+CMD+xk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fj7QcjBN38Xsu9MSMCP9wdPO5oBC0j9IBNq48PdVJusuzBjoM0vAfBdC//8rNT/Qf WpPtANKsxp1lX9Mn42v5QZApCiLEM47xO4XGMQ/e904h9I4bfg5FEACEmfoh2XZO68 0Xu04NpC6lqkVRcm4YXrypXji7Z0t2d1o6mog1TMoMKPv06rtZ+Os4vKziOmL55C78 wwl6a6FDwzgNZHk8fUjK4u32YpN1K9J0sdEnie5LQndjoVAeBTq+Twc17CgLHzoh9v XABEujhFb5b1KyAfgvqWMRGILHTAKv0DPQKb2GU2w9snXG1Dan6MYp2jhW6J0bC5Ob WvKqURoJ7dGVA== Date: Thu, 28 Jun 2012 21:49:02 +0200 From: Alexander Leidinger To: Marcel Moolenaar Message-ID: <20120628214902.00004e34@unknown> In-Reply-To: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 97E3C8443FE.A49C0 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.921, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.19, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1341517751.24885@iNvizbqaG+q1nHn8i0eSQw X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 28 Jun 2012 20:42:14 +0000 Cc: Doug Rabson , Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Marcel, Stefan Esser , Andriy Gapon , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 19:49:31 -0000 On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar wrote: > My advise is to leave disk mirroring to H/W or firmware solutions and > use FreeBSD mirroring for FreeBSD partitions only. If you want to > mirror the whole disk, don't partition the disk with non-FreeBSD > partitioning schemes and partition only with FreeBSD-specific schemes > or put a FreeBSD file system on the whole disk. In other words: make > the whole disk private to FreeBSD. If I gmirror the entire disk, I already expressed my interest to make the whole disk private to FreeBSD, haven't I? Or are you suggesting to convince all BIOS vendors to include the ability to boot from some kind of FreeBSD private partitioning scheme (not MBR as it is not suitable, not GPT as you are not OK to use it on a gmirror)? > Whether or not people agree with this is besides the point. All I'm > saying is that unique disk identifiers such as the > "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) > or the "DiskGUID" (an UUID written to offset 56 in the GPT header) > cannot, in general, be mirrored across disks if OSes can see the > mirrored disks as independent entities. One violates the spec on > grounds of making the *unique* disk identifier non-unique by > presenting OSes with multiple disks that have identical IDs. What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 20:49:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FF9D106566B for ; Thu, 28 Jun 2012 20:49:46 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 536A08FC16 for ; Thu, 28 Jun 2012 20:49:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=olrwkaN/h4w8VATipNCuHzH5hMu2BtOpDgQX3CZhNnE=; b=I30SNHViArBfjRYjqQ73fDlLZqBwToY1zXOqSri8aX9RuLeg0i6+JY9yeb+NkB+W9jJviBXsXI4HVxZLL2pXqYa1M5s7puSLQ7fO5mo7+3AhqwRQ5tu79UJJuvk8oHzd; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkLer-000LLl-Ct for freebsd-current@freebsd.org; Thu, 28 Jun 2012 15:49:46 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340916579-94480-94479/5/74; Thu, 28 Jun 2012 20:49:39 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> Date: Thu, 28 Jun 2012 15:49:39 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120628214902.00004e34@unknown> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 20:49:46 -0000 On Thu, 28 Jun 2012 14:49:02 -0500, Alexander Leidinger wrote: > What about multipathing? In case the disk is attached via two paths but > multipath is not enabled, the OS sees the same disk (and the same > identical unique disk identifier) multiple times. Is this a violation > of the spec too? Good point; does gmirror and gmultipath play together nicely? From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 21:41:22 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84682106566C; Thu, 28 Jun 2012 21:41:22 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 381D58FC0C; Thu, 28 Jun 2012 21:41:22 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SLf3oI037908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:41:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628172526.GA1438@garage.freebsd.pl> Date: Thu, 28 Jun 2012 14:40:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <279E75A8-0D3C-4492-B470-BCF4A8973748@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628172526.GA1438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 21:41:22 -0000 On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >>=20 >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>>=20 >>> All of the above is ugly, U'm afraid :( >>=20 >> Indeed. The only sane way is to put the metadata in a partition of = its own. >> Every compliant OS will respect that and consequently will not = scribble over >> the data unintentionally. Any other scheme that puts valuable data in = some >> undocumented or unregistered location is violating the GPT spec right = away >> and is susceptible to being clobbered unintentionally. >=20 > If the user runs: >=20 > # gpart create -s GPT /dev/mirror/foo >=20 > for me it is obvious that he wants to partition the mirror device and > not individual disks. It could definitely be interpreted as the user knowing what he/she wants and as such design an infrastructure around this assumption. If users were at least as knowledgable as developers, my concerns wouldn't be as big. But we all know how knoweldgable users can be and kike it or not, even developers aren't gurus in everything. We may think to know stuff, but in practice we're just as clueless in cases as users -- more clueless even sometimes. So you may think the intend is obvious, but you should know better. > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. Yes. I think we finally reached the point we should have reached years ago. With the proper tooling, our flexible infrastructure can be used in a safe and complaint way while still giving the freedom to those who unwisely think they know better. Build it and I'll concur. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 22:04:27 2012 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 172801065672; Thu, 28 Jun 2012 22:04:27 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 65B248FC15; Thu, 28 Jun 2012 22:04:26 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 184412842A; Fri, 29 Jun 2012 00:04:19 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CBA2B28427; Fri, 29 Jun 2012 00:04:17 +0200 (CEST) Message-ID: <4FECD4E1.1070505@quip.cz> Date: Fri, 29 Jun 2012 00:04:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628172526.GA1438@garage.freebsd.pl> In-Reply-To: <20120628172526.GA1438@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 22:04:27 -0000 Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >> >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>> >>> All of the above is ugly, U'm afraid :( >> >> Indeed. The only sane way is to put the metadata in a partition of its own. >> Every compliant OS will respect that and consequently will not scribble over >> the data unintentionally. Any other scheme that puts valuable data in some >> undocumented or unregistered location is violating the GPT spec right away >> and is susceptible to being clobbered unintentionally. > > If the user runs: > > # gpart create -s GPT /dev/mirror/foo > > for me it is obvious that he wants to partition the mirror device and > not individual disks. Because the mirror was configured earlier, do you > expect gmirror to somehow detect that someone is writting GPT metadata > later and magically place GPT metadata on the raw disk and move mirror's > metadata to some magic partition? Not to mention that the mirror itself > doesn't have to be configured on top of raw disks. And not to mention > that the mirror may never be partitioned. > > If GPT in your opinion is limited only to raw disks then I guess the > best way to fix that is to refuse to configure GPT on anything except > raw disks (which was already proposed by Andrey?). In my opinion this is > unacceptable, but I think this is what you are suggesting. > > One of the GEOM design goals was to be flexible. Let the user decide in > what order he wants to configure various layers. How do you know that in > every possible scenerio software mirroring should come after > partitioning and encryption after mirroring? Why can't we provide > flexible tools to the user and let him decide? Maybe GPT nesting > violates standards, but why can't we support it as an extention, really? > > I recognize the need to warn users if they use FreeBSD-specific > features. We do that with non-standard APIs. So how about this. > > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. > > In my opinion that's fair. > > With such a warning in place, I think we can allow users to decide on > their own if they really want that or not. Then, we can also improve > FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 21:55:04 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 385E91065675; Thu, 28 Jun 2012 21:55:04 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D48328FC19; Thu, 28 Jun 2012 21:55:03 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SLsnfc037954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:54:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628214902.00004e34@unknown> Date: Thu, 28 Jun 2012 14:54:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 28 Jun 2012 22:50:28 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 21:55:04 -0000 On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar > wrote: > >> My advise is to leave disk mirroring to H/W or firmware solutions and >> use FreeBSD mirroring for FreeBSD partitions only. If you want to >> mirror the whole disk, don't partition the disk with non-FreeBSD >> partitioning schemes and partition only with FreeBSD-specific schemes >> or put a FreeBSD file system on the whole disk. In other words: make >> the whole disk private to FreeBSD. > > If I gmirror the entire disk, I already expressed my interest to make > the whole disk private to FreeBSD, haven't I? No. All you've done is type some commands. There's no inherent value in it that relays that you know what you're doing. I have no problem accepting that you do in fact know what you're doing, but that doesn't mean that anyone who types the same sequence of commands is as skilled as you are -- that would be a silly inference. What you need to do is not have it be about you, but about some random user. > Or are you suggesting to > convince all BIOS vendors to include the ability to boot from some kind > of FreeBSD private partitioning scheme (not MBR as it is not > suitable, not GPT as you are not OK to use it on a gmirror)? I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. Thus, it's not that I object to the mirroring per se, just to the mirroring as it is currently implemented with gmirror. > What about multipathing? In case the disk is attached via two paths but > multipath is not enabled, the OS sees the same disk (and the same > identical unique disk identifier) multiple times. Is this a violation > of the spec too? It's the same disk, isn't it? The OS can actually use the property of the ID to infer that it has already seen this disk and not create multiple device nodes. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 23:09:33 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9836106564A; Thu, 28 Jun 2012 23:09:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF2E8FC0C; Thu, 28 Jun 2012 23:09:33 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 616735BF; Fri, 29 Jun 2012 01:09:31 +0200 (CEST) Date: Fri, 29 Jun 2012 01:07:26 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120628230725.GB1438@garage.freebsd.pl> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 29 Jun 2012 01:43:47 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , Alexander Leidinger , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jun 2012 23:09:33 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote: > On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > > Or are you suggesting to > > convince all BIOS vendors to include the ability to boot from some kind > > of FreeBSD private partitioning scheme (not MBR as it is not > > suitable, not GPT as you are not OK to use it on a gmirror)? >=20 > I would be having less problems if the mirroring didn't force the backup > GPT header in anything but the last sector. [...] GPT backup header is placed in the last sector of the mirror device, just like the user asked. Gmirror doesn't force anything. User decides to put GPT partitioning on the mirror device instead of raw disk. Gmirror doesn't even know and doesn't have to know how the user uses data area on the mirror device. > [...] If the metadata was somewhere > else, then we wouldn't need to kluge various places to deal with the > ambiguity and visible interoperability problems of the various tools and > OSes. [...] Where is "somewhere else", exactly? If somewhere else on this disk, then where? At the begining of the disk? Then you would complain that it keeps metadata where the primary header should be located and also MBR metadata, BSDlabel metadata, etc. Somewhere in the middle of the disk? Some future GPTng may want to use the same spot, but also gmirror-unaware boot loader will see corrupted data (shifted by one sector). Come on... If somewhere else is not on this disk, then I'm sorry, but this is totally impractical. Disks are the place you store stuff. In 99% of the cases there is no other place to store it, but the disk itself. Should we ask users to use additional disk to keep mirror's metadata? > [...] Thus, it's not that I object to the mirroring per se, just to the > mirroring as it is currently implemented with gmirror. Do you know software RAID (>=3D1) or volume manager that doesn't keep metadata on component disks? PS. We are discussing two totally different things here: 1. Is placing GPT on anything but raw disk violates the spec? I can agree that it does and I'm happy with gpart(8) growing a warning. 2. How to do software mirroring. Besides trying really hard I'm not sure what alternative are you proposing. Could you be more specific and describe how gmirror should be implemented in your opinion? > > What about multipathing? In case the disk is attached via two paths but > > multipath is not enabled, the OS sees the same disk (and the same > > identical unique disk identifier) multiple times. Is this a violation > > of the spec too? >=20 > It's the same disk, isn't it? The OS can actually use the property > of the ID to infer that it has already seen this disk and not create > multiple device nodes. You cannot trust some id that is found on disk to be unique, as all your assumptions break when the user decides to dd(1)-copy content of this disk to another disk, for example. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/s460ACgkQForvXbEpPzRTGwCfTL2ATAwe2abfVXK56cmuJocw R10An0aub6mww15UVaL2CrI3ao8Ohu9k =7Mep -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 03:10:55 2012 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 13186106564A; Fri, 29 Jun 2012 03:10:55 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id C17A88FC0C; Fri, 29 Jun 2012 03:10:54 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id q5T3Aq72091796 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 28 Jun 2012 23:10:53 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4FED1CBC.50308@FreeBSD.org> Date: Thu, 28 Jun 2012 23:10:52 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthias Apitz References: <20120615094837.GA1440@tiny.Sisis.de> <201206150818.22208.jhb@freebsd.org> <20120616085106.GA3213@tinyCurrent> <201206160811.40632.jhb@freebsd.org> <20120627051941.GA2468@tinyCurrent> In-Reply-To: <20120627051941.GA2468@tinyCurrent> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Thu, 28 Jun 2012 23:10:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: panic's in 10-CURRENT r235646 in VMware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 03:10:55 -0000 Hi Matthais, On 06/27/12 01:19, Matthias Apitz wrote: > El día Saturday, June 16, 2012 a las 08:11:40AM -0400, John Baldwin escribió: > >> On Saturday, June 16, 2012 04:51:06 AM Matthias Apitz wrote: >>> El día Friday, June 15, 2012 a las 08:18:22AM -0400, John Baldwin escribió: >>>>> the panic says: >>>>> mutex page lock not owned at /usr/src/sys/vm/vm_page.c:2060 >>>>> >>>>> I have a screen shoot here: >>>>> http://www.unixarea.de/aurora-panic.gif >>>>> >>>>> Installed and started (via rc.conf) is the port open-vm-tools-425873,1; >>>>> >>>>> Thx >>>>> >>>>> matthias >>>> >>>> Can you get a stack trace? > > The attached patch file (to be replaced in open-vm-tools/files/patch-vmmemctl-os.c) > solved the problem for me; thanks, John > > matthias > Thanks! I've updated the port with this and the other patches you sent and it seems to build and work properly on 10-CURRENT. Steve From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 00:42:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50083106566B; Fri, 29 Jun 2012 00:42:44 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6148FC0A; Fri, 29 Jun 2012 00:42:44 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5T0gXcs038953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 17:42:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> Date: Thu, 28 Jun 2012 17:42:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: <03CF2422-2A8F-4055-B5CF-F6F110D146F4@xcllnt.net> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 29 Jun 2012 03:23:50 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , Alexander Leidinger , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 00:42:44 -0000 On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote: >> >> I would be having less problems if the mirroring didn't force the backup >> GPT header in anything but the last sector. [...] > > GPT backup header is placed in the last sector of the mirror device, > just like the user asked. Gmirror doesn't force anything. User decides > to put GPT partitioning on the mirror device instead of raw disk. > Gmirror doesn't even know and doesn't have to know how the user uses > data area on the mirror device. This really is a cop-out paragraph. >> [...] If the metadata was somewhere >> else, then we wouldn't need to kluge various places to deal with the >> ambiguity and visible interoperability problems of the various tools and >> OSes. [...] > > Where is "somewhere else", exactly? I already suggested a few things in this thread. Go read it. I'm bored now, so I'll just wait for UEFI booting to be forced upon those who mirror the whole disk with gmirror. I think that's when we will have a more substantial and meaningful continuation of this thread. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 03:06:00 2012 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 C9658106566B; Fri, 29 Jun 2012 03:05:59 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 0149C8FC12; Fri, 29 Jun 2012 03:05:58 +0000 (UTC) Received: from alph.allbsd.org (p4242-ipbf1504funabasi.chiba.ocn.ne.jp [118.7.211.242]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35WTi080211; Fri, 29 Jun 2012 12:05:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35SaH061314; Fri, 29 Jun 2012 12:05:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 29 Jun 2012 11:47:34 +0900 (JST) Message-Id: <20120629.114734.957117006298853448.hrs@allbsd.org> To: pjd@FreeBSD.org From: Hiroki Sato In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> References: <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_29_11_47_34_2012_987)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 29 Jun 2012 12:05:44 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-Mailman-Approved-At: Fri, 29 Jun 2012 03:36:02 +0000 Cc: dfr@FreeBSD.org, marcel@FreeBSD.org, xi@borderworlds.dk, freebsd-hackers@FreeBSD.org, avg@FreeBSD.org, marcel@xcllnt.net, se@FreeBSD.org, bu7cher@yandex.ru, Alexander@Leidinger.net, freebsd-current@FreeBSD.org Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 03:06:00 -0000 ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Jakub Dawidek wrote in <20120628230725.GB1438@garage.freebsd.pl>: pj> PS. We are discussing two totally different things here: pj> 1. Is placing GPT on anything but raw disk violates the spec? I can pj> agree that it does and I'm happy with gpart(8) growing a warning. I agree that there is a sort of violation, but in practice most of implementations which use GPT can recognize the backup header as long as the primary one is not corrupted by using the alternative LBA field. One thing we have to consider is what happens when the primary header becomes broken. In that case and if a GEOM metadata is placed at the end of the raw disk, GPT will be lost and it cannot recover by non-GEOM-aware software including BIOS and other OS. Also, even for FreeBSD it causes a boot failure. The modification which ae@ proposes mitigates this case. Of course, maybe BIOS or EFI will not recognize the corrupted header because the backup header is not located at the end. In that case all of the partitions are not recognized and the FreeBSD does not boot. This is the trade-off when we use GPT in a logical volume provided by GEOM. In short, the risk is that backup header does not work as a backup when the primary is broken. I agree that putting a warning about that is good and enough. Whether this risk is acceptable or not depends on the sysadmin. Also, we can describe the pros and cons in detail in a section of the handbook because I and wblock@ are working on updating it. pj> 2. How to do software mirroring. Besides trying really hard I'm not sure pj> what alternative are you proposing. Could you be more specific and pj> describe how gmirror should be implemented in your opinion? I do not think this topic is related to ae@'s change and this should be discussed in a separate thread. His change aims to support a non-standard GPT header location in a quite limited situation, not actively promote such a configuration. The issue of GPT+GEOM is not limited to gmirror. Just putting GEOM::LABEL metadata causes the same issue. -- Hiroki ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/tF0YACgkQTyzT2CeTzy1kOgCfVfIyJA3wP4V+tAeNSOb/fD9D jx4An3Buxn6SA3rVPDkMuYTZNgVU7QZj =R0+R -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)---- From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 08:31:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FFDE10656E4 for ; Fri, 29 Jun 2012 08:31:56 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7D97B8FC0C for ; Fri, 29 Jun 2012 08:31:55 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q5T8VsZc028905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jun 2012 10:31:54 +0200 Received: from portgus.lan (labtel2.upc.edu [147.83.40.20]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q5T8VrFa012133 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2012 10:31:53 +0200 Message-ID: <4FED67FF.9030502@entel.upc.edu> Date: Fri, 29 Jun 2012 10:31:59 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-current@freebsd.org >> FreeBSD current" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 29 Jun 2012 10:31:54 +0200 (CEST) Subject: Unable to resume amd64 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 08:31:56 -0000 Hi, I've trying to suspend/resume an amd64 machine. The machine is a fujitsu S710 laptop running: FreeBSD 10.0-CURRENT #4 r237339=e61ad3a-dirty: Sat Jun 23 17:12:58 CEST 2012 I did the tests in the following conditions: - No X running. Everything in console. The machine has an Intel video card, but I did the tests without the i915kms module. - I removed all the modules I could from the kernel. The behavior is basically the machine seems to suspend fine (I see the power led blinking) but when resuming it freezes hard. I see the disk spinning for a while and then it stops. I can't ssh to it, I can't use the keyboard at all so I can issue no command at all. I've tried stripping down the kernel (everything is out except if_ath, em and usb stack). No pccard, no sdhci, no sound, no cuse4bsd, no usb hid devices (I'm using uhidd for hid devices), no acpi_video or acpi_fujitsu there but the same result. I tried enabling debug.acpi.resume_beep=1. When doing this, the laptop beeped like crazy. I tried using the serial console on the laptop. I saw the suspend process taking down some usb devices. Resume showed nothing on the serial console. With sysctl debug.acpi.suspend_bounce=1, the machine stayed alive (this is expected) but the screen went blank (this I think isn't expected). The video never came back. The three-finger-salute rebooted the machine. With acpi.reset_video I got no result. Disabling devices in the BIOS (removing wifi, bluetooth, webcam, etc ...) didn't bring me further. -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 08:49:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16FFA106566C; Fri, 29 Jun 2012 08:49:05 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B083A8FC0A; Fri, 29 Jun 2012 08:49:04 +0000 (UTC) Received: by ghbz22 with SMTP id z22so2990122ghb.13 for ; Fri, 29 Jun 2012 01:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jb3NUBW3eY1vqcJkKUJZZcH6qekyhkjNKsrTTamieRw=; b=vZpvqZwOpIeu5y3NWBi3dQ8vcB+JEDuNvL0OBVXufxHxgBQvjTCBqrM4/9UYF//pF6 7LfTempQYzlcWH4fs4iYwZbccyG0XNJfXtVoH+2Sd4A06sD4ghBpnZuCTXxrksvw1Rjz H1OGemuBP/GpYNtlBLzERksPWKCeTav6SrB5JCdxyf6GDZr1q2GnztF6tNU16aXaAVpk T5BJUwM5AVoPlGcRjFEtEJNw99dQPJ+yH6aEQxo9P5faMpers2MwgN5pQPtPP9L/XkGE bjXMMMJ+RYTqUYIyV542tYiHGal7IfIRFO641CpV76c/s6btw1ru1WAsTrMVAlrDTVD+ IdpA== MIME-Version: 1.0 Received: by 10.60.3.194 with SMTP id e2mr773616oee.1.1340959743910; Fri, 29 Jun 2012 01:49:03 -0700 (PDT) Received: by 10.60.14.42 with HTTP; Fri, 29 Jun 2012 01:49:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jun 2012 12:49:03 +0400 Message-ID: From: Andrey Fesenko To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@freebsd.org, freebsd-current Subject: Re: GPU_KMS still not working CURRENT X220 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 08:49:05 -0000 On Thu, Jun 28, 2012 at 8:15 PM, Kevin Oberman wrote: > On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko wrot= e: >> I have lenovo thinkpad x220 >> >> # uname -a >> FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun >> 28 08:41:40 MSK 2012 =C2=A0 =C2=A0 root@bsdx220:/usr/obj/usr/src/sys/MY_= INTEL >> amd64 >> >> # pciconf -lvb >> vgapci0@pci0:0:2:0: =C2=A0 =C2=A0 class=3D0x030000 card=3D0x21da17aa chi= p=3D0x01268086 >> rev=3D0x09 hdr=3D0x00 >> =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' >> =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D '2nd Generation Core Processor Fam= ily Integrated >> Graphics Controller' >> =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D display >> =C2=A0 =C2=A0subclass =C2=A0 =3D VGA >> =C2=A0 =C2=A0bar =C2=A0 [10] =3D type Memory, range 64, base 0xf0000000,= size 4194304, enabled >> =C2=A0 =C2=A0bar =C2=A0 [18] =3D type Prefetchable Memory, range 64, bas= e 0xe0000000, >> size 268435456, enabled >> =C2=A0 =C2=A0bar =C2=A0 [20] =3D type I/O Port, range 32, base 0x6000, s= ize 64, enabled >> >> After # kldload i915kms screen is black, if # kldunload i915kms panic > > Don't do this. It has been clearly stated that i915kms my not be > unloaded and that attempting to unload it WILL panic the system. > > Also, don't load i945kms. This WILL lock up the system with a blank scree= n. > > The modules required are autoloaded during Xorg initialization. Just > make absolutely sure that you have the latest version of > xf-video-intel. (If you installed a rather early version of the KMS > code, it is possible that you have two xf-video.intel* ports in your > tree, thought I don't expect this is the case. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com Thank you so much, it worked :) necessary as it is written in the wiki From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 10:58:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE9EA1065672; Fri, 29 Jun 2012 10:58:33 +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 840268FC0C; Fri, 29 Jun 2012 10:58:33 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SkYuG-00039a-5H; Fri, 29 Jun 2012 11:58:32 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SkYuF-0001sP-N6; Fri, 29 Jun 2012 11:58:31 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q5TAwVPS018546; Fri, 29 Jun 2012 11:58:31 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q5TAwVSI018545; Fri, 29 Jun 2012 11:58:31 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Fri, 29 Jun 2012 11:58:31 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20120629105831.GA18531@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ia64 r235474 panic preceded by LOR : exclusive sleep mutex vnode interlock (vnode interlock)panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 10:58:34 -0000 # dump -0aLuf - / | restore -rf - produces this panic: lock order reversal: 1st 0xa00000009ca034f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2652 2nd 0xe00000001163ebb0 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2297 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0000000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0000000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0000000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0000000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0000000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock)panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562 cpuid = 1 KDB: enter: panic [ thread pid 956 tid 100089 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe25000,gp ;; db> db> show thread Thread 100089 at 0xe000000011f25140: proc (pid 956): 0xe000000011d8b6a8 name: dump stack: 0xa0000000f87a4000-0xa0000000f87abfff flags: 0x10004 pflags: 0 state: RUNNING (CPU 1) priority: 120 container lock: sched lock 1 (0x9ffc000000d8b8c0) db> db> thread 100089 [ thread pid 956 tid 100089 ] kdb_enter+0x92: [I2] addl r14=0xffffffffffe25000,gp ;; db> bt Tracing pid 956 tid 100089 td 0xe000000011f25140 kdb_enter(0x9ffc000000c52c38, 0x9ffc000000c52c38, 0x9ffc0000004eb6b0, 0x793) at kdb_enter+0x92 panic(0x9ffc000000c5b748, 0x9ffc000000c50f60, 0x9ffc000000c50f40, 0x9ffc000000c93830, 0x232, 0x9ffc000000c93830) at panic+0x420 witness_checkorder(0xe000000011d8b7a0, 0x9, 0x9ffc000000c93830, 0x232, 0x0) at witness_checkorder+0x1b0 _mtx_lock_flags(0xe000000011d8b7a0, 0x0, 0x9ffc000000c93830, 0x232, 0x9ffc00000097dcc0, 0x716, 0x0) at _mtx_lock_flags+0x160 trap(0x14, 0xa0000000f87a5800) at trap+0x940 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa0000000f87a5800 ia64_handle_intr(0xa0000000f87a5c00) at ia64_handle_intr+0x171 ivt_External_Interrupt() at ivt_External_Interrupt+0x30 --- trapframe at 0xa0000000f87a5c00 __gp(...) at __gp db> -- 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 Fri Jun 29 11:00:30 2012 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 B336F1065672; Fri, 29 Jun 2012 11:00:30 +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 6A3408FC19; Fri, 29 Jun 2012 11:00:30 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SkYcY-0004bv-Kx; Fri, 29 Jun 2012 11:40:14 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SkYcX-00013N-Sg; Fri, 29 Jun 2012 11:40:14 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q5TAeDQj018425; Fri, 29 Jun 2012 11:40:13 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q5TAeDrV018424; Fri, 29 Jun 2012 11:40:13 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Fri, 29 Jun 2012 11:40:13 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20120629104013.GA18398@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 11:00:30 -0000 # newfs /dev/da2p2 /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size 4096 using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. super-block backups (for fsck -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432 # mount /dev/da2p2 /mnt # cd /mnt # dump 0aLuf - / | restore -rf - results in this panic: KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepablefatal kernel trap (cpu 0): locks held: exclusive sleep mutex vnode interlock trap vector = 0x18 (General Exception) (vnode interlock) cr.iip = 0x9ffc000000967e90 r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 cr.ipsr = 0x1210080a2018 (KDB: stack backtrace: ac,getenvmfl with the following, non-sleepableic, locks held: dtexclusive sleep mutex vnode interlock, (vnode interlock)dfh r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 ,rtKDB: stack backtrace: ,cpl=0getenv, with the followingit non-sleepable,ri=1 locks held: ,exclusive sleep mutex vnode interlockbn (vnode interlock)) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 cr.isr = 0x20000000030 (KDB: stack backtrace: code=48,vector=0getenv, with the followingei=1 non-sleepable) locks held: cr.ifa = 0xe00000001113cd60 exclusive sleep mutex vnode interlock curthread = 0xe000000011d6c000 (vnode interlock) pid = 640, comm = ipmon r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: [ thread pid 640 tid 100076 ] Stopped at cpu_switch+0x201: [I1] mov.i ar.pfs=r36 db> db> bt Tracing pid 640 tid 100076 td 0xe000000011d6c000 cpu_switch(0x0) at cpu_switch+0x201 uart_quicc_class(0xe000000011d6c000, 0x0, 0x0, 0x9ffc000000979a40, 0x8, 0x9ffc000000f2b3b0, 0xe000000011d6c000, 0xa0000000f87434e8) at 0x204 db> The panic is reproducible, I now saw it 3 times in a row. -- 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 Fri Jun 29 13:34:28 2012 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 947321065670 for ; Fri, 29 Jun 2012 13:34:28 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC588FC0C for ; Fri, 29 Jun 2012 13:34:28 +0000 (UTC) Received: from [89.204.139.52] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SkbL8-0007oV-NN for freebsd-current@freebsd.org; Fri, 29 Jun 2012 15:34:27 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q5TDYOZ8002275 for ; Fri, 29 Jun 2012 15:34:24 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q5TDYNNc002274 for freebsd-current@freebsd.org; Fri, 29 Jun 2012 15:34:23 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 29 Jun 2012 15:34:23 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20120629133422.GA2233@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.139.52 Subject: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:34:28 -0000 Hello, I have a boot-able USB key with r235646 which works fine in all my laptops so far; today I got as a gift an older FS Amilo D 7830 which has enough resources to use it as new build machine (1 GByte RAM, 80 GByte disk). I booted it with from the USB key and after the system is up it does not echo or react on any key-press; before booting the keys are working, for example in the menu to boot into single user etc. What could be the problem? I will later configure that the USB booted system brings Ethernet and SSH up, maybe I can see something when I can login via SSH... matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 13:19:58 2012 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 AFAC3106564A; Fri, 29 Jun 2012 13:19:58 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from server2.allsitecontrol.com (server2.allsitecontrol.com [63.143.36.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7309B8FC0A; Fri, 29 Jun 2012 13:19:58 +0000 (UTC) Received: from tor20.anonymizer.ccc.de ([31.172.30.3]:39068 helo=internal.tormail.org) by server2.allsitecontrol.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1SkYzK-002t8J-98; Fri, 29 Jun 2012 07:03:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=2iNMBWz1J7koQQFjd6/wR/UQybpI6su7zV7+ORHa9XQ=; b=dGAteT/fmOFtvBAeStL2N7zXTbX0nmBDsKbDmd+jVnO+sx+eH1C9z8QnRD8d2vYu38pjZSWHlb8GapEUk/wWecM1DDcEh1SUmWRRG1SIaOwMGG9ul2oTOjVDaD3R2D+0HtUeec4iX4d4OeusasB1xyQ5+7+BqAFXkB1kUfir4jg=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1SkYxx-0007Fr-SA; Fri, 29 Jun 2012 11:02:22 +0000 From: Jan Beich To: Dimitry Andric In-Reply-To: <4FEB5B0E.8020009@FreeBSD.org> (Dimitry Andric's message of "Wed, 27 Jun 2012 21:12:14 +0200") Date: Fri, 29 Jun 2012 06:01:48 -0500 References: <4FE9B01C.30306@yandex.ru> <4FEB5B0E.8020009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1SkYxx-0007Fr-SA@internal.tormail.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.allsitecontrol.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.org X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Fri, 29 Jun 2012 13:35:25 +0000 Cc: freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 13:19:58 -0000 Dimitry Andric writes: > On 2012-06-26 14:50, Andrey V. Elsukov wrote: > >> Some time ago i have started reading the code in the sys/boot. >> Especially i'm interested in the partition tables handling. >> I found several problems: >> 1. There are several copies of the same code in the libi386/biosdisk.c >> and common/disk.c, and partially libpc98/biosdisk.c. >> 2. ZFS probing is very slow, because the ZFS code doesn't know how many >> disks and partitions the system has: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 >> 3. The GPT support doesn't check CRC and even doesn't know anything >> about the secondary GPT header/table. >> >> So, i have created the branch and committed the changes: >> http://svnweb.freebsd.org/base/user/ae/bootcode/ >> The patch is here: >> http://people.freebsd.org/~ae/boot.diff > > FWIW, I verified it compiles OK with clang, and especially boot2's size > isn't increased at all. Does it boot for you? Same if I build zfs.c with gcc -O0: FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (foo@bar, Tue Jun 26 18:52:52 UTC 2012) ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' > > It would be nice if you could check it with clang now and again, before > you finally merge this project into head. From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 14:46:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9A01106564A for ; Fri, 29 Jun 2012 14:46:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 66F278FC0C for ; Fri, 29 Jun 2012 14:46:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 117804657; Fri, 29 Jun 2012 16:46:07 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Matthias Apitz Date: Fri, 29 Jun 2012 16:45:57 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> In-Reply-To: <20120629133422.GA2233@tiny.Sisis.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206291645.57359.hselasky@c2i.net> Cc: Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 14:46:16 -0000 On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: > Hello, > > I have a boot-able USB key with r235646 which works fine in all my > laptops so far; today I got as a gift an older FS Amilo D 7830 which has > enough resources to use it as new build machine (1 GByte RAM, 80 GByte > disk). I booted it with from the USB key and after the system is up it > does not echo or react on any key-press; before booting the keys are > working, for example in the menu to boot into single user etc. > > What could be the problem? > > I will later configure that the USB booted system brings Ethernet and > SSH up, maybe I can see something when I can login via SSH... > > matthias What does dmesg say about USB? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 16:10:46 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3B45106564A; Fri, 29 Jun 2012 16:10:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 895978FC1A; Fri, 29 Jun 2012 16:10:46 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SkdmJ-0007jO-Rx>; Fri, 29 Jun 2012 18:10:39 +0200 Received: from e178027104.adsl.alicedsl.de ([85.178.27.104] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SkdmJ-0007D5-MX>; Fri, 29 Jun 2012 18:10:39 +0200 Message-ID: <4FEDD378.10206@zedat.fu-berlin.de> Date: Fri, 29 Jun 2012 18:10:32 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Current FreeBSD , Ports FreeBSD X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C5BA2E966DBFF11F7416A3D" X-Originating-IP: 85.178.27.104 Cc: Subject: print/foomatic-db-engine : install: *.1: No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 16:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C5BA2E966DBFF11F7416A3D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm stuck with this nasty error in print/foomatic-db-engine, which prevents me from updating ports relying on this specific port. This problem is sticky on all FreeBSD 10-CURRENT boxes. /usr/local/bin/perl -p -i -e "s:foomatic-templates:/usr/local/share/foomatic//templates:g" //usr/local/sbin/foomatic-addpjloptions ln -sf foomatic-ppdfile //usr/local/bin/foomatic-datafile if [ -d /usr/local/libexec/cups ]; then \ ./mkinstalldirs //usr/local/libexec/cups/driver; \ ln -sf /usr/local/bin/foomatic-ppdfile //usr/local/libexec/cups/driver/foomatic; \ fi =2E/mkinstalldirs //usr/local/man =2E/mkinstalldirs //usr/local/man/man1 =2E/mkinstalldirs //usr/local/man/man8 /usr/bin/install -c -o root -g wheel -m 644 *.1 //usr/local/man/man1 install: *.1: No such file or directory gmake: *** [install-man] Error 71 *** [do-install] Error code 2 Stop in /usr/ports/print/foomatic-db-engine. =3D=3D=3D>>> Installation of foomatic-db-engine-4.0.7,2 (print/foomatic-db-engine) failed =3D=3D=3D>>> Aborting update Terminated =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster print/foomatic-db-engine --------------enig7C5BA2E966DBFF11F7416A3D 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.19 (FreeBSD) iQEcBAEBAgAGBQJP7dN+AAoJEOgBcD7A/5N86SYIAICxNB6QbiqldlsHw/hpwEER qCaRA8CYGgJiZnOh8zuRRGsWRxXJ9a3UPtBaUQ9k2C8YeDHSLWn/vdJc1SjBcQw8 5kfKeucntwUwVzJj0mblKrpDtlrNEpOCm7cuSltvKdzBQ6Q9PoNbSvCsBMU6Ffd7 yu4aoMZn3IyWAa9n/LOtatlWTIHx1onB+cikAoFTucVeFzVdB4b87RAchACk0dX1 bXLa46Nr889/B0KEySHf9sFWMKIgrkXR4g6eMJuxRGu4NCpMKohACqhE4deKmqQc nelxHHszOQVMLykhOd1VB1lHWKmrtmA+VvlKBgD/G7bh/WSRnFP2hK5y1hwFEGg= =5g+Q -----END PGP SIGNATURE----- --------------enig7C5BA2E966DBFF11F7416A3D-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 17:28:42 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F5A0106566B; Fri, 29 Jun 2012 17:28:42 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF1E8FC08; Fri, 29 Jun 2012 17:28:42 +0000 (UTC) Received: from [209.249.190.124] (port=58309 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Skeyr-0007xu-2u; Fri, 29 Jun 2012 13:27:41 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20120626210606.632498e2@fabiankeil.de> Date: Fri, 29 Jun 2012 13:27:26 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5993D573-4D53-44F5-BE8F-C48E9816398B@neville-neil.com> References: <4FE9EFF9.9080507@FreeBSD.org> <1340735734.53528.YahooMailClassic@web113510.mail.gq1.yahoo.com> <20120626210606.632498e2@fabiankeil.de> To: Fabian Keil X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Mark Peek , freebsd-current@FreeBSD.org, pfg@freebsd.org Subject: Re: [RFT] llquantize for FreeBSD's dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 17:28:42 -0000 On Jun 26, 2012, at 15:06 , Fabian Keil wrote: > Pedro Giffuni wrote: > >> --- Mar 26/6/12, Mark Peek ha scritto: > >>> Try this, change the assert on line 1429 in file dt_cc.c >>> from: >>> >>> assert(!(arg & (UINT16_MAX << args[i].shift))); >>> >>> to >>> >>> assert(!(arg & ((uint64_t)UINT16_MAX << >>> args[i].shift))); >>> >> >> This certainly looks correct. Thanks Mark ! >> >> I updated the patch: >> >> http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize > > Thanks a lot. Seems to work for me: > And me as well. I tested the example from the web site. Nicely done! Best, George From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 20:32:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 497001065675; Fri, 29 Jun 2012 20:32:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92B728FC12; Fri, 29 Jun 2012 20:32:16 +0000 (UTC) Received: by lbon10 with SMTP id n10so6362921lbo.13 for ; Fri, 29 Jun 2012 13:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ehOsrdsAjWs6A/OrckXkgYX4Cn5m5KVMI0AR5/7+JHE=; b=XAgK7XWnHhWxFzE6mde33uarSv3YHZaVtuwlnjHZJCaXhr7c4uwmwgFHe94shU4T19 SymbRfbEVnvN1XOZXLfRrdiMAcbYikIm1zUR62CRnHVSqmaTtCCZkxzqmMtU2hamyNcj z+DPyg3VwSdM8BMkNkiIAhIuDYePxIWUdEVJT0eLoFQuab1G0/0J92MxjXZ8WWlKq/Vs 7P3HbkfrZpi8faJ0fGYivX38cWzDr3jC+IAY7JSgmDqx6h/5WHDqgkfc6LACdkqbzt3I gI7x3i1rVGY3sjFaU57SyWDT9wx9QngK3F+kSliykueQFid9W3nw/0zrMuau23fyG+9i 8xsg== MIME-Version: 1.0 Received: by 10.152.46.6 with SMTP id r6mr3451911lam.7.1341001935561; Fri, 29 Jun 2012 13:32:15 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Fri, 29 Jun 2012 13:32:15 -0700 (PDT) Date: Fri, 29 Jun 2012 21:32:15 +0100 X-Google-Sender-Auth: 0ShlmjcXU8U5YNu43Q-N9EzqHMI Message-ID: From: Attilio Rao To: FreeBSD FS , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 20:32:17 -0000 As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS in 2 months the code dealing with non-MPSAFE filesystem will be removed and filesystems not yet MPSAFE will be disconnected from the tree. Their code will be however available in our official repository yet for 6 months. This leaves a total time of 8 months to do actions. Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and XFS. Coda and SMBFS have current mantainership but the status of the work has still to be determined. NTFS, is being worked for the Summer of Code program. Finally, ReiserFS was successfully locked during this campaign. It is time for community members to step up and offer time and skills to lock a filesystem or test the effort of other developers willing to do so. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 20:50:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C367C106566B for ; Fri, 29 Jun 2012 20:50:37 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC498FC15 for ; Fri, 29 Jun 2012 20:50:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,500,1336363200"; d="scan'208";a="29950877" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Jun 2012 16:50:31 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Fri, 29 Jun 2012 13:50:30 -0700 From: Oleg Moskalenko To: FreeBSD Current Date: Fri, 29 Jun 2012 13:50:30 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1Uo5g7GRfagTCSQTmFXyZMUcNVBAAKET7QAFgtpPA= Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8E@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:50:37 -0000 Now I am going to provide the second informational=20 part about the new BSD sort: the differences between the new BSD sort and the GNU sort programs. Below:=20 NBSD - new BSD sort; OGNU - old BSD/GNU sort, version 5.3.0; NGNU - new GNU sort, version 8.15. There are several areas: 1) -k option (sort fields/keys), with single byte locales.=20 The -k option functionality is described in POSIX standard=20 with deceitfully simple wording. Unfortunately, the real meaning=20 is rather complex, and sometimes it defies the common sense.=20 For example, a sort key can spread across boundaries with=20 subsequent sort keys. A common-sense-based implementation=20 would fail the POSIX standard.=20 The OGNU implementation fails to follow the standard. In our tests, there are thousands various use cases when it does not work properly. The OGNU exact algorithm and the failure pattern is a mystery for us. The NGNU implements the POSIX algorithm properly, and the NBSD is compatible with NGNU when using -k in single-byte locales. 2) -k option (sort fields/keys), with multi-byte locales. Here the situation is reverse. During the -k calculation, NGNU basically=20 ignores the symbol sizes (but it does not ignore the symbol sizes when=20 it compares the fields). The result is that the sort keys are not=20 calculated correctly by the NGNU. OGNU, on the other hand, seems to use=20 the correct symbol sizes, but it is still using incorrect algorithm. So,=20 the overall picture is: - OGNU uses wrong algorithm, but it uses correct symbol sizes; - NGNU uses correct algorithm, but it uses wrong symbol sizes; - NBSD uses NGNU-compatible algorithm with correct symbol sizes. So, for big majority of users who are using only single-byte=20 locales, the NBSD sort key calculation is compatible with NGNU.=20 For the multi-byte locales (like zh_HK.Big5HKSCS), we believe=20 that only NBSD provides the correct results with -k option. 3) NGNU does not allow options -d and/or -i together with numeric sorting. OGNU and NBSD allows that. 4) NBSD adds NGNU-compatible options, which are absent in OGNU: -C (silent version of -c) -h ("human" numeric sort) -R (random sort) -V (version sort) --batch-size --compress-program --random-source --debug --files0-from =20 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=3D... (multi-threaded build only) 6) NBSD does not support option --parallel of NGNU.=20 It has roughly the same meaning as --nthreads in NBSD.=20 This difference will be fixed soon. Thanks Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Oleg Moskalenko > Sent: Wednesday, June 27, 2012 6:45 PM > To: FreeBSD Current > Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > Hi >=20 > As promised, I am supplying an example of comparison between several > sort programs. >=20 > The test file is a randomly generated 1,000,000 lines, each line > contain a single floating point number. >=20 > We are going to sort it three ways - as text, as -n numeric sort, and > as -g numeric sort, with 4 programs: > 1) Old BSD/GNU sort 5.3.0 > 2) New GNU sort 8.15 > 3) New BSD sort, single threaded > 4) New BSD sort, multi-threaded >=20 > The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All > times are in seconds. Locale C. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > TEXT SORT >=20 > sys user real > Old BSD/GNU sort: 0.0 1.692 2.008 > New GNU sort: 0.0 2.279 1.605 > New BSD sort, st: 0.0 1.964 2.300 > New BSD sort, mt: 0.0 2.385 1.897 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > NUMERIC SORT -n >=20 > sys user real > Old BSD/GNU sort: 0.0 4.357 4.674 > New GNU sort: 0.0 8.839 5.134 > New BSD sort, st: 0.0 5.308 5.592 > New BSD sort, mt: 0.0 4.581 2.489 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > NUMERIC SORT -g >=20 > sys user real > Old BSD/GNU sort: 0.0 45.378 45.630 > New GNU sort: ~450 ~121 ~300 > New BSD sort, st: 0.33 4.334 5.992 > New BSD sort, mt: 11.140 4.624 8.983 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Thanks > Oleg >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 Fri Jun 29 21:03:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id D48B51065675 for ; Fri, 29 Jun 2012 21:03:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C28BE160564; Fri, 29 Jun 2012 21:02:25 +0000 (UTC) Message-ID: <4FEE17E1.90304@FreeBSD.org> Date: Fri, 29 Jun 2012 14:02:25 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Oleg Moskalenko References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8E@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8E@SJCPMAILBOX01.citrite.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:03:10 -0000 On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: > 5) NBSD adds several of its own new proprietary options: > > --mergesort > --qsort > --heapsort > --radixsort > --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 21:20:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89EBC106566C; Fri, 29 Jun 2012 21:20:25 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 333C88FC0A; Fri, 29 Jun 2012 21:20:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,500,1336363200"; d="scan'208";a="29954388" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Jun 2012 17:20:24 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Fri, 29 Jun 2012 14:20:23 -0700 From: Oleg Moskalenko To: 'Doug Barton' Date: Fri, 29 Jun 2012 14:20:23 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1WOpyNDFoWdILgREO0TBrP4VBMZwAAftLw Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8F@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8E@SJCPMAILBOX01.citrite.net> <4FEE17E1.90304@FreeBSD.org> In-Reply-To: <4FEE17E1.90304@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Current Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:20:25 -0000 Doug, --nthreads option corresponds to --parallel option of NGNU=20 and it will be renamed. The other four proprietary options=20 will be marked as non-portable in the man page.=20 After nthreads=3D=3D>parallel renaming, NBSD will support all=20 NGNU options. Thank you for the suggestion. Oleg > -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Friday, June 29, 2012 2:02 PM > To: Oleg Moskalenko > Cc: FreeBSD Current > Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: > > 5) NBSD adds several of its own new proprietary options: > > > > --mergesort > > --qsort > > --heapsort > > --radixsort > > --nthreads=3D... (multi-threaded build only) >=20 > Oleg, >=20 > First, thank you very much for providing both the performance numbers, > and the breakdown in the differences in command line options. > Everything > looks great, my only concern is the above. >=20 > Are there similar/identical options in NGNU that correspond to the > options above? If so, I would be hesitant to add new names for them > because it hurts portability between platforms. If these are totally > new > features then my assumption is that you have clearly marked them as > non-portable in the man page? >=20 > Once again, I really appreciate you addressing my concerns, and your > hard work on this project. >=20 > Doug From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 23:23:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5E7E106566B; Fri, 29 Jun 2012 23:23:46 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 794B18FC08; Fri, 29 Jun 2012 23:23:46 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id C2D8661F0; Fri, 29 Jun 2012 19:23:38 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=ZJZ+A7asYiOF/kczVyD4XUFaCAR7qUmFvb0QxB2HIZ8QY5kOIBHXTT8JQVVrVr4mu NcJLcYS0llxqRrvrsSbhfPSjFQGITJyzXQhDOf0bLcvabB/tVEUjyWQi6ITGEqu Message-ID: <4FEE38F8.2050104@protected-networks.net> Date: Fri, 29 Jun 2012 19:23:36 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Attilio Rao References: In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 23:23:46 -0000 On 06/29/12 16:32, Attilio Rao wrote: > As already published several times, according to the following plan: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > in 2 months the code dealing with non-MPSAFE filesystem will be > removed and filesystems not yet MPSAFE will be disconnected from the > tree. Their code will be however available in our official repository > yet for 6 months. This leaves a total time of 8 months to do actions. > > Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and > XFS. Coda and SMBFS have current mantainership but the status of the > work has still to be determined. NTFS, is being worked for the Summer > of Code program. Finally, ReiserFS was successfully locked during this > campaign. What is to become of fusefs and friends, i.e. write-capable NTFS and truecrypt? imb From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 23:27:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18AB11065670; Fri, 29 Jun 2012 23:27:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 495248FC0A; Fri, 29 Jun 2012 23:27:54 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so1295377wib.1 for ; Fri, 29 Jun 2012 16:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VrOPUXCksJpl9R1LcO4j4Rn1Hczz9lZ0U4OOq0wgg6w=; b=0h2lhloe3y3oRscu70OYYEytCDByPofQ5Ybwnoekyc97H5jHoS8gITRpyW6nG0OoMB 240OI/dpbFcQyXLcoFr2+3D5sLchSPRtTtQp7e6HXsFVYTzW8zH/gM5GmG7oWgUHwxFo Iq9RWRSs8H6dcUlmzHMvWs9GLhM+7LvwNqUTU8x+vgqWZ6kVnkc7QDOPHkBAY/qhdSxD GJE16JVC/KGYi9UVRJRzxWSBA/osRpQMglcI72y4C0hl1lU1ZYzD6W0r997+AGfk6PAr jDAFhsVbW9OeFRaCRm9C4B3wBWS49rHkBel9wLi+ReLtsHn3pSwtEQr29Yhn1RYRPEuy uJ1w== MIME-Version: 1.0 Received: by 10.180.109.195 with SMTP id hu3mr1627136wib.8.1341012473120; Fri, 29 Jun 2012 16:27:53 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Fri, 29 Jun 2012 16:27:53 -0700 (PDT) In-Reply-To: <4FEE38F8.2050104@protected-networks.net> References: <4FEE38F8.2050104@protected-networks.net> Date: Fri, 29 Jun 2012 16:27:53 -0700 Message-ID: From: Kevin Oberman To: Michael Butler Content-Type: text/plain; charset=UTF-8 Cc: Attilio Rao , FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jun 2012 23:27:55 -0000 On Fri, Jun 29, 2012 at 4:23 PM, Michael Butler wrote: > On 06/29/12 16:32, Attilio Rao wrote: >> As already published several times, according to the following plan: >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >> >> in 2 months the code dealing with non-MPSAFE filesystem will be >> removed and filesystems not yet MPSAFE will be disconnected from the >> tree. Their code will be however available in our official repository >> yet for 6 months. This leaves a total time of 8 months to do actions. >> >> Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and >> XFS. Coda and SMBFS have current mantainership but the status of the >> work has still to be determined. NTFS, is being worked for the Summer >> of Code program. Finally, ReiserFS was successfully locked during this >> campaign. > > What is to become of fusefs and friends, i.e. write-capable NTFS and > truecrypt? > fusefs is not a part of the OS.It is a port. I believe gnn@ is working on it, but I have not seen any report on its status for a while. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 02:34:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3B7D106564A; Sat, 30 Jun 2012 02:34:55 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id B0DE98FC08; Sat, 30 Jun 2012 02:34:54 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5U2YMi8013540; Fri, 29 Jun 2012 20:34:49 -0600 From: Erich Dollansky Organization: ALO Green Technologies To: freebsd-x11@freebsd.org Date: Sat, 30 Jun 2012 09:34:15 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206300934.15441.erich@alogreentechnologies.com> X-Mailman-Approved-At: Sat, 30 Jun 2012 02:44:38 +0000 Cc: Andrey Fesenko , freebsd-current Subject: Re: GPU_KMS still not working CURRENT X220 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 02:34:56 -0000 Hi, On Thursday, June 28, 2012 11:15:54 PM Kevin Oberman wrote: > On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko wrote: > > I have lenovo thinkpad x220 > > > > # uname -a > > FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun > > 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL > > amd64 it works for me with this: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Thu Jun 28 09:09:16 WIT 2012 > > > > # pciconf -lvb > > vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 > > rev=0x09 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '2nd Generation Core Processor Family Integrated > > Graphics Controller' > > class = display > > subclass = VGA > > bar [10] = type Memory, range 64, base 0xf0000000, size 4194304, enabled > > bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, > > size 268435456, enabled > > bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled > > > > After # kldload i915kms screen is black, if # kldunload i915kms panic > > Don't do this. It has been clearly stated that i915kms my not be > unloaded and that attempting to unload it WILL panic the system. > > Also, don't load i945kms. This WILL lock up the system with a blank screen. > it works for me. I use this kind of script to start X: sudo kldload i915kms sudo kldload acpi_call sudo chmod 666 /dev/acpi startx > The modules required are autoloaded during Xorg initialization. Just > make absolutely sure that you have the latest version of > xf-video-intel. (If you installed a rather early version of the KMS > code, it is possible that you have two xf-video.intel* ports in your > tree, thought I don't expect this is the case. This could be the real reason why it fails But I must say that it hangs on rare occasions. It might has to do with playing with the mouse or the keyboard during the start-up phase of X. At least, I did not notice a freeze when I did not play around with them during the start of X. Erich From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 03:48:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AB65106566B; Sat, 30 Jun 2012 03:48:29 +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 6449F8FC12; Sat, 30 Jun 2012 03:48:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5U3mNSu093646; Fri, 29 Jun 2012 23:48:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5U3mNV0093642; Sat, 30 Jun 2012 03:48:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 03:48:23 GMT Message-Id: <201206300348.q5U3mNV0093642@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: Sat, 30 Jun 2012 03:48:29 -0000 TB --- 2012-06-30 02:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 02:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 02:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-30 02:20:00 - cleaning the object tree TB --- 2012-06-30 02:20:00 - cvsupping the source tree TB --- 2012-06-30 02:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-30 02:26:13 - building world TB --- 2012-06-30 02:26:13 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 02:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 02:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 02:26:13 - SRCCONF=/dev/null TB --- 2012-06-30 02:26:13 - TARGET=arm TB --- 2012-06-30 02:26:13 - TARGET_ARCH=arm TB --- 2012-06-30 02:26:13 - TZ=UTC TB --- 2012-06-30 02:26:13 - __MAKE_CONF=/dev/null TB --- 2012-06-30 02:26:13 - cd /src TB --- 2012-06-30 02:26:13 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 02:26:13 UTC 2012 >>> 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 Jun 30 03:30:02 UTC 2012 TB --- 2012-06-30 03:30:02 - cd /src/sys/arm/conf TB --- 2012-06-30 03:30:02 - /usr/sbin/config -m AVILA TB --- 2012-06-30 03:30:02 - skipping AVILA kernel TB --- 2012-06-30 03:30:02 - cd /src/sys/arm/conf TB --- 2012-06-30 03:30:02 - /usr/sbin/config -m BWCT TB --- 2012-06-30 03:30:02 - building BWCT kernel TB --- 2012-06-30 03:30:02 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:30:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:30:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:30:02 - SRCCONF=/dev/null TB --- 2012-06-30 03:30:02 - TARGET=arm TB --- 2012-06-30 03:30:02 - TARGET_ARCH=arm TB --- 2012-06-30 03:30:02 - TZ=UTC TB --- 2012-06-30 03:30:02 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:30:02 - cd /src TB --- 2012-06-30 03:30:02 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Jun 30 03:30:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Jun 30 03:32:12 UTC 2012 TB --- 2012-06-30 03:32:12 - cd /src/sys/arm/conf TB --- 2012-06-30 03:32:12 - /usr/sbin/config -m CAMBRIA TB --- 2012-06-30 03:32:12 - skipping CAMBRIA kernel TB --- 2012-06-30 03:32:12 - cd /src/sys/arm/conf TB --- 2012-06-30 03:32:12 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-06-30 03:32:13 - building CNS11XXNAS kernel TB --- 2012-06-30 03:32:13 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:32:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:32:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:32:13 - SRCCONF=/dev/null TB --- 2012-06-30 03:32:13 - TARGET=arm TB --- 2012-06-30 03:32:13 - TARGET_ARCH=arm TB --- 2012-06-30 03:32:13 - TZ=UTC TB --- 2012-06-30 03:32:13 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:32:13 - cd /src TB --- 2012-06-30 03:32:13 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Jun 30 03:32:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Jun 30 03:34:41 UTC 2012 TB --- 2012-06-30 03:34:41 - cd /src/sys/arm/conf TB --- 2012-06-30 03:34:41 - /usr/sbin/config -m CRB TB --- 2012-06-30 03:34:41 - skipping CRB kernel TB --- 2012-06-30 03:34:41 - cd /src/sys/arm/conf TB --- 2012-06-30 03:34:41 - /usr/sbin/config -m DB-78XXX TB --- 2012-06-30 03:34:41 - building DB-78XXX kernel TB --- 2012-06-30 03:34:41 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:34:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:34:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:34:41 - SRCCONF=/dev/null TB --- 2012-06-30 03:34:41 - TARGET=arm TB --- 2012-06-30 03:34:41 - TARGET_ARCH=arm TB --- 2012-06-30 03:34:41 - TZ=UTC TB --- 2012-06-30 03:34:41 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:34:41 - cd /src TB --- 2012-06-30 03:34:41 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Jun 30 03:34:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Jun 30 03:37:34 UTC 2012 TB --- 2012-06-30 03:37:34 - cd /src/sys/arm/conf TB --- 2012-06-30 03:37:34 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-06-30 03:37:34 - building DB-88F5XXX kernel TB --- 2012-06-30 03:37:34 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:37:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:37:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:37:34 - SRCCONF=/dev/null TB --- 2012-06-30 03:37:34 - TARGET=arm TB --- 2012-06-30 03:37:34 - TARGET_ARCH=arm TB --- 2012-06-30 03:37:34 - TZ=UTC TB --- 2012-06-30 03:37:34 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:37:34 - cd /src TB --- 2012-06-30 03:37:34 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Jun 30 03:37:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Jun 30 03:40:19 UTC 2012 TB --- 2012-06-30 03:40:19 - cd /src/sys/arm/conf TB --- 2012-06-30 03:40:19 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-06-30 03:40:19 - building DB-88F6XXX kernel TB --- 2012-06-30 03:40:19 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:40:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:40:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:40:19 - SRCCONF=/dev/null TB --- 2012-06-30 03:40:19 - TARGET=arm TB --- 2012-06-30 03:40:19 - TARGET_ARCH=arm TB --- 2012-06-30 03:40:19 - TZ=UTC TB --- 2012-06-30 03:40:19 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:40:19 - cd /src TB --- 2012-06-30 03:40:19 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Jun 30 03:40:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Jun 30 03:43:18 UTC 2012 TB --- 2012-06-30 03:43:18 - cd /src/sys/arm/conf TB --- 2012-06-30 03:43:18 - /usr/sbin/config -m DOCKSTAR TB --- 2012-06-30 03:43:18 - building DOCKSTAR kernel TB --- 2012-06-30 03:43:18 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:43:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:43:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:43:18 - SRCCONF=/dev/null TB --- 2012-06-30 03:43:18 - TARGET=arm TB --- 2012-06-30 03:43:18 - TARGET_ARCH=arm TB --- 2012-06-30 03:43:18 - TZ=UTC TB --- 2012-06-30 03:43:18 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:43:18 - cd /src TB --- 2012-06-30 03:43:18 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Jun 30 03:43:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Jun 30 03:45:54 UTC 2012 TB --- 2012-06-30 03:45:54 - cd /src/sys/arm/conf TB --- 2012-06-30 03:45:54 - /usr/sbin/config -m EP80219 TB --- 2012-06-30 03:45:55 - skipping EP80219 kernel TB --- 2012-06-30 03:45:55 - cd /src/sys/arm/conf TB --- 2012-06-30 03:45:55 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-06-30 03:45:55 - building ETHERNUT5 kernel TB --- 2012-06-30 03:45:55 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:45:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:45:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:45:55 - SRCCONF=/dev/null TB --- 2012-06-30 03:45:55 - TARGET=arm TB --- 2012-06-30 03:45:55 - TARGET_ARCH=arm TB --- 2012-06-30 03:45:55 - TZ=UTC TB --- 2012-06-30 03:45:55 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:45:55 - cd /src TB --- 2012-06-30 03:45:55 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Jun 30 03:45:55 UTC 2012 >>> 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 -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 03:48:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 03:48:23 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-06-30 03:48:23 - 3291.30 user 701.27 system 5302.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 04:17:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F255C106566B for ; Sat, 30 Jun 2012 04:17:34 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp2.insight.synacor.com [208.47.185.24]) by mx1.freebsd.org (Postfix) with ESMTP id A1A858FC16 for ; Sat, 30 Jun 2012 04:17:34 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=gf1CudfSVYh3XhyQAPGMwPFQ/4pzwPTMDeXC112K/mI= c=1 sm=0 a=190A9ldbhagA:10 a=jLN7EqiLvroA:10 a=6I5d2MoRAAAA:8 a=92czzIUlAAAA:8 a=FGtwrQyA_QvGIjOFz88A:9 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:41201] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 43/6E-23439-7DD7EEF4; Sat, 30 Jun 2012 00:17:27 -0400 Date: Sat, 30 Jun 2012 00:17:27 -0400 Message-ID: <43.6E.23439.7DD7EEF4@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-current@freebsd.org Cc: FreeBSD FS , Attilio Rao Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 04:17:35 -0000 On 06/29/12 16:32, Attilio Rao wrote: > As already published several times, according to the following plan: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > in 2 months the code dealing with non-MPSAFE filesystem will be > removed and filesystems not yet MPSAFE will be disconnected from the > tree. Their code will be however available in our official repository > yet for 6 months. This leaves a total time of 8 months to do actions. > Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and > XFS. Coda and SMBFS have current mantainership but the status of the > work has still to be determined. NTFS, is being worked for the Summer > of Code program. Finally, ReiserFS was successfully locked during this > campaign. I'm familiar with HPFS but not NWFS, PortalFS and SMBFS; don't really know what Coda is. I've been wondering about the status of XFS in (Free or other)BSD, know it's in ports and is usable in Linux. I think you can even run Linux on XFS instead of ext(2,3 or 4)fs, or ReiserFS, or btrfs. I remember Linux having read-only access, later also read-write, to HPFS, and I actually read HPFS partitions from Linux. That was long ago. Sometime during the single-digit days of April 2001, my OS/2 Warp 4 installation came apart when, following a crash where the file system was not cleanly dismounted, CHKDSK ran amok on reboot and trashed the entire hard disk, destroying a Linux installation as well. I was never able to boot any OS/2 again after that (trap 000c or 000d if it got that far), even from installation or other diskettes; there was no such thing as bootable CD back then, at least not for OS/2 Warp 4. Although OS/2 has continued on as eComStation (www.ecomstation.com), 32-bit i386 only, no 64-bit, eComStation has fallen far behind Linux and the BSDs. So one could say HPFS is antiquated, very few Linux or BSD users would have use for HPFS access; my last time was in April 2001. Tom From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 04:43:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C42BC106566B for ; Sat, 30 Jun 2012 04:43:26 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id C88E28FC08 for ; Sat, 30 Jun 2012 04:43:25 +0000 (UTC) Received: from [188.174.208.104] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SkpWf-0003mS-PB; Sat, 30 Jun 2012 06:43:18 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q5U4hHnS002400; Sat, 30 Jun 2012 06:43:17 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q5U4hGdr002399; Sat, 30 Jun 2012 06:43:16 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Jun 2012 06:43:16 +0200 From: Matthias Apitz To: Hans Petter Selasky Message-ID: <20120630044316.GA2383@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206291645.57359.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201206291645.57359.hselasky@c2i.net> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.208.104 Cc: freebsd-current@freebsd.org Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 04:43:26 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selasky escribió: > On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: > > Hello, > > > > I have a boot-able USB key with r235646 which works fine in all my > > laptops so far; today I got as a gift an older FS Amilo D 7830 which has > > enough resources to use it as new build machine (1 GByte RAM, 80 GByte > > disk). I booted it with from the USB key and after the system is up it > > does not echo or react on any key-press; before booting the keys are > > working, for example in the menu to boot into single user etc. > > > > What could be the problem? > > > > I will later configure that the USB booted system brings Ethernet and > > SSH up, maybe I can see something when I can login via SSH... > > > > matthias > > What does dmesg say about USB? > attached is the dmesg output matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.txt" Copyright (c) 1992-2012 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 10.0-CURRENT #0 r235646: Sat May 19 15:52:36 CEST 2012 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.35-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = f Model = 2 Stepping = 7 Features=0xbfebfbff Features2=0x4400 real memory = 1073741824 (1024 MB) avail memory = 1027141632 (979 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xd0000000-0xd7ffffff,0xffcf0000-0xffcfffff irq 16 at device 0.0 on pci1 uhci0: port 0xdf20-0xdf3f irq 16 at device 29.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: port 0xdf40-0xdf5f irq 19 at device 29.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: port 0xdf80-0xdf9f irq 18 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 ehci0: mem 0xffeffc00-0xffefffff irq 23 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: at device 3.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: port 0xcc00-0xcc7f mem 0xffdff800-0xffdfffff irq 18 at device 10.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:0d:49:75:50:7a:e8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x29b8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:0d:50:7a:e8 fwe0: Ethernet address: 02:03:0d:50:7a:e8 fwip0: on firewire0 fwip0: Firewire address: 00:03:0d:49:75:50:7a:e8 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode sis0: port 0xc800-0xc8ff mem 0xffdfe000-0xffdfefff irq 17 at device 12.0 on pci2 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:a0:cc:df:75:57 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xe000-0xe0ff,0xe100-0xe13f at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 acpi_lid0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 p4tcc0: on cpu0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: < DVD+RW RW8160 1.03> Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [847 x 2048 byte records] ATA-6 device da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 14784MB (30277632 512 byte sectors: 255H 63S/T 1884C) ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 2398347920 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0s1a [rw]... Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. lock order reversal: 1st 0xc7a4a388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254 2nd 0xc7a57168 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1383 KDB: stack backtrace: db_trace_self_wrapper(c0fcdffb,7366662f,7366765f,2e73706f,33313a63,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0ac004b,c0fd1a48,c12ce208,567,c4fb39c4,...) at kdb_backtrace+0x2a _witness_debugger(c0fd1a48,c7a57168,c0fc4dcc,c51864d8,c1001cf0,...) at _witness_debugger+0x25 witness_checkorder(c7a57168,9,c1001cf0,567,c7a57188,...) at witness_checkorder+0x86f __lockmgr_args(c7a57168,80400,c7a57188,0,0,...) at __lockmgr_args+0x8b5 vop_stdlock(c4fb3ac8,0,c4fb3abc,c12ce218,c7976950,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c10ee3a0,c4fb3ac8,c7a4b770,c11404e0,c7a57110,...) at VOP_LOCK1_APV+0xf3 _vn_lock(c7a57110,80400,c1001cf0,567,c7923000,...) at _vn_lock+0x5e ffs_flushfiles(c7951a40,2,c79768a0,0,c1140580,...) at ffs_flushfiles+0xa7 ffs_unmount(c7951a40,80000,c4fb3ba0,51f,0,...) at ffs_unmount+0x180 dounmount(c7951a40,80000,c79768a0,d9931c2c,0,...) at dounmount+0x419 vfs_unmountall(c0fc9b21,0,c0fc9a6f,143,c0a75bf4,...) at vfs_unmountall+0x4e kern_reboot(0,0,c0fc9a6f,c2,0,...) at kern_reboot+0x4ea sys_reboot(c79768a0,c4fb3ccc,c101c7a8,c0fd3464,c0aae917,...) at sys_reboot+0x6c syscall(c4fb3d08) at syscall+0x2de Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x2809726b, esp = 0xbfbfeaac, ebp = 0xbfbfebf8 --- Uptime: 5m14s usbus0: Controller shutdown uhub0: at usbus0, port 1, addr 1 (disconnected) usbus0: Controller shutdown complete usbus1: Controller shutdown uhub1: at usbus1, port 1, addr 1 (disconnected) usbus1: Controller shutdown complete usbus2: Controller shutdown uhub2: at usbus2, port 1, addr 1 (disconnected) usbus2: Controller shutdown complete usbus3: Controller shutdown uhub3: at usbus3, port 1, addr 1 (disconnected) ugen3.2: at usbus3 (disconnected) umass0: at uhub3, port 1, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 0 refs (da0:umass-sim0:0:0:0): removing device entry usbus3: Controller shutdown complete MP Configuration Table version 1.4 found at 0xc00f8df0 Table 'FACP' at 0x3ffd0200 Table 'APIC' at 0x3ffd0390 APIC: Found table at 0x3ffd0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 129 ACPI ID 2: disabled Copyright (c) 1992-2012 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 10.0-CURRENT #0 r235646: Sat May 19 15:52:36 CEST 2012 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc15f0000. Calibrating TSC clock ... TSC clock: 2398344540 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = f Model = 2 Stepping = 7 Features=0xbfebfbff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001826000 - 0x000000003ed6dfff, 1028947968 bytes (251208 pages) avail memory = 1027141632 (979 MB) INTR: Adding local APIC 0 as a target Event timer "LAPIC" quality 400 ACPI APIC Table: APIC: CPU 0 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f32c0 pnpbios: Entry = f0000:41fa Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ACPI: RSDP 0xf54e0 00014 (v00 ACPIAM) ACPI: RSDT 0x3ffd0000 00030 (v01 A M I OEMRSDT 06000308 MSFT 00000097) ACPI: FACP 0x3ffd0200 00081 (v02 A M I OEMFACP 06000308 MSFT 00000097) ACPI: DSDT 0x3ffd03f0 03831 (v01 UW FSC_____ 00000016 INTL 02002026) ACPI: FACS 0x3ffdf000 00040 ACPI: APIC 0x3ffd0390 0005C (v01 A M I OEMAPIC 06000308 MSFT 00000097) ACPI: OEMB 0x3ffdf040 00108 (v01 A M I AMI_OEM 06000308 MSFT 00000097) MADT: Found IO APIC ID 1, 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: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> 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 random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled VESA: INT 0x10 vector 0xc000:0x1e14 VESA: information block 0000 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 0010 00 01 00 04 00 01 19 01 00 01 2f 01 00 01 34 01 0020 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 0090 ff ff 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 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 0110 45 4f 4e 20 39 30 30 30 00 41 54 49 20 54 65 63 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 4d 0130 39 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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: 55 mode(s) found VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc4dbf022 (1000022) VESA: ATI MOBILITY RADEON 9000 VESA: ATI Technologies Inc. M9 01.00 io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ctl: CAM Target Layer loaded acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 2 blocks of module-level executable AML code pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25608086) pcibios: BIOS version 2.10 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4de9000 pa 0x9e000 ACPI: \\_PR_.CPU1 (ACPI ID 1) -> cpu0 ACPI: \\_PR_.CPU2 (ACPI ID 2) ignored acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed acpi_sysresource: acpi_sysresource0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) acpi_timer: acpi_timer0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: on acpi0 cpu0: switching to generic Cx mode attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 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 50 Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 1/1 1/1 1/1 1/2 1/2 1/2 1/2 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd1000-0xdffff pcib0: decoding 3 range 0x40000000-0xffffffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2560, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 28, enabled pcib0: allocated type 3 (0xe0000000-0xefffffff) for rid 10 of pci0:0:0:0 found-> vendor=0x8086, dev=0x2561, revid=0x03 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c2, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0xdf20, size 5, enabled pcib0: allocated type 4 (0xdf20-0xdf3f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24c4, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0xdf40, size 5, enabled pcib0: allocated type 4 (0xdf40-0xdf5f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24c7, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type I/O Port, range 32, base 0xdf80, size 5, enabled pcib0: allocated type 4 (0xdf80-0xdf9f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x24cd, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xffeffc00, size 10, enabled pcib0: allocated type 3 (0xffeffc00-0xffefffff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x82 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c0, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24cb, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled pcib0: allocated type 4 (0xffa0-0xffaf) for rid 20 of pci0:0:31:1 map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=0x8086, dev=0x24c3, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type I/O Port, range 32, base 0x540, size 5, enabled pcib0: allocated type 4 (0x540-0x55f) for rid 20 of pci0:0:31:3 found-> vendor=0x8086, dev=0x24c5, revid=0x02 domain=0, bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xe000, size 8, enabled pcib0: allocated type 4 (0xe000-0xe0ff) for rid 10 of pci0:0:31:5 map[14]: type I/O Port, range 32, base 0xe100, size 6, enabled pcib0: allocated type 4 (0xe100-0xe13f) for rid 14 of pci0:0:31:5 map[18]: type Memory, range 32, base 0, size 9, memory disabled map[1c]: type Memory, range 32, base 0, size 8, memory disabled found-> vendor=0x8086, dev=0x24c6, revid=0x02 domain=0, bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xe200, size 8, enabled pcib0: allocated type 4 (0xe200-0xe2ff) for rid 10 of pci0:0:31:6 map[14]: type I/O Port, range 32, base 0xe300, size 7, enabled pcib0: allocated type 4 (0xe300-0xe37f) for rid 14 of pci0:0:31:6 agp0: on hostb0 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0xb000-0xbfff) for rid 1c of pcib1 pcib0: allocated type 3 (0xffc00000-0xffcfffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xceb00000-0xdeafffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xb000-0xbfff pcib1: memory decode 0xffc00000-0xffcfffff pcib1: prefetched decode 0xceb00000-0xdeafffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x4c66, revid=0x01 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 27, enabled pcib1: allocated prefetch range (0xd0000000-0xd7ffffff) for rid 10 of pci0:1:0:0 map[14]: type I/O Port, range 32, base 0xb000, size 8, enabled pcib1: allocated I/O port range (0xb000-0xb0ff) for rid 14 of pci0:1:0:0 map[18]: type Memory, range 32, base 0xffcf0000, size 16, enabled pcib1: allocated memory range (0xffcf0000-0xffcfffff) for rid 18 of pci0:1:0:0 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 vgapci0: port 0xb000-0xb0ff mem 0xd0000000-0xd7ffffff,0xffcf0000-0xffcfffff irq 16 at device 0.0 on pci1 uhci0: port 0xdf20-0xdf3f irq 16 at device 29.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 uhci0: LegSup = 0x2f00 usbus0 on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xdf40-0xdf5f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 52 uhci1: LegSup = 0x2f00 usbus1 on uhci1 usbus1: bpf attached uhci1: usbpf: Attached uhci2: port 0xdf80-0xdf9f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 uhci2: LegSup = 0x2f00 usbus2 on uhci2 usbus2: bpf attached uhci2: usbpf: Attached ehci0: mem 0xffeffc00-0xffefffff irq 23 at device 29.7 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 usbus3: EHCI version 1.0 usbus3 on ehci0 usbus3: bpf attached ehci0: usbpf: Attached pcib2: at device 30.0 on pci0 pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib2 pcib0: allocated type 3 (0xffd00000-0xffdfffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xffd00000-0xffdfffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1217, dev=0x6972, revid=0x00 domain=0, bus=2, slot=3, func=0 class=06-07-00, hdrtype=0x02, mfdev=0 cmdreg=0x0007, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, enabled found-> vendor=0x1106, dev=0x3044, revid=0x80 domain=0, bus=2, slot=10, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=9 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xffdff800, size 11, enabled pcib2: allocated memory range (0xffdff800-0xffdfffff) for rid 10 of pci0:2:10:0 map[14]: type I/O Port, range 32, base 0xcc00, size 7, enabled pcib2: allocated I/O port range (0xcc00-0xcc7f) for rid 14 of pci0:2:10:0 pcib2: matched entry for 2.10.INTA pcib2: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x100b, dev=0x0020, revid=0x00 domain=0, bus=2, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0b (2750 ns), maxlat=0x34 (13000 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xc800, size 8, enabled pcib2: allocated I/O port range (0xc800-0xc8ff) for rid 10 of pci0:2:12:0 map[14]: type Memory, range 32, base 0xffdfe000, size 12, enabled pcib2: allocated memory range (0xffdfe000-0xffdfefff) for rid 14 of pci0:2:12:0 pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 17 cbb0: at device 3.0 on pci2 pcib2: allocated memory range (0xffd00000-0xffd00fff) for rid 10 of cbb0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xffd00000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.3.INTA pcib2: slot 3 INTA hardwired to IRQ 17 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 55 cbb0: PCI Configuration space: 0x00: 0x69721217 0x04100007 0x06070000 0x00022000 0x10: 0xffd00000 0x020000a0 0x20040302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffd 0x30: 0x00000001 0x0000fffd 0x00000001 0x07400111 0x40: 0x102a1734 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x08801882 0x90: 0x00000002 0x00000000 0x00000000 0x00000000 0xa0: 0xfe020001 0x00c04000 0x00000000 0x00000009 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x08004000 0x028203ea 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: port 0xcc00-0xcc7f mem 0xffdff800-0xffdfffff irq 18 at device 10.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:0d:49:75:50:7a:e8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x29b8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:0d:50:7a:e8 fwe0: bpf attached fwe0: Ethernet address: 02:03:0d:50:7a:e8 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:03:0d:49:75:50:7a:e8 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode sis0: port 0xc800-0xc8ff mem 0xffdfe000-0xffdfefff irq 17 at device 12.0 on pci2 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: OUI 0x1000e8, model 0x0002, rev. 1 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: bpf attached sis0: Ethernet address: 00:a0:cc:df:75:57 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata1: at channel 1 on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 pci0: at device 31.3 (no driver attached) pcm0: port 0xe000-0xe0ff,0xe100-0xe13f at device 31.5 on pci0 pcib0: allocated type 3 (0x80000000-0x800001ff) for rid 18 of pcm0 pcm0: Lazy allocation of 0x200 bytes rid 0x18 type 3 at 0x80000000 pcib0: allocated type 3 (0x80000200-0x800002ff) for rid 1c of pcm0 pcm0: Lazy allocation of 0x100 bytes rid 0x1c type 3 at 0x80000200 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 pcm0: pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, Reserved 27 pcm0: Primary codec extended features variable rate PCM, AMAP 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 "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 1968000, 4000; 0xc4f10000 -> 1968000 pcm0: sndbuf_setmap 196c000, 4000; 0xc4f14000 -> 196c000 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 psmcpnp0: irq 12 on acpi0 ppc0: using extended I/O port range ppc0: SPP EPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 58 ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 plip0: bpf attached acpi_lid0: on acpi0 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 2: ioport 0x2c00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 5: ioport 0x5c00 alloc failed ahc_isa_probe 6: ioport 0x6c00 alloc failed ahc_isa_probe 7: ioport 0x7c00 alloc failed ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 9: ioport 0x9c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 2 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 2 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 2 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 2 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 2 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 2 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 2 of orm0 isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff pnpid ORM0000 on isa0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) 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 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 atkbdc0 failed to probe at port 0x60 on isa0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 uart0 failed to probe at port 0x3f8-0x3ff irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices p4tcc0: on cpu0 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 66619500 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 lo0: bpf attached hptrr: no controller detected. pcm0: measured ac97 link rate at 48008 Hz, will use 48000 Hz usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe0:ata0:0:0:0): SIGNATURE: 0000 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ata1: reset tp1 mask=03 ostat0=50 ostat1=01 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 (aprobe0:ata1:0:0:0): SIGNATURE: eb14 battery0: battery initialization start acpi_acad0: acline initialization start battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered (probe0:ctl2cam0:0:1:0): Error 6, Unretryable error uhub3: 6 ports with 6 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 (aprobe0:ata1:0:0:0): SETFEATURES SET TRANSFER MODE. ACB: ef 03 00 00 00 40 00 00 00 00 42 00 (aprobe0:ata1:0:0:0): CAM status: Command timeout (aprobe0:ata1:0:0:0): SIGNATURE: eb14 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-6 device pass0: Serial Number MRG401K4G2NA6C pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: < DVD+RW RW8160 1.03> Removable CD-ROM SCSI-0 device cd0: Serial Number \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [847 x 2048 byte records] GEOM: new disk cd0 pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: < DVD+RW RW8160 1.03> Removable CD-ROM SCSI-0 device pass1: Serial Number \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) pass2 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass2: Removable Direct Access SCSI-2 device pass2: Serial Number 09073100023558 pass2: 40.000MB/s transfers ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number MRG401K4G2NA6C da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: Serial Number 09073100023558 da0: 40.000MB/s transfers da0: 14784MB (30277632 512 byte sectors: 255H 63S/T 1884C) ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 2398344540 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. GEOM: new disk da0 GEOM: new disk ada0 Trying to mount root from ufs:/dev/da0s1a [rw]... start_init: trying /sbin/init --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 05:25:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4FA9106566C for ; Sat, 30 Jun 2012 05:25:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 321308FC1B for ; Sat, 30 Jun 2012 05:25:23 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 291393048; Sat, 30 Jun 2012 07:25:16 +0200 From: Hans Petter Selasky To: Matthias Apitz Date: Sat, 30 Jun 2012 07:25:04 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> <201206291645.57359.hselasky@c2i.net> <20120630044316.GA2383@tinyCurrent> In-Reply-To: <20120630044316.GA2383@tinyCurrent> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@ =?iso-8859-1?q?d2+AyewRX=7DmAm=3BYp=0A=09=7CU=5B?=@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y> =?iso-8859-1?q?Y=7Dk1C4TfysrsUI=0A=09-=25GU9V5=5DiUZF=26nRn9mJ=27=3F=26?=>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201206300725.04903.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 05:25:23 -0000 On Saturday 30 June 2012 06:43:16 Matthias Apitz wrote: > El d=EDa Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selask= y=20 escribi=F3: > > On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: > > > Hello, > > >=20 > > > I have a boot-able USB key with r235646 which works fine in all my > > > laptops so far; today I got as a gift an older FS Amilo D 7830 which > > > has enough resources to use it as new build machine (1 GByte RAM, 80 > > > GByte disk). I booted it with from the USB key and after the system > > > is up it does not echo or react on any key-press; before booting the > > > keys are working, for example in the menu to boot into single user > > > etc. > > >=20 > > > What could be the problem? > > >=20 > > > I will later configure that the USB booted system brings Ethernet and > > > SSH up, maybe I can see something when I can login via SSH... > > >=20 > > > matthias > >=20 > > What does dmesg say about USB? >=20 > attached is the dmesg output >=20 > matthias Hi, Can you try to play with USB settings in the BIOS? You can also try to compile a kernel with options USB_DEBUG, and=20 hw.usb.uhub.debug=3D15. I don't see any errors in the dmesg. Maybe there are some magick bits that= =20 needs to be tweaked. Also try to put an external high speed hub in between. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 06:25:38 2012 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 8C2671065672 for ; Sat, 30 Jun 2012 06:25:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id F30528FC15 for ; Sat, 30 Jun 2012 06:25:37 +0000 (UTC) Received: from [188.174.208.104] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Skr7f-0006qI-Kv; Sat, 30 Jun 2012 08:25:35 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q5U6PYOK002697; Sat, 30 Jun 2012 08:25:34 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q5U6PXgY002696; Sat, 30 Jun 2012 08:25:33 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Jun 2012 08:25:33 +0200 From: Matthias Apitz To: Hans Petter Selasky Message-ID: <20120630062533.GA2666@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206291645.57359.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201206291645.57359.hselasky@c2i.net> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.208.104 Cc: freebsd-current@freebsd.org Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 06:25:38 -0000 El día Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selasky escribió: > On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: > > Hello, > > > > I have a boot-able USB key with r235646 which works fine in all my > > laptops so far; today I got as a gift an older FS Amilo D 7830 which has > > enough resources to use it as new build machine (1 GByte RAM, 80 GByte > > disk). I booted it with from the USB key and after the system is up it > > does not echo or react on any key-press; before booting the keys are > > working, for example in the menu to boot into single user etc. > > > > What could be the problem? > > > > I will later configure that the USB booted system brings Ethernet and > > SSH up, maybe I can see something when I can login via SSH... I have just for beeing curios booted an older USB key with r214444 (from October 2010) and the keyboard just works as it should; a ls -l /dev/kb* shows now: /dev/kbd0 -> atkbd0 /dev/kbd1 -> kbdmux0 /dev/kbdmux0 the first line /dev/kbd0 -> atkbd0 is not shown in r235646; don't know if this has todo with the problem; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 06:46:58 2012 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 5DCAF1065677; Sat, 30 Jun 2012 06:46: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 2519D8FC12; Sat, 30 Jun 2012 06:46:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5U6kvFx080826; Sat, 30 Jun 2012 02:46:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5U6kvN1080817; Sat, 30 Jun 2012 06:46:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 06:46:57 GMT Message-Id: <201206300646.q5U6kvN1080817@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: Sat, 30 Jun 2012 06:46:58 -0000 TB --- 2012-06-30 05:44:28 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 05:44:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 05:44:28 - starting HEAD tinderbox run for mips/mips TB --- 2012-06-30 05:44:28 - cleaning the object tree TB --- 2012-06-30 05:44:28 - cvsupping the source tree TB --- 2012-06-30 05:44:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-06-30 05:45:12 - building world TB --- 2012-06-30 05:45:12 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 05:45:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 05:45:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 05:45:12 - SRCCONF=/dev/null TB --- 2012-06-30 05:45:12 - TARGET=mips TB --- 2012-06-30 05:45:12 - TARGET_ARCH=mips TB --- 2012-06-30 05:45:12 - TZ=UTC TB --- 2012-06-30 05:45:12 - __MAKE_CONF=/dev/null TB --- 2012-06-30 05:45:12 - cd /src TB --- 2012-06-30 05:45:12 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 05:45:13 UTC 2012 >>> 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 Jun 30 06:45:33 UTC 2012 TB --- 2012-06-30 06:45:33 - cd /src/sys/mips/conf TB --- 2012-06-30 06:45:33 - /usr/sbin/config -m ADM5120 TB --- 2012-06-30 06:45:33 - skipping ADM5120 kernel TB --- 2012-06-30 06:45:33 - cd /src/sys/mips/conf TB --- 2012-06-30 06:45:33 - /usr/sbin/config -m ALCHEMY TB --- 2012-06-30 06:45:33 - skipping ALCHEMY kernel TB --- 2012-06-30 06:45:33 - cd /src/sys/mips/conf TB --- 2012-06-30 06:45:33 - /usr/sbin/config -m AP93 TB --- 2012-06-30 06:45:33 - building AP93 kernel TB --- 2012-06-30 06:45:33 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 06:45:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 06:45:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 06:45:33 - SRCCONF=/dev/null TB --- 2012-06-30 06:45:33 - TARGET=mips TB --- 2012-06-30 06:45:33 - TARGET_ARCH=mips TB --- 2012-06-30 06:45:33 - TZ=UTC TB --- 2012-06-30 06:45:33 - __MAKE_CONF=/dev/null TB --- 2012-06-30 06:45:33 - cd /src TB --- 2012-06-30 06:45:33 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sat Jun 30 06:45:33 UTC 2012 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 06:46:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 06:46:57 - ERROR: failed to build AP93 kernel TB --- 2012-06-30 06:46:57 - 2600.53 user 555.05 system 3748.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 06:50:07 2012 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 C15DC106566C for ; Sat, 30 Jun 2012 06:50:07 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6438FC12 for ; Sat, 30 Jun 2012 06:50:07 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5U6nxXm007357; Sat, 30 Jun 2012 00:50:01 -0600 From: Erich Dollansky Organization: ALO Green Technologies To: freebsd-current@freebsd.org, Matthias Apitz Date: Sat, 30 Jun 2012 13:49:58 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> <201206291645.57359.hselasky@c2i.net> <20120630062533.GA2666@tinyCurrent> In-Reply-To: <20120630062533.GA2666@tinyCurrent> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201206301349.58930.erich@alogreentechnologies.com> X-Mailman-Approved-At: Sat, 30 Jun 2012 11:06:16 +0000 Cc: Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 06:50:07 -0000 Hi, On Saturday, June 30, 2012 01:25:33 PM Matthias Apitz wrote: > El d=EDa Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selask= y escribi=F3: >=20 > > On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: > > > Hello, > > >=20 > > > I have a boot-able USB key with r235646 which works fine in all my > > > laptops so far; today I got as a gift an older FS Amilo D 7830 which = has > > > enough resources to use it as new build machine (1 GByte RAM, 80 GByte > > > disk). I booted it with from the USB key and after the system is up = it > > > does not echo or react on any key-press; before booting the keys are > > > working, for example in the menu to boot into single user etc. > > >=20 > > > What could be the problem? > > >=20 > > > I will later configure that the USB booted system brings Ethernet and > > > SSH up, maybe I can see something when I can login via SSH... >=20 > I have just for beeing curios booted an older USB key with r214444 > (from October 2010) and the keyboard just works as it should; >=20 I have had a problem like this before. I have had to stick with an older Fr= eeBSD version on this machine. Can you try FreeBSD 7.4 or 8.3? It is sad to say but some times support for older hardware gets cut out for= whatever reason. Erich From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 12:15:51 2012 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 C6447106564A; Sat, 30 Jun 2012 12:15:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8B56B8FC0C; Sat, 30 Jun 2012 12:15:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5UCFoxI001708; Sat, 30 Jun 2012 08:15:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5UCFouw001707; Sat, 30 Jun 2012 12:15:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 12:15:50 GMT Message-Id: <201206301215.q5UCFouw001707@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: Sat, 30 Jun 2012 12:15:51 -0000 TB --- 2012-06-30 10:50:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 10:50:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 10:50:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-30 10:50:01 - cleaning the object tree TB --- 2012-06-30 10:53:43 - cvsupping the source tree TB --- 2012-06-30 10:53:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-30 10:54:25 - building world TB --- 2012-06-30 10:54:25 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 10:54:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 10:54:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 10:54:25 - SRCCONF=/dev/null TB --- 2012-06-30 10:54:25 - TARGET=arm TB --- 2012-06-30 10:54:25 - TARGET_ARCH=arm TB --- 2012-06-30 10:54:25 - TZ=UTC TB --- 2012-06-30 10:54:25 - __MAKE_CONF=/dev/null TB --- 2012-06-30 10:54:25 - cd /src TB --- 2012-06-30 10:54:25 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 10:54:26 UTC 2012 >>> 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 Jun 30 11:57:42 UTC 2012 TB --- 2012-06-30 11:57:42 - cd /src/sys/arm/conf TB --- 2012-06-30 11:57:42 - /usr/sbin/config -m AVILA TB --- 2012-06-30 11:57:42 - skipping AVILA kernel TB --- 2012-06-30 11:57:42 - cd /src/sys/arm/conf TB --- 2012-06-30 11:57:42 - /usr/sbin/config -m BWCT TB --- 2012-06-30 11:57:42 - building BWCT kernel TB --- 2012-06-30 11:57:42 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 11:57:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 11:57:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 11:57:42 - SRCCONF=/dev/null TB --- 2012-06-30 11:57:42 - TARGET=arm TB --- 2012-06-30 11:57:42 - TARGET_ARCH=arm TB --- 2012-06-30 11:57:42 - TZ=UTC TB --- 2012-06-30 11:57:42 - __MAKE_CONF=/dev/null TB --- 2012-06-30 11:57:42 - cd /src TB --- 2012-06-30 11:57:42 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Jun 30 11:57:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Jun 30 11:59:54 UTC 2012 TB --- 2012-06-30 11:59:54 - cd /src/sys/arm/conf TB --- 2012-06-30 11:59:54 - /usr/sbin/config -m CAMBRIA TB --- 2012-06-30 11:59:54 - skipping CAMBRIA kernel TB --- 2012-06-30 11:59:54 - cd /src/sys/arm/conf TB --- 2012-06-30 11:59:54 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-06-30 11:59:54 - building CNS11XXNAS kernel TB --- 2012-06-30 11:59:54 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 11:59:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 11:59:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 11:59:54 - SRCCONF=/dev/null TB --- 2012-06-30 11:59:54 - TARGET=arm TB --- 2012-06-30 11:59:54 - TARGET_ARCH=arm TB --- 2012-06-30 11:59:54 - TZ=UTC TB --- 2012-06-30 11:59:54 - __MAKE_CONF=/dev/null TB --- 2012-06-30 11:59:54 - cd /src TB --- 2012-06-30 11:59:54 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Jun 30 11:59:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Jun 30 12:02:21 UTC 2012 TB --- 2012-06-30 12:02:21 - cd /src/sys/arm/conf TB --- 2012-06-30 12:02:21 - /usr/sbin/config -m CRB TB --- 2012-06-30 12:02:21 - skipping CRB kernel TB --- 2012-06-30 12:02:21 - cd /src/sys/arm/conf TB --- 2012-06-30 12:02:21 - /usr/sbin/config -m DB-78XXX TB --- 2012-06-30 12:02:21 - building DB-78XXX kernel TB --- 2012-06-30 12:02:21 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 12:02:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 12:02:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 12:02:21 - SRCCONF=/dev/null TB --- 2012-06-30 12:02:21 - TARGET=arm TB --- 2012-06-30 12:02:21 - TARGET_ARCH=arm TB --- 2012-06-30 12:02:21 - TZ=UTC TB --- 2012-06-30 12:02:21 - __MAKE_CONF=/dev/null TB --- 2012-06-30 12:02:21 - cd /src TB --- 2012-06-30 12:02:21 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Jun 30 12:02:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Jun 30 12:05:11 UTC 2012 TB --- 2012-06-30 12:05:11 - cd /src/sys/arm/conf TB --- 2012-06-30 12:05:11 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-06-30 12:05:11 - building DB-88F5XXX kernel TB --- 2012-06-30 12:05:11 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 12:05:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 12:05:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 12:05:11 - SRCCONF=/dev/null TB --- 2012-06-30 12:05:11 - TARGET=arm TB --- 2012-06-30 12:05:11 - TARGET_ARCH=arm TB --- 2012-06-30 12:05:11 - TZ=UTC TB --- 2012-06-30 12:05:11 - __MAKE_CONF=/dev/null TB --- 2012-06-30 12:05:11 - cd /src TB --- 2012-06-30 12:05:11 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Jun 30 12:05:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Jun 30 12:07:53 UTC 2012 TB --- 2012-06-30 12:07:53 - cd /src/sys/arm/conf TB --- 2012-06-30 12:07:53 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-06-30 12:07:53 - building DB-88F6XXX kernel TB --- 2012-06-30 12:07:53 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 12:07:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 12:07:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 12:07:53 - SRCCONF=/dev/null TB --- 2012-06-30 12:07:53 - TARGET=arm TB --- 2012-06-30 12:07:53 - TARGET_ARCH=arm TB --- 2012-06-30 12:07:53 - TZ=UTC TB --- 2012-06-30 12:07:53 - __MAKE_CONF=/dev/null TB --- 2012-06-30 12:07:53 - cd /src TB --- 2012-06-30 12:07:53 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Jun 30 12:07:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Jun 30 12:10:44 UTC 2012 TB --- 2012-06-30 12:10:44 - cd /src/sys/arm/conf TB --- 2012-06-30 12:10:44 - /usr/sbin/config -m DOCKSTAR TB --- 2012-06-30 12:10:44 - building DOCKSTAR kernel TB --- 2012-06-30 12:10:44 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 12:10:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 12:10:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 12:10:44 - SRCCONF=/dev/null TB --- 2012-06-30 12:10:44 - TARGET=arm TB --- 2012-06-30 12:10:44 - TARGET_ARCH=arm TB --- 2012-06-30 12:10:44 - TZ=UTC TB --- 2012-06-30 12:10:44 - __MAKE_CONF=/dev/null TB --- 2012-06-30 12:10:44 - cd /src TB --- 2012-06-30 12:10:44 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Jun 30 12:10:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Jun 30 12:13:21 UTC 2012 TB --- 2012-06-30 12:13:21 - cd /src/sys/arm/conf TB --- 2012-06-30 12:13:21 - /usr/sbin/config -m EP80219 TB --- 2012-06-30 12:13:21 - skipping EP80219 kernel TB --- 2012-06-30 12:13:21 - cd /src/sys/arm/conf TB --- 2012-06-30 12:13:21 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-06-30 12:13:21 - building ETHERNUT5 kernel TB --- 2012-06-30 12:13:21 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 12:13:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 12:13:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 12:13:21 - SRCCONF=/dev/null TB --- 2012-06-30 12:13:21 - TARGET=arm TB --- 2012-06-30 12:13:21 - TARGET_ARCH=arm TB --- 2012-06-30 12:13:21 - TZ=UTC TB --- 2012-06-30 12:13:21 - __MAKE_CONF=/dev/null TB --- 2012-06-30 12:13:21 - cd /src TB --- 2012-06-30 12:13:21 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Jun 30 12:13:21 UTC 2012 >>> 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 -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 12:15:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 12:15:50 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-06-30 12:15:50 - 3287.11 user 709.17 system 5149.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 15:11:35 2012 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 1EA0B106566C for ; Sat, 30 Jun 2012 15:11:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8FE8FC12 for ; Sat, 30 Jun 2012 15:11:34 +0000 (UTC) Received: from [89.204.130.164] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SkzKe-0004DO-0U; Sat, 30 Jun 2012 17:11:32 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q5UFBXSx001151; Sat, 30 Jun 2012 17:11:33 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q5UFBWFo001150; Sat, 30 Jun 2012 17:11:32 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Jun 2012 17:11:31 +0200 From: Matthias Apitz To: Erich Dollansky Message-ID: <20120630151130.GA1106@tiny.Sisis.de> References: <20120629133422.GA2233@tiny.Sisis.de> <201206291645.57359.hselasky@c2i.net> <20120630062533.GA2666@tinyCurrent> <201206301349.58930.erich@alogreentechnologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201206301349.58930.erich@alogreentechnologies.com> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.164 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 15:11:35 -0000 El día Saturday, June 30, 2012 a las 01:49:58PM +0700, Erich Dollansky escribió: > > > > I have a boot-able USB key with r235646 which works fine in all my > > > > laptops so far; today I got as a gift an older FS Amilo D 7830 which has > > > > enough resources to use it as new build machine (1 GByte RAM, 80 GByte > > > > disk). I booted it with from the USB key and after the system is up it > > > > does not echo or react on any key-press; before booting the keys are > > > > working, for example in the menu to boot into single user etc. > > > > > > > > What could be the problem? > > > > > > > > I will later configure that the USB booted system brings Ethernet and > > > > SSH up, maybe I can see something when I can login via SSH... > > > > I have just for beeing curios booted an older USB key with r214444 > > (from October 2010) and the keyboard just works as it should; > > > I have had a problem like this before. I have had to stick with an older FreeBSD version on this machine. > > Can you try FreeBSD 7.4 or 8.3? > > It is sad to say but some times support for older hardware gets cut out for whatever reason. The IT guy of my company found this laptop in the attic and because it has no Wifi, nobody is interested in using it anymore. As I said, I could make use of it as a build machine and for this it must run CURRENT and no older versions. I will install the USB booted system to harddisk and hope when booted from disk and not from USB the keyboard is working. Ofc, I would be willing to help debugging this, for example compiling a kernel with special options and/or debug printfs; but I can't start such a debug path on my own, because I have no clue about where to start. HIH matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 15:15:39 2012 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 6CA55106566B; Sat, 30 Jun 2012 15:15:39 +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 3BAF98FC18; Sat, 30 Jun 2012 15:15:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5UFFcAc090907; Sat, 30 Jun 2012 11:15:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5UFFceu090902; Sat, 30 Jun 2012 15:15:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 15:15:38 GMT Message-Id: <201206301515.q5UFFceu090902@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: Sat, 30 Jun 2012 15:15:39 -0000 TB --- 2012-06-30 14:13:09 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 14:13:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 14:13:09 - starting HEAD tinderbox run for mips/mips TB --- 2012-06-30 14:13:09 - cleaning the object tree TB --- 2012-06-30 14:14:12 - cvsupping the source tree TB --- 2012-06-30 14:14:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-06-30 14:14:47 - building world TB --- 2012-06-30 14:14:47 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 14:14:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 14:14:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 14:14:47 - SRCCONF=/dev/null TB --- 2012-06-30 14:14:47 - TARGET=mips TB --- 2012-06-30 14:14:47 - TARGET_ARCH=mips TB --- 2012-06-30 14:14:47 - TZ=UTC TB --- 2012-06-30 14:14:47 - __MAKE_CONF=/dev/null TB --- 2012-06-30 14:14:47 - cd /src TB --- 2012-06-30 14:14:47 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 14:14:48 UTC 2012 >>> 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 Jun 30 15:14:12 UTC 2012 TB --- 2012-06-30 15:14:12 - cd /src/sys/mips/conf TB --- 2012-06-30 15:14:12 - /usr/sbin/config -m ADM5120 TB --- 2012-06-30 15:14:13 - skipping ADM5120 kernel TB --- 2012-06-30 15:14:13 - cd /src/sys/mips/conf TB --- 2012-06-30 15:14:13 - /usr/sbin/config -m ALCHEMY TB --- 2012-06-30 15:14:13 - skipping ALCHEMY kernel TB --- 2012-06-30 15:14:13 - cd /src/sys/mips/conf TB --- 2012-06-30 15:14:13 - /usr/sbin/config -m AP93 TB --- 2012-06-30 15:14:13 - building AP93 kernel TB --- 2012-06-30 15:14:13 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 15:14:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 15:14:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 15:14:13 - SRCCONF=/dev/null TB --- 2012-06-30 15:14:13 - TARGET=mips TB --- 2012-06-30 15:14:13 - TARGET_ARCH=mips TB --- 2012-06-30 15:14:13 - TZ=UTC TB --- 2012-06-30 15:14:13 - __MAKE_CONF=/dev/null TB --- 2012-06-30 15:14:13 - cd /src TB --- 2012-06-30 15:14:13 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sat Jun 30 15:14:13 UTC 2012 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 15:15:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 15:15:38 - ERROR: failed to build AP93 kernel TB --- 2012-06-30 15:15:38 - 2603.27 user 555.23 system 3749.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 20:25:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEBA31065676; Sat, 30 Jun 2012 20:25: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 9DE078FC2A; Sat, 30 Jun 2012 20:25:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5UKPBCt009181; Sat, 30 Jun 2012 16:25:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5UKPBDO009180; Sat, 30 Jun 2012 20:25:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 20:25:11 GMT Message-Id: <201206302025.q5UKPBDO009180@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: Sat, 30 Jun 2012 20:25:12 -0000 TB --- 2012-06-30 19:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 19:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 19:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-30 19:00:00 - cleaning the object tree TB --- 2012-06-30 19:03:54 - cvsupping the source tree TB --- 2012-06-30 19:03:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-30 19:04:31 - building world TB --- 2012-06-30 19:04:31 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 19:04:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 19:04:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 19:04:31 - SRCCONF=/dev/null TB --- 2012-06-30 19:04:31 - TARGET=arm TB --- 2012-06-30 19:04:31 - TARGET_ARCH=arm TB --- 2012-06-30 19:04:31 - TZ=UTC TB --- 2012-06-30 19:04:31 - __MAKE_CONF=/dev/null TB --- 2012-06-30 19:04:31 - cd /src TB --- 2012-06-30 19:04:31 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 19:04:32 UTC 2012 >>> 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 Jun 30 20:07:07 UTC 2012 TB --- 2012-06-30 20:07:07 - cd /src/sys/arm/conf TB --- 2012-06-30 20:07:07 - /usr/sbin/config -m AVILA TB --- 2012-06-30 20:07:07 - skipping AVILA kernel TB --- 2012-06-30 20:07:07 - cd /src/sys/arm/conf TB --- 2012-06-30 20:07:07 - /usr/sbin/config -m BWCT TB --- 2012-06-30 20:07:07 - building BWCT kernel TB --- 2012-06-30 20:07:07 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:07:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:07:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:07:07 - SRCCONF=/dev/null TB --- 2012-06-30 20:07:07 - TARGET=arm TB --- 2012-06-30 20:07:07 - TARGET_ARCH=arm TB --- 2012-06-30 20:07:07 - TZ=UTC TB --- 2012-06-30 20:07:07 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:07:07 - cd /src TB --- 2012-06-30 20:07:07 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Jun 30 20:07:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Jun 30 20:09:20 UTC 2012 TB --- 2012-06-30 20:09:20 - cd /src/sys/arm/conf TB --- 2012-06-30 20:09:20 - /usr/sbin/config -m CAMBRIA TB --- 2012-06-30 20:09:20 - skipping CAMBRIA kernel TB --- 2012-06-30 20:09:20 - cd /src/sys/arm/conf TB --- 2012-06-30 20:09:20 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-06-30 20:09:20 - building CNS11XXNAS kernel TB --- 2012-06-30 20:09:20 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:09:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:09:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:09:20 - SRCCONF=/dev/null TB --- 2012-06-30 20:09:20 - TARGET=arm TB --- 2012-06-30 20:09:20 - TARGET_ARCH=arm TB --- 2012-06-30 20:09:20 - TZ=UTC TB --- 2012-06-30 20:09:20 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:09:20 - cd /src TB --- 2012-06-30 20:09:20 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Jun 30 20:09:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Jun 30 20:11:47 UTC 2012 TB --- 2012-06-30 20:11:47 - cd /src/sys/arm/conf TB --- 2012-06-30 20:11:47 - /usr/sbin/config -m CRB TB --- 2012-06-30 20:11:47 - skipping CRB kernel TB --- 2012-06-30 20:11:47 - cd /src/sys/arm/conf TB --- 2012-06-30 20:11:47 - /usr/sbin/config -m DB-78XXX TB --- 2012-06-30 20:11:47 - building DB-78XXX kernel TB --- 2012-06-30 20:11:47 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:11:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:11:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:11:47 - SRCCONF=/dev/null TB --- 2012-06-30 20:11:47 - TARGET=arm TB --- 2012-06-30 20:11:47 - TARGET_ARCH=arm TB --- 2012-06-30 20:11:47 - TZ=UTC TB --- 2012-06-30 20:11:47 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:11:47 - cd /src TB --- 2012-06-30 20:11:47 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Jun 30 20:11:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Jun 30 20:14:34 UTC 2012 TB --- 2012-06-30 20:14:34 - cd /src/sys/arm/conf TB --- 2012-06-30 20:14:34 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-06-30 20:14:34 - building DB-88F5XXX kernel TB --- 2012-06-30 20:14:34 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:14:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:14:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:14:34 - SRCCONF=/dev/null TB --- 2012-06-30 20:14:34 - TARGET=arm TB --- 2012-06-30 20:14:34 - TARGET_ARCH=arm TB --- 2012-06-30 20:14:34 - TZ=UTC TB --- 2012-06-30 20:14:34 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:14:34 - cd /src TB --- 2012-06-30 20:14:34 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Jun 30 20:14:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Jun 30 20:17:16 UTC 2012 TB --- 2012-06-30 20:17:16 - cd /src/sys/arm/conf TB --- 2012-06-30 20:17:16 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-06-30 20:17:16 - building DB-88F6XXX kernel TB --- 2012-06-30 20:17:16 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:17:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:17:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:17:16 - SRCCONF=/dev/null TB --- 2012-06-30 20:17:16 - TARGET=arm TB --- 2012-06-30 20:17:16 - TARGET_ARCH=arm TB --- 2012-06-30 20:17:16 - TZ=UTC TB --- 2012-06-30 20:17:16 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:17:16 - cd /src TB --- 2012-06-30 20:17:16 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Jun 30 20:17:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Jun 30 20:20:10 UTC 2012 TB --- 2012-06-30 20:20:10 - cd /src/sys/arm/conf TB --- 2012-06-30 20:20:10 - /usr/sbin/config -m DOCKSTAR TB --- 2012-06-30 20:20:10 - building DOCKSTAR kernel TB --- 2012-06-30 20:20:10 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:20:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:20:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:20:10 - SRCCONF=/dev/null TB --- 2012-06-30 20:20:10 - TARGET=arm TB --- 2012-06-30 20:20:10 - TARGET_ARCH=arm TB --- 2012-06-30 20:20:10 - TZ=UTC TB --- 2012-06-30 20:20:10 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:20:10 - cd /src TB --- 2012-06-30 20:20:10 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Jun 30 20:20:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Jun 30 20:22:45 UTC 2012 TB --- 2012-06-30 20:22:45 - cd /src/sys/arm/conf TB --- 2012-06-30 20:22:45 - /usr/sbin/config -m EP80219 TB --- 2012-06-30 20:22:45 - skipping EP80219 kernel TB --- 2012-06-30 20:22:45 - cd /src/sys/arm/conf TB --- 2012-06-30 20:22:45 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-06-30 20:22:45 - building ETHERNUT5 kernel TB --- 2012-06-30 20:22:45 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 20:22:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 20:22:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 20:22:45 - SRCCONF=/dev/null TB --- 2012-06-30 20:22:45 - TARGET=arm TB --- 2012-06-30 20:22:45 - TARGET_ARCH=arm TB --- 2012-06-30 20:22:45 - TZ=UTC TB --- 2012-06-30 20:22:45 - __MAKE_CONF=/dev/null TB --- 2012-06-30 20:22:45 - cd /src TB --- 2012-06-30 20:22:45 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Jun 30 20:22:45 UTC 2012 >>> 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 -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -mlittle-endian -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 -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 20:25:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 20:25:11 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-06-30 20:25:11 - 3286.30 user 707.99 system 5111.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 22:26:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 030C2106566C for ; Sat, 30 Jun 2012 22:26:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E1CB614E25E; Sat, 30 Jun 2012 22:26:44 +0000 (UTC) Message-ID: <4FEF7D24.8070406@FreeBSD.org> Date: Sat, 30 Jun 2012 15:26:44 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Oleg Moskalenko References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8E@SJCPMAILBOX01.citrite.net> <4FEE17E1.90304@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8F@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB8F@SJCPMAILBOX01.citrite.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 22:26:46 -0000 Sounds great, thanks again! Doug On 06/29/2012 02:20 PM, Oleg Moskalenko wrote: > Doug, > > --nthreads option corresponds to --parallel option of NGNU > and it will be renamed. The other four proprietary options > will be marked as non-portable in the man page. > > After nthreads==>parallel renaming, NBSD will support all > NGNU options. > > Thank you for the suggestion. > Oleg > >> -----Original Message----- >> From: Doug Barton [mailto:dougb@FreeBSD.org] >> Sent: Friday, June 29, 2012 2:02 PM >> To: Oleg Moskalenko >> Cc: FreeBSD Current >> Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT >> >> On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: >>> 5) NBSD adds several of its own new proprietary options: >>> >>> --mergesort >>> --qsort >>> --heapsort >>> --radixsort >>> --nthreads=... (multi-threaded build only) >> >> Oleg, >> >> First, thank you very much for providing both the performance numbers, >> and the breakdown in the differences in command line options. >> Everything >> looks great, my only concern is the above. >> >> Are there similar/identical options in NGNU that correspond to the >> options above? If so, I would be hesitant to add new names for them >> because it hurts portability between platforms. If these are totally >> new >> features then my assumption is that you have clearly marked them as >> non-portable in the man page? >> >> Once again, I really appreciate you addressing my concerns, and your >> hard work on this project. >> >> Doug > From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 22:47:24 2012 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 9C10A106564A; Sat, 30 Jun 2012 22:47:24 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 24E918FC0A; Sat, 30 Jun 2012 22:47:24 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 35CEBE6564; Sat, 30 Jun 2012 23:48:37 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=ggXQd7+FMWdy xUPYXGCVEiQKWQE=; b=ok3/+mHV6OYZpqbzmLa2ynXtKWy4AuZLkKZ4+HKEh7zp bNLVS7A5aS8y4GseOFi0BFXuaX3Pt+6t9V5sDcjrMxL9I8gz+qTgKsIK2bLgD2Mn ojhCvHUQh/gyNHKlKbAx5A+sG8ZiAxRsqurQ47AGyowqT/iCZtpqDBkoBrcm2+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=vV/uji mAVLqciWeGBhYOcN3/6uIWkr5MkU6NlnHJkEQHyFAZ3OEgeyO7H1M45zaWSDnITB wcQEMpil4SuAvPgKkHSzCmzXpyoeYzS1AivNsx2MwQ7VpBzZrPQpQqimvCwb7teG nYHza1inQbz7+kVqAOUCBOl/P5hl/hHP4sj2o= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id EDA43E6561; Sat, 30 Jun 2012 23:48:36 +0100 (BST) Message-ID: <4FEF81F5.3050509@cran.org.uk> Date: Sat, 30 Jun 2012 23:47:17 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ron McDowell , Devin Teske Subject: Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 22:47:24 -0000 On 28/06/2012 00:11, Devin Teske wrote: > I'd like to announce that I intend to import bsdconfig(8) today. I haven't seen this get committed yet - was there a problem? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 23:25:57 2012 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 03FE0106564A; Sat, 30 Jun 2012 23:25:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C81DC8FC0C; Sat, 30 Jun 2012 23:25:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q5UNPu6E099324; Sat, 30 Jun 2012 19:25:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q5UNPuuY099323; Sat, 30 Jun 2012 23:25:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Jun 2012 23:25:56 GMT Message-Id: <201206302325.q5UNPuuY099323@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: Sat, 30 Jun 2012 23:25:57 -0000 TB --- 2012-06-30 22:22:35 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 22:22:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-30 22:22:35 - starting HEAD tinderbox run for mips/mips TB --- 2012-06-30 22:22:35 - cleaning the object tree TB --- 2012-06-30 22:23:35 - cvsupping the source tree TB --- 2012-06-30 22:23:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-06-30 22:24:09 - building world TB --- 2012-06-30 22:24:09 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 22:24:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 22:24:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 22:24:09 - SRCCONF=/dev/null TB --- 2012-06-30 22:24:09 - TARGET=mips TB --- 2012-06-30 22:24:09 - TARGET_ARCH=mips TB --- 2012-06-30 22:24:09 - TZ=UTC TB --- 2012-06-30 22:24:09 - __MAKE_CONF=/dev/null TB --- 2012-06-30 22:24:09 - cd /src TB --- 2012-06-30 22:24:09 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 30 22:24:10 UTC 2012 >>> 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 Jun 30 23:24:38 UTC 2012 TB --- 2012-06-30 23:24:38 - cd /src/sys/mips/conf TB --- 2012-06-30 23:24:38 - /usr/sbin/config -m ADM5120 TB --- 2012-06-30 23:24:38 - skipping ADM5120 kernel TB --- 2012-06-30 23:24:38 - cd /src/sys/mips/conf TB --- 2012-06-30 23:24:38 - /usr/sbin/config -m ALCHEMY TB --- 2012-06-30 23:24:38 - skipping ALCHEMY kernel TB --- 2012-06-30 23:24:38 - cd /src/sys/mips/conf TB --- 2012-06-30 23:24:38 - /usr/sbin/config -m AP93 TB --- 2012-06-30 23:24:39 - building AP93 kernel TB --- 2012-06-30 23:24:39 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 23:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 23:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 23:24:39 - SRCCONF=/dev/null TB --- 2012-06-30 23:24:39 - TARGET=mips TB --- 2012-06-30 23:24:39 - TARGET_ARCH=mips TB --- 2012-06-30 23:24:39 - TZ=UTC TB --- 2012-06-30 23:24:39 - __MAKE_CONF=/dev/null TB --- 2012-06-30 23:24:39 - cd /src TB --- 2012-06-30 23:24:39 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sat Jun 30 23:24:39 UTC 2012 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-30 23:25:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-30 23:25:55 - ERROR: failed to build AP93 kernel TB --- 2012-06-30 23:25:55 - 2599.04 user 560.16 system 3800.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 23:51:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD408106566B for ; Sat, 30 Jun 2012 23:51:48 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id 70A1B8FC0A for ; Sat, 30 Jun 2012 23:51:48 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id q5UNpfQC089984 for ; Sat, 30 Jun 2012 19:51:47 -0400 (EDT) (envelope-from andy@neu.net) Date: Sat, 30 Jun 2012 19:51:41 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Subject: problem with top X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 23:51:48 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r237852: Sat Jun 30 18:45:27 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 After a recent upgrade, I am seeing a formatting issue with top. top -SPH -s 1: last pid: 26011; load averages: 3.61, 2.80, 1.56 up 0+00:23:30 19:48:46 268 processes: 6 running, 245 sleeping, 17 waiting CPU 0: 22.0% user, 0.0% nice, 0.8% system, 0.8% interrupt, 76.4% idle CPU 16877.6ctive, 2313M Inact, 6.3M Wired, 3 0.8 Cache, 1440M65.4, 7674M Free CPU 2: 28.3% user, 0.0% nice, 2.4% system, 0.0% interrupt, 69.3% idle CPU 3: 36.2% user, 0.0% nice, 1.6% system, 0.0% interrupt, 62.2% idle Mem: 455M Active, 2302M Inact, 3151M Wired, 3900K Cache, 1440M Buf, 7943M Free Swap: 20G Total, 20G Free Seems like the entry for CPU 1 is wrong. From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 23:53:41 2012 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 018CC106564A for ; Sat, 30 Jun 2012 23:53:41 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id A60118FC0A for ; Sat, 30 Jun 2012 23:53:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,503,1336363200"; d="scan'208";a="200648138" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Jun 2012 19:53:34 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Sat, 30 Jun 2012 16:53:33 -0700 From: Oleg Moskalenko To: FreeBSD Current Date: Sat, 30 Jun 2012 16:53:33 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1Uo5g7GRfagTCSQTmFXyZMUcNVBAAKET7QAJNWXtA= Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB94@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <4FEB6D2B.4090508@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB84@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 23:53:41 -0000 I am going to post the ministat results of my tests: 1) Text sort of 167-Mb file (1,000,000 random lines, each contains several = fields,=20 each field is either a floating point number or a binary string with ran= dom=20 symbols between 0 and 255).=20 Sorted on second field (-k 2,2 option): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D x OGNU + NGNU * NBSD (multi-threaded) +--------------------------------------------------+ | x * + | | x x * +++ | |xxxxx x * ** * +++* * * *| | |_A_| |_______M_|AA___________| | +--------------------------------------------------+ N Min Max Median Avg Stddev x 10 5.758 5.937 5.848 5.8508 0.057276716 + 10 6.29 6.366 6.332 6.3302 0.02123833 Difference at 95.0% confidence 0.4794 +/- 0.0405862 8.19375% +/- 0.693687% (Student's t, pooled s =3D 0.0431954) * 10 6.067 7.228 6.225 6.3449 0.35979422 Difference at 95.0% confidence 0.4941 +/- 0.242055 8.445% +/- 4.13713% (Student's t, pooled s =3D 0.257616) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) Same file, numeric sort on the same field (-k 2,2 -n option): x OGNU.n + NGNU.n * NBSD.n (multi-threaded) +--------------------------------------------------+ |**** * x x x +++| |**** * xx x x ++++| | |MA_| |__A_| |A | +--------------------------------------------------+ N Min Max Median Avg Stddev x 10 7.142 7.338 7.216 7.2179 0.066727389 + 10 8.231 8.307 8.271 8.2677 0.022701199 Difference at 95.0% confidence 1.0498 +/- 0.0468287 14.5444% +/- 0.648785% (Student's t, pooled s =3D 0.0498392) * 10 6.91 7.094 6.98 6.9864 0.061449528 Difference at 95.0% confidence -0.2315 +/- 0.0602683 -3.2073% +/- 0.834983% (Student's t, pooled s =3D 0.0641428) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On these two tests, all three program produced the same output. So, on text sort, NBSD is slightly slower than GNU; on simple numeric sort, NBSD is slightly faster. I did not use ministat for complex numeric sort (-g) because the performanc= e=20 difference is huge (in favor of NBSD) and it would make no sense. Thanks Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Oleg Moskalenko > Sent: Wednesday, June 27, 2012 6:45 PM > To: FreeBSD Current > Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT >=20 > Hi >=20 > As promised, I am supplying an example of comparison between several > sort programs. >=20 > The test file is a randomly generated 1,000,000 lines, each line > contain a single floating point number. >=20 > We are going to sort it three ways - as text, as -n numeric sort, and > as -g numeric sort, with 4 programs: > 1) Old BSD/GNU sort 5.3.0 > 2) New GNU sort 8.15 > 3) New BSD sort, single threaded > 4) New BSD sort, multi-threaded >=20 > The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All > times are in seconds. Locale C. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > TEXT SORT >=20 > sys user real > Old BSD/GNU sort: 0.0 1.692 2.008 > New GNU sort: 0.0 2.279 1.605 > New BSD sort, st: 0.0 1.964 2.300 > New BSD sort, mt: 0.0 2.385 1.897 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > NUMERIC SORT -n >=20 > sys user real > Old BSD/GNU sort: 0.0 4.357 4.674 > New GNU sort: 0.0 8.839 5.134 > New BSD sort, st: 0.0 5.308 5.592 > New BSD sort, mt: 0.0 4.581 2.489 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > NUMERIC SORT -g >=20 > sys user real > Old BSD/GNU sort: 0.0 45.378 45.630 > New GNU sort: ~450 ~121 ~300 > New BSD sort, st: 0.33 4.334 5.992 > New BSD sort, mt: 11.140 4.624 8.983 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Thanks > Oleg >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 23:55:02 2012 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 F15ED106566B for ; Sat, 30 Jun 2012 23:55:01 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id A18588FC18 for ; Sat, 30 Jun 2012 23:55:01 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5UNsxXd026193; Sat, 30 Jun 2012 17:55:01 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Sun, 1 Jul 2012 06:54:58 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207010654.58777.erichfreebsdlist@ovitrap.com> Cc: AN Subject: Re: problem with top X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 23:55:02 -0000 Hi, On Sunday, July 01, 2012 06:51:41 AM AN wrote: > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r237852: Sat Jun 30 > 18:45:27 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > After a recent upgrade, I am seeing a formatting issue with top. > > top -SPH -s 1: > > last pid: 26011; load averages: 3.61, 2.80, 1.56 up > 0+00:23:30 19:48:46 > 268 processes: 6 running, 245 sleeping, 17 waiting > CPU 0: 22.0% user, 0.0% nice, 0.8% system, 0.8% interrupt, 76.4% idle > CPU 16877.6ctive, 2313M Inact, 6.3M Wired, 3 0.8 Cache, 1440M65.4, 7674M > Free > CPU 2: 28.3% user, 0.0% nice, 2.4% system, 0.0% interrupt, 69.3% idle > CPU 3: 36.2% user, 0.0% nice, 1.6% system, 0.0% interrupt, 62.2% idle > Mem: 455M Active, 2302M Inact, 3151M Wired, 3900K Cache, 1440M Buf, 7943M > Free > Swap: 20G Total, 20G Free > > > Seems like the entry for CPU 1 is wrong. I also noticed this but thought it is of temporary nature. The data of CPU 1 is getting overwritten by the data of the memory usage. Erich