From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 22:49:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B721065679 for ; Sat, 29 Oct 2011 22:49:56 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 33E798FC14 for ; Sat, 29 Oct 2011 22:49:56 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p9TMYeSU047757; Sat, 29 Oct 2011 15:34:40 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201110292234.p9TMYeSU047757@chez.mckusick.com> To: "deeptech71@gmail.com" In-reply-to: Date: Sat, 29 Oct 2011 15:34:40 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com X-Mailman-Approved-At: Sun, 30 Oct 2011 01:44:33 +0000 Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 22:49:56 -0000 > Date: Fri, 28 Oct 2011 11:16:59 +0200 > From: "deeptech71@gmail.com" > To: freebsd-current@freebsd.org > Subject: panic: ffs_blkfree_cg: freeing free block > > A panic occured while I was ``rm -rf''ing a large file&directory tree > (that I just created with untar) on an old drive that I have not used > for a long time. Unfortunately I'm not 100% sure that the filesystem > was clean when I mounted it today. Could that result in such a panic? > > I don't have the intermediate object files for the kernel; now I'm > building the kernel again (from the appropriate, exact sources). That > shouldn't harm debugging, should it? Meanwhile, I'll take any debug > info requests, which I'll attempt to address shortly. This panic happens when the free-block bitmap is corrupted. That can happen due to: 1) An unclean filesystem being mounted (though you should get a warning when you attempt to do this). 2) Bit-rot on the disk that is not checked for before mounting. This is typically only an issue for a disk that has been offline for a long time. 3) Write errors to the disk. There have been no changes to the code that manage the filesystem bitmaps in decades (nearly three decades), so a software cause of this panic is unlikely to have been recently introduced. Hence, I would not spend a lot of time trying to get a backtrace, etc. Kirk McKusick From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 03:42:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C936106564A; Sun, 30 Oct 2011 03:42:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 98BD78FC0A; Sun, 30 Oct 2011 03:42:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9U3gSOu042476; Sat, 29 Oct 2011 23:42:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9U3gSOG042448; Sun, 30 Oct 2011 03:42:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 30 Oct 2011 03:42:28 GMT Message-Id: <201110300342.p9U3gSOG042448@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 03:42:30 -0000 TB --- 2011-10-30 00:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-30 00:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-30 00:50:00 - cleaning the object tree TB --- 2011-10-30 00:50:28 - cvsupping the source tree TB --- 2011-10-30 00:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-30 00:51:10 - building world TB --- 2011-10-30 00:51:10 - CROSS_BUILD_TESTING=YES TB --- 2011-10-30 00:51:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-30 00:51:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-30 00:51:10 - SRCCONF=/dev/null TB --- 2011-10-30 00:51:10 - TARGET=amd64 TB --- 2011-10-30 00:51:10 - TARGET_ARCH=amd64 TB --- 2011-10-30 00:51:10 - TZ=UTC TB --- 2011-10-30 00:51:10 - __MAKE_CONF=/dev/null TB --- 2011-10-30 00:51:10 - cd /src TB --- 2011-10-30 00:51:10 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 30 00:51:11 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Oct 30 03:26:50 UTC 2011 TB --- 2011-10-30 03:26:50 - generating LINT kernel config TB --- 2011-10-30 03:26:50 - cd /src/sys/amd64/conf TB --- 2011-10-30 03:26:50 - /usr/bin/make -B LINT TB --- 2011-10-30 03:26:50 - cd /src/sys/amd64/conf TB --- 2011-10-30 03:26:50 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-30 03:26:50 - building LINT-NOINET kernel TB --- 2011-10-30 03:26:50 - CROSS_BUILD_TESTING=YES TB --- 2011-10-30 03:26:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-30 03:26:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-30 03:26:50 - SRCCONF=/dev/null TB --- 2011-10-30 03:26:50 - TARGET=amd64 TB --- 2011-10-30 03:26:50 - TARGET_ARCH=amd64 TB --- 2011-10-30 03:26:50 - TZ=UTC TB --- 2011-10-30 03:26:50 - __MAKE_CONF=/dev/null TB --- 2011-10-30 03:26:50 - cd /src TB --- 2011-10-30 03:26:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Oct 30 03:26:50 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT-NOINET /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel ia32_syscall.o:(.bss+0x0): multiple definition of `systrace_probe_func' trap.o:(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-30 03:42:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-30 03:42:27 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-30 03:42:27 - 8107.09 user 1541.27 system 10347.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 07:15:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967A2106566B for ; Sun, 30 Oct 2011 07:15:19 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id 78EA68FC0A for ; Sun, 30 Oct 2011 07:15:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p9U6qnlo037705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Oct 2011 23:52:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p9U6qnqB037704 for freebsd-current@FreeBSD.org; Sat, 29 Oct 2011 23:52:49 -0700 (PDT) (envelope-from jmg) Date: Sat, 29 Oct 2011 23:52:49 -0700 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Message-ID: <20111030065249.GT25601@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 29 Oct 2011 23:52:49 -0700 (PDT) Cc: Subject: how to detach ata w/ new ATA_CAM layer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:15:19 -0000 How am I suppose to detach an ata controller with the new ATA_CAM layer? On the old layer when pulling drives like CF cards, I would always detach, to ensure that nothing would be going on when I pulled the drive, but a quick glance through camcontrol's man page I don't see a way to do that. Anyone have a clue? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 07:28:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1540106564A for ; Sun, 30 Oct 2011 07:28:21 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7638FC0C for ; Sun, 30 Oct 2011 07:28:21 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id A45D77000879 for ; Sun, 30 Oct 2011 08:28:19 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 8271D7000864 for ; Sun, 30 Oct 2011 08:28:19 +0100 (CET) X-SFR-UUID: 20111030072819534.8271D7000864@msfrf2304.sfr.fr Message-ID: <4EACFC93.6010309@davenulle.org> Date: Sun, 30 Oct 2011 08:28:19 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org References: <4EAC0966.2050607@davenulle.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:28:22 -0000 Le 30.10.2011 01:31, Daniel O'Connor a écrit : > On 30/10/2011, at 24:40, David Marec wrote: >> But, now running FreeBSD 9, I get new usb/devd behavior issues. >> >> First, the ulpt module is always loaded. Is there any elegant way to get rid of this 'self loading' behavior, except to remove it from /boot/modules ? >> Anyway, it sounds like HPLIP is now working with the ulpt module loaded. > > I'm not sure what would load it automatically - it may be built into the kernel though. Anyway, as you say it should work with ulpt loaded anyway. I'm quite sure it was not; I mean, if ulpt.ko has been manually removed from /boot/modules, this module is not loaded when I plugged in the printer. >> And, how to handle them with devd ? > > I have a similar problem.. > [ ATTACH statement in devd.conf] > However this doesn't seem to work anymore, it certainly used to.. :( Yep, sounds like it is the same here. > I tried adding the system, subsystem& type parts and changing device-name to cdev but no luck.. I also tried to add entries into /usr/local/etc/devd/devd.conf instead of /etc/devd.conf. And some more unsuccessful attempts, like changing system/subsystem and others, as you did. -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 07:41:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B36106564A for ; Sun, 30 Oct 2011 07:41:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 00CC28FC14 for ; Sun, 30 Oct 2011 07:41:29 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9U7fM6O062190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Oct 2011 18:11:27 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20111030065249.GT25601@funkthat.com> Date: Sun, 30 Oct 2011 18:11:21 +1030 Content-Transfer-Encoding: 7bit Message-Id: References: <20111030065249.GT25601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: how to detach ata w/ new ATA_CAM layer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:41:30 -0000 On 30/10/2011, at 17:22, John-Mark Gurney wrote: > How am I suppose to detach an ata controller with the new ATA_CAM layer? > On the old layer when pulling drives like CF cards, I would always detach, > to ensure that nothing would be going on when I pulled the drive, but a > quick glance through camcontrol's man page I don't see a way to do that. > > Anyone have a clue? If it's not mounted I don't think it matters. However, you could try using "camcontrol eject nnn" on the device. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 07:45:59 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B841065675 for ; Sun, 30 Oct 2011 07:45:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id C591A8FC0C for ; Sun, 30 Oct 2011 07:45:58 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 45B027F382D; Sun, 30 Oct 2011 08:28:42 +0100 (CET) Date: Sun, 30 Oct 2011 08:28:42 +0100 From: Roman Divacky To: David Marec Message-ID: <20111030072842.GA23153@freebsd.org> References: <4EAC033E.6010201@davenulle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAC033E.6010201@davenulle.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:45:59 -0000 This is a bug in clang, llvm supports "amdfam10" but the clang counterpart wasnt updated. Thank you for the report! On Sat, Oct 29, 2011 at 03:44:30PM +0200, David Marec wrote: > hi list, > > > Running FreebSD 9.0 RC-1, the "make buildworld" processing failed on the > following error on its attempt to build 'lib/libssp': > > ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) > rm -f .depend > CC='clang' mkdep -f .depend -a -DHAVE_CONFIG_H > -I/usr/src/gnu/lib/libssp/libs > sp_nonshared/.. > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/g > cclibs/libssp > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcc > libs/include -DPIC > /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/ > gcclibs/libssp/ssp-local.c > clang -O2 -pipe -march=native -DHAVE_CONFIG_H > -I/usr/src/gnu/lib/libssp/libssp_n > onshared/.. > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccl > ibs/libssp > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccli > bs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector > -c /usr > /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-loca > l.c > error: unknown target CPU 'amdfam10' > *** Error code 1 > > Stop in /usr/src/gnu/lib/libssp/libssp_nonshared. > *** Error code 1 > > > > The sources files were updated yesterday evening. > I did not try to process this with gcc yet. > > -- > David Marec, mailto:david.marec@davenulle.org > http://user.lamaiziere.net/david/Site > http://www.diablotins.org/ > _______________________________________________ > 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 Oct 30 07:46:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BC7E1065670 for ; Sun, 30 Oct 2011 07:46:32 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 091FE8FC16 for ; Sun, 30 Oct 2011 07:46:31 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 906437000864 for ; Sun, 30 Oct 2011 08:28:55 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 6E95D7000863 for ; Sun, 30 Oct 2011 08:28:55 +0100 (CET) X-SFR-UUID: 20111030072855453.6E95D7000863@msfrf2304.sfr.fr Message-ID: <4EACFCB7.5040309@davenulle.org> Date: Sun, 30 Oct 2011 08:28:55 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EAC0966.2050607@davenulle.org> <20111029195852.GA90408@stack.nl> In-Reply-To: <20111029195852.GA90408@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:46:32 -0000 Le 29.10.2011 21:58, Jilles Tjoelker a écrit : > On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote: >> So, what's should be the news group&user's rights required by HPLIP/cups >> on FreeBSD 9 ? > >> And, how to handle them with devd ? > > Use devfs rules. Doing this, device rights become unreliable. > [devfsrules_mybox=10] > add path 'fd0*' mode 660 What are the user rights that the devfs interface should set ? mode 0666 for all usb entries ('usb*') ? - ugen stands for "generic" usb support. - Setting 'cups:hplip' rights for 'ugen[0-9]' doesn't do the trick anymore: HPlip needs the suitable rights on 'usb/x.y.*' too, which are now targeted by the ugenx.y links. -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 07:52:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A227D106566C for ; Sun, 30 Oct 2011 07:52:29 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 664178FC16 for ; Sun, 30 Oct 2011 07:52:29 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id F02FB7F3810; Sun, 30 Oct 2011 08:52:24 +0100 (CET) Date: Sun, 30 Oct 2011 08:52:24 +0100 From: Roman Divacky To: David Marec Message-ID: <20111030075224.GA25155@freebsd.org> References: <4EAC033E.6010201@davenulle.org> <20111030072842.GA23153@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111030072842.GA23153@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 07:52:29 -0000 On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: > This is a bug in clang, llvm supports "amdfam10" but the clang counterpart > wasnt updated. Thank you for the report! fwiw, I fixed it in clang r143305, so in the next import this will work just fine :) roman From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 08:56:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D76D106566C for ; Sun, 30 Oct 2011 08:56:36 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 78DB48FC0A for ; Sun, 30 Oct 2011 08:56:35 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RKRBy-0006sR-Ez for freebsd-current@freebsd.org; Sun, 30 Oct 2011 01:56:34 -0700 Date: Sun, 30 Oct 2011 01:56:34 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1319964994443-4949780.post@n5.nabble.com> In-Reply-To: <4EACFCB7.5040309@davenulle.org> References: <4EAC0966.2050607@davenulle.org> <20111029195852.GA90408@stack.nl> <4EACFCB7.5040309@davenulle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 08:56:36 -0000 It would be nice, If somebody would write updated manual documenting whole process of setting up hplip. In past, I could only get it to the point of printing test pages (sigh...) Before release preferably? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949780.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 09:04:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48A6C106566B for ; Sun, 30 Oct 2011 09:04:40 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 233608FC08 for ; Sun, 30 Oct 2011 09:04:39 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RKRJn-0007xc-JM for freebsd-current@freebsd.org; Sun, 30 Oct 2011 02:04:39 -0700 Date: Sun, 30 Oct 2011 02:04:39 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1319965479593-4949796.post@n5.nabble.com> In-Reply-To: <1319964994443-4949780.post@n5.nabble.com> References: <4EAC0966.2050607@davenulle.org> <20111029195852.GA90408@stack.nl> <4EACFCB7.5040309@davenulle.org> <1319964994443-4949780.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 09:04:40 -0000 Or "just" extend hplip section in handbook. http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It could be roughly based upon this: http://freebsd.kde.org/howtos/hplip.php -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949796.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 09:34:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34AC6106566C for ; Sun, 30 Oct 2011 09:34:15 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by mx1.freebsd.org (Postfix) with ESMTP id E3BF88FC14 for ; Sun, 30 Oct 2011 09:34:14 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 6AB2F70000AF for ; Sun, 30 Oct 2011 10:34:13 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 4898470000AC for ; Sun, 30 Oct 2011 10:34:13 +0100 (CET) X-SFR-UUID: 20111030093413297.4898470000AC@msfrf2421.sfr.fr Message-ID: <4EAD1A15.1040102@davenulle.org> Date: Sun, 30 Oct 2011 10:34:13 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EAC0966.2050607@davenulle.org> <20111029195852.GA90408@stack.nl> <4EACFCB7.5040309@davenulle.org> <1319964994443-4949780.post@n5.nabble.com> <1319965479593-4949796.post@n5.nabble.com> In-Reply-To: <1319965479593-4949796.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 09:34:15 -0000 Le 30.10.2011 10:04, Jakub Lach a écrit : > Or "just" extend hplip section in handbook. > > http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It should be a good idea, I agree. Especially in this case, where nobody now knows how and where HPLIP rights have to be settled. > It could be roughly based upon this: > > http://freebsd.kde.org/howtos/hplip.php This one is really outdated. It seems that `hpiod` and `hpssd` are not useful in any way, and, mostly, the use of devfs stands for :setting rights for everyone (or close to) on USB system. -- Et je vais rater ma béarnaise si je continue à répondre. http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 13:06:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DFC106566C for ; Sun, 30 Oct 2011 13:06:33 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by mx1.freebsd.org (Postfix) with ESMTP id 98EFF8FC19 for ; Sun, 30 Oct 2011 13:06:32 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id E0DEA700031E for ; Sun, 30 Oct 2011 14:06:30 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id BB92B700031D for ; Sun, 30 Oct 2011 14:06:30 +0100 (CET) X-SFR-UUID: 20111030130630768.BB92B700031D@msfrf2309.sfr.fr Message-ID: <4EAD4BD6.1080701@davenulle.org> Date: Sun, 30 Oct 2011 14:06:30 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org References: <4EAC0966.2050607@davenulle.org> <4EACFC93.6010309@davenulle.org> In-Reply-To: <4EACFC93.6010309@davenulle.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 13:06:33 -0000 Le 30.10.2011 08:28, David Marec a écrit : >> I have a similar problem.. Le 30.10.2011 08:28, David Marec a écrit : >> I have a similar problem.. A new behavior occurs since I updated the world & kernel this morning. `devd` now executes the entry for hplip, as I defined it inside /usr/local/etc/devd/devd.conf. But, with `ulpt0` forwarded as device node. That sounds ok since ulpt has been loaded and attached by devd (or some other stuff, i dont know); What comes now as the major issue. hold it... since the update, ulpt keeps on being quiet while the printer gets plugged.. So, I changed my script to: #!/bin/sh # # set up /dev/$1.$2.* to cups:hplip -rw-rw--- # logger "HPLIP printer found on $1.$2" logger "setting suitable rights for $1.$2" /usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9] /bin/chmod g+rw /dev/usb/$1.$2.[0-9] ...and used the "nomatch" key instead of the "attach" key into /usr/local/etc/devd/devd.conf nomatch 100 { match "vendor" "0x03f0"; match "product" "0x4712"; action "/root/sbin/ugen-hdle $port $devaddr"; }; 'looks like it works . -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ A new behavior occurs since i update the world & kernel this morning. `devd` now executes the entry for hplip, as I defined it inside /usr/local/etc/devd/devd.conf. But, with `ulpt0` forwarded as device node. That sounds ok since ulpt has been loaded and attached by devd (or some other stuff, i dont know); What comes now as the major issue. And, up to now, ulpt keep on being stuck. So, i change my script to #!/bin/sh # # set up /dev/$1.$2.* to cups:hplip -rw-rw--- # logger "HPLIP printer found on $1.$2" logger "setting suitable rights for $1.$2" /usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9] /bin/chmod g+rw /dev/usb/$1.$2.[0-9] And uses "nomatch" instead of "attach" into /usr/local/etc/devd/devd.conf nomatch 100 { match "vendor" "0x03f0"; match "product" "0x4712"; action "/root/sbin/ugen-hdle $port $devaddr"; }; seems to work finally. -- Délicieuse cette béarnaise. http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 14:55:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822C6106566B; Sun, 30 Oct 2011 14:55:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49CA78FC15; Sun, 30 Oct 2011 14:55:14 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:504f:9791:43c0:21ab]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 7BE214AC1C; Sun, 30 Oct 2011 18:55:01 +0400 (MSK) Date: Sun, 30 Oct 2011 18:54:51 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <43470728.20111030185451@serebryakov.spb.ru> To: current@freebsd.org, hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: In-kernel API for tasks, which could wait? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 14:55:14 -0000 Hello, Current. It was explained to me, that all three GEOM threads (up, down and ctl) could not execute code, which should sleep. It looks sound for up and down, but not for ctl, but it is so now. So, I have question: what should I do if I need to perofrm ONE action, which could block for some time (for example, open file or create ALQ)? I could create thread for this. But it looks strange and too heavy: create= thread to call one function once. Maybe, kernel has some API to postpone such task to one, always-running idle thread? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 15:03:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3B1106568D; Sun, 30 Oct 2011 15:03:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 801D68FC1C; Sun, 30 Oct 2011 15:03:43 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9UF3dqn047709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Oct 2011 17:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9UF3dM5019112; Sun, 30 Oct 2011 17:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9UF3dld019111; Sun, 30 Oct 2011 17:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Oct 2011 17:03:39 +0200 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20111030150339.GP50300@deviant.kiev.zoral.com.ua> References: <43470728.20111030185451@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6B4omjoolujX8zOn" Content-Disposition: inline In-Reply-To: <43470728.20111030185451@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: In-kernel API for tasks, which could wait? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 15:03:44 -0000 --6B4omjoolujX8zOn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2011 at 06:54:51PM +0400, Lev Serebryakov wrote: > So, I have question: what should I do if I need to perofrm ONE > action, which could block for some time (for example, open file or > create ALQ)? >=20 > I could create thread for this. But it looks strange and too heavy: crea= te thread > to call one function once. >=20 > Maybe, kernel has some API to postpone such task to one, > always-running idle thread? See taskqueue(9). On the other hand, waiting for the enqueued task to finish is itself the sleepable action. --6B4omjoolujX8zOn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6tZ0sACgkQC3+MBN1Mb4guAgCfcYfAru4Fg3QD3rJ4Ww0Zo+Dn RS0AoNfmqRCpOFfzLfD4lfF4c2dftR3x =oMrN -----END PGP SIGNATURE----- --6B4omjoolujX8zOn-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 15:11:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B68106564A; Sun, 30 Oct 2011 15:11:41 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 779648FC16; Sun, 30 Oct 2011 15:11:41 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:504f:9791:43c0:21ab]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 83D054AC1C; Sun, 30 Oct 2011 19:11:40 +0400 (MSK) Date: Sun, 30 Oct 2011 19:11:31 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <435960310.20111030191131@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111030150339.GP50300@deviant.kiev.zoral.com.ua> References: <43470728.20111030185451@serebryakov.spb.ru> <20111030150339.GP50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: In-kernel API for tasks, which could wait? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 15:11:41 -0000 Hello, Kostik. You wrote 30 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 19:03:39: > See taskqueue(9). On the other hand, waiting for the enqueued task to > finish is itself the sleepable action. I'll not wait for finishing. Task will put result to volatile atomic field, and it's all.=20 --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 16:55:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F4641065673 for ; Sun, 30 Oct 2011 16:55:39 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE258FC19 for ; Sun, 30 Oct 2011 16:55:38 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 6FED9700004B for ; Sun, 30 Oct 2011 17:55:37 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 4DC1B70000A5 for ; Sun, 30 Oct 2011 17:55:37 +0100 (CET) X-SFR-UUID: 20111030165537318.4DC1B70000A5@msfrf2208.sfr.fr Message-ID: <4EAD8189.40607@davenulle.org> Date: Sun, 30 Oct 2011 17:55:37 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EAC033E.6010201@davenulle.org> <20111030072842.GA23153@freebsd.org> <20111030075224.GA25155@freebsd.org> In-Reply-To: <20111030075224.GA25155@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 16:55:39 -0000 Le 30.10.2011 08:52, Roman Divacky a écrit : > On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: >> This is a bug in clang, llvm supports "amdfam10" but the clang counterpart >> wasnt updated. Thank you for the report! > > fwiw, I fixed it in clang r143305, so in the next import this will work just > fine :) Thank you for getting involved. -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 17:10:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5521065670 for ; Sun, 30 Oct 2011 17:10:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9CF8FC18 for ; Sun, 30 Oct 2011 17:10:22 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9UHAFEj057224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Oct 2011 19:10:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9UHAFbw019626 for ; Sun, 30 Oct 2011 19:10:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9UHAFvI019625 for current@freebsd.org; Sun, 30 Oct 2011 19:10:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Oct 2011 19:10:15 +0200 From: Kostik Belousov To: current@freebsd.org Message-ID: <20111030171015.GR50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gCjauHB7LOSWqPxs" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: x86: how to get maximum possible CPU frequency ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 17:10:23 -0000 --gCjauHB7LOSWqPxs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Assume we are running on the single-package X86 machine, how to answer the question: what is the possible maximum tsc frequency ? I read tsc_levels_changed(), is it the right way to query the max frequency for the general purpose driver ? If yes, could the code be made into the utility function ? BTW, there is some usage of the barriers in sysctl_machdep_tsc_freq() that I do not understand. When the read from tsc_freq is performed with the acquire semantic ? Why there are two store barriers when tsc_freq and tsc_timecounter.tc_frequency are written ? I would think that a single barrier on the last write is enough, but is it needed at all ? --gCjauHB7LOSWqPxs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6thPYACgkQC3+MBN1Mb4iCEACgjX9e2TBMIx1K078YHRqObpfM NOsAn3xZjU5+AYSwWkhpXNzpAAqT52y9 =QWqW -----END PGP SIGNATURE----- --gCjauHB7LOSWqPxs-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 20:23:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79AE3106564A; Sun, 30 Oct 2011 20:23:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id CD7F98FC08; Sun, 30 Oct 2011 20:23:57 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 198365108; Sun, 30 Oct 2011 21:23:55 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sun, 30 Oct 2011 21:20:54 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EAC0966.2050607@davenulle.org> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110302120.54937.hselasky@c2i.net> Cc: David Marec , current@freebsd.org Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:23:58 -0000 On Sunday 30 October 2011 01:31:21 Daniel O'Connor wrote: > I'm not sure what would load it automatically - it may be built into the > kernel though. Anyway, as you say it should work with ulpt loaded anyway. Hi, ulpt is autoloaded by /etc/devd/usb.conf --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 20:30:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF894106568F for ; Sun, 30 Oct 2011 20:30:54 +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 3B19B8FC21 for ; Sun, 30 Oct 2011 20:30:53 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 196811458; Sun, 30 Oct 2011 21:30:52 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 30 Oct 2011 21:27:51 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110302127.51898.hselasky@c2i.net> Cc: "deeptech71@gmail.com" Subject: Re: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:30:54 -0000 On Saturday 29 October 2011 23:26:29 deeptech71@gmail.com wrote: > If a USB mass storage device was connected when the computer was > turned on or reset and the device is left connected, then the system > locks up somewhere around the ``acpi0: on > motherboard'' line (not exactly deterministically at that line). > Otherwise (if the device is connected or disconnected just before > FreeBSD started booting, or if the device is nowhere near the computer > for the whole booting process), the system boots fine. I'm using a > -CURRENT kernel. > Hi, > I don't recall this case happening some time ago. But now, this > happens with and without the NEW_PCIB option. I mention this because > ``acpi0: on motherboard'' is shortly followed by > ``acpi0: reservation of 0, a0000 (3) failed'', whatever that means. Have you tried to turn off USB legacy support in the BIOS? ACPI involves some USB BIOS code most likely which is causing the crash. I think this is maybe not a FreeBSD issue, but if you can binary search the revisions to find exactly what commit broke your system, them I can look further at your issue. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 30 22:23:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA411065672 for ; Sun, 30 Oct 2011 22:23:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DFCDD8FC0A for ; Sun, 30 Oct 2011 22:23:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4dd5:7fa:5daa:979e] (unknown [IPv6:2001:7b8:3a7:0:4dd5:7fa:5daa:979e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 620D75C37; Sun, 30 Oct 2011 23:23:30 +0100 (CET) Message-ID: <4EADCE5E.8080703@FreeBSD.org> Date: Sun, 30 Oct 2011 23:23:26 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: David Marec References: <4EAC033E.6010201@davenulle.org> <20111030072842.GA23153@freebsd.org> <20111030075224.GA25155@freebsd.org> <4EAD8189.40607@davenulle.org> In-Reply-To: <4EAD8189.40607@davenulle.org> Content-Type: multipart/mixed; boundary="------------010501090604020301060102" Cc: freebsd-current@freebsd.org Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 22:23:32 -0000 This is a multi-part message in MIME format. --------------010501090604020301060102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2011-10-30 17:55, David Marec wrote: > Le 30.10.2011 08:52, Roman Divacky a =E9crit : > > >> On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: >>> This is a bug in clang, llvm supports "amdfam10" but the clang counte= rpart >>> wasnt updated. Thank you for the report! >> >> fwiw, I fixed it in clang r143305, so in the next import this will wor= k just >> fine :) > > Thank you for getting involved. I pulled Roman's fixes into head in r226951. This will be merged to stable/9 later, but if you want to try it out in the meantime, please use the attached diff. --------------010501090604020301060102 Content-Type: text/x-diff; name="clang-amdfam10-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clang-amdfam10-1.diff" Index: contrib/llvm/tools/clang/lib/Basic/Targets.cpp =================================================================== --- contrib/llvm/tools/clang/lib/Basic/Targets.cpp (revision 226948) +++ contrib/llvm/tools/clang/lib/Basic/Targets.cpp (working copy) @@ -1282,6 +1282,7 @@ class X86TargetInfo : public TargetInfo { CK_K8SSE3, CK_Opteron, CK_OpteronSSE3, + CK_AMDFAM10, /// This specification is deprecated and will be removed in the future. /// Users should prefer \see CK_K8. @@ -1381,6 +1382,7 @@ class X86TargetInfo : public TargetInfo { .Case("k8-sse3", CK_K8SSE3) .Case("opteron", CK_Opteron) .Case("opteron-sse3", CK_OpteronSSE3) + .Case("amdfam10", CK_AMDFAM10) .Case("x86-64", CK_x86_64) .Case("geode", CK_Geode) .Default(CK_Generic); @@ -1441,6 +1443,7 @@ class X86TargetInfo : public TargetInfo { case CK_K8SSE3: case CK_Opteron: case CK_OpteronSSE3: + case CK_AMDFAM10: case CK_x86_64: return true; } @@ -1459,12 +1462,10 @@ void X86TargetInfo::getDefaultFeatures(llvm::Strin Features["ssse3"] = false; Features["sse41"] = false; Features["sse42"] = false; + Features["sse4a"] = false; Features["aes"] = false; Features["avx"] = false; - // LLVM does not currently recognize this. - // Features["sse4a"] = false; - // FIXME: This *really* should not be here. // X86_64 always has SSE2. @@ -1561,6 +1562,11 @@ void X86TargetInfo::getDefaultFeatures(llvm::Strin setFeatureEnabled(Features, "sse3", true); setFeatureEnabled(Features, "3dnowa", true); break; + case CK_AMDFAM10: + setFeatureEnabled(Features, "sse3", true); + setFeatureEnabled(Features, "sse4a", true); + setFeatureEnabled(Features, "3dnowa", true); + break; case CK_C3_2: setFeatureEnabled(Features, "mmx", true); setFeatureEnabled(Features, "sse", true); @@ -1604,6 +1610,8 @@ bool X86TargetInfo::setFeatureEnabled(llvm::String else if (Name == "avx") Features["avx"] = Features["sse"] = Features["sse2"] = Features["sse3"] = Features["ssse3"] = Features["sse41"] = Features["sse42"] = true; + else if (Name == "sse4a") + Features["sse4a"] = true; } else { if (Name == "mmx") Features["mmx"] = Features["3dnow"] = Features["3dnowa"] = false; @@ -1630,6 +1638,8 @@ bool X86TargetInfo::setFeatureEnabled(llvm::String Features["aes"] = false; else if (Name == "avx") Features["avx"] = false; + else if (Name == "sse4a") + Features["sse4a"] = false; } return true; @@ -1826,6 +1836,11 @@ void X86TargetInfo::getTargetDefines(const LangOpt Builder.defineMacro("__k8__"); Builder.defineMacro("__tune_k8__"); break; + case CK_AMDFAM10: + Builder.defineMacro("__amdfam10"); + Builder.defineMacro("__amdfam10__"); + Builder.defineMacro("__tune_amdfam10__"); + break; case CK_Geode: Builder.defineMacro("__geode"); Builder.defineMacro("__geode__"); --------------010501090604020301060102-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 01:47:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79343106564A for ; Mon, 31 Oct 2011 01:47:53 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 36B108FC13 for ; Mon, 31 Oct 2011 01:47:52 +0000 (UTC) Received: by qyg14 with SMTP id 14so6799749qyg.13 for ; Sun, 30 Oct 2011 18:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YIcDLyNS/QqWK3s+ny1EXVhZNV/Oq47NvxQZdWR1XAU=; b=pGCUMW1vaooJ459KZAHPL246U+7Fo3yUy8XdeN/11iUQLv9kRXrkJSXK4MSzu7nupp 2zOzgmhwH8Ee+VrwirULwoP6cLJmEgmAugIHlhJlGDfw2X+30G3h5FpHyqbzm39O/5Ba jlCp0XezY3xZESIVtLRF6JJs0yjrfNYZKanF0= MIME-Version: 1.0 Received: by 10.229.245.149 with SMTP id lu21mr2661328qcb.70.1320025672118; Sun, 30 Oct 2011 18:47:52 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Sun, 30 Oct 2011 18:47:52 -0700 (PDT) In-Reply-To: <201110302127.51898.hselasky@c2i.net> References: <201110302127.51898.hselasky@c2i.net> Date: Mon, 31 Oct 2011 02:47:52 +0100 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:47:53 -0000 On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky wrote: > On Saturday 29 October 2011 23:26:29 deeptech71@gmail.com wrote: >> I don't recall this case happening some time ago. But now, this >> happens with and without the NEW_PCIB option. I mention this because >> ``acpi0: on motherboard'' is shortly followed by >> ``acpi0: reservation of 0, a0000 (3) failed'', whatever that means. > ACPI involves some USB BIOS code most likely which is causing the crash. I > think this is maybe not a FreeBSD issue, but if you can binary search the > revisions to find exactly what commit broke your system, them I can look > further at your issue. Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, and the lockup also occurs there. > Have you tried to turn off USB legacy support in the BIOS? Hmm. Interesting, only a combination of the following result in the lockup: - Legacy USB Support: Auto (enable if and only if a USB device is connected) or Enabled, - USB 2.0 Controller: Enabled, - USB 2.0 Controller Mode: HiSpeed, - the memory stick is plugged in when the computer starts, and - the memory stick is plugged in when FreeBSD boots. Note that, to reproduce the lockup, it is not sufficient to just have the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also required that the mutherboard recognize the memory stick when the computer starts, and to have the memory stick connected when FreeBSD boots. (If I disable 2.0 support, or set the speed to FullSpeed, or disable legacy support, or do not have the stick plugged in when the computer starts, or do not have the stick plugged in when FreeBSD boots, then the lockup does not occur.) But Windows XP does not produce any lockups in the case where FreeBSD does. Furthermore, in all cases, the memory stick is usable from FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD to lock up? From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 02:01:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F4B6106566C for ; Mon, 31 Oct 2011 02:01:23 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C052A8FC15 for ; Mon, 31 Oct 2011 02:01:22 +0000 (UTC) Received: by ywt32 with SMTP id 32so7174919ywt.13 for ; Sun, 30 Oct 2011 19:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=X+t7FvJhkuKCZ9bX06QPnXGIDcuDjrE34YYJpLY2mvc=; b=R53U7sUDjdhY/5wrUn/aY0QIcRn3iQB5BFy+Kt5lX94BObIoC7I25wbKu2dzgcWxm7 iN1BgeB3kMuObrBWuHfQM4SYqMW6mo0Q1/z6mkyORBUPnEsyMhALBssfajWmPYMGj1up oeJnG42p+b4vA+gfQr15rdbLoYrcKz9A+25K4= Received: by 10.68.60.97 with SMTP id g1mr19749844pbr.108.1320026481713; Sun, 30 Oct 2011 19:01:21 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id mh1sm7413852pbc.11.2011.10.30.19.01.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Oct 2011 19:01:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 30 Oct 2011 19:01:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5083193D-4DEA-4BFC-BD87-612C11B46C90@gmail.com> References: <201110302127.51898.hselasky@c2i.net> To: "deeptech71@gmail.com" X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 02:01:23 -0000 On Oct 30, 2011, at 6:47 PM, deeptech71@gmail.com wrote: > On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky = wrote: >=20 >> On Saturday 29 October 2011 23:26:29 deeptech71@gmail.com wrote: >=20 >>> I don't recall this case happening some time ago. But now, this >=20 >>> happens with and without the NEW_PCIB option. I mention this because >=20 >>> ``acpi0: on motherboard'' is shortly followed by >=20 >>> ``acpi0: reservation of 0, a0000 (3) failed'', whatever that means. >=20 >=20 >=20 >> ACPI involves some USB BIOS code most likely which is causing the = crash. I >=20 >> think this is maybe not a FreeBSD issue, but if you can binary search = the >=20 >> revisions to find exactly what commit broke your system, them I can = look >=20 >> further at your issue. >=20 >=20 >=20 > Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, > and the lockup also occurs there. >=20 >=20 >=20 >> Have you tried to turn off USB legacy support in the BIOS? >=20 >=20 >=20 > Hmm. Interesting, only a combination of the following result in the = lockup: >=20 > - Legacy USB Support: Auto (enable if and only if a USB device is > connected) or Enabled, >=20 > - USB 2.0 Controller: Enabled, >=20 > - USB 2.0 Controller Mode: HiSpeed, >=20 > - the memory stick is plugged in when the computer starts, and >=20 > - the memory stick is plugged in when FreeBSD boots. >=20 > Note that, to reproduce the lockup, it is not sufficient to just have > the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also > required that the mutherboard recognize the memory stick when the > computer starts, and to have the memory stick connected when FreeBSD > boots. (If I disable 2.0 support, or set the speed to FullSpeed, or > disable legacy support, or do not have the stick plugged in when the > computer starts, or do not have the stick plugged in when FreeBSD > boots, then the lockup does not occur.) >=20 >=20 >=20 > But Windows XP does not produce any lockups in the case where FreeBSD > does. Furthermore, in all cases, the memory stick is usable from > FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD > to lock up? Vendor hacks and limited testing on other OSes is the most = likely cause, if it's not a bug within FreeBSD. Just to narrow things = down a bit... 1. Are there are BIOS updates for your motherboard? 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of = this because some ASUS MBs default this setting to off -- which may or = may not cause problems with FreeBSD)? -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 02:46:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C95106566C for ; Mon, 31 Oct 2011 02:46:00 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CB5AE8FC0C for ; Mon, 31 Oct 2011 02:45:59 +0000 (UTC) Received: by qyk35 with SMTP id 35so3973956qyk.13 for ; Sun, 30 Oct 2011 19:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DjHFBiV0qLlgGLSBtVKqVjU3HNL65jQlrVagD8Ro28c=; b=g823hdk0lPftJBuTP0feQQV8cWm0+HTz/fMGZMJ0eB+VMHE9MOAA3UemSd1Y1+sefG 0uFTm8EKCkBPH5SsKtebg72dSE5kL0eGeKXUyLyJ+CZdie2Vh8I/wg2Smn/uzKZF9nOu yVFOffvWptPaaDzaacMkXc9QuqcTCu7aYoRng= MIME-Version: 1.0 Received: by 10.229.65.70 with SMTP id h6mr1235677qci.146.1320029159039; Sun, 30 Oct 2011 19:45:59 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Sun, 30 Oct 2011 19:45:58 -0700 (PDT) In-Reply-To: <5083193D-4DEA-4BFC-BD87-612C11B46C90@gmail.com> References: <201110302127.51898.hselasky@c2i.net> <5083193D-4DEA-4BFC-BD87-612C11B46C90@gmail.com> Date: Mon, 31 Oct 2011 03:45:58 +0100 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 02:46:00 -0000 On Mon, Oct 31, 2011 at 3:01 AM, Garrett Cooper wrote: > On Oct 30, 2011, at 6:47 PM, deeptech71@gmail.com wrote: > >> On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky = wrote: >> >>> On Saturday 29 October 2011 23:26:29 deeptech71@gmail.com wrote: >> >>>> I don't recall this case happening some time ago. But now, this >> >>>> happens with and without the NEW_PCIB option. I mention this because >> >>>> ``acpi0: on motherboard'' is shortly followed by >> >>>> ``acpi0: reservation of 0, a0000 (3) failed'', whatever that means. >> >> >> >>> ACPI involves some USB BIOS code most likely which is causing the crash= . I >> >>> think this is maybe not a FreeBSD issue, but if you can binary search t= he >> >>> revisions to find exactly what commit broke your system, them I can loo= k >> >>> further at your issue. >> >> >> >> Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, >> and the lockup also occurs there. >> >> >> >>> Have you tried to turn off USB legacy support in the BIOS? >> >> >> >> Hmm. Interesting, only a combination of the following result in the lock= up: >> >> - Legacy USB Support: Auto (enable if and only if a USB device is >> connected) or Enabled, >> >> - USB 2.0 Controller: Enabled, >> >> - USB 2.0 Controller Mode: HiSpeed, >> >> - the memory stick is plugged in when the computer starts, and >> >> - the memory stick is plugged in when FreeBSD boots. >> >> Note that, to reproduce the lockup, it is not sufficient to just have >> the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also >> required that the mutherboard recognize the memory stick when the >> computer starts, and to have the memory stick connected when FreeBSD >> boots. (If I disable 2.0 support, or set the speed to FullSpeed, or >> disable legacy support, or do not have the stick plugged in when the >> computer starts, or do not have the stick plugged in when FreeBSD >> boots, then the lockup does not occur.) >> >> >> >> But Windows XP does not produce any lockups in the case where FreeBSD >> does. Furthermore, in all cases, the memory stick is usable from >> FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD >> to lock up? > > > =A0 =A0 =A0 =A0Vendor hacks and limited testing on other OSes is the most= likely cause, if it's not a bug within FreeBSD. Just to narrow things down= a bit... > 1. Are there are BIOS updates for your motherboard? Yes, and I have the latest non-beta version (v1019 (dated 2004-11-08) for P4P800 mutherboards). > 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of th= is because some ASUS MBs default this setting to off -- which may or may no= t cause problems with FreeBSD)? Yes (also, I've just tried disabling ACPI 2.0, with no luck). From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 07:57:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D58106564A; Mon, 31 Oct 2011 07:57:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7B54F8FC12; Mon, 31 Oct 2011 07:57:01 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 199399039; Mon, 31 Oct 2011 08:56:58 +0100 From: Hans Petter Selasky To: Pawel Jakub Dawidek Date: Mon, 31 Oct 2011 08:53:57 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111027170738.GB1667@garage.freebsd.pl> <201110280911.43003.hselasky@c2i.net> <20111028190947.GA1713@garage.freebsd.pl> In-Reply-To: <20111028190947.GA1713@garage.freebsd.pl> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110310853.57877.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 07:57:02 -0000 On Friday 28 October 2011 21:09:47 Pawel Jakub Dawidek wrote: > On Fri, Oct 28, 2011 at 09:11:42AM +0200, Hans Petter Selasky wrote: > > On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote: > > > On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: > > > > This is the root HUB. Can you also show the actual device? > > > > > > Sorry, it wasn't connected, here it goes: > > > > > > ugen0.2: at usbus0, cfg=255 md=HOST spd=HIGH > > > (480Mbps) pwr=ON > > > > > > bLength = 0x0012 > > > bDescriptorType = 0x0001 > > > bcdUSB = 0x0200 > > > bDeviceClass = 0x0000 > > > bDeviceSubClass = 0x0000 > > > bDeviceProtocol = 0x0000 > > > bMaxPacketSize0 = 0x0008 > > > idVendor = 0x0bda > > > idProduct = 0x0119 > > > bcdDevice = 0x1981 > > > iManufacturer = 0x0001 > > > iProduct = 0x0002 > > > iSerialNumber = 0x0003 > > > bNumConfigurations = 0x0001 > > > > Hi, > > > > The control request in question is mandatory according to the UMASS > > specification, and I wonder why it times out and all other control > > requests aswell. > > > > Could you try setting the no-synchronize cache quirk instead, and then > > plug your device. > > > > I'm sorry, but this problem needs further investigation before we can > > make a patch. > > It wasn't immediately obvious for me how to set the no-synchronize cache > quirk, but I think I found it: > > # usbconfig add_quirk UQ_MSC_NO_SYNC_CACHE > > And it seems to work: > > umass0: on usbus0 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready > to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus13 > target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 30799MB (63076352 512 byte sectors: 255H 63S/T 3926C) Hi Pawel, REALTEK, which is the manufacturer of your device has already been quirked: http://svnweb.freebsd.org/base?view=revision&revision=225777 I think the patch is just MFC'ed yet. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 08:52:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56F301065675 for ; Mon, 31 Oct 2011 08:52:53 +0000 (UTC) (envelope-from mokomull@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE6A48FC17 for ; Mon, 31 Oct 2011 08:52:52 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so3119231bkb.13 for ; Mon, 31 Oct 2011 01:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iVeXEZinBfQBHVvXGHw9ADJDYziKsKypIxhjQeewJCY=; b=smecAYnXm8yuym+eXQLN7915Er+msomdZYPpSKUZlp41Br0y6UB9Pa2l15Vbse1TpU HXU3o4hGkdS3ytv6Ip3fLG7kAyHIrojen7H9FEF9bTKOdATN4Cmp7rVI5XYvqnPNGlup jkG7GQpOh6Q28zPLhRBdU/DQKFMcJ5kFOqGlM= MIME-Version: 1.0 Received: by 10.204.16.67 with SMTP id n3mr7934318bka.6.1320049360342; Mon, 31 Oct 2011 01:22:40 -0700 (PDT) Received: by 10.204.30.198 with HTTP; Mon, 31 Oct 2011 01:22:40 -0700 (PDT) Date: Mon, 31 Oct 2011 01:22:40 -0700 Message-ID: From: Matt Mullins To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: ng_ubt fatal trap 12 on RELENG_9 and CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 08:52:53 -0000 I ran into a somewhat interesting snag while trying out FreeBSD 9 on my laptop.=A0 I built a kernel from the RELENG_9 branch, and get a "fatal trap 12" during the initialization sequence.=A0 For testing, I rebuilt the same kernel from the CURRENT branch, with the same problem -- this is the one that I'm debugging now. The kernel was built with the following options in addition to the generic config: options VIMAGE device epair nooptions GEOM_PART_EBR_COMPAT The errors as retrieved from the core dump: ubt0: on usbus0 Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address=A0=A0 =3D 0x28 fault code=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D supervisor read data,= page not present instruction pointer=A0=A0=A0=A0 =3D 0x20:0xffffffff8164475d stack pointer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x28:0xffffff80f7180970 frame pointer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x28:0xffffff80f71809a0 code segment=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D base 0x0, limit 0xfffff, = type 0x1b =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D D= PL 0, pres 1, long 1, def32 0, gran 1 processor eflags=A0=A0=A0=A0=A0=A0=A0 =3D interrupt enabled, resume, IOPL = =3D 0 current process=A0=A0=A0=A0=A0=A0=A0=A0 =3D 15 (usbus0) trap number=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 12 panic: page fault cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff8086b45e at kdb_backtrace+0x5e #1 0xffffffff80835da7 at panic+0x187 #2 0xffffffff80b2ccc0 at trap_fatal+0x290 #3 0xffffffff80b2d009 at trap_pfault+0x1f9 #4 0xffffffff80b2d4cf at trap+0x3df #5 0xffffffff80b17a1f at calltrap+0x8 #6 0xffffffff8163620e at ubt_attach+0x5e #7 0xffffffff80864799 at device_attach+0x69 #8 0xffffffff806d8389 at usb_probe_and_attach+0x1f9 #9 0xffffffff806e078c at uhub_explore+0x46c #10 0xffffffff806cab5e at usb_bus_explore+0x9e #11 0xffffffff806e4783 at usb_process+0xd3 #12 0xffffffff8080927f at fork_exit+0x11f #13 0xffffffff80b17f4e at fork_trampoline+0xe Relevant information pulled from kgdb: (kgdb) bt #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff808358e5 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:442 #2 0xffffffff80835d91 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:607 #3 0xffffffff80b2ccc0 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:818 #4 0xffffffff80b2d009 in trap_pfault (frame=3D0xffffff80f71808c0, usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:734 #5 0xffffffff80b2d4cf in trap (frame=3D0xffffff80f71808c0) at /usr/src/sys/amd64/amd64/trap.c:473 #6 0xffffffff80b17a1f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff8164475d in ng_make_node_common (type=3D0xffffffff81638fc0, nodepp=3D0xfffffe0005b93910) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:655 #8 0xffffffff8163620e in ubt_attach (dev=3D0xfffffe0005e65100) at /usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/= drivers/ubt/ng_ubt.c:455 #9 0xffffffff80864799 in device_attach (dev=3D0xfffffe0005e65100) at device_if.h:180 #10 0xffffffff806d8389 in usb_probe_and_attach (udev=3D0xfffffe000534e000, iface_index=3DVariable "iface_index" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1195 #11 0xffffffff806e078c in uhub_explore (udev=3D0xfffffe00052d3000) at /usr/src/sys/dev/usb/usb_hub.c:269 #12 0xffffffff806cab5e in usb_bus_explore (pm=3DVariable "pm" is not availa= ble. ) at /usr/src/sys/dev/usb/controller/usb_controller.c:259 #13 0xffffffff806e4783 in usb_process (arg=3DVariable "arg" is not availabl= e. ) at /usr/src/sys/dev/usb/usb_process.c:165 #14 0xffffffff8080927f in fork_exit (callout=3D0xffffffff806e46b0 , arg=3D0xffffff8000726e88, frame=3D0xffffff80f7180c50) at /usr/src/sys/kern/kern_fork.c:995 #15 0xffffffff80b17f4e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 (kgdb) list *0xffffffff8164475d 0xffffffff8164475d is in ng_make_node_common (/usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:655). 650 /* Initialize hook list for new node */ 651 LIST_INIT(&node->nd_hooks); 652 653 /* Link us into the name hash. */ 654 mtx_lock(&ng_namehash_mtx); 655 LIST_INSERT_HEAD(&V_ng_name_hash[0], node, nd_nodes); 656 mtx_unlock(&ng_namehash_mtx); 657 658 /* get an ID and put us in the hash chain */ 659 mtx_lock(&ng_idhash_mtx); This is my first time looking at FreeBSD kernel code, so to verify that I'm reading these #defines correctly and not looking at nonsense objects: (kgdb) print ((struct pcpu*) __pcpu)->pc_curthread->td_proc->p_comm $16 =3D "usb\000el", '\0' Time to get dirty and figure out what address V_ng_name_hash points to. First, find the value of curvnet in net/vnet.h: (kgdb) print ((struct pcpu*) __pcpu)->pc_curthread->td_vnet $17 =3D (struct vnet *) 0x0 That looks like a null pointer... not good. It's late, so I'm going to come back to this later. Any ideas on where I should go from here? From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 09:52:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56AD106566C for ; Mon, 31 Oct 2011 09:52:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC7C8FC12 for ; Mon, 31 Oct 2011 09:52:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p9V9qdsC029347; Mon, 31 Oct 2011 12:52:39 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p9V9qd7r029341; Mon, 31 Oct 2011 12:52:39 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 31 Oct 2011 12:52:39 +0300 From: Gleb Smirnoff To: Matt Mullins Message-ID: <20111031095239.GF36064@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org Subject: Re: ng_ubt fatal trap 12 on RELENG_9 and CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:52:41 -0000 On Mon, Oct 31, 2011 at 01:22:40AM -0700, Matt Mullins wrote: M> I ran into a somewhat interesting snag while trying out FreeBSD 9 on M> my laptop.š I built a kernel from the RELENG_9 branch, and get a M> "fatal trap 12" during the initialization sequence.š For testing, I M> rebuilt the same kernel from the CURRENT branch, with the same problem M> -- this is the one that I'm debugging now. M> M> The kernel was built with the following options in addition to the M> generic config: M> options VIMAGE M> device epair M> nooptions GEOM_PART_EBR_COMPAT ... M> (kgdb) list *0xffffffff8164475d M> 0xffffffff8164475d is in ng_make_node_common M> (/usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:655). M> 650 /* Initialize hook list for new node */ M> 651 LIST_INIT(&node->nd_hooks); M> 652 M> 653 /* Link us into the name hash. */ M> 654 mtx_lock(&ng_namehash_mtx); M> 655 LIST_INSERT_HEAD(&V_ng_name_hash[0], node, nd_nodes); M> 656 mtx_unlock(&ng_namehash_mtx); M> 657 M> 658 /* get an ID and put us in the hash chain */ M> 659 mtx_lock(&ng_idhash_mtx); M> M> This is my first time looking at FreeBSD kernel code, so to verify M> that I'm reading these #defines correctly and not looking at nonsense M> objects: M> (kgdb) print ((struct pcpu*) __pcpu)->pc_curthread->td_proc->p_comm M> $16 = "usb\000el", '\0' M> M> Time to get dirty and figure out what address V_ng_name_hash points M> to. First, find the value of curvnet in net/vnet.h: M> (kgdb) print ((struct pcpu*) __pcpu)->pc_curthread->td_vnet M> $17 = (struct vnet *) 0x0 M> M> That looks like a null pointer... not good. M> M> It's late, so I'm going to come back to this later. Any ideas on M> where I should go from here? IMHO, this is definitely related to VIMAGE. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 09:53:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B0910656A9 for ; Mon, 31 Oct 2011 09:53:45 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 365D78FC19 for ; Mon, 31 Oct 2011 09:53:44 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RKoYq-0002Mx-Fx for freebsd-current@freebsd.org; Mon, 31 Oct 2011 02:53:44 -0700 Date: Mon, 31 Oct 2011 02:53:44 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1320054824481-4951986.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: WITHOUT_GCC for build target / system without base gcc (9RC1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:53:45 -0000 Hello. When one can expect being able to have system without base gcc installed? Since I enabled clang, and I'm using gcc46 for ports, having base gcc is largely pointless for me, but couldn't build system with clang only, because of: ===> usr.bin/xlint/llib (all) lint -cghapbx -Cposix /usr/src/usr.bin/xlint/llib/llib-lposix llib-lposix: lint: cannot exec /usr/obj/usr/src/tmp/usr/bin/cc: No such file or directory *** Error code 1 best regards, - Jakub Lach PS. If I'm doing something retarded, feel free to point out. I'm just feeling that 3 compilers on one system is a bit much, and most ports are developed with newest gcc in mind, while for FreeBSD clang is obviously way to go. FWIW, right now I would need base gcc only for compiling libreoffice, and I hope it will change sometime in future. -- View this message in context: http://freebsd.1045724.n5.nabble.com/WITHOUT-GCC-for-build-target-system-without-base-gcc-9RC1-tp4951986p4951986.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 10:25:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FDD5106566B for ; Mon, 31 Oct 2011 10:25:33 +0000 (UTC) (envelope-from armin@frozen-zone.org) Received: from mailbackup.inode.at (mailbackup.inode.at [213.229.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3042C8FC20 for ; Mon, 31 Oct 2011 10:25:33 +0000 (UTC) Received: from [62.99.145.3] (port=29701 helo=mx.inode.at) by mailbackup.inode.at with esmtp (Exim 4.76) (envelope-from ) id 1RKoeX-0000RV-Rq for freebsd-current@freebsd.org; Mon, 31 Oct 2011 10:59:37 +0100 Received: from [84.119.18.197] (port=3710 helo=fz-sub1.local) by smartmx-03.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RKoeJ-0000Fm-Jf; Mon, 31 Oct 2011 10:59:23 +0100 Message-ID: <4EAE714D.50303@frozen-zone.org> Date: Mon, 31 Oct 2011 10:58:37 +0100 From: Armin Pirkovitsch User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pegasus Mc Cleaft References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> <20111025202755.4243ae74@kan.dyndns.org> <20111027185957.54ece0ad@kan.dyndns.org> <005e01cc94fe$dfbe3390$9f3a9ab0$@com> In-Reply-To: <005e01cc94fe$dfbe3390$9f3a9ab0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Alexey Shuvaev' , freebsd-current@freebsd.org, "'C. P. Ghost'" Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:25:33 -0000 Hi! Just wanted to say - in my case the AHCI timeouts (and therefor the panics afterwards) were solved by updating the firmware of my SSDs. [Corsair Force 3, 120GB, old firmware: 1.3, new firmware: 1.3.3] Armin On 10/28/11 01:19, Pegasus Mc Cleaft wrote: >>> If it's only one process, the machine (usually) doesn't hang, even >>> when that process is copying big files back and forth for a long >>> period of time (it's a backup process). But interleave that process >>> with another one accessing the same disk, and poof!, almost >>> immediately ahci timeouts. occur. Very strange... Maybe a race >>> condition of some sort after all? >>> >> >> No, I cannot say there is any specific correlation to IO load of the > machine, >> timeouts I saw happen randomly and seem almost always happen as system > uptime >> crosses two weeks boundary. I am suspecting Samsung firmware at this point. > > Now that's interesting as I use a mixture of Samsung, WD, and Seagate.. And > I do believe the Samsungs tend to do this more. I see ACHI timeouts from > time to time on my machine (10-Current AMD64) but normally only when I am > doing something like a scrub. The machine has never panicked as a result of > this, it normally just FAULTS the drive in the pool and keeps on going. At > that point, doing a camcontrol rescan all does not bring the drive back into > existence (it will normally just hang on that bus for 15-20 seconds and then > carry on without identifying a drive). I have to pull the drive, let it spin > down and then reinsert it. Once its reinserted, the drive comes back on the > bus and I can online it again. > > The weird thing is this.. For me, it only ever seems to be when I am writing > to the pool/disk. Pure reads don't seem to bother it. > > I don't really know at this point if the SATA ports have gone wonkey on the > motherboard, or if the processor on the HD has crashed. I almost tend to > believe it's the drive because camcontrol stops on that port almost as it if > knows there is a link there, but can't talk to it. > > Peg > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 12:26:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D5D31065670 for ; Mon, 31 Oct 2011 12:26:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 11D638FC0A for ; Mon, 31 Oct 2011 12:26:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:55a7:a9f1:1d0f:91f9] (unknown [IPv6:2001:7b8:3a7:0:55a7:a9f1:1d0f:91f9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 45F045C37; Mon, 31 Oct 2011 13:26:58 +0100 (CET) Message-ID: <4EAE9412.2080905@FreeBSD.org> Date: Mon, 31 Oct 2011 13:26:58 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: Jakub Lach References: <1320054824481-4951986.post@n5.nabble.com> In-Reply-To: <1320054824481-4951986.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_GCC for build target / system without base gcc (9RC1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:26:59 -0000 On 2011-10-31 10:53, Jakub Lach wrote: > When one can expect being able to have system > without base gcc installed? There's quite some work to be done. The trickiest part is to get rid of GNU libstdc++, which is sort of a symbiote with gcc. Also, there are still some programs that hardcode ${CC}, and ignore any environment-supplied value. > Since I enabled clang, and > I'm using gcc46 for ports, having base gcc is largely > pointless for me, You should use clang for ports. :) But seriously, building ports which have not explicitly been marked as being gcc 4.5 or 4.6 compatible is taking a chance. It might work, or break in various interesting ways. That said, many problems that manifest in ports when you build them with clang, also pop up with newer versions of gcc, simply because both are more strict with regard to sloppy coding practices. > but couldn't build system with clang only, > because of: > > ===> usr.bin/xlint/llib (all) > lint -cghapbx -Cposix /usr/src/usr.bin/xlint/llib/llib-lposix > llib-lposix: > lint: cannot exec /usr/obj/usr/src/tmp/usr/bin/cc: No such file or directory > *** Error code 1 Yes, this is one of the programs that hardcodedly calls 'cc', and ignores environment values. I simply haven't got to fixing this yet, but I plan on doing so soon. > PS. If I'm doing something retarded, feel free to point out. > I'm just feeling that 3 compilers on one system is a bit much, > and most ports are developed with newest gcc in mind, while > for FreeBSD clang is obviously way to go. As I said, many ports compile fine with clang, so you could get by just with the compiler in base. On my systems, everything is clang-compiled, including all ports, but I am using just a subset of the available ones, of course. There are even people that would like to remove all compilers from the base system, and move them to an external package, so you can freely switch to whatever toolchain has your fancy. But that will take some time to materialize... :) > FWIW, right now I would need base gcc only for compiling > libreoffice, and I hope it will change sometime in future. I have no idea what the issues are with libreoffice, so I can't help you there, sorry. From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 13:02:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E811065672 for ; Mon, 31 Oct 2011 13:02:44 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE8C8FC16 for ; Mon, 31 Oct 2011 13:02:39 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RKrVf-00039C-A8 for freebsd-current@freebsd.org; Mon, 31 Oct 2011 06:02:39 -0700 Date: Mon, 31 Oct 2011 06:02:39 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1320066159307-4952372.post@n5.nabble.com> In-Reply-To: <4EAE9412.2080905@FreeBSD.org> References: <1320054824481-4951986.post@n5.nabble.com> <4EAE9412.2080905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WITHOUT_GCC for build target / system without base gcc (9RC1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:02:44 -0000 Hi, thanks for reply. > But seriously, building ports which > have not explicitly been marked as being > gcc 4.5 or 4.6 compatible is > taking a chance. It might work, or break > in various interesting ways. Yes, I know. I'm just using small subset of ports as well. Will probably try clang for ports too, when feeling suitably adventurous :) While totally unscientific, clang 3.0 (-O2 -march=native) surprised me with getting more MIPS from p7zip than gcc46. Clang built kernel is smaller here too. Libreoffice is not problem per se, considering it's nature, I'm happy it's working at all for me. best regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/WITHOUT-GCC-for-build-target-system-without-base-gcc-9RC1-tp4951986p4952372.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 16:05:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CA601065670; Mon, 31 Oct 2011 16:05:08 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDD38FC0A; Mon, 31 Oct 2011 16:05:07 +0000 (UTC) Received: by qadz32 with SMTP id z32so6803321qad.13 for ; Mon, 31 Oct 2011 09:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HzHWDlQvxpQc5HTyA2TQjFzH9gViilBtMkyEeDD4pZc=; b=j8TIReU3D7nkqgssYCsJuP9ik/ER+IygNOXkzr6klvs5a/MisCHw0goOFAWN5A99FW mRtnigAk152Da3LcM3cnQZibsglBynPgueaBqyuskqN+DarLlvCmYzkt1onPBzmev5Y7 fRqDERjFV2xbQVx8vQp6p9E26O820+KjvV0As= MIME-Version: 1.0 Received: by 10.224.187.75 with SMTP id cv11mr12088509qab.89.1320077106733; Mon, 31 Oct 2011 09:05:06 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Mon, 31 Oct 2011 09:05:06 -0700 (PDT) In-Reply-To: <201110281055.20822.avilla@freebsd.org> References: <201110270133.44259.avilla@freebsd.org> <201110281055.20822.avilla@freebsd.org> Date: Mon, 31 Oct 2011 12:05:06 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Alberto Villa Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:05:08 -0000 On Fri, Oct 28, 2011 at 4:55 AM, Alberto Villa wrote: > On Thursday 27 October 2011 02:34:11 Mehmet Erol Sanliturk wrote: > > In a message previously I mentioned the KDE4 problem for 8.2 amd64 > Release > > , but that message even did not receive a single reply . > > Things just may get lost, sorry. > > > Install X . > > Install KDE4 . > > Login to console . > > Without an .xinitrc file , and unmodified /etc/ttys file , execute > startx . > > ( Do not start KDE4 directly . ) > > In right xterm window of X , execute /usr/local/kde4/bin/startkde > > ( /usr/local/kde4/bin is not in path definition ) . > > Done. > > > Then , I do not know , but , even this will supply much information > about > > what is going problematic . Correction of first displayed errors and > > continuing in that way , will solve the problems one by one . > > I see several kinds of messages: > - kcheckrunning not found in PATH... this can indeed be fixed, and I'll do > it, but it's harmless; > - logs of activity... they're expected; > - the KSharedDataCache one, "ensure this partition...", is harmless (I'll > patch kdelibs to hide this as it's causing a lot of misunderstandings... > and maybe I'll just make it work on 9.x and 10.x); > - messages about Soprano/Akonadi/Virtuoso not being started... I guess > it's because they still have to start, and sure enough they disappear > after a while, and Akonadi/Nepomuk seem to work; > - X errors... well, they're due to my driver. > > Apart from this, Plasma Desktop starts successfully, Amarok can play > music... In short, my session is fully restored. Apart from KWin, but a > kwin > --replace would be needed for this. > > > If KDE4 is starting directly , during waiting after display of hard disk > > symbol , discontinuation of X with Ctrl-Alt-F1 will reveal some > messages , > > but last ones . Therefore , the above method is better than that > second > > method . > > I don't understand what "starting directly" means. Anyway, if you see > the same messages, there's nothing wrong here as well. > -- > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla > > "Starting directly" KDE4 means , inserting into ~/.xinitrc , the statement exec /usr/local/kde4/bin/startkde and then use startx after login in the console . The problem caused by the messages is at least the time used to generate them . Starting of KDE4 or its parts are taking a long time with respect to other system KDE4 start up times which is actually unacceptable or unusable . ( My ADSL line was broken at the ISP side since October , 27 . Today it has started to work . ) Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 16:39:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 128F7106566B; Mon, 31 Oct 2011 16:39:01 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC448FC13; Mon, 31 Oct 2011 16:38:59 +0000 (UTC) Received: by wyh11 with SMTP id 11so2242818wyh.13 for ; Mon, 31 Oct 2011 09:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=l+BGz+s7i0wDxsYsWrWxY9O7NSenSkd5aizUHGmVBa0=; b=sLk2GACz8oYIhnW35lCN1TgHWvQxFKOm35Ycgzccv9sExwGR30BCy15uAVyfGl7Ws0 Fi3PBBfvRrUI1kj83MxRiLSQ5Mnrkap0iUhLvRGBESlpYSAekmbXGLx2bna2b2YY9DD9 vKl3ffmDHz/bQMZQADenufW/Wdj2IySxPb02w= Received: by 10.216.138.223 with SMTP id a73mr3333821wej.62.1320079139163; Mon, 31 Oct 2011 09:38:59 -0700 (PDT) Received: from woodstock.peanuts (host9-68-dynamic.10-188-r.retail.telecomitalia.it. [188.10.68.9]) by mx.google.com with ESMTPS id gg13sm33419414wbb.8.2011.10.31.09.38.57 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 09:38:58 -0700 (PDT) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: Mehmet Erol Sanliturk Date: Mon, 31 Oct 2011 17:38:56 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC1; KDE/4.7.2; amd64; ; ) References: <201110281055.20822.avilla@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1364380.VW2sdqV1Uf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201110311738.57131.avilla@freebsd.org> Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:39:01 -0000 --nextPart1364380.VW2sdqV1Uf Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Monday 31 October 2011 17:05:06 Mehmet Erol Sanliturk wrote: > The problem caused by the messages is at least the time used to=20 generate > them . Some of these have been removed in the latest kdelibs4 port. > Starting of KDE4 or its parts are taking a long time with respect to=20 other > system KDE4 start up times which is actually unacceptable or=20 unusable . Unfortunately, unless you paste a log of your errors, I cannot go any=20 further with this investigation. =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla The Pig, if I am not mistaken, Gives us ham and pork and Bacon. Let others think his heart is big, I think it stupid of the Pig. -- Ogden Nash --nextPart1364380.VW2sdqV1Uf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk6uzyEACgkQ3xiC6kQ1Cou+fgP+KMVFGaB6HY0J40q2CLrYgk2p 3D9AXP1TNMb7Xn48228VAx7615XFGYcI2QYdKPdWJVNrXkQ+vJHDVCPvNia+Y1N/ kjwSMhnT8claYL2MdzSx9+thA1/MO1Rlmee7J0aKC3vlfCxKu49IJK0kvu4Tt0yL TIwRTHgS+NZlzUElDKs= =Lix3 -----END PGP SIGNATURE----- --nextPart1364380.VW2sdqV1Uf-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 20:10:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 102D11065674; Mon, 31 Oct 2011 20:10:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 700598FC12; Mon, 31 Oct 2011 20:10:18 +0000 (UTC) Received: by faar19 with SMTP id r19so8417043faa.13 for ; Mon, 31 Oct 2011 13:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=vxcFKLjoZvxph4J+RwapjBEIpTuVlaiOHm8Kq/NL7dg=; b=NaacfmOZjBzusl1ZCqq4xSodUs/7/4svyRLS00fUqVBq95G8eJkwprpa0cbc5T7BX9 jNuQq3wi8S7tR/UIsxCyNHn+KCgrZ22cyU2xuZzFQ0IEvnooFcv7RS7CPhkgvfdg+lg7 WbIfh1O4Q0q8QG7ZgD12OCF+tAtIZxVjFOCsM= Received: by 10.223.61.138 with SMTP id t10mr31505566fah.20.1320091817314; Mon, 31 Oct 2011 13:10:17 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o16sm39868369fag.21.2011.10.31.13.10.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 13:10:16 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EAF00A6.5060903@FreeBSD.org> Date: Mon, 31 Oct 2011 22:10:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:10:19 -0000 Hi. Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So I would like to present my results and request for testing and feedback. The main changes: - Improved locking and destruction process to fix crashes in many cases. - Improved "automatic" configuration method to make it safe by reading metadata back from all specified paths after writing to one. - Added provider size check to reduce chance of conflict with other GEOM classes. - Added "manual" configuration method without using on-disk metadata. - Added "add" and "remove" commands to manage paths manually. - Failed paths no longer dropped from GEOM, but only marked as FAIL and excluded from I/O operations. - Automatically restore failed paths when all others paths are marked as failed, for example, because of device-caused (not transport) errors. - Added "fail" and "restore" commands to manually control FAIL flag. - GEOM is now destroyed on last provider disconnection. IMHO it is right to do if device was completely removed. - Added optional Active/Active mode support. Unlike Active/Passive mode, load evenly distributed between all working paths. If supported by device, it allows to significantly improve performance, utilizing bandwidth of all paths. It is controlled by -A option during creation. Disabled by default now. - Improved `status` and `list` commands output. Latest patch can be found here: http://people.freebsd.org/~mav/gmultipath4.patch Feedbacks are welcome! Sponsored by: iXsystems, Inc. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 20:34:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D146E1065670 for ; Mon, 31 Oct 2011 20:34:47 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88B258FC16 for ; Mon, 31 Oct 2011 20:34:47 +0000 (UTC) Received: by vcbfk26 with SMTP id fk26so1988205vcb.13 for ; Mon, 31 Oct 2011 13:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wpQKXp6m8rFQ0sBAuNSgjz7Cc+Z/DnWxHoAjSbSKdcY=; b=K3GbthP7ExfMycMplNJAVP/7P0kfmcgNOPLJFmrfeDZ8O+9cbhTErdFm+51Avg9fdB iouRypazEg//BHe8osdxT7H3TbDC49BioRpkrGbU8AqzaflNBsWaURZRiviKlmrVb4XJ wt1XyuzNuVfaMz34UzW6TV0dcAblb0ufn7EBA= MIME-Version: 1.0 Received: by 10.220.150.142 with SMTP id y14mr2500635vcv.269.1320093286672; Mon, 31 Oct 2011 13:34:46 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.101.161 with HTTP; Mon, 31 Oct 2011 13:34:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Oct 2011 21:34:46 +0100 X-Google-Sender-Auth: WcLbHTizVhFa1kYgxUKL6Hfnqe4 Message-ID: From: "K. Macy" To: Penta Upa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:34:47 -0000 Someone was seeing the same issue with the vmtools kmod. The only thing that might make sense is that the page lock array is defined as being a different size in your kmod as in the kernel itself so the lock corresponding to the page you're locking differs between the two files. Cheers On Fri, Oct 21, 2011 at 5:25 PM, Penta Upa wrote: > Hi, > > I'm facing a kernel panic at vm_page_wire(). Page is locked with > vm_page_lock() yet i get the following panic > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page:1845 > > Code sequence is as below > vm_page_lock(pp); > vm_page_lock_assert(pp, MA_OWNED); /* No panic here */ > vm_page_wire(pp); /* Panic here for the same assertion as above, strange = */ > vm_page_unlock(pp); > > Kernel on the system is unchanged after install. The only thing which > occurred out the way was that the first time install failed for checksum > mismatch for src.txz. Also there were some SCSI errors/warnings with the = CD > drive during install. So the next time, i only installed the base and > kernel and later unpacked src.txz under /usr/src . Could this lead to any > issues ? > > Attached is a test module (vmtest) and the makefile used. Uname output fr= om > the system is > > FreeBSD scache 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 21:31:28 UTC > 2011 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =A0amd64 > > Is there anything i'm doing wrong here ? Kindly help. > > Regards, > Penta > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 21:17:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F6D1065670; Mon, 31 Oct 2011 21:17:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D0C5A8FC13; Mon, 31 Oct 2011 21:17:28 +0000 (UTC) Received: by vcbfk26 with SMTP id fk26so2038104vcb.13 for ; Mon, 31 Oct 2011 14:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=DFJH9F6hvdq7hmPsXuxrJ/Qq9OgGWj80scMhLZh7Oeg=; b=BemKo8DnHBIlK1y+CcHdcJ2Vsz5Bg/nUD53zgBK8TT0ANTdrD4VzTpWpCAox3nYF4D xyp7CBbkAwcLEzF82m0xTRqQqnXSd7AZiuc7+Piw1uk3Icihi7lz/DN4pSglrLuea0Vg u3qoLR45C3vVdeS+XCvPcewSoaUViVVwn3pDI= MIME-Version: 1.0 Received: by 10.220.240.132 with SMTP id la4mr2476523vcb.244.1320095848227; Mon, 31 Oct 2011 14:17:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.164.101 with HTTP; Mon, 31 Oct 2011 14:17:28 -0700 (PDT) Date: Mon, 31 Oct 2011 14:17:28 -0700 X-Google-Sender-Auth: csjTxmdsUOIwHQtpA9s4bawIZ5c Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:17:29 -0000 Hi all, I'd like to merge the if_ath_tx code into -HEAD so it gets some wider testing. This includes a couple of net80211 changes but it overwhelmingly is if_ath driver changes. The code is a bit messy and it's still a work in progress but I'd rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate situation of having to keep merging between the if_ath_tx branch and -HEAD. Please let me know if you have any feelings/comments about this. I'll look to start doing this over the next few days. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 21:53:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BA21F106566C; Mon, 31 Oct 2011 21:53:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D435114EE8E; Mon, 31 Oct 2011 21:52:50 +0000 (UTC) Message-ID: <4EAF18B2.9040909@FreeBSD.org> Date: Mon, 31 Oct 2011 14:52:50 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adrian Chadd References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:53:03 -0000 On 10/31/2011 14:17, Adrian Chadd wrote: > Hi all, > > I'd like to merge the if_ath_tx code into -HEAD so it gets some wider > testing. This includes a couple of net80211 changes but it > overwhelmingly is if_ath driver changes. > > The code is a bit messy and it's still a work in progress but I'd > rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate > situation of having to keep merging between the if_ath_tx branch and > -HEAD. Is this work that is planned to be migrated to 9.0-RELEASE? If not, shouldn't it wait till after the release? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 21:54:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB5521065672; Mon, 31 Oct 2011 21:54:47 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 35C698FC16; Mon, 31 Oct 2011 21:54:46 +0000 (UTC) Received: by faar19 with SMTP id r19so8525625faa.13 for ; Mon, 31 Oct 2011 14:54:46 -0700 (PDT) Received: by 10.223.7.14 with SMTP id b14mr32831189fab.10.1320096465791; Mon, 31 Oct 2011 14:27:45 -0700 (PDT) Received: from rnote.ddteam.net (215-134-133-95.pool.ukrtel.net. [95.133.134.215]) by mx.google.com with ESMTPS id i3sm2015045faf.0.2011.10.31.14.27.42 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 14:27:43 -0700 (PDT) Date: Mon, 31 Oct 2011 23:27:40 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20111031232740.70161b82.ray@ddteam.net> In-Reply-To: References: X-Mailer: Sylpheed 3.1.0 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:54:47 -0000 On Mon, 31 Oct 2011 14:17:28 -0700 Adrian Chadd wrote: > Hi all, > > I'd like to merge the if_ath_tx code into -HEAD so it gets some wider > testing. This includes a couple of net80211 changes but it > overwhelmingly is if_ath driver changes. > > The code is a bit messy and it's still a work in progress but I'd > rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate > situation of having to keep merging between the if_ath_tx branch and > -HEAD. > > Please let me know if you have any feelings/comments about this. I'll > look to start doing this over the next few days. > > Thanks, > Hi, I think it will make driver update process faster and easier, so +1 > > > Adrian > _______________________________________________ > 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" -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 23:43:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDEF106564A for ; Mon, 31 Oct 2011 23:43:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AE3798FC0C for ; Mon, 31 Oct 2011 23:43:04 +0000 (UTC) Received: by wwp14 with SMTP id 14so1445878wwp.31 for ; Mon, 31 Oct 2011 16:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w5SRXRbXpZY4RgvyhKLVwsUhgLA2JqvbDqciSfmM2hE=; b=paUy7jE9g7cR7XGyGrbTwRwy8iQqixEKZkZfu/CCIigTfRsAfdQ6Wkjauc78jRgfEf QDdCv2VBlf4hLlXkm1uRfFXH4O+o0TauSzlETkAzRxj8dgVNQXWhuxRRfmvIkinS+wWc 9AEBDyhPwY8SSDm+fJTbbqWEPrxXBJtD+wLz8= MIME-Version: 1.0 Received: by 10.216.134.93 with SMTP id r71mr5168855wei.59.1320104583486; Mon, 31 Oct 2011 16:43:03 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Mon, 31 Oct 2011 16:43:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Nov 2011 00:43:03 +0100 X-Google-Sender-Auth: Pqa4TeibKRX5JJSKYPkBRfS-Hxo Message-ID: From: Attilio Rao To: mdf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Ryan Stone , mlaier@freebsd.org Subject: Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:43:05 -0000 2011/10/28 : > On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone wrote: >> I'm seeing issues on a unicore systems running a derivative of FreeBSD >> 8.2-RELEASE if something calls mem_range_attr_set. =C2=A0It turns out th= at >> the root cause is a bug in smp_rendezvous_cpus. =C2=A0The first part of >> smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note >> that smp_started is never set to 1 on a unicore system): >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!smp_started) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (setup_func != =3D NULL) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0setup_func(arg); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (action_func != =3D NULL) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0action_func(arg); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (teardown_func= !=3D NULL) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0teardown_func(arg); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> >> The problem is that this runs with interrupts enabled, outside of a >> critical section. =C2=A0My system runs with device_polling enabled with = hz >> set to 2500, so its quite easy to wedge the system by having a thread >> run mem_range_attr_set. =C2=A0That has to do a smp_rendezvous, and if a >> timer interrupt happens to go off half-way through the action_func and >> preempt this thread, the system ends up deadlocked(although once it's >> wedged, typing at the serial console stands a good chance of unwedging >> the system. =C2=A0Go figure). I'm not entirely sure why this exactly breaks though (do you see that happening with a random rendezvous callback or it is always the same?), because that just becames a simple function calling on cpu0, even if I think that there is still a bug as smp_rendezvous callbacks may expect to have interrupts and preemption disabled and the short-circuit breaks that assumption. >> I know that smp_rendezvous was reworked substantially on HEAD, but by >> inspection it looks like the bug is still present, as the >> short-circuit behaviour is still there. >> >> I am not entirely sure of the best way to fix this. =C2=A0Is it as simpl= e >> as doing a spinlock_enter before setup_func and a spinlock_exit after >> teardown_func? =C2=A0It seems to boot fine, but I'm not at all confident >> that I understand the nuances of smp_rendezvous to be sure that there >> aren't side effects that I don't know about. > > Looks like Max didn't have time to upstream this fix: > > =C2=A0struct mtx smp_ipi_mtx; > +MTX_SYSINIT(smp_ipi_mtx, &smp_ipi_mtx, "smp rendezvous", MTX_SPIN); > > ... > > =C2=A0static void > =C2=A0mp_start(void *dummy) > =C2=A0{ > > - =C2=A0 =C2=A0 =C2=A0 mtx_init(&smp_ipi_mtx, "smp rendezvous", NULL, MTX= _SPIN); > > ... > > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!smp_started) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mtx_lock_spin(&smp_ipi= _mtx); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (setup_func != =3D NULL) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0setup_func(arg); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (action_func != =3D NULL) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0action_func(arg); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (teardown_func = !=3D NULL) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0teardown_func(arg); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mtx_unlock_spin(&smp_i= pi_mtx); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return; > =C2=A0 =C2=A0 =C2=A0 =C2=A0} I don't think that we strictly need the lock here, my preferred solution would be (only test-compiled): Index: sys/kern/subr_smp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/subr_smp.c (revision 226972) +++ sys/kern/subr_smp.c (working copy) @@ -415,13 +415,16 @@ smp_rendezvous_cpus(cpuset_t map, { int curcpumap, i, ncpus =3D 0; + /* Look comments in the !SMP case. */ if (!smp_started) { + spinlock_enter(); if (setup_func !=3D NULL) setup_func(arg); if (action_func !=3D NULL) action_func(arg); if (teardown_func !=3D NULL) teardown_func(arg); + spinlock_exit(); return; } @@ -666,12 +669,18 @@ smp_rendezvous_cpus(cpuset_t map, void (*teardown_func)(void *), void *arg) { + /* + * In the !SMP case we just need to ensure the same initial conditi= ons + * as the SMP case. + */ + spinlock_enter(); if (setup_func !=3D NULL) setup_func(arg); if (action_func !=3D NULL) action_func(arg); if (teardown_func !=3D NULL) teardown_func(arg); + spinlock_exit(); } void @@ -681,12 +690,15 @@ smp_rendezvous(void (*setup_func)(void *), void *arg) { + /* Look comments in the smp_rendezvous_cpus() case. */ + spinlock_enter(); if (setup_func !=3D NULL) setup_func(arg); if (action_func !=3D NULL) action_func(arg); if (teardown_func !=3D NULL) teardown_func(arg); + spinlock_exit(); } /* Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 00:22:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33EA9106566B; Tue, 1 Nov 2011 00:22:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B5BBD8FC17; Tue, 1 Nov 2011 00:22:34 +0000 (UTC) Received: by vcbfk26 with SMTP id fk26so2188270vcb.13 for ; Mon, 31 Oct 2011 17:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EcB+zylS/SCTK7eXqRWw/oGbTUtRTQlsB64MV3cpRbI=; b=wJUzzvp8gcIJoCPnXB3WK/gL/fNyWGbH69bWcKH2g3AZyRCUW9GrqxlDAHLvg/8ZpZ Y3wIUxgxWkeuf3Ray0ee7lpigjjp0bpX1PhNOhlrHyNlcOR+vhe7V9MmDe6XeLMtGBtK 7n6jAVceJ88O3u+QqJ74mKTzx5H54bl9FYYMs= MIME-Version: 1.0 Received: by 10.52.100.70 with SMTP id ew6mr6081659vdb.49.1320106953729; Mon, 31 Oct 2011 17:22:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.164.101 with HTTP; Mon, 31 Oct 2011 17:22:33 -0700 (PDT) In-Reply-To: <4EAF18B2.9040909@FreeBSD.org> References: <4EAF18B2.9040909@FreeBSD.org> Date: Mon, 31 Oct 2011 17:22:33 -0700 X-Google-Sender-Auth: qzERnkLlPvwX5f7qAjmA_Ol_YM8 Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:22:35 -0000 On 31 October 2011 14:52, Doug Barton wrote: >> The code is a bit messy and it's still a work in progress but I'd >> rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate >> situation of having to keep merging between the if_ath_tx branch and >> -HEAD. > > Is this work that is planned to be migrated to 9.0-RELEASE? If not, > shouldn't it wait till after the release? Well, it depends on how long 9.0-RELEASE is going to take. If it's going to take days, then sure I can wait. But if it's going to take weeks, I'll likely _have_ the rest of the if_ath_tx missing pieces done and ready for merge into 9.0. In any case, I do want to merge the ath 11n stuff into -9, so even if it's not done by 9.0, it'll be done shortly after. Adrian From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 01:35:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60FD21065718 for ; Tue, 1 Nov 2011 01:35:12 +0000 (UTC) (envelope-from loox@e-shell.net) Received: from mail.serpronet.com (mail.serpronet.com [64.214.84.187]) by mx1.freebsd.org (Postfix) with ESMTP id 44FB08FC0C for ; Tue, 1 Nov 2011 01:35:07 +0000 (UTC) Received: by titan.serpronet.com (Postfix, from userid 506) id DB3BBC4C3B; Mon, 31 Oct 2011 18:35:37 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on titan.serpronet.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from twinmoon.e-shell.net (unknown [10.1.10.180]) by titan.serpronet.com (Postfix) with ESMTP id 325E0C4C30 for ; Mon, 31 Oct 2011 18:35:35 -0600 (CST) Received: from moonlight.e-shell.tk (unknown [189.247.245.165]) by twinmoon.e-shell.net (Postfix) with ESMTPSA id 99D4D17025 for ; Mon, 31 Oct 2011 18:36:55 -0600 (CST) From: Axel Gonzalez To: freebsd-current@freebsd.org Date: Mon, 31 Oct 2011 18:35:18 -0600 Message-ID: <1562351.Ln9lEKl2rv@moonlight.e-shell.tk> User-Agent: KMail/4.7.1 (FreeBSD/9.0-RC1; KDE/4.7.2; i386; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Strange warning with clang and 9RC1 (ntohs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 01:35:12 -0000 I'm getting an strange warning whem compiling with clang (from base) on RC1. This warning doesn't appear with 8.X and clang from ports. The warning is strange because ntohs is not int: uint16_t ntohs(uint16_t netshort); Any insight would be appreciated, thanks in advance! A **** % gcc -Wall -o ntohs ntohs.c % clang -Wall -o ntohs ntohs.c ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the argument has type 'int' [-Wformat] printf("%hu\n", ntohs(x)); ~~^ ~~~~~~~~ %d 1 warning generated. #include #include int main() { uint16_t x = htons(80); printf("%hu\n", (uint16_t)ntohs(x)); printf("%hu\n", ntohs(x)); return (0); } -- Mon Oct 31 18:02:13 2011 GMT ** **** ***** ****** ****** ***** **** ** 5. From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 03:15:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D2C2B106564A; Tue, 1 Nov 2011 03:15:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C58DE14D9C9; Tue, 1 Nov 2011 03:15:14 +0000 (UTC) Message-ID: <4EAF6442.5020901@FreeBSD.org> Date: Mon, 31 Oct 2011 20:15:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <4EAF18B2.9040909@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 03:15:25 -0000 On 10/31/2011 17:22, Adrian Chadd wrote: > On 31 October 2011 14:52, Doug Barton wrote: > >>> The code is a bit messy and it's still a work in progress but I'd >>> rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate >>> situation of having to keep merging between the if_ath_tx branch and >>> -HEAD. >> >> Is this work that is planned to be migrated to 9.0-RELEASE? If not, >> shouldn't it wait till after the release? > > Well, it depends on how long 9.0-RELEASE is going to take. If it's > going to take days, then sure I can wait. But if it's going to take > weeks, I'll likely _have_ the rest of the if_ath_tx missing pieces > done and ready for merge into 9.0. > > In any case, I do want to merge the ath 11n stuff into -9, so even if > it's not done by 9.0, it'll be done shortly after. Given that RC1 is already out, you should probably check with re@ first. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 03:58:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95876106566B for ; Tue, 1 Nov 2011 03:58:01 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFB78FC17 for ; Tue, 1 Nov 2011 03:58:00 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 6EC317711; Tue, 1 Nov 2011 04:42:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=selector1; bh=CGuO3uobQVaXkpqLi46slu4fnVM=; b=M qxEJxZtnQPUui6fYWWX45t4uLm9KZYPGQcl6uD4oKd0D5uX6d4zXyRkr6NgXbNvE rpsG/wpdRbxC/+gAZQbY657YKdm+amlGWSGyCbKdJN8wJFhvSswXLQoGVvkejGUf kHuizETFSmYC5D7STu7//mDkwJ3XqEijCnaf4aAxOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=selector1; b=dnRdQpHaK6yFeljtu0T1U46UAkk xEFJrsf/Y59YfM1w/5RrDgwDlQZ1CyWBsM2QcXQUfyN/MyJVH1VkSiAvoxx2xGhR j0OQ5nwtzI5bV1AoaVWFCdqMaI9TNPpt/l4L+zCReu1WLu8dZKVA9TYHFXBtCmHQ 1u79ohcV3chBKKhs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=selector1; t=1320118955; bh=79SNKGBmqTfdv0oWWVt9DyW E8W+UKc5XGxjuCrQJp4o=; b=WONndy5+IaRlV17uCjNuYWlZ4mYMfY1fkRs0YsJ FZVazHoxhpg1KznjnaKNcdULOcxlFHCTFBfPAHkscn4Q8yB9QM0tV68eSYFZ6MMv t7HyjHFuzfwQ+qE+B7UAZK2IM+fdJEbXNZNQyItvjRk2jnrKjhVDBpVeQNbbG6HL kM7k= Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ro83RX-+tSAR; Tue, 1 Nov 2011 04:42:35 +0100 (CET) Received: from [192.168.166.168] (unknown [210.188.173.246]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 5AA97770A; Tue, 1 Nov 2011 04:42:34 +0100 (CET) Message-ID: <4EAF6A99.5020609@darkbsd.org> Date: Tue, 01 Nov 2011 12:42:17 +0900 From: Stephane LAPIE User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Motin References: <4EAF00A6.5060903@FreeBSD.org> In-Reply-To: <4EAF00A6.5060903@FreeBSD.org> X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB3C5D17B9A52540D296E9FEC" Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 03:58:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB3C5D17B9A52540D296E9FEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, First of all, many thanks. I am going to test your patch on 9.0-RC1, and try to backport it to 8.2 (which is the main version I am currently using at work, in the environment where I have a critical need for FC multipath redundancy...) Again, thanks for your efforts. I hope to be giving feedback soon. Cheers, On 11/01/2011 05:10 AM, Alexander Motin wrote: > Hi. >=20 > Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So= > I would like to present my results and request for testing and feedback= =2E >=20 > The main changes: > - Improved locking and destruction process to fix crashes in many case= s. > - Improved "automatic" configuration method to make it safe by reading= > metadata back from all specified paths after writing to one. > - Added provider size check to reduce chance of conflict with other > GEOM classes. > - Added "manual" configuration method without using on-disk metadata. > - Added "add" and "remove" commands to manage paths manually. > - Failed paths no longer dropped from GEOM, but only marked as FAIL an= d > excluded from I/O operations. > - Automatically restore failed paths when all others paths are marked > as failed, for example, because of device-caused (not transport) errors= =2E > - Added "fail" and "restore" commands to manually control FAIL flag. > - GEOM is now destroyed on last provider disconnection. IMHO it is > right to do if device was completely removed. > - Added optional Active/Active mode support. Unlike Active/Passive > mode, load evenly distributed between all working paths. If supported b= y > device, it allows to significantly improve performance, utilizing > bandwidth of all paths. It is controlled by -A option during creation. > Disabled by default now. > - Improved `status` and `list` commands output. >=20 > Latest patch can be found here: > http://people.freebsd.org/~mav/gmultipath4.patch >=20 > Feedbacks are welcome! >=20 > Sponsored by: iXsystems, Inc. >=20 --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigB3C5D17B9A52540D296E9FEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6vaqMACgkQ24Ql8u6TF2OwKwCgod1huQlPNHd8P2VV0jvgXY8O jUAAn18c9LnMA8IRP3VBcNOaPOXVhXQX =UdJZ -----END PGP SIGNATURE----- --------------enigB3C5D17B9A52540D296E9FEC-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 06:56:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD8AC1065670 for ; Tue, 1 Nov 2011 06:56:58 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 049458FC15 for ; Tue, 1 Nov 2011 06:56:57 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id E33397F3836; Tue, 1 Nov 2011 07:56:51 +0100 (CET) Date: Tue, 1 Nov 2011 07:56:51 +0100 From: Roman Divacky To: Axel Gonzalez Message-ID: <20111101065651.GA27751@freebsd.org> References: <1562351.Ln9lEKl2rv@moonlight.e-shell.tk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1562351.Ln9lEKl2rv@moonlight.e-shell.tk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Strange warning with clang and 9RC1 (ntohs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 06:56:58 -0000 It doesnt warn here. Can you check with "clang -E" what the ntohs() is being expanded to and what the real prototype is? On Mon, Oct 31, 2011 at 06:35:18PM -0600, Axel Gonzalez wrote: > > I'm getting an strange warning whem compiling with clang (from base) on RC1. > > This warning doesn't appear with 8.X and clang from ports. > > The warning is strange because ntohs is not int: > > uint16_t > ntohs(uint16_t netshort); > > > Any insight would be appreciated, thanks in advance! > > A > > **** > > % gcc -Wall -o ntohs ntohs.c > % clang -Wall -o ntohs ntohs.c > ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the > argument has type > 'int' [-Wformat] > printf("%hu\n", ntohs(x)); > ~~^ ~~~~~~~~ > %d > 1 warning generated. > > > #include > #include > > int main() > { > uint16_t x = htons(80); > printf("%hu\n", (uint16_t)ntohs(x)); > printf("%hu\n", ntohs(x)); > return (0); > } > > > -- > Mon Oct 31 18:02:13 2011 GMT > > ** > **** > ***** > ****** > ****** > ***** > **** > ** 5. > > _______________________________________________ > 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 Nov 1 07:10:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 791BA1065680 for ; Tue, 1 Nov 2011 07:10:54 +0000 (UTC) (envelope-from loox@e-shell.net) Received: from mail.serpronet.com (mail.serpronet.com [64.214.84.187]) by mx1.freebsd.org (Postfix) with ESMTP id ED5098FC0C for ; Tue, 1 Nov 2011 07:10:47 +0000 (UTC) Received: by mail.serpronet.com (Postfix, from userid 506) id 264B0C4C37; Tue, 1 Nov 2011 01:10:46 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on titan.serpronet.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from twinmoon.e-shell.net (unknown [10.1.10.180]) by mail.serpronet.com (Postfix) with ESMTP id 760EDC4C30; Tue, 1 Nov 2011 01:10:42 -0600 (CST) Received: from moonlight.e-shell.tk (unknown [189.247.245.165]) by twinmoon.e-shell.net (Postfix) with ESMTPSA id 09FA317021; Tue, 1 Nov 2011 01:12:01 -0600 (CST) From: Axel Gonzalez To: Roman Divacky Date: Tue, 01 Nov 2011 01:10:36 -0600 Message-ID: <2104381.NqWTZMXtng@moonlight.e-shell.tk> User-Agent: KMail/4.7.1 (FreeBSD/9.0-RC1; KDE/4.7.2; i386; ; ) In-Reply-To: <20111101065651.GA27751@freebsd.org> References: <1562351.Ln9lEKl2rv@moonlight.e-shell.tk> <20111101065651.GA27751@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-current@freebsd.org Subject: Re: Strange warning with clang and 9RC1 (ntohs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 07:10:54 -0000 Here is the output (short version): ... (snip) static __inline __uint16_t __bswap16_var(__uint16_t _x) { return ((__uint16_t)((_x) << 8 | (_x) >> 8)); } ... (snip) int main() { uint16_t x = (__builtin_constant_p(80) ? (__uint16_t)(((__uint16_t)(80)) << 8 | ((__uint16_t)(80)) >> 8) : __bswap16_var(80)); printf("%hu\n", (uint16_t)(__builtin_constant_p(x) ? (__uint16_t) (((__uint16_t)(x)) << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))); printf("%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))); return (0); } % clang -E ntohs.c > ntohs_.c % clang -Wall -o ntohs ntohs_.c In file included from ntohs.c:1: ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the argument has type 'int' [-Wformat] ...%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))... ~~^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %d 1 warning generated. And I missed it the first mail: FreeBSD moonlight 9.0-RC1 FreeBSD 9.0-RC1 #0: Fri Oct 28 22:53:45 CDT 2011 toor@moonlight:/usr/obj/usr/src/sys/LXCORE9 i386 Thanks! A On Tuesday 01 November 2011 07:56:51 Roman Divacky wrote: > It doesnt warn here. Can you check with "clang -E" what the ntohs() > is being expanded to and what the real prototype is? > -- Tue Nov 1 01:01:15 2011 GMT ** ***** ****** ******* ******* ****** ***** ** 6. From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 07:43:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A57106564A; Tue, 1 Nov 2011 07:43:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2298FC17; Tue, 1 Nov 2011 07:43:00 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 14C49B8027; Tue, 1 Nov 2011 11:23:20 +0400 (SAMT) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 0A84CB801F; Tue, 1 Nov 2011 11:23:20 +0400 (SAMT) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 00337B8433; Tue, 1 Nov 2011 11:23:19 +0400 (SAMT) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id B84DCB8422; Tue, 1 Nov 2011 11:23:19 +0400 (SAMT) Message-ID: <4EAF9E67.4040605@FreeBSD.org> Date: Tue, 01 Nov 2011 11:23:19 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: sascha@trimind.de References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> <20111028094828.GA1781@trimind.de> In-Reply-To: <20111028094828.GA1781@trimind.de> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: Garrett Cooper , antik@bsd.ee, Martin Wilke , current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 07:43:00 -0000 On 28.10.2011 13:48, Sascha Klauder wrote: > I've got bitten by this as well when trying a source up- > grade of a freshly installed 8.2-RELEASE system that had > gmirror configured after installation according to the > procedure in the Handbook. > > The 9.0-RC1 kernel drops to the mountroot prompt when > booting with > > GEOM_MIRROR: Device mirror/gm0 launched (2/2). > GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > 490350670 > GEOM_PART: integrity check failed (mirror/gm0, MBR) This is the main problem. Your MBR' slice is bigger than actual space you have. The only way to fix this - recreate slice. You can break your mirror, recreate the slice (NOTE: you must preserve one sector for the gmirror's meta-data), then copy your data to the newly created slice, then reboot from the new slice and recreate mirror. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 08:20:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D81106566B for ; Tue, 1 Nov 2011 08:20:51 +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 933548FC14 for ; Tue, 1 Nov 2011 08:20:50 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 197362028; Tue, 01 Nov 2011 09:20:48 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 1 Nov 2011 09:17:49 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111010917.49742.hselasky@c2i.net> Cc: Matt Mullins Subject: Re: ng_ubt fatal trap 12 on RELENG_9 and CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 08:20:51 -0000 On Monday 31 October 2011 09:22:40 Matt Mullins wrote: > It's late, so I'm going to come back to this later. Any ideas on > where I should go from here? Try to figure out where the NULL valued structure is initialised. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 08:23:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ECB1106566C for ; Tue, 1 Nov 2011 08:23:37 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6AB8FC08 for ; Tue, 1 Nov 2011 08:23:36 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 8CCC4700005F for ; Tue, 1 Nov 2011 09:23:35 +0100 (CET) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 6CD28700005B for ; Tue, 1 Nov 2011 09:23:35 +0100 (CET) X-SFR-UUID: 20111101082335445.6CD28700005B@msfrf2301.sfr.fr Message-ID: <4EAFAC87.3090208@davenulle.org> Date: Tue, 01 Nov 2011 09:23:35 +0100 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EAC033E.6010201@davenulle.org> <20111030072842.GA23153@freebsd.org> <20111030075224.GA25155@freebsd.org> <4EAD8189.40607@davenulle.org> <4EADCE5E.8080703@FreeBSD.org> In-Reply-To: <4EADCE5E.8080703@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 08:23:37 -0000 Le 30.10.2011 23:23, Dimitry Andric a écrit : > I pulled Roman's fixes into head in r226951. This will be merged to > stable/9 later, but if you want to try it out in the meantime, please > use the attached diff. Thanks a lot. FYI, `make buildworld & kernel` were successful after I applied the patch. -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 12:40:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F820106564A; Tue, 1 Nov 2011 12:40:39 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E44A98FC0A; Tue, 1 Nov 2011 12:40:38 +0000 (UTC) Received: from localhost (host-89-230-170-58.ostrowmaz.mm.pl [89.230.170.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 169C7A58; Tue, 1 Nov 2011 13:40:37 +0100 (CET) Date: Tue, 1 Nov 2011 13:39:48 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20111101123944.GC4567@garage.freebsd.pl> References: <4EAF00A6.5060903@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <4EAF00A6.5060903@FreeBSD.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:40:39 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 31, 2011 at 10:10:14PM +0200, Alexander Motin wrote: > Hi. >=20 > Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So > I would like to present my results and request for testing and feedback. >=20 > The main changes: > - Improved locking and destruction process to fix crashes in many cases. > - Improved "automatic" configuration method to make it safe by reading > metadata back from all specified paths after writing to one. > - Added provider size check to reduce chance of conflict with other > GEOM classes. > - Added "manual" configuration method without using on-disk metadata. > - Added "add" and "remove" commands to manage paths manually. > - Failed paths no longer dropped from GEOM, but only marked as FAIL and > excluded from I/O operations. > - Automatically restore failed paths when all others paths are marked > as failed, for example, because of device-caused (not transport) errors. > - Added "fail" and "restore" commands to manually control FAIL flag. > - GEOM is now destroyed on last provider disconnection. IMHO it is > right to do if device was completely removed. > - Added optional Active/Active mode support. Unlike Active/Passive > mode, load evenly distributed between all working paths. If supported by > device, it allows to significantly improve performance, utilizing > bandwidth of all paths. It is controlled by -A option during creation. > Disabled by default now. > - Improved `status` and `list` commands output. >=20 > Latest patch can be found here: > http://people.freebsd.org/~mav/gmultipath4.patch >=20 > Feedbacks are welcome! >=20 > Sponsored by: iXsystems, Inc. There are two possible issues that comes to my mind, not sure if you address them. 1. When configuration is based on on-disk metadata, GEOM spoil/taste is not fully helpful - if you have two paths: da0 and da1 and I write to da0, gmultipath won't be informed by GEOM that da1 changed as well. One solution is to basically keep all paths open exclusively all the time, even if gmultipath provider is not open or emulate spoil/taste for other paths if any path was modified. 2. In active/active mode do you do anything to handle possible reordering? Ie. if you have overlapping writes and send both of them using different paths, you cannot be sure that order will be preserved. Most of the time that's not a problem, as file systems rarely if at all send overlapping writes to device, but this is weak assumption. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6v6JAACgkQForvXbEpPzQwSwCg7HoRkKI+8LdccEgUbpMFmcfM eQYAn3RWr/nGiRparSXh2LCHLgtu/fv7 =B1cU -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 13:05:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE3C1065672; Tue, 1 Nov 2011 13:05:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE2F8FC12; Tue, 1 Nov 2011 13:05:42 +0000 (UTC) Received: by eyd10 with SMTP id 10so8038033eyd.13 for ; Tue, 01 Nov 2011 06:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sRSKsN1WmuXYXd7bywp5jE1hRJRacNhtvinHkTUFlCw=; b=Thpbx2UQwdSs3Eo2LJnX7vuMiVmJR+9+Viev42J9iUi+zVrsoixH16cjhkmn5N6Gzv 8sM6cECvQKZXk3D10G7w+HoVq41NEiNTJo80E2vVRxVbv2Be8KWy1+XzQxP060uLIT0O ar4pe1NUCPuCTRvEmB8Pgpk9eqxXcU//9WmxQ= Received: by 10.14.8.136 with SMTP id 8mr4284eer.87.1320152741192; Tue, 01 Nov 2011 06:05:41 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t6sm29926393eeb.11.2011.11.01.06.05.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 06:05:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EAFEEA1.80500@FreeBSD.org> Date: Tue, 01 Nov 2011 15:05:37 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4EAF00A6.5060903@FreeBSD.org> <20111101123944.GC4567@garage.freebsd.pl> In-Reply-To: <20111101123944.GC4567@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:05:43 -0000 On 11/01/11 14:39, Pawel Jakub Dawidek wrote: > On Mon, Oct 31, 2011 at 10:10:14PM +0200, Alexander Motin wrote: >> Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So >> I would like to present my results and request for testing and feedback. >> >> The main changes: >> - Improved locking and destruction process to fix crashes in many cases. >> - Improved "automatic" configuration method to make it safe by reading >> metadata back from all specified paths after writing to one. >> - Added provider size check to reduce chance of conflict with other >> GEOM classes. >> - Added "manual" configuration method without using on-disk metadata. >> - Added "add" and "remove" commands to manage paths manually. >> - Failed paths no longer dropped from GEOM, but only marked as FAIL and >> excluded from I/O operations. >> - Automatically restore failed paths when all others paths are marked >> as failed, for example, because of device-caused (not transport) errors. >> - Added "fail" and "restore" commands to manually control FAIL flag. >> - GEOM is now destroyed on last provider disconnection. IMHO it is >> right to do if device was completely removed. >> - Added optional Active/Active mode support. Unlike Active/Passive >> mode, load evenly distributed between all working paths. If supported by >> device, it allows to significantly improve performance, utilizing >> bandwidth of all paths. It is controlled by -A option during creation. >> Disabled by default now. >> - Improved `status` and `list` commands output. >> >> Latest patch can be found here: >> http://people.freebsd.org/~mav/gmultipath4.patch >> >> Feedbacks are welcome! >> >> Sponsored by: iXsystems, Inc. > > There are two possible issues that comes to my mind, not sure if you > address them. > > 1. When configuration is based on on-disk metadata, GEOM spoil/taste is > not fully helpful - if you have two paths: da0 and da1 and I write > to da0, gmultipath won't be informed by GEOM that da1 changed as well. > One solution is to basically keep all paths open exclusively all the > time, even if gmultipath provider is not open or emulate spoil/taste > for other paths if any path was modified. Now I am opening all underlying providers exclusively on attach to spoil other consumers. It is configurable via sysctl. > 2. In active/active mode do you do anything to handle possible > reordering? Ie. if you have overlapping writes and send both of them > using different paths, you cannot be sure that order will be > preserved. Most of the time that's not a problem, as file systems > rarely if at all send overlapping writes to device, but this is weak > assumption. No, I don't. I have doubt that it is sane to send even dependent I/O simultaneously without waiting for completion, not speaking about overlapping. When most of present devices support command queuing and so officially justify reordering simultaneous commands in custom way, I am not sure why above layers should be more strict, especially in cases when it is problematic. If somebody have ideas why and how to implement it, I am ready to discuss. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 15:09:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58F25106564A for ; Tue, 1 Nov 2011 15:09:59 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 169DE8FC14 for ; Tue, 1 Nov 2011 15:09:58 +0000 (UTC) Received: by iabz21 with SMTP id z21so3409082iab.13 for ; Tue, 01 Nov 2011 08:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CxtsWBBGNihUkREhvaHj7ZE2kD7zGVPdLJF5P19d0EE=; b=bGrBMTkckOdM+gFIyO/UiwnUwVHUYoFkbZOjeph+iB+jFVZ7YAd6aOuYCsOZYSzJug 4pjE1h0WSrdzv0bkL5zRH+L3u9TPgFsD97H780GSmFlY1XUHmObyWKPxQzVKbvoTJ9PJ 8dr5dwHpOUTd4nWd/uIQM4gyxLmKaYEj8W0DU= MIME-Version: 1.0 Received: by 10.42.151.4 with SMTP id c4mr29098185icw.39.1320160197896; Tue, 01 Nov 2011 08:09:57 -0700 (PDT) Received: by 10.50.15.234 with HTTP; Tue, 1 Nov 2011 08:09:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Nov 2011 20:39:57 +0530 Message-ID: From: Penta Upa To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:09:59 -0000 Yes that seems to be the problem. It will is for out of tree modules. http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . I have to verify if moving the module to /usr/src/ tree fixes the problem. Thanks, Penta On Tue, Nov 1, 2011 at 2:04 AM, K. Macy wrote: > Someone was seeing the same issue with the vmtools kmod. The only > thing that might make sense is that the page lock array is defined as > being a different size in your kmod as in the kernel itself so the > lock corresponding to the page you're locking differs between the two > files. > > Cheers > > On Fri, Oct 21, 2011 at 5:25 PM, Penta Upa wrote: > > Hi, > > > > I'm facing a kernel panic at vm_page_wire(). Page is locked with > > vm_page_lock() yet i get the following panic > > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page:1845 > > > > Code sequence is as below > > vm_page_lock(pp); > > vm_page_lock_assert(pp, MA_OWNED); /* No panic here */ > > vm_page_wire(pp); /* Panic here for the same assertion as above, strange > */ > > vm_page_unlock(pp); > > > > Kernel on the system is unchanged after install. The only thing which > > occurred out the way was that the first time install failed for checksum > > mismatch for src.txz. Also there were some SCSI errors/warnings with the > CD > > drive during install. So the next time, i only installed the base and > > kernel and later unpacked src.txz under /usr/src . Could this lead to any > > issues ? > > > > Attached is a test module (vmtest) and the makefile used. Uname output > from > > the system is > > > > FreeBSD scache 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 21:31:28 UTC > > 2011 > > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > Is there anything i'm doing wrong here ? Kindly help. > > > > Regards, > > Penta > > > > _______________________________________________ > > 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 Nov 1 15:28:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74007106566B; Tue, 1 Nov 2011 15:28:13 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 740F68FC1A; Tue, 1 Nov 2011 15:28:11 +0000 (UTC) Received: by wyg36 with SMTP id 36so593377wyg.13 for ; Tue, 01 Nov 2011 08:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ByjM4/R2GSbwGemkN4G6IGtKFX91jrtYO19ZWMU8wUs=; b=ZTY6N3bXVtly4YCwP01C/EQM3xXDRxsZCDjDAhGmAldNbLf+/fM3KFtLj+V0sXerhj A+rRfSMaXkAl9OdC/wipQhJSEGGHFBGwt23x2TREdg51TEGiJU8oBlxhtcjjMgiNp2ty t76KyIAjVipvxDgw8D/am0d17Lfzs1OHoX64U= MIME-Version: 1.0 Received: by 10.227.202.143 with SMTP id fe15mr24898171wbb.25.1320161291064; Tue, 01 Nov 2011 08:28:11 -0700 (PDT) Received: by 10.180.8.34 with HTTP; Tue, 1 Nov 2011 08:28:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Nov 2011 11:28:11 -0400 Message-ID: From: Ryan Stone To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: mdf@freebsd.org, FreeBSD Current , mlaier@freebsd.org Subject: Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:28:13 -0000 On Mon, Oct 31, 2011 at 7:43 PM, Attilio Rao wrote: > I'm not entirely sure why this exactly breaks though (do you see that > happening with a random rendezvous callback or it is always the > same?), because that just becames a simple function calling on cpu0, > even if I think that there is still a bug as smp_rendezvous callbacks > may expect to have interrupts and preemption disabled and the > short-circuit breaks that assumption. I have only observed the problem with i686_mrstoreone(smp_rendezvous is called from i686_mrstore). I notice that i686_mrstoreone does scary things like disabling the cache and global TLB entries. My experience was that everything got very slow when i686_mrstoreone was preempted, so it easily could be the case that the system because so slow with the cache disabled that it became livelocked. > I don't think that we strictly need the lock here, my preferred > solution would be (only test-compiled): I tried the same thing for the SMP case, and it fixed my problem. From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 17:15:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6629B1065676; Tue, 1 Nov 2011 17:15:00 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id E0FC68FC18; Tue, 1 Nov 2011 17:14:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id pA1HExLG004262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2011 10:14:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id pA1HExj3004261; Tue, 1 Nov 2011 10:14:59 -0700 (PDT) (envelope-from jmg) Date: Tue, 1 Nov 2011 10:14:59 -0700 From: John-Mark Gurney To: Alexander Motin Message-ID: <20111101171459.GY25601@funkthat.com> Mail-Followup-To: Alexander Motin , Pawel Jakub Dawidek , freebsd-current@freebsd.org, freebsd-geom@freebsd.org References: <4EAF00A6.5060903@FreeBSD.org> <20111101123944.GC4567@garage.freebsd.pl> <4EAFEEA1.80500@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAFEEA1.80500@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 01 Nov 2011 10:14:59 -0700 (PDT) Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:15:00 -0000 Alexander Motin wrote this message on Tue, Nov 01, 2011 at 15:05 +0200: > > 2. In active/active mode do you do anything to handle possible > > reordering? Ie. if you have overlapping writes and send both of them > > using different paths, you cannot be sure that order will be > > preserved. Most of the time that's not a problem, as file systems > > rarely if at all send overlapping writes to device, but this is weak > > assumption. > > No, I don't. I have doubt that it is sane to send even dependent I/O > simultaneously without waiting for completion, not speaking about > overlapping. When most of present devices support command queuing and so > officially justify reordering simultaneous commands in custom way, I am > not sure why above layers should be more strict, especially in cases > when it is problematic. If somebody have ideas why and how to implement > it, I am ready to discuss. I know that phk and others have an idea what the contract for writes like this, but I just checked geom(4) and the IO section doesn't describe it.. I believe that you should not submit overlapping writes unless it's preceded or is an _ORDERED write, and that reads can be satisifed w/ stale data if it is submitted after a write of the same location, but it's not in geom(4). Hmm... turns out BIO_ORDERED isn't even documented in geom(4)... I'm willing to put some of this in the man page if someone comes up w/ a good list of points. Are the ones I listed above enough? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 19:24:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FA41065672; Tue, 1 Nov 2011 19:24:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 653A58FC12; Tue, 1 Nov 2011 19:24:09 +0000 (UTC) Received: by faar19 with SMTP id r19so9829386faa.13 for ; Tue, 01 Nov 2011 12:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=PTv7EGUW8kqZr06FiGa9RubFwC17uF1URowYwXehEwg=; b=RnJ+947bZ3/901dZvzVozHn7+UytrK6YVy6oh/IVtkGUvxclx2NVHhkjKU7YgcZ1aV af+GKFgqLi6R5QAyauTHw6QNTk7XPNZmxMacQfQAF8V6r+/GpIPIZe1ZZgYtQPsUGBvf kK9gsxzYXF1rXmiZze22fpV5WoO/hu6xMXelA= Received: by 10.223.76.27 with SMTP id a27mr2650763fak.12.1320175448305; Tue, 01 Nov 2011 12:24:08 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o16sm395395fag.21.2011.11.01.12.24.06 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 12:24:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EB05566.3060700@FreeBSD.org> Date: Tue, 01 Nov 2011 22:24:06 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dennis_K=F6gel?= References: <4EAF00A6.5060903@FreeBSD.org> <05E0E64F-5EC4-425A-81E4-B6C35320608B@neveragain.de> In-Reply-To: <05E0E64F-5EC4-425A-81E4-B6C35320608B@neveragain.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:24:10 -0000 On 01.11.2011 19:50, Dennis Kögel wrote: > Not sure if replying on-list or off-list makes more sense... Replying on-list could share experience to other users. > Anyway, some first impressions, on stable/9: > > The lab environment here is a EMC VNX / Clariion SAN, which has two Storage Processors, connected to different switches, connected to two isp(4)s on the test machine. So at any time, the machine sees four paths, but only two are available (depending on which SP owns the LUN). > > 580# camcontrol devlist > at scbus0 target 0 lun 0 (da0,pass0) > at scbus0 target 1 lun 0 (da1,pass1) > at scbus1 target 0 lun 0 (da2,pass2) > at scbus1 target 1 lun 0 (da3,pass3) > at scbus2 target 0 lun 0 (da4,pass4) > at scbus2 target 1 lun 0 (da5,pass5) > at scbus4 target 0 lun 0 (cd0,pass6) > > I miss the ability to "add" disks to automatic mode multipaths, but I (just now) realized this only makes sense when gmultipath has some kind of path checking facility (like periodically trying to read sector 0 of each configured device, this is was Linux' devicemapper-multipathd does). In automatic mode other paths supposed to be detected via metadata reading. If in your case some paths are not readable, automatic mode can't work as expected. By the way, could you describe how your configuration supposed to work, like when other paths will start working? Only when second storage processor itself detect that first one is dead or it suppose to be controlled somehow? If booted with verbose messages, what SCSI errors do you see on console/logs when trying to access second storage processor? Speaking about user-level daemons, it should be possible to do the same: write rc.d script to create multipath device in manual mode on boot and hook small script into devd.conf that will check models, serial numbers, or whatever else of newly detected devices and manually add them. At least if you are not booting from that device. Another possible way I see is to make geom_multipath to analyze device models and serial numbers on kernel level and attach devices based on it without using metadata. > First I did a test with active/active and manual mode (gmultipath create -A TESTBSD da{0,1,2,3}). > > This worked fine, and immediately kicked da{0,2} (which are not available) after writing something. Predictable. Errors caused not working paths to be marked as failed. If all working paths fail, these will be retried. > It's quite unexpected that act/act is apparently based on the writer's process id or CPU affinity (guessing) -- I needed multiple parallel dd(1) jobs to get gmultipath to use more than one path, but then it worked fine. (This also means that a dysfunct path isn't recognized before some I/O is attempted). Performance was similar to an identical Linux setup (for a very simple sequential I/O test at least). It is not an affinity, but just a dumb probe order. Now geom_multipath only balances immediate load, not average. So if you have only one request at a time, it will always use one path. If you have only one initiator, it should not be important, but if there are several, it should probably be improved. > Using automatic mode (gmultipath label -A TESTBSD da{1,3,0,2}) silently ignores da{0,2}, which are not available. "list" does not show them at all. I guess it should at least throw an error. Now "label" command only hints kernel to retaste other paths. If kernel is unable to read metadata from specified devices or there is no metadata, they just silently won't be added. I can add metadata checking in user-level. It will not guarantee success, but should at least handle basic mistakes. > Do any of the layers below gmultipath currently have information about metadata like the volume's WWN? This could be helpful in status / list output, maybe for other things, I guess... That information may be present inside CAM, but not above at the moment. Only device model and serial number exported to GEOM. > Another thought: As I guess "automatic" mode is meant to be the common case, the choice of "create" vs. "label" might be misleading. Users in a hurry will probably just look through the built-in help, see "create", and then use it. (I'm guilty as charged here, I didn't realize at first that I was using manual mode.) It is a somewhat unified among several GEOM classes that label is for automatic method and create is for manual. Thank you for your feedback! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 05:51:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA636106564A for ; Wed, 2 Nov 2011 05:51:50 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 744498FC12 for ; Wed, 2 Nov 2011 05:51:50 +0000 (UTC) Received: from [93.104.91.236] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLSgJ-0004y4-IR; Wed, 02 Nov 2011 05:44:07 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id pA24i5GB002450; Wed, 2 Nov 2011 05:44:05 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id pA24i2gx002449; Wed, 2 Nov 2011 05:44:02 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 2 Nov 2011 05:44:02 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, umq@ueo.co.jp Message-ID: <20111102044402.GA2425@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 93.104.91.236 Cc: Subject: 10.0-CUR && ports/security/libgcrypt fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 05:51:51 -0000 Hello, I've pulled out r226986 fromm SVN and port from CVS completely fresh on November 1st; ports/security/libgcrypt fails to build with: # make install ... /bin/sh /usr/local/bin/libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -Wa,--noexecstack -O2 -pipe -fno-strict-aliasing -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c -o mpih-add1-asm.lo mpih-add1-asm.S libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -Wa,--noexecstack -O2 -pipe -fno-strict-aliasing -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c mpih-add1-asm.S -fPIC -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S: Assembler messages: mpih-add1-asm.S:44: Error: alignment not a power of 2 mpih-add1-asm.S:79: Error: alignment not a power of 2 *** Error code 1 Any ideas? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 06:10:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA541065673 for ; Wed, 2 Nov 2011 06:10:22 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id B05908FC0A for ; Wed, 2 Nov 2011 06:10:21 +0000 (UTC) X-AuditID: 1209190c-b7f806d0000008d6-cf-4eb0deccc923 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 51.D5.02262.CCED0BE4; Wed, 2 Nov 2011 02:10:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id pA26AJ8O022328; Wed, 2 Nov 2011 02:10:20 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pA26AIsk002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Nov 2011 02:10:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pA26AH7l024806; Wed, 2 Nov 2011 02:10:17 -0400 (EDT) Date: Wed, 2 Nov 2011 02:10:17 -0400 (EDT) From: Benjamin Kaduk To: "K. Macy" In-Reply-To: Message-ID: References: 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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHvm3gY/g9YDAhaTXnWyW8x584HJ 4vHeLWwOzB4zPs1nCWCM4rJJSc3JLEst0rdL4MromXyWtWA/f8WrL8vZGhjX8XQxcnJICJhI tD56xghhi0lcuLeerYuRi0NIYB+jxJEP+1ggnPWMEicPv4Ny9jNJnH3+nA2kRUigXqJ9+VYw m0VAS2La2m0sIDabgIrEzDcbweIiAooSJ/6uYAexmQUMJH7e2cQKYgsLWEn8ndoIFOfg4BQI lFg5H6yVV8BeYv3RJ1BX3GKUuLF0HVivqICOxOr9U6CKBCVOznzCAjHTUuLcn+tsExgFZyFJ zUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4VCV5djC+Oah0iFGA g1GJh9dZa4OfEGtiWXFl7iFGSQ4mJVFeDWCgC/El5adUZiQWZ8QXleakFh9ilOBgVhLhLVwG lONNSaysSi3Kh0lJc7AoifMe3OHgJySQnliSmp2aWpBaBJOV4eBQkuDVAhkqWJSanlqRlplT gpBm4uAEGc4DNHz6XZDhxQWJucWZ6RD5U4yKUuK8LSAJAZBERmkeXC8slbxiFAd6RZhXFmQF DzANwXW/AhrMBDR45qX1IINLEhFSUg2MLaYxr6yPCe63q3wTwnn0U83T7TOc56hrvvHYfJDx A0vH9FmvdS7vE7i5/PDpXe/2lN2L/7jOa1fbjDc+JzYJbr/SIFfMqvfV3OdRwpWYGrEJMuqr NS2/Mf6/ydbhsPSP/JZpWzctCprqkXOm6bDxVQnjbPvopVFugX6x1bW3DmwsX9LgpOkQq8RS nJFoqMVcVJwIADVBRQAAAwAA Cc: freebsd-current@freebsd.org, avg@freebsd.org Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:10:22 -0000 On Tue, 1 Nov 2011, Penta Upa wrote: > Yes that seems to be the problem. It will is for out of tree modules. > http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . I have to verify if > moving the module to /usr/src/ tree fixes the problem. > > Thanks, > Penta > > On Tue, Nov 1, 2011 at 2:04 AM, K. Macy wrote: > >> Someone was seeing the same issue with the vmtools kmod. The only >> thing that might make sense is that the page lock array is defined as >> being a different size in your kmod as in the kernel itself so the >> lock corresponding to the page you're locking differs between the two >> files. Quoting from the PR, Andriy Gapon wrote: > A standalone module build doesn't get some important definitions from > kernel config (e.g. via opt_global.h) and can be in a serious > disagreement with the kernel. In particular, if a kernel is built with > SMP option, but a module build doesn't have SMP defined, then they will > have different definitions of PA_LOCK_COUNT and thus would work on > different actual locks when manipulating the same page. I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include opt_global.h' to be passed on the command line. Is the issue just that the opt_global.h used for the kmod could be different from the actual kernel's opt_global.h, because KERNCONF was not specified and the header is generated at module-build time? In this case, clearly the onus is on the user to pass KERNCONF at module build time. (I have gotten my laptop to panic in vm_page_free() with the page lock not owned, in OpenAFS' vop_getpages implementation, but I had previously attributed this to having an old -current snapshot on my laptop and openafs sources that were using freebsd major version for API decisions (we're not converted to __FreeBSD_version, yet). If there is a real problem here, I will need to care much more.) Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 07:19:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03E3106564A for ; Wed, 2 Nov 2011 07:19:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id AF8418FC12 for ; Wed, 2 Nov 2011 07:19:55 +0000 (UTC) Received: from [82.113.99.190] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLV71-0000MK-RG; Wed, 02 Nov 2011 08:19:53 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA27JrlO001064; Wed, 2 Nov 2011 08:19:55 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA27Jp9O001063; Wed, 2 Nov 2011 08:19:51 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Wed, 2 Nov 2011 08:19:51 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, umq@ueo.co.jp Message-ID: <20111102071950.GA1044@tiny> References: <20111102044402.GA2425@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111102044402.GA2425@tinyCurrent> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 82.113.99.190 Cc: Subject: Re: 10.0-CUR && ports/security/libgcrypt fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 07:19:56 -0000 El día Wednesday, November 02, 2011 a las 05:44:02AM +0100, Matthias Apitz escribió: > > Hello, > > I've pulled out r226986 fromm SVN and port from CVS completely fresh on > November 1st; > > ports/security/libgcrypt fails to build with: > > # make install > ... > -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c > mpih-add1-asm.S -fPIC -DPIC -o .libs/mpih-add1-asm.o > mpih-add1-asm.S: Assembler messages: > mpih-add1-asm.S:44: Error: alignment not a power of 2 > mpih-add1-asm.S:79: Error: alignment not a power of 2 > *** Error code 1 I have had a look into the Makefile and for the moment I could do a workaround with adding a ./configure hint: # diff Makefile Makefile.orig 36d35 < CONFIGURE_ARGS+= --disable-asm matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 10:32:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B40106566C; Wed, 2 Nov 2011 10:32:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 045D98FC0A; Wed, 2 Nov 2011 10:32:22 +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 MAA07975; Wed, 02 Nov 2011 12:32:19 +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 1RLY7H-000DA6-7P; Wed, 02 Nov 2011 12:32:19 +0200 Message-ID: <4EB11C32.80106@FreeBSD.org> Date: Wed, 02 Nov 2011 12:32:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Benjamin Kaduk References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "K. Macy" , Penta Upa Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:32:24 -0000 [restored cc: to the original poster] on 02/11/2011 08:10 Benjamin Kaduk said the following: > I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include > opt_global.h' to be passed on the command line. Is the issue just that the > opt_global.h used for the kmod could be different from the actual kernel's > opt_global.h, because KERNCONF was not specified and the header is generated at > module-build time? In this case, clearly the onus is on the user to pass > KERNCONF at module build time. To be precise, this is what is actually passed to a compiler: sys/conf/kmod.mk: .if defined(KERNBUILDDIR) CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h .endif where KERNBUILDDIR can be passed via environment from a kernel build: sys/conf/kern.post.mk: MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}" KERNCONF does not have any meaning in a module build. To make sure that a module build sees exactly the same kernel options as a kernel with which the module should work, one has to either build the module together with the kernel (within the kernel build; search for MODULES in make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel build directory. (Which to a certain degree implies impossibility to build a "perfect" module for a pre-built binary kernel or to provide a "perfect" universal pre-built module for any custom kernel) Of course, the real problem is that modules should not care about any (or at least some) kernel options, they should be isolated from the options via a proper KPI/KBI (perhaps DDI or "module-to-kernel interface" or whatever). A module should be able to work correctly with kernels built with different options. As Bruce Evans has pointed to me privately [I am not sure why privately], there is already an example in i386 and amd64 atomic.h, where operations are inlined for a kernel build, but presented as real (external) functions for a module build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. I think that the same treatment could/should be applied to vm_page_*lock* operations defined in sys/vm/vm_page.h. Or, if the above operations are intended to be used only in the kernel proper, then there should be some guidelines on what API should module writers use to perform certain page manipulations like e.g. wiring a page. P.S. Bruce has also pointed out some other potentially dangerous places with respect to the SMP option and modules build. Most prominent is sys/sys/mutex.h P.P.S. [and tangential] I see that many module makefiles fake up various kernel options in a fashion similar to the following: .if !defined(KERNBUILDDIR) opt_compat.h: echo "#define COMPAT_FREEBSD6 1" > ${.TARGET} opt_kbd.h: echo "#define KBD_INSTALL_CDEV 1" > ${.TARGET} .endif And handful of modules fake up opt_global.h, e.g.: opt_global.h: echo "#define ALTQ 1" > ${.TARGET} -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 12:03:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B7E1065675 for ; Wed, 2 Nov 2011 12:03:37 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id E18EF8FC23 for ; Wed, 2 Nov 2011 12:03:36 +0000 (UTC) Received: by qadz32 with SMTP id z32so114235qad.13 for ; Wed, 02 Nov 2011 05:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.27.136 with SMTP id i8mr481289qcc.171.1320235415991; Wed, 02 Nov 2011 05:03:35 -0700 (PDT) Received: by 10.229.134.84 with HTTP; Wed, 2 Nov 2011 05:03:35 -0700 (PDT) In-Reply-To: <4E644993.4090703@gmail.com> References: <4E62915E.1010405@FreeBSD.org> <4E6294E0.5010104@gmail.com> <4E6298DE.5090007@FreeBSD.org> <4E644993.4090703@gmail.com> Date: Wed, 2 Nov 2011 13:03:35 +0100 Message-ID: From: Olivier Smedts To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: Compiling BETA2 with clang fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 12:03:37 -0000 2011/9/5 Volodymyr Kostyrko : > > 0k, here you go. Just as you say - no -fPIC, no ccache, no anything. > > =3D=3D=3D> libexec/atrun (all) > clang -O2 -pipe -march=3Dnative -DATJOB_DIR=3D\"/var/at/jobs/\" > -DLFILE=3D\"/var/at/jobs/.lockfile\" =A0-DLOADAVG_MX=3D1.5 > -DATSPOOL_DIR=3D\"/var/at/spool\" =A0-DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 > -DDAEMON_GID=3D1 =A0-DDEFAULT_BATCH_QUEUE=3D\'E\' =A0-DDEFAULT_AT_QUEUE= =3D\'c\' > -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at > -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-si= gn > -c /usr/src/libexec/atrun/atrun.c > clang -O2 -pipe -march=3Dnative -DATJOB_DIR=3D\"/var/at/jobs/\" > -DLFILE=3D\"/var/at/jobs/.lockfile\" =A0-DLOADAVG_MX=3D1.5 > -DATSPOOL_DIR=3D\"/var/at/spool\" =A0-DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 > -DDAEMON_GID=3D1 =A0-DDEFAULT_BATCH_QUEUE=3D\'E\' =A0-DDEFAULT_AT_QUEUE= =3D\'c\' > -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at > -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-si= gn > -c /usr/src/libexec/atrun/gloadavg.c > clang -O2 -pipe -march=3Dnative -DATJOB_DIR=3D\"/var/at/jobs/\" > -DLFILE=3D\"/var/at/jobs/.lockfile\" =A0-DLOADAVG_MX=3D1.5 > -DATSPOOL_DIR=3D\"/var/at/spool\" =A0-DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 > -DDAEMON_GID=3D1 =A0-DDEFAULT_BATCH_QUEUE=3D\'E\' =A0-DDEFAULT_AT_QUEUE= =3D\'c\' > -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at > -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-si= gn > =A0-o atrun atrun.o gloadavg.o -lpam -lutil > clang: warning: argument unused during compilation: '-std=3Dgnu99' > /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1': > /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to > `atexit' > /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to > `_init_tls' > /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to > `atexit' > /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to > `exit' > atrun.o: In function `perr': > /usr/src/libexec/atrun/atrun.c:(.text+0x12): undefined reference to `strl= en' > /usr/src/libexec/atrun/atrun.c:(.text+0x45): undefined reference to `vwar= n' > /usr/src/libexec/atrun/atrun.c:(.text+0x6d): undefined reference to > `snprintf' > /usr/src/libexec/atrun/atrun.c:(.text+0x8a): undefined reference to > `vsyslog' > /usr/src/libexec/atrun/atrun.c:(.text+0x9c): undefined reference to `exit= ' > atrun.o: In function `perrx': > /usr/src/libexec/atrun/atrun.c:(.text+0xd3): undefined reference to `vwar= nx' > /usr/src/libexec/atrun/atrun.c:(.text+0xdf): undefined reference to `exit= ' > /usr/src/libexec/atrun/atrun.c:(.text+0xf3): undefined reference to > `vsyslog' > /usr/src/libexec/atrun/atrun.c:(.text+0xff): undefined reference to `exit= ' > atrun.o: In function `main': > /usr/src/libexec/atrun/atrun.c:(.text+0x160): undefined reference to > `geteuid' > /usr/src/libexec/atrun/atrun.c:(.text+0x174): undefined reference to > `getegid' > /usr/src/libexec/atrun/atrun.c:(.text+0x186): undefined reference to > `setegid' > /usr/src/libexec/atrun/atrun.c:(.text+0x193): undefined reference to > `seteuid' [...] > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop in /usr/src/libexec/atrun. > *** Error code 1 > > Stop in /usr/src/libexec. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. Replying to an old thread, but FYI this problem which has been bugging me since months has gone away since the lastest clang branches/release_30 import, and it has been MFC'ed to stable/9. I can now buildworld with -march=3Dcorei7 instead of -march=3Dcore2 :) (the same should apply for -march=3Dnative) Cheers --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 15:40:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9963B1065676 for ; Wed, 2 Nov 2011 15:40:08 +0000 (UTC) (envelope-from me@janh.de) Received: from mxchg03.rrz.uni-hamburg.de (mxchg03.rrz.uni-hamburg.de [134.100.38.113]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4DC8FC16 for ; Wed, 2 Nov 2011 15:40:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTP id 7AB191EE283; Wed, 2 Nov 2011 16:22:26 +0100 (CET) X-Virus-Scanned: by University of Hamburg ( RRZ / mgw02.rrz.uni-hamburg.de ) Received: from mxchg03.rrz.uni-hamburg.de ([127.0.0.1]) by localhost (mxchg03.rrz.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10324) with ESMTP id qh-4RafVSTFt; Wed, 2 Nov 2011 16:22:26 +0100 (CET) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.38.99]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTPS; Wed, 2 Nov 2011 16:22:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id 6868F90003; Wed, 2 Nov 2011 16:22:26 +0100 (CET) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dWgsYiRgoLgQ; Wed, 2 Nov 2011 16:22:26 +0100 (CET) Received: from nb981.math (g224007119.adsl.alicedsl.de [92.224.7.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 2A38490002; Wed, 2 Nov 2011 16:22:26 +0100 (CET) Message-ID: <4EB1602C.6030807@janh.de> Date: Wed, 02 Nov 2011 16:22:20 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111101 Thunderbird/7.0.1 MIME-Version: 1.0 To: current-list freebsd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Nov 2011 15:44:33 +0000 Subject: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:40:08 -0000 I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0xffffffff806e80aa stack pointer = 0x28:0xffffff810ee50bc0 frame pointer = 0x28:0xffffff810ee50bf0 code segment = base 0x0, limit 0xfffff, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 18:05:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86457106566B; Wed, 2 Nov 2011 18:05:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4418C8FC43; Wed, 2 Nov 2011 18:05:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E7F6346B0A; Wed, 2 Nov 2011 14:05:01 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5086A8A02F; Wed, 2 Nov 2011 14:05:01 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 2 Nov 2011 11:45:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111021145.02622.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Nov 2011 14:05:01 -0400 (EDT) Cc: Attilio Rao , mdf@freebsd.org, mlaier@freebsd.org, Ryan Stone Subject: Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:05:02 -0000 On Monday, October 31, 2011 7:43:03 pm Attilio Rao wrote: > 2011/10/28 : > > On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone wrote: > >> I'm seeing issues on a unicore systems running a derivative of FreeBSD > >> 8.2-RELEASE if something calls mem_range_attr_set. It turns out that > >> the root cause is a bug in smp_rendezvous_cpus. The first part of > >> smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note > >> that smp_started is never set to 1 on a unicore system): > >> > >> if (!smp_started) { > >> if (setup_func != NULL) > >> setup_func(arg); > >> if (action_func != NULL) > >> action_func(arg); > >> if (teardown_func != NULL) > >> teardown_func(arg); > >> return; > >> } > >> > >> The problem is that this runs with interrupts enabled, outside of a > >> critical section. My system runs with device_polling enabled with hz > >> set to 2500, so its quite easy to wedge the system by having a thread > >> run mem_range_attr_set. That has to do a smp_rendezvous, and if a > >> timer interrupt happens to go off half-way through the action_func and > >> preempt this thread, the system ends up deadlocked(although once it's > >> wedged, typing at the serial console stands a good chance of unwedging > >> the system. Go figure). > > I'm not entirely sure why this exactly breaks though (do you see that > happening with a random rendezvous callback or it is always the > same?), because that just becames a simple function calling on cpu0, > even if I think that there is still a bug as smp_rendezvous callbacks > may expect to have interrupts and preemption disabled and the > short-circuit breaks that assumption. > > >> I know that smp_rendezvous was reworked substantially on HEAD, but by > >> inspection it looks like the bug is still present, as the > >> short-circuit behaviour is still there. > >> > >> I am not entirely sure of the best way to fix this. Is it as simple > >> as doing a spinlock_enter before setup_func and a spinlock_exit after > >> teardown_func? It seems to boot fine, but I'm not at all confident > >> that I understand the nuances of smp_rendezvous to be sure that there > >> aren't side effects that I don't know about. > > > > Looks like Max didn't have time to upstream this fix: > > > > struct mtx smp_ipi_mtx; > > +MTX_SYSINIT(smp_ipi_mtx, &smp_ipi_mtx, "smp rendezvous", MTX_SPIN); > > > > ... > > > > static void > > mp_start(void *dummy) > > { > > > > - mtx_init(&smp_ipi_mtx, "smp rendezvous", NULL, MTX_SPIN); > > > > ... > > > > if (!smp_started) { > > + mtx_lock_spin(&smp_ipi_mtx); > > if (setup_func != NULL) > > setup_func(arg); > > if (action_func != NULL) > > action_func(arg); > > if (teardown_func != NULL) > > teardown_func(arg); > > + mtx_unlock_spin(&smp_ipi_mtx); > > return; > > } > > I don't think that we strictly need the lock here, my preferred > solution would be (only test-compiled): > Index: sys/kern/subr_smp.c > =================================================================== > --- sys/kern/subr_smp.c (revision 226972) > +++ sys/kern/subr_smp.c (working copy) > @@ -415,13 +415,16 @@ smp_rendezvous_cpus(cpuset_t map, > { > int curcpumap, i, ncpus = 0; > > + /* Look comments in the !SMP case. */ > if (!smp_started) { > + spinlock_enter(); > if (setup_func != NULL) > setup_func(arg); > if (action_func != NULL) > action_func(arg); > if (teardown_func != NULL) > teardown_func(arg); > + spinlock_exit(); > return; > } > > @@ -666,12 +669,18 @@ smp_rendezvous_cpus(cpuset_t map, > void (*teardown_func)(void *), > void *arg) > { > + /* > + * In the !SMP case we just need to ensure the same initial conditions > + * as the SMP case. > + */ > + spinlock_enter(); > if (setup_func != NULL) > setup_func(arg); > if (action_func != NULL) > action_func(arg); > if (teardown_func != NULL) > teardown_func(arg); > + spinlock_exit(); > } > > void > @@ -681,12 +690,15 @@ smp_rendezvous(void (*setup_func)(void *), > void *arg) > { > > + /* Look comments in the smp_rendezvous_cpus() case. */ > + spinlock_enter(); > if (setup_func != NULL) > setup_func(arg); > if (action_func != NULL) > action_func(arg); > if (teardown_func != NULL) > teardown_func(arg); > + spinlock_exit(); > } I think this is fine, and probably correct. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 19:36:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C197106564A for ; Wed, 2 Nov 2011 19:36:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3548FC14 for ; Wed, 2 Nov 2011 19:36:15 +0000 (UTC) Received: from [89.204.137.138] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLgbc-0001Jr-HD; Wed, 02 Nov 2011 20:36:13 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA2JaAKn001104; Wed, 2 Nov 2011 20:36:11 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA2Ja8G3001103; Wed, 2 Nov 2011 20:36:08 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Wed, 2 Nov 2011 20:36:07 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20111102193606.GA1086@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.137.138 Cc: freebsd-multimedia@freebsd.org Subject: 10.0-CUR r226986 && ports/audio/jack installs no libjack.so X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:36:15 -0000 Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; Any ideas? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 19:37:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE22F106566C; Wed, 2 Nov 2011 19:37:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6078FC1B; Wed, 2 Nov 2011 19:37:32 +0000 (UTC) Received: by faar19 with SMTP id r19so1159844faa.13 for ; Wed, 02 Nov 2011 12:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zI4YI/bG7QndiOFEvqrQgZeeknyW3LUaay8fbSSJ2A8=; b=jtcnQ8kGvTfonYmdRFbCfdErMYKL8gasU5zaoLkSvqKzP+NsTAyxKc9yQzTzCFNzB4 Xa3HbBlzI1EqRg3oGu6hrTq7kRhAVwz432oNyncOwHHWCRWPJy9nTmVcO9yVh/DHIaGZ Xg9qljrXGpNF1Dfcea+Gdh+i5MmzwstSh0lg8= Received: by 10.223.61.72 with SMTP id s8mr3994602fah.27.1320262574879; Wed, 02 Nov 2011 12:36:14 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i3sm7320419faf.0.2011.11.02.12.36.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 12:36:13 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EB19BAB.90801@FreeBSD.org> Date: Wed, 02 Nov 2011 21:36:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EAF00A6.5060903@FreeBSD.org> In-Reply-To: <4EAF00A6.5060903@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dennis Koegel , freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:37:34 -0000 On 10/31/11 22:10, Alexander Motin wrote: > Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So > I would like to present my results and request for testing and feedback. > > The main changes: > - Improved locking and destruction process to fix crashes in many cases. > - Improved "automatic" configuration method to make it safe by reading > metadata back from all specified paths after writing to one. > - Added provider size check to reduce chance of conflict with other > GEOM classes. > - Added "manual" configuration method without using on-disk metadata. > - Added "add" and "remove" commands to manage paths manually. > - Failed paths no longer dropped from GEOM, but only marked as FAIL and > excluded from I/O operations. > - Automatically restore failed paths when all others paths are marked > as failed, for example, because of device-caused (not transport) errors. > - Added "fail" and "restore" commands to manually control FAIL flag. > - GEOM is now destroyed on last provider disconnection. IMHO it is > right to do if device was completely removed. > - Added optional Active/Active mode support. Unlike Active/Passive > mode, load evenly distributed between all working paths. If supported by > device, it allows to significantly improve performance, utilizing > bandwidth of all paths. It is controlled by -A option during creation. > Disabled by default now. > - Improved `status` and `list` commands output. Here is slightly updated version: http://people.freebsd.org/~mav/gmultipath5.patch Changes from previous: - "label" command was made to check metadata on other specified devices after writing to the first one and warn if something wrong there. - "add" command was allowed for devices created using automatic method. It may be useful in cases when some paths are temporary not operational and can't even read metadata. In such case they could be added manually and marked failed until their time will come. - Load balancing in Active/Active mode slightly improved: if all paths have equal load, do round-robin between them. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 05:57:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4871065672; Thu, 3 Nov 2011 05:57:15 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh7.mail.rice.edu (mh7.mail.rice.edu [128.42.199.46]) by mx1.freebsd.org (Postfix) with ESMTP id 534738FC0C; Thu, 3 Nov 2011 05:57:15 +0000 (UTC) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 9447F291D87; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 5FEA4291DD6; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id KqLcmE+4i8xX; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh7.mail.rice.edu (Postfix) with ESMTPSA id 4F80A291DDD; Thu, 3 Nov 2011 00:40:09 -0500 (CDT) Message-ID: <4EB22938.4050803@rice.edu> Date: Thu, 03 Nov 2011 00:40:08 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andriy Gapon References: <4EB11C32.80106@FreeBSD.org> In-Reply-To: <4EB11C32.80106@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Penta Upa , freebsd-current@FreeBSD.org, Benjamin Kaduk , "K. Macy" Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:57:15 -0000 On 11/02/2011 05:32, Andriy Gapon wrote: > [restored cc: to the original poster] > > on 02/11/2011 08:10 Benjamin Kaduk said the following: >> I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include >> opt_global.h' to be passed on the command line. Is the issue just that the >> opt_global.h used for the kmod could be different from the actual kernel's >> opt_global.h, because KERNCONF was not specified and the header is generated at >> module-build time? In this case, clearly the onus is on the user to pass >> KERNCONF at module build time. > To be precise, this is what is actually passed to a compiler: > sys/conf/kmod.mk: > .if defined(KERNBUILDDIR) > CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h > .endif > > where KERNBUILDDIR can be passed via environment from a kernel build: > sys/conf/kern.post.mk: > MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}" > > KERNCONF does not have any meaning in a module build. > > To make sure that a module build sees exactly the same kernel options as a > kernel with which the module should work, one has to either build the module > together with the kernel (within the kernel build; search for MODULES in > make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel > build directory. (Which to a certain degree implies impossibility to build a > "perfect" module for a pre-built binary kernel or to provide a "perfect" > universal pre-built module for any custom kernel) > > Of course, the real problem is that modules should not care about any (or at > least some) kernel options, they should be isolated from the options via a > proper KPI/KBI (perhaps DDI or "module-to-kernel interface" or whatever). A > module should be able to work correctly with kernels built with different options. > > As Bruce Evans has pointed to me privately [I am not sure why privately], there > is already an example in i386 and amd64 atomic.h, where operations are inlined > for a kernel build, but presented as real (external) functions for a module > build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. > > I think that the same treatment could/should be applied to vm_page_*lock* > operations defined in sys/vm/vm_page.h. *snip* Yes, it should be. There are without question legitimate reasons for a module to acquire a page lock. Alan From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 06:10:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D837106566C; Thu, 3 Nov 2011 06:10:53 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7D28FC12; Thu, 3 Nov 2011 06:10:53 +0000 (UTC) Received: from [93.104.66.14] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLqVn-0007sK-Sp; Thu, 03 Nov 2011 07:10:52 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id pA36AoGa002396; Thu, 3 Nov 2011 07:10:50 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id pA36AnlB002395; Thu, 3 Nov 2011 07:10:49 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 3 Nov 2011 07:10:49 +0100 From: Matthias Apitz Message-ID: <20111103061049.GA2273@tinyCurrent> References: <20111102193606.GA1086@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111102193606.GA1086@tiny> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 93.104.66.14 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 06:10:53 -0000 El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: > > Hello, > > I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November > 1st; > > The ports/audio/jack seems installing fine, but the shared lib > libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it > is mentioned in the list -L of the package; later ports/audio/arts and > ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 07:32:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8027A1065676; Thu, 3 Nov 2011 07:32:51 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D95F8FC14; Thu, 3 Nov 2011 07:32:51 +0000 (UTC) Received: by iabz21 with SMTP id z21so1722322iab.13 for ; Thu, 03 Nov 2011 00:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TJw0E5fPxI0OA7TDYFfqwG0M84Y5jGqXYdWF9vdxOIY=; b=FMDH6nhAXxAbwm+rtU6oS/u+UxMqM9+gDfKID6Wl6Gpt8lQ+Wq9HLplXv55WNHMOPk rlrci6iutjh0YMXC76f1iqjkStcZ9teyVqlgiBNe9pm7Y5d3zTwqnw9gmVHeRs6m6dmh DPIvWSYqpjfLBvTtJ+q3cqo13iekGk+M6ueJ4= MIME-Version: 1.0 Received: by 10.50.36.168 with SMTP id r8mr2265527igj.49.1320305570800; Thu, 03 Nov 2011 00:32:50 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Thu, 3 Nov 2011 00:32:50 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Thu, 3 Nov 2011 00:32:50 -0700 (PDT) In-Reply-To: <20111103061049.GA2273@tinyCurrent> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> Date: Thu, 3 Nov 2011 07:32:50 +0000 Message-ID: From: Chris Rees To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 07:32:51 -0000 On 3 Nov 2011 06:11, "Matthias Apitz" wrote: > > El d=EDa Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribi=F3: > > > > > Hello, > > > > I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on Novembe= r > > 1st; > > > > The ports/audio/jack seems installing fine, but the shared lib > > libjack.so is missing below ports/audio/jack/work and /usr/local/lib; i= t > > is mentioned in the list -L of the package; later ports/audio/arts and > > ports/x11/kde3 are missing the shared lib; > > It turns out that the problem is more general! A lot of ./configure > scripts are detecting in 10-CUR that they can't or should not build > shared libs; the problem is that the OS is detected now as > > host_os: freebsd10.0 > > and the ./configure scripts have tests like this: > > ports/audio/jack/work/jack-audio-connection-kit-0.121.3: > > case $host_os in > ... > freebsd1*) > dynamic_linker=3Dno > ;; > ... > > And now? I'm cluesless now how we could solve this :-( > Searching the archives of both these lists would help you ;) Chris From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 07:44:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61948106566B; Thu, 3 Nov 2011 07:44:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC4258FC08; Thu, 3 Nov 2011 07:44:43 +0000 (UTC) Received: by vcbfk26 with SMTP id fk26so1334222vcb.13 for ; Thu, 03 Nov 2011 00:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GvebTT4Sdk8PLlWSmIuzf1xnk36sWeTEDjwbimMlRMM=; b=sR/rgoe2bdLQkgUYz2apOLduAzQZyRmgpALdk8C+5zF135AujIAmXwc5189B07qDtb gbTip+u/HqxQ6oETLSo6y2UgTtXnsuoBwZ2rCKAELCSsXw4MfoiMeQllcnUk/MPTZUHs sdLeOBPWigxVfJbK3yyN5Sr82nVvm2KPT7kss= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr8419102vdb.72.1320306282996; Thu, 03 Nov 2011 00:44:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 3 Nov 2011 00:44:42 -0700 (PDT) In-Reply-To: <4EAF6442.5020901@FreeBSD.org> References: <4EAF18B2.9040909@FreeBSD.org> <4EAF6442.5020901@FreeBSD.org> Date: Thu, 3 Nov 2011 00:44:42 -0700 X-Google-Sender-Auth: 3d5HYZycYYpM_bPDuNW8kzDVIYw Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 07:44:44 -0000 On 31 October 2011 20:15, Doug Barton wrote: >> In any case, I do want to merge the ath 11n stuff into -9, so even if >> it's not done by 9.0, it'll be done shortly after. > > Given that RC1 is already out, you should probably check with re@ first. I'll poke them tomorrow, but since others have merged in driver changes and other stuff into -HEAD, I wouldn't be the first person to merge in bigger things. Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 07:52:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44EDA1065672; Thu, 3 Nov 2011 07:52:16 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 205788FC0A; Thu, 3 Nov 2011 07:52:14 +0000 (UTC) Received: by wwp14 with SMTP id 14so1462029wwp.31 for ; Thu, 03 Nov 2011 00:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OHJR3BcuomvnRK+r5HEsNoHVMxpDa/GXA+163v2y/gk=; b=kNbLdNBw48gCsi1MWDdursu39HS+t6GjB9Xx3AVy5vOawrNeYQca2YgfKjXp7ojows Du6QdRJL/9KfYWVmIk6V9O4iFaAVQJQEB9vVPDefM5T99cJQyhZDL+BaI6pAApK4qMq+ vGWIdNP/nzZVet1tsziBueh43gGZiCK3Fre8U= MIME-Version: 1.0 Received: by 10.216.221.163 with SMTP id r35mr2556316wep.21.1320306733941; Thu, 03 Nov 2011 00:52:13 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.18.9 with HTTP; Thu, 3 Nov 2011 00:52:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Nov 2011 13:22:13 +0530 X-Google-Sender-Auth: NzKG5apbfYG4k92-vgoE-euh8pM Message-ID: From: "Jayachandran C." To: Rafal Jaworowski , Nathan Whitehorn , freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org, FreeBSD Current Content-Type: multipart/mixed; boundary=0016e65a0986df04a304b0cfdd47 Cc: Marcel Moolenaar Subject: [RFC] Fix OF_finddevice return code for FDT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 07:52:16 -0000 --0016e65a0986df04a304b0cfdd47 Content-Type: text/plain; charset=ISO-8859-1 [I had posted this to freebsd-ppc@ and freebsd-arm@, did not see any comments, posting to freebsd-current@ to see if there is any interest or comments] While reviewing the previous FDT patch, nwhitehorn@ noted that the return code of OF_finddevice was not correct in case of FDT. According to the 1275 standard, we should return a phandle value of -1 in case of error, but the ofw_fdt_finddevice implementation now returns 0. The attached patches fixes this in the FDT code, and makes changes in the callers to check the return code correctly. Since most of the callers are in ARM, any testing on ARM would be really appreciated. Thanks, JC. --0016e65a0986df04a304b0cfdd47 Content-Type: application/octet-stream; name="fdt-finddevice-fix.patch" Content-Disposition: attachment; filename="fdt-finddevice-fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvap00 Y29tbWl0IDgxMDc2ZThhYTRjYmYyM2M4YWQ4OTBlYzg1MTVmNzkxN2JhZTJhYjgKQXV0aG9yOiBK YXlhY2hhbmRyYW4gQyA8amF5YWNoYW5kcmFuY0BuZXRsb2dpY21pY3JvLmNvbT4KRGF0ZTogICBU dWUgT2N0IDE4IDAwOjU3OjQ2IDIwMTEgKzA1MzAKCiAgICBPRl9maW5kZGV2aWNlIHNob3VsZCBy ZXR1cm4gLTEgb24gZXJyb3IKICAgIAogICAgRml4IHRoZSBpbXBsZW1lbnRhdGlvbiwgYW5kIGZp eHVwIHRoZSBjYWxsZXJzLgoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvZmR0L2ZkdF9jb21tb24uYyBi L3N5cy9kZXYvZmR0L2ZkdF9jb21tb24uYwppbmRleCBkMjU3MTViLi44NzAyZGYyIDEwMDY0NAot LS0gYS9zeXMvZGV2L2ZkdC9mZHRfY29tbW9uLmMKKysrIGIvc3lzL2Rldi9mZHQvZmR0X2NvbW1v bi5jCkBAIC03NCwxMyArNzQsMTMgQEAgZmR0X2ltbXJfYWRkcih2bV9vZmZzZXRfdCBpbW1yX3Zh KQogCS8qCiAJICogVHJ5IHRvIGFjY2VzcyB0aGUgU09DIG5vZGUgZGlyZWN0bHkgaS5lLiB0aHJv dWdoIC9hbGlhc2VzLy4KIAkgKi8KLQlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCJzb2MiKSkg IT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCJzb2MiKSkgIT0gLTEpCiAJCWlmIChm ZHRfaXNfY29tcGF0aWJsZV9zdHJpY3Qobm9kZSwgInNpbXBsZS1idXMiKSkKIAkJCWdvdG8gbW92 ZW9uOwogCS8qCiAJICogRmluZCB0aGUgbm9kZSB0aGUgbG9uZyB3YXkuCiAJICovCi0JaWYgKChu b2RlID0gT0ZfZmluZGRldmljZSgiLyIpKSA9PSAwKQorCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZp Y2UoIi8iKSkgPT0gLTEpCiAJCXJldHVybiAoRU5YSU8pOwogCiAJaWYgKChub2RlID0gZmR0X2Zp bmRfY29tcGF0aWJsZShub2RlLCAic2ltcGxlLWJ1cyIsIDEpKSA9PSAwKQpAQCAtNTc2LDcgKzU3 Niw3IEBAIGZkdF9nZXRfbWVtX3JlZ2lvbnMoc3RydWN0IG1lbV9yZWdpb24gKm1yLCBpbnQgKm1y Y250LCB1aW50MzJfdCAqbWVtc2l6ZSkKIAogCW1heF9zaXplID0gc2l6ZW9mKHJlZyk7CiAJbWVt b3J5ID0gT0ZfZmluZGRldmljZSgiL21lbW9yeSIpOwotCWlmIChtZW1vcnkgPD0gMCkgeworCWlm IChtZW1vcnkgPT0gLTEpIHsKIAkJcnYgPSBFTlhJTzsKIAkJZ290byBvdXQ7CiAJfQpkaWZmIC0t Z2l0IGEvc3lzL2Rldi9mZHQvZmR0YnVzLmMgYi9zeXMvZGV2L2ZkdC9mZHRidXMuYwppbmRleCBl MjgwOGQxLi5kNTI5NmE5IDEwMDY0NAotLS0gYS9zeXMvZGV2L2ZkdC9mZHRidXMuYworKysgYi9z eXMvZGV2L2ZkdC9mZHRidXMuYwpAQCAtMTc3LDcgKzE3Nyw3IEBAIGZkdGJ1c19hdHRhY2goZGV2 aWNlX3QgZGV2KQogCXVfbG9uZyBzdGFydCwgZW5kOwogCWludCBlcnJvcjsKIAotCWlmICgocm9v dCA9IE9GX3BlZXIoMCkpID09IDApCisJaWYgKChyb290ID0gT0ZfZmluZGRldmljZSgiLyIpKSA9 PSAtMSkKIAkJcGFuaWMoImZkdGJ1c19hdHRhY2g6IG5vIHJvb3Qgbm9kZS4iKTsKIAogCXNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9vZncvb2Z3X2ZkdC5j IGIvc3lzL2Rldi9vZncvb2Z3X2ZkdC5jCmluZGV4IDgwNmYxN2MuLjdiM2IwZTkgMTAwNjQ0Ci0t LSBhL3N5cy9kZXYvb2Z3L29md19mZHQuYworKysgYi9zeXMvZGV2L29mdy9vZndfZmR0LmMKQEAg LTM5Miw2ICszOTIsOCBAQCBvZndfZmR0X2ZpbmRkZXZpY2Uob2Z3X3Qgb2Z3LCBjb25zdCBjaGFy ICpkZXZpY2UpCiAJaW50IG9mZnNldDsKIAogCW9mZnNldCA9IGZkdF9wYXRoX29mZnNldChmZHRw LCBkZXZpY2UpOworCWlmIChvZmZzZXQgPCAwKQorCQlyZXR1cm4gKC0xKTsKIAlyZXR1cm4gKGZk dF9vZmZzZXRfcGhhbmRsZShvZmZzZXQpKTsKIH0KIApAQCAtNDIwLDcgKzQyMiw3IEBAIG9md19m ZHRfZml4dXAob2Z3X3Qgb2Z3KQogCXNzaXplX3QgbGVuOwogCWludCBpOwogCi0JaWYgKChyb290 ID0gb2Z3X2ZkdF9maW5kZGV2aWNlKG9mdywgIi8iKSkgPT0gMCkKKwlpZiAoKHJvb3QgPSBvZndf ZmR0X2ZpbmRkZXZpY2Uob2Z3LCAiLyIpKSA9PSAtMSkKIAkJcmV0dXJuIChFTk9ERVYpOwogCiAJ aWYgKChsZW4gPSBvZndfZmR0X2dldHByb3BsZW4ob2Z3LCByb290LCAibW9kZWwiKSkgPD0gMCkK ZGlmZiAtLWdpdCBhL3N5cy9kZXYvb2Z3L29wZW5maXJtLmMgYi9zeXMvZGV2L29mdy9vcGVuZmly bS5jCmluZGV4IGE4Y2I4ZjcuLmY1NDNkY2UgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvb2Z3L29wZW5m aXJtLmMKKysrIGIvc3lzL2Rldi9vZncvb3BlbmZpcm0uYwpAQCAtMTMxLDcgKzEzMSw3IEBAIE9G X2luaXQodm9pZCAqY29va2llKQogCiAJcnYgPSBPRldfSU5JVChvZndfb2JqLCBjb29raWUpOwog Ci0JaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2VuIikpID4gMCkKKwlpZiAoKGNo b3NlbiA9IE9GX2ZpbmRkZXZpY2UoIi9jaG9zZW4iKSkgIT0gLTEpCiAJCWlmIChPRl9nZXRwcm9w KGNob3NlbiwgInN0ZG91dCIsICZzdGRvdXQsIHNpemVvZihzdGRvdXQpKSA9PSAtMSkKIAkJCXN0 ZG91dCA9IC0xOwogCmRpZmYgLS1naXQgYS9zeXMvZGV2L3VhcnQvdWFydF9idXNfZmR0LmMgYi9z eXMvZGV2L3VhcnQvdWFydF9idXNfZmR0LmMKaW5kZXggNDIwOTg2Ni4uOGJiNjJlYSAxMDA2NDQK LS0tIGEvc3lzL2Rldi91YXJ0L3VhcnRfYnVzX2ZkdC5jCisrKyBiL3N5cy9kZXYvdWFydC91YXJ0 X2J1c19mZHQuYwpAQCAtMTU1LDExICsxNTUsMTEgQEAgdWFydF9jcHVfZ2V0ZGV2KGludCBkZXZ0 eXBlLCBzdHJ1Y3QgdWFydF9kZXZpbmZvICpkaSkKIAkvKgogCSAqIFJldHJpZXZlIC9jaG9zZW4v c3Rke2luLG91dH0uCiAJICovCi0JaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2Vu IikpID09IDApCisJaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2VuIikpID09IC0x KQogCQlyZXR1cm4gKEVOWElPKTsKIAlpZiAoT0ZfZ2V0cHJvcChjaG9zZW4sICJzdGRpbiIsIGJ1 Ziwgc2l6ZW9mKGJ1ZikpIDw9IDApCiAJCXJldHVybiAoRU5YSU8pOwotCWlmICgobm9kZSA9IE9G X2ZpbmRkZXZpY2UoYnVmKSkgPT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKGJ1Zikp ID09IC0xKQogCQlyZXR1cm4gKEVOWElPKTsKIAlpZiAoT0ZfZ2V0cHJvcChjaG9zZW4sICJzdGRv dXQiLCBidWYsIHNpemVvZihidWYpKSA8PSAwKQogCQlyZXR1cm4gKEVOWElPKTsK --0016e65a0986df04a304b0cfdd47 Content-Type: application/octet-stream; name="arm-fixes.patch" Content-Disposition: attachment; filename="arm-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvc7g1 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vbXYvY29tbW9uLmMgYi9zeXMvYXJtL212L2NvbW1vbi5jCmlu ZGV4IDQ1OTZhMjAuLmM3YmVhZTggMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vbXYvY29tbW9uLmMKKysr IGIvc3lzL2FybS9tdi9jb21tb24uYwpAQCAtMTY5Myw3ICsxNjkzLDcgQEAgZmR0X2dldF9yYW5n ZXMoY29uc3QgY2hhciAqbm9kZW5hbWUsIHZvaWQgKmJ1ZiwgaW50IHNpemUsIGludCAqdHVwbGVz LAogCWludCBsZW4sIHR1cGxlX3NpemUsIHR1cGxlc19jb3VudDsKIAogCW5vZGUgPSBPRl9maW5k ZGV2aWNlKG5vZGVuYW1lKTsKLQlpZiAobm9kZSA8PSAwKQorCWlmIChub2RlID09IC0xKQogCQly ZXR1cm4gKEVJTlZBTCk7CiAKIAlpZiAoKGZkdF9hZGRyc2l6ZV9jZWxscyhub2RlLCAmYWRkcl9j ZWxscywgJnNpemVfY2VsbHMpKSAhPSAwKQpAQCAtMTc2MiwxMSArMTc2MiwxMSBAQCB3aW5fY3B1 X2Zyb21fZHQodm9pZCkKIAkvKgogCSAqIFJldHJpZXZlIENFU0EgU1JBTSBkYXRhLgogCSAqLwot CWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoInNyYW0iKSkgIT0gMCkKKwlpZiAoKG5vZGUgPSBP Rl9maW5kZGV2aWNlKCJzcmFtIikpICE9IC0xKQogCQlpZiAoZmR0X2lzX2NvbXBhdGlibGUobm9k ZSwgIm1ydmwsY2VzYS1zcmFtIikpCiAJCQlnb3RvIG1vdmVvbjsKIAotCWlmICgobm9kZSA9IE9G X2ZpbmRkZXZpY2UoIi8iKSkgPT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCIvIikp ICE9IC0xKQogCQlyZXR1cm4gKEVOWElPKTsKIAogCWlmICgobm9kZSA9IGZkdF9maW5kX2NvbXBh dGlibGUobm9kZSwgIm1ydmwsY2VzYS1zcmFtIiwgMCkpID09IDApCkBAIC0xNzk2LDcgKzE3OTYs NyBAQCBmZHRfd2luX3NldHVwKHZvaWQpCiAJaW50IGVyciwgaTsKIAogCW5vZGUgPSBPRl9maW5k ZGV2aWNlKCIvIik7Ci0JaWYgKG5vZGUgPT0gMCkKKwlpZiAobm9kZSA9PSAtMSkKIAkJcGFuaWMo ImZkdF93aW5fc2V0dXA6IG5vIHJvb3Qgbm9kZSIpOwogCiAJbm9kZSA9IGZkdF9maW5kX2NvbXBh dGlibGUobm9kZSwgInNpbXBsZS1idXMiLCAxKTsKZGlmZiAtLWdpdCBhL3N5cy9hcm0vbXYvbXZf bWFjaGRlcC5jIGIvc3lzL2FybS9tdi9tdl9tYWNoZGVwLmMKaW5kZXggZmQxNzY5Mi4uODgzOTc0 MCAxMDA2NDQKLS0tIGEvc3lzL2FybS9tdi9tdl9tYWNoZGVwLmMKKysrIGIvc3lzL2FybS9tdi9t dl9tYWNoZGVwLmMKQEAgLTYxNywxMyArNjE3LDEzIEBAIHBsYXRmb3JtX21wcF9pbml0KHZvaWQp CiAJLyoKIAkgKiBUcnkgdG8gYWNjZXNzIHRoZSBNUFAgbm9kZSBkaXJlY3RseSBpLmUuIHRocm91 Z2ggL2FsaWFzZXMvbXBwLgogCSAqLwotCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoIm1wcCIp KSAhPSAwKQorCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoIm1wcCIpKSAhPSAtMSkKIAkJaWYg KGZkdF9pc19jb21wYXRpYmxlKG5vZGUsICJtcnZsLG1wcCIpKQogCQkJZ290byBtb3Zlb247CiAJ LyoKIAkgKiBGaW5kIHRoZSBub2RlIHRoZSBsb25nIHdheS4KIAkgKi8KLQlpZiAoKG5vZGUgPSBP Rl9maW5kZGV2aWNlKCIvIikpID09IDApCisJaWYgKChub2RlID0gT0ZfZmluZGRldmljZSgiLyIp KSA9PSAtMSkKIAkJcmV0dXJuIChFTlhJTyk7CiAKIAlpZiAoKG5vZGUgPSBmZHRfZmluZF9jb21w YXRpYmxlKG5vZGUsICJzaW1wbGUtYnVzIiwgMCkpID09IDApCkBAIC03NTIsNyArNzUyLDcgQEAg cGxhdGZvcm1fZGV2bWFwX2luaXQodm9pZCkKIAkvKgogCSAqIFBDSSByYW5nZShzKS4KIAkgKi8K LQlpZiAoKHJvb3QgPSBPRl9maW5kZGV2aWNlKCIvIikpID09IDApCisJaWYgKChyb290ID0gT0Zf ZmluZGRldmljZSgiLyIpKSA9PSAtMSkKIAkJcmV0dXJuIChFTlhJTyk7CiAKIAlmb3IgKGNoaWxk ID0gT0ZfY2hpbGQocm9vdCk7IGNoaWxkICE9IDA7IGNoaWxkID0gT0ZfcGVlcihjaGlsZCkpCkBA IC03NzksNyArNzc5LDcgQEAgcGxhdGZvcm1fZGV2bWFwX2luaXQodm9pZCkKIAkvKgogCSAqIENF U0EgU1JBTSByYW5nZS4KIAkgKi8KLQlpZiAoKGNoaWxkID0gT0ZfZmluZGRldmljZSgic3JhbSIp KSAhPSAwKQorCWlmICgoY2hpbGQgPSBPRl9maW5kZGV2aWNlKCJzcmFtIikpICE9IC0xKQogCQlp ZiAoZmR0X2lzX2NvbXBhdGlibGUoY2hpbGQsICJtcnZsLGNlc2Etc3JhbSIpKQogCQkJZ290byBt b3Zlb247CiAK --0016e65a0986df04a304b0cfdd47 Content-Type: application/octet-stream; name="ppc-fixes.patch" Content-Disposition: attachment; filename="ppc-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvczc2 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZmR0L2ZkdF9wb3dlcnBjLmMgYi9zeXMvZGV2L2ZkdC9mZHRf cG93ZXJwYy5jCmluZGV4IGVhNjE0ZGIuLmFjODFjMDggMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvZmR0 L2ZkdF9wb3dlcnBjLmMKKysrIGIvc3lzL2Rldi9mZHQvZmR0X3Bvd2VycGMuYwpAQCAtNjIsNyAr NjIsNyBAQCBmZHRfZml4dXBfYnVzZnJlcShwaGFuZGxlX3Qgcm9vdCkKIAkgKiBUaGlzIGZpeHVw IHVzZXMgL2NwdXMvIGJ1cy1mcmVxdWVuY3kgcHJvcCB2YWx1ZSB0byBzZXQgc2ltcGxlLWJ1cwog CSAqIGJ1cy1mcmVxdWVuY3kgcHJvcGVydHkuCiAJICovCi0JaWYgKChjcHVzID0gT0ZfZmluZGRl dmljZSgiL2NwdXMiKSkgPT0gMCkKKwlpZiAoKGNwdXMgPSBPRl9maW5kZGV2aWNlKCIvY3B1cyIp KSA9PSAtMSkKIAkJcmV0dXJuOwogCiAJaWYgKChjaGlsZCA9IE9GX2NoaWxkKGNwdXMpKSA9PSAw KQpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvYm9va2UvcGxhdGZvcm1fYmFyZS5jIGIvc3lzL3Bv d2VycGMvYm9va2UvcGxhdGZvcm1fYmFyZS5jCmluZGV4IGNhM2NmYTIuLmYwNGJmOTYgMTAwNjQ0 Ci0tLSBhL3N5cy9wb3dlcnBjL2Jvb2tlL3BsYXRmb3JtX2JhcmUuYworKysgYi9zeXMvcG93ZXJw Yy9ib29rZS9wbGF0Zm9ybV9iYXJlLmMKQEAgLTE4OSw3ICsxODksNyBAQCBiYXJlX3RpbWViYXNl X2ZyZXEocGxhdGZvcm1fdCBwbGF0LCBzdHJ1Y3QgY3B1cmVmICpjcHVyZWYpCiAJfSBlbHNlCiAJ CXRpY2tzID0gMDsKIAotCWlmICgoY3B1cyA9IE9GX2ZpbmRkZXZpY2UoIi9jcHVzIikpID09IDAp CisJaWYgKChjcHVzID0gT0ZfZmluZGRldmljZSgiL2NwdXMiKSkgPT0gLTEpCiAJCWdvdG8gb3V0 OwogCiAJaWYgKChjaGlsZCA9IE9GX2NoaWxkKGNwdXMpKSA9PSAwKQo= --0016e65a0986df04a304b0cfdd47-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 08:30:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9B71065676 for ; Thu, 3 Nov 2011 08:30:56 +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 14B338FC17 for ; Thu, 3 Nov 2011 08:30:55 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 23933984; Thu, 03 Nov 2011 09:30:52 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 3 Nov 2011 09:27:55 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EB1602C.6030807@janh.de> In-Reply-To: <4EB1602C.6030807@janh.de> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111030927.55637.hselasky@c2i.net> Cc: Jan Henrik Sylvester Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 08:30:56 -0000 On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: > I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect > an USB3 hard disk to my Thinkpad T510, which only has USB2. > > Trying to hot plug the express card did nothing, but I guess that is > expected. Hence, I booted with the express card already inserted, only > to receive a panic upon xhci0 initialization, see below. > > This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from > the official DVD. > > I guess I could test 226803 mentioned in > http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html > , which happened after RC1, but from the commit message, it only fixes > suspend and resume. > > As I do not have much time now, should I test 226803, find a Linux CD to > actually identify the device, or anything else? > > Cheers, > Jan Henrik > > > usbus0: 480 Mbps High Speed USB v2.0 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor write data, page not present > instruction ponter = 0x20:0xffffffff806e80aa > stack pointer = 0x28:0xffffff810ee50bc0 > frame pointer = 0x28:0xffffff810ee50bf0 > code segment = base 0x0, limit 0xfffff, type 0x16 > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 15 (xhci0) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime = 1s > Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside "xhci_configure_msg()" which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 11:13:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F3E106566C for ; Thu, 3 Nov 2011 11:13:38 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 591B88FC20 for ; Thu, 3 Nov 2011 11:13:37 +0000 (UTC) Received: by faar19 with SMTP id r19so2091688faa.13 for ; Thu, 03 Nov 2011 04:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=R5uF1oA/bWcq/Hmqo5gOg3dqQDsdZMExrNShLt9VT98=; b=mEAlvIMPqdO3rT+GB65YNEb46bgNVBRyU8zGTYyn7iMGuE0w66WZhF0X/037+s5GYO KAYkRTRX7NO77Y1TSdtkWPDoIY/Xy4sBiwOtP8f0YHqOXgWX9LyvzeBIM5gQdp0gvU1G CZeYuQIpVJR9zkoWOrrKVvBFRPhZmTFuPAPog= Received: by 10.223.92.135 with SMTP id r7mr292600fam.35.1320318816230; Thu, 03 Nov 2011 04:13:36 -0700 (PDT) Received: from [192.168.119.6] (gate19.robnet.pl. [194.105.132.219]) by mx.google.com with ESMTPS id a8sm11506578faa.11.2011.11.03.04.13.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 04:13:35 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20111103061049.GA2273@tinyCurrent> Date: Thu, 3 Nov 2011 12:13:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <750E14C8-D184-4ECC-9701-27D8E715B773@FreeBSD.org> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> To: Matthias Apitz X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:13:38 -0000 Wiadomo=B6=E6 napisana przez Matthias Apitz w dniu 3 lis 2011, o godz. = 07:10: > El d=EDa Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias = Apitz escribi=F3: >> Hello, >>=20 >> I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on = November >> 1st; >>=20 >> The ports/audio/jack seems installing fine, but the shared lib >> libjack.so is missing below ports/audio/jack/work and /usr/local/lib; = it >> is mentioned in the list -L of the package; later ports/audio/arts = and >> ports/x11/kde3 are missing the shared lib; >=20 > It turns out that the problem is more general! A lot of ./configure > scripts are detecting in 10-CUR that they can't or should not build > shared libs; the problem is that the OS is detected now as As a temporary workaround, add "WITH_FBSD10_FIX=3D1" to /etc/make.conf. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 11:26:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F141065677; Thu, 3 Nov 2011 11:26:49 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id EF4C08FC13; Thu, 3 Nov 2011 11:26:48 +0000 (UTC) Received: from [89.204.137.149] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLvRV-0002TG-Gw; Thu, 03 Nov 2011 12:26:47 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA3BQpLf001178; Thu, 3 Nov 2011 12:26:51 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA3BQoRv001177; Thu, 3 Nov 2011 12:26:50 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Thu, 3 Nov 2011 12:26:49 +0100 From: Matthias Apitz To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Message-ID: <20111103112649.GA1164@tiny> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> <750E14C8-D184-4ECC-9701-27D8E715B773@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <750E14C8-D184-4ECC-9701-27D8E715B773@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.137.149 Cc: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:26:49 -0000 El día Thursday, November 03, 2011 a las 12:13:31PM +0100, Edward Tomasz NapieraÅ‚a escribió: > > It turns out that the problem is more general! A lot of ./configure > > scripts are detecting in 10-CUR that they can't or should not build > > shared libs; the problem is that the OS is detected now as > > As a temporary workaround, add "WITH_FBSD10_FIX=1" to /etc/make.conf. ports/UPDATING and some of the mails in the archive of -current recommend setting UNAME_r=9.0-CURRENT; is this the same or which method is prefered? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 11:28:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B789F106566B; Thu, 3 Nov 2011 11:28:47 +0000 (UTC) Date: Thu, 3 Nov 2011 11:28:47 +0000 From: Alexander Best To: Matthias Apitz Message-ID: <20111103112847.GA35937@freebsd.org> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111103061049.GA2273@tinyCurrent> Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:28:47 -0000 On Thu Nov 3 11, Matthias Apitz wrote: > El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: > > > > > Hello, > > > > I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November > > 1st; > > > > The ports/audio/jack seems installing fine, but the shared lib > > libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it > > is mentioned in the list -L of the package; later ports/audio/arts and > > ports/x11/kde3 are missing the shared lib; > > It turns out that the problem is more general! A lot of ./configure > scripts are detecting in 10-CUR that they can't or should not build > shared libs; the problem is that the OS is detected now as > > host_os: freebsd10.0 > > and the ./configure scripts have tests like this: > > ports/audio/jack/work/jack-audio-connection-kit-0.121.3: > > case $host_os in > ... > freebsd1*) > dynamic_linker=no > ;; > ... > > And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? uname -a FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 i did a 'cd /usr/ports/security/p11-kit ; make ; make install', yet from the following list: otaku% pkg_info -L p11-kit-0.8 Information for p11-kit-0.8: Files: /usr/local/bin/p11-kit /usr/local/include/p11-kit-1/p11-kit/p11-kit.h /usr/local/include/p11-kit-1/p11-kit/pin.h /usr/local/include/p11-kit-1/p11-kit/uri.h /usr/local/include/p11-kit-1/p11-kit/pkcs11.h /usr/local/lib/libp11-kit.a /usr/local/lib/libp11-kit.la /usr/local/lib/libp11-kit.so /usr/local/lib/libp11-kit.so.0 /usr/local/lib/p11-kit-proxy.so /usr/local/libdata/pkgconfig/p11-kit-1.pc /usr/local/share/gtk-doc/html/p11-kit/api-index-full.html /usr/local/share/gtk-doc/html/p11-kit/config-example.html /usr/local/share/gtk-doc/html/p11-kit/config-format.html /usr/local/share/gtk-doc/html/p11-kit/config-global.html /usr/local/share/gtk-doc/html/p11-kit/config-locations.html /usr/local/share/gtk-doc/html/p11-kit/config-module.html /usr/local/share/gtk-doc/html/p11-kit/config.html /usr/local/share/gtk-doc/html/p11-kit/gtk-doc.css /usr/local/share/gtk-doc/html/p11-kit/home.png /usr/local/share/gtk-doc/html/p11-kit/index.html /usr/local/share/gtk-doc/html/p11-kit/index.sgml /usr/local/share/gtk-doc/html/p11-kit/left.png /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Future.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Modules.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-PIN-Callbacks.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-URIs.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Utilities.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit.devhelp2 /usr/local/share/gtk-doc/html/p11-kit/up.png /usr/local/share/gtk-doc/html/p11-kit/reference.html /usr/local/share/gtk-doc/html/p11-kit/right.png /usr/local/share/gtk-doc/html/p11-kit/sharing-initialize.html /usr/local/share/gtk-doc/html/p11-kit/sharing-module.html /usr/local/share/gtk-doc/html/p11-kit/sharing.html /usr/local/share/gtk-doc/html/p11-kit/style.css /usr/local/share/examples/p11-kit/pkcs11.conf.example all *.so* files didn't get installed! cheers. alex > > matthias > > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) > UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 10:51:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01693106566B for ; Thu, 3 Nov 2011 10:51:21 +0000 (UTC) (envelope-from me@janh.de) Received: from mxchg03.rrz.uni-hamburg.de (mxchg03.rrz.uni-hamburg.de [134.100.38.113]) by mx1.freebsd.org (Postfix) with ESMTP id 834648FC1C for ; Thu, 3 Nov 2011 10:51:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTP id E7A4D1EE2A3; Thu, 3 Nov 2011 11:51:18 +0100 (CET) X-Virus-Scanned: by University of Hamburg ( RRZ / mgw02.rrz.uni-hamburg.de ) Received: from mxchg03.rrz.uni-hamburg.de ([127.0.0.1]) by localhost (mxchg03.rrz.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10324) with ESMTP id vOogmoa6vkdl; Thu, 3 Nov 2011 11:51:18 +0100 (CET) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.38.99]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTPS; Thu, 3 Nov 2011 11:51:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id D48549000B; Thu, 3 Nov 2011 11:51:18 +0100 (CET) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R8Oknz9Bt6dG; Thu, 3 Nov 2011 11:51:18 +0100 (CET) Received: from nb981.math (g224003050.adsl.alicedsl.de [92.224.3.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 7B20490006; Thu, 3 Nov 2011 11:51:18 +0100 (CET) Message-ID: <4EB27225.4020504@janh.de> Date: Thu, 03 Nov 2011 11:51:17 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111101 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EB1602C.6030807@janh.de> <201111030927.55637.hselasky@c2i.net> In-Reply-To: <201111030927.55637.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Nov 2011 11:28:59 +0000 Cc: freebsd-current@freebsd.org Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 10:51:21 -0000 On 11/03/2011 09:27, Hans Petter Selasky wrote: > On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: >> I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect >> an USB3 hard disk to my Thinkpad T510, which only has USB2. >> >> Trying to hot plug the express card did nothing, but I guess that is >> expected. Hence, I booted with the express card already inserted, only >> to receive a panic upon xhci0 initialization, see below. >> >> This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from >> the official DVD. >> >> I guess I could test 226803 mentioned in >> http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html >> , which happened after RC1, but from the commit message, it only fixes >> suspend and resume. >> >> As I do not have much time now, should I test 226803, find a Linux CD to >> actually identify the device, or anything else? >> >> Cheers, >> Jan Henrik >> >> >> usbus0: 480 Mbps High Speed USB v2.0 >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x18 >> fault code = supervisor write data, page not present >> instruction ponter = 0x20:0xffffffff806e80aa >> stack pointer = 0x28:0xffffff810ee50bc0 >> frame pointer = 0x28:0xffffff810ee50bf0 >> code segment = base 0x0, limit 0xfffff, type 0x16 >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 15 (xhci0) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> Uptime = 1s >> Automatic reboot in 15 seconds - press a key on the console to abort > > Hi, > > This looks like a NULL-pointer issue inside "xhci_configure_msg()" which > probably should be easy to fix. > > Could you compile and boot a kernel with kernel debugging enable so that you > get a backgtrace? I have not done this before. The GENERIC kernel already contains "makeoptions DEBUG=-g" (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev="AUTO" in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? Cheers, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 12:05:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64F4106567D; Thu, 3 Nov 2011 12:05:56 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4D38FC0C; Thu, 3 Nov 2011 12:05:55 +0000 (UTC) Received: by faar19 with SMTP id r19so2160260faa.13 for ; Thu, 03 Nov 2011 05:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rZulWx+Ciuxx+3covd/MuLgQ0MdCxWh/W65wfpXuBEA=; b=NkPvb1LqE7mm72NFZN2XBBouO5UV7QaEky7sOXk2n73me4gIiQ39Q1nus44XafeSfg NRGSPUzQXH5F3uuw9vTWbYZ8NOW1cIDzEBkzYUs+7VLnEdyfQVkmetK/QcNnsDs1NnT8 UD24y2wVnLqh+OUhLjgOkKPZAOvFeXWFjJks4= Received: by 10.223.77.71 with SMTP id f7mr15916587fak.33.1320321954594; Thu, 03 Nov 2011 05:05:54 -0700 (PDT) Received: from [192.168.119.6] (gate19.robnet.pl. [194.105.132.219]) by mx.google.com with ESMTPS id l18sm11740213fab.9.2011.11.03.05.05.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 05:05:53 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20111103112649.GA1164@tiny> Date: Thu, 3 Nov 2011 13:05:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> <750E14C8-D184-4ECC-9701-27D8E715B773@FreeBSD.org> <20111103112649.GA1164@tiny> To: Matthias Apitz X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:05:56 -0000 Wiadomo=B6=E6 napisana przez Matthias Apitz w dniu 3 lis 2011, o godz. = 12:26: > El d=EDa Thursday, November 03, 2011 a las 12:13:31PM +0100, Edward = Tomasz Napiera=B3a escribi=F3: >=20 >>> It turns out that the problem is more general! A lot of ./configure >>> scripts are detecting in 10-CUR that they can't or should not build >>> shared libs; the problem is that the OS is detected now as >>=20 >> As a temporary workaround, add "WITH_FBSD10_FIX=3D1" to = /etc/make.conf. >=20 > ports/UPDATING and some of the mails in the archive of -current > recommend setting UNAME_r=3D9.0-CURRENT; is this the same or which = method > is prefered? No, I guess UPDATING is right. It's just that I never remember to read it when encountering problems after an update, and the above method "works for me". --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 11:51:00 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DF7106564A; Thu, 3 Nov 2011 11:51:00 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from mikako.shopkeeper.de (mikako.shopkeeper.de [82.119.175.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2E58FC15; Thu, 3 Nov 2011 11:50:59 +0000 (UTC) Received: from avalon.dobu.local (p508D4743.dip.t-dialin.net [80.141.71.67]) (authenticated bits=0) by mikako.shopkeeper.de (8.14.3/8.14.3) with ESMTP id pA3BosIW031316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 12:50:57 +0100 (CET) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.4/8.14.2) with ESMTP id pA3BosWg002210; Thu, 3 Nov 2011 12:50:54 +0100 (CET) (envelope-from sascha@avalon.dobu.local) Received: (from sascha@localhost) by avalon.dobu.local (8.14.4/8.14.4/Submit) id pA3Boso9002209; Thu, 3 Nov 2011 12:50:54 +0100 (CET) (envelope-from sascha) Date: Thu, 3 Nov 2011 12:50:54 +0100 From: Sascha Klauder To: "Andrey V. Elsukov" Message-ID: <20111103115054.GA2155@trimind.de> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> <20111028094828.GA1781@trimind.de> <4EAF9E67.4040605@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAF9E67.4040605@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.97.2 at mikako.shopkeeper.de X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 Nov 2011 12:14:47 +0000 Cc: Garrett Cooper , antik@bsd.ee, Martin Wilke , current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:51:01 -0000 On Tue, 2011-11-01 11:23 +0400, Andrey V. Elsukov wrote: > On 28.10.2011 13:48, Sascha Klauder wrote: > > GEOM_MIRROR: Device mirror/gm0 launched (2/2). > > GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > 490350670 > > GEOM_PART: integrity check failed (mirror/gm0, MBR) > This is the main problem. Your MBR' slice is bigger than actual space > you have. The only way to fix this - recreate slice. I've partioned and labeled the disk with sysinstall(8) from 8.2-RELEASE media. Does 9.0 use different disk geometry cal- culation than 8.2 or is usage of gmirror the culprit? Both 8.2 and 9.0 kernels report the disk having 490350672 sectors. > You can break your mirror, recreate the slice (NOTE: you must preserve > one sector for the gmirror's meta-data), then copy your data to the > newly created slice, then reboot from the new slice and recreate mirror. I think I'd rather reinstall 9.0 from scratch, getting rid of MBR/disklabel as well. Cheers, -sascha From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 12:15:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E46106564A; Thu, 3 Nov 2011 12:15:18 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 23F9E8FC14; Thu, 3 Nov 2011 12:15:18 +0000 (UTC) Received: from [89.204.137.188] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RLwCR-0006KX-1e; Thu, 03 Nov 2011 13:15:16 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA3CFK1B001250; Thu, 3 Nov 2011 13:15:21 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA3CFJsS001249; Thu, 3 Nov 2011 13:15:19 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Thu, 3 Nov 2011 13:15:19 +0100 From: Matthias Apitz To: Alexander Best Message-ID: <20111103121519.GA1237@tiny> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> <20111103112847.GA35937@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111103112847.GA35937@freebsd.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.137.188 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:15:18 -0000 El día Thursday, November 03, 2011 a las 11:28:47AM +0000, Alexander Best escribió: > > It turns out that the problem is more general! A lot of ./configure > > scripts are detecting in 10-CUR that they can't or should not build > > shared libs; the problem is that the OS is detected now as > > > > host_os: freebsd10.0 > > > > and the ./configure scripts have tests like this: > > > > ports/audio/jack/work/jack-audio-connection-kit-0.121.3: > > > > case $host_os in > > ... > > freebsd1*) > > dynamic_linker=no > > ;; > > ... > > > > And now? I'm cluesless now how we could solve this :-( > > are you sure this issue is related to the freebsd1* case? I can only comment what I saw: - OS was detected as freebsd10.0 (I inserted a 'echo $host_os' into the ./configure script - ./configure said that it should/will not build shared libs - the *.so* were missing in ports/audio/jack/work/... and in /usr/local/lib I will remove all /usr/ports/* and /usr/local/* and /var/db/pkg/* and will start from scratch with "cvs checkout" and will set UNAME_r as explained in ports/UPDATING; will let you know the result matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 12:30:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809DD10656D0 for ; Thu, 3 Nov 2011 12:30:22 +0000 (UTC) (envelope-from me@janh.de) Received: from mxchg03.rrz.uni-hamburg.de (mxchg03.rrz.uni-hamburg.de [134.100.38.113]) by mx1.freebsd.org (Postfix) with ESMTP id 280518FC12 for ; Thu, 3 Nov 2011 12:30:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTP id DFD7C1EE251; Thu, 3 Nov 2011 13:30:20 +0100 (CET) X-Virus-Scanned: by University of Hamburg ( RRZ / mgw02.rrz.uni-hamburg.de ) Received: from mxchg03.rrz.uni-hamburg.de ([127.0.0.1]) by localhost (mxchg03.rrz.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10324) with ESMTP id mzrWahVGQ21N; Thu, 3 Nov 2011 13:30:20 +0100 (CET) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.38.99]) by mxchg03.rrz.uni-hamburg.de (Postfix) with ESMTPS; Thu, 3 Nov 2011 13:30:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id CA80790006; Thu, 3 Nov 2011 13:30:20 +0100 (CET) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OSCgURL-9cOT; Thu, 3 Nov 2011 13:30:20 +0100 (CET) Received: from nb981.math (g224003050.adsl.alicedsl.de [92.224.3.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 70A7590002; Thu, 3 Nov 2011 13:30:20 +0100 (CET) Message-ID: <4EB2895B.3080104@janh.de> Date: Thu, 03 Nov 2011 13:30:19 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111101 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EB1602C.6030807@janh.de> <201111030927.55637.hselasky@c2i.net> <4EB27225.4020504@janh.de> In-Reply-To: <4EB27225.4020504@janh.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Nov 2011 12:39:53 +0000 Cc: freebsd-current@freebsd.org Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:30:22 -0000 On 11/03/2011 11:51, Jan Henrik Sylvester wrote: > On 11/03/2011 09:27, Hans Petter Selasky wrote: >> On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: >>> I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect >>> an USB3 hard disk to my Thinkpad T510, which only has USB2. >>> >>> Trying to hot plug the express card did nothing, but I guess that is >>> expected. Hence, I booted with the express card already inserted, only >>> to receive a panic upon xhci0 initialization, see below. >>> >>> This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from >>> the official DVD. >>> >>> I guess I could test 226803 mentioned in >>> http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html >>> , which happened after RC1, but from the commit message, it only fixes >>> suspend and resume. >>> >>> As I do not have much time now, should I test 226803, find a Linux CD to >>> actually identify the device, or anything else? >>> >>> Cheers, >>> Jan Henrik >>> >>> >>> usbus0: 480 Mbps High Speed USB v2.0 >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x18 >>> fault code = supervisor write data, page not present >>> instruction ponter = 0x20:0xffffffff806e80aa >>> stack pointer = 0x28:0xffffff810ee50bc0 >>> frame pointer = 0x28:0xffffff810ee50bf0 >>> code segment = base 0x0, limit 0xfffff, type 0x16 >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 15 (xhci0) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> Uptime = 1s >>> Automatic reboot in 15 seconds - press a key on the console to abort >> >> Hi, >> >> This looks like a NULL-pointer issue inside "xhci_configure_msg()" which >> probably should be easy to fix. >> >> Could you compile and boot a kernel with kernel debugging enable so >> that you >> get a backgtrace? > > I have not done this before. > > The GENERIC kernel already contains "makeoptions DEBUG=-g" (at least it > is in /usr/src/sys/amd64/conf/GENERIC and there are all this large > /boot/kernel/*.symbols). Is there anything else needed? (I do not need > all the stuff that Ken Smith took out just before RC1 in r226405 just to > get a trace, since I do not want to do online debugging, or do I need it > anyhow?) > > From > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > , I thought that setting dumpdev="AUTO" in /etc/rc.conf was enough to > get a dump in /var/crash/ after the next boot to multiuser. That does > not seem to be the case for me. What else do I have to do? After reading a bit more, I still do not know why I do not get a crash dump with dumpdev="AUTO" (and /var/crash/ having enough space for a full memory dump). Is it too early during boot for dumpon to be set? After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that ffffffff806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0xffffffff806e80aa. Does this help? Cheers, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 13:24:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68797106564A; Thu, 3 Nov 2011 13:24:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B86448FC13; Thu, 3 Nov 2011 13:24:48 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA3DOcPv099404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 15:24:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA3DOcFl037762; Thu, 3 Nov 2011 15:24:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA3DObTj037761; Thu, 3 Nov 2011 15:24:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Nov 2011 15:24:37 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111103132437.GV50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b26/eLay4JVJAfoL" Content-Disposition: inline In-Reply-To: <4EB22938.4050803@rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:24:49 -0000 --b26/eLay4JVJAfoL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote: > On 11/02/2011 05:32, Andriy Gapon wrote: > >[restored cc: to the original poster] > >As Bruce Evans has pointed to me privately [I am not sure why privately]= ,=20 > >there > >is already an example in i386 and amd64 atomic.h, where operations are= =20 > >inlined > >for a kernel build, but presented as real (external) functions for a mod= ule > >build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. > > > >I think that the same treatment could/should be applied to vm_page_*lock* > >operations defined in sys/vm/vm_page.h. > *snip* >=20 > Yes, it should be. There are without question legitimate reasons for a= =20 > module to acquire a page lock. I agree. Also, I think that we should use the opportunity to also isolate the modules from the struct vm_page layout changes. As example, I converted nfsclient.ko. Patch is not tested. diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c index 305c189..7264cd1 100644 --- a/sys/nfsclient/nfs_bio.c +++ b/sys/nfsclient/nfs_bio.c @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) * can only occur at the file EOF. */ VM_OBJECT_LOCK(object); - if (pages[ap->a_reqpage]->valid !=3D 0) { + if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { for (i =3D 0; i < npages; ++i) { if (i !=3D ap->a_reqpage) { vm_page_lock(pages[i]); @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) /* * Read operation filled an entire page */ - m->valid =3D VM_PAGE_BITS_ALL; - KASSERT(m->dirty =3D=3D 0, + vm_page_write_valid(m, VM_PAGE_BITS_ALL); + KASSERT(vm_page_read_dirty(m) =3D=3D 0, ("nfs_getpages: page %p is dirty", m)); } else if (size > toff) { /* * Read operation filled a partial page. */ - m->valid =3D 0; + vm_page_write_valid(m, 0); vm_page_set_valid(m, 0, size - toff); - KASSERT(m->dirty =3D=3D 0, + KASSERT(vm_page_read_dirty(m) =3D=3D 0, ("nfs_getpages: page %p is dirty", m)); } else { /* diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c index f14da4a..5b8b4e3 100644 --- a/sys/vm/vm_page.c +++ b/sys/vm/vm_page.c @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) vm_page_dirty(m); } =20 +void +vm_page_lock_func(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_lock(vm_page_lockptr(m), 0, file, line); +#endif +} + +void +vm_page_unlock_func(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); +#endif +} + +int +vm_page_trylock_func(vm_page_t m, const char *file, int line) +{ + + return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); +} + +void +vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line) +{ + +#ifdef INVARIANTS + _mtx_assert(vm_page_lockptr(m), a, file, line); +#endif +} + +vm_page_bits_t +vm_page_read_dirty_func(vm_page_t m) +{ + + return (m->dirty); +} + +vm_page_bits_t +vm_page_read_valid_func(vm_page_t m) +{ + + return (m->valid); +} + +void +vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v) +{ + + m->valid =3D v; +} + + int so_zerocp_fullpage =3D 0; =20 /* diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 23637bb..618ba2b 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -113,6 +113,21 @@ =20 TAILQ_HEAD(pglist, vm_page); =20 +#if PAGE_SIZE =3D=3D 4096 +#define VM_PAGE_BITS_ALL 0xffu +typedef uint8_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 8192 +#define VM_PAGE_BITS_ALL 0xffffu +typedef uint16_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 16384 +#define VM_PAGE_BITS_ALL 0xffffffffu +typedef uint32_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 32768 +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu +typedef uint64_t vm_page_bits_t; +#endif + + struct vm_page { TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q)= */ TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ @@ -138,19 +153,8 @@ struct vm_page { /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ /* so, on normal X86 kernels, they must be at least 8 bits wide */ /* In reality, support for 32KB pages is not fully implemented. */ -#if PAGE_SIZE =3D=3D 4096 - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 8192 - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 16384 - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 32768 - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#endif + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ }; =20 /* @@ -216,12 +220,50 @@ extern struct vpglocks pa_lock[]; =20 #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a)) =20 +#ifdef KLD_MODULE +#define vm_page_lock(m) vm_page_lock_func((m), LOCK_FILE, LOCK_LINE) +#define vm_page_unlock(m) vm_page_unlock_func((m), LOCK_FILE, LOCK_LINE) +#define vm_page_trylock(m) vm_page_trylock_func((m), LOCK_FILE, LOCK_LINE) +#ifdef INVARIANTS +#define vm_page_lock_assert(m, a) \ + vm_page_lock_assert_func((m), (a), LOCK_FILE, LOCK_LINE) +#else +#define vm_page_lock_assert(m, a) +#endif + +#define vm_page_read_dirty(m) vm_page_read_dirty_func((m)) +#define vm_page_read_valid(m) vm_page_read_valid_func((m)) +#define vm_page_write_valid(m, v) vm_page_write_valid_func((m), (v)) + +#else /* KLD_MODULE */ #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m)))) #define vm_page_lock(m) mtx_lock(vm_page_lockptr((m))) #define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m))) #define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m))) #define vm_page_lock_assert(m, a) mtx_assert(vm_page_lockptr((m)), (a)) =20 +static inline vm_page_bits_t +vm_page_read_dirty(vm_page_t m) +{ + + return (m->dirty); +} + +static inline vm_page_bits_t +vm_page_read_valid(vm_page_t m) +{ + + return (m->valid); +} + +static inline void +vm_page_write_valid(vm_page_t m, vm_page_bits_t v) +{ + + m->valid =3D v; +} +#endif + #define vm_page_queue_free_mtx vm_page_queue_free_lock.data /* * These are the flags defined for vm_page. @@ -322,16 +364,6 @@ extern struct vpglocks vm_page_queue_lock; #define vm_page_lock_queues() mtx_lock(&vm_page_queue_mtx) #define vm_page_unlock_queues() mtx_unlock(&vm_page_queue_mtx) =20 -#if PAGE_SIZE =3D=3D 4096 -#define VM_PAGE_BITS_ALL 0xffu -#elif PAGE_SIZE =3D=3D 8192 -#define VM_PAGE_BITS_ALL 0xffffu -#elif PAGE_SIZE =3D=3D 16384 -#define VM_PAGE_BITS_ALL 0xffffffffu -#elif PAGE_SIZE =3D=3D 32768 -#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu -#endif - /* page allocation classes: */ #define VM_ALLOC_NORMAL 0 #define VM_ALLOC_INTERRUPT 1 @@ -411,6 +443,15 @@ void vm_page_cowfault (vm_page_t); int vm_page_cowsetup(vm_page_t); void vm_page_cowclear (vm_page_t); =20 +void vm_page_lock_func(vm_page_t m, const char *file, int line); +void vm_page_unlock_func(vm_page_t m, const char *file, int line); +int vm_page_trylock_func(vm_page_t m, const char *file, int line); +void vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int li= ne); + +vm_page_bits_t vm_page_read_dirty_func(vm_page_t m); +vm_page_bits_t vm_page_read_valid_func(vm_page_t m); +void vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v); + #ifdef INVARIANTS void vm_page_object_lock_assert(vm_page_t m); #define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m) --b26/eLay4JVJAfoL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6ylhQACgkQC3+MBN1Mb4g1oQCg5+rQCsUWaSFBVK9LZEwkaod4 z/IAoNR7rcQ7oLyQy5f9EwiDwlvD93iy =IyQ9 -----END PGP SIGNATURE----- --b26/eLay4JVJAfoL-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 13:28:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6FE0D1065670; Thu, 3 Nov 2011 13:28:24 +0000 (UTC) Date: Thu, 3 Nov 2011 13:28:24 +0000 From: Alexander Best To: Matthias Apitz Message-ID: <20111103132824.GA56322@freebsd.org> References: <20111102193606.GA1086@tiny> <20111103061049.GA2273@tinyCurrent> <20111103112847.GA35937@freebsd.org> <20111103121519.GA1237@tiny> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111103121519.GA1237@tiny> Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:28:24 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu Nov 3 11, Matthias Apitz wrote: > El día Thursday, November 03, 2011 a las 11:28:47AM +0000, Alexander Best escribió: > > > > It turns out that the problem is more general! A lot of ./configure > > > scripts are detecting in 10-CUR that they can't or should not build > > > shared libs; the problem is that the OS is detected now as > > > > > > host_os: freebsd10.0 > > > > > > and the ./configure scripts have tests like this: here's my config.log after building and installing security/p11-kit. i have edited my newvers.sh according to UPDATING and uname -a now properly reports: FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 still for me the issue remains: no libs get built and thus not installed! cheers. alex > > > > > > ports/audio/jack/work/jack-audio-connection-kit-0.121.3: > > > > > > case $host_os in > > > ... > > > freebsd1*) > > > dynamic_linker=no > > > ;; > > > ... > > > > > > And now? I'm cluesless now how we could solve this :-( > > > > are you sure this issue is related to the freebsd1* case? > > I can only comment what I saw: > > - OS was detected as freebsd10.0 (I inserted a 'echo $host_os' into the > ./configure script > > - ./configure said that it should/will not build shared libs > > - the *.so* were missing in ports/audio/jack/work/... and in > /usr/local/lib > > I will remove all /usr/ports/* and /usr/local/* and /var/db/pkg/* and > will start from scratch with "cvs checkout" and will set UNAME_r as > explained in ports/UPDATING; > > will let you know the result > > matthias > > -- > Matthias Apitz > e - w http://www.unixarea.de/ > UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) > UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config.log" This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by p11-kit configure 0.8, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure --disable-gtk-doc --disable-nls --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.9 ## --------- ## ## Platform. ## ## --------- ## hostname = otaku uname -m = amd64 uname -r = 9.9-CURRENT uname -s = FreeBSD uname -v = FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/local/diablo-jre1.6.0/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2406: checking for a BSD-compatible install configure:2474: result: /usr/bin/install -c -o root -g wheel configure:2485: checking whether build environment is sane configure:2535: result: yes configure:2676: checking for a thread-safe mkdir -p configure:2715: result: ./install-sh -c -d configure:2728: checking for gawk configure:2758: result: no configure:2728: checking for mawk configure:2758: result: no configure:2728: checking for nawk configure:2744: found /usr/bin/nawk configure:2755: result: nawk configure:2766: checking whether make sets $(MAKE) configure:2788: result: yes configure:2868: checking whether build environment is sane configure:2918: result: yes configure:2921: checking whether to disable maintainer-specific portions of Makefiles configure:2930: result: yes configure:2986: checking build system type configure:3000: result: amd64-portbld-freebsd9.9 configure:3020: checking host system type configure:3033: result: amd64-portbld-freebsd9.9 configure:3074: checking how to print strings configure:3101: result: printf configure:3134: checking for style of include used by make configure:3162: result: GNU configure:3232: checking for gcc configure:3259: result: cc configure:3488: checking for C compiler version configure:3497: cc --version >&5 cc (GCC) 4.2.2 20070831 prerelease [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3508: $? = 0 configure:3497: cc -v >&5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] configure:3508: $? = 0 configure:3497: cc -V >&5 cc: '-V' option must have argument configure:3508: $? = 1 configure:3497: cc -qversion >&5 cc: unrecognized option '-qversion' cc: No input files specified configure:3508: $? = 1 configure:3528: checking whether the C compiler works configure:3550: cc -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3554: $? = 0 configure:3602: result: yes configure:3605: checking for C compiler default output file name configure:3607: result: a.out configure:3613: checking for suffix of executables configure:3620: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3624: $? = 0 configure:3646: result: configure:3668: checking whether we are cross compiling configure:3676: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3680: $? = 0 configure:3687: ./conftest configure:3691: $? = 0 configure:3706: result: no configure:3711: checking for suffix of object files configure:3733: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3737: $? = 0 configure:3758: result: o configure:3762: checking whether we are using the GNU C compiler configure:3781: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3781: $? = 0 configure:3790: result: yes configure:3799: checking whether cc accepts -g configure:3819: cc -c -g conftest.c >&5 configure:3819: $? = 0 configure:3860: result: yes configure:3877: checking for cc option to accept ISO C89 configure:3941: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:3941: $? = 0 configure:3954: result: none needed configure:3976: checking dependency style of cc configure:4086: result: gcc3 configure:4101: checking for a sed that does not truncate output configure:4165: result: /usr/bin/sed configure:4183: checking for grep that handles long lines and -e configure:4241: result: /usr/bin/grep configure:4246: checking for egrep configure:4308: result: /usr/bin/grep -E configure:4313: checking for fgrep configure:4375: result: /usr/bin/grep -F configure:4410: checking for ld used by cc configure:4477: result: /usr/bin/ld configure:4484: checking if the linker (/usr/bin/ld) is GNU ld configure:4499: result: yes configure:4511: checking for BSD- or MS-compatible name lister (nm) configure:4560: result: /usr/bin/nm -B configure:4690: checking the name lister (/usr/bin/nm -B) interface configure:4697: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:4700: /usr/bin/nm -B "conftest.o" configure:4703: output 0000000000000000 B some_variable configure:4710: result: BSD nm configure:4713: checking whether ln -s works configure:4717: result: yes configure:4725: checking the maximum length of command line arguments configure:4850: result: 262144 configure:4867: checking whether the shell understands some XSI constructs configure:4877: result: yes configure:4881: checking whether the shell understands "+=" configure:4887: result: no configure:4922: checking how to convert amd64-portbld-freebsd9.9 file names to amd64-portbld-freebsd9.9 format configure:4962: result: func_convert_file_noop configure:4969: checking how to convert amd64-portbld-freebsd9.9 file names to toolchain format configure:4989: result: func_convert_file_noop configure:4996: checking for /usr/bin/ld option to reload object files configure:5003: result: -r configure:5077: checking for objdump configure:5093: found /usr/bin/objdump configure:5104: result: objdump configure:5136: checking how to recognize dependent libraries configure:5338: result: pass_all configure:5423: checking for dlltool configure:5453: result: no configure:5483: checking how to associate runtime and link libraries configure:5510: result: printf %s\n configure:5571: checking for ar configure:5587: found /usr/bin/ar configure:5598: result: ar configure:5635: checking for archiver @FILE support configure:5652: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:5652: $? = 0 configure:5655: ar cru libconftest.a @conftest.lst >&5 ar: warning: can't open file: @conftest.lst: No such file or directory configure:5658: $? = 0 configure:5663: ar cru libconftest.a @conftest.lst >&5 ar: warning: can't open file: @conftest.lst: No such file or directory configure:5666: $? = 0 configure:5678: result: no configure:5736: checking for strip configure:5752: found /usr/bin/strip configure:5763: result: strip configure:5835: checking for ranlib configure:5851: found /usr/bin/ranlib configure:5862: result: ranlib configure:5964: checking command to parse /usr/bin/nm -B output from cc object configure:6083: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:6086: $? = 0 configure:6090: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm configure:6093: $? = 0 configure:6159: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c conftstm.o >&5 configure:6162: $? = 0 configure:6200: result: ok configure:6237: checking for sysroot configure:6267: result: no configure:6510: checking for mt configure:6526: found /usr/bin/mt configure:6537: result: mt configure:6560: checking if mt is a manifest tool configure:6566: mt '-?' mt: illegal option -- ? usage: mt [-f device] command [count] configure:6574: result: no configure:7206: checking how to run the C preprocessor configure:7276: result: cpp configure:7296: cpp conftest.c configure:7296: $? = 0 configure:7310: cpp conftest.c conftest.c:11:28: error: ac_nonexistent.h: No such file or directory configure:7310: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | /* end confdefs.h. */ | #include configure:7339: checking for ANSI C header files configure:7359: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7359: $? = 0 configure:7432: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7432: $? = 0 configure:7432: ./conftest configure:7432: $? = 0 configure:7443: result: yes configure:7456: checking for sys/types.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for sys/stat.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for stdlib.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for string.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for memory.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for strings.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for inttypes.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for stdint.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7456: checking for unistd.h configure:7456: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7456: $? = 0 configure:7456: result: yes configure:7470: checking for dlfcn.h configure:7470: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:7470: $? = 0 configure:7470: result: yes configure:7655: checking for objdir configure:7670: result: .libs configure:7941: checking if cc supports -fno-rtti -fno-exceptions configure:7959: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -fno-rtti -fno-exceptions conftest.c >&5 cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C configure:7963: $? = 0 configure:7976: result: no configure:8286: checking for cc option to produce PIC configure:8293: result: -fPIC -DPIC configure:8301: checking if cc PIC flag -fPIC -DPIC works configure:8319: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -fPIC -DPIC -DPIC conftest.c >&5 configure:8323: $? = 0 configure:8336: result: yes configure:8365: checking if cc static flag -static works configure:8393: result: yes configure:8408: checking if cc supports -c -o file.o configure:8429: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -o out/conftest2.o conftest.c >&5 configure:8433: $? = 0 configure:8455: result: yes configure:8463: checking if cc supports -c -o file.o configure:8510: result: yes configure:8543: checking whether the cc linker (/usr/bin/ld) supports shared libraries configure:9701: result: yes configure:9738: checking whether -lc should be explicitly linked in configure:9746: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:9749: $? = 0 configure:9764: cc -shared -fPIC -DPIC conftest.o -v -Wl,-soname -Wl,conftest -o conftest 2\>\&1 \| /usr/bin/grep -lc \>/dev/null 2\>\&1 configure:9767: $? = 0 configure:9781: result: no configure:9946: checking dynamic linker characteristics configure:10686: result: freebsd9.9 ld.so configure:10793: checking how to hardcode library paths into programs configure:10818: result: immediate configure:10912: checking for shl_load configure:10912: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 /var/tmp//ccmoNINM.o: In function `main': conftest.c:(.text+0x7): undefined reference to `shl_load' configure:10912: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | /* Define shl_load to an innocuous variant, in case declares shl_load. | For example, HP-UX 11i declares gettimeofday. */ | #define shl_load innocuous_shl_load | | /* System header to define __stub macros and hopefully few prototypes, | which can conflict with char shl_load (); below. | Prefer to if __STDC__ is defined, since | exists even on freestanding compilers. */ | | #ifdef __STDC__ | # include | #else | # include | #endif | | #undef shl_load | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined __stub_shl_load || defined __stub___shl_load | choke me | #endif | | int | main () | { | return shl_load (); | ; | return 0; | } configure:10912: result: no configure:10916: checking for shl_load in -ldld configure:10941: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c -ldld >&5 /usr/bin/ld: cannot find -ldld configure:10941: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | int | main () | { | return shl_load (); | ; | return 0; | } configure:10950: result: no configure:10955: checking for dlopen configure:10955: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:10955: $? = 0 configure:10955: result: yes configure:11112: checking whether a program can dlopen itself configure:11192: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -DHAVE_DLFCN_H -Wl,--export-dynamic conftest.c >&5 configure:11195: $? = 0 configure:11213: result: yes configure:11218: checking whether a statically linked program can dlopen itself configure:11298: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -DHAVE_DLFCN_H -Wl,--export-dynamic -static conftest.c >&5 configure:11301: $? = 0 Service unavailable configure:11319: result: no configure:11358: checking whether stripping libraries is possible configure:11363: result: yes configure:11398: checking if libtool supports shared libraries configure:11400: result: yes configure:11403: checking whether to build shared libraries configure:11424: result: yes configure:11427: checking whether to build static libraries configure:11431: result: no configure:11514: checking for gcc configure:11541: result: cc configure:11770: checking for C compiler version configure:11779: cc --version >&5 cc (GCC) 4.2.2 20070831 prerelease [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:11790: $? = 0 configure:11779: cc -v >&5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] configure:11790: $? = 0 configure:11779: cc -V >&5 cc: '-V' option must have argument configure:11790: $? = 1 configure:11779: cc -qversion >&5 cc: unrecognized option '-qversion' cc: No input files specified configure:11790: $? = 1 configure:11794: checking whether we are using the GNU C compiler configure:11822: result: yes configure:11831: checking whether cc accepts -g configure:11892: result: yes configure:11909: checking for cc option to accept ISO C89 configure:11986: result: none needed configure:12008: checking dependency style of cc configure:12118: result: gcc3 configure:12138: checking how to run the C preprocessor configure:12208: result: cpp configure:12228: cpp conftest.c configure:12228: $? = 0 configure:12242: cpp conftest.c conftest.c:23:28: error: ac_nonexistent.h: No such file or directory configure:12242: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | #include configure:12274: checking whether cc understands -c and -o together configure:12302: cc -c conftest.c -o conftest2.o >&5 configure:12306: $? = 0 configure:12312: cc -c conftest.c -o conftest2.o >&5 configure:12316: $? = 0 configure:12371: result: yes configure:12399: checking whether NLS is requested configure:12408: result: no configure:12449: checking for msgfmt configure: trying /usr/local/bin/msgfmt... 0 translated messages. configure:12481: result: /usr/local/bin/msgfmt configure:12490: checking for gmsgfmt configure:12521: result: /usr/local/bin/msgfmt configure:12572: checking for xgettext configure: trying /usr/local/bin/xgettext... /usr/local/bin/xgettext: warning: file `/dev/null' extension `' is unknown; will try C configure:12604: result: /usr/local/bin/xgettext configure:12650: checking for msgmerge configure: trying /usr/local/bin/msgmerge... configure:12681: result: /usr/local/bin/msgmerge configure:12738: checking for ld used by GCC configure:12802: result: /usr/bin/ld configure:12809: checking if the linker (/usr/bin/ld) is GNU ld configure:12822: result: yes configure:12829: checking for shared library run path origin configure:12842: result: done configure:13414: checking for CFPreferencesCopyAppValue configure:13432: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c -Wl,-framework -Wl,CoreFoundation >&5 conftest.c:23:42: error: CoreFoundation/CFPreferences.h: No such file or directory conftest.c: In function 'main': conftest.c:27: error: 'NULL' undeclared (first use in this function) conftest.c:27: error: (Each undeclared identifier is reported only once conftest.c:27: error: for each function it appears in.) configure:13432: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | #include | int | main () | { | CFPreferencesCopyAppValue(NULL, NULL) | ; | return 0; | } configure:13441: result: no configure:13448: checking for CFLocaleCopyCurrent configure:13466: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c -Wl,-framework -Wl,CoreFoundation >&5 conftest.c:23:37: error: CoreFoundation/CFLocale.h: No such file or directory configure:13466: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "p11-kit" | #define PACKAGE_TARNAME "p11-kit" | #define PACKAGE_VERSION "0.8" | #define PACKAGE_STRING "p11-kit 0.8" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" | #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" | #define PACKAGE "p11-kit" | #define VERSION "0.8" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | #include | int | main () | { | CFLocaleCopyCurrent(); | ; | return 0; | } configure:13475: result: no configure:14344: checking whether to use NLS configure:14346: result: no configure:14471: checking for pkg-config configure:14489: found /usr/local/bin/pkg-config configure:14501: result: /usr/local/bin/pkg-config configure:14526: checking pkg-config is at least version 0.9.0 configure:14529: result: yes configure:14542: checking for gtkdoc-check configure:14575: result: no configure:14584: checking for gtkdoc-rebase configure:14617: result: no configure:14628: checking for gtkdoc-mkpdf configure:14661: result: no configure:14792: checking whether to build gtk-doc documentation configure:14794: result: no configure:14859: checking for win32 configure:14881: result: no configure:14896: checking for pthread_mutex_lock in -pthread configure:14921: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c -pthread >&5 configure:14921: $? = 0 configure:14930: result: yes configure:14943: checking for library containing dlopen configure:14974: cc -o conftest -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c -pthread >&5 configure:14974: $? = 0 configure:14991: result: none required configure:15001: checking for struct dirent.d_type configure:15001: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:15001: $? = 0 configure:15001: result: yes configure:15014: checking err.h usability configure:15014: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing conftest.c >&5 configure:15014: $? = 0 configure:15014: result: yes configure:15014: checking err.h presence configure:15014: cpp conftest.c configure:15014: $? = 0 configure:15014: result: yes configure:15014: checking for err.h configure:15014: result: yes configure:15067: checking for debug mode configure:15103: result: default (-g, debug output) configure:15106: checking for more warnings configure:15118: checking whether gcc understands -Wmissing-include-dirs configure:15131: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -g -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wdeclaration-after-statement -Wformat=2 -Winit-self -Waggregate-return -Wno-missing-format-attribute -Wmissing-include-dirs conftest.c >&5 conftest.c:32: warning: function declaration isn't a prototype configure:15131: $? = 0 configure:15137: result: yes configure:15118: checking whether gcc understands -Wundef configure:15131: cc -c -O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -g -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wdeclaration-after-statement -Wformat=2 -Winit-self -Waggregate-return -Wno-missing-format-attribute -Wmissing-include-dirs -Wundef conftest.c >&5 conftest.c:32: warning: function declaration isn't a prototype configure:15131: $? = 0 configure:15137: result: yes configure:15154: checking build strict configure:15169: result: no configure:15172: checking whether to build with gcov testing configure:15182: result: no configure:15514: creating ./config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by p11-kit config.status 0.8, which was generated by GNU Autoconf 2.68. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status on otaku config.status:1165: creating Makefile config.status:1165: creating doc/Makefile config.status:1165: creating doc/version.xml config.status:1165: creating po/Makefile.in config.status:1165: creating p11-kit/Makefile config.status:1165: creating p11-kit/p11-kit-1.pc config.status:1165: creating p11-kit/pkcs11.conf.example config.status:1165: creating tests/Makefile config.status:1165: creating tools/Makefile config.status:1165: creating config.h config.status:1394: executing depfiles commands config.status:1394: executing libtool commands config.status:1394: executing po-directories commands configure:17884: build options: Host: amd64-portbld-freebsd9.9 Debug build: default (-g, debug output) Strict build: no System global config: ${prefix}/etc/pkcs11/pkcs11.conf System module config directory: ${prefix}/etc/pkcs11/modules User global config: ~/.pkcs11/pkcs11.conf User module config directory: ~/.pkcs11/modules Load relative module paths from: ${exec_prefix}/lib/pkcs11 ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=amd64-portbld-freebsd9.9 ac_cv_c_compiler_gnu=yes ac_cv_env_CC_set=set ac_cv_env_CC_value=cc ac_cv_env_CFLAGS_set=set ac_cv_env_CFLAGS_value='-O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing' ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value='' ac_cv_env_CPP_set=set ac_cv_env_CPP_value=cpp ac_cv_env_GTKDOC_DEPS_CFLAGS_set='' ac_cv_env_GTKDOC_DEPS_CFLAGS_value='' ac_cv_env_GTKDOC_DEPS_LIBS_set='' ac_cv_env_GTKDOC_DEPS_LIBS_value='' ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value='' ac_cv_env_LIBS_set='' ac_cv_env_LIBS_value='' ac_cv_env_PKG_CONFIG_LIBDIR_set='' ac_cv_env_PKG_CONFIG_LIBDIR_value='' ac_cv_env_PKG_CONFIG_PATH_set='' ac_cv_env_PKG_CONFIG_PATH_value='' ac_cv_env_PKG_CONFIG_set='' ac_cv_env_PKG_CONFIG_value='' ac_cv_env_build_alias_set=set ac_cv_env_build_alias_value=amd64-portbld-freebsd9.9 ac_cv_env_host_alias_set='' ac_cv_env_host_alias_value='' ac_cv_env_target_alias_set='' ac_cv_env_target_alias_value='' ac_cv_func_dlopen=yes ac_cv_func_shl_load=no ac_cv_header_dlfcn_h=yes ac_cv_header_err_h=yes ac_cv_header_inttypes_h=yes ac_cv_header_memory_h=yes ac_cv_header_stdc=yes ac_cv_header_stdint_h=yes ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_host=amd64-portbld-freebsd9.9 ac_cv_lib_dld_shl_load=no ac_cv_lib_pthread_pthread_mutex_lock=yes ac_cv_member_struct_dirent_d_type=yes ac_cv_objext=o ac_cv_path_DOLT_BASH='' ac_cv_path_EGREP='/usr/bin/grep -E' ac_cv_path_FGREP='/usr/bin/grep -F' ac_cv_path_GMSGFMT=/usr/local/bin/msgfmt ac_cv_path_GREP=/usr/bin/grep ac_cv_path_MSGFMT=/usr/local/bin/msgfmt ac_cv_path_MSGMERGE=/usr/local/bin/msgmerge ac_cv_path_SED=/usr/bin/sed ac_cv_path_XGETTEXT=/usr/local/bin/xgettext ac_cv_path_ac_pt_PKG_CONFIG=/usr/local/bin/pkg-config ac_cv_prog_AWK=nawk ac_cv_prog_CPP=cpp ac_cv_prog_ac_ct_AR=ar ac_cv_prog_ac_ct_CC=cc ac_cv_prog_ac_ct_MANIFEST_TOOL=mt ac_cv_prog_ac_ct_OBJDUMP=objdump ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_ac_ct_STRIP=strip ac_cv_prog_cc_c89='' ac_cv_prog_cc_cc_c_o=yes ac_cv_prog_cc_g=yes ac_cv_prog_make_make_set=yes ac_cv_search_dlopen='none required' acl_cv_hardcode_direct=no acl_cv_hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir' acl_cv_hardcode_libdir_separator='' acl_cv_hardcode_minus_L=no acl_cv_libext=a acl_cv_libname_spec='lib$name' acl_cv_library_names_spec='$libname$shrext' acl_cv_path_LD=/usr/bin/ld acl_cv_prog_gnu_ld=yes acl_cv_rpath=done acl_cv_shlibext=so acl_cv_wl=-Wl, am_cv_CC_dependencies_compiler_type=gcc3 gt_cv_func_CFLocaleCopyCurrent=no gt_cv_func_CFPreferencesCopyAppValue=no lt_cv_ar_at_file=no lt_cv_archive_cmds_need_lc=no lt_cv_deplibs_check_method=pass_all lt_cv_dlopen=dlopen lt_cv_dlopen_libs='' lt_cv_dlopen_self=yes lt_cv_dlopen_self_static=no lt_cv_file_magic_cmd='$MAGIC_CMD' lt_cv_file_magic_test_file='' lt_cv_ld_reload_flag=-r lt_cv_nm_interface='BSD nm' lt_cv_objdir=.libs lt_cv_path_LD=/usr/bin/ld lt_cv_path_NM='/usr/bin/nm -B' lt_cv_path_mainfest_tool=no lt_cv_prog_compiler_c_o=yes lt_cv_prog_compiler_pic='-fPIC -DPIC' lt_cv_prog_compiler_pic_works=yes lt_cv_prog_compiler_rtti_exceptions=no lt_cv_prog_compiler_static_works=yes lt_cv_prog_gnu_ld=yes lt_cv_sharedlib_from_linklib_cmd='printf %s\n' lt_cv_sys_global_symbol_pipe='sed -n -e '\''s/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\'' | sed '\''/ __gnu_lto/d'\' lt_cv_sys_global_symbol_to_c_name_address='sed -n -e '\''s/^: \([^ ]*\)[ ]*$/ {\"\1\", (void *) 0},/p'\'' -e '\''s/^[ABCDGIRSTW]* \([^ ]*\) \([^ ]*\)$/ {"\2", (void *) \&\2},/p'\' lt_cv_sys_global_symbol_to_c_name_address_lib_prefix='sed -n -e '\''s/^: \([^ ]*\)[ ]*$/ {\"\1\", (void *) 0},/p'\'' -e '\''s/^[ABCDGIRSTW]* \([^ ]*\) \(lib[^ ]*\)$/ {"\2", (void *) \&\2},/p'\'' -e '\''s/^[ABCDGIRSTW]* \([^ ]*\) \([^ ]*\)$/ {"lib\2", (void *) \&\2},/p'\' lt_cv_sys_global_symbol_to_cdecl='sed -n -e '\''s/^T .* \(.*\)$/extern int \1();/p'\'' -e '\''s/^[ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p'\' lt_cv_sys_max_cmd_len=262144 lt_cv_to_host_file_cmd=func_convert_file_noop lt_cv_to_tool_file_cmd=func_convert_file_noop ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run aclocal-1.11' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE='' AMTAR='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run tar' AM_BACKSLASH='\' AM_DEFAULT_VERBOSITY='0' AR='ar' AUTOCONF='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run autoconf' AUTOHEADER='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run autoheader' AUTOMAKE='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run automake-1.11' AWK='nawk' CC='cc' CCDEPMODE='depmode=gcc3' CFLAGS='-O2 -pipe -frename-registers -march=core2 -fno-strict-aliasing -g -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wdeclaration-after-statement -Wformat=2 -Winit-self -Waggregate-return -Wno-missing-format-attribute -Wmissing-include-dirs -Wundef' CPP='cpp' CPPFLAGS='' CYGPATH_W='echo' DEFS='-DHAVE_CONFIG_H' DEPDIR='.deps' DLLTOOL='false' DSYMUTIL='' DUMPBIN='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='/usr/bin/grep -E' ENABLE_GTK_DOC_FALSE='' ENABLE_GTK_DOC_TRUE='#' EXEEXT='' FGREP='/usr/bin/grep -F' GCOV='' GENHTML='' GETTEXT_MACRO_VERSION='0.18' GMSGFMT='/usr/local/bin/msgfmt' GMSGFMT_015='/usr/local/bin/msgfmt' GREP='/usr/bin/grep' GTKDOC_CHECK='' GTKDOC_DEPS_CFLAGS='' GTKDOC_DEPS_LIBS='' GTKDOC_MKPDF='' GTKDOC_REBASE='true' GTK_DOC_BUILD_HTML_FALSE='#' GTK_DOC_BUILD_HTML_TRUE='' GTK_DOC_BUILD_PDF_FALSE='' GTK_DOC_BUILD_PDF_TRUE='#' GTK_DOC_USE_LIBTOOL_FALSE='#' GTK_DOC_USE_LIBTOOL_TRUE='' GTK_DOC_USE_REBASE_FALSE='#' GTK_DOC_USE_REBASE_TRUE='' HTML_DIR='${datadir}/gtk-doc/html' INSTALL_DATA='install -o root -g wheel -m 444' INSTALL_PROGRAM='install -s -o root -g wheel -m 555' INSTALL_SCRIPT='install -o root -g wheel -m 555' INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' INTLLIBS='' INTL_MACOSX_LIBS='' LCOV='' LD='/usr/bin/ld' LDFLAGS='' LIBICONV='/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib' LIBINTL='' LIBOBJS='' LIBS='-pthread ' LIBTOOL='$(SHELL) /usr/ports/security/p11-kit/work/gnome-libtool' LIPO='' LN_S='ln -s' LTLIBICONV='-L/usr/local/lib -liconv -R/usr/local/lib' LTLIBINTL='' LTLIBOBJS='' MAINT='' MAINTAINER_MODE_FALSE='#' MAINTAINER_MODE_TRUE='' MAKEINFO='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/missing --run makeinfo' MANIFEST_TOOL=':' MKDIR_P='./install-sh -c -d' MSGFMT='/usr/local/bin/msgfmt' MSGFMT_015='/usr/local/bin/msgfmt' MSGMERGE='/usr/local/bin/msgmerge' NM='/usr/bin/nm -B' NMEDIT='' OBJDUMP='objdump' OBJEXT='o' OS_WIN32_FALSE='' OS_WIN32_TRUE='#' OTOOL64='' OTOOL='' P11KIT_LT_RELEASE='0:0:0' PACKAGE='p11-kit' PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue' PACKAGE_NAME='p11-kit' PACKAGE_STRING='p11-kit 0.8' PACKAGE_TARNAME='p11-kit' PACKAGE_URL='http://p11-glue.freedesktop.org/p11-kit.html' PACKAGE_VERSION='0.8' PATH_SEPARATOR=':' PKG_CONFIG='/usr/local/bin/pkg-config' PKG_CONFIG_LIBDIR='' PKG_CONFIG_PATH='' POSUB='' RANLIB='ranlib' SED='/usr/bin/sed' SET_MAKE='' SHELL='/bin/sh' STRIP='strip' USE_NLS='no' VERSION='0.8' WITH_COVERAGE_FALSE='' WITH_COVERAGE_TRUE='#' XGETTEXT='/usr/local/bin/xgettext' XGETTEXT_015='/usr/local/bin/xgettext' XGETTEXT_EXTRA_OPTIONS='' ac_ct_AR='ar' ac_ct_CC='cc' ac_ct_DUMPBIN='' am__EXEEXT_FALSE='' am__EXEEXT_TRUE='#' am__fastdepCC_FALSE='#' am__fastdepCC_TRUE='' am__include='include' am__isrc='' am__leading_dot='.' am__quote='' am__tar='${AMTAR} chof - "$$tardir"' am__untar='${AMTAR} xf -' bindir='${exec_prefix}/bin' build='amd64-portbld-freebsd9.9' build_alias='amd64-portbld-freebsd9.9' build_cpu='amd64' build_os='freebsd9.9' build_vendor='portbld' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='${prefix}' host='amd64-portbld-freebsd9.9' host_alias='' host_cpu='amd64' host_os='freebsd9.9' host_vendor='portbld' htmldir='${docdir}' includedir='${prefix}/include' infodir='/usr/local/info' install_sh='${SHELL} /usr/ports/security/p11-kit/work/p11-kit-0.8/install-sh' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='/usr/local/man' mkdir_p='$(top_builddir)/./install-sh -c -d' oldincludedir='/usr/include' p11_module_path='${exec_prefix}/lib/pkcs11' p11_system_config='${prefix}/etc/pkcs11' p11_system_config_file='${prefix}/etc/pkcs11/pkcs11.conf' p11_system_config_modules='${prefix}/etc/pkcs11/modules' p11_user_config='~/.pkcs11' p11_user_config_file='~/.pkcs11/pkcs11.conf' p11_user_config_modules='~/.pkcs11/modules' pdfdir='${docdir}' prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "p11-kit" #define PACKAGE_TARNAME "p11-kit" #define PACKAGE_VERSION "0.8" #define PACKAGE_STRING "p11-kit 0.8" #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue" #define PACKAGE_URL "http://p11-glue.freedesktop.org/p11-kit.html" #define PACKAGE "p11-kit" #define VERSION "0.8" #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_DLFCN_H 1 #define LT_OBJDIR ".libs/" #define OS_UNIX 1 #define HAVE_LIBPTHREAD 1 #define HAVE_STRUCT_DIRENT_D_TYPE 1 #define HAVE_ERR_H 1 #define WITH_DEBUG 1 #define _DEBUG 1 configure: exit 0 --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 16:46:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5CC1065673; Thu, 3 Nov 2011 16:46:11 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76DFD8FC15; Thu, 3 Nov 2011 16:46:10 +0000 (UTC) Received: by wyg36 with SMTP id 36so1958799wyg.13 for ; Thu, 03 Nov 2011 09:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HDy871jlL4CWiemC3ZlSsL5rK9m2C89LoYPTMnky7lw=; b=uZomNETizKX332VxgvV5QhMESV/XSgzad4KydMKqSbdngKMpxXDe7UvasMSTvnpUzn h0QWbR8lgA4me9gAeFnn6u9m+XfSAWyRyKvIbS4ZVfXeB66+aaGYHJ8lasBNcxcAyaFe czMbwyIHhnUyVhS6sc7cjh7b7oZVU7F6idBms= MIME-Version: 1.0 Received: by 10.227.198.77 with SMTP id en13mr12776046wbb.28.1320338700819; Thu, 03 Nov 2011 09:45:00 -0700 (PDT) Received: by 10.180.94.106 with HTTP; Thu, 3 Nov 2011 09:45:00 -0700 (PDT) In-Reply-To: References: <4EAF18B2.9040909@FreeBSD.org> <4EAF6442.5020901@FreeBSD.org> Date: Thu, 3 Nov 2011 12:45:00 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:46:11 -0000 Hi, On Thu, Nov 3, 2011 at 3:44 AM, Adrian Chadd wrote: > On 31 October 2011 20:15, Doug Barton wrote: > >>> In any case, I do want to merge the ath 11n stuff into -9, so even if >>> it's not done by 9.0, it'll be done shortly after. >> >> Given that RC1 is already out, you should probably check with re@ first. > > I'll poke them tomorrow, but since others have merged in driver > changes and other stuff into -HEAD, I wouldn't be the first person to > merge in bigger things. > Maybe not the place to ask, but why are you (ie. FreeBSD folks) unable to unleash commit to `trunk' and let only required MFC go to `stable/9' ? - Arnaud From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 16:49:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A5D106566C; Thu, 3 Nov 2011 16:49:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA2A8FC19; Thu, 3 Nov 2011 16:49:01 +0000 (UTC) Received: by vws11 with SMTP id 11so2018345vws.13 for ; Thu, 03 Nov 2011 09:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Sxf4EevLZFOrlY8EKM6neIobBnkdqQh2xRUGyw0lyJQ=; b=he/ORG+yn8DA88B7KBV8rEYOgoVZHXeh+Ecgp6hF9FUeOIl+wN4eKttZAEnMg0RLC7 AQorLuoWiU8o/s8K3pmNvu+NP3jLTiSeI2Vah5pDDDIvH1HFo7viZqKdxWq7dbTsuNGx OjeoyDO1Nyr+bZz8RK8JBGeuLpb5K4Dq8M40U= MIME-Version: 1.0 Received: by 10.52.24.102 with SMTP id t6mr10353618vdf.106.1320338940524; Thu, 03 Nov 2011 09:49:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 3 Nov 2011 09:49:00 -0700 (PDT) In-Reply-To: References: <4EAF18B2.9040909@FreeBSD.org> <4EAF6442.5020901@FreeBSD.org> Date: Thu, 3 Nov 2011 09:49:00 -0700 X-Google-Sender-Auth: kQueMHSs4yc5gszqaFQP-ME8_XA Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , freebsd-wireless@freebsd.org, freebsd-current Subject: Re: request: merging if_ath_tx branch to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:49:01 -0000 On 3 November 2011 09:45, Arnaud Lacombe wrote: > Maybe not the place to ask, but why are you (ie. FreeBSD folks) unable > to unleash commit to `trunk' and let only required MFC go to > `stable/9' ? Hi, We "can". It's just that we're being "nice" to keep the diffs between -HEAD and stable/9 low to keep things easier for release engineering. But it's taking a while and I really want to push this 11n stuff into -HEAD so I can continue active development in a way that users can actively test it. :) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 17:51:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CF6106566C; Thu, 3 Nov 2011 17:51:14 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id BA46F8FC08; Thu, 3 Nov 2011 17:51:13 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id AF9C9291AA7; Thu, 3 Nov 2011 12:51:12 -0500 (CDT) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 9E191297603; Thu, 3 Nov 2011 12:51:12 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id VvTsGICp0T6z; Thu, 3 Nov 2011 12:51:12 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id D152D291AA7; Thu, 3 Nov 2011 12:51:11 -0500 (CDT) Message-ID: <4EB2D48E.1030102@rice.edu> Date: Thu, 03 Nov 2011 12:51:10 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111103132437.GV50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:51:14 -0000 On 11/03/2011 08:24, Kostik Belousov wrote: > On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote: >> On 11/02/2011 05:32, Andriy Gapon wrote: >>> [restored cc: to the original poster] >>> As Bruce Evans has pointed to me privately [I am not sure why privately], >>> there >>> is already an example in i386 and amd64 atomic.h, where operations are >>> inlined >>> for a kernel build, but presented as real (external) functions for a module >>> build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. >>> >>> I think that the same treatment could/should be applied to vm_page_*lock* >>> operations defined in sys/vm/vm_page.h. >> *snip* >> >> Yes, it should be. There are without question legitimate reasons for a >> module to acquire a page lock. > I agree. Also, I think that we should use the opportunity to also isolate > the modules from the struct vm_page layout changes. As example, I converted > nfsclient.ko. > I would suggest introducing the vm_page_bits_t change first. If, at the same time, you change the return type from the function vm_page_bits() to use vm_page_bits_t, then I believe it is straightforward to fix all of the places in vm_page.c that don't properly handle a 32 KB page size. Alan > Patch is not tested. > > diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c > index 305c189..7264cd1 100644 > --- a/sys/nfsclient/nfs_bio.c > +++ b/sys/nfsclient/nfs_bio.c > @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) > * can only occur at the file EOF. > */ > VM_OBJECT_LOCK(object); > - if (pages[ap->a_reqpage]->valid != 0) { > + if (vm_page_read_valid(pages[ap->a_reqpage]) != 0) { > for (i = 0; i< npages; ++i) { > if (i != ap->a_reqpage) { > vm_page_lock(pages[i]); > @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) > /* > * Read operation filled an entire page > */ > - m->valid = VM_PAGE_BITS_ALL; > - KASSERT(m->dirty == 0, > + vm_page_write_valid(m, VM_PAGE_BITS_ALL); > + KASSERT(vm_page_read_dirty(m) == 0, > ("nfs_getpages: page %p is dirty", m)); > } else if (size> toff) { > /* > * Read operation filled a partial page. > */ > - m->valid = 0; > + vm_page_write_valid(m, 0); > vm_page_set_valid(m, 0, size - toff); > - KASSERT(m->dirty == 0, > + KASSERT(vm_page_read_dirty(m) == 0, > ("nfs_getpages: page %p is dirty", m)); > } else { > /* > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index f14da4a..5b8b4e3 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) > vm_page_dirty(m); > } > > +void > +vm_page_lock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG> 0 || defined(MUTEX_NOINLINE) > + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + __mtx_lock(vm_page_lockptr(m), 0, file, line); > +#endif > +} > + > +void > +vm_page_unlock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG> 0 || defined(MUTEX_NOINLINE) > + _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); > +#endif > +} > + > +int > +vm_page_trylock_func(vm_page_t m, const char *file, int line) > +{ > + > + return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > +} > + > +void > +vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line) > +{ > + > +#ifdef INVARIANTS > + _mtx_assert(vm_page_lockptr(m), a, file, line); > +#endif > +} > + > +vm_page_bits_t > +vm_page_read_dirty_func(vm_page_t m) > +{ > + > + return (m->dirty); > +} > + > +vm_page_bits_t > +vm_page_read_valid_func(vm_page_t m) > +{ > + > + return (m->valid); > +} > + > +void > +vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v) > +{ > + > + m->valid = v; > +} > + > + > int so_zerocp_fullpage = 0; > > /* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 23637bb..618ba2b 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -113,6 +113,21 @@ > > TAILQ_HEAD(pglist, vm_page); > > +#if PAGE_SIZE == 4096 > +#define VM_PAGE_BITS_ALL 0xffu > +typedef uint8_t vm_page_bits_t; > +#elif PAGE_SIZE == 8192 > +#define VM_PAGE_BITS_ALL 0xffffu > +typedef uint16_t vm_page_bits_t; > +#elif PAGE_SIZE == 16384 > +#define VM_PAGE_BITS_ALL 0xffffffffu > +typedef uint32_t vm_page_bits_t; > +#elif PAGE_SIZE == 32768 > +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu > +typedef uint64_t vm_page_bits_t; > +#endif > + > + > struct vm_page { > TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q) */ > TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ > @@ -138,19 +153,8 @@ struct vm_page { > /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ > /* so, on normal X86 kernels, they must be at least 8 bits wide */ > /* In reality, support for 32KB pages is not fully implemented. */ > -#if PAGE_SIZE == 4096 > - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 8192 > - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 16384 > - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 32768 > - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#endif > + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ > + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > }; > > /* > @@ -216,12 +220,50 @@ extern struct vpglocks pa_lock[]; > > #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a)) > > +#ifdef KLD_MODULE > +#define vm_page_lock(m) vm_page_lock_func((m), LOCK_FILE, LOCK_LINE) > +#define vm_page_unlock(m) vm_page_unlock_func((m), LOCK_FILE, LOCK_LINE) > +#define vm_page_trylock(m) vm_page_trylock_func((m), LOCK_FILE, LOCK_LINE) > +#ifdef INVARIANTS > +#define vm_page_lock_assert(m, a) \ > + vm_page_lock_assert_func((m), (a), LOCK_FILE, LOCK_LINE) > +#else > +#define vm_page_lock_assert(m, a) > +#endif > + > +#define vm_page_read_dirty(m) vm_page_read_dirty_func((m)) > +#define vm_page_read_valid(m) vm_page_read_valid_func((m)) > +#define vm_page_write_valid(m, v) vm_page_write_valid_func((m), (v)) > + > +#else /* KLD_MODULE */ > #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m)))) > #define vm_page_lock(m) mtx_lock(vm_page_lockptr((m))) > #define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m))) > #define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m))) > #define vm_page_lock_assert(m, a) mtx_assert(vm_page_lockptr((m)), (a)) > > +static inline vm_page_bits_t > +vm_page_read_dirty(vm_page_t m) > +{ > + > + return (m->dirty); > +} > + > +static inline vm_page_bits_t > +vm_page_read_valid(vm_page_t m) > +{ > + > + return (m->valid); > +} > + > +static inline void > +vm_page_write_valid(vm_page_t m, vm_page_bits_t v) > +{ > + > + m->valid = v; > +} > +#endif > + > #define vm_page_queue_free_mtx vm_page_queue_free_lock.data > /* > * These are the flags defined for vm_page. > @@ -322,16 +364,6 @@ extern struct vpglocks vm_page_queue_lock; > #define vm_page_lock_queues() mtx_lock(&vm_page_queue_mtx) > #define vm_page_unlock_queues() mtx_unlock(&vm_page_queue_mtx) > > -#if PAGE_SIZE == 4096 > -#define VM_PAGE_BITS_ALL 0xffu > -#elif PAGE_SIZE == 8192 > -#define VM_PAGE_BITS_ALL 0xffffu > -#elif PAGE_SIZE == 16384 > -#define VM_PAGE_BITS_ALL 0xffffffffu > -#elif PAGE_SIZE == 32768 > -#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu > -#endif > - > /* page allocation classes: */ > #define VM_ALLOC_NORMAL 0 > #define VM_ALLOC_INTERRUPT 1 > @@ -411,6 +443,15 @@ void vm_page_cowfault (vm_page_t); > int vm_page_cowsetup(vm_page_t); > void vm_page_cowclear (vm_page_t); > > +void vm_page_lock_func(vm_page_t m, const char *file, int line); > +void vm_page_unlock_func(vm_page_t m, const char *file, int line); > +int vm_page_trylock_func(vm_page_t m, const char *file, int line); > +void vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line); > + > +vm_page_bits_t vm_page_read_dirty_func(vm_page_t m); > +vm_page_bits_t vm_page_read_valid_func(vm_page_t m); > +void vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v); > + > #ifdef INVARIANTS > void vm_page_object_lock_assert(vm_page_t m); > #define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m) From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 18:12:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5382B1065673 for ; Thu, 3 Nov 2011 18:12:23 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2C8F8FC1C for ; Thu, 3 Nov 2011 18:12:22 +0000 (UTC) Received: by wyg36 with SMTP id 36so2077868wyg.13 for ; Thu, 03 Nov 2011 11:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=92E3TWfgZawLeAio4VJtTicljPvX7+7vHofrhjP41R8=; b=x0aa2M1M8oftpB6yR1FkqczGcpd/5dZd4E2acXHXKppEW8yJfVSh0IZx7cPVuiBKQh lTkIp+IFSiDljg0pAwLbMQhHp0ctyesYgf7Ml8G3BpHRxmepke0B1ROqhhB2Rc/DBzUb ET+ydRua+322fd0OnIfN/OTGfSjxbv/yPmTjU= MIME-Version: 1.0 Received: by 10.227.206.147 with SMTP id fu19mr13360004wbb.22.1320342170073; Thu, 03 Nov 2011 10:42:50 -0700 (PDT) Received: by 10.180.98.5 with HTTP; Thu, 3 Nov 2011 10:42:50 -0700 (PDT) Date: Thu, 3 Nov 2011 13:42:50 -0400 Message-ID: From: "b. f." To: freebsd-ports@FreeBSD.org, freebsd-current@FreeBSD.org, Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:12:23 -0000 > > > It turns out that the problem is more general! A lot of ./configure > > > scripts are detecting in 10-CUR that they can't or should not build > > > shared libs; the problem is that the OS is detected now as > > > > As a temporary workaround, add "WITH_FBSD10_FIX=1" to /etc/make.conf. > > ports/UPDATING and some of the mails in the archive of -current > recommend setting UNAME_r=9.0-CURRENT; is this the same or which method > is prefered? No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. b. From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 18:45:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55845106566C for ; Thu, 3 Nov 2011 18:45:30 +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 A70D18FC1B for ; Thu, 3 Nov 2011 18:45:29 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 198563699; Thu, 03 Nov 2011 19:45:26 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 3 Nov 2011 19:42:30 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EB1602C.6030807@janh.de> <4EB27225.4020504@janh.de> <4EB2895B.3080104@janh.de> In-Reply-To: <4EB2895B.3080104@janh.de> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111031942.30498.hselasky@c2i.net> Cc: Jan Henrik Sylvester Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:45:30 -0000 On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: > On 11/03/2011 11:51, Jan Henrik Sylvester wrote: > > On 11/03/2011 09:27, Hans Petter Selasky wrote: > >> On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: > >>> I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect > >>> an USB3 hard disk to my Thinkpad T510, which only has USB2. > >>> > >>> Trying to hot plug the express card did nothing, but I guess that is > >>> expected. Hence, I booted with the express card already inserted, only > >>> to receive a panic upon xhci0 initialization, see below. > >>> > >>> This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from > >>> the official DVD. > >>> > >>> I guess I could test 226803 mentioned in > >>> http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html > >>> , which happened after RC1, but from the commit message, it only fixes > >>> suspend and resume. > >>> > >>> As I do not have much time now, should I test 226803, find a Linux CD > >>> to actually identify the device, or anything else? > >>> > >>> Cheers, > >>> Jan Henrik > >>> > >>> > >>> usbus0: 480 Mbps High Speed USB v2.0 > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 0; apic id = 00 > >>> fault virtual address = 0x18 > >>> fault code = supervisor write data, page not present > >>> instruction ponter = 0x20:0xffffffff806e80aa > >>> stack pointer = 0x28:0xffffff810ee50bc0 > >>> frame pointer = 0x28:0xffffff810ee50bf0 > >>> code segment = base 0x0, limit 0xfffff, type 0x16 > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>> current process = 15 (xhci0) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 0 > >>> Uptime = 1s > >>> Automatic reboot in 15 seconds - press a key on the console to abort > >> > >> Hi, > >> > >> This looks like a NULL-pointer issue inside "xhci_configure_msg()" which > >> probably should be easy to fix. > >> > >> Could you compile and boot a kernel with kernel debugging enable so > >> that you > >> get a backgtrace? > > > > I have not done this before. > > > > The GENERIC kernel already contains "makeoptions DEBUG=-g" (at least it > > is in /usr/src/sys/amd64/conf/GENERIC and there are all this large > > /boot/kernel/*.symbols). Is there anything else needed? (I do not need > > all the stuff that Ken Smith took out just before RC1 in r226405 just to > > get a trace, since I do not want to do online debugging, or do I need it > > anyhow?) > > > > From > > > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > , I thought that setting dumpdev="AUTO" in /etc/rc.conf was enough to > > get a dump in /var/crash/ after the next boot to multiuser. That does > > not seem to be the case for me. What else do I have to do? > > After reading a bit more, I still do not know why I do not get a crash > dump with dumpdev="AUTO" (and /var/crash/ having enough space for a full > memory dump). Is it too early during boot for dumpon to be set? > > After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found > that ffffffff806e8040 t usb_process is the last symbol before > instruction pointer = 0x20:0xffffffff806e80aa. Does this help? Try add: options KDB # Enable kernel debugger support. options DDB # Support DDB. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 20:07:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72957106564A for ; Thu, 3 Nov 2011 20:07:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id F37458FC0A for ; Thu, 3 Nov 2011 20:07:22 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 201105522; Thu, 03 Nov 2011 21:07:18 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 3 Nov 2011 21:04:23 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EB1602C.6030807@janh.de> <4EB2895B.3080104@janh.de> <201111031942.30498.hselasky@c2i.net> In-Reply-To: <201111031942.30498.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111032104.23332.hselasky@c2i.net> Cc: Jan Henrik Sylvester Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:07:23 -0000 On Thursday 03 November 2011 19:42:30 Hans Petter Selasky wrote: > On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: > > After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found > > that ffffffff806e8040 t usb_process is the last symbol before > > instruction pointer = 0x20:0xffffffff806e80aa. Does this help? > > Try add: > > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > Hi, Looks like it panics at: mtx_lock(up->up_mtx); In "usb_process()" which is created by the "xhci0" instance. I would really like to see a dump of "up" and "up_mtx" because I cannot see how this can happen. Have you seen any USB errors in the dmesg up to the point of this panic? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 20:09:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CCD1065670 for ; Thu, 3 Nov 2011 20:09:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 9013B8FC1D for ; Thu, 3 Nov 2011 20:09:17 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 197443195; Thu, 03 Nov 2011 21:09:15 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 3 Nov 2011 21:06:20 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EB1602C.6030807@janh.de> <201111031942.30498.hselasky@c2i.net> <201111032104.23332.hselasky@c2i.net> In-Reply-To: <201111032104.23332.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111032106.20278.hselasky@c2i.net> Cc: Jan Henrik Sylvester Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:09:18 -0000 On Thursday 03 November 2011 21:04:23 Hans Petter Selasky wrote: > On Thursday 03 November 2011 19:42:30 Hans Petter Selasky wrote: > > On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: > > > After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I > > > found that ffffffff806e8040 t usb_process is the last symbol before > > > instruction pointer = 0x20:0xffffffff806e80aa. Does this help? > > > > Try add: > > > > options KDB # Enable kernel debugger support. > > options DDB # Support DDB. > > Hi, > > Looks like it panics at: > > mtx_lock(up->up_mtx); > > In "usb_process()" which is created by the "xhci0" instance. > > I would really like to see a dump of "up" and "up_mtx" because I cannot see > how this can happen. > > Have you seen any USB errors in the dmesg up to the point of this panic? > > --HPS Here is a snippet of assembly code: ffffffff806e808b: 48 8b 13 mov (%rbx),%rdx ffffffff806e808e: 83 6a 0c 01 subl $0x1,0xc(%rdx) ffffffff806e8092: e8 19 4e 42 00 callq ffffffff80b0ceb0 ffffffff806e8097: 65 48 8b 34 25 00 00 mov %gs:0x0,%rsi ffffffff806e809e: 00 00 ffffffff806e80a0: 49 8b 7c 24 40 mov 0x40(%r12),%rdi ffffffff806e80a5: b8 04 00 00 00 mov $0x4,%eax ffffffff806e80aa: f0 48 0f b1 77 18 lock cmpxchg %rsi,0x18(%rdi) ^^^^^ fault line ffffffff806e80b0: 0f 94 c0 sete %al ffffffff806e80b3: 84 c0 test %al,%al ffffffff806e80b5: 0f 84 5f 01 00 00 je ffffffff806e821a ffffffff806e80bb: 4d 8d 6c 24 10 lea 0x10(%r12),%r13 ffffffff806e80c0: 4d 8d 74 24 20 lea 0x20(%r12),%r14 ffffffff806e80c5: 49 89 5c 24 38 mov %rbx,0x38(%r12) --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 20:14:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E791610657A4 for ; Thu, 3 Nov 2011 20:14:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5208FC21 for ; Thu, 3 Nov 2011 20:14:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 200147385; Thu, 03 Nov 2011 21:14:14 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 3 Nov 2011 21:11:18 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EB1602C.6030807@janh.de> <4EB27225.4020504@janh.de> <4EB2895B.3080104@janh.de> In-Reply-To: <4EB2895B.3080104@janh.de> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111032111.18806.hselasky@c2i.net> Cc: Jan Henrik Sylvester Subject: Re: USB3 express card panics on 9.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:14:17 -0000 On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: > On 11/03/2011 11:51, Jan Henrik Sylvester wrote: > > On 11/03/2011 09:27, Hans Petter Selasky wrote: > >> On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: > >>> I have bought a "Super-speed Express Card To USB 3.0 1-Port" to connect > >>> an USB3 hard disk to my Thinkpad T510, which only has USB2. > >>> > >>> Trying to hot plug the express card did nothing, but I guess that is > >>> expected. Hence, I booted with the express card already inserted, only > >>> to receive a panic upon xhci0 initialization, see below. > >>> > >>> This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from > >>> the official DVD. > >>> > >>> I guess I could test 226803 mentioned in > >>> http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html > >>> , which happened after RC1, but from the commit message, it only fixes > >>> suspend and resume. > >>> > >>> As I do not have much time now, should I test 226803, find a Linux CD > >>> to actually identify the device, or anything else? > >>> > >>> Cheers, > >>> Jan Henrik > >>> > >>> > >>> usbus0: 480 Mbps High Speed USB v2.0 > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 0; apic id = 00 > >>> fault virtual address = 0x18 > >>> fault code = supervisor write data, page not present > >>> instruction ponter = 0x20:0xffffffff806e80aa > >>> stack pointer = 0x28:0xffffff810ee50bc0 > >>> frame pointer = 0x28:0xffffff810ee50bf0 > >>> code segment = base 0x0, limit 0xfffff, type 0x16 > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>> current process = 15 (xhci0) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 0 > >>> Uptime = 1s > >>> Automatic reboot in 15 seconds - press a key on the console to abort > >> > >> Hi, > >> > >> This looks like a NULL-pointer issue inside "xhci_configure_msg()" which > >> probably should be easy to fix. > >> > >> Could you compile and boot a kernel with kernel debugging enable so > >> that you > >> get a backgtrace? > > > > I have not done this before. > > > > The GENERIC kernel already contains "makeoptions DEBUG=-g" (at least it > > is in /usr/src/sys/amd64/conf/GENERIC and there are all this large > > /boot/kernel/*.symbols). Is there anything else needed? (I do not need > > all the stuff that Ken Smith took out just before RC1 in r226405 just to > > get a trace, since I do not want to do online debugging, or do I need it > > anyhow?) > > > > From > > > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > , I thought that setting dumpdev="AUTO" in /etc/rc.conf was enough to > > get a dump in /var/crash/ after the next boot to multiuser. That does > > not seem to be the case for me. What else do I have to do? > > After reading a bit more, I still do not know why I do not get a crash > dump with dumpdev="AUTO" (and /var/crash/ having enough space for a full > memory dump). Is it too early during boot for dumpon to be set? Try removing "device xhci" from the kernel config file and "kldload xhci" from the root prompt. Then I think you will get the kernel dump. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 20:28:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0F5106566B for ; Thu, 3 Nov 2011 20:28:57 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2308FC20 for ; Thu, 3 Nov 2011 20:28:56 +0000 (UTC) Received: by iabz21 with SMTP id z21so2821157iab.13 for ; Thu, 03 Nov 2011 13:28:56 -0700 (PDT) Received: by 10.42.149.71 with SMTP id u7mr10709407icv.37.1320351700465; Thu, 03 Nov 2011 13:21:40 -0700 (PDT) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id z10sm12267293ibv.9.2011.11.03.13.21.37 (version=SSLv3 cipher=OTHER); Thu, 03 Nov 2011 13:21:39 -0700 (PDT) Date: Thu, 3 Nov 2011 10:21:48 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ivan Klymenko In-Reply-To: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> Message-ID: References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:28:57 -0000 On Sat, 22 Oct 2011, Ivan Klymenko wrote: > Hello people! > > I have: > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz K8-class CPU) > FreeBSD 10.0-CURRENT r226607 amd64 > > For example during the building of the port lang/gcc46 in four streams (-j 4) with a heavy load on the processor - use the system was nearly impossible - responsiveness was terrible - the mouse cursor sometimes froze on the spot a few seconds... Am I right in understanding that you have only two cores? What else is running that achieves poor interactivity? What is the cpu utilization of your x server at this time? > > I managed to achieve a significant increase in the degree of interactivity ULE scheduler due to the following changes: This patch probably breaks nice, adaptive idling, and slows the interactivity computation. That being said I'm not sure why it helps you. It seems that there are increasing reports of bad interactivity creeping in to ULE over the last year. If people can help provide me with data I can look into this more. Thanks for your report. Jeff > ########################## > --- sched_ule.c.orig 2011-10-22 11:40:30.000000000 +0300 > +++ sched_ule.c 2011-10-22 12:25:05.000000000 +0300 > @@ -2119,6 +2119,14 @@ > > THREAD_LOCK_ASSERT(td, MA_OWNED); > tdq = TDQ_SELF(); > + if (td->td_pri_class & PRI_FIFO_BIT) > + return; > + ts = td->td_sched; > + /* > + * We used up one time slice. > + */ > + if (--ts->ts_slice > 0) > + return; > #ifdef SMP > /* > * We run the long term load balancer infrequently on the first cpu. > @@ -2144,9 +2152,6 @@ > if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx])) > tdq->tdq_ridx = tdq->tdq_idx; > } > - ts = td->td_sched; > - if (td->td_pri_class & PRI_FIFO_BIT) > - return; > if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) { > /* > * We used a tick; charge it to the thread so > @@ -2157,11 +2162,6 @@ > sched_priority(td); > } > /* > - * We used up one time slice. > - */ > - if (--ts->ts_slice > 0) > - return; > - /* > * We're out of time, force a requeue at userret(). > */ > ts->ts_slice = sched_slice; > ########################## > > What do you think about this? > > Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 20:43:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F021065670; Thu, 3 Nov 2011 20:43:46 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D05E8FC18; Thu, 3 Nov 2011 20:43:45 +0000 (UTC) Received: by gyd5 with SMTP id 5so1079243gyd.13 for ; Thu, 03 Nov 2011 13:43:45 -0700 (PDT) Received: by 10.42.168.202 with SMTP id x10mr6241270icy.4.1320351460146; Thu, 03 Nov 2011 13:17:40 -0700 (PDT) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id z10sm12237818ibv.9.2011.11.03.13.17.37 (version=SSLv3 cipher=OTHER); Thu, 03 Nov 2011 13:17:39 -0700 (PDT) Date: Thu, 3 Nov 2011 10:17:48 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andriy Gapon In-Reply-To: <4E720CB6.3070103@FreeBSD.org> Message-ID: References: <4E720CB6.3070103@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: couple of sched_ule issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:43:46 -0000 On Thu, 15 Sep 2011, Andriy Gapon wrote: > > This is more of a "just for the record" email. > I think I've already stated the following observations, but I suspect that they > drowned in the noise of a thread in which I mentioned them. > > 1. Incorrect topology is built for single-package SMP systems. > That topology has two levels ("shared nothing" and "shared package") with exactly > the same CPU sets. That doesn't work well with the rebalancing algorithm which > assumes that each level is a proper/strict subset of its parent. > > 2. CPU load comparison algorithms are biased towards lower logical CPU IDs. > With all other things being equal the algorithms will always pick a CPU with a > lower ID. This creates certain load asymmetry and predictable patterns in load > distribution. If all other things truly are equal why does selecting a lower cpu number matter? > > Another observation. > It seems that ULE makes a decision about thread-to-CPU affinity at the time when a > thread gets switched out. This looks logical from the implementation point of > view. But it doesn't seem logical from a general point of view - when the thread > will be becoming running again its affinity profile may become completely > different. I think that it would depend on how much a thread actually spends not > running. The decision is made at sched_add() time. sched_pickcpu() does the work and selects the run-queue we will be added to. We consider the CPU that the thread was last running on but the decision is made at the time that a run queue must be selected. Jeff > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 21:09:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C20D106566B for ; Thu, 3 Nov 2011 21:09:37 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id ABC498FC18 for ; Thu, 3 Nov 2011 21:09:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=vrMhpS/GYrR1HnpptlDMRR7AaA1xI1ay8awPu/0Uhoc=; b=ELnyv7KWK3SvP1F4qmwW1h70wI8h0GJKa0cwXWrj+jdHiAXv7Omb972tjV7zjxlf1vU9ivYuQHY24l2ti24vdSIvWbRpyXNfm6kFBruG6UOcgKf+bgf5ZmSCxIWhjeIYQ+ICdBN7WOdzUV6H+QL3u7hQFNb5ecIhVUEnjyqTf/M=; Received: from [81.23.24.116] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1RM4XT-000124-Jr ; Thu, 03 Nov 2011 23:09:34 +0200 Date: Thu, 3 Nov 2011 23:08:29 +0200 From: Ivan Klymenko To: Jeff Roberson Message-ID: <20111103230829.0d26579e@nonamehost.> In-Reply-To: References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/3p=06TSChVIs=2fxqfo=S/r" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:09:37 -0000 --MP_/3p=06TSChVIs=2fxqfo=S/r Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thank you for taking the time to answer me. =D0=92 Thu, 3 Nov 2011 10:21:48 -1000 (HST) Jeff Roberson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sat, 22 Oct 2011, Ivan Klymenko wrote: >=20 > > Hello people! > > > > I have: > > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz > > K8-class CPU) FreeBSD 10.0-CURRENT r226607 amd64 > > > > For example during the building of the port lang/gcc46 in four > > streams (-j 4) with a heavy load on the processor - use the system > > was nearly impossible - responsiveness was terrible - the mouse > > cursor sometimes froze on the spot a few seconds... >=20 > Am I right in understanding that you have only two cores? Yes. > What else is running that achieves poor interactivity? This is mainly a compilation with make option -j >=3D ncpu*2 And as an example - launching a large number of programs http://www.youtube.com/watch?v=3D1CLCp-dqWu0 This patch allows me to make do with ULE nearly as well as with FBFS Without the patch, somewhere in the middle of the time with ULE has been difficult to control the mouse cursor. > What is the cpu utilization of your x server at this time? ~2.00% - 20.00% WCPU time... But sometimes there are up to 79%... Upon unloading the CPU returns to normal... >=20 > > > > I managed to achieve a significant increase in the degree of > > interactivity ULE scheduler due to the following changes: >=20 > This patch probably breaks nice, adaptive idling, and slows the=20 > interactivity computation. That being said I'm not sure why it helps > you. >=20 > It seems that there are increasing reports of bad interactivity > creeping in to ULE over the last year. If people can help provide me > with data I can look into this more. >=20 I'll be glad to provide data > Thanks for your report. >=20 > Jeff How to repeat your tests on my system? http://jeffr-tech.livejournal.com/24280.html Sorry for my english. Thanks! --MP_/3p=06TSChVIs=2fxqfo=S/r-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 21:22:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83F6A106567E for ; Thu, 3 Nov 2011 21:22:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 60EFB8FC0C for ; Thu, 3 Nov 2011 21:22:20 +0000 (UTC) Received: by pzk32 with SMTP id 32so6851274pzk.3 for ; Thu, 03 Nov 2011 14:22:19 -0700 (PDT) Received: by 10.50.169.99 with SMTP id ad3mr6947279igc.6.1320355339520; Thu, 03 Nov 2011 14:22:19 -0700 (PDT) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id fu10sm6050989igc.6.2011.11.03.14.22.17 (version=SSLv3 cipher=OTHER); Thu, 03 Nov 2011 14:22:18 -0700 (PDT) Date: Thu, 3 Nov 2011 11:22:28 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ivan Klymenko In-Reply-To: <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> Message-ID: References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:22:20 -0000 On Thu, 3 Nov 2011, Ivan Klymenko wrote: > Thank you for taking the time to answer me. > > ? Thu, 3 Nov 2011 10:21:48 -1000 (HST) > Jeff Roberson ?????: > >> On Sat, 22 Oct 2011, Ivan Klymenko wrote: >> >>> Hello people! >>> >>> I have: >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz >>> K8-class CPU) FreeBSD 10.0-CURRENT r226607 amd64 >>> >>> For example during the building of the port lang/gcc46 in four >>> streams (-j 4) with a heavy load on the processor - use the system >>> was nearly impossible - responsiveness was terrible - the mouse >>> cursor sometimes froze on the spot a few seconds... >> >> Am I right in understanding that you have only two cores? > > Yes. > >> What else is running that achieves poor interactivity? > > This is mainly a compilation with make option -j >= ncpu*2 > And as an example - launching a large number of programs > http://www.youtube.com/watch?v=1CLCp-dqWu0 > This patch allows me to make do with ULE nearly as well as with FBFS > Without the patch, somewhere in the middle of the time with ULE has > been difficult to control the mouse cursor. > >> What is the cpu utilization of your x server at this time? > > ~2.00% - 20.00% WCPU time... But sometimes there are up to 79%... > Upon unloading the CPU returns to normal... When the x server is down at 20% is it laggy? Can you tell me the priorities of the x server and the compile tasks? You can use the 'pri' keyword with ps and write a short script to log all priorities once per second during your test. That would be most helpful. Let me know if you need assistance with that. Jeff > >> >>> >>> I managed to achieve a significant increase in the degree of >>> interactivity ULE scheduler due to the following changes: >> >> This patch probably breaks nice, adaptive idling, and slows the >> interactivity computation. That being said I'm not sure why it helps >> you. >> >> It seems that there are increasing reports of bad interactivity >> creeping in to ULE over the last year. If people can help provide me >> with data I can look into this more. >> > > I'll be glad to provide data > >> Thanks for your report. >> >> Jeff > > How to repeat your tests on my system? > http://jeffr-tech.livejournal.com/24280.html > > Sorry for my english. > > Thanks! > From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 21:25:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D1E106566C; Thu, 3 Nov 2011 21:25:13 +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 49C718FC13; Thu, 3 Nov 2011 21:25:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RM4md-0008WA-Hr>; Thu, 03 Nov 2011 22:25:12 +0100 Received: from e178038027.adsl.alicedsl.de ([85.178.38.27] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RM4md-0006pi-Cy>; Thu, 03 Nov 2011 22:25:11 +0100 Message-ID: <4EB306B2.30602@zedat.fu-berlin.de> Date: Thu, 03 Nov 2011 22:25:06 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111030 Thunderbird/7.0.1 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92391ED3A6F5D5D019BB462F" X-Originating-IP: 85.178.38.27 Cc: Matthias Apitz , freebsd-current@FreeBSD.org, "b. f." , freebsd-ports@FreeBSD.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:25:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92391ED3A6F5D5D019BB462F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/03/11 18:42, schrieb b. f.: >>>> It turns out that the problem is more general! A lot of ./configure >>>> scripts are detecting in 10-CUR that they can't or should not build >>>> shared libs; the problem is that the OS is detected now as >>> >>> As a temporary workaround, add "WITH_FBSD10_FIX=3D1" to /etc/make.con= f. >> >> ports/UPDATING and some of the mails in the archive of -current >> recommend setting UNAME_r=3D9.0-CURRENT; is this the same or which met= hod >> is prefered? >=20 > No, it is not the same. You can either masquerade, by setting UNAME_r > and OSVERSION, or by editing the headers and scripts that define them; > or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE > (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the > masquerading is probably safer, because there are some problems with > the fix that are still being resolved -- and a few ports that may fail > despite the fix. But of course if you help to test without > masquerading, these problems will be resolved sooner. >=20 > b. So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right? Setting this and try building ports without the masquerading will help those people involved in fixing more than the masquerading solution? If so, I would like to do so. I compile/update quite often ports, simply to keep my system fresh and for some testing purposes. At the moment I switch very often between CLANG and the legacy gcc 4.2.2 of FBSD 10, so it would not bother me much more as the inherited bothering due to the problems discussed if I have to switch one time more or prepare a PR for the problem. On the other hand, as far as I know, there was only suggested using UNAME_r. When do I have to use the OSVERSION? Regards Oliver --------------enig92391ED3A6F5D5D019BB462F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOswa2AAoJEOgBcD7A/5N86UsH/1n3ND7VbDotep7wvTQfl/FH G+ZmRil17h0qiHQXx7pB/XL/xP2LHRA2nQGkE9a+wnlnUBBglt12pWTyZDV7LYtN pP98g4ticpvxFJXCJ0VlHgSTPveB20UhF4O1wEFjkBB2oi19OQwA9+LPPfRSZhsu ZHxo+nKQSAmDSTdzCse5qDR/Nveu8UGLl1iSVY8liDqXxnmxgv9RTmM50jVYLh8j OwUU6SuDsOWE0Bb2ePToBe8uoIlSnq8btrfCmHqyfE53k/xD7zEEDcP7AheEX5Ds ffzUw0EMLH5B4SE3bRjCdy6ObaUZaMf6LIR9NKLm5G9SWWCE9H3xg+ViON+p0cg= =+8E6 -----END PGP SIGNATURE----- --------------enig92391ED3A6F5D5D019BB462F-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 22:26:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5337106564A for ; Thu, 3 Nov 2011 22:26:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 68DFC8FC0A for ; Thu, 3 Nov 2011 22:26:54 +0000 (UTC) Received: by iabz21 with SMTP id z21so2983964iab.13 for ; Thu, 03 Nov 2011 15:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RWHdmeFDZbWUIJPgKJNseBYC4j9tYB+PcjCpp3DaQf8=; b=ig+V/8J+Kh+Gh1kJhA0hQ0QUUnA1anip8YVTEEaKAKnvag0WG3I7H2lsEFXWtYdxYI HDagcHmgIVtHDZNRKZQoqUYdB9luKhMYW2dsKn21UQZZOCJQZKj7AKq9qr2zSbkbm6K8 zjUx2aJ4iqyyWnmvjRgfHZYGM1cn1hRsqKafY= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr2553578ibc.89.1320359213721; Thu, 03 Nov 2011 15:26:53 -0700 (PDT) Received: by 10.231.46.198 with HTTP; Thu, 3 Nov 2011 15:26:53 -0700 (PDT) In-Reply-To: <20111103115054.GA2155@trimind.de> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> <20111028094828.GA1781@trimind.de> <4EAF9E67.4040605@FreeBSD.org> <20111103115054.GA2155@trimind.de> Date: Thu, 3 Nov 2011 15:26:53 -0700 Message-ID: From: Kevin Oberman To: Sascha Klauder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: antik@bsd.ee, current@freebsd.org, freebsd-geom@freebsd.org, Garrett Cooper , Martin Wilke , "Andrey V. Elsukov" Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 22:26:54 -0000 On Thu, Nov 3, 2011 at 4:50 AM, Sascha Klauder wrote: > On Tue, 2011-11-01 11:23 +0400, Andrey V. Elsukov wrote: >> On 28.10.2011 13:48, Sascha Klauder wrote: >> > =A0GEOM_MIRROR: Device mirror/gm0 launched (2/2). >> > =A0GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > = 490350670 >> > =A0GEOM_PART: integrity check failed (mirror/gm0, MBR) >> This is the main problem. Your MBR' slice is bigger than actual space >> you have. The only way to fix this - recreate slice. > > =A0I've partioned and labeled the disk with sysinstall(8) from > 8.2-RELEASE media. =A0Does 9.0 use different disk geometry cal- > culation than 8.2 or is usage of gmirror the culprit? =A0Both > 8.2 and 9.0 kernels report the disk having 490350672 sectors. > >> You can break your mirror, recreate the slice (NOTE: you must preserve >> one sector for the gmirror's meta-data), then copy your data to the >> newly created slice, then reboot from the new slice and recreate mirror. > > =A0I think I'd rather reinstall 9.0 from scratch, getting rid > of MBR/disklabel as well. While using gpart and the 9.0 installer has some real benefits, it also has a few problems. I ave a disk that I partitioned with bsdinstall from the 9.0 distribution media and it worked fine for a STAT disk, but I am unable to boot te same disk when connected to a USB adapter. It shows up in the boot list, but when I select it, the screen blanks for a few seconds (<5) and the list re-appears. No errors, but my T520 BIOS clearly is not happy with it. I have no idea how common htis issue might be, but the T520 does have a UEFI BIOS. As noted, GEOM wants the final sector on the disk for its metadata, but GPT mandates that hte ast sector of the disk be used for a backup of the boot sector. The leads to the potential ofr all kinds if ugliness to develop, especially when BIOS, which knows nothing about GEOM, is accessing the disk. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 23:14:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5631065670; Thu, 3 Nov 2011 23:14:19 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBA5A8FC13; Thu, 3 Nov 2011 23:14:18 +0000 (UTC) Received: by wyg36 with SMTP id 36so2420359wyg.13 for ; Thu, 03 Nov 2011 16:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ufOduUj4oF4uL+rQBUFybxW7P7qg2T8QV0n23cx4PG0=; b=ZJu1DZJE2kjsVrpDHHdmPENYIaQDIz2h0qAxzMo5CQV2SMPj0gupeHOI9DRveqLAUy YSSNtgz0WU5IwPGvheAqnfUR6TaSGX1AA7C89WW7y5csuqNfcBuWjUtGW8Auq3EdvkZK nl2cULXwaTYAuhDS1CT+SF867lfMZj5VCNQTc= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr104100wib.6.1320362057578; Thu, 03 Nov 2011 16:14:17 -0700 (PDT) Received: by 10.180.98.5 with HTTP; Thu, 3 Nov 2011 16:14:17 -0700 (PDT) In-Reply-To: <4EB306B2.30602@zedat.fu-berlin.de> References: <4EB306B2.30602@zedat.fu-berlin.de> Date: Thu, 3 Nov 2011 19:14:17 -0400 Message-ID: From: "b. f." To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Matthias Apitz , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports (general) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 23:14:19 -0000 On 11/3/11, O. Hartmann wrote: > Am 11/03/11 18:42, schrieb b. f.: >So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right? You can set it in a number of local Makefiles that are automatically included during a port build. That includes make.conf, and the others mentioned in ports/Mk/bsd.port.mk. A few days ago Martin also added WITH_FBSD10_FIX to the Makefiles of a number of commonly-used ports that need the fix. >Setting this and try building ports without the masquerading will help >those people involved in fixing more than the masquerading solution? If Yes. Some of the known problems with the current fix don't occur when ports are built in tinderboxes or clean sandboxes, but on live systems that already have other ports installed. > On the other hand, as far as I know, there was only suggested using > UNAME_r. When do I have to use the OSVERSION? > You don't have to alter OSVERSION, but if you do not, then for those ports that have WITH_FBSD10_FIX set in their Makefiles, the fix will be applied, and you will be subject to any problems that the fix may cause, even though you are trying to masquerade as a version of FreeBSD less than 10. Look at the conditional that determine whether any action is taken during the run-autotools-fixup target in ports/Mk/bsd.port.mk. b. From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 01:54:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F9D106566C for ; Fri, 4 Nov 2011 01:54:30 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 236E28FC17 for ; Fri, 4 Nov 2011 01:54:29 +0000 (UTC) X-AuditID: 1209190e-b7f4a6d0000008e5-87-4eb345d4563d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 94.41.02277.4D543BE4; Thu, 3 Nov 2011 21:54:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pA41sSov011146; Thu, 3 Nov 2011 21:54:28 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pA41sQwM003329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2011 21:54:27 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pA41sQYu003166; Thu, 3 Nov 2011 21:54:26 -0400 (EDT) Date: Thu, 3 Nov 2011 21:54:25 -0400 (EDT) From: Benjamin Kaduk To: Chuck Burns , coco@executive-computing.de In-Reply-To: <7778873.vO2TIhRvIe@beastiefree> Message-ID: References: <201110272148.15459.break19@gmail.com> <7778873.vO2TIhRvIe@beastiefree> 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+NgFvrCIsWRmVeSWpSXmKPExsUixG6nonvVdbOfwWEbi2Xrb7NYnL7xk9Vi zpsPTA7MHvOmPWL0mPFpPovHzll32QOYo7hsUlJzMstSi/TtErgy+toUCy6yVqzfPZG5gXEb SxcjJ4eEgInEjObDrBC2mMSFe+vZuhi5OIQE9jFKTNqzlR0kISSwnlFiXkM5RGI/k8S0zy9Y IRL1EveaNzKB2CwCWhIf7z4Ai7MJqEjMfLORDcQWEXCQeLngHDOIzSwgL/H/ymWwemEBfYkd v+4B2RwcnAK6En93uoCEeQXsJU7d7mGG2NXOKDG78SojSEJUQEdi9f4pLBBFghInZz5hgZhp KXHuz3W2CYyCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREU uJySfDsYvx5UOsQowMGoxMObWLTRT4g1say4MvcQoyQHk5Io7yuXzX5CfEn5KZUZicUZ8UWl OanFhxglOJiVRHiVf2zyE+JNSaysSi3Kh0lJc7AoifOu3uHgJySQnliSmp2aWpBaBJOV4eBQ kuD9BDJUsCg1PbUiLTOnBCHNxMEJMpwHaLgiMNKFeIsLEnOLM9Mh8qcYFaXEef+DNAuAJDJK 8+B6YYnlFaM40CvCvCog7TzApATX/QpoMBPQYJ+NIFcXlyQipKQaGDmPWfV7RBjfO1nY6tCR Wnzjzzubm5scDNpy9q9T+yrTt9zlwtkXjteXdjaeYa/mu9nFY9U6pUzp4J45F0vsnfNr+o6X TnizQ+205VGDJnax/BMilYrre49+3fo1hueg3O7TyeaFB5n9JNY9qGJf3bqfK6n93fvjjrlF PYlZ3uG3C5Y4Ht25Q4mlOCPRUIu5qDgRAHf7lPoHAwAA Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:54:30 -0000 On Sat, 29 Oct 2011, Chuck Burns wrote: > On Saturday, October 29, 2011 1:13:58 AM Benjamin Kaduk wrote: >> >> Are you running installworld in single-user mode? >> What is the value of kern.securelevel? >> >> -Ben Kaduk > > Yes, I was running in single-user mode, and kern.securelevel was never > modified, and is currently showing as "-1" > > Also, I am running zfs root, if that makes a difference Hmm, ZFS root is indeed potentially interesting. Marco, are you also on ZFS root? Have you run a ZFS scrub recently? (That being about the limit of my ZFS knowledge, unfortunately.) It's pretty puzzling why only this handful of immutable files would trigger an issue, though. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 02:01:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02B8106566B for ; Fri, 4 Nov 2011 02:01:07 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 637CF8FC08 for ; Fri, 4 Nov 2011 02:01:07 +0000 (UTC) Received: by qadb12 with SMTP id b12so277615qad.13 for ; Thu, 03 Nov 2011 19:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.164.74 with SMTP id yo10mr2439933obb.69.1320372065908; Thu, 03 Nov 2011 19:01:05 -0700 (PDT) Received: by 10.182.39.169 with HTTP; Thu, 3 Nov 2011 19:01:05 -0700 (PDT) X-Originating-IP: [93.221.165.185] In-Reply-To: <201110251454.00471.jhb@freebsd.org> References: <99483.1319566152@critter.freebsd.dk> <201110251454.00471.jhb@freebsd.org> Date: Fri, 4 Nov 2011 03:01:05 +0100 Message-ID: From: "C. P. Ghost" To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 02:01:07 -0000 On Tue, Oct 25, 2011 at 8:54 PM, John Baldwin wrote: > On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote: >> In message <201110251342.45194.jhb@freebsd.org>, John Baldwin writes: >> >On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: >> >> as the subject says... is there any way to get the current >> >> CPU id for a userspace process (of course, >> >> valid only at the time the function is called as the >> >> process might be arbitrarily moved while it runs) >> > >> >Not from userland, no. =A0On x86 you can use cpuid to fetch the APIC ID= , but >> >that does not map 1:1 to FreeBSD cpu IDs. >> >> How does JEmalloc do it ? > > I don't think it does on FreeBSD. =A0The only thing malloc() knows on Fre= eBSD is > the total number of CPUs. =A0I believe Linux has a system call that retur= ns this > though (sched_getcpu() is the public interface which is a wrapper around = a > getcpu() system call). =A0From the manpage it would seem that sched_getcp= u() > uses a per-thread shared page of some sort so that it doesn't actually ha= ve to > enter the kernel to get the CPU ID. =A0Alternatively, you could imagine i= t on > x86 at least exporting a table mapping APIC IDs to CPU IDs and then using > cpuid and that table to do the lookup purely in userland. =A0That would o= nly > necessitate a global shared page and not one per-thread. =A0You could sti= ll fall > back to a system call for other architectures that simply returned > curthread->td_oncpu. Exposing a table mapping to userland would be somewhat similar to the way L4Ka::Pistachio exports a UTCB area to userland threads: https://github.com/l4ka/pistachio/blob/dd624dde5bce4ab120b2fcecbbcd94473eff= b201/kernel/src/glue/v4-x86/utcb.h > -- > John Baldwin -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 02:05:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 962BA106567B for ; Fri, 4 Nov 2011 02:05:56 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 21BC48FC14 for ; Fri, 4 Nov 2011 02:05:55 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so2279832bkb.13 for ; Thu, 03 Nov 2011 19:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e3tPaOLNc9lcmCdr1O4J4eSqCUovSf++0v12vbHWbJs=; b=BzQl0nDFe7gZIueLkiH9hk2aAhUk3i7vsa/6VwQ68GHy/V4rSFGZN7xn1J7acbvPbE 7F7ZxFBdgWDpNZQQ2E6mUpHcuMr4mtCjZApoJHWXU2dSpyXCFSLeFmcX7akcgAjKEXEO DNwqi4hcBstpX5zEyhnR5LtoVAKd7K8K5OUCI= MIME-Version: 1.0 Received: by 10.204.147.215 with SMTP id m23mr10109690bkv.84.1320372354855; Thu, 03 Nov 2011 19:05:54 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Thu, 3 Nov 2011 19:05:54 -0700 (PDT) In-Reply-To: <20111028204706.GA57454@sandvine.com> References: <20111028204706.GA57454@sandvine.com> Date: Thu, 3 Nov 2011 19:05:54 -0700 X-Google-Sender-Auth: Cc0n2sP47qxUlSAxkJ22pMiD7f8 Message-ID: From: Craig Rodrigues To: Nima Misaghian Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 02:05:56 -0000 On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian w= rote: > Hi, > > I have got code developed by Andre Albsmeier that is capable of > programming firmware of hard drives from several vendors and =A0turned > it into a camcontrol command. +1 I took a look at your patch and it looks great. I have worked on a storage product before where there was a requirement to reprogram the firmware of hard drives. On tha product= , proprietary Windows tools had to be used. It would have been nice to be able to use camcontrol in FreeBSD. I think the patch is fine in its current form. Very few "regular users" need to reprogram hard drive firmware. It is a special administrative operation. --=20 Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 03:25:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB691106566B; Fri, 4 Nov 2011 03:25:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 799E68FC14; Fri, 4 Nov 2011 03:25:25 +0000 (UTC) Received: from [93.104.81.74] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMAPD-0008If-IO; Fri, 04 Nov 2011 04:25:23 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id pA43PM02004498; Fri, 4 Nov 2011 04:25:22 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id pA43PLcW004497; Fri, 4 Nov 2011 04:25:21 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 04:25:21 +0100 From: Matthias Apitz To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Message-ID: <20111104032521.GA4093@tinyCurrent> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 93.104.81.74 Cc: bf1783@gmail.com, sylvio@freebsd.org Subject: Re: 10.0-CUR r226986 && ports/net-mgmt/net-snmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 03:25:26 -0000 El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: > No, it is not the same. You can either masquerade, by setting UNAME_r > and OSVERSION, or by editing the headers and scripts that define them; > or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE > (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the > masquerading is probably safer, because there are some problems with > the fix that are still being resolved -- and a few ports that may fail > despite the fix. But of course if you help to test without > masquerading, these problems will be resolved sooner. Well, I will try to help. I have set WITH_FBSD10_FIX in /etc/make.conf; the port ports/net-mgmt/net-snmp installs: /usr/local/include/net-snmp/net-snmp-config.h with: ... /* define the system type include file here */ #define NETSNMP_SYSTEM_INCLUDE_FILE "net-snmp/system/freebsd10.h" ... but the named header file is not there: # ls -C1 /usr/local/include/net-snmp/system/free* /usr/local/include/net-snmp/system/freebsd.h /usr/local/include/net-snmp/system/freebsd2.h /usr/local/include/net-snmp/system/freebsd3.h /usr/local/include/net-snmp/system/freebsd4.h /usr/local/include/net-snmp/system/freebsd5.h /usr/local/include/net-snmp/system/freebsd6.h /usr/local/include/net-snmp/system/freebsd7.h /usr/local/include/net-snmp/system/freebsd8.h /usr/local/include/net-snmp/system/freebsd9.h I don't know what the correct fix ist, and for the moment I created 'freebsd10.h' as a copy of 'freebsd9.h': # cat freebsd10.h #include "freebsd9.h" #define freebsd8 freebsd8 +Cc: maintainer Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 03:46:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3694E106564A for ; Fri, 4 Nov 2011 03:46:06 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id C7BD28FC15 for ; Fri, 4 Nov 2011 03:46:05 +0000 (UTC) X-AuditID: 1209190c-b7f806d0000008d6-b6-4eb35ffcba74 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 87.04.02262.CFF53BE4; Thu, 3 Nov 2011 23:46:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pA43k4uF020321; Thu, 3 Nov 2011 23:46:04 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pA43k3HD016403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2011 23:46:04 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pA43k2DS004265; Thu, 3 Nov 2011 23:46:02 -0400 (EDT) Date: Thu, 3 Nov 2011 23:46:02 -0400 (EDT) From: Benjamin Kaduk To: Alexander Yerenkow In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT0f0Tv9nP4PpqI4s5bz4wWWya85PZ gcljxqf5LB47Z91lD2CK4rJJSc3JLEst0rdL4MrYs/AEe8ESx4qmg+sYGxi7TbsYOTkkBEwk 1nUdYYKwxSQu3FvP1sXIxSEksI9R4sX9uywgCSGB9YwSe6ayQtj7mSR+7vCCsOslrvRNAIuz CGhJbF5wgg3EZhNQkZj5ZiOYLSKgLfH/zyFGEJtZQF7i/5XLYMuEBZQk5jQdBJvPKRAosXTd WnYQm1fAXuLP7h3sEEccZ5Q4sLedGSQhKqAjsXr/FBaIIkGJkzOfsEAMtZT4t/YX6wRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQIClROSZ4djG8OKh1i FOBgVOLhTSza6CfEmlhWXJl7iFGSg0lJlNchbrOfEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe 5R+b/IR4UxIrq1KL8mFS0hwsSuK8B3c4+AkJpCeWpGanphakFsFk1Tk4BK7O/8UsxZKXn5eq JMFbBYxTIcGi1PTUirTMnBKESiYOTpA9PEB71oPcwFtckJhbnJkOkT/FaMyxsPHyKUaOhulA UghsnJQ4LzvIOAGQ0ozSPLhpsBT0ilEc6E9hXgOQKh5g+oKb9wpoFRPQKp+NIC8VlyQipKQa GGOTRcV5wzxPSFzMczDu9kys2vlFbK23kK6B4cm3EkZzpWuvPbueKXnKX+RI20PriRZPXZ53 b7CRLPOMFt3perdootX5sMMZvB+PLjP7w7TwxF1Oe1knl/gD7v+vnllgNbNfV+B+2g/JA+EZ EvnPD0WrJfPurm+p+/By/v7/annuz4KuiZ+zVGIpzkg01GIuKk4EAF+VTOkcAwAA Cc: freebsd-current@freebsd.org Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 03:46:06 -0000 On Wed, 19 Oct 2011, Alexander Yerenkow wrote: > Hello all! > > I'm working currently on creating images with a set pre-installed packages. > I looked at project pkgng (candidate for replacing current pkg_* subsystem), > and also I have some thought about current packages/ports system. > > 1. pkg_add can be launched with parameter -p $PREFIX. So, my first thought > was: I create empty directory structure with mtree, and I'll install there > all required packages; after that I need only update this installation tree > (manually by pkg_delete $old pkg_add $new, or with some tool). But I cannot > specify to pkg_add relative root, instead of real one. > > Let me show example: > PKG_DBDIR=/zpool0/testroot/var/db/pkg pkg_add -p /zpool0/testroot/usr/local > ubench-0.32.tbz > installs package, and in /zpool0/testroot/var/db/pkg/ubench-0.32/+CONTENTS > there will be such record: > @cwd /zpool0/testroot/usr/local > > I can't specify to pkg_add that it should treat /zpool0/testroot as root, as > I need (so record really should be @cwd /usr/local) > Instead, pkg_add allows me to make chroot, which as you understand is not > good (In specified chroot all required by pkg* binaries/libraries must > exists, unfortunately I can't specify some empty dir and install there). > > Why is that? Because there is +INSTALL script in packages, in which > package/port system allows execute any code/script written by porter. This is indeed a frustrating problem. > > 2. In ports enhancements task list (somewhere i read it) there was one item: > Make packages non-executable (or something similar). To do this properly, we > must get rid of of free-form post-install post-deinstall scripts. > To do this, we need some deep analysis of what types of actions there > happening, formalize them and provide some way to porters specify all needed > actions in Makefile. > I downloaded all packages for 9-current i386, found all +INSTALL scripts, > and kinda categorized them, you can get all of them here: > http://www.box.net/shared/ieovjj7l8omkrm3l21xb > > To summarize my efforts: > I checked 21195 packages; > I found 880 install scripts; > > 3 scripts contains plain "exit 0" > 8 install scripts contains some perl code; > 17 scripts contains some additional "install" commands; > 70 scripts contains some chgroup/chown actions (which probably could be done > by specifying mtree file?...) > 75 contains uncategorized actions (print of license, some interactive > questions, ghostscript actions, tex, fonts etc.) > 161 scripts contains some file commands, like (ld / cp / mv, creating > backups, creating configs if they aren't exists etc. ) > 166 scripts contains useradd/groupadd commands (many similar constructions, > not too hard to move this to .mk, in pkgng group/users can be specified in > yaml config) > 380 contains pear component registration (md5 -q * | uniq - produces > exactly one result, so these all scripts are really one, could be moved to > some pear.mk) > Thank you for doing this analysis/breakdown! However, I worry that it may have missed @exec statements in pkg-plist files ... for example, net/openafs (which I maintain) runs kldxref in /boot/modules after installing a kernel module, which is needed in order for kldload to find the module. Now, this is clearly a case that a potential nonexecutable package framework could handle, checking for installed kernel modules and acting accordingly. However, having not done the survey of the sort you did for install scripts, it is an uneasy dangling unknown. > Why I'm interested in non-executable install of package (e.g. simple unpack > + execute some typical actions based on package description): > - Unpacking of hundreds Mb packages takes several minutes (to mdconfig-ed > filesystem) > - Installation of these packages via pkg_add (they downloads from local ftp) > took hours in my case (to mdconfig-ed filesystem) > This is quite a telling statistic :) > As you understand, to make efficient image building system, I need to deal > with package installation without spending too many cpu/disk resources. > Ideally I consider all required packages are extracted to some their own > directory, like for ubench: > $X/packages/ubench/ (and here goes all directory structure which should be > copied to new root) > > plus separated info of new users/groups (maybe there need some additional > data to make package installed in such way fully working). There would certainly be additional data needed, e.g. for installing sample configuration files and copying to the real location, and removing both copies on uninstallation if the "real" file is unchanged from the sample. I'm sure there are others, too. > > So, maybe someone working in this direction, or have any comments? > I would be very hesitant to proceed in this direction without doing some investigation of other package-based systems. For example, Debian packages are inherently binary-based, there is not a real parallel to our ports framework. Yet if anything, I think that "executable packages" may be even more heavily used in Debian than in FreeBSD. In addition to the tarball of files to extract, the maintainer can also supply "maintainer scripts" which run before and/or after installation and/or uninstallation. (Not to mention the infrastructure components which implement things like diversions.) I have an incomplete survey of a biased sample of Debian(-style) packages in my slides at http://web.mit.edu/kaduk/Public/bsdcan-ports-talk-20110511.pdf , which shows that in addition to being used to manage users and groups, these maintainer scripts also are used to start/stop services, update gconf keys, the PAM stack, and more. It quickly becomes quite a pile of "additional data needed" (per the above) that I fear would be too much infrastructure to safely maintain in a non-executable package framework. Another incredibly useful (though hopefully infrequently used) feature of maintainer scripts is the ability they give to recover from packaging errors. The first example that comes to mind is unfortunately not a very good one, but recently here at Athena we had a bug in our TeX configuration package which resulted in a dangling symlink from a broken diversion (which has no direct parallel in FreeBSD, making this a bad example). In any case, this packaging bug made the package uninstallable! However, we could produce an updated version of the package which had a preinst that corrected for the previous packaging error, offering us a way out that did not require manual user intervention, which I feel is something that we should try very hard to avoid. Because of this, I don't think that having it be impossible for a package to have a custom executable component is a realistic goal. (Which is not to say it is not a goal worth having.) However, it would probably be feasible to add pieces to our framework (e.g. USERS/GROUPS) that make it easier for packages to avoid executable components. If appropriately flagged, then a package could just be an "unpack this tarball" operation, possibly with a couple hooks (e.g. users/groups) from the packaging system. > 3. Other "ports" ideas/thoughts. > I proposed small enahcement to pkgng, but instead in pkgng this should be > implemented in ports subsystem, it's about specifying abstract dependencies, > and correct resolving of them: > https://github.com/pkgng/pkgng/issues/100 > > Who can comment/elaborate about this? It shouldn't be very complicated, > since currently almost same functionality provided in .mk. files ( like > USE_PERL etc) Interesting, though I don't think I'm really one to comment/elaborate on it. It does seem vaguely analogous to the concept of a (Debian) "virtual package", which can be depended on like a first-class package, but is actually "provide"d by any number of candidate packages. I don't have a sense of how hard it would be to implement for us, though, and I have not had any time to look at pkgng at all. :( > > > 4. Where's the "right" place to discuss ports system? :) Presumably freebsd-ports@freebsd.org, though I alas do not regularly read there. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 03:58:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BABF1106566B for ; Fri, 4 Nov 2011 03:58:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 566668FC13 for ; Fri, 4 Nov 2011 03:58:46 +0000 (UTC) Received: by ggnk3 with SMTP id k3so797326ggn.13 for ; Thu, 03 Nov 2011 20:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5s7bI0hQWKAuYmEuEAsFAcFDGq1dp+p5Xsj4KfgjP+s=; b=VGRsNm+ESt9symQ/gbDpADXbauVj6q+znHU6BOYxKg6n7rH+R9zh/pyNxNcrsI8xog pL9J37ZM5Fm9+8fIt8u8SdvNhG6aa24SZuuhlXmXDU4TRlofEAI2XicRMb59blEl0U0U cLMEdVj68CrP5RRfFt2VWuobqo+f8qIGRTgPM= Received: by 10.150.7.15 with SMTP id 15mr12997649ybg.65.1320379126471; Thu, 03 Nov 2011 20:58:46 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id l19sm23689144anc.14.2011.11.03.20.58.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 20:58:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <20111104032521.GA4093@tinyCurrent> Date: Thu, 3 Nov 2011 20:58:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7989121B-FF1E-4631-BACC-73FED47E7BC1@gmail.com> References: <20111104032521.GA4093@tinyCurrent> To: Matthias Apitz X-Mailer: Apple Mail (2.1084) Cc: bf1783@gmail.com, sylvio@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports/net-mgmt/net-snmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 03:58:47 -0000 On Nov 3, 2011, at 8:25 PM, Matthias Apitz wrote: > El d=EDa Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. = escribi=F3: >=20 >> No, it is not the same. You can either masquerade, by setting = UNAME_r >> and OSVERSION, or by editing the headers and scripts that define = them; >> or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE >> (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the >> masquerading is probably safer, because there are some problems with >> the fix that are still being resolved -- and a few ports that may = fail >> despite the fix. But of course if you help to test without >> masquerading, these problems will be resolved sooner. >=20 > Well, I will try to help. >=20 > I have set WITH_FBSD10_FIX in /etc/make.conf; the port > ports/net-mgmt/net-snmp installs: >=20 > /usr/local/include/net-snmp/net-snmp-config.h >=20 > with: >=20 > ... > /* define the system type include file here */ > #define NETSNMP_SYSTEM_INCLUDE_FILE "net-snmp/system/freebsd10.h" > ... >=20 > but the named header file is not there: >=20 > # ls -C1 /usr/local/include/net-snmp/system/free* > /usr/local/include/net-snmp/system/freebsd.h > /usr/local/include/net-snmp/system/freebsd2.h > /usr/local/include/net-snmp/system/freebsd3.h > /usr/local/include/net-snmp/system/freebsd4.h > /usr/local/include/net-snmp/system/freebsd5.h > /usr/local/include/net-snmp/system/freebsd6.h > /usr/local/include/net-snmp/system/freebsd7.h > /usr/local/include/net-snmp/system/freebsd8.h > /usr/local/include/net-snmp/system/freebsd9.h >=20 > I don't know what the correct fix ist, and for the moment I > created 'freebsd10.h' as a copy of 'freebsd9.h': >=20 > # cat freebsd10.h > #include "freebsd9.h" > #define freebsd8 freebsd8 >=20 > +Cc: maintainer You'll need to do more than just that. Take a look at the port history = for more details... -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 04:31:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA2E1065670 for ; Fri, 4 Nov 2011 04:31:17 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 589298FC08 for ; Fri, 4 Nov 2011 04:31:16 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pA44V7Kx005231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2011 15:01:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Fri, 4 Nov 2011 15:01:07 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> References: To: Alexander Yerenkow X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Warren Block , freebsd-current@freebsd.org Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 04:31:18 -0000 On 19/10/2011, at 21:19, Alexander Yerenkow wrote: > I can't specify to pkg_add that it should treat /zpool0/testroot as = root, as > I need (so record really should be @cwd /usr/local) > Instead, pkg_add allows me to make chroot, which as you understand is = not > good (In specified chroot all required by pkg* binaries/libraries must > exists, unfortunately I can't specify some empty dir and install = there). Hmmm, why is it empty? When I have made something analogous I did an installkernel/world into a = directory and then chroot'd in there and built ports. There is no reason = you couldn't pkg_add from a local mirror (or nullfs mount a local = package mirror directory into the chroot). > Why is that? Because there is +INSTALL script in packages, in which > package/port system allows execute any code/script written by porter. This is a feature ;) > To summarize my efforts: > I checked 21195 packages; > I found 880 install scripts; >=20 > 3 scripts contains plain "exit 0" > 8 install scripts contains some perl code; > 17 scripts contains some additional "install" commands; > 70 scripts contains some chgroup/chown actions (which probably could = be done > by specifying mtree file?...) > 75 contains uncategorized actions (print of license, some interactive > questions, ghostscript actions, tex, fonts etc.) > 161 scripts contains some file commands, like (ld / cp / mv, creating > backups, creating configs if they aren't exists etc. ) > 166 scripts contains useradd/groupadd commands (many similar = constructions, > not too hard to move this to .mk, in pkgng group/users can be = specified in > yaml config) > 380 contains pear component registration (md5 -q * | uniq - produces > exactly one result, so these all scripts are really one, could be = moved to > some pear.mk) Interesting stats, thanks for taking the time to do the analysis. I think one of the reasons pkg_add is so slow is that it copies = everything to a staging directory, then copies the files.. This is very = tedious (obviously). I wonder if it could be modified to have a "stream" = mode where it unpacks directly into the target FS. Alternatively you could cut it in 2 conceptually and modify pkg_add so = it can run it a mode where it just unpacks to a staging area, and = another mode where it copies from the staging area to the destination. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 05:03:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF18106564A; Fri, 4 Nov 2011 05:03:06 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 53EE38FC12; Fri, 4 Nov 2011 05:03:06 +0000 (UTC) Received: from [93.104.81.74] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMBvk-00009V-5U; Fri, 04 Nov 2011 06:03:04 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id pA45339n004838; Fri, 4 Nov 2011 06:03:03 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id pA4532Y5004837; Fri, 4 Nov 2011 06:03:02 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 06:03:02 +0100 From: Matthias Apitz To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Message-ID: <20111104050302.GA4811@tinyCurrent> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 93.104.81.74 Cc: bf1783@gmail.com, ume@freebsd.org Subject: Re: 10.0-CUR r226986 && ports/security/cyrus-sasl2-saslauthd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 05:03:06 -0000 El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: > No, it is not the same. You can either masquerade, by setting UNAME_r > and OSVERSION, or by editing the headers and scripts that define them; > or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE > (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the > masquerading is probably safer, because there are some problems with > the fix that are still being resolved -- and a few ports that may fail > despite the fix. But of course if you help to test without > masquerading, these problems will be resolved sooner. the ports/security/cyrus-sasl2-saslauthd does not install with WITH_FBSD10_FIX; terminates with: cc -O2 -pipe -fno-strict-aliasing -rpath=/usr/lib:/usr/local/lib -o saslauthd mechanisms.o auth_dce.o auth_getpwent.o auth_krb5.o auth_krb4.o auth_pam.o aut h_rimap.o auth_httpform.o auth_shadow.o auth_sia.o auth_sasldb.o lak.o auth_l dap.o cache.o cfile.o krbtf.o utils.o ipc_unix.o ipc_doors.o saslauthd-main.o md5.o -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -l roken -lcrypt -lcrypt ../sasldb/.libs/libsasldb.al -lpam cc: ../sasldb/.libs/libsasldb.al: No such file or directory *** Error code 1 installes fine with UNAME_r set to 9-CURRENT; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 06:50:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16A8106564A; Fri, 4 Nov 2011 06:50:00 +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 733B28FC1C; Fri, 4 Nov 2011 06:50:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RMDbD-0006Gx-3H>; Fri, 04 Nov 2011 07:49:59 +0100 Received: from e178008245.adsl.alicedsl.de ([85.178.8.245] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RMDbC-0000Bi-UH>; Fri, 04 Nov 2011 07:49:59 +0100 Message-ID: <4EB38B10.8090003@zedat.fu-berlin.de> Date: Fri, 04 Nov 2011 07:49:52 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111030 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4EB312E4.2010904@zedat.fu-berlin.de> <20111103224858.GA2683@icarus.home.lan> In-Reply-To: <20111103224858.GA2683@icarus.home.lan> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6570F957B915DC33953D9F57" X-Originating-IP: 85.178.8.245 Cc: Current FreeBSD , FreeBSD Stable Mailing List Subject: Re: FreeBSD 10.0-CURRENT/amd64: Weirdness with LOCALE settings: ghostswitching in csh? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 06:50:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6570F957B915DC33953D9F57 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/03/11 23:48, schrieb Jeremy Chadwick: > On Thu, Nov 03, 2011 at 11:17:08PM +0100, O. Hartmann wrote: >> Hello. >> I realised something weird in FreeBSD 10.-CURRENT/amd64 (CLANG >> compiled), build as from today (buildworld). >> >> Working the whole day coding some pyhton scripts and committing the co= de >> to my subversion server (most recent subversion from the ports >> collection, the server is a FreeBSD 9.0-RC1/amd64 box, also system >> compiled with CLANG, most recent as compiled world of today), suddenly= , >> oy of the blue, trying again to commit I get this error: >> >> svn: warning: cannot set LC_CTYPE locale >> svn: warning: environment variable LC_CTYPE is de_DE.ISO-8859-1 >> svn: warning: please check that your locale name is correct >> >> >> Checking csh shell setting with 'locale": >> LANG=3D >> LC_CTYPE=3D"C" >> LC_COLLATE=3D"C" >> LC_TIME=3D"C" >> LC_NUMERIC=3D"C" >> LC_MONETARY=3D"C" >> LC_MESSAGES=3D"C" >> LC_ALL=3D >> >> >> Checking my settings from /etc/csh.cshrc and ./.cshrc or .login reveal= s >> localised settings for some of the locales as I need those: >> >> (set in $HOME/.cshrc) >> setenv LC_CTYPE "de_DE.ISO-8859-1" >> setenv LC_TIME "de_DE.ISO-8859-1" >> setenv LC_MONETARY "de_DE.ISO-8859-1" >> >> What is going on? >> >> I realised this behaviour now several times, first time I thought I di= d >> something and I couldn't remember, but this time, only two terminal >> windows were opened and the whole day committing data to the repositor= y >> wasn't an issue. >> >> Is there an explanation for this? >=20 > It sounds like a problem specific to the "client end", meaning your > -CURRENT box. If that's the case: shouldn't this mail have gone to > freebsd-current@ instead of freebsd-stable@ ? What am I missing? Mea culpa, mea culpa, mea maxima culpa! It was intented to send the mail to CURRENT. Sorry, missed the listentry by one row ... Can you please so kind and show mercy? >=20 > As for your problem: your locale looks incorrect. It's > "de_DE.ISO8859-1". Note that yours has an extra hyphen, which probably= > explains the error (sort of). >=20 > $ ls -ld /usr/share/locale/de_DE* > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/= de_DE.ISO8859-1/ > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/= de_DE.ISO8859-15/ > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/= de_DE.UTF-8/ >=20 > As for the fact that it's "random": I cannot explain why a sub-shell > might get spawned in some cases but not others. I corrected this. Sorry. I ffel a bit confused, since sometimes it is ISO-8859-1 and sometimes ISO8859-1. I got confused again. After correcting that, the locale variables has been set correctly. I will check now wether this also influences this weird random behaviour.= Thank you very much. Regards, Oliver --------------enig6570F957B915DC33953D9F57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOs4sWAAoJEOgBcD7A/5N8oUwH/2RdEWbUiDCfa3tpZC0863n4 L6EIN60QoQiYiqrQ7FHGNYVVv+MltwlpLo6oeuidvPVu3YEYaXjrXZGbiaK1c2RR JIJPC1LKc+xRu2Dh9bWmk+u3zZ0E23DwEbMcQ5nxSpOtu6GlDYD5jjEkhZH5cTod gMiu0Eiz97YOafn7/qbrANKcBuED8+/GjqAZbiua4JWx/XZS7Nb/08ijmavB5vjh imLDtJMR9suX6z4LCgVqjGpSL3ogpdj/zppXd+y4yYY0bc8xDFwJ4zh9JmRsm1zQ Fq++zNOKPKQllPJeg06amRp508GPm/VU83a/ArYqt/9wrHoX93LPLYhJYH4DNG8= =mGWT -----END PGP SIGNATURE----- --------------enig6570F957B915DC33953D9F57-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 09:07:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2B61065674; Fri, 4 Nov 2011 09:07:47 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id D65B38FC0A; Fri, 4 Nov 2011 09:07:46 +0000 (UTC) Received: from [89.204.155.132] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMFkV-0005gC-PI; Fri, 04 Nov 2011 10:07:45 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA497qIk001149; Fri, 4 Nov 2011 10:07:52 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA497p5K001148; Fri, 4 Nov 2011 10:07:51 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 10:07:50 +0100 From: Matthias Apitz To: Garrett Cooper Message-ID: <20111104090750.GA1134@tiny> References: <1320397282.2056.40.camel@vm-9Current> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1320397282.2056.40.camel@vm-9Current> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.155.132 Cc: bf1783@gmail.com, sylvio@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: 10.0-CUR r226986 && ports/net-mgmt/net-snmp] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:07:47 -0000 ----- message from Garrett Cooper ----- > > I don't know what the correct fix ist, and for the moment I > > created 'freebsd10.h' as a copy of 'freebsd9.h': > > > > # cat freebsd10.h > > #include "freebsd9.h" > > #define freebsd8 freebsd8 > > > > +Cc: maintainer > > You'll need to do more than just that. Take a look at the port history for more details... > -Garrett I can imagine, esp. after reading the dialogs of the last PR ports/158714; that's why I cc'ed the maintainer; my ugly change above at least made compiling of KDE3 to continue; the port is broken at the moment for 10-CURRENT; matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 10:08:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E667106564A; Fri, 4 Nov 2011 10:08:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C46CC8FC15; Fri, 4 Nov 2011 10:08:33 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA4A8Ur4043428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2011 12:08:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA4A8UZl043301; Fri, 4 Nov 2011 12:08:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA4A8S9T043300; Fri, 4 Nov 2011 12:08:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Nov 2011 12:08:28 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111104100828.GG50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+5H7HCnwmuggT63n" Content-Disposition: inline In-Reply-To: <4EB2D48E.1030102@rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:08:34 -0000 --+5H7HCnwmuggT63n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote: > On 11/03/2011 08:24, Kostik Belousov wrote: > >On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote: > >>On 11/02/2011 05:32, Andriy Gapon wrote: > >>>[restored cc: to the original poster] > >>>As Bruce Evans has pointed to me privately [I am not sure why privatel= y], > >>>there > >>>is already an example in i386 and amd64 atomic.h, where operations are > >>>inlined > >>>for a kernel build, but presented as real (external) functions for a= =20 > >>>module > >>>build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. > >>> > >>>I think that the same treatment could/should be applied to vm_page_*lo= ck* > >>>operations defined in sys/vm/vm_page.h. > >>*snip* > >> > >>Yes, it should be. There are without question legitimate reasons for a > >>module to acquire a page lock. > >I agree. Also, I think that we should use the opportunity to also isolate > >the modules from the struct vm_page layout changes. As example, I conver= ted > >nfsclient.ko. > > >=20 > I would suggest introducing the vm_page_bits_t change first. If, at the= =20 > same time, you change the return type from the function vm_page_bits()=20 > to use vm_page_bits_t, then I believe it is straightforward to fix all=20 > of the places in vm_page.c that don't properly handle a 32 KB page size. Ok, I think this is orhtohonal to the ABI issue. The vm_page_bits_t applied. diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c index f14da4a..f22c34a 100644 --- a/sys/vm/vm_page.c +++ b/sys/vm/vm_page.c @@ -137,7 +137,7 @@ SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD, =20 static uma_zone_t fakepg_zone; =20 -static void vm_page_clear_dirty_mask(vm_page_t m, int pagebits); +static void vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits); static void vm_page_queue_remove(int queue, vm_page_t m); static void vm_page_enqueue(int queue, vm_page_t m); static void vm_page_init_fakepg(void *dummy); @@ -2350,7 +2350,7 @@ retrylookup: * * Inputs are required to range within a page. */ -int +vm_page_bits_t vm_page_bits(int base, int size) { int first_bit; @@ -2367,7 +2367,8 @@ vm_page_bits(int base, int size) first_bit =3D base >> DEV_BSHIFT; last_bit =3D (base + size - 1) >> DEV_BSHIFT; =20 - return ((2 << last_bit) - (1 << first_bit)); + return (((vm_page_bits_t)2 << last_bit) - + ((vm_page_bits_t)1 << first_bit)); } =20 /* @@ -2426,7 +2427,7 @@ vm_page_set_valid(vm_page_t m, int base, int size) * Clear the given bits from the specified page's dirty field. */ static __inline void -vm_page_clear_dirty_mask(vm_page_t m, int pagebits) +vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits) { uintptr_t addr; #if PAGE_SIZE < 16384 @@ -2455,7 +2456,6 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) */ addr =3D (uintptr_t)&m->dirty; #if PAGE_SIZE =3D=3D 32768 -#error pagebits too short atomic_clear_64((uint64_t *)addr, pagebits); #elif PAGE_SIZE =3D=3D 16384 atomic_clear_32((uint32_t *)addr, pagebits); @@ -2492,8 +2492,8 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) void vm_page_set_validclean(vm_page_t m, int base, int size) { - u_long oldvalid; - int endoff, frag, pagebits; + vm_page_bits_t oldvalid, pagebits; + int endoff, frag; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); if (size =3D=3D 0) /* handle degenerate case */ @@ -2505,7 +2505,7 @@ vm_page_set_validclean(vm_page_t m, int base, int siz= e) * first block. */ if ((frag =3D base & ~(DEV_BSIZE - 1)) !=3D base && - (m->valid & (1 << (base >> DEV_BSHIFT))) =3D=3D 0) + (m->valid & ((vm_page_bits_t)1 << (base >> DEV_BSHIFT))) =3D=3D 0) pmap_zero_page_area(m, frag, base - frag); =20 /* @@ -2515,7 +2515,7 @@ vm_page_set_validclean(vm_page_t m, int base, int siz= e) */ endoff =3D base + size; if ((frag =3D endoff & ~(DEV_BSIZE - 1)) !=3D endoff && - (m->valid & (1 << (endoff >> DEV_BSHIFT))) =3D=3D 0) + (m->valid & ((vm_page_bits_t)1 << (endoff >> DEV_BSHIFT))) =3D=3D 0) pmap_zero_page_area(m, endoff, DEV_BSIZE - (endoff & (DEV_BSIZE - 1))); =20 @@ -2585,7 +2585,7 @@ vm_page_clear_dirty(vm_page_t m, int base, int size) void vm_page_set_invalid(vm_page_t m, int base, int size) { - int bits; + vm_page_bits_t bits; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); KASSERT((m->oflags & VPO_BUSY) =3D=3D 0, @@ -2656,9 +2656,10 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) int vm_page_is_valid(vm_page_t m, int base, int size) { - int bits =3D vm_page_bits(base, size); + vm_page_bits_t bits; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); + bits =3D vm_page_bits(base, size); if (m->valid && ((m->valid & bits) =3D=3D bits)) return 1; else diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 23637bb..7d1a529 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -113,6 +113,21 @@ =20 TAILQ_HEAD(pglist, vm_page); =20 +#if PAGE_SIZE =3D=3D 4096 +#define VM_PAGE_BITS_ALL 0xffu +typedef uint8_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 8192 +#define VM_PAGE_BITS_ALL 0xffffu +typedef uint16_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 16384 +#define VM_PAGE_BITS_ALL 0xffffffffu +typedef uint32_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 32768 +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu +typedef uint64_t vm_page_bits_t; +#endif + + struct vm_page { TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q)= */ TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ @@ -138,19 +153,8 @@ struct vm_page { /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ /* so, on normal X86 kernels, they must be at least 8 bits wide */ /* In reality, support for 32KB pages is not fully implemented. */ -#if PAGE_SIZE =3D=3D 4096 - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 8192 - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 16384 - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 32768 - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#endif + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ }; =20 /* @@ -403,7 +407,7 @@ void vm_page_clear_dirty (vm_page_t, int, int); void vm_page_set_invalid (vm_page_t, int, int); int vm_page_is_valid (vm_page_t, int, int); void vm_page_test_dirty (vm_page_t); -int vm_page_bits (int, int); +vm_page_bits_t vm_page_bits (int, int); void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid); void vm_page_free_toq(vm_page_t m); void vm_page_zero_idle_wakeup(void); diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c index e3222cb..cd2658d 100644 --- a/sys/vm/vnode_pager.c +++ b/sys/vm/vnode_pager.c @@ -486,15 +486,16 @@ vnode_pager_input_smlfs(object, m) vm_object_t object; vm_page_t m; { - int bits, i; struct vnode *vp; struct bufobj *bo; struct buf *bp; struct sf_buf *sf; daddr_t fileaddr; vm_offset_t bsize; - int error =3D 0; + vm_page_bits_t bits; + int error, i; =20 + error =3D 0; vp =3D object->handle; if (vp->v_iflag & VI_DOOMED) return VM_PAGER_BAD; --+5H7HCnwmuggT63n Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6zuZwACgkQC3+MBN1Mb4gZ8ACgyWDEE1H9k/uAle0grS4IdElI xdcAnj/52l3XGtf7LA6umSUGxQVnZHJp =HXYo -----END PGP SIGNATURE----- --+5H7HCnwmuggT63n-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 10:37:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC0A106566C; Fri, 4 Nov 2011 10:37:19 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3B41F8FC17; Fri, 4 Nov 2011 10:37:19 +0000 (UTC) Received: from [89.204.155.132] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMH99-0006tA-Jr; Fri, 04 Nov 2011 11:37:17 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA4AbOSG001206; Fri, 4 Nov 2011 11:37:25 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA4AbNY0001205; Fri, 4 Nov 2011 11:37:23 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 11:37:23 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, freebsd-gnome@freebsd.org Message-ID: <20111104103721.GA1191@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.155.132 Cc: freebsd-ports@freebsd.org Subject: 10-CURRENT && ports/devel/libnotify does not build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 10:37:19 -0000 Hello, ports/devel/libnotify (requested by www/firefox36) does not build in 10-CURRENT (ports uptodate to November 3 from CVS): # make ... checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PACKAGE... yes checking for TESTS... no configure: error: Package requirements (gtk+-3.0 >= 2.90) were not met: No package 'gtk+-3.0' found btw: nice test 3.0 >= 2.90 not matched :-) matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 07:17:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22ED106566B for ; Fri, 4 Nov 2011 07:17:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 885908FC14 for ; Fri, 4 Nov 2011 07:17:29 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta13.emeryville.ca.mail.comcast.net with comcast id sut61h0030mlR8UADv4C3R; Fri, 04 Nov 2011 07:04:12 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta11.emeryville.ca.mail.comcast.net with comcast id sv171h00D1t3BNj8Xv1818; Fri, 04 Nov 2011 07:01:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C27EE102C19; Fri, 4 Nov 2011 00:04:17 -0700 (PDT) Date: Fri, 4 Nov 2011 00:04:17 -0700 From: Jeremy Chadwick To: "O. Hartmann" Message-ID: <20111104070417.GA14869@icarus.home.lan> References: <4EB312E4.2010904@zedat.fu-berlin.de> <20111103224858.GA2683@icarus.home.lan> <4EB38B10.8090003@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB38B10.8090003@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 04 Nov 2011 11:06:57 +0000 Cc: Current FreeBSD , FreeBSD Stable Mailing List Subject: Re: FreeBSD 10.0-CURRENT/amd64: Weirdness with LOCALE settings: ghostswitching in csh? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 07:17:29 -0000 On Fri, Nov 04, 2011 at 07:49:52AM +0100, O. Hartmann wrote: > Am 11/03/11 23:48, schrieb Jeremy Chadwick: > > On Thu, Nov 03, 2011 at 11:17:08PM +0100, O. Hartmann wrote: > >> Hello. > >> I realised something weird in FreeBSD 10.-CURRENT/amd64 (CLANG > >> compiled), build as from today (buildworld). > >> > >> Working the whole day coding some pyhton scripts and committing the code > >> to my subversion server (most recent subversion from the ports > >> collection, the server is a FreeBSD 9.0-RC1/amd64 box, also system > >> compiled with CLANG, most recent as compiled world of today), suddenly, > >> oy of the blue, trying again to commit I get this error: > >> > >> svn: warning: cannot set LC_CTYPE locale > >> svn: warning: environment variable LC_CTYPE is de_DE.ISO-8859-1 > >> svn: warning: please check that your locale name is correct > >> > >> > >> Checking csh shell setting with 'locale": > >> LANG= > >> LC_CTYPE="C" > >> LC_COLLATE="C" > >> LC_TIME="C" > >> LC_NUMERIC="C" > >> LC_MONETARY="C" > >> LC_MESSAGES="C" > >> LC_ALL= > >> > >> > >> Checking my settings from /etc/csh.cshrc and ./.cshrc or .login reveals > >> localised settings for some of the locales as I need those: > >> > >> (set in $HOME/.cshrc) > >> setenv LC_CTYPE "de_DE.ISO-8859-1" > >> setenv LC_TIME "de_DE.ISO-8859-1" > >> setenv LC_MONETARY "de_DE.ISO-8859-1" > >> > >> What is going on? > >> > >> I realised this behaviour now several times, first time I thought I did > >> something and I couldn't remember, but this time, only two terminal > >> windows were opened and the whole day committing data to the repository > >> wasn't an issue. > >> > >> Is there an explanation for this? > > > > It sounds like a problem specific to the "client end", meaning your > > -CURRENT box. If that's the case: shouldn't this mail have gone to > > freebsd-current@ instead of freebsd-stable@ ? What am I missing? > > Mea culpa, mea culpa, mea maxima culpa! > > It was intented to send the mail to CURRENT. Sorry, missed the listentry > by one row ... Can you please so kind and show mercy? No worries. I wasn't sure if there was a reason -stable was involved; I saw it and thought "Hmm, he mentions a 9.0-RC1/amd64 box, maybe that's where the problem is? I must be missing something", so I thought I'd ask. Mistakes happen, especially ones from me! :-) > > As for your problem: your locale looks incorrect. It's > > "de_DE.ISO8859-1". Note that yours has an extra hyphen, which probably > > explains the error (sort of). > > > > $ ls -ld /usr/share/locale/de_DE* > > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/de_DE.ISO8859-1/ > > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/de_DE.ISO8859-15/ > > drwxr-xr-x 2 root wheel 512 Sep 28 14:36 /usr/share/locale/de_DE.UTF-8/ > > > > As for the fact that it's "random": I cannot explain why a sub-shell > > might get spawned in some cases but not others. > > I corrected this. Sorry. I ffel a bit confused, since sometimes it is > ISO-8859-1 and sometimes ISO8859-1. I got confused again. > > After correcting that, the locale variables has been set correctly. > > I will check now wether this also influences this weird random behaviour. I find the "randomness" of the situation more perplexing than fixing your locale (I have a feeling you do too). I imagine this will probably fix the errors you were seeing, but I'm still surprised that the errors would happen seemingly intermittently. I wonder how one could go about debugging such a thing. Hmm. Are there any "environment complexities" you might have, such as using GNU screen or tmux? I'm cycling through ideas as they come to me. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 11:16:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53B6A106566B for ; Fri, 4 Nov 2011 11:16:02 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id C2E4C8FC12 for ; Fri, 4 Nov 2011 11:16:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Q5JYJA1F6JPO0HI8TGs4OnN8Dzt/Xbg+QipTq5qPgPk=; b=gnr+c7YX1fSesld+2C0p9H5O6woTwKpo720OkL/iATXE96Uvsc0vS1zPDD0ubNkwy/M82P1/L6sbbMMSFZAReT3KQPoQXG5gbvackSySfC3SVji9SwVREw/3Wo+8v98K5GstRJvBhCONC/aEwQA7u9++GMU3QrM+ubWqkoWBETk=; Received: from [81.23.24.109] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RMHkc-000Ncj-9q ; Fri, 04 Nov 2011 13:15:59 +0200 Date: Fri, 4 Nov 2011 13:15:27 +0200 From: Ivan Klymenko To: Jeff Roberson Message-ID: <20111104131527.08d72583@nonamehost.> In-Reply-To: References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/HZM2r9C6vj7Caiv83.q+3uO" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 11:16:02 -0000 --MP_/HZM2r9C6vj7Caiv83.q+3uO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =D0=92 Thu, 3 Nov 2011 11:22:28 -1000 (HST) Jeff Roberson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > When the x server is down at 20% is it laggy? In different ways, but basically - yes. Sometimes appear in Xorg.0.log messages like: "[mi] EQ overflowing. The server is probably stuck in an infinite loop." When I run a lot of programs is beginning to actively use swap, although i have 4G RAM on my system and if use 4BSD or FBFS this does not happen... > Can you tell me the priorities of the x server and the compile tasks? cc1: PRI 74-86 (4 processes) X: PRI 20-74 (mainly 74 at high load CPU) WCPU: 0.98%-6.98% > You can use the 'pri' keyword with ps and write a short script to log > all priorities once per second during your test. Yes. ps ax|grep X 2786 - S 3:31,13 /usr/local/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-cqiXfH/database -nolisten tcp (Xorg) I use script #!/bin/sh while [ 1 -lt 2 ] do #ps -p 2786 -uo pri >> pri_test.log ps -p 2786 -o pri >> pri_test.log sleep 1 done log file pri_test.log as an attachment... > That would be most helpful. > Let me know if you need assistance with that. Thanks! --MP_/HZM2r9C6vj7Caiv83.q+3uO-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 11:18:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F808106564A for ; Fri, 4 Nov 2011 11:18:50 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0BA8FC12 for ; Fri, 4 Nov 2011 11:18:49 +0000 (UTC) Received: by ywt32 with SMTP id 32so3141831ywt.13 for ; Fri, 04 Nov 2011 04:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zuf5aVSPsyh4bk7TGIvsDkvXPl2uezYnPm+vEo69HNM=; b=jDwBrDkEMMzbWT3cxcUz9YFwVrYczDDj1lMS5RlAzHPnaI0hY3jLuvY5cDkGx6nPhq Le7Bi7SuEus/ejPOyBL9ABE4J2MiQ5WGMs0XkJA2EC5DM/T36CGvtzjljjchzoI2FR// OcPrEzfounE+nyuS0S2ukYe0Do5Kmhj0I/9AA= MIME-Version: 1.0 Received: by 10.151.21.19 with SMTP id y19mr13712551ybi.72.1320405528893; Fri, 04 Nov 2011 04:18:48 -0700 (PDT) Received: by 10.150.225.9 with HTTP; Fri, 4 Nov 2011 04:18:48 -0700 (PDT) In-Reply-To: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Fri, 4 Nov 2011 13:18:48 +0200 Message-ID: From: Alexander Yerenkow To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Warren Block , freebsd-current@freebsd.org Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 11:18:50 -0000 2011/11/4 Daniel O'Connor > > On 19/10/2011, at 21:19, Alexander Yerenkow wrote: > > I can't specify to pkg_add that it should treat /zpool0/testroot as > root, as > > I need (so record really should be @cwd /usr/local) > > Instead, pkg_add allows me to make chroot, which as you understand is not > > good (In specified chroot all required by pkg* binaries/libraries must > > exists, unfortunately I can't specify some empty dir and install there). > > Hmmm, why is it empty? > When I have made something analogous I did an installkernel/world into a > directory and then chroot'd in there and built ports. There is no reason > you couldn't pkg_add from a local mirror (or nullfs mount a local package > mirror directory into the chroot). > >From beginning I thought about having a lot of directories, which contains one installed package; I assume using plain copy all requried data, to have requried packages installed in new chroot env. Not via install, but simply by copy. Reason was - to make composing of images with pre-installed software faster (avoiding pkg_add/unpack/mtree/etc. steps). I could easily use unionfs, if only it could work under zfs :) In any way, all package installation process, all running scripts ends and leaving a bunch of new files (links too), and some changed files (like added groups/users etc), that's all. I just wanted have unpacked and initialized packages in directories, which I could use as puzzle parts, to build image with pre-installed packages. Of course, I understand that there required some tricks to make it all works (like adding users/groups/ X config etc.), but many straightforward software will just work, which is in mostly cases enough to test another release. Currently I'm using pretty slow way to make pre-installed images, new fresh copy of base world for each package-set, after that created install script, and runned in chroot. for i in `cat test-package-list` ; do echo "env PACKAGESITE=$packagesite pkg_add -rifF $i" >> $blank/root/install.sh done parameters used: -r, --remote Use the remote fetching feature. -i, --no-deps Install the package without fetching and installing dependencies. -I, --no-script If any installation scripts (pre-install or post-install) exist for a given package, do not execute them. -f, --force Force installation to proceed even if prerequisite packages are not installed or the requirements script fails. -F Already installed packages are not an error So, package not getting dependencies (they all must be specified too), but all went installed and even working somehow. But all this is pretty rough :) About long way to standardize installation process - I think even if it's so complex, it should just start somewhere. Best candidate - all pear install scripts; they can easily be moved to *.mk. A bit more complex is standardizing user/groups. > > > Why is that? Because there is +INSTALL script in packages, in which > > package/port system allows execute any code/script written by porter. > > This is a feature ;) > > > To summarize my efforts: > > I checked 21195 packages; > > I found 880 install scripts; > > > > 3 scripts contains plain "exit 0" > > 8 install scripts contains some perl code; > > 17 scripts contains some additional "install" commands; > > 70 scripts contains some chgroup/chown actions (which probably could be > done > > by specifying mtree file?...) > > 75 contains uncategorized actions (print of license, some interactive > > questions, ghostscript actions, tex, fonts etc.) > > 161 scripts contains some file commands, like (ld / cp / mv, creating > > backups, creating configs if they aren't exists etc. ) > > 166 scripts contains useradd/groupadd commands (many similar > constructions, > > not too hard to move this to .mk, in pkgng group/users can be specified > in > > yaml config) > > 380 contains pear component registration (md5 -q * | uniq - produces > > exactly one result, so these all scripts are really one, could be moved > to > > some pear.mk) > > Interesting stats, thanks for taking the time to do the analysis. > > I think one of the reasons pkg_add is so slow is that it copies everything > to a staging directory, then copies the files.. This is very tedious > (obviously). I wonder if it could be modified to have a "stream" mode where > it unpacks directly into the target FS. > > Alternatively you could cut it in 2 conceptually and modify pkg_add so it > can run it a mode where it just unpacks to a staging area, and another mode > where it copies from the staging area to the destination. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 12:50:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B93FC106566B; Fri, 4 Nov 2011 12:50:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 539C78FC0A; Fri, 4 Nov 2011 12:50:38 +0000 (UTC) Received: from [89.204.137.190] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMJEC-0005x8-3v; Fri, 04 Nov 2011 13:50:37 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA4CodfS001350; Fri, 4 Nov 2011 13:50:40 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA4Cob14001349; Fri, 4 Nov 2011 13:50:37 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 13:50:37 +0100 From: Matthias Apitz To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Message-ID: <20111104125036.GA1335@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.137.190 Cc: pav@freebsd.org Subject: 10-CURRENT && ports/graphics/gphoto2 and ports/graphics/libgphoto2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 12:50:39 -0000 Hello, ports/graphics/gphoto2 is missing a lot of libs which should be installed by ports/graphics/libgphoto2: # make ===> gphoto2-2.4.11 depends on executable: gmake - found ===> gphoto2-2.4.11 depends on shared library: popt.0 - found ===> gphoto2-2.4.11 depends on shared library: gphoto2.2 - not found ===> Verifying install for gphoto2.2 in /usr/ports/graphics/libgphoto2 ===> Returning to build of gphoto2-2.4.11 Error: shared library "gphoto2.2" does not exist a check of the "pkg_inf -L" shows that the libs are missing: ... ls: /usr/local/lib/libgphoto2/2.4.11/sq905.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/st2205.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/stv0674.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/stv0680.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/sx330z.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/topfield.a: No such file or directory ls: /usr/local/lib/libgphoto2/2.4.11/toshiba_pdrm11.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/disk.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/ptpip.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/serial.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/usb.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/usbdiskdirect.a: No such file or directory ls: /usr/local/lib/libgphoto2_port/0.8.0/usbscsi.a: No such file or directory ls: /usr/local/lib/libgphoto2.a: No such file or directory ls: /usr/local/lib/libgphoto2.so.2: No such file or directory ls: /usr/local/lib/libgphoto2_port.a: No such file or directory ls: /usr/local/lib/libgphoto2_port.so.0: No such file or directory ls: /usr/local/libdata/pkgconfig/libgphoto2.pc: No such file or directory ls: /usr/local/libdata/pkgconfig/libgphoto2_port.pc: No such file or directory -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 13:26:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA178106564A; Fri, 4 Nov 2011 13:26:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 69B468FC17; Fri, 4 Nov 2011 13:26:38 +0000 (UTC) Received: from [89.204.137.190] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMJn0-0002T8-2K; Fri, 04 Nov 2011 14:26:37 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA4DQghO001391; Fri, 4 Nov 2011 14:26:42 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA4DQfYO001390; Fri, 4 Nov 2011 14:26:41 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 14:26:41 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Message-ID: <20111104132640.GA1378@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.137.190 Cc: novel@freebsd.org Subject: 10-CURRENT && ports/security/p11-kit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 13:26:38 -0000 ports/security/p11-kit (requested by ports/graphics/evince via gnome) does not build: caracas# pwd /usr/ports/security/p11-kit caracas# make ===> Building for p11-kit-0.8 ... checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking whether to use NLS... no ./configure: 14377: Syntax error: word unexpected (expecting ")") *** Error code 2 -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 13:33:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C47106564A; Fri, 4 Nov 2011 13:33:49 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA338FC14; Fri, 4 Nov 2011 13:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=4slA3WF7dtBy8FSXia+XlpXdPTkAza8cqbr6W0ZbE24=; b=i5RX1otQpP4rCGrUM0N9EYrT8K3M+gHnfybbWmnEeL5SDvgX/ewaCiGK7PzmpgS/+p8DUkirtD0juMWgeAeUTwsTSKDNB37A7QEmEqXnR6JtPCNjx10ca5twWWEoQi5cggVMyd/YHAhAGCcXamCQtfEM1e9DuezAigvFpsyZAhc=; Received: from [81.23.24.104] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RMJty-000Bo0-R7 ; Fri, 04 Nov 2011 15:33:47 +0200 Date: Fri, 4 Nov 2011 15:33:18 +0200 From: Ivan Klymenko To: Jeff Roberson , Andriy Gapon Message-ID: <20111104153318.0f3b9c9a@nonamehost.> In-Reply-To: References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 13:33:49 -0000 Maybe useful the following information: This problem appears not to all architectures and types of CPU. on the Russian forums http://www.bsdportal.ru/viewtopic.php?t=24900 http://forum.lissyara.su/viewtopic.php?f=45&t=34641&sid=aa596f0b70806ba053011da911f9ccae was a brute force to find out that: there is a suspicion that: - for AMD processors, this problem is not observed at all when the number of cores >= 2 - on all single-core is the problem - only for some models with Intel >= 2 cores of the problem is not found Perhaps, after all, avg@ rights (Subject: couple of sched_ule issues), that is not working properly mechanism rebalancing and to determine the topology of CPU? All converge, because my patch ( http://docs.freebsd.org/cgi/mid.cgi?20111022132817.35db5ccd ) for SMP systems just do respite for rebalancing, which eliminates the problem with interactivity ... Thanks! From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 14:16:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5181106566B for ; Fri, 4 Nov 2011 14:16:42 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 776BD8FC08 for ; Fri, 4 Nov 2011 14:16:42 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Fri, 4 Nov 2011 10:05:53 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 8966433C02; Fri, 4 Nov 2011 10:05:53 -0400 (EDT) Date: Fri, 4 Nov 2011 10:05:53 -0400 From: Ed Maste To: Craig Rodrigues Message-ID: <20111104140553.GA39317@sandvine.com> References: <20111028204706.GA57454@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Nima Misaghian Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:16:42 -0000 On Thu, Nov 03, 2011 at 07:05:54PM -0700, Craig Rodrigues wrote: > On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian wrote: > > Hi, > > > > I have got code developed by Andre Albsmeier that is capable of > > programming firmware of hard drives from several vendors and ?turned > > it into a camcontrol command. > ... > > I think the patch is fine in its current form. Very few "regular > users" need to reprogram hard drive firmware. > It is a special administrative operation. Thanks for reviewing. I discussed it with Ken Merry off-list and he mentioned the format command, which has a similar requirement. It has a -y flag to confirm the operation from the command line, and prompts for confirmation if the flag is not provided. Mirroring that behaviour sounds reasonable to me; we'll update the patch with that change before it gets committed. -Ed From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 14:54:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1E1106564A for ; Fri, 4 Nov 2011 14:54:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 756548FC08 for ; Fri, 4 Nov 2011 14:54:52 +0000 (UTC) Received: by gyd5 with SMTP id 5so2188614gyd.13 for ; Fri, 04 Nov 2011 07:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3AcJ2hBqrE3utjJUpnEsGghLToUP54npoBpssldCeEo=; b=qe7yCPi/Phj+fqoZ/ahthFnv7yikbRkrhDmBH1dVxmz7mS6nRluo3xQHso26XATvJP IyvAPKN2Ab+NMWwN9xu+IzpJ5/ZQAyTU+5g3n6a78xVg1NF/dwBsin+f4qTxpF0WvIhd QEZgLDiWKNpUNPL/sM6V/otI/9ZPba5lyj5UY= Received: by 10.236.124.17 with SMTP id w17mr20956373yhh.126.1320418491655; Fri, 04 Nov 2011 07:54:51 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id c44sm15667297yhm.5.2011.11.04.07.54.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 07:54:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Fri, 4 Nov 2011 07:54:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1084) Cc: Warren Block , Alexander Yerenkow , freebsd-current@freebsd.org Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:54:52 -0000 On Nov 3, 2011, at 9:31 PM, Daniel O'Connor wrote: >=20 > On 19/10/2011, at 21:19, Alexander Yerenkow wrote: >> I can't specify to pkg_add that it should treat /zpool0/testroot as = root, as >> I need (so record really should be @cwd /usr/local) >> Instead, pkg_add allows me to make chroot, which as you understand is = not >> good (In specified chroot all required by pkg* binaries/libraries = must >> exists, unfortunately I can't specify some empty dir and install = there). >=20 > Hmmm, why is it empty? > When I have made something analogous I did an installkernel/world into = a directory and then chroot'd in there and built ports. There is no = reason you couldn't pkg_add from a local mirror (or nullfs mount a local = package mirror directory into the chroot). The chroot option via the pkg_install tools is broken. Look = through the PR database for more details. >> Why is that? Because there is +INSTALL script in packages, in which >> package/port system allows execute any code/script written by porter. >=20 > This is a feature ;) Except it doesn't work too terribly well on cross-compiled = images or in installed worlds where the image version and the host = system may not match and the script digs into the info that it needs = from the kernel (one example is available here: = http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-07/msg00597.h= tml , but I've seen other issues if things are executing something like = ifconfig, geom, etc). This would probably be less of an issue if = BUILD_DEPENDS was compiled with the host architecture instead of the = target architecture, so the tools could be run on the build host, but = assuming that that level of intelligence exists within ports is = incorrect. >> To summarize my efforts: >> I checked 21195 packages; >> I found 880 install scripts; >>=20 >> 3 scripts contains plain "exit 0" >> 8 install scripts contains some perl code; >> 17 scripts contains some additional "install" commands; >> 70 scripts contains some chgroup/chown actions (which probably could = be done >> by specifying mtree file?...) >> 75 contains uncategorized actions (print of license, some interactive >> questions, ghostscript actions, tex, fonts etc.) >> 161 scripts contains some file commands, like (ld / cp / mv, creating >> backups, creating configs if they aren't exists etc. ) >> 166 scripts contains useradd/groupadd commands (many similar = constructions, >> not too hard to move this to .mk, in pkgng group/users can be = specified in >> yaml config) >> 380 contains pear component registration (md5 -q * | uniq - produces >> exactly one result, so these all scripts are really one, could be = moved to >> some pear.mk) >=20 > Interesting stats, thanks for taking the time to do the analysis. >=20 > I think one of the reasons pkg_add is so slow is that it copies = everything to a staging directory, then copies the files.. This is very = tedious (obviously). I wonder if it could be modified to have a "stream" = mode where it unpacks directly into the target FS. >=20 > Alternatively you could cut it in 2 conceptually and modify pkg_add so = it can run it a mode where it just unpacks to a staging area, and = another mode where it copies from the staging area to the destination. This is also why "ports" is "faster" -- it hacks around the = double piped tar copy and installs _directly_ to the live system and = sets up the metadata after the fact, which needless to say.. isn't very = atomic :/.. That and while .bz2 compresses better, for most cases than .gz, = compressing/decompressing is slower with .bz2 than with .gz. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 15:09:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B5AE106566B; Fri, 4 Nov 2011 15:09:13 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF278FC12; Fri, 4 Nov 2011 15:09:12 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 3D3E9291280; Fri, 4 Nov 2011 10:09:12 -0500 (CDT) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 2ED6C2975F3; Fri, 4 Nov 2011 10:09:12 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id ty+ivorUF8rq; Fri, 4 Nov 2011 10:09:12 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id DA38429129F; Fri, 4 Nov 2011 10:09:10 -0500 (CDT) Message-ID: <4EB40015.5040100@rice.edu> Date: Fri, 04 Nov 2011 10:09:09 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111104100828.GG50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:09:13 -0000 On 11/04/2011 05:08, Kostik Belousov wrote: > On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote: >> On 11/03/2011 08:24, Kostik Belousov wrote: >>> On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote: >>>> On 11/02/2011 05:32, Andriy Gapon wrote: >>>>> [restored cc: to the original poster] >>>>> As Bruce Evans has pointed to me privately [I am not sure why privately], >>>>> there >>>>> is already an example in i386 and amd64 atomic.h, where operations are >>>>> inlined >>>>> for a kernel build, but presented as real (external) functions for a >>>>> module >>>>> build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE. >>>>> >>>>> I think that the same treatment could/should be applied to vm_page_*lock* >>>>> operations defined in sys/vm/vm_page.h. >>>> *snip* >>>> >>>> Yes, it should be. There are without question legitimate reasons for a >>>> module to acquire a page lock. >>> I agree. Also, I think that we should use the opportunity to also isolate >>> the modules from the struct vm_page layout changes. As example, I converted >>> nfsclient.ko. >>> >> I would suggest introducing the vm_page_bits_t change first. If, at the >> same time, you change the return type from the function vm_page_bits() >> to use vm_page_bits_t, then I believe it is straightforward to fix all >> of the places in vm_page.c that don't properly handle a 32 KB page size. > Ok, I think this is orhtohonal to the ABI issue. The vm_page_bits_t > applied. Agreed, which is why I wanted to separate the two things. I've made a few comments below. > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index f14da4a..f22c34a 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -137,7 +137,7 @@ SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD, > > static uma_zone_t fakepg_zone; > > -static void vm_page_clear_dirty_mask(vm_page_t m, int pagebits); > +static void vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits); > static void vm_page_queue_remove(int queue, vm_page_t m); > static void vm_page_enqueue(int queue, vm_page_t m); > static void vm_page_init_fakepg(void *dummy); > @@ -2350,7 +2350,7 @@ retrylookup: > * > * Inputs are required to range within a page. > */ > -int > +vm_page_bits_t > vm_page_bits(int base, int size) > { > int first_bit; > @@ -2367,7 +2367,8 @@ vm_page_bits(int base, int size) > first_bit = base>> DEV_BSHIFT; > last_bit = (base + size - 1)>> DEV_BSHIFT; > > - return ((2<< last_bit) - (1<< first_bit)); > + return (((vm_page_bits_t)2<< last_bit) - > + ((vm_page_bits_t)1<< first_bit)); > } > > /* > @@ -2426,7 +2427,7 @@ vm_page_set_valid(vm_page_t m, int base, int size) > * Clear the given bits from the specified page's dirty field. > */ > static __inline void > -vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > +vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits) > { > uintptr_t addr; > #if PAGE_SIZE< 16384 > @@ -2455,7 +2456,6 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > */ > addr = (uintptr_t)&m->dirty; > #if PAGE_SIZE == 32768 > -#error pagebits too short > atomic_clear_64((uint64_t *)addr, pagebits); > #elif PAGE_SIZE == 16384 > atomic_clear_32((uint32_t *)addr, pagebits); > @@ -2492,8 +2492,8 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > void > vm_page_set_validclean(vm_page_t m, int base, int size) > { > - u_long oldvalid; > - int endoff, frag, pagebits; > + vm_page_bits_t oldvalid, pagebits; > + int endoff, frag; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > if (size == 0) /* handle degenerate case */ > @@ -2505,7 +2505,7 @@ vm_page_set_validclean(vm_page_t m, int base, int size) > * first block. > */ > if ((frag = base& ~(DEV_BSIZE - 1)) != base&& > - (m->valid& (1<< (base>> DEV_BSHIFT))) == 0) > + (m->valid& ((vm_page_bits_t)1<< (base>> DEV_BSHIFT))) == 0) > pmap_zero_page_area(m, frag, base - frag); > > /* > @@ -2515,7 +2515,7 @@ vm_page_set_validclean(vm_page_t m, int base, int size) > */ > endoff = base + size; > if ((frag = endoff& ~(DEV_BSIZE - 1)) != endoff&& > - (m->valid& (1<< (endoff>> DEV_BSHIFT))) == 0) > + (m->valid& ((vm_page_bits_t)1<< (endoff>> DEV_BSHIFT))) == 0) > pmap_zero_page_area(m, endoff, > DEV_BSIZE - (endoff& (DEV_BSIZE - 1))); > > @@ -2585,7 +2585,7 @@ vm_page_clear_dirty(vm_page_t m, int base, int size) > void > vm_page_set_invalid(vm_page_t m, int base, int size) > { > - int bits; > + vm_page_bits_t bits; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > KASSERT((m->oflags& VPO_BUSY) == 0, I believe that a cast is still needed in vm_page_zero_invalid(): (m->valid & (1 << i)) > @@ -2656,9 +2656,10 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) > int > vm_page_is_valid(vm_page_t m, int base, int size) > { > - int bits = vm_page_bits(base, size); > + vm_page_bits_t bits; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > + bits = vm_page_bits(base, size); > if (m->valid&& ((m->valid& bits) == bits)) > return 1; > else > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 23637bb..7d1a529 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -113,6 +113,21 @@ > > TAILQ_HEAD(pglist, vm_page); > > +#if PAGE_SIZE == 4096 > +#define VM_PAGE_BITS_ALL 0xffu > +typedef uint8_t vm_page_bits_t; > +#elif PAGE_SIZE == 8192 > +#define VM_PAGE_BITS_ALL 0xffffu > +typedef uint16_t vm_page_bits_t; > +#elif PAGE_SIZE == 16384 > +#define VM_PAGE_BITS_ALL 0xffffffffu > +typedef uint32_t vm_page_bits_t; > +#elif PAGE_SIZE == 32768 > +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu > +typedef uint64_t vm_page_bits_t; > +#endif > + > + Is there any reason for the extra blank line? > struct vm_page { > TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q) */ > TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ > @@ -138,19 +153,8 @@ struct vm_page { > /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ > /* so, on normal X86 kernels, they must be at least 8 bits wide */ > /* In reality, support for 32KB pages is not fully implemented. */ The previous comment can now be eliminated. > -#if PAGE_SIZE == 4096 > - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 8192 > - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 16384 > - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 32768 > - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#endif > + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ > + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > }; > > /* > @@ -403,7 +407,7 @@ void vm_page_clear_dirty (vm_page_t, int, int); > void vm_page_set_invalid (vm_page_t, int, int); > int vm_page_is_valid (vm_page_t, int, int); > void vm_page_test_dirty (vm_page_t); > -int vm_page_bits (int, int); > +vm_page_bits_t vm_page_bits (int, int); Might as well change this to: vm_page_bits(int base, int size) > void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid); > void vm_page_free_toq(vm_page_t m); > void vm_page_zero_idle_wakeup(void); > diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c > index e3222cb..cd2658d 100644 > --- a/sys/vm/vnode_pager.c > +++ b/sys/vm/vnode_pager.c > @@ -486,15 +486,16 @@ vnode_pager_input_smlfs(object, m) > vm_object_t object; > vm_page_t m; > { > - int bits, i; > struct vnode *vp; > struct bufobj *bo; > struct buf *bp; > struct sf_buf *sf; > daddr_t fileaddr; > vm_offset_t bsize; > - int error = 0; > + vm_page_bits_t bits; > + int error, i; > > + error = 0; > vp = object->handle; > if (vp->v_iflag& VI_DOOMED) > return VM_PAGER_BAD; > Looks good. Alan From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 15:30:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075F11065672; Fri, 4 Nov 2011 15:30:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 642218FC1C; Fri, 4 Nov 2011 15:30:09 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA4FU5Lk062022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2011 17:30:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA4FU5wv044357; Fri, 4 Nov 2011 17:30:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA4FU5eg044356; Fri, 4 Nov 2011 17:30:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Nov 2011 17:30:05 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111104153004.GK50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FdRGtB4gDWnqYrPg" Content-Disposition: inline In-Reply-To: <4EB40015.5040100@rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:30:11 -0000 --FdRGtB4gDWnqYrPg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2011 at 10:09:09AM -0500, Alan Cox wrote: > On 11/04/2011 05:08, Kostik Belousov wrote: > >On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote: > >>I would suggest introducing the vm_page_bits_t change first. If, at the > >>same time, you change the return type from the function vm_page_bits() > >>to use vm_page_bits_t, then I believe it is straightforward to fix all > >>of the places in vm_page.c that don't properly handle a 32 KB page size. > >Ok, I think this is orhtohonal to the ABI issue. The vm_page_bits_t > >applied. >=20 > Agreed, which is why I wanted to separate the two things. >=20 > I've made a few comments below. =2E.. > Looks good. I will make universe the patch below. Any further notes ? diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c index f14da4a..f398453 100644 --- a/sys/vm/vm_page.c +++ b/sys/vm/vm_page.c @@ -137,7 +137,7 @@ SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD, =20 static uma_zone_t fakepg_zone; =20 -static void vm_page_clear_dirty_mask(vm_page_t m, int pagebits); +static void vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits); static void vm_page_queue_remove(int queue, vm_page_t m); static void vm_page_enqueue(int queue, vm_page_t m); static void vm_page_init_fakepg(void *dummy); @@ -2350,7 +2350,7 @@ retrylookup: * * Inputs are required to range within a page. */ -int +vm_page_bits_t vm_page_bits(int base, int size) { int first_bit; @@ -2367,7 +2367,8 @@ vm_page_bits(int base, int size) first_bit =3D base >> DEV_BSHIFT; last_bit =3D (base + size - 1) >> DEV_BSHIFT; =20 - return ((2 << last_bit) - (1 << first_bit)); + return (((vm_page_bits_t)2 << last_bit) - + ((vm_page_bits_t)1 << first_bit)); } =20 /* @@ -2426,7 +2427,7 @@ vm_page_set_valid(vm_page_t m, int base, int size) * Clear the given bits from the specified page's dirty field. */ static __inline void -vm_page_clear_dirty_mask(vm_page_t m, int pagebits) +vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits) { uintptr_t addr; #if PAGE_SIZE < 16384 @@ -2455,7 +2456,6 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) */ addr =3D (uintptr_t)&m->dirty; #if PAGE_SIZE =3D=3D 32768 -#error pagebits too short atomic_clear_64((uint64_t *)addr, pagebits); #elif PAGE_SIZE =3D=3D 16384 atomic_clear_32((uint32_t *)addr, pagebits); @@ -2492,8 +2492,8 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) void vm_page_set_validclean(vm_page_t m, int base, int size) { - u_long oldvalid; - int endoff, frag, pagebits; + vm_page_bits_t oldvalid, pagebits; + int endoff, frag; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); if (size =3D=3D 0) /* handle degenerate case */ @@ -2505,7 +2505,7 @@ vm_page_set_validclean(vm_page_t m, int base, int siz= e) * first block. */ if ((frag =3D base & ~(DEV_BSIZE - 1)) !=3D base && - (m->valid & (1 << (base >> DEV_BSHIFT))) =3D=3D 0) + (m->valid & ((vm_page_bits_t)1 << (base >> DEV_BSHIFT))) =3D=3D 0) pmap_zero_page_area(m, frag, base - frag); =20 /* @@ -2515,7 +2515,7 @@ vm_page_set_validclean(vm_page_t m, int base, int siz= e) */ endoff =3D base + size; if ((frag =3D endoff & ~(DEV_BSIZE - 1)) !=3D endoff && - (m->valid & (1 << (endoff >> DEV_BSHIFT))) =3D=3D 0) + (m->valid & ((vm_page_bits_t)1 << (endoff >> DEV_BSHIFT))) =3D=3D 0) pmap_zero_page_area(m, endoff, DEV_BSIZE - (endoff & (DEV_BSIZE - 1))); =20 @@ -2585,7 +2585,7 @@ vm_page_clear_dirty(vm_page_t m, int base, int size) void vm_page_set_invalid(vm_page_t m, int base, int size) { - int bits; + vm_page_bits_t bits; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); KASSERT((m->oflags & VPO_BUSY) =3D=3D 0, @@ -2625,7 +2625,7 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) */ for (b =3D i =3D 0; i <=3D PAGE_SIZE / DEV_BSIZE; ++i) { if (i =3D=3D (PAGE_SIZE / DEV_BSIZE) ||=20 - (m->valid & (1 << i)) + (m->valid & ((vm_page_bits_t)1 << i)) ) { if (i > b) { pmap_zero_page_area(m,=20 @@ -2656,9 +2656,10 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) int vm_page_is_valid(vm_page_t m, int base, int size) { - int bits =3D vm_page_bits(base, size); + vm_page_bits_t bits; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); + bits =3D vm_page_bits(base, size); if (m->valid && ((m->valid & bits) =3D=3D bits)) return 1; else diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 23637bb..e3eb08c 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -113,6 +113,20 @@ =20 TAILQ_HEAD(pglist, vm_page); =20 +#if PAGE_SIZE =3D=3D 4096 +#define VM_PAGE_BITS_ALL 0xffu +typedef uint8_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 8192 +#define VM_PAGE_BITS_ALL 0xffffu +typedef uint16_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 16384 +#define VM_PAGE_BITS_ALL 0xffffffffu +typedef uint32_t vm_page_bits_t; +#elif PAGE_SIZE =3D=3D 32768 +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu +typedef uint64_t vm_page_bits_t; +#endif + struct vm_page { TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q)= */ TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ @@ -137,20 +151,8 @@ struct vm_page { u_char busy; /* page busy count (O) */ /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ /* so, on normal X86 kernels, they must be at least 8 bits wide */ - /* In reality, support for 32KB pages is not fully implemented. */ -#if PAGE_SIZE =3D=3D 4096 - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 8192 - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 16384 - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#elif PAGE_SIZE =3D=3D 32768 - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ -#endif + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ }; =20 /* @@ -403,7 +405,7 @@ void vm_page_clear_dirty (vm_page_t, int, int); void vm_page_set_invalid (vm_page_t, int, int); int vm_page_is_valid (vm_page_t, int, int); void vm_page_test_dirty (vm_page_t); -int vm_page_bits (int, int); +vm_page_bits_t vm_page_bits(int base, int size); void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid); void vm_page_free_toq(vm_page_t m); void vm_page_zero_idle_wakeup(void); diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c index e3222cb..cd2658d 100644 --- a/sys/vm/vnode_pager.c +++ b/sys/vm/vnode_pager.c @@ -486,15 +486,16 @@ vnode_pager_input_smlfs(object, m) vm_object_t object; vm_page_t m; { - int bits, i; struct vnode *vp; struct bufobj *bo; struct buf *bp; struct sf_buf *sf; daddr_t fileaddr; vm_offset_t bsize; - int error =3D 0; + vm_page_bits_t bits; + int error, i; =20 + error =3D 0; vp =3D object->handle; if (vp->v_iflag & VI_DOOMED) return VM_PAGER_BAD; --FdRGtB4gDWnqYrPg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk60BPwACgkQC3+MBN1Mb4jt6gCg2BmcnCD1X9++gR2OZxqz2EXx ujIAoIEt7WnjQoQJlfzZXkPPaTU9e/1g =/hl5 -----END PGP SIGNATURE----- --FdRGtB4gDWnqYrPg-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 15:48:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0861E1065670; Fri, 4 Nov 2011 15:48:50 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id BD3568FC1B; Fri, 4 Nov 2011 15:48:49 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 9546B291AB4; Fri, 4 Nov 2011 10:48:48 -0500 (CDT) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 85C06297603; Fri, 4 Nov 2011 10:48:48 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id B67p-ZQtdalS; Fri, 4 Nov 2011 10:48:48 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 74FD4291AB4; Fri, 4 Nov 2011 10:48:46 -0500 (CDT) Message-ID: <4EB4095D.3030303@rice.edu> Date: Fri, 04 Nov 2011 10:48:45 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111104153004.GK50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:48:50 -0000 On 11/04/2011 10:30, Kostik Belousov wrote: > On Fri, Nov 04, 2011 at 10:09:09AM -0500, Alan Cox wrote: >> On 11/04/2011 05:08, Kostik Belousov wrote: >>> On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote: >>>> I would suggest introducing the vm_page_bits_t change first. If, at the >>>> same time, you change the return type from the function vm_page_bits() >>>> to use vm_page_bits_t, then I believe it is straightforward to fix all >>>> of the places in vm_page.c that don't properly handle a 32 KB page size. >>> Ok, I think this is orhtohonal to the ABI issue. The vm_page_bits_t >>> applied. >> Agreed, which is why I wanted to separate the two things. >> >> I've made a few comments below. > ... > >> Looks good. > I will make universe the patch below. Any further notes ? > Only one. See below. > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index f14da4a..f398453 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -137,7 +137,7 @@ SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD, > > static uma_zone_t fakepg_zone; > > -static void vm_page_clear_dirty_mask(vm_page_t m, int pagebits); > +static void vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits); > static void vm_page_queue_remove(int queue, vm_page_t m); > static void vm_page_enqueue(int queue, vm_page_t m); > static void vm_page_init_fakepg(void *dummy); > @@ -2350,7 +2350,7 @@ retrylookup: > * > * Inputs are required to range within a page. > */ > -int > +vm_page_bits_t > vm_page_bits(int base, int size) > { > int first_bit; > @@ -2367,7 +2367,8 @@ vm_page_bits(int base, int size) > first_bit = base>> DEV_BSHIFT; > last_bit = (base + size - 1)>> DEV_BSHIFT; > > - return ((2<< last_bit) - (1<< first_bit)); > + return (((vm_page_bits_t)2<< last_bit) - > + ((vm_page_bits_t)1<< first_bit)); > } > > /* > @@ -2426,7 +2427,7 @@ vm_page_set_valid(vm_page_t m, int base, int size) > * Clear the given bits from the specified page's dirty field. > */ > static __inline void > -vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > +vm_page_clear_dirty_mask(vm_page_t m, vm_page_bits_t pagebits) > { > uintptr_t addr; > #if PAGE_SIZE< 16384 > @@ -2455,7 +2456,6 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > */ > addr = (uintptr_t)&m->dirty; > #if PAGE_SIZE == 32768 > -#error pagebits too short > atomic_clear_64((uint64_t *)addr, pagebits); > #elif PAGE_SIZE == 16384 > atomic_clear_32((uint32_t *)addr, pagebits); > @@ -2492,8 +2492,8 @@ vm_page_clear_dirty_mask(vm_page_t m, int pagebits) > void > vm_page_set_validclean(vm_page_t m, int base, int size) > { > - u_long oldvalid; > - int endoff, frag, pagebits; > + vm_page_bits_t oldvalid, pagebits; > + int endoff, frag; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > if (size == 0) /* handle degenerate case */ > @@ -2505,7 +2505,7 @@ vm_page_set_validclean(vm_page_t m, int base, int size) > * first block. > */ > if ((frag = base& ~(DEV_BSIZE - 1)) != base&& > - (m->valid& (1<< (base>> DEV_BSHIFT))) == 0) > + (m->valid& ((vm_page_bits_t)1<< (base>> DEV_BSHIFT))) == 0) > pmap_zero_page_area(m, frag, base - frag); > > /* > @@ -2515,7 +2515,7 @@ vm_page_set_validclean(vm_page_t m, int base, int size) > */ > endoff = base + size; > if ((frag = endoff& ~(DEV_BSIZE - 1)) != endoff&& > - (m->valid& (1<< (endoff>> DEV_BSHIFT))) == 0) > + (m->valid& ((vm_page_bits_t)1<< (endoff>> DEV_BSHIFT))) == 0) > pmap_zero_page_area(m, endoff, > DEV_BSIZE - (endoff& (DEV_BSIZE - 1))); > > @@ -2585,7 +2585,7 @@ vm_page_clear_dirty(vm_page_t m, int base, int size) > void > vm_page_set_invalid(vm_page_t m, int base, int size) > { > - int bits; > + vm_page_bits_t bits; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > KASSERT((m->oflags& VPO_BUSY) == 0, > @@ -2625,7 +2625,7 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) > */ > for (b = i = 0; i<= PAGE_SIZE / DEV_BSIZE; ++i) { > if (i == (PAGE_SIZE / DEV_BSIZE) || > - (m->valid& (1<< i)) > + (m->valid& ((vm_page_bits_t)1<< i)) > ) { > if (i> b) { > pmap_zero_page_area(m, While we're here, we might as well fix the old style bug above by moving the ") {" to the proper place. > @@ -2656,9 +2656,10 @@ vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) > int > vm_page_is_valid(vm_page_t m, int base, int size) > { > - int bits = vm_page_bits(base, size); > + vm_page_bits_t bits; > > VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); > + bits = vm_page_bits(base, size); > if (m->valid&& ((m->valid& bits) == bits)) > return 1; > else > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 23637bb..e3eb08c 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -113,6 +113,20 @@ > > TAILQ_HEAD(pglist, vm_page); > > +#if PAGE_SIZE == 4096 > +#define VM_PAGE_BITS_ALL 0xffu > +typedef uint8_t vm_page_bits_t; > +#elif PAGE_SIZE == 8192 > +#define VM_PAGE_BITS_ALL 0xffffu > +typedef uint16_t vm_page_bits_t; > +#elif PAGE_SIZE == 16384 > +#define VM_PAGE_BITS_ALL 0xffffffffu > +typedef uint32_t vm_page_bits_t; > +#elif PAGE_SIZE == 32768 > +#define VM_PAGE_BITS_ALL 0xfffffffffffffffflu > +typedef uint64_t vm_page_bits_t; > +#endif > + > struct vm_page { > TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free list (Q) */ > TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */ > @@ -137,20 +151,8 @@ struct vm_page { > u_char busy; /* page busy count (O) */ > /* NOTE that these must support one bit per DEV_BSIZE in a page!!! */ > /* so, on normal X86 kernels, they must be at least 8 bits wide */ > - /* In reality, support for 32KB pages is not fully implemented. */ > -#if PAGE_SIZE == 4096 > - uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint8_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 8192 > - uint16_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint16_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 16384 > - uint32_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint32_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#elif PAGE_SIZE == 32768 > - uint64_t valid; /* map of valid DEV_BSIZE chunks (O) */ > - uint64_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > -#endif > + vm_page_bits_t valid; /* map of valid DEV_BSIZE chunks (O) */ > + vm_page_bits_t dirty; /* map of dirty DEV_BSIZE chunks (M) */ > }; > > /* > @@ -403,7 +405,7 @@ void vm_page_clear_dirty (vm_page_t, int, int); > void vm_page_set_invalid (vm_page_t, int, int); > int vm_page_is_valid (vm_page_t, int, int); > void vm_page_test_dirty (vm_page_t); > -int vm_page_bits (int, int); > +vm_page_bits_t vm_page_bits(int base, int size); > void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid); > void vm_page_free_toq(vm_page_t m); > void vm_page_zero_idle_wakeup(void); > diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c > index e3222cb..cd2658d 100644 > --- a/sys/vm/vnode_pager.c > +++ b/sys/vm/vnode_pager.c > @@ -486,15 +486,16 @@ vnode_pager_input_smlfs(object, m) > vm_object_t object; > vm_page_t m; > { > - int bits, i; > struct vnode *vp; > struct bufobj *bo; > struct buf *bp; > struct sf_buf *sf; > daddr_t fileaddr; > vm_offset_t bsize; > - int error = 0; > + vm_page_bits_t bits; > + int error, i; > > + error = 0; > vp = object->handle; > if (vp->v_iflag& VI_DOOMED) > return VM_PAGER_BAD; From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:03:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D55A106566C; Fri, 4 Nov 2011 16:03:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9128FC0A; Fri, 4 Nov 2011 16:03:43 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA4G3d9Y070748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2011 18:03:40 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA4G3dA4044505; Fri, 4 Nov 2011 18:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA4G3ds3044504; Fri, 4 Nov 2011 18:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Nov 2011 18:03:39 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111104160339.GM50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="02fnLrunYGada9IV" Content-Disposition: inline In-Reply-To: <4EB4095D.3030303@rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:03:44 -0000 --02fnLrunYGada9IV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2011 at 10:48:45AM -0500, Alan Cox wrote: > On 11/04/2011 10:30, Kostik Belousov wrote: > > for (b =3D i =3D 0; i<=3D PAGE_SIZE / DEV_BSIZE; ++i) { > > if (i =3D=3D (PAGE_SIZE / DEV_BSIZE) || > >- (m->valid& (1<< i)) > >+ (m->valid& ((vm_page_bits_t)1<< i)) > > ) { > > if (i> b) { > > pmap_zero_page_area(m, >=20 > While we're here, we might as well fix the old style bug above by moving= =20 > the ") {" to the proper place. Fixed, this does not warrant the universe restart. --02fnLrunYGada9IV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk60DNoACgkQC3+MBN1Mb4jG7gCeKZ8HB+fEhV0PhE5dRhQEbdkD V3gAniUzbhG3Zj6LW5CPP6uOotJicbgx =nGBY -----END PGP SIGNATURE----- --02fnLrunYGada9IV-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:16:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D90E106564A for ; Fri, 4 Nov 2011 16:16:24 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 372998FC14 for ; Fri, 4 Nov 2011 16:16:23 +0000 (UTC) Received: by iabz21 with SMTP id z21so4337995iab.13 for ; Fri, 04 Nov 2011 09:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mk1TSvhmtZp54WVP7surmY/4UAcIau+sDaZ88SSQdPc=; b=QLoFZ4wYRfXSGhXyChux+iq3sBArjuwXPx+IkUTbTBPxCItsHXw1hHk7hTd789ajoH dmTXJwWSKyAmKdPzMeEbMVr40+hl7ox/3FnoZ3w09AmW+8DuGV7AMF4ct9vP7Wnq87uv qFwBFLap31j3ogxLHZQOsmn7IsBdnoqV016ZQ= MIME-Version: 1.0 Received: by 10.231.48.203 with SMTP id s11mr3811116ibf.90.1320423383393; Fri, 04 Nov 2011 09:16:23 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Fri, 4 Nov 2011 09:16:22 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Fri, 4 Nov 2011 09:16:22 -0700 (PDT) In-Reply-To: <003101cc95ca$80ec8b60$82c5a220$@com> References: <4EAB2D38.4040200@feral.com> <003101cc95ca$80ec8b60$82c5a220$@com> Date: Fri, 4 Nov 2011 16:16:22 +0000 Message-ID: From: Chris Rees To: Pegasus Mc Cleaft Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mj@feral.com, freebsd-current@freebsd.org, "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" Subject: RE: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:16:24 -0000 On 29 Oct 2011 00:38, "Pegasus Mc Cleaft" wrote: > > >> The linux hdparm program is so paranoid about this that you have to us= e > >> extra arguments like "--yes-really-destroy-my-disk-drive" to do this. > > > >I concur. Loudly. The ability to brick your hardware is just too > >large to not make people go through the "I tell you three times" > >dance. It's not like people will do this often enough that the > >pain will be fatal. And if it is, they ought to be bright enough to > >know how to automate the process. > > > >--lyndon > > Hi Lyndon and group, > > I tend to disagree that there should be such argument antics > employed to protect an operation such as this. Being root should be the only > protection needed (of course, that's only my opinion). I don=92t want to have > to look up in a man page what magic token I need to add to prove to the > utility that I understand the consequences of what I am about to do. I > personally wouldn't mind a simple "Are you sure?" if the magic token is not > added on the command line, however. > > To me, the only difference between borking a drive because of bad > firmware and typing "rm -rf *" from root is about =A340. You still lose = at > least a day rebuilding/restoring everything. > You clearly haven't bought a hard drive recently. Chris From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:28:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3160A106566B for ; Fri, 4 Nov 2011 16:28:53 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E49F98FC18 for ; Fri, 4 Nov 2011 16:28:52 +0000 (UTC) Received: by vws11 with SMTP id 11so3516705vws.13 for ; Fri, 04 Nov 2011 09:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=aCmBEmWLsCHuuUIdEXEeGBsyoU+a72SlOtpc2AaCtCA=; b=eJv76oI/q27FqB2EusWBt+UmibqPj/UOAS7qoKLoxCnccKefwFNJMzMAd/+fZe3wKF hsjIKRUE/odgMWBc2X6pwXb82xzgjWkeMWZtlHVkX3yVfdy2ptJh/XdhnyoMkxJP6q29 D7SSJLr6nEG6oSyM9J65OkE7vDrnauC0dLijk= MIME-Version: 1.0 Received: by 10.52.17.112 with SMTP id n16mr15284905vdd.70.1320422788795; Fri, 04 Nov 2011 09:06:28 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 09:06:28 -0700 (PDT) Date: Sat, 5 Nov 2011 00:06:28 +0800 Message-ID: From: Archy Cho To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rizzo@iet.unipi.it Subject: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:28:53 -0000 Hello I am very happy to see freebsd could have such network performance with netmap , since I am currently using freebsd as core routers instead of cisco. I tried to re-compile the freebsd 8.2 kernel to test , however , I could not complete the task ( both i386 and amd64 ), I could only success at 9.0-RC-1. Here is my task and error message, cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router cd /tmp/netmap/sys/ cp -R * /usr/src/sys/ cd /usr/src/ patch -p < /tmp/netmap/head-netmap.diff echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf make buildkernel KERNCONF=Netmap-Router make installkernel KERNCONF=Netmap-Router -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in this function) ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is reported only once ../../../dev/e1000/if_em.c:4012: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/i386/compile/Netmap-Router Any hint of error message ? More questions , I seldom facing DDOS , whatever using polling or not , 1Gbps link with 64bytes packet will cause CPU 100% , if a freebsd box compile with netmap , could it have performance boost of routed / ipfw / pf ? From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:33:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BCA7106566B for ; Fri, 4 Nov 2011 16:33:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (unknown [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 34B038FC18 for ; Fri, 4 Nov 2011 16:33:31 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.5/8.14.3) with ESMTP id pA4GX2Q8060540; Fri, 4 Nov 2011 16:33:03 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: "'Chris Rees'" References: <4EAB2D38.4040200@feral.com> <003101cc95ca$80ec8b60$82c5a220$@com> In-Reply-To: Date: Fri, 4 Nov 2011 16:33:04 -0000 Message-ID: <000e01cc9b0f$6dfacef0$49f06cd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybDSjmJBf1abkVSMWt/neB6YNgNgAAQ7qQ Content-Language: en-gb X-Spam-Status: No, score=0.9 required=15.0 tests=BAYES_00,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Cc: "'Lyndon Nerenberg \(VE6BBM/VE7TFX\)'" , freebsd-current@freebsd.org, mj@feral.com Subject: RE: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:33:31 -0000 >> >> To me, the only difference between borking a drive because of=20 >> bad firmware and typing "rm -rf *" from root is about =A340. You = still=20 >> lose at least a day rebuilding/restoring everything. >> > >You clearly haven't bought a hard drive recently. > >Chris Laughs!=20 Yea, trust karma to insert my foot into my mouth when I open it to speak 8-) =20 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:47:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38551065673 for ; Fri, 4 Nov 2011 16:47:11 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 661268FC14 for ; Fri, 4 Nov 2011 16:47:11 +0000 (UTC) Received: by qyc1 with SMTP id 1so1345692qyc.13 for ; Fri, 04 Nov 2011 09:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YeOklDmImYtnZtRvRLvOSsvUql6VZ63Pdabft/kvGQA=; b=JMO+ZkrQumu3qI+WdKghTM80Dj18TThlIB6GVZEncHZWWN7rDVOROoIK9Jsfk3G888 K5QhbnYvQLuX4gP6Te0iSuBhp7957xU9Cilut5/Bp80K48dtAMX9OdQIWiM18bpShbgP 9bB7Yzih3rqkqMoXmtkyYBPu+vmhKi5n9uKKY= MIME-Version: 1.0 Received: by 10.50.169.97 with SMTP id ad1mr13120196igc.35.1320425230532; Fri, 04 Nov 2011 09:47:10 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Fri, 4 Nov 2011 09:47:10 -0700 (PDT) Received: by 10.231.11.140 with HTTP; Fri, 4 Nov 2011 09:47:10 -0700 (PDT) In-Reply-To: <000e01cc9b0f$6dfacef0$49f06cd0$@com> References: <4EAB2D38.4040200@feral.com> <003101cc95ca$80ec8b60$82c5a220$@com> <000e01cc9b0f$6dfacef0$49f06cd0$@com> Date: Fri, 4 Nov 2011 16:47:10 +0000 Message-ID: From: Chris Rees To: Pegasus Mc Cleaft Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mj@feral.com, freebsd-current@freebsd.org, "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" Subject: RE: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:47:11 -0000 On 4 Nov 2011 16:33, "Pegasus Mc Cleaft" wrote: > > >> > >> To me, the only difference between borking a drive because of > >> bad firmware and typing "rm -rf *" from root is about =A340. You stil= l > >> lose at least a day rebuilding/restoring everything. > >> > > > >You clearly haven't bought a hard drive recently. > > > >Chris > > Laughs! > > Yea, trust karma to insert my foot into my mouth when I open it to > speak 8-) > Never mind ;) I do take issue with this viewpoint however; in documentation this is the difference between Caution (you may lose data) and Warning (you may break your hardware). Why should the software be inconsistent with the hardware? I think an option *specifically for this task* would be useful as confirmation. I'm really sorry for bikeshedding; the code and idea is excellent, but I feel this issue is important! Chris From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 16:51:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D7E1065672 for ; Fri, 4 Nov 2011 16:51:04 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B6AE98FC0C for ; Fri, 4 Nov 2011 16:51:03 +0000 (UTC) Received: by faar19 with SMTP id r19so4224327faa.13 for ; Fri, 04 Nov 2011 09:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PcHpmasFXK9kr9c010JFnnusOvSInVEhWOWaA5N5Kho=; b=VaNs0BTzQ21YaQeVbEdIsRq/AaSGe1uXyWHkBZ6Y+MF4SMpQ+GFZA0w0ncz0dYk0SY kk4NiWdrdEp3GR2W8468BLu2oH32d+UiB/4uUekwVMgrPR6Hb/gcqFKJQanBaPMhl/7h CY5AambqCSjHOFJdPU2Vxgjzqh1EzeW4Pk9KM= Received: by 10.152.132.72 with SMTP id os8mr1104685lab.4.1320425462711; Fri, 04 Nov 2011 09:51:02 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id me18sm26085lab.10.2011.11.04.09.51.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 09:51:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Vlad Galu In-Reply-To: Date: Fri, 4 Nov 2011 16:50:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <89098B91-49DE-4316-81C6-12AAB1849B44@dudu.ro> References: To: Archy Cho X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current@freebsd.org, rizzo@iet.unipi.it Subject: Re: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:51:04 -0000 On Nov 4, 2011, at 4:06 PM, Archy Cho wrote: > Hello >=20 > I am very happy to see freebsd could have such network performance = with > netmap , > since I am currently using freebsd as core routers instead of cisco. >=20 > I tried to re-compile the freebsd 8.2 kernel to test , > however , I could not complete the task ( both i386 and amd64 ), > I could only success at 9.0-RC-1. >=20 > Here is my task and error message, >=20 > cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router > echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router > cd /tmp/netmap/sys/ > cp -R * /usr/src/sys/ > cd /usr/src/ > patch -p < /tmp/netmap/head-netmap.diff > echo "WITHOUT_MODULES =3D bge re igb" >> /etc/make.conf > make buildkernel KERNCONF=3DNetmap-Router > make installkernel KERNCONF=3DNetmap-Router >=20 > -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 > ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': > ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in = this > function) > ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is > reported only once > ../../../dev/e1000/if_em.c:4012: error: for each function it appears = in.) > *** Error code 1 >=20 > Stop in /usr/src/sys/i386/compile/Netmap-Router >=20 >=20 > Any hint of error message ? >=20 It's fairly easy to remove the offending code, AFAIK there were a few = unused variable and signed vs unsigned comparisons. > More questions , > I seldom facing DDOS , whatever using polling or not , > 1Gbps link with 64bytes packet will cause CPU 100% , > if a freebsd box compile with netmap , > could it have performance boost of routed / ipfw / pf ? Not yet. In order to do that, ipfw or pf need to be ported to userspace. = I believe that was on Luigi's agenda, though. -- Good, fast & cheap: pick any two. From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:09:15 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6789106564A for ; Fri, 4 Nov 2011 19:09:14 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB878FC0A for ; Fri, 4 Nov 2011 19:09:14 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.5) with ESMTP id pA4J9C2E021970 for ; Fri, 4 Nov 2011 15:09:13 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.5/Submit) id pA4J9C2T021969 for current@freebsd.org; Fri, 4 Nov 2011 15:09:12 -0400 (EDT) (envelope-from mwlucas) Date: Fri, 4 Nov 2011 15:09:12 -0400 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Fri, 04 Nov 2011 15:09:13 -0400 (EDT) Cc: Subject: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:09:15 -0000 I suspect I'm building on a system that's too old, but it's worth asking. FreeBSD eyeball.lodden.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Aug 29 0= 0:31:14 EDT 2009 mwlucas@stretchlimo.blackhelicopters.org:/usr/obj/usr/= src/sys/GENERIC i386 csup today. no /etc/src.conf, /etc/make.conf only contains a perl definition. =2E.. c++ -O2 -pipe -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include= -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include = -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I= /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include= -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_M= ACROS -DLLVM_HOSTTRIPLE=3D\"i386-unknown-freebsd9.0\" -I/usr/obj/usr/src/tm= p/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o tblg= en ARMDecoderEmitter.o AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst= .o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstru= ction.o CodeGenRegisters.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.= o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o Disassemb= lerEmitter.o EDEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o InstrEn= umEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o PseudoLoweringEmitter.o R= egisterInfoEmitter.o SetTheory.o StringMatcher.o SubtargetEmitter.o TGValue= Types.o TableGen.o X86DisassemblerTables.o X86RecognizableInstr.o /usr/obj/= usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen= /libllvmtablegen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../= ../lib/clang/libllvmsupport/libllvmsupport.a -legacy /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllv= msupport/libllvmsupport.a(Atomic.o)(.text+0x25): In function `llvm::sys::At= omicIncrement(unsigned int volatile*)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllv= msupport/libllvmsupport.a(Atomic.o)(.text+0x45): In function `llvm::sys::At= omicDecrement(unsigned int volatile*)': : undefined reference to `__sync_sub_and_fetch_4' /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllv= msupport/libllvmsupport.a(Atomic.o)(.text+0x5): In function `llvm::sys::Ato= micAdd(unsigned int volatile*, unsigned int)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllv= msupport/libllvmsupport.a(Atomic.o)(.text+0x61): In function `llvm::sys::Co= mpareAndSwap(unsigned int volatile*, unsigned int, unsigned int)': : undefined reference to `__sync_val_compare_and_swap_4' *** Error code 1 Stop in /usr/src/usr.bin/clang/tblgen. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 --=20 Michael W. Lucas =09 http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:20:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8387B106564A for ; Fri, 4 Nov 2011 19:20:07 +0000 (UTC) (envelope-from armin@frozen-zone.org) Received: from mailbackup.inode.at (mailbackup.inode.at [213.229.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD068FC0C for ; Fri, 4 Nov 2011 19:20:07 +0000 (UTC) Received: from [62.99.145.5] (port=51630 helo=mx.inode.at) by mailbackup.inode.at with esmtp (Exim 4.76) (envelope-from ) id 1RMPJ8-0004u7-0u for freebsd-current@freebsd.org; Fri, 04 Nov 2011 20:20:06 +0100 Received: from [84.119.18.197] (port=13612 helo=fz-sub1.local) by smartmx-05.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMPJ5-0001AE-G7; Fri, 04 Nov 2011 20:20:03 +0100 Message-ID: <4EB43AB0.4030107@frozen-zone.org> Date: Fri, 04 Nov 2011 20:19:12 +0100 From: Armin Pirkovitsch User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: guru@unixarea.de, freebsd-current@freebsd.org References: <20111104132640.GA1378@tiny> In-Reply-To: <20111104132640.GA1378@tiny> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 10-CURRENT && ports/security/p11-kit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:20:07 -0000 On 11/04/11 14:26, Matthias Apitz wrote: > > ports/security/p11-kit (requested by ports/graphics/evince via gnome) > does not build: > > caracas# pwd > /usr/ports/security/p11-kit > caracas# make > ===> Building for p11-kit-0.8 > ... > checking for ld used by GCC... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for shared library run path origin... done > checking for CFPreferencesCopyAppValue... no > checking for CFLocaleCopyCurrent... no > checking whether to use NLS... no > ./configure: 14377: Syntax error: word unexpected (expecting ")") > *** Error code 2 Just wondering - have you looked at UPDATING? - especially: 20110928: AFFECTS: users of 10-current AUTHOR: eadler@FreeBSD.org There are known issues installing ports on FreeBSD 10+ due to bogus assumptions by various build scripts. This will not be fixed until 9-RELEASE is released. There are two workarounds: 1) Set UNAME_r=9.9-CURRENT in your environment 2) Set REVISION="9.9" in ${SRCDIR}/sys/conf/newvers.sh afaik there are already some people working on that problem - however I'd suggest you try one of the workarounds for now... Armin From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:35:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1EA5106564A for ; Fri, 4 Nov 2011 19:35:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 874F98FC08 for ; Fri, 4 Nov 2011 19:35:40 +0000 (UTC) Received: from [89.204.154.105] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMPY9-00035l-EP; Fri, 04 Nov 2011 20:35:39 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA4JZklN001201; Fri, 4 Nov 2011 20:35:46 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA4JZi9j001200; Fri, 4 Nov 2011 20:35:44 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 20:35:44 +0100 From: Matthias Apitz To: Armin Pirkovitsch Message-ID: <20111104193543.GA1188@tiny> References: <20111104132640.GA1378@tiny> <4EB43AB0.4030107@frozen-zone.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4EB43AB0.4030107@frozen-zone.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.154.105 Cc: freebsd-current@freebsd.org Subject: Re: 10-CURRENT && ports/security/p11-kit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:35:42 -0000 El día Friday, November 04, 2011 a las 08:19:12PM +0100, Armin Pirkovitsch escribió: > > ports/security/p11-kit (requested by ports/graphics/evince via gnome) > > does not build: > > > > Just wondering - have you looked at UPDATING? - especially: > > 20110928: > AFFECTS: users of 10-current > AUTHOR: eadler@FreeBSD.org > > There are known issues installing ports on FreeBSD 10+ due to > bogus assumptions by various build scripts. This will not be fixed > until 9-RELEASE is released. > ... I have read this and I have in /etc/make.conf the following lines: # From: "b. f." # To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org # Date: Thu, 3 Nov 2011 13:42:50 -0400 # # No, it is not the same. You can either masquerade, by setting UNAME_r # and OSVERSION, or by editing the headers and scripts that define them; # or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE # (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the # masquerading is probably safer, because there are some problems with # the fix that are still being resolved -- and a few ports that may fail # despite the fix. But of course if you help to test without # masquerading, these problems will be resolved sooner. # WITH_FBSD10_FIX=1 and most of the ports I'm using are compiling now; the port mentioned here does not (not even with UNAME_r) and I wanted to bring this to the attention of the maintainer and others; HIH matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:49:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3BA7106566B for ; Fri, 4 Nov 2011 19:49:43 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7B48FC12 for ; Fri, 4 Nov 2011 19:49:42 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so2292904vcb.13 for ; Fri, 04 Nov 2011 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BBDbbrKrRwQB2kFW+Toxi0AlwU3jQMcXilwSlNX4PRI=; b=joHDYW+n1w9w0yzPu6eqQ6Wo0ajcriOWO837M941sm6PNmNk9sfvxvd0hE+OijQnin AK13XX9EZ3mGGDnOpO5U1cU1epmThehctYrc1ypG+eGBuN3V+G6Z3VQod3eat8G+G0Lg m2/IjT+XJD/11Glbp636CvhL2/QpXJPWFWs7c= MIME-Version: 1.0 Received: by 10.52.20.207 with SMTP id p15mr15982558vde.87.1320436182507; Fri, 04 Nov 2011 12:49:42 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 12:49:42 -0700 (PDT) In-Reply-To: References: <89098B91-49DE-4316-81C6-12AAB1849B44@dudu.ro> Date: Sat, 5 Nov 2011 03:49:42 +0800 Message-ID: From: Archy Cho To: freebsd-current@freebsd.org, rizzo@iet.unipi.it Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:49:43 -0000 ---------- Forwarded message ---------- From: Archy Cho Date: 2011/11/5 Subject: Re: Netmap for routers (em0 device) To: Vlad Galu Do you know about time line for this ? Thanks. 2011/11/5 Vlad Galu > On Nov 4, 2011, at 4:06 PM, Archy Cho wrote: > > Hello > > > > I am very happy to see freebsd could have such network performance with > > netmap , > > since I am currently using freebsd as core routers instead of cisco. > > > > I tried to re-compile the freebsd 8.2 kernel to test , > > however , I could not complete the task ( both i386 and amd64 ), > > I could only success at 9.0-RC-1. > > > > Here is my task and error message, > > > > cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router > > echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router > > cd /tmp/netmap/sys/ > > cp -R * /usr/src/sys/ > > cd /usr/src/ > > patch -p < /tmp/netmap/head-netmap.diff > > echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf > > make buildkernel KERNCONF=Netmap-Router > > make installkernel KERNCONF=Netmap-Router > > > > -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 > > ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': > > ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in this > > function) > > ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is > > reported only once > > ../../../dev/e1000/if_em.c:4012: error: for each function it appears in.) > > *** Error code 1 > > > > Stop in /usr/src/sys/i386/compile/Netmap-Router > > > > > > Any hint of error message ? > > > > It's fairly easy to remove the offending code, AFAIK there were a few > unused variable and signed vs unsigned comparisons. > > > More questions , > > I seldom facing DDOS , whatever using polling or not , > > 1Gbps link with 64bytes packet will cause CPU 100% , > > if a freebsd box compile with netmap , > > could it have performance boost of routed / ipfw / pf ? > > Not yet. In order to do that, ipfw or pf need to be ported to userspace. I > believe that was on Luigi's agenda, though. > > > -- > Good, fast & cheap: pick any two. > > From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:49:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69AA11065672 for ; Fri, 4 Nov 2011 19:49:50 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFD28FC13 for ; Fri, 4 Nov 2011 19:49:49 +0000 (UTC) Received: by vws11 with SMTP id 11so3799445vws.13 for ; Fri, 04 Nov 2011 12:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Wf2DhiopJvva8qwYY7BbwHwyJsORzsYTKusx6R5YMSQ=; b=DXvS7DK+at42nF0ATdkrKItFNufejEGm9/8av5WYnaigcBjx/TkAsofs92cTp5mIQC /C7OihkY6Vnv1RErslB/DtV2U9LV0dh8aFw15nQMRd7u1MYNDUGLs38JJ4H49+EXRejv If2gKek6sgcc6RBn/RgzdWAdV3R58+ZG0yoow= MIME-Version: 1.0 Received: by 10.52.97.35 with SMTP id dx3mr16285488vdb.2.1320436189214; Fri, 04 Nov 2011 12:49:49 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 12:49:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 03:49:49 +0800 Message-ID: From: Archy Cho To: freebsd-current@freebsd.org, rizzo@iet.unipi.it Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:49:50 -0000 ---------- Forwarded message ---------- From: Archy Cho Date: 2011/11/5 Subject: Re: Netmap for routers (em0 device) To: Jack Vogel undefined 'j' appears on FreeBSD 8.2 release ( both i386 and amd64 tested ), I could compile netmap to a 9.0-RC-1 box with disabling re/bge. 2011/11/5 Jack Vogel > What version of the code is this, em certainly compiles in 8.2, and if you > mean > the code from HEAD or 9.0 I also don't see an undefined 'j'?? > > Jack > > > On Fri, Nov 4, 2011 at 9:06 AM, Archy Cho wrote: > >> Hello >> >> I am very happy to see freebsd could have such network performance with >> netmap , >> since I am currently using freebsd as core routers instead of cisco. >> >> I tried to re-compile the freebsd 8.2 kernel to test , >> however , I could not complete the task ( both i386 and amd64 ), >> I could only success at 9.0-RC-1. >> >> Here is my task and error message, >> >> cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router >> echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router >> cd /tmp/netmap/sys/ >> cp -R * /usr/src/sys/ >> cd /usr/src/ >> patch -p < /tmp/netmap/head-netmap.diff >> echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf >> make buildkernel KERNCONF=Netmap-Router >> make installkernel KERNCONF=Netmap-Router >> >> -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 >> ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': >> ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in this >> function) >> ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is >> reported only once >> ../../../dev/e1000/if_em.c:4012: error: for each function it appears in.) >> *** Error code 1 >> >> Stop in /usr/src/sys/i386/compile/Netmap-Router >> >> >> Any hint of error message ? >> >> More questions , >> I seldom facing DDOS , whatever using polling or not , >> 1Gbps link with 64bytes packet will cause CPU 100% , >> if a freebsd box compile with netmap , >> could it have performance boost of routed / ipfw / pf ? >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:50:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3619E106566C for ; Fri, 4 Nov 2011 19:50:02 +0000 (UTC) (envelope-from armin@frozen-zone.org) Received: from mx.inode.at (mx20.lb01.inode.at [62.99.145.22]) by mx1.freebsd.org (Postfix) with ESMTP id EA8A38FC1C for ; Fri, 4 Nov 2011 19:50:01 +0000 (UTC) Received: from [84.119.18.197] (port=5247 helo=fz-sub1.local) by smartmx-20.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMPm4-0003XO-Bs; Fri, 04 Nov 2011 20:50:00 +0100 Message-ID: <4EB441B6.9000400@frozen-zone.org> Date: Fri, 04 Nov 2011 20:49:10 +0100 From: Armin Pirkovitsch User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Matthias Apitz References: <20111104132640.GA1378@tiny> <4EB43AB0.4030107@frozen-zone.org> <20111104193543.GA1188@tiny> In-Reply-To: <20111104193543.GA1188@tiny> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: 10-CURRENT && ports/security/p11-kit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:50:02 -0000 On 11/04/11 20:35, Matthias Apitz wrote: > El día Friday, November 04, 2011 a las 08:19:12PM +0100, Armin Pirkovitsch escribió: > >>> ports/security/p11-kit (requested by ports/graphics/evince via gnome) >>> does not build: >>> >> >> Just wondering - have you looked at UPDATING? - especially: >> >> 20110928: >> AFFECTS: users of 10-current >> AUTHOR: eadler@FreeBSD.org >> >> There are known issues installing ports on FreeBSD 10+ due to >> bogus assumptions by various build scripts. This will not be fixed >> until 9-RELEASE is released. >> ... > > I have read this and I have in /etc/make.conf the following lines: > > # From: "b. f." > # To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org > # Date: Thu, 3 Nov 2011 13:42:50 -0400 > # > # No, it is not the same. You can either masquerade, by setting UNAME_r > # and OSVERSION, or by editing the headers and scripts that define them; > # or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE > # (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the > # masquerading is probably safer, because there are some problems with > # the fix that are still being resolved -- and a few ports that may fail > # despite the fix. But of course if you help to test without > # masquerading, these problems will be resolved sooner. > # > WITH_FBSD10_FIX=1 > > and most of the ports I'm using are compiling now; the port mentioned > here does not (not even with UNAME_r) and I wanted to bring this to the > attention of the maintainer and others; Would have been useful if you had written that in the first place I guess... From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:50:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2E3F1065673 for ; Fri, 4 Nov 2011 19:50:22 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1908FC27 for ; Fri, 4 Nov 2011 19:50:22 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so2293674vcb.13 for ; Fri, 04 Nov 2011 12:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1DvE0TJ6OqxnD3qX2rBil95N9OApB7w6g009bRluRbU=; b=KFqmlvaXshqLGZiDE3oxcQVDuTVBAKlERBGMck0d7h8r/OjhZfY67an4Wdn8Bv0FEy +aDtnm9VDrbFbs7bUqd3XcLSNGAMuLNx2ydpfzBlkcZKt5IBvtqa3kVG+lmiITIv3hBK kn4EyGP8//UL0nQtunMW5Sa7fpR0lmMTiIYds= MIME-Version: 1.0 Received: by 10.52.33.140 with SMTP id r12mr16467535vdi.36.1320436221551; Fri, 04 Nov 2011 12:50:21 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 12:50:21 -0700 (PDT) In-Reply-To: References: <4EB432E2.2030402@bluerosetech.com> Date: Sat, 5 Nov 2011 03:50:21 +0800 Message-ID: From: Archy Cho To: freebsd-current@freebsd.org, rizzo@iet.unipi.it Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:50:22 -0000 ---------- Forwarded message ---------- From: Archy Cho Date: 2011/11/5 Subject: Re: Netmap for routers (em0 device) To: Darren Pilgrim 2011/11/5 Darren Pilgrim > On 2011-11-04 09:06, Archy Cho wrote: > >> Hello >> >> I am very happy to see freebsd could have such network performance >> with netmap , since I am currently using freebsd as core routers >> instead of cisco. >> > > I'm looking at doing the same at a site, but we're not sure about the > performance as it will sit on 10 GE. Would you tell me about: > > - the hardware you use > - previous hardware that didn't work > - functions performed (firewall, VPN, BGP feed, etc.) > - the wire speeds involved > - the bit and packet rates achieved > - the CPU load > > Thanks in advance > I am currently using FreeBSD 7.4-AMD64 seldom under large pps of DDoS the router box ( freebsd ) will drop packets , one of the CPU core getting 100% of swi1:net with command `top -HSP` The following configuration , could only forward around 600Kpps Intel 3420GVP mainboard Intel Xeon X3480 CPU with HT disabled 8GB DDR3-1333 Ram 450GB 10000rpm WDHLHX Intel 82578DM on board as EM0 Intel 82574L on board as EM1 >100 ipfw rules 1Gbps uplink with upstream Quagga as BGP router with 2 upstream providers full routes kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } kern.dcons.poll_hz: 100 kern.hz: 1000 debug.psm.hz: 20 kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 114 kern.polling.suspect: 5775 kern.polling.phase: 0 kern.polling.enable: 0 kern.polling.handlers: 2 kern.polling.residual_burst: 0 kern.polling.pending_polls: 1 kern.polling.lost_polls: 871230 kern.polling.short_ticks: 1636 kern.polling.reg_frac: 20 kern.polling.user_frac: 10 kern.polling.idle_poll: 0 kern.polling.each_burst: 1000 kern.polling.burst_max: 1000 kern.polling.burst: 1000 dev.em.0.rx_processing_limit=10000000 dev.em.1.rx_processing_limit=10000000 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.icmp.icmplim=10485760 net.inet.ip.dummynet.pipe_byte_limit=104857600 net.inet.ip.dummynet.pipe_slot_limit=104857600 net.inet.ip.dummynet.hash_size=65535 net.inet.ip.fw.tables_max=65535 net.inet.ip.fw.dyn_keepalive=1 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.dyn_short_lifetime=5 net.inet.ip.fw.dyn_buckets=4096 net.local.stream.recvspace=524288 net.local.stream.sendspace=524288 net.local.dgram.recvspace=614400 net.inet.tcp.sendspace=614400 net.inet.tcp.recvspace=614400 net.inet.udp.recvspace=420800 net.inet.sctp.recvspace=2330160 net.inet.sctp.sendspace=2330160 net.inet.raw.recvspace=614400 net.raw.recvspace=524288 net.raw.sendspace=524288 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 19:59:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0715106564A for ; Fri, 4 Nov 2011 19:59:56 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id AEF408FC0A for ; Fri, 4 Nov 2011 19:59:56 +0000 (UTC) Received: from [89.204.154.105] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMPve-000114-4K; Fri, 04 Nov 2011 20:59:55 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id pA4K02Pd001241; Fri, 4 Nov 2011 21:00:03 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id pA4K01wm001240; Fri, 4 Nov 2011 21:00:01 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Fri, 4 Nov 2011 21:00:01 +0100 From: Matthias Apitz To: Armin Pirkovitsch Message-ID: <20111104200000.GA1228@tiny> References: <20111104132640.GA1378@tiny> <4EB43AB0.4030107@frozen-zone.org> <20111104193543.GA1188@tiny> <4EB441B6.9000400@frozen-zone.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4EB441B6.9000400@frozen-zone.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.154.105 Cc: freebsd-current@freebsd.org Subject: Re: 10-CURRENT && ports/security/p11-kit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:59:57 -0000 El día Friday, November 04, 2011 a las 08:49:10PM +0100, Armin Pirkovitsch escribió: > > WITH_FBSD10_FIX=1 > > > > and most of the ports I'm using are compiling now; the port mentioned > > here does not (not even with UNAME_r) and I wanted to bring this to the > > attention of the maintainer and others; > > Would have been useful if you had written that in the first place I guess... Yes, I did, please check the archives of -current about my message with the Subject: 10-CURRENT && port/... but you are right, will from now mention WITH_FBSD10_FIX=1 in any report; thanis for the hint matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 20:32:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42804106564A for ; Fri, 4 Nov 2011 20:32:33 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF0C68FC15 for ; Fri, 4 Nov 2011 20:32:32 +0000 (UTC) Received: by vws11 with SMTP id 11so3852547vws.13 for ; Fri, 04 Nov 2011 13:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qpAuYwPh4cPddFa5gawBjy/aXvsYmqfUeF2ryHBMELg=; b=i7bW4TjgU6tR4GM4vIL9PjaQ5xTs1SblGOzaU1TX/nQV5uI+y1GagjLPjBpQJ8agTo VnamgqDHrh+AWPQocZPAGLWCF0koWq0V8Qm5gqgc9YRzoaJOLVszL8xTGsc3VEBUxupp a2CSy0cNVwwT876WWsBYjvBA/ypq3TflIidGE= MIME-Version: 1.0 Received: by 10.52.97.35 with SMTP id dx3mr16439568vdb.2.1320438752121; Fri, 04 Nov 2011 13:32:32 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 13:32:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 04:32:32 +0800 Message-ID: From: Archy Cho To: Jack Vogel , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 20:32:33 -0000 With NETMAP patch I know there has no errors for default. 2011/11/5 Jack Vogel > I looked at the if_em.c in a untouched 8.2 machine, there is no 'j' at > line 4012, > furthermore, hundreds of users of 8.2 have compiled the em driver without > errors, > the release would not have happened with a broken em compile, the GENERIC > kernel depends on it. > > .... SO, either the source is modified, or your environment is modified?? > > Jack > > > > On Fri, Nov 4, 2011 at 12:47 PM, Archy Cho wrote: > >> undefined 'j' appears on FreeBSD 8.2 release ( both i386 and amd64 tested >> ), >> I could compile netmap to a 9.0-RC-1 box with disabling re/bge. >> >> 2011/11/5 Jack Vogel >> >>> What version of the code is this, em certainly compiles in 8.2, and if >>> you mean >>> the code from HEAD or 9.0 I also don't see an undefined 'j'?? >>> >>> Jack >>> >>> >>> On Fri, Nov 4, 2011 at 9:06 AM, Archy Cho wrote: >>> >>>> Hello >>>> >>>> I am very happy to see freebsd could have such network performance with >>>> netmap , >>>> since I am currently using freebsd as core routers instead of cisco. >>>> >>>> I tried to re-compile the freebsd 8.2 kernel to test , >>>> however , I could not complete the task ( both i386 and amd64 ), >>>> I could only success at 9.0-RC-1. >>>> >>>> Here is my task and error message, >>>> >>>> cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router >>>> echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router >>>> cd /tmp/netmap/sys/ >>>> cp -R * /usr/src/sys/ >>>> cd /usr/src/ >>>> patch -p < /tmp/netmap/head-netmap.diff >>>> echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf >>>> make buildkernel KERNCONF=Netmap-Router >>>> make installkernel KERNCONF=Netmap-Router >>>> >>>> -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 >>>> ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': >>>> ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in >>>> this >>>> function) >>>> ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is >>>> reported only once >>>> ../../../dev/e1000/if_em.c:4012: error: for each function it appears >>>> in.) >>>> *** Error code 1 >>>> >>>> Stop in /usr/src/sys/i386/compile/Netmap-Router >>>> >>>> >>>> Any hint of error message ? >>>> >>>> More questions , >>>> I seldom facing DDOS , whatever using polling or not , >>>> 1Gbps link with 64bytes packet will cause CPU 100% , >>>> if a freebsd box compile with netmap , >>>> could it have performance boost of routed / ipfw / pf ? >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to " >>>> freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> >> > From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 20:33:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5105D1065672 for ; Fri, 4 Nov 2011 20:33:59 +0000 (UTC) (envelope-from archycho@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0938FC17 for ; Fri, 4 Nov 2011 20:33:58 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so2346850vcb.13 for ; Fri, 04 Nov 2011 13:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tzA2eoVmDL9Pcuaxsp+wrZl0IhyX0LuRGmx+u/OW544=; b=P2TVC0r1s0+9InBomqiOgFgCSMSJHLBwjdl4l7YHZYd1Dj5MERsmB22u9+bCBBOXyt P3dAt4+3XnSvfIiWKawcJ+LbNoVC5mHbtkQMqkaPGyfyRy0HLXou64twuPr4Vjxbw9Z8 /zk5/O0ROtPK5MV0kq7m/8ujsfB8JqWi8goyw= MIME-Version: 1.0 Received: by 10.52.97.35 with SMTP id dx3mr16444123vdb.2.1320438838257; Fri, 04 Nov 2011 13:33:58 -0700 (PDT) Received: by 10.52.158.72 with HTTP; Fri, 4 Nov 2011 13:33:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 04:33:58 +0800 Message-ID: From: Archy Cho To: Jack Vogel , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Netmap for routers (em0 device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 20:33:59 -0000 With NETMAP patch I know there has no errors for default. source from info.iet.unipi.it/~luigi/*netmap*/ thank you. 2011/11/5 Archy Cho > With NETMAP patch > I know there has no errors for default. > > > 2011/11/5 Jack Vogel > >> I looked at the if_em.c in a untouched 8.2 machine, there is no 'j' at >> line 4012, >> furthermore, hundreds of users of 8.2 have compiled the em driver without >> errors, >> the release would not have happened with a broken em compile, the GENERIC >> kernel depends on it. >> >> .... SO, either the source is modified, or your environment is modified?? >> >> Jack >> >> >> >> On Fri, Nov 4, 2011 at 12:47 PM, Archy Cho wrote: >> >>> undefined 'j' appears on FreeBSD 8.2 release ( both i386 and amd64 >>> tested ), >>> I could compile netmap to a 9.0-RC-1 box with disabling re/bge. >>> >>> 2011/11/5 Jack Vogel >>> >>>> What version of the code is this, em certainly compiles in 8.2, and if >>>> you mean >>>> the code from HEAD or 9.0 I also don't see an undefined 'j'?? >>>> >>>> Jack >>>> >>>> >>>> On Fri, Nov 4, 2011 at 9:06 AM, Archy Cho wrote: >>>> >>>>> Hello >>>>> >>>>> I am very happy to see freebsd could have such network performance with >>>>> netmap , >>>>> since I am currently using freebsd as core routers instead of cisco. >>>>> >>>>> I tried to re-compile the freebsd 8.2 kernel to test , >>>>> however , I could not complete the task ( both i386 and amd64 ), >>>>> I could only success at 9.0-RC-1. >>>>> >>>>> Here is my task and error message, >>>>> >>>>> cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router >>>>> echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router >>>>> cd /tmp/netmap/sys/ >>>>> cp -R * /usr/src/sys/ >>>>> cd /usr/src/ >>>>> patch -p < /tmp/netmap/head-netmap.diff >>>>> echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf >>>>> make buildkernel KERNCONF=Netmap-Router >>>>> make installkernel KERNCONF=Netmap-Router >>>>> >>>>> -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 >>>>> ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': >>>>> ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in >>>>> this >>>>> function) >>>>> ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is >>>>> reported only once >>>>> ../../../dev/e1000/if_em.c:4012: error: for each function it appears >>>>> in.) >>>>> *** Error code 1 >>>>> >>>>> Stop in /usr/src/sys/i386/compile/Netmap-Router >>>>> >>>>> >>>>> Any hint of error message ? >>>>> >>>>> More questions , >>>>> I seldom facing DDOS , whatever using polling or not , >>>>> 1Gbps link with 64bytes packet will cause CPU 100% , >>>>> if a freebsd box compile with netmap , >>>>> could it have performance boost of routed / ipfw / pf ? >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to " >>>>> freebsd-current-unsubscribe@freebsd.org" >>>>> >>>> >>>> >>> >> > From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 21:21:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF111065673; Fri, 4 Nov 2011 21:21:28 +0000 (UTC) (envelope-from loox@e-shell.net) Received: from mail.serpronet.com (mail.serpronet.com [64.214.84.187]) by mx1.freebsd.org (Postfix) with ESMTP id 608788FC08; Fri, 4 Nov 2011 21:21:28 +0000 (UTC) Received: by mail.serpronet.com (Postfix, from userid 506) id 42A5CC4BB9; Fri, 4 Nov 2011 15:21:27 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on titan.serpronet.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from twinmoon.e-shell.net (unknown [10.1.10.180]) by mail.serpronet.com (Postfix) with ESMTP id B9460C4BB4; Fri, 4 Nov 2011 15:21:24 -0600 (CST) Received: from moonlight.e-shell.tk (unknown [189.247.86.136]) by twinmoon.e-shell.net (Postfix) with ESMTPSA id 7359217021; Fri, 4 Nov 2011 15:22:44 -0600 (CST) From: Axel Gonzalez To: freebsd-current@freebsd.org Date: Fri, 04 Nov 2011 15:21:21 -0600 Message-ID: <3103300.opx6oxscCi@moonlight.e-shell.tk> User-Agent: KMail/4.7.1 (FreeBSD/9.0-RC1; KDE/4.7.2; i386; ; ) In-Reply-To: <2104381.NqWTZMXtng@moonlight.e-shell.tk> References: <1562351.Ln9lEKl2rv@moonlight.e-shell.tk> <20111101065651.GA27751@freebsd.org> <2104381.NqWTZMXtng@moonlight.e-shell.tk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Roman Divacky Subject: bug in clang printf format | was Re: Strange warning with clang and 9RC1 (ntohs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 21:21:28 -0000 After getting in contact with clang's ml, the determined that this a bug in clang's format checker. Note that this bug affects: printf("%hu\n", ntohs(x)); This happens in 9 that ntohs is defined as a macro using conditinal operator (? :) The discussion is here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018464.html The bug in clang is here: http://llvm.org/bugs/show_bug.cgi?id=11313 Greetings! On Tuesday 01 November 2011 01:10:36 Axel Gonzalez wrote: > Here is the output (short version): > > ... > (snip) > > static __inline __uint16_t > __bswap16_var(__uint16_t _x) > { > > return ((__uint16_t)((_x) << 8 | (_x) >> 8)); > } > > ... > (snip) > > > int main() > { > uint16_t x = (__builtin_constant_p(80) ? (__uint16_t)(((__uint16_t)(80)) << > 8 > | ((__uint16_t)(80)) >> 8) : __bswap16_var(80)); > > printf("%hu\n", (uint16_t)(__builtin_constant_p(x) ? (__uint16_t) > (((__uint16_t)(x)) << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))); > printf("%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) > << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))); > return (0); > } > > > % clang -E ntohs.c > ntohs_.c > % clang -Wall -o ntohs ntohs_.c > In file included from ntohs.c:1: > ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the > argument has type > 'int' [-Wformat] > ...%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) << 8 > | ((__uint16_t)(x)) >> 8) : __bswap16_var(x))... > ~~^ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %d > 1 warning generated. > > > > And I missed it the first mail: > > FreeBSD moonlight 9.0-RC1 FreeBSD 9.0-RC1 #0: Fri Oct 28 22:53:45 CDT 2011 > toor@moonlight:/usr/obj/usr/src/sys/LXCORE9 i386 > > > Thanks! > > A > > On Tuesday 01 November 2011 07:56:51 Roman Divacky wrote: > > It doesnt warn here. Can you check with "clang -E" what the ntohs() > > is being expanded to and what the real prototype is? -- Fri Nov 4 15:11:00 2011 GMT ** ****** ********* ********** ********** ********* ****** ** 9. From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 08:46:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96306106566B for ; Sat, 5 Nov 2011 08:46:44 +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 4FCFF8FC12 for ; Sat, 5 Nov 2011 08:46:44 +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 <1RMbtj-0002vO-Ex>; Sat, 05 Nov 2011 09:46:43 +0100 Received: from e178024217.adsl.alicedsl.de ([85.178.24.217] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RMbtj-0006kL-9t>; Sat, 05 Nov 2011 09:46:43 +0100 Message-ID: <4EB4F7ED.3020404@zedat.fu-berlin.de> Date: Sat, 05 Nov 2011 09:46:37 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111030 Thunderbird/7.0.1 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3A07B71D10B7F9DEE59D2517" X-Originating-IP: 85.178.24.217 Subject: FreeBSD 9.0-RC1/FreeBSD 10.0-CURRENT (amd64, CLANG): in some clients hitting backspace or arrow keys results in crashing client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 08:46:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A07B71D10B7F9DEE59D2517 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Operating systems in question: FreeBSD 9.0-RC1/amd64 and FreeBSD 10.0-CURRENT/amd64, both compiled with CLANG. It happens that when using clients with requester for pathnames (like evim, thunderbird, mozilla and others) that typing some attributes into the requester-inputline and then hitting backspace or the arrow keys for editing a possibly wrong entry, the client crashes. I realized that this very often occur with locales set to non "C". Such a weird behaviour occured also on a Dell Latitude E6510 with FreeBSD 9.0-CURRENT earlier this year compiled with CLANG and compiler option -march=3Dnative or -march=3Dcorei7 (this laptop does have a Lynnfi= eld dualCore i5 CPU). Whenever I hit backspave in the console of such a compiled system, the console exited and I found myself back at the login prompter again. This vanished after setting explicitely -march=3Dcore2. The boxes now in question are both older CoreDuo architectures (Q6600 and E8400 CPUs). The backspace/arrow-key weirdness occures not on the consoles anymore, but it happens that clients with files requester or entry fields for some data input exiting, when hitting backspace or, say, the back-arrow key. Today I realized this in evim when being asked for a file to open and I made a typo. It seems, that the error occurs more often if the locale is set to non-C standard (in my case, its partially set either to de_DE.UTF-8 or de_DE.ISO8859-1 or en_US.UTF-8). Regards, Oliver --------------enig3A07B71D10B7F9DEE59D2517 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOtPfyAAoJEOgBcD7A/5N8vZsH/0Vtjw8fwLlHSNcxoWwzIh5n Ek5N4UebjjoD+BmaqMRCSQW/nZyv1GAgfHkKzpgq68TfC99WQisnigUkx+CL/XWS 0oPpcgPQ3EaD0a72TH+6y/a6qaEBu7ZNno+fHDbr5ywgp19uCrUtwXsZ7XN7FBYm OgrlcwcuRzVw7OCwFla+OaCUFIIi+I4M0F362WxjEUmw8U9BRHCz/x7Iu4VLCtBM U2cpdVH8/qYR3NBhPg8nvarQG30AKNaih0rC48szmRZbBuPTS9nPiMJWygwzwU58 HYMpni0nnUpYeDR9EYKeuYnZWXvxQdICajnwv9hjCpD6xn0QX3Ek71z5hBnRYsU= =RDTL -----END PGP SIGNATURE----- --------------enig3A07B71D10B7F9DEE59D2517-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 13:19:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B41106567A for ; Sat, 5 Nov 2011 13:19:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3308FC19 for ; Sat, 5 Nov 2011 13:19:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5502:9023:fa7c:ca0f] (unknown [IPv6:2001:7b8:3a7:0:5502:9023:fa7c:ca0f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BFEE05C59; Sat, 5 Nov 2011 14:19:57 +0100 (CET) Message-ID: <4EB53803.2000205@FreeBSD.org> Date: Sat, 05 Nov 2011 14:20:03 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: "Michael W. Lucas" References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> In-Reply-To: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 13:19:58 -0000 On 2011-11-04 20:09, Michael W. Lucas wrote: > I suspect I'm building on a system that's too old, but it's worth > asking. > > FreeBSD eyeball.lodden.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Aug 29 00:31:14 EDT 2009 mwlucas@stretchlimo.blackhelicopters.org:/usr/obj/usr/src/sys/GENERIC i386 > > csup today. no /etc/src.conf, /etc/make.conf only contains a perl > definition. > > ... > c++ -O2 -pipe -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o tblgen ARMDecoderEmitter.o AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenRegisters.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DisassemblerEmitter.o EDEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o InstrEnumEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o PseudoLoweringEmitter.o RegisterInfoEmi tter.o SetTheory.o StringMatcher.o SubtargetEmitter.o TGValueTypes.o TableGen.o X86DisassemblerTables.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a -legacy > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a(Atomic.o)(.text+0x25): In function `llvm::sys::AtomicIncrement(unsigned int volatile*)': > : undefined reference to `__sync_add_and_fetch_4' Hm, the only way I can imagine this happening, is then you compile your system with -march=i386. In that case the atomic primitives, such as __sync_add_and_fetch, are called as external functions, which would lead to a link error like the above. I tried building 9-STABLE from a 9-CURRENT box that was not updated since April 2011, and from a fairly recent 8-STABLE, but both did not exhibit this issue. Are you using any special other settings, e.g. in your environment, or on the make command line? In case, it would be handy if you post the full buildlog somewhere, so we can see which flags have been used to compile the llvmsupport library. From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 13:28:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 474B4106566B; Sat, 5 Nov 2011 13:28:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D60E28FC14; Sat, 5 Nov 2011 13:28:22 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA5DSG53009029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2011 15:28:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA5DSGTc050817; Sat, 5 Nov 2011 15:28:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA5DSGmh050816; Sat, 5 Nov 2011 15:28:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Nov 2011 15:28:16 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20111105132816.GR50300@deviant.kiev.zoral.com.ua> References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> <4EB53803.2000205@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZTeqt8Ca5PdqcYoi" Content-Disposition: inline In-Reply-To: <4EB53803.2000205@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Re: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 13:28:23 -0000 --ZTeqt8Ca5PdqcYoi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 02:20:03PM +0100, Dimitry Andric wrote: > On 2011-11-04 20:09, Michael W. Lucas wrote: > > I suspect I'm building on a system that's too old, but it's worth > > asking. > >=20 > > FreeBSD eyeball.lodden.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Aug = 29 00:31:14 EDT 2009 mwlucas@stretchlimo.blackhelicopters.org:/usr/obj/= usr/src/sys/GENERIC i386 > >=20 > > csup today. no /etc/src.conf, /etc/make.conf only contains a perl > > definition. > >=20 > > ... > > c++ -O2 -pipe -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/inc= lude -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/incl= ude -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I= . -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/inc= lude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTA= NT_MACROS -DLLVM_HOSTTRIPLE=3D\"i386-unknown-freebsd9.0\" -I/usr/obj/usr/sr= c/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o = tblgen ARMDecoderEmitter.o AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriter= Inst.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenIn= struction.o CodeGenRegisters.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatc= her.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o Disas= semblerEmitter.o EDEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o Ins= trEnumEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o PseudoLoweringEmitter= .o RegisterInfoEmi > tter.o SetTheory.o StringMatcher.o SubtargetEmitter.o TGValueTypes.o Tabl= eGen.o X86DisassemblerTables.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/= usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtabl= egen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang= /libllvmsupport/libllvmsupport.a -legacy > > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/li= bllvmsupport/libllvmsupport.a(Atomic.o)(.text+0x25): In function `llvm::sys= ::AtomicIncrement(unsigned int volatile*)': > > : undefined reference to `__sync_add_and_fetch_4' >=20 > Hm, the only way I can imagine this happening, is then you compile your > system with -march=3Di386. In that case the atomic primitives, such as > __sync_add_and_fetch, are called as external functions, which would lead > to a link error like the above. >=20 > I tried building 9-STABLE from a 9-CURRENT box that was not updated > since April 2011, and from a fairly recent 8-STABLE, but both did not > exhibit this issue. >=20 > Are you using any special other settings, e.g. in your environment, or > on the make command line? In case, it would be handy if you post the > full buildlog somewhere, so we can see which flags have been used to > compile the llvmsupport library. The system gcc was changed to assume march=3D486 some time ago. I suppose that the current-9 system is before the change, see r198344. --ZTeqt8Ca5PdqcYoi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk61Oe8ACgkQC3+MBN1Mb4i0zwCg61j9PoGvUyfXrKXT8ehz8Twr es4An1bxrAbqcUYR3rkY2plcIC/87LxF =KnXA -----END PGP SIGNATURE----- --ZTeqt8Ca5PdqcYoi-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 13:35:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BD1106566C for ; Sat, 5 Nov 2011 13:35:47 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 09D918FC08 for ; Sat, 5 Nov 2011 13:35:46 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id A11B87F3810; Sat, 5 Nov 2011 14:35:41 +0100 (CET) Date: Sat, 5 Nov 2011 14:35:41 +0100 From: Roman Divacky To: "O. Hartmann" Message-ID: <20111105133541.GA65266@freebsd.org> References: <4EB4F7ED.3020404@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB4F7ED.3020404@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Current FreeBSD Subject: Re: FreeBSD 9.0-RC1/FreeBSD 10.0-CURRENT (amd64, CLANG): in some clients hitting backspace or arrow keys results in crashing client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 13:35:47 -0000 Can you run the crashing app under gdb and show me where it crashes? What is the cause of the crash? SIGILL or something like that? What instruction does it crash on? Thank you, roman On Sat, Nov 05, 2011 at 09:46:37AM +0100, O. Hartmann wrote: > Operating systems in question: FreeBSD 9.0-RC1/amd64 and FreeBSD > 10.0-CURRENT/amd64, both compiled with CLANG. > > It happens that when using clients with requester for pathnames (like > evim, thunderbird, mozilla and others) that typing some attributes into > the requester-inputline and then hitting backspace or the arrow keys for > editing a possibly wrong entry, the client crashes. > > I realized that this very often occur with locales set to non "C". > > Such a weird behaviour occured also on a Dell Latitude E6510 with > FreeBSD 9.0-CURRENT earlier this year compiled with CLANG and compiler > option -march=native or -march=corei7 (this laptop does have a Lynnfield > dualCore i5 CPU). Whenever I hit backspave in the console of such a > compiled system, the console exited and I found myself back at the login > prompter again. > This vanished after setting explicitely -march=core2. > > The boxes now in question are both older CoreDuo architectures (Q6600 > and E8400 CPUs). The backspace/arrow-key weirdness occures not on the > consoles anymore, but it happens that clients with files requester or > entry fields for some data input exiting, when hitting backspace or, > say, the back-arrow key. > > Today I realized this in evim when being asked for a file to open and I > made a typo. It seems, that the error occurs more often if the locale is > set to non-C standard (in my case, its partially set either to > de_DE.UTF-8 or de_DE.ISO8859-1 or en_US.UTF-8). > > Regards, > Oliver > From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 14:13:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB18106564A; Sat, 5 Nov 2011 14:13:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 495918FC12; Sat, 5 Nov 2011 14:13:10 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA5ED7aB012981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2011 16:13:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA5ED7p5051021; Sat, 5 Nov 2011 16:13:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA5ED6Zg051020; Sat, 5 Nov 2011 16:13:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Nov 2011 16:13:06 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1aUG3Yn8t1V/31Mw" Content-Disposition: inline In-Reply-To: <20111104160339.GM50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , freebsd-current@freebsd.org, Penta Upa , Andriy Gapon , Benjamin Kaduk Subject: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 14:13:11 -0000 --1aUG3Yn8t1V/31Mw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: Below is the KBI patch after vm_page_bits_t merge is done. Again, I did not spent time converting all in-tree consumers from the (potentially) loadable modules to the new KPI until it is agreed upon. diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c index 305c189..7264cd1 100644 --- a/sys/nfsclient/nfs_bio.c +++ b/sys/nfsclient/nfs_bio.c @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) * can only occur at the file EOF. */ VM_OBJECT_LOCK(object); - if (pages[ap->a_reqpage]->valid !=3D 0) { + if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { for (i =3D 0; i < npages; ++i) { if (i !=3D ap->a_reqpage) { vm_page_lock(pages[i]); @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) /* * Read operation filled an entire page */ - m->valid =3D VM_PAGE_BITS_ALL; - KASSERT(m->dirty =3D=3D 0, + vm_page_write_valid(m, VM_PAGE_BITS_ALL); + KASSERT(vm_page_read_dirty(m) =3D=3D 0, ("nfs_getpages: page %p is dirty", m)); } else if (size > toff) { /* * Read operation filled a partial page. */ - m->valid =3D 0; + vm_page_write_valid(m, 0); vm_page_set_valid(m, 0, size - toff); - KASSERT(m->dirty =3D=3D 0, + KASSERT(vm_page_read_dirty(m) =3D=3D 0, ("nfs_getpages: page %p is dirty", m)); } else { /* diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c index 389aea5..2f41e70 100644 --- a/sys/vm/vm_page.c +++ b/sys/vm/vm_page.c @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) vm_page_dirty(m); } =20 +void +vm_page_lock_func(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_lock(vm_page_lockptr(m), 0, file, line); +#endif +} + +void +vm_page_unlock_func(vm_page_t m, const char *file, int line) +{ + +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) + _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); +#else + __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); +#endif +} + +int +vm_page_trylock_func(vm_page_t m, const char *file, int line) +{ + + return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); +} + +void +vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line) +{ + +#ifdef INVARIANTS + _mtx_assert(vm_page_lockptr(m), a, file, line); +#endif +} + +vm_page_bits_t +vm_page_read_dirty_func(vm_page_t m) +{ + + return (m->dirty); +} + +vm_page_bits_t +vm_page_read_valid_func(vm_page_t m) +{ + + return (m->valid); +} + +void +vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v) +{ + + m->valid =3D v; +} + + int so_zerocp_fullpage =3D 0; =20 /* diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 7099b70..4f8f71e 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -218,12 +218,50 @@ extern struct vpglocks pa_lock[]; =20 #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a)) =20 +#ifdef KLD_MODULE +#define vm_page_lock(m) vm_page_lock_func((m), LOCK_FILE, LOCK_LINE) +#define vm_page_unlock(m) vm_page_unlock_func((m), LOCK_FILE, LOCK_LINE) +#define vm_page_trylock(m) vm_page_trylock_func((m), LOCK_FILE, LOCK_LINE) +#ifdef INVARIANTS +#define vm_page_lock_assert(m, a) \ + vm_page_lock_assert_func((m), (a), LOCK_FILE, LOCK_LINE) +#else +#define vm_page_lock_assert(m, a) +#endif + +#define vm_page_read_dirty(m) vm_page_read_dirty_func((m)) +#define vm_page_read_valid(m) vm_page_read_valid_func((m)) +#define vm_page_write_valid(m, v) vm_page_write_valid_func((m), (v)) + +#else /* KLD_MODULE */ #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m)))) #define vm_page_lock(m) mtx_lock(vm_page_lockptr((m))) #define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m))) #define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m))) #define vm_page_lock_assert(m, a) mtx_assert(vm_page_lockptr((m)), (a)) =20 +static inline vm_page_bits_t +vm_page_read_dirty(vm_page_t m) +{ + + return (m->dirty); +} + +static inline vm_page_bits_t +vm_page_read_valid(vm_page_t m) +{ + + return (m->valid); +} + +static inline void +vm_page_write_valid(vm_page_t m, vm_page_bits_t v) +{ + + m->valid =3D v; +} +#endif + #define vm_page_queue_free_mtx vm_page_queue_free_lock.data /* * These are the flags defined for vm_page. @@ -403,6 +441,15 @@ void vm_page_cowfault (vm_page_t); int vm_page_cowsetup(vm_page_t); void vm_page_cowclear (vm_page_t); =20 +void vm_page_lock_func(vm_page_t m, const char *file, int line); +void vm_page_unlock_func(vm_page_t m, const char *file, int line); +int vm_page_trylock_func(vm_page_t m, const char *file, int line); +void vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int li= ne); + +vm_page_bits_t vm_page_read_dirty_func(vm_page_t m); +vm_page_bits_t vm_page_read_valid_func(vm_page_t m); +void vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v); + #ifdef INVARIANTS void vm_page_object_lock_assert(vm_page_t m); #define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m) --1aUG3Yn8t1V/31Mw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk61RHEACgkQC3+MBN1Mb4gqOQCg7uvpBiNDsWfJDI0/BwjoRdAJ SygAoJWaG0CBzx1p7UdfNb8xKa/B/+cg =V+lG -----END PGP SIGNATURE----- --1aUG3Yn8t1V/31Mw-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 14:37:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB14106566B for ; Sat, 5 Nov 2011 14:37:50 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E55D8FC1B for ; Sat, 5 Nov 2011 14:37:49 +0000 (UTC) Received: by ggnk3 with SMTP id k3so2781430ggn.13 for ; Sat, 05 Nov 2011 07:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3MzEuGvx3ixXbSt0fROfukip4PhMyQdhBQ8D3a/tQhM=; b=ZbxmrWbnQd5qPFjSB45Bv5UhcZAGfaUFMMNhC+heh/NxRFvIixYQWWkU5AwvzPB27m X/2+c6nZ1NIrsWsiuNRdJPPkq72zRO2iXhxkZydBNG+pF2wmiTWFw6/Wh/O+mw5aw96/ 8AS3P2+mKgdde/6/5Mkc0nReyfUdscZGw+M1w= MIME-Version: 1.0 Received: by 10.50.6.202 with SMTP id d10mr22238607iga.31.1320503868278; Sat, 05 Nov 2011 07:37:48 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.49.35 with HTTP; Sat, 5 Nov 2011 07:37:48 -0700 (PDT) In-Reply-To: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> References: <4EB11C32.80106@FreeBSD.org> <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Date: Sat, 5 Nov 2011 07:37:48 -0700 X-Google-Sender-Auth: WU7QhCJp7wUegAJjw5gDNYs3Ouc Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 14:37:50 -0000 On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov wrote= : > On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: > > Below is the KBI patch after vm_page_bits_t merge is done. > Again, I did not spent time converting all in-tree consumers > from the (potentially) loadable modules to the new KPI until it > is agreed upon. I like my bikeshed orange... I would think a more canonical name would be get/set rather than read/write, especially since these operations aren't reading and writing the page (neither are they getting the page, but at least set is pretty unambiguous). Thanks, matthew > > diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c > index 305c189..7264cd1 100644 > --- a/sys/nfsclient/nfs_bio.c > +++ b/sys/nfsclient/nfs_bio.c > @@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap) > =A0 =A0 =A0 =A0 * can only occur at the file EOF. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0VM_OBJECT_LOCK(object); > - =A0 =A0 =A0 if (pages[ap->a_reqpage]->valid !=3D 0) { > + =A0 =A0 =A0 if (vm_page_read_valid(pages[ap->a_reqpage]) !=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < npages; ++i) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i !=3D ap->a_reqpage) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_lo= ck(pages[i]); > @@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled a= n entire page > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D VM_PAGE_BITS_A= LL; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, VM_P= AGE_BITS_ALL); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirty(= m) =3D=3D 0, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: pa= ge %p is dirty", m)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (size > toff) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Read operation filled a= partial page. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->valid =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_write_valid(m, 0); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_set_valid(m, 0, si= ze - toff); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(m->dirty =3D=3D 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(vm_page_read_dirty(= m) =3D=3D 0, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("nfs_getpages: pa= ge %p is dirty", m)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > index 389aea5..2f41e70 100644 > --- a/sys/vm/vm_page.c > +++ b/sys/vm/vm_page.c > @@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_dirty(m); > =A0} > > +void > +vm_page_lock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_lock(vm_page_lockptr(m), 0, file, line); > +#endif > +} > + > +void > +vm_page_unlock_func(vm_page_t m, const char *file, int line) > +{ > + > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > + =A0 =A0 =A0 _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > +#else > + =A0 =A0 =A0 __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line); > +#endif > +} > + > +int > +vm_page_trylock_func(vm_page_t m, const char *file, int line) > +{ > + > + =A0 =A0 =A0 return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > +} > + > +void > +vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line) > +{ > + > +#ifdef INVARIANTS > + =A0 =A0 =A0 _mtx_assert(vm_page_lockptr(m), a, file, line); > +#endif > +} > + > +vm_page_bits_t > +vm_page_read_dirty_func(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->dirty); > +} > + > +vm_page_bits_t > +vm_page_read_valid_func(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->valid); > +} > + > +void > +vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v) > +{ > + > + =A0 =A0 =A0 m->valid =3D v; > +} > + > + > =A0int so_zerocp_fullpage =3D 0; > > =A0/* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 7099b70..4f8f71e 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -218,12 +218,50 @@ extern struct vpglocks pa_lock[]; > > =A0#define =A0 =A0 =A0 =A0PA_LOCK_ASSERT(pa, a) =A0 mtx_assert(PA_LOCKPTR= (pa), (a)) > > +#ifdef KLD_MODULE > +#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 vm_page_lock_func= ((m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 vm_page_unlock_func= ((m), LOCK_FILE, LOCK_LINE) > +#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0vm_page_trylock_fun= c((m), LOCK_FILE, LOCK_LINE) > +#ifdef INVARIANTS > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 \ > + =A0 =A0vm_page_lock_assert_func((m), (a), LOCK_FILE, LOCK_LINE) > +#else > +#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) > +#endif > + > +#define =A0 =A0 =A0 =A0vm_page_read_dirty(m) =A0 vm_page_read_dirty_func= ((m)) > +#define =A0 =A0 =A0 =A0vm_page_read_valid(m) =A0 vm_page_read_valid_func= ((m)) > +#define =A0 =A0 =A0 =A0vm_page_write_valid(m, v) =A0 =A0 =A0 vm_page_wri= te_valid_func((m), (v)) > + > +#else =A0/* KLD_MODULE */ > =A0#define =A0 =A0 =A0 =A0vm_page_lockptr(m) =A0 =A0 =A0(PA_LOCKPTR(VM_PA= GE_TO_PHYS((m)))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock(m) =A0 =A0 =A0 =A0 mtx_lock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_unlock(m) =A0 =A0 =A0 mtx_unlock(vm_pag= e_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_trylock(m) =A0 =A0 =A0mtx_trylock(vm_pa= ge_lockptr((m))) > =A0#define =A0 =A0 =A0 =A0vm_page_lock_assert(m, a) =A0 =A0 =A0 mtx_asser= t(vm_page_lockptr((m)), (a)) > > +static inline vm_page_bits_t > +vm_page_read_dirty(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->dirty); > +} > + > +static inline vm_page_bits_t > +vm_page_read_valid(vm_page_t m) > +{ > + > + =A0 =A0 =A0 return (m->valid); > +} > + > +static inline void > +vm_page_write_valid(vm_page_t m, vm_page_bits_t v) > +{ > + > + =A0 =A0 =A0 m->valid =3D v; > +} > +#endif > + > =A0#define =A0 =A0 =A0 =A0vm_page_queue_free_mtx =A0vm_page_queue_free_lo= ck.data > =A0/* > =A0* These are the flags defined for vm_page. > @@ -403,6 +441,15 @@ void vm_page_cowfault (vm_page_t); > =A0int vm_page_cowsetup(vm_page_t); > =A0void vm_page_cowclear (vm_page_t); > > +void vm_page_lock_func(vm_page_t m, const char *file, int line); > +void vm_page_unlock_func(vm_page_t m, const char *file, int line); > +int vm_page_trylock_func(vm_page_t m, const char *file, int line); > +void vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int = line); > + > +vm_page_bits_t vm_page_read_dirty_func(vm_page_t m); > +vm_page_bits_t vm_page_read_valid_func(vm_page_t m); > +void vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v); > + > =A0#ifdef INVARIANTS > =A0void vm_page_object_lock_assert(vm_page_t m); > =A0#define =A0 =A0 =A0 =A0VM_PAGE_OBJECT_LOCK_ASSERT(m) =A0 vm_page_objec= t_lock_assert(m) > From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 15:15:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8561106566C; Sat, 5 Nov 2011 15:15:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9198FC19; Sat, 5 Nov 2011 15:15:35 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA5FFWih018069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2011 17:15:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA5FFWE3051180; Sat, 5 Nov 2011 17:15:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA5FFVQU051179; Sat, 5 Nov 2011 17:15:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Nov 2011 17:15:31 +0200 From: Kostik Belousov To: mdf@freebsd.org Message-ID: <20111105151530.GX50300@deviant.kiev.zoral.com.ua> References: <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ps88Q+2tj/fdI4QF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 15:15:36 -0000 --ps88Q+2tj/fdI4QF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote: > On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov wro= te: > > On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: > > > > Below is the KBI patch after vm_page_bits_t merge is done. > > Again, I did not spent time converting all in-tree consumers > > from the (potentially) loadable modules to the new KPI until it > > is agreed upon. >=20 > I like my bikeshed orange... >=20 > I would think a more canonical name would be get/set rather than > read/write, especially since these operations aren't reading and > writing the page (neither are they getting the page, but at least set > is pretty unambiguous). Look at the vm_page.h:385. vm_page_set_valid() is already taken. --ps88Q+2tj/fdI4QF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk61UxIACgkQC3+MBN1Mb4j/NwCgmgjqknOevgh+k6Wd/BYhlGLu RwAAoLi7w0iLGDgf50R8hrKiB/aZe2W8 =PzM2 -----END PGP SIGNATURE----- --ps88Q+2tj/fdI4QF-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 18:42:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1F9106566B; Sat, 5 Nov 2011 18:42:33 +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 B64AF8FC1C; Sat, 5 Nov 2011 18:42:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RMlCJ-00027V-8C>; Sat, 05 Nov 2011 19:42:31 +0100 Received: from e178014088.adsl.alicedsl.de ([85.178.14.88] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RMlCG-0004jo-FK>; Sat, 05 Nov 2011 19:42:31 +0100 Message-ID: <4EB58384.6020205@zedat.fu-berlin.de> Date: Sat, 05 Nov 2011 19:42:12 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111105 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ivan Klymenko References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> <20111104153318.0f3b9c9a@nonamehost.> In-Reply-To: <20111104153318.0f3b9c9a@nonamehost.> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01D0397EF8A8ACEDD79AE686" X-Originating-IP: 85.178.14.88 Cc: freebsd-current@freebsd.org, Jeff Roberson , Andriy Gapon Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 18:42:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01D0397EF8A8ACEDD79AE686 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/04/11 14:33, schrieb Ivan Klymenko: > Maybe useful the following information: > This problem appears not to all architectures and types of CPU. > on the Russian forums > http://www.bsdportal.ru/viewtopic.php?t=3D24900 > http://forum.lissyara.su/viewtopic.php?f=3D45&t=3D34641&sid=3Daa596f0b7= 0806ba053011da911f9ccae > was a brute force to find out that: > there is a suspicion that: > - for AMD processors, this problem is not observed at all when the numb= er of cores >=3D 2 > - on all single-core is the problem > - only for some models with Intel >=3D 2 cores of the problem is not fo= und >=20 > Perhaps, after all, avg@ rights (Subject: couple of sched_ule issues), = that is not working > properly mechanism rebalancing and to determine the topology of CPU? > All converge, because my patch ( http://docs.freebsd.org/cgi/mid.cgi?20= 111022132817.35db5ccd ) > for SMP systems just do respite for rebalancing, which eliminates the p= roblem with interactivity ... >=20 > Thanks! > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Is the patch going to be merged into HEAD shortly? Regards, Oliver --------------enig01D0397EF8A8ACEDD79AE686 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOtYOJAAoJEOgBcD7A/5N8lMwIAOEnBlpKK/CiNn1wQzR0AVfs UvnSYpeN5IGTLW2P919x+yvDRMNjwKBJX5ocWnxJ233DKl31f44ZrLFXM5Ls1Qpb cu/3zlLmxIP5Rf7G/rl2XIcHZ0B3+Fz7N2b4muGfetVbuo0OcuGB5l7g4MZgTWGm 5H83noUwtCj3HDBsUlcMpQS/j9yLgz+gSo+7f3Xwe0xDAGi/2448tc7zfbKTWwRj c0Oh+m2TX7Q6xUqIEMi2NWNmvmJHSqNAlDlrHzzpJLvNuN5dEvFOnZKukVWLT6OS d5q97eAQxZaRLUCRjUjjBBIrWfditaKisvGEHIJqc/BtmuUo0x0GVpWu8kyeFag= =Cd8+ -----END PGP SIGNATURE----- --------------enig01D0397EF8A8ACEDD79AE686-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 19:00:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E1B10656A3; Sat, 5 Nov 2011 19:00:27 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 097CA8FC0C; Sat, 5 Nov 2011 19:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=PUKNMHdPZa4wugqQoc87dBw8iDwJscDEIBMmCCTiFvU=; b=M3rgUeF/zRS7xjnNGARCGVtj1J5dsnMOHsGNqLLIa4rK/ai6rNmMzo49U5n6apTcN7tq0XIdPZjCbBcVJxVcrhq9eYvYyCg6B7LWOYulPyKNmTt7uv42O7qY8ggqyL1lX2PpDW62yityx653uzC7aEvnWcfYQV8zeRHq0xXMGec=; Received: from [81.23.24.116] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RMlTX-000BNb-S3 ; Sat, 05 Nov 2011 21:00:21 +0200 Date: Sat, 5 Nov 2011 20:59:46 +0200 From: Ivan Klymenko To: "O. Hartmann" Message-ID: <20111105205946.346dbc34@nonamehost.> In-Reply-To: <4EB58384.6020205@zedat.fu-berlin.de> References: <4ea29f2c.a823440a.4aa0.3599SMTPIN_ADDED@mx.google.com> <4eb3032e.a82eec0a.12ad.ffff8d64SMTPIN_ADDED@mx.google.com> <20111104153318.0f3b9c9a@nonamehost.> <4EB58384.6020205@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jeff Roberson , Andriy Gapon Subject: Re: Increase the degree of interactivity ULE scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 19:00:27 -0000 =D0=92 Sat, 05 Nov 2011 19:42:12 +0100 "O. Hartmann" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Am 11/04/11 14:33, schrieb Ivan Klymenko: > > Maybe useful the following information: > > This problem appears not to all architectures and types of CPU. > > on the Russian forums > > http://www.bsdportal.ru/viewtopic.php?t=3D24900 > > http://forum.lissyara.su/viewtopic.php?f=3D45&t=3D34641&sid=3Daa596f0b7= 0806ba053011da911f9ccae > > was a brute force to find out that: > > there is a suspicion that: > > - for AMD processors, this problem is not observed at all when the > > number of cores >=3D 2 > > - on all single-core is the problem > > - only for some models with Intel >=3D 2 cores of the problem is not > > found > >=20 > > Perhaps, after all, avg@ rights (Subject: couple of sched_ule > > issues), that is not working properly mechanism rebalancing and to > > determine the topology of CPU? All converge, because my patch > > ( http://docs.freebsd.org/cgi/mid.cgi?20111022132817.35db5ccd ) for > > SMP systems just do respite for rebalancing, which eliminates the > > problem with interactivity ... > >=20 > > Thanks! >=20 > Is the patch going to be merged into HEAD shortly? >=20 > Regards, > Oliver >=20 I'm not sure... Most of all we must address the root causes of this problem... From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 19:06:26 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD3F106564A for ; Sat, 5 Nov 2011 19:06:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFFD8FC14 for ; Sat, 5 Nov 2011 19:06:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5502:9023:fa7c:ca0f] (unknown [IPv6:2001:7b8:3a7:0:5502:9023:fa7c:ca0f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3E13B5C59; Sat, 5 Nov 2011 20:06:25 +0100 (CET) Message-ID: <4EB58932.1030309@FreeBSD.org> Date: Sat, 05 Nov 2011 20:06:26 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> <4EB53803.2000205@FreeBSD.org> <20111105132816.GR50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111105132816.GR50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.ORG Subject: Re: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 19:06:26 -0000 On 2011-11-05 14:28, Kostik Belousov wrote: > On Sat, Nov 05, 2011 at 02:20:03PM +0100, Dimitry Andric wrote: >> On 2011-11-04 20:09, Michael W. Lucas wrote: ... >>> : undefined reference to `__sync_add_and_fetch_4' ... > The system gcc was changed to assume march=486 some time ago. > I suppose that the current-9 system is before the change, see r198344. Yes, that is most likely the cause of this problem. It is reproducible if you set CC to 'gcc -march=i386' and CXX to 'g++ -march=i386'. At first, I thought it would be easily fixable, since when you use -march=i386, the macro __tune_i386__ is defined, so you can disable LLVM's use of atomic builtins. However, since r212286, libstdc++ is also configured to use atomic builtins, and any non-trivial C++ program will encounter this linking issue when compiling with -march=i386. A workaround could be this: Index: gnu/lib/libstdc++/config.h =================================================================== --- gnu/lib/libstdc++/config.h (revision 227112) +++ gnu/lib/libstdc++/config.h (working copy) @@ -671,7 +671,7 @@ /* #undef VERSION */ /* Define if builtin atomic operations are supported on this host. */ -#if defined(__amd64__) || defined(__i386__) +#if defined(__amd64__) || (defined(__i386__) && !defined(__tune_i386__)) #define _GLIBCXX_ATOMIC_BUILTINS 1 #endif but unfortunately during the bootstrap stage, the system includes are used, not those in the source tree... At the moment I don't know a clean way out of this, except setting CC to 'gcc -march=i486' and CXX to 'g++ -march=i486', and then building the bootstrap-tools stage should at least complete successfully. From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 19:41:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 636431065672; Sat, 5 Nov 2011 19:41:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EC91B8FC0C; Sat, 5 Nov 2011 19:41:43 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA5Jfbrm040162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2011 21:41:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA5Jfbgj052107; Sat, 5 Nov 2011 21:41:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA5JfaLI052106; Sat, 5 Nov 2011 21:41:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Nov 2011 21:41:36 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20111105194136.GI50300@deviant.kiev.zoral.com.ua> References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> <4EB53803.2000205@FreeBSD.org> <20111105132816.GR50300@deviant.kiev.zoral.com.ua> <4EB58932.1030309@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PQp0kazJUQKmOuaU" Content-Disposition: inline In-Reply-To: <4EB58932.1030309@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Re: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 19:41:44 -0000 --PQp0kazJUQKmOuaU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 08:06:26PM +0100, Dimitry Andric wrote: > On 2011-11-05 14:28, Kostik Belousov wrote: > > On Sat, Nov 05, 2011 at 02:20:03PM +0100, Dimitry Andric wrote: > >> On 2011-11-04 20:09, Michael W. Lucas wrote: > ... > >>> : undefined reference to `__sync_add_and_fetch_4' > ... > > The system gcc was changed to assume march=3D486 some time ago. > > I suppose that the current-9 system is before the change, see r198344. >=20 > Yes, that is most likely the cause of this problem. It is reproducible > if you set CC to 'gcc -march=3Di386' and CXX to 'g++ -march=3Di386'. >=20 > At first, I thought it would be easily fixable, since when you use > -march=3Di386, the macro __tune_i386__ is defined, so you can disable > LLVM's use of atomic builtins. >=20 > However, since r212286, libstdc++ is also configured to use atomic > builtins, and any non-trivial C++ program will encounter this linking > issue when compiling with -march=3Di386. >=20 > A workaround could be this: >=20 > Index: gnu/lib/libstdc++/config.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gnu/lib/libstdc++/config.h (revision 227112) > +++ gnu/lib/libstdc++/config.h (working copy) > @@ -671,7 +671,7 @@ > /* #undef VERSION */ >=20 > /* Define if builtin atomic operations are supported on this host. */ > -#if defined(__amd64__) || defined(__i386__) > +#if defined(__amd64__) || (defined(__i386__) && !defined(__tune_i386__)) > #define _GLIBCXX_ATOMIC_BUILTINS 1 > #endif >=20 > but unfortunately during the bootstrap stage, the system includes are > used, not those in the source tree... >=20 > At the moment I don't know a clean way out of this, except setting CC to > 'gcc -march=3Di486' and CXX to 'g++ -march=3Di486', and then building the > bootstrap-tools stage should at least complete successfully. I believe that sources were bootstrapable after the commit, with the old world. The solution could be to checkout exactly r198344, build and install new world, and then checkout latest HEAD. Personally, I would install from any snapshot, 9.0RC1 is good enough for later HEAD rebuild. --PQp0kazJUQKmOuaU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk61kXAACgkQC3+MBN1Mb4ji5gCgu6fdoe3cb1QcC74gxFVHVUpa RJQAnRoWP30CnDp4RmoLGYq6i26BlyYr =5VP1 -----END PGP SIGNATURE----- --PQp0kazJUQKmOuaU-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 20:01:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 496F6106564A; Sat, 5 Nov 2011 20:01:01 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id 08C098FC08; Sat, 5 Nov 2011 20:01:00 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 2AFD229125F; Sat, 5 Nov 2011 15:01:00 -0500 (CDT) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 102D72975F3; Sat, 5 Nov 2011 15:01:00 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id OQKNd9H0D+-5; Sat, 5 Nov 2011 15:00:59 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id 37B6629125F; Sat, 5 Nov 2011 15:00:59 -0500 (CDT) Message-ID: <4EB595FA.4020500@rice.edu> Date: Sat, 05 Nov 2011 15:00:58 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4EB22938.4050803@rice.edu> <20111103132437.GV50300@deviant.kiev.zoral.com.ua> <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111105151530.GX50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mdf@freebsd.org, "K. Macy" , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 20:01:01 -0000 On 11/05/2011 10:15, Kostik Belousov wrote: > On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote: >> On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov wrote: >>> On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: >>> >>> Below is the KBI patch after vm_page_bits_t merge is done. >>> Again, I did not spent time converting all in-tree consumers >>> from the (potentially) loadable modules to the new KPI until it >>> is agreed upon. >> I like my bikeshed orange... >> >> I would think a more canonical name would be get/set rather than >> read/write, especially since these operations aren't reading and >> writing the page (neither are they getting the page, but at least set >> is pretty unambiguous). > Look at the vm_page.h:385. vm_page_set_valid() is already taken. I don't feel good about creating an interface under which we have functions named vm_page_set_valid() and vm_page_write_valid(). I think that we should take a step back and look at the whole of set of functions that exist for manipulating the page's valid and dirty field and see if we can come up with a logical schema for naming them. I wouldn't then be surprised if this results in renaming some of the existing functions. However, this should not delay the changes to address the vm_page_lock problem. I had two questions about that part of your patch. First, is there any reason that you didn't include vm_page_lockptr()? If we created the page locking macros that you, jhb@, and I were talking about last week, then vm_page_lockptr() would be required. Second, there seems to be precedent for naming the locking functions _vm_page_lock() instead of vm_page_lock_func(), for example, the mutex code, i.e., sys/mutex.h, and the vm map locking functions. Alan From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 20:30:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4992E106566C for ; Sat, 5 Nov 2011 20:30:50 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C865D8FC12 for ; Sat, 5 Nov 2011 20:30:49 +0000 (UTC) Received: by wwp14 with SMTP id 14so5106879wwp.31 for ; Sat, 05 Nov 2011 13:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TbiHTyk6DGDem4Nwn2//P+6fJUlwpkn66L+6vKFO33s=; b=C83UIrFhnPYtvq4Ilp4MlRSL0RqgXm+TfzuR/T6ZZinfOkbXK5youOpmPkAIAHMSaw vVw38vUBqE8u+kx8E3lOaXupdYBl/x3jKT2gbwSMr7WtLJqG3i4rQc6x7UTxlHuzQIRU fN8yb128gz9pByg+QpdRt0890rbPluTPjyAJw= MIME-Version: 1.0 Received: by 10.180.74.197 with SMTP id w5mr3599165wiv.25.1320525048254; Sat, 05 Nov 2011 13:30:48 -0700 (PDT) Received: by 10.180.8.34 with HTTP; Sat, 5 Nov 2011 13:30:48 -0700 (PDT) Date: Sat, 5 Nov 2011 16:30:48 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Fix types of arguments to dtrace syscall return probes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 20:30:50 -0000 Currently if you try to use the args[] array passed to a syscall return probe, you get variables with the wrong type. This is because the systrace implementation is currently using the same function to provide the same argument types for both the entry and return probes, which is completely wrong. For example: # dtrace -v -l -n syscall::mmap:return ID PROVIDER MODULE FUNCTION NAME 32159 syscall mmap return Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Types args[0]: caddr_t args[1]: size_t args[2]: int args[3]: int args[4]: int args[5]: off_t The following patch[1] fixes this and provides the correct type to all return probes. For example, # dtrace -l -v -n syscall::mmap:return ID PROVIDER MODULE FUNCTION NAME 2000 syscall freebsd mmap return Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Types args[0]: caddr_t args[1]: caddr_t The patch: diff --git a/sys/cddl/dev/systrace/systrace.c b/sys/cddl/dev/systrace/systrace.c index cc48747..31c11c2 100644 --- a/sys/cddl/dev/systrace/systrace.c +++ b/sys/cddl/dev/systrace/systrace.c @@ -220,8 +220,12 @@ systrace_getargdesc(void *arg, dtrace_id_t id, void *parg, dtrace_argdesc_t *des { int sysnum = SYSTRACE_SYSNUM((uintptr_t)parg); - systrace_setargdesc(sysnum, desc->dtargd_ndx, desc->dtargd_native, - sizeof(desc->dtargd_native)); + if (SYSTRACE_ISENTRY((uintptr_t)parg)) + systrace_entry_setargdesc(sysnum, desc->dtargd_ndx, + desc->dtargd_native, sizeof(desc->dtargd_native)); + else + systrace_return_setargdesc(sysnum, desc->dtargd_ndx, + desc->dtargd_native, sizeof(desc->dtargd_native)); if (desc->dtargd_native[0] == '\0') desc->dtargd_ndx = DTRACE_ARGNONE; diff --git a/sys/kern/makesyscalls.sh b/sys/kern/makesyscalls.sh index d1162b5..1f081ce 100644 --- a/sys/kern/makesyscalls.sh +++ b/sys/kern/makesyscalls.sh @@ -38,6 +38,7 @@ sysinc="sysinc.switch.$$" sysarg="sysarg.switch.$$" sysprotoend="sysprotoend.$$" systracetmp="systrace.$$" +systraceret="systraceret.$$" if [ -r capabilities.conf ]; then capenabled=`cat capabilities.conf | grep -v "^#" | grep -v "^$"` @@ -46,9 +47,9 @@ else capenabled="" fi -trap "rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl $sysent $sysinc $sysarg $sysprotoend $systracetmp" 0 +trap "rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl $sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret" 0 -touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl $sysent $sysinc $sysarg $sysprotoend $systracetmp +touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4 $syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl $sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret case $# in 0) echo "usage: $0 input-file " 1>&2 @@ -96,6 +97,7 @@ s/\$//g sysmk = \"$sysmk\" systrace = \"$systrace\" systracetmp = \"$systracetmp\" + systraceret = \"$systraceret\" compat = \"$compat\" compat4 = \"$compat4\" compat6 = \"$compat6\" @@ -179,9 +181,12 @@ s/\$//g printf "\tint64_t *iarg = (int64_t *) uarg;\n" > systrace printf "\tswitch (sysnum) {\n" > systrace - printf "static void\nsystrace_setargdesc(int sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p = NULL;\n" > systracetmp + printf "static void\nsystrace_entry_setargdesc(int sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p = NULL;\n" > systracetmp printf "\tswitch (sysnum) {\n" > systracetmp + printf "static void\nsystrace_return_setargdesc(int sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p = NULL;\n" > systraceret + printf "\tswitch (sysnum) {\n" > systraceret + next } NF == 0 || $1 ~ /^;/ { @@ -202,6 +207,7 @@ s/\$//g print > sysnames print > systrace print > systracetmp + print > systraceret savesyscall = syscall next } @@ -216,6 +222,7 @@ s/\$//g print > sysnames print > systrace print > systracetmp + print > systraceret syscall = savesyscall next } @@ -230,6 +237,7 @@ s/\$//g print > sysnames print > systrace print > systracetmp + print > systraceret next } syscall != $1 { @@ -303,7 +311,8 @@ s/\$//g parserr($end, ")") end-- - f++ #function return type + syscallret=$f + f++ funcname=$f @@ -387,6 +396,7 @@ s/\$//g parseline() printf("\t/* %s */\n\tcase %d: {\n", funcname, syscall) > systrace printf("\t/* %s */\n\tcase %d:\n", funcname, syscall) > systracetmp + printf("\t/* %s */\n\tcase %d:\n", funcname, syscall) > systraceret if (argc > 0) { printf("\t\tswitch(ndx) {\n") > systracetmp printf("\t\tstruct %s *p = params;\n", argalias) > systrace @@ -406,6 +416,10 @@ s/\$//g argname[i], argtype[i]) > systrace } printf("\t\tdefault:\n\t\t\tbreak;\n\t\t};\n") > systracetmp + + printf("\t\tif (ndx == 0 || ndx == 1)\n") > systraceret + printf("\t\t\tp = \"%s\";\n", syscallret) > systraceret + printf("\t\tbreak;\n") > systraceret } printf("\t\t*n_args = %d;\n\t\tbreak;\n\t}\n", argc) > systrace printf("\t\tbreak;\n") > systracetmp @@ -623,6 +637,7 @@ s/\$//g > syshdr printf "\tdefault:\n\t\t*n_args = 0;\n\t\tbreak;\n\t};\n}\n" > systrace printf "\tdefault:\n\t\tbreak;\n\t};\n\tif (p != NULL)\n\t\tstrlcpy(desc, p, descsz);\n}\n" > systracetmp + printf "\tdefault:\n\t\tbreak;\n\t};\n\tif (p != NULL)\n\t\tstrlcpy(desc, p, descsz);\n}\n" > systraceret } ' cat $sysinc $sysent >> $syssw @@ -633,4 +648,5 @@ cat $sysarg $sysdcl \ $syscompat7 $syscompat7dcl \ $sysaue $sysprotoend > $sysproto cat $systracetmp >> $systrace +cat $systraceret >> $systrace [1] Can also be found at http://people.freebsd.org/~rstone/patches/dtrace_syscall_ret.diff From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 21:46:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FDD1065675 for ; Sat, 5 Nov 2011 21:46:45 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 838D88FC1D for ; Sat, 5 Nov 2011 21:46:45 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.5) with ESMTP id pA5LkiHK028416 for ; Sat, 5 Nov 2011 17:46:44 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.5/Submit) id pA5Lkik8028415 for current@freebsd.org; Sat, 5 Nov 2011 17:46:44 -0400 (EDT) (envelope-from mwlucas) Date: Sat, 5 Nov 2011 17:46:44 -0400 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20111105214644.GA28408@bewilderbeast.blackhelicopters.org> References: <20111104190912.GA21948@bewilderbeast.blackhelicopters.org> <4EB53803.2000205@FreeBSD.org> <20111105132816.GR50300@deviant.kiev.zoral.com.ua> <4EB58932.1030309@FreeBSD.org> <20111105194136.GI50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111105194136.GI50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Sat, 05 Nov 2011 17:46:44 -0400 (EDT) Cc: Subject: Re: 9.0/i386 build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 21:46:45 -0000 On Sat, Nov 05, 2011 at 09:41:36PM +0200, Kostik Belousov wrote: > Personally, I would install from any snapshot, 9.0RC1 is good enough for > later HEAD rebuild. Thank you, gentlemen! I believe that upgrading via snapshot is the smart solution here. But it'll be in the archives for anyone else bit by this issue. ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 22:31:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A261065674 for ; Sat, 5 Nov 2011 22:31:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB818FC17 for ; Sat, 5 Nov 2011 22:31:06 +0000 (UTC) Received: by wwp14 with SMTP id 14so5164734wwp.31 for ; Sat, 05 Nov 2011 15:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=yp+iQkKlVFookDn83T0YExW24NBXQHid7ntXtQm57zc=; b=Y0kXUAHDuQ+BDCPYG4Om3Q7DwOrvSBN6zDowXIpY97QSTniWdpCYv9Lq1Ou+crf0Ie CuWQ1RFDopOeGDHGhUzQriFA/ga8p4ngLqD416e2nFgFm1FAAyugFMaZzd07BzWghCu+ K2dEkfArE+uXgvSjIzJ7XLNAVhkEPAJlPhL5A= MIME-Version: 1.0 Received: by 10.181.13.82 with SMTP id ew18mr3751006wid.16.1320532265797; Sat, 05 Nov 2011 15:31:05 -0700 (PDT) Received: by 10.180.8.34 with HTTP; Sat, 5 Nov 2011 15:31:05 -0700 (PDT) Date: Sat, 5 Nov 2011 18:31:05 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Fix kernel panics when using dtrace fbt return probes on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 22:31:07 -0000 I have a patch that fixes crash when using dtrace fbt return probes on i386. dtrace implements an fbt probe by overwriting a small part of the function when the probe is active. On i386, it writes an invalid opcode. dtrace has a hook into the invalid opcode fault handler that checks whether the fault was due to an active probe; if it was, the probe fires and then the fault handler emulates the behaviour of the instruction that was replaced with the invalid opcode and returns control to the instruction after the invalid opcode. The bug is in the emulation of the leave instruction(which is replaced for an fbt return probe). The is a small window in which the emulation leaves critical state above the current stack pointer. If the CPU takes an interrupt in this window, the trap frame corrupts this state. The leave instruction is used to pop off a stack frame immediately prior to returning from a function. Because the leave emulation is running in a fault handler, it must copy the trap frame to the bottom of the stack frame that is being removed, set its stack pointer to the start of the new trap frame and then execute the iret instruction. There are actually two bugs in the current implementation. The first is that immediately before restoring the stack pointer to point to the new trap frame, the emulation must save the new stack pointer on the stack, restore the values of its scratch registers, and then load the new stack pointer back from the stack. The current implementation saves the new stack pointer at -4(%esp). If an interrupt is taking after the new stack pointer is saved at this location the trap frame will overwrite the new stack pointer. The fix for this is to instead save the new stack pointer at 8(%esp), which was part of the old trap frame that was copied forward. This is safe as we know that the trap frame must exist (so 8(%esp) can't possibly point to still-valid data from the next stack frame, for instances) and at this point we have copied the stack frame forward so we can safely overwrite the old one without any issues. The second bug is that when the new stack pointer is restored, it does not point at the new trap frame. Instead it points 8 bytes into the trap frame. The emulation code corrects for this by subtracting 8 from %esp before executing the iret. However if we take an interrupt after we have restored the new stack pointer, but before subtracting 8 from %esp, the trap frame from the interrupt will overwrite the first 8 bytes of the invalid opcode trap frame, causing us to crash when we execute the iret. The fix is to adjust the new stack pointer before saving onto the stack in the first place, so that we we restore it it is immediately valid, closing the window in which an interrupt can corrupt anything. If there are no objections to this patch I will commit it soonish. I would appreciate some review, but IMO this really needs to get in for 9.0 as a central tenet of dtrace is that it will not crash your system. Index: sys/cddl/dev/dtrace/i386/dtrace_asm.S =================================================================== --- sys/cddl/dev/dtrace/i386/dtrace_asm.S (revision 227094) +++ sys/cddl/dev/dtrace/i386/dtrace_asm.S (working copy) @@ -125,11 +125,11 @@ movl 8(%esp), %eax /* load calling EIP */ incl %eax /* increment over LOCK prefix */ movl %eax, -8(%ebx) /* store calling EIP */ - movl %ebx, -4(%esp) /* temporarily store new %esp */ + subl $8, %ebx /* adjust for three pushes, one pop */ + movl %ebx, 8(%esp) /* temporarily store new %esp */ popl %ebx /* pop off temp */ popl %eax /* pop off temp */ - movl -12(%esp), %esp /* set stack pointer */ - subl $8, %esp /* adjust for three pushes, one pop */ + movl (%esp), %esp /* set stack pointer */ iret /* return from interrupt */ invop_nop: /*