From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 04:15:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF8853D2; Sun, 20 Jan 2013 04:15:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A6302F55; Sun, 20 Jan 2013 04:15:02 +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 r0K4F1lZ032616; Sat, 19 Jan 2013 23:15:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0K4F1Zw032583; Sun, 20 Jan 2013 04:15:01 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 20 Jan 2013 04:15:01 GMT Message-Id: <201301200415.r0K4F1Zw032583@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 04:15:02 -0000 TB --- 2013-01-20 02:14:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-20 02:14:44 - 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 --- 2013-01-20 02:14:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-20 02:14:44 - cleaning the object tree TB --- 2013-01-20 02:16:42 - /usr/local/bin/svn stat /src TB --- 2013-01-20 02:16:46 - At svn revision 245677 TB --- 2013-01-20 02:16:47 - building world TB --- 2013-01-20 02:16:47 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 02:16:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 02:16:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 02:16:47 - SRCCONF=/dev/null TB --- 2013-01-20 02:16:47 - TARGET=ia64 TB --- 2013-01-20 02:16:47 - TARGET_ARCH=ia64 TB --- 2013-01-20 02:16:47 - TZ=UTC TB --- 2013-01-20 02:16:47 - __MAKE_CONF=/dev/null TB --- 2013-01-20 02:16:47 - cd /src TB --- 2013-01-20 02:16:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 20 02:16:52 UTC 2013 >>> 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 Sun Jan 20 03:53:35 UTC 2013 TB --- 2013-01-20 03:53:35 - generating LINT kernel config TB --- 2013-01-20 03:53:35 - cd /src/sys/ia64/conf TB --- 2013-01-20 03:53:35 - /usr/bin/make -B LINT TB --- 2013-01-20 03:53:35 - cd /src/sys/ia64/conf TB --- 2013-01-20 03:53:35 - /usr/sbin/config -m LINT TB --- 2013-01-20 03:53:35 - building LINT kernel TB --- 2013-01-20 03:53:35 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 03:53:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 03:53:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 03:53:35 - SRCCONF=/dev/null TB --- 2013-01-20 03:53:35 - TARGET=ia64 TB --- 2013-01-20 03:53:35 - TARGET_ARCH=ia64 TB --- 2013-01-20 03:53:35 - TZ=UTC TB --- 2013-01-20 03:53:35 - __MAKE_CONF=/dev/null TB --- 2013-01-20 03:53:35 - cd /src TB --- 2013-01-20 03:53:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 20 03:53:35 UTC 2013 >>> 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 [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-20 04:15:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-20 04:15:01 - ERROR: failed to build LINT kernel TB --- 2013-01-20 04:15:01 - 5520.48 user 1232.55 system 7216.94 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 07:34:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D45D391; Sun, 20 Jan 2013 07:34: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 4DAC2377; Sun, 20 Jan 2013 07:34: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 r0K7Yo22017797; Sun, 20 Jan 2013 02:34:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0K7Yo4J017796; Sun, 20 Jan 2013 07:34:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 20 Jan 2013 07:34:50 GMT Message-Id: <201301200734.r0K7Yo4J017796@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 07:34:51 -0000 TB --- 2013-01-20 06:29:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-20 06:29:21 - 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 --- 2013-01-20 06:29:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-01-20 06:29:21 - cleaning the object tree TB --- 2013-01-20 06:29:21 - /usr/local/bin/svn stat /src TB --- 2013-01-20 06:30:49 - At svn revision 245677 TB --- 2013-01-20 06:30:50 - building world TB --- 2013-01-20 06:30:50 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 06:30:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 06:30:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 06:30:50 - SRCCONF=/dev/null TB --- 2013-01-20 06:30:50 - TARGET=powerpc TB --- 2013-01-20 06:30:50 - TARGET_ARCH=powerpc TB --- 2013-01-20 06:30:50 - TZ=UTC TB --- 2013-01-20 06:30:50 - __MAKE_CONF=/dev/null TB --- 2013-01-20 06:30:50 - cd /src TB --- 2013-01-20 06:30:50 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 20 06:30:54 UTC 2013 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaInit.cpp -o SemaInit.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLambda.cpp -o SemaLambda.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp -o SemaLookup.o /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp: In member function 'void clang::Sema::ArgumentDependentLookup(clang::DeclarationName, bool, clang::SourceLocation, llvm::ArrayRef, clang::ADLResult&)': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaLookup.cpp:2652: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [SemaLookup.o] Error code 1 Stop in /src/lib/clang/libclangsema. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-20 07:34:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-20 07:34:50 - ERROR: failed to build world TB --- 2013-01-20 07:34:50 - 3180.58 user 417.23 system 3928.79 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 09:15:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D81475B for ; Sun, 20 Jan 2013 09:15:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id CAD0C8BD for ; Sun, 20 Jan 2013 09:15:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Twr4g-0003X5-Rm for current@freebsd.org; Sun, 20 Jan 2013 13:20:22 +0400 Date: Sun, 20 Jan 2013 13:20:22 +0400 From: Slawa Olhovchenkov To: current@freebsd.org Subject: FreeBSD-10.0-CURRENT-i386-20130108-r245175-release.iso trapped at rm -r Message-ID: <20130120092022.GA13382@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 09:15:46 -0000 Fresh install FreeBSD-10.0-CURRENT-i386-20130108-r245175-release.iso in virtualbox 4.2 (Host -- FreeBSD-9 amd64). After install run in headless mode, login by ssh. mount -u -o async / rm -r /usr/port Got trap http://zxy.spb.ru/trap.png From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 09:39:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47C7698F for ; Sun, 20 Jan 2013 09:39:55 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id 270DA923 for ; Sun, 20 Jan 2013 09:39:54 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so2791090pbc.32 for ; Sun, 20 Jan 2013 01:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4KWmO0vgjZ6GYI+Na3KCnES/4E4NcgnYInOmfUXBXzg=; b=rqu2uCT2PxBkZkOKcL60RxxHFMUhdbQ/1EN11nDtBUTX3sWAFOHzUWCfnenUo6fyOG q991ZoEhzHOkSE36t4qb7h+vosf5x9lmolq9QstDFROSSnxXhQYayeMWfpR8FPilVjmy iav0ztew7T4feyZa68lorQCe5Dl/WxH486K+M4gsoibp0U0tcdqTRZrAseovFEQS92ZK fqCZwBMQQ4By7AGDZxz4uJHfwV75P07PNCArV0b7YRpBuLLduZUiUzB0ASmXY+8vooMi 5eNKN3jHfzlpTiv0IAKCsjriUMaoHdRLSOJKyjUeA4Xk7zesD7WaT7WstnITH8F9aCsA VcQw== X-Received: by 10.68.212.200 with SMTP id nm8mr21319032pbc.4.1358674794424; Sun, 20 Jan 2013 01:39:54 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id tq4sm6495636pbc.50.2013.01.20.01.39.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 01:39:53 -0800 (PST) Message-ID: <50FBBB60.5070702@gmail.com> Date: Sun, 20 Jan 2013 01:39:44 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: ZFS Trim on mps? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 09:39:55 -0000 Should I be getting trim with ZFS on an mps device? Disks are SATA ssd (830s), only "unsupported" is being reported. Do I need to set the cam "da" delete method to something (unmap?), or is ZFS trim only supported on ahci sata controllers? vfs.zfs.trim_disable: 0 vfs.zfs.trim_txg_limit: 64 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 281 Matt From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 10:29:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15DC153E for ; Sun, 20 Jan 2013 10:29:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 804D3B1C for ; Sun, 20 Jan 2013 10:29:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0KAT804072982; Sun, 20 Jan 2013 12:29:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0KAT804072982 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0KAT8Xl072981; Sun, 20 Jan 2013 12:29:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Jan 2013 12:29:08 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter() Message-ID: <20130120102908.GC2522@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9uNR01GrImESOVvg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 10:29:15 -0000 --9uNR01GrImESOVvg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2013 at 11:56:27AM -0500, Ryan Stone wrote: > I have been experiencing occasional deadlocks on FreeBSD 8.2 systems using > the ULE scheduler. The root cause in every case has been that ULE's > TDQ_LOCK for cpu 0 is owned by a thread that is not running. I have been > investigating the issue, and I believe that I see the issue. The problem > occurs if the interrupt that drives statclock does not call > critical_enter() upon calling into statclock(). The lapic timer does use > critical_enter(), so default configurations would not see this. I have > local patches to use the RTC to drive statclock, and from a quick reading > of the eventtimer code in -CURRENT the same thing is possible there. The > RTC code does not call statclock within a critical section. So here's the > bug: >=20 > 1) A thread with interrupts enabled, running on CPU 0, with td_owepreempt= =3D1 > and td_critnest=3D1 calls critical_exit(): >=20 > void > critical_exit(void) > { > // ... > if (td->td_critnest =3D=3D 1) { > td->td_critnest =3D 0; > if (td->td_owepreempt && !kdb_active) { > // Irrelevant bits snipped >=20 > 2) td_critnest is set to 0, and then the RTC interrupt fires. >=20 > 3) rtcintr calls into statclock (8.2) or statclock_cnt(head) with > td_critnest still 0 (on head it goes through the eventtimer code, but it > ends up in statclock eventually). >=20 > 4) statclock takes the thread_lock on curthread, then calls sched_clock(). > sched_clock calls sched_balance(); >=20 > static void > sched_balance(void) > { > // snip... > tdq =3D TDQ_SELF(); > TDQ_UNLOCK(tdq); > sched_balance_group(cpu_top); > TDQ_LOCK(tdq); > } I think that current code deserves at least CRITICAL_ASSERT() on the entry to sched_balance(). The same assert should be added to kern_clocksource.c::timercb(). >=20 > TDQ_UNLOCK does a spinlock_exit which does a critical_exit. td_critnest > will be decremented back to 0 and td_owepreempt is still 1, so this > triggers a preemption. Note that this TDQ_UNLOCK is (intentionally) > unlocking the thread_lock done by statclock. >=20 > 5) thread migrates to any other CPU, call it CPU n. tdq is now stale. > TDQ_LOCK takes the lock for CPU 0 (but really it's intending to re-take t= he > thread_lock, although a thread_lock() here would be equally incorrect -- > sched_balance's caller is going to be mucking around with the TDQ when > sched_balance returns). >=20 > 6) The thread returns to statclock. statclock does a thread_unlock(). The > td_lock is TDQ_LOCK(n), which we don't hold. We mangle the stat of > TDQ_LOCK(n) and leave TDQ_LOCK(0) held. >=20 >=20 > The simplest solution would be to do a critical_enter() in sched_balance, > although that would be superfluous in the normal case where the lapic tim= er > is driving statclock. I'm not sure if there's other code in the > eventtimers infrastructure that's assuming that a preemption or migration > is impossible while handling an event. A quick look at kern_clocksource.c > turns up worrying comments like "Handle all events for specified time on > this CPU" and uses of curcpu, so there may well be other issues lurking > here. >=20 > It looks to me that the safest thing to do would be to push the > critical_enter() into the eventtimer code or even all the way back to the > interrupt handlers (mirroring what the lapic code already does). Both atrtc and hpet register the interrupt handler as the filter. The filters call loop enters critical section around handlers, see kern_intr.c:intr_event_handle(). At least on HEAD it is so, and I see the same code in the 8. --9uNR01GrImESOVvg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ+8bzAAoJEJDCuSvBvK1Bzf0P/i6Pn20zXYAF3J/4pOjfxs8n IXCy9Oww+1tKBOYnfZoWjvcllJqmGg7xI8rwNWrmJE9ctPRLEkBJK4nEh1fg6ySu 9hxvNwEXofOHGzifHX61OzKkr3on0OeRvru9V8p8Rcd5p97tKaQJK1nLyHGD8df6 WIUKkQJDAjrGImQ4T1JzIvWOA/M60cYGMJEYhXeUeqTJsY0O1nYQAyxv11Nk7day wtc3cO2AtvVKETyAO1ghqR7Uc42b0+IYbYqc/CnyLCfFn9+ibZMCT+eL/Jfkgeur 62kt6L0qxGLy/fKTlK2cddWFfPyBXOLT6PxYlcpGshGaZD0srHIN+HiJ921Heuqa bWWd3dxMAsJq/u3z+IUw0+gzUbw/rlLt++zpVQN6bGW6R+FPMyHeaD4ZrWryPmOO GikeQG4IzkpcQXjTr+V23fvbojHHosTVZocrhS8yKUxWshOGOEZNVntjejD0RwnQ O9nKdt3H5xPBWTmn4pKHQp212gzNAbA5z+nRMQsDtyMhk15VbqQw+Akdp/I+Px6k 99lKoGiUi0Ft2QECac+nyAGdnQpBxe0h9wrmgyUkXr20f60N9G9hazC6mQqpTOPv zPvVOtDpBarVIrSs0mx9kbI/zwq2CzEQBO+4ZBSALI07QccrtD9OxGR9elojMUk/ HogeXqujI8vFr6Z/L/mJ =Orve -----END PGP SIGNATURE----- --9uNR01GrImESOVvg-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 07:06:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFB2617D; Sun, 20 Jan 2013 07:06:33 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4364C2EC; Sun, 20 Jan 2013 07:06:32 +0000 (UTC) Received: from eee.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 2F99118AC6; Sun, 20 Jan 2013 16:06:30 +0900 (JST) Received: from nest.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) (authenticated bits=0) by eee.bbnest.net (8.14.6/8.14.5) with ESMTP id r0K768Xp009354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jan 2013 16:06:09 +0900 (JST) (envelope-from bland@bbnest.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS + usb in trouble? From: Alexander Nedotsukov In-Reply-To: Date: Sun, 20 Jan 2013 16:06:09 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <69A7081B-B50A-440F-8DA2-A1E29AB728D6@bbnest.net> References: To: FreeBSD Current X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Jan 20 16:06:30 2013 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50fb977693551021314089 X-Mailman-Approved-At: Sun, 20 Jan 2013 12:21:42 +0000 Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 07:06:33 -0000 Borrowed USB stick today and did same excersize as below (# zpool create = tank raidz da5{d,e,f}) with exactly same outcome. On 19.01.2013, at 23:26, Alexander Nedotsukov wrote: > Hi All, >=20 > Just a note that after catch up with -current my zfs pool kissed good = bye. I'll omit details about its last days and go strait to the final = state: >=20 > Creating pool from scratch: >=20 > #zpool create tank raidz da{1..3} > #zpool status > pool: tank > state: ONLINE > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 >=20 > errors: No known data errors > #zfs list > NAME USED AVAIL REFER MOUNTPOINT > tank 140K 3,56T 40,0K /tank >=20 > Let's use some space out of it. >=20 > #dd if=3D/dev/zero of=3D/tank/foo > ^C250939+0 records in > 250938+0 records out > 128480256 bytes transferred in 30.402453 secs (4225983 bytes/sec) >=20 > Oops... >=20 > #zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an unrecoverable error. = An > attempt was made to correct the error. Applications are = unaffected. > action: Determine if the device needs to be replaced, and clear the = errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 5K in 0h0m with 0 errors on Sat Jan 19 23:11:20 = 2013 > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da1 ONLINE 0 0 1 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 1 >=20 > At some state (more data copied) it is enough to do another scrub run = to trigger new cksum errors / unrecoverable file loss. > I do not see any error messages from kernel and smartctl output has = zero error counters. > Full memtest cycle seems to be all right. > Kernel built with gcc is suffering from same sympthoms. > Tried to create raidz pool out of files and it worked fine (even = placed one chunk to UFS made out of da0).=20 >=20 > Any idea what it can be? >=20 > Last kernel which did work was back from October 2012. >=20 > Thanks, > Alexander. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 14:23:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81E6EA4C; Sun, 20 Jan 2013 14:23:10 +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 4203B680; Sun, 20 Jan 2013 14:23:09 +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 r0KEN9Hk028469; Sun, 20 Jan 2013 09:23:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0KEN9GW028424; Sun, 20 Jan 2013 14:23:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 20 Jan 2013 14:23:09 GMT Message-Id: <201301201423.r0KEN9GW028424@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 14:23:10 -0000 TB --- 2013-01-20 12:25:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-20 12:25:42 - 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 --- 2013-01-20 12:25:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-20 12:25:42 - cleaning the object tree TB --- 2013-01-20 12:27:02 - /usr/local/bin/svn stat /src TB --- 2013-01-20 12:27:05 - At svn revision 245686 TB --- 2013-01-20 12:27:06 - building world TB --- 2013-01-20 12:27:06 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 12:27:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 12:27:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 12:27:06 - SRCCONF=/dev/null TB --- 2013-01-20 12:27:06 - TARGET=ia64 TB --- 2013-01-20 12:27:06 - TARGET_ARCH=ia64 TB --- 2013-01-20 12:27:06 - TZ=UTC TB --- 2013-01-20 12:27:06 - __MAKE_CONF=/dev/null TB --- 2013-01-20 12:27:06 - cd /src TB --- 2013-01-20 12:27:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 20 12:27:11 UTC 2013 >>> 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 Sun Jan 20 14:02:41 UTC 2013 TB --- 2013-01-20 14:02:41 - generating LINT kernel config TB --- 2013-01-20 14:02:41 - cd /src/sys/ia64/conf TB --- 2013-01-20 14:02:41 - /usr/bin/make -B LINT TB --- 2013-01-20 14:02:41 - cd /src/sys/ia64/conf TB --- 2013-01-20 14:02:41 - /usr/sbin/config -m LINT TB --- 2013-01-20 14:02:41 - building LINT kernel TB --- 2013-01-20 14:02:41 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 14:02:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 14:02:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 14:02:41 - SRCCONF=/dev/null TB --- 2013-01-20 14:02:41 - TARGET=ia64 TB --- 2013-01-20 14:02:41 - TARGET_ARCH=ia64 TB --- 2013-01-20 14:02:41 - TZ=UTC TB --- 2013-01-20 14:02:41 - __MAKE_CONF=/dev/null TB --- 2013-01-20 14:02:41 - cd /src TB --- 2013-01-20 14:02:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 20 14:02:41 UTC 2013 >>> 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 [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-20 14:23:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-20 14:23:09 - ERROR: failed to build LINT kernel TB --- 2013-01-20 14:23:09 - 5387.35 user 1227.09 system 7046.46 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 16:33:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B70CFEA5 for ; Sun, 20 Jan 2013 16:33:06 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mx1.freebsd.org (Postfix) with ESMTP id 87335A9A for ; Sun, 20 Jan 2013 16:33:06 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id dn14so5195395obc.30 for ; Sun, 20 Jan 2013 08:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=anpJDWlne39PIlhi4rC1JSnYt/yV9AbuZUIpKm1zveU=; b=Ne+oH0beXdmZao4E2AcOMQnFX6/8MfsTb9vXEr6fn0cHCyvr4b9L6kbIpRFKQcly4V dHKxb3dwtTPBwfRmdgnS5iP6LlOOBrr0LxOYKaCRIKaSjBqtL0aCtGzMWZ52+bZBO3CW KaUgiRfLryAGi3ghvgvt6GX/zDikKGu8yDeGKro/MKTHS4FSRfV5gorm7f8dn6mX7Z/R Y/WEJAtX+ndou5L2ZKL7Euxq/hIbcezpr7586GkfFkklF/IpUa+DTz/UF5VxyxhwtSnk zqXi+2x10+2WAUJbpV7am+ZLChX9tthTmczR8GOUMlhjHgbQmlB/IuOtxN/Q7BHwr5gx Xmgg== MIME-Version: 1.0 X-Received: by 10.60.172.6 with SMTP id ay6mr11765144oec.10.1358699585456; Sun, 20 Jan 2013 08:33:05 -0800 (PST) Received: by 10.76.128.68 with HTTP; Sun, 20 Jan 2013 08:33:05 -0800 (PST) In-Reply-To: <20130120102908.GC2522@kib.kiev.ua> References: <20130120102908.GC2522@kib.kiev.ua> Date: Sun, 20 Jan 2013 11:33:05 -0500 Message-ID: Subject: Re: ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter() From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 16:33:06 -0000 On Sun, Jan 20, 2013 at 5:29 AM, Konstantin Belousov wrote: > Both atrtc and hpet register the interrupt handler as the filter. > The filters call loop enters critical section around handlers, see > kern_intr.c:intr_event_handle(). At least on HEAD it is so, and I see > the same code in the 8. > Huh, I missed that. However, on 8.2 ipi_bitmap_handler does not do a critical_enter() (while HEAD does), so if CPU 0 gets an IPI_STATCLOCK, we have my bug. I have DTrace data (from 8.2) showing a thread entering sched_switch() from sched_balance() when called through an IPI_STATCLOCK. I'll poke around some more in HEAD to see if there are any entry points (maybe on other architectures) that don't do a critical section, and then add the assertions that you suggested. From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 17:02:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8687E503 for ; Sun, 20 Jan 2013 17:02:13 +0000 (UTC) (envelope-from prvs=173216f972=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 26C7DB8D for ; Sun, 20 Jan 2013 17:02:12 +0000 (UTC) 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 md50001777366.msg for ; Sun, 20 Jan 2013 17:02:05 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 20 Jan 2013 17:02:05 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=173216f972=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@FreeBSD.org Message-ID: <4F089B368D7F446B85A57D52A6EBF712@multiplay.co.uk> From: "Steven Hartland" To: "matt" , References: <50FBBB60.5070702@gmail.com> Subject: Re: ZFS Trim on mps? Date: Sun, 20 Jan 2013 17:02:13 -0000 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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 17:02:13 -0000 ----- Original Message ----- From: "matt" To: Sent: Sunday, January 20, 2013 9:39 AM Subject: ZFS Trim on mps? > Should I be getting trim with ZFS on an mps device? > > Disks are SATA ssd (830s), only "unsupported" is being reported. > Do I need to set the cam "da" delete method to something (unmap?), or is > ZFS trim only supported on ahci sata controllers? > > vfs.zfs.trim_disable: 0 > vfs.zfs.trim_txg_limit: 64 > kstat.zfs.misc.zio_trim.bytes: 0 > kstat.zfs.misc.zio_trim.success: 0 > kstat.zfs.misc.zio_trim.unsupported: 281 I've got a patch which TRIM support to cam/scsi_da on 8.3, not sure as yet how much work its going to be to port to HEAD but your welcome to try and test. We're done loads of testing on it and we are using it in production so am confident of its quality. LMK if you want the patch to test. 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 Jan 20 18:34:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 26942679; Sun, 20 Jan 2013 18:34:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1DAAEFF; Sun, 20 Jan 2013 18:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=pOgNRlkoJY8cTPQvjASdAqJMWt3J2wRxnxzJjfa5nGw=; b=JABuW+C9AtZZ8IY1gyfWik/lCXMslb2cO/RuQ+diGIjotJtIP9jq92ACZyk0c+/VoP0CVgA38XR6FKPs6rQAnwOt+4GDVlg12eYTJ6QcFVlvzRQc4/ZPtpTMYbiP1AR47k45aqHPA6JTw42N1p5GJWJ46eFIlqDoY0A0sN9hbpk=; Received: from lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net ([2001:470:1f0e:3ad::2]:11024) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Twzim-000OAF-7s; Sun, 20 Jan 2013 12:34:20 -0600 Date: Sun, 20 Jan 2013 12:34:17 -0600 (CST) From: Larry Rosenman To: Andriy Gapon Subject: Re: My panic in amd64/pmap In-Reply-To: Message-ID: References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.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-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 18:34:22 -0000 On Fri, 18 Jan 2013, Larry Rosenman wrote: > Never mind, it's in VirtualBox itself. The line is at ~~line 8020 in the > same file. I've patched it and am recompiling > VirtualBox. > > If I don't see the panic for a few days, I'll submit a PR. > I've submitted the PR, because for nehalem class or better cpu's it's probably needed, however, I can still panic FreeBSD9 or FreeBSD10 with running a zpool scrub, sometimes :(. I have vmcores and kernels from both VM's available. Latest core.txts: http://www.lerctr.org/~ler/zfs10-core.txt.4 http://www.lerctr.org/~ler/zfs9-core.txt.4 I can still give ssh access to both VM's as well as the host. I'd really like to get to the bottom of this..... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 19:00:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E4ECB2E; Sun, 20 Jan 2013 19:00:29 +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 43E93FDD; Sun, 20 Jan 2013 19:00:27 +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 VAA07884; Sun, 20 Jan 2013 21:00:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tx07u-0005ww-48; Sun, 20 Jan 2013 21:00:18 +0200 Message-ID: <50FC3EBF.6070803@FreeBSD.org> Date: Sun, 20 Jan 2013 21:00:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs , freebsd-geom@FreeBSD.org Subject: disk "flipped" - a known problem? X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 19:00:29 -0000 Today something unusual happened on one of my machines: kernel: (ada0:ahcich0:0:0:0): lost device kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00 kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00 kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted kernel: cam_periph_alloc: attempt to re-allocate valid device ada0 rejected flags 0x18 refcount 1 kernel: adaasync: Unable to attach to new device due to status 0x6 It looks like the disk disappeared from the bus and then re-appeared on the bus, but not to the OS. One of the partitions that the disk hosted was a swap partition and it seems to be the cause of some of the following consequences. The consequences: * ZFS properly noticed disappearance of the disk, but its diagnostic was a little bit misleading: pool: pond state: DEGRADED status: One or more devices has been removed by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: scrub repaired 0 in 8h55m with 0 errors on Sat Dec 22 12:06:30 2012 config: NAME STATE READ WRITE CKSUM pond DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 12725235722288301230 REMOVED 0 0 0 was /dev/gptid/fcf3558b-493b-11de-a8b9-001cc08221ff gptid/48782c6e-8fbd-11de-b3e1-00241d20d446 ONLINE 0 0 0 Yes, I agree that the disk got removed/lost, but disagree that "the administrator" did it. * geom_event thread started consuming 100% of CPU in g_wither_washer() * /dev/ada0 disappeared but camcontrol devlist still reported ada0: at scbus0 target 0 lun 0 (pass0,ada0) * As seen in the system messages, CAM layer refused to re-attach the disk * gpart command would just crash So, I can explain the behavior of the geom_event thread - apparently swapgeom_orphan doesn't do anything that is really meaningful to GEOM and so g_wither_washer is stuck waiting until the swap consumer goes way (drops its access bits). (Another sad thing about this state is that I couldn't swapoff the device, because there was no device entry.) I am not sure if the "attempt to re-allocate valid device" failure was caused by this, but it could be, if something in CAM layer was waiting for GEOM layer to be done with the disk. It would be nice if the swap code properly supported disappearance of the underlying disks. Especially in this case where the swap was actually never used / touched at all (few hours after reboot and completely idle system). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Jan 20 21:19:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76001EC8 for ; Sun, 20 Jan 2013 21:19:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id D9E7B62D for ; Sun, 20 Jan 2013 21:19:26 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id wz17so2929539pbc.6 for ; Sun, 20 Jan 2013 13:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7JCYJg0k6EUEnWZ0HBruChHfXX0eOepyvXQgstaJhGE=; b=RB1uGJxpWTMROUxNrRKtu+0+gB3a5fs1uFbIPMjduHy5Y4g9S8mFDaxQ65khfmeDWu /PwGksQgAga7ybYSRE2SZpg7Yt7lxPt9KKMOdFXSUrlbM9ESgb6JTXPYP8DvfobydtAC Vt6575yKWeh/sPx2yein6CR8OmARMHojbN+403wnOTpGyBmD/cjmk6BlH197a0Xz29Fb 8t80kEaRscTGrvV5VCOiDpR+eGnnYfMmax+8vihETIjxnzp3BnwglBhxim3KzC/IS5Bs XXsqGMS2PBMJzC5Q/EsVkhaeAaRhByEw8JI/r+Sy0qJPRsOqg/AL4T/AatbkPBo9q8bS Ab2w== MIME-Version: 1.0 X-Received: by 10.68.189.163 with SMTP id gj3mr24514152pbc.110.1358716766209; Sun, 20 Jan 2013 13:19:26 -0800 (PST) Received: by 10.67.2.65 with HTTP; Sun, 20 Jan 2013 13:19:26 -0800 (PST) In-Reply-To: <50F87819.3060605@mu.org> References: <201301171622.09624.jhb@freebsd.org> <50F87819.3060605@mu.org> Date: Sun, 20 Jan 2013 13:19:26 -0800 Message-ID: Subject: Re: [PATCH] Adjust 'ps H' to include kthread names by default From: Kevin Oberman To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 20 Jan 2013 21:19:27 -0000 On Thu, Jan 17, 2013 at 2:15 PM, Alfred Perlstein wrote: > On 1/17/13 1:22 PM, John Baldwin wrote: >> >> Running 'ps axH' on a current system results in a lot of kthreads with not >> very useful names (unless you add -c): >> >> PID TT STAT TIME COMMAND >> 0 ?? DLs 1:09.52 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 0:03.82 [kernel] >> 0 ?? DLs 1:15.14 [kernel] >> 0 ?? DLs 0:00.00 [kernel] >> 0 ?? DLs 39:24.55 [kernel] >> 0 ?? DLs 0:00.04 [kernel] >> >> This patch changes this to: >> >> PID TT STAT TIME COMMAND >> 0 ?? DLs 1:09.53 [kernel/swapper] >> 0 ?? DLs 0:00.00 [kernel/firmware tas] >> 0 ?? DLs 0:00.00 [kernel/ffs_trim tas] >> 0 ?? DLs 0:00.00 [kernel/acpi_task_0] >> 0 ?? DLs 0:00.00 [kernel/acpi_task_1] >> 0 ?? DLs 0:00.00 [kernel/acpi_task_2] >> 0 ?? DLs 0:00.00 [kernel/aiod_bio tas] >> 0 ?? DLs 0:03.82 [kernel/thread taskq] >> 0 ?? DLs 1:15.19 [kernel/nvidia taskq] >> 0 ?? DLs 0:00.00 [kernel/kqueue taskq] >> 0 ?? DLs 39:26.82 [kernel/em0 taskq] >> 0 ?? DLs 0:00.04 [kernel/mca taskq] > > Nice! Looks good. Thank you so much, John! This has been annoying me for years. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 00:21:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F10B57DE; Mon, 21 Jan 2013 00:21:28 +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 B9C50D7B; Mon, 21 Jan 2013 00:21:28 +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 r0L0LLQk088366; Sun, 20 Jan 2013 19:21:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0L0LLqg088286; Mon, 21 Jan 2013 00:21:21 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Jan 2013 00:21:21 GMT Message-Id: <201301210021.r0L0LLqg088286@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 00:21:29 -0000 TB --- 2013-01-20 22:23:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-20 22:23:20 - 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 --- 2013-01-20 22:23:20 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-20 22:23:20 - cleaning the object tree TB --- 2013-01-20 22:25:09 - /usr/local/bin/svn stat /src TB --- 2013-01-20 22:25:13 - At svn revision 245696 TB --- 2013-01-20 22:25:14 - building world TB --- 2013-01-20 22:25:14 - CROSS_BUILD_TESTING=YES TB --- 2013-01-20 22:25:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-20 22:25:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-20 22:25:14 - SRCCONF=/dev/null TB --- 2013-01-20 22:25:14 - TARGET=ia64 TB --- 2013-01-20 22:25:14 - TARGET_ARCH=ia64 TB --- 2013-01-20 22:25:14 - TZ=UTC TB --- 2013-01-20 22:25:14 - __MAKE_CONF=/dev/null TB --- 2013-01-20 22:25:14 - cd /src TB --- 2013-01-20 22:25:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 20 22:25:18 UTC 2013 >>> 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 Mon Jan 21 00:00:51 UTC 2013 TB --- 2013-01-21 00:00:51 - generating LINT kernel config TB --- 2013-01-21 00:00:51 - cd /src/sys/ia64/conf TB --- 2013-01-21 00:00:51 - /usr/bin/make -B LINT TB --- 2013-01-21 00:00:51 - cd /src/sys/ia64/conf TB --- 2013-01-21 00:00:51 - /usr/sbin/config -m LINT TB --- 2013-01-21 00:00:51 - building LINT kernel TB --- 2013-01-21 00:00:51 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 00:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 00:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 00:00:51 - SRCCONF=/dev/null TB --- 2013-01-21 00:00:51 - TARGET=ia64 TB --- 2013-01-21 00:00:51 - TARGET_ARCH=ia64 TB --- 2013-01-21 00:00:51 - TZ=UTC TB --- 2013-01-21 00:00:51 - __MAKE_CONF=/dev/null TB --- 2013-01-21 00:00:51 - cd /src TB --- 2013-01-21 00:00:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 21 00:00:51 UTC 2013 >>> 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 [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-21 00:21:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-21 00:21:21 - ERROR: failed to build LINT kernel TB --- 2013-01-21 00:21:21 - 5408.87 user 1223.12 system 7080.74 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 08:14:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0346A3CE; Mon, 21 Jan 2013 08:14:58 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id AA8191ED; Mon, 21 Jan 2013 08:14:57 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TxCWn-000ABP-0u ; Mon, 21 Jan 2013 10:14:49 +0200 Date: Mon, 21 Jan 2013 10:14:49 +0200 From: Vitalij Satanivskij To: Jaakko Heinonen Subject: Re: panic after r244584 Message-ID: <20130121081448.GA39070@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net, Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 08:14:58 -0000 Jaakko Heinonen wrote: JH> On 2013-01-18, Alexander Motin wrote: JH> > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are JH> > impossible there, as previous name components are unique. Special JH> > characters haven't yet seen, but I think theoretically possible. JH> JH> I see two possible solutions for the problem. JH> JH> 1) Replace non-printable, space and '/' characters for example with '_'. JH> '/' should be replaced anyway. JH> JH> 2) Apply the patches in JH> http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html JH> to allow spaces again. I haven't committed the patches because I JH> think that there isn't full consensus that it's right thing to do and JH> also I personally prefer not to have spaces in device names. After patch was applied, problem is gone away. da0 at mps0 bus 0 scbus7 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) ses1: da0,pass7: Element descriptor: 'Slot 08' ses1: da0,pass7: SAS Device Slot Element: 1 Phys at Slot 7 ses1: phy 0: SATA device ses1: phy 0: parent 5003048000baa87f addr 5003048000baa853 JH> JH> -- JH> Jaakko JH> _______________________________________________ JH> freebsd-current@freebsd.org mailing list JH> http://lists.freebsd.org/mailman/listinfo/freebsd-current JH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 09:54:59 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA844622; Mon, 21 Jan 2013 09:54:59 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0743CB81; Mon, 21 Jan 2013 09:54:58 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0L9svRW099017; Mon, 21 Jan 2013 10:54:57 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0L9sv57099016; Mon, 21 Jan 2013 10:54:57 +0100 (CET) (envelope-from marius) Date: Mon, 21 Jan 2013 10:54:57 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130121095457.GL85306@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F30CAB.3000001@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 09:54:59 -0000 On Sun, Jan 13, 2013 at 09:36:11PM +0200, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: > > On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: > >> On 06.01.2013 17:23, Marius Strobl wrote: > >>> I'm not really sure what to do about that. Earlier you already said > >>> that sched_bind(9) also isn't an option in case if td_critnest > 1. > >>> To be honest, I don't really unerstand why using a spin lock in the > >>> timecounter path makes sparc64 the only problematic architecture > >>> for your changes. The x86 i8254_get_timecount() also uses a spin lock > >>> so it should be in the same boat. > >> > >> The problem is not in using spinlock, but in waiting for other CPU while > >> spinlock is held. Other CPU may also hold spinlock and wait for > >> something, causing deadlock. i8254 code uses spinlock just to atomically > >> access hardware registers, so it causes no problems. > > > > Okay, but wouldn't that be a general problem then? Pretty much > > anything triggering an IPI holds smp_ipi_mtx while doing so and > > the lower level IPI stuff waits for other CPU(s), including on > > x86. > > The problem is general. But now it works because single smp_ipi_mtx is > used in all cases where IPI result is waited. As soon as spinning > happens with interrupts still enabled, there is no deadlocks. But > problem reappears if any different lock is used, or locks are nested. I'm having a hard time getting an alternate time counter device to work. The crystal required for the counters in the south bridge just doesn't seem to be mounted any where near it (I've not looked at the bottom of the PCB though). While the time counter part of the on- board bge(4) driven chips basically work, they don't seem to like concurrent accesses caused by the rest of bge(4). I.e. although the counter is just read, sooner or later this causes a fatal bus error. I haven't tried serializing accesses to the chip, but getting to such a complexity for just reading a non-indexed register at least doesn't feel good ... However, AFAICT the scenario you describe can't happen. On sparc64, spinlock_enter() only raises the processor interrupt level, which doesn't block the direct cross traps I've implemented remote reading of (S)TICK as (which also means that the actions such traps may perform are very limitted and must occur in interrupt context, but which are sufficient for this purpose and in turn makes them very fast). I.e. although the AP holds smp_ipi_mtx or any amount of nested spin locks, this will not deadlock in case the BSP also holds any spin lock when reading (S)TICK from it. Marius From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 10:23:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C58AFC30; Mon, 21 Jan 2013 10:23:08 +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 9CCC7DBA; Mon, 21 Jan 2013 10:23:08 +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 r0LAN7pM046189; Mon, 21 Jan 2013 05:23:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0LAN7hA046185; Mon, 21 Jan 2013 10:23:07 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Jan 2013 10:23:07 GMT Message-Id: <201301211023.r0LAN7hA046185@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 10:23:08 -0000 TB --- 2013-01-21 08:24:09 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-21 08:24: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 --- 2013-01-21 08:24:09 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-21 08:24:09 - cleaning the object tree TB --- 2013-01-21 08:25:27 - /usr/local/bin/svn stat /src TB --- 2013-01-21 08:25:37 - At svn revision 245708 TB --- 2013-01-21 08:25:38 - building world TB --- 2013-01-21 08:25:38 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 08:25:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 08:25:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 08:25:38 - SRCCONF=/dev/null TB --- 2013-01-21 08:25:38 - TARGET=ia64 TB --- 2013-01-21 08:25:38 - TARGET_ARCH=ia64 TB --- 2013-01-21 08:25:38 - TZ=UTC TB --- 2013-01-21 08:25:38 - __MAKE_CONF=/dev/null TB --- 2013-01-21 08:25:38 - cd /src TB --- 2013-01-21 08:25:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 21 08:25:43 UTC 2013 >>> 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 Mon Jan 21 10:02:31 UTC 2013 TB --- 2013-01-21 10:02:31 - generating LINT kernel config TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf TB --- 2013-01-21 10:02:31 - /usr/bin/make -B LINT TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf TB --- 2013-01-21 10:02:31 - /usr/sbin/config -m LINT TB --- 2013-01-21 10:02:31 - building LINT kernel TB --- 2013-01-21 10:02:31 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 10:02:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 10:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 10:02:31 - SRCCONF=/dev/null TB --- 2013-01-21 10:02:31 - TARGET=ia64 TB --- 2013-01-21 10:02:31 - TARGET_ARCH=ia64 TB --- 2013-01-21 10:02:31 - TZ=UTC TB --- 2013-01-21 10:02:31 - __MAKE_CONF=/dev/null TB --- 2013-01-21 10:02:31 - cd /src TB --- 2013-01-21 10:02:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 21 10:02:31 UTC 2013 >>> 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 [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-21 10:23:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-21 10:23:07 - ERROR: failed to build LINT kernel TB --- 2013-01-21 10:23:07 - 5391.37 user 1213.96 system 7137.96 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 14:46:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79387D96; Mon, 21 Jan 2013 14:46:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by mx1.freebsd.org (Postfix) with ESMTP id 3196C714; Mon, 21 Jan 2013 14:46:52 +0000 (UTC) Received: from [78.35.171.46] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TxIcp-00047V-8m; Mon, 21 Jan 2013 15:45:27 +0100 Date: Mon, 21 Jan 2013 15:44:50 +0100 From: Fabian Keil To: Andriy Gapon Subject: Re: disk "flipped" - a known problem? Message-ID: <20130121154450.60f457d1@fabiankeil.de> In-Reply-To: <50FC3EBF.6070803@FreeBSD.org> References: <50FC3EBF.6070803@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/t7ntFaXohqG3FgxzzyKTQc7"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs , freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 14:46:52 -0000 --Sig_/t7ntFaXohqG3FgxzzyKTQc7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > Today something unusual happened on one of my machines: > kernel: (ada0:ahcich0:0:0:0): lost device > kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00= 00 00 > kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout > kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted > kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00= 00 00 > kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout > kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted > kernel: cam_periph_alloc: attempt to re-allocate valid device ada0 reject= ed > flags 0x18 refcount 1 > kernel: adaasync: Unable to attach to new device due to status 0x6 I believe I saw something similar when trying to forcefully end the cam lockups reported in: http://lists.freebsd.org/pipermail/freebsd-current/2012-October/037413.html Detaching the disc drive caused /dev/cd0 to disappear as expected, but reinserting the drive didn't bring cd0 back. > It looks like the disk disappeared from the bus and then re-appeared on t= he bus, > but not to the OS. >=20 > One of the partitions that the disk hosted was a swap partition and it se= ems to > be the cause of some of the following consequences. >=20 > The consequences: [...] > * geom_event thread started consuming 100% of CPU in g_wither_washer() This sounds familiar as well: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D171865 Fabian --Sig_/t7ntFaXohqG3FgxzzyKTQc7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD9VGUACgkQBYqIVf93VJ0RpQCfUBrj2QYbgBfT710Iy1tTmGWO bUYAmwQoYLnfhRfr2pCN7o5FrQz9agGz =Ex10 -----END PGP SIGNATURE----- --Sig_/t7ntFaXohqG3FgxzzyKTQc7-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 15:50:02 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD6B0E01; Mon, 21 Jan 2013 15:50:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB96AA2; Mon, 21 Jan 2013 15:50:02 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id DA88F216895; Mon, 21 Jan 2013 17:44:01 +0200 (EET) Date: Mon, 21 Jan 2013 17:44:01 +0200 From: Jaakko Heinonen To: Alexander Motin Subject: Re: panic after r244584 Message-ID: <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Justin T. Gibbs" , satan@ukr.net, Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 15:50:02 -0000 On 2013-01-19, Jaakko Heinonen wrote: > On 2013-01-18, Alexander Motin wrote: > > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are > > impossible there, as previous name components are unique. Special > > characters haven't yet seen, but I think theoretically possible. > > I see two possible solutions for the problem. > > 1) Replace non-printable, space and '/' characters for example with '_'. > '/' should be replaced anyway. > > 2) Apply the patches in > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html > to allow spaces again. I haven't committed the patches because I > think that there isn't full consensus that it's right thing to do and > also I personally prefer not to have spaces in device names. Here's a patch to implement 1: http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 16:35:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8348BAA0 for ; Mon, 21 Jan 2013 16:35:50 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 32996DE0 for ; Mon, 21 Jan 2013 16:35:49 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M2rdY-1T62jr0tWg-00se6q for ; Mon, 21 Jan 2013 17:35:49 +0100 Received: (qmail invoked by alias); 21 Jan 2013 16:35:49 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp028) with SMTP; 21 Jan 2013 17:35:49 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+WhogqSGGWbji/QPn9uri6OOYM2egaGhKsU4WzjT C4kEbaFwuCAV08 From: Christian Gusenbauer To: freebsd-current@freebsd.org Subject: Re: disk "flipped" - a known problem? Date: Mon, 21 Jan 2013 17:37:18 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <50FC3EBF.6070803@FreeBSD.org> In-Reply-To: <50FC3EBF.6070803@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301211737.19235.c47g@gmx.at> X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 16:35:50 -0000 Hi! On Sunday 20 January 2013 20:00:15 Andriy Gapon wrote: > Today something unusual happened on one of my machines: > kernel: (ada0:ahcich0:0:0:0): lost device > kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 > 00 00 kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout > kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted > kernel: (aprobe1:ahcich0:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 > 00 00 kernel: (aprobe1:ahcich0:0:15:0): CAM status: Command timeout > kernel: (aprobe1:ahcich0:0:15:0): Error 5, Retries exhausted > kernel: cam_periph_alloc: attempt to re-allocate valid device ada0 rejected > flags 0x18 refcount 1 > kernel: adaasync: Unable to attach to new device due to status 0x6 > > It looks like the disk disappeared from the bus and then re-appeared on the > bus, but not to the OS. > > One of the partitions that the disk hosted was a swap partition and it > seems to be the cause of some of the following consequences. > > The consequences: > > * ZFS properly noticed disappearance of the disk, but its diagnostic was a > little bit misleading: > > pool: pond > state: DEGRADED > status: One or more devices has been removed by the administrator. > Sufficient replicas exist for the pool to continue functioning in a > degraded state. > action: Online the device using 'zpool online' or replace the device with > 'zpool replace'. > scan: scrub repaired 0 in 8h55m with 0 errors on Sat Dec 22 12:06:30 2012 > config: > > NAME STATE READ > WRITE CKSUM pond DEGRADED 0 > 0 0 mirror-0 DEGRADED 0 > 0 0 12725235722288301230 REMOVED 0 0 > 0 was /dev/gptid/fcf3558b-493b-11de-a8b9-001cc08221ff > gptid/48782c6e-8fbd-11de-b3e1-00241d20d446 ONLINE 0 > 0 0 > > Yes, I agree that the disk got removed/lost, but disagree that "the > administrator" did it. > > * geom_event thread started consuming 100% of CPU in g_wither_washer() > > * /dev/ada0 disappeared but camcontrol devlist still reported ada0: > at scbus0 target 0 lun 0 (pass0,ada0) > > * As seen in the system messages, CAM layer refused to re-attach the disk > > * gpart command would just crash > > > So, I can explain the behavior of the geom_event thread - apparently > swapgeom_orphan doesn't do anything that is really meaningful to GEOM and > so g_wither_washer is stuck waiting until the swap consumer goes way > (drops its access bits). > > (Another sad thing about this state is that I couldn't swapoff the device, > because there was no device entry.) > > I am not sure if the "attempt to re-allocate valid device" failure was > caused by this, but it could be, if something in CAM layer was waiting for > GEOM layer to be done with the disk. > > It would be nice if the swap code properly supported disappearance of the > underlying disks. Especially in this case where the swap was actually > never used / touched at all (few hours after reboot and completely idle > system). I don't know if it's related, but my new 2 TB WD green harddisk vanished three times during the last couple of weeks, too, Some guys over there at hackers@ told me that that might be due to bad blocks on the disk, but unfortunately (or luckily?) neither of the smart tests did find any errors :-(. So I wonder if there's a hardware or software problem. That happened on 9.1 stable when I was copying data from/to that harddisk (UFS). Ciao, Christian. From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 17:31:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF100C32; Mon, 21 Jan 2013 17:31:23 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8F7101; Mon, 21 Jan 2013 17:31:23 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TxLDO-0005Kz-42 ; Mon, 21 Jan 2013 19:31:22 +0200 Date: Mon, 21 Jan 2013 19:31:22 +0200 From: Vitalij Satanivskij To: Jaakko Heinonen Subject: Re: panic after r244584 Message-ID: <20130121173122.GA20466@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net, Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 17:31:24 -0000 Jaakko Heinonen wrote: JH> On 2013-01-19, Jaakko Heinonen wrote: JH> > On 2013-01-18, Alexander Motin wrote: JH> > > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are JH> > > impossible there, as previous name components are unique. Special JH> > > characters haven't yet seen, but I think theoretically possible. JH> > JH> > I see two possible solutions for the problem. JH> > JH> > 1) Replace non-printable, space and '/' characters for example with '_'. JH> > '/' should be replaced anyway. JH> > JH> > 2) Apply the patches in JH> > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html JH> > to allow spaces again. I haven't committed the patches because I JH> > think that there isn't full consensus that it's right thing to do and JH> > also I personally prefer not to have spaces in device names. JH> JH> Here's a patch to implement 1: JH> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff Ok that patch work's too. ses1: da0,pass5,probe8: Element descriptor: 'Slot 08' ses1: da0,pass5,probe8: SAS Device Slot Element: 1 Phys at Slot 7 ses1: phy 0: SATA device ses1: phy 0: parent 5003048000baa87f addr 5003048000baa853 da0 at mps0 bus 0 scbus7 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 19:49:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0709EDC3; Mon, 21 Jan 2013 19:49:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC949BD; Mon, 21 Jan 2013 19:49:23 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id d42so2645658qca.15 for ; Mon, 21 Jan 2013 11:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wjdKlrX0qNEgX3U7dMQWSkIzkEW1kMY8ERt6D0XyWtA=; b=AamXnvB5Jfj30ElI43JlgPkr7nLmfQ7/+z53b9WXj+BlmmgVKvW6LoZTpolUKvaSuq L+xPnVYymwcbMHzr0JoBiRJMlsBZBTkstX/unNXtAFwsZGEKkd9d/lS8sOBUO2/Fby3I ZAEpK7qcBeoeUk1lElUK199V0EfeMmluhk3x5dFxvT4Fblb0FpsGF+4k0URl/T0waZuP AVaqXqylEZUfYIeQ7cewAP2lpg8DUDjfmsXUnwCHwz8DZ6syJsKtBC0UeCzortdYIFju dKNY3As1qKsiDSJybbGh0+s+PqykgytgY73Xc/UdHLQ44ozSGUUkbb9/yma1BA+6Vv0z 8IzQ== MIME-Version: 1.0 X-Received: by 10.49.130.167 with SMTP id of7mr23776256qeb.22.1358797757146; Mon, 21 Jan 2013 11:49:17 -0800 (PST) Received: by 10.229.78.96 with HTTP; Mon, 21 Jan 2013 11:49:16 -0800 (PST) In-Reply-To: <201301211023.r0LAN7hA046185@freebsd-current.sentex.ca> References: <201301211023.r0LAN7hA046185@freebsd-current.sentex.ca> Date: Mon, 21 Jan 2013 22:49:16 +0300 Message-ID: Subject: Re: [head tinderbox] failure on ia64/ia64 From: Sergey Kandaurov To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 19:49:24 -0000 On 21 January 2013 14:23, FreeBSD Tinderbox wrote: > TB --- 2013-01-21 08:24:09 - tinderbox 2.10 running on freebsd-current.sentex.ca > TB --- 2013-01-21 08:24: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 --- 2013-01-21 08:24:09 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2013-01-21 08:24:09 - cleaning the object tree > TB --- 2013-01-21 08:25:27 - /usr/local/bin/svn stat /src > TB --- 2013-01-21 08:25:37 - At svn revision 245708 > TB --- 2013-01-21 08:25:38 - building world > TB --- 2013-01-21 08:25:38 - CROSS_BUILD_TESTING=YES > TB --- 2013-01-21 08:25:38 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-01-21 08:25:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-01-21 08:25:38 - SRCCONF=/dev/null > TB --- 2013-01-21 08:25:38 - TARGET=ia64 > TB --- 2013-01-21 08:25:38 - TARGET_ARCH=ia64 > TB --- 2013-01-21 08:25:38 - TZ=UTC > TB --- 2013-01-21 08:25:38 - __MAKE_CONF=/dev/null > TB --- 2013-01-21 08:25:38 - cd /src > TB --- 2013-01-21 08:25:38 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Mon Jan 21 08:25:43 UTC 2013 >>>> 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 Mon Jan 21 10:02:31 UTC 2013 > TB --- 2013-01-21 10:02:31 - generating LINT kernel config > TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf > TB --- 2013-01-21 10:02:31 - /usr/bin/make -B LINT > TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf > TB --- 2013-01-21 10:02:31 - /usr/sbin/config -m LINT > TB --- 2013-01-21 10:02:31 - building LINT kernel > TB --- 2013-01-21 10:02:31 - CROSS_BUILD_TESTING=YES > TB --- 2013-01-21 10:02:31 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-01-21 10:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-01-21 10:02:31 - SRCCONF=/dev/null > TB --- 2013-01-21 10:02:31 - TARGET=ia64 > TB --- 2013-01-21 10:02:31 - TARGET_ARCH=ia64 > TB --- 2013-01-21 10:02:31 - TZ=UTC > TB --- 2013-01-21 10:02:31 - __MAKE_CONF=/dev/null > TB --- 2013-01-21 10:02:31 - cd /src > TB --- 2013-01-21 10:02:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>>> Kernel build for LINT started on Mon Jan 21 10:02:31 UTC 2013 >>>> 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 > [...] > acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' > dbcmds.o:(.sbss+0x0): first defined here > acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' > dbcmds.o:(.sbss+0x0): first defined here > acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' > dbcmds.o:(.sbss+0x0): first defined here > acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' > dbcmds.o:(.sbss+0x0): first defined here > *** [kernel] Error code 1 > > Stop in /obj/ia64.ia64/src/sys/LINT. > *** [buildkernel] Error code 1 > The (first) patch should fix the build. So that it is only declared when included in utglobal.c (and extern elsewhere). DEFINE_ACPI_GLOBALS defined there expects ACPI_EXTERN to properly handle global objects defined with ACPI_INIT_GLOBAL. ### Index: contrib/dev/acpica/include/acglobal.h =================================================================== --- contrib/dev/acpica/include/acglobal.h (revision 245745) +++ contrib/dev/acpica/include/acglobal.h (working copy) @@ -420,7 +420,7 @@ #ifdef ACPI_DISASSEMBLER -BOOLEAN ACPI_INIT_GLOBAL (AcpiGbl_IgnoreNoopOperator, FALSE); +ACPI_EXTERN BOOLEAN ACPI_INIT_GLOBAL (AcpiGbl_IgnoreNoopOperator, FALSE); ACPI_EXTERN BOOLEAN AcpiGbl_DbOpt_disasm; ACPI_EXTERN BOOLEAN AcpiGbl_DbOpt_verbose; ### The other way is to declare AcpiGbl_IgnoreNoopOperator as extern below. This seems to be used for other ACPI_INIT_GLOBAL's as well, see acglobal.h But this doesn't work because it is not defined under DEFINE_ACPI_GLOBALS. ### Index: contrib/dev/acpica/include/acpixf.h =================================================================== --- contrib/dev/acpica/include/acpixf.h (revision 245745) +++ contrib/dev/acpica/include/acpixf.h (working copy) @@ -79,6 +79,7 @@ extern UINT8 AcpiGbl_CopyDsdtLocally; extern UINT8 AcpiGbl_TruncateIoAddresses; extern UINT8 AcpiGbl_DisableAutoRepair; +extern BOOLEAN AcpiGbl_IgnoreNoopOperator; /* ### > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-01-21 10:23:07 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-01-21 10:23:07 - ERROR: failed to build LINT kernel > TB --- 2013-01-21 10:23:07 - 5391.37 user 1213.96 system 7137.96 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 20:22:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 950C56F5; Mon, 21 Jan 2013 20:22: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 68DB6B05; Mon, 21 Jan 2013 20:22:59 +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 r0LKMwr3012621; Mon, 21 Jan 2013 15:22:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0LKMwJI012550; Mon, 21 Jan 2013 20:22:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Jan 2013 20:22:58 GMT Message-Id: <201301212022.r0LKMwJI012550@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 20:22:59 -0000 TB --- 2013-01-21 18:24:06 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-21 18:24:06 - 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 --- 2013-01-21 18:24:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-21 18:24:06 - cleaning the object tree TB --- 2013-01-21 18:26:05 - /usr/local/bin/svn stat /src TB --- 2013-01-21 18:26:09 - At svn revision 245742 TB --- 2013-01-21 18:26:10 - building world TB --- 2013-01-21 18:26:10 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 18:26:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 18:26:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 18:26:10 - SRCCONF=/dev/null TB --- 2013-01-21 18:26:10 - TARGET=ia64 TB --- 2013-01-21 18:26:10 - TARGET_ARCH=ia64 TB --- 2013-01-21 18:26:10 - TZ=UTC TB --- 2013-01-21 18:26:10 - __MAKE_CONF=/dev/null TB --- 2013-01-21 18:26:10 - cd /src TB --- 2013-01-21 18:26:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 21 18:26:15 UTC 2013 >>> 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 Mon Jan 21 20:02:02 UTC 2013 TB --- 2013-01-21 20:02:02 - generating LINT kernel config TB --- 2013-01-21 20:02:02 - cd /src/sys/ia64/conf TB --- 2013-01-21 20:02:02 - /usr/bin/make -B LINT TB --- 2013-01-21 20:02:02 - cd /src/sys/ia64/conf TB --- 2013-01-21 20:02:02 - /usr/sbin/config -m LINT TB --- 2013-01-21 20:02:02 - building LINT kernel TB --- 2013-01-21 20:02:02 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 20:02:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 20:02:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 20:02:02 - SRCCONF=/dev/null TB --- 2013-01-21 20:02:02 - TARGET=ia64 TB --- 2013-01-21 20:02:02 - TARGET_ARCH=ia64 TB --- 2013-01-21 20:02:02 - TZ=UTC TB --- 2013-01-21 20:02:02 - __MAKE_CONF=/dev/null TB --- 2013-01-21 20:02:02 - cd /src TB --- 2013-01-21 20:02:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 21 20:02:02 UTC 2013 >>> 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 [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-21 20:22:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-21 20:22:58 - ERROR: failed to build LINT kernel TB --- 2013-01-21 20:22:58 - 5462.62 user 1225.88 system 7131.85 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 20:26:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A11B384D for ; Mon, 21 Jan 2013 20:26:22 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 78FA8B31 for ; Mon, 21 Jan 2013 20:26:22 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r0LKQLwA060972 for ; Mon, 21 Jan 2013 12:26:21 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <50FDA46D.6080105@rawbw.com> Date: Mon, 21 Jan 2013 12:26:21 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: [PATCH] Variable-size ioctl data handling Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 20:26:22 -0000 Hi, Could anybody please review and check in the patch patch-ioctl-var-size.txt from this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=175425 ? This patch introduces the generic way to pass variable size ioctl argument using the structure like this struct my_struct {int len; ...any fields...}. Thank you, Yuri From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 20:58:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49934E4B for ; Mon, 21 Jan 2013 20:58:21 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id EF559D23 for ; Mon, 21 Jan 2013 20:58:17 +0000 (UTC) Received: from localhost (unknown [86.188.145.194]) by mail.dawidek.net (Postfix) with ESMTPSA id 6DD7A754; Mon, 21 Jan 2013 21:55:43 +0100 (CET) Date: Mon, 21 Jan 2013 21:58:52 +0100 From: Pawel Jakub Dawidek To: Alexander Nedotsukov Subject: Re: ZFS + usb in trouble? Message-ID: <20130121205851.GB1341@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" 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 , hps@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 20:58:21 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 19, 2013 at 11:26:39PM +0900, Alexander Nedotsukov wrote: > Let's use some space out of it. >=20 > #dd if=3D/dev/zero of=3D/tank/foo > ^C250939+0 records in > 250938+0 records out > 128480256 bytes transferred in 30.402453 secs (4225983 bytes/sec) >=20 > Oops... >=20 > #zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 5K in 0h0m with 0 errors on Sat Jan 19 23:11:20 20= 13 > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da1 ONLINE 0 0 1 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 1 This seems like umass/usb issue (hps@ CCed). Can you also try GELI with data integrity verification? # geli onetime -a hmac/sha1 -s 4096 /dev/da0 It will report some problems due to GEOM tasting, but ignore them and run: # dd if=3D/dev/random of=3D/dev/da0.eli bs=3D1m Once that done try to read the data back and look at the logs to see if any corruptions are reported. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD9rAsACgkQForvXbEpPzTLxACfQbLD/npGOnnORDu9RhBogjQx PlwAnRbW/Ov1DHG6298E1NRnik28i799 =l+he -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:06:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6416FFF; Mon, 21 Jan 2013 21:06:10 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0A1D92; Mon, 21 Jan 2013 21:06:10 +0000 (UTC) Received: from localhost (unknown [86.188.145.194]) by mail.dawidek.net (Postfix) with ESMTPSA id B9CF875A; Mon, 21 Jan 2013 22:03:36 +0100 (CET) Date: Mon, 21 Jan 2013 22:06:45 +0100 From: Pawel Jakub Dawidek To: mdf@FreeBSD.org Subject: Re: kmem_map auto-sizing and size dependencies Message-ID: <20130121210645.GC1341@garage.freebsd.pl> References: <50F96A67.9080203@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL" 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 , freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:06:10 -0000 --iFRdW5/EC4oqxDHL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote: > > Should it be set to a larger initial value based on min(physical,KVM) = space > > available? >=20 > It needs to be smaller than the physical space, [...] Or larger, as the address space can get fragmented and you might not be able to allocate memory even if you have physical pages available. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --iFRdW5/EC4oqxDHL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD9reUACgkQForvXbEpPzRQuACgmpMuaWnlzrwGLDg8via2mpRB H/MAn0osPB9G8vejrumWSQaYnHc8khDu =hBju -----END PGP SIGNATURE----- --iFRdW5/EC4oqxDHL-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:16:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B25D23EC; Mon, 21 Jan 2013 21:16:44 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0DEDF8; Mon, 21 Jan 2013 21:16:44 +0000 (UTC) Received: from localhost (unknown [86.188.145.194]) by mail.dawidek.net (Postfix) with ESMTPSA id A9997763; Mon, 21 Jan 2013 22:14:10 +0100 (CET) Date: Mon, 21 Jan 2013 22:17:19 +0100 From: Pawel Jakub Dawidek To: Alexander Nedotsukov Subject: Re: ZFS + usb in trouble? Message-ID: <20130121211718.GD1341@garage.freebsd.pl> References: <20130121205851.GB1341@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: <20130121205851.GB1341@garage.freebsd.pl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:16:44 -0000 --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I used wrong Hans' login, resending with the proper e-mail. On Mon, Jan 21, 2013 at 09:58:52PM +0100, Pawel Jakub Dawidek wrote: > On Sat, Jan 19, 2013 at 11:26:39PM +0900, Alexander Nedotsukov wrote: > > Let's use some space out of it. > >=20 > > #dd if=3D/dev/zero of=3D/tank/foo > > ^C250939+0 records in > > 250938+0 records out > > 128480256 bytes transferred in 30.402453 secs (4225983 bytes/sec) > >=20 > > Oops... > >=20 > > #zpool status > > pool: tank > > state: ONLINE > > status: One or more devices has experienced an unrecoverable error. An > > attempt was made to correct the error. Applications are unaffected. > > action: Determine if the device needs to be replaced, and clear the err= ors > > using 'zpool clear' or replace the device with 'zpool replace'. > > see: http://illumos.org/msg/ZFS-8000-9P > > scan: scrub repaired 5K in 0h0m with 0 errors on Sat Jan 19 23:11:20 = 2013 > > config: > >=20 > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > raidz1-0 ONLINE 0 0 0 > > da1 ONLINE 0 0 1 > > da2 ONLINE 0 0 0 > > da3 ONLINE 0 0 1 >=20 > This seems like umass/usb issue (hps@ CCed). Can you also try GELI with > data integrity verification? >=20 >=20 > # geli onetime -a hmac/sha1 -s 4096 /dev/da0 >=20 > It will report some problems due to GEOM tasting, but ignore them and run: >=20 > # dd if=3D/dev/random of=3D/dev/da0.eli bs=3D1m >=20 > Once that done try to read the data back and look at the logs to see if > any corruptions are reported. >=20 > --=20 > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD9sF4ACgkQForvXbEpPzTskwCgkiW9bFakIrBS7IDNVvjpTy1D 8AMAnRUQd29njTB83MTJdH7aXripsQ4I =5PBk -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:30:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 542227CF; Mon, 21 Jan 2013 21:30:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C1BDDEA3; Mon, 21 Jan 2013 21:30:27 +0000 (UTC) Message-ID: <50FDB321.6090403@FreeBSD.org> Date: Mon, 21 Jan 2013 16:29:05 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130116 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on ia64/ia64 References: <201301212022.r0LKMwJI012550@freebsd-current.sentex.ca> In-Reply-To: <201301212022.r0LKMwJI012550@freebsd-current.sentex.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:30:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-21 15:22:58 -0500, FreeBSD Tinderbox wrote: > TB --- 2013-01-21 18:24:06 - tinderbox 2.10 running on > freebsd-current.sentex.ca TB --- 2013-01-21 18:24:06 - 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 --- 2013-01-21 18:24:06 - starting HEAD tinderbox run for > ia64/ia64 TB --- 2013-01-21 18:24:06 - cleaning the object tree TB > --- 2013-01-21 18:26:05 - /usr/local/bin/svn stat /src TB --- > 2013-01-21 18:26:09 - At svn revision 245742 TB --- 2013-01-21 > 18:26:10 - building world TB --- 2013-01-21 18:26:10 - > CROSS_BUILD_TESTING=YES TB --- 2013-01-21 18:26:10 - > MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 18:26:10 - > PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 18:26:10 - > SRCCONF=/dev/null TB --- 2013-01-21 18:26:10 - TARGET=ia64 TB --- > 2013-01-21 18:26:10 - TARGET_ARCH=ia64 TB --- 2013-01-21 18:26:10 - > TZ=UTC TB --- 2013-01-21 18:26:10 - __MAKE_CONF=/dev/null TB --- > 2013-01-21 18:26:10 - cd /src TB --- 2013-01-21 18:26:10 - > /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) World build started on Mon Jan >>>> 21 18:26:15 UTC 2013 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 Mon Jan 21 >>>> 20:02:02 UTC 2013 > TB --- 2013-01-21 20:02:02 - generating LINT kernel config TB --- > 2013-01-21 20:02:02 - cd /src/sys/ia64/conf TB --- 2013-01-21 > 20:02:02 - /usr/bin/make -B LINT TB --- 2013-01-21 20:02:02 - cd > /src/sys/ia64/conf TB --- 2013-01-21 20:02:02 - /usr/sbin/config -m > LINT TB --- 2013-01-21 20:02:02 - building LINT kernel TB --- > 2013-01-21 20:02:02 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 > 20:02:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 20:02:02 - > PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 20:02:02 - > SRCCONF=/dev/null TB --- 2013-01-21 20:02:02 - TARGET=ia64 TB --- > 2013-01-21 20:02:02 - TARGET_ARCH=ia64 TB --- 2013-01-21 20:02:02 - > TZ=UTC TB --- 2013-01-21 20:02:02 - __MAKE_CONF=/dev/null TB --- > 2013-01-21 20:02:02 - cd /src TB --- 2013-01-21 20:02:02 - > /usr/bin/make -B buildkernel KERNCONF=LINT >>>> Kernel build for LINT started on Mon Jan 21 20:02:02 UTC >>>> 2013 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 > [...] acpi_powerres.o:(.sbss+0x0): multiple definition of > `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined > here acpi_resource.o:(.sbss+0x0): multiple definition of > `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined > here acpi_thermal.o:(.sbss+0x20): multiple definition of > `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined > here acpi_timer.o:(.sbss+0x28): multiple definition of > `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined > here *** [kernel] Error code 1 > > Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code > 1 > > Stop in /src. *** Error code 1 > > Stop in /src. TB --- 2013-01-21 20:22:58 - WARNING: /usr/bin/make > returned exit code 1 TB --- 2013-01-21 20:22:58 - ERROR: failed to > build LINT kernel TB --- 2013-01-21 20:22:58 - 5462.62 user 1225.88 > system 7131.85 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full It > should be fixed now (r245748, "make universe" tested). Sorry for the breakage, again. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ/bMgAAoJECXpabHZMqHOtbcH/jNd3nq5/nKaWXP4kdbmi1bj sVPeNi1+C3nYTAxfzIn1UzIlObiyg3u3b2xKuTp2/YNN/k3s9jhloWwzoTCS0YcR qVWGfJ+3zRsMQQ1gMMnzkoZdqnkoznMQNZvCt0Uti0lwk1mASLU7VKxGHsmnyqO8 hnZaa8XgwnZDiQW5ac6utpFpGvQyCQEBJIbsZ/yg2FXz8bHi9QOXRGJs22KiASZB RjQFmv7U4TpeRzQT11UsjopfIZ3RssI7g8pA5+iIbzjZ9nsGaf21itvJSiRfFqlg sFYRy00rm1rMdlgPc+ToTNTtzTc0M/2QULhhEkZjP0S8O/U+w69+qSdpkqcsrdA= =GyLm -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:36:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 444AF970; Mon, 21 Jan 2013 21:36:00 +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 9F00EEE0; Mon, 21 Jan 2013 21:35:59 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 368862908; Mon, 21 Jan 2013 22:35:51 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: ZFS + usb in trouble? Date: Mon, 21 Jan 2013 22:37:11 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <20130121211718.GD1341@garage.freebsd.pl> <201301212236.04250.hselasky@c2i.net> In-Reply-To: <201301212236.04250.hselasky@c2i.net> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Alexander Nedotsukov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:36:00 -0000 On Monday 21 January 2013 22:36:04 Hans Petter Selasky wrote: > On Monday 21 January 2013 22:17:19 Pawel Jakub Dawidek wrote: > > I used wrong Hans' login, resending with the proper e-mail. > > Hi, > > You should try to use some tools to write some random data and read it back > and see if the data is the same, at /dev/daX level. The USB wrapper for > SCSI is very simple and it passes commands directly from CAM to the > hardware. I would be surprised if data was corrupted at this stage. Please also check if your USB device suffers from the lack of SYNCHRONIZE CACHE. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:39:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8A9FAF8; Mon, 21 Jan 2013 21:39:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 51ECBF23; Mon, 21 Jan 2013 21:39:52 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 368930676; Mon, 21 Jan 2013 22:34:45 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: ZFS + usb in trouble? Date: Mon, 21 Jan 2013 22:36:04 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <20130121205851.GB1341@garage.freebsd.pl> <20130121211718.GD1341@garage.freebsd.pl> In-Reply-To: <20130121211718.GD1341@garage.freebsd.pl> X-Face: ?p&W)c( =?iso-8859-15?q?+80hU=3B=27=7B=2E=245K+zq=7BoC6y=7C=0A=09/D=27an*6mw?=>j'f:eBsex\Gi, Cc: Alexander Nedotsukov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:39:54 -0000 On Monday 21 January 2013 22:17:19 Pawel Jakub Dawidek wrote: > I used wrong Hans' login, resending with the proper e-mail. > Hi, You should try to use some tools to write some random data and read it back and see if the data is the same, at /dev/daX level. The USB wrapper for SCSI is very simple and it passes commands directly from CAM to the hardware. I would be surprised if data was corrupted at this stage. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 21 21:48:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C415C8A; Mon, 21 Jan 2013 21:48:44 +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 C0920F73; Mon, 21 Jan 2013 21:48:43 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 196287832; Mon, 21 Jan 2013 22:43:34 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: ZFS + usb in trouble? Date: Mon, 21 Jan 2013 22:44:53 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301212236.04250.hselasky@c2i.net> <201301212237.11092.hselasky@c2i.net> In-Reply-To: <201301212237.11092.hselasky@c2i.net> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Alexander Nedotsukov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jan 2013 21:48:44 -0000 On Monday 21 January 2013 22:37:11 Hans Petter Selasky wrote: > On Monday 21 January 2013 22:36:04 Hans Petter Selasky wrote: > > On Monday 21 January 2013 22:17:19 Pawel Jakub Dawidek wrote: > > > I used wrong Hans' login, resending with the proper e-mail. > > > > Hi, > > > > You should try to use some tools to write some random data and read it > > back and see if the data is the same, at /dev/daX level. The USB wrapper > > for SCSI is very simple and it passes commands directly from CAM to the > > hardware. I would be surprised if data was corrupted at this stage. > > Please also check if your USB device suffers from the lack of SYNCHRONIZE > CACHE. > Hi, Try this first: usbconfig -d X.Y add_quirk UQ_MSC_NO_SYNC_CACHE Re-plug device. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 06:13:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11C41987 for ; Tue, 22 Jan 2013 06:13:11 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADA4737 for ; Tue, 22 Jan 2013 06:13:10 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r0M6D7gH052322 for ; Tue, 22 Jan 2013 01:13:07 -0500 (EST) (envelope-from andy@neu.net) Date: Tue, 22 Jan 2013 01:13:07 -0500 (EST) From: AN To: freebsd-current@freebsd.org Subject: installworld fails In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.6 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 06:13:11 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan 22 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone seeing this? install -l s usr/src/sys /sys install: /sys/sys: Directory not empty *** [distrib-dirs] Error code 71 From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 06:24:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 209CED8 for ; Tue, 22 Jan 2013 06:24:13 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id EF0577A5 for ; Tue, 22 Jan 2013 06:24:12 +0000 (UTC) Received: from [192.168.168.12] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 2CA0C286E2; Mon, 21 Jan 2013 22:24:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: installworld fails From: Jason Evans In-Reply-To: Date: Mon, 21 Jan 2013 22:24:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <18A556A4-5B93-49B3-88B3-BD955394EA2A@freebsd.org> References: To: AN X-Mailer: Apple Mail (2.1499) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 06:24:13 -0000 On Jan 21, 2013, at 10:13 PM, AN wrote: > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan = 22 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL = amd64 >=20 > Is anyone seeing this? >=20 > install -l s usr/src/sys /sys > install: /sys/sys: Directory not empty > *** [distrib-dirs] Error code 71 Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to = installworld is an effective workaround. Jason= From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 13:11:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AED1F1FB for ; Tue, 22 Jan 2013 13:11:27 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by mx1.freebsd.org (Postfix) with ESMTP id 762192BB for ; Tue, 22 Jan 2013 13:11:27 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id ff1so4247123vbb.1 for ; Tue, 22 Jan 2013 05:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type:content-transfer-encoding; bh=dh1krEnY6KGGLwaIIwjsD2r3z+0WOi3zTS8CHcwG1oU=; b=La9nqujdbILx694Ip9h40nnccm7TmuY3M+QnyNMrOcpdEPERTCIF3wHeNFP7CelHq5 HshBBviBS3+nC+fM8RmKDmslvb0KTojWm4DcZif9w3WbxxrVe06qotJzPpFJvFhJq+iN W0YXKKoYweowv5mj5YTZPYDF/4HGtxHnscLALvkMprSm0tFYr40d+HSAQqeYrnF5PTNm Dyo0pKfuWqZVo5c9LXRiwFYj2IUpjrKwKe7ftSY3YACxUBn7+tGW7sEpp38D6zd0+Wfw J+6KXzlG+r0+Dpj3E9VmTQjQl1ywzyvXNEungkRKgs4moOqippGPznJk8pe97m5uIYPB KAbA== X-Received: by 10.220.219.73 with SMTP id ht9mr13812050vcb.47.1358859812751; Tue, 22 Jan 2013 05:03:32 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Tue, 22 Jan 2013 05:03:12 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 22 Jan 2013 14:03:12 +0100 X-Google-Sender-Auth: 5iS-j9du7s6uvqG5GCQtRekFlqY Message-ID: Subject: Adding more tools to be used by operator group members To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 13:11:27 -0000 Hi all, There are only 2 useable tools by "operator" group members: shutdown (and its child: poweroff, halt, etc=85) and mksnap_ffs. On my HAL-less laptop, I've put my user in the operator group that let me reboot/power-off it with shutdown. But I would to be able to suspend-resume it too (with zzz). Here is what I've did: for f in "/usr/sbin/acpiconf /usr/sbin/apm"; do chown :operator $f chmod 4550 $f done What about configuring this permission by default on FreeBSD ? And why /sbin/reboot isn't useable by operator too ? Are there somes security issue ? Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 13:49:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36DA4C71; Tue, 22 Jan 2013 13:49:19 +0000 (UTC) (envelope-from rysto32@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 C22E675C; Tue, 22 Jan 2013 13:49:18 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id uo13so2224533obb.41 for ; Tue, 22 Jan 2013 05:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oW62GpOS7HCS3rTiqiQ3dPA1RnIqqrgDtw/kc2fycgI=; b=JlhbcOGHXsmTLw2ob6/WRvcwlsNTuRA4s8B6Sxdu3Wnn2p9WAkvdn9qdsLZusPp50V wQEMDvzJHkTNT4q1X4heEJEbuqn7TDyTH889uOUkrts4t2z8lPWC6Dp2E5Azvkx/70VV BUdiIpvbv5bvaLa185g3blbpQBCdY1FLQPOQMOfAa7WPNk3dtwETItCsXc8DbhRzXkgb gYmvNYsnKOaLX8b/cZ3TnM2rbcm8CbW6rm79fnzXlWaANNJnl1FyA5P5SqaIOw12w5WZ BYpOqG+bJEC06TKUj7JVKhEQIuca4WtNLHyctVOR0RNdS4J2xrwlcZtoRhY3OTE8BaXc pSzg== MIME-Version: 1.0 X-Received: by 10.182.92.70 with SMTP id ck6mr16875458obb.46.1358862552712; Tue, 22 Jan 2013 05:49:12 -0800 (PST) Received: by 10.76.128.68 with HTTP; Tue, 22 Jan 2013 05:49:12 -0800 (PST) In-Reply-To: <18A556A4-5B93-49B3-88B3-BD955394EA2A@freebsd.org> References: <18A556A4-5B93-49B3-88B3-BD955394EA2A@freebsd.org> Date: Tue, 22 Jan 2013 08:49:12 -0500 Message-ID: Subject: Re: installworld fails From: Ryan Stone To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: AN , Brooks Davis , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 13:49:19 -0000 On Tue, Jan 22, 2013 at 1:24 AM, Jason Evans wrote: > On Jan 21, 2013, at 10:13 PM, AN wrote: > > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan 22 > 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > > > Is anyone seeing this? > > > > install -l s usr/src/sys /sys > > install: /sys/sys: Directory not empty > > *** [distrib-dirs] Error code 71 > > Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to > installworld is an effective workaround. > > Jason > > CC'ing Brooks, who I believe made this change. It looks as though install is using the semantics of ln -s /usr/src/sys /sys instead of ln -fs. From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 15:50:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A7ACFAF for ; Tue, 22 Jan 2013 15:50:34 +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 2D4F7ED2 for ; Tue, 22 Jan 2013 15:50:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Txg2L-002L3d-7O>; Tue, 22 Jan 2013 16:45:21 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Txg2L-0038wq-4p>; Tue, 22 Jan 2013 16:45:21 +0100 Message-ID: <50FEB409.9060907@zedat.fu-berlin.de> Date: Tue, 22 Jan 2013 16:45:13 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: r245791: make installworld fails X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6D36D9E5AABCF42375B1EF1C" X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 15:50:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D36D9E5AABCF42375B1EF1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A make installworld fails since today on FreeBSD 10.0-CURRENT/amd64. FreeBSD 10.0-CURRENT #0 r245455: Tue Jan 15 11:31:21 CET 2013 See error message below. Regards, Oliver [...] mkdir -p /tmp/install.qSk73yBh progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep install-info ln lockf make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic tzsetup; do if progpath=3D`which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $progs /tmp/install.qSk73yBh cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.qSk73yBh/locale cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Da= md64 CPUTYPE=3Dnative GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbi= n:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/instal= l.qSk73yBh LD_LIBRARY_PATH=3D/tmp/install.qSk73yBh PATH_LOCALE=3D/tmp/install.qSk73yBh/locale /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/install.qSk73yBh/sh reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3Dnative GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbi= n:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/instal= l.qSk73yBh LD_LIBRARY_PATH=3D/tmp/install.qSk73yBh PATH_LOCALE=3D/tmp/install.qSk73yBh/locale rm -rf /tmp/install.qSk73yBh -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 LOCAL_MTREE=3D hierarchy cd /usr/src/etc; /usr/obj/usr/src/make.amd64/make LOCAL_MTREE=3D distrib-= dirs mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var cache changed permissions expected 0750 found 0755 modified tmp/vi.recover changed user expected 0 found 2001 modified =2E/run/named missing (created) =2E/run/ppp missing (created) =2E/run/wpa_supplicant missing (created) mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BIND.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BIND.chroot.dist -p /var/named mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / install -l s usr/src/sys /sys install: /sys/sys: Directory not empty --------------enig6D36D9E5AABCF42375B1EF1C 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) iQEcBAEBAgAGBQJQ/rQRAAoJEOgBcD7A/5N8L6YIAOAGu0ZpYmUu2KqMDADrTpo0 tQ4sxx5KNNwvataJdGmyF2KrPKXxqFwMyhcPXYS1OkyEcvtqKs0ufCFaIc6lf7qB uLwZVe5uiI/aNs7v0i8UB8ic7KWQ7aXXsaXM/kgEAeiyaeA0DFoX2I2OklHoZ+Li nka7UdYoWfJO2XV/VH/K34xs1RKGr5ROvtAmpLZgtyy/+BRswk/7vD2sOC0kYO3E 7m35QsCQsASqVV7zPrI7CBzY6IjcHqBI1mbwcPXvqo3ZH5Fr9X2AnDasszA4/usS RCwerYujV0v7+Uds3YwuU7VoOAoU3VZOORf0S49czo47tRV4vZdClZQTZMcmkDY= =PA3r -----END PGP SIGNATURE----- --------------enig6D36D9E5AABCF42375B1EF1C-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 16:02:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94ACD3EC; Tue, 22 Jan 2013 16:02:39 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id E12BCF6C; Tue, 22 Jan 2013 16:02:38 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0MG2dNJ001096; Tue, 22 Jan 2013 10:02:39 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0MG2dMn001095; Tue, 22 Jan 2013 10:02:39 -0600 (CST) (envelope-from brooks) Date: Tue, 22 Jan 2013 10:02:39 -0600 From: Brooks Davis To: Ryan Stone Subject: Re: installworld fails Message-ID: <20130122160239.GB794@lor.one-eyed-alien.net> References: <18A556A4-5B93-49B3-88B3-BD955394EA2A@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: AN , Jason Evans , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 16:02:39 -0000 On Tue, Jan 22, 2013 at 08:49:12AM -0500, Ryan Stone wrote: > On Tue, Jan 22, 2013 at 1:24 AM, Jason Evans wrote: >=20 > > On Jan 21, 2013, at 10:13 PM, AN wrote: > > > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan= 22 > > 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > > > > > Is anyone seeing this? > > > > > > install -l s usr/src/sys /sys > > > install: /sys/sys: Directory not empty > > > *** [distrib-dirs] Error code 71 > > > > Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to > > installworld is an effective workaround. > > > > Jason > > > > > CC'ing Brooks, who I believe made this change. >=20 > It looks as though install is using the semantics of ln -s /usr/src/sys > /sys instead of ln -fs. Sorry about this breakage I'm testing a fix now. The problem is actually that install implemented the behavior of ln -sf and not ln -sfh. -- Brooks From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 16:03:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2302501 for ; Tue, 22 Jan 2013 16:03:20 +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 91D16F81 for ; Tue, 22 Jan 2013 16:03:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1TxgJj-002Q90-QZ>; Tue, 22 Jan 2013 17:03:19 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1TxgJj-003AJC-OB>; Tue, 22 Jan 2013 17:03:19 +0100 Message-ID: <50FEB83D.1000806@zedat.fu-berlin.de> Date: Tue, 22 Jan 2013 17:03:09 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: Re: r245791: make installworld fails References: <50FEB409.9060907@zedat.fu-berlin.de> In-Reply-To: <50FEB409.9060907@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAAD50757F7EF17D4A4D6510F" X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 16:03:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAAD50757F7EF17D4A4D6510F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Grmpf ... obviously, I should look first into the list, then post. it has been discovered by others recently ... On 01/22/13 16:45, O. Hartmann wrote: > A make installworld fails since today on FreeBSD 10.0-CURRENT/amd64. > FreeBSD 10.0-CURRENT #0 r245455: Tue Jan 15 11:31:21 CET 2013 >=20 > See error message below. >=20 >=20 > Regards, >=20 > Oliver >=20 >=20 > [...] >=20 > mkdir -p /tmp/install.qSk73yBh > progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo= > egrep find grep install-info ln lockf make mkdir mtree mv pwd_mkdb rm > sed sh sysctl test true uname wc zic tzsetup; do if progpath=3D`which= > $prog`; then echo $progpath; else echo "Required tool $prog not foun= d > in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "%o %p\n" -f "%o > %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line= ; > if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo "Required > library $1 not found." >&2; exit 1; fi; done); cp $libs $progs > /tmp/install.qSk73yBh > cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.qSk73yBh/locale > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3D= amd64 > CPUTYPE=3Dnative GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy= /usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/s= bin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/inst= all.qSk73yBh > LD_LIBRARY_PATH=3D/tmp/install.qSk73yBh > PATH_LOCALE=3D/tmp/install.qSk73yBh/locale > /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 > __MAKE_SHELL=3D/tmp/install.qSk73yBh/sh reinstall; > MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Damd64 MACHINE=3Damd64 > CPUTYPE=3Dnative GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy= /usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/s= bin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/inst= all.qSk73yBh > LD_LIBRARY_PATH=3D/tmp/install.qSk73yBh > PATH_LOCALE=3D/tmp/install.qSk73yBh/locale rm -rf /tmp/install.qSk73yBh= > -------------------------------------------------------------- >>>> Making hierarchy > -------------------------------------------------------------- > cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 > LOCAL_MTREE=3D hierarchy > cd /usr/src/etc; /usr/obj/usr/src/make.amd64/make LOCAL_MTREE=3D distri= b-dirs > mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p / > mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var > cache changed > permissions expected 0750 found 0755 modified > tmp/vi.recover changed > user expected 0 found 2001 modified > ./run/named missing (created) > ./run/ppp missing (created) > ./run/wpa_supplicant missing (created) > mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr > mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include > mtree -deU -f /usr/src/etc/mtree/BIND.include.dist -p /usr/include > mtree -deU -f /usr/src/etc/mtree/BIND.chroot.dist -p /var/named > mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr > mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / > install -l s usr/src/sys /sys > install: /sys/sys: Directory not empty --------------enigAAD50757F7EF17D4A4D6510F 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) iQEcBAEBAgAGBQJQ/rhHAAoJEOgBcD7A/5N8rPsIAItchZJ3R4wMrt1d+x31zUPP q8YT+aG5x/yZUc6ghajNkBqHmm+YcfkZuLEB2ZI18nbiIGPwlipnFduNmy3n8r3G vA5cEvs7CQMuW0pd1paqyqRH3k4vWKx/tF4ylKDaXWM22RMzGZhhKJKjjtwtDeJy hxw3WEE6+jO1J4lawT3DfAFKCvpRwWYEUyVyUDNj4WBcRRgsue2LP/EWH7wyAFJi 1N5ndIt+UMaReBTR6oI6iHSzYlDFPcYuOvvQTCDuObVf/xHhlSfEMKp9Z0hQiTTi vu/U7Db96pum+QOoopmnuEqiMMDNhc3oO+8tuP9gr7nsC0V6iJ4r6RzeNvP83lI= =3HS2 -----END PGP SIGNATURE----- --------------enigAAD50757F7EF17D4A4D6510F-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 16:23:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FE0FB63; Tue, 22 Jan 2013 16:23:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id DC501104; Tue, 22 Jan 2013 16:23:50 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0MGNpwW001205; Tue, 22 Jan 2013 10:23:51 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0MGNphv001204; Tue, 22 Jan 2013 10:23:51 -0600 (CST) (envelope-from brooks) Date: Tue, 22 Jan 2013 10:23:51 -0600 From: Brooks Davis To: Ryan Stone Subject: Re: installworld fails Message-ID: <20130122162351.GC794@lor.one-eyed-alien.net> References: <18A556A4-5B93-49B3-88B3-BD955394EA2A@freebsd.org> <20130122160239.GB794@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20130122160239.GB794@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: AN , Jason Evans , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 16:23:51 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 22, 2013 at 10:02:39AM -0600, Brooks Davis wrote: > On Tue, Jan 22, 2013 at 08:49:12AM -0500, Ryan Stone wrote: > > On Tue, Jan 22, 2013 at 1:24 AM, Jason Evans wrote: > >=20 > > > On Jan 21, 2013, at 10:13 PM, AN wrote: > > > > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue J= an 22 > > > 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > > > > > > > Is anyone seeing this? > > > > > > > > install -l s usr/src/sys /sys > > > > install: /sys/sys: Directory not empty > > > > *** [distrib-dirs] Error code 71 > > > > > > Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to > > > installworld is an effective workaround. > > > > > > Jason > > > > > > > > CC'ing Brooks, who I believe made this change. > >=20 > > It looks as though install is using the semantics of ln -s /usr/src/sys > > /sys instead of ln -fs. >=20 > Sorry about this breakage I'm testing a fix now. The problem is > actually that install implemented the behavior of ln -sf and not ln -sfh. Should be fixed with r245793. Sorry for the breakage. -- Brooks --gKMricLos+KVdGMg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ/r0XXY6L6fI4GtQRAj3eAJwK7JUwr1Hvawj8COENrsALwjUMTQCePwpO mcY6Zwbd2YVXrgYGfkfWl6g= =SG9I -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 14:51:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C98F8E7E for ; Tue, 22 Jan 2013 14:51:33 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9C899AA9 for ; Tue, 22 Jan 2013 14:51:32 +0000 (UTC) Received: from eee.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 31414177D6; Tue, 22 Jan 2013 23:51:26 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [192.168.1.108]) (authenticated bits=0) by eee.bbnest.net (8.14.6/8.14.5) with ESMTP id r0MEpKML084360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jan 2013 23:51:21 +0900 (JST) (envelope-from bland@bbnest.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS + usb in trouble? From: Alexander Nedotsukov In-Reply-To: <201301212244.54025.hselasky@c2i.net> Date: Tue, 22 Jan 2013 23:51:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201301212236.04250.hselasky@c2i.net> <201301212237.11092.hselasky@c2i.net> <201301212244.54025.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 22 23:51:26 2013 X-DSPAM-Confidence: 0.9995 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50fea76e843611385919958 X-Mailman-Approved-At: Tue, 22 Jan 2013 16:31:54 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 14:51:33 -0000 Hans, Please see my reply to Pawel. I believe that GELI test does suffice you = request. Also I did try quirk you mentioned but it did not fix the problem. I wonder if anybody else besides me can reproduce this. Thanks, Alexander. On 22.01.2013, at 6:44, Hans Petter Selasky wrote: > On Monday 21 January 2013 22:37:11 Hans Petter Selasky wrote: >> On Monday 21 January 2013 22:36:04 Hans Petter Selasky wrote: >>> On Monday 21 January 2013 22:17:19 Pawel Jakub Dawidek wrote: >>>> I used wrong Hans' login, resending with the proper e-mail. >>>=20 >>> Hi, >>>=20 >>> You should try to use some tools to write some random data and read = it >>> back and see if the data is the same, at /dev/daX level. The USB = wrapper >>> for SCSI is very simple and it passes commands directly from CAM to = the >>> hardware. I would be surprised if data was corrupted at this stage. >>=20 >> Please also check if your USB device suffers from the lack of = SYNCHRONIZE >> CACHE. >>=20 >=20 > Hi, >=20 > Try this first: >=20 > usbconfig -d X.Y add_quirk UQ_MSC_NO_SYNC_CACHE >=20 > Re-plug device. >=20 > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 15:06:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA38B1B1; Tue, 22 Jan 2013 15:06:08 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 73682BDC; Tue, 22 Jan 2013 15:06:08 +0000 (UTC) Received: from eee.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id AA038E57E; Tue, 22 Jan 2013 23:47:37 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [192.168.1.108]) (authenticated bits=0) by eee.bbnest.net (8.14.6/8.14.5) with ESMTP id r0MElQao084331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jan 2013 23:47:27 +0900 (JST) (envelope-from bland@bbnest.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS + usb in trouble? From: Alexander Nedotsukov In-Reply-To: <20130121211718.GD1341@garage.freebsd.pl> Date: Tue, 22 Jan 2013 23:47:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130121205851.GB1341@garage.freebsd.pl> <20130121211718.GD1341@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 22 23:47:37 2013 X-DSPAM-Confidence: 0.9996 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50fea689843321386813696 X-Mailman-Approved-At: Tue, 22 Jan 2013 16:40:36 +0000 Cc: FreeBSD Current , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 15:06:08 -0000 Hi Pawel, Here what I did. # geli onetime -a hmac/sha1 -s 4096 /dev/da5=20 # dmesg | tail -15 wlan0: link state changed to UP ugen5.4: at usbus5 umass2: on usbus5 umass2: SCSI over Bulk-Only; quirks =3D 0x0100 umass2:4:2:-1: Attached to scbus4 da5 at umass-sim2 bus 2 scbus4 target 0 lun 0 da5: Removable Direct Access SCSI-2 device=20 da5: 40.000MB/s transfers da5: 983MB (2015231 512 byte sectors: 64H 32S/T 983C) GEOM_ELI: Device da5.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Integrity: HMAC/SHA1 GEOM_ELI: Crypto: software GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset = 4096. GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset = 0. # dd if=3D/dev/random of=3D/dev/da5.eli bs=3D1m dd: /dev/da5.eli: short write on character device dd: /dev/da5.eli: end of device 875+0 records in 874+1 records out 917151744 bytes transferred in 1530.831674 secs (599120 bytes/sec) # dd if=3D/dev/da5.eli of=3D/dev/null bs=3D1m 874+1 records in 874+1 records out 917151744 bytes transferred in 178.874312 secs (5127353 bytes/sec) All clear. No new errors. Zpool created on the same usb stick is still failing with cksum errors. # usbconfig -d 5.4 add_quirk UQ_MSC_NO_SYNC_CACHE umass2: SCSI over Bulk-Only; quirks =3D 0x4000 Re-created zpool is still failing with cksum errors. Every new scrub run = is triggering another "repairing". Thanks, Alexander. On 22.01.2013, at 6:17, Pawel Jakub Dawidek wrote: > I used wrong Hans' login, resending with the proper e-mail. >=20 > On Mon, Jan 21, 2013 at 09:58:52PM +0100, Pawel Jakub Dawidek wrote: >> On Sat, Jan 19, 2013 at 11:26:39PM +0900, Alexander Nedotsukov wrote: >>> Let's use some space out of it. >>>=20 >>> #dd if=3D/dev/zero of=3D/tank/foo >>> ^C250939+0 records in >>> 250938+0 records out >>> 128480256 bytes transferred in 30.402453 secs (4225983 bytes/sec) >>>=20 >>> Oops... >>>=20 >>> #zpool status >>> pool: tank >>> state: ONLINE >>> status: One or more devices has experienced an unrecoverable error. = An >>> attempt was made to correct the error. Applications are = unaffected. >>> action: Determine if the device needs to be replaced, and clear the = errors >>> using 'zpool clear' or replace the device with 'zpool replace'. >>> see: http://illumos.org/msg/ZFS-8000-9P >>> scan: scrub repaired 5K in 0h0m with 0 errors on Sat Jan 19 = 23:11:20 2013 >>> config: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> tank ONLINE 0 0 0 >>> raidz1-0 ONLINE 0 0 0 >>> da1 ONLINE 0 0 1 >>> da2 ONLINE 0 0 0 >>> da3 ONLINE 0 0 1 >>=20 >> This seems like umass/usb issue (hps@ CCed). Can you also try GELI = with >> data integrity verification? >>=20 >>=20 >> # geli onetime -a hmac/sha1 -s 4096 /dev/da0 >>=20 >> It will report some problems due to GEOM tasting, but ignore them and = run: >>=20 >> # dd if=3D/dev/random of=3D/dev/da0.eli bs=3D1m >>=20 >> Once that done try to read the data back and look at the logs to see = if >> any corruptions are reported. >>=20 >> --=20 >> Pawel Jakub Dawidek http://www.wheelsystems.com >> FreeBSD committer http://www.FreeBSD.org >> Am I Evil? Yes, I Am! http://tupytaj.pl >=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 From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 17:39:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E31142B for ; Tue, 22 Jan 2013 17:39:37 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id B5503863 for ; Tue, 22 Jan 2013 17:39:35 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so7498260oag.5 for ; Tue, 22 Jan 2013 09:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=HvnJ1SwgLlUe5ie7K2fUD3ofOPN+8CLBUASiqZV37Kg=; b=XlewjtctzvmtjZkWCv6am/h9Cy75rS8MuasEjkeOxKCiG+xg7ouAJKBZYHwhZj3uQe 8rwvj5oBGQr+gTiXdOOGFYVB3avGZHR6hsUPhW6YsrAAd2CnuNpS3S9q5SX2m1q6YBsa pOHjUo63Twy8sN5wBrJKsFscKFGGF+59wq3M5DhVQPiQl7iacjaIyU7wltcuygcC/Z4F jqX+h1PqD02Bs8BngRlFLL+IlsBLQK/ZB4FxOvyBPxilE9TXBAkm7+NmHMLuVV3rxbn6 qHxLMk0emeMydwlTXxK02x8ClrMhmNcJYS1G8JWC82lSzwGK5vGvVcjGkJdus7m4i0+Y XB1Q== X-Received: by 10.60.171.175 with SMTP id av15mr17297118oec.75.1358876375255; Tue, 22 Jan 2013 09:39:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.93.105 with HTTP; Tue, 22 Jan 2013 09:39:05 -0800 (PST) From: Jia-Shiun Li Date: Wed, 23 Jan 2013 01:39:05 +0800 Message-ID: Subject: if_re not working on boot To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 17:39:37 -0000 Hi all, wondering if anyone else encounters the same situation. LOM Realtek RT8111F on my mainboard Asus P8H77M-LE does not appear to work on boot. Ping to any hosts has no response. But after "ifconfig re0 down up" it works fine. Looks like something was not properly initialized. verbose dmesg: http://pastebin.com/h4S38sGZ Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 17:55:59 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 727208E7; Tue, 22 Jan 2013 17:55:59 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 36791932; Tue, 22 Jan 2013 17:55:59 +0000 (UTC) Received: from localhost (global-1-11.nat.csx.cam.ac.uk [131.111.184.11]) by mail.dawidek.net (Postfix) with ESMTPSA id C6128AD8; Tue, 22 Jan 2013 18:53:18 +0100 (CET) Date: Tue, 22 Jan 2013 18:56:29 +0100 From: Pawel Jakub Dawidek To: current@FreeBSD.org Subject: ACPI panic on unplugging the power cord. Message-ID: <20130122175629.GA1714@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 17:55:59 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just upgraded to HEAD today and was wondering what will explode. Now I know. When I unplug power cord from my laptop, ACPI panics. Pictures here: http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg Let me know if you need more info. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD+0s0ACgkQForvXbEpPzSK1ACg+SHMt62zk8uZQkHb9symGT1c ad4AoOPrmQceRBb4c4Zqa9OL0FVWJCm2 =EqOd -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 17:59:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 91302D1B for ; Tue, 22 Jan 2013 17:59:43 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCEF976 for ; Tue, 22 Jan 2013 17:59:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r0MHxXFH042768; Tue, 22 Jan 2013 21:59:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r0MHxXDa042767; Tue, 22 Jan 2013 21:59:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 22 Jan 2013 21:59:33 +0400 From: Gleb Smirnoff To: Olivier Cochard-Labb? Subject: Re: Adding more tools to be used by operator group members Message-ID: <20130122175933.GD41700@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 17:59:43 -0000 On Tue, Jan 22, 2013 at 02:03:12PM +0100, Olivier Cochard-Labb? wrote: O> There are only 2 useable tools by "operator" group members: O> shutdown (and its child: poweroff, halt, etc?) and mksnap_ffs. O> O> On my HAL-less laptop, I've put my user in the operator group that let O> me reboot/power-off it with shutdown. O> But I would to be able to suspend-resume it too (with zzz). O> O> Here is what I've did: O> for f in "/usr/sbin/acpiconf /usr/sbin/apm"; do O> chown :operator $f O> chmod 4550 $f O> done O> O> What about configuring this permission by default on FreeBSD ? O> And why /sbin/reboot isn't useable by operator too ? O> Are there somes security issue ? +1 here. I was always annoyed and surprised by this fact. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 18:09:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B4B5825; Tue, 22 Jan 2013 18:09:37 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2F164A20; Tue, 22 Jan 2013 18:09:36 +0000 (UTC) Received: from localhost (global-1-11.nat.csx.cam.ac.uk [131.111.184.11]) by mail.dawidek.net (Postfix) with ESMTPSA id 836BAAEB; Tue, 22 Jan 2013 19:07:02 +0100 (CET) Date: Tue, 22 Jan 2013 19:10:12 +0100 From: Pawel Jakub Dawidek To: Alexander Nedotsukov Subject: Re: ZFS + usb in trouble? Message-ID: <20130122181012.GD1714@garage.freebsd.pl> References: <20130121205851.GB1341@garage.freebsd.pl> <20130121211718.GD1341@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" 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 , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 18:09:37 -0000 --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 22, 2013 at 11:47:29PM +0900, Alexander Nedotsukov wrote: > Hi Pawel, >=20 > Here what I did. >=20 > # geli onetime -a hmac/sha1 -s 4096 /dev/da5=20 > # dmesg | tail -15 > wlan0: link state changed to UP > ugen5.4: at usbus5 > umass2: on usbus5 > umass2: SCSI over Bulk-Only; quirks =3D 0x0100 > umass2:4:2:-1: Attached to scbus4 > da5 at umass-sim2 bus 2 scbus4 target 0 lun 0 > da5: Removable Direct Access SCSI-2 device=20 > da5: 40.000MB/s transfers > da5: 983MB (2015231 512 byte sectors: 64H 32S/T 983C) > GEOM_ELI: Device da5.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Integrity: HMAC/SHA1 > GEOM_ELI: Crypto: software > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 40= 96. > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 0. >=20 > # dd if=3D/dev/random of=3D/dev/da5.eli bs=3D1m > dd: /dev/da5.eli: short write on character device > dd: /dev/da5.eli: end of device > 875+0 records in > 874+1 records out > 917151744 bytes transferred in 1530.831674 secs (599120 bytes/sec) >=20 > # dd if=3D/dev/da5.eli of=3D/dev/null bs=3D1m > 874+1 records in > 874+1 records out > 917151744 bytes transferred in 178.874312 secs (5127353 bytes/sec) >=20 > All clear. No new errors. >=20 > Zpool created on the same usb stick is still failing with cksum errors. >=20 > # usbconfig -d 5.4 add_quirk UQ_MSC_NO_SYNC_CACHE >=20 > umass2: SCSI over Bulk-Only; quirks =3D 0x4000 >=20 > Re-created zpool is still failing with cksum errors. Every new scrub run = is triggering another "repairing". Interesting. Can you put ZFS on top of GELI with authentication after filling da0.eli with random random and see if GELI will report corruption when ZFS will or if only ZFS will report corruption? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --T7mxYSe680VjQnyC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD+1gQACgkQForvXbEpPzS00ACeI7A/Orl3ISZNXqs//iKBTUKu SsEAnAhCVir8jIyWs3Pxbf4Uhf3JlPBF =0fKt -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 18:38:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ADBE8504; Tue, 22 Jan 2013 18:38:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 2443DCEF; Tue, 22 Jan 2013 18:38:15 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k14so274087wer.25 for ; Tue, 22 Jan 2013 10:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oqgDlE+POmH3Kdjiw1wBHY+snj+IJ0GgzVakKbKHUYw=; b=TOX9fn3OqYR09gwTuPxr4XrN4DbjPPvrNqCAxeS2Z3lb7N3t0cEYW6SNroXC2MeEQ9 0SBUw0pttm+Fb95io4q6Gj+FOspsSVCK7Jg6jNZcOb3b4atZjDsArXOXCgTAtjrCOZM6 4tIWWnxZp10e+RtNSqRNyObZt4AVkIjd1h7pry5HqKqOnvoBCDLccnuBCreIVqj9pUlr 0D+StIRV4TnDeQ3ak5GPeD9EAAdjmT51oWJu4nIUKNYbr+y+vo28HA+cCKApKLZ4KkXW aA1+E5pSiP5SCAEQi6r1UJaB3iLWrQXwHJEhxJN+YaKhxD1xcVVMOtaYWd2Ri35GCxXe sgAQ== MIME-Version: 1.0 X-Received: by 10.180.24.70 with SMTP id s6mr23182849wif.22.1358879894495; Tue, 22 Jan 2013 10:38:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.123.73 with HTTP; Tue, 22 Jan 2013 10:38:14 -0800 (PST) In-Reply-To: <20130122175933.GD41700@FreeBSD.org> References: <20130122175933.GD41700@FreeBSD.org> Date: Tue, 22 Jan 2013 10:38:14 -0800 X-Google-Sender-Auth: O08Ep2mHh4bMyMCvHs5NRRpexYY Message-ID: Subject: Re: Adding more tools to be used by operator group members From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Cochard-Labb? , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 18:38:16 -0000 Ah, the historical difference between shutdown -r and reboot.... adrian On 22 January 2013 09:59, Gleb Smirnoff wrote: > On Tue, Jan 22, 2013 at 02:03:12PM +0100, Olivier Cochard-Labb? wrote: > O> There are only 2 useable tools by "operator" group members: > O> shutdown (and its child: poweroff, halt, etc?) and mksnap_ffs. > O> > O> On my HAL-less laptop, I've put my user in the operator group that let > O> me reboot/power-off it with shutdown. > O> But I would to be able to suspend-resume it too (with zzz). > O> > O> Here is what I've did: > O> for f in "/usr/sbin/acpiconf /usr/sbin/apm"; do > O> chown :operator $f > O> chmod 4550 $f > O> done > O> > O> What about configuring this permission by default on FreeBSD ? > O> And why /sbin/reboot isn't useable by operator too ? > O> Are there somes security issue ? > > +1 here. I was always annoyed and surprised by this fact. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 20:11:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8810B82 for ; Tue, 22 Jan 2013 20:11:04 +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 C736410D for ; Tue, 22 Jan 2013 20:11:04 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CED30B95B; Tue, 22 Jan 2013 15:11:03 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [PATCH] Variable-size ioctl data handling Date: Tue, 22 Jan 2013 13:54:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <50FDA46D.6080105@rawbw.com> In-Reply-To: <50FDA46D.6080105@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301221354.45093.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Jan 2013 15:11:03 -0500 (EST) Cc: Yuri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 20:11:05 -0000 On Monday, January 21, 2013 3:26:21 pm Yuri wrote: > Hi, > > Could anybody please review and check in the patch > patch-ioctl-var-size.txt from this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=175425 ? > This patch introduces the generic way to pass variable size ioctl > argument using the structure like this struct my_struct {int len; ...any > fields...}. I think this layout is a bit of a special case. I think you should just put the userland pointer in length in the structure you pass to the ioctl as mdf@ suggested in the thread on hackers@. If nothing else, the length should be a size_t instead of an int. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 23:22:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7ABCC6EC; Tue, 22 Jan 2013 23:22:43 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id D1DE9CB7; Tue, 22 Jan 2013 23:22:42 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id fy7so4018112vcb.4 for ; Tue, 22 Jan 2013 15:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QVYpoF9mNN/yWXsdDowaIcwb0yfm0+A5bqqZZTqm0Ng=; b=tkfxzg9/ps834gRnfNd9iCycmE1JYhvgRyMDRgvyIZVOY7b/dK/DdWeT51agJx0njM 8e3y2P3NaPjyqtAWL2/ATuAZndg04tubHMoo8wSMYd+IvibVVwCfhctdz3zGR0sjdzjO Wtz1MmaDVlnBaO2EsfBXO0ai5FRLnWBw8uxgz3Vcr0Cx0vSw/HtjPXVMfWr9RWjDdyVO p4cZCUiarMrVK9oxO2MWkGvS80GLAn4eUsqwNFdt/32z7J60jMZJ+1V6alPazR7vsGcU gne0ZfVMTrqxcyKMBUGlzq93eZUfMmzDH9yLl7SVZ217y+/b8amVt05yT1XV4EQcbPkc SK5g== MIME-Version: 1.0 X-Received: by 10.52.67.45 with SMTP id k13mr23456165vdt.9.1358896956102; Tue, 22 Jan 2013 15:22:36 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.122.196 with HTTP; Tue, 22 Jan 2013 15:22:35 -0800 (PST) In-Reply-To: <20130121210645.GC1341@garage.freebsd.pl> References: <50F96A67.9080203@freebsd.org> <20130121210645.GC1341@garage.freebsd.pl> Date: Tue, 22 Jan 2013 15:22:35 -0800 X-Google-Sender-Auth: Wy68ekTm74emE4euEUDfVS6eJ2s Message-ID: Subject: Re: kmem_map auto-sizing and size dependencies From: Artem Belevich To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Cc: Matthew Fleming , FreeBSD Current , Andre Oppermann , freebsd-hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jan 2013 23:22:43 -0000 On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote: > On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote: >> > Should it be set to a larger initial value based on min(physical,KVM) space >> > available? >> >> It needs to be smaller than the physical space, [...] > > Or larger, as the address space can get fragmented and you might not be > able to allocate memory even if you have physical pages available. +1 for relaxing upper limit. I routinely patch all my systems that use ZFS to allow kmem_map size to be larger than physical memory. Otherwise on a system where most of RAM goes towards ZFS ARC I used to eventually run into dreaded kmem_map too small panic. --Artem From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 00:54:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA68356A for ; Wed, 23 Jan 2013 00:54:03 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id ADEE9F5B for ; Wed, 23 Jan 2013 00:54:03 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 9B5E226A5A for ; Tue, 22 Jan 2013 19:54:02 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7UDyNuyyjxv for ; Tue, 22 Jan 2013 19:54:02 -0500 (EST) Received: from EGR authenticated sender Message-ID: <50FF34AC.9000204@egr.msu.edu> Date: Tue, 22 Jan 2013 19:54:04 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: kmem_map auto-sizing and size dependencies References: <50F96A67.9080203@freebsd.org> <20130121210645.GC1341@garage.freebsd.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 00:54:04 -0000 On 1/22/2013 6:22 PM, Artem Belevich wrote: > On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote: >> On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote: >>>> Should it be set to a larger initial value based on min(physical,KVM) space >>>> available? >>> It needs to be smaller than the physical space, [...] >> Or larger, as the address space can get fragmented and you might not be >> able to allocate memory even if you have physical pages available. > +1 for relaxing upper limit. > > I routinely patch all my systems that use ZFS to allow kmem_map size > to be larger than physical memory. Otherwise on a system where most of > RAM goes towards ZFS ARC I used to eventually run into dreaded > kmem_map too small panic. > > --Artem > _______________________________________________ Ever since related code has been patched to properly permit kmem=2x physmem out of the box, I've been using that guideline for my systems and I've not had an out of kmem panic in years. I've previously ran into weird temporary deadlocks with strong IO if I set the kmem too high, as if the ARC caused something important to be overwritten; that is just my theory. I agree with the fragmentation principle here. YMMV regarding the kmem size. From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 07:13:55 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 033D69D3; Wed, 23 Jan 2013 07:13:55 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 50A1EDC9; Wed, 23 Jan 2013 07:13:54 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TxuWo-000Ep7-4C ; Wed, 23 Jan 2013 09:13:46 +0200 Date: Wed, 23 Jan 2013 09:13:46 +0200 From: Vitalij Satanivskij To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130123071346.GA56937@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121173122.GA20466@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jaakko Heinonen , Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 07:13:55 -0000 Vitalij Satanivskij wrote: VS> Jaakko Heinonen wrote: VS> JH> On 2013-01-19, Jaakko Heinonen wrote: VS> JH> > On 2013-01-18, Alexander Motin wrote: VS> JH> > > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are VS> JH> > > impossible there, as previous name components are unique. Special VS> JH> > > characters haven't yet seen, but I think theoretically possible. VS> JH> > VS> JH> > I see two possible solutions for the problem. VS> JH> > VS> JH> > 1) Replace non-printable, space and '/' characters for example with '_'. VS> JH> > '/' should be replaced anyway. VS> JH> > VS> JH> > 2) Apply the patches in VS> JH> > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html VS> JH> > to allow spaces again. I haven't committed the patches because I VS> JH> > think that there isn't full consensus that it's right thing to do and VS> JH> > also I personally prefer not to have spaces in device names. VS> JH> VS> JH> Here's a patch to implement 1: VS> JH> VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff VS> VS> Ok that patch work's too. VS> VS> ses1: da0,pass5,probe8: Element descriptor: 'Slot 08' VS> ses1: da0,pass5,probe8: SAS Device Slot Element: 1 Phys at Slot 7 VS> ses1: phy 0: SATA device VS> ses1: phy 0: parent 5003048000baa87f addr 5003048000baa853 VS> da0 at mps0 bus 0 scbus7 target 8 lun 0 VS> da0: Fixed Direct Access SCSI-6 device VS> da0: 300.000MB/s transfers VS> da0: Command Queueing enabled VS> da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) Is there any chance, that one of this patches will be merged to head? From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 08:10:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 633336C7 for ; Wed, 23 Jan 2013 08:10:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B4F12FD9 for ; Wed, 23 Jan 2013 08:10:44 +0000 (UTC) Received: (qmail 23874 invoked from network); 23 Jan 2013 09:32:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jan 2013 09:32:03 -0000 Message-ID: <50FF9AFE.9000406@freebsd.org> Date: Wed, 23 Jan 2013 09:10:38 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Artem Belevich Subject: Re: kmem_map auto-sizing and size dependencies References: <50F96A67.9080203@freebsd.org> <20130121210645.GC1341@garage.freebsd.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Fleming , FreeBSD Current , freebsd-hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 08:10:45 -0000 On 23.01.2013 00:22, Artem Belevich wrote: > On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote: >> On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote: >>>> Should it be set to a larger initial value based on min(physical,KVM) space >>>> available? >>> >>> It needs to be smaller than the physical space, [...] >> >> Or larger, as the address space can get fragmented and you might not be >> able to allocate memory even if you have physical pages available. > > +1 for relaxing upper limit. > > I routinely patch all my systems that use ZFS to allow kmem_map size > to be larger than physical memory. Otherwise on a system where most of > RAM goes towards ZFS ARC I used to eventually run into dreaded > kmem_map too small panic. During startup and VM initialization the following kernel VM maps are created: kernel_map (parent) specifying the entire kernel virtual address space. It is 512GB on amd64 currently. Out of the kernel_map a number of sub-maps are created: clean_map which isn't referenced anywhere else buffer_map used in vfs_bio.c for i/o buffers pager_map used in vm_page.c for paging exec_map used in kern/kern_exec.c and other places for program startup pipe_map used in kern/sys_pipe.c for pipe buffering kmem_map used in kern/kern_malloc. and vm/uma_core.c among other places and provides all kernel malloc and UMA zone memory allocations. Having the kernel occupy all of physical RAM eventually isn't pretty. So the problem you're describing is that even though enough kernel_map space is still available it is too fragmented to find a sufficiently large chunk. If the kmem_map is larger than the available physical memory another mechanism has to track and limit its physical memory consumption. This may become a SMP bottleneck due to synchronization issues. I haven't looked how the maps are managed internally. Maybe there is a natural hook to attach such a mechanism and to allow the sub-maps to be larger in kVM space than physical memory. Maybe ZFS then can have its own sub-map for ARC too. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 08:14:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D396EA8F for ; Wed, 23 Jan 2013 08:14:21 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 8390575 for ; Wed, 23 Jan 2013 08:14:21 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id u8so3788670iag.17 for ; Wed, 23 Jan 2013 00:14:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=HNS1+SZSi3N8ztmJCyfu+o0M0OAQFs+TZ+KGCEIA1YM=; b=DcaGw91M2i2s9dl0wVeJ69qHnoExBY/qhBBpd34EZbUM+jk92CsoLWRv/LQp/gCPxb mLV1XDem3Gl5IdOKzOFq0i5fGZC0rN8zmPz0+M9eirBq0SJf23iLolw+dB4KXksPbgE4 QDhz0LyrCuyilOvHUuRx290jNxSSYKOoygGrH439UyyxCCTMgJ2Q/fGdmSBCubf8c2HU CldSznsb6y1IpxATxCZuWMV8FFTxdxgYgVkZNH8GUKb8j+lKF9ANUMFPl6mK0jCZpEqO Ug3qw82VBPhy9kf0imVQFIngLk/mL9ep6nlRrG4AOELOKQ79PXVz9wHXuSbB4zdgVkNP tGYQ== MIME-Version: 1.0 X-Received: by 10.50.12.135 with SMTP id y7mr14257628igb.98.1358928860067; Wed, 23 Jan 2013 00:14:20 -0800 (PST) Received: by 10.64.63.100 with HTTP; Wed, 23 Jan 2013 00:14:20 -0800 (PST) Date: Wed, 23 Jan 2013 16:14:20 +0800 Message-ID: Subject: Compilation error (pkgng) From: Alie Tan To: freebsd-current@freebsd.org X-Gm-Message-State: ALoCoQlBXODr9UiDkR7DkhrUp1yBGesWsG0Qjd/naOdRFH/tXlzg+LVkKCw4gHASj+ZZ1ifPdSEI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 08:14:21 -0000 Seems this check-in causing compilation error: http://freshbsd.org/commit/freebsd/r245828 -nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')' rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite", pkgngdir); ^ /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '(' rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite", pkgngdir); ^ /usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (rc >= sizeof(pkgngpath)) { ~~ ^ ~~~~~~~~~~~~~~~~~ 1 warning and 1 error generated. *** [pkgng.o] Error code 1 Stop in /usr/src/usr.sbin/pkg_install/lib. *** [all] Error code 1 Stop in /usr/src/usr.sbin/pkg_install. *** [all] Error code 1 Stop in /usr/src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 08:15:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8E0ABA6 for ; Wed, 23 Jan 2013 08:15:49 +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 7A8A195 for ; Wed, 23 Jan 2013 08:15:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1TxvUq-0007YJ-M3>; Wed, 23 Jan 2013 09:15:48 +0100 Received: from e178024073.adsl.alicedsl.de ([85.178.24.73] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1TxvUq-003zMt-H7>; Wed, 23 Jan 2013 09:15:48 +0100 Message-ID: <50FF9C2B.30403@zedat.fu-berlin.de> Date: Wed, 23 Jan 2013 09:15:39 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg); References: <50FEB409.9060907@zedat.fu-berlin.de> <50FEB83D.1000806@zedat.fu-berlin.de> In-Reply-To: <50FEB83D.1000806@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig679809CE141FDB2E2E2DDF24" X-Originating-IP: 85.178.24.73 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 08:15:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig679809CE141FDB2E2E2DDF24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors com[laining about an undeclared identifier: [...] =3D=3D=3D> usr.bin/dtc (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc= rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -stdlib=3Dlibc++ /usr/src/usr.bin/dtc/dtc.cc /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc /usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc /usr/src/usr.bin/dtc/checking.cc echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo dtc: /usr/lib/libc++.a >> .depend c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include -stdlib=3Dlibc++ -std=3Dc++11 -c /usr/src/usr.bin/dtc/dtc.cc c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include -stdlib=3Dlibc++ -std=3Dc++11 -c /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared identifier 'strtoll' [...] 7 errors generated. *** [string.o] Error code 1 /usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared identifier 'stderr' fprintf(stderr, "Current cursor: %d\n", cursor); ^ /usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared identifier 'stderr' fwrite(&buffer[cursor], size-cursor, 1, stderr); ^ /usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared identifier 'perror' perror("Failed to stat file"); ^ /usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared identifier 'perror' perror("Failed to mmap file"); ^ /usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared identifier 'stdin' while ((c =3D fgetc(stdin)) !=3D EOF) ^ /usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared identifier 'EOF' while ((c =3D fgetc(stdin)) !=3D EOF) ^ 15 errors generated. *** [input_buffer.o] Error code 1 /usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier 'write' write(fd, buffer.data(), buffer.size()); ^ /usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier 'snprintf'; did you mean 'vswprintf'? snprintf(out, 3, "%.2hhx", b); ^~~~~~~~ vswprintf /usr/include/wchar.h:130:5: note: 'vswprintf' declared here int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * __restrict, ^ /usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a parameter of type 'wchar_t *' with an lvalue of type 'char [3]' snprintf(out, 3, "%.2hhx", b); ^~~ /usr/include/wchar.h:130:35: note: passing argument to parameter here int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * __restrict, ^ /usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier 'write' write(fd, buffer.data(), buffer.size()); ^ /usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared identifier 'stderr' fprintf(stderr, "Missing magic token in header. Got %" PRIx32 ^ 5 errors generated. *** [dtb.o] Error code 1 /usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared identifier 'getopt' while ((ch =3D getopt(argc, argv, options)) !=3D -1) [...] --------------enig679809CE141FDB2E2E2DDF24 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) iQEcBAEBAgAGBQJQ/5w0AAoJEOgBcD7A/5N8HV4H/1DW8PV1BXzPtEsyqpRhcKXG M/YjmSfyQ4Xqe7m/OTAneXXzi+Cf+Tbp1gcHVOpPGqb13HWxUKXJ7KUtSKxWUwR4 IPG1M2qagdvYTuacZFwLry+IUonsAYaCsbD2RoNs5MvWidob2eIVZGUQ6ibeCe+1 jD+mbN5ux5BvDW5Ozp1cgQ/+5cdvTq4LfTnWuDcAr1IGhpeCo5m4JJ2M8ZOTHXTD gZAvNtRTkWQIYNnT2hi3kGNbrva9Q6bMv2QUvPwY2xFXZCD1Y7Am7a/0IlgBadNa VSWTtkJbfj9ZoyfJ+ox3sOhmdzUCnU4RvzgLpjci7cCppNIHbVP+4/lMAHNaUQc= =RrDe -----END PGP SIGNATURE----- --------------enig679809CE141FDB2E2E2DDF24-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 08:57:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D68B4D2 for ; Wed, 23 Jan 2013 08:57:13 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4C113235 for ; Wed, 23 Jan 2013 08:57:12 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0N8vA30066703 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 23 Jan 2013 08:57:11 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg); Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_C3F94373-5D62-4117-9FA1-4B02A3BB9E52"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <50FF9C2B.30403@zedat.fu-berlin.de> Date: Wed, 23 Jan 2013 08:57:05 +0000 Message-Id: <86EC4A5E-7426-48D1-B4C4-E60B61FD5797@FreeBSD.org> References: <50FEB409.9060907@zedat.fu-berlin.de> <50FEB83D.1000806@zedat.fu-berlin.de> <50FF9C2B.30403@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1278) Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 08:57:13 -0000 --Apple-Mail=_C3F94373-5D62-4117-9FA1-4B02A3BB9E52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This appears to be caused by your addition of -stdlib=3Dlibc++ = -std=3Dc++11 to your CXXFLAGS. So, first of all, thank you for testing = libc++! =20 I tested with libc++ while I was developing dtc, but then was building = with libstdc++ while I was removing extraneous includes. Unfortunately, = libstdc++ leaks a load of C headers, whereas libc++ is very careful not = to. I've now (r245839) explicitly included everything so it now builds = with libc++ and in C++11 mode. =20 Thanks for the report, David On 23 Jan 2013, at 08:15, O. Hartmann wrote: > Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors > com[laining about an undeclared identifier: >=20 > [...] > =3D=3D=3D> usr.bin/dtc (obj,depend,all,install) > /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for = /usr/src/usr.bin/dtc > rm -f .depend > mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include > -std=3Dc++11 -stdlib=3Dlibc++ /usr/src/usr.bin/dtc/dtc.cc > /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc > /usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc > /usr/src/usr.bin/dtc/checking.cc > echo dtc: /usr/lib/libc.a = /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >>> .depend > echo dtc: /usr/lib/libc++.a >> .depend > c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include > -stdlib=3Dlibc++ -std=3Dc++11 -c /usr/src/usr.bin/dtc/dtc.cc > c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include > -stdlib=3Dlibc++ -std=3Dc++11 -c /usr/src/usr.bin/dtc/input_buffer.cc > /usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared > identifier 'strtoll' > [...] > 7 errors generated. > *** [string.o] Error code 1 > /usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared > identifier 'stderr' > fprintf(stderr, "Current cursor: %d\n", cursor); > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared > identifier 'stderr' > fwrite(&buffer[cursor], size-cursor, 1, stderr); > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared > identifier 'perror' > perror("Failed to stat file"); > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared > identifier 'perror' > perror("Failed to mmap file"); > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared > identifier 'stdin' > while ((c =3D fgetc(stdin)) !=3D EOF) > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared > identifier 'EOF' > while ((c =3D fgetc(stdin)) !=3D EOF) > ^ > 15 errors generated. > *** [input_buffer.o] Error code 1 > /usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier > 'write' > write(fd, buffer.data(), buffer.size()); > ^ > /usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier > 'snprintf'; did you mean 'vswprintf'? > snprintf(out, 3, "%.2hhx", b); > ^~~~~~~~ > vswprintf > /usr/include/wchar.h:130:5: note: 'vswprintf' declared here > int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * > __restrict, > ^ > /usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a = parameter > of type 'wchar_t *' with an lvalue of type 'char [3]' > snprintf(out, 3, "%.2hhx", b); > ^~~ > /usr/include/wchar.h:130:35: note: passing argument to parameter here > int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * > __restrict, > ^ > /usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier > 'write' > write(fd, buffer.data(), buffer.size()); > ^ > /usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared = identifier > 'stderr' > fprintf(stderr, "Missing magic token in header. Got %" > PRIx32 > ^ > 5 errors generated. > *** [dtb.o] Error code 1 > /usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared = identifier > 'getopt' > while ((ch =3D getopt(argc, argv, options)) !=3D -1) > [...] >=20 --Apple-Mail=_C3F94373-5D62-4117-9FA1-4B02A3BB9E52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/6XiAAoJEKx65DEEsqIdRl8P/1xiRx/UPA2kv+xRb+ANobi8 x7oHcrCAA4DosqtzA70mBMgH7FAL5s2QlaCRv24smyeWK4JhmdFuARv+K/AnhPaT 2ItHDh8sqtjKlmxBCsOW3HcbrrNI7MQEFuJE8IlKNDWJ1UvbumexoVNWdWiJFGj2 MARMC3flMhP8YSgy//daSe7s3DJsbxunoLPi86qLgTGS/DNzl5cY5pMQHvt6mMZ0 Oob5eTt13WKyXtBCytVOmHZ2gWW3k3IIayyhJ7x0izYIeILi21yxisHVyNf6Tzcy 1uEGZiieOl/2wzucYHkD3gY9KF9mjRT9oxZxm4bF82TbJBU0tBL+njqK/plTt1IW LpGASa/XHhq0aROebNBlDAe/wt7f2K9zpy4+rJXCPEkfNo1c8J0ndXZQ42HVQbWG k12Md0zX/a9RlOv1Iba9EFFIMMPOBdN3i9DOLcY6H22RaOITSFXkEKpJkhMMyqBQ 0Ae2P3eVRUP80SaUBjtsFGB6SpoUNnaXn77fe5BwairFJoBC2PijR4hU4mEHf5Ok HDuYuPL7EsGS0tW38+25KddHGBSKc8CLQb4d8M4Dn/NMQjLgkA5mQ5ZBiiP2Jgu8 GFjli3H+T3YNPE3Drsj2cZY+XCWGcH62Kg5XWRhYT4dO4/EbgrahVqY9RCsICsNr 65BLxJwvLrQfS7Nd/BWu =oovN -----END PGP SIGNATURE----- --Apple-Mail=_C3F94373-5D62-4117-9FA1-4B02A3BB9E52-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 09:54:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9DED8F72; Wed, 23 Jan 2013 09:54:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E2DCE6C2; Wed, 23 Jan 2013 09:54:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0N9sGm1049005; Wed, 23 Jan 2013 11:54:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0N9sGm1049005 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0N9sEHv049004; Wed, 23 Jan 2013 11:54:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Jan 2013 11:54:14 +0200 From: Konstantin Belousov To: Kohji Okuno Subject: Re: deadlock between g_event and a thread on removing a device. Message-ID: <20130123095414.GU2522@kib.kiev.ua> References: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8MIuRhPDBHHz1F6y" Content-Disposition: inline In-Reply-To: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: ae@freebsd.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 09:54:24 -0000 --8MIuRhPDBHHz1F6y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote: > Hi, >=20 > When I removed a device (ex. /dev/da0), I have encounterd a > dead-lock between ``g_event'' thread and a thread that is opening > device file (I call this thread as A). >=20 > Would you refer the following? >=20 > When the device is removed between dev_refthread() and g_dev_open(), > thread A incremented dev->si_threadcount, but can't acquire > topology_lock. >=20 > On the other hand, g_event is waiting to set dev->si_threadcount to 0 > with topology_lock. >=20 > Regards, > Kohji Okuno >=20 >=20 > <<< Thread A >>> > ... > devfs_open() > { > ... > dsw =3D dev_refthread(dev, &ref); <=3D increment dev->si_threadcount > ... > error =3D dsw->d_open(...); <=3D call g_dev_open() > ... > dev_relthread(dev, ref); <=3D decrement dev->si_threadcount > } >=20 > g_dev_open() > { > ... > g_topology_lock(); <=3D Thread A couldn't acquire=20 > ... topology_lock. > } >=20 > <<< g_event >>> > g_run_events() > { > ... > g_topology_lock(); <=3D g_event acuired topology_lock here. > ... > one_event() > ... > } >=20 > one_event() > g_orphan_register() > g_dev_orphan() > destroy_dev() > destroy_dev() > destroy_devl() > { > ... > while (dev->si_threadcount !=3D 0) { <=3D this count was incremented by= Thread A > /* Use unique dummy wait ident */ > msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > } > ... > } Yes, you are absolutely right. I believe there were some patches floating around which changed the destroy_dev() call in the g_dev_orphan() to destroy_dev_sched(). I do not remember who was the author. My reply was that naive substitution of the destroy_dev() to destroy_dev_sched() is racy, because some requests might still come in after the call to destroy_dev_sched(). Despite destroy_dev_sched() setting the CDP_SCHED_DTR flag on the devfs node, some thread might already entered the cdevsw method. I do not believe that there was further progress there. --8MIuRhPDBHHz1F6y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/7NFAAoJEJDCuSvBvK1BudYP/j4awPTFvuXcmeShTVrIRgix guS7LxPnWNAFJztRiKSu1SiYGFY0lwyrAru9+L/pPaUwPsiHFGTwCHeqcXQIRv8l mD3+8vx1M6ynXeVf39ACVB1Fxro5W9gyrj7f/z04sgjDY0vg4q0hswBEyZ0N1ROU TF69g1De2GLfgOhm5SnXzmhPRbrcA4vJV5z35nmE1FV2uhyvGNmVrQlHSKepSq5C xI7Pr/hpStJu1sFTt6aNlJAMjqQnvdzXDkYAq5QfQRzVeXionyVDv3rDgL3PoMJg pGvsc4CsMqozBhNF0Bk2kHVSyXpXA/J+/oJutGarIEPyHJDj8xcJG6UG+2N7KyTU O8KhRDj2k+LfwHzk3Rbl7SuWGyKGl47zmBrjrEFK7zavVHpxjN7ox5M/68WAcTCE 0c26MuMWTZ7PTRe/zibQTW2I0v1EjmlWk4S5eM1dZSn1STtcm6dJ2fF0dYClm1rY zt4yeASiAPSl3gVuNL8tGA6KYbkihTei0Fdhvbd7aSmpYoZ6yfoTiU6BOIIyueiE 40T5Bs0NEEPp2BtLEXRelW8fIvgCVegwrPLwIesVHA7D9J7omS+BPTyJZanFxoHc AobMYzxk/8B22CkPtswCtJb51QcRts29xPPolJ56lFG0ObUMl11M0lIvsP2rmzd9 ZaK+3a7WiezyXjSqbReO =xJf+ -----END PGP SIGNATURE----- --8MIuRhPDBHHz1F6y-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 10:08:04 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6D124F9; Wed, 23 Jan 2013 10:08:04 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 408D177F; Wed, 23 Jan 2013 10:08:03 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id r0NA7v3k004048; Wed, 23 Jan 2013 19:07:57 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili12) with ESMTP id r0NA7uG12602; Wed, 23 Jan 2013 19:07:56 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi13) id r0NA7tMH010780; Wed, 23 Jan 2013 19:07:55 +0900 Received: from localhost by lomi13.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id r0NA7t0r010757; Wed, 23 Jan 2013 19:07:55 +0900 Date: Wed, 23 Jan 2013 19:07:54 +0900 (JST) Message-Id: <20130123.190754.558674226904055738.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: deadlock between g_event and a thread on removing a device. From: Kohji Okuno In-Reply-To: <20130123095414.GU2522@kib.kiev.ua> References: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> <20130123095414.GU2522@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ae@freebsd.org, freebsd-current@FreeBSD.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 10:08:04 -0000 Hi Konstantin, Thank you for your comment. I don't have any solution for this issue. And when a device is removed suddenly, there are other problems, I think. > On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote: >> Hi, >> >> When I removed a device (ex. /dev/da0), I have encounterd a >> dead-lock between ``g_event'' thread and a thread that is opening >> device file (I call this thread as A). >> >> Would you refer the following? >> >> When the device is removed between dev_refthread() and g_dev_open(), >> thread A incremented dev->si_threadcount, but can't acquire >> topology_lock. >> >> On the other hand, g_event is waiting to set dev->si_threadcount to 0 >> with topology_lock. >> >> Regards, >> Kohji Okuno >> >> >> <<< Thread A >>> >> ... >> devfs_open() >> { >> ... >> dsw = dev_refthread(dev, &ref); <= increment dev->si_threadcount >> ... >> error = dsw->d_open(...); <= call g_dev_open() >> ... >> dev_relthread(dev, ref); <= decrement dev->si_threadcount >> } >> >> g_dev_open() >> { >> ... >> g_topology_lock(); <= Thread A couldn't acquire >> ... topology_lock. >> } >> >> <<< g_event >>> >> g_run_events() >> { >> ... >> g_topology_lock(); <= g_event acuired topology_lock here. >> ... >> one_event() >> ... >> } >> >> one_event() >> g_orphan_register() >> g_dev_orphan() >> destroy_dev() >> destroy_dev() >> destroy_devl() >> { >> ... >> while (dev->si_threadcount != 0) { <= this count was incremented by Thread A >> /* Use unique dummy wait ident */ >> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); >> } >> ... >> } > > Yes, you are absolutely right. > > I believe there were some patches floating around which changed the > destroy_dev() call in the g_dev_orphan() to destroy_dev_sched(). I do > not remember who was the author. > > My reply was that naive substitution of the destroy_dev() to > destroy_dev_sched() is racy, because some requests might still come > in after the call to destroy_dev_sched(). Despite destroy_dev_sched() > setting the CDP_SCHED_DTR flag on the devfs node, some thread might > already entered the cdevsw method. I do not believe that there was > further progress there. From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 12:11:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51009347; Wed, 23 Jan 2013 12:11:30 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 20DA4D83; Wed, 23 Jan 2013 12:11:30 +0000 (UTC) Received: from eee.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id A958D19781; Wed, 23 Jan 2013 21:11:28 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [192.168.1.108]) (authenticated bits=0) by eee.bbnest.net (8.14.6/8.14.5) with ESMTP id r0NCBLNe097795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jan 2013 21:11:22 +0900 (JST) (envelope-from bland@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS + usb in trouble? From: Alexander Nedotsukov In-Reply-To: <20130122181012.GD1714@garage.freebsd.pl> Date: Wed, 23 Jan 2013 21:11:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130121205851.GB1341@garage.freebsd.pl> <20130121211718.GD1341@garage.freebsd.pl> <20130122181012.GD1714@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jan 23 21:11:28 2013 X-DSPAM-Confidence: 0.9996 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50ffd370977962915317530 Cc: FreeBSD Current , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 12:11:30 -0000 On 23.01.2013, at 3:10, Pawel Jakub Dawidek wrote: > On Tue, Jan 22, 2013 at 11:47:29PM +0900, Alexander Nedotsukov wrote: >> Hi Pawel, >>=20 >> Here what I did. >>=20 >> # geli onetime -a hmac/sha1 -s 4096 /dev/da5=20 >> # dmesg | tail -15 >> wlan0: link state changed to UP >> ugen5.4: at usbus5 >> umass2: on usbus5 >> umass2: SCSI over Bulk-Only; quirks =3D 0x0100 >> umass2:4:2:-1: Attached to scbus4 >> da5 at umass-sim2 bus 2 scbus4 target 0 lun 0 >> da5: Removable Direct Access SCSI-2 device=20 >> da5: 40.000MB/s transfers >> da5: 983MB (2015231 512 byte sectors: 64H 32S/T 983C) >> GEOM_ELI: Device da5.eli created. >> GEOM_ELI: Encryption: AES-XTS 128 >> GEOM_ELI: Integrity: HMAC/SHA1 >> GEOM_ELI: Crypto: software >> GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at = offset 4096. >> GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at = offset 0. >>=20 >> # dd if=3D/dev/random of=3D/dev/da5.eli bs=3D1m >> dd: /dev/da5.eli: short write on character device >> dd: /dev/da5.eli: end of device >> 875+0 records in >> 874+1 records out >> 917151744 bytes transferred in 1530.831674 secs (599120 bytes/sec) >>=20 >> # dd if=3D/dev/da5.eli of=3D/dev/null bs=3D1m >> 874+1 records in >> 874+1 records out >> 917151744 bytes transferred in 178.874312 secs (5127353 bytes/sec) >>=20 >> All clear. No new errors. >>=20 >> Zpool created on the same usb stick is still failing with cksum = errors. >>=20 >> # usbconfig -d 5.4 add_quirk UQ_MSC_NO_SYNC_CACHE >>=20 >> umass2: SCSI over Bulk-Only; quirks =3D 0x4000 >>=20 >> Re-created zpool is still failing with cksum errors. Every new scrub = run is triggering another "repairing". >=20 > Interesting. Can you put ZFS on top of GELI with authentication after > filling da0.eli with random random and see if GELI will report > corruption when ZFS will or if only ZFS will report corruption? And now both are failing, although zfs in a different way. # zpool status pool: testpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are = unaffected. action: Determine if the device needs to be replaced, and clear the = errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 1M in 0h2m with 0 errors on Wed Jan 23 20:57:11 = 2013 config: NAME STATE READ WRITE CKSUM testpool ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da5.elid ONLINE 0 0 0 da5.elie ONLINE 21 0 0 da5.elif ONLINE 0 0 0 # dmesg | tail -20 GEOM_ELI: da1.eli: Failed to authenticate 131072 bytes of data at offset = 1010827264. ath0: bb hang detected (0x4), resetting GEOM_ELI: Device da5.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Integrity: HMAC/SHA1 GEOM_ELI: Crypto: software GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset = 4096. GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset = 0. GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset = 229288288. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset = 229429248. GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset = 229298176. GEOM_ELI: da5.eli: Failed to authenticate 26496 bytes of data at offset = 229494784. GEOM_ELI: da5.eli: Failed to authenticate 12288 bytes of data at offset = 270299136. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset = 270319616. GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset = 273095488. GEOM_ELI: da5.eli: Failed to authenticate 56864 bytes of data at offset = 273105376. GEOM_ELI: da5.eli: Failed to authenticate 2400 bytes of data at offset = 273326080. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset = 272560128. GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset = 272429056. GEOM_ELI: da5.eli: Failed to authenticate 32768 bytes of data at offset = 272396288. From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 13:45:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59E29B86; Wed, 23 Jan 2013 13:45:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id E7E6F22E; Wed, 23 Jan 2013 13:45:27 +0000 (UTC) Received: from localhost (unknown [86.188.145.194]) by mail.dawidek.net (Postfix) with ESMTPSA id 105FDD97; Wed, 23 Jan 2013 14:42:51 +0100 (CET) Date: Wed, 23 Jan 2013 14:46:02 +0100 From: Pawel Jakub Dawidek To: Alexander Nedotsukov Subject: Re: ZFS + usb in trouble? Message-ID: <20130123134601.GB53514@garage.freebsd.pl> References: <20130121205851.GB1341@garage.freebsd.pl> <20130121211718.GD1341@garage.freebsd.pl> <20130122181012.GD1714@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" 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 , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 13:45:28 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2013 at 09:11:23PM +0900, Alexander Nedotsukov wrote: > And now both are failing, although zfs in a different way. Yes, but now we are sure this is not ZFS issue. Sequential read simply doesn't trigger the corruption, but ZFS access patterns do. The read errors you are seeing are due to GELI returning EIO on integrity verification error. > # zpool status > pool: testpool > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 1M in 0h2m with 0 errors on Wed Jan 23 20:57:11 20= 13 > config: >=20 > NAME STATE READ WRITE CKSUM > testpool ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da5.elid ONLINE 0 0 0 > da5.elie ONLINE 21 0 0 > da5.elif ONLINE 0 0 0 >=20 > # dmesg | tail -20 > GEOM_ELI: da1.eli: Failed to authenticate 131072 bytes of data at offset = 1010827264. > ath0: bb hang detected (0x4), resetting > GEOM_ELI: Device da5.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Integrity: HMAC/SHA1 > GEOM_ELI: Crypto: software > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 40= 96. > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 0. > GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset 22= 9288288. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 2= 29429248. > GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset = 229298176. > GEOM_ELI: da5.eli: Failed to authenticate 26496 bytes of data at offset 2= 29494784. > GEOM_ELI: da5.eli: Failed to authenticate 12288 bytes of data at offset 2= 70299136. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 2= 70319616. > GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset 27= 3095488. > GEOM_ELI: da5.eli: Failed to authenticate 56864 bytes of data at offset 2= 73105376. > GEOM_ELI: da5.eli: Failed to authenticate 2400 bytes of data at offset 27= 3326080. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 2= 72560128. > GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset = 272429056. > GEOM_ELI: da5.eli: Failed to authenticate 32768 bytes of data at offset 2= 72396288. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD/6ZkACgkQForvXbEpPzSD5ACg8k7swASI51QRNekbauTup5Jm 2GcAoPIhUumysLxngIrxY15Z3G1y/M4Z =wkZg -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 15:43:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 178E2605 for ; Wed, 23 Jan 2013 15:43:38 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id 016DEB3F for ; Wed, 23 Jan 2013 15:43:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,523,1355126400"; d="scan'208";a="6032922" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 23 Jan 2013 07:43:37 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0NFhaDZ023838 for ; Wed, 23 Jan 2013 07:43:37 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 07:43:36 -0800 From: "Eggert, Lars" To: "freebsd-current@freebsd.org" Subject: serial console not accepting input? Thread-Topic: serial console not accepting input? Thread-Index: AQHN+YBoyi5llRmNskaJJfjFwBFvjg== Date: Wed, 23 Jan 2013 15:43:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <7FEDF5F3EA6BC643B93E42B7E68FDC51@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 15:43:38 -0000 Hi, I'm embarrassed to ask this newbie question, but I'm at my wit's end: I've = configured a serial console according to the handbook. I see the boot messa= ges and get the login prompt. But at no point during the boot process does = the console seem to accept any input, incl. when at the boot prompt. The sa= me serial setup works fine with other boxes. Any ideas? Thanks, Lars= From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 16:04:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2726FF20 for ; Wed, 23 Jan 2013 16:04:49 +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 DF37AD62 for ; Wed, 23 Jan 2013 16:04:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2150:ab85:542c:b811] (unknown [IPv6:2001:7b8:3a7:0:2150:ab85:542c:b811]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A83065C43; Wed, 23 Jan 2013 17:04:40 +0100 (CET) Message-ID: <51000A18.1020001@FreeBSD.org> Date: Wed, 23 Jan 2013 17:04:40 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Eggert, Lars" , "freebsd-current@freebsd.org" Subject: Re: serial console not accepting input? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 16:04:49 -0000 On 2013-01-23 16:43, Eggert, Lars wrote: > I'm embarrassed to ask this newbie question, but I'm at my wit's end: I've configured a serial console according to the handbook. I see the boot messages and get the login prompt. But at no point during the boot process does the console seem to accept any input, incl. when at the boot prompt. The same serial setup works fine with other boxes. > > Any ideas? CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default settings in /etc/gettytab, or make a specific entry with an added ":hw" setting. If it is a physical serial console, you could also simply have a bad cable. Try swapping it with working system. :) From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 16:33:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4A27C87 for ; Wed, 23 Jan 2013 16:33:02 +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 CA2C2F06 for ; Wed, 23 Jan 2013 16:33:01 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5CFB07300B; Wed, 23 Jan 2013 17:32:38 +0100 (CET) Date: Wed, 23 Jan 2013 17:32:38 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ? Message-ID: <20130123163238.GB56212@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 16:33:02 -0000 Probably our compiler folks have some ideas on this... When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, __builtin_memcpy() was even worse, and so i ended up writing my custom routine, (called pkt_copy() in the program below). This happens with gcc 4.2.1, clang, gcc 4.6.4 I was then surprised to notice that on a recent ubuntu using gcc 4.6.2 (if that matters) the __builtin_memcpy beats other methods by a large factor. Here are the number in millions of calls per second. Is the test program flawed, or the compiler is built with different options ? Unfortunately i have no chance to run the two versions of the code on the same machine, but the hardware should be relatively similar (i7-2600 i@ 3.4 GHz on one, Xeon E5-1650 @ 3.2 GHz on the other) BSD / Linux block size (bytes) 31 32 64 2048 __builtin_memcpy 10 / 150 13 / 158 13 / 152 5.1 / 23.2 memcpy 23 / 64 47 / 64 45 / 64 5.4 / 3.8 bcopy 24 / 64 47 / 64 45 / 63 5.4 / 3.8 pkt_copy 65 / 63 65 / 63 64 / 63 5.5 / 3.7 cheers luigi /* * Copyright (C) 2012 Luigi Rizzo. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ /* * $Id: testlock.c 12015 2013-01-23 15:51:17Z luigi $ * * Test program to study various ops and concurrency issues. * Create multiple threads, possibly bind to cpus, and run a workload. * * cc -O2 -Werror -Wall testlock.c -o testlock -lpthread * you might need -lrt */ #include #include #include /* pthread_* */ #if defined(__APPLE__) #include #define atomic_add_int(p, n) OSAtomicAdd32(n, (int *)p) #define atomic_cmpset_32(p, o, n) OSAtomicCompareAndSwap32(o, n, (int *)p) #elif defined(linux) int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #if defined(HAVE_GCC_ATOMICS) int atomic_add_int(volatile int *p, int v) { return __sync_fetch_and_add(p, v); } #else inline uint32_t atomic_add_int(uint32_t *p, int v) { __asm __volatile ( " lock xaddl %0, %1 ; " : "+r" (v), /* 0 (result) */ "=m" (*p) /* 1 */ : "m" (*p)); /* 2 */ return (v); } #endif #else /* FreeBSD */ #include #include #include /* pthread w/ affinity */ #if __FreeBSD_version > 500000 #include /* cpu_set */ #if __FreeBSD_version > 800000 #define HAVE_AFFINITY #endif inline void prefetch (const void *x) { __asm volatile("prefetcht0 %0" :: "m" (*(const unsigned long *)x)); } #else /* FreeBSD 4.x */ int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #define PRIu64 "llu" #endif /* FreeBSD 4.x */ #endif /* FreeBSD */ #include /* signal */ #include #include #include #include /* PRI* macros */ #include /* strcmp */ #include /* open */ #include /* getopt */ #include /* sysctl */ #include /* timersub */ static inline int min(int a, int b) { return a < b ? a : b; } #define ONE_MILLION 1000000 /* debug support */ #define ND(format, ...) #define D(format, ...) \ fprintf(stderr, "%s [%d] " format "\n", \ __FUNCTION__, __LINE__, ##__VA_ARGS__) int verbose = 0; #if 1//def MY_RDTSC /* Wrapper around `rdtsc' to take reliable timestamps flushing the pipeline */ #define my_rdtsc(t) \ do { \ u_int __regs[4]; \ \ do_cpuid(0, __regs); \ (t) = rdtsc(); \ } while (0) static __inline void do_cpuid(u_int ax, u_int *p) { __asm __volatile("cpuid" : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) : "0" (ax) ); } static __inline uint64_t rdtsc(void) { uint64_t rv; // XXX does not work on linux-64 bit __asm __volatile("rdtscp" : "=A" (rv) : : "%rax"); return (rv); } #endif /* 1 */ struct targ; /*** global arguments for all threads ***/ struct glob_arg { struct { uint32_t ctr[1024]; } v __attribute__ ((aligned(256) )); int64_t m_cycles; /* total cycles */ int nthreads; int cpus; int privs; // 1 if has IO privileges int arg; // microseconds in usleep char *test_name; void (*fn)(struct targ *); uint64_t scale; // scaling factor char *scale_name; // scaling factor }; /* * Arguments for a new thread. */ struct targ { struct glob_arg *g; int completed; u_int *glob_ctr; uint64_t volatile count; struct timeval tic, toc; int me; pthread_t thread; int affinity; }; static struct targ *ta; static int global_nthreads; /* control-C handler */ static void sigint_h(int sig) { int i; (void)sig; /* UNUSED */ for (i = 0; i < global_nthreads; i++) { /* cancel active threads. */ if (ta[i].completed) continue; D("Cancelling thread #%d\n", i); pthread_cancel(ta[i].thread); ta[i].completed = 0; } signal(SIGINT, SIG_DFL); } /* sysctl wrapper to return the number of active CPUs */ static int system_ncpus(void) { #ifdef linux return 1; #else int mib[2] = { CTL_HW, HW_NCPU}, ncpus; size_t len = sizeof(mib); sysctl(mib, len / sizeof(mib[0]), &ncpus, &len, NULL, 0); D("system had %d cpus", ncpus); return (ncpus); #endif } /* * try to get I/O privileges so we can execute cli/sti etc. */ int getprivs(void) { int fd = open("/dev/io", O_RDWR); if (fd < 0) { D("cannot open /dev/io, fd %d", fd); return 0; } return 1; } /* set the thread affinity. */ /* ARGSUSED */ #ifdef HAVE_AFFINITY static int setaffinity(pthread_t me, int i) { cpuset_t cpumask; if (i == -1) return 0; /* Set thread affinity affinity.*/ CPU_ZERO(&cpumask); CPU_SET(i, &cpumask); if (pthread_setaffinity_np(me, sizeof(cpuset_t), &cpumask) != 0) { D("Unable to set affinity"); return 1; } return 0; } #endif static void * td_body(void *data) { struct targ *t = (struct targ *) data; #ifdef HAVE_AFFINITY if (0 == setaffinity(t->thread, t->affinity)) #endif { /* main loop.*/ D("testing %ld cycles", t->g->m_cycles); gettimeofday(&t->tic, NULL); t->g->fn(t); gettimeofday(&t->toc, NULL); } t->completed = 1; return (NULL); } void test_sel(struct targ *t) { int64_t m; for (m = 0; m < t->g->m_cycles; m++) { fd_set r; struct timeval to = { 0, t->g->arg}; FD_ZERO(&r); FD_SET(0,&r); // FD_SET(1,&r); select(1, &r, NULL, NULL, &to); t->count++; } } void test_poll(struct targ *t) { int64_t m, ms = t->g->arg/1000; for (m = 0; m < t->g->m_cycles; m++) { struct pollfd x; x.fd = 0; x.events = POLLIN; poll(&x, 1, ms); t->count++; } } void test_usleep(struct targ *t) { int64_t m; for (m = 0; m < t->g->m_cycles; m++) { usleep(t->g->arg); t->count++; } } void test_cli(struct targ *t) { int64_t m, i; if (!t->g->privs) { D("%s", "privileged instructions not available"); return; } for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("cli;"); __asm __volatile("and %eax, %eax;"); __asm __volatile("sti;"); t->count++; } } } void test_nop(struct targ *t) { int64_t m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("nop;"); __asm __volatile("nop; nop; nop; nop; nop;"); //__asm __volatile("nop; nop; nop; nop; nop;"); t->count++; } } } void test_rdtsc1(struct targ *t) { int64_t m, i; uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { my_rdtsc(v); t->count++; } } } void test_rdtsc(struct targ *t) { int64_t m, i; volatile uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { v = rdtsc(); t->count++; } } } void test_add(struct targ *t) { int64_t m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { t->glob_ctr[0] ++; t->count++; } } } void test_atomic_add(struct targ *t) { int64_t m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_add_int(t->glob_ctr, 1); t->count++; } } } void test_atomic_cmpset(struct targ *t) { int64_t m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_cmpset_32(t->glob_ctr, m, i); t->count++; } } } void test_time(struct targ *t) { int64_t m; for (m = 0; m < t->g->m_cycles; m++) { #ifndef __APPLE__ struct timespec ts; clock_gettime(t->g->arg, &ts); #endif t->count++; } } void test_gettimeofday(struct targ *t) { int64_t m; struct timeval ts; for (m = 0; m < t->g->m_cycles; m++) { gettimeofday(&ts, NULL); t->count++; } } /* * getppid is the simplest system call (getpid is cached by glibc * so it would not be a good test) */ void test_getpid(struct targ *t) { int64_t m; for (m = 0; m < t->g->m_cycles; m++) { getppid(); t->count++; } } #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) static void fast_bcopy(void *_src, void *_dst, int l) { uint64_t *src = _src; uint64_t *dst = _dst; if (unlikely(l >= 1024)) { bcopy(src, dst, l); return; } for (; likely(l > 0); l-=64) { *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; } } // XXX if you want to make sure there is no inlining... // static void (*fp)(void *_src, void *_dst, int l) = fast_bcopy; #define HU 0x3ffff static struct glob_arg huge[HU+1]; void test_fastcopy(struct targ *t) { int64_t m; int len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("fast copying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { fast_bcopy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_bcopy(struct targ *t) { int64_t m; int len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("bcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { bcopy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_builtin_memcpy(struct targ *t) { int64_t m; int len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("bcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { __builtin_memcpy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_memcpy(struct targ *t) { int64_t m; int len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("memcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { memcpy((void *)&huge[m & HU], t->g, len); t->count+=1; } } struct entry { void (*fn)(struct targ *); char *name; uint64_t scale; uint64_t m_cycles; }; struct entry tests[] = { { test_sel, "select", 1, 1000 }, { test_poll, "poll", 1, 1000 }, { test_usleep, "usleep", 1, 1000 }, { test_time, "time", 1, 1000 }, { test_gettimeofday, "gettimeofday", 1, 1000000 }, { test_getpid, "getpid", 1, 1000000 }, { test_bcopy, "bcopy", 1000, 100000000 }, { test_builtin_memcpy, "__builtin_memcpy", 1000, 100000000 }, { test_memcpy, "memcpy", 1000, 100000000 }, { test_fastcopy, "fastcopy", 1000, 100000000 }, { test_add, "add", ONE_MILLION, 100000000 }, { test_nop, "nop", ONE_MILLION, 100000000 }, { test_atomic_add, "atomic-add", ONE_MILLION, 100000000 }, { test_cli, "cli", ONE_MILLION, 100000000 }, { test_rdtsc, "rdtsc", ONE_MILLION, 100000000 }, // unserialized { test_rdtsc1, "rdtsc1", ONE_MILLION, 100000000 }, // serialized { test_atomic_cmpset, "cmpset", ONE_MILLION, 100000000 }, { NULL, NULL, 0, 0 } }; static void usage(void) { const char *cmd = "test"; int i; fprintf(stderr, "Usage:\n" "%s arguments\n" "\t-m name test name\n" "\t-n cycles (millions) of cycles\n" "\t-l arg bytes, usec, ... \n" "\t-t threads total threads\n" "\t-c cores cores to use\n" "\t-a n force affinity every n cores\n" "\t-A n cache contention every n bytes\n" "\t-w report_ms milliseconds between reports\n" "", cmd); fprintf(stderr, "Available tests:\n"); for (i = 0; tests[i].name; i++) { fprintf(stderr, "%12s\n", tests[i].name); } exit(0); } static int64_t getnum(const char *s) { int64_t n; char *e; n = strtol(s, &e, 0); switch (e ? *e : '\0') { case 'k': case 'K': return n*1000; case 'm': case 'M': return n*1000*1000; case 'g': case 'G': return n*1000*1000*1000; case 't': case 'T': return n*1000*1000*1000*1000; default: return n; } } struct glob_arg g; int main(int argc, char **argv) { int i, ch, report_interval, affinity, align; ND("g has size %d", (int)sizeof(g)); report_interval = 250; /* ms */ affinity = 0; /* no affinity */ align = 0; /* global variable */ bzero(&g, sizeof(g)); g.privs = getprivs(); g.nthreads = 1; g.cpus = 1; g.m_cycles = 0; while ( (ch = getopt(argc, argv, "A:a:m:n:w:c:t:vl:")) != -1) { switch(ch) { default: D("bad option %c %s", ch, optarg); usage(); break; case 'A': /* align */ align = atoi(optarg); break; case 'a': /* force affinity */ affinity = atoi(optarg); break; case 'n': /* cycles */ g.m_cycles = getnum(optarg); break; case 'w': /* report interval */ report_interval = atoi(optarg); break; case 'c': g.cpus = atoi(optarg); break; case 't': g.nthreads = atoi(optarg); break; case 'm': g.test_name = optarg; break; case 'l': g.arg = getnum(optarg); break; case 'v': verbose++; break; } } argc -= optind; argv += optind; if (!g.test_name && argc > 0) g.test_name = argv[0]; if (g.test_name) { for (i = 0; tests[i].name; i++) { if (!strcmp(g.test_name, tests[i].name)) { g.fn = tests[i].fn; g.scale = tests[i].scale; if (g.m_cycles == 0) g.m_cycles = tests[i].m_cycles; if (g.scale == ONE_MILLION) g.scale_name = "M"; else if (g.scale == 1000) g.scale_name = "K"; else { g.scale = 1; g.scale_name = ""; } break; } } } if (!g.fn) { D("%s", "missing/unknown test name"); usage(); } i = system_ncpus(); if (g.cpus < 0 || g.cpus > i) { D("%d cpus is too high, have only %d cpus", g.cpus, i); usage(); } if (g.cpus == 0) g.cpus = i; if (g.nthreads < 1) { D("bad nthreads %d, using 1", g.nthreads); g.nthreads = 1; } i = sizeof(g.v.ctr) / g.nthreads*sizeof(g.v.ctr[0]); if (align < 0 || align > i) { D("bad align %d, max is %d", align, i); align = i; } /* Install ^C handler. */ global_nthreads = g.nthreads; signal(SIGINT, sigint_h); ta = calloc(g.nthreads, sizeof(*ta)); /* * Now create the desired number of threads, each one * using a single descriptor. */ D("start %d threads on %d cores", g.nthreads, g.cpus); for (i = 0; i < g.nthreads; i++) { struct targ *t = &ta[i]; bzero(t, sizeof(*t)); t->g = &g; t->me = i; t->glob_ctr = &g.v.ctr[(i*align)/sizeof(g.v.ctr[0])]; D("thread %d ptr %p", i, t->glob_ctr); t->affinity = affinity ? (affinity*i) % g.cpus : -1; if (pthread_create(&t->thread, NULL, td_body, t) == -1) { D("Unable to create thread %d", i); t->completed = 1; } } /* the main loop */ { uint64_t my_count = 0, prev = 0; uint64_t count = 0; double delta_t; struct timeval tic, toc; gettimeofday(&toc, NULL); for (;;) { struct timeval now, delta; uint64_t pps; int done = 0; delta.tv_sec = report_interval/1000; delta.tv_usec = (report_interval%1000)*1000; select(0, NULL, NULL, NULL, &delta); gettimeofday(&now, NULL); timersub(&now, &toc, &toc); my_count = 0; for (i = 0; i < g.nthreads; i++) { my_count += ta[i].count; if (ta[i].completed) done++; } pps = toc.tv_sec* ONE_MILLION + toc.tv_usec; if (pps < 10000) continue; pps = (my_count - prev)*ONE_MILLION / pps; D("%" PRIu64 " %scycles/s scale %" PRIu64 " in %dus", pps/g.scale, g.scale_name, g.scale, (int)(toc.tv_sec* ONE_MILLION + toc.tv_usec)); prev = my_count; toc = now; if (done == g.nthreads) break; } D("total %" PRIu64 " cycles", prev); timerclear(&tic); timerclear(&toc); for (i = 0; i < g.nthreads; i++) { pthread_join(ta[i].thread, NULL); if (ta[i].completed == 0) continue; /* * Collect threads o1utput and extract information about * how log it took to send all the packets. */ count += ta[i].count; if (!timerisset(&tic) || timercmp(&ta[i].tic, &tic, <)) tic = ta[i].tic; if (!timerisset(&toc) || timercmp(&ta[i].toc, &toc, >)) toc = ta[i].toc; } /* print output. */ timersub(&toc, &tic, &toc); delta_t = toc.tv_sec + 1e-6* toc.tv_usec; D("total %8.6f seconds", delta_t); } return (0); } /* end of file */ From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 18:20:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89FA328D for ; Wed, 23 Jan 2013 18:20:39 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 70A176A5 for ; Wed, 23 Jan 2013 18:20:39 +0000 (UTC) Received: from jemac.thefacebook.com (unknown [173.252.71.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 865EF286E2; Wed, 23 Jan 2013 10:20:33 -0800 (PST) Subject: Re: Compilation error (pkgng) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: Date: Wed, 23 Jan 2013 10:20:32 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 18:20:39 -0000 On Jan 23, 2013, at 12:14 AM, Alie Tan wrote: > Seems this check-in causing compilation error: > > http://freshbsd.org/commit/freebsd/r245828 > > -nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o > /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')' > rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite", > pkgngdir); > ^ > /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '(' > rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite", > pkgngdir); > ^ > /usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of > integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] > if (rc >= sizeof(pkgngpath)) { > ~~ ^ ~~~~~~~~~~~~~~~~~ > 1 warning and 1 error generated. Fixed by r245837. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 19:26:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C06E7D3 for ; Wed, 23 Jan 2013 19:26:17 +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 D384D9B6 for ; Wed, 23 Jan 2013 19:26:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2150:ab85:542c:b811] (unknown [IPv6:2001:7b8:3a7:0:2150:ab85:542c:b811]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 899955C43; Wed, 23 Jan 2013 20:26:15 +0100 (CET) Message-ID: <51003956.50301@FreeBSD.org> Date: Wed, 23 Jan 2013 20:26:14 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Luigi Rizzo , current@freebsd.org Subject: Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ? References: <20130123163238.GB56212@onelab2.iet.unipi.it> In-Reply-To: <20130123163238.GB56212@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 19:26:17 -0000 On 2013-01-23 17:32, Luigi Rizzo wrote: > Probably our compiler folks have some ideas on this... > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > __builtin_memcpy() was even worse, Which compilation flags did you use to test this? When I compiled your testcase program with clang 3.2, gcc 4.2 and gcc 4.7 at -O2, with all other settings at their defaults, all three compilers just called libc's memcpy() for the __builtin_memcpy tests. For example, with gcc 4.7, the loop in test_builtin_memcpy becomes: .L116: movq %rbx, %rax addq $1, %rbx andl $262143, %eax movq %rax, %rdx salq $12, %rax salq $8, %rdx leaq huge(%rdx,%rax), %rsi movq %r12, %rdx call memcpy movq 24(%rbp), %rax movq 0(%rbp), %rdi addq $1, %rax cmpq %rbx, 4096(%rdi) movq %rax, 24(%rbp) jg .L116 The other routines are emitted as similar code. For test_bcopy() the loop becomes: .L123: movq %rbx, %rax addq $1, %rbx andl $262143, %eax movq %rax, %rdx salq $12, %rax salq $8, %rdx leaq huge(%rdx,%rax), %rsi movq %r12, %rdx call bcopy movq 24(%rbp), %rax movq 0(%rbp), %rdi addq $1, %rax cmpq %rbx, 4096(%rdi) movq %rax, 24(%rbp) jg .L123 and similarly, for test_memcpy() it becomes: .L109: movq %rbx, %rax addq $1, %rbx andl $262143, %eax movq %rax, %rdx salq $12, %rax salq $8, %rdx leaq huge(%rdx,%rax), %rdi movq %r12, %rdx call memcpy movq 24(%rbp), %rax movq 0(%rbp), %rsi addq $1, %rax cmpq %rbx, 4096(%rsi) movq %rax, 24(%rbp) jg .L109 In our libc, bcopy and memcpy are implemented from the same source file, which just the arguments swapped around. So I fail to see what could cause the performance difference between __builtin_memcpy, memcpy and bcopy you are seeing. Also, on amd64, this is implemented in lib/libc/amd64/string/bcopy.S, so the compiler does not have any influence on its performance. Note the routine uses "rep movsq" as its main loop, which is apparently not the best way on modern CPUs. Maybe you have found another instance where hand-rolled assembly is slower than compiler-optimized code... :-) With gcc 4.7, your fast_bcopy() gets inlined to this: .L131: movq (%rax), %rdx subl $64, %ecx movq %rdx, (%rsi) movq 8(%rax), %rdx movq %rdx, 8(%rsi) movq 16(%rax), %rdx movq %rdx, 16(%rsi) movq 24(%rax), %rdx movq %rdx, 24(%rsi) movq 32(%rax), %rdx movq %rdx, 32(%rsi) movq 40(%rax), %rdx movq %rdx, 40(%rsi) movq 48(%rax), %r9 movq %r9, 48(%rsi) movq 56(%rax), %r9 addq $64, %rax movq %r9, 56(%rsi) addq $64, %rsi testl %ecx, %ecx jg .L131 while clang 3.2 produces: .LBB14_5: movq (%rdi), %rcx movq %rcx, (%rsi) movq 8(%rdi), %rcx movq %rcx, 8(%rsi) movq 16(%rdi), %rcx movq %rcx, 16(%rsi) addl $-64, %eax movq 24(%rdi), %rcx movq %rcx, 24(%rsi) testl %eax, %eax movq 32(%rdi), %rcx movq %rcx, 32(%rsi) movq 40(%rdi), %rcx movq %rcx, 40(%rsi) movq 48(%rdi), %rcx movq %rcx, 48(%rsi) movq 56(%rdi), %rcx leaq 64(%rdi), %rdi movq %rcx, 56(%rsi) leaq 64(%rsi), %rsi jg .LBB14_5 Both are most likely faster than the "rep movsq" logic in bcopy.S. > and so i ended up writing > my custom routine, (called pkt_copy() in the program below). > This happens with gcc 4.2.1, clang, gcc 4.6.4 > > I was then surprised to notice that on a recent ubuntu using > gcc 4.6.2 (if that matters) the __builtin_memcpy beats other > methods by a large factor. On Ubuntu, I see the same thing as on FreeBSD; __builtin_memcpy just calls the regular memcpy. However, eglibc's memcpy looks to be more highly optimized; there are several CPU-specific implementations, for example for i386 and amd64 arches: sysdeps/i386/i586/memcpy_chk.S sysdeps/i386/i586/memcpy.S sysdeps/i386/i686/memcpy_chk.S sysdeps/i386/i686/memcpy.S sysdeps/i386/i686/multiarch/memcpy_chk.S sysdeps/i386/i686/multiarch/memcpy.S sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S sysdeps/i386/i686/multiarch/memcpy-ssse3.S sysdeps/x86_64/memcpy_chk.S sysdeps/x86_64/memcpy.S sysdeps/x86_64/multiarch/memcpy_chk.S sysdeps/x86_64/multiarch/memcpy.S sysdeps/x86_64/multiarch/memcpy-ssse3-back.S sysdeps/x86_64/multiarch/memcpy-ssse3.S Most likely, your test program on Ubuntu is calling the ssse3 version, which should be much faster than any of the above loops. > Here are the number in millions of calls per second. Is the test > program flawed, or the compiler is built with different options ? I think the test program looks fine after lightly skimming it. FreeBSD's memcpy is probably just slower for the CPUs you have been testing on. From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 19:29:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6B0A918 for ; Wed, 23 Jan 2013 19:29:51 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2E69E3 for ; Wed, 23 Jan 2013 19:29:51 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id b13so7831417vby.5 for ; Wed, 23 Jan 2013 11:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=imA63FCZL9RurQoLDbaCaab9Ww56uDIbVHTWsjsJfjM=; b=nGj84Zn/xp7JLY4QTuYsVxAxWLdZTSSa4r+HLzFJ4Me1EFuXvD6pqwEB+7qlGP5m6f UGGQnD9ek+tTlwu3HyH3Eu6ZvTBgR1zO0dUO8F+EcUkLCfarWA1/ixRtM139nbEnM8al NPNWmC4Fc815SGl/C5L09R6WKM58Hy6/3HCmo2vJjoqfA6/S65edIw+/u+5He7neJ8Y+ fG2Jbl96YXapISOPwnkCF3dN7KC8KKOaIrCnJaytMYV1p8+FFhkFtEM6HATEvRMSCnGW 2Jvdk2YbImK0PQHKF78dhO0T2+gjP9N0HSqTfG1P0AoCLe53ipZLqqOOWwDAZ7wmZXs6 OKFQ== MIME-Version: 1.0 X-Received: by 10.52.16.102 with SMTP id f6mr2426166vdd.12.1358969385749; Wed, 23 Jan 2013 11:29:45 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.123.2 with HTTP; Wed, 23 Jan 2013 11:29:45 -0800 (PST) In-Reply-To: <20130123163238.GB56212@onelab2.iet.unipi.it> References: <20130123163238.GB56212@onelab2.iet.unipi.it> Date: Wed, 23 Jan 2013 11:29:45 -0800 X-Google-Sender-Auth: 928PYZ4452NaqcnmUyyVfpL2QXo Message-ID: Subject: Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ? From: Artem Belevich To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 19:29:51 -0000 On Wed, Jan 23, 2013 at 8:32 AM, Luigi Rizzo wrote: > Probably our compiler folks have some ideas on this... > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > __builtin_memcpy() was even worse, and so i ended up writing > my custom routine, (called pkt_copy() in the program below). > This happens with gcc 4.2.1, clang, gcc 4.6.4 The program does not seem to have pkt_copy. It does have fast_bcopy. Is that the one you meant by pkt_copy? --Artem From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 19:51:18 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C7F86EBA; Wed, 23 Jan 2013 19:51:18 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 74C6CAC7; Wed, 23 Jan 2013 19:51:18 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 61ED313967E; Wed, 23 Jan 2013 21:51:05 +0200 (EET) Date: Wed, 23 Jan 2013 21:51:04 +0200 From: Jaakko Heinonen To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130123195104.GA1802@a91-153-116-96.elisa-laajakaista.fi> References: <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> <20130123071346.GA56937@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123071346.GA56937@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 19:51:18 -0000 On 2013-01-23, Vitalij Satanivskij wrote: > VS> Jaakko Heinonen wrote: > VS> JH> > I see two possible solutions for the problem. > VS> JH> > > VS> JH> > 1) Replace non-printable, space and '/' characters for example with '_'. > VS> JH> > '/' should be replaced anyway. > VS> JH> > > VS> JH> > 2) Apply the patches in > VS> JH> > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html > VS> JH> > to allow spaces again. I haven't committed the patches because I > VS> JH> > think that there isn't full consensus that it's right thing to do and > VS> JH> > also I personally prefer not to have spaces in device names. > VS> JH> > VS> JH> Here's a patch to implement 1: > VS> JH> > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > VS> > VS> Ok that patch work's too. > > Is there any chance, that one of this patches will be merged to head? Yes. Alexander and Justin: what do you think about this patch? http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 20:24:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D23D9943; Wed, 23 Jan 2013 20:24:24 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6ACCF7; Wed, 23 Jan 2013 20:24:23 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id gf7so5535731lbb.4 for ; Wed, 23 Jan 2013 12:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mq8Zajx6crQEELE7LUURctnd+aBHpC7PbJF5snm0I94=; b=ccrdu4itPypgqmMLnkw7OO4RR3j6CvOJcR5JsKTxgPCRMoOlkH+Pqk9XoQthJb7XYF Dg3xR+sKd2U1O+atEoHjGAf8RzCmHYuYhk08KW1N0wYNQgTzcL6xkbmfnwGvsoVKnL6r ovQ8rK1bZXStQ4xK2ZsYAW21wyhqn5dERrOd4A8PiRHdGyLT4dpoPPuxo7MDfyOLRg3h gBED+o4wzZFSxNQbZWHus0ii2PIVcNAGhQWuTI13rBy5DtP0eJagUn2IFnGCGzDyb6go YxNbpng7kTIVEIx6AC8LX5Lzb+7eudMNTd6j7v/4r4mb1YQ7yi57KxjKJPgN/syCV0Ty Ikfw== MIME-Version: 1.0 X-Received: by 10.112.8.231 with SMTP id u7mr1135559lba.45.1358972657151; Wed, 23 Jan 2013 12:24:17 -0800 (PST) Received: by 10.67.2.65 with HTTP; Wed, 23 Jan 2013 12:24:16 -0800 (PST) In-Reply-To: References: <20130122175933.GD41700@FreeBSD.org> Date: Wed, 23 Jan 2013 12:24:16 -0800 Message-ID: Subject: Re: Adding more tools to be used by operator group members From: Kevin Oberman To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Cc: Olivier Cochard-Labb? , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 20:24:24 -0000 On Tue, Jan 22, 2013 at 10:38 AM, Adrian Chadd wrote: > Ah, the historical difference between shutdown -r and reboot.... > > > adrian > > On 22 January 2013 09:59, Gleb Smirnoff wrote: >> On Tue, Jan 22, 2013 at 02:03:12PM +0100, Olivier Cochard-Labb? wrote: >> O> There are only 2 useable tools by "operator" group members: >> O> shutdown (and its child: poweroff, halt, etc?) and mksnap_ffs. >> O> >> O> On my HAL-less laptop, I've put my user in the operator group that let >> O> me reboot/power-off it with shutdown. >> O> But I would to be able to suspend-resume it too (with zzz). >> O> >> O> Here is what I've did: >> O> for f in "/usr/sbin/acpiconf /usr/sbin/apm"; do >> O> chown :operator $f >> O> chmod 4550 $f >> O> done >> O> >> O> What about configuring this permission by default on FreeBSD ? >> O> And why /sbin/reboot isn't useable by operator too ? >> O> Are there somes security issue ? >> >> +1 here. I was always annoyed and surprised by this fact. >> >> -- >> Totus tuus, Glebius. While reboot is dangerous and should really only be used in single user mode or an emergency, I don't understood why operator was not allowed to do it. for those who assume that "reboot" is short for "shutdown -r now", it is not. Reboot does not bother shutting down stuff in rc.d while shutdown does. This can result in shutdown not working, but reboot can leave things like database files in bad shape. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 20:39:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F28B319; Wed, 23 Jan 2013 20:39:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx1.freebsd.org (Postfix) with ESMTP id B88E5DFD; Wed, 23 Jan 2013 20:39:15 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id fo12so3802043lab.28 for ; Wed, 23 Jan 2013 12:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4IoYgzNvKeXVUTLW31IJdq9L+w1yAHZ1rMtrPImWriU=; b=sRii53ZvGdwnfyos5kYMOQAorRcwgG9/7uZ8jIFYmdrq/OHiBsrbjG1xYiSAkfWd1r 9p+9tmMJEZPWqM5Khc3YLI2fgJoQ7vINeNoHnJxDLCw5H5/ARoIBXb0bT3r23DXjeHr4 qfnv5MX3y1cEkdZFij5+aBf5zSKLlIOGcvue/BlrFt/A+p74dfKUUgNgf3O+uKSRcSTc vJvktMRXEl2sbx/L9ZWOONj4qce3wyZijSaTDdmuS/Qkf1JLv3Mk6M/ey3bp5/5hlTZb gTNqKlM54O2fSgLMoTDaJtYXpnEY3wnt9CJaLj8fADOmmKVxLXhApH/LaGqg8qpfXqr9 tJaQ== X-Received: by 10.112.36.165 with SMTP id r5mr1283343lbj.112.1358973549483; Wed, 23 Jan 2013 12:39:09 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id pp13sm6002161lab.12.2013.01.23.12.39.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 12:39:08 -0800 (PST) Sender: Alexander Motin Message-ID: <51004A69.6020809@FreeBSD.org> Date: Wed, 23 Jan 2013 22:39:05 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jaakko Heinonen Subject: Re: panic after r244584 References: <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> <20130123071346.GA56937@hell.ukr.net> <20130123195104.GA1802@a91-153-116-96.elisa-laajakaista.fi> In-Reply-To: <20130123195104.GA1802@a91-153-116-96.elisa-laajakaista.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vitalij Satanivskij , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 20:39:17 -0000 On 23.01.2013 21:51, Jaakko Heinonen wrote: > On 2013-01-23, Vitalij Satanivskij wrote: >> VS> Jaakko Heinonen wrote: >> VS> JH> > I see two possible solutions for the problem. >> VS> JH> > >> VS> JH> > 1) Replace non-printable, space and '/' characters for example with '_'. >> VS> JH> > '/' should be replaced anyway. >> VS> JH> > >> VS> JH> > 2) Apply the patches in >> VS> JH> > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html >> VS> JH> > to allow spaces again. I haven't committed the patches because I >> VS> JH> > think that there isn't full consensus that it's right thing to do and >> VS> JH> > also I personally prefer not to have spaces in device names. >> VS> JH> >> VS> JH> Here's a patch to implement 1: >> VS> JH> >> VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff >> VS> >> VS> Ok that patch work's too. >> >> Is there any chance, that one of this patches will be merged to head? > > Yes. > > Alexander and Justin: what do you think about this patch? > > http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff It is fine for me, or at least better then panic. But that is Justin's code, so he should know better. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 21:29:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F822C13; Wed, 23 Jan 2013 21:29:28 +0000 (UTC) (envelope-from gibbs@freebsd.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id CD48DC7; Wed, 23 Jan 2013 21:29:27 +0000 (UTC) Received: from benscottlt.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id r0NLT2De001731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jan 2013 14:29:26 -0700 (MST) (envelope-from gibbs@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: panic after r244584 From: "Justin T. Gibbs" In-Reply-To: <51004A69.6020809@FreeBSD.org> Date: Wed, 23 Jan 2013 14:29:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> <20130123071346.GA56937@hell.ukr.net> <20130123195104.GA1802@a91-153-116-96.elisa-laajakaista.fi> <51004A69.6020809@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [70.89.174.89]); Wed, 23 Jan 2013 14:29:27 -0700 (MST) Cc: Jaakko Heinonen , Gleb Smirnoff , freebsd-current@freebsd.org, Vitalij Satanivskij X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 21:29:28 -0000 On Jan 23, 2013, at 1:39 PM, Alexander Motin wrote: > On 23.01.2013 21:51, Jaakko Heinonen wrote: >> On 2013-01-23, Vitalij Satanivskij wrote: >>> VS> Jaakko Heinonen wrote: >>> VS> JH> > I see two possible solutions for the problem. >>> VS> JH> >=20 >>> VS> JH> > 1) Replace non-printable, space and '/' characters for = example with '_'. >>> VS> JH> > '/' should be replaced anyway. >>> VS> JH> >=20 >>> VS> JH> > 2) Apply the patches in >>> VS> JH> > = http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html >>> VS> JH> > to allow spaces again. I haven't committed the patches = because I >>> VS> JH> > think that there isn't full consensus that it's right = thing to do and >>> VS> JH> > also I personally prefer not to have spaces in device = names. >>> VS> JH>=20 >>> VS> JH> Here's a patch to implement 1: >>> VS> JH>=20 >>> VS> JH> = http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff >>> VS>=20 >>> VS> Ok that patch work's too. >>>=20 >>> Is there any chance, that one of this patches will be merged to = head?=20 >>=20 >> Yes. >>=20 >> Alexander and Justin: what do you think about this patch? >>=20 >> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff >=20 > It is fine for me, or at least better then panic. But that is Justin's > code, so he should know better. It's fine. -- Justin From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 21:31:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1D28D38; Wed, 23 Jan 2013 21:31:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id 06006E5; Wed, 23 Jan 2013 21:31:41 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id gg13so4946099lbb.2 for ; Wed, 23 Jan 2013 13:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xK7P6FMCraSo+D+GPtnZzG/sez00jwel/VgCAcPRDZc=; b=aPJYIU4wynCUVePA8GOHNpXr9x93qfb3U+ajyrSQibz/+lWBvbSbzVCrSc2NefnobK aUJj1ImL28fxYyNmRRK7UpHfTWmXZ8HFQca+cUL6Y6hXoz3UCx5BbOk9WFTG2mBL49X0 D9VTOaZWQJuLlJfMIOIxKh7ImDGh5XE4m9DGjq80EqO8+jgyG0MoQBscrGhEs1E8WNSM mQW6KrzzVbVDsUDlV5mnInZCa9td9h7SQkpGU6UZ3dM8yY6icRrGQ6HKNj9tB2GmonpW UVPyOBPdn1JBP1geLrmd/vNFpVB6KEKigFuO4UAsfiP+n7Pnv89K19m9ESHE+g6RGr5b cBjg== MIME-Version: 1.0 X-Received: by 10.112.102.9 with SMTP id fk9mr1323907lbb.100.1358976700604; Wed, 23 Jan 2013 13:31:40 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.93.200 with HTTP; Wed, 23 Jan 2013 13:31:40 -0800 (PST) In-Reply-To: <51003956.50301@FreeBSD.org> References: <20130123163238.GB56212@onelab2.iet.unipi.it> <51003956.50301@FreeBSD.org> Date: Wed, 23 Jan 2013 13:31:40 -0800 X-Google-Sender-Auth: 6pgT4-eU0wPz3Ha7wtcuTLoLBuc Message-ID: Subject: Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ? From: Luigi Rizzo To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 21:31:42 -0000 On Wed, Jan 23, 2013 at 11:26 AM, Dimitry Andric wrote: > Which compilation flags did you use to test this? When I compiled your > testcase program with clang 3.2, gcc 4.2 and gcc 4.7 at -O2, with all > other settings at their defaults, all three compilers just called libc's > memcpy() for the __builtin_memcpy tests. > just -O2 -Wall -Werror, no special -m* or -f* flags cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 21:36:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CBF01F56; Wed, 23 Jan 2013 21:36:52 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by mx1.freebsd.org (Postfix) with ESMTP id DD31911E; Wed, 23 Jan 2013 21:36:51 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id j14so1820052lbo.24 for ; Wed, 23 Jan 2013 13:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=w8rVVADAoWyqpDEi8zneNOiuwgjizAobASxGS87p05c=; b=EFrm9J5If9upW9o3Kij7aIYRqJQswCqkffqO3jxKAqJvJqAymvLnyv4uewm94iGy8E rbQMRqZFkAByBKxB8G732ZQlBTmTp4aHPNod2jG1L0mJR9f9/uiVkZ3z80VHbg8KkFsA 8mQzrrFeqeTFQ2Ld+eJ763dgUsIuHePkNIXO6EeZrANO53HIBLjZctEmuxthbtGqDV48 igbNJaMdt7CTvHQiCvgmLVRVic4uCsCzun5gjLZlAcps9miFn1/4wjS5DJNS9+DkPLWU UwJluen5GCP5pANI6WAN46jbz6os9pw4H4+jjox9ubxtrkv+00vWoLjzr+iau6hqcu0T 129w== MIME-Version: 1.0 X-Received: by 10.112.24.199 with SMTP id w7mr603973lbf.102.1358977010718; Wed, 23 Jan 2013 13:36:50 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.93.200 with HTTP; Wed, 23 Jan 2013 13:36:50 -0800 (PST) In-Reply-To: References: <20130123163238.GB56212@onelab2.iet.unipi.it> Date: Wed, 23 Jan 2013 13:36:50 -0800 X-Google-Sender-Auth: y-mhuFPn4P8ObOBQgDQaFqCp2ZA Message-ID: Subject: Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ? From: Luigi Rizzo To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 21:36:52 -0000 On Wed, Jan 23, 2013 at 11:29 AM, Artem Belevich wrote: > On Wed, Jan 23, 2013 at 8:32 AM, Luigi Rizzo wrote: > > Probably our compiler folks have some ideas on this... > > > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > > __builtin_memcpy() was even worse, and so i ended up writing > > my custom routine, (called pkt_copy() in the program below). > > This happens with gcc 4.2.1, clang, gcc 4.6.4 > > The program does not seem to have pkt_copy. It does have fast_bcopy. > Is that the one you meant by pkt_copy? > > sorry for the confusion, i did some last-minute name changes. pkt_copy() is the name of the C function, ./testloop -m fastcopy is the name you need to use to run pkt_copy() cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 22:55:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C681CFA2 for ; Wed, 23 Jan 2013 22:55:10 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 73C57722 for ; Wed, 23 Jan 2013 22:55:08 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r0NMsuKd067369 for ; Wed, 23 Jan 2013 17:54:56 -0500 (EST) (envelope-from andy@neu.net) Date: Wed, 23 Jan 2013 17:54:56 -0500 (EST) From: AN To: freebsd-current@freebsd.org Subject: /usr/bin/ld: final link failed: Bad value 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-Virus-Scanned: clamav-milter 0.97.6 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jan 2013 22:55:10 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r245800: Tue Jan 22 13:00:27 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Could someone please comment on this. I am trying to build and install FireFox Nightly. This is not the Firefox version in the ports tree, it is from here: https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/firefox-nightly/ I did an svn co to /usr/ports/www/FF_nightly and use this command to build and install: make update && make makesum && time make all deinstall install clean Here is the error: c++ -o nsRDFResource.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include ../../../config/gcc_hidden.h -DMOZ_JSDEBUGGER -DMOZ_PREF_EXTENSIONS -DMOZ_AUTH_EXTENSION -DMOZ_PERMISSIONS -DMOZ_UNIVERSALCHARDET -DMOZ_FILEVIEW -DICON_DECODER -DMOZ_SPELLCHECK -DMOZ_ZIPWRITER -DIMPL_XREAPI -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DNO_NSPR_10_SUPPORT -D_IMPL_NS_COM -D_IMPL_NS_STRINGAPI -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -I../../../intl/unicharutil/util -I../../../intl/unicharutil/src -I../../../config -I../../../widget/windows -I../../../toolkit/library -I. -I../../dist/include -I/usr/local/include/nspr -I/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/dist/include/nss -I/usr/local/include -I/usr/local/include -fPIC -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -O2 -pipe -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsRDFResource.o.pp /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/toolkit/library/nsRDFResource.cpp rm -f libxul.so /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/_virtualenv/bin/python ../../../config/expandlibs_exec.py --depend .deps/libxul.so.pp --target libxul.so --uselist -- c++ -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -O2 -pipe -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsSpecialCasingData.o nsUnicodeProperties.o nsRDFResource.o -pthread -L/usr/local/lib -Wl,-z,origin -Wl,-rpath,\$ORIGIN -Wl,-z,noexecstack -Wl,-rpath-link,/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/dist/bin -Wl,-rpath-link,/usr/local/lib ../../toolkit/components/osfile/libosfile_s.a ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libidentity.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libmediasniffer.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsinspector.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libdombindings_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libsnappy_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libgl.a ../../staticlib/libycbcr.a -L../../dist/bin -L../../dist/lib /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/dist/lib/libjs_static.a -L/usr/local/lib -lffi -L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 -L/usr/local/lib -lcairo -pthread -L/usr/local/lib -lcairo -pthread -lXrender -L/usr/local/lib -lX11 -L/usr/local/lib -lsqlite3 -L/usr/local/lib -ljpeg -L/usr/local/lib -lpng -lz -L/usr/local/lib -lhunspell-1.3 -L/usr/local/lib/event2 -levent-2.0 -L/usr/local/lib -lvpx -L/usr/local/lib -lpixman-1 ../../dist/lib/libgkmedias.a -L../../dist/bin -L../../dist/lib -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread ../../dist/lib/libmozalloc.a -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lgthread-2.0 -pthread -L/usr/local/lib -lglib-2.0 -L/usr/local/lib -lX11 -lXext -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -pthread -lglib-2.0 -lfreetype -L/usr/local/lib -lfontconfig -L/usr/local/lib -lfontconfig -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lgio-2.0 -lgmodule-2.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lcairo -pthread -L/usr/local/lib -lX11 -lXt -lgthread-2.0 -L/usr/local/lib -lfreetype -L/usr/local/lib -lstartup-notification-1 -Wl,--warn-unresolved-symbols -lgstapp-0.10 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -pthread -lglib-2.0 -L/usr/local/lib -lxml2 -lgstvideo-0.10 -Wl,--as-needed,-lcxxrt,--no-as-needed -lkvm -liconv ../../dom/ipc/ContentChild.o: In function `mozilla::dom::ContentChild::RecvSetProcessPrivileges(base::ChildPrivileges const&)': /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/dom/ipc/ContentChild.cpp:(.text._ZN7mozilla3dom12ContentChild24RecvSetProcessPrivilegesERKN4base15ChildPrivilegesE+0xf): undefined reference to `base::SetCurrentProcessPrivileges(base::ChildPrivileges)' /usr/bin/ld: ../../dom/ipc/ContentChild.o: relocation R_X86_64_PC32 against `_ZN4base27SetCurrentProcessPrivilegesENS_15ChildPrivilegesE' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [libxul.so] Error 1 gmake[3]: Leaving directory `/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/toolkit/library' gmake[2]: *** [libs_tier_platform] Error 2 gmake[2]: Leaving directory `/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0' gmake[1]: *** [tier_platform] Error 2 gmake[1]: Leaving directory `/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0' gmake: *** [default] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/www/FF_nightly. *** [/usr/ports/www/FF_nightly/work/.build_done.firefox._usr_local] Error code 1 Stop in /usr/ports/www/FF_nightly. *** [build] Error code 1 Stop in /usr/ports/www/FF_nightly. Is it a bug in FreeBSD, or is it something specific to FF_nightly? Any help would be appreciated, thanks in advance. From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 00:56:23 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 03E3270; Thu, 24 Jan 2013 00:56:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A5DEEB2C; Thu, 24 Jan 2013 00:56:22 +0000 (UTC) Message-ID: <51008661.4060006@FreeBSD.org> Date: Wed, 23 Jan 2013 19:54:57 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130116 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: ACPI panic on unplugging the power cord. References: <20130122175629.GA1714@garage.freebsd.pl> In-Reply-To: <20130122175629.GA1714@garage.freebsd.pl> X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------080405050404060205050101" Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 00:56:23 -0000 This is a multi-part message in MIME format. --------------080405050404060205050101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-22 12:56:29 -0500, Pawel Jakub Dawidek wrote: > I just upgraded to HEAD today and was wondering what will explode. > Now I know. > > When I unplug power cord from my laptop, ACPI panics. Pictures > here: > > http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg > http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg > > Let me know if you need more info. Can you please try the attached patch? It is also available from here: http://people.freebsd.org/~jkim/utcache.diff Please note the patch may or may not fix the problem but I think I found an ancient bug. :-( Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRAIZhAAoJECXpabHZMqHOWl8H/3pUGshUkzCNbEOQHoZOYXMW TtLaUqdV3/zYGEYDYl5Tbxv2JUz4tWDU5KlWhnZk+MjNnR1+g0fgzQu3mK056NU+ rpZucEnoaEeKriLpd+Hsw3Y28eXiY8/9T8/SnFMUW7AS6HZk8G7itdu9cx9A+IY6 A2tQBIpDXes4a5BLNZzyP/2dSMrcKVeS28+fZlxGdWWakFs5/FWYguK5kR2PIkCS 3yh8vEv7XH8WJz+sK/v/jcpcxt+heCG+j8XIwJieqk1CDXaCtH6g+4mlKQogsZY1 1YSYaGE+/szNvnR9UjW1+x/mhA5atFa9ysCq96zvVOs/Ih7X9Id4fZ6laetSDIs= =rUXs -----END PGP SIGNATURE----- --------------080405050404060205050101 Content-Type: text/x-patch; name="utcache.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="utcache.diff" Index: sys/contrib/dev/acpica/components/utilities/utcache.c =================================================================== --- sys/contrib/dev/acpica/components/utilities/utcache.c (revision 245848) +++ sys/contrib/dev/acpica/components/utilities/utcache.c (working copy) @@ -95,7 +95,6 @@ AcpiOsCreateCache ( /* Populate the cache object and return it */ ACPI_MEMSET (Cache, 0, sizeof (ACPI_MEMORY_LIST)); - Cache->LinkOffset = 8; Cache->ListName = CacheName; Cache->ObjectSize = ObjectSize; Cache->MaxDepth = MaxDepth; @@ -121,7 +120,7 @@ ACPI_STATUS AcpiOsPurgeCache ( ACPI_MEMORY_LIST *Cache) { - char *Next; + void *Next; ACPI_STATUS Status; @@ -145,8 +144,7 @@ AcpiOsPurgeCache ( { /* Delete and unlink one cached state object */ - Next = *(ACPI_CAST_INDIRECT_PTR (char, - &(((char *) Cache->ListHead)[Cache->LinkOffset]))); + Next = ((ACPI_OBJECT_COMMON *) Cache->ListHead)->NextObject; ACPI_FREE (Cache->ListHead); Cache->ListHead = Next; @@ -251,8 +249,7 @@ AcpiOsReleaseObject ( /* Put the object at the head of the cache list */ - * (ACPI_CAST_INDIRECT_PTR (char, - &(((char *) Object)[Cache->LinkOffset]))) = Cache->ListHead; + ((ACPI_OBJECT_COMMON *) Object)->NextObject = Cache->ListHead; Cache->ListHead = Object; Cache->CurrentDepth++; @@ -307,8 +304,7 @@ AcpiOsAcquireObject ( /* There is an object available, use it */ Object = Cache->ListHead; - Cache->ListHead = *(ACPI_CAST_INDIRECT_PTR (char, - &(((char *) Object)[Cache->LinkOffset]))); + Cache->ListHead = ((ACPI_OBJECT_COMMON *) Object)->NextObject; Cache->CurrentDepth--; Index: sys/contrib/dev/acpica/include/actypes.h =================================================================== --- sys/contrib/dev/acpica/include/actypes.h (revision 245848) +++ sys/contrib/dev/acpica/include/actypes.h (working copy) @@ -1226,7 +1226,6 @@ typedef struct acpi_memory_list UINT16 ObjectSize; UINT16 MaxDepth; UINT16 CurrentDepth; - UINT16 LinkOffset; #ifdef ACPI_DBG_TRACK_ALLOCATIONS --------------080405050404060205050101-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 02:55:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D8F42 for ; Thu, 24 Jan 2013 02:55:05 +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 4D755F95 for ; Thu, 24 Jan 2013 02:55:05 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 18F507300A; Thu, 24 Jan 2013 03:54:42 +0100 (CET) Date: Thu, 24 Jan 2013 03:54:42 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: false alarm (Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?) Message-ID: <20130124025442.GA63831@onelab2.iet.unipi.it> References: <20130123163238.GB56212@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123163238.GB56212@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 02:55:05 -0000 On Wed, Jan 23, 2013 at 05:32:38PM +0100, Luigi Rizzo wrote: > Probably our compiler folks have some ideas on this... > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > __builtin_memcpy() was even worse, and so i ended up writing > my custom routine, (called pkt_copy() in the program below). > This happens with gcc 4.2.1, clang, gcc 4.6.4 > > I was then surprised to notice that on a recent ubuntu using > gcc 4.6.2 (if that matters) the __builtin_memcpy beats other > methods by a large factor. so, it turns out that in my test program I had swapped the source and destination operands for __builtin_memcpy(), and this substantially changed the memory access pattern. With the correct operands, __builtin_memcpy == memcpy == bcopy on both FreeBSD and Linux. On FreeBSD pkt_copy is still faster than the other methods for small packets, whereas on Linux they are equivalent. If you are curious why swapping source and dst changed things so dramatically: the test was supposed to read from a large chunk of memory (over 1GB) to avoid always hitting L1 or L2. Swapping operands causes reads to hit always the same line, thus saving a lot of misses. The difference between the two machine then probably is due to how the cache is used on writes. sorry for the noise. luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 09:41:19 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E12F3D9C; Thu, 24 Jan 2013 09:41:19 +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 9A9122C5; Thu, 24 Jan 2013 09:41:18 +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 LAA20278; Thu, 24 Jan 2013 11:41:10 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TyJJ0-000CkK-Kd; Thu, 24 Jan 2013 11:41:10 +0200 Message-ID: <510101B4.4030409@FreeBSD.org> Date: Thu, 24 Jan 2013 11:41:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jung-uk Kim Subject: Re: ACPI panic on unplugging the power cord. References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> In-Reply-To: <51008661.4060006@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 09:41:19 -0000 on 24/01/2013 02:54 Jung-uk Kim said the following: > > Can you please try the attached patch? It is also available from here: > > http://people.freebsd.org/~jkim/utcache.diff Jung-uk, I think that I have a much better patch for all potential ACPI object cache problems :-) http://people.freebsd.org/~avg/acpi-uma-cache.diff What do you think? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 12:40:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C844380; Thu, 24 Jan 2013 12:40:36 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 36F543CE; Thu, 24 Jan 2013 12:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=Fi9RGfPkJ88vQumCDEouStYkub4SO0ftgDNuWGVx07w=; b=dXuVSCHZDnmaJIoyukwr7yWEO/XGeJDcmKT37oc6LZ2eKtHagKs87RpZxqHZh29HSBNe/3+IFzqVX0tRY8NKR/9xEiCmS2vEAajMrlqDpPFN+6K9q0sBKX372NQDxw28bNoSoZ5LmIm82M5GsFVwf0XalKiRKk5/JADG0GZgBgc=; Received: from mail by ffe16.ukr.net with local ID 1TyLmM-0003XF-5m ; Thu, 24 Jan 2013 14:19:38 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: AHCI timeout when using ZFS + AIO + NCQ To: fs@freebsd.org From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <13391.1359029978.3957795939058384896@ffe16.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Date: Thu, 24 Jan 2013 14:19:38 +0200 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 12:40:36 -0000 I have the server: FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 Jan 24 12:53:01 vesuvius kernel: atapci0: port 0xc040-0xc047,0xc030-0xc033,0xc020-0xc027,0xc010-0xc013,0xc000-0xc00f mem 0xfe210000-0xfe2101ff irq 51 at device 0.0 on pci3 ... Jan 24 12:53:01 vesuvius kernel: ahci0: port 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem 0xfe307000-0xfe3073ff irq 19 at device 17.0 on pci0 Jan 24 12:53:01 vesuvius kernel: ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ... Jan 24 12:53:01 vesuvius kernel: ada2 at ahcich2 bus 0 scbus4 target 0 lun 0 Jan 24 12:53:01 vesuvius kernel: ada2: ATA-8 SATA 3.x device Jan 24 12:53:01 vesuvius kernel: ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Jan 24 12:53:01 vesuvius kernel: ada2: Command Queueing enabled Jan 24 12:53:01 vesuvius kernel: ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) Jan 24 12:53:01 vesuvius kernel: ada2: Previously was known as ad12 ... I use 4 HDD in RAID10 via ZFS. With a very irregular intervals fall off HDD drives. As a result, the server stops. Jan 24 06:48:06 vesuvius kernel: ahcich2: Timeout on slot 6 port 0 Jan 24 06:48:06 vesuvius kernel: ahcich2: is 00000000 cs 00000000 ss 000000c0 rs 000000c0 tfd 40 serr 00000000 cmd 0000e817 Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 4c 4e 1e 40 68 00 00 01 00 00 Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): CAM status: Command timeout Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): Retrying command Jan 24 06:51:11 vesuvius kernel: ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) Jan 24 06:51:11 vesuvius kernel: ahcich2: Timeout on slot 8 port 0 Jan 24 06:51:11 vesuvius kernel: ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd 00 serr 00000000 cmd 0000e817 Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): CAM status: Command timeout Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retry was blocked Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 Jan 24 06:51:11 vesuvius kernel: ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 Jan 24 06:51:11 vesuvius kernel: ahcich2: Timeout on slot 8 port 0 Jan 24 06:51:11 vesuvius kernel: ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd 00 serr 00000000 cmd 0000e817 Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): CAM status: Command timeout Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retry was blocked Jan 24 06:51:11 vesuvius kernel: swap_pager: I/O error - pagein failed; blkno 4227133,size 8192, error 6 Jan 24 06:51:11 vesuvius kernel: (ada2:(pass2:vm_fault: pager read error, pid 1943 (named) Jan 24 06:51:11 vesuvius kernel: ahcich2:0:ahcich2:0:0:0:0): lost device Jan 24 06:51:11 vesuvius kernel: 0): passdevgonecb: devfs entry is gone Jan 24 06:51:11 vesuvius kernel: pid 1943 (named), uid 53: exited on signal 11 ... Helps only restart by pressing Power. Judging by the state of SMART, HDD have no problems. SATA data cable changed. I found a similar problem: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html PR: amd64/165547: NVIDIA MCP67 AHCI SATA controller timeout -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 12:49:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E2FC7EB; Thu, 24 Jan 2013 12:49:59 +0000 (UTC) (envelope-from prvs=1736dd70aa=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 F3C9166C; Thu, 24 Jan 2013 12:49:58 +0000 (UTC) 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 md50001835522.msg; Thu, 24 Jan 2013 12:49:57 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 24 Jan 2013 12:49:57 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1736dd70aa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <221B307551154F489452F89E304CA5F7@multiplay.co.uk> From: "Steven Hartland" To: , "Vladislav Prodan" References: <13391.1359029978.3957795939058384896@ffe16.ukr.net> Subject: Re: AHCI timeout when using ZFS + AIO + NCQ Date: Thu, 24 Jan 2013 12:50:30 -0000 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 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 12:49:59 -0000 Is it always the same disk, of so replace it SMART helps identify issues but doesn't tell you 100% there's no problem. ----- Original Message ----- From: "Vladislav Prodan" To: Cc: Sent: Thursday, January 24, 2013 12:19 PM Subject: AHCI timeout when using ZFS + AIO + NCQ >I have the server: > > FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 > > Jan 24 12:53:01 vesuvius kernel: atapci0: port > 0xc040-0xc047,0xc030-0xc033,0xc020-0xc027,0xc010-0xc013,0xc000-0xc00f mem 0xfe210000-0xfe2101ff irq 51 at device 0.0 on pci3 > ... > Jan 24 12:53:01 vesuvius kernel: ahci0: port > 0xf040-0xf047,0xf030-0xf033,0xf020-0xf027,0xf010-0xf013,0xf000-0xf00f mem 0xfe307000-0xfe3073ff irq 19 at device 17.0 on pci0 > Jan 24 12:53:01 vesuvius kernel: ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported > ... > Jan 24 12:53:01 vesuvius kernel: ada2 at ahcich2 bus 0 scbus4 target 0 lun 0 > Jan 24 12:53:01 vesuvius kernel: ada2: ATA-8 SATA 3.x device > Jan 24 12:53:01 vesuvius kernel: ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > Jan 24 12:53:01 vesuvius kernel: ada2: Command Queueing enabled > Jan 24 12:53:01 vesuvius kernel: ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > Jan 24 12:53:01 vesuvius kernel: ada2: Previously was known as ad12 > ... > I use 4 HDD in RAID10 via ZFS. > > With a very irregular intervals fall off HDD drives. As a result, the server stops. > > Jan 24 06:48:06 vesuvius kernel: ahcich2: Timeout on slot 6 port 0 > Jan 24 06:48:06 vesuvius kernel: ahcich2: is 00000000 cs 00000000 ss 000000c0 rs 000000c0 tfd 40 serr 00000000 cmd 0000e817 > Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 4c 4e 1e 40 68 00 00 01 00 00 > Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): CAM status: Command timeout > Jan 24 06:48:06 vesuvius kernel: (ada2:ahcich2:0:0:0): Retrying command > Jan 24 06:51:11 vesuvius kernel: ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) > Jan 24 06:51:11 vesuvius kernel: ahcich2: Timeout on slot 8 port 0 > Jan 24 06:51:11 vesuvius kernel: ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd 00 serr 00000000 cmd 0000e817 > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): CAM status: Command timeout > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retry was blocked > Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 > Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 > Jan 24 06:51:11 vesuvius kernel: ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) > Jan 24 06:51:11 vesuvius kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 4227133, size: 8192 > Jan 24 06:51:11 vesuvius kernel: ahcich2: Timeout on slot 8 port 0 > Jan 24 06:51:11 vesuvius kernel: ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd 00 serr 00000000 cmd 0000e817 > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): CAM status: Command timeout > Jan 24 06:51:11 vesuvius kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retry was blocked > Jan 24 06:51:11 vesuvius kernel: swap_pager: I/O error - pagein failed; blkno 4227133,size 8192, error 6 > Jan 24 06:51:11 vesuvius kernel: (ada2:(pass2:vm_fault: pager read error, pid 1943 (named) > Jan 24 06:51:11 vesuvius kernel: ahcich2:0:ahcich2:0:0:0:0): lost device > Jan 24 06:51:11 vesuvius kernel: 0): passdevgonecb: devfs entry is gone > Jan 24 06:51:11 vesuvius kernel: pid 1943 (named), uid 53: exited on signal 11 > ... > > Helps only restart by pressing Power. > Judging by the state of SMART, HDD have no problems. SATA data cable changed. > > > I found a similar problem: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html > PR: amd64/165547: NVIDIA MCP67 AHCI SATA controller timeout > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This 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 Thu Jan 24 13:23:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B42DFEDC; Thu, 24 Jan 2013 13:23:58 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 87E947F0; Thu, 24 Jan 2013 13:23:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,529,1355126400"; d="scan'208";a="11219718" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 24 Jan 2013 05:23:51 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0ODNpkX024847; Thu, 24 Jan 2013 05:23:51 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 05:23:51 -0800 From: "Eggert, Lars" To: Dimitry Andric Subject: Re: serial console not accepting input? Thread-Topic: serial console not accepting input? Thread-Index: AQHN+YBoyi5llRmNskaJJfjFwBFvjphXmc4AgAFlZIA= Date: Thu, 24 Jan 2013 13:23:50 +0000 Message-ID: References: <51000A18.1020001@FreeBSD.org> In-Reply-To: <51000A18.1020001@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <4304FDE21AA16C4A99067CD60657D83B@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 13:23:58 -0000 Hi, On Jan 23, 2013, at 17:04, Dimitry Andric wrote: > CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default > settings in /etc/gettytab, or make a specific entry with an added ":hw" > setting. nope, I don't even get a login prompt if I do that. > If it is a physical serial console, you could also simply have a bad > cable. Try swapping it with working system. :) Spent the last few hours fiddling with the cabling and the various BIOS ser= ial redirection options (it's a Dell 2950). My best guess is that the seria= l port on the box is physically broken. Thanks for the help! Lars= From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 16:18:12 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2EE8F81; Thu, 24 Jan 2013 16:18:12 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC002D1; Thu, 24 Jan 2013 16:18:12 +0000 (UTC) Received: from localhost (unknown [62.49.66.12]) by mail.dawidek.net (Postfix) with ESMTPSA id D818D24C; Thu, 24 Jan 2013 17:15:35 +0100 (CET) Date: Thu, 24 Jan 2013 17:18:48 +0100 From: Pawel Jakub Dawidek To: Jung-uk Kim Subject: Re: ACPI panic on unplugging the power cord. Message-ID: <20130124161848.GA2386@garage.freebsd.pl> References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <51008661.4060006@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 16:18:12 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2013 at 07:54:57PM -0500, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-01-22 12:56:29 -0500, Pawel Jakub Dawidek wrote: > > I just upgraded to HEAD today and was wondering what will explode.=20 > > Now I know. > >=20 > > When I unplug power cord from my laptop, ACPI panics. Pictures > > here: > >=20 > > http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg=20 > > http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg > >=20 > > Let me know if you need more info. >=20 > Can you please try the attached patch? It is also available from here: >=20 > http://people.freebsd.org/~jkim/utcache.diff >=20 > Please note the patch may or may not fix the problem but I think I > found an ancient bug. :-( This patch didn't fix the panic: http://people.freebsd.org/~pjd/misc/acpi_unplug_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_unplug_panic_1.jpg In the meantime I found two other panics. One is when I leave laptop idle for some time (few hours?): http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg And when is when I boot laptop without power connected and I connect the power: http://people.freebsd.org/~pjd/misc/acpi_power_connect_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_power_connect_panic_1.jpg BTW. On the acpi_power_connect_panic_0.JPG photo, at the top of the screen you can see error messages that are logged every second when I have power disconnected. This is not a new problem. I had this problem when I bought this laptop, but now that I'm reporting those bugs, I can as well let you know about this one. I'm running this on Thinkpad T530. I understand that those problems are specific to my laptop and that on your laptop all of the above work just fine? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEBXugACgkQForvXbEpPzS/jACg82eUvcOydKD2Oidyz+0J6QiS pkcAn3N14p4lrA9JngQpqRAedPL0J22b =UUqX -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 17:34:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6B05C74; Thu, 24 Jan 2013 17:34:29 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 8147B966; Thu, 24 Jan 2013 17:34:29 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id EEEFF1397C2; Thu, 24 Jan 2013 19:34:22 +0200 (EET) Date: Thu, 24 Jan 2013 19:34:21 +0200 From: Jaakko Heinonen To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130124173420.GA2921@a91-153-116-96.elisa-laajakaista.fi> References: <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> <20130123071346.GA56937@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123071346.GA56937@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 17:34:30 -0000 On 2013-01-23, Vitalij Satanivskij wrote: > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > VS> > VS> Ok that patch work's too. > > Is there any chance, that one of this patches will be merged to head? Committed as r245891. Thanks for reporting and testing! -- Jaakko From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 18:30:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB5F7FE4; Thu, 24 Jan 2013 18:30:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7EED7D08; Thu, 24 Jan 2013 18:30:38 +0000 (UTC) Message-ID: <51017D79.6060202@FreeBSD.org> Date: Thu, 24 Jan 2013 13:29:13 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130116 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: ACPI panic on unplugging the power cord. References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> <510101B4.4030409@FreeBSD.org> In-Reply-To: <510101B4.4030409@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jan 2013 18:30:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-24 04:41:08 -0500, Andriy Gapon wrote: > on 24/01/2013 02:54 Jung-uk Kim said the following: >> >> Can you please try the attached patch? It is also available from >> here: >> >> http://people.freebsd.org/~jkim/utcache.diff > > Jung-uk, > > I think that I have a much better patch for all potential ACPI > object cache problems :-) > http://people.freebsd.org/~avg/acpi-uma-cache.diff > > What do you think? We have to fix this bug because local cache is always used for userland applications, e.g., iasl. BTW, I tried something like that long ago. In fact, the first attempt goes all the way back to this patch (warning: it's naive, broken, and overly complicated): http://people.freebsd.org/~jkim/acpica/OsdCache.diff I have more up-to-date and correct patch to use UMA but I'm still not 100% convinced whether we want to do it or not. When utcache.c works, it works fairly well, actually. :-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRAX15AAoJECXpabHZMqHOyoAH/i1eccONiETE+LiHlApmL+zy Y1h1D+R/S8hJ55fQ7i/2CkqAhNdHFI+TCrt2YIPNXS79VP9xyNRa+gPGHNqYUTF4 nv34ZpSi5MMERg7r+mOitNjPZfy+aiyDHI/PQFZ4lQR+by3c1HogKAwNPhLn0rxF NiA+X11lkcbBCxb4HzH8kSI5wFW/e5tEAHgGTrxJLzS1IGTbRBYLV6lA+ITBR0wu EzGw3FEU2pO2jDL3WxsM0vg/4VMCZvsnezxvRQ1XPbdJe4UU0ri3VgqzFX6N5ThI AeDuehji9lZiZc6Hjn35jSxq5KpzMiOj6bjLTEeO5zIdjmeGUWiMex+aoRrFOGU= =/bG6 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 23:52:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 151B8535; Thu, 24 Jan 2013 23:52:23 +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 B8986EC7; Thu, 24 Jan 2013 23:52:22 +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 r0ONqF6R015125; Thu, 24 Jan 2013 18:52:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0ONqFVR015124; Thu, 24 Jan 2013 23:52:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 24 Jan 2013 23:52:15 GMT Message-Id: <201301242352.r0ONqFVR015124@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 23:52:23 -0000 TB --- 2013-01-24 23:50:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-24 23:50:17 - 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 --- 2013-01-24 23:50:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-01-24 23:50:17 - cleaning the object tree TB --- 2013-01-24 23:50:17 - /usr/local/bin/svn stat /src TB --- 2013-01-24 23:50:21 - At svn revision 245894 TB --- 2013-01-24 23:50:22 - building world TB --- 2013-01-24 23:50:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-24 23:50:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-24 23:50:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-24 23:50:22 - SRCCONF=/dev/null TB --- 2013-01-24 23:50:22 - TARGET=arm TB --- 2013-01-24 23:50:22 - TARGET_ARCH=arm TB --- 2013-01-24 23:50:22 - TZ=UTC TB --- 2013-01-24 23:50:22 - __MAKE_CONF=/dev/null TB --- 2013-01-24 23:50:22 - cd /src TB --- 2013-01-24 23:50:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 24 23:50:27 UTC 2013 >>> 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 [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> gnu/usr.bin/cc/cc1plus (cleandir) rm -f cfns.h cc1plus-dummy cc1plus-checksum.c cc1plus cc1plus-checksum.o main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o typeck.o typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> gnu/usr.bin/cc/c++ (cleandir) "../Makefile.inc", line 29: Malformed conditional (${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no") "../Makefile.inc", line 110: if-less endif make: fatal errors encountered -- cannot continue *** [cleandir] Error code 1 Stop in /src/gnu/usr.bin/cc. *** [cleandir] Error code 1 Stop in /src/gnu/usr.bin. *** [cleandir] Error code 1 Stop in /src/gnu. *** [gnu.cleandir__D] Error code 1 Stop in /src. *** [_cleanobj] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-24 23:52:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-24 23:52:15 - ERROR: failed to build world TB --- 2013-01-24 23:52:15 - 80.16 user 15.41 system 118.16 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 24 23:52:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B09F060B; Thu, 24 Jan 2013 23:52:25 +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 673BAEC8; Thu, 24 Jan 2013 23:52:22 +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 r0ONqFuC015119; Thu, 24 Jan 2013 18:52:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0ONqFf1015074; Thu, 24 Jan 2013 23:52:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 24 Jan 2013 23:52:15 GMT Message-Id: <201301242352.r0ONqFf1015074@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 , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 23:52:25 -0000 TB --- 2013-01-24 23:50:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-24 23:50:17 - 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 --- 2013-01-24 23:50:17 - starting HEAD tinderbox run for armv6/arm TB --- 2013-01-24 23:50:17 - cleaning the object tree TB --- 2013-01-24 23:50:17 - /usr/local/bin/svn stat /src TB --- 2013-01-24 23:50:21 - At svn revision 245894 TB --- 2013-01-24 23:50:22 - building world TB --- 2013-01-24 23:50:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-24 23:50:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-24 23:50:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-24 23:50:22 - SRCCONF=/dev/null TB --- 2013-01-24 23:50:22 - TARGET=arm TB --- 2013-01-24 23:50:22 - TARGET_ARCH=armv6 TB --- 2013-01-24 23:50:22 - TZ=UTC TB --- 2013-01-24 23:50:22 - __MAKE_CONF=/dev/null TB --- 2013-01-24 23:50:22 - cd /src TB --- 2013-01-24 23:50:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 24 23:50:27 UTC 2013 >>> 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 [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> gnu/usr.bin/cc/cc1plus (cleandir) rm -f cfns.h cc1plus-dummy cc1plus-checksum.c cc1plus cc1plus-checksum.o main.o cp-lang.o c-opts.o call.o class.o cvt.o cxx-pretty-print.o decl.o decl2.o error.o except.o expr.o dump.o friend.o init.o lex.o mangle.o method.o name-lookup.o parser.o pt.o ptree.o repo.o rtti.o search.o semantics.o tree.o typeck.o typeck2.o optimize.o cp-objcp-common.o cp-gimplify.o tree-mudflap.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> gnu/usr.bin/cc/c++ (cleandir) "../Makefile.inc", line 29: Malformed conditional (${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no") "../Makefile.inc", line 110: if-less endif make: fatal errors encountered -- cannot continue *** [cleandir] Error code 1 Stop in /src/gnu/usr.bin/cc. *** [cleandir] Error code 1 Stop in /src/gnu/usr.bin. *** [cleandir] Error code 1 Stop in /src/gnu. *** [gnu.cleandir__D] Error code 1 Stop in /src. *** [_cleanobj] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-24 23:52:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-24 23:52:15 - ERROR: failed to build world TB --- 2013-01-24 23:52:15 - 80.88 user 14.78 system 118.01 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 01:11:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3728D29B; Fri, 25 Jan 2013 01:11:19 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3B981CE; Fri, 25 Jan 2013 01:11:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=JKPrHWFPsUdoRnExCWBdFvgw3Ul+/7WT2hKYGWWy6DA=; b=nskPQJii0nghIfVKg0TQ9F93+78pXp42WA22BYzppuUXCVX2anznS0RdD/2VgJ+fLyAjrW79+CuUJ73zemCK1bgXjcv1uVFwd5hEHh/fHz6EZMcYhuznhhrN/NI+oQVrG0IMCiTQpJXZDOdVzVIBd0sCwUNjvu8OgVXgSZNdLuQ=; Received: from lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net ([2001:470:1f0e:3ad::2]:54684) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TyXp4-000LlG-TF; Thu, 24 Jan 2013 19:11:17 -0600 Date: Thu, 24 Jan 2013 19:11:12 -0600 (CST) From: Larry Rosenman To: Andriy Gapon Subject: Re: My panic in amd64/pmap In-Reply-To: Message-ID: References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.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-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 01:11:19 -0000 On Sun, 20 Jan 2013, Larry Rosenman wrote: > On Fri, 18 Jan 2013, Larry Rosenman wrote: >> Never mind, it's in VirtualBox itself. The line is at ~~line 8020 in the >> same file. I've patched it and am recompiling >> VirtualBox. >> >> If I don't see the panic for a few days, I'll submit a PR. >> > I've submitted the PR, because for nehalem class or better cpu's it's > probably needed, however, I can still panic FreeBSD9 or FreeBSD10 with > running a zpool scrub, sometimes :(. > > I have vmcores and kernels from both VM's available. > > Latest core.txts: http://www.lerctr.org/~ler/zfs10-core.txt.4 > http://www.lerctr.org/~ler/zfs9-core.txt.4 > > I can still give ssh access to both VM's as well as the host. > > I'd really like to get to the bottom of this..... > > > I've moved all the core.txt's to: http://www.lerctr.org/~ler/FreeBSD-PMAP/ I got another one on FreeBSD9 today.... Is there ANYONE interested in this? These always seem to be ZFS induced..... I've added freebsd-fs to the cc list. I have vmcore's from them all. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 07:14:21 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A8AE8FF; Fri, 25 Jan 2013 07:14:21 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 184A91D4; Fri, 25 Jan 2013 07:14:20 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TydUK-000Ih8-Pv ; Fri, 25 Jan 2013 09:14:12 +0200 Date: Fri, 25 Jan 2013 09:14:12 +0200 From: Vitalij Satanivskij To: Jaakko Heinonen Subject: Re: panic after r244584 Message-ID: <20130125071412.GA71748@hell.ukr.net> References: <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> <20130121154400.GA1808@a91-153-116-96.elisa-laajakaista.fi> <20130121173122.GA20466@hell.ukr.net> <20130123071346.GA56937@hell.ukr.net> <20130124173420.GA2921@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130124173420.GA2921@a91-153-116-96.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Alexander Motin , "Justin T. Gibbs" , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 07:14:21 -0000 Jaakko Heinonen wrote: JH> On 2013-01-23, Vitalij Satanivskij wrote: JH> > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff JH> > VS> JH> > VS> Ok that patch work's too. JH> > JH> > Is there any chance, that one of this patches will be merged to head? JH> JH> Committed as r245891. Thanks for reporting and testing! JH> Thank you all for the quick help in solving the problem. From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 08:43:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ADD59D9F for ; Fri, 25 Jan 2013 08:43:37 +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 E06DC773 for ; Fri, 25 Jan 2013 08:43:36 +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 KAA29659 for ; Fri, 25 Jan 2013 10:43:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tyeso-000F6a-V9 for freebsd-current@FreeBSD.org; Fri, 25 Jan 2013 10:43:35 +0200 Message-ID: <510245B5.8070704@FreeBSD.org> Date: Fri, 25 Jan 2013 10:43:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: acpi resume related patch X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 08:43:37 -0000 If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 09:06:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB222400; Fri, 25 Jan 2013 09:06:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id AD41C877; Fri, 25 Jan 2013 09:06:44 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1TyfJf-00089t-T8; Fri, 25 Jan 2013 13:11:19 +0400 Date: Fri, 25 Jan 2013 13:11:19 +0400 From: Slawa Olhovchenkov To: Andriy Gapon Subject: Re: acpi resume related patch Message-ID: <20130125091119.GB54431@zxy.spb.ru> References: <510245B5.8070704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510245B5.8070704@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 09:06:45 -0000 On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote: > > If you have ACPI suspend/resume working, if it used to work but stopped working > at some time, if it never worked, but you are still hoping, could you please > test the following patch and report back? > > http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch I have ACPI suspend/resume working but AR9220 never resume from sleep. From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 09:17:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 877FD6D8 for ; Fri, 25 Jan 2013 09:17:10 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 273D98F0 for ; Fri, 25 Jan 2013 09:17:09 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so77911eek.33 for ; Fri, 25 Jan 2013 01:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; bh=pWuFwcZC/bzF+Xl2hixcMl/l1tGEPZxHgB3P4LAiO4Q=; b=DnWxvZK2lbbdQ+Fz2s/pI+7HtuRC2634zmftHnLbAQwGiaPxFZy9wLHipRKisg9Spv 3+zWPmKh2VuYqXPV6AXJcBRFJzxPLg85TaI8/Ya6902tei2I/xC+gJLaYPnBbqbliNzO UHOuH+zEHjEsmyY8NHyOK1IkHwNhB60kyZHnlUPGoU3qUBihLKCSH5p3C9CvYN/Mx6RR o7RSsktkHDmMOViOpmIebKCEIF75002PwnkhQSkzIGdDhTMB5Id3ZAvCJn19uCise+2N /wFqlhvMC2WvDD6fQaP8IEP2J6+h5yO1ySnARNemJKuGAIJyhPoqjQe5/pUwNe8Xedkg UiuA== X-Received: by 10.14.1.195 with SMTP id 43mr16179888eed.31.1359105423399; Fri, 25 Jan 2013 01:17:03 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id 6sm738610eea.3.2013.01.25.01.17.02 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 25 Jan 2013 01:17:02 -0800 (PST) Date: Fri, 25 Jan 2013 12:17:04 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: acpi resume related patch Message-ID: <20130125121704.68d7fafa@laptop> In-Reply-To: <20130125091119.GB54431@zxy.spb.ru> References: <510245B5.8070704@FreeBSD.org> <20130125091119.GB54431@zxy.spb.ru> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 09:17:10 -0000 On Fri, 25 Jan 2013 13:11:19 +0400 Slawa Olhovchenkov wrote: > On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote: > > > > > If you have ACPI suspend/resume working, if it used to work but > > stopped working at some time, if it never worked, but you are still > > hoping, could you please test the following patch and report back? > > > > http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch > > I have ACPI suspend/resume working but AR9220 never resume from sleep. resume works with or without patch ?:) resume was broken after r243764 for me (and I'm not alone :)) -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 09:25:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D7ECA1F; Fri, 25 Jan 2013 09:25:31 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5A326963; Fri, 25 Jan 2013 09:25:30 +0000 (UTC) Received: from localhost (unknown [86.188.145.194]) by mail.dawidek.net (Postfix) with ESMTPSA id 418B4490; Fri, 25 Jan 2013 10:22:48 +0100 (CET) Date: Fri, 25 Jan 2013 10:26:02 +0100 From: Pawel Jakub Dawidek To: Jung-uk Kim Subject: Re: ACPI panic on unplugging the power cord. Message-ID: <20130125092602.GB1295@garage.freebsd.pl> References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> <20130124161848.GA2386@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <20130124161848.GA2386@garage.freebsd.pl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 09:25:31 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek wrote: > One is when I leave laptop idle for some time (few hours?): >=20 > http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg > http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg Small update. This panic doesn't happen when the system is idle, it happens we I close the lid to the point when display is turned off (which is almost closed, but not entirely closed). Closing lid doesn't trigger suspend or anything like that. It just turns off the display. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --MW5yreqqjyrRcusr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlECT6oACgkQForvXbEpPzTa3gCg2gBBdEQkhR8X5F6m+sf1rEes yoMAn25InDJnbiAwJFqOb5s/K+CzecsI =MyFz -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 10:06:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23A2A66F for ; Fri, 25 Jan 2013 10:06:25 +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 DB28AB36 for ; Fri, 25 Jan 2013 10:06:24 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1TygAy-002efH-00>; Fri, 25 Jan 2013 11:06:24 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1TygAx-002q2l-Tr>; Fri, 25 Jan 2013 11:06:23 +0100 Message-ID: <51025918.8070002@zedat.fu-berlin.de> Date: Fri, 25 Jan 2013 11:06:16 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: r245901: make buildworld fails: ===> kerberos5/lib/libheimipcs (install) X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2EE94AAC8E74B56989C93C1E" X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 10:06:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2EE94AAC8E74B56989C93C1E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just want to note that make buildworld fails on r245901 with the following unhealthy end: =3D=3D=3D> kerberos5/lib/libheimbase (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libheimbase.a /usr/obj/usr/src/lib32/usr/lib32 sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libheimbase_p.a /usr/obj/usr/src/lib32/usr/lib32 sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libheimbase.so.11 /usr/obj/usr/src/lib32/usr/lib32 sh /usr/src/tools/install.sh -l s libheimbase.so.11 /usr/obj/usr/src/lib32/usr/lib32/libheimbase.so =3D=3D=3D> kerberos5/lib/libheimipcc (install) =3D=3D=3D> kerberos5/lib/libheimipcs (install) 1 error *** [libraries] Error code 2 1 error *** [build32] Error code 2 1 error *** [buildworld] Error code 2 1 error --------------enig2EE94AAC8E74B56989C93C1E 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) iQEcBAEBAgAGBQJRAlkfAAoJEOgBcD7A/5N8HPsIANYm+igP1VmXNwhUwheKPofY 0nMGMZbwUxYGQy5ql4Tvg6GT+wi1nv3x8OIT8wEFRGEEKi5UZRqekz2avhStGP07 zpNIGEmJ/Qj5sdb5gk43feNZleZsAEqS4jf0DoDfZgiDWtNxwtckezzFEzXuI8wO vBOqTJDIm4P2VXHR9Eplw2Sp5k6OHEXkUEBezpZqFYn7gvRX/+5T7SbaFoOX+rqj 7/BpU4xgmmuUlmv0OVgKJrwjRICHOzmDYUrbi60fozU8uh4Zchq+d/NcZcIuYJeu VVI/2CaD728bb6srVcSKw/Mx7W1IA8ai56dHE+BCAU065xoqVySCpP51mypjjwk= =6AlT -----END PGP SIGNATURE----- --------------enig2EE94AAC8E74B56989C93C1E-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 10:45:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3368F2E3; Fri, 25 Jan 2013 10:45:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D8B74F95; Fri, 25 Jan 2013 10:45:14 +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 MAA00680; Fri, 25 Jan 2013 12:45:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TygmS-000FKK-H3; Fri, 25 Jan 2013 12:45:08 +0200 Message-ID: <51026233.2020601@FreeBSD.org> Date: Fri, 25 Jan 2013 12:45:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: My panic in amd64/pmap References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 10:45:16 -0000 on 25/01/2013 03:11 Larry Rosenman said the following: > I've moved all the core.txt's to: > http://www.lerctr.org/~ler/FreeBSD-PMAP/ > > I got another one on FreeBSD9 today.... > > Is there ANYONE interested in this? > > These always seem to be ZFS induced..... > > I've added freebsd-fs to the cc list. > > I have vmcore's from them all. Can you try to reproduce the issue using the same VM image but in a different VM implementation? E.g. qemu... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 12:36:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB514E21 for ; Fri, 25 Jan 2013 12:36:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 204C77E6 for ; Fri, 25 Jan 2013 12:36:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0PCZs2Q094581 for ; Fri, 25 Jan 2013 14:35:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0PCZs2Q094581 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0PCZspT094580 for current@freebsd.org; Fri, 25 Jan 2013 14:35:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jan 2013 14:35:54 +0200 From: Konstantin Belousov To: current@freebsd.org Subject: Fast gettimeofday(2) and static linking Message-ID: <20130125123554.GQ2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3DRm6T3aFkHkz+Qz" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 12:36:03 -0000 --3DRm6T3aFkHkz+Qz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bruce Evans reported that statically linked binaries on HEAD an stable/9 use the syscall for gettimeofday(2) and clock_gettime(2). Apparently, this is due to my use of the weak reference to the __vdso* symbols in the libc implementations. Patch below reworks the __vdso* attributes to only make the symbols weak, but keep the references strong. Since I have to add a stub for each architecture, I would like to ask non-x86 machines owners to test the patch. Thank you. diff --git a/lib/libc/amd64/sys/__vdso_gettc.c b/lib/libc/amd64/sys/__vdso_= gettc.c index 091fe26..c6f2dfb 100644 --- a/lib/libc/amd64/sys/__vdso_gettc.c +++ b/lib/libc/amd64/sys/__vdso_gettc.c @@ -27,9 +27,11 @@ __FBSDID("$FreeBSD$"); =20 #include +#include #include #include #include +#include "libc_private.h" =20 static u_int __vdso_gettc_low(const struct vdso_timehands *th) @@ -41,9 +43,18 @@ __vdso_gettc_low(const struct vdso_timehands *th) return (rv); } =20 +#pragma weak __vdso_gettc u_int __vdso_gettc(const struct vdso_timehands *th) { =20 return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32()); } + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk))); +} diff --git a/lib/libc/arm/sys/Makefile.inc b/lib/libc/arm/sys/Makefile.inc index 1a58eae..fd251c8 100644 --- a/lib/libc/arm/sys/Makefile.inc +++ b/lib/libc/arm/sys/Makefile.inc @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +SRCS+=3D __vdso_gettc.c + MDASM=3D Ovfork.S brk.S cerror.S pipe.S ptrace.S sbrk.S shmat.S sigreturn.= S syscall.S =20 # Don't generate default code for these syscalls: diff --git a/lib/libc/arm/sys/__vdso_gettc.c b/lib/libc/arm/sys/__vdso_gett= c.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/arm/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/i386/sys/__vdso_gettc.c b/lib/libc/i386/sys/__vdso_ge= ttc.c index 4419141..c6f2dfb 100644 --- a/lib/libc/i386/sys/__vdso_gettc.c +++ b/lib/libc/i386/sys/__vdso_gettc.c @@ -27,9 +27,11 @@ __FBSDID("$FreeBSD$"); =20 #include +#include #include #include #include +#include "libc_private.h" =20 static u_int __vdso_gettc_low(const struct vdso_timehands *th) @@ -48,3 +50,11 @@ __vdso_gettc(const struct vdso_timehands *th) =20 return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32()); } + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk))); +} diff --git a/lib/libc/ia64/sys/Makefile.inc b/lib/libc/ia64/sys/Makefile.inc index 3876d3a..2846590 100644 --- a/lib/libc/ia64/sys/Makefile.inc +++ b/lib/libc/ia64/sys/Makefile.inc @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +SRCS+=3D __vdso_gettc.c + MDASM+=3D Ovfork.S brk.S cerror.S exect.S fork.S getcontext.S pipe.S ptrac= e.S \ sbrk.S setlogin.S sigreturn.S swapcontext.S =20 diff --git a/lib/libc/ia64/sys/__vdso_gettc.c b/lib/libc/ia64/sys/__vdso_ge= ttc.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/ia64/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/mips/sys/Makefile.inc b/lib/libc/mips/sys/Makefile.inc index 3601909..fc11349 100644 --- a/lib/libc/mips/sys/Makefile.inc +++ b/lib/libc/mips/sys/Makefile.inc @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +SRCS+=3D __vdso_gettc.c + MDASM=3D Ovfork.S brk.S cerror.S exect.S \ fork.S pipe.S ptrace.S sbrk.S syscall.S =20 diff --git a/lib/libc/mips/sys/__vdso_gettc.c b/lib/libc/mips/sys/__vdso_ge= ttc.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/mips/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/powerpc/Makefile.inc b/lib/libc/powerpc/Makefile.inc index 453726a..104f80c 100644 --- a/lib/libc/powerpc/Makefile.inc +++ b/lib/libc/powerpc/Makefile.inc @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +SRCS+=3D __vdso_gettc.c + # Long double is 64-bits MDSRCS+=3Dmachdep_ldisd.c SYM_MAPS+=3D${.CURDIR}/powerpc/Symbol.map diff --git a/lib/libc/powerpc/sys/__vdso_gettc.c b/lib/libc/powerpc/sys/__v= dso_gettc.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/powerpc/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/powerpc64/Makefile.inc b/lib/libc/powerpc64/Makefile.= inc index e4ccbb9..a30779d 100644 --- a/lib/libc/powerpc64/Makefile.inc +++ b/lib/libc/powerpc64/Makefile.inc @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +SRCS+=3D __vdso_gettc.c + # Long double is 64-bits MDSRCS+=3Dmachdep_ldisd.c SYM_MAPS+=3D${.CURDIR}/powerpc64/Symbol.map diff --git a/lib/libc/powerpc64/sys/__vdso_gettc.c b/lib/libc/powerpc64/sys= /__vdso_gettc.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/powerpc64/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/sparc64/Makefile.inc b/lib/libc/sparc64/Makefile.inc index 76cc8b9..84a0e06 100644 --- a/lib/libc/sparc64/Makefile.inc +++ b/lib/libc/sparc64/Makefile.inc @@ -5,6 +5,8 @@ =20 .include "fpu/Makefile.inc" =20 +SRCS+=3D __vdso_gettc.c + # Long double is quad precision GDTOASRCS+=3DstrtorQ.c MDSRCS+=3Dmachdep_ldisQ.c diff --git a/lib/libc/sparc64/sys/__vdso_gettc.c b/lib/libc/sparc64/sys/__v= dso_gettc.c new file mode 100644 index 0000000..b99bbc4 --- /dev/null +++ b/lib/libc/sparc64/sys/__vdso_gettc.c @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + + return (0); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (ENOSYS); +} diff --git a/lib/libc/sys/__vdso_gettimeofday.c b/lib/libc/sys/__vdso_getti= meofday.c index 32abb69..a305173 100644 --- a/lib/libc/sys/__vdso_gettimeofday.c +++ b/lib/libc/sys/__vdso_gettimeofday.c @@ -79,6 +79,7 @@ binuptime(struct bintime *bt, struct vdso_timekeep *tk, i= nt abs) =20 static struct vdso_timekeep *tk; =20 +#pragma weak __vdso_gettimeofday int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz) { @@ -88,7 +89,7 @@ __vdso_gettimeofday(struct timeval *tv, struct timezone *= tz) if (tz !=3D NULL) return (ENOSYS); if (tk =3D=3D NULL) { - error =3D _elf_aux_info(AT_TIMEKEEP, &tk, sizeof(tk)); + error =3D __vdso_gettimekeep(&tk); if (error !=3D 0 || tk =3D=3D NULL) return (ENOSYS); } @@ -101,6 +102,7 @@ __vdso_gettimeofday(struct timeval *tv, struct timezone= *tz) return (0); } =20 +#pragma weak __vdso_clock_gettime int __vdso_clock_gettime(clockid_t clock_id, struct timespec *ts) { diff --git a/lib/libc/sys/gettimeofday.c b/lib/libc/sys/gettimeofday.c index 4cc87e1..5b12523 100644 --- a/lib/libc/sys/gettimeofday.c +++ b/lib/libc/sys/gettimeofday.c @@ -41,10 +41,7 @@ __gettimeofday(struct timeval *tv, struct timezone *tz) { int error; =20 - if (__vdso_gettimeofday !=3D NULL && __vdso_gettc !=3D NULL) - error =3D __vdso_gettimeofday(tv, tz); - else - error =3D ENOSYS; + error =3D __vdso_gettimeofday(tv, tz); if (error =3D=3D ENOSYS) error =3D __sys_gettimeofday(tv, tz); return (error); diff --git a/sys/sys/vdso.h b/sys/sys/vdso.h index 653a606..f584315 100644 --- a/sys/sys/vdso.h +++ b/sys/sys/vdso.h @@ -61,13 +61,9 @@ struct timeval; struct timezone; =20 int __vdso_clock_gettime(clockid_t clock_id, struct timespec *ts); -#pragma weak __vdso_clock_gettime - int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz); -#pragma weak __vdso_gettimeofday - u_int __vdso_gettc(const struct vdso_timehands *vdso_th); -#pragma weak __vdso_gettc +int __vdso_gettimekeep(struct vdso_timekeep **tk); =20 #endif =20 --3DRm6T3aFkHkz+Qz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAnwpAAoJEJDCuSvBvK1BJ1MP/jdpPvlEN5beUNgH3oDJvHhk v7FRRKPxjL15vDGp7eS8H/156RCrPMhx5NNovEfNlyXKjMfZVn2AdpTuPBWgjmj5 hnM5pIrebJXGgfTs9jpk3INpQzTNuEZ5NF055lyBVurUPB3VD7rnf8l6Uw6p3F2H 4asMh+HZ/dMtK5ODDEvvmoZFItzO/VNVdol5FLgPQcuJ9QLPgqW/KjQJeV6YWclj mXo9FhCJpONHYsZu7tkxr+vi373wZehpdsRly7tjQ9Th5uA67NnGEOs+ca8Mao3G +tt/lxg8+Pvz+SFqndfXUOGNUk9zy+DAs2Y8pI2F8ycKX8TNOmdREHbZ0Yh4lEY/ 8xTdocI5am2dWkEnRb/d85RqNC+r9Md6aZOTcrevp9g4ezDNqjcrk2gmcAJdHMsF AAcD1D9stP4k3kT4ZeD9b+s6s3LUTQR6OYm8TTwjKacy7XcUn1IvTPMdA3iLsSpf bt4O7FCnJ14iq0Bb6yx6TMDIFjbgK343wyg5dmK9iXwXKmgRYm4RttTXqSfjAWV4 NI5ffz5f5PAb1Gzb71w8xRPjc5rUjqr2Vdw/pDYQRYqs+FHmb8Pt0KP9E2g6TBw7 cqnCQqmewn8e0oNDaAc4zJL60JLyQAx7GxaOCYTBdcIPTeWoSitax87O06zEIbZE G/6+apNMyk3azMasoF34 =IGaq -----END PGP SIGNATURE----- --3DRm6T3aFkHkz+Qz-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 14:57:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7227F476; Fri, 25 Jan 2013 14:57:11 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41604B8; Fri, 25 Jan 2013 14:57:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=HSnH/o2PVUCD+Ej1wqnwuHu5FGyYhr7+Us8RTdvG834=; b=KVmM55NYZ+zN6RmPlpgOHNjgE3EkDAzqvmRdTPsXaku3btAQv1VNPyNLaXwPuVHYLCbGKo8Q55EMTNGYlIx4RjEYIh9OonbP+dyvNnBje1SY7VE0HcV4lV5mVabuuxmMlVjLtUrAmqvHq/DXJq2rsF16fBKW132SXdHUBN4qtYU=; Received: from localhost.lerctr.org ([127.0.0.1]:18569 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TykiM-00031z-5J; Fri, 25 Jan 2013 08:57:10 -0600 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 25 Jan 2013 08:57:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jan 2013 08:57:10 -0600 From: Larry Rosenman To: Andriy Gapon Subject: Re: My panic in amd64/pmap In-Reply-To: <51026233.2020601@FreeBSD.org> References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.org> <51026233.2020601@FreeBSD.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.4 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 14:57:11 -0000 On 2013-01-25 04:45, Andriy Gapon wrote: > on 25/01/2013 03:11 Larry Rosenman said the following: >> I've moved all the core.txt's to: >> http://www.lerctr.org/~ler/FreeBSD-PMAP/ >> >> I got another one on FreeBSD9 today.... >> >> Is there ANYONE interested in this? >> >> These always seem to be ZFS induced..... >> >> I've added freebsd-fs to the cc list. >> >> I have vmcore's from them all. > > Can you try to reproduce the issue using the same VM image but in a > different VM > implementation? E.g. qemu... Can qemu use a VBox setup, or is it easy to convert the vdi's and vbox xml file? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 15:37:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4421F4F1; Fri, 25 Jan 2013 15:37:39 +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 248FD3CB; Fri, 25 Jan 2013 15:37:39 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 77F10B922; Fri, 25 Jan 2013 10:37:38 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: acpi resume related patch Date: Fri, 25 Jan 2013 08:51:25 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <510245B5.8070704@FreeBSD.org> In-Reply-To: <510245B5.8070704@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301250851.25243.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 25 Jan 2013 10:37:38 -0500 (EST) Cc: Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 15:37:39 -0000 On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: > > If you have ACPI suspend/resume working, if it used to work but stopped working > at some time, if it never worked, but you are still hoping, could you please > test the following patch and report back? > > http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch This will break systems not using the local APIC since you unconditionally call lapic_setup() on resume. This was part of the feature of the previous code that by using a dummy pic it could register it only when the local APIC was used. It should also be registered before any of the I/O APICs are by the design of the local_apic.c code. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 16:08:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9797A767; Fri, 25 Jan 2013 16:08:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B2E46810; Fri, 25 Jan 2013 16:08:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA03087; Fri, 25 Jan 2013 18:08:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5102ADF6.4060202@FreeBSD.org> Date: Fri, 25 Jan 2013 18:08:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: acpi resume related patch References: <510245B5.8070704@FreeBSD.org> <201301250851.25243.jhb@freebsd.org> In-Reply-To: <201301250851.25243.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 16:08:30 -0000 on 25/01/2013 15:51 John Baldwin said the following: > On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: >> >> If you have ACPI suspend/resume working, if it used to work but stopped working >> at some time, if it never worked, but you are still hoping, could you please >> test the following patch and report back? >> >> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch > > This will break systems not using the local APIC since you unconditionally > call lapic_setup() on resume.This was part of the feature of the previous > code that by using a dummy pic it could register it only when the local APIC > was used. Thank you for drawing my attention to this. I will try to fix this issue. The reason I want to remove lapic from 'pics' (and I already described it in a private email) is that Local APIC is a special kind of PIC. It's already explicitly initialized by APs. Putting it into 'pics' tailq just obfuscates the code. > It should also be registered before any of the I/O APICs are by > the design of the local_apic.c code. In fact, as I see in the code, Local APIC is always registered _after_ I/O APICs. And thus lapic_resume was called after ioapic_resume. Additionally, currently there is no synchronization between initialization of Local APICs on APs and initialization of I/O APICs at the wakeup/resume time. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 16:30:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35045D34 for ; Fri, 25 Jan 2013 16:30:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id EEF448F1 for ; Fri, 25 Jan 2013 16:30:53 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r0PGUrXo046100; Fri, 25 Jan 2013 08:30:53 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r0PGUrP7046099; Fri, 25 Jan 2013 08:30:53 -0800 (PST) (envelope-from david) Date: Fri, 25 Jan 2013 08:30:53 -0800 From: David Wolfskill To: "O. Hartmann" Subject: Re: r245901: make buildworld fails: ===> kerberos5/lib/libheimipcs (install) Message-ID: <20130125163053.GV29203@albert.catwhisker.org> References: <51025918.8070002@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="geqNt1NAoYRYy2Pr" Content-Disposition: inline In-Reply-To: <51025918.8070002@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 16:30:54 -0000 --geqNt1NAoYRYy2Pr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 11:06:16AM +0100, O. Hartmann wrote: > Just want to note that make buildworld fails on > r245901 with the following unhealthy end: >=20 > =3D=3D=3D> kerberos5/lib/libheimbase (install) > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libheimbase.a > /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 > libheimbase_p.a /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 > libheimbase.so.11 /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -l s libheimbase.so.11 > /usr/obj/usr/src/lib32/usr/lib32/libheimbase.so > =3D=3D=3D> kerberos5/lib/libheimipcc (install) > =3D=3D=3D> kerberos5/lib/libheimipcs (install) > 1 error > *** [libraries] Error code 2 > 1 error > *** [build32] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error >=20 I did not have a problem updating from: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #801 r2458= 76M/245876: Thu Jan 24 08:15:00 PST 2013 root@g1-227.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 to FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #802 r2459= 01M/245901: Fri Jan 25 08:05:54 PST 2013 root@g1-227.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 (The "M" flag is because I modified sys/conf/newvers.sh to refactor all of the VCS-specific stuff into external files so I don't need to run code for VCSen I don't use.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --geqNt1NAoYRYy2Pr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlECszwACgkQmprOCmdXAD1I8QCbBGEYoGWJFlcFmilgj4bAPDbZ 6hYAn2vMcjhagWGkLaoFdrRwj1dYSNGQ =mrrP -----END PGP SIGNATURE----- --geqNt1NAoYRYy2Pr-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 19:01:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D97954B9 for ; Fri, 25 Jan 2013 19:01:39 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9746914D for ; Fri, 25 Jan 2013 19:01:39 +0000 (UTC) X-AuditID: 1209190d-b7fa66d0000008f6-b6-5102d560cf38 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 18.22.02294.065D2015; Fri, 25 Jan 2013 13:56:32 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r0PIuWsE007209; Fri, 25 Jan 2013 13:56:32 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id r0PIuUJj002775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jan 2013 13:56:31 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r0PIuTQ5000674; Fri, 25 Jan 2013 13:56:29 -0500 (EST) Date: Fri, 25 Jan 2013 13:56:29 -0500 (EST) From: Benjamin Kaduk To: "O. Hartmann" Subject: Re: r245901: make buildworld fails: ===> kerberos5/lib/libheimipcs (install) In-Reply-To: <51025918.8070002@zedat.fu-berlin.de> Message-ID: References: <51025918.8070002@zedat.fu-berlin.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrptwlSnQ4MFtOYs5bz4wWfyd9YfJ gcljxqf5LB6nth9kDGCK4rJJSc3JLEst0rdL4Mrov3iGvWAPe0XrvWvMDYxT2boYOTkkBEwk Zu1dxw5hi0lcuLceKM7FISSwj1Hiyt7fUM4GRolpb7pYIZwTTBKvZu1hBWkREmhglDg/LxDE ZhHQlljxth9sLJuAisTMNxvBbBEBfYlzTafBbGYBQ4k5B7vAeoUFwiUOnuhiAbE5BYwkpu2Z A1bDK+AgMWvNPzaI+YYSHxqegp0nKqAjsXr/FBaIGkGJkzOfsEDMtJQ49+c62wRGwVlIUrOQ pBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIClVOSd4djO8OKh1iFOBg VOLh9VjAFCjEmlhWXJl7iFGSg0lJlHfmeaAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV4ZE6Ac b0piZVVqUT5MSpqDRUmc90rKTX8hgfTEktTs1NSC1CKYrAwHh5IEb8gVoEbBotT01Iq0zJwS hDQTByfIcB6g4VkgNbzFBYm5xZnpEPlTjIpS4rx5IAkBkERGaR5cLyyVvGIUB3pFmDcGpIoH mIbgul8BDWYCGrx/1v8AoMEliQgpqQbGSS0qKk8e/XU0fXXy5qbyfy9b6y4c91msmRz+eIp5 m/S0h7FKDm/eWbVaGGVZXzq0kLu0+MCXpD6D1lTN4idm1c6rNuhxb3i189CUSTt7ivilWnOF PD0K82Q79T5tCgsX7J2x8MZ3vcigeYefLbV7/3OSWuCnuIBcVoW925ZG/7bOCrm05121Ektx RqKhFnNRcSIAubIllAADAAA= Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 19:01:39 -0000 On Fri, 25 Jan 2013, O. Hartmann wrote: > Just want to note that make buildworld fails on > r245901 with the following unhealthy end: > > ===> kerberos5/lib/libheimbase (install) > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libheimbase.a > /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 > libheimbase_p.a /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 > libheimbase.so.11 /usr/obj/usr/src/lib32/usr/lib32 > sh /usr/src/tools/install.sh -l s libheimbase.so.11 > /usr/obj/usr/src/lib32/usr/lib32/libheimbase.so > ===> kerberos5/lib/libheimipcc (install) > ===> kerberos5/lib/libheimipcs (install) > 1 error > *** [libraries] Error code 2 > 1 error > *** [build32] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error It seems that make -jN was used and the actual error not included in this snippet? -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 20:01:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0754C7D9; Fri, 25 Jan 2013 20:01:22 +0000 (UTC) (envelope-from rysto32@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 799F969C; Fri, 25 Jan 2013 20:01:21 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id uo13so908692obb.41 for ; Fri, 25 Jan 2013 12:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=HHblxSDoBl+9CVwy3jKhoDMaH/fz0niloOu23Dmd1yE=; b=Qr4tU2ad7P+j0Jyz+Pqp2j/v2+TWqEn998hBwkstvvTH9u/xTY2mXjA1puH2ECRSmQ IdI269lVgzuRNwmzTtk0Sd2iCROAwbWhW1Ho2W20H9IqEJ18Dc+lMl8d/wQCGgxOdaQK wXbouUvBYyI2uu5sbPAPb8SErkGzO9leqMe+f5msgcqP8Mapyydqu2oafw1y+kEaObuA dusqX93BhBkziRAESV6sU3o69hZr9E9L41RP9g2r188l7o56rngXnJxMWBpa5gK8LfLl R32HD0sphiQBK9rh+v4FZe6KqVNgl4Lv6vkvpBJrLDgDssaQmMUJYcjlDR2ZmykMEXVx OtbQ== MIME-Version: 1.0 X-Received: by 10.182.92.70 with SMTP id ck6mr5481463obb.46.1359144074803; Fri, 25 Jan 2013 12:01:14 -0800 (PST) Received: by 10.76.128.68 with HTTP; Fri, 25 Jan 2013 12:01:14 -0800 (PST) Date: Fri, 25 Jan 2013 15:01:14 -0500 Message-ID: Subject: Why don't we check for preemption when we unlend priority? From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Attilio Rao X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 20:01:22 -0000 I'm having a problem where userland threads are running with a loaned (via mutex priority propagation) priority even after they have released the mutex. This is causing the low-priority userland thread to starve high-priority interrupt threads. One scenario is(which I am seeing on FreeBSD 8.2, but the priority lending code does not seem to have changed in HEAD): 1) I have several swi threads that are pulling packets off of interfaces and forwarding them. Each swi thread is pinned to a CPU. 2) A remote user initiates an scp of a large file to this machine. 3) sshd (which handles the scp) takes a mutex on its socket 4) An interrupt or taskqueue thread belonging to the driver that is receiving the scp traffic tries to take the same mutex. It can't and so it lends its priority to the sshd thread. 5) My swi thread is woken. It is pinned to the same CPU as sshd, but it has a lower priority than the lent priority, so it is placed on the runqueue. 6) The sshd thread releases the mutex. sched_unlend_prio is called to set its priority back to a normal user priority. However, it does not check whether any higher-priority threads are waiting in the runqueue. 7) The sshd thread is allowed to run for its full quantum (100ms). This is easily long enough for my swi thread to start and I drop packets. This is similar to a problem fixed by jhb@ a while ago, which was discussed here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-December/010835.html However in my case it is a thread at an ithread priority that is started, not a userland realtime thread. I don't see why sched_unlend_prio can't check for preemption. I know that in jhb's case we didn't want to check for preemption in userret for performance reasons. In my case, sched_unlend_prio already holds the relevant scheduler lock (and hopefully mutex contention is a rare case anyway), so I don't see that the same performance argument applies. The following proof-of-concept patch for ULE resolves the starvation for me. Any comments? diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c index 01559ee..2659614 100644 --- a/sys/kern/sched_ule.c +++ b/sys/kern/sched_ule.c @@ -1586,6 +1586,22 @@ sched_pctcpu_update(struct td_sched *ts) ts->ts_ftick = ts->ts_ltick - SCHED_TICK_TARG; } +static void +sched_check_preempt(struct tdq *tdq, struct thread *td) +{ + + KASSERT(TD_IS_RUNNING(td), ("thread is not running")); + TDQ_LOCK_ASSERT(tdq, MA_OWNED); + KASSERT(tdq == TDQ_CPU(td->td_sched->ts_cpu), ("tdq does not td")); + + if (tdq == TDQ_SELF()) { + if (td->td_priority > tdq->tdq_lowpri && + sched_shouldpreempt(tdq->tdq_lowpri, td->td_priority, 0)) + td->td_owepreempt = 1; + } else + tdq_notify(tdq, td); +} + /* * Adjust the priority of a thread. Move it to the appropriate run-queue * if necessary. This is the back-end for several priority related @@ -1635,8 +1651,10 @@ sched_thread_priority(struct thread *td, u_char prio) td->td_priority = prio; if (prio < tdq->tdq_lowpri) tdq->tdq_lowpri = prio; - else if (tdq->tdq_lowpri == oldpri) + else if (tdq->tdq_lowpri == oldpri) { tdq_setlowpri(tdq, td); + sched_check_preempt(tdq, td); + } return; } td->td_priority = prio; From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 20:07:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D74C928 for ; Fri, 25 Jan 2013 20:07:01 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id D343C6D5 for ; Fri, 25 Jan 2013 20:07:00 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 0594583C0 for ; Sat, 26 Jan 2013 05:06:59 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id TsGf7lMIIgP1 for ; Sat, 26 Jan 2013 05:06:55 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Sat, 26 Jan 2013 05:06:55 +0900 (JST) Date: Sat, 26 Jan 2013 05:06:54 +0900 From: Taku YAMAMOTO To: FreeBSD Current Subject: [PATCH] to fix slow gen2 Intel video (i830, i845, i85x, i865) with KMS Message-Id: <20130126050654.37ac83fd477464a911b49bf6@tackymt.homeip.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; i386-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__26_Jan_2013_05_06_54_+0900_2f/IEF=5_9PGFAyl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 20:07:01 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__26_Jan_2013_05_06_54_+0900_2f/IEF=5_9PGFAyl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all, A good news to owners of i830, i845, i852, i855 and i865 (a.k.a. gen2), who've got frustrated with the bad performance with KMS. I managed to track down the root cause of the slowness of gen2 with KMS and finally fixed it. The attached one-liner patch is the fix. (It was my surprise that the actual problem lied in agp rather than i915kms.) -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Sat__26_Jan_2013_05_06_54_+0900_2f/IEF=5_9PGFAyl Content-Type: text/plain; name="agp_i830_chipset_flush.patch" Content-Disposition: attachment; filename="agp_i830_chipset_flush.patch" Content-Transfer-Encoding: 7bit --- sys/dev/agp/agp_i810.c.orig 2013-01-20 16:18:33.382363986 +0900 +++ sys/dev/agp/agp_i810.c 2013-01-25 05:47:17.046570619 +0900 @@ -2228,7 +2228,7 @@ agp_i830_chipset_flush(device_t dev) bus_write_4(sc->sc_res[0], AGP_I830_HIC, hic | (1 << 31)); for (i = 0; i < 20000 /* 1 sec */; i++) { hic = bus_read_4(sc->sc_res[0], AGP_I830_HIC); - if ((hic & (1 << 31)) != 0) + if ((hic & (1 << 31)) == 0) break; DELAY(50); } --Multipart=_Sat__26_Jan_2013_05_06_54_+0900_2f/IEF=5_9PGFAyl-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 20:48:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B5E4862 for ; Fri, 25 Jan 2013 20:48:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B060883 for ; Fri, 25 Jan 2013 20:48:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0PKmMUt046421; Fri, 25 Jan 2013 22:48:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0PKmMUt046421 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0PKmLpg046420; Fri, 25 Jan 2013 22:48:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jan 2013 22:48:21 +0200 From: Konstantin Belousov To: Taku YAMAMOTO Subject: Re: [PATCH] to fix slow gen2 Intel video (i830, i845, i85x, i865) with KMS Message-ID: <20130125204821.GY2522@kib.kiev.ua> References: <20130126050654.37ac83fd477464a911b49bf6@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hcIbdsWGSbvvNW1J" Content-Disposition: inline In-Reply-To: <20130126050654.37ac83fd477464a911b49bf6@tackymt.homeip.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 20:48:32 -0000 --hcIbdsWGSbvvNW1J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2013 at 05:06:54AM +0900, Taku YAMAMOTO wrote: > Hi all, >=20 > A good news to owners of i830, i845, i852, i855 and i865 (a.k.a. gen2), > who've got frustrated with the bad performance with KMS. >=20 > I managed to track down the root cause of the slowness of gen2 with KMS a= nd > finally fixed it. > The attached one-liner patch is the fix. > (It was my surprise that the actual problem lied in agp rather than i915k= ms.) >=20 > --=20 > -|-__ YAMAMOTO, Taku > | __ < >=20 > - A chicken is an egg's way of producing more eggs. - > --- sys/dev/agp/agp_i810.c.orig 2013-01-20 16:18:33.382363986 +0900 > +++ sys/dev/agp/agp_i810.c 2013-01-25 05:47:17.046570619 +0900 > @@ -2228,7 +2228,7 @@ agp_i830_chipset_flush(device_t dev) > bus_write_4(sc->sc_res[0], AGP_I830_HIC, hic | (1 << 31)); > for (i =3D 0; i < 20000 /* 1 sec */; i++) { > hic =3D bus_read_4(sc->sc_res[0], AGP_I830_HIC); > - if ((hic & (1 << 31)) !=3D 0) > + if ((hic & (1 << 31)) =3D=3D 0) > break; > DELAY(50); > } This looks right, comparing our (mine) code and the Linux intel-gtt.c. Thank you for tracking it down. Unfortunately, this magic is not documented at all. The 855GM datasheet I have completely omits a description for the register 0x70 of the host bridge. The only reference we are allowed to see is in the Linux agp driver source. I will wait a little before committing, in the hope that someone gives the change an additional test. --hcIbdsWGSbvvNW1J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAu+UAAoJEJDCuSvBvK1B9pMQAIqibTx39+2PM1Urc4wL6LTM g4IdQLQ/TQZtitVYMHEC8OtkUNlRe5xxSVTSmng8E8sk+uCFm5JiDgwDrQ6kGAsh 3mDNhsBDe+GXOa9QkaeESoeOyEPCh22LK8NBwF6bBx2cVM9LNmUtmljEEwsLIt5C G/BJNrdV54IjIdp9F6IGUSucn695VjDQm7oJMbm0NLZyxIcKCt5oTD09ojJ59gr+ tCPvGJW8R/wSar1vk/ZpFrgJGF8ahTcbPd1hkhYVP6tXMSTJmSbUCeKWy7xTwCrj Fl8raY/V+3BzzWR9uu5G4KFK+jYZSit20u4HEzTFD3czryoxGUffA2aPQbJpEyYA HlbNQnZ2DvTkXjfcKfIEI87Pnhe6O5FhOOn7KbO2O55uC9MQ/pDUjsCFqH1vMdq+ IeopcAuAJorv1XwdSjRMnAy3HI96SiYKhrXQ9mo648oO2xjmYQzmBg8t1eQ6cL5y LCMq1pYlgZISuyQKp889dtfJQgGpNFUBX8B5hlS5fVzw9vlFJ/1/nkCvxhayJuzM SlXhxJWq8wGocg5wyZ6KqpLIQgJTDVcScOCG30opVnm0WH2clZEX3/Ma8QlED90q YD9SRWW47BgjRP+17BaDof5WxFLxCU+bK2AlScBVzGc1S1R2/kZdi6GrwLr7XUjW P+Ful6QsofOtoznXPHaj =jgSn -----END PGP SIGNATURE----- --hcIbdsWGSbvvNW1J-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 21:21:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53E32CD9; Fri, 25 Jan 2013 21:21:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CBB65A7E; Fri, 25 Jan 2013 21:21:09 +0000 (UTC) Message-ID: <5102F6F0.4000100@FreeBSD.org> Date: Fri, 25 Jan 2013 16:19:44 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130116 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: ACPI panic on unplugging the power cord. References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> <20130124161848.GA2386@garage.freebsd.pl> <20130125092602.GB1295@garage.freebsd.pl> In-Reply-To: <20130125092602.GB1295@garage.freebsd.pl> X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------000606020304020107010502" Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jan 2013 21:21:10 -0000 This is a multi-part message in MIME format. --------------000606020304020107010502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote: > On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek > wrote: >> One is when I leave laptop idle for some time (few hours?): >> >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg > > Small update. This panic doesn't happen when the system is idle, > it happens we I close the lid to the point when display is turned > off (which is almost closed, but not entirely closed). > > Closing lid doesn't trigger suspend or anything like that. It just > turns off the display. Please try the attached patch (with my previous patch). Also, available from here: http://people.freebsd.org/~jkim/acpi_exit.diff Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRAvbwAAoJECXpabHZMqHOhkwIALmKk6ylgFwrvgTCWUZKrJXM X41gMBhbNnMoa+g/lBwxIsTxb17zXRAN2T8K6xOQZoB66vjW+ykq38SU0qQTaTLt ldihTV7xZawmMz/t5meshDZCbXUTtwOd6ChdFrjgc8+FUq+siL3mRi5UpoIk8o0k wblQ2werCGESIReW57cfGTnF+Sbfz1fBbobos+04gvs9d72FEfrsGRwSZv/wsBYP RKv2zGGWFzXSgPwYHbA+Nz1Tt36zl1npLV7mx/nijA6CNtYvL/RX4QDUTxFw2G5h Bjr3kVXTqz2ITM/K6Oajel6HE1utYDEMgBUL3kaEKdmxK2cguZmcP3p04f1XzRw= =AUMk -----END PGP SIGNATURE----- --------------000606020304020107010502 Content-Type: text/x-patch; name="acpi_exit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_exit.diff" Index: sys/contrib/dev/acpica/include/acoutput.h =================================================================== --- sys/contrib/dev/acpica/include/acoutput.h (revision 245916) +++ sys/contrib/dev/acpica/include/acoutput.h (working copy) @@ -329,9 +329,9 @@ /* Helper macro */ -#define ACPI_TRACE_ENTRY(Name, Function, Cast, Param) \ +#define ACPI_TRACE_ENTRY(Name, Function, Type, Param) \ ACPI_FUNCTION_NAME (Name) \ - Function (ACPI_DEBUG_PARAMETERS, Cast (Param)) + Function (ACPI_DEBUG_PARAMETERS, (Type) (Param)) /* The actual entry trace macros */ @@ -340,13 +340,13 @@ AcpiUtTrace (ACPI_DEBUG_PARAMETERS) #define ACPI_FUNCTION_TRACE_PTR(Name, Pointer) \ - ACPI_TRACE_ENTRY (Name, AcpiUtTracePtr, (void *), Pointer) + ACPI_TRACE_ENTRY (Name, AcpiUtTracePtr, void *, Pointer) #define ACPI_FUNCTION_TRACE_U32(Name, Value) \ - ACPI_TRACE_ENTRY (Name, AcpiUtTraceU32, (UINT32), Value) + ACPI_TRACE_ENTRY (Name, AcpiUtTraceU32, UINT32, Value) #define ACPI_FUNCTION_TRACE_STR(Name, String) \ - ACPI_TRACE_ENTRY (Name, AcpiUtTraceStr, (char *), String) + ACPI_TRACE_ENTRY (Name, AcpiUtTraceStr, char *, String) #define ACPI_FUNCTION_ENTRY() \ AcpiUtTrackStackPtr() @@ -361,16 +361,37 @@ * * One of the FUNCTION_TRACE macros above must be used in conjunction * with these macros so that "_AcpiFunctionName" is defined. + * + * There are two versions of most of the return macros. The default version is + * safer, since it avoids side-effects by guaranteeing that the argument will + * not be evaluated twice. + * + * A less-safe version of the macros is provided for optional use if the + * compiler uses excessive CPU stack (for example, this may happen in the + * debug case if code optimzation is disabled.) */ /* Exit trace helper macro */ -#define ACPI_TRACE_EXIT(Function, Cast, Param) \ +#ifndef ACPI_SIMPLE_RETURN_MACROS + +#define ACPI_TRACE_EXIT(Function, Type, Param) \ ACPI_DO_WHILE0 ({ \ - Function (ACPI_DEBUG_PARAMETERS, Cast (Param)); \ - return ((Param)); \ + register Type _Param = (Type) (Param); \ + Function (ACPI_DEBUG_PARAMETERS, _Param); \ + return (_Param); \ }) +#else /* Use original less-safe macros */ + +#define ACPI_TRACE_EXIT(Function, Type, Param) \ + ACPI_DO_WHILE0 ({ \ + Function (ACPI_DEBUG_PARAMETERS, (Type) (Param)); \ + return (Param); \ + }) + +#endif /* ACPI_SIMPLE_RETURN_MACROS */ + /* The actual exit macros */ #define return_VOID \ @@ -380,13 +401,13 @@ }) #define return_ACPI_STATUS(Status) \ - ACPI_TRACE_EXIT (AcpiUtStatusExit, (ACPI_STATUS), Status) + ACPI_TRACE_EXIT (AcpiUtStatusExit, ACPI_STATUS, Status) #define return_PTR(Pointer) \ - ACPI_TRACE_EXIT (AcpiUtPtrExit, (UINT8 *), Pointer) + ACPI_TRACE_EXIT (AcpiUtPtrExit, void *, Pointer) #define return_VALUE(Value) \ - ACPI_TRACE_EXIT (AcpiUtValueExit, (UINT64), Value) + ACPI_TRACE_EXIT (AcpiUtValueExit, UINT64, Value) /* Conditional execution */ --------------000606020304020107010502-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 09:58:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 267F27F6; Sat, 26 Jan 2013 09:58:13 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA2E85F; Sat, 26 Jan 2013 09:58:12 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c41so573508eek.41 for ; Sat, 26 Jan 2013 01:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=tn1Q6N4PNIeGI3Opomv4sWpUY9atuaPI/uOYO6HCpNg=; b=DNurDvobn11Wa92PdXzmInsZC/sfo3mvkYsMuS8jL7O9Z5YUfyQKu7oTmexAQEpUwD eyFnBkQips5pw8TBms0bfFy9J5NPTDqJ5MjeOpAEQVrPiWnyjlLLAlrlfvyMupghwsZ4 +oVkkzLpe+KgQ1ZIPIeeW+aGp7nFNbRxV1B8c48tOIFJvJv0wEOprXbeKeEyjq5k781u dZvn+TSrMOAcsiDcKnYFplndJ3VhYaAFjugBryDAbE+jjGUYQSiRe/d3xuvbRkU6Ga0M 1a9CXx47+BjRPj4vo+4xj/sMBLtaNxFI1nrsvPJjDHkeU66mJyvUdELp8fGzvGoz3gJ8 f42Q== MIME-Version: 1.0 X-Received: by 10.14.211.136 with SMTP id w8mr28470103eeo.7.1359194285012; Sat, 26 Jan 2013 01:58:05 -0800 (PST) Received: by 10.14.45.5 with HTTP; Sat, 26 Jan 2013 01:58:04 -0800 (PST) Date: Sat, 26 Jan 2013 01:58:04 -0800 Message-ID: Subject: hwpmc support for Ivy Bridge Xeon From: hiren panchasara To: freebsd-current Content-Type: text/plain; charset=UTF-8 Cc: Jim Harris , Fabien Thomas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 09:58:13 -0000 I've tried to update hwpmc by adding support for xeon class of Ivy bridge processors. Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) I do not have a reference machine to test with. Any help in that regard would be appreciated. Here are the diffs against head (245927): http://www.strugglingcoder.info/patches/hwpmc_ibx.txt Thanks, Hiren From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 11:52:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D345B163; Sat, 26 Jan 2013 11:52:08 +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 C44DCB4E; Sat, 26 Jan 2013 11:52:07 +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 NAA11336; Sat, 26 Jan 2013 13:52:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tz4Il-000Hod-AF; Sat, 26 Jan 2013 13:52:03 +0200 Message-ID: <5103C361.6060605@FreeBSD.org> Date: Sat, 26 Jan 2013 13:52:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: some questions on kern_linker and pre-loaded modules X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 11:52:08 -0000 I. It seems that linker_preload checks a module for being a duplicate module only if the module has MDT_VERSION. This is probably designed to allow different version of the same module to co-exist (for some definition of co-exist)? But, OTOH, this doesn't work well if the module is version-less (no MODULE_VERSION in the code) and is pre-loaded twice (e.g. once in kernel and once in a preloaded file). At present a good example of this is zfsctrl module, which could be present both in kernel (options ZFS) and in zfs.ko. I haven't thought about any linker-level resolution for this issue. I've just tried a plug the ZFS hole for now. commit ed8b18f2d6c4d1be915bff94cdec0c51a479529f Author: Andriy Gapon Date: Wed Dec 19 23:29:23 2012 +0200 [bugfix] zfs: add MODULE_VERSION for zfsctrl This should allow the kernel linker to easily detect a situation when the module is present both in a kernel and in a preloaded file (zfs.ko). diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c index 10d28c2..5721010 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c @@ -5599,6 +5599,7 @@ static moduledata_t zfs_mod = { 0 }; DECLARE_MODULE(zfsctrl, zfs_mod, SI_SUB_VFS, SI_ORDER_ANY); +MODULE_VERSION(zfsctrl, 1); MODULE_DEPEND(zfsctrl, opensolaris, 1, 1, 1); MODULE_DEPEND(zfsctrl, krpc, 1, 1, 1); MODULE_DEPEND(zfsctrl, acl_nfs4, 1, 1, 1); II. It seems that linker_file_register_modules() for the kernel is called after linker_file_register_modules() is called for all the pre-loaded files. linker_file_register_modules() for the kernel is called from linker_init_kernel_modules via SYSINIT(SI_SUB_KLD, SI_ORDER_ANY) and that happens after linker_preload() which is executed via SYSINIT(SI_SUB_KLD, SI_ORDER_MIDDLE). Perhaps this is designed to allow modules in the preloaded files to override modules compiled into the kernel? But this doesn't seem to work well. Because modules from the kernel are not registered yet, linker_file_register_modules() would be successful for the duplicate modules in a preloaded file and thus any sysinits present in the file will also be registered. So, if the module is present both in the kernel and in the preloaded file and the module has a module event handler (modeventhand_t), then the handler will registered and called twice. I cobbled together the following hack, but I am not sure if it is OK or if it violates fundamental architecture/design of this subsystem. commit 14ebf07633d0f0ea393801c3e4161d6c37393661 Author: Andriy Gapon Date: Wed Dec 19 23:27:46 2012 +0200 [wip][experiment] kernel linker: register kernel modules before preloaded modules... Also, skip adding sysinit and sysctl stuff from preloaded modules if module registration fails. This should result in much saner behavior if a module is present in both the kernel and a preloaded file. Perhaps, the original intent was to allow the preloaded files to override modules present in kernel, but that was extremly fragile because of double sysinit registration. diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c index b3ab4df..be46cdf 100644 --- a/sys/kern/kern_linker.c +++ b/sys/kern/kern_linker.c @@ -365,6 +365,7 @@ linker_file_register_modules(linker_file_t lf) return (first_error); } +#if 0 static void linker_init_kernel_modules(void) { @@ -374,6 +375,7 @@ linker_init_kernel_modules(void) SYSINIT(linker_kernel, SI_SUB_KLD, SI_ORDER_ANY, linker_init_kernel_modules, 0); +#endif static int linker_load_file(const char *filename, linker_file_t *result) @@ -1599,7 +1601,11 @@ restart: printf("KLD file %s is missing dependencies\n", lf->filename); linker_file_unload(lf, LINKER_UNLOAD_FORCE); } - +#if 1 + error = linker_file_register_modules(linker_kernel_file); + if (error) + printf("linker_file_register_modules(linker_kernel_file) failed: %d\n", error); +#endif /* * We made it. Finish off the linking in the order we determined. */ @@ -1642,13 +1648,15 @@ restart: * Now do relocation etc using the symbol search paths * established by the dependencies */ + error = linker_file_register_modules(lf); + if (error) + goto fail; error = LINKER_LINK_PRELOAD_FINISH(lf); if (error) { printf("KLD file %s - could not finalize loading\n", lf->filename); goto fail; } - linker_file_register_modules(lf); if (linker_file_lookup_set(lf, "sysinit_set", &si_start, &si_stop, NULL) == 0) sysinit_add(si_start, si_stop); -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 13:41:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7271390 for ; Sat, 26 Jan 2013 13:41:08 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9BFD4FBE for ; Sat, 26 Jan 2013 13:41:08 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id fw7so937719vcb.34 for ; Sat, 26 Jan 2013 05:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UqsmCWeLuuZn0xe9Cuqa9jJ8LtH47RT+gJciSLtQsx4=; b=pFDf5SbTalRUe5fH4neEk404Jry31PMo3rQCpGK+7mDgq7izdBoearN4R5szYRR4mk Ci72DpWkVLe7J3B2xb/PUDWls+T0Ze0k5t35wHGUg9EuhLf6fKr6oGTsJXWY/71eAjrF WugDjYnbM0AucIQy99A3JByThpD0nMKJDKdu26tg3QuSxVixsU3vqr/R0G5qgiNeqE0p BzpYe6/j9vHG01oEobo+4Xtc2oRFrB39RcRM3sXIj8C9wMOph+SNcnG59ms6YCs5zmJQ Quprkr86llCdEeZCl5kkUilo3hk71ScfJSBh8JG5Jm3qB5wD6tZV0XEThmFOLnLXNeVI b2fw== MIME-Version: 1.0 X-Received: by 10.52.66.70 with SMTP id d6mr8320937vdt.30.1359207661589; Sat, 26 Jan 2013 05:41:01 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Sat, 26 Jan 2013 05:41:01 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 05:41:01 -0800 X-Google-Sender-Auth: NTUyddzF1SXs51mBw7c4QSC1DfA Message-ID: Subject: Re: hwpmc support for Ivy Bridge Xeon From: Davide Italiano To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: Fabien Thomas , freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 13:41:08 -0000 On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara wrote: > I've tried to update hwpmc by adding support for xeon class of Ivy > bridge processors. > > Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) > > I do not have a reference machine to test with. Any help in that > regard would be appreciated. > > Here are the diffs against head (245927): > http://www.strugglingcoder.info/patches/hwpmc_ibx.txt > > Thanks, > Hiren > _______________________________________________ > 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 a first look appears good -- I've a couple of observations though. I see your patch covers only core events -- am I missing something? Not really important, and I don't want to be pedantic here, but maybe this can be renamed to something less ugly: static int -iap_event_sb_sbx_ib_ok_on_counter(enum pmc_event pe, int ri) +iap_event_sb_sbx_ib_ibx_ok_on_counter(enum pmc_event pe, int ri) -- Davide From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 14:19:07 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C657493C; Sat, 26 Jan 2013 14:19:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1A4D13D; Sat, 26 Jan 2013 14:19:06 +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 QAA12547; Sat, 26 Jan 2013 16:18:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tz6ax-000HxU-9H; Sat, 26 Jan 2013 16:18:59 +0200 Message-ID: <5103E5D1.3070808@FreeBSD.org> Date: Sat, 26 Jan 2013 16:18:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: acpi resume related patch References: <510245B5.8070704@FreeBSD.org> <201301250851.25243.jhb@freebsd.org> <5102ADF6.4060202@FreeBSD.org> In-Reply-To: <5102ADF6.4060202@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 14:19:07 -0000 on 25/01/2013 18:08 Andriy Gapon said the following: > on 25/01/2013 15:51 John Baldwin said the following: >> On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: >>> >>> If you have ACPI suspend/resume working, if it used to work but stopped working >>> at some time, if it never worked, but you are still hoping, could you please >>> test the following patch and report back? >>> >>> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch >> >> This will break systems not using the local APIC since you unconditionally >> call lapic_setup() on resume.This was part of the feature of the previous >> code that by using a dummy pic it could register it only when the local APIC >> was used. > > Thank you for drawing my attention to this. I will try to fix this issue. > The reason I want to remove lapic from 'pics' (and I already described it in a > private email) is that Local APIC is a special kind of PIC. It's already > explicitly initialized by APs. Putting it into 'pics' tailq just obfuscates the code. > >> It should also be registered before any of the I/O APICs are by >> the design of the local_apic.c code. > > In fact, as I see in the code, Local APIC is always registered _after_ I/O APICs. > And thus lapic_resume was called after ioapic_resume. > Additionally, currently there is no synchronization between initialization of > Local APICs on APs and initialization of I/O APICs at the wakeup/resume time. > Here is an updated version of the patch: http://people.freebsd.org/~avg/acpi-apic-wakeup.2.patch John, could you please review the PIC-related part? I decided to go back to the current approach while fixing the suspend/resume ordering and also order of registration for Local APIC. Must say that XEN special casing makes apic_setup_io a little bit untidy. Additionally this patch fixes AP Local APIC initialization ordering on i386. In the original patch I changed only amd64 code. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 16:57:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA3ACCB0; Sat, 26 Jan 2013 16:57:36 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 889CC7C0; Sat, 26 Jan 2013 16:57:36 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 120468DF; Sat, 26 Jan 2013 17:54:59 +0100 (CET) Date: Sat, 26 Jan 2013 17:58:16 +0100 From: Pawel Jakub Dawidek To: Jung-uk Kim Subject: Re: ACPI panic on unplugging the power cord. Message-ID: <20130126165816.GA1376@garage.freebsd.pl> References: <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> <20130124161848.GA2386@garage.freebsd.pl> <20130125092602.GB1295@garage.freebsd.pl> <5102F6F0.4000100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <5102F6F0.4000100@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 16:57:36 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 04:19:44PM -0500, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote: > > On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek > > wrote: > >> One is when I leave laptop idle for some time (few hours?): > >>=20 > >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg=20 > >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg > >=20 > > Small update. This panic doesn't happen when the system is idle, > > it happens we I close the lid to the point when display is turned > > off (which is almost closed, but not entirely closed). > >=20 > > Closing lid doesn't trigger suspend or anything like that. It just > > turns off the display. >=20 > Please try the attached patch (with my previous patch). Also, > available from here: >=20 > http://people.freebsd.org/~jkim/acpi_exit.diff Your patch fixes panic triggered by unplugging power cable as well the one triggered by closing the lid. I haven't tried booting from battery and connecting power cable, but I expect happy end there as well. Thank you very much for the fix. BTW. When I'm closing the lid and opening it again (not cosing it entirely, just to the point when display is turned off) I see this message to be printed twice on the console: CPU0: local APIC error 0x80 Although I must admit I see this message from time to time, but I haven't found a pattern. Closing and opening the lid always make it appear. Not sure how much it is related to ACPI, though. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEECygACgkQForvXbEpPzQ2SwCgxV513hTG4uZ6V8Ofyjp+jpQu zWkAn3/s6M8iJ8/ZMn44T2IspQlPL/mM =WDki -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 26 20:14:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A30BA2A; Sat, 26 Jan 2013 20:14:12 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4926FE17; Sat, 26 Jan 2013 20:14:10 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so736402eek.33 for ; Sat, 26 Jan 2013 12:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7ZwNZzRqBziCKgah2d6VnJiyYdFqrcwIeNsI+3IfXPQ=; b=oqn2Ml46Qfxpca43UGdTrptUIHrYnXEqk7SvZBGa4yM0d+yUaTEM0GpMQNK5oLmMs+ TLALAm7ss5+psuZKNVN0i49oJ91OHLGdXgSUiCXDfMWICHpHCSkUUsLO/vHXWofnmM7b FLEOe6ABU3zvD+G4gdWHhqygZjbiiL0lgsPVZsV11NET9weFp1SndDgG+6QEkGolfuJr gh3sR1yfKx52Z+uAEppT3XHxeT5/aEtBoolelAe+Hf89chj+JfdxIlbkAWIQzdfT3iV5 t65i6NLJTr+VjmW7sDDn6R3YnQXsJWaOn59XNm4TZkOlg/VDvZ6OJOYh5EPULTB5xf8+ bDAg== MIME-Version: 1.0 X-Received: by 10.14.174.198 with SMTP id x46mr33317673eel.23.1359231249337; Sat, 26 Jan 2013 12:14:09 -0800 (PST) Received: by 10.14.45.5 with HTTP; Sat, 26 Jan 2013 12:14:09 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 12:14:09 -0800 Message-ID: Subject: Re: hwpmc support for Ivy Bridge Xeon From: hiren panchasara To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: Fabien Thomas , freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jan 2013 20:14:12 -0000 Keeping sbruno in the chain. On Sat, Jan 26, 2013 at 5:41 AM, Davide Italiano wrote: > On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara > wrote: >> I've tried to update hwpmc by adding support for xeon class of Ivy >> bridge processors. >> >> Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) >> >> I do not have a reference machine to test with. Any help in that >> regard would be appreciated. >> >> Here are the diffs against head (245927): >> http://www.strugglingcoder.info/patches/hwpmc_ibx.txt >> >> Thanks, >> Hiren >> _______________________________________________ >> 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 a first look appears good -- I've a couple of observations though. > I see your patch covers only core events -- am I missing something? My bad, should've mentioned that diffs only has core events. I could not find uncore events clearly mentioned in the spec. > > Not really important, and I don't want to be pedantic here, but maybe > this can be renamed to something less ugly: > > static int > -iap_event_sb_sbx_ib_ok_on_counter(enum pmc_event pe, int ri) > +iap_event_sb_sbx_ib_ibx_ok_on_counter(enum pmc_event pe, int ri) Now when I look at this yes, we should change it. :-) Not sure about the new name. Thanks for looking into it, Hiren