From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 00:13:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24D4106564A; Sun, 14 Nov 2010 00:13:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 603C98FC0C; Sun, 14 Nov 2010 00:13:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAE0D9Zj007940; Sat, 13 Nov 2010 19:13:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAE0D9JD007931; Sun, 14 Nov 2010 00:13:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Nov 2010 00:13:09 GMT Message-Id: <201011140013.oAE0D9JD007931@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 00:13:10 -0000 TB --- 2010-11-14 00:07:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-14 00:07:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-14 00:07:50 - cleaning the object tree TB --- 2010-11-14 00:07:53 - cvsupping the source tree TB --- 2010-11-14 00:07:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-14 00:08:07 - building world TB --- 2010-11-14 00:08:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-14 00:08:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-14 00:08:07 - TARGET=powerpc TB --- 2010-11-14 00:08:07 - TARGET_ARCH=powerpc64 TB --- 2010-11-14 00:08:07 - TZ=UTC TB --- 2010-11-14 00:08:07 - __MAKE_CONF=/dev/null TB --- 2010-11-14 00:08:07 - cd /src TB --- 2010-11-14 00:08:07 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 14 00:08:08 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-14 00:13:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-14 00:13:09 - ERROR: failed to build world TB --- 2010-11-14 00:13:09 - 205.25 user 57.69 system 318.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 03:40:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5F00106566B; Sun, 14 Nov 2010 03:40:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4272F8FC1C; Sun, 14 Nov 2010 03:40:21 +0000 (UTC) Received: by wwb29 with SMTP id 29so138749wwb.1 for ; Sat, 13 Nov 2010 19:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tcMYEDsRNYVwodpQanCbtYTN63VrtQyry5fnVtFTQ+w=; b=m1MJYfgrViTgw0aWK19btU/OQ+xcC+OI0/0PZdNxl04tK7qgRsrEQvi5ws1cHphEfa BUUzAzUgZf1q9PBfDGteCnC4YnnrKAhkhwlsRgOJujpKo7AtHHYTmmJAuqmE3eacCNmH hiQ7NSERcyaIpoz5NOkNHfcup/ZzGyaZwSeaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=k7lGigg/sbGI4NPFPPDM6FXlmydbADqhgvYH3CG3lw6IRH5LvqwIAoadTOncph3BEL ddep4XbcbTr9C/YIX6JYU1KpnrUq6K9xyBrlafzpzbqt31znAqNtUAkmC7SNcUOcMzPx XqvfTg7AdLou2je18mBU7P3wt7h9rEDaEe6vg= MIME-Version: 1.0 Received: by 10.216.142.131 with SMTP id i3mr5340577wej.5.1289706020496; Sat, 13 Nov 2010 19:40:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Sat, 13 Nov 2010 19:40:20 -0800 (PST) Date: Sun, 14 Nov 2010 11:40:20 +0800 X-Google-Sender-Auth: FFePrc8HCv2HcLXNbwOJAoaJMGU Message-ID: From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , freebsd-embedded@freebsd.org Subject: The path is now set for "busybox", FreeBSD style X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 03:40:22 -0000 Hi everyone, I've committed the below changes to -HEAD. You can now create and build your own busybox style binary system, completely cross-compiled within the existing Make framework. It isn't as impressive as it sounds though - a lot of the framework is already there from just building crunchgen'ed rescue/sysinstall binaries. There's a few things which should be done. Specifically, being able to build an alternative set of libraries before building the crunchgen target. The base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc but you may not want your crunch'ed image to have them. To do this right now, you have to disable these features in the main build. That may be OK for some. But just to stress it - I've got a couple of access point images at home running a crunchgen'ed environment under MIPS and besides the obvious binary bloat, it works perfectly well. Besides a cut-down startup framework, the image cross-builds entirely from the base FreeBSD source tree. Let me know if you'd like to give it a shot and I'll put my "bsdbox" Makefile scripts online to try. Adrian On 5 October 2010 10:36, Adrian Chadd wrote: > Hi, > > I've broken out the crunchgen logic from src/rescue/rescue into a > share/mk file - that way it can be reused in other areas. > > The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff > > This bsd.crunchgen.mk file is generic enough to use in my > busybox-style thing as well as for src/rescue/rescue/. > > Comments, feedback, etc welcome! > > > Adrian > From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 11:08:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A4B106566C; Sun, 14 Nov 2010 11:08:05 +0000 (UTC) (envelope-from adrian.chadd@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 CEAAF8FC16; Sun, 14 Nov 2010 11:08:04 +0000 (UTC) Received: by wyb36 with SMTP id 36so1551762wyb.13 for ; Sun, 14 Nov 2010 03:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=a5eu/imDk4kuntILXXMEKG/wTaiM9Ez0q+5rWuIUoGU=; b=VLYn0NgqApSKkIWswgFszzT3q1IkuWiHxvarEzinPEqZICMWHJcJpuN6UJb87VkRYC ExF431Cf8s/GJ83HOIEyWWRCgqz9DC6/+2MQ3yRfZJ7N70k7erwZgbqPOQKaX+WdFfTH yCsplRfnK2vdq2I0ZarEE+RkrqH6N64vwyRec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=IkbTJJk+CTeLoDgKivWEnKYMQcfiyqezCjJNgj5etYZyps1as9cmx0g29FRZsWab9m fKW8rA8uDLA3AGL9uj3moE8GXf0fAKGAfIgh2RIYGZFvcCxZYkzCagf0mA0/ZsPHh3MK o+c8eLlqHMtvZ8iXDKsnrH7tDs6zQE/IZoEM4= MIME-Version: 1.0 Received: by 10.216.179.81 with SMTP id g59mr5634495wem.35.1289732883801; Sun, 14 Nov 2010 03:08:03 -0800 (PST) Received: by 10.216.65.210 with HTTP; Sun, 14 Nov 2010 03:08:03 -0800 (PST) Date: Sun, 14 Nov 2010 19:08:03 +0800 Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-mobile@freebsd.org Subject: Non-ubiquiti AR9160's? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 11:08:05 -0000 Hi all, Does anyone out there have any non-Ubiquiti AR9160's? Ie, something that puts out the power it's supposed to, rather than pretending to be a different output power than what's configured. Please let me know if you do. I'd like to compare EEPROM outputs with you. thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 13:09:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A45401065670; Sun, 14 Nov 2010 13:09:19 +0000 (UTC) (envelope-from g.veniamin@googlemail.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 34DF88FC0C; Sun, 14 Nov 2010 13:09:17 +0000 (UTC) Received: by eyb7 with SMTP id 7so2562932eyb.13 for ; Sun, 14 Nov 2010 05:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=mMD4rOnT2lyCSFKPLB2RX1ezsSjaEZ62jahU2zL5lVc=; b=UBpDwYeuIlCAZ0W4AfNCcefPC+QvvZczYwCOi9NnLFsKtOPm7kpzitBqvG3WUk7aPx x5eiJSIY37UglLf4yV0RoPKKevPVdkAp3Ehbc4WO65FCUGbjQ4Ow38CKfY+tisOzIWoK G25h3758hC7iINHGUe0r19C7K9Q1BCtx3I7o4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=wBVhnmpiRS5ZRI9orJsf4iXcnimt0uhIcVI1mBQtmXQASaBPzqn+TnBdYsDJ5/jVhk XzRN/x+KETQDBEPvH7T1zZpIbxW9QgYCL970xa8GkjuQB/xTauWgcfpI7Mz4gWeqvuG3 RNzTCpbWxO7COCmLsMvP6Rx6AUzOV7ACT2kwM= Received: by 10.213.13.15 with SMTP id z15mr2312135ebz.30.1289740156563; Sun, 14 Nov 2010 05:09:16 -0800 (PST) Received: from zlobook.local (zlonet.ru [94.78.205.21]) by mx.google.com with ESMTPS id v51sm5463551eeh.22.2010.11.14.05.09.11 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 05:09:14 -0800 (PST) Message-ID: <4CDFDF76.3080102@googlemail.com> Date: Sun, 14 Nov 2010 20:09:10 +0700 From: Veniamin Gvozdikov User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky , jkim@FreeBSD.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <4CDD7922.1060105@googlemail.com> <201011122131.57554.hselasky@c2i.net> <4CDE8738.1040406@googlemail.com> <201011131345.43364.hselasky@c2i.net> In-Reply-To: <201011131345.43364.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="------------040602000703070109000602" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: MacBookPro7,1 and FreeBSD 8.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 13:09:19 -0000 This is a multi-part message in MIME format. --------------040602000703070109000602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. I think that I can broke my laptop %) I same found information about MacBook in the files: sys/dev/asmc/asmc.c sys/dev/asmc/asmcvar.h sys/dev/usb/input/atp.c I attached acpi dumps from this is how to http://www.projectosx.com/forum/index.php?showtopic=359 > On Saturday 13 November 2010 13:40:24 Veniamin Gvozdikov wrote: >> Hello. >> I fund a few lines about the macbook but I have issue. >> >> if (strncmp(sysenv, "MacBook5,1", 10) == 0 || >> strncmp(sysenv, "MacBookPro5,5", 13) == 0 || >> strncmp(sysenv, "Macmini3,1", 10) == 0) >> strncmp(sysenv, "Macmini3,1", 10) == 0 || >> strncmp(sysenv, "iMac9,1", 7) == 0) >> >> I see for macbookpro5,5 value 13, where is can I found value for 7,1? > 13 is the length of the string exluding the terminating zero. > > --HPS > >> thank you! >> >>> This might be because your model is not listed in a quirk-table: >>> >>> grep -ri macbook /usr/src/sys/amd64 >>> >>> /usr/src/sys/amd64/amd64/machdep.c >>> >>> --HPS --------------040602000703070109000602-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 15:10:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E21106564A; Sun, 14 Nov 2010 15:10:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 79C998FC0A; Sun, 14 Nov 2010 15:10:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAEFAbtu011077; Sun, 14 Nov 2010 10:10:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAEFAbUM011057; Sun, 14 Nov 2010 15:10:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Nov 2010 15:10:37 GMT Message-Id: <201011141510.oAEFAbUM011057@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 15:10:38 -0000 TB --- 2010-11-14 14:57:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-14 14:57:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-14 14:57:08 - cleaning the object tree TB --- 2010-11-14 14:57:11 - cvsupping the source tree TB --- 2010-11-14 14:57:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-14 14:57:50 - building world TB --- 2010-11-14 14:57:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-14 14:57:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-14 14:57:50 - TARGET=powerpc TB --- 2010-11-14 14:57:50 - TARGET_ARCH=powerpc64 TB --- 2010-11-14 14:57:50 - TZ=UTC TB --- 2010-11-14 14:57:50 - __MAKE_CONF=/dev/null TB --- 2010-11-14 14:57:50 - cd /src TB --- 2010-11-14 14:57:50 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 14 14:57:50 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries -------------------------------------------------------------- cd /src; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make -f Makefile.inc1 DESTDIR=/obj/powerpc.powerpc64/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /src; /usr/bin/make -f Makefile.inc1 _prereq_libs; /usr/bin/make -f Makefile.inc1 _startup_libs; /usr/bin/make -f Makefile.inc1 _prebuild_libs; /usr/bin/make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c Assembler messages: FATAL: can't create ssp-local.o: Invalid bfd target *** Error code 2 Stop in /src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-14 15:10:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-14 15:10:37 - ERROR: failed to build world TB --- 2010-11-14 15:10:37 - 585.13 user 110.62 system 808.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 15:33:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A871065679; Sun, 14 Nov 2010 15:33:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B8A068FC08; Sun, 14 Nov 2010 15:33:06 +0000 (UTC) Received: by bwz2 with SMTP id 2so4468654bwz.13 for ; Sun, 14 Nov 2010 07:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=SLNfXrMcepKZZk3c+l2QNA9WCzTqjdskeZCqcu4vtvE=; b=m0S1cjNAvziq2ZpqBFQm8e+QcChhpVjMdJek5axA4PlJxRAnFmTjTF4/1kCBN4r/6S CWjGApja3kvYWaPgz/gB/LuqnSA+ieoKyIcKrkNNRiFWOlDfhJDP7v3blycVPvbaRX1A gxnbTkvTYvTNLNx8pPM39AEND1Ihm9yRyuljM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=a2HWqdDpYE8uY1piSuHTJ0r07DK4raa+8D0pxqtXIkqoj7PVyZ9vqQprrnCB349kx2 +WoEdvdvpSZAxbA02Dv+Mt4oqFi5dn+ZgJuDrcDJiJe9xFYyGt23e5tkpeq2SiL8QYq/ /djEhAjafCHwu6cwSSo/9IYBBW2rpxXN7vJsk= Received: by 10.204.59.193 with SMTP id m1mr5027545bkh.176.1289748785602; Sun, 14 Nov 2010 07:33:05 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f21sm2537431bkf.0.2010.11.14.07.33.02 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 07:33:03 -0800 (PST) Sender: Alexander Motin Message-ID: <4CE0010D.7080505@FreeBSD.org> Date: Sun, 14 Nov 2010 17:32:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Brandon Gooch References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 15:33:07 -0000 Brandon Gooch wrote: > On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: >> Now uncommitted pass_autosence.patch and possibly cdrtools.patch. > > OK. Patched kernel and cdrtools has resulted in a working cdrecord > (burned an ISO successfully) and an endless stream of: > > ... > (pass0:ata0:0:0:0): Requesting SCSI sense data > (pass0:ata0:0:0:0): SCSI status error > (pass0:ata0:0:0:0): Requesting SCSI sense data > (pass0:ata0:0:0:0): SCSI status error > (pass0:ata0:0:0:0): Requesting SCSI sense data > (pass0:ata0:0:0:0): SCSI status error > (pass0:ata0:0:0:0): Requesting SCSI sense data > (pass0:ata0:0:0:0): SCSI status error > ... I think it can be hald probing for media insertion. Probably we should slightly reduce error logging verbosity. May be somehow make to not log errors on requests submitted from user-level via pass driver. > But most important part: It works, and it burned very quickly! The CD > was created, and fully functional (I booted the Fedora image and > completed an installation). Nice! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 15:40:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A376F1065672 for ; Sun, 14 Nov 2010 15:40:48 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id 30F368FC14 for ; Sun, 14 Nov 2010 15:40:47 +0000 (UTC) Received: from unixmania.com ([187.153.244.221]) by ns2.bafirst.com with esmtp; Sun, 14 Nov 2010 09:40:38 -0600 id 000D4C4D.4CE002F6.00002F2B Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Sun, 14 Nov 2010 09:40:45 -0600 id 000CF523.4CE002FD.0000E615 Received: from dsl-189-251-44-203-dyn.prod-infinitum.com.mx (dsl-189-251-44-203-dyn.prod-infinitum.com.mx [189.251.44.203]) by econet.encontacto.net (Horde Framework) with HTTP; Sun, 14 Nov 2010 09:40:45 -0600 Message-ID: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> Date: Sun, 14 Nov 2010 09:40:45 -0600 From: eculp To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4 X-IMP-Server: 187.153.244.221 X-Originating-IP: 189.251.44.203 X-Originating-User: eculp@encontacto.net Subject: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 15:40:48 -0000 I build world several times a week on this machine: 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 Since the above build I have not been able to get past gnu. Today it broke at gdb : =3D=3D=3D> gnu/usr.bin/dialog (cleandir) =3D=3D=3D> gnu/usr.bin/dialog/TESTS (cleandir) =3D=3D=3D> gnu/usr.bin/diff (cleandir) =3D=3D=3D> gnu/usr.bin/diff/doc (cleandir) rm -f diff.info diff.info.gz =3D=3D=3D> gnu/usr.bin/diff3 (cleandir) =3D=3D=3D> gnu/usr.bin/gdb (cleandir) =3D=3D=3D> gnu/usr.bin/gdb/doc (cleandir) =3D=3D=3D> gnu/usr.bin/gdb/libgdb (cleandir) Unclosed substitution for TARGET_ARCH (/ missing) *** Error code 2 Stop in /usr/src/gnu/usr.bin/gdb. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 My main concern is if it is my error or a known problem that I have =20 missed. I regularly do make check-old and delete-old. Thanks for confirming, ed P.S. This isn't a problem but a concern. From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 15:50:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6144C1065675 for ; Sun, 14 Nov 2010 15:50:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1B58FC0C for ; Sun, 14 Nov 2010 15:50:48 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oAEFof4C030251; Sun, 14 Nov 2010 07:50:41 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oAEFofct030250; Sun, 14 Nov 2010 07:50:41 -0800 (PST) (envelope-from david) Date: Sun, 14 Nov 2010 07:50:41 -0800 From: David Wolfskill To: eculp Message-ID: <20101114155041.GI1671@albert.catwhisker.org> References: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BWWlCdgt6QLN7tv3" Content-Disposition: inline In-Reply-To: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current Subject: Re: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 15:50:49 -0000 --BWWlCdgt6QLN7tv3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 14, 2010 at 09:40:45AM -0600, eculp wrote: > I build world several times a week on this machine: > 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 >=20 > Since the above build I have not been able to get past gnu. >=20 > Today it broke at gdb : > ... > Stop in /usr/src/gnu/usr.bin/gdb. > *** Error code 1 >=20 > Stop in /usr/src/gnu/usr.bin. > *** Error code 1 >=20 > Stop in /usr/src/gnu. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > My main concern is if it is my error or a known problem that I have =20 > missed. I regularly do make check-old and delete-old. >=20 > Thanks for confirming, Cannot confirm. I track stable/8 & head daily, both on a build machine and my laptop; most recent "uname -a" results for head for my laptop are: FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #42 r215173:= Fri Nov 12 05:10:01 PST 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/= src/sys/CANARY i386 FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #43 r215238:= Sat Nov 13 05:11:32 PST 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/= src/sys/CANARY i386 FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #44 r215293:= Sun Nov 14 05:15:13 PST 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/= src/sys/CANARY i386 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --BWWlCdgt6QLN7tv3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzgBVAACgkQmprOCmdXAD1PcgCfTwGogQOYKV2SVDoFT/HhjGWX ItMAnRLezDwYcYzti7aCxeafO3C8PMeR =aLbv -----END PGP SIGNATURE----- --BWWlCdgt6QLN7tv3-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 16:02:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9760F1065674 for ; Sun, 14 Nov 2010 16:02:49 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF4E8FC08 for ; Sun, 14 Nov 2010 16:02:48 +0000 (UTC) Received: by ewy3 with SMTP id 3so1049124ewy.13 for ; Sun, 14 Nov 2010 08:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=LqWggCYma9SXCMUhSOpvixO/HHOP2X/XAZsPPrDEOBE=; b=TEAj82A/DLfni6sP9IQBtbznHZA0g/o0e6h7Ttpx2LJKEofemaIJdhXS9Kw4QIWDTR K5YdQUAH0RDOKBH0DOOmglBqp2miixRx4YE35Cs904J7XoxsPewKkdgyQI+3OvF1sTQW F0jwraW0cvzh8NKbESglXslEpRSTs1plvljh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uiBE+2Eciw31hCyZ1cCQAcLCjYbtXEKvYC6cAUAqEwyWeQpvkzZU1ZSlQH+zk6s3WK 0Ok+iGda7ZjWdem808je1bOH/rXhSrgfLccs7oMIzpLISpIA3tNk5cCPflk7n3Y7IjK5 A+X+5FJAaL0wfgsuV9q3yemn2RjFNhUtC+8nY= MIME-Version: 1.0 Received: by 10.213.17.13 with SMTP id q13mr4118551eba.65.1289748973623; Sun, 14 Nov 2010 07:36:13 -0800 (PST) Received: by 10.213.27.144 with HTTP; Sun, 14 Nov 2010 07:36:13 -0800 (PST) Date: Sun, 14 Nov 2010 09:36:13 -0600 Message-ID: From: "Edwin L. Culp W." To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Subject: world build stuck in gnu for almost a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 16:02:49 -0000 I build world several times a week on this machine: 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 Since the above build I have not been able to get past gnu. Today it broke at gdb : ===> gnu/usr.bin/dialog (cleandir) ===> gnu/usr.bin/dialog/TESTS (cleandir) ===> gnu/usr.bin/diff (cleandir) ===> gnu/usr.bin/diff/doc (cleandir) rm -f diff.info diff.info.gz ===> gnu/usr.bin/diff3 (cleandir) ===> gnu/usr.bin/gdb (cleandir) ===> gnu/usr.bin/gdb/doc (cleandir) ===> gnu/usr.bin/gdb/libgdb (cleandir) Unclosed substitution for TARGET_ARCH (/ missing) *** Error code 2 Stop in /usr/src/gnu/usr.bin/gdb. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 My main concern is if it is my error or a known problem that I have missed. I regularly do make check-old and delete-old. Thanks for confirming, ed P.S. This isn't a problem but a concern. From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 16:41:34 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7AB10656E9 for ; Sun, 14 Nov 2010 16:41:34 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 271CC8FC18 for ; Sun, 14 Nov 2010 16:41:33 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id oAEGJjbg009781; Sun, 14 Nov 2010 17:19:46 +0100 (CET) (envelope-from andreast@FreeBSD.org) Message-ID: <4CE00C21.7050004@FreeBSD.org> Date: Sun, 14 Nov 2010 17:19:45 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: eculp References: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> In-Reply-To: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 16:41:34 -0000 On 14.11.10 16:40, eculp wrote: > I build world several times a week on this machine: > 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 > > Since the above build I have not been able to get past gnu. > > Today it broke at gdb : > > > ===> gnu/usr.bin/dialog (cleandir) > ===> gnu/usr.bin/dialog/TESTS (cleandir) > ===> gnu/usr.bin/diff (cleandir) > ===> gnu/usr.bin/diff/doc (cleandir) > rm -f diff.info diff.info.gz > ===> gnu/usr.bin/diff3 (cleandir) > ===> gnu/usr.bin/gdb (cleandir) > ===> gnu/usr.bin/gdb/doc (cleandir) > ===> gnu/usr.bin/gdb/libgdb (cleandir) > Unclosed substitution for TARGET_ARCH (/ missing) This one was fixed today: http://svn.freebsd.org/viewvc/base?view=revision&revision=215292 Gruss, Andreas From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 17:05:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3498D106564A; Sun, 14 Nov 2010 17:05:10 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA18C8FC08; Sun, 14 Nov 2010 17:05:09 +0000 (UTC) Received: by gwj20 with SMTP id 20so2310146gwj.13 for ; Sun, 14 Nov 2010 09:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:subject:x-enigmail-version :content-type:content-transfer-encoding; bh=iSnXMueL4TheEPrIU1ByWMaZyf1s7/OLa6YxKrA/qlI=; b=K6EWDaoVb6v4UK6eVOvNVIyvofYMfma0FxsYU5lF6H2gOwxTmAG5OYM4LUBU1fkVvY sCdQ+8mn70Ra2Oxjw9X9XoRBFWNUZbemPCFWM/JCT1wsnhTwZT1BU3JqXg+iE/78xQ0e 7exHaf1Nwm0/3WEKhTXSaJM7RXGT179XCoHJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; b=UhAOMDdU6AcO1Sc+Rvb3P2RNoGxB9g5PYaC7oLwIVxAkpxgK/1RxAuoIlGP+4dm7fo 0n0Fz1E5OKgKhKzMXME6NPMZ844yiR6OraMq0Fd9mOoy4gD51Zd7+S0tZjKVa24hZaYk LwExD5N47fqZ8YJpohCQiZ/XZXDmWX1LB+HOo= Received: by 10.151.83.16 with SMTP id k16mr7898651ybl.239.1289752608430; Sun, 14 Nov 2010 08:36:48 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-158-26.dsl.klmzmi.sbcglobal.net [99.181.158.26]) by mx.google.com with ESMTPS id q8sm2250881ybk.12.2010.11.14.08.36.46 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 08:36:47 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CE0101D.4020600@DataIX.net> Date: Sun, 14 Nov 2010 11:36:45 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Jilles Tjoelker , FreeBSD Current X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: head/bin/sh/output.h r215303 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 17:05:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Jilles, I just merged some of the changes to stable/8 of bin/sh, specifically all the recent changes that happened. In revision 215303 it shows that you added stddef.h as an include to output.h while jobs.c includes both output.h and stddef.h resulting in 'offsetof' being redefined. This fixes the problem, diff -r e16f819581a1 bin/sh/jobs.c - --- a/bin/sh/jobs.c Sun Nov 14 11:07:41 2010 -0500 +++ b/bin/sh/jobs.c Sun Nov 14 11:35:11 2010 -0500 @@ -41,7 +41,6 @@ #include #include #include - -#include #include #include #include - -- jhell,v -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJM4BAdAAoJEJBXh4mJ2FR+2soH/1wsPWvw8fM2mzlYcfch51LA nOC7CLxDw1tirMmH/TeVmG1vZt0l1HbW15c3wuxgjLt1ubDiAGiR4FRFj0LIz4FS xtnHlpT4HednVBxRflqhPr1KoJWNoM94r3GF93DwHpYsMTpThtWoV1RpnPW9ZrNs +IaooRECQazDnb5ctQq64ysrzTTmqw9khRRS8ovGTjOQCNaHA1/68rTVpj6Kykne OqlVHFRnxqdaC/+yxocyWpAk4T4zPzTz4H7kTdiWcGhphjuhJPtTFweJPQpD4VV/ QkNecRocgYp0fDB3wjhCqu4QN2AF48AveKtbAYlFKC92//8ShXDGdTOCID3CeLs= =63/p -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 17:23:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F20310656AA for ; Sun, 14 Nov 2010 17:23:45 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8798FC24 for ; Sun, 14 Nov 2010 17:23:44 +0000 (UTC) Received: from unixmania.com ([187.153.244.221]) by ns2.bafirst.com with esmtp; Sun, 14 Nov 2010 11:23:34 -0600 id 000D4CF7.4CE01B17.000030BA Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Sun, 14 Nov 2010 11:23:41 -0600 id 000CF574.4CE01B1D.0000EFD9 Received: from dsl-189-251-44-203-dyn.prod-infinitum.com.mx (dsl-189-251-44-203-dyn.prod-infinitum.com.mx [189.251.44.203]) by econet.encontacto.net (Horde Framework) with HTTP; Sun, 14 Nov 2010 11:23:41 -0600 Message-ID: <20101114112341.157320z24i4cquzo@econet.encontacto.net> Date: Sun, 14 Nov 2010 11:23:41 -0600 From: eculp To: freebsd-current@freebsd.org References: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> <4CE00C21.7050004@FreeBSD.org> In-Reply-To: <4CE00C21.7050004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4 X-IMP-Server: 187.153.244.221 X-Originating-IP: 189.251.44.203 X-Originating-User: eculp@encontacto.net Subject: Re: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 17:23:45 -0000 Quoting Andreas Tobler : > On 14.11.10 16:40, eculp wrote: >> I build world several times a week on this machine: >> 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 >> >> Since the above build I have not been able to get past gnu. >> >> Today it broke at gdb : >> >> >> ===> gnu/usr.bin/dialog (cleandir) >> ===> gnu/usr.bin/dialog/TESTS (cleandir) >> ===> gnu/usr.bin/diff (cleandir) >> ===> gnu/usr.bin/diff/doc (cleandir) >> rm -f diff.info diff.info.gz >> ===> gnu/usr.bin/diff3 (cleandir) >> ===> gnu/usr.bin/gdb (cleandir) >> ===> gnu/usr.bin/gdb/doc (cleandir) >> ===> gnu/usr.bin/gdb/libgdb (cleandir) >> Unclosed substitution for TARGET_ARCH (/ missing) > > This one was fixed today: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=215292 Thanks, I supped too early, ed From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 17:56:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125EB1065695; Sun, 14 Nov 2010 17:56:23 +0000 (UTC) (envelope-from jhein@gossamer.timing.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mx1.freebsd.org (Postfix) with ESMTP id CF0B58FC08; Sun, 14 Nov 2010 17:56:22 +0000 (UTC) Received: from gossamer.timing.com ([206.168.13.144]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MSciy-1OsUEZ1nm8-00RrxR; Sun, 14 Nov 2010 12:43:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19680.8138.582316.245120@gossamer.timing.com> Date: Sun, 14 Nov 2010 10:43:38 -0700 From: John Hein To: Adrian Chadd In-Reply-To: References: X-Mailer: VM 8.0.12 under 22.3.1 (i386-redhat-linux-gnu) X-Provags-ID: V02:K0:KWdt4qXSYYaHeYMvN0pjr3m7dKXDF7vueTe2JPHG6W3 EJnY+InP3N0smu+BSQodDMYgY1QqwdgWUzAkjwaMfe6d8WFtEA //IOig+XQfK3T81SOP990JDOZkDBEmT2vmJcJbD9BH8u6ImeQC 0G1ZVTgwyNvDLcnQrk3F2JrDShnMFMTGwFabHW0v0RIV5tG/yq lr+Bj4IC5yX0SWrlPNf4g== Cc: freebsd-hackers@freebsd.org, freebsd-current , freebsd-embedded@freebsd.org Subject: Re: The path is now set for "busybox", FreeBSD style X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 17:56:23 -0000 Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > I've committed the below changes to -HEAD. You can now create and build your > own busybox style binary system, completely cross-compiled within the > existing Make framework. It isn't as impressive as it sounds though - a lot > of the framework is already there from just building crunchgen'ed > rescue/sysinstall binaries. > > There's a few things which should be done. Specifically, being able to build > an alternative set of libraries before building the crunchgen target. The > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc > but you may not want your crunch'ed image to have them. To do this right > now, you have to disable these features in the main build. That may be OK > for some. > > But just to stress it - I've got a couple of access point images at home > running a crunchgen'ed environment under MIPS and besides the obvious binary > bloat, it works perfectly well. Besides a cut-down startup framework, the > image cross-builds entirely from the base FreeBSD source tree. > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > Makefile scripts online to try. That's great. I assume it be not be hard for someone to take your scripts as a starting point and create a sysutils/bsdbox akin to sysutils/busybox? From owner-freebsd-current@FreeBSD.ORG Sun Nov 14 19:46:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6311F1065670 for ; Sun, 14 Nov 2010 19:46:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id F27058FC08 for ; Sun, 14 Nov 2010 19:46:28 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 23F081DD649; Sun, 14 Nov 2010 20:46:27 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 0A9B31735C; Sun, 14 Nov 2010 20:46:27 +0100 (CET) Date: Sun, 14 Nov 2010 20:46:26 +0100 From: Jilles Tjoelker To: jhell Message-ID: <20101114194626.GB1831@stack.nl> References: <4CE0101D.4020600@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE0101D.4020600@DataIX.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current Subject: Re: head/bin/sh/output.h r215303 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2010 19:46:29 -0000 On Sun, Nov 14, 2010 at 11:36:45AM -0500, jhell wrote: > I just merged some of the changes to stable/8 of bin/sh, specifically > all the recent changes that happened. In revision 215303 it shows that > you added stddef.h as an include to output.h while jobs.c includes both > output.h and stddef.h resulting in 'offsetof' being redefined. This problem was introduced by r213775 include changes, which you have merged yourself. I had already noticed this myself in head and fixed it in r213925. I have now MFCed r213775 and r213925 so your problem should be solved. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 05:01:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0709B106566B for ; Mon, 15 Nov 2010 05:01:25 +0000 (UTC) (envelope-from jhellenthal@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 AE3678FC20 for ; Mon, 15 Nov 2010 05:01:24 +0000 (UTC) Received: by gxk9 with SMTP id 9so2908807gxk.13 for ; Sun, 14 Nov 2010 21:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jAK89TGg8aVTr3T2amwxBRhdg8x2aGejmkFdPvDtdaI=; b=JD6LPBDEzHuy6gfPXuqwgr53pwdN2amMXc1oX9/FJoaJo3D/xVzMlvC571hykvZUOk x2EqZwsUWCE7rRSL31tVfzRcyHOjCoAvaZ5Q0PP+yEfW+QvQf6aOtHQ68Q4LxJeNzEky mexzFQmGAn2faG0FKuB/gCrmF/s7Er7CFU35g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FQpaQrxjvvWGH/Dp0MTmIdIAAw5t0E0nGAWMDKZp8pXY7d2PG5e8GhVwPOqoSKv8hF CKxdy/BVKxz3lT1y78vqCgpb2xg5ymyr3mPSmVrd2JO47lf6/KUggFqq2F8oirXvuob5 y2mCmMV2MK42ly0BCG6hagCdpqk69s+hYNI94= Received: by 10.151.9.8 with SMTP id m8mr8814084ybi.213.1289797283877; Sun, 14 Nov 2010 21:01:23 -0800 (PST) Received: from centel.dataix.local ([99.181.158.26]) by mx.google.com with ESMTPS id q41sm2827192ybk.13.2010.11.14.21.01.20 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 21:01:22 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CE0BE9F.7050203@DataIX.net> Date: Mon, 15 Nov 2010 00:01:19 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Jilles Tjoelker References: <4CE0101D.4020600@DataIX.net> <20101114194626.GB1831@stack.nl> In-Reply-To: <20101114194626.GB1831@stack.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: head/bin/sh/output.h r215303 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 05:01:25 -0000 On 11/14/2010 14:46, Jilles Tjoelker wrote: > On Sun, Nov 14, 2010 at 11:36:45AM -0500, jhell wrote: >> I just merged some of the changes to stable/8 of bin/sh, specifically >> all the recent changes that happened. In revision 215303 it shows that >> you added stddef.h as an include to output.h while jobs.c includes both >> output.h and stddef.h resulting in 'offsetof' being redefined. > > This problem was introduced by r213775 include changes, which you have > merged yourself. I had already noticed this myself in head and fixed it > in r213925. > > I have now MFCed r213775 and r213925 so your problem should be solved. > Ugh! thanks Still not quite clear on how a full merge of the changes in head to what is in stable would have missed that, so I guess Ill just have to look into that. -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 06:15:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045C8106566C; Mon, 15 Nov 2010 06:15:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C3AA28FC16; Mon, 15 Nov 2010 06:15:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAF6Fu7s033651; Mon, 15 Nov 2010 01:15:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAF6FuWA033650; Mon, 15 Nov 2010 06:15:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Nov 2010 06:15:56 GMT Message-Id: <201011150615.oAF6FuWA033650@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 06:15:58 -0000 TB --- 2010-11-15 06:02:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-15 06:02:49 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-15 06:02:49 - cleaning the object tree TB --- 2010-11-15 06:02:54 - cvsupping the source tree TB --- 2010-11-15 06:02:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-15 06:03:14 - building world TB --- 2010-11-15 06:03:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-15 06:03:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-15 06:03:14 - TARGET=powerpc TB --- 2010-11-15 06:03:14 - TARGET_ARCH=powerpc64 TB --- 2010-11-15 06:03:14 - TZ=UTC TB --- 2010-11-15 06:03:14 - __MAKE_CONF=/dev/null TB --- 2010-11-15 06:03:14 - cd /src TB --- 2010-11-15 06:03:14 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 15 06:03:15 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries -------------------------------------------------------------- cd /src; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make -f Makefile.inc1 DESTDIR=/obj/powerpc.powerpc64/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /src; /usr/bin/make -f Makefile.inc1 _prereq_libs; /usr/bin/make -f Makefile.inc1 _startup_libs; /usr/bin/make -f Makefile.inc1 _prebuild_libs; /usr/bin/make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c Assembler messages: FATAL: can't create ssp-local.o: Invalid bfd target *** Error code 2 Stop in /src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-15 06:15:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-15 06:15:56 - ERROR: failed to build world TB --- 2010-11-15 06:15:56 - 585.12 user 114.82 system 786.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 12:33:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337E71065670 for ; Mon, 15 Nov 2010 12:33:57 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id CBA8A8FC21 for ; Mon, 15 Nov 2010 12:33:56 +0000 (UTC) Received: from unixmania.com ([187.153.244.221]) by ns2.bafirst.com with esmtp; Mon, 15 Nov 2010 06:33:47 -0600 id 000D4C4D.4CE128AB.0000737B Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Mon, 15 Nov 2010 06:33:53 -0600 id 000CF671.4CE128B1.00011D16 Received: from dsl-189-251-44-203-dyn.prod-infinitum.com.mx (dsl-189-251-44-203-dyn.prod-infinitum.com.mx [189.251.44.203]) by econet.encontacto.net (Horde Framework) with HTTP; Mon, 15 Nov 2010 06:33:53 -0600 Message-ID: <20101115063353.42711xu4ckv3esw0@econet.encontacto.net> Date: Mon, 15 Nov 2010 06:33:53 -0600 From: eculp To: freebsd-current@freebsd.org References: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> <4CE00C21.7050004@FreeBSD.org> In-Reply-To: <4CE00C21.7050004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4 X-IMP-Server: 187.153.244.221 X-Originating-IP: 189.251.44.203 X-Originating-User: eculp@encontacto.net Subject: Re: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 12:33:57 -0000 Quoting Andreas Tobler : > On 14.11.10 16:40, eculp wrote: >> I build world several times a week on this machine: >> 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 >> >> Since the above build I have not been able to get past gnu. >> >> Today it broke at gdb : >> >> >> =3D=3D=3D> gnu/usr.bin/dialog (cleandir) >> =3D=3D=3D> gnu/usr.bin/dialog/TESTS (cleandir) >> =3D=3D=3D> gnu/usr.bin/diff (cleandir) >> =3D=3D=3D> gnu/usr.bin/diff/doc (cleandir) >> rm -f diff.info diff.info.gz >> =3D=3D=3D> gnu/usr.bin/diff3 (cleandir) >> =3D=3D=3D> gnu/usr.bin/gdb (cleandir) >> =3D=3D=3D> gnu/usr.bin/gdb/doc (cleandir) >> =3D=3D=3D> gnu/usr.bin/gdb/libgdb (cleandir) >> Unclosed substitution for TARGET_ARCH (/ missing) > > This one was fixed today: > > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D215292 > > Gruss, > Andreas Thanks, Andreas. With a new cvsup this morning it now stops at a =20 different point for me: Making grotty.1 from =20 /usr/src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/grof= f/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz =3D=3D=3D> gnu/usr.bin/groff/src/preproc (all) =3D=3D=3D> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe =20 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff= /src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/prepro= c/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/gro= ff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exc= eptions -c =20 eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ed From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 12:45:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33AF11065672 for ; Mon, 15 Nov 2010 12:45:53 +0000 (UTC) (envelope-from swell.k@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 DD1518FC14 for ; Mon, 15 Nov 2010 12:45:52 +0000 (UTC) Received: by ywa8 with SMTP id 8so2495965ywa.13 for ; Mon, 15 Nov 2010 04:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :in-reply-to:references:user-agent:date:message-id:mime-version :content-type; bh=JtUXygGeCWItcGZykyxBVow/tnmIRr/AYXzFHcSjX8A=; b=L5eco4gyHIzjJ9zKtOqUgSSqRkGoU1dhZ6DPjDP5cmkBjraU/tC4yq0g9j8U2WDocM C6bHGZV4sgj8JfhpV/NQx/as+7AG35uj8u4MU7JY3uNBvqGye6RhqmggDUORo8MDwGRn OFF4BXPOAqlr+6ZbeR/vbzb8Mc/vz7b1/+7Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; b=Ml+uPXB5PtGvz7N6hyGqLrA6Cq998NY2Mqr26Sy1w+YO7r09OrGVLOaAqTKfiwEKOi VpjHuW2HU9Vmp8T/FXRW5Ql9+nvz9v4VH9W32LcFZQiKf7BaO+kQSTLASSV7lI+N6gIK f1K8Kds2mCPBqdm7ie1UmEFqXIh5f292VYv0w= Received: by 10.90.4.19 with SMTP id 19mr7681637agd.195.1289825150162; Mon, 15 Nov 2010 04:45:50 -0800 (PST) Received: from localhost (tor-exit-proxy5-readme.formlessnetworking.net [208.53.142.41]) by mx.google.com with ESMTPS id i70sm4572694yha.22.2010.11.15.04.45.47 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Nov 2010 04:45:49 -0800 (PST) From: Anonymous To: eculp In-Reply-To: <20101115063353.42711xu4ckv3esw0@econet.encontacto.net> (eculp@encontacto.net's message of "Mon, 15 Nov 2010 06:33:53 -0600") References: <20101114094045.20695b96t90gjrpc@econet.encontacto.net> <4CE00C21.7050004@FreeBSD.org> <20101115063353.42711xu4ckv3esw0@econet.encontacto.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) Date: Mon, 15 Nov 2010 15:45:43 +0300 Message-ID: <86wroeg3go.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: world build stuck in gnu for about a week for me. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 12:45:53 -0000 eculp writes: > Thanks, Andreas. With a new cvsup this morning it now stops at a > different point for me: > > > Making grotty.1 from > /usr/src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man > gzip -cn grotty.1 > grotty.1.gz > ===> gnu/usr.bin/groff/src/preproc (all) > ===> gnu/usr.bin/groff/src/preproc/eqn (all) > c++ -O2 -pipe > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn > -I. -DHAVE_CONFIG_H > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include > -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > y.tab.c: In function 'int yygrowstack()': > y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' > *** Error code 1 If you have r214990 try to reinstall yacc(1) before buildworld. $ make all install -C usr.bin/yacc From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 17:05:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A54D106578D; Mon, 15 Nov 2010 17:05:52 +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 383818FC0A; Mon, 15 Nov 2010 17:05:52 +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 C94F346B51; Mon, 15 Nov 2010 12:05:51 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3EA498A027; Mon, 15 Nov 2010 12:05:46 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 15 Nov 2010 11:43:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011122125.47922.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011151143.04825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 15 Nov 2010 12:05:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: mdf@freebsd.org, Hans Petter Selasky Subject: Re: sleep bug in taskqueue(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: Mon, 15 Nov 2010 17:05:52 -0000 On Friday, November 12, 2010 4:24:51 pm mdf@freebsd.org wrote: > On Fri, Nov 12, 2010 at 12:25 PM, Hans Petter Selasky wrote: > > On Friday 12 November 2010 17:38:38 mdf@freebsd.org wrote: > >> On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky > > wrote: > >> > On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: > >> >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky > >> > > >> > wrote: > >> >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > >> >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > >> >> >> correctly detect whether or not a task is currently running. The > >> >> >> check is against a field in the taskqueue struct, but for the > >> >> >> taskqueue_thread queue with more than one thread, multiple threads > >> >> >> can simultaneously be running a task, thus stomping over the > >> >> >> tq_running field. > >> >> >> > >> >> >> I have not seen any problem with the code as-is in actual use, so > >> >> >> this is purely an inspection bug. > >> >> >> > >> >> >> The following patch should fix the problem. Because it changes the > >> >> >> size of struct task I'm not sure if it would be suitable for MFC. > >> >> > > >> >> > 1) The u_char is going to leave a hole in that structure on ARM > >> >> > platforms for example. > >> >> > > >> >> > 2) The existing taskqueue implementation also has a missing check for > >> >> > the pending count wrapping to zero. I.E. it should stick at 0xFFFF > >> >> > and not wrap to 0. > >> >> > >> >> This commit mail is rather old, and this fix was incorrect, because > >> >> the task cannot be referenced after it has been run. Some task > >> >> handlers will free the task as part of the handler. > >> > > >> > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above > >> > mentioned issues in a newer patch? > >> > >> If you look at the file history for subr_taskqueue.c: > >> > >> http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c > >> > >> You will see quite a few commits by me. The most recent relating to > >> detecting if a task is running is being MFC'd today: > > > > Yes, and I see that this code needs an overflow check, which is one of the > > issues still not fixed: > > You keep bringing this up. It is not a new issue. It is not a bug in > any of the patches. It is extremely unlikely that a task will be > queued 65536 times before execution. It is more worthy of an assert > rather than a check, because if a task is enqueued that many times > without being run then there's likely a stuck task in the queue. > > The patch you posted will lie as well, so I would not consider it > sufficient if someone wanted to address the issue. I agree it should be an assert. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 21:16:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5EC10656A4; Mon, 15 Nov 2010 21:16:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F40BA8FC18; Mon, 15 Nov 2010 21:16:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAFLGFBV027339; Mon, 15 Nov 2010 16:16:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAFLGFFS027338; Mon, 15 Nov 2010 21:16:15 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Nov 2010 21:16:15 GMT Message-Id: <201011152116.oAFLGFFS027338@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 21:16:16 -0000 TB --- 2010-11-15 21:02:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-15 21:02:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-15 21:02:51 - cleaning the object tree TB --- 2010-11-15 21:02:54 - cvsupping the source tree TB --- 2010-11-15 21:02:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-15 21:03:32 - building world TB --- 2010-11-15 21:03:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-15 21:03:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-15 21:03:32 - TARGET=powerpc TB --- 2010-11-15 21:03:32 - TARGET_ARCH=powerpc64 TB --- 2010-11-15 21:03:32 - TZ=UTC TB --- 2010-11-15 21:03:32 - __MAKE_CONF=/dev/null TB --- 2010-11-15 21:03:32 - cd /src TB --- 2010-11-15 21:03:32 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 15 21:03:32 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries -------------------------------------------------------------- cd /src; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make -f Makefile.inc1 DESTDIR=/obj/powerpc.powerpc64/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /src; /usr/bin/make -f Makefile.inc1 _prereq_libs; /usr/bin/make -f Makefile.inc1 _startup_libs; /usr/bin/make -f Makefile.inc1 _prebuild_libs; /usr/bin/make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c Assembler messages: FATAL: can't create ssp-local.o: Invalid bfd target *** Error code 2 Stop in /src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-15 21:16:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-15 21:16:15 - ERROR: failed to build world TB --- 2010-11-15 21:16:15 - 584.23 user 114.09 system 803.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 22:19:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 76A821065675; Mon, 15 Nov 2010 22:19:24 +0000 (UTC) Date: Mon, 15 Nov 2010 22:19:24 +0000 From: Alexander Best To: Julian Elischer Message-ID: <20101115221924.GA38676@freebsd.org> References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0F03.10703@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDF0F03.10703@freebsd.org> Cc: Kostik Belousov , freebsd-current@freebsd.org, Robert Watson , Garrett Cooper Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 22:19:24 -0000 On Sat Nov 13 10, Julian Elischer wrote: > On 11/13/10 2:13 PM, Robert Watson wrote: > > > >On Sat, 13 Nov 2010, Garrett Cooper wrote: > > > >> Isn't there also DEADLKRES that might be helpful in this case (if > >>Alex is really dealing with a livelock in the kernel)...? > > > >The deadlock resolver is compiled into the GENERIC kernel on > >-CURRENT, so I'm assuming it hasn't helped (or perhaps is even part > >of the problem). I think the best thing to do at this point is to > >try to get into DDB. Of the schemes I suggested to work around the > >X11 issue, switching to a virtual console before starting Chromium > >may work best, since it will continue to use the local X server, etc. > An alternate way of handling this: > Turn on the VNC X server and use that from a remote place, leaving the > console free. thanks for all your help. i've recently switched to chromium 6.0.472.63 and so far my computer has been very stable. if i experience more lock ups i'll let you know and try to figure out a way to gain access to some more debugging data. cheers. alex > > > >Robert > >_______________________________________________ > >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" > > -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 22:26:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A13E106566B for ; Mon, 15 Nov 2010 22:26:55 +0000 (UTC) (envelope-from villa.alberto@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 1D2E78FC1D for ; Mon, 15 Nov 2010 22:26:54 +0000 (UTC) Received: by qyk32 with SMTP id 32so299956qyk.13 for ; Mon, 15 Nov 2010 14:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=y5sL9G3gSMYKk4AOErai+KFxA7R+Sg4QI+VwhNKaDVg=; b=lm6nRHBwr90/81N6nuGpopjeeq7QpCkmon1Lwi2QZrqXPoUEbH38xJFxJntVXKN34b Q9P6Hn/MnVYmjo6Ui0mF2fTsLjLXJ3E5XzQdnze5N/ewneAPt7w2Dk4sjTm/PLinFcPd f91A97apgpKqVDb012aRLoSyQwFNRrMzAWqyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=WdwZ9JffDli8zPvWOf0r4epeOYTqtvqecnLZtRmzl81OQDyWipbs9xfP1jw+fa0L+1 uZUTkmQlb4SiCE06vQHeTGi8h24IOS+lXd6ChKyxfyptpXAK+vWNHTADWziWShO5aNZP 5FGjOD1oRy9f6FE1fyR8SW6PXeVPzp/MCIdSI= MIME-Version: 1.0 Received: by 10.229.240.213 with SMTP id lb21mr5625226qcb.185.1289860014323; Mon, 15 Nov 2010 14:26:54 -0800 (PST) Sender: villa.alberto@gmail.com Received: by 10.220.195.68 with HTTP; Mon, 15 Nov 2010 14:26:54 -0800 (PST) In-Reply-To: References: <20101025080705.GA33315@current.Sisis.de> Date: Mon, 15 Nov 2010 23:26:54 +0100 X-Google-Sender-Auth: q23rauRAy60oeVG_7UE4lX5qVD8 Message-ID: From: Alberto Villa To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Broadcom BCM4310 USB Controller (Wifi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 22:26:55 -0000 On Wed, Oct 27, 2010 at 3:36 PM, Paul B Mahol wrote: > Currently amd64 is broken with some/most drivers. Drivers appears to > use fpu registers. > I dunno how it ever worked, probably original developer(s) never > encountered drivers which use fpu registers. > > I will probably fix amd64 support in this year. so, i've tried the ndis driver with amd64 and it paniced, as you said. do you have any idea on when you're gonna fix this? i need to know if i can keep amd64 and wait for a fix (in short time) or if i have to install i386 temporarily... thanks -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 22:41:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00B71065673; Mon, 15 Nov 2010 22:41:18 +0000 (UTC) (envelope-from onemda@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 953B58FC13; Mon, 15 Nov 2010 22:41:18 +0000 (UTC) Received: by ywa8 with SMTP id 8so1559ywa.13 for ; Mon, 15 Nov 2010 14:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ODvQer0oaoIaUut+p7Sne46YcqMxRTvvaljj4FQkF04=; b=WaZSOp96rSVe34j85L41JRvbN1MNP7ouVGZduWNaMlKiKqUax+Ch1yVuvY7/LLyAFK nt61ypWdOGuF1eyOa744DKN/8NOk69oa9nCG2YnGdU0zl7THqyfld1j2FzG5QcI2Lo1p 6yv8B96hTaMMFjsE4WW1T5KC/Ap5CXzUFbxrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=joITb4hBT59n+Dktpy0/AUqSIWjoOdRS4z3ZY3B0zxxHrzqV+8ACwU1fRgSztYlKAd 4y6jICSCl2yVk4JCf3y/LlQVnXHo8jMdBCiwHslFWNrWcXQZx0hNYk27ODLeib8FLDe6 y08F5JgtxloNWMsiZ1HBhoB0RMNl4VhlA3rrc= MIME-Version: 1.0 Received: by 10.91.172.14 with SMTP id z14mr8549780ago.35.1289860877139; Mon, 15 Nov 2010 14:41:17 -0800 (PST) Received: by 10.91.191.17 with HTTP; Mon, 15 Nov 2010 14:41:16 -0800 (PST) In-Reply-To: References: <20101025080705.GA33315@current.Sisis.de> Date: Mon, 15 Nov 2010 22:41:16 +0000 Message-ID: From: Paul B Mahol To: Alberto Villa Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Broadcom BCM4310 USB Controller (Wifi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2010 22:41:19 -0000 On 11/15/10, Alberto Villa wrote: > On Wed, Oct 27, 2010 at 3:36 PM, Paul B Mahol wrote: >> Currently amd64 is broken with some/most drivers. Drivers appears to >> use fpu registers. >> I dunno how it ever worked, probably original developer(s) never >> encountered drivers which use fpu registers. >> >> I will probably fix amd64 support in this year. > > so, i've tried the ndis driver with amd64 and it paniced, as you said. > do you have any idea on when you're gonna fix this? i need to know if > i can keep amd64 and wait for a fix (in short time) or if i have to > install i386 temporarily... Feel free to test code at: gitorious.org/NDISulator github.com/richardpl/NDISulator The code is developed on CURRENT. But with small changes it can be compiled on STABLE too. Just now I have only one tester (and that is without counting me). From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 01:00:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C39E106566C for ; Tue, 16 Nov 2010 01:00:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8443E8FC14 for ; Tue, 16 Nov 2010 01:00:04 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PI9ty-0000wy-Ne for freebsd-current@freebsd.org; Tue, 16 Nov 2010 02:00:02 +0100 Received: from static-78-8-147-77.ssp.dialog.net.pl ([78.8.147.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2010 02:00:02 +0100 Received: from mwisnicki+freebsd by static-78-8-147-77.ssp.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2010 02:00:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Wisnicki Date: Tue, 16 Nov 2010 00:59:49 +0000 (UTC) Lines: 40 Message-ID: References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: static-78-8-147-77.ssp.dialog.net.pl User-Agent: Pan/0.133 (House of Butterflies) Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 01:00:05 -0000 On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > On 11/13/10 2:08 PM, Robert Watson wrote: >> >> If regular crashdumps appear unreliable, try setting up a textdump with >> an automatic reboot, that might provde more reliable (small chance, but >> it could). > > we did have some people working on an ethernet version of the > dcons/remote debugging stuff > I guess it only supports a small subset of ethernet chips though.. > Anyone know the status of that work? > I don't know about ethernet dump but how about simply dumping memory after reset ? See: - http://en.wikipedia.org/wiki/Cold_boot_attack - http://citp.princeton.edu/memory/ - http://www.mcgrewsecurity.com/tools/msramdmp/ Last link contains a tool to dump memory to usb disk after reset. If kgdb works with raw memory dumps, it may already work. This has the potential to solve all tricky debugging cases without needing firewire. A boot time kernel option to avoid certain memory areas which are overwritten during boot by bios and ram dumping tool could be useful or maybe necessary. It can even be completely automated, eg. if kernel would maintain some kind of "RAM dirty" flag, then during boot something (loader or kernel) would check for it and perform dump if needed. Another idea worth implementing or at least adding to project ideas list is to implement everything that is currently possible with serial (boot0, loader, kernel console, ddb) over EHCI debug port: - http://www.coreboot.org/EHCI_Debug_Port From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 01:37:10 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 406541065679; Tue, 16 Nov 2010 01:37:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 15 Nov 2010 20:36:42 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_wAe4McdFcflp2mK" Message-Id: <201011152036.48181.jkim@FreeBSD.org> Cc: Ed Schouten , Hans Petter Selasky Subject: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 01:37:10 -0000 --Boundary-00=_wAe4McdFcflp2mK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Often times I hear complaints like "my Mac hangs after upgrading to 8.1" or "snapshot CD hangs on my brand new Mac". I know some of these complaints started happening when we switched to new PAT layout. It is so puzzling because it never happened on non-Apple hardware, AFAIK. I really like to fix this problem but I cannot afford a Mac. :-P If you are one of those lucky people, please test the attached patch and report your hardware model and any improvement or regression. Also, I added a new tunable "vm.pmap.pat_works" so that you can turn it off from loader (i.e., "set vm.pmap.pat_works=0") and restore old behaviour without recompiling a new kernel. Thanks in advance! Jung-uk Kim --Boundary-00=_wAe4McdFcflp2mK Content-Type: text/plain; charset="iso-8859-1"; name="pmap.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pmap.diff" Index: sys/amd64/amd64/pmap.c =================================================================== --- sys/amd64/amd64/pmap.c (revision 215352) +++ sys/amd64/amd64/pmap.c (working copy) @@ -180,10 +180,13 @@ static vm_paddr_t dmaplimit; vm_offset_t kernel_vm_end = VM_MIN_KERNEL_ADDRESS; pt_entry_t pg_nx; -static int pat_works = 0; /* Is page attribute table sane? */ - SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters"); +static int pat_works = 1; +TUNABLE_INT("vm.pmap.pat_works", &pat_works); +SYSCTL_INT(_vm_pmap, OID_AUTO, pat_works, CTLFLAG_RDTUN, &pat_works, 1, + "Is page attribute table fully functional?"); + static int pg_ps_enabled = 1; SYSCTL_INT(_vm_pmap, OID_AUTO, pg_ps_enabled, CTLFLAG_RDTUN, &pg_ps_enabled, 0, "Are large page mappings enabled?"); @@ -609,35 +612,15 @@ void pmap_init_pat(void) { uint64_t pat_msr; - char *sysenv; - static int pat_tested = 0; /* Bail if this CPU doesn't implement PAT. */ if (!(cpu_feature & CPUID_PAT)) panic("no PAT??"); - /* - * Some Apple Macs based on nVidia chipsets cannot enter ACPI mode - * via SMI# when we use upper 4 PAT entries for unknown reason. - */ - if (!pat_tested) { - pat_works = 1; - sysenv = getenv("smbios.system.product"); - if (sysenv != NULL) { - if (strncmp(sysenv, "MacBook5,1", 10) == 0 || - strncmp(sysenv, "MacBookPro5,5", 13) == 0 || - strncmp(sysenv, "Macmini3,1", 10) == 0 || - strncmp(sysenv, "iMac9,1", 7) == 0) - pat_works = 0; - freeenv(sysenv); - } - pat_tested = 1; - } - /* Initialize default PAT entries. */ pat_msr = PAT_VALUE(0, PAT_WRITE_BACK) | PAT_VALUE(1, PAT_WRITE_THROUGH) | - PAT_VALUE(2, PAT_UNCACHED) | + PAT_VALUE(2, PAT_WRITE_COMBINING) | PAT_VALUE(3, PAT_UNCACHEABLE) | PAT_VALUE(4, PAT_WRITE_BACK) | PAT_VALUE(5, PAT_WRITE_THROUGH) | @@ -646,19 +629,10 @@ pmap_init_pat(void) if (pat_works) { /* - * Leave the indices 0-3 at the default of WB, WT, UC-, and UC. - * Program 4 and 5 as WP and WC. - * Leave 6 and 7 as UC- and UC. + * Just replace PAT Index 5 with WP instead of WT. */ - pat_msr &= ~(PAT_MASK(4) | PAT_MASK(5)); - pat_msr |= PAT_VALUE(4, PAT_WRITE_PROTECTED) | - PAT_VALUE(5, PAT_WRITE_COMBINING); - } else { - /* - * Just replace PAT Index 2 with WC instead of UC-. - */ - pat_msr &= ~PAT_MASK(2); - pat_msr |= PAT_VALUE(2, PAT_WRITE_COMBINING); + pat_msr &= ~PAT_MASK(5); + pat_msr |= PAT_VALUE(5, PAT_WRITE_PROTECTED); } wrmsr(MSR_PAT, pat_msr); } @@ -829,13 +803,13 @@ pmap_cache_bits(int mode, boolean_t is_pde) pat_index = 0; break; case PAT_UNCACHED: - pat_index = 2; + pat_index = 6; break; case PAT_WRITE_COMBINING: - pat_index = 5; + pat_index = 2; break; case PAT_WRITE_PROTECTED: - pat_index = 4; + pat_index = 5; break; default: panic("Unknown caching mode %d\n", mode); Index: sys/i386/i386/pmap.c =================================================================== --- sys/i386/i386/pmap.c (revision 215352) +++ sys/i386/i386/pmap.c (working copy) @@ -217,10 +217,13 @@ pt_entry_t pg_nx; static uma_zone_t pdptzone; #endif -static int pat_works = 0; /* Is page attribute table sane? */ - SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters"); +static int pat_works = 1; +TUNABLE_INT("vm.pmap.pat_works", &pat_works); +SYSCTL_INT(_vm_pmap, OID_AUTO, pat_works, CTLFLAG_RDTUN, &pat_works, 1, + "Is page attribute table fully functional?"); + static int pg_ps_enabled = 1; SYSCTL_INT(_vm_pmap, OID_AUTO, pg_ps_enabled, CTLFLAG_RDTUN, &pg_ps_enabled, 0, "Are large page mappings enabled?"); @@ -491,12 +494,12 @@ void pmap_init_pat(void) { uint64_t pat_msr; - char *sysenv; - static int pat_tested = 0; /* Bail if this CPU doesn't implement PAT. */ - if (!(cpu_feature & CPUID_PAT)) + if (!(cpu_feature & CPUID_PAT)) { + pat_works = 0; return; + } /* * Due to some Intel errata, we can only safely use the lower 4 @@ -508,32 +511,15 @@ pmap_init_pat(void) * * Intel Pentium IV Processor Specification Update * Errata N46 (PAT Index MSB May Be Calculated Incorrectly) - * - * Some Apple Macs based on nVidia chipsets cannot enter ACPI mode - * via SMI# when we use upper 4 PAT entries for unknown reason. */ - if (!pat_tested) { - if (cpu_vendor_id != CPU_VENDOR_INTEL || - (CPUID_TO_FAMILY(cpu_id) == 6 && - CPUID_TO_MODEL(cpu_id) >= 0xe)) { - pat_works = 1; - sysenv = getenv("smbios.system.product"); - if (sysenv != NULL) { - if (strncmp(sysenv, "MacBook5,1", 10) == 0 || - strncmp(sysenv, "MacBookPro5,5", 13) == 0 || - strncmp(sysenv, "Macmini3,1", 10) == 0 || - strncmp(sysenv, "iMac9,1", 7) == 0) - pat_works = 0; - freeenv(sysenv); - } - } - pat_tested = 1; - } + if (cpu_vendor_id == CPU_VENDOR_INTEL && + !(CPUID_TO_FAMILY(cpu_id) == 6 && CPUID_TO_MODEL(cpu_id) >= 0xe)) + pat_works = 0; /* Initialize default PAT entries. */ pat_msr = PAT_VALUE(0, PAT_WRITE_BACK) | PAT_VALUE(1, PAT_WRITE_THROUGH) | - PAT_VALUE(2, PAT_UNCACHED) | + PAT_VALUE(2, PAT_WRITE_COMBINING) | PAT_VALUE(3, PAT_UNCACHEABLE) | PAT_VALUE(4, PAT_WRITE_BACK) | PAT_VALUE(5, PAT_WRITE_THROUGH) | @@ -542,19 +528,10 @@ pmap_init_pat(void) if (pat_works) { /* - * Leave the indices 0-3 at the default of WB, WT, UC-, and UC. - * Program 4 and 5 as WP and WC. - * Leave 6 and 7 as UC- and UC. + * Just replace PAT Index 5 with WP instead of WT. */ - pat_msr &= ~(PAT_MASK(4) | PAT_MASK(5)); - pat_msr |= PAT_VALUE(4, PAT_WRITE_PROTECTED) | - PAT_VALUE(5, PAT_WRITE_COMBINING); - } else { - /* - * Just replace PAT Index 2 with WC instead of UC-. - */ - pat_msr &= ~PAT_MASK(2); - pat_msr |= PAT_VALUE(2, PAT_WRITE_COMBINING); + pat_msr &= ~PAT_MASK(5); + pat_msr |= PAT_VALUE(5, PAT_WRITE_PROTECTED); } wrmsr(MSR_PAT, pat_msr); } @@ -825,13 +802,13 @@ pmap_cache_bits(int mode, boolean_t is_pde) pat_index = 0; break; case PAT_UNCACHED: - pat_index = 2; + pat_index = 6; break; case PAT_WRITE_COMBINING: - pat_index = 5; + pat_index = 2; break; case PAT_WRITE_PROTECTED: - pat_index = 4; + pat_index = 5; break; default: panic("Unknown caching mode %d\n", mode); --Boundary-00=_wAe4McdFcflp2mK-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 07:50:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2B610656B2; Tue, 16 Nov 2010 07:50:08 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DCF788FC29; Tue, 16 Nov 2010 07:50:07 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-149.range86-161.btcentralplus.com [86.161.142.149]) by cyrus.watson.org (Postfix) with ESMTPSA id AEA5546B58; Tue, 16 Nov 2010 02:50:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20101115221924.GA38676@freebsd.org> Date: Tue, 16 Nov 2010 07:50:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0F03.10703@freebsd.org> <20101115221924.GA38676@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1082) Cc: Kostik Belousov , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 07:50:08 -0000 On 15 Nov 2010, at 22:19, Alexander Best wrote: > thanks for all your help. i've recently switched to chromium = 6.0.472.63 > and so far my computer has been very stable. >=20 > if i experience more lock ups i'll let you know and try to figure out = a way to > gain access to some more debugging data. I'd prefer we try to figure out why your system was crashing now -- the = kernel bug has not gone away just because Chromium is no longer = triggering it. Working around the bug means someone else gets to run = into it later -- perhaps when it's 9.0-RELEASE rather than 9-CURRENT... Robert= From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 09:42:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBB110656CA for ; Tue, 16 Nov 2010 09:42:19 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2A18FC12 for ; Tue, 16 Nov 2010 09:42:19 +0000 (UTC) Received: by yxh35 with SMTP id 35so199534yxh.13 for ; Tue, 16 Nov 2010 01:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=SeSobH9V6BNc9zNOC+Kd7DeL7x0CAsY0dDIDtYDsSZs=; b=veNQcHyhJH22SqecQlnmfnGLf+WGGZDMC+ItK7sXDuxqgvYzhWzqYKNioA//9OYl+q IWx0Cjs+zV6vvuSqixgaBllbGIypDknouL6ybpAmY1w0ZYcfg3AO09MF2tHNPUgXqsWp 8MUEKESP3oCYjzRf2FWRZ2hithMwDuMs2Um7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=GlPXpyXoCs+MCxgAmSzBMz89NHpoe6UZSXOw3+HW/Kh39EeEn3ttM5PGGaBG7CMpUZ xkIu/PrI3BrOOsall0WKK9cr83CwRcBH38FR65jA8QLt8d36RqPAT8M/H4k/9jJ59WIQ IWOfJlgEcDlIDaozxpmvx5OtakI5ZzEuzk+Wk= MIME-Version: 1.0 Received: by 10.42.76.66 with SMTP id d2mr5349165ick.219.1289900537472; Tue, 16 Nov 2010 01:42:17 -0800 (PST) Received: by 10.231.58.202 with HTTP; Tue, 16 Nov 2010 01:42:17 -0800 (PST) In-Reply-To: <20101112042456.GD46709@stlux503.dsto.defence.gov.au> References: <20101111155243.GL2054@hoeg.nl> <20101112042456.GD46709@stlux503.dsto.defence.gov.au> Date: Tue, 16 Nov 2010 10:42:17 +0100 Message-ID: From: Daniel Nebdal To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 09:42:19 -0000 On Fri, Nov 12, 2010 at 5:24 AM, Wilkinson, Alex wrote: > > =A0 =A00n Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > > =A0 =A0>I just committed libcompiler_rt.a to HEAD. Even though I don't ex= pect > =A0 =A0>serious issues -- especially not on the tier 1 architectures -- b= e sure > =A0 =A0>to contact me in case something goes wrong. I hooked it up to the= build > =A0 =A0>in a separate commit, so if your system starts to act weird, just= revert > =A0 =A0>r2151 > Can you please explain to us what this actually brings to the table for f= reebsd ? > I know it replaces libgcc ... but why is that such a good thing ? > > =A0-Alex The main thing is that it's BSD-licensed instead of GPL, I believe. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 12:20:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2982106566B for ; Tue, 16 Nov 2010 12:20:52 +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 B7A658FC12 for ; Tue, 16 Nov 2010 12:20:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA07645 for ; Tue, 16 Nov 2010 14:20:47 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE2771F.8020109@freebsd.org> Date: Tue, 16 Nov 2010 14:20:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: taskqueue_create() name parameter lieftime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 12:20:52 -0000 taskqueue_create() documentation never explicitly says this, but current taskqueue_create() implementation just stores a 'name' pointer parameter internally. Thus it depends on the 'name' having a life time encompassing that of the taskqueue. I think that alternatively we could have copied the name (or a portion of it) into an internal buffer. I don't any argument for either approach, just curious which one looks more preferable from general (FreeBSD, kernel) programming practices point of view. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:01:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F607106566B for ; Tue, 16 Nov 2010 13:01:47 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 30A258FC14 for ; Tue, 16 Nov 2010 13:01:46 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 645946F60051; Tue, 16 Nov 2010 16:01:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289912505; bh=ev8ClHZXhuBwFeAuzm9BDWumLFFAYZCx0jN99WMp9Bg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=KarWMsBJD9dq7Qus9oX/3+V2UGLF0DG4ZE9A6ykDKm64revoCONWEEsedQnvoqRTI Q4iTezh9urIhxnNUmtcs2ZTRd1zcrvdOdSFXEFR+TEdTe4V5xRZgerX7XjADHNEh/d BfS1BWCUC5uGj5M/kOOKJQ6fddFT6ZSyTlzTcU+U= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id E5B311280A6; Tue, 16 Nov 2010 16:01:44 +0300 (MSK) Message-ID: <4CE280B7.1070502@yandex.ru> Date: Tue, 16 Nov 2010 16:01:43 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Adrian Chadd References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060308000204010909070501" Cc: Bruce Cran , freebsd-hackers@freebsd.org, freebsd-current Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 13:01:47 -0000 This is a multi-part message in MIME format. --------------060308000204010909070501 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit On 08.11.2010 15:31, Adrian Chadd wrote: >> I've broken out the crunchgen logic from src/rescue/rescue into a >> share/mk file - that way it can be reused in other areas. >> >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> >> >> This bsd.crunchgen.mk file is generic enough to use in my >> busybox-style thing as well as for src/rescue/rescue/. >> >> Comments, feedback, etc welcome! It seems this broke usage of livefs from sysinstall. sysinstall does check for /rescue/ldconfig and can not find it there. I think attached patch can fix this issue (not tested). -- WBR, Andrey V. Elsukov --------------060308000204010909070501 Content-Type: text/plain; name="sysinstall_rescue.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysinstall_rescue.diff" Index: head/usr.sbin/sysinstall/install.c =================================================================== --- head/usr.sbin/sysinstall/install.c (revision 215396) +++ head/usr.sbin/sysinstall/install.c (working copy) @@ -342,7 +342,7 @@ installFixitUSB(dialogMenuItem *self) !DEVICE_INIT(mediaDevice)) { msgConfirm("No USB devices found!"); return (DITEM_FAILURE); - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { msgConfirm("Unable to find a FreeBSD live filesystem."); return (DITEM_FAILURE); } @@ -375,7 +375,7 @@ installFixitCDROM(dialogMenuItem *self) mediaClose(); if (need_eject && msgYesNo("Unable to mount the disc. Do you want to try again?") != 0) return DITEM_FAILURE; - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { mediaClose(); if (need_eject && msgYesNo("Unable to find a FreeBSD live filesystem. Do you want to try again?") != 0) @@ -565,7 +565,7 @@ fixit_livefs_common(dialogMenuItem *self) /* Generate a new ld.so.hints */ if (!file_readable("/var/run/ld.so.hints")) { Mkdir("/var/run"); - if (vsystem("/mnt2/rescue/ldconfig -s /mnt2/lib " + if (vsystem("/mnt2/rescue/rescue ldconfig -s /mnt2/lib " "/mnt2/usr/lib")) { msgConfirm("Warning: ldconfig could not create the " "ld.so hints file.\nDynamic executables from the " --------------060308000204010909070501-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:29:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17AE106566B; Tue, 16 Nov 2010 13:29:34 +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 C4FBA8FC1D; Tue, 16 Nov 2010 13:29:34 +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 7E97446B29; Tue, 16 Nov 2010 08:29:34 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 840E78A009; Tue, 16 Nov 2010 08:29:33 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Nov 2010 08:27:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4CE2771F.8020109@freebsd.org> In-Reply-To: <4CE2771F.8020109@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011160827.11628.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 08:29:33 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Andriy Gapon Subject: Re: taskqueue_create() name parameter lieftime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 13:29:35 -0000 On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > > taskqueue_create() documentation never explicitly says this, but current > taskqueue_create() implementation just stores a 'name' pointer parameter > internally. Thus it depends on the 'name' having a life time encompassing that of > the taskqueue. > I think that alternatively we could have copied the name (or a portion of it) into > an internal buffer. > I don't any argument for either approach, just curious which one looks more > preferable from general (FreeBSD, kernel) programming practices point of view. Hmm, in many other places we store a separate copy (e.g. all the interrupt code uses separate MAXCOMLEN char arrays to hold names). If that is easy to do, that is probably the best approach. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:29:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4194E106564A; Tue, 16 Nov 2010 13:29:37 +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 116888FC08; Tue, 16 Nov 2010 13:29:37 +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 BE32046B39; Tue, 16 Nov 2010 08:29:36 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5751D8A01D; Tue, 16 Nov 2010 08:29:35 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Nov 2010 08:29:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4CE280B7.1070502@yandex.ru> In-Reply-To: <4CE280B7.1070502@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011160829.13511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 08:29:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 13:29:37 -0000 On Tuesday, November 16, 2010 8:01:43 am Andrey V. Elsukov wrote: > On 08.11.2010 15:31, Adrian Chadd wrote: > >> I've broken out the crunchgen logic from src/rescue/rescue into a > >> share/mk file - that way it can be reused in other areas. > >> > >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< > >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> > >> > >> This bsd.crunchgen.mk file is generic enough to use in my > >> busybox-style thing as well as for src/rescue/rescue/. > >> > >> Comments, feedback, etc welcome! > > It seems this broke usage of livefs from sysinstall. > sysinstall does check for /rescue/ldconfig and can not find it there. > I think attached patch can fix this issue (not tested). Err, are there no longer hard links to all of the frontends for a given crunch? If so, that is a problem as it will make rescue much harder to use. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:42:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1A3106566C; Tue, 16 Nov 2010 13:42:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 23C368FC18; Tue, 16 Nov 2010 13:42:26 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 692C945CAC; Tue, 16 Nov 2010 14:42:24 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5ABD545C9C; Tue, 16 Nov 2010 14:42:19 +0100 (CET) Date: Tue, 16 Nov 2010 14:41:37 +0100 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20101116134137.GD1753@garage.freebsd.pl> References: <4CE2771F.8020109@freebsd.org> <201011160827.11628.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oPmsXEqKQNHCSXW7" Content-Disposition: inline In-Reply-To: <201011160827.11628.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: taskqueue_create() name parameter lieftime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 13:42:27 -0000 --oPmsXEqKQNHCSXW7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 08:27:11AM -0500, John Baldwin wrote: > On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > >=20 > > taskqueue_create() documentation never explicitly says this, but current > > taskqueue_create() implementation just stores a 'name' pointer parameter > > internally. Thus it depends on the 'name' having a life time encompass= ing that of > > the taskqueue. > > I think that alternatively we could have copied the name (or a portion = of it) into > > an internal buffer. > > I don't any argument for either approach, just curious which one looks = more > > preferable from general (FreeBSD, kernel) programming practices point o= f view. >=20 > Hmm, in many other places we store a separate copy (e.g. all the interrupt > code uses separate MAXCOMLEN char arrays to hold names). If that is easy= to > do, that is probably the best approach. The most friendly API would keep the name internally, but would also allow me to provide name in printf-like format, so I don't have to use sprint()/snprintf() before calling it. This unfortunatelly will change taskqueue API as name is the first argument, which makes it not worth the pain. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oPmsXEqKQNHCSXW7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkziihEACgkQForvXbEpPzTE3ACgxYxc+eVUNuGtflV+plOW3Sdb 4C0AmwYQOvFv+CRYkfNcleDxjQZLpzAF =lJer -----END PGP SIGNATURE----- --oPmsXEqKQNHCSXW7-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:43:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87B1410656AB; Tue, 16 Nov 2010 13:43:40 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0BF8FC26; Tue, 16 Nov 2010 13:43:39 +0000 (UTC) Received: by qyk7 with SMTP id 7so732678qyk.13 for ; Tue, 16 Nov 2010 05:43:39 -0800 (PST) Received: by 10.229.215.8 with SMTP id hc8mr6271829qcb.23.1289913717646; Tue, 16 Nov 2010 05:21:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.230.202 with HTTP; Tue, 16 Nov 2010 05:21:37 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Tue, 16 Nov 2010 14:21:37 +0100 Message-ID: To: advocacy@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 Cc: Subject: BSD at FOSDEM 2011 - Call for speakers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 13:43:40 -0000 Hello all, FOSDEM 2011 will take place February 5-6, 2011 in Brussels, Belgium. We want to continue the great success of the last years and again we have a booth and a devroom. Please submit your proposal to me asap. We have a devroom on saturday this time. Talks will be 45 minutes including discussion (feel free to ask if you want to have a longer/shorter slot). Every talk is welcome, from internal hacker discussion to real-world examples and presentations about new and shiny features. The talk committee consists of Daniel Seuffert and me. Please submit your proposals to: marius@nuenneri.ch and include the following information: * Your name * The title of your talk (please be descriptive, as titles will be listed with ~250 from other projects) * A short abstract of one to two paragraphs * A short biography introducing yourself * Links to related websites/blogs etc. The deadline for submissions is 20th December 2010. The proposals will be considered by committee. If your proposal has been accepted, you will be informed by email within one week of the submission deadline. Best regards, Marius From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 13:45:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F0E1106564A; Tue, 16 Nov 2010 13:45:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 3306F8FC1C; Tue, 16 Nov 2010 13:45:15 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 7070D2210815; Tue, 16 Nov 2010 16:45:13 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289915113; bh=hTm+LU+UaOMNGcaeRYMsGlaNwRAV7OXIq0bCOysf++A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=IZvI2xuZZ/rrKUso9jAtbDk3uurz3M3elKRMQmpBLzAsoNYkIgl+B7UR9E4elD7IU RGhwEzgw/czkackM/LDFX+OmMJOKeB5EkeEp7sRqgqiocrDsihDx9m/Z4/eRPALSq4 xRfCzN8YgmO3QVTpiffd4hBjYVe3xKIp3kq01Kcs= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id E9E2F415805A; Tue, 16 Nov 2010 16:45:12 +0300 (MSK) Message-ID: <4CE28AE4.70101@yandex.ru> Date: Tue, 16 Nov 2010 16:45:08 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4CE280B7.1070502@yandex.ru> <201011160829.13511.jhb@freebsd.org> In-Reply-To: <201011160829.13511.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA27E854D4E700BE54394D527" Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 13:45:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA27E854D4E700BE54394D527 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.11.2010 16:29, John Baldwin wrote: > Err, are there no longer hard links to all of the frontends for a given= =20 > crunch? If so, that is a problem as it will make rescue much harder to= use. Yes, probably this patch is not needed and it should be fixed somewhere i= n makefiles. But currently rescue does not have any hardlinks: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNA= P/cdrom/livefs/rescue/ And what is was before: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNA= P/cdrom/livefs/rescue/ --=20 WBR, Andrey V. Elsukov --------------enigA27E854D4E700BE54394D527 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM4oroAAoJEAHF6gQQyKF6L5IIAMBnnOFJhRRR2QbbAA2c4acK zxwCLhFJ7MTFcoYdwX9HHAJnaEILssMzI8sF6p/Yqa1bvm6Jrl6hPBQAllJU/Qlx Fj3xGrf+tjJMEmlaPQxalCkF6IWmiVmBB4+/aYLb0J66vAHywZJPsIqdx3BfQHrq 2Gxy7YjxUhnW86b9rOb9UOJPalqK8eEojb7HYzWaeW0haJhjzXGcjTdSD0oh6Rvk VAqr82kMvhjUV0MzYDtxY7fYQaJB04wa+jZWSVQmVMH2MPOFbzK35py38o8aQ27y bL83MVVboVAHDGGjGnD1QmlbVas1T4Hzw+lqJUgduOSjtACP4cQveZZXcms1CqI= =lt5u -----END PGP SIGNATURE----- --------------enigA27E854D4E700BE54394D527-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 14:20:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32849106564A; Tue, 16 Nov 2010 14:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02F118FC0C; Tue, 16 Nov 2010 14:20:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 97A5F46B35; Tue, 16 Nov 2010 09:20:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A74C78A009; Tue, 16 Nov 2010 09:20:55 -0500 (EST) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 16 Nov 2010 09:12:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> In-Reply-To: <4CE28AE4.70101@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011160912.27693.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 09:20:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 14:20:57 -0000 On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: > On 16.11.2010 16:29, John Baldwin wrote: > > Err, are there no longer hard links to all of the frontends for a given > > crunch? If so, that is a problem as it will make rescue much harder to use. > > Yes, probably this patch is not needed and it should be fixed somewhere in > makefiles. But currently rescue does not have any hardlinks: > http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ > > And what is was before: > http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ That definitely needs to be fixed. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 14:37:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C017106566C; Tue, 16 Nov 2010 14:37:16 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 103CA8FC0C; Tue, 16 Nov 2010 14:37:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10183; Tue, 16 Nov 2010 16:37:13 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE29718.2050508@freebsd.org> Date: Tue, 16 Nov 2010 16:37:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 14:37:16 -0000 Many modern processors provide APERF and MPERF MSRs which allow to easily and reliable calculate average CPU performance level over some interval of time. This also allows to notice things like performance boost, which is generally hidden from software. What would be a proper place to add code that would measure APERF/MPERF ratio? When should trigger such a measurement and over what interval? Ideas? Thanks a lot! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 14:35:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D6A1065675 for ; Tue, 16 Nov 2010 14:35:41 +0000 (UTC) (envelope-from crockabiscuit@yahoo.com) Received: from nm21-vm0.bullet.mail.ne1.yahoo.com (nm21-vm0.bullet.mail.ne1.yahoo.com [98.138.90.94]) by mx1.freebsd.org (Postfix) with SMTP id 860B08FC0A for ; Tue, 16 Nov 2010 14:35:41 +0000 (UTC) Received: from [98.138.90.48] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2010 14:35:40 -0000 Received: from [98.138.89.244] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2010 14:35:40 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 16 Nov 2010 14:35:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873061.1482.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 37176 invoked by uid 60001); 16 Nov 2010 14:35:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289918140; bh=QNfkjvMI232lOK3YWdYnVWjHdoSGq52Jkm0vPSZx0N0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=fZVjsOtCVzZ3wvpLfYKf2L9D4WwqlMWk7VtDsK/PNBRT2wEWkvB+TCCXMyz8Oav7rlsCKexnXU0qaZGGftSF7z8Fx8bvgu5xtaTV8sjREwEdUtoHg85FcAwGIRqqjJ5WMcskwERm5Cr200yDKSg1Qjlib0/oReT43VCtoER6trc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=KkZD0AWgs8psy9lU/5/DOWWrv9NmfObWoupvG/+FImz7t9z9iNKgNE1yc3NujYj0womltddWejgJmOSgk0F3QtCIts+eqI+5DkhKxBRFHz0zIGN4ncRMgbz6n7O4ZZpRqfzUaHYdeZprCUGfYOp/OEbRu4e7AlwyTEEqqmXWePs=; Message-ID: <555002.36918.qm@web120302.mail.ne1.yahoo.com> X-YMail-OSG: 8ZIF9.AVM1nByDDlg5v5pQuDiK449GDh7dcZ91k3T.0MTrB LoYdjtZ2echxLg5LiFXI5qqnZN.0afIJU0OPaB70pmTXFUHqtMHEiLkmsz0m RanZu_52IxdY3WWWi33P1rz.KSUcNvHEFdXr8GbCyXUIfksslZQgXJCAJiWw QFz4V8Azn76qSr7Yhr53_ib7P24OFaFm.ioQ7 Received: from [180.68.85.212] by web120302.mail.ne1.yahoo.com via HTTP; Tue, 16 Nov 2010 06:35:40 PST X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.285259 Date: Tue, 16 Nov 2010 06:35:40 -0800 (PST) From: crocket To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 16 Nov 2010 16:44:52 +0000 Subject: Does FreeBSD with TEKEN_UTF8 support displaying CKJ characters? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 14:35:42 -0000 I wonder whether CKJ characters would be displayed out of box if TEKEN_UTF8 was set in the kernel. From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 17:52:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C734106564A; Tue, 16 Nov 2010 17:52:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 874788FC18; Tue, 16 Nov 2010 17:52:57 +0000 (UTC) Received: by gwj20 with SMTP id 20so536408gwj.13 for ; Tue, 16 Nov 2010 09:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=gGzOmkDQAnN2sQIWAGWjI7Pee+mUT8fPdzenvyQLD4U=; b=P+25Ke1qyZKpQ5zPbQySLXSk88WG7fDa23eXA9Lav8txCd8wg52dV2yNTutG3vGr40 FDaQguS/KdPpNfqAJhB0Sug/CXhwphJljz0L57ZrBlxaGyeGfCL/skc2nuMFPjMhxRJE jtP5+JYRM1zFaFR0D6/7hEhC9CRHiYAz9DOf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=phjCIAccAAFcJ8dw4tATy8QeA2vg3D6aSLSI9HLmmAxC2FjHkHFFYCpuQgzsjFJZXb qANuCIVipE58GdRtfyxmdeulBIAoy5GNN8b/SW5hQunVybudPMDe50RAB41h+WHrdp3A YE1EM1mZHmzHI5ni14LU/BwQff214IfvA2Tds= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr7512660wee.45.1289929976116; Tue, 16 Nov 2010 09:52:56 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 09:52:56 -0800 (PST) In-Reply-To: <201011160912.27693.jhb@freebsd.org> References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Tue, 16 Nov 2010 09:52:56 -0800 X-Google-Sender-Auth: NRgn383jEBK6pv3JGpWOucqoQ_Q Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=001636eefd2a02f74904952f3a30 Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 17:52:58 -0000 --001636eefd2a02f74904952f3a30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: > On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >> On 16.11.2010 16:29, John Baldwin wrote: >> > Err, are there no longer hard links to all of the frontends for a give= n >> > crunch? =A0If so, that is a problem as it will make rescue much harder= to use. >> >> Yes, probably this patch is not needed and it should be fixed somewhere = in >> makefiles. But currently rescue does not have any hardlinks: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSN= AP/cdrom/livefs/rescue/ >> >> And what is was before: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSN= AP/cdrom/livefs/rescue/ > > That definitely needs to be fixed. The .mk file wasn't being installed. Could someone please test this patch for validity and commit it? More importantly, why didn't the above build process, or tinderbox fail properly with this change? Thanks, -Garrett --001636eefd2a02f74904952f3a30 Content-Type: text/x-patch; charset=US-ASCII; name="fix-crunchgen.patch" Content-Disposition: attachment; filename="fix-crunchgen.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggl2yoqx0 SW5kZXg6IHNoYXJlL21rL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21rL01ha2VmaWxl CShyZXZpc2lvbiAyMTUzMzMpCisrKyBzaGFyZS9tay9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpA QCAtMyw3ICszLDggQEAKIAogRklMRVM9CWJzZC5SRUFETUUKIEZJTEVTKz0JYnNkLmFyY2guaW5j Lm1rCi1GSUxFUys9CWJzZC5jb21wYXQubWsgYnNkLmNwdS5tayBic2QuZGVwLm1rIGJzZC5kb2Mu bWsgYnNkLmR0cmFjZS5taworRklMRVMrPQlic2QuY29tcGF0Lm1rIGJzZC5jcnVuY2hnZW4ubWsg YnNkLmNwdS5taworRklMRVMrPQlic2QuZGVwLm1rIGJzZC5kb2MubWsgYnNkLmR0cmFjZS5tawog RklMRVMrPQlic2QuZW5kaWFuLm1rCiBGSUxFUys9CWJzZC5maWxlcy5tayBic2QuaW5jcy5tayBi c2QuaW5mby5tayBic2QuaW5pdC5tawogRklMRVMrPQlic2Qua21vZC5tawo= --001636eefd2a02f74904952f3a30-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 18:05:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D49106566B; Tue, 16 Nov 2010 18:05:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42EF98FC24; Tue, 16 Nov 2010 18:05:01 +0000 (UTC) Received: by ewy3 with SMTP id 3so488360ewy.13 for ; Tue, 16 Nov 2010 10:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dYKXwu4MmTrYL/HeXhk6vnq9wIoCZ8f2jWNfH4VwGEQ=; b=hdM4h+SWGO+gu3aeT3cr56rSbq4qHfkbLBqCciZvvmj3AcW0wBp49+a3EQpVjbKHrz FJbA/D1HK2+wGgxI2fa7aLKlA+PqQfi4SK5P9Xkfmbx6viWokhE/pAo2t6kvm1d7Wt3k jPX0h42revKJ7P1JXpWWXXGkSCWrWeSE3e3qY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BID756Oswrvhp5wuyKMimT1U2Vis7NBAZtn1FG5OTevfCwRdwKep43uIZ8SZVUGxgr zSeuMjyqWUPba33HB9T8DJ/8RzN4mnOT2XLJurupTc7WWH6c/dzjXvfB5GMLIHFIbNtz ZpAS6FmkiI43u/FMcLAiQzZVfXT3bomz0g8hk= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr650331web.45.1289930698964; Tue, 16 Nov 2010 10:04:58 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 10:04:58 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Tue, 16 Nov 2010 10:04:58 -0800 X-Google-Sender-Auth: vzdiBGHsrwYxIV4RYGtDyb46xuU Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: multipart/mixed; boundary=0016364c7a13191b8204952f65dc Cc: Bruce Cran , freebsd-hackers@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:05:03 -0000 --0016364c7a13191b8204952f65dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wrote= : > On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>> On 16.11.2010 16:29, John Baldwin wrote: >>> > Err, are there no longer hard links to all of the frontends for a giv= en >>> > crunch? =A0If so, that is a problem as it will make rescue much harde= r to use. >>> >>> Yes, probably this patch is not needed and it should be fixed somewhere= in >>> makefiles. But currently rescue does not have any hardlinks: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPS= NAP/cdrom/livefs/rescue/ >>> >>> And what is was before: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPS= NAP/cdrom/livefs/rescue/ >> >> That definitely needs to be fixed. > > =A0 =A0The .mk file wasn't being installed. Could someone please test > this patch for validity and commit it? > =A0 =A0More importantly, why didn't the above build process, or tinderbox > fail properly with this change? Ouch. I can definitely still see the other problem: # make install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script The second attached patch (not a superset of the first) what unbreaks it: # make -C rescue/rescue/ install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script /rescue/cat -> /rescue/rescue /rescue/chflags -> /rescue/rescue /rescue/chio -> /rescue/rescue /rescue/chmod -> /rescue/rescue /rescue/cp -> /rescue/rescue /rescue/date -> /rescue/rescue /rescue/dd -> /rescue/rescue /rescue/df -> /rescue/rescue /rescue/echo -> /rescue/rescue /rescue/ed -> /rescue/rescue /rescue/red -> /rescue/rescue /rescue/expr -> /rescue/rescue /rescue/getfacl -> /rescue/rescue /rescue/hostname -> /rescue/rescue /rescue/kenv -> /rescue/rescue /rescue/kill -> /rescue/rescue /rescue/ln -> /rescue/rescue /rescue/link -> /rescue/rescue /rescue/ls -> /rescue/rescue /rescue/mkdir -> /rescue/rescue /rescue/mv -> /rescue/rescue /rescue/pkill -> /rescue/rescue /rescue/pgrep -> /rescue/rescue /rescue/ps -> /rescue/rescue /rescue/pwd -> /rescue/rescue /rescue/realpath -> /rescue/rescue /rescue/rm -> /rescue/rescue /rescue/unlink -> /rescue/rescue /rescue/rmdir -> /rescue/rescue /rescue/setfacl -> /rescue/rescue /rescue/sh -> /rescue/rescue /rescue/stty -> /rescue/rescue /rescue/sync -> /rescue/rescue /rescue/test -> /rescue/rescue /rescue/[ -> /rescue/rescue /rescue/csh -> /rescue/rescue /rescue/tcsh -> /rescue/rescue /rescue/atacontrol -> /rescue/rescue /rescue/badsect -> /rescue/rescue /rescue/camcontrol -> /rescue/rescue /rescue/ccdconfig -> /rescue/rescue /rescue/clri -> /rescue/rescue /rescue/devfs -> /rescue/rescue /rescue/dmesg -> /rescue/rescue /rescue/dump -> /rescue/rescue /rescue/rdump -> /rescue/rescue /rescue/dumpfs -> /rescue/rescue /rescue/dumpon -> /rescue/rescue /rescue/fsck -> /rescue/rescue /rescue/fsck_ffs -> /rescue/rescue /rescue/fsck_4.2bsd -> /rescue/rescue /rescue/fsck_ufs -> /rescue/rescue /rescue/fsck_msdosfs -> /rescue/rescue /rescue/fsdb -> /rescue/rescue /rescue/fsirand -> /rescue/rescue /rescue/gbde -> /rescue/rescue /rescue/geom -> /rescue/rescue /rescue/glabel -> /rescue/rescue /rescue/gpart -> /rescue/rescue /rescue/ifconfig -> /rescue/rescue /rescue/init -> /rescue/rescue /rescue/kldconfig -> /rescue/rescue /rescue/kldload -> /rescue/rescue /rescue/kldstat -> /rescue/rescue /rescue/kldunload -> /rescue/rescue /rescue/ldconfig -> /rescue/rescue /rescue/md5 -> /rescue/rescue /rescue/mdconfig -> /rescue/rescue /rescue/mdmfs -> /rescue/rescue /rescue/mknod -> /rescue/rescue /rescue/mount -> /rescue/rescue /rescue/mount_cd9660 -> /rescue/rescue /rescue/mount_msdosfs -> /rescue/rescue /rescue/mount_nfs -> /rescue/rescue /rescue/mount_ntfs -> /rescue/rescue /rescue/mount_nullfs -> /rescue/rescue /rescue/mount_udf -> /rescue/rescue /rescue/mount_unionfs -> /rescue/rescue /rescue/newfs -> /rescue/rescue /rescue/newfs_msdos -> /rescue/rescue /rescue/nos-tun -> /rescue/rescue /rescue/ping -> /rescue/rescue /rescue/reboot -> /rescue/rescue /rescue/fastboot -> /rescue/rescue /rescue/halt -> /rescue/rescue /rescue/fasthalt -> /rescue/rescue /rescue/restore -> /rescue/rescue /rescue/rrestore -> /rescue/rescue /rescue/rcorder -> /rescue/rescue /rescue/route -> /rescue/rescue /rescue/routed -> /rescue/rescue /rescue/rtquery -> /rescue/rescue /rescue/rtsol -> /rescue/rescue /rescue/savecore -> /rescue/rescue /rescue/spppcontrol -> /rescue/rescue /rescue/swapon -> /rescue/rescue /rescue/sysctl -> /rescue/rescue /rescue/tunefs -> /rescue/rescue /rescue/umount -> /rescue/rescue /rescue/bsdlabel -> /rescue/rescue /rescue/disklabel -> /rescue/rescue /rescue/fdisk -> /rescue/rescue /rescue/dhclient -> /rescue/rescue /rescue/head -> /rescue/rescue /rescue/mt -> /rescue/rescue /rescue/sed -> /rescue/rescue /rescue/tail -> /rescue/rescue /rescue/tee -> /rescue/rescue /rescue/gzip -> /rescue/rescue /rescue/gunzip -> /rescue/rescue /rescue/gzcat -> /rescue/rescue /rescue/zcat -> /rescue/rescue /rescue/bzip2 -> /rescue/rescue /rescue/bunzip2 -> /rescue/rescue /rescue/bzcat -> /rescue/rescue /rescue/xz -> /rescue/rescue /rescue/unxz -> /rescue/rescue /rescue/lzma -> /rescue/rescue /rescue/unlzma -> /rescue/rescue /rescue/xzcat -> /rescue/rescue /rescue/lzcat -> /rescue/rescue /rescue/tar -> /rescue/rescue /rescue/vi -> /rescue/rescue /rescue/ex -> /rescue/rescue /rescue/id -> /rescue/rescue /rescue/groups -> /rescue/rescue /rescue/whoami -> /rescue/rescue /rescue/chroot -> /rescue/rescue /rescue/chown -> /rescue/rescue /rescue/chgrp -> /rescue/rescue So it looks like something tunable needs to be added to the .mk file to deal with hardlinks as this basically reenables functionality that Adrian disabled. Thanks, -Garrett --0016364c7a13191b8204952f65dc Content-Type: text/x-patch; charset=US-ASCII; name="fix-crunchgen-hardlinking.patch" Content-Disposition: attachment; filename="fix-crunchgen-hardlinking.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggl3c4zt1 SW5kZXg6IHNoYXJlL21rL2JzZC5jcnVuY2hnZW4ubWsKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWsv YnNkLmNydW5jaGdlbi5tawkocmV2aXNpb24gMjE1MzMzKQorKysgc2hhcmUvbWsvYnNkLmNydW5j aGdlbi5tawkod29ya2luZyBjb3B5KQpAQCAtNTEsMTkgKzUxLDE2IEBACiAuZWxzZQogJChPVVRQ VVRTKTogJCguQ1VSRElSKS8uLi8uLi8kKEQpLyQoUCkvTWFrZWZpbGUKIC5lbmRpZgotIyBEaXNh YmxlIGJ1aWxkaW5nIGxpbmtzIGZvciBic2Rib3ggLSB3aGF0ZXZlciBpcyBpbnN0YWxsaW5nIHRo ZSBiaW5hcmllcyBpbnRvCi0jIHRoZSBlbWJlZGRlZCBzeXN0ZW0gc2hvdWxkIChmb3Igbm93KSBk byB0aGUgbGlua2luZyB0aGVyZS4gVGhpcyBtYXkgY2hhbmdlCi0jIGluIHRoZSBmdXR1cmUuIC1h ZHJpYW4KLSMuaWZuZGVmIENSVU5DSF9TVVBQUkVTU19MSU5LXyR7UH0KLSNMSU5LUys9ICQoQklO RElSKS8kKFBST0cpICQoQklORElSKS8kKFApCi0jLmVuZGlmCi0jLmZvciBBIGluICQoQ1JVTkNI X0FMSUFTXyQoUCkpCi0jLmlmbmRlZiBDUlVOQ0hfU1VQUFJFU1NfTElOS18ke0F9Ci0jTElOS1Mr PSAkKEJJTkRJUikvJChQUk9HKSAkKEJJTkRJUikvJChBKQotIy5lbmRpZgotIy5lbmRmb3IKKy5p Zm5kZWYgQ1JVTkNIX1NVUFBSRVNTX0xJTktfJHtQfQorTElOS1MrPSAkKEJJTkRJUikvJChQUk9H KSAkKEJJTkRJUikvJChQKQorLmVuZGlmCisuZm9yIEEgaW4gJChDUlVOQ0hfQUxJQVNfJChQKSkK Ky5pZm5kZWYgQ1JVTkNIX1NVUFBSRVNTX0xJTktfJHtBfQorTElOS1MrPSAkKEJJTkRJUikvJChQ Uk9HKSAkKEJJTkRJUikvJChBKQorLmVuZGlmCiAuZW5kZm9yCiAuZW5kZm9yCisuZW5kZm9yCiAK IGFsbDogJChQUk9HKQogZXhlOiAkKFBST0cpCg== --0016364c7a13191b8204952f65dc-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 18:20:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7D8106566B for ; Tue, 16 Nov 2010 18:20:55 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [204.109.60.194]) by mx1.freebsd.org (Postfix) with ESMTP id EF6058FC21 for ; Tue, 16 Nov 2010 18:20:54 +0000 (UTC) Received: from neu.net (neu.net [204.109.60.194]) by sop3 (8.14.4/8.14.4) with ESMTP id oAGDCcPj017214 for ; Tue, 16 Nov 2010 13:12:38 GMT (envelope-from andy@neu.net) Date: Tue, 16 Nov 2010 13:12:37 +0000 (UTC) From: AN To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.4 at neu.net X-Virus-Status: Clean X-Spam-Status: No, score=3.6 required=5.0 tests=TO_NO_BRKTS_DIRECT, TO_NO_BRKTS_NOTLIST,T_RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sop3 Subject: make installworld 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: Tue, 16 Nov 2010 18:20:55 -0000 Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. Tia From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 18:31:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F10F1106567A for ; Tue, 16 Nov 2010 18:31:26 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id ADA3B8FC1C for ; Tue, 16 Nov 2010 18:31:26 +0000 (UTC) X-AuditID: 12074423-b7bd0ae000000a00-06-4ce2cdfdffde Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 73.2E.02560.DFDC2EC4; Tue, 16 Nov 2010 13:31:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id oAGIVPww014605; Tue, 16 Nov 2010 13:31:25 -0500 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 oAGIVNjE007523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 13:31:24 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id oAGIVMJu003871; Tue, 16 Nov 2010 13:31:22 -0500 (EST) Date: Tue, 16 Nov 2010 13:31:22 -0500 (EST) From: Benjamin Kaduk To: AN 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: AAAAAA== Cc: freebsd-current@freebsd.org Subject: Re: make installworld 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: Tue, 16 Nov 2010 18:31:27 -0000 On Tue, 16 Nov 2010, AN wrote: > > Trying to installworld on 9-current AMD64, and it fails with: > > install -o root -g wheel -m 444 > /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ > Updating /etc/localtime > tzsetup: illegal option -- r > usage:tzsetup [-ns] > ***Error code 1 > > Stop in /usr/src/share/zoneinfo. > > (above was transcribed from console) > > Anyone else seeing this? Is there a fix > > Csup from last night. We have seen similar tzsetup errors in installworld in the past. Is your build environment unusual in any way (cross-building, DESTDIR set, etc.)? -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 18:39:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06F0210656A4 for ; Tue, 16 Nov 2010 18:39:41 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [204.109.60.194]) by mx1.freebsd.org (Postfix) with ESMTP id AB6048FC20 for ; Tue, 16 Nov 2010 18:39:41 +0000 (UTC) Received: from neu.net (neu.net [204.109.60.194]) by mail.neu.net (8.14.4/8.14.4) with ESMTP id oAGIdaAQ001425; Tue, 16 Nov 2010 18:39:36 GMT (envelope-from andy@neu.net) Date: Tue, 16 Nov 2010 18:39:35 +0000 (UTC) From: AN To: Benjamin Kaduk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.4 at neu.net X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.neu.net Cc: freebsd-current@freebsd.org Subject: Re: make installworld 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: Tue, 16 Nov 2010 18:39:42 -0000 On Tue, 16 Nov 2010, Benjamin Kaduk wrote: > On Tue, 16 Nov 2010, AN wrote: > >> >> Trying to installworld on 9-current AMD64, and it fails with: >> >> install -o root -g wheel -m 444 >> /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >> Updating /etc/localtime >> tzsetup: illegal option -- r >> usage:tzsetup [-ns] >> ***Error code 1 >> >> Stop in /usr/src/share/zoneinfo. >> >> (above was transcribed from console) >> >> Anyone else seeing this? Is there a fix >> >> Csup from last night. > > We have seen similar tzsetup errors in installworld in the past. Is your > build environment unusual in any way (cross-building, DESTDIR set, etc.)? > > -Ben Kaduk > Nothing unusual, standard plain install. I used an image from http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. Used standard procedure: csup make buildworld make buildkernel make install kernel make installworld (single user mode) From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 19:00:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F31B1065672 for ; Tue, 16 Nov 2010 19:00:26 +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 8F38C8FC32 for ; Tue, 16 Nov 2010 19:00:20 +0000 (UTC) X-AuditID: 1209190c-b7ba9ae0000009f8-c9-4ce2d4c3e6b9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id 2B.09.02552.3C4D2EC4; Tue, 16 Nov 2010 14:00:19 -0500 (EST) 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 oAGJ0JC9008349; Tue, 16 Nov 2010 14:00:19 -0500 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 oAGJ0HYu014359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 14:00:18 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id oAGJ0HnQ004635; Tue, 16 Nov 2010 14:00:17 -0500 (EST) Date: Tue, 16 Nov 2010 14:00:17 -0500 (EST) From: Benjamin Kaduk To: AN 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: AAAAARagEl4= Cc: freebsd-current@freebsd.org Subject: Re: make installworld 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: Tue, 16 Nov 2010 19:00:26 -0000 On Tue, 16 Nov 2010, AN wrote: > > > On Tue, 16 Nov 2010, Benjamin Kaduk wrote: > >> On Tue, 16 Nov 2010, AN wrote: >> >>> >>> Trying to installworld on 9-current AMD64, and it fails with: >>> >>> install -o root -g wheel -m 444 >>> /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >>> Updating /etc/localtime >>> tzsetup: illegal option -- r >>> usage:tzsetup [-ns] >>> ***Error code 1 >>> >>> Stop in /usr/src/share/zoneinfo. >>> >>> (above was transcribed from console) >>> >>> Anyone else seeing this? Is there a fix >>> >>> Csup from last night. >> >> We have seen similar tzsetup errors in installworld in the past. Is your >> build environment unusual in any way (cross-building, DESTDIR set, etc.)? >> >> -Ben Kaduk >> > > > Nothing unusual, standard plain install. I used an image from > http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. > > Used standard procedure: > > csup Hmm, what server do you csup from? My tzsetup has this usage: usage: tzsetup [-nrs] [zoneinfo file] The one quoted above looks to be rather old. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 19:36:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6291065673; Tue, 16 Nov 2010 19:36:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6C98FC08; Tue, 16 Nov 2010 19:36:06 +0000 (UTC) Received: by gwj20 with SMTP id 20so635313gwj.13 for ; Tue, 16 Nov 2010 11:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4JMrruOUPLqrhp3MyZdXXEkyfjDY23+5WXd4kduVn64=; b=QU1/kuZYg65rxWP33FSUe5JZA1lgC9EjOvliBhF0gt5cys78VkeySqfUBOxyvvc2/7 lRNQYzZnOLP9ko/xfclQowRRCFa0NUs5mejVHAMyqkrS00pO5p29MdGj7DAwvyL5Zo/Y ZNEVHkrcsNEvXJ0FiWdApvU2gul7Muv/UIR4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Hj2eHMcsJm2Xl92w2oUfa54LWPkUfUDipjVqWFjBnz2IrSNakjFXRvTTFGsecy/UjW CDIleLyJVMasVQMBq6fPAJtBgY0AlMxH2T8dZQZGVygHkzSmuTzP+1/R8JFnu51W/jjV 3ZQ97gu5pXWG/X1WTD+aFy0PJTb23+ga8k2DI= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr771506web.45.1289936165800; Tue, 16 Nov 2010 11:36:05 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 16 Nov 2010 11:36:05 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Nov 2010 11:36:05 -0800 X-Google-Sender-Auth: uimXIPfSi_soPnJYvM7c7xDP1GE Message-ID: From: Garrett Cooper To: AN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Benjamin Kaduk , Edwin Groothuis Subject: Re: make installworld 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: Tue, 16 Nov 2010 19:36:07 -0000 On Tue, Nov 16, 2010 at 10:39 AM, AN wrote: > > > On Tue, 16 Nov 2010, Benjamin Kaduk wrote: > >> On Tue, 16 Nov 2010, AN wrote: >> >>> >>> Trying to installworld on 9-current AMD64, and it fails with: >>> >>> install -o root -g wheel -m 444 >>> /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >>> Updating /etc/localtime >>> tzsetup: illegal option -- r >>> usage:tzsetup [-ns] >>> ***Error code 1 >>> >>> Stop in /usr/src/share/zoneinfo. >>> >>> (above was transcribed from console) >>> >>> Anyone else seeing this? =A0Is there a fix >>> >>> Csup from last night. >> >> We have seen similar tzsetup errors in installworld in the past. =A0Is y= our >> build environment unusual in any way (cross-building, DESTDIR set, etc.)= ? >> >> -Ben Kaduk >> > > > Nothing unusual, standard plain install. =A0I used an image from > http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago= . > > Used standard procedure: > > csup > make buildworld > make buildkernel > make install kernel > make installworld (single user mode) (CCing edwin@) There might be a handful of other apps that don't work when upgrading from major version to major version (config; the way to work around this particular issue is to execute: cd /usr/src make -C usr.sbin/tzsetup all install This should be fixed in the share/zoneinfo Makefile (but might be tricky with cross-builds); producing an UPDATING entry to document the breakage might be good enough. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 19:52:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043561065672; Tue, 16 Nov 2010 19:52:53 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id BE31C8FC1A; Tue, 16 Nov 2010 19:52:52 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id 0733B633201; Tue, 16 Nov 2010 20:33:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 2A2F02CF69A; Tue, 16 Nov 2010 20:33:52 +0100 (CET) Date: Tue, 16 Nov 2010 20:33:48 +0100 From: Patrick Lamaiziere To: freebsd-current@freebsd.org, Jung-uk Kim Message-ID: <20101116203348.3c1e6b4e@davenulle.org> In-Reply-To: <201011152036.48181.jkim@FreeBSD.org> References: <201011152036.48181.jkim@FreeBSD.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 19:52:53 -0000 Le Mon, 15 Nov 2010 20:36:42 -0500, Jung-uk Kim a écrit : > Often times I hear complaints like "my Mac hangs after upgrading to > 8.1" or "snapshot CD hangs on my brand new Mac". I know some of > these complaints started happening when we switched to new PAT > layout. It is so puzzling because it never happened on non-Apple > hardware, AFAIK. I really like to fix this problem but I cannot > afford a Mac. :-P Thanks. > If you are one of those lucky people, please test the attached patch > and report your hardware model and any improvement or regression. Shall we test if the model is not listed in the patch and already works fine? (I'm using a MacBookPro3,1 on FreeBSD 8.1) if (strncmp(sysenv, "MacBook5,1", 10) strncmp(sysenv, "MacBookPro5,5", strncmp(sysenv, "Macmini3,1", 10) strncmp(sysenv, "iMac9,1", 7) == 0) Regards. From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 20:00:06 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B53106564A; Tue, 16 Nov 2010 20:00:06 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [204.109.60.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD878FC0A; Tue, 16 Nov 2010 20:00:05 +0000 (UTC) Received: from neu.net (neu.net [204.109.60.194]) by mail.neu.net (8.14.4/8.14.4) with ESMTP id oAGJxu46001803; Tue, 16 Nov 2010 19:59:56 GMT (envelope-from andy@neu.net) Date: Tue, 16 Nov 2010 19:59:55 +0000 (UTC) From: AN To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.4 at neu.net X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.neu.net Cc: freebsd-current@FreeBSD.org, Benjamin Kaduk , Edwin Groothuis Subject: Re: make installworld 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: Tue, 16 Nov 2010 20:00:06 -0000 On Tue, 16 Nov 2010, Garrett Cooper wrote: > On Tue, Nov 16, 2010 at 10:39 AM, AN wrote: >> >> >> On Tue, 16 Nov 2010, Benjamin Kaduk wrote: >> >>> On Tue, 16 Nov 2010, AN wrote: >>> >>>> >>>> Trying to installworld on 9-current AMD64, and it fails with: >>>> >>>> install -o root -g wheel -m 444 >>>> /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >>>> Updating /etc/localtime >>>> tzsetup: illegal option -- r >>>> usage:tzsetup [-ns] >>>> ***Error code 1 >>>> >>>> Stop in /usr/src/share/zoneinfo. >>>> >>>> (above was transcribed from console) >>>> >>>> Anyone else seeing this? Is there a fix >>>> >>>> Csup from last night. >>> >>> We have seen similar tzsetup errors in installworld in the past. Is your >>> build environment unusual in any way (cross-building, DESTDIR set, etc.)? >>> >>> -Ben Kaduk >>> >> >> >> Nothing unusual, standard plain install. I used an image from >> http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. >> >> Used standard procedure: >> >> csup >> make buildworld >> make buildkernel >> make install kernel >> make installworld (single user mode) > > (CCing edwin@) > > There might be a handful of other apps that don't work when upgrading > from major version to major version (config; the way to work around > this particular issue is to execute: > > cd /usr/src > make -C usr.sbin/tzsetup all install > > This should be fixed in the share/zoneinfo Makefile (but might be > tricky with cross-builds); producing an UPDATING entry to document the > breakage might be good enough. > > Thanks, > -Garrett > > Hi Garrett: After executing: cd /usr/src make -C usr.sbin/tzsetup all install make installworld completed sucessfully Machine is back, and seems to be fine. Thanks for your fast and helpful reply. From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 20:01:25 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8E51065673 for ; Tue, 16 Nov 2010 20:01:25 +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 0D4098FC16 for ; Tue, 16 Nov 2010 20:01:24 +0000 (UTC) X-AuditID: 1209190e-b7b3bae000000a71-bf-4ce2e3143176 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 70.44.02673.413E2EC4; Tue, 16 Nov 2010 15:01:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id oAGK1NgB024407; Tue, 16 Nov 2010 15:01:23 -0500 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 oAGK1MAV029609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 15:01:23 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id oAGK1L9d005675; Tue, 16 Nov 2010 15:01:21 -0500 (EST) Date: Tue, 16 Nov 2010 15:01:21 -0500 (EST) From: Benjamin Kaduk To: Garrett Cooper 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: AAAAAA== Cc: freebsd-current@FreeBSD.org, AN , Edwin Groothuis Subject: Re: make installworld 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: Tue, 16 Nov 2010 20:01:25 -0000 On Tue, 16 Nov 2010, Garrett Cooper wrote: > There might be a handful of other apps that don't work when upgrading > from major version to major version (config; the way to work around this > I thought we only supported major version upgrades by first upgrading from RELENG_X_Y to RELENG_X and then to RELENG_{X+1}_Z, but I didn't find documentation for that in a quick check. > > This should be fixed in the share/zoneinfo Makefile (but might be > tricky with cross-builds); producing an UPDATING entry to document the > breakage might be good enough. I had actually thought we fixed it a year ago when I ran into issues with r198351, but my memory is a bit hazy on what actually happened. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 20:05:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id CB79D106564A; Tue, 16 Nov 2010 20:05:14 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Patrick Lamaiziere Date: Tue, 16 Nov 2010 15:05:05 -0500 User-Agent: KMail/1.6.2 References: <201011152036.48181.jkim@FreeBSD.org> <20101116203348.3c1e6b4e@davenulle.org> In-Reply-To: <20101116203348.3c1e6b4e@davenulle.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201011161505.07740.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 20:05:16 -0000 On Tuesday 16 November 2010 02:33 pm, Patrick Lamaiziere wrote: > Le Mon, 15 Nov 2010 20:36:42 -0500, > > Jung-uk Kim a écrit : > > Often times I hear complaints like "my Mac hangs after upgrading > > to 8.1" or "snapshot CD hangs on my brand new Mac". I know some > > of these complaints started happening when we switched to new PAT > > layout. It is so puzzling because it never happened on non-Apple > > hardware, AFAIK. I really like to fix this problem but I cannot > > afford a Mac. :-P > > Thanks. > > > If you are one of those lucky people, please test the attached > > patch and report your hardware model and any improvement or > > regression. > > Shall we test if the model is not listed in the patch and already > works fine? (I'm using a MacBookPro3,1 on FreeBSD 8.1) > > if (strncmp(sysenv, "MacBook5,1", 10) > strncmp(sysenv, "MacBookPro5,5", > strncmp(sysenv, "Macmini3,1", 10) > strncmp(sysenv, "iMac9,1", 7) == 0) There's no need if it already works fine. It seems the new PAT layout only broke recent models with NVidia chipset. Also, this patch won't apply to stable pmap.c. Actually, I am working on more complex version now. When I am done, I'll make patches for both branches. Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 20:30:29 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 482A8106566C; Tue, 16 Nov 2010 20:30:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Date: Tue, 16 Nov 2010 15:30:18 -0500 User-Agent: KMail/1.6.2 References: <201011152036.48181.jkim@FreeBSD.org> In-Reply-To: <201011152036.48181.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011161530.20165.jkim@FreeBSD.org> Cc: Ed Schouten , Hans Petter Selasky Subject: Re: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 20:30:29 -0000 On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: > Often times I hear complaints like "my Mac hangs after upgrading to > 8.1" or "snapshot CD hangs on my brand new Mac". I know some of > these complaints started happening when we switched to new PAT > layout. It is so puzzling because it never happened on non-Apple > hardware, AFAIK. I really like to fix this problem but I cannot > afford a Mac. :-P > > If you are one of those lucky people, please test the attached > patch and report your hardware model and any improvement or > regression. > > Also, I added a new tunable "vm.pmap.pat_works" so that you can > turn it off from loader (i.e., "set vm.pmap.pat_works=0") and > restore old behaviour without recompiling a new kernel. I revised this patch to make it more robust. http://people.freebsd.org/~jkim/pat-current.diff Also, I prepared a patch for stable/8. If you have recent Apple hardware and it hangs with 8.1 or stable/8, please test this patch. http://people.freebsd.org/~jkim/pat-stable.diff Thanks! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 22:19:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86942106566B; Tue, 16 Nov 2010 22:19:06 +0000 (UTC) (envelope-from adrian.chadd@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 93E038FC1B; Tue, 16 Nov 2010 22:19:05 +0000 (UTC) Received: by wyb35 with SMTP id 35so404212wyb.13 for ; Tue, 16 Nov 2010 14:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rOFBbTuxnWVzfOftmlbfnyGT7hp18rmVRlPxXG5z55k=; b=bevQ/h60xMvnyZanJjyklwScfmVOnBve2A1fFFoWWJJIq0DUmuC2aJCjMgPSEsMzZH UnMFbfKbujzp+BDpkRhTLAbVa8NQunzZJezx7WsOHYee3glCcPIhMNJBFgjRuUHiPGq5 Xj6oXMszxrbMa1Hi30ohDxiXih63p28c9X8Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=H2M4odKKt7rXZGV+6LPh2En8SsCMV5LB87XYhRRRWxWoXARfHFsC3W1HbTV+ZuYqGN u57PsyoHxVYlchEUpblpM6KH9sML3xzISjQWR5dlS2AfNJxCLHZpoiMNiSpsVxBRUw1Z jkQth5GPT2XLoA833na22BWqTQCgkWq6zhbfs= MIME-Version: 1.0 Received: by 10.216.46.19 with SMTP id q19mr650148web.0.1289945944342; Tue, 16 Nov 2010 14:19:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 14:19:04 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Wed, 17 Nov 2010 06:19:04 +0800 X-Google-Sender-Auth: uiFfRJjXQAW4V5XYeqP1Z5v_KTc Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-hackers@freebsd.org, "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 22:19:06 -0000 Oops, I can't believe I committed the wrong version of this damned thing. I'll go and commit that particular un-braindamage. in a sec. Sorry everyone. Adrian On 17 November 2010 02:04, Garrett Cooper wrote: > On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wro= te: >> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>> On 16.11.2010 16:29, John Baldwin wrote: >>>> > Err, are there no longer hard links to all of the frontends for a gi= ven >>>> > crunch? =A0If so, that is a problem as it will make rescue much hard= er to use. >>>> >>>> Yes, probably this patch is not needed and it should be fixed somewher= e in >>>> makefiles. But currently rescue does not have any hardlinks: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JP= SNAP/cdrom/livefs/rescue/ >>>> >>>> And what is was before: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JP= SNAP/cdrom/livefs/rescue/ >>> >>> That definitely needs to be fixed. >> >> =A0 =A0The .mk file wasn't being installed. Could someone please test >> this patch for validity and commit it? >> =A0 =A0More importantly, why didn't the above build process, or tinderbo= x >> fail properly with this change? > > Ouch. I can definitely still see the other problem: > > # make install > install -s -o root -g wheel -m 555 =A0 rescue /rescue > install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot > install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient-= script > > The second attached patch (not a superset of the first) what unbreaks it: > > # make -C rescue/rescue/ install > install -s -o root -g wheel -m 555 =A0 rescue /rescue > install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot > install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient-= script > /rescue/cat -> /rescue/rescue > /rescue/chflags -> /rescue/rescue > /rescue/chio -> /rescue/rescue > /rescue/chmod -> /rescue/rescue > /rescue/cp -> /rescue/rescue > /rescue/date -> /rescue/rescue > /rescue/dd -> /rescue/rescue > /rescue/df -> /rescue/rescue > /rescue/echo -> /rescue/rescue > /rescue/ed -> /rescue/rescue > /rescue/red -> /rescue/rescue > /rescue/expr -> /rescue/rescue > /rescue/getfacl -> /rescue/rescue > /rescue/hostname -> /rescue/rescue > /rescue/kenv -> /rescue/rescue > /rescue/kill -> /rescue/rescue > /rescue/ln -> /rescue/rescue > /rescue/link -> /rescue/rescue > /rescue/ls -> /rescue/rescue > /rescue/mkdir -> /rescue/rescue > /rescue/mv -> /rescue/rescue > /rescue/pkill -> /rescue/rescue > /rescue/pgrep -> /rescue/rescue > /rescue/ps -> /rescue/rescue > /rescue/pwd -> /rescue/rescue > /rescue/realpath -> /rescue/rescue > /rescue/rm -> /rescue/rescue > /rescue/unlink -> /rescue/rescue > /rescue/rmdir -> /rescue/rescue > /rescue/setfacl -> /rescue/rescue > /rescue/sh -> /rescue/rescue > /rescue/stty -> /rescue/rescue > /rescue/sync -> /rescue/rescue > /rescue/test -> /rescue/rescue > /rescue/[ -> /rescue/rescue > /rescue/csh -> /rescue/rescue > /rescue/tcsh -> /rescue/rescue > /rescue/atacontrol -> /rescue/rescue > /rescue/badsect -> /rescue/rescue > /rescue/camcontrol -> /rescue/rescue > /rescue/ccdconfig -> /rescue/rescue > /rescue/clri -> /rescue/rescue > /rescue/devfs -> /rescue/rescue > /rescue/dmesg -> /rescue/rescue > /rescue/dump -> /rescue/rescue > /rescue/rdump -> /rescue/rescue > /rescue/dumpfs -> /rescue/rescue > /rescue/dumpon -> /rescue/rescue > /rescue/fsck -> /rescue/rescue > /rescue/fsck_ffs -> /rescue/rescue > /rescue/fsck_4.2bsd -> /rescue/rescue > /rescue/fsck_ufs -> /rescue/rescue > /rescue/fsck_msdosfs -> /rescue/rescue > /rescue/fsdb -> /rescue/rescue > /rescue/fsirand -> /rescue/rescue > /rescue/gbde -> /rescue/rescue > /rescue/geom -> /rescue/rescue > /rescue/glabel -> /rescue/rescue > /rescue/gpart -> /rescue/rescue > /rescue/ifconfig -> /rescue/rescue > /rescue/init -> /rescue/rescue > /rescue/kldconfig -> /rescue/rescue > /rescue/kldload -> /rescue/rescue > /rescue/kldstat -> /rescue/rescue > /rescue/kldunload -> /rescue/rescue > /rescue/ldconfig -> /rescue/rescue > /rescue/md5 -> /rescue/rescue > /rescue/mdconfig -> /rescue/rescue > /rescue/mdmfs -> /rescue/rescue > /rescue/mknod -> /rescue/rescue > /rescue/mount -> /rescue/rescue > /rescue/mount_cd9660 -> /rescue/rescue > /rescue/mount_msdosfs -> /rescue/rescue > /rescue/mount_nfs -> /rescue/rescue > /rescue/mount_ntfs -> /rescue/rescue > /rescue/mount_nullfs -> /rescue/rescue > /rescue/mount_udf -> /rescue/rescue > /rescue/mount_unionfs -> /rescue/rescue > /rescue/newfs -> /rescue/rescue > /rescue/newfs_msdos -> /rescue/rescue > /rescue/nos-tun -> /rescue/rescue > /rescue/ping -> /rescue/rescue > /rescue/reboot -> /rescue/rescue > /rescue/fastboot -> /rescue/rescue > /rescue/halt -> /rescue/rescue > /rescue/fasthalt -> /rescue/rescue > /rescue/restore -> /rescue/rescue > /rescue/rrestore -> /rescue/rescue > /rescue/rcorder -> /rescue/rescue > /rescue/route -> /rescue/rescue > /rescue/routed -> /rescue/rescue > /rescue/rtquery -> /rescue/rescue > /rescue/rtsol -> /rescue/rescue > /rescue/savecore -> /rescue/rescue > /rescue/spppcontrol -> /rescue/rescue > /rescue/swapon -> /rescue/rescue > /rescue/sysctl -> /rescue/rescue > /rescue/tunefs -> /rescue/rescue > /rescue/umount -> /rescue/rescue > /rescue/bsdlabel -> /rescue/rescue > /rescue/disklabel -> /rescue/rescue > /rescue/fdisk -> /rescue/rescue > /rescue/dhclient -> /rescue/rescue > /rescue/head -> /rescue/rescue > /rescue/mt -> /rescue/rescue > /rescue/sed -> /rescue/rescue > /rescue/tail -> /rescue/rescue > /rescue/tee -> /rescue/rescue > /rescue/gzip -> /rescue/rescue > /rescue/gunzip -> /rescue/rescue > /rescue/gzcat -> /rescue/rescue > /rescue/zcat -> /rescue/rescue > /rescue/bzip2 -> /rescue/rescue > /rescue/bunzip2 -> /rescue/rescue > /rescue/bzcat -> /rescue/rescue > /rescue/xz -> /rescue/rescue > /rescue/unxz -> /rescue/rescue > /rescue/lzma -> /rescue/rescue > /rescue/unlzma -> /rescue/rescue > /rescue/xzcat -> /rescue/rescue > /rescue/lzcat -> /rescue/rescue > /rescue/tar -> /rescue/rescue > /rescue/vi -> /rescue/rescue > /rescue/ex -> /rescue/rescue > /rescue/id -> /rescue/rescue > /rescue/groups -> /rescue/rescue > /rescue/whoami -> /rescue/rescue > /rescue/chroot -> /rescue/rescue > /rescue/chown -> /rescue/rescue > /rescue/chgrp -> /rescue/rescue > > So it looks like something tunable needs to be added to the .mk file > to deal with hardlinks as this basically reenables functionality that > Adrian disabled. > > Thanks, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 22:23:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C54AD106564A; Tue, 16 Nov 2010 22:23:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id D1A5B8FC18; Tue, 16 Nov 2010 22:23:57 +0000 (UTC) Received: by wwb28 with SMTP id 28so154520wwb.1 for ; Tue, 16 Nov 2010 14:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PE8ie1nQIiOjYWzM8pS82w9qRpfZCDIpFPHTWuV4/NY=; b=qzZHNIhlpivw8SEXxlBBLKharIh/COVGxpzwsdBbmLW4LREcQNuCnlXcnNQc1By5i8 qesLQQPMTLfZtV1OS/lxzPgQBl37k126mevXHe6eeYonPR9AAoHMc+OfnXqL5WV2J/3C +2N5/57XrH9PmxMov8YzlbuftZxRaLw3FN5Bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gUwHl808c1dAZgnTjvjsJ99h4AkoQddUzMivoY46pHbKiJuUaL1m68XmDo3HIwID3+ rZ5+1N8IL38/IPJesldPHNN/yklPm0GpuSxihre4GVLQXedK8KH2swzr4YHwaZoh8mLi 9XB01F3vru74iyp0AmIzVo4UlJzOZ3zclhl10= MIME-Version: 1.0 Received: by 10.216.5.21 with SMTP id 21mr830194wek.20.1289946235708; Tue, 16 Nov 2010 14:23:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 14:23:55 -0800 (PST) In-Reply-To: References: <201011160829.13511.jhb@freebsd.org> <4CE28AE4.70101@yandex.ru> <201011160912.27693.jhb@freebsd.org> Date: Wed, 17 Nov 2010 06:23:55 +0800 X-Google-Sender-Auth: UARpsTmeTUvB-FS9RwA_tikQAkA Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , freebsd-hackers@freebsd.org, "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: breaking the crunchgen logic into a share/mk file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 22:23:59 -0000 I've just committed: * stuff to re-enable the link production * installing bsd.crunchgen.mk Thanks, Adrian On 17 November 2010 06:19, Adrian Chadd wrote: > Oops, I can't believe I committed the wrong version of this damned thing. > > I'll go and commit that particular un-braindamage. in a sec. > > Sorry everyone. > > > > Adrian > > On 17 November 2010 02:04, Garrett Cooper wrote: >> On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wr= ote: >>> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>>> On 16.11.2010 16:29, John Baldwin wrote: >>>>> > Err, are there no longer hard links to all of the frontends for a g= iven >>>>> > crunch? =A0If so, that is a problem as it will make rescue much har= der to use. >>>>> >>>>> Yes, probably this patch is not needed and it should be fixed somewhe= re in >>>>> makefiles. But currently rescue does not have any hardlinks: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-J= PSNAP/cdrom/livefs/rescue/ >>>>> >>>>> And what is was before: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-J= PSNAP/cdrom/livefs/rescue/ >>>> >>>> That definitely needs to be fixed. >>> >>> =A0 =A0The .mk file wasn't being installed. Could someone please test >>> this patch for validity and commit it? >>> =A0 =A0More importantly, why didn't the above build process, or tinderb= ox >>> fail properly with this change? >> >> Ouch. I can definitely still see the other problem: >> >> # make install >> install -s -o root -g wheel -m 555 =A0 rescue /rescue >> install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot >> install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient= -script >> >> The second attached patch (not a superset of the first) what unbreaks it= : >> >> # make -C rescue/rescue/ install >> install -s -o root -g wheel -m 555 =A0 rescue /rescue >> install -o root =A0-g wheel -m 555 =A0nextboot_FIXED =A0/rescue/nextboot >> install -o root =A0-g wheel -m 555 =A0dhclient_FIXED =A0/rescue/dhclient= -script >> /rescue/cat -> /rescue/rescue >> /rescue/chflags -> /rescue/rescue >> /rescue/chio -> /rescue/rescue >> /rescue/chmod -> /rescue/rescue >> /rescue/cp -> /rescue/rescue >> /rescue/date -> /rescue/rescue >> /rescue/dd -> /rescue/rescue >> /rescue/df -> /rescue/rescue >> /rescue/echo -> /rescue/rescue >> /rescue/ed -> /rescue/rescue >> /rescue/red -> /rescue/rescue >> /rescue/expr -> /rescue/rescue >> /rescue/getfacl -> /rescue/rescue >> /rescue/hostname -> /rescue/rescue >> /rescue/kenv -> /rescue/rescue >> /rescue/kill -> /rescue/rescue >> /rescue/ln -> /rescue/rescue >> /rescue/link -> /rescue/rescue >> /rescue/ls -> /rescue/rescue >> /rescue/mkdir -> /rescue/rescue >> /rescue/mv -> /rescue/rescue >> /rescue/pkill -> /rescue/rescue >> /rescue/pgrep -> /rescue/rescue >> /rescue/ps -> /rescue/rescue >> /rescue/pwd -> /rescue/rescue >> /rescue/realpath -> /rescue/rescue >> /rescue/rm -> /rescue/rescue >> /rescue/unlink -> /rescue/rescue >> /rescue/rmdir -> /rescue/rescue >> /rescue/setfacl -> /rescue/rescue >> /rescue/sh -> /rescue/rescue >> /rescue/stty -> /rescue/rescue >> /rescue/sync -> /rescue/rescue >> /rescue/test -> /rescue/rescue >> /rescue/[ -> /rescue/rescue >> /rescue/csh -> /rescue/rescue >> /rescue/tcsh -> /rescue/rescue >> /rescue/atacontrol -> /rescue/rescue >> /rescue/badsect -> /rescue/rescue >> /rescue/camcontrol -> /rescue/rescue >> /rescue/ccdconfig -> /rescue/rescue >> /rescue/clri -> /rescue/rescue >> /rescue/devfs -> /rescue/rescue >> /rescue/dmesg -> /rescue/rescue >> /rescue/dump -> /rescue/rescue >> /rescue/rdump -> /rescue/rescue >> /rescue/dumpfs -> /rescue/rescue >> /rescue/dumpon -> /rescue/rescue >> /rescue/fsck -> /rescue/rescue >> /rescue/fsck_ffs -> /rescue/rescue >> /rescue/fsck_4.2bsd -> /rescue/rescue >> /rescue/fsck_ufs -> /rescue/rescue >> /rescue/fsck_msdosfs -> /rescue/rescue >> /rescue/fsdb -> /rescue/rescue >> /rescue/fsirand -> /rescue/rescue >> /rescue/gbde -> /rescue/rescue >> /rescue/geom -> /rescue/rescue >> /rescue/glabel -> /rescue/rescue >> /rescue/gpart -> /rescue/rescue >> /rescue/ifconfig -> /rescue/rescue >> /rescue/init -> /rescue/rescue >> /rescue/kldconfig -> /rescue/rescue >> /rescue/kldload -> /rescue/rescue >> /rescue/kldstat -> /rescue/rescue >> /rescue/kldunload -> /rescue/rescue >> /rescue/ldconfig -> /rescue/rescue >> /rescue/md5 -> /rescue/rescue >> /rescue/mdconfig -> /rescue/rescue >> /rescue/mdmfs -> /rescue/rescue >> /rescue/mknod -> /rescue/rescue >> /rescue/mount -> /rescue/rescue >> /rescue/mount_cd9660 -> /rescue/rescue >> /rescue/mount_msdosfs -> /rescue/rescue >> /rescue/mount_nfs -> /rescue/rescue >> /rescue/mount_ntfs -> /rescue/rescue >> /rescue/mount_nullfs -> /rescue/rescue >> /rescue/mount_udf -> /rescue/rescue >> /rescue/mount_unionfs -> /rescue/rescue >> /rescue/newfs -> /rescue/rescue >> /rescue/newfs_msdos -> /rescue/rescue >> /rescue/nos-tun -> /rescue/rescue >> /rescue/ping -> /rescue/rescue >> /rescue/reboot -> /rescue/rescue >> /rescue/fastboot -> /rescue/rescue >> /rescue/halt -> /rescue/rescue >> /rescue/fasthalt -> /rescue/rescue >> /rescue/restore -> /rescue/rescue >> /rescue/rrestore -> /rescue/rescue >> /rescue/rcorder -> /rescue/rescue >> /rescue/route -> /rescue/rescue >> /rescue/routed -> /rescue/rescue >> /rescue/rtquery -> /rescue/rescue >> /rescue/rtsol -> /rescue/rescue >> /rescue/savecore -> /rescue/rescue >> /rescue/spppcontrol -> /rescue/rescue >> /rescue/swapon -> /rescue/rescue >> /rescue/sysctl -> /rescue/rescue >> /rescue/tunefs -> /rescue/rescue >> /rescue/umount -> /rescue/rescue >> /rescue/bsdlabel -> /rescue/rescue >> /rescue/disklabel -> /rescue/rescue >> /rescue/fdisk -> /rescue/rescue >> /rescue/dhclient -> /rescue/rescue >> /rescue/head -> /rescue/rescue >> /rescue/mt -> /rescue/rescue >> /rescue/sed -> /rescue/rescue >> /rescue/tail -> /rescue/rescue >> /rescue/tee -> /rescue/rescue >> /rescue/gzip -> /rescue/rescue >> /rescue/gunzip -> /rescue/rescue >> /rescue/gzcat -> /rescue/rescue >> /rescue/zcat -> /rescue/rescue >> /rescue/bzip2 -> /rescue/rescue >> /rescue/bunzip2 -> /rescue/rescue >> /rescue/bzcat -> /rescue/rescue >> /rescue/xz -> /rescue/rescue >> /rescue/unxz -> /rescue/rescue >> /rescue/lzma -> /rescue/rescue >> /rescue/unlzma -> /rescue/rescue >> /rescue/xzcat -> /rescue/rescue >> /rescue/lzcat -> /rescue/rescue >> /rescue/tar -> /rescue/rescue >> /rescue/vi -> /rescue/rescue >> /rescue/ex -> /rescue/rescue >> /rescue/id -> /rescue/rescue >> /rescue/groups -> /rescue/rescue >> /rescue/whoami -> /rescue/rescue >> /rescue/chroot -> /rescue/rescue >> /rescue/chown -> /rescue/rescue >> /rescue/chgrp -> /rescue/rescue >> >> So it looks like something tunable needs to be added to the .mk file >> to deal with hardlinks as this basically reenables functionality that >> Adrian disabled. >> >> Thanks, >> -Garrett >> > From owner-freebsd-current@FreeBSD.ORG Tue Nov 16 22:41:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E5FFF106566B; Tue, 16 Nov 2010 22:41:56 +0000 (UTC) Date: Tue, 16 Nov 2010 22:41:56 +0000 From: Alexander Best To: Marcin Wisnicki Message-ID: <20101116224156.GA52556@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2010 22:41:57 -0000 On Tue Nov 16 10, Marcin Wisnicki wrote: > On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > > > On 11/13/10 2:08 PM, Robert Watson wrote: > >> > >> If regular crashdumps appear unreliable, try setting up a textdump with > >> an automatic reboot, that might provde more reliable (small chance, but > >> it could). > > > > we did have some people working on an ethernet version of the > > dcons/remote debugging stuff > > I guess it only supports a small subset of ethernet chips though.. > > Anyone know the status of that work? > > > > I don't know about ethernet dump but how about simply dumping memory after > reset ? > > See: > - http://en.wikipedia.org/wiki/Cold_boot_attack > - http://citp.princeton.edu/memory/ > - http://www.mcgrewsecurity.com/tools/msramdmp/ > > Last link contains a tool to dump memory to usb disk after reset. If kgdb > works with raw memory dumps, it may already work. > > This has the potential to solve all tricky debugging cases without needing > firewire. WOW! this is the first time i hear of such a concept. it seems great for people like me who are desktop users without any serial/firewire consoles or any additional debugging hardware. is there a way of trying this out somehow? personally i wouldn't need the memory dump to work in partitions. i'd simply blug in a blank usb stick and have the memory dump dd'ed onto it. i think adding partition awareness is not really needed. cheers. alex > > A boot time kernel option to avoid certain memory areas which are > overwritten during boot by bios and ram dumping tool could be useful or > maybe necessary. > > It can even be completely automated, eg. if kernel would maintain some > kind of "RAM dirty" flag, then during boot something (loader or kernel) > would check for it and perform dump if needed. > > Another idea worth implementing or at least adding to project ideas list > is to implement everything that is currently possible with serial (boot0, > loader, kernel console, ddb) over EHCI debug port: > - http://www.coreboot.org/EHCI_Debug_Port > -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 03:07:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F9D1065673; Wed, 17 Nov 2010 03:07:11 +0000 (UTC) (envelope-from adrian.chadd@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 AEACF8FC18; Wed, 17 Nov 2010 03:07:10 +0000 (UTC) Received: by wwd20 with SMTP id 20so1493126wwd.31 for ; Tue, 16 Nov 2010 19:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HOAX9yMStPrnvHc2fKb7Q3ZH5TwmPb9EXEblnBgPlss=; b=j6stnoYdkAVPxWD6LNBmNzt/V/AsaIPcZetLoxjItY4xORhBgDUOOgkcSe1VBTmL5/ RMISx8eUTIEL8cEnyHQoGoBUUoYVcaxLMcYpSRC/GtabOiR2VEfxXSwlzjSYm76UquDJ 6XTVh7u8E15vB9p0DwTvX9kWAA3NbmS1BAdHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=gYCPQAocktbZ4zBwLqkVO7jppVnKL7JxxqxFyNXiY+tcT5wEiH2PQ1blATJovvODe9 E/IB9OO3wF7AM992uB0NDmKKHKiCqFosToZD50G2IbziJ6x11j2tnEqgXpwt9j58ZOYG qaZg3bcA8sDcvVKXdzCucvtU5wXlcJP5/uAH8= MIME-Version: 1.0 Received: by 10.216.142.131 with SMTP id i3mr1132874wej.5.1289963229083; Tue, 16 Nov 2010 19:07:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 16 Nov 2010 19:07:09 -0800 (PST) In-Reply-To: <19680.8138.582316.245120@gossamer.timing.com> References: <19680.8138.582316.245120@gossamer.timing.com> Date: Wed, 17 Nov 2010 11:07:09 +0800 X-Google-Sender-Auth: NtB3hwy-bl4gpj2aXNFar1oUPss Message-ID: From: Adrian Chadd To: John Hein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current , freebsd-embedded@freebsd.org Subject: Re: The path is now set for "busybox", FreeBSD style X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 03:07:11 -0000 Nope. it's easy. That's why I've done it. Adrian On 15 November 2010 01:43, John Hein wrote: > Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > > I've committed the below changes to -HEAD. You can now create and build > your > > own busybox style binary system, completely cross-compiled within the > > existing Make framework. It isn't as impressive as it sounds though - a > lot > > of the framework is already there from just building crunchgen'ed > > rescue/sysinstall binaries. > > > > There's a few things which should be done. Specifically, being able to > build > > an alternative set of libraries before building the crunchgen target. > The > > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, > etc > > but you may not want your crunch'ed image to have them. To do this right > > now, you have to disable these features in the main build. That may be > OK > > for some. > > > > But just to stress it - I've got a couple of access point images at home > > running a crunchgen'ed environment under MIPS and besides the obvious > binary > > bloat, it works perfectly well. Besides a cut-down startup framework, > the > > image cross-builds entirely from the base FreeBSD source tree. > > > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > > Makefile scripts online to try. > > That's great. > I assume it be not be hard for someone to take your scripts as a > starting point and create a sysutils/bsdbox akin to sysutils/busybox? > From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 03:20:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 37BF11065674; Wed, 17 Nov 2010 03:20:12 +0000 (UTC) Date: Wed, 17 Nov 2010 03:20:12 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101117032012.GA93866@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <20101110215839.GA74943@freebsd.org> <20101110220721.GA76154@freebsd.org> <201011101717.51062.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011101717.51062.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 03:20:12 -0000 On Wed Nov 10 10, John Baldwin wrote: > On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > > On Wed Nov 10 10, Alexander Best wrote: > > > On Tue Nov 9 10, John Baldwin wrote: > > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > > hi there, > > > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > > the second attempt). > > > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > > loaded. > > > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > > > Id Refs Address Size Name > > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > > to the description in kldunload(2). > > > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > > after boot? > > > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > > 3 for netgraph.ko and i get the behavior i described beforehand. > > Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually > loading any other netgraph modules so that nothing is loaded magically as a > dependency) and see what behavior that gives you. sorry it took me a while to check this out. i did some more research and it seems a few things are broken: 1) i have snd_hda in my loader.conf which will load sound as a dependency. unloading snd_hda should then automatically unload sound, which it *doesn't*. i need to unload sound manually. 2) if i unload all ng_* modules i should then be able to also unload netgraph, because no dependencies are left. however kldunload fails with EBUSY! cheers. alex > > When you load modules from the loader, they and all their dependencies are > treated as if you had manually loaded them similar to kldload. This because > the kernel can't determine which modules loaded by the loader were silent > dependencies. > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 03:35:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B51071065670; Wed, 17 Nov 2010 03:35:20 +0000 (UTC) Date: Wed, 17 Nov 2010 03:35:20 +0000 From: Alexander Best To: Marcin Wisnicki Message-ID: <20101117033520.GA95666@freebsd.org> References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> <20101116224156.GA52556@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101116224156.GA52556@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 03:35:20 -0000 On Tue Nov 16 10, Alexander Best wrote: > On Tue Nov 16 10, Marcin Wisnicki wrote: > > On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > > > > > On 11/13/10 2:08 PM, Robert Watson wrote: > > >> > > >> If regular crashdumps appear unreliable, try setting up a textdump with > > >> an automatic reboot, that might provde more reliable (small chance, but > > >> it could). > > > > > > we did have some people working on an ethernet version of the > > > dcons/remote debugging stuff > > > I guess it only supports a small subset of ethernet chips though.. > > > Anyone know the status of that work? > > > > > > > I don't know about ethernet dump but how about simply dumping memory after > > reset ? > > > > See: > > - http://en.wikipedia.org/wiki/Cold_boot_attack > > - http://citp.princeton.edu/memory/ > > - http://www.mcgrewsecurity.com/tools/msramdmp/ > > > > Last link contains a tool to dump memory to usb disk after reset. If kgdb > > works with raw memory dumps, it may already work. > > > > This has the potential to solve all tricky debugging cases without needing > > firewire. > > WOW! this is the first time i hear of such a concept. it seems great for > people like me who are desktop users without any serial/firewire consoles or > any additional debugging hardware. > > is there a way of trying this out somehow? personally i wouldn't need the > memory dump to work in partitions. i'd simply blug in a blank usb stick and > have the memory dump dd'ed onto it. i think adding partition awareness is not > really needed. ok i read some more details and i think i figured out how to dump the memory to a usb stick. question still remains however: will i be able to use that memory snapshot in kgdb or gdb? cheers. alex > > cheers. > alex > > > > > A boot time kernel option to avoid certain memory areas which are > > overwritten during boot by bios and ram dumping tool could be useful or > > maybe necessary. > > > > It can even be completely automated, eg. if kernel would maintain some > > kind of "RAM dirty" flag, then during boot something (loader or kernel) > > would check for it and perform dump if needed. > > > > Another idea worth implementing or at least adding to project ideas list > > is to implement everything that is currently possible with serial (boot0, > > loader, kernel console, ddb) over EHCI debug port: > > - http://www.coreboot.org/EHCI_Debug_Port > > > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 05:46:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E10106566C for ; Wed, 17 Nov 2010 05:46:30 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3F87D8FC1A for ; Wed, 17 Nov 2010 05:46:27 +0000 (UTC) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 23CFED1A00E for ; Wed, 17 Nov 2010 06:27:42 +0100 (CET) Received: from mail.herbelot.nom (unknown [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9DA3182257 for ; Wed, 17 Nov 2010 06:27:36 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id oAH5RY1G022744 for ; Wed, 17 Nov 2010 06:27:34 +0100 (CET) To: "freebsd-current" Content-Disposition: inline From: Thierry Herbelot Date: Wed, 17 Nov 2010 06:27:27 +0100 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Af24MOlSd6d3t6h" Message-Id: <201011170627.28025.thierry.herbelot@free.fr> Subject: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 05:46:30 -0000 --Boundary-00=_Af24MOlSd6d3t6h Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, We are using FreeBSD + VIMAGE at work, and we have seen an annoying problem : there seems to be a memory leak in the kernel, which eventually causes a panic. (yes, we have seen the following message : "WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.") Configuring a network interface in a jail with vnet enabled, then removing that jail causes these messages. In dmesg: [...] Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled (with attached VIMAGE kernel config file). The following commands reproduce the bug: jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo Running it too many times exhausts kernel memory and crashes the machine. The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN -head. Attachments: dmesg log and kernel config. cheers Thierry Herbelot --Boundary-00=_Af24MOlSd6d3t6h Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=VIMAGE # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.519.2.10.2.1 2010/06/14 02:09:06 kensmith Exp $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident VIMAGE options VIMAGE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device ti # Alteon Networks Tigon I/II gigabit Ethernet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device ae # Attansic/Atheros L2 FastEthernet device age # Attansic/Atheros L1 Gigabit Ethernet device alc # Atheros AR8131/AR8132 Ethernet device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sge # Silicon Integrated Systems SiS190/191 device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player # USB Serial devices device u3g # USB-based 3G modems (Option, Huawei, Sierra) device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet device udav # Davicom DM9601E USB # USB Wireless device rum # Ralink Technology RT2501USB wireless NICs device uath # Atheros AR5523 wireless NICs device ural # Ralink Technology RT2500USB wireless NICs device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons --Boundary-00=_Af24MOlSd6d3t6h Content-Type: text/plain; charset="ISO-8859-15"; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE #0: Tue Nov 16 17:45:10 CET 2010 root@waldorf:/usr/src/sys/i386/compile/VIMAGE i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz (2660.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3400019968 (3242 MB) ACPI APIC Table: <070809 APIC1512> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <070809 RSDT1512> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cf600000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x6F, should be 0x6A (20100331/tbutils-354) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci4: on pcib1 em0: port 0xe880-0xe89f mem 0xfeb80000-0xfeb9ffff,0xfeb60000-0xfeb7ffff irq 16 at device 0.0 on pci4 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:eb:a1:d2 em1: port 0xec00-0xec1f mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 17 at device 0.1 on pci4 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:eb:a1:d3 vgapci0: port 0xbc00-0xbc07 mem 0xfe980000-0xfe9fffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci1: on pcib3 re0: port 0xc800-0xc8ff mem 0xfdeff000-0xfdefffff,0xfdef8000-0xfdefbfff irq 17 at device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:25:22:35:67:8f re0: [FILTER] uhci0: port 0xb400-0xb41f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb480-0xb49f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 uhci3: port 0xb880-0xb89f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3: on uhci3 ehci0: mem 0xfe977c00-0xfe977fff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib4: at device 30.0 on pci0 pci3: on pcib4 pci3: at device 1.0 (no driver attached) pci3: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0xb080-0xb087,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa80f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 acd0: CDROM at ata0-master UDMA33 ad6: 715404MB at ata3-master UDMA100 SATA ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 GEOM: ad6: geometry does not match label (255h,63s != 16h,63s). SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! GEOM: ad6s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad6s1a GEOM: ad6: geometry does not match label (255h,63s != 16h,63s). GEOM: ad6: geometry does not match label (255h,63s != 16h,63s). ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 uhid0: on usbus3 epair0a: Ethernet address: 02:c0:64:00:06:0a epair0b: Ethernet address: 02:c0:64:00:07:0b epair1a: Ethernet address: 02:c0:64:00:08:0a epair1b: Ethernet address: 02:c0:64:00:09:0b bridge0: Ethernet address: ae:82:95:1d:28:52 re0: link state changed to UP Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. --Boundary-00=_Af24MOlSd6d3t6h-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 06:00:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01D4F106566B; Wed, 17 Nov 2010 06:00:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 052508FC17; Wed, 17 Nov 2010 06:00:09 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 56FEA41C6DB; Wed, 17 Nov 2010 07:00:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Y9KXxZ-ykPnq; Wed, 17 Nov 2010 07:00:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5C48B41C690; Wed, 17 Nov 2010 07:00:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 24A584448F3; Wed, 17 Nov 2010 05:57:53 +0000 (UTC) Date: Wed, 17 Nov 2010 05:57:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Thierry Herbelot In-Reply-To: <201011170627.28025.thierry.herbelot@free.fr> Message-ID: <20101117055208.S24596@maildrop.int.zabbadoz.net> References: <201011170627.28025.thierry.herbelot@free.fr> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current , FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD virtualization mailing 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, 17 Nov 2010 06:00:25 -0000 On Wed, 17 Nov 2010, Thierry Herbelot wrote: Hi, first of all freebsd-virtualization@ is the better list for this; Cc:ed. > We are using FreeBSD + VIMAGE at work, and we have seen an annoying problem : > there seems to be a memory leak in the kernel, which eventually causes a > panic. > > (yes, we have seen the following message : "WARNING: VIMAGE (virtualized > network stack) is a highly experimental feature.") > > Configuring a network interface in a jail with vnet enabled, then removing > that jail causes these messages. In dmesg: > > [...] > Freed UMA keg was not empty (203 items). Lost 1 pages of memory. > Freed UMA keg was not empty (36 items). Lost 2 pages of memory. > > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled (with > attached VIMAGE kernel config file). > > The following commands reproduce the bug: > > jail -l -u root -c path=/ name=foo persist vnet && > jexec foo ifconfig lo0 127.0.0.1/8 && > jail -r foo > > Running it too many times exhausts kernel memory and crashes the machine. > > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN -head. The problem has been present since day 1 and is still present up to HEAD. This is about type stability and teardown. So far we are no able to actually free TCP (and UDP in SVN) states as they might still be accesses after "free". It's a general problem in the network stack and has been implemented as a measure to circumvent panics in those cases. I am not sure if that's actually what's biting you wrt to memory or if it's something else. Unfortunately boot logs and kernel configs don't help much; enable ddb and get show uma and show malloc reports after the crash (or watch vmstat -z and vmstat -m) after every 50 jail restarts. I might have some patches for a couple of things but cannot (yet) help with the additional (duplicate) UMA zones showing up at each iteration (for the -z case). /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 06:26:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CA1106564A for ; Wed, 17 Nov 2010 06:26:19 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id B8B9B8FC14 for ; Wed, 17 Nov 2010 06:26:18 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 44A6B7E84A for ; Wed, 17 Nov 2010 17:26:16 +1100 (EST) Message-ID: <4CE37587.6020705@freebsd.org> Date: Wed, 17 Nov 2010 17:26:15 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101117 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CDD0A71.7020708@freebsd.org> In-Reply-To: <4CDD0A71.7020708@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Subject: Re: [HEADS UP] Significant TCP work committed to head - VIMAGE users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 06:26:19 -0000 On 11/12/10 20:35, Lawrence Stewart wrote: > Hi All, > > A quick note that this evening, I made the first in a series of upcoming > commits to head that modify the TCP stack fairly significantly. I have > no reason to believe you'll notice any issues, but TCP is a complex > beast and it's possible things might crop up. The changes are mostly > related to congestion control, so the sorts of issues that are likely to > crop up if any will most probably be subtle and difficult to even > detect. The first svn revision in question is r215166. The next few > commits I plan to make will be basically zero impact and then another > significant patch will follow in a few weeks. > > If you bump into an issue that you think might be related to this work, > please roll back r215166 from your tree and attempt to reporoduce before > reporting the problem. Please CC me directly with your problem report > and post to freebsd-current@ or freebsd-net@ as well. > > Lots more information about what all this does and how to use it will be > following in the coming weeks, but in the meantime, just keep this note > in the back of your mind. For the curious, some information about the > project is available at [1,2]. > > Cheers, > Lawrence > > [1] http://caia.swin.edu.au/freebsd/5cc/ > [2] > http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD For any VIMAGE users running head, please note that r215166 overlooked some important VIMAGE related issues and actually triggers a kernel panic when the first vnet is brought up (see [3] for details). Please ensure you update to r215395 or later to ensure you have all the patches I committed to address the VIMAGE deficiencies in the original r215166 commit. Cheers, Lawrence [3] http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022381.html From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 06:30:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDB2B106566B for ; Wed, 17 Nov 2010 06:30:08 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by mx1.freebsd.org (Postfix) with ESMTP id C9D9B8FC14 for ; Wed, 17 Nov 2010 06:30:05 +0000 (UTC) Received: from mail.herbelot.nom (unknown [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0FDA38224B; Wed, 17 Nov 2010 07:30:00 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id oAH6TlFe020404; Wed, 17 Nov 2010 07:29:48 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org, FreeBSD virtualization mailing list , "Bjoern A. Zeeb" Date: Wed, 17 Nov 2010 07:29:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; amd64; ; ) References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> In-Reply-To: <20101117055208.S24596@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201011170729.41894.thierry.herbelot@free.fr> Cc: Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 06:30:08 -0000 "Bjoern A. Zeeb" a =E9crit > On Wed, 17 Nov 2010, Thierry Herbelot wrote: >=20 > Hi, >=20 > first of all freebsd-virtualization@ is the better list for this; Cc:ed. (in fact, I did not know where else to send this message : -net, ... ? than= ks=20 for the CC) >=20 > > We are using FreeBSD + VIMAGE at work, and we have seen an annoying > > problem : there seems to be a memory leak in the kernel, which > > eventually causes a panic. > >=20 > > (yes, we have seen the following message : "WARNING: VIMAGE (virtualized > > network stack) is a highly experimental feature.") > >=20 > > Configuring a network interface in a jail with vnet enabled, then > > removing that jail causes these messages. In dmesg: > >=20 > > [...] > > Freed UMA keg was not empty (203 items). Lost 1 pages of memory. > > Freed UMA keg was not empty (36 items). Lost 2 pages of memory. > >=20 > > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled > > (with attached VIMAGE kernel config file). > >=20 > > The following commands reproduce the bug: > >=20 > > jail -l -u root -c path=3D/ name=3Dfoo persist vnet && > > jexec foo ifconfig lo0 127.0.0.1/8 && > > jail -r foo > >=20 > > Running it too many times exhausts kernel memory and crashes the machin= e. > >=20 > > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN > > -head. >=20 > The problem has been present since day 1 and is still present up to > HEAD. This is about type stability and teardown. So far we are no > able to actually free TCP (and UDP in SVN) states as they might still > be accesses after "free". It's a general problem in the network stack > and has been implemented as a measure to circumvent panics in those > cases. >=20 > I am not sure if that's actually what's biting you wrt to memory or > if it's something else. Unfortunately boot logs and kernel configs > don't help much; enable ddb and get show uma and show malloc reports > after the crash (or watch vmstat -z and vmstat -m) after every 50 jail > restarts. I might have some patches for a couple of things but cannot > (yet) help with the additional (duplicate) UMA zones showing up at > each iteration (for the -z case). The context for our problem is that VIMAGE jails are mant to be used "in=20 production" for automated tests, thus are likely to be multiple on one=20 physical host, and are likely to be started and stopped according to our=20 needs. We have tried more "classical" virtualization solutions (qemu, kvm, ... ,=20 normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems = to=20 be the correct answer. (for other reasons, an i386 version of the kernel mu= st=20 be used) The point of my original email was to simplify the configuration for a test= =20 setup : any machine with the attached configuration file and the above=20 sequence of commands creating and deleting jails, running in a loop, will=20 eventually panic. Anyway, I will follow up with the logs you mentioned. Cheers (and thanks for the quick feedback) Thierry Herbelot >=20 > /bz From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 07:27:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 842301065674 for ; Wed, 17 Nov 2010 07:27:00 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9F18FC1B for ; Wed, 17 Nov 2010 07:26:59 +0000 (UTC) Received: by gwj20 with SMTP id 20so971132gwj.13 for ; Tue, 16 Nov 2010 23:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=YrRaEkGsSmo0ipD05FlGCpv3i1VUtXy+UDx2vi4bsFU=; b=xXDe+wcZwEpGGxSmS7nevRrk7OAMm9EsSlpyalwZmqvrUirMqosT5OA3Q+a64s9UIo UgV+vgv0frs6fFzN2uux5ma+xw/Jo8iApQnGlVsSwncP1JKWF++w5D/IUYCZNqBTFZRv bdSX19N4wxrLpu13lYYbkZaWc9QUNr2XlstYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=stGtOXJ+GYeMGy1XTVGFPDhY1E3AVe5oRp6n9YFgRI1vhqt8GZg7YCoiB4GFyHsfLE PFcmO+ZcHomjdD2Mb3P9vq/glOI0NlIxCDCxQtvoRlRapxzdKD4lFR870Ez28Mo8OqFe 7IsE+iqXBmyrH0tDAuU0+QFPirrpT9HcteoGo= Received: by 10.150.190.20 with SMTP id n20mr13440437ybf.275.1289978819468; Tue, 16 Nov 2010 23:26:59 -0800 (PST) Received: from localhost ([85.17.254.135]) by mx.google.com with ESMTPS id o10sm1410124yha.27.2010.11.16.23.26.53 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 23:26:58 -0800 (PST) From: Anonymous To: Xin LI References: <4CC62413.50703@delphij.net> Date: Wed, 17 Nov 2010 10:26:38 +0300 Message-ID: <861v6kwgup.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: FreeBSD Current Subject: Re: [PATCH] top(1) inverse display of table header X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 07:27:00 -0000 --=-=-= Content-Type: text/plain Xin LI writes: > Hi, > > Here is a patch that makes top(1) to inverse its table header (PID > USERNAME THR, etc). > That MAX_COLS change in it makes `top -b' produce too much extra whitespace that's not trimmed and spans several lines, e.g. $ stty -a | sed 1q speed 38400 baud; 57 rows; 79 columns; $ top -b last pid: 54799; load averages: 1.90, 2.16, 2.16 up 0+04:28:34 10:18:15 91 processes: 4 running, 85 sleeping, 2 stopped Mem: 540M Active, 243M Inact, 2934M Wired, 79M Cache, 417M Buf, 136M Free Swap: 4097M Total, 8856K Used, 4088M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1730 holo 14 46 0 358M 197M ucond 1 1:24 0.00% firefox-bin FYI, using inverse color for header line can also be achieved on top-3.8b1 without touching source at all $ export TOPCOLORS='header=,#7' edwin@ planned to update top(1) but stalled, not sure why. http://docs.freebsd.org/cgi/mid.cgi?20080928054620.GA80250 And I for one still use his branch with below diff. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=top-3.8b1.diff Content-Description: local hacks for top-3.8b1 against svn://svn.freebsd.org/base/user/edwin/top/top-3.8b1 - cherry-pick changes from /head (r189626, r200979, r211419) - report realtime priority like /head - lower min_screenwidth for FLG field, for 80 col tty sake - use int type for counter - fix amd64/i386 cross-compilation - remove `-g', prefer DEBUG_FLAGS - abbreviate Kern/Kernel row like Mem/Memory - adjust whitespace --- Index: contrib/top/display.c =================================================================== --- contrib/top/display.c (revision 215416) +++ contrib/top/display.c (working copy) @@ -993,7 +993,6 @@ if (*bt != -1) { uptime = *tod - *bt; - uptime += 30; uptime_days = uptime / 86400; tm = gmtime(&uptime); @@ -1312,7 +1311,7 @@ } /* - * *_kernel(stats) - print "Kernel: " followed by the kernel summary string + * *_kernel(stats) - print "Kern: " followed by the kernel summary string * * Assumptions: cursor is on "lastline", the previous line */ @@ -1323,7 +1322,7 @@ { if (num_kernel > 0) { - display_write(0, y_kernel, 0, 0, "Kernel: "); + display_write(0, y_kernel, 0, 0, "Kern: "); /* format and print the kernel summary */ summary_format(x_kernel, y_kernel, stats, kernel_names, kernel_cidx); Index: contrib/top/username.c =================================================================== --- contrib/top/username.c (revision 215416) +++ contrib/top/username.c (working copy) @@ -53,7 +53,6 @@ #include #include -#include #include "top.h" #include "utils.h" @@ -72,7 +71,7 @@ struct hash_data { int uid; - char name[UT_NAMESIZE + 1]; /* big enough? */ + char name[MAXLOGNAME]; /* big enough? */ time_t expire; }; @@ -120,7 +119,7 @@ { if ((pw = getpwuid(uid)) != NULL) { - strncpy(data->name, pw->pw_name, UT_NAMESIZE); + strncpy(data->name, pw->pw_name, MAXLOGNAME - 1); data->expire = now + EXPIRETIME; dprintf("username: updating %d with %s, expires %d\n", data->uid, data->name, data->expire); Index: contrib/top/hash.c =================================================================== --- contrib/top/hash.c (revision 215416) +++ contrib/top/hash.c (working copy) @@ -99,7 +99,7 @@ next_prime(int x) { - double i, j; + int i, j; int f; i = x; @@ -108,7 +108,7 @@ f=1; for (j=2; j ${.TARGET} CLEANFILES+= config.h -CPU!= uname -m config.h: config.h.in @${ECHO} Making ${.TARGET} from ${.ALLSRC:T} sed \ @@ -55,7 +55,7 @@ -e 's/@DEFAULT_DELAY@/2/' \ -e 's/@HAVE_GETOPT_LONG@/1/' \ -e 's/@ENABLE_KILL@/1/' \ - -e "s/@CPU@/${CPU}/" \ + -e "s/@CPU@/${MACHINE}/" \ < ${.ALLSRC} > ${.TARGET} CLEANFILES+= top.1.local --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 08:06:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FC0B1065693 for ; Wed, 17 Nov 2010 08:06:33 +0000 (UTC) (envelope-from villa.alberto@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 AFB498FC13 for ; Wed, 17 Nov 2010 08:06:32 +0000 (UTC) Received: by qwd7 with SMTP id 7so529365qwd.13 for ; Wed, 17 Nov 2010 00:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=XDEN/bn7bxjiDrzeWg8oaM4+YUrdh13XXf1MDS8QfjI=; b=VzFcW7TMADGvHFAMITXF3LN/xMruV9bzh/VmQSvputPn+LdMCwtF10zZu/2vqLdcIW Bn3c5CTZ2vYCBUbhDTMoL3iFF2up716CegJIzlj0u9ulehhkFllM+GJJtKeIlDd5gkuV VNjVMqGDMsaHRsVIN5wq0bNqW/tPQwZebcsb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=igjZxiXnrrBUr1k+NnCtpjx7Cm9FEvDE7iJufFj7ile5sFYgvYVSfXDRt/T3flm/Y7 f33/k0ds07ghHJIYPTvOa0XfwKX1dNPYJsh+HRwhrTXIa4YVferFKf2pDE4RiHVXZpmK VBhjNl+wgRCOyJxmjBkBqGmHV3m6WAUTS00Cw= Received: by 10.224.212.72 with SMTP id gr8mr7321799qab.157.1289981191373; Wed, 17 Nov 2010 00:06:31 -0800 (PST) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.220.195.68 with HTTP; Wed, 17 Nov 2010 00:06:11 -0800 (PST) In-Reply-To: References: <20101025080705.GA33315@current.Sisis.de> From: Alberto Villa Date: Wed, 17 Nov 2010 00:06:11 -0800 X-Google-Sender-Auth: m440PKfnL6_pmdwARZ_k2GNaPe4 Message-ID: To: Paul B Mahol Content-Type: multipart/mixed; boundary=20cf300fb1b7adc5b904953b2675 Cc: freebsd-current@freebsd.org Subject: Re: Broadcom BCM4310 USB Controller (Wifi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 08:06:33 -0000 --20cf300fb1b7adc5b904953b2675 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 15, 2010 at 2:41 PM, Paul B Mahol wrote: > Feel free to test code at: > > gitorious.org/NDISulator > github.com/richardpl/NDISulator > > The code is developed on CURRENT. But with small changes it can be > compiled on STABLE too. thanks! i've applied a checkout of last night to current. i can load the module after boot, but the panic is still there when i unload or load on boot, and wpa_supplicant fails to work (see attached log) > Just now I have only one tester (and that is without counting me). consider me as the third one :) -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla --20cf300fb1b7adc5b904953b2675 Content-Type: application/octet-stream; name="ndis.log" Content-Disposition: attachment; filename="ndis.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gglvbn650 SW5pdGlhbGl6aW5nIGludGVyZmFjZSAnd2xhbjAnIGNvbmYgJy9ldGMvd3BhX3N1cHBsaWNhbnQu Y29uZicgZHJpdmVyICduZGlzJyBjdHJsX2ludGVyZmFjZSAnTi9BJyBicmlkZ2UgJ04vQScKQ29u ZmlndXJhdGlvbiBmaWxlICcvZXRjL3dwYV9zdXBwbGljYW50LmNvbmYnIC0+ICcvZXRjL3dwYV9z dXBwbGljYW50LmNvbmYnClJlYWRpbmcgY29uZmlndXJhdGlvbiBmaWxlICcvZXRjL3dwYV9zdXBw bGljYW50LmNvbmYnCmN0cmxfaW50ZXJmYWNlPScvdmFyL3J1bi93cGFfc3VwcGxpY2FudCcKZWFw b2xfdmVyc2lvbj0xCmFwX3NjYW49MQpmYXN0X3JlYXV0aD0xCkxpbmU6IDczNyAtIHN0YXJ0IG9m IGEgbmV3IG5ldHdvcmsgYmxvY2sKa2V5X21nbXQ6IDB4NApMaW5lOiA3NDEgLSBzdGFydCBvZiBh IG5ldyBuZXR3b3JrIGJsb2NrCnNzaWQgLSBoZXhkdW1wX2FzY2lpKGxlbj0xMik6CiAgICAgNTMg NjEgNmMgNjUgNmQgMjAgNDMgNjUgNmUgNzQgNjUgNzIgICAgICAgICAgICAgICBTYWxlbSBDZW50 ZXIgICAgClBTSyAoQVNDSUkgcGFzc3BocmFzZSkgLSBoZXhkdW1wX2FzY2lpKGxlbj02Myk6IFtS RU1PVkVEXQpQU0sgKGZyb20gcGFzc3BocmFzZSkgLSBoZXhkdW1wKGxlbj0zMik6IFtSRU1PVkVE XQpQcmlvcml0eSBncm91cCAwCiAgIGlkPTAgc3NpZD0nJwogICBpZD0xIHNzaWQ9J1NhbGVtIENl bnRlcicKTkRJUzogUGFja2V0LmRsbCB2ZXJzaW9uOiBGcmVlQlNEIFdpblBjYXAgY29tcGF0aWJp bGl0eSBzaGltIHYxLjAKTkRJUzogMSBhZGFwdGVyIG5hbWVzIGZvdW5kCk5ESVM6IDEgYWRhcHRl ciBkZXNjcmlwdGlvbnMgZm91bmQKTkRJUzogMCAtIHdsYW4wIC0gd2xhbjAKTkRJUzogQWRhcHRl ciBkZXNjcmlwdGlvbiBwcmVmaXggJ3dsYW4wJwpuZGlzX2dldF9vaWQ6IG9pZD0weDEwMTAxMDIg bGVuICg2KSBmYWlsZWQKTkRJUzogR2V0IE9JRF84MDJfM19DVVJSRU5UX0FERFJFU1MgZmFpbGVk CkZhaWxlZCB0byBpbml0aWFsaXplIGRyaXZlciBpbnRlcmZhY2UKRmFpbGVkIHRvIGFkZCBpbnRl cmZhY2Ugd2xhbjAKQ2FuY2VsbGluZyBzY2FuIHJlcXVlc3QKQ2FuY2VsbGluZyBhdXRoZW50aWNh dGlvbiB0aW1lb3V0Cg== --20cf300fb1b7adc5b904953b2675-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 09:31:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12AAD1065670 for ; Wed, 17 Nov 2010 09:31:32 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BDAE98FC17 for ; Wed, 17 Nov 2010 09:31:30 +0000 (UTC) Received: by qwd7 with SMTP id 7so597930qwd.13 for ; Wed, 17 Nov 2010 01:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=Kstb0UdBZ8lGywLWi/SazAf2TPIjXrHi/SDU6Ieqzag=; b=WD9lMFGgrVMImwDWCqZwAvUmbpNWzVmZWgl2djiA8MwkGd0hbD+bqcM2hZZYSJ7rhy b0YMiDyTK4bYC1EJyYyAJO53eDbVxiXH/EjAuSxRBOkzTsLhWlsBJoVrLZwstB2rHQcU vgvTa32RAy8FXNGGbgG2fOz5usyfLVpn6mKsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=YxvhM4gTeiDfDf3HNXxEZNYGtHxh5HkyyeISpJmC+9BphO2FpGU6IU5gK4GKTq8d/6 8E7fN6aSXgskBFSuwZMZHGErPIyL66J2Kc18CPxjdyhjG32p0W0J3sqy82ZCxZvZN+AD qqX0+55cRIAUODlXnvr5gXVGQbNLva2PUa6lI= Received: by 10.229.70.130 with SMTP id d2mr7354987qcj.53.1289986290115; Wed, 17 Nov 2010 01:31:30 -0800 (PST) Received: from localhost (anonymous-relay.omegamicro.net [216.86.61.205]) by mx.google.com with ESMTPS id k15sm1419103qcu.11.2010.11.17.01.31.28 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Nov 2010 01:31:29 -0800 (PST) From: Anonymous To: Xin LI References: <4CC62413.50703@delphij.net> <861v6kwgup.fsf@gmail.com> Date: Wed, 17 Nov 2010 12:31:15 +0300 In-Reply-To: <861v6kwgup.fsf@gmail.com> (Anonymous's message of "Wed, 17 Nov 2010 10:26:38 +0300") Message-ID: <86oc9othy4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: FreeBSD Current Subject: Re: [PATCH] top(1) inverse display of table header X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 09:31:32 -0000 Anonymous writes: > Xin LI writes: > >> Hi, >> >> Here is a patch that makes top(1) to inverse its table header (PID >> USERNAME THR, etc). >> > > That MAX_COLS change in it makes `top -b' produce too much extra > whitespace that's not trimmed and spans several lines, e.g. > > $ stty -a | sed 1q > speed 38400 baud; 57 rows; 79 columns; > $ top -b > last pid: 54799; load averages: 1.90, 2.16, 2.16 up 0+04:28:34 10:18:15 > 91 processes: 4 running, 85 sleeping, 2 stopped > > Mem: 540M Active, 243M Inact, 2934M Wired, 79M Cache, 417M Buf, 136M Free > Swap: 4097M Total, 8856K Used, 4088M Free > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1730 holo 14 46 0 358M 197M ucond 1 1:24 0.00% firefox-bin A more illustrative screenshot, whitespace is selected http://img201.imageshack.us/img201/4484/17763882.png Workaround is to revert r214857. From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 09:57:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 165391065670; Wed, 17 Nov 2010 09:57:37 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id 74E5B8FC0A; Wed, 17 Nov 2010 09:57:36 +0000 (UTC) Received: by wwb17 with SMTP id 17so1730690wwb.8 for ; Wed, 17 Nov 2010 01:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/wOhpwzwzi5GrQxUlOg00gM/WcEIfw2LZlTxxXimMoI=; b=C/HS4t9pe8SS4tMqPZ8jccPIpwHXmozbh7e6FvhPU6VRaibRKC0DeNW614eTb1L5RO YpWc2xb22fx6OjjI7MQXiIXeRWyh7hCRE99r8EkXUo/4RpiUWWJVX2J9QhLXWfGSmby1 tou6QvKfiqWLP2pWxM+dhwQTqp2EirSixXjco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x6MpR+pvEwK4SBnu+EjvoUpq9Qs4lwYHkQCOOlOjx79Z7S7elLOM6tAf03i437xeuF rrucfEGxJm/t2AZ/DNHl5s8MuDvV14X98gBimGq4F1OaLM3m+Ch/R+4IcCQ0K1a9ObTi f3azwU4XGFWa05kNMufiesHyfZfNl0zVGJmFc= MIME-Version: 1.0 Received: by 10.216.172.149 with SMTP id t21mr7440893wel.62.1289987854270; Wed, 17 Nov 2010 01:57:34 -0800 (PST) Received: by 10.216.234.82 with HTTP; Wed, 17 Nov 2010 01:57:34 -0800 (PST) In-Reply-To: References: <20101025080705.GA33315@current.Sisis.de> Date: Wed, 17 Nov 2010 09:57:34 +0000 Message-ID: From: Paul B Mahol To: Alberto Villa Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Broadcom BCM4310 USB Controller (Wifi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 09:57:37 -0000 On 11/17/10, Alberto Villa wrote: > On Mon, Nov 15, 2010 at 2:41 PM, Paul B Mahol wrote: >> Feel free to test code at: >> >> gitorious.org/NDISulator >> github.com/richardpl/NDISulator >> >> The code is developed on CURRENT. But with small changes it can be >> compiled on STABLE too. > > thanks! > i've applied a checkout of last night to current. i can load the > module after boot, but the panic is still there when i unload or load > on boot, and wpa_supplicant fails to work (see attached log) > >> Just now I have only one tester (and that is without counting me). > > consider me as the third one :) Please use ndis5 branch. master branch is in heavy development. CURRENT branch just blindly (and badly) track code on FreeBSD CURRENT. When you say what you did be more specific, like are you are using i386 or amd64, and so on. When testing, enable debug.bootverbose, and debug.ndis sysctl before loading miniport module. [miniport module is module you created with ndisgen(8)] Do not load miniport module(s) during boot(from loader), if it ever worked it was big luck. [Even on Windows, drivers are loaded after boot.] Actually drivers can be loaded but we must be extra carefull what to call during boot and what to call after boot. For using code in branch master and ndis5, you will need to reinstall ndisgen and ndiscvt from git repo and do not use one from FreeBSD world. This also means you will need to regenerate miniport module with new ndiscvt & ndisgen because interface have changed slightly. From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 12:57:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0712E1065694; Wed, 17 Nov 2010 12:57:17 +0000 (UTC) (envelope-from zec@icir.org) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by mx1.freebsd.org (Postfix) with ESMTP id 8882F8FC17; Wed, 17 Nov 2010 12:57:16 +0000 (UTC) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 13:45:11 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 13:45:10 +0100 From: Marko Zec To: freebsd-virtualization@freebsd.org Date: Wed, 17 Nov 2010 13:45:06 +0100 User-Agent: KMail/1.9.10 References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> In-Reply-To: <20101117055208.S24596@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201011171345.06789.zec@icir.org> X-OriginalArrivalTime: 17 Nov 2010 12:45:11.0037 (UTC) FILETIME=[45BA4AD0:01CB8655] Cc: Thierry Herbelot , "Bjoern A. Zeeb" , freebsd-current Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 12:57:17 -0000 On Wednesday 17 November 2010 06:57:53 Bjoern A. Zeeb wrote: > On Wed, 17 Nov 2010, Thierry Herbelot wrote: > > Hi, > > first of all freebsd-virtualization@ is the better list for this; Cc:ed. > > > We are using FreeBSD + VIMAGE at work, and we have seen an annoying > > problem : there seems to be a memory leak in the kernel, which eventually > > causes a panic. > > > > (yes, we have seen the following message : "WARNING: VIMAGE (virtualized > > network stack) is a highly experimental feature.") > > > > Configuring a network interface in a jail with vnet enabled, then > > removing that jail causes these messages. In dmesg: > > > > [...] > > Freed UMA keg was not empty (203 items). Lost 1 pages of memory. > > Freed UMA keg was not empty (36 items). Lost 2 pages of memory. > > > > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled > > (with attached VIMAGE kernel config file). > > > > The following commands reproduce the bug: > > > > jail -l -u root -c path=/ name=foo persist vnet && > > jexec foo ifconfig lo0 127.0.0.1/8 && > > jail -r foo > > > > Running it too many times exhausts kernel memory and crashes the machine. > > > > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN > > -head. > > The problem has been present since day 1 and is still present up to > HEAD. This is about type stability and teardown. So far we are no > able to actually free TCP (and UDP in SVN) states as they might still > be accesses after "free". It's a general problem in the network stack > and has been implemented as a measure to circumvent panics in those > cases. Actually, we never seriously discussed or revisited the issue with separate UMA pools for each vnet instance. My original motivation when O introduced separate UMA pools was primarily in making it easier to spot resource leaks, and to prove the correctness of the whole VIMAGE / VNET thing. Having more or less achieved those goals, perhaps the time has come to move on. Having said that, and given that the current VIMAGE resource allocation model is far from being optimal (a lot of memory sits reserved but 99% unused, and cannot be reclaimed later on vnet teardown), perhaps it's time that we reconsider using unified UMA pools. Note that the original VIMAGE prototype on FreeBSD 4.x from 2002 or 2003 used (mostly) unified memory zones, so there's no technical reason why this couldn't work again in FreeBSD current or 8-stable. Cheers, Marko > I am not sure if that's actually what's biting you wrt to memory or > if it's something else. Unfortunately boot logs and kernel configs > don't help much; enable ddb and get show uma and show malloc reports > after the crash (or watch vmstat -z and vmstat -m) after every 50 jail > restarts. I might have some patches for a couple of things but cannot > (yet) help with the additional (duplicate) UMA zones showing up at > each iteration (for the -z case). > > /bz From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 15:08:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4874C106564A; Wed, 17 Nov 2010 15:08:45 +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 0CC9F8FC1C; Wed, 17 Nov 2010 15:08:45 +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 A549C46B0C; Wed, 17 Nov 2010 10:08:44 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 771388A009; Wed, 17 Nov 2010 10:08:43 -0500 (EST) From: John Baldwin To: Alexander Best Date: Wed, 17 Nov 2010 10:06:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101109114612.GA58585@freebsd.org> <201011101717.51062.jhb@freebsd.org> <20101117032012.GA93866@freebsd.org> In-Reply-To: <20101117032012.GA93866@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011171006.10486.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 17 Nov 2010 10:08:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 15:08:45 -0000 On Tuesday, November 16, 2010 10:20:12 pm Alexander Best wrote: > On Wed Nov 10 10, John Baldwin wrote: > > On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > > > On Wed Nov 10 10, Alexander Best wrote: > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > > > hi there, > > > > > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > > > the second attempt). > > > > > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > > > loaded. > > > > > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > > > > > Id Refs Address Size Name > > > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > > > to the description in kldunload(2). > > > > > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > > > after boot? > > > > > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > > > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > > > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > > > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > > > 3 for netgraph.ko and i get the behavior i described beforehand. > > > > Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually > > loading any other netgraph modules so that nothing is loaded magically as a > > dependency) and see what behavior that gives you. > > sorry it took me a while to check this out. i did some more research and it > seems a few things are broken: > > 1) i have snd_hda in my loader.conf which will load sound as a dependency. > unloading snd_hda should then automatically unload sound, which it *doesn't*. > i need to unload sound manually. I clearly said earlier that this is what happens. It's the paragraph below where I said that the kernel has no idea when it discovers the modules that the loader loaded which ones were explicit and which ones were implicit. It treats them all as explicit. > > 2) if i unload all ng_* modules i should then be able to also unload netgraph, > because no dependencies are left. however kldunload fails with EBUSY! Perhaps netgraph.ko is not unloadable in general? Actually, that is exactly what it does: case MOD_UNLOAD: /* You can't unload it because an interface may be using it. */ error = EBUSY; break; (from ng_base.c). > > When you load modules from the loader, they and all their dependencies are > > treated as if you had manually loaded them similar to kldload. This because > > the kernel can't determine which modules loaded by the loader were silent > > dependencies. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 17:11:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C6D9210658FE; Wed, 17 Nov 2010 17:11:54 +0000 (UTC) Date: Wed, 17 Nov 2010 17:11:54 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101117171154.GA1398@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <201011101717.51062.jhb@freebsd.org> <20101117032012.GA93866@freebsd.org> <201011171006.10486.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011171006.10486.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 17:11:54 -0000 On Wed Nov 17 10, John Baldwin wrote: > On Tuesday, November 16, 2010 10:20:12 pm Alexander Best wrote: > > On Wed Nov 10 10, John Baldwin wrote: > > > On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > > > > On Wed Nov 10 10, Alexander Best wrote: > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > > > > hi there, > > > > > > > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > > > > the second attempt). > > > > > > > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > > > > loaded. > > > > > > > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > > > > > > > Id Refs Address Size Name > > > > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > > > > to the description in kldunload(2). > > > > > > > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > > > > after boot? > > > > > > > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > > > > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > > > > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > > > > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > > > > 3 for netgraph.ko and i get the behavior i described beforehand. > > > > > > Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually > > > loading any other netgraph modules so that nothing is loaded magically as a > > > dependency) and see what behavior that gives you. i did some more research regarding this matter: 1) DEPENDENCIES: netgraph => X (none) ng_ubt => ng_hci ng_hci => ng_bluetooth ng_buetooth => X (none; [no not even netgraph]) 2) VARIOUS results: ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 ** ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 (obvious, since ng_bluetooth doesn't depend on netgraph) ** ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 kldload ng_hci => REF_COUNT_NETGRAPH = 2 kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 [1] ** ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 kldload ng_hci => REF_COUNT_NETGRAPH = 2 kldload ng_ubt => REF_COUNT_NETGRAPH = 3 kldunload netgraph => OK, REF_COUNT_NETGRAPH = 2 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] ** ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 kldload ng_hci => REF_COUNT_NETGRAPH = 2 kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 [1] kldload ng_ubt => REF_COUNT_NETGRAPH = 2 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] ** ** kldload netgraph => REF_COUNT_NETGRAPH = 1 kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 kldload ng_hci => REF_COUNT_NETGRAPH = 2 kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 kldload ng_ubt => REF_COUNT_NETGRAPH = 2 kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] ** [1] before EBUSY gets returned i see a notice that netgraph.ko cannot be unloaded, since it was loaded by the kernel. this doesn't happen in the last two cases. > > > > sorry it took me a while to check this out. i did some more research and it > > seems a few things are broken: > > > > 1) i have snd_hda in my loader.conf which will load sound as a dependency. > > unloading snd_hda should then automatically unload sound, which it *doesn't*. > > i need to unload sound manually. > > I clearly said earlier that this is what happens. It's the paragraph below > where I said that the kernel has no idea when it discovers the modules that > the loader loaded which ones were explicit and which ones were implicit. It > treats them all as explicit. i'm really sorry. i completely forgot about that fact. so to make this easy for me to finally comprehend: if a module is loaded via loader.conf *no* implicit dependencies are present and unloading a module from a chain that got triggered by loader.conf will *never* unload anything except that one module i specified! > > > > 2) if i unload all ng_* modules i should then be able to also unload netgraph, > > because no dependencies are left. however kldunload fails with EBUSY! > > Perhaps netgraph.ko is not unloadable in general? Actually, that is exactly what > it does: > > case MOD_UNLOAD: > /* You can't unload it because an interface may be using it. */ > error = EBUSY; > break; > > (from ng_base.c). > > > > When you load modules from the loader, they and all their dependencies are > > > treated as if you had manually loaded them similar to kldload. This because > > > the kernel can't determine which modules loaded by the loader were silent > > > dependencies. > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 18:36:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A1F1065673; Wed, 17 Nov 2010 18:36:34 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by mx1.freebsd.org (Postfix) with ESMTP id 486C48FC13; Wed, 17 Nov 2010 18:36:30 +0000 (UTC) Received: from mail.herbelot.nom (unknown [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5BA83822F6; Wed, 17 Nov 2010 19:36:24 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id oAHIaGu9018073; Wed, 17 Nov 2010 19:36:16 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 17 Nov 2010 19:36:10 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; amd64; ; ) References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> <201011170729.41894.thierry.herbelot@free.fr> In-Reply-To: <201011170729.41894.thierry.herbelot@free.fr> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_aCC5MxDID7T1Y5x" Message-Id: <201011171936.10764.thierry.herbelot@free.fr> Cc: "Bjoern A. Zeeb" , FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 18:36:34 -0000 --Boundary-00=_aCC5MxDID7T1Y5x Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thierry Herbelot a =E9crit > "Bjoern A. Zeeb" a =E9crit >=20 > > On Wed, 17 Nov 2010, Thierry Herbelot wrote: > >=20 > > Hi, > >=20 > > first of all freebsd-virtualization@ is the better list for this; Cc:ed. >=20 > (in fact, I did not know where else to send this message : -net, ... ? > thanks for the CC) >=20 > > > We are using FreeBSD + VIMAGE at work, and we have seen an annoying > > > problem : there seems to be a memory leak in the kernel, which > > > eventually causes a panic. > > >=20 > > > (yes, we have seen the following message : "WARNING: VIMAGE > > > (virtualized network stack) is a highly experimental feature.") > > >=20 > > > Configuring a network interface in a jail with vnet enabled, then > > > removing that jail causes these messages. In dmesg: > > >=20 > > > [...] > > > Freed UMA keg was not empty (203 items). Lost 1 pages of memory. > > > Freed UMA keg was not empty (36 items). Lost 2 pages of memory. > > >=20 > > > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled > > > (with attached VIMAGE kernel config file). > > >=20 > > > The following commands reproduce the bug: > > >=20 > > > jail -l -u root -c path=3D/ name=3Dfoo persist vnet && > > > jexec foo ifconfig lo0 127.0.0.1/8 && > > > jail -r foo > > >=20 > > > Running it too many times exhausts kernel memory and crashes the > > > machine. > > >=20 > > > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN > > > -head. > >=20 > > The problem has been present since day 1 and is still present up to > > HEAD. This is about type stability and teardown. So far we are no > > able to actually free TCP (and UDP in SVN) states as they might still > > be accesses after "free". It's a general problem in the network stack > > and has been implemented as a measure to circumvent panics in those > > cases. > >=20 > > I am not sure if that's actually what's biting you wrt to memory or > > if it's something else. Unfortunately boot logs and kernel configs > > don't help much; enable ddb and get show uma and show malloc reports > > after the crash (or watch vmstat -z and vmstat -m) after every 50 jail > > restarts. I might have some patches for a couple of things but cannot > > (yet) help with the additional (duplicate) UMA zones showing up at > > each iteration (for the -z case). >=20 > The context for our problem is that VIMAGE jails are mant to be used "in > production" for automated tests, thus are likely to be multiple on one > physical host, and are likely to be started and stopped according to our > needs. >=20 > We have tried more "classical" virtualization solutions (qemu, kvm, ... , > normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems > to be the correct answer. (for other reasons, an i386 version of the > kernel must be used) >=20 > The point of my original email was to simplify the configuration for a te= st > setup : any machine with the attached configuration file and the above > sequence of commands creating and deleting jails, running in a loop, will > eventually panic. >=20 > Anyway, I will follow up with the logs you mentioned. As promised, here are the full logs (in attachment) This is a serial console log showing the command loop that triggers the bug= on=20 a debug kernel and ensuing DDB session. the obvious problem line is : routetbl 2684 303890K 3469 (further tests showed an increase of the routetbl malloc zone by 4MBytes fo= r=20 each vnet jail creation/destruction cycle) Cheers Thierry >=20 > Cheers (and thanks for the quick feedback) >=20 > Thierry Herbelot >=20 > > /bz >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Boundary-00=_aCC5MxDID7T1Y5x Content-Type: text/plain; charset="ISO-8859-15"; name="ddb-log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ddb-log" [root@waldorf ~]# while jail -l -u root -c path=/ name=foo persist vnet && jexe c foo ifconfig lo0 127.0.0.1/8 && jail -r foo ; do continue ; done lock order reversal: 1st 0xc0bed490 allprison (allprison) @ kern/kern_jail.c:914 2nd 0xc0d5c56c vnet_sysinit_sxlock (vnet_sysinit_sxlock) @ net/vnet.c:618 KDB: stack backtrace: db_trace_self_wrapper(c0ab1220,e9867a08,c05fc285,c05ec9db,c0ab40dc,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05ec9db,c0ab40dc,c6d2d138,c6d30c88,e9867a64,...) at kdb_backtrace+0x29 _witness_debugger(c0ab40dc,c0d5c56c,c0abf638,c6d30c88,c0abf794,...) at _witness_debugger+0x25 witness_checkorder(c0d5c56c,1,c0abf78b,26a,0,...) at witness_checkorder+0x839 _sx_slock(c0d5c56c,0,c0abf78b,26a,0,...) at _sx_slock+0x85 vnet_sysinit(c7acf000,c0bb5d00,6180,0,c0b80888,...) at vnet_sysinit+0x2b vnet_alloc(c6f73028,c0aa9de6,0,10,c0aa5dc0,...) at vnet_alloc+0x9e kern_jail_set(c77ed000,c767b380,1,c767b380,280930fc,...) at kern_jail_set+0x179a jail_set(c77ed000,e9867cf8,c0ae5dd0,c0ab4ea5,c77e87f8,...) at jail_set+0x50 syscall(e9867d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (507, FreeBSD ELF32, jail_set), eip = 0x280eae1b, esp = 0xbf7feb7c, ebp = 0xbf7fec38 --- Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. panic: kmem_malloc(131072): kmem_map too small: 335409152 total allocated cpuid = 0 KDB: enter: panic [thread pid 2129 tid 100072 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 2129 tid 100072 td 0xc771fc80 kdb_enter(c0aadf11,c0aadf11,c0ad7eba,e95fa94c,0,...) at kdb_enter+0x3a panic(c0ad7eba,20000,13fdf000,c0ad7eb4,7d0,...) at panic+0x136 kmem_malloc(c149008c,20000,102,e95fa9d8,c082951d,...) at kmem_malloc+0x280 page_alloc(0,20000,e95fa9cb,102,0,...) at page_alloc+0x27 uma_large_malloc(20000,102,102,2,1,...) at uma_large_malloc+0x4d malloc(20000,c0b90240,102,c0585588,20000,...) at malloc+0x118 flowtable_alloc(c0ac790e,8000,2,0,0,...) at flowtable_alloc+0xee ip_init(40,c7629dc0,0,e95faa80,c0617807,...) at ip_init+0x330 protosw_init(40,c0b8e754,c0b941b4,c7629dc0,e95faa8c,...) at protosw_init+0x139 domain_init(c0b93f20,e95faaa8,c068bdde,c0b93f20,0,...) at domain_init+0x27 vnet_domain_init(c0b93f20,0,c0abf78b,26a,0,...) at vnet_domain_init+0x11 vnet_sysinit(c718c000,c0bb5d00,6180,0,c0b80888,...) at vnet_sysinit+0x3e vnet_alloc(c877e028,c0aa9de6,0,10,c0aa5dc0,...) at vnet_alloc+0x9e kern_jail_set(c771fc80,c7676e80,1,c7676e80,280930fc,...) at kern_jail_set+0x179a jail_set(c771fc80,e95facf8,c0ae5dd0,c0ab4ea5,c771ad48,...) at jail_set+0x50 syscall(e95fad38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (507, FreeBSD ELF32, jail_set), eip = 0x280eae1b, esp = 0xbf7feb7c, ebp = 0xbf7fec38 --- db> show uma Zone Size Used Free Requests ipq 32 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 rtentry 108 0 72 6 ripcb 220 0 0 0 FFS2 dinode 256 397 83 420 FFS1 dinode 128 0 0 0 FFS inode 116 397 98 420 Mountpoints 644 3 15 3 SWAPMETA 276 0 0 0 ip6flow 64 0 0 0 ip4flow 40 0 0 0 selfd 28 13 622 953 rtentry 108 9 99 9 unpcb 172 4 88 41 ripcb 220 0 0 0 sctp_asconf_ack 24 0 0 0 sctp_asconf 24 0 0 0 sctp_stream_msg_out 64 0 0 0 sctp_readq 76 0 0 0 sctp_chunk 92 0 0 0 sctp_raddr 432 0 0 0 sctp_laddr 24 0 145 3 sctp_asoc 1484 0 0 0 sctp_ep 860 0 0 0 sackhole 20 0 0 0 tcpreass 20 0 0 0 hostcache 76 0 0 0 syncache 112 0 0 0 tcptw 52 0 0 0 tcpcb 632 2 10 2 tcp_inpcb 220 2 34 2 udpcb 8 2 404 215 udp_inpcb 220 2 70 215 ipq 32 0 0 0 socket 412 8 28 405 bridge_rtnode 36 20 283 24 KNOTE 72 0 0 0 itimer 220 0 0 0 ksiginfo 80 56 232 153 pipe 392 0 90 1453 NFSNODE 468 0 0 0 NFSMOUNT 524 0 0 0 DIRHASH 1024 0 48 26 NAMEI 1024 0 48 17675 L VFS Cache 292 0 0 0 S VFS Cache 72 410 226 917 VNODEPOLL 60 0 0 0 VNODE 268 422 68 447 ata_composite 180 0 0 0 ata_request 204 0 190 2955 ttyoutq 256 156 84 420 ttyinq 152 300 168 810 g_bio 140 0 224 15483 mbuf_ext_refcnt 4 0 0 0 mbuf_jumbo_16k 16384 0 0 0 mbuf_jumbo_9k 9216 0 0 0 mbuf_jumbo_page 4096 0 0 0 mbuf_cluster 2048 512 42 512 mbuf 256 1 387 3924 mbuf_packet 256 256 256 1367 audit_record 816 0 0 0 cpuset 40 2 366 148 VMSPACE 236 17 159 2112 SLEEPQUEUE 48 133 221 133 THREAD 636 113 19 113 PROC 680 35 37 2129 MAC labels 20 0 0 0 umtx pi 52 0 0 0 TURNSTILE 72 133 77 133 Files 56 40 563 8850 4096 4096 2534 28 7824 2048 2048 273 109 1052 1024 1024 68 192 3976 512 512 92 76 4304 256 256 904 131 16844 128 128 2546 484 12434 64 64 5488 707 49123 32 32 3077 426 40826 16 16 3258 1005 42186 mt_zone 2056 270 0 270 SG fakepg 76 0 0 0 DP fakepg 76 0 0 0 PDPT 32 137 428 137 MAP ENTRY 72 280 356 51654 KMAP ENTRY 72 59 471 34398 MAP 140 7 21 7 VM OBJECT 136 667 232 27531 128 Bucket 524 93 12 1366 64 Bucket 268 206 18 260 32 Bucket 140 78 34 259 16 Bucket 76 56 44 82 UMA Hash 128 4 26 4 UMA RCntSlabs 544 277 3 277 UMA Slabs 284 5388 16 18442 UMA Zones 888 237 19 1770 UMA Kegs 128 237 33 1770 db> show malloc Type InUse MemUse Requests CAM periph 2 1K 12 scsi_cd 0 0K 0 acpicmbat 0 0K 0 $PIR 0 0K 0 acpidev 68 3K 68 CAM SIM 1 1K 1 isofs_mount 0 0K 0 isofs_node 0 0K 0 isadev 8 1K 8 ast_driver 0 0K 0 afd_driver 0 0K 0 nexusdev 4 1K 4 msi 3 1K 3 mptable 0 0K 0 memdesc 1 4K 1 MCA 0 0K 0 acd_driver 1 2K 1 ar_driver 0 0K 6 legacydrv 0 0K 0 io_apic 1 1K 1 ad_driver 1 1K 1 ata_pci 0 0K 0 ata_dma 0 0K 0 ata_generic 2 2K 2 scsi_da 0 0K 0 madt_table 0 0K 0 CAM queue 3 1K 7 GEOM 66 181K 5441 apmdev 2 1K 3 mpt_user 0 0K 0 CAM dev queue 1 1K 1 pfs_vncache 0 0K 0 pfs_nodes 21 3K 21 nullfs_mount 0 0K 0 atkbddev 2 1K 2 nullfs_hash 1 1K 1 vm_pgdata 1 64K 1 nullfs_node 0 0K 0 msdosfs_mount 0 0K 0 msdosfs_fat 0 0K 0 UMAHash 0 0K 0 ufs_mount 6 93K 6 ufs_quota 0 0K 0 ufs_dirhash 9 5K 27 pagedep 1 64K 1 inodedep 1 256K 1 newblk 1 1K 1 bmsafemap 0 0K 0 allocdirect 0 0K 0 indirdep 0 0K 0 allocindir 0 0K 0 freefrag 0 0K 0 freeblks 0 0K 0 freefile 0 0K 0 diradd 0 0K 0 mkdir 0 0K 0 dirrem 0 0K 0 newdirblk 0 0K 0 savedino 0 0K 0 mactemp 0 0K 0 audit_trigger 0 0K 0 audit_pipe 0 0K 0 audit_pipeent 0 0K 0 audit_pipe_presel 0 0K 0 audit_evclass 172 3K 211 audit_bsm 0 0K 0 audit_cred 0 0K 0 audit_data 0 0K 0 audit_path 0 0K 0 audit_text 0 0K 0 audit_gidset 0 0K 0 rpc 2 5K 2 NLM 0 0K 0 nfss_srvsock 0 0K 0 nfss_srvdesc 0 0K 0 nfss_daemon 0 0K 0 NFS FHA 1 1K 1 nfsclient_lock 0 0K 0 nfsclient_nlminfo 0 0K 0 nfsclient_req 0 0K 0 nfsclient_bigfh 0 0K 0 nfsclient_diroff 0 0K 0 nfsclient_hash 0 0K 0 nfsclient_directio 0 0K 0 nfsclient_srvsock 0 0K 0 mld 10 2K 83 msdosfs_fileno 0 0K 0 msdosfs_node 0 0K 0 in6_mfilter 0 0K 0 in6_multi 12 2K 669 ip6_moptions 0 0K 0 ip6_msource 0 0K 0 DEVFSP 0 0K 0 DEVFS 16 1K 17 DEVFS_RULE 0 0K 0 fragment 0 0K 0 syncache 1 72K 74 tcplog 0 0K 0 hostcache 1 16K 74 sctp_map 0 0K 0 sctp_stri 0 0K 0 sctp_stro 0 0K 0 sctp_aadr 0 0K 0 sctp_a_it 0 0K 103 sctp_atcl 0 0K 0 sctp_atky 0 0K 0 sctp_athm 0 0 sctp_athi 0 0K 0 sctp_stre 0 0K 0 sctp_cmsg 0 0K 0 sctp_cpal 0 0K 0 sctp_vrf 1 1K 74 sctp_ifa 99 13K 223 sctp_ifn 2 1K 75 sctp_timw 0 0K 0 sctp_mvrf 0 0K 0 sctp_iter 0 0K 103 sctp_socko 0 0K 0 encap_export_host 0 0K 0 in_mfilter 0 0K 0 in_multi 2 1K 75 ip_moptions 0 0K 0 ip_msource 0 0K 0 DEVFS2 0 0K 0 DEVFS3 206 26K 330 DEVFS1 190 48K 315 ipid 0 0K 0 igmp 10 2K 83 80211scan 0 0K 0 80211ratectl 0 0K 0 80211power 0 0K 0 80211node 0 0K 0 80211nodeie 0 0K 0 80211mesh 0 0K 0 80211com 0 0K 0 80211dfs 0 0K 0 80211crypto 0 0K 0 80211vap 0 0K 0 vnet 2 1K 75 vnet_data 2 56K 75 vnet_data_free 1 1K 1 routetbl 2684 303890K 3469 CAM ccb queue 0 0K 0 ata_da 0 0K 0 scsi_ch 0 0K 0 mfibuf 0 0K 0 md_disk 0 0K 0 md_sectors 0 0K 0 LED 2 1K 2 kbdmux 7 10K 7 vlan 0 0K 0 tun 0 0K 0 amr 0 0K 0 lltable 23 6K 315 gif 0 0K 0 fw_com 0 0K 0 faith 0 0K 0 arpcom 8 1K 8 epair 4 1K 4 clone 8 32K 81 ifdescr 0 0K 0 ifnet 12 11K 158 ifaddr 93 18K 823 ether_multi 15 1K 600 BPF 10 1K 83 subr_export_host 0 0K 0 mount 50 3K 2211 vnodemarker 0 0K 385 acpisem 15 2K 15 vnodes 2 1K 2 vfs_hash 1 256K 1 export_host 0 0K 0 cl_savebuf 0 0K 0 vfscache 1 512K 1 biobuf 4 8K 6 acl 0 0K 0 soname 3 1K 89 pcb 14 79K 891 ipsbuf 0 0K 0 shmfd 1 4K 1 ksem 1 4K 1 mbuf_tag 0 0K 1 accf 0 0K 0 pts 0 0K 0 tty 36 18K 38 shm 1 12K 1 sem 4 6K 4 msg 4 25K 4 ioctlops 0 0K 13640 select 6 1K 6 iov 1 1K 745 Witness 1 104K 1 iirbuf 0 0K 0 if_fwip 0 0K 0 ata_pmp 0 0K 0 USB 45 68K 46 Unitno 11 1K 403 taskqueue 15 1K 15 stack 0 0K 2 USBdev 29 7K 29 USBHC 0 0K 0 if_fwe 0 0K 0 sglist 0 0K 0 sbuf 0 0K 2741 CAM XPT 12 2K 26 rman 233 15K 683 acpitask 1 1K 1 acpica 3082 163K 65871 Per-cpu 1 1K 1 kobj 255 510K 363 aaccam 0 0K 0 eventhandler 299 11K 299 devstat 32 65K 32 bus 1110 52K 5921 bus-sc 81 171K 2508 fwmem 0 0K 0 SWAP 0 0K 0 p1003.1b 1 1K 1 umtx 132 9K 132 callout 3 768K 3 sysctl 0 0K 1420 sysctloid 4004 122K 4124 sysctltmp 0 0K 535 firewire 0 0K 0 plimit 12 3K 355 uidinfo 2 2K 17 cred 20 2K 10282 pgrp 17 2K 472 session 15 1K 31 proc 2 8K 2 subproc 109 163K 2203 fw_xfer 0 0K 0 osd 0 0K 0 aacbuf 0 0K 0 UART 51 22K 51 mtx_pool 2 8K 2 twe_commands 0 0K 0 module 379 24K 379 twa_commands 0 0K 0 cache 0 0K 0 devbuf 5642 12692K 5728 temp 59 231K 52869 ip6opt 0 0K 0 ip6ndp 11 1K 157 acpipwr 0 0K 0 free 0 0K 0 lockf 14 1K 18 linker 108 4K 110 ddb_capture 1 48K 1 KTRACE 100 13K 100 ciss_data 0 0K 0 entropy 1024 64K 1024 prison 1 2K 74 ithread 99 8K 99 PUC 8 2K 8 Fail Points 0 0K 0 zombie 0 0K 0 proc-args 17 1K 771 ppbusdev 3 1K 3 kqueue 0 0K 0 kenv 79 7K 83 filedesc 40 14K 2572 filedesc_to_leader 0 0K 0 sigio 1 1K 1 acpi_perf 4 1K 4 SCSI SES 0 0K 0 tty console 0 0K 0 cdev 9 2K 9 pci_link 16 2K 16 SCSI sa 0 0K 0 db> --Boundary-00=_aCC5MxDID7T1Y5x-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 19:05:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB32B1065670; Wed, 17 Nov 2010 19:05:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4BEA28FC1C; Wed, 17 Nov 2010 19:05:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAHJ5VVk045925; Wed, 17 Nov 2010 14:05:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAHJ5Vgq045920; Wed, 17 Nov 2010 19:05:31 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 17 Nov 2010 19:05:31 GMT Message-Id: <201011171905.oAHJ5Vgq045920@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:05:33 -0000 TB --- 2010-11-17 17:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-17 17:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-11-17 17:15:00 - cleaning the object tree TB --- 2010-11-17 17:15:34 - cvsupping the source tree TB --- 2010-11-17 17:15:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-11-17 17:15:57 - building world TB --- 2010-11-17 17:15:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 17:15:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 17:15:57 - TARGET=pc98 TB --- 2010-11-17 17:15:57 - TARGET_ARCH=i386 TB --- 2010-11-17 17:15:57 - TZ=UTC TB --- 2010-11-17 17:15:57 - __MAKE_CONF=/dev/null TB --- 2010-11-17 17:15:57 - cd /src TB --- 2010-11-17 17:15:57 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 17 17:15:57 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 17 19:00:43 UTC 2010 TB --- 2010-11-17 19:00:43 - generating LINT kernel config TB --- 2010-11-17 19:00:43 - cd /src/sys/pc98/conf TB --- 2010-11-17 19:00:43 - /usr/bin/make -B LINT TB --- 2010-11-17 19:00:43 - building LINT kernel TB --- 2010-11-17 19:00:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 19:00:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 19:00:43 - TARGET=pc98 TB --- 2010-11-17 19:00:43 - TARGET_ARCH=i386 TB --- 2010-11-17 19:00:43 - TZ=UTC TB --- 2010-11-17 19:00:43 - __MAKE_CONF=/dev/null TB --- 2010-11-17 19:00:43 - cd /src TB --- 2010-11-17 19:00:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 17 19:00:43 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ata/chipsets/ata-via.c:109: error: 'ATA_VIAVX900' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:109: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/chipsets/ata-via.c:109: error: for each function it appears in.) /src/sys/dev/ata/chipsets/ata-via.c:128: error: 'ATA_VIASATAIDE2' undeclared (first use in this function) cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-via.c:128: warning: comparison between pointer and integer /src/sys/dev/ata/chipsets/ata-via.c:129: error: 'ATA_VIASATAIDE3' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:129: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-17 19:05:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-17 19:05:31 - ERROR: failed to build lint kernel TB --- 2010-11-17 19:05:31 - 5143.41 user 999.59 system 6630.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 19:06:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97B8106566B; Wed, 17 Nov 2010 19:06:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 730758FC19; Wed, 17 Nov 2010 19:06:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAHJ6OpA051027; Wed, 17 Nov 2010 14:06:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAHJ6Oax051017; Wed, 17 Nov 2010 19:06:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 17 Nov 2010 19:06:24 GMT Message-Id: <201011171906.oAHJ6Oax051017@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:06:25 -0000 TB --- 2010-11-17 17:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-17 17:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-17 17:15:00 - cleaning the object tree TB --- 2010-11-17 17:15:37 - cvsupping the source tree TB --- 2010-11-17 17:15:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-17 17:15:59 - building world TB --- 2010-11-17 17:15:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 17:15:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 17:15:59 - TARGET=i386 TB --- 2010-11-17 17:15:59 - TARGET_ARCH=i386 TB --- 2010-11-17 17:15:59 - TZ=UTC TB --- 2010-11-17 17:15:59 - __MAKE_CONF=/dev/null TB --- 2010-11-17 17:15:59 - cd /src TB --- 2010-11-17 17:15:59 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 17 17:16:00 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 17 19:00:38 UTC 2010 TB --- 2010-11-17 19:00:38 - generating LINT kernel config TB --- 2010-11-17 19:00:38 - cd /src/sys/i386/conf TB --- 2010-11-17 19:00:38 - /usr/bin/make -B LINT TB --- 2010-11-17 19:00:38 - building LINT kernel TB --- 2010-11-17 19:00:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 19:00:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 19:00:38 - TARGET=i386 TB --- 2010-11-17 19:00:38 - TARGET_ARCH=i386 TB --- 2010-11-17 19:00:38 - TZ=UTC TB --- 2010-11-17 19:00:38 - __MAKE_CONF=/dev/null TB --- 2010-11-17 19:00:38 - cd /src TB --- 2010-11-17 19:00:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 17 19:00:38 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ata/chipsets/ata-via.c:109: error: 'ATA_VIAVX900' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:109: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/chipsets/ata-via.c:109: error: for each function it appears in.) /src/sys/dev/ata/chipsets/ata-via.c:128: error: 'ATA_VIASATAIDE2' undeclared (first use in this function) cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-via.c:128: warning: comparison between pointer and integer /src/sys/dev/ata/chipsets/ata-via.c:129: error: 'ATA_VIASATAIDE3' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:129: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-17 19:06:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-17 19:06:24 - ERROR: failed to build lint kernel TB --- 2010-11-17 19:06:24 - 5223.47 user 973.37 system 6684.21 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 19:34:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D951065673; Wed, 17 Nov 2010 19:34:42 +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 850B08FC13; Wed, 17 Nov 2010 19:34:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAHJYfYe000774; Wed, 17 Nov 2010 14:34:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAHJYfQu000772; Wed, 17 Nov 2010 19:34:41 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 17 Nov 2010 19:34:41 GMT Message-Id: <201011171934.oAHJYfQu000772@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:34:43 -0000 TB --- 2010-11-17 17:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-17 17:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-11-17 17:15:00 - cleaning the object tree TB --- 2010-11-17 17:15:41 - cvsupping the source tree TB --- 2010-11-17 17:15:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-11-17 17:16:01 - building world TB --- 2010-11-17 17:16:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 17:16:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 17:16:01 - TARGET=amd64 TB --- 2010-11-17 17:16:01 - TARGET_ARCH=amd64 TB --- 2010-11-17 17:16:01 - TZ=UTC TB --- 2010-11-17 17:16:01 - __MAKE_CONF=/dev/null TB --- 2010-11-17 17:16:01 - cd /src TB --- 2010-11-17 17:16:01 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 17 17:16:02 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 17 19:29:31 UTC 2010 TB --- 2010-11-17 19:29:31 - generating LINT kernel config TB --- 2010-11-17 19:29:31 - cd /src/sys/amd64/conf TB --- 2010-11-17 19:29:31 - /usr/bin/make -B LINT TB --- 2010-11-17 19:29:31 - building LINT kernel TB --- 2010-11-17 19:29:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 19:29:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 19:29:31 - TARGET=amd64 TB --- 2010-11-17 19:29:31 - TARGET_ARCH=amd64 TB --- 2010-11-17 19:29:31 - TZ=UTC TB --- 2010-11-17 19:29:31 - __MAKE_CONF=/dev/null TB --- 2010-11-17 19:29:31 - cd /src TB --- 2010-11-17 19:29:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 17 19:29:31 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ata/chipsets/ata-via.c:109: error: 'ATA_VIAVX900' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:109: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/chipsets/ata-via.c:109: error: for each function it appears in.) /src/sys/dev/ata/chipsets/ata-via.c:128: error: 'ATA_VIASATAIDE2' undeclared (first use in this function) cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-via.c:128: warning: comparison between pointer and integer /src/sys/dev/ata/chipsets/ata-via.c:129: error: 'ATA_VIASATAIDE3' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:129: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-17 19:34:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-17 19:34:41 - ERROR: failed to build lint kernel TB --- 2010-11-17 19:34:41 - 6433.05 user 1278.53 system 8381.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 19:36:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7811065670; Wed, 17 Nov 2010 19:36:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C7EEE8FC13; Wed, 17 Nov 2010 19:36:13 +0000 (UTC) Received: by ewy3 with SMTP id 3so1458961ewy.13 for ; Wed, 17 Nov 2010 11:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=KGxn2keoFgwXRMb+tMvVqQMekyIq9SY6HBhoAhJjIw8=; b=S1yVns44iaV0Xu47+zoCAENuYIG1iqsiXRKkCDmnqXNIVjJ+FlQ1ubxjBFGJn2CH/z I1U3KzAWRZIAXhwmBCB3nfi2dC3DeHd1E04BwWVLoqDPiNOUiFSRBgi4UrJotlfXG8Fh KL3SpwFYoC2VtrRVg2HhF1/iyt1kK24wMuFog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ct8gE3QxJCX8fO5AdqG4HBd/enA/mWGqkkulA8UiSbC6chOm6dttucPFocXyY9HW6a oXqAhhOKTtaxOn86N3x54IGHEoEGNVG+zULKz5cf9rAKkUeIBXP/Q6eBkmKJiWF5HRla zMLDPqQkpADfjqBOspyGsxXUzQeMYuiUOfHus= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr9271388wee.45.1290022572143; Wed, 17 Nov 2010 11:36:12 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 11:36:12 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Nov 2010 11:36:12 -0800 X-Google-Sender-Auth: My3LDOueYsv_tnliA0ZG-o_Bb2M Message-ID: From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Warner Losh Subject: newvers.sh: can't find dirname? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 19:36:14 -0000 =A0 =A0This is the second time I've seen this (I forgot why I fixed it the first time, reverted the local change, and ran into the change the second time): =3D=3D=3D> include (install) creating osreldate.h from newvers.sh NEWVERS PATH: /usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/leg= acy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/= sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/insta= ll.Nuxzcgf9 /usr/src/include/../sys/conf/newvers.sh: dirname: not found ... # dirname usage: dirname string [...] =A0 =A0I hacked around this by adding dirname to $PATH in newvers.sh (if you look at the above $PATH printed out, it doesn't contain /bin and /usr/bin -- both which are required to run the above commands), but I was wondering if anyone else has run into this issue before, and whether or not a better solution was in the works (maybe). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 19:38:44 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03CA106566C; Wed, 17 Nov 2010 19:38:43 +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 A52C78FC1D; Wed, 17 Nov 2010 19:38:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAHJcgYA042899; Wed, 17 Nov 2010 14:38:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAHJcguj042890; Wed, 17 Nov 2010 19:38:42 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 17 Nov 2010 19:38:42 GMT Message-Id: <201011171938.oAHJcguj042890@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:38:44 -0000 TB --- 2010-11-17 18:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-17 18:10:00 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-11-17 18:10:00 - cleaning the object tree TB --- 2010-11-17 18:10:22 - cvsupping the source tree TB --- 2010-11-17 18:10:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-11-17 18:10:36 - building world TB --- 2010-11-17 18:10:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 18:10:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 18:10:36 - TARGET=ia64 TB --- 2010-11-17 18:10:36 - TARGET_ARCH=ia64 TB --- 2010-11-17 18:10:36 - TZ=UTC TB --- 2010-11-17 18:10:36 - __MAKE_CONF=/dev/null TB --- 2010-11-17 18:10:36 - cd /src TB --- 2010-11-17 18:10:36 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 17 18:10:36 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 17 19:33:19 UTC 2010 TB --- 2010-11-17 19:33:19 - generating LINT kernel config TB --- 2010-11-17 19:33:19 - cd /src/sys/ia64/conf TB --- 2010-11-17 19:33:19 - /usr/bin/make -B LINT TB --- 2010-11-17 19:33:19 - building LINT kernel TB --- 2010-11-17 19:33:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-17 19:33:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-17 19:33:19 - TARGET=ia64 TB --- 2010-11-17 19:33:19 - TARGET_ARCH=ia64 TB --- 2010-11-17 19:33:19 - TZ=UTC TB --- 2010-11-17 19:33:19 - __MAKE_CONF=/dev/null TB --- 2010-11-17 19:33:19 - cd /src TB --- 2010-11-17 19:33:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 17 19:33:19 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ata/chipsets/ata-via.c:109: error: 'ATA_VIAVX900' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:109: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/chipsets/ata-via.c:109: error: for each function it appears in.) /src/sys/dev/ata/chipsets/ata-via.c:128: error: 'ATA_VIASATAIDE2' undeclared (first use in this function) cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-via.c:128: warning: comparison between pointer and integer /src/sys/dev/ata/chipsets/ata-via.c:129: error: 'ATA_VIASATAIDE3' undeclared (first use in this function) /src/sys/dev/ata/chipsets/ata-via.c:129: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-17 19:38:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-17 19:38:42 - ERROR: failed to build lint kernel TB --- 2010-11-17 19:38:42 - 4123.91 user 744.64 system 5322.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 20:10:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77DE4106566C for ; Wed, 17 Nov 2010 20:10:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 494D18FC15 for ; Wed, 17 Nov 2010 20:10:47 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id oAHJunNG017416 for ; Wed, 17 Nov 2010 11:56:49 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 11:56:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: immediate panic in vm Thread-Index: AcuGkYW4b7UlLWe9Sv6sIYFdsRjHyw== From: "Li, Qing" To: Subject: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 20:10:47 -0000 The latest -current panics immediately on start-up. Running -current in VMware, I get: ... panic: mtx_init: mtx_lock not aligned for netir_mtx: 0xffffffff8114791c ... Has anyone else seen this? Any pointers ? Thanks, -- Qing From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 20:15:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B11106566B for ; Wed, 17 Nov 2010 20:15:51 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id CC0CF8FC1A for ; Wed, 17 Nov 2010 20:15:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PIoQ1-0002yp-Il for freebsd-current@freebsd.org; Wed, 17 Nov 2010 21:15:49 +0100 Received: from static-78-8-147-77.ssp.dialog.net.pl ([78.8.147.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Nov 2010 21:15:49 +0100 Received: from mwisnicki+freebsd by static-78-8-147-77.ssp.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Nov 2010 21:15:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Wisnicki Date: Wed, 17 Nov 2010 20:15:35 +0000 (UTC) Lines: 22 Message-ID: References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> <20101116224156.GA52556@freebsd.org> <20101117033520.GA95666@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: static-78-8-147-77.ssp.dialog.net.pl User-Agent: Pan/0.133 (House of Butterflies) Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 20:15:51 -0000 On Wed, 17 Nov 2010 03:35:20 +0000, Alexander Best wrote: > On Tue Nov 16 10, Alexander Best wrote: >> >> WOW! this is the first time i hear of such a concept. it seems great >> for people like me who are desktop users without any serial/firewire >> consoles or any additional debugging hardware. >> >> is there a way of trying this out somehow? personally i wouldn't need >> the memory dump to work in partitions. i'd simply blug in a blank usb >> stick and have the memory dump dd'ed onto it. i think adding partition >> awareness is not really needed. > > ok i read some more details and i think i figured out how to dump the > memory to a usb stick. question still remains however: will i be able to > use that memory snapshot in kgdb or gdb? > Probably not. I thought about it a bit more and realized that you will miss state of cpu registers which is rather important. How does debugging over firewire work if it only has access to host RAM ? From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 20:31:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B68A106564A; Wed, 17 Nov 2010 20:31:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 194F88FC14; Wed, 17 Nov 2010 20:31:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAHKNlvj053348; Wed, 17 Nov 2010 13:23:47 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE439D1.5040803@bsdimp.com> Date: Wed, 17 Nov 2010 13:23:45 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Warner Losh Subject: Re: newvers.sh: can't find dirname? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 20:31:40 -0000 On 11/17/2010 12:36, Garrett Cooper wrote: > This is the second time I've seen this (I forgot why I fixed it the > first time, reverted the local change, and ran into the change the > second time): > > ===> include (install) > creating osreldate.h from newvers.sh > NEWVERS PATH: /usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.Nuxzcgf9 > /usr/src/include/../sys/conf/newvers.sh: dirname: not found This shouldn't be running newvers.sh... Warner > ... > > # dirname > usage: dirname string [...] > > I hacked around this by adding dirname to $PATH in newvers.sh (if > you look at the above $PATH printed out, it doesn't contain /bin and > /usr/bin -- both which are required to run the above commands), but I > was wondering if anyone else has run into this issue before, and > whether or not a better solution was in the works (maybe). > Thanks, > -Garrett > > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 20:56:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1C91065670; Wed, 17 Nov 2010 20:56:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3158FC0A; Wed, 17 Nov 2010 20:56:26 +0000 (UTC) Received: by wwd20 with SMTP id 20so2416217wwd.31 for ; Wed, 17 Nov 2010 12:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZQunjKkpkOBhBlrvq4WFKl2Af32NjmPx+wTc97qeBJI=; b=wZcnZDHMeo4ZDrFPfP1DxFED/Xq6/IHz5jod73+VQqhtYiD4xv9QyCBGoxEXCjvUxP pw1b2BqblAWob+da7EY491OI93ZdjdWEfyTW9GY8mwXjd/5hf2KARcaUxEzlV7T4niBL /YGJ5l97830hcLuas5bovLDVjhl/dH18iTfnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Sl1sNSnlfkVR+ob9NhVgNVDyyn62CfjBuh8/hRgWAKF8PReagTXuCVvYdISqpgKIeH BgvEi59sITpXSRylAhJYeQ3YkGaHGne86MwyUk08ce7O69JInZBlyE58jwqv3aRT7DQw /ZKjWkcaJGAkZr2IlUzq1AKkNZ+SubH7BRcwo= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr2323284wep.30.1290027384208; Wed, 17 Nov 2010 12:56:24 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 12:56:24 -0800 (PST) In-Reply-To: <4CE439D1.5040803@bsdimp.com> References: <4CE439D1.5040803@bsdimp.com> Date: Wed, 17 Nov 2010 12:56:24 -0800 X-Google-Sender-Auth: GgCDOqDnREe_1V82CgPVB3uK51k Message-ID: From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Warner Losh Subject: Re: newvers.sh: can't find dirname? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 20:56:27 -0000 On Wed, Nov 17, 2010 at 12:23 PM, Warner Losh wrote: > On 11/17/2010 12:36, Garrett Cooper wrote: >> >> =A0 =A0This is the second time I've seen this (I forgot why I fixed it t= he >> first time, reverted the local change, and ran into the change the >> second time): >> >> =3D=3D=3D> =A0include (install) >> creating osreldate.h from newvers.sh >> NEWVERS PATH: >> /usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin= :/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/o= bj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.Nuxzcgf9 >> /usr/src/include/../sys/conf/newvers.sh: dirname: not found > > This shouldn't be running newvers.sh... This might be because sys/param.h was newer than osreldate.h (I unpacked it from a tarball as it was on a memory disk). I thought tar was supposed to preserve the file dates and times with -p though -_-: -m, --modification-time (x mode only) Do not extract modification time. By default, t= he modification time is set to the time stored in the archive. >> # dirname >> usage: dirname string [...] >> >> =A0 =A0I hacked around this by adding dirname to $PATH in newvers.sh (if >> you look at the above $PATH printed out, it doesn't contain /bin and >> /usr/bin -- both which are required to run the above commands), but I >> was wondering if anyone else has run into this issue before, and >> whether or not a better solution was in the works (maybe). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 21:38:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4BF5A106566C; Wed, 17 Nov 2010 21:38:12 +0000 (UTC) Date: Wed, 17 Nov 2010 21:38:12 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101117213812.GA45491@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <201011101717.51062.jhb@freebsd.org> <20101117032012.GA93866@freebsd.org> <201011171006.10486.jhb@freebsd.org> <20101117171154.GA1398@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20101117171154.GA1398@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 21:38:12 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed Nov 17 10, Alexander Best wrote: > On Wed Nov 17 10, John Baldwin wrote: > > On Tuesday, November 16, 2010 10:20:12 pm Alexander Best wrote: > > > On Wed Nov 10 10, John Baldwin wrote: > > > > On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > > > > > On Wed Nov 10 10, Alexander Best wrote: > > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > > > > > hi there, > > > > > > > > > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > > > > > the second attempt). > > > > > > > > > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > > > > > loaded. > > > > > > > > > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > > > > > > > > > Id Refs Address Size Name > > > > > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > > > > > to the description in kldunload(2). > > > > > > > > > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > > > > > after boot? > > > > > > > > > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > > > > > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > > > > > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > > > > > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > > > > > 3 for netgraph.ko and i get the behavior i described beforehand. > > > > > > > > Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually > > > > loading any other netgraph modules so that nothing is loaded magically as a > > > > dependency) and see what behavior that gives you. > > i did some more research regarding this matter: > > 1) DEPENDENCIES: > > netgraph => X (none) > ng_ubt => ng_hci > ng_hci => ng_bluetooth > ng_buetooth => X (none; [no not even netgraph]) > > 2) VARIOUS results: > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 > ** > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 > (obvious, since ng_bluetooth doesn't depend on netgraph) > ** > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 > kldload ng_hci => REF_COUNT_NETGRAPH = 2 > kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 [1] > ** > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 > kldload ng_hci => REF_COUNT_NETGRAPH = 2 > kldload ng_ubt => REF_COUNT_NETGRAPH = 3 > kldunload netgraph => OK, REF_COUNT_NETGRAPH = 2 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] > ** > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 > kldload ng_hci => REF_COUNT_NETGRAPH = 2 > kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 1 [1] > kldload ng_ubt => REF_COUNT_NETGRAPH = 2 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] > ** > > ** > kldload netgraph => REF_COUNT_NETGRAPH = 1 > kldload ng_bluetooth => REF_COUNT_NETGRAPH = 1 > kldload ng_hci => REF_COUNT_NETGRAPH = 2 > kldunload netgraph => OK, REF_COUNT_NETGRAPH = 1 > kldload ng_ubt => REF_COUNT_NETGRAPH = 2 > kldunload netgraph => EBUSY, REF_COUNT_NETGRAPH = 2 [1] > ** > > [1] before EBUSY gets returned i see a notice that netgraph.ko cannot be > unloaded, since it was loaded by the kernel. this doesn't happen in the > last two cases. > > > > > > > sorry it took me a while to check this out. i did some more research and it > > > seems a few things are broken: > > > > > > 1) i have snd_hda in my loader.conf which will load sound as a dependency. > > > unloading snd_hda should then automatically unload sound, which it *doesn't*. > > > i need to unload sound manually. > > > > I clearly said earlier that this is what happens. It's the paragraph below > > where I said that the kernel has no idea when it discovers the modules that > > the loader loaded which ones were explicit and which ones were implicit. It > > treats them all as explicit. the following patch changes the semantics of kldunload to deal with removing modules after all their dependencies have been removed too. this is just a quick hack and probably contains several style(9) bugs. cheers. alex > > i'm really sorry. i completely forgot about that fact. so to make this easy for > me to finally comprehend: > > if a module is loaded via loader.conf *no* implicit dependencies are present > and unloading a module from a chain that got triggered by loader.conf will > *never* unload anything except that one module i specified! > > > > > > > 2) if i unload all ng_* modules i should then be able to also unload netgraph, > > > because no dependencies are left. however kldunload fails with EBUSY! > > > > Perhaps netgraph.ko is not unloadable in general? Actually, that is exactly what > > it does: > > > > case MOD_UNLOAD: > > /* You can't unload it because an interface may be using it. */ > > error = EBUSY; > > break; > > > > (from ng_base.c). > > > > > > When you load modules from the loader, they and all their dependencies are > > > > treated as if you had manually loaded them similar to kldload. This because > > > > the kernel can't determine which modules loaded by the loader were silent > > > > dependencies. > > > > -- > > John Baldwin > > -- > a13x -- a13x --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldunload.diff" diff --git a/sbin/kldunload/kldunload.c b/sbin/kldunload/kldunload.c index 8a3ea61..50e215c 100644 --- a/sbin/kldunload/kldunload.c +++ b/sbin/kldunload/kldunload.c @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -53,7 +54,7 @@ int main(int argc, char** argv) { struct kld_file_stat stat; - int c, fileid, force, opt; + int c, error, fileid, force, opt; char *filename; filename = NULL; @@ -109,7 +110,14 @@ main(int argc, char** argv) else force = LINKER_UNLOAD_NORMAL; - if (kldunloadf(fileid, force) < 0) + error = kldunloadf(fileid, force); + + if (error < 0 && errno == EDOOFUS) { + warnx("module scheduled for removal when refcount drops " + "to zero"); + errno = EBUSY; + } + if (error < 0) err(EXIT_FAILURE, "can't unload file"); } diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c index 43ccd74..82128d0 100644 --- a/sys/kern/kern_linker.c +++ b/sys/kern/kern_linker.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD$"); #include #endif +#define KLD_DEBUG #ifdef KLD_DEBUG int kld_debug = 0; SYSCTL_INT(_debug, OID_AUTO, kld_debug, CTLFLAG_RW, @@ -592,7 +593,7 @@ linker_file_unload(linker_file_t file, int flags) /* Easy case of just dropping a reference. */ if (file->refs > 1) { file->refs--; - return (0); + return (EDOOFUS); } KLD_DPF(FILE, ("linker_file_unload: file is unloading," @@ -1095,7 +1096,7 @@ kern_kldunload(struct thread *td, int fileid, int flags) #endif lf->userrefs--; error = linker_file_unload(lf, flags); - if (error) + if (error && error != EDOOFUS) lf->userrefs++; } } else --ZPt4rx8FFjLCG7dd-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:02:10 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D481065670; Wed, 17 Nov 2010 22:02:10 +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 AAC508FC13; Wed, 17 Nov 2010 22:02:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304] (unknown [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8AD455C43; Wed, 17 Nov 2010 23:02:08 +0100 (CET) Message-ID: <4CE450E3.7080100@FreeBSD.org> Date: Wed, 17 Nov 2010 23:02:11 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13pre) Gecko/20101113 Lanikai/3.1.7pre MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: multipart/mixed; boundary="------------040503070102020500070009" Cc: Marcel Moolenaar Subject: Patches for gcc PR 20218 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:02:10 -0000 This is a multi-part message in MIME format. --------------040503070102020500070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, When I was doing my own ports sort-of-exp-run, using the binutils 2.17 branch, I encountered an issue with the glib20 port on amd64. Some files in it failed to link with the error: relocation R_X86_64_PC32 against `_g_atomic_thread_init' can not be used when making a shared object; recompile with -fPIC After some digging, I found this to be due to gcc PR 20218, which boils down to '__attribute__ ((visibility ("hidden"))) does not work': http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 This is unfortunately *not* yet fixed in our tree. There is a (GPLv2) backport of the fix to the 4.2 branch in the PR, but it does not apply cleanly to our tree, so I have fixed it up, and attached it here as pr20218.diff. I have run a "make universe" with this patch, and the only problem I encountered was with ia64: ===> gnu/lib/libgcc (obj,depend,all,install) ... building shared library libgcc_s.so.1 unwind-ia64.So(.text+0x1762): In function `_Unwind_FindEnclosingFunction': : undefined reference to `_Unwind_FindTableEntry' unwind-ia64.So(.text+0x1d82): In function `uw_frame_state_for': : undefined reference to `_Unwind_FindTableEntry' /usr/obj/ia64.ia64/home/dim/src/freebsd/stage/head/tmp/usr/bin/ld: libgcc_s.so.1: hidden symbol `_Unwind_FindTableEntry' isn't defined *** Error code 1 It turns out libgcc declares the _Unwind_FindTableEntry() function with a hidden attribute in contrib/gcc/config/ia64/unwind-ia64.h, which is fine for the glibc and VMS (!) implementations in that directory. However, FreeBSD's _Unwind_FindTableEntry() is in libc, so the function declaration should be stripped of its hidden attribute to make it link. I have attached a separate patch for this as unwind-ia64.diff. Please review and test both patches. There could possibly be some fallout in ports that do weird things with hidden attributes, as those attributes have never worked before. So if they start working again, some link steps might fall over... --------------040503070102020500070009 Content-Type: text/plain; name="pr20218.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pr20218.diff" Index: contrib/gcc/toplev.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 --- contrib/gcc/toplev.c (revision 215396) +++ contrib/gcc/toplev.c (working copy) @@ -1080,9 +1080,7 @@ compile_file (void) =20 dw2_output_indirect_constants (); =20 - /* Flush any pending external directives. cgraph did this for - assemble_external calls from the front end, but the RTL - expander can also generate them. */ + /* Flush any pending external directives. */ process_pending_assemble_externals (); =20 /* Attach a special .ident directive to the end of the file to identif= y Index: contrib/gcc/cgraphunit.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 --- contrib/gcc/cgraphunit.c (revision 215396) +++ contrib/gcc/cgraphunit.c (working copy) @@ -1536,8 +1536,6 @@ cgraph_optimize (void) return; } =20 - process_pending_assemble_externals (); - /* Frontend may output common variables after the unit has been finali= zed. It is safe to deal with them here as they are always zero initializ= ed. */ cgraph_varpool_analyze_pending_decls (); Index: contrib/gcc/varasm.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 --- contrib/gcc/varasm.c (revision 215396) +++ contrib/gcc/varasm.c (working copy) @@ -126,7 +126,6 @@ static unsigned HOST_WIDE_INT array_size_for_const static unsigned min_align (unsigned, unsigned); static void output_constructor (tree, unsigned HOST_WIDE_INT, unsigned i= nt); static void globalize_decl (tree); -static void maybe_assemble_visibility (tree); #ifdef BSS_SECTION_ASM_OP #ifdef ASM_OUTPUT_BSS static void asm_output_bss (FILE *, tree, const char *, @@ -1957,11 +1956,10 @@ assemble_external (tree decl ATTRIBUTE_UNUSED) if (!DECL_P (decl) || !DECL_EXTERNAL (decl) || !TREE_PUBLIC (decl)) return; =20 - if (flag_unit_at_a_time) - pending_assemble_externals =3D tree_cons (0, decl, - pending_assemble_externals); - else - assemble_external_real (decl); + /* We want to output external symbols at very last to check if they + are references or not. */ + pending_assemble_externals =3D tree_cons (0, decl, + pending_assemble_externals); #endif } =20 @@ -5064,13 +5062,18 @@ default_assemble_visibility (tree decl, int vis) =20 /* A helper function to call assemble_visibility when needed for a decl.= */ =20 -static void +int maybe_assemble_visibility (tree decl) { enum symbol_visibility vis =3D DECL_VISIBILITY (decl); =20 if (vis !=3D VISIBILITY_DEFAULT) - targetm.asm_out.visibility (decl, vis); + { + targetm.asm_out.visibility (decl, vis); + return 1; + } + else + return 0; } =20 /* Returns 1 if the target configuration supports defining public symbol= s @@ -6224,4 +6227,19 @@ output_object_blocks (void) htab_traverse (object_block_htab, output_object_block_htab, NULL); } =20 +/* Emit text to declare externally defined symbols. It is needed to + properly support non-default visibility. */ +void +default_elf_asm_output_external (FILE *file ATTRIBUTE_UNUSED, + tree decl, + const char *name ATTRIBUTE_UNUSED) +{ + /* We output the name if and only if TREE_SYMBOL_REFERENCED is + set in order to avoid putting out names that are never really + used. */ + if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) + && targetm.binds_local_p (decl)) + maybe_assemble_visibility (decl); +} + #include "gt-varasm.h" Index: contrib/gcc/output.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 --- contrib/gcc/output.h (revision 215396) +++ contrib/gcc/output.h (working copy) @@ -200,9 +200,9 @@ extern void assemble_variable (tree, int, int, int DONT_OUTPUT_DATA is from assemble_variable. */ extern void align_variable (tree decl, bool dont_output_data); =20 -/* Output something to declare an external symbol to the assembler. - (Most assemblers don't need this, so we normally output nothing.) - Do nothing if DECL is not external. */ +/* Queue for outputing something to declare an external symbol to the + assembler. (Most assemblers don't need this, so we normally output + nothing.) Do nothing if DECL is not external. */ extern void assemble_external (tree); =20 /* Assemble code to leave SIZE bytes of zeros. */ @@ -607,6 +607,10 @@ extern void default_file_start (void); extern void file_end_indicate_exec_stack (void); extern bool default_valid_pointer_mode (enum machine_mode); =20 +extern void default_elf_asm_output_external (FILE *file, tree, + const char *); +extern int maybe_assemble_visibility (tree); + extern int default_address_cost (rtx); =20 /* dbxout helper functions */ Index: contrib/gcc/config/elfos.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 --- contrib/gcc/config/elfos.h (revision 215396) +++ contrib/gcc/config/elfos.h (working copy) @@ -496,3 +496,13 @@ Boston, MA 02110-1301, USA. */ fprintf ((FILE), "\"\n"); \ } \ while (0) + +/* A C statement (sans semicolon) to output to the stdio stream STREAM + any text necessary for declaring the name of an external symbol + named NAME whch is referenced in this compilation but not defined. + It is needed to properly support non-default visibility. */ + +#ifndef ASM_OUTPUT_EXTERNAL +#define ASM_OUTPUT_EXTERNAL(FILE, DECL, NAME) \ + default_elf_asm_output_external (FILE, DECL, NAME) +#endif Index: contrib/gcc/config/ia64/ia64.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 --- contrib/gcc/config/ia64/ia64.c (revision 215396) +++ contrib/gcc/config/ia64/ia64.c (working copy) @@ -250,10 +250,6 @@ static section *ia64_select_rtx_section (enum mach static void ia64_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED; static unsigned int ia64_section_type_flags (tree, const char *, int); -static void ia64_hpux_add_extern_decl (tree decl) - ATTRIBUTE_UNUSED; -static void ia64_hpux_file_end (void) - ATTRIBUTE_UNUSED; static void ia64_init_libfuncs (void) ATTRIBUTE_UNUSED; static void ia64_hpux_init_libfuncs (void) @@ -5015,49 +5011,6 @@ ia64_secondary_reload_class (enum reg_class class,= } =20 =0C -/* Emit text to declare externally defined variables and functions, beca= use - the Intel assembler does not support undefined externals. */ - -void -ia64_asm_output_external (FILE *file, tree decl, const char *name) -{ - int save_referenced; - - /* GNU as does not need anything here, but the HP linker does need - something for external functions. */ - - if (TARGET_GNU_AS - && (!TARGET_HPUX_LD - || TREE_CODE (decl) !=3D FUNCTION_DECL - || strstr (name, "__builtin_") =3D=3D name)) - return; - - /* ??? The Intel assembler creates a reference that needs to be satisf= ied by - the linker when we do this, so we need to be careful not to do this= for - builtin functions which have no library equivalent. Unfortunately,= we - can't tell here whether or not a function will actually be called b= y - expand_expr, so we pull in library functions even if we may not nee= d - them later. */ - if (! strcmp (name, "__builtin_next_arg") - || ! strcmp (name, "alloca") - || ! strcmp (name, "__builtin_constant_p") - || ! strcmp (name, "__builtin_args_info")) - return; - - if (TARGET_HPUX_LD) - ia64_hpux_add_extern_decl (decl); - else - { - /* assemble_name will set TREE_SYMBOL_REFERENCED, so we must save = and - restore it. */ - save_referenced =3D TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (d= ecl)); - if (TREE_CODE (decl) =3D=3D FUNCTION_DECL) - ASM_OUTPUT_TYPE_DIRECTIVE (file, name, "function"); - (*targetm.asm_out.globalize_label) (file, name); - TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) =3D save_refer= enced; - } -} -=0C /* Parse the -mfixed-range=3D option string. */ =20 static void @@ -9223,55 +9176,33 @@ ia64_hpux_function_arg_padding (enum machine_mode= return DEFAULT_FUNCTION_ARG_PADDING (mode, type); } =20 -/* Linked list of all external functions that are to be emitted by GCC. - We output the name if and only if TREE_SYMBOL_REFERENCED is set in - order to avoid putting out names that are never really used. */ +/* Emit text to declare externally defined variables and functions, beca= use + the Intel assembler does not support undefined externals. */ =20 -struct extern_func_list GTY(()) +void +ia64_asm_output_external (FILE *file, tree decl, const char *name) { - struct extern_func_list *next; - tree decl; -}; - -static GTY(()) struct extern_func_list *extern_func_head; - -static void -ia64_hpux_add_extern_decl (tree decl) -{ - struct extern_func_list *p =3D ggc_alloc (sizeof (struct extern_func_l= ist)); - - p->decl =3D decl; - p->next =3D extern_func_head; - extern_func_head =3D p; -} - -/* Print out the list of used global functions. */ - -static void -ia64_hpux_file_end (void) -{ - struct extern_func_list *p; - - for (p =3D extern_func_head; p; p =3D p->next) + /* We output the name if and only if TREE_SYMBOL_REFERENCED is + set in order to avoid putting out names that are never really + used. */ + if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) { - tree decl =3D p->decl; - tree id =3D DECL_ASSEMBLER_NAME (decl); + /* maybe_assemble_visibility will return 1 if the assembler + visibility directive is outputed. */ + int need_visibility =3D ((*targetm.binds_local_p) (decl) + && maybe_assemble_visibility (decl)); =20 - gcc_assert (id); - - if (!TREE_ASM_WRITTEN (decl) && TREE_SYMBOL_REFERENCED (id)) - { - const char *name =3D XSTR (XEXP (DECL_RTL (decl), 0), 0); - - TREE_ASM_WRITTEN (decl) =3D 1; - (*targetm.asm_out.globalize_label) (asm_out_file, name); - fputs (TYPE_ASM_OP, asm_out_file); - assemble_name (asm_out_file, name); - fprintf (asm_out_file, "," TYPE_OPERAND_FMT "\n", "function"); - } + /* GNU as does not need anything here, but the HP linker does + need something for external functions. */ + if ((TARGET_HPUX_LD || !TARGET_GNU_AS) + && TREE_CODE (decl) =3D=3D FUNCTION_DECL) + { + ASM_OUTPUT_TYPE_DIRECTIVE (file, name, "function"); + (*targetm.asm_out.globalize_label) (file, name); + } + else if (need_visibility && !TARGET_GNU_AS) + (*targetm.asm_out.globalize_label) (file, name); } - - extern_func_head =3D 0; } =20 /* Set SImode div/mod functions, init_integral_libfuncs only initializes= Index: contrib/gcc/config/ia64/hpux.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 --- contrib/gcc/config/ia64/hpux.h (revision 215396) +++ contrib/gcc/config/ia64/hpux.h (working copy) @@ -144,10 +144,6 @@ do { \ definitions, so do not use them in gthr-posix.h. */ #define GTHREAD_USE_WEAK 0 =20 -/* Put out the needed function declarations at the end. */ - -#define TARGET_ASM_FILE_END ia64_hpux_file_end - #undef CTORS_SECTION_ASM_OP #define CTORS_SECTION_ASM_OP "\t.section\t.init_array,\t\"aw\",\"init_a= rray\"" =20 --------------040503070102020500070009 Content-Type: text/plain; name="unwind-ia64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="unwind-ia64.diff" Index: contrib/gcc/config/ia64/unwind-ia64.h =================================================================== --- contrib/gcc/config/ia64/unwind-ia64.h (revision 215423) +++ contrib/gcc/config/ia64/unwind-ia64.h (working copy) @@ -19,6 +19,13 @@ the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ +#ifdef __FreeBSD__ +/* On FreeBSD, _Unwind_FindTableEntry is in libc, and must not be hidden here. */ +#define ATTRIBUTE_HIDDEN +#else +#define ATTRIBUTE_HIDDEN __attribute__ ((__visibility__ ("hidden"))) +#endif + struct unw_table_entry { unsigned long start_offset; @@ -29,4 +36,4 @@ struct unw_table_entry extern struct unw_table_entry * _Unwind_FindTableEntry (void *pc, unsigned long *segment_base, unsigned long *gp) - __attribute__ ((__visibility__ ("hidden"))); + ATTRIBUTE_HIDDEN; --------------040503070102020500070009-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 21:06:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E76106567A for ; Wed, 17 Nov 2010 21:06:09 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 183668FC15 for ; Wed, 17 Nov 2010 21:06:08 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3BFFEBDC46 for ; Wed, 17 Nov 2010 12:50:04 -0800 (PST) To: freebsd-current@freebsd.org Date: Wed, 17 Nov 2010 12:50:04 -0800 Message-ID: <18338.1290027004@tristatelogic.com> From: "Ronald F. Guilmette" X-Mailman-Approved-At: Wed, 17 Nov 2010 22:03:11 +0000 Subject: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 21:06:09 -0000 Greetings, I have recently posted a possible patch which seems to solve a malfunction that occurs with the script(1) program when it is used with the -k option and certain shells which allow for command line editing. The patch may be send towards the (current) end of the discussion regarding this bug which can be seen here: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 I'd like to know who I should talk to in order to get this patch approved and integrated into the official source tree. (And it was suggested to me that I should ask here.) From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:04:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A472106564A; Wed, 17 Nov 2010 22:04:11 +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 4C8DA8FC12; Wed, 17 Nov 2010 22:04:11 +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 E1E4346B58; Wed, 17 Nov 2010 17:04:10 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D99F48A009; Wed, 17 Nov 2010 17:04:09 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 17 Nov 2010 17:04:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011171704.03157.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 17 Nov 2010 17:04:10 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Li, Qing" , dim@freebsd.org Subject: Re: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:04:11 -0000 On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: > The latest -current panics immediately on start-up. > Running -current in VMware, I get: > > > ... > panic: mtx_init: mtx_lock not aligned for netir_mtx: 0xffffffff8114791c > ... > > > Has anyone else seen this? Any pointers ? I'm guessing the recent changes to how the VNET stuff works have broken the alignment of DPCPU and VNET structures again. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:15:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF91A10656C9; Wed, 17 Nov 2010 22:15:38 +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 6CDB08FC12; Wed, 17 Nov 2010 22:15:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304] (unknown [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A7EDC5C43; Wed, 17 Nov 2010 23:15:37 +0100 (CET) Message-ID: <4CE4540C.9050409@FreeBSD.org> Date: Wed, 17 Nov 2010 23:15:40 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13pre) Gecko/20101113 Lanikai/3.1.7pre MIME-Version: 1.0 To: John Baldwin References: <201011171704.03157.jhb@freebsd.org> In-Reply-To: <201011171704.03157.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , freebsd-current@freebsd.org Subject: Re: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:15:38 -0000 On 2010-11-17 23:04, John Baldwin wrote: > On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: >> panic: mtx_init: mtx_lock not aligned for netir_mtx: 0xffffffff8114791c ... > I'm guessing the recent changes to how the VNET stuff works have broken the > alignment of DPCPU and VNET structures again. That is indeed possible; Qing, can you please try to revert r215212, and see if that fixes it? From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:29:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE37106566C; Wed, 17 Nov 2010 22:29:18 +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 764E08FC08; Wed, 17 Nov 2010 22:29:17 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAHMT9IA038320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 00:29:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAHMT9hW015516; Thu, 18 Nov 2010 00:29:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAHMT9dj015515; Thu, 18 Nov 2010 00:29:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Nov 2010 00:29:09 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20101117222909.GY2392@deviant.kiev.zoral.com.ua> References: <201011171704.03157.jhb@freebsd.org> <4CE4540C.9050409@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MLzAvpn/0c4xt0VU" Content-Disposition: inline In-Reply-To: <4CE4540C.9050409@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "Li, Qing" , freebsd-current@freebsd.org Subject: Re: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:29:18 -0000 --MLzAvpn/0c4xt0VU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2010 at 11:15:40PM +0100, Dimitry Andric wrote: > On 2010-11-17 23:04, John Baldwin wrote: > >On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: > >>panic: mtx_init: mtx_lock not aligned for netir_mtx: 0xffffffff8114791c > ... > >I'm guessing the recent changes to how the VNET stuff works have broken = the > >alignment of DPCPU and VNET structures again. >=20 > That is indeed possible; Qing, can you please try to revert r215212, and > see if that fixes it? I suggest to see how old is the world where buildkernel was done ? In particular, the thing to check is whether the ld(1) used to link the kernel contains r210245. --MLzAvpn/0c4xt0VU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzkVzQACgkQC3+MBN1Mb4iOiQCgyF3lHJDlJ3v+LW1vpAK/+7D/ P28Anip5VHLvpiGplNBxZaMMvsGbgTwV =fsfM -----END PGP SIGNATURE----- --MLzAvpn/0c4xt0VU-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:40:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286E4106564A for ; Wed, 17 Nov 2010 22:40:01 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 08D9C8FC13 for ; Wed, 17 Nov 2010 22:40:00 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id oAHMe0ce006086; Wed, 17 Nov 2010 14:40:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 14:39:36 -0800 Message-ID: In-Reply-To: <4CE4540C.9050409@FreeBSD.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: immediate panic in vm Thread-Index: AcuGpPlym9jAZXNnQXiSS3Vz97k2MAAA0z/w References: <201011171704.03157.jhb@freebsd.org> <4CE4540C.9050409@FreeBSD.org> From: "Li, Qing" To: "Dimitry Andric" , "John Baldwin" Cc: freebsd-current@FreeBSD.org Subject: RE: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:40:01 -0000 I saw the panic before r215212. --Qing > -----Original Message----- > From: Dimitry Andric [mailto:dim@FreeBSD.org] > Sent: Wednesday, November 17, 2010 2:16 PM > To: John Baldwin > Cc: freebsd-current@FreeBSD.org; Li, Qing > Subject: Re: immediate panic in vm >=20 > On 2010-11-17 23:04, John Baldwin wrote: > > On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: > >> panic: mtx_init: mtx_lock not aligned for netir_mtx: > 0xffffffff8114791c > ... > > I'm guessing the recent changes to how the VNET stuff works have > broken the > > alignment of DPCPU and VNET structures again. >=20 > That is indeed possible; Qing, can you please try to revert r215212, > and > see if that fixes it? From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:41:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7BC11065674 for ; Wed, 17 Nov 2010 22:41:23 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C38468FC12 for ; Wed, 17 Nov 2010 22:41:23 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id oAHMfNmK006531; Wed, 17 Nov 2010 14:41:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 14:41:03 -0800 Message-ID: In-Reply-To: <20101117222909.GY2392@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: immediate panic in vm Thread-Index: AcuGpt6HCWdF2BucSnmTV5i94ri7IwAAXQmg References: <201011171704.03157.jhb@freebsd.org> <4CE4540C.9050409@FreeBSD.org> <20101117222909.GY2392@deviant.kiev.zoral.com.ua> From: "Li, Qing" To: "Kostik Belousov" , "Dimitry Andric" Cc: freebsd-current@freebsd.org Subject: RE: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:41:24 -0000 Building kernel on 8.1-RELEASE should not require a buildworld, right ? Or there have been changes committed since that would mandate a buildworld? -- Qing > -----Original Message----- > From: Kostik Belousov [mailto:kostikbel@gmail.com] > Sent: Wednesday, November 17, 2010 2:29 PM > To: Dimitry Andric > Cc: John Baldwin; Li, Qing; freebsd-current@freebsd.org > Subject: Re: immediate panic in vm >=20 > On Wed, Nov 17, 2010 at 11:15:40PM +0100, Dimitry Andric wrote: > > On 2010-11-17 23:04, John Baldwin wrote: > > >On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: > > >>panic: mtx_init: mtx_lock not aligned for netir_mtx: > 0xffffffff8114791c > > ... > > >I'm guessing the recent changes to how the VNET stuff works have > broken the > > >alignment of DPCPU and VNET structures again. > > > > That is indeed possible; Qing, can you please try to revert r215212, > and > > see if that fixes it? > I suggest to see how old is the world where buildkernel was done ? > In particular, the thing to check is whether the ld(1) used to link > the kernel contains r210245. From owner-freebsd-current@FreeBSD.ORG Wed Nov 17 22:51:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02F00106566C; Wed, 17 Nov 2010 22:51:57 +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 52D188FC17; Wed, 17 Nov 2010 22:51:55 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAHMpn7M040013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 00:51:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAHMpn43015689; Thu, 18 Nov 2010 00:51:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAHMpnEM015688; Thu, 18 Nov 2010 00:51:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Nov 2010 00:51:49 +0200 From: Kostik Belousov To: "Li, Qing" Message-ID: <20101117225149.GZ2392@deviant.kiev.zoral.com.ua> References: <201011171704.03157.jhb@freebsd.org> <4CE4540C.9050409@FreeBSD.org> <20101117222909.GY2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+tSNo1AAyLoC1Dkm" 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=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2010 22:51:57 -0000 --+tSNo1AAyLoC1Dkm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2010 at 02:41:03PM -0800, Li, Qing wrote: > Building kernel on 8.1-RELEASE should not require a buildworld, right ? >=20 > Or there have been changes committed since that would mandate a > buildworld? Yes, you have to do buildworld/buildkernel, 8.1 release ld(1) does not have the change. >=20 > -- Qing >=20 >=20 > > -----Original Message----- > > From: Kostik Belousov [mailto:kostikbel@gmail.com] > > Sent: Wednesday, November 17, 2010 2:29 PM > > To: Dimitry Andric > > Cc: John Baldwin; Li, Qing; freebsd-current@freebsd.org > > Subject: Re: immediate panic in vm > >=20 > > On Wed, Nov 17, 2010 at 11:15:40PM +0100, Dimitry Andric wrote: > > > On 2010-11-17 23:04, John Baldwin wrote: > > > >On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: > > > >>panic: mtx_init: mtx_lock not aligned for netir_mtx: > > 0xffffffff8114791c > > > ... > > > >I'm guessing the recent changes to how the VNET stuff works have > > broken the > > > >alignment of DPCPU and VNET structures again. > > > > > > That is indeed possible; Qing, can you please try to revert r215212, > > and > > > see if that fixes it? > > I suggest to see how old is the world where buildkernel was done ? > > In particular, the thing to check is whether the ld(1) used to link > > the kernel contains r210245. --+tSNo1AAyLoC1Dkm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzkXIQACgkQC3+MBN1Mb4gMBgCgsfNg8VlGjs7OeoBK3kBqyKtP 1VAAn0L0CNDfNOjcQbORpWyxgo4sE0A2 =VmUI -----END PGP SIGNATURE----- --+tSNo1AAyLoC1Dkm-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 00:10:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5730106564A for ; Thu, 18 Nov 2010 00:10:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE3F8FC18 for ; Thu, 18 Nov 2010 00:10:38 +0000 (UTC) Received: by wwd20 with SMTP id 20so2599949wwd.31 for ; Wed, 17 Nov 2010 16:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=XDVZeWLWnx6pDqqMYaqLz6xSutWtsOZAFMqx6j9ahwo=; b=jYdph1GjA7gEfla5Ig6RbAPimHShMAd4jsvcVcHWd3WA3JiaO/Sz06KpWpB+L+Rhme HmEtokpy2fuLZFONgOH3/MinCjffbzKChH6oDOQPEvHTfLYvUhKPm/i6GaKsI7llnV38 9h3qOJ2WWG2+Vj9w6qSjjotNs6pbLeC340pMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BtyNlW1X+ZTZ0swoOPjR0BqePADMhKWElHod0y0Haww+I0aR2NOD+zBap3NpW9qG+6 zPXlnhTU1qRmD8sVE2cB7MyoJZyFg4aJNKyfmbdxGGW3WSdAKHhSUsMis4ZNJJlhsPXU Lw1RrI14h9c9z+PtPhADgAmCEV7KHMyO6WoYw= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr9691986wel.30.1290039035967; Wed, 17 Nov 2010 16:10:35 -0800 (PST) Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 16:10:35 -0800 (PST) Date: Wed, 17 Nov 2010 16:10:35 -0800 Message-ID: From: Garrett Cooper To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 18 Nov 2010 00:18:32 +0000 Cc: FreeBSD Current Subject: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 00:10:39 -0000 On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar wrote: > > On Sep 28, 2010, at 10:27 AM, M. Warner Losh wrote: > >> Hey Marcel, >> >> haven't had a chance to look through this in detail yet. =A0One item >> that has always bugged me is why when we hit the prompt that has to be >> the end of discovery... =A0Why can't we have a method to listen to new >> geom providers being advertised and then 'short circuit' the ask >> prompt if /dev/da0s1a or /dev/ufs/rootfs or whatever it originally >> wanted appears. >> >> Maybe this isn't .ask, but some other verb in your language? > > Hmmm... I think we should give .ask an option so that it can be > made conditional upon a key press then. I don't think it's nice > to print all that stuff, present a prompt, wait for input and > then shortly after continue booting anyway because some device > showed up. > > Say we have ".ask on-key-press", which basically nullifies the > .ask directive (by implicitly failing to mount) unless a key was > pressed. At that time we actually print the help, show a prompt > and wait for input. This in combination with ".onfail retry" > allows us to cycle through the alternatives until 1) a key was > pressed and we'll drop at the interactive mount prompt or 2) a > device we've been waiting for appears and we can mount root. > > Would that address your case? > > Another feature we may need is the alternative: if you boot > with -C, we'll try cd9660:/dev/cd0 and cd9660:/dev/acd0. What > we really want to do is: > =A0 =A0 =A0 =A0.select /dev/cd0 /dev/acd0 > =A0 =A0 =A0 =A0cd9660:%selected% Hi Marcel, Do you have any examples that use nfs rootfs's out of the box that work with the new logic that don't involve creating an mfsroot? I keep on running into this error with vfs.root.mountfrom=3Dnfs (previously on CURRENT it would just try to mount nfs via nfs_mount in the NFS client without any complaints): Root mount waiting for: usbus2 uhid0: on usbus2 panic: mountroot: unable to (re-)mount root. cpuid =3D 10 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movq $0,0x6e60e0(%rip) db> continue Uptime: 13s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort I don't run into this error when I unset this variable sometimes (it boots up multiuser and all is happy, hunky dory when I manually query this variable from the pxeboot loader, but not when I don't... it's weird). It seems to ignore the directives in mount.conf: # cat mount.conf .onfail continue .ask and always panics for no good reason (and gets stuck so I have to powercycle the machine manually, but that's a different issue entirely). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 00:31:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAB6F106567A for ; Thu, 18 Nov 2010 00:31:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD7B8FC0A for ; Thu, 18 Nov 2010 00:31:38 +0000 (UTC) Received: by wyb35 with SMTP id 35so1790783wyb.13 for ; Wed, 17 Nov 2010 16:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S2dhHWqFwGOm/IzJib1YpAJx5FYH18JGzEej9X0cQTQ=; b=HeGvdsfw9i0vn8fVLFPrQ2j+HSb2xyxRwa3KsJ41xKiAivlShhfk4N700jcrB7+iiE gsqVXlH8v+63SakNslywen0kWJEkvilGf7tY9C8u5NSqK84OJe+WWJPWuT11NcbqknjX 9bbtwS6ldb87N1tMdCUnNdWmg3vky8HwDXejs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kH6J284wO2EzgWbvtzE5p6QFIFACEPDvCZLd9w0ZbeNOZ/gwZZgIYok+zJN6UDudeb Xbt5Pq6MQrEzTKxD6ilVNeGHs3mwRHLRV0msO+2OH0LulQR3CKzlwxe0jgfGy2N/VPsd r4A737kMvoILRTmSsaELkiySYEiveWECsGoSY= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr9566506wee.45.1290040297338; Wed, 17 Nov 2010 16:31:37 -0800 (PST) Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 16:31:37 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Nov 2010 16:31:37 -0800 Message-ID: From: Garrett Cooper To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 18 Nov 2010 00:45:58 +0000 Cc: FreeBSD Current Subject: Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 00:31:39 -0000 On Wed, Nov 17, 2010 at 4:10 PM, Garrett Cooper wrote: > On Tue, Sep 28, 2010 at 11:24 AM, Marcel Moolenaar wrote= : >> >> On Sep 28, 2010, at 10:27 AM, M. Warner Losh wrote: >> >>> Hey Marcel, >>> >>> haven't had a chance to look through this in detail yet. =A0One item >>> that has always bugged me is why when we hit the prompt that has to be >>> the end of discovery... =A0Why can't we have a method to listen to new >>> geom providers being advertised and then 'short circuit' the ask >>> prompt if /dev/da0s1a or /dev/ufs/rootfs or whatever it originally >>> wanted appears. >>> >>> Maybe this isn't .ask, but some other verb in your language? >> >> Hmmm... I think we should give .ask an option so that it can be >> made conditional upon a key press then. I don't think it's nice >> to print all that stuff, present a prompt, wait for input and >> then shortly after continue booting anyway because some device >> showed up. >> >> Say we have ".ask on-key-press", which basically nullifies the >> .ask directive (by implicitly failing to mount) unless a key was >> pressed. At that time we actually print the help, show a prompt >> and wait for input. This in combination with ".onfail retry" >> allows us to cycle through the alternatives until 1) a key was >> pressed and we'll drop at the interactive mount prompt or 2) a >> device we've been waiting for appears and we can mount root. >> >> Would that address your case? >> >> Another feature we may need is the alternative: if you boot >> with -C, we'll try cd9660:/dev/cd0 and cd9660:/dev/acd0. What >> we really want to do is: >> =A0 =A0 =A0 =A0.select /dev/cd0 /dev/acd0 >> =A0 =A0 =A0 =A0cd9660:%selected% > > Hi Marcel, > =A0 =A0Do you have any examples that use nfs rootfs's out of the box that > work with the new logic that don't involve creating an mfsroot? I keep > on running into this error with vfs.root.mountfrom=3Dnfs (previously on > CURRENT it would just try to mount nfs via nfs_mount in the NFS client > without any complaints): > > Root mount waiting for: usbus2 > uhid0: on usbus2 > panic: mountroot: unable to (re-)mount root. > cpuid =3D 10 > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$0,0x6e60e0(%rip) > db> continue > Uptime: 13s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > > =A0 =A0I don't run into this error when I unset this variable sometimes > (it boots up multiuser and all is happy, hunky dory when I manually > query this variable from the pxeboot loader, but not when I don't... > it's weird). I would ignore this piece of information. I might have been picking up a stale copy of pxeboot that was working by accident. I'll look into this issue further to see whether or not that was that root cause. > =A0 =A0It seems to ignore the directives in mount.conf: > > # cat mount.conf > .onfail continue > .ask > > =A0 =A0and always panics for no good reason (and gets stuck so I have to > powercycle the machine manually, but that's a different issue > entirely). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 02:51:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A7B1065670 for ; Thu, 18 Nov 2010 02:51:02 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 43E658FC08 for ; Thu, 18 Nov 2010 02:51:01 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id oAI2p104000502; Wed, 17 Nov 2010 18:51:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 18:50:38 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECMP and route ownership Thread-Index: AcuGy2HNmPXzqoQ4TmqD4OlIsFM6OA== From: "Li, Qing" To: , Cc: Subject: ECMP and route ownership X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 02:51:02 -0000 As I am revising the ECMP code and reviewing the work done by Ingo Flaschberger, I come to the conclusion that I need to make one more enhancement to ECMP. I want to implement the "inetCidrRouteProto" concept as the 2nd variable that differentiates among the ECMP routes. I have already started on the prototyping work and should have something out in a couple of days. Any comments on its usefulness or perhaps sharing your=20 knowledge about what has been done already? Thank you. -- Qing From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 04:26:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4830C106564A; Thu, 18 Nov 2010 04:26:48 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 19B098FC08; Thu, 18 Nov 2010 04:26:47 +0000 (UTC) Received: from cpe-74-66-24-70.nyc.res.rr.com ([74.66.24.70] helo=[192.168.1.155]) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PIvZ5-0007NL-9A; Wed, 17 Nov 2010 22:53:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <4CE29718.2050508@freebsd.org> Date: Wed, 17 Nov 2010 22:53:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE29718.2050508@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 04:26:48 -0000 On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: >=20 > Many modern processors provide APERF and MPERF MSRs which allow to = easily and > reliable calculate average CPU performance level over some interval of = time. > This also allows to notice things like performance boost, which is = generally > hidden from software. > What would be a proper place to add code that would measure = APERF/MPERF ratio? > When should trigger such a measurement and over what interval? > Ideas? Can you point me at documentation for this? This sounds a lot like hwpmc(4) and I wonder if we can make these available in the same way. Best, George From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 05:30:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC439106566B for ; Thu, 18 Nov 2010 05:30:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-1.mx.aerioconnect.net [216.240.47.61]) by mx1.freebsd.org (Postfix) with ESMTP id 988F18FC0C for ; Thu, 18 Nov 2010 05:30:13 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAI5UCL8022182; Wed, 17 Nov 2010 21:30:12 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CFF772D6014; Wed, 17 Nov 2010 21:30:11 -0800 (PST) Message-ID: <4CE4B9E5.3000005@freebsd.org> Date: Wed, 17 Nov 2010 21:30:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Marcin Wisnicki References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> <20101116224156.GA52556@freebsd.org> <20101117033520.GA95666@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 05:30:13 -0000 On 11/17/10 12:15 PM, Marcin Wisnicki wrote: > On Wed, 17 Nov 2010 03:35:20 +0000, Alexander Best wrote: > >> On Tue Nov 16 10, Alexander Best wrote: >>> WOW! this is the first time i hear of such a concept. it seems great >>> for people like me who are desktop users without any serial/firewire >>> consoles or any additional debugging hardware. >>> >>> is there a way of trying this out somehow? personally i wouldn't need >>> the memory dump to work in partitions. i'd simply blug in a blank usb >>> stick and have the memory dump dd'ed onto it. i think adding partition >>> awareness is not really needed. >> ok i read some more details and i think i figured out how to dump the >> memory to a usb stick. question still remains however: will i be able to >> use that memory snapshot in kgdb or gdb? >> > Probably not. I thought about it a bit more and realized that you will > miss state of cpu registers which is rather important. > > How does debugging over firewire work if it only has access to host RAM ? registers are saved to ram as part of exception handling.. > _______________________________________________ > 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 18 07:37:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB30106564A for ; Thu, 18 Nov 2010 07:37:42 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id DD8AF8FC0A for ; Thu, 18 Nov 2010 07:37:41 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3A3D241C713; Thu, 18 Nov 2010 08:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 0qE4-gd5+TV9; Thu, 18 Nov 2010 08:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 899D641C733; Thu, 18 Nov 2010 08:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2312A4448F3; Thu, 18 Nov 2010 07:24:46 +0000 (UTC) Date: Thu, 18 Nov 2010 07:24:45 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Paul B Mahol In-Reply-To: Message-ID: <20101118072341.V24596@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: net.link.log_link_state_change broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 07:37:42 -0000 On Tue, 2 Nov 2010, Paul B Mahol wrote: Hi, > It appears we do not log such events anymore (at least with wlan > devices) in console. > > I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. > > Because I had loging disabled for very long time I encountered this > problem just now. not sure. Might be, might not be. Have you further looked into this? I at least see: ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_UP); ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_DOWN); maybe a good start to search from there? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 08:17:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18378106566B; Thu, 18 Nov 2010 08:17:35 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id C32D78FC13; Thu, 18 Nov 2010 08:17:34 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 23C5341C710; Thu, 18 Nov 2010 09:17:34 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id d7CNhwaOADxN; Thu, 18 Nov 2010 09:17:33 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2ADDE41C705; Thu, 18 Nov 2010 09:17:33 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1B6584448F3; Thu, 18 Nov 2010 08:16:23 +0000 (UTC) Date: Thu, 18 Nov 2010 08:16:22 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Thierry Herbelot In-Reply-To: <201011171936.10764.thierry.herbelot@free.fr> Message-ID: <20101118081512.K24596@maildrop.int.zabbadoz.net> References: <201011170627.28025.thierry.herbelot@free.fr> <20101117055208.S24596@maildrop.int.zabbadoz.net> <201011170729.41894.thierry.herbelot@free.fr> <201011171936.10764.thierry.herbelot@free.fr> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 08:17:35 -0000 On Wed, 17 Nov 2010, Thierry Herbelot wrote: > As promised, here are the full logs (in attachment) > > This is a serial console log showing the command loop that triggers the bug on > a debug kernel and ensuing DDB session. > > the obvious problem line is : > routetbl 2684 303890K 3469 > > (further tests showed an increase of the routetbl malloc zone by 4MBytes for > each vnet jail creation/destruction cycle) Hmm, I had fixed that (somewhere). I'll see where the patch went. You are on 8.1-RELEASE or -STABLE? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 11:23:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 853AA106566C; Thu, 18 Nov 2010 11:23:19 +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 3E73E8FC12; Thu, 18 Nov 2010 11:23:19 +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 <1PJ2IA-0000Ju-93>; Thu, 18 Nov 2010 12:04:38 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PJ2IA-0000XK-4R>; Thu, 18 Nov 2010 12:04:38 +0100 Message-ID: <4CE50849.106@zedat.fu-berlin.de> Date: Thu, 18 Nov 2010 12:04:41 +0100 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 11:23:19 -0000 On 11/18/10 02:30, grarpamp wrote: > Just documenting regarding interactive performance things. > This one's from Linux. > > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 Well, it would be nice to have those improvements in FreeBSD, but I doubt this will make it in due time to FreeBSD's kernel. From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 12:32:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F99B1065696; Thu, 18 Nov 2010 12:32:36 +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 8DBD98FC0C; Thu, 18 Nov 2010 12:32:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA22794; Thu, 18 Nov 2010 14:32:27 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE51CDA.6010202@freebsd.org> Date: Thu, 18 Nov 2010 14:32:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: George Neville-Neil References: <4CE29718.2050508@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 12:32:37 -0000 on 18/11/2010 05:53 George Neville-Neil said the following: > > On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: > >> >> Many modern processors provide APERF and MPERF MSRs which allow to easily and >> reliable calculate average CPU performance level over some interval of time. >> This also allows to notice things like performance boost, which is generally >> hidden from software. >> What would be a proper place to add code that would measure APERF/MPERF ratio? >> When should trigger such a measurement and over what interval? >> Ideas? > > Can you point me at documentation for this? This sounds a lot like > hwpmc(4) and I wonder if we can make these available in the same way. Actually it feels more cpufreq-ish to me. This feature is documented in, e.g., Intel Software Developer's Manual volume 3A, section 14.2 P-STATE HARDWARE COORDINATION. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 12:49:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD61106564A; Thu, 18 Nov 2010 12:49: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 B71EF8FC18; Thu, 18 Nov 2010 12:49:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23029; Thu, 18 Nov 2010 14:49:18 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE520CD.5070805@freebsd.org> Date: Thu, 18 Nov 2010 14:49:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Li, Qing" References: <201011171704.03157.jhb@freebsd.org> <4CE4540C.9050409@FreeBSD.org> <20101117222909.GY2392@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: immediate panic in vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 12:49:24 -0000 on 18/11/2010 00:41 Li, Qing said the following: > Building kernel on 8.1-RELEASE should not require a buildworld, right ? > > Or there have been changes committed since that would mandate a > buildworld? See UPDATING entry 20100915 (for head). Sorry for the inconvenience. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 12:52:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F41D2106566C; Thu, 18 Nov 2010 12:52:10 +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 D846E8FC13; Thu, 18 Nov 2010 12:52:09 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23072; Thu, 18 Nov 2010 14:52:07 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE52177.3020306@freebsd.org> Date: Thu, 18 Nov 2010 14:52:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "O. Hartmann" References: <4CE50849.106@zedat.fu-berlin.de> In-Reply-To: <4CE50849.106@zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 12:52:11 -0000 on 18/11/2010 13:04 O. Hartmann said the following: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this will make > it in due time to FreeBSD's kernel. Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. P.S. What is the due time, BTW? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 13:38:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7745106566B for ; Thu, 18 Nov 2010 13:38:16 +0000 (UTC) (envelope-from dnebdal@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 3884D8FC0A for ; Thu, 18 Nov 2010 13:38:15 +0000 (UTC) Received: by gyg13 with SMTP id 13so1874051gyg.13 for ; Thu, 18 Nov 2010 05:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rSripufxnW3W+X/Ig1gTgvvhSpznakKfthQVxZohjSU=; b=ZNmeIzfeEtiJky0GLyFZLtuRMNWGlkhhrvA7Kw/qc7lLe9ggrT/q5J1y4nXrPMlmJ8 7WuU4CSnQpVDfRA15OJY/PdLVvS6BAk+7uvY7833JundtdQtnQrGNAm4N0MZ7OKNx/o3 xTrjDGBRS+JaOXPhC3rPHYkGic9ouLtvdXEro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qoNjQtoDHkb3yFqKxcbfLPEf0DO3hE8GHOSDY/xt7d71NmEzeKU7leOJfk0+Is5svS uuuipRCMJtk6K8UB8Q7gDr/SLHWEVxUjSqRwYuzI2jSVHJxTJurG8hJFwOM9dh+pgPzz HCoQLRHxpcT8AIqeqx0pqN+S2akz5LpOdJyLk= MIME-Version: 1.0 Received: by 10.151.42.16 with SMTP id u16mr1313341ybj.97.1290087495436; Thu, 18 Nov 2010 05:38:15 -0800 (PST) Received: by 10.151.114.4 with HTTP; Thu, 18 Nov 2010 05:38:15 -0800 (PST) In-Reply-To: <4CE51CDA.6010202@freebsd.org> References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> Date: Thu, 18 Nov 2010 15:38:15 +0200 Message-ID: From: Daniel Nebdal To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: George Neville-Neil , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 13:38:16 -0000 On Thu, Nov 18, 2010 at 2:32 PM, Andriy Gapon wrote: > on 18/11/2010 05:53 George Neville-Neil said the following: >> >> On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: >> >>> >>> Many modern processors provide APERF and MPERF MSRs which allow to easi= ly and >>> reliable calculate average CPU performance level over some interval of = time. >>> This also allows to notice things like performance boost, which is gene= rally >>> hidden from software. >>> What would be a proper place to add code that would measure APERF/MPERF= ratio? >>> When should trigger such a measurement and over what interval? >>> Ideas? >> >> Can you point me at documentation for this? =A0 This sounds a lot like >> hwpmc(4) and I wonder if we can make these available in the same way. > > Actually it feels more cpufreq-ish to me. > This feature is documented in, e.g., Intel Software Developer's Manual vo= lume 3A, > section 14.2 P-STATE HARDWARE COORDINATION. > Just for the sake of gathering information here: What they offer are two (64-bit, wrapping) counters; one that increases at a constant rate, and one that increases in proportion to the current performance of the CPU, so that APERF/MPERF =3D fraction of max possible performance the CPU has offered since the last time the counters were zeroed. Intel specifically suggests multiplying that with the observed CPU load over the same time period to get an absolute CPU load number, and using that to pick a suitable P-state. On a tangent, I wonder if you can get APERF>MPERF if you're using an i5/i7 and their dynamic/automatic overclocking kicks in? As for what to do with it, it sounds like it would make sense as an alternate data source for powerd? --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 14:10:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B504106566C; Thu, 18 Nov 2010 14:10:49 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 71EAC8FC14; Thu, 18 Nov 2010 14:10:48 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA24448; Thu, 18 Nov 2010 16:10:39 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE533DE.7010401@freebsd.org> Date: Thu, 18 Nov 2010 16:10:38 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Daniel Nebdal References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 14:10:49 -0000 on 18/11/2010 15:38 Daniel Nebdal said the following: > Just for the sake of gathering information here: > What they offer are two (64-bit, wrapping) counters; one that > increases at a constant rate, and one that increases in proportion to > the current performance of the CPU, so that APERF/MPERF = fraction of > max possible performance the CPU has offered since the last time the > counters were zeroed. Intel specifically suggests multiplying that > with the observed CPU load over the same time period to get an > absolute CPU load number, and using that to pick a suitable P-state. > > On a tangent, I wonder if you can get APERF>MPERF if you're using an > i5/i7 and their dynamic/automatic overclocking kicks in? Yes, I believe so. At the very least AMD explicitly documents that to be the case when Core Performance Boost feature is activated. > As for what to do with it, it sounds like it would make sense as an > alternate data source for powerd? Yes, indeed. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 14:15:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6BB4106564A; Thu, 18 Nov 2010 14:15:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 7782E8FC0C; Thu, 18 Nov 2010 14:15:54 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PJ5HF-0007wm-5D; Thu, 18 Nov 2010 09:15:53 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <4CE51CDA.6010202@freebsd.org> Date: Thu, 18 Nov 2010 09:15:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2A8C55CE-AD3A-419E-9028-EF8407596329@neville-neil.com> References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 14:15:54 -0000 On Nov 18, 2010, at 07:32 , Andriy Gapon wrote: > on 18/11/2010 05:53 George Neville-Neil said the following: >>=20 >> On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: >>=20 >>>=20 >>> Many modern processors provide APERF and MPERF MSRs which allow to = easily and >>> reliable calculate average CPU performance level over some interval = of time. >>> This also allows to notice things like performance boost, which is = generally >>> hidden from software. >>> What would be a proper place to add code that would measure = APERF/MPERF ratio? >>> When should trigger such a measurement and over what interval? >>> Ideas? >>=20 >> Can you point me at documentation for this? This sounds a lot like >> hwpmc(4) and I wonder if we can make these available in the same way. >=20 > Actually it feels more cpufreq-ish to me. > This feature is documented in, e.g., Intel Software Developer's Manual = volume 3A, > section 14.2 P-STATE HARDWARE COORDINATION. Ah, yes, quite right on cpufreq etc. Thanks for the documentation = pointer though. Best, George From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 18:23:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 25C25106566B; Thu, 18 Nov 2010 18:23:24 +0000 (UTC) Date: Thu, 18 Nov 2010 18:23:24 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20101118182324.GA36312@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE52177.3020306@freebsd.org> Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 18:23:24 -0000 On Thu Nov 18 10, Andriy Gapon wrote: > on 18/11/2010 13:04 O. Hartmann said the following: > > On 11/18/10 02:30, grarpamp wrote: > >> Just documenting regarding interactive performance things. > >> This one's from Linux. > >> > >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > > > Well, > > it would be nice to have those improvements in FreeBSD, but I doubt this will make > > it in due time to FreeBSD's kernel. > > Well, I think that those improvements apply only to a very specific usage pattern > and are greatly over-hyped. you think so? judging from the videos the changes are having a huge impact imo. cheers. alex btw: i posted a similar thread on freebsd-backers@, but nobody seemed interested in it. subject line is "sched_autogroup_enabled". > > P.S. What is the due time, BTW? > > -- > Andriy Gapon -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 18:42:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4B701065694; Thu, 18 Nov 2010 18:42:50 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6409A8FC15; Thu, 18 Nov 2010 18:42:50 +0000 (UTC) Received: by qwd6 with SMTP id 6so49742qwd.13 for ; Thu, 18 Nov 2010 10:42:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.196.67 with SMTP id ef3mr878967qab.160.1290105769592; Thu, 18 Nov 2010 10:42:49 -0800 (PST) Received: by 10.220.16.199 with HTTP; Thu, 18 Nov 2010 10:42:49 -0800 (PST) X-Originating-IP: [128.95.133.115] In-Reply-To: <39F4F32E-A30C-47F3-AD69-F7777A7E30A8@mac.com> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <39F4F32E-A30C-47F3-AD69-F7777A7E30A8@mac.com> Date: Thu, 18 Nov 2010 10:42:49 -0800 Message-ID: From: Rob Farmer To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 18:42:51 -0000 On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote: > Frankly, I'm also turned off by the attempt to popup a full page ad in ad= dition to the rest of the advertising content which surrounds what is nomin= ally supposed to be the real content. =A0That doesn't mean there is anythin= g wrong with the patch or the notion of adjusting the scheduler, but I don'= t see any value added from these phoronix.com links. Most stuff on Phoronix is of dubious value, and they have outright lied about stuff in the past, in order to drum up advertising business (such as Steam on Linux, which Value has consistently said isn't happening). --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 18:45:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04BDD106564A; Thu, 18 Nov 2010 18:45:33 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id CADCE8FC0C; Thu, 18 Nov 2010 18:45:32 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 003EC37B444; Thu, 18 Nov 2010 12:28:52 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 67BA761C42; Thu, 18 Nov 2010 12:28:52 -0600 (CST) Date: Thu, 18 Nov 2010 12:28:52 -0600 From: "Matthew D. Fuller" To: Alexander Best Message-ID: <20101118182852.GR63683@over-yonder.net> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118182324.GA36312@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96.4 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: "O. Hartmann" , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 18:45:33 -0000 On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of Alexander Best, and lo! it spake thus: > > judging from the videos the changes are having a huge impact imo. Well, my (admittedly limited, and certainly anecdotal) experience is that Linux's interactive response when under heavy load was always much worse than FreeBSD's. So maybe that's just them catching up to where we already are ;) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 18:56:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id ABCF7106566C; Thu, 18 Nov 2010 18:56:35 +0000 (UTC) Date: Thu, 18 Nov 2010 18:56:35 +0000 From: Alexander Best To: "Matthew D. Fuller" Message-ID: <20101118185635.GA43706@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118182852.GR63683@over-yonder.net> Cc: "O. Hartmann" , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 18:56:35 -0000 On Thu Nov 18 10, Matthew D. Fuller wrote: > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > Alexander Best, and lo! it spake thus: > > > > judging from the videos the changes are having a huge impact imo. > > Well, my (admittedly limited, and certainly anecdotal) experience is > that Linux's interactive response when under heavy load was always > much worse than FreeBSD's. So maybe that's just them catching up to > where we already are ;) well...i tried playing back a 1080p vide files while doing `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. it might be possible that linux'es interactivity was worse than freebsd's, but still this patch should be evaluated for freebsd. in this particular case it seems linux now does better than freebsd. cheers. alex > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 18:58:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 851231065674 for ; Thu, 18 Nov 2010 18:58:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6D99B8FC24 for ; Thu, 18 Nov 2010 18:58:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LC300MB5GP5J620@asmtp026.mac.com> for freebsd-current@freebsd.org; Thu, 18 Nov 2010 10:58:20 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011180154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-18_08:2010-11-18, 2010-11-18, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: Date: Thu, 18 Nov 2010 10:58:17 -0800 Message-id: <5ED46E71-B0C1-459E-976C-D64234002F03@mac.com> References: To: Garrett Cooper X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Current Subject: Re: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 18:58:25 -0000 On Nov 17, 2010, at 4:10 PM, Garrett Cooper wrote: > > Hi Marcel, > Do you have any examples that use nfs rootfs's out of the box that > work with the new logic that don't involve creating an mfsroot? I keep > on running into this error with vfs.root.mountfrom=nfs (previously on > CURRENT it would just try to mount nfs via nfs_mount in the NFS client > without any complaints): The syntax is $fs:$dev. For NFS $dev can be empty, leaving "nfs:". The problem is with there not being a colon after nfs in your case. This could be a change in behaviour from before, which probably needs a fix. I'll look into it... > I don't run into this error when I unset this variable sometimes > (it boots up multiuser and all is happy, hunky dory when I manually > query this variable from the pxeboot loader, but not when I don't... > it's weird). > It seems to ignore the directives in mount.conf: > > # cat mount.conf > .onfail continue > .ask The filename to use is "/.mount.conf". Notice the period. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:02:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AFFE4106566B; Thu, 18 Nov 2010 19:02:09 +0000 (UTC) Date: Thu, 18 Nov 2010 19:02:09 +0000 From: Alexander Best To: Rob Farmer Message-ID: <20101118190209.GA45054@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <39F4F32E-A30C-47F3-AD69-F7777A7E30A8@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 19:02:09 -0000 On Thu Nov 18 10, Rob Farmer wrote: > On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote: > > Frankly, I'm also turned off by the attempt to popup a full page ad in addition to the rest of the advertising content which surrounds what is nominally supposed to be the real content.  That doesn't mean there is anything wrong with the patch or the notion of adjusting the scheduler, but I don't see any value added from these phoronix.com links. > > Most stuff on Phoronix is of dubious value, and they have outright > lied about stuff in the past, in order to drum up advertising business > (such as Steam on Linux, which Value has consistently said isn't > happening). so we need a trusted source to check whether the impact of the ~200 line patch as claimed by phoronix remains valid. can anybody test this? or provide links to independant benchmark results? cheers. alex > > -- > Rob Farmer -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:09:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E28106566C; Thu, 18 Nov 2010 19:09:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BD2D28FC1C; Thu, 18 Nov 2010 19:09:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA28332; Thu, 18 Nov 2010 21:09:18 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE579DD.2030406@freebsd.org> Date: Thu, 18 Nov 2010 21:09:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: ideas for _PSD/_CSD/_TSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 19:09:20 -0000 I am trying to solicit some architectural/design ideas for implementing logic that would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. Well, I am primarily interested in _PSD, but I think that some general principles could be shared. In simple terms. Currently we do only the "global" P-state management. cpufreq advertises a common set of frequencies/P-states and a single P-state/frequency is set on all (logical) processors by e.g. powerd based on global system load. The downsides are obvious, I think. Modern systems can provide _PSD method which describes grouping of logical processors into P-state domains and nature of dependency between the processors in the domain. E.g. on some systems putting a single processor from the domain into a Px state results in all the processors being put into that state. On other systems, all processors have to be put into the same state for it to become effective. On yet other systems there could be no coordination required between the processors (even when they are all cores in the same package), so each would be placed in its own domain. I think that this issue may get more prominence because of the new technologies that combine power saving with "turbo boosting". E.g. there could be a technology where some processor's performance would only be boosted if other processors are at or above some state Pt. With current cpufreq design we would not be able to take an advantage of that, because we always put all the processors into the same state. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:16:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 058291065670; Thu, 18 Nov 2010 19:16:41 +0000 (UTC) Date: Thu, 18 Nov 2010 19:16:41 +0000 From: Alexander Best To: "Robert N. M. Watson" Message-ID: <20101118191640.GA48394@freebsd.org> References: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0F03.10703@freebsd.org> <20101115221924.GA38676@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Kostik Belousov , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 19:16:41 -0000 On Tue Nov 16 10, Robert N. M. Watson wrote: > > On 15 Nov 2010, at 22:19, Alexander Best wrote: > > > thanks for all your help. i've recently switched to chromium 6.0.472.63 > > and so far my computer has been very stable. > > > > if i experience more lock ups i'll let you know and try to figure out a way to > > gain access to some more debugging data. > > I'd prefer we try to figure out why your system was crashing now -- the kernel bug has not gone away just because Chromium is no longer triggering it. Working around the bug means someone else gets to run into it later -- perhaps when it's 9.0-RELEASE rather than 9-CURRENT... i'm really sorry, but this is a problem ~ 90% of desktop users have: 1) we only have 1 computer 2) we can't access our computer via some other box via ssh or something 3) we don't have serial cables or firewire cables so it seems in this situation a complete deadlock *cannot* be analyzed. the idea of dumping the memory to a usb stick after a hard reboot thus seems so attractive to users like me. still the question is: how can we use such a complete memory dump? i don't think it's as easy as loading it into kdb, is it? cheers. alex > > Robert -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:21:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2CF106566C; Thu, 18 Nov 2010 19:21:46 +0000 (UTC) (envelope-from lwindschuh@googlemail.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 A2FC28FC0A; Thu, 18 Nov 2010 19:21:45 +0000 (UTC) Received: by gxk9 with SMTP id 9so2182912gxk.13 for ; Thu, 18 Nov 2010 11:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=n2z2pECZ4dz5Pikhase/txALObjsijI69ae9TSt7c/o=; b=VX3EyXddnk6u7Mz6Go7lq4XcC88RZuAt7xFtqz0FaOoD1SEt1QQOPNj4ynK0PdUlUY j5TX6BeFzXa1vggkiY5t0VfgRZf6W5H9KfoTbdUouv+gk9ccLYCEIHY0uXkvhqu4e+QL 6yCz+gCqIouoPy3yXi8FXnETPoMoCSK9aCoaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r7zFMpZlKPl0hSIJafNGmrlsJkGkvb4cL++NrTsYTvPpIqjVSMT291tIuoppJhCxr4 8PcL0Ij0c3sU+PMYq3nrLSR08JoDSeDl0dlrjSxDi44Okmq9gmpVop36Wkc3lJ9BboQo kJARhQgpCU2PKRmgMt16mpZmERoHnKflLcsrI= MIME-Version: 1.0 Received: by 10.42.240.195 with SMTP id lb3mr657505icb.114.1290106505346; Thu, 18 Nov 2010 10:55:05 -0800 (PST) Received: by 10.231.192.139 with HTTP; Thu, 18 Nov 2010 10:55:05 -0800 (PST) In-Reply-To: <4CE52177.3020306@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> Date: Thu, 18 Nov 2010 19:55:05 +0100 Message-ID: From: Lucius Windschuh To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 19:21:46 -0000 2010/11/18 Andriy Gapon : > [Grouping of processes into TTY groups] > > Well, I think that those improvements apply only to a very specific usage pattern > and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using "idprio 1 $cmd" as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. Regards, Lucius From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:40:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C16106566B; Thu, 18 Nov 2010 19:40:16 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 262E98FC12; Thu, 18 Nov 2010 19:40:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LC300F0LFU76910@asmtp024.mac.com>; Thu, 18 Nov 2010 10:39:44 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-18_08:2010-11-18, 2010-11-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011180150 From: Chuck Swiger In-reply-to: <20101118182324.GA36312@freebsd.org> Date: Thu, 18 Nov 2010 10:39:43 -0800 Message-id: <39F4F32E-A30C-47F3-AD69-F7777A7E30A8@mac.com> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1082) Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-performance@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: Thu, 18 Nov 2010 19:40:16 -0000 On Nov 18, 2010, at 10:23 AM, Alexander Best wrote: > On Thu Nov 18 10, Andriy Gapon wrote: >> on 18/11/2010 13:04 O. Hartmann said the following: >>> On 11/18/10 02:30, grarpamp wrote: >>>> Just documenting regarding interactive performance things. >>>> This one's from Linux. >>>> >>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>> >>> Well, >>> it would be nice to have those improvements in FreeBSD, but I doubt this will make >>> it in due time to FreeBSD's kernel. >> >> Well, I think that those improvements apply only to a very specific usage pattern >> and are greatly over-hyped. > > you think so? judging from the videos the changes are having a huge impact imo. > > cheers. > alex > > btw: i posted a similar thread on freebsd-backers@, but nobody seemed > interested in it. subject line is "sched_autogroup_enabled". I attempted to find reliable benchmarks or even an idea as to what they thought they were measuring, because a sentence like the following: Tests done by Mike show the maximum latency dropping by over ten times and the average latency of the desktop by about 60 times. ...isn't mathematically possible, I'm pretty sure. Frankly, I'm also turned off by the attempt to popup a full page ad in addition to the rest of the advertising content which surrounds what is nominally supposed to be the real content. That doesn't mean there is anything wrong with the patch or the notion of adjusting the scheduler, but I don't see any value added from these phoronix.com links. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 19:44:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137571065693; Thu, 18 Nov 2010 19:44:54 +0000 (UTC) (envelope-from fjwcash@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 8480A8FC16; Thu, 18 Nov 2010 19:44:53 +0000 (UTC) Received: by gyg13 with SMTP id 13so2209392gyg.13 for ; Thu, 18 Nov 2010 11:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1DooHdNPKrh28hk1XLwU+v4woJgksR0RKFN0Bki/nCY=; b=D2ouUGPS+KR4g0PuiRNaJ0KERqTr8ia+KxQxvRBxNq6rZc4iaELBVHfo1AtcuxAjw4 uFmGvN4KhXk0VKqeuKmiKc/ONZRQIkp6by/e2Yz+axrkZfPEkUUapyl6i1tXF4097jw3 9R7tSTbmUOLkX6DdmqjvDhV9fj/tHu5qAiOzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aCgDIQDcoFJ6ERhJwppKnKfxjwvsqpLIxJzSVpuEIFOUKFgbBKz2KjML2uJdmILE8U CR21OjW66uJkUEIbvd04fBoE4EoGYH+jnw1heSpmlRIdYCqf7W34y3GgwxlpiI8v9YvF EONxQ1pKod5u9UIR3/LVL8SWaFJO2VnTab/7I= MIME-Version: 1.0 Received: by 10.100.14.8 with SMTP id 8mr766406ann.65.1290107638130; Thu, 18 Nov 2010 11:13:58 -0800 (PST) Received: by 10.90.211.7 with HTTP; Thu, 18 Nov 2010 11:13:57 -0800 (PST) In-Reply-To: <20101118185635.GA43706@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> Date: Thu, 18 Nov 2010 11:13:57 -0800 Message-ID: From: Freddie Cash To: Alexander Best Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable , Andriy Gapon , FreeBSD Current , "Matthew D. Fuller" , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 19:44:54 -0000 On Thu, Nov 18, 2010 at 10:56 AM, Alexander Best wrot= e: > On Thu Nov 18 10, Matthew D. Fuller wrote: >> On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of >> Alexander Best, and lo! it spake thus: >> > >> > judging from the videos the changes are having a huge impact imo. >> >> Well, my (admittedly limited, and certainly anecdotal) experience is >> that Linux's interactive response when under heavy load was always >> much worse than FreeBSD's. =C2=A0So maybe that's just them catching up t= o >> where we already are =C2=A0 ;) > > well...i tried playing back a 1080p vide files while doing > `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfec= t. > > it might be possible that linux'es interactivity was worse than freebsd's= , > but still this patch should be evaluated for freebsd. in this particular = case > it seems linux now does better than freebsd. Maybe I'm just a lowly user and don't fully understand the issue, but isn't this the whole reason for having /usr/bin/nice installed? As in, if you don't want your make job to hog resources, then use nice to run it in the background. How does the work on the geom_sched (for I/O scheduling) play into this? Am I missing something fundamental to the issue in question? Also, does this really need to be cross-posted to -current, -hackers, and -performance? --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 20:20:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1320A106564A; Thu, 18 Nov 2010 20:20:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-16.mx.aerioconnect.net [216.240.47.76]) by mx1.freebsd.org (Postfix) with ESMTP id E49368FC0C; Thu, 18 Nov 2010 20:20:22 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAIKKMB0024055; Thu, 18 Nov 2010 12:20:22 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 31AEF2D601A; Thu, 18 Nov 2010 12:20:20 -0800 (PST) Message-ID: <4CE58A86.6010406@freebsd.org> Date: Thu, 18 Nov 2010 12:20:22 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lucius Windschuh References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 20:20:23 -0000 On 11/18/10 10:55 AM, Lucius Windschuh wrote: > 2010/11/18 Andriy Gapon: >> [Grouping of processes into TTY groups] >> >> Well, I think that those improvements apply only to a very specific usage pattern >> and are greatly over-hyped. > But there are serious issue if you use FreeBSD as a desktop OS with > SMP and SCHED_ULE, or? > Because currently, my machine is barely usable if a compile job with > parallelism is running. Movies stutter, Firefox hangs. And even nice > -n 20 doesn't do the job in every case, as +20 seems not to be the > idle priority anymore?!? > And using "idprio 1 $cmd" as a workaround is, well, a kludge. > I am not sure if TTY grouping is the right solution, if you look at > potentially CPU-intensive GUI applications that all run on the same > TTY (or no TTY at all? Same problem). > Maybe, we could simply enhance the algorithm that decides if a task is > interactive? That would also improve the described situation. tty grouping is a variant of what we used to have at one stage which is a "kernel schedulable entity group".. KSEG the idea is that all items in a group share some characteristic and some amount of resources. We stripped the KSEG out of the picture because it really complicated the picture. > Regards, > > Lucius > _______________________________________________ > 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 18 20:29:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C85106566B; Thu, 18 Nov 2010 20:29:08 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDDB8FC1C; Thu, 18 Nov 2010 20:29:05 +0000 (UTC) Received: from mail.herbelot.nom (unknown [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id DB7F782260; Thu, 18 Nov 2010 21:28:59 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id oAIKSoc2026327; Thu, 18 Nov 2010 21:28:51 +0100 (CET) From: Thierry Herbelot To: "Bjoern A. Zeeb" Date: Thu, 18 Nov 2010 21:28:44 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; amd64; ; ) References: <201011170627.28025.thierry.herbelot@free.fr> <201011171936.10764.thierry.herbelot@free.fr> <20101118081512.K24596@maildrop.int.zabbadoz.net> In-Reply-To: <20101118081512.K24596@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201011182128.44827.thierry.herbelot@free.fr> Cc: freebsd-current@freebsd.org, FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 20:29:08 -0000 "Bjoern A. Zeeb" a =E9crit > On Wed, 17 Nov 2010, Thierry Herbelot wrote: > > As promised, here are the full logs (in attachment) > >=20 > > This is a serial console log showing the command loop that triggers the > > bug on a debug kernel and ensuing DDB session. > >=20 > > the obvious problem line is : > > routetbl 2684 303890K 3469 > >=20 > > (further tests showed an increase of the routetbl malloc zone by 4MBytes > > for each vnet jail creation/destruction cycle) >=20 > Hmm, I had fixed that (somewhere). I'll see where the patch went. You > are on 8.1-RELEASE or -STABLE? This will be for a -release, thus 8.1 for now, but we will switch to 8.2 AS= AP Thanks TfH >=20 > /bz From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 20:55:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F357106564A; Thu, 18 Nov 2010 20:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 26A5A8FC0A; Thu, 18 Nov 2010 20:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DD8F541C747; Thu, 18 Nov 2010 21:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id UHOzSxamPhup; Thu, 18 Nov 2010 21:55:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 061B141C750; Thu, 18 Nov 2010 21:55:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1828A4448F3; Thu, 18 Nov 2010 20:51:23 +0000 (UTC) Date: Thu, 18 Nov 2010 20:51:22 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Thierry Herbelot In-Reply-To: <201011182128.44827.thierry.herbelot@free.fr> Message-ID: <20101118203639.K24596@maildrop.int.zabbadoz.net> References: <201011170627.28025.thierry.herbelot@free.fr> <201011171936.10764.thierry.herbelot@free.fr> <20101118081512.K24596@maildrop.int.zabbadoz.net> <201011182128.44827.thierry.herbelot@free.fr> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-64664707-1290113482=:24596" Cc: freebsd-current@freebsd.org, FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 20:55:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-64664707-1290113482=:24596 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 18 Nov 2010, Thierry Herbelot wrote: > "Bjoern A. Zeeb" a =E9crit >> On Wed, 17 Nov 2010, Thierry Herbelot wrote: >>> As promised, here are the full logs (in attachment) >>> >>> This is a serial console log showing the command loop that triggers the >>> bug on a debug kernel and ensuing DDB session. >>> >>> the obvious problem line is : >>> routetbl 2684 303890K 3469 >>> >>> (further tests showed an increase of the routetbl malloc zone by 4MByte= s >>> for each vnet jail creation/destruction cycle) >> >> Hmm, I had fixed that (somewhere). I'll see where the patch went. You >> are on 8.1-RELEASE or -STABLE? > > This will be for a -release, thus 8.1 for now, but we will switch to 8.2 = ASAP Well wait; I am not sure the changes are in SVN at all. I'll get back to you. /bz --=20 Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --0-64664707-1290113482=:24596-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 21:17:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFA61065670 for ; Thu, 18 Nov 2010 21:17:51 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BAC228FC1C for ; Thu, 18 Nov 2010 21:17:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJBrY-0006bY-RL for freebsd-current@freebsd.org; Thu, 18 Nov 2010 22:17:48 +0100 Received: from cpe-188-129-90-233.dynamic.amis.hr ([188.129.90.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2010 22:17:48 +0100 Received: from ivoras by cpe-188-129-90-233.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2010 22:17:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 18 Nov 2010 22:17:30 +0100 Lines: 4 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-90-233.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 Subject: Testing /dev/fido ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 21:17:51 -0000 I have an IPMI-enabled server with BMC watchdog, and if I understand it correctly, /dev/fido will be attached as the result of loading ipmi.ko. Is there some easy way to test if everything works? From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 20:48:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18B91065670; Thu, 18 Nov 2010 20:48:22 +0000 (UTC) (envelope-from ohartman@mail.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 785AC8FC08; Thu, 18 Nov 2010 20:48:22 +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 <1PJAzl-0004gQ-Fu>; Thu, 18 Nov 2010 21:22:13 +0100 Received: from e178041009.adsl.alicedsl.de ([85.178.41.9] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PJAzl-0001Oq-90>; Thu, 18 Nov 2010 21:22:13 +0100 Message-ID: <4CE58AF4.5090304@mail.zedat.fu-berlin.de> Date: Thu, 18 Nov 2010 21:22:12 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Matthew D. Fuller" References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> In-Reply-To: <20101118182852.GR63683@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.41.9 X-Mailman-Approved-At: Thu, 18 Nov 2010 21:22:22 +0000 Cc: FreeBSD Stable , Andriy Gapon , FreeBSD Current , Alexander Best , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 20:48:22 -0000 On 11/18/10 19:28, Matthew D. Fuller wrote: > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > Alexander Best, and lo! it spake thus: >> >> judging from the videos the changes are having a huge impact imo. > > Well, my (admittedly limited, and certainly anecdotal) experience is > that Linux's interactive response when under heavy load was always > much worse than FreeBSD's. So maybe that's just them catching up to > where we already are ;) > > Wishful thinking? From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 20:48:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 474881065673; Thu, 18 Nov 2010 20:48:23 +0000 (UTC) (envelope-from ohartman@mail.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 F3C0A8FC0A; Thu, 18 Nov 2010 20:48:22 +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 <1PJB7Y-0005kz-SL>; Thu, 18 Nov 2010 21:30:16 +0100 Received: from e178041009.adsl.alicedsl.de ([85.178.41.9] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PJB7Y-0001nv-Na>; Thu, 18 Nov 2010 21:30:16 +0100 Message-ID: <4CE58CD8.2000407@mail.zedat.fu-berlin.de> Date: Thu, 18 Nov 2010 21:30:16 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lucius Windschuh References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.41.9 X-Mailman-Approved-At: Thu, 18 Nov 2010 21:22:31 +0000 Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 20:48:23 -0000 On 11/18/10 19:55, Lucius Windschuh wrote: > 2010/11/18 Andriy Gapon: >> [Grouping of processes into TTY groups] >> >> Well, I think that those improvements apply only to a very specific usage pattern >> and are greatly over-hyped. > > But there are serious issue if you use FreeBSD as a desktop OS with > SMP and SCHED_ULE, or? > Because currently, my machine is barely usable if a compile job with > parallelism is running. Movies stutter, Firefox hangs. And even nice > -n 20 doesn't do the job in every case, as +20 seems not to be the > idle priority anymore?!? > And using "idprio 1 $cmd" as a workaround is, well, a kludge. > I am not sure if TTY grouping is the right solution, if you look at > potentially CPU-intensive GUI applications that all run on the same > TTY (or no TTY at all? Same problem). > Maybe, we could simply enhance the algorithm that decides if a task is > interactive? That would also improve the described situation. > > Regards, > > Lucius Stuttering Response, being stuck for over 20 seconds also happens when I start updating the OS' sources via svn. This happens on all boxes, some of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those phenomena are most seen when you interact with the machine via X11 clients. I think it's hard to realize if a server only does console I/O, but console also seems to be stuck sometimes. It would be worth checking this with some 'benchmark'. X11 in its kind of oldish incarnation on FreeBSD seems to contribute most to those slowdowns, what so ever. From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 21:24:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9D3106567A for ; Thu, 18 Nov 2010 21:24:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A20BF8FC0C for ; Thu, 18 Nov 2010 21:24:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJBy0-0004H8-Rx for freebsd-current@freebsd.org; Thu, 18 Nov 2010 22:24:28 +0100 Received: from static-78-8-147-77.ssp.dialog.net.pl ([78.8.147.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2010 22:24:28 +0100 Received: from mwisnicki+freebsd by static-78-8-147-77.ssp.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Nov 2010 22:24:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Wisnicki Date: Thu, 18 Nov 2010 21:24:18 +0000 (UTC) Lines: 15 Message-ID: References: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0E7F.3060406@freebsd.org> <20101116224156.GA52556@freebsd.org> <20101117033520.GA95666@freebsd.org> <4CE4B9E5.3000005@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: static-78-8-147-77.ssp.dialog.net.pl User-Agent: Pan/0.133 (House of Butterflies) Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 21:24:31 -0000 On Wed, 17 Nov 2010 21:30:13 -0800, Julian Elischer wrote: > On 11/17/10 12:15 PM, Marcin Wisnicki wrote: >>> >> Probably not. I thought about it a bit more and realized that you will >> miss state of cpu registers which is rather important. >> >> How does debugging over firewire work if it only has access to host RAM >> ? > > registers are saved to ram as part of exception handling.. > So I guess it means it's not possible to debug complete lockup (caused by driver) where no panic() occured ? From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:04:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730AB106564A; Thu, 18 Nov 2010 22:04:27 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEC48FC18; Thu, 18 Nov 2010 22:04:24 +0000 (UTC) Received: from mail.herbelot.nom (unknown [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id 38801822A0; Thu, 18 Nov 2010 23:04:18 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id oAIM4CO3010277; Thu, 18 Nov 2010 23:04:12 +0100 (CET) From: Thierry Herbelot To: "Bjoern A. Zeeb" Date: Thu, 18 Nov 2010 23:04:06 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.3; amd64; ; ) References: <201011170627.28025.thierry.herbelot@free.fr> <201011182128.44827.thierry.herbelot@free.fr> <20101118203639.K24596@maildrop.int.zabbadoz.net> In-Reply-To: <20101118203639.K24596@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201011182304.06712.thierry.herbelot@free.fr> Cc: freebsd-current@freebsd.org, FreeBSD virtualization mailing list Subject: Re: VIMAGE: Freed UMA keg was not empty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 22:04:27 -0000 "Bjoern A. Zeeb" a =E9crit > On Thu, 18 Nov 2010, Thierry Herbelot wrote: > > "Bjoern A. Zeeb" a =E9crit > >=20 > >> On Wed, 17 Nov 2010, Thierry Herbelot wrote: > >>> As promised, here are the full logs (in attachment) > >>>=20 > >>> This is a serial console log showing the command loop that triggers t= he > >>> bug on a debug kernel and ensuing DDB session. > >>>=20 > >>> the obvious problem line is : > >>> routetbl 2684 303890K 3469 > >>>=20 > >>> (further tests showed an increase of the routetbl malloc zone by > >>> 4MBytes for each vnet jail creation/destruction cycle) > >>=20 > >> Hmm, I had fixed that (somewhere). I'll see where the patch went. You > >> are on 8.1-RELEASE or -STABLE? > >=20 > > This will be for a -release, thus 8.1 for now, but we will switch to 8.2 > > ASAP >=20 > Well wait; I am not sure the changes are in SVN at all. I'll get back > to you. OK for us : we are still in the process of deploying the solution, but stil= l=20 we will test any patch you can forward ;-) TfH >=20 > /bz From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:20:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC11106564A; Thu, 18 Nov 2010 22:20:06 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id CC6D18FC13; Thu, 18 Nov 2010 22:20:05 +0000 (UTC) Received: from [10.1.0.198] (dsl081-053-082.sfo1.dsl.speakeasy.net [64.81.53.82]) by mail.root.org (Postfix) with ESMTP id A98B06ECE; Thu, 18 Nov 2010 22:02:44 +0000 (UTC) Message-ID: <4CE5A282.1000300@root.org> Date: Thu, 18 Nov 2010 14:02:42 -0800 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <4CE579DD.2030406@freebsd.org> In-Reply-To: <4CE579DD.2030406@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ideas for _PSD/_CSD/_TSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 22:20:06 -0000 On 11/18/2010 11:09 AM, Andriy Gapon wrote: > I am trying to solicit some architectural/design ideas for implementing logic that > would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. > Well, I am primarily interested in _PSD, but I think that some general principles > could be shared. > > In simple terms. > Currently we do only the "global" P-state management. cpufreq advertises a common > set of frequencies/P-states and a single P-state/frequency is set on all (logical) > processors by e.g. powerd based on global system load. > The downsides are obvious, I think. > > Modern systems can provide _PSD method which describes grouping of logical > processors into P-state domains and nature of dependency between the processors in > the domain. E.g. on some systems putting a single processor from the domain into > a Px state results in all the processors being put into that state. On other > systems, all processors have to be put into the same state for it to become > effective. On yet other systems there could be no coordination required between > the processors (even when they are all cores in the same package), so each would > be placed in its own domain. > > I think that this issue may get more prominence because of the new technologies > that combine power saving with "turbo boosting". E.g. there could be a technology > where some processor's performance would only be boosted if other processors are > at or above some state Pt. With current cpufreq design we would not be able to > take an advantage of that, because we always put all the processors into the same > state. As you can see from the codebase, cpufreq was designed with this model in mind. I spent a lot of work adding the cpu devices to newbus in order to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq setting. Of course, there weren't any asymmetrical CPU Px states back then so calculation of levels is shared as you point out. But since it's done in cpufreq attach(), it is easy to make that independent while still merging states with global settings (e.g., p4tcc relative levels that apply system-wide, not per-cpu). What you want is to have a flag that indicates if Px states are global or not. If global, you can still attach a cpufreq device to each cpu but make changing any of their settings loop through changing all cpu settings equally. This is how it currently works. If the flag is false, then only apply a setting to the device it was received on. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:28:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF154106566B; Thu, 18 Nov 2010 22:28:42 +0000 (UTC) (envelope-from kabaev@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 437A18FC0C; Thu, 18 Nov 2010 22:28:41 +0000 (UTC) Received: by qyk29 with SMTP id 29so451664qyk.13 for ; Thu, 18 Nov 2010 14:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=G6gTXaaqCJpPu9PlygEv7NCUGM5qj47slKRFxtsO51o=; b=sTD0gjkmYL2VuBDq/OYTJrZMLTh6XnuEltxE1cO5xeiLFncW3q15CNSA9OVYE2mb7L C9yURePw/SfhKBHkS8n6TYnQNBcVdA0JWeHpZduYNiUm+XcOmJgLsq3IAZkpflR13+Et mfESpG/2wkrCZGVn+nBWqH91rA/Jb/nIilcxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=WU/bTCIJtdnrZPa3Ab0ZO7nW/xgTW2BsDas+v7+Lum+TWrmqbQ9Yo2Fj29VQYzWqC9 OY3KevhjC95IwkfviMuMKlUnZ3xzbwblakk6zzwi2NIskCGn+vJMt1UjKlmeUoshU4QD YmjXwRJ0boFlkQkdhwSbTYzS5PGI/vegOdBDk= Received: by 10.229.236.193 with SMTP id kl1mr1055289qcb.37.1290117992914; Thu, 18 Nov 2010 14:06:32 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id u2sm513935qcq.7.2010.11.18.14.06.30 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 14:06:31 -0800 (PST) Date: Thu, 18 Nov 2010 17:06:23 -0500 From: Alexander Kabaev To: Alexander Best Message-ID: <20101118170623.7f9c14f3@kan.dnsalias.net> In-Reply-To: <20101118185635.GA43706@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bizU4bG9u1fade+f3H9rMcX"; protocol="application/pgp-signature" Cc: FreeBSD Stable , "Matthew D. Fuller" , Current , Andriy Gapon , FreeBSD, freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 22:28:43 -0000 --Sig_/bizU4bG9u1fade+f3H9rMcX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 18 Nov 2010 18:56:35 +0000 Alexander Best wrote: > On Thu Nov 18 10, Matthew D. Fuller wrote: > > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > > Alexander Best, and lo! it spake thus: > > >=20 > > > judging from the videos the changes are having a huge impact imo. > >=20 > > Well, my (admittedly limited, and certainly anecdotal) experience is > > that Linux's interactive response when under heavy load was always > > much worse than FreeBSD's. So maybe that's just them catching up to > > where we already are ;) >=20 > well...i tried playing back a 1080p vide files while doing > `make -j64 buildkernel` and FreeBSD's interactivity seems far from > perfect. One thing that just begs to be asked: since when decoding 1080p became an interactive task? =20 --=20 Alexander Kabaev --Sig_/bizU4bG9u1fade+f3H9rMcX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFM5aNlQ6z1jMm+XZYRAuAzAJ4yOUUZa/HC1AFxowzBaYuagv92PwCgjT5Y XQ8fvbCjXoZstEJhQ7LJAMA= =e9CV -----END PGP SIGNATURE----- --Sig_/bizU4bG9u1fade+f3H9rMcX-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:55:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A94106566C; Thu, 18 Nov 2010 22:55:33 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 53A898FC08; Thu, 18 Nov 2010 22:55:33 +0000 (UTC) Received: by iwn39 with SMTP id 39so4240617iwn.13 for ; Thu, 18 Nov 2010 14:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RF7CCOjjlMdWa/4rvqXFs+lIae9Tv2SV06gC2Iwg5lw=; b=sg9Lue/o9Zt6bStriwYNlVqnQS2YrtrgKujqeiMr1Nkx+9Gm5XOyKRnTPAUPmC8+/+ u7LeESnuWOXHJgWbFDgZEGnxcOVQzTDWN89cyiRmIYuKoWtt5yHy0XOvs0887AYgM8bg cCG4fLaATSvJ2WRDRJgVFeFGYEGbw2SIP7em4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fMlbe/aYao6kyPml/TI2MMaYrkjEeXAYlqYo6rXpVarqxEHJR5QiqLRIjkLBNo37yI gnYRMlLahOhJilq+0MPIIKXkIkg537iFPno/+ZVvRsAWd3XoFWIsrrte00ij69wZWLr9 Fb8VOwpOraNIIU2yUONOG4sos62SPreFwEawg= MIME-Version: 1.0 Received: by 10.231.34.3 with SMTP id j3mr1454614ibd.100.1290120931782; Thu, 18 Nov 2010 14:55:31 -0800 (PST) Received: by 10.231.58.202 with HTTP; Thu, 18 Nov 2010 14:55:31 -0800 (PST) In-Reply-To: <20101118170623.7f9c14f3@kan.dnsalias.net> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> Date: Fri, 19 Nov 2010 00:55:31 +0200 Message-ID: From: Daniel Nebdal To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD@freebsd.org, Andriy Gapon , Current , "Matthew D. Fuller" , Alexander Best , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 22:55:34 -0000 On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote= : > On Thu, 18 Nov 2010 18:56:35 +0000 > Alexander Best wrote: > >> On Thu Nov 18 10, Matthew D. Fuller wrote: >> > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of >> > Alexander Best, and lo! it spake thus: >> > > >> > > judging from the videos the changes are having a huge impact imo. >> > >> > Well, my (admittedly limited, and certainly anecdotal) experience is >> > that Linux's interactive response when under heavy load was always >> > much worse than FreeBSD's. =A0So maybe that's just them catching up to >> > where we already are =A0 ;) >> >> well...i tried playing back a 1080p vide files while doing >> `make -j64 buildkernel` and FreeBSD's interactivity seems far from >> perfect. > > One thing that just begs to be asked: since when decoding 1080p became > an interactive task? > Strictly speaking it isn't - but displaying it is a timing-sensitive task that isn't CPU- or I/O-bound, and scheduling-wise that probably makes it more like the "fast response when woken up" interactive tasks than a CPU-bound non-interactive process. Decoding it into another file on the disk is in the latter category, of course - but I don't think that's what he meant. :) More on topic - while this was a tiny patch for Linux, it seems like it would take more work for us, since I don't believe either of the schedulers handles task groups in the required way. The linux patch was just "create task groups automatically", since they already had some suitable logic for scheduling based on task groups in their CFS scheduler. We would have to (re-)add that first, which is non-trivial. -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:59:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0D0E81065695; Thu, 18 Nov 2010 22:59:43 +0000 (UTC) Date: Thu, 18 Nov 2010 22:59:43 +0000 From: Alexander Best To: Alexander Kabaev Message-ID: <20101118225943.GB99684@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118170623.7f9c14f3@kan.dnsalias.net> Cc: FreeBSD Stable , Andriy Gapon , FreeBSD Current , "Matthew D. Fuller" , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 22:59:43 -0000 On Thu Nov 18 10, Alexander Kabaev wrote: > On Thu, 18 Nov 2010 18:56:35 +0000 > Alexander Best wrote: > > > On Thu Nov 18 10, Matthew D. Fuller wrote: > > > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > > > Alexander Best, and lo! it spake thus: > > > > > > > > judging from the videos the changes are having a huge impact imo. > > > > > > Well, my (admittedly limited, and certainly anecdotal) experience is > > > that Linux's interactive response when under heavy load was always > > > much worse than FreeBSD's. So maybe that's just them catching up to > > > where we already are ;) > > > > well...i tried playing back a 1080p vide files while doing > > `make -j64 buildkernel` and FreeBSD's interactivity seems far from > > perfect. > > One thing that just begs to be asked: since when decoding 1080p became > an interactive task? well i did exactly what they did in the video. watch a 1080p video and move the output window around while compiling the kernel. cheers. alex > > -- > Alexander Kabaev -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:12:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC0C106564A; Thu, 18 Nov 2010 23:12:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7A48C8FC12; Thu, 18 Nov 2010 23:12:38 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oAINCZUT012234; Thu, 18 Nov 2010 15:12:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oAINCZjX012233; Thu, 18 Nov 2010 15:12:35 -0800 (PST) (envelope-from sgk) Date: Thu, 18 Nov 2010 15:12:35 -0800 From: Steve Kargl To: Alexander Best Message-ID: <20101118231235.GA12137@troutmask.apl.washington.edu> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118225943.GB99684@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118225943.GB99684@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Stable , "Matthew D. Fuller" , FreeBSD Current , Andriy Gapon , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 23:12:38 -0000 On Thu, Nov 18, 2010 at 10:59:43PM +0000, Alexander Best wrote: > > well i did exactly what they did in the video. watch a 1080p video and move > the output window around while compiling the kernel. > It is trivial to bring ULE to its knees. If you have N cores then all you need is N+1 cpu intensive task. The issue has been known for a few years. http://freebsd.monkey.org/freebsd-current/200807/msg00278.html http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg65839.html -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:14:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 76E56106566C; Thu, 18 Nov 2010 23:14:11 +0000 (UTC) Date: Thu, 18 Nov 2010 23:14:11 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101118231411.GA5121@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: old references to vfs_mountroot_try() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 23:14:11 -0000 hi there, vfs_mountroot_try() seems to have been removed, yet the src still contains three references to it: vfs_mount.c:386 vfs_mount.c:723 freebsd32_misc.c:2368 cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:37:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12C62106566C; Thu, 18 Nov 2010 23:37:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1B128FC16; Thu, 18 Nov 2010 23:37:03 +0000 (UTC) Received: by wyb35 with SMTP id 35so3012065wyb.13 for ; Thu, 18 Nov 2010 15:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/WOlykv8xFvgtJ2Af3FWvX3HKveRtvuImXmPM9HGXJY=; b=qrDlMAKEckzjOxsssbpZj6y+Ao583W3U87S+32aG+AoZo/66aZ8UGdaZ0bTjVXXOQX rQOyC2nGzNv8gaDk0WKbWz0m8kBzK6XtN20hDNgD3jXEa32curfXUc7DcNVQRGJLKR5B fZMfflcZlQ2jguWFJWRNwrpmpJAhgcY+sG5oI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fpvWgY9WGFmdwWtDAxsxt3VhzhgmThiYdoktIXj/KOW0SekSTqwdciejI1MUjbqhsm tbQRoYpvUiIbppwsEK6jSViM9CT8opSEpx5UK6gduHMXo8tPLE6CtA2qmqi4NnXvr/qb ial56ef351rX/njIfoVv17nkJjMhr6nCA1FJ0= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr180958web.45.1290123417909; Thu, 18 Nov 2010 15:36:57 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Thu, 18 Nov 2010 15:36:57 -0800 (PST) In-Reply-To: <20101118231235.GA12137@troutmask.apl.washington.edu> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118225943.GB99684@freebsd.org> <20101118231235.GA12137@troutmask.apl.washington.edu> Date: Thu, 18 Nov 2010 15:36:57 -0800 X-Google-Sender-Auth: QQMUstOnBrl7mFCsjAfL84y5D2Q Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable , Andriy Gapon , FreeBSD Current , "Matthew D. Fuller" , Alexander Best , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 23:37:05 -0000 On Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl wrote: > On Thu, Nov 18, 2010 at 10:59:43PM +0000, Alexander Best wrote: >> >> well i did exactly what they did in the video. watch a 1080p video and m= ove >> the output window around while compiling the kernel. >> > > It is trivial to bring ULE to its knees. =A0If you > have N cores then all you need is N+1 cpu intensive > task. =A0The issue has been known for a few years. I/O intensive tasks don't help either though. Things tend to get choppy whenever I'm doing something like update from svn and doing something a bit more interactive like use firefox (and scroll... for instance gmail seems to be a pig in this area -- heh), vlc is a little less painful, etc. I wonder if the issue isn't necessarily tasks but more or less locking. firefox uses a lot of threads and file based mutexes according to what I've seen with top and ps (please correct me if I'm wrong). firefox also has a tendency with the nvidia-driver (I know... blobs are bad) to produce funky artifacts on the screen (again, when scrolling on gmail, dealing with flash, etc) or certain bits don't redraw properly (text when scrolling ends up ghosting on multiple lines until I force a redraw with the cursor or by scrolling back over that section of text). I'm sure there are a lot of performance issues within FreeBSD and opensource desktop software that needs to be properly worked out on a case by case basis, so I think that writing everything off as awesome and working better with one magic patch is unlikely. Besides, Linux has a more complicated scheduler than FreeBSD does. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:37:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 92FCC106566B; Thu, 18 Nov 2010 23:37:31 +0000 (UTC) Date: Thu, 18 Nov 2010 23:37:31 +0000 From: Alexander Best To: Daniel Nebdal Message-ID: <20101118233731.GA10392@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: FreeBSD@freebsd.org, FreeBSD Stable , Andriy Gapon , Current , "Matthew D. Fuller" , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 23:37:31 -0000 On Fri Nov 19 10, Daniel Nebdal wrote: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: > > On Thu, 18 Nov 2010 18:56:35 +0000 > > Alexander Best wrote: > > > >> On Thu Nov 18 10, Matthew D. Fuller wrote: > >> > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > >> > Alexander Best, and lo! it spake thus: > >> > > > >> > > judging from the videos the changes are having a huge impact imo. > >> > > >> > Well, my (admittedly limited, and certainly anecdotal) experience is > >> > that Linux's interactive response when under heavy load was always > >> > much worse than FreeBSD's.  So maybe that's just them catching up to > >> > where we already are   ;) > >> > >> well...i tried playing back a 1080p vide files while doing > >> `make -j64 buildkernel` and FreeBSD's interactivity seems far from > >> perfect. > > > > One thing that just begs to be asked: since when decoding 1080p became > > an interactive task? > > > > Strictly speaking it isn't - but displaying it is a timing-sensitive > task that isn't CPU- or I/O-bound, and scheduling-wise that probably > makes it more like the "fast response when woken up" interactive tasks > than a CPU-bound non-interactive process. > Decoding it into another file on the disk is in the latter category, > of course - but I don't think that's what he meant. :) > > More on topic - while this was a tiny patch for Linux, it seems like > it would take more work for us, since I don't believe either of the > schedulers handles task groups in the required way. The linux patch > was just "create task groups automatically", since they already had > some suitable logic for scheduling based on task groups in their CFS > scheduler. We would have to (re-)add that first, which is non-trivial. personally i think freebsd would hugely benefit from a scheduler framework such as geom/gsched, where it's easy to switch between various algorithms. that way it be much easier to try out new concepts without having to write a completely new scheduler. cheers. alex > > > -- > Daniel Nebdal -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:43:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 564A7106564A; Thu, 18 Nov 2010 23:43:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-19.mx.aerioconnect.net [216.240.47.79]) by mx1.freebsd.org (Postfix) with ESMTP id 28F718FC14; Thu, 18 Nov 2010 23:43:51 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAINho0W001757; Thu, 18 Nov 2010 15:43:50 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 1B2192D601E; Thu, 18 Nov 2010 15:43:48 -0800 (PST) Message-ID: <4CE5BA37.20604@freebsd.org> Date: Thu, 18 Nov 2010 15:43:51 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Best References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> In-Reply-To: <20101118233731.GA10392@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: FreeBSD@freebsd.org, FreeBSD Stable , "O. Hartmann" , "Matthew D. Fuller" , Current , Andriy Gapon , freebsd-performance@freebsd.org, Daniel Nebdal Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2010 23:43:52 -0000 On 11/18/10 3:37 PM, Alexander Best wrote: > On Fri Nov 19 10, Daniel Nebdal wrote: >> On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: >>> On Thu, 18 Nov 2010 18:56:35 +0000 >>> Alexander Best wrote: >>> >>>> On Thu Nov 18 10, Matthew D. Fuller wrote: >>>>> On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of >>>>> Alexander Best, and lo! it spake thus: >>>>>> judging from the videos the changes are having a huge impact imo. >>>>> Well, my (admittedly limited, and certainly anecdotal) experience is >>>>> that Linux's interactive response when under heavy load was always >>>>> much worse than FreeBSD's. So maybe that's just them catching up to >>>>> where we already are ;) >>>> well...i tried playing back a 1080p vide files while doing >>>> `make -j64 buildkernel` and FreeBSD's interactivity seems far from >>>> perfect. >>> One thing that just begs to be asked: since when decoding 1080p became >>> an interactive task? >>> >> Strictly speaking it isn't - but displaying it is a timing-sensitive >> task that isn't CPU- or I/O-bound, and scheduling-wise that probably >> makes it more like the "fast response when woken up" interactive tasks >> than a CPU-bound non-interactive process. >> Decoding it into another file on the disk is in the latter category, >> of course - but I don't think that's what he meant. :) >> >> More on topic - while this was a tiny patch for Linux, it seems like >> it would take more work for us, since I don't believe either of the >> schedulers handles task groups in the required way. The linux patch >> was just "create task groups automatically", since they already had >> some suitable logic for scheduling based on task groups in their CFS >> scheduler. We would have to (re-)add that first, which is non-trivial. > personally i think freebsd would hugely benefit from a scheduler framework > such as geom/gsched, where it's easy to switch between various algorithms. > > that way it be much easier to try out new concepts without having to write a > completely new scheduler. we are part of the way there.. at least we did abstract the scheduler to the point where we have two completely different ones. you are welcome to develop a 'framework as you describe and plug it into the abstraction we already have. > cheers. > alex > >> >> -- >> Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 00:17:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 169521065694; Fri, 19 Nov 2010 00:17:10 +0000 (UTC) Date: Fri, 19 Nov 2010 00:17:10 +0000 From: Alexander Best To: Julian Elischer Message-ID: <20101119001710.GA14641@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE5BA37.20604@freebsd.org> Cc: FreeBSD@freebsd.org, FreeBSD Stable , "O. Hartmann" , "Matthew D. Fuller" , Current , Andriy Gapon , freebsd-performance@freebsd.org, Daniel Nebdal Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 00:17:10 -0000 On Thu Nov 18 10, Julian Elischer wrote: > On 11/18/10 3:37 PM, Alexander Best wrote: > >On Fri Nov 19 10, Daniel Nebdal wrote: > >>On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev > >>wrote: > >>>On Thu, 18 Nov 2010 18:56:35 +0000 > >>>Alexander Best wrote: > >>> > >>>>On Thu Nov 18 10, Matthew D. Fuller wrote: > >>>>>On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > >>>>>Alexander Best, and lo! it spake thus: > >>>>>>judging from the videos the changes are having a huge impact imo. > >>>>>Well, my (admittedly limited, and certainly anecdotal) experience is > >>>>>that Linux's interactive response when under heavy load was always > >>>>>much worse than FreeBSD's. So maybe that's just them catching up to > >>>>>where we already are ;) > >>>>well...i tried playing back a 1080p vide files while doing > >>>>`make -j64 buildkernel` and FreeBSD's interactivity seems far from > >>>>perfect. > >>>One thing that just begs to be asked: since when decoding 1080p became > >>>an interactive task? > >>> > >>Strictly speaking it isn't - but displaying it is a timing-sensitive > >>task that isn't CPU- or I/O-bound, and scheduling-wise that probably > >>makes it more like the "fast response when woken up" interactive tasks > >>than a CPU-bound non-interactive process. > >>Decoding it into another file on the disk is in the latter category, > >>of course - but I don't think that's what he meant. :) > >> > >>More on topic - while this was a tiny patch for Linux, it seems like > >>it would take more work for us, since I don't believe either of the > >>schedulers handles task groups in the required way. The linux patch > >>was just "create task groups automatically", since they already had > >>some suitable logic for scheduling based on task groups in their CFS > >>scheduler. We would have to (re-)add that first, which is non-trivial. > >personally i think freebsd would hugely benefit from a scheduler framework > >such as geom/gsched, where it's easy to switch between various algorithms. > > > >that way it be much easier to try out new concepts without having to write > >a > >completely new scheduler. > > we are part of the way there.. > > at least we did abstract the scheduler to the point where > we have two completely different ones. > you are welcome to develop a 'framework as you describe and plug it into > the abstraction we already have. **** 17:49 @ arundel : also looking at the svn log shows that still a lot of \ commits happen to sched_4bsd. so it's defenately not being abbandoned. in \ fact there might be situations where it performs better than sched_ule. 17:50 @ arundel : i'm looking forward to a scheduler which looks sorta like \ geom and enables you to plugin addition plugins with different scheduling \ algorithms. :) 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or \ thereabouts 17:51 @ Genesys : you could kldload new ones and switch to them on the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it into src \ tree. by now it's probably outdated and needs to be reworked quite a bit. **** does anybody know something about this? i'm sorry. i'd really love to contribute some code, but my programing skills are pretty scrappy. ;) it would probably take me 20 years to figure out the current sched code. cheers. alex > > >cheers. > >alex > > > >> > >>-- > >>Daniel Nebdal -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 00:44:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C661D1065672 for ; Fri, 19 Nov 2010 00:44:55 +0000 (UTC) (envelope-from onemda@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 5D63E8FC13 for ; Fri, 19 Nov 2010 00:44:54 +0000 (UTC) Received: by wyb35 with SMTP id 35so3071924wyb.13 for ; Thu, 18 Nov 2010 16:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VXVDk7LoduV4wceNmV76396YYY89VdIcCfO82Zssjvs=; b=IxAEvS4C0o+y5GcSsZU6PBL/zyLK6dS26PuWLM2DZLjSAJQ5v9fJYK1TDia/N2B6oD tkbBM59YFiJXlj+2fNx3pbuy8O9ysk1E2EgUWmTosNhzEXAVwRUW3FoD3N/GS28nWbLO TwoCUHlRZGYP02HogkqFJYignCiyzPakTJImE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tloORtE7UNX+MO8qPfEdgsvaWM53UdKT2xLAuRCAWwP5WElHpFdiukEagsnyPd3B2G mHGHVwr5v/BU22sT5RO28LLHF9wJS5Xb7Yz327bg9eq6C7Ga01D+2g6ibYxf308cCM1y sG4fvdd02fgYntsi9/4I0Bt7LAZWWpasbxif0= MIME-Version: 1.0 Received: by 10.216.231.162 with SMTP id l34mr1133179weq.77.1290127494160; Thu, 18 Nov 2010 16:44:54 -0800 (PST) Received: by 10.216.234.82 with HTTP; Thu, 18 Nov 2010 16:44:54 -0800 (PST) In-Reply-To: <20101118072341.V24596@maildrop.int.zabbadoz.net> References: <20101118072341.V24596@maildrop.int.zabbadoz.net> Date: Fri, 19 Nov 2010 00:44:54 +0000 Message-ID: From: Paul B Mahol To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD current mailing list Subject: Re: net.link.log_link_state_change broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 00:44:55 -0000 On 11/18/10, Bjoern A. Zeeb wrote: > On Tue, 2 Nov 2010, Paul B Mahol wrote: > > Hi, > >> It appears we do not log such events anymore (at least with wlan >> devices) in console. >> >> I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will >> change. >> >> Because I had loging disabled for very long time I encountered this >> problem just now. > > not sure. Might be, might not be. Have you further looked into this? > > I at least see: > ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, > LINK_STATE_UP); > ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, > LINK_STATE_DOWN); That part is not problematic, klog part is. Messages of link state changes are not available in console but are available in klog and in console once you open it with cat. Reading comment it appears that logic is inverted in code. From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 01:30:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A4551065697 for ; Fri, 19 Nov 2010 01:30:03 +0000 (UTC) (envelope-from pyunyh@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 C06EF8FC1C for ; Fri, 19 Nov 2010 01:30:02 +0000 (UTC) Received: by gxk21 with SMTP id 21so19720gxk.13 for ; Thu, 18 Nov 2010 17:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=oqiSIyqLRRVDk/Th7HGb0waxmOkNSFFaJaZ7oqsW5DU=; b=O5BM2/xKfek6IsOUhwGJw4wowRQK9DEmI6dTwgAEGEyuTzsO9DQjuok1YzM/roTtQx UX3vJN1V8XCR7QbPxTZeAdx0MwgciuBKj51fwkxcpbBJFaQdPE2l1YgVzYyQWy3YkfhG hU4IxffSwayqiV3h813ibQufRslWEWWNcwZ2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wmKVKwYdjhLJLUBJylYC0J97kppPP9g3ZPawSjXZWNOczYsjlKjccTpIrkigA7REWY TFrXrn1Ymsa1WojJYhKxOKg5zxvXGx8nVC9/wznaafmiCB21aNiqbrLFFrLdmJxo4n75 sOygCOtujg+bF309QcMpIs6Izmvpj6qv07jAw= Received: by 10.100.254.13 with SMTP id b13mr1023571ani.78.1290130202070; Thu, 18 Nov 2010 17:30:02 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w15sm1110112anw.33.2010.11.18.17.29.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 17:29:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 18 Nov 2010 17:29:58 -0800 From: Pyun YongHyeon Date: Thu, 18 Nov 2010 17:29:58 -0800 To: Paul B Mahol Message-ID: <20101119012958.GD8512@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: panic: loading if_bfe after boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 01:30:03 -0000 On Sat, Oct 30, 2010 at 09:19:06PM -0700, Pyun YongHyeon wrote: > On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol wrote: > > Hi, > > > > Loading if_bfe module after boot hangs machine, it works/attach fine > > from loader. > > > > Tell me if you need bt. > > Yes, I want to see the back trace. I think it was fixed in HEAD(r215348) and MFCed to stable/8 and stable/7. From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 01:50:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4503010657E5 for ; Fri, 19 Nov 2010 01:50:29 +0000 (UTC) (envelope-from onemda@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 D013A8FC13 for ; Fri, 19 Nov 2010 01:50:28 +0000 (UTC) Received: by wyb35 with SMTP id 35so3125575wyb.13 for ; Thu, 18 Nov 2010 17:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=hJjfqL2jw0SR7QaBv++XkPcusurnVu7TpRLiOmhUm4Y=; b=c0FcT357fw3kN0eFsU9FsbPXuIarwUkEx3T77jmIh/ywinAo76u6/VatRMm3ssk7Fg oU+ZQANIWrxJRiis0SrDNxRqhhJpBHTN7G89lqfWvXP0Wo188YJgqpeAd4W01k2UtXwr GY9HRp8PSuJrEyxn0XxihRtVuT4GQCDIhyUBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PmlEve7LCr8DHvohYHpJQAj+NyvCLtp3iEhoesnKEbWO4yAj7F8c45t8ArUMA60LFT BJRd+Kvhatvfys0Luiv0wbKKFO19r7tLfn6HqDYnDKjyEaX0EC0xN+6vCtvi7yD9Vy41 1rBFV3gnb3j51F2q1ajrvrh+IoTTAlU1nRHZQ= Received: by 10.216.164.194 with SMTP id c44mr1135289wel.107.1290131427243; Thu, 18 Nov 2010 17:50:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.234.82 with HTTP; Thu, 18 Nov 2010 17:50:07 -0800 (PST) In-Reply-To: <20101119012958.GD8512@michelle.cdnetworks.com> References: <20101119012958.GD8512@michelle.cdnetworks.com> From: Paul B Mahol Date: Fri, 19 Nov 2010 01:50:07 +0000 Message-ID: To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: panic: loading if_bfe after boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 01:50:29 -0000 On Fri, Nov 19, 2010 at 1:29 AM, Pyun YongHyeon wrote: > On Sat, Oct 30, 2010 at 09:19:06PM -0700, Pyun YongHyeon wrote: >> On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol wrote: >> > Hi, >> > >> > Loading if_bfe module after boot hangs machine, it works/attach fine >> > from loader. >> > >> > Tell me if you need bt. >> >> Yes, I want to see the back trace. > > I think it was fixed in HEAD(r215348) and MFCed to stable/8 and > stable/7. Of course it did. Otherwise I would scream on list ;) From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 01:05:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 041E9106566B; Fri, 19 Nov 2010 01:05:19 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id B19838FC17; Fri, 19 Nov 2010 01:05:18 +0000 (UTC) Received: from [10.0.1.3] (bas1-toronto09-1279534875.dsl.bell.ca [76.68.39.27]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id oAJ0owe8008179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Nov 2010 19:50:59 -0500 (EST) (envelope-from dmagda@ee.ryerson.ca) Message-Id: <38521DB9-B3AE-4F96-89C9-75A80D2E0B3E@ee.ryerson.ca> From: David Magda To: Julian Elischer In-Reply-To: <4CE5BA37.20604@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Nov 2010 19:50:58 -0500 References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 19 Nov 2010 03:32:28 +0000 Cc: freebsd-performance@freebsd.org, Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 01:05:19 -0000 On Nov 18, 2010, at 18:43, Julian Elischer wrote: > we are part of the way there.. > > at least we did abstract the scheduler to the point where we have > two completely different ones. you are welcome to develop a > 'framework as you describe and plug it into the abstraction we > already have. It may be something to suggest for the next round of Google's Summer of Code. Or perhaps part of a school project in operating systems work (master's level? eager-beaver bachelor's thesis?). Having a bit more flexibility in being able to make different components "pluggable" would help encourage the use of BSD in more research projects. And more people learning and hacking on BSD can't be a bad thing. :) From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 07:05:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1B4106566B; Fri, 19 Nov 2010 07:05:17 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntqsrv01p.mx.bigpond.com (nskntqsrv01p.mx.bigpond.com [61.9.168.231]) by mx1.freebsd.org (Postfix) with ESMTP id 495FB8FC08; Fri, 19 Nov 2010 07:05:15 +0000 (UTC) Received: from nskntotgx01p.mx.bigpond.com ([124.188.161.100]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20101119044139.EVJD24865.nskntmtas03p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com>; Fri, 19 Nov 2010 04:41:39 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20101119044139.GCRY25056.nskntotgx01p.mx.bigpond.com@johnny.reilly.home>; Fri, 19 Nov 2010 04:41:39 +0000 Date: Fri, 19 Nov 2010 15:41:29 +1100 From: Andrew Reilly To: Alexander Best Message-ID: <20101119044129.GA4063@johnny.reilly.home> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118182324.GA36312@freebsd.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4CE60003.00B0,ss=1,fgs=0 X-SIH-MSG-ID: rRg6ENH9TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rVMfpRv9GgxD9FJhqBNGUhaa/tTY3Rs9mK Cc: "O. Hartmann" , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 07:05:17 -0000 On Thu, Nov 18, 2010 at 06:23:24PM +0000, Alexander Best wrote: > you think so? judging from the videos the changes are having a huge impact imo. On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 09:25:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EA61065673; Fri, 19 Nov 2010 09:25:34 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E9F2B8FC1E; Fri, 19 Nov 2010 09:25:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07142; Fri, 19 Nov 2010 11:25:31 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJNDm-000LXs-O4; Fri, 19 Nov 2010 11:25:30 +0200 Message-ID: <4CE64289.5030903@freebsd.org> Date: Fri, 19 Nov 2010 11:25:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Best References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> In-Reply-To: <20101118185635.GA43706@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , "Matthew D. Fuller" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 09:25:34 -0000 on 18/11/2010 20:56 Alexander Best said the following: > On Thu Nov 18 10, Matthew D. Fuller wrote: >> On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of >> Alexander Best, and lo! it spake thus: >>> >>> judging from the videos the changes are having a huge impact imo. >> >> Well, my (admittedly limited, and certainly anecdotal) experience is >> that Linux's interactive response when under heavy load was always >> much worse than FreeBSD's. So maybe that's just them catching up to >> where we already are ;) > > well...i tried playing back a 1080p vide files while doing > `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. > > it might be possible that linux'es interactivity was worse than freebsd's, > but still this patch should be evaluated for freebsd. in this particular case > it seems linux now does better than freebsd. You do realize that there are many more variables for such a test than just "1080p video" and "make -j64 buildkernel"? Let's not forget about hardware, video drivers, player capabilities, exact kind of the video (you know, 1080p alone doesn't tell much). Besides, someone might be interested in running -j64 on his 1,2,4-core desktop system, but it's definitely not me. I prefer to be reasonable. I am not saying that our scheduler (ULE) is perfect. I don't even say that it's better (in whatever comparison system) than Linux scheduler X. I say that I wouldn't spend my time improving system behavior in a scenario like this. I compile stuff very frequently (kernels, ports, world) while browsing web, reading email, doing various "desktop stuff", sometimes watching videos from the web (like e.g. trailers). On this machine/hardware I have never personally felt a need for improvements in the scheduler. And I run KDE4 with all bells and whistles enabled. YMMV. P.S. I don't discourage anyone from improving our scheduler, I even do encourage that. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 09:37:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285891065670; Fri, 19 Nov 2010 09:37:18 +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 827F78FC0A; Fri, 19 Nov 2010 09:37:15 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07284; Fri, 19 Nov 2010 11:37:13 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJNP7-000LZD-99; Fri, 19 Nov 2010 11:37:13 +0200 Message-ID: <4CE64548.4020709@freebsd.org> Date: Fri, 19 Nov 2010 11:37:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Daniel Nebdal References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD@freebsd.org, FreeBSD Stable , "Matthew D. Fuller" , Current , Alexander Best , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 09:37:18 -0000 on 19/11/2010 00:55 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: >> On Thu, 18 Nov 2010 18:56:35 +0000 >> Alexander Best wrote: >>> well...i tried playing back a 1080p vide files while doing >>> `make -j64 buildkernel` and FreeBSD's interactivity seems far from >>> perfect. >> >> One thing that just begs to be asked: since when decoding 1080p became >> an interactive task? >> > > Strictly speaking it isn't - but displaying it is a timing-sensitive > task that isn't CPU- or I/O-bound, and scheduling-wise that probably Well, I am not sure if I can agree about CPU-bound-ness. Depends on the exact video file, of course, but certain high-quality 1080p are very CPU intensive unless decoding is offloaded from the CPU. Depends on decoder code too. I had some videos that were CPU-bound on my Athlon II X2 250 with then-version of mplayer from ports. YMMV. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 10:09:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA911065673; Fri, 19 Nov 2010 10:09:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6AE8FC16; Fri, 19 Nov 2010 10:09:30 +0000 (UTC) Received: by qyk31 with SMTP id 31so468013qyk.13 for ; Fri, 19 Nov 2010 02:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rezOWqcltP3g05dhS44hCe3yhv+tFm0lz4AYBz/sb20=; b=aUFpzVh4YFp/m4BYGG6MCAjqfAQI++p2ipl/qanRbiT7y+1aNMtp2J+gbRKLQ+aPP3 Yd+cmWRkojA426VMVLUiRhMwycVxJoYqiJaTzH8U0yfOJgrzNfGiB5sYZpdt5UqBSddZ qQQPvtD6SXGm4HNDeqOqDewBcNFM3iE/k0CA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KSCpWS8Vt8ObfmCpwH2IP7v+nADYjdM3bMr86vJwNxJg7OLU81BWUsJojw+f6DtfM7 3N/MUBgWEQgqe6LhrlEO8SYHc/ZizpYGKLUjPjUppx6/TFg62NWUi3+J54w394wmLkYP /++4DR4eu4BlaCvSQeBb1wqBtdd9daKqBnkE0= MIME-Version: 1.0 Received: by 10.229.221.17 with SMTP id ia17mr1663225qcb.24.1290161369216; Fri, 19 Nov 2010 02:09:29 -0800 (PST) Received: by 10.229.69.135 with HTTP; Fri, 19 Nov 2010 02:09:24 -0800 (PST) In-Reply-To: <20101118231411.GA5121@freebsd.org> References: <20101118231411.GA5121@freebsd.org> Date: Fri, 19 Nov 2010 13:09:24 +0300 Message-ID: From: Sergey Kandaurov To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: old references to vfs_mountroot_try() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 10:09:31 -0000 On 19 November 2010 02:14, Alexander Best wrote: > hi there, > > vfs_mountroot_try() seems to have been removed, yet the src still contains > three references to it: > > vfs_mount.c:386 > vfs_mount.c:723 > freebsd32_misc.c:2368 > So, what about just to rename those comments to reflect function name change? Index: sys/kern/vfs_mount.c =================================================================== --- sys/kern/vfs_mount.c (revision 215516) +++ sys/kern/vfs_mount.c (working copy) @@ -383,7 +383,7 @@ * Filter out MNT_ROOTFS. We do not want clients of nmount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). + * MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; @@ -720,7 +720,7 @@ * Filter out MNT_ROOTFS. We do not want clients of mount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). + * MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; Index: sys/compat/freebsd32/freebsd32_misc.c =================================================================== --- sys/compat/freebsd32/freebsd32_misc.c (revision 215516) +++ sys/compat/freebsd32/freebsd32_misc.c (working copy) @@ -2365,7 +2365,7 @@ * Filter out MNT_ROOTFS. We do not want clients of nmount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). + * MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 10:55:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFDE01065672 for ; Fri, 19 Nov 2010 10:55:43 +0000 (UTC) (envelope-from pluknet@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 4B4168FC13 for ; Fri, 19 Nov 2010 10:55:43 +0000 (UTC) Received: by qyk9 with SMTP id 9so595126qyk.13 for ; Fri, 19 Nov 2010 02:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=oe4cvvvBeNuc59PY2r6QPCfHn3b++VLtw4YnNTbw2+4=; b=or1qR64DTnKNSC7Y+epwWTbPyjUzfA8v/JS8umEwq+ESE8sV36PaJ4bQm5yNOmPSrX Zj/ZA0PzxVCy4LOF4srZJXXAIpVAf8SI/Or/LZ21F0vOwiM7ts4b/4uaBUwiazvzalcu 98Fr8gnEvyiudJOA9aQu4qKT+8qcsDCQqc1yM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HGWt/w7iQP21XI2HKd2RSLKCWXpmRXcvlptBGk+ZIvduP8GfA8Azxj2/ncamulVuf4 2GAH0tlr5jYRHMyn2GqVGaPDGEiOLny/9/a78++S0VE6KbQTbBdSLzsm1zyD10rxMlmA o3SYRvEzE8oOp+tRQEK5qM61dl0fB89q/8zLE= MIME-Version: 1.0 Received: by 10.229.229.135 with SMTP id ji7mr1686531qcb.100.1290164142194; Fri, 19 Nov 2010 02:55:42 -0800 (PST) Received: by 10.229.69.135 with HTTP; Fri, 19 Nov 2010 02:55:42 -0800 (PST) In-Reply-To: <20101011.192914.82309657.hrs@allbsd.org> References: <4C76CA06.5010001@FreeBSD.org> <20101011.192914.82309657.hrs@allbsd.org> Date: Fri, 19 Nov 2010 13:55:42 +0300 Message-ID: From: Sergey Kandaurov To: Hiroki Sato Content-Type: multipart/mixed; boundary=0016363b8f2065c2b3049565bf68 Cc: dougb@freebsd.org, freebsd-rc@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 10:55:44 -0000 --0016363b8f2065c2b3049565bf68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11 October 2010 14:29, Hiroki Sato wrote: > Hi, > > pluknet wrote > =A0in : > > pl> On 27 August 2010 00:09, Doug Barton wrote: > pl> > On 08/26/2010 12:53 PM, pluknet wrote: > pl> >> > pl> >> [cc'ing current@ as rc@ looks too quite] > pl> >> > pl> >> Hi. > pl> >> > pl> >> Since ifconfig has grown to label interfaces with > pl> >> ifconfig $ifname description "foobar", what about > pl> >> to give it more life and store i/face descriptions > pl> >> semi-permanently, so they will survive between reboots? > pl> >> > pl> >> This patch adds a functionality to rc.d to label > pl> >> interfaces at boot time. > pl> >> > pl> >> Comments are welcome. > pl> > > pl> > This seems like a good addition, thanks. Please also write a patch = for > pl> > rc.conf.5 to describe this new functionality and I'll be happy to c= ommit it. > pl> > pl> Xin Li helped me with updating rc.conf.5 (thanks!). > pl> It's included in attached patch. > (snip) > pl> >> + =A0 =A0 =A0 # ifconfig_IF_descr > pl> >> + =A0 =A0 =A0 for _if in `ifconfig -l`; do > > =A0I think using "ifconfig -l" here is not a good idea. =A0Setting a > =A0description for each interface in a function invoked by ifn_start() > =A0would be better. > > =A0This is beacuse the netif script can be run not only at boottime but > =A0also via devd or by hand for a specific interface. =A0So, if the > =A0ifnet_descr is there, "/etc/rc.d/netif start IF" does not make it > =A0run. =A0Since the description is a per-interface property, > =A0"/etc/rc.d/netif start IF" should set one, and "/etc/rc.d/netif stop > =A0IF" should clear one, IMHO. > > =A0Also, "ifconfig -l" is not compatible with $network_interfaces, so > =A0you need to use list_net_interface() for that purpose instead (if you > =A0move ifnet_descr() into ifn_start() it is useless, though). > Actually, both versions were developed at the same time. This one follows "netif" approach. Somehow it was rejected by me for some reasons which I don't remember for now. That's why I didn't include it to my original message. Please, see attached. --=20 wbr, pluknet P.S. Google marks patches as (application/octet-stream). Bad Google. --0016363b8f2065c2b3049565bf68 Content-Type: application/octet-stream; name="descr.rc.d.netif.patch" Content-Disposition: attachment; filename="descr.rc.d.netif.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggoyd0vv1 SW5kZXg6IGV0Yy9uZXR3b3JrLnN1YnIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL25ldHdvcmsuc3Vicgko cmV2aXNpb24gMjE1NDIzKQorKysgZXRjL25ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQpAQCAt NDcsNiArNDcsNyBAQAogCWlwdjRfdXAgJHtpZm59ICYmIGNmZz0wCiAJaXB2Nl91cCAke2lmbn0g JiYgY2ZnPTAKIAlpcHhfdXAgJHtpZm59ICYmIGNmZz0wCisJaWZkZXNjcl91cCAke2lmbn0gJiYg Y2ZnPTAKIAljaGlsZGlmX2NyZWF0ZSAke2lmbn0gJiYgY2ZnPTAKIAogCXJldHVybiAkY2ZnCkBA IC02OSw2ICs3MCw3IEBACiAJaXB2NF9kb3duICR7aWZufSAmJiBjZmc9MAogCWlmY29uZmlnX2Rv d24gJHtpZm59ICYmIGNmZz0wCiAJaWZzY3JpcHRfZG93biAke2lmbn0gJiYgY2ZnPTAKKwlpZmRl c2NyX2Rvd24gJHtpZm59ICYmIGNmZz0wCiAJY2hpbGRpZl9kZXN0cm95ICR7aWZufSAmJiBjZmc9 MAogCiAJcmV0dXJuICRjZmcKQEAgLTEyMTQsNiArMTIxNiwzNSBAQAogCXJldHVybiAwCiB9CiAK KyMgaWZkZXNjcl91cCBpZgorIwlBZGQgZGVzY3JpcHRpb24gdG8gdGhlIGludGVyZmFjZSAkaWYu CisjCitpZmRlc2NyX3VwKCkKK3sKKwlsb2NhbCBfaWYgX2lmZGVzY3IKKworCV9pZj0kMQorCV9p ZmRlc2NyPSJgZ2V0X2lmX3ZhciAkX2lmIGlmY29uZmlnX0lGX2Rlc2NyYCIKKwlpZiBbICEgLXog IiRfaWZkZXNjciIgXTsgdGhlbgorCQlpZmNvbmZpZyAkX2lmIGRlc2NyICIkX2lmZGVzY3IiCisJ ZmkKKworCXJldHVybiAwCit9CisKKyMgaWZkZXNjcl9kb3duIGlmCisjCVJlbW92ZSBkZXNjcmlw dGlvbiBmcm9tIHRoZSBpbnRlcmZhY2UgJGlmLgorIworaWZkZXNjcl9kb3duKCkKK3sKKwlsb2Nh bCBfaWYgX2lmZGVzY3IKKworCV9pZj0kMQorCWlmY29uZmlnICRfaWYgLWRlc2NyCisKKwlyZXR1 cm4gMAorfQorCiAjIGxpc3RfbmV0X2ludGVyZmFjZXMgdHlwZQogIwlMaXN0IGFsbCBuZXR3b3Jr IGludGVyZmFjZXMuIFRoZSB0eXBlIG9mIGludGVyZmFjZSByZXR1cm5lZAogIwljYW4gYmUgY29u dHJvbGxlZCBieSB0aGUgdHlwZSBhcmd1bWVudC4gVGhlIHR5cGUKSW5kZXg6IGV0Yy9kZWZhdWx0 cy9yYy5jb25mCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9kZWZhdWx0cy9yYy5jb25mCShyZXZpc2lvbiAy MTU0MjMpCisrKyBldGMvZGVmYXVsdHMvcmMuY29uZgkod29ya2luZyBjb3B5KQpAQCAtMjE0LDYg KzIxNCw3IEBACiAjaWZjb25maWdfZWQwX2lwdjY9ImluZXQ2IDIwMDE6ZGI4OjE6OjEgcHJlZml4 bGVuIDY0IiAjIFNhbXBsZSBJUHY2IGFkZHIgZW50cnkKICNpZmNvbmZpZ19lZDBfYWxpYXMwPSJp bmV0NiAyMDAxOmRiODoyOjoxIHByZWZpeGxlbiA2NCIgIyBTYW1wbGUgSVB2NiBhbGlhcwogI2lm Y29uZmlnX2Z4cDBfbmFtZT0ibmV0MCIJIyBDaGFuZ2UgaW50ZXJmYWNlIG5hbWUgZnJvbSBmeHAw IHRvIG5ldDAuCisjaWZjb25maWdfZnhwMF9kZXNjcj0iVXBsaW5rIHRvIFN3aXRjaCAyIgkjIExh YmVsIGZ4cDAgaW50ZXJmYWNlCiAjdmxhbnNfZnhwMD0iMTAxIHZsYW4wIgkJIyB2bGFuKDQpIGlu dGVyZmFjZXMgZm9yIGZ4cDAgZGV2aWNlCiAjY3JlYXRlX2FyZ3NfdmxhbjA9InZsYW4gMTAyIgkj IHZsYW4gdGFnIGZvciB2bGFuMCBkZXZpY2UKICN3bGFuc19hdGgwPSJ3bGFuMCIJCSMgd2xhbig0 KSBpbnRlcmZhY2VzIGZvciBhdGgwIGRldmljZQo= --0016363b8f2065c2b3049565bf68-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 09:42:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E73B106566C; Fri, 19 Nov 2010 09:42:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C2F4C8FC18; Fri, 19 Nov 2010 09:42:06 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id AA582E60BE; Fri, 19 Nov 2010 09:42:05 +0000 (GMT) Received: from unknown (client-86-27-40-229.glfd.adsl.virginmedia.com [86.27.40.229]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 19 Nov 2010 09:42:04 +0000 (GMT) Date: Fri, 19 Nov 2010 09:42:07 +0000 From: Bruce Cran To: Alexander Best Message-ID: <20101119094207.00004cb4@unknown> In-Reply-To: <20101119001710.GA14641@freebsd.org> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Nov 2010 11:56:52 +0000 Cc: FreeBSD@freebsd.org, Stable , Daniel Nebdal , "Matthew D. Fuller" , Current , Gapon , FreeBSD, Andriy, freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 09:42:07 -0000 On Fri, 19 Nov 2010 00:17:10 +0000 Alexander Best wrote: > 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* > or \ thereabouts > 17:51 @ Genesys : you could kldload new ones and switch to them on > the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't > make it into src \ tree. by now it's probably outdated and needs to > be reworked quite a bit. **** > > does anybody know something about this? Google suggests that the work was a GSoC project in 2005 on a pluggable disk scheduler. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 11:29:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F64B1065673; Fri, 19 Nov 2010 11:29:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A7C4E8FC15; Fri, 19 Nov 2010 11:29:16 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A2B7.dip.t-dialin.net [87.179.162.183]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D582384400E; Fri, 19 Nov 2010 12:09:43 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5D85F118D; Fri, 19 Nov 2010 12:09:40 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oAJB8xkN002093; Fri, 19 Nov 2010 12:08:59 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 19 Nov 2010 12:08:59 +0100 Message-ID: <20101119120859.59361egrovtna9q8@webmail.leidinger.net> Date: Fri, 19 Nov 2010 12:08:59 +0100 From: Alexander Leidinger To: Alexander Best References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> In-Reply-To: <20101119001710.GA14641@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D582384400E.A69F4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1290769784.20671@yoypZWdpM06a5ccjyLEuLQ X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 19 Nov 2010 11:57:04 +0000 Cc: FreeBSD@freebsd.org, Stable , Daniel Nebdal , "Matthew D. Fuller" , Current , Gapon , FreeBSD, Andriy, freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 11:29:17 -0000 Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 +0000): > 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or \ > thereabouts > 17:51 @ Genesys : you could kldload new ones and switch to them on the fly > 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it > into src \ > tree. by now it's probably outdated and needs to be reworked quite a bit. > **** > > does anybody know something about this? I'm aware of the I/O scheduling code (which is now available at least in -current), but I do not remember CPU scheduling code from Luigi. Are you sure Genesys didn't mix up something by accident? Bye, Alexander. -- Ferengi Rule of Acquisition #123: Even a blind man can recognize the glow of latinum. -- ST: Legends of the Ferengi http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 12:40:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1CFC3106566B; Fri, 19 Nov 2010 12:40:55 +0000 (UTC) Date: Fri, 19 Nov 2010 12:40:55 +0000 From: Alexander Best To: Sergey Kandaurov Message-ID: <20101119124055.GA11368@freebsd.org> References: <20101118231411.GA5121@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: old references to vfs_mountroot_try() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 12:40:55 -0000 On Fri Nov 19 10, Sergey Kandaurov wrote: > On 19 November 2010 02:14, Alexander Best wrote: > > hi there, > > > > vfs_mountroot_try() seems to have been removed, yet the src still contains > > three references to it: > > > > vfs_mount.c:386 > > vfs_mount.c:723 > > freebsd32_misc.c:2368 > > > > So, what about just to rename those comments to reflect function name change? that looks fine. i don't know anything about vfs, so i simply figured out that the reference to vfs_mountroot_try() was not right anymore, but couldn't find where MNT_ROOTFS is now being set. ...so its parse_mount(). :) could you commit that? cheers. alex > > Index: sys/kern/vfs_mount.c > =================================================================== > --- sys/kern/vfs_mount.c (revision 215516) > +++ sys/kern/vfs_mount.c (working copy) > @@ -383,7 +383,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > + * MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > @@ -720,7 +720,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of mount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > + * MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > Index: sys/compat/freebsd32/freebsd32_misc.c > =================================================================== > --- sys/compat/freebsd32/freebsd32_misc.c (revision 215516) > +++ sys/compat/freebsd32/freebsd32_misc.c (working copy) > @@ -2365,7 +2365,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > + * MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > -- > wbr, > pluknet -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 13:03:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67786106564A for ; Fri, 19 Nov 2010 13:03:35 +0000 (UTC) (envelope-from ivoras@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 17B148FC12 for ; Fri, 19 Nov 2010 13:03:34 +0000 (UTC) Received: by qwi2 with SMTP id 2so111658qwi.13 for ; Fri, 19 Nov 2010 05:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=jbS8MFiQuCKFvDe74fC4C8awLgdZnN0tT5afryU1IoI=; b=YQ39o6J0dZ78ZAkkBLRkcqNzwa39KbJq1hMX0fEIDvuyIY1b/fkGBkRzYIQe32pLbE QsXnUjQbPGsgSB75ZlVCbDhtYL9MEOQ+HUS46hmOx0r9brkp7NYKUMu5xqJr1axeUBve AcVTV55KGBkjAoTjX2tPVzgpCm9StTY+HalyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ck5TEQDgC8shb+qqveSaZyTQcK3POLIw7x4vX+TatpjEaoKRGLE2KaKsrfJ8+54T4m MlGdEGIvD3+yTLgJBq/uXXIkS149AErbaqbgrcpl2XzFvZemPhgyKu/w6YZd5VpA5ng5 ijQYCgmDS84vZWKxgJ3rmRAj/p8d4OBFQ1Erg= Received: by 10.229.189.72 with SMTP id dd8mr1813751qcb.123.1290171814136; Fri, 19 Nov 2010 05:03:34 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 05:02:17 -0800 (PST) In-Reply-To: <1290128206.3201.17.camel@home-yahoo> References: <1290128206.3201.17.camel@home-yahoo> From: Ivan Voras Date: Fri, 19 Nov 2010 14:02:17 +0100 X-Google-Sender-Auth: v9AswNygg_kf6J4NvsdPSJsRVbQ Message-ID: To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-current@hackers.org" Subject: Re: Testing /dev/fido ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 13:03:35 -0000 On 19 November 2010 01:56, Sean Bruno wrote: > On Thu, 2010-11-18 at 13:17 -0800, Ivan Voras wrote: >> I have an IPMI-enabled server with BMC watchdog, and if I understand it >> correctly, /dev/fido will be attached as the result of loading ipmi.ko. >> >> Is there some easy way to test if everything works? > > I *think* that if you panic the box to the debugger, that should put the > machine into a state where the watchdog will fire right? Heh, unfortunately it seems to not work at all, in the sense that the OS (i have watchdogd running!) apparently doesn't communicate to IPMI that it's alive and IPMI resets the system out of the blue when that feature is enabled. Any ideas where to dig for problems? I have ipmi.ko loaded and watchdogd started - is there something else I should do? dmesg ipmi messages are: > dmesg |grep ipmi ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa ipmi0: IPMI device rev. 1, firmware rev. 2.2, version 2.0 ipmi0: Number of channels 2 ipmi0: Attached watchdog From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 13:14:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D85106564A; Fri, 19 Nov 2010 13:14:17 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6F0898FC0A; Fri, 19 Nov 2010 13:14:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13146; Fri, 19 Nov 2010 15:14:13 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE67825.4010700@freebsd.org> Date: Fri, 19 Nov 2010 15:14:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <4CE58A86.6010406@freebsd.org> In-Reply-To: <4CE58A86.6010406@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucius Windschuh , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 13:14:17 -0000 on 18/11/2010 22:20 Julian Elischer said the following: > tty grouping is a variant of what we used to have at one stage which is > a "kernel schedulable entity group".. KSEG Or rather, I think, a concrete application of a variant of that. > the idea is that all items in a group share some characteristic and some amount > of resources. > > We stripped the KSEG out of the picture because it really complicated the picture. Yes, unfortunately. One can think about a number of applications for hierarchical schedulable resources. Even one-level group scheduling could be a very useful subcase. BTW, http://www.mjmwired.net/kernel/Documentation/cgroups.txt -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 13:10:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04A4E1065672; Fri, 19 Nov 2010 13:10:48 +0000 (UTC) (envelope-from emss.mail@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 4FB138FC19; Fri, 19 Nov 2010 13:10:46 +0000 (UTC) Received: by wyb35 with SMTP id 35so3639283wyb.13 for ; Fri, 19 Nov 2010 05:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received :x-virus-scanned:received:received:to:cc:subject:from:in-reply-to :references:x-operating-system:date:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=ARCthvL34kJuHzwdGbFdIq8QLq5CkruPFrVzrKEuh5k=; b=rnGIO8/OpL7RTzPFBtAqyf4K7ZjdfTPhu0Owq+lkQ3FqfvLE7HJMwG6w21kt2hZuvN PeBtzoji9w/zv/nyV2REr9f/p5FPnTahV2L9IdXXj3hkWHJxskjERMCSykvtPObqPPRE SEqKadyJIdxtOlqHaItRjcsaoULCtAd7u2Jys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:x-virus-scanned:to:cc:subject:from:in-reply-to:references :x-operating-system:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; b=aMbxVjew7mpPIUERohgypaeDDkB+9jAymgYowlu1rif+BSwv5Vl4R3QOCnWJriKOGR MkJqEYPeNNRv/P7EPmurfsiDsKax39sqRhYHNWkQ7Lq/MBnbiyqsB66lKznIDTCeRcE/ EhRvnWr3KQrFNquvs3OoJ7a4HnpqcWeiHMMCI= Received: by 10.227.147.209 with SMTP id m17mr2215700wbv.51.1290170546015; Fri, 19 Nov 2010 04:42:26 -0800 (PST) Received: from srvbsdfenssv.interne.associated-bears.org (LCaen-151-92-21-48.w217-128.abo.wanadoo.fr [217.128.200.48]) by mx.google.com with ESMTPS id x12sm764804weq.18.2010.11.19.04.42.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 04:42:25 -0800 (PST) Sender: Eric Masson Received: from srvbsdfenssv.interne.associated-bears.org (localhost [127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id DA83B1CF6F; Fri, 19 Nov 2010 13:42:21 +0100 (CET) X-Virus-Scanned: amavisd-new at interne.associated-bears.org Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (srvbsdfenssv.interne.associated-bears.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ8aqkcGtYVY; Fri, 19 Nov 2010 13:42:18 +0100 (CET) Received: by srvbsdfenssv.interne.associated-bears.org (Postfix, from userid 1001) id 8953D1CC5B; Fri, 19 Nov 2010 13:42:18 +0100 (CET) To: Bruce Cran From: Eric Masson In-Reply-To: <20101119094207.00004cb4@unknown> (Bruce Cran's message of "Fri, 19 Nov 2010 09:42:07 +0000") References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> <20101119094207.00004cb4@unknown> X-Operating-System: FreeBSD 8.1-RELEASE-p1 amd64 Date: Fri, 19 Nov 2010 13:42:18 +0100 Message-ID: <864obdeb85.fsf@srvbsdfenssv.interne.associated-bears.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 19 Nov 2010 13:18:40 +0000 Cc: Andriy@FreeBSD.ORG, FreeBSD@freebsd.org, Stable , Daniel Nebdal , "Matthew D. Fuller" , "O. Hartmann" , Current , Gapon , Alexander Best , freebsd-performance@freebsd.org Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 13:10:48 -0000 Bruce Cran writes: Hello, > Google suggests that the work was a GSoC project in 2005 on a pluggable > disk scheduler. It seems that something similar has found its way in DFlyBSD, dsched. Éric Masson -- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons. From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 14:18:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BED106564A; Fri, 19 Nov 2010 14:18:56 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21E508FC14; Fri, 19 Nov 2010 14:18:54 +0000 (UTC) Received: from vhoffman-macbooklocal.local (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id oAJEIqJm059907 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 14:18:52 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4CE6874C.1060204@unsane.co.uk> Date: Fri, 19 Nov 2010 14:18:52 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Eric Masson References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> <20101119094207.00004cb4@unknown> <864obdeb85.fsf@srvbsdfenssv.interne.associated-bears.org> In-Reply-To: <864obdeb85.fsf@srvbsdfenssv.interne.associated-bears.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-performance@freebsd.org, Current , Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 14:18:56 -0000 On 19/11/2010 12:42, Eric Masson wrote: > Bruce Cran writes: > > Hello, > >> Google suggests that the work was a GSoC project in 2005 on a pluggable >> disk scheduler. > It seems that something similar has found its way in DFlyBSD, dsched. And indeed to FreeBSD, man gsched. Added sometime round April http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log Vince > Éric Masson > From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 14:39:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D0F1065672; Fri, 19 Nov 2010 14:39:10 +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 60C358FC17; Fri, 19 Nov 2010 14:39:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA14336; Fri, 19 Nov 2010 16:39:07 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE68C0B.1080007@freebsd.org> Date: Fri, 19 Nov 2010 16:39:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> <4CE533DE.7010401@freebsd.org> In-Reply-To: <4CE533DE.7010401@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 14:39:10 -0000 I am thinking about providing two APIs for this. 1. KPI void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); 2. Userland sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. But I am not sure where to put the code for both APIs. Adding another device under cpu seems like an overkill. Ideas? Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 14:51:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 709461065672; Fri, 19 Nov 2010 14:51:41 +0000 (UTC) (envelope-from dnebdal@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 180258FC08; Fri, 19 Nov 2010 14:51:40 +0000 (UTC) Received: by gxk22 with SMTP id 22so105349gxk.13 for ; Fri, 19 Nov 2010 06:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4OAJo5VQWDdWCDTyhIKA0XkXYufKaB9XYWbFkQb0M5A=; b=xxFZqOM3Of1Bj4n6xygKv2vrteDO3wq+sPc5Af4grZG9oImSqxikqrl+g9N24+xnGK xewn+KB5wTL7tCM8uH6jNZ3QUUyDUu9RYH0WoZAVCiYIxwopHW0vP1AVGWMTRzxe5EnI vXWpNe+Ty4+3yW2LlbzG8OT5J3R/tV9s1i8Gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HV5p5PIlb+xrYCxdW2JE49jMSf0oXGebuEz5YxJtzKfg/XoNKNrp/FYFwb/tku0KyP thIjF313F8XPUUk7XPEpwj0R69ZopYO6pOIY/FfzRLD7IaoD+SemgoDF//iZdesUVWvB NtmjATgnEiE/pGiQ1tJssnZsn/ynGCxrhwK4I= MIME-Version: 1.0 Received: by 10.42.76.66 with SMTP id d2mr413305ick.219.1290178299717; Fri, 19 Nov 2010 06:51:39 -0800 (PST) Received: by 10.231.58.202 with HTTP; Fri, 19 Nov 2010 06:51:39 -0800 (PST) In-Reply-To: <4CE68C0B.1080007@freebsd.org> References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> <4CE533DE.7010401@freebsd.org> <4CE68C0B.1080007@freebsd.org> Date: Fri, 19 Nov 2010 16:51:39 +0200 Message-ID: From: Daniel Nebdal To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 14:51:41 -0000 On Fri, Nov 19, 2010 at 4:39 PM, Andriy Gapon wrote: > > I am thinking about providing two APIs for this. > > 1. KPI > void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); > > 2. Userland > sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. > > But I am not sure where to put the code for both APIs. > Adding another device under cpu seems like an overkill. > > Ideas? > Thanks! No comment on where to put it, but one other detail: Since these are measures since last reset, you probably want a similar "cpu_zero_a_m_perf" call. As for how that interacts with the sysctl, uhm ... maybe also offering a time-since-last-reset could be useful? -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 14:44:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 154F1106566C for ; Fri, 19 Nov 2010 14:44:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id AD09C8FC13 for ; Fri, 19 Nov 2010 14:44:54 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Z1Xp1f0051HpZEsA92kuka; Fri, 19 Nov 2010 14:44:54 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta14.emeryville.ca.mail.comcast.net with comcast id Z2ks1f00K3LrwQ28a2ktR8; Fri, 19 Nov 2010 14:44:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B60DD9B427; Fri, 19 Nov 2010 06:44:52 -0800 (PST) Date: Fri, 19 Nov 2010 06:44:52 -0800 From: Jeremy Chadwick To: Vincent Hoffman Message-ID: <20101119144452.GA67750@icarus.home.lan> References: <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> <20101119094207.00004cb4@unknown> <864obdeb85.fsf@srvbsdfenssv.interne.associated-bears.org> <4CE6874C.1060204@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE6874C.1060204@unsane.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 19 Nov 2010 15:18:20 +0000 Cc: Eric Masson , freebsd-performance@freebsd.org, Current , Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 14:44:55 -0000 On Fri, Nov 19, 2010 at 02:18:52PM +0000, Vincent Hoffman wrote: > On 19/11/2010 12:42, Eric Masson wrote: > > Bruce Cran writes: > > > > Hello, > > > >> Google suggests that the work was a GSoC project in 2005 on a pluggable > >> disk scheduler. > > It seems that something similar has found its way in DFlyBSD, dsched. > And indeed to FreeBSD, man gsched. Added sometime round April > http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log It's been pointed out on the list a couple times, and I've sent mail to the authors about this, that gsched breaks (very, very badly) things like sysinstall, and does other strange things like leaves trailing periods at the end of its ".sched." labels. This appears to be by design, but I'm still left thinking "?!" It's hard to discern technical innards/workings of GEOM since the documentation is so poor (and reading the code doesn't help, especially with regards to libgeom). IMHO, the gsched "stuff", as a "layer", should probably be moved into the I/O framework by default, with the functionality *disabled* by default and tunables to adjust it. That's just how I feel about it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:28:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 11A471065670; Fri, 19 Nov 2010 15:28:55 +0000 (UTC) Date: Fri, 19 Nov 2010 15:28:55 +0000 From: Alexander Best To: "Robert N. M. Watson" Message-ID: <20101119152855.GA34603@freebsd.org> References: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0F03.10703@freebsd.org> <20101115221924.GA38676@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Kostik Belousov , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 15:28:55 -0000 On Tue Nov 16 10, Robert N. M. Watson wrote: > > On 15 Nov 2010, at 22:19, Alexander Best wrote: > > > thanks for all your help. i've recently switched to chromium 6.0.472.63 > > and so far my computer has been very stable. > > > > if i experience more lock ups i'll let you know and try to figure out a way to > > gain access to some more debugging data. > > I'd prefer we try to figure out why your system was crashing now -- the kernel bug has not gone away just because Chromium is no longer triggering it. Working around the bug means someone else gets to run into it later -- perhaps when it's 9.0-RELEASE rather than 9-CURRENT... "GOOD" news btw: the new chromium port just crashed my system. ;) so the issue is still there. and be issue i mean the code that triggers the crash. > > Robert -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:39:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C0E106577E for ; Fri, 19 Nov 2010 15:39:56 +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 3F4438FC1F for ; Fri, 19 Nov 2010 15:39:55 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA15017; Fri, 19 Nov 2010 17:39:53 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE69A49.4080801@freebsd.org> Date: Fri, 19 Nov 2010 17:39:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: new cpuid bits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 15:39:57 -0000 Guys, I would like to add definitions for couple more useful CPUID bits, but I am greatly confused about how to name them. I failed to deduce the naming convention from the existing definitions and I am not sure how to make the names proper and descriptive. The bits in question are returned by CPUID.6 in EAX and ECX. CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is defined for both. Description/naming of the bits from the specifications: EAX[0]: Digital temperature sensor is supported if set EAX[1]: Intel Turbo Boost Technology Available EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. ECX[0]: Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT MSRs). AMD: EffFreq: effective frequency interface. How does the following look to you? I will appreciate suggestions/comments. Thanks! Index: sys/amd64/include/specialreg.h =================================================================== --- sys/amd64/include/specialreg.h (revision 215524) +++ sys/amd64/include/specialreg.h (working copy) @@ -136,6 +136,15 @@ #define CPUID2_AESNI 0x02000000 /* + * Important bits in the Thermal and Power Management flags + * CPUID.6 EAX and ECX. + */ +#define CPUTPM1_SENSOR 0x00000001 +#define CPUTPM1_TURBO 0x00000002 +#define CPUTPM1_ARAT 0x00000004 +#define CPUTPM2_EFFREQ 0x00000001 + +/* * Important bits in the AMD extended cpuid flags */ #define AMDID_SYSCALL 0x00000800 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:41:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039C810656A3 for ; Fri, 19 Nov 2010 15:41:14 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B0A878FC1B for ; Fri, 19 Nov 2010 15:41:13 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJT5M-0001Vn-DK for freebsd-current@freebsd.org; Fri, 19 Nov 2010 16:41:12 +0100 Received: from 213.202.123.72 ([213.202.123.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Nov 2010 16:41:12 +0100 Received: from ivoras by 213.202.123.72 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Nov 2010 16:41:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 19 Nov 2010 16:41:11 +0100 Lines: 9 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 213.202.123.72 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 Subject: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 15:41:14 -0000 I have a large-ish marchine, a Fujitsu TX300 S6 with 2x6-core + HTT CPUs and 24 GB RAM, configured as a demo machine with lots of interesting hardware. Unfortunately, the kernel hangs on boot. The loader finishes, the twirly starts spinning but then hangs. Enabling verbose booting results in nothing new - no kernel messages at all. Any ideas? From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:45:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F7D4106566B; Fri, 19 Nov 2010 15:45:36 +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 6493E8FC14; Fri, 19 Nov 2010 15:45:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA15070; Fri, 19 Nov 2010 17:45:31 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE69B9B.60101@freebsd.org> Date: Fri, 19 Nov 2010 17:45:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Daniel Nebdal References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> <4CE533DE.7010401@freebsd.org> <4CE68C0B.1080007@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 15:45:36 -0000 [looks like I originally sent the reply only privately] on 19/11/2010 16:50 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 4:39 PM, Andriy Gapon wrote: >> >> I am thinking about providing two APIs for this. >> >> 1. KPI >> void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); >> >> 2. Userland >> sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. >> >> But I am not sure where to put the code for both APIs. >> Adding another device under cpu seems like an overkill. >> >> Ideas? >> Thanks! > > No comment on where to put it, but one other detail: Since these are > measures since last reset, you probably want a similar > "cpu_zero_a_m_perf" call. As for how that interacts with the sysctl, > uhm ... maybe also offering a time-since-last-reset could be useful? > I have something else in mind - no reset, but you call cpu_get_a_m_perf() twice, take differences in the counters (accounting for possible overflows) and divide those deltas. In my opinion that should work. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:49:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BCD106564A; Fri, 19 Nov 2010 15:49:58 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 82A588FC08; Fri, 19 Nov 2010 15:49:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id B141813324; Sat, 20 Nov 2010 00:49:57 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41fp7la0-sfI; Sat, 20 Nov 2010 00:49:56 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Sat, 20 Nov 2010 00:49:56 +0900 (JST) Date: Sat, 20 Nov 2010 00:49:55 +0900 From: Taku YAMAMOTO To: "O. Hartmann" Message-Id: <20101120004955.68c8af6a.taku@tackymt.homeip.net> In-Reply-To: <4CE58CD8.2000407@mail.zedat.fu-berlin.de> References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <4CE58CD8.2000407@mail.zedat.fu-berlin.de> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Lucius Windschuh , freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable , Andriy Gapon Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 15:49:59 -0000 On Thu, 18 Nov 2010 21:30:16 +0100 "O. Hartmann" wrote: > On 11/18/10 19:55, Lucius Windschuh wrote: > > 2010/11/18 Andriy Gapon: > >> [Grouping of processes into TTY groups] > >> > >> Well, I think that those improvements apply only to a very specific usage pattern > >> and are greatly over-hyped. > > > > But there are serious issue if you use FreeBSD as a desktop OS with > > SMP and SCHED_ULE, or? > > Because currently, my machine is barely usable if a compile job with > > parallelism is running. Movies stutter, Firefox hangs. And even nice > > -n 20 doesn't do the job in every case, as +20 seems not to be the > > idle priority anymore?!? > > And using "idprio 1 $cmd" as a workaround is, well, a kludge. > > I am not sure if TTY grouping is the right solution, if you look at > > potentially CPU-intensive GUI applications that all run on the same > > TTY (or no TTY at all? Same problem). > > Maybe, we could simply enhance the algorithm that decides if a task is > > interactive? That would also improve the described situation. > > > > Regards, > > > > Lucius > > Stuttering Response, being stuck for over 20 seconds also happens when I > start updating the OS' sources via svn. This happens on all boxes, some > of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, > doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those > phenomena are most seen when you interact with the machine via X11 > clients. I think it's hard to realize if a server only does console I/O, > but console also seems to be stuck sometimes. It would be worth checking > this with some 'benchmark'. X11 in its kind of oldish incarnation on > FreeBSD seems to contribute most to those slowdowns, what so ever. I guess schedulers can hardly distinguish heavy disk I/Os from nanosleep()s and user-interactions; schedulers think both as voluntary sleep. To make the matters worse, the current implementation of SCHED_ULE reassigns ts_slice on sched_wakeup() no matter how short the sleep was. I have a dumb local hack to grant ts_slice proportional to the duration the waking thread slept rather than unconditionally reset to sched_slice. --- sys/kern/sched_ule.c.orig +++ sys/kern/sched_ule.c @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) u_int hzticks; hzticks = (ticks - slptick) << SCHED_TICK_SHIFT; + if (hzticks > SCHED_SLP_RUN_MAX) + hzticks = SCHED_SLP_RUN_MAX; ts->ts_slptime += hzticks; + /* Grant additional slices after we sleep. */ + ts->ts_slice += hzticks / tickincr; + if (ts->ts_slice > sched_slice) + ts->ts_slice = sched_slice; sched_interact_update(td); sched_pctcpu_update(ts); } - /* Reset the slice value after we sleep. */ - ts->ts_slice = sched_slice; sched_add(td, SRQ_BORING); } -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 15:51:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 659821065670; Fri, 19 Nov 2010 15:51:25 +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 6396B8FC0A; Fri, 19 Nov 2010 15:51:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA15132; Fri, 19 Nov 2010 17:51:22 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE69CFA.4030803@freebsd.org> Date: Fri, 19 Nov 2010 17:51:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 15:51:25 -0000 on 19/11/2010 17:41 Ivan Voras said the following: > Fujitsu TX300 [Thunderbird 3 sometimes fails quoting while replying - blame it] Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? Not sure if the kernel does that. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:14:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1DC106566B for ; Fri, 19 Nov 2010 16:14:05 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 405EF8FC14 for ; Fri, 19 Nov 2010 16:14:04 +0000 (UTC) Received: by bwz2 with SMTP id 2so4130416bwz.13 for ; Fri, 19 Nov 2010 08:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=lNoI7TpLMOlSzyfUsRtN7ZgHHmrqrWhpjX0+zk/yfiU=; b=O1jJPo8yaCkQpIUBxgWNAzCk8ntievyMRtwf1/t2XjLyZgJHHLCN4C2zuNNJ1ahwIb 1XD7ygf4PZsj8F4NkpIemqDZX1bLZv2MOvRBgcQbR918bFwWmHNjYjXKmpyRyqUghVJ9 ZTNRx7GP0XRS1JAp9Hyth9IYnIA7JUIe9VHS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=o/SmRIj33gI5x3jEKe079lyLhErB8UunjUzRvWUbRRdf1e6rry2AwUeJZ5KY5BUuYn iXrENYqHBehqKgnGwnOjS24dRxfWhxLY+xTIwQ0xifm6IjTuRNNIEuAv/MgacALIKeHW FGvAS/tJAuGwAVmUkT3v6DQRH7MpgZZsIs9Ls= Received: by 10.204.62.3 with SMTP id v3mr2234633bkh.99.1290183242989; Fri, 19 Nov 2010 08:14:02 -0800 (PST) Received: from ernst.jennejohn.org (p578E3432.dip.t-dialin.net [87.142.52.50]) by mx.google.com with ESMTPS id g8sm943675bkg.23.2010.11.19.08.14.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 08:14:02 -0800 (PST) Date: Fri, 19 Nov 2010 17:13:59 +0100 From: Gary Jennejohn To: Andriy Gapon Message-ID: <20101119171359.65b43213@ernst.jennejohn.org> In-Reply-To: <4CE69CFA.4030803@freebsd.org> References: <4CE69CFA.4030803@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:14:06 -0000 On Fri, 19 Nov 2010 17:51:22 +0200 Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: > > Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] > > Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? > Not sure if the kernel does that. > Yup, that's the boot loader. The kernel spits out printfs. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:20:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2D831065670; Fri, 19 Nov 2010 16:20:07 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7999A8FC20; Fri, 19 Nov 2010 16:20:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA15507; Fri, 19 Nov 2010 18:20:04 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE6A3B4.2080604@freebsd.org> Date: Fri, 19 Nov 2010 18:20:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <4CE2771F.8020109@freebsd.org> <201011160827.11628.jhb@freebsd.org> In-Reply-To: <201011160827.11628.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: taskqueue_create() name parameter lieftime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 16:20:07 -0000 on 16/11/2010 15:27 John Baldwin said the following: > On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: >> >> taskqueue_create() documentation never explicitly says this, but current >> taskqueue_create() implementation just stores a 'name' pointer parameter >> internally. Thus it depends on the 'name' having a life time encompassing that of >> the taskqueue. >> I think that alternatively we could have copied the name (or a portion of it) into >> an internal buffer. >> I don't any argument for either approach, just curious which one looks more >> preferable from general (FreeBSD, kernel) programming practices point of view. > > Hmm, in many other places we store a separate copy (e.g. all the interrupt > code uses separate MAXCOMLEN char arrays to hold names). If that is easy to > do, that is probably the best approach. BTW, tq_name doesn't seem to be used anywhere at all. Perhaps just drop it? But still could be useful in a debugger, though. Anyway, here is a possible change: diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c index 49ddce2..9b8ae66 100644 --- a/sys/kern/subr_taskqueue.c +++ b/sys/kern/subr_taskqueue.c @@ -53,7 +53,6 @@ struct taskqueue_busy { struct taskqueue { STAILQ_HEAD(, task) tq_queue; - const char *tq_name; taskqueue_enqueue_fn tq_enqueue; void *tq_context; TAILQ_HEAD(, taskqueue_busy) tq_active; @@ -62,6 +61,7 @@ struct taskqueue { int tq_tcount; int tq_spin; int tq_flags; + char tq_name[MAXCOMLEN]; }; #define TQ_FLAGS_ACTIVE (1 << 0) @@ -106,7 +106,7 @@ _taskqueue_create(const char *name, int mflags, STAILQ_INIT(&queue->tq_queue); TAILQ_INIT(&queue->tq_active); - queue->tq_name = name; + strlcpy(queue->tq_name, name, sizeof(queue->tq_name)); queue->tq_enqueue = enqueue; queue->tq_context = context; queue->tq_spin = (mtxflags & MTX_SPIN) != 0; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:21:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBDD1065674; Fri, 19 Nov 2010 16:21:25 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 439D58FC15; Fri, 19 Nov 2010 16:21:24 +0000 (UTC) Received: by yxh35 with SMTP id 35so2875488yxh.13 for ; Fri, 19 Nov 2010 08:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=8Z+yC0ilfTRbgWr3NYwWl3q4yI5+5G0JGhbvRhcpaqI=; b=q+O+qFq+/XuyqAL5DEN/ietfuZJ8tfm7IGUE+kX+e6eRidw/p5hn4UPF4cf1uOjaC3 pXQ4QgpUc+Hv62CGXLLvexwzO+Q3Q7hFZksmonzVJOaf17AsoTLyv2M5iNktBvmuFsPX i8P1gIgnW6qQ5Dvy2z5t2v9JjK0qPYtUS2KGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=bT0q4Kn568uWVnUJIPcDs7UreuFBKFEZdl8gkMOOLQTS8F1ax4opIS/SDq5FzvP9uV thIXp8iuM9KlEnTaCwq+KKDve2qg/cYXTe9T9HfwrMJG1Upjh01iGPg5/JUkALjZ9W4U jYj7dusKwE0AkX8ptyh2ROLgvZ5U5joMUksVI= Received: by 10.204.97.143 with SMTP id l15mr2261073bkn.127.1290183683115; Fri, 19 Nov 2010 08:21:23 -0800 (PST) Received: from ernst.jennejohn.org (p578E3432.dip.t-dialin.net [87.142.52.50]) by mx.google.com with ESMTPS id p34sm947484bkf.15.2010.11.19.08.21.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 08:21:22 -0800 (PST) Date: Fri, 19 Nov 2010 17:21:20 +0100 From: Gary Jennejohn To: Andriy Gapon Message-ID: <20101119172120.7fd14c9f@ernst.jennejohn.org> In-Reply-To: <4CE69A49.4080801@freebsd.org> References: <4CE69A49.4080801@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: new cpuid bits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:21:25 -0000 On Fri, 19 Nov 2010 17:39:53 +0200 Andriy Gapon wrote: > > Guys, > > I would like to add definitions for couple more useful CPUID bits, but I am > greatly confused about how to name them. > I failed to deduce the naming convention from the existing definitions and I am > not sure how to make the names proper and descriptive. > > The bits in question are returned by CPUID.6 in EAX and ECX. > CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management > (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is > defined for both. > > Description/naming of the bits from the specifications: > EAX[0]: Digital temperature sensor is supported if set > EAX[1]: Intel Turbo Boost Technology Available > EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. > ECX[0]: > Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT > MSRs). > AMD: EffFreq: effective frequency interface. > > How does the following look to you? > I will appreciate suggestions/comments. > Thanks! > > Index: sys/amd64/include/specialreg.h > =================================================================== > --- sys/amd64/include/specialreg.h (revision 215524) > +++ sys/amd64/include/specialreg.h (working copy) > @@ -136,6 +136,15 @@ > #define CPUID2_AESNI 0x02000000 > > /* > + * Important bits in the Thermal and Power Management flags > + * CPUID.6 EAX and ECX. > + */ > +#define CPUTPM1_SENSOR 0x00000001 > +#define CPUTPM1_TURBO 0x00000002 > +#define CPUTPM1_ARAT 0x00000004 > +#define CPUTPM2_EFFREQ 0x00000001 > + > +/* > * Important bits in the AMD extended cpuid flags > */ > #define AMDID_SYSCALL 0x00000800 > Maybe add a comment in which register the bits are to be found, like in the text? -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:21:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09091065767 for ; Fri, 19 Nov 2010 16:21:47 +0000 (UTC) (envelope-from ivoras@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 8C5DF8FC12 for ; Fri, 19 Nov 2010 16:21:47 +0000 (UTC) Received: by qyk9 with SMTP id 9so114852qyk.13 for ; Fri, 19 Nov 2010 08:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=RvhoV89t01cHy0/U8Nkmi/3Wy0hmlasjSliWFmn56f4=; b=fYwIy4g9OT8p3iBMKe/q0w3iQk+tvg0+lzLbb4ewChAeKfLr0Fk3N0rVQP6N50FEUG 1iQgU1MRFpIrvbwqNjbT+4dkmrqBUUw+h9HuC/ZD9eYPm3UU72FkPfH8Adus3BzaKqn4 7+vF5XgN1LMhqrJOMuDcHrOZWUYWfxCglsh9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=mb3D1kWyg1EnU7bY9dIX0J6DR49B0tDNIvkQav+dPOc7cqB5FqYvhzBIvYKIZQa/O+ m2kUFeYvMexhwTOqcyjik0UeXjJjrAUsWW0/nLWdHm1CzXXvVmHqz45JeGw6y6lMtfA4 0bv2da/5bY3aA1xn3r1K7P0RlU0MYwyfQbleU= Received: by 10.229.212.5 with SMTP id gq5mr1911856qcb.275.1290183705450; Fri, 19 Nov 2010 08:21:45 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 08:21:02 -0800 (PST) In-Reply-To: <4CE69CFA.4030803@freebsd.org> References: <4CE69CFA.4030803@freebsd.org> From: Ivan Voras Date: Fri, 19 Nov 2010 17:21:02 +0100 X-Google-Sender-Auth: _my7sUaeJrW4QC8hTqD79qGU3h0 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:21:48 -0000 On 19 November 2010 16:51, Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: >> Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] > > Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? > Not sure if the kernel does that. Could be, I'll try more fiddling with BIOS. From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:57:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E487E1065675; Fri, 19 Nov 2010 16:57:47 +0000 (UTC) (envelope-from ivoras@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 7D0388FC1F; Fri, 19 Nov 2010 16:57:47 +0000 (UTC) Received: by qwi4 with SMTP id 4so52922qwi.13 for ; Fri, 19 Nov 2010 08:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=CVeKbduM4lLkfP2hsclPhWlY6j2X9cIKowHelYN8cf0=; b=sefjKNU4ZGFUdmvjDPPjP4Q4g4Txf21NsG68819SUrFmquAXcDe4c3zIoH6psnwjRg 4CSnN478P0ighD2yhL701jwjkrpk+EQjE9BsBmg1NGQws8OZ9qk3YhG5/eFJ6KAThZLx SOoPuaOWSmrdTX2JIXMCWJJGeTyXdC3edr2tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=CUHD5tt7AYT2RgXVlyaDCf71hw23MRvKjYWOxxjb9h0HKyuV/hsYcM0CpeAvecFq1j d2uI9bcY3pizGJmajZY9qeovdSREZ293RNtbQ0SibZfp2j53BMMLysp+DsrhRhlV5fZy v8eHH1T/nzZqhpTbbPx1qtLqUqUuvbOkyy6sU= Received: by 10.229.212.5 with SMTP id gq5mr1940302qcb.275.1290185865933; Fri, 19 Nov 2010 08:57:45 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 08:57:05 -0800 (PST) In-Reply-To: <20101119171359.65b43213@ernst.jennejohn.org> References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> From: Ivan Voras Date: Fri, 19 Nov 2010 17:57:05 +0100 X-Google-Sender-Auth: CDq78fNJRGvWIcH-tKQasW8UHmw Message-ID: To: gljennjohn@googlemail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:57:48 -0000 On 19 November 2010 17:13, Gary Jennejohn wrote= : > On Fri, 19 Nov 2010 17:51:22 +0200 > Andriy Gapon wrote: > >> on 19/11/2010 17:41 Ivan Voras said the following: >> > Fujitsu TX300 >> >> [Thunderbird 3 sometimes fails quoting while replying - blame it] >> >> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >> Not sure if the kernel does that. >> > > Yup, that's the boot loader. =C2=A0The kernel spits out printfs. Good news, of sorts - I left while I went for dinner and apparently it did boot in the meantime. So it's not a complete hang, it just takes unexpectedly long (10+ minutes?) I'm currently running "make -j24 buildworld" and once it boots it looks very fast! From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 16:59:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E352106566B; Fri, 19 Nov 2010 16:59:30 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2A58FC14; Fri, 19 Nov 2010 16:59:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA16302; Fri, 19 Nov 2010 18:59:27 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE6ACEF.4000303@freebsd.org> Date: Fri, 19 Nov 2010 18:59:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:59:30 -0000 on 19/11/2010 18:57 Ivan Voras said the following: > On 19 November 2010 17:13, Gary Jennejohn wrote: >> On Fri, 19 Nov 2010 17:51:22 +0200 >> Andriy Gapon wrote: >> >>> on 19/11/2010 17:41 Ivan Voras said the following: >>>> Fujitsu TX300 >>> >>> [Thunderbird 3 sometimes fails quoting while replying - blame it] >>> >>> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >>> Not sure if the kernel does that. >>> >> >> Yup, that's the boot loader. The kernel spits out printfs. > > Good news, of sorts - I left while I went for dinner and apparently it > did boot in the meantime. So it's not a complete hang, it just takes > unexpectedly long (10+ minutes?) > > I'm currently running "make -j24 buildworld" and once it boots it > looks very fast! You ought to determine a cause of the long boot, though. No compromises or excuses! :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 17:04:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D4D106566B; Fri, 19 Nov 2010 17:04:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 433408FC0C; Fri, 19 Nov 2010 17:04:02 +0000 (UTC) Received: by wyb35 with SMTP id 35so3875476wyb.13 for ; Fri, 19 Nov 2010 09:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PFFKLRKUvkQaWSGCMIoLBgw3VMLHhoUSXYImykJ1BCo=; b=vd9jKT357seYJSl8yghKFzmQDT64tTIWZbh5/ujydbt9M2MgSTChx+f14aKqoZB0t8 WLgoNZrBgMcmb82996pTc0UYk+GJTFA6gUJnpF/FKIKViL5d+JKkY62gaA24AJLKlWco 3Hvo2GMN6dVNx+vHdKnl8rNEvjdehWESpZM/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GxAFwc6fhOgCTZrIXngJU+l7C2ypHcY5yUPasXm+Wmrp9eElQ2JzuM28NzmKbmWrDC 8innflYuGXs82wzPPDcVqwuN70zLJMihY4aQY3v52K2j1MM0Ykp4MTUL4ZU5xG7EkaPo oo2q5Ru/yKh8fOqmLbrvgDSiOiD/C5DntbDW4= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr1233068web.45.1290186241376; Fri, 19 Nov 2010 09:04:01 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 09:04:01 -0800 (PST) In-Reply-To: <4CE6ACEF.4000303@freebsd.org> References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> Date: Fri, 19 Nov 2010 09:04:01 -0800 X-Google-Sender-Auth: jD86kVTQGPGgpyliOYYQGABXJ1k Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:04:04 -0000 On Fri, Nov 19, 2010 at 8:59 AM, Andriy Gapon wrote: > on 19/11/2010 18:57 Ivan Voras said the following: >> On 19 November 2010 17:13, Gary Jennejohn wr= ote: >>> On Fri, 19 Nov 2010 17:51:22 +0200 >>> Andriy Gapon wrote: >>> >>>> on 19/11/2010 17:41 Ivan Voras said the following: >>>>> Fujitsu TX300 >>>> >>>> [Thunderbird 3 sometimes fails quoting while replying - blame it] >>>> >>>> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >>>> Not sure if the kernel does that. >>>> >>> >>> Yup, that's the boot loader. =A0The kernel spits out printfs. >> >> Good news, of sorts - I left while I went for dinner and apparently it >> did boot in the meantime. So it's not a complete hang, it just takes >> unexpectedly long (10+ minutes?) >> >> I'm currently running "make -j24 buildworld" and once it boots it >> looks very fast! > > You ought to determine a cause of the long boot, though. > No compromises or excuses! :-) A similar issue occurred with an HP box recently (in the last 3-4 months?). I'd check the archives for more details. -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 17:04:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCB5106564A; Fri, 19 Nov 2010 17:04:21 +0000 (UTC) (envelope-from ivoras@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 3290E8FC08; Fri, 19 Nov 2010 17:04:20 +0000 (UTC) Received: by vws4 with SMTP id 4so2489936vws.13 for ; Fri, 19 Nov 2010 09:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=shLQsg/D0AtjqcArys3GMaDCiHlhV7pikiFCrZwj8EU=; b=ldMkMb1DyuW/4sZu/nXBNyrGewDHEl/vFsUCgjyM+LY128gXVRJ1YqRzYffctSDpe5 8LDu1YV+3k9fZ7GzQxzqZn330QwPLlcs798dVcIbPe0DKlAZuK1WLUif23D7kazDe5WO bMBUFJ7fbcISfsqCG8IusWyAOALqhJ3pLTtDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=pMm4TlzATQUkg8gGiHQm2lHtrBucl3SPTERMc2s99/XfHuf53+xBudVmjEARQD+PSL sVSKEYtk9rYZ+qsCzWGx6MweO22MJbdcNkM9GXToWIpbx1g3mJ+w9h+5fV7IaUvgSZRv jNnUdpWUK0T7UyAKsulT/gta9xmATVV/WaRkY= Received: by 10.229.246.136 with SMTP id ly8mr1955636qcb.237.1290186259959; Fri, 19 Nov 2010 09:04:19 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 09:03:39 -0800 (PST) In-Reply-To: <4CE6ACEF.4000303@freebsd.org> References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> From: Ivan Voras Date: Fri, 19 Nov 2010 18:03:39 +0100 X-Google-Sender-Auth: z2nBf7Dj-PKtDVP_blZCK97UkaA Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:04:21 -0000 On 19 November 2010 17:59, Andriy Gapon wrote: > on 19/11/2010 18:57 Ivan Voras said the following: >> On 19 November 2010 17:13, Gary Jennejohn wr= ote: >>> On Fri, 19 Nov 2010 17:51:22 +0200 >>> Andriy Gapon wrote: >>> >>>> on 19/11/2010 17:41 Ivan Voras said the following: >>>>> Fujitsu TX300 >>>> >>>> [Thunderbird 3 sometimes fails quoting while replying - blame it] >>>> >>>> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >>>> Not sure if the kernel does that. >>>> >>> >>> Yup, that's the boot loader. =C2=A0The kernel spits out printfs. >> >> Good news, of sorts - I left while I went for dinner and apparently it >> did boot in the meantime. So it's not a complete hang, it just takes >> unexpectedly long (10+ minutes?) >> >> I'm currently running "make -j24 buildworld" and once it boots it >> looks very fast! > > You ought to determine a cause of the long boot, though. > No compromises or excuses! :-) Yes, it does bug me. It looked like a kernel hang (not loader) since the machine didn't respond to ctrl-alt-del, only on cold boot. No BIOS options seemed to help - not disabling SMP nor trying different memory options or timings. From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 17:09:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD3A106564A; Fri, 19 Nov 2010 17:09:10 +0000 (UTC) (envelope-from ivoras@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 85B688FC23; Fri, 19 Nov 2010 17:09:09 +0000 (UTC) Received: by vws4 with SMTP id 4so2494713vws.13 for ; Fri, 19 Nov 2010 09:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=bJuuZDUQctyxEso39U10dXRnGdVuGFZhzyFbr66AbBs=; b=OqQ9fVUp75cjCmoB++c34VrB5cXW8JxdOj7khbut4pFsF33qBBDheK+huy3Cpk2FGD H5xRHSJ/QHsDUvp3pxIZwvVQYL0K2ki6qhjDUgcmcKYmAVVDtToPXoyzjueQytQY3ZHi 1p54FlzT6njjEmUYjmF2VUWkKbH5Ly4WtRF40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=nacy/yfQFw4R4SwlEXzXSnl8gPkjN46zDUgWMmAzaqfvibagGpkXS8DwxLnL+tPrO8 G3C7uF8JkmxJDAyADXZ2H1vvqiB/lvrNlPd/tvDow2Fj6qEsdv3NI9fgDzALKJS1awNg /X0I+7DJH920J3WjO6gF6vIjlQ1gP4hKuIv4E= Received: by 10.229.212.5 with SMTP id gq5mr1949260qcb.275.1290186547433; Fri, 19 Nov 2010 09:09:07 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 09:08:27 -0800 (PST) In-Reply-To: References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> From: Ivan Voras Date: Fri, 19 Nov 2010 18:08:27 +0100 X-Google-Sender-Auth: p6C0ZTAmgKvmx7U0kn70vbjebtQ Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:09:10 -0000 On 19 November 2010 18:04, Garrett Cooper wrote: > A similar issue occurred with an HP box recently (in the last 3-4 > months?). I'd check the archives for more details. Yes, I remembered the post by Sean Bruno but then I also remembered people replying they have successfully booted larger machines than his or mine. What is the last thing the loader does before booting the kernel? Enumberating memory regions? From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 17:09:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6FBC10656CA for ; Fri, 19 Nov 2010 17:09:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9A58FC1D for ; Fri, 19 Nov 2010 17:09:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LC5004506AQRU10@asmtp030.mac.com>; Fri, 19 Nov 2010 09:08:51 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011190121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-19_08:2010-11-19, 2010-11-19, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: Date: Fri, 19 Nov 2010 09:08:50 -0800 Message-id: <6E2CBEBA-FFD7-4BBF-BFAD-192935040105@mac.com> References: <20101118231411.GA5121@freebsd.org> To: Sergey Kandaurov X-Mailer: Apple Mail (2.1082) Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: old references to vfs_mountroot_try() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 17:09:13 -0000 On Nov 19, 2010, at 2:09 AM, Sergey Kandaurov wrote: > On 19 November 2010 02:14, Alexander Best wrote: >> hi there, >> >> vfs_mountroot_try() seems to have been removed, yet the src still contains >> three references to it: >> >> vfs_mount.c:386 >> vfs_mount.c:723 >> freebsd32_misc.c:2368 >> > > So, what about just to rename those comments to reflect function name change? > > Index: sys/kern/vfs_mount.c > =================================================================== > --- sys/kern/vfs_mount.c (revision 215516) > +++ sys/kern/vfs_mount.c (working copy) > @@ -383,7 +383,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > + * MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > Keep it vague. Just change the line to "MNT_ROOTFS should only be set by the kernel when mounting its root file system". The parse_mount() function name has no meaning other than within sys/kern/vfs_mountroot.c, so referring to it isn't making things clear. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 17:43:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78BAC106564A; Fri, 19 Nov 2010 17:43:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 85C1E8FC13; Fri, 19 Nov 2010 17:43:25 +0000 (UTC) Received: by wwd20 with SMTP id 20so4757708wwd.31 for ; Fri, 19 Nov 2010 09:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T6hpIAulMfXqCBWF4T+ng/viExkNOVGn4xKXMrREhx0=; b=HpznpEUEHiJVdpjfWqoaIQ8SXD5OF3MC6zFz/TGs3A32PttzjC12g5LQ9uUZJIWIiw 0QWOjzYIKhAMdEympnhPBAqkRUnG9CBEtNRfiOJPrdOAqDUn3bDDC8pSMJb6rUg5o/ol EjVRSYd4G5N6g9Qnb/cXQOVk72QKJFlKThA/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GuQpQUd1WMydgLeV2eTkz1+wbCQ4QB//jUWMarvmd4Mv2Ujp0uzeKlUT45+g5pmd25 7NmwCv9vfPDw/G0muUEzTYeLC1WU/ekyqyDnnI1EvJfUZQwUf2MZhwnN34DUOW+AJiAn BHJauI3MWRcVtTTimAl8b7KJ4GLiSUjBu0BWs= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr2363223wee.45.1290188602928; Fri, 19 Nov 2010 09:43:22 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 09:43:22 -0800 (PST) In-Reply-To: References: <4C76CA06.5010001@FreeBSD.org> <20101011.192914.82309657.hrs@allbsd.org> Date: Fri, 19 Nov 2010 09:43:22 -0800 X-Google-Sender-Auth: KZf6OJWmUmF7uRaowXZOYh5G4IA Message-ID: From: Garrett Cooper To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-rc@freebsd.org, freebsd-current@freebsd.org, dougb@freebsd.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 17:43:26 -0000 On Fri, Nov 19, 2010 at 2:55 AM, Sergey Kandaurov wrote= : > On 11 October 2010 14:29, Hiroki Sato wrote: >> Hi, >> >> pluknet wrote >> =A0in : >> >> pl> On 27 August 2010 00:09, Doug Barton wrote: >> pl> > On 08/26/2010 12:53 PM, pluknet wrote: >> pl> >> >> pl> >> [cc'ing current@ as rc@ looks too quite] >> pl> >> >> pl> >> Hi. >> pl> >> >> pl> >> Since ifconfig has grown to label interfaces with >> pl> >> ifconfig $ifname description "foobar", what about >> pl> >> to give it more life and store i/face descriptions >> pl> >> semi-permanently, so they will survive between reboots? >> pl> >> >> pl> >> This patch adds a functionality to rc.d to label >> pl> >> interfaces at boot time. >> pl> >> >> pl> >> Comments are welcome. >> pl> > >> pl> > This seems like a good addition, thanks. Please also write a patch= for >> pl> > rc.conf.5 to describe this new functionality and I'll be happy to = commit it. >> pl> >> pl> Xin Li helped me with updating rc.conf.5 (thanks!). >> pl> It's included in attached patch. >> (snip) >> pl> >> + =A0 =A0 =A0 # ifconfig_IF_descr >> pl> >> + =A0 =A0 =A0 for _if in `ifconfig -l`; do >> >> =A0I think using "ifconfig -l" here is not a good idea. =A0Setting a >> =A0description for each interface in a function invoked by ifn_start() >> =A0would be better. >> >> =A0This is beacuse the netif script can be run not only at boottime but >> =A0also via devd or by hand for a specific interface. =A0So, if the >> =A0ifnet_descr is there, "/etc/rc.d/netif start IF" does not make it >> =A0run. =A0Since the description is a per-interface property, >> =A0"/etc/rc.d/netif start IF" should set one, and "/etc/rc.d/netif stop >> =A0IF" should clear one, IMHO. >> >> =A0Also, "ifconfig -l" is not compatible with $network_interfaces, so >> =A0you need to use list_net_interface() for that purpose instead (if you >> =A0move ifnet_descr() into ifn_start() it is useless, though). >> > > Actually, both versions were developed at the same time. > This one follows "netif" approach. Somehow it was rejected > by me for some reasons which I don't remember for now. > That's why I didn't include it to my original message. > > Please, see attached. + _ifdescr=3D"`get_if_var $_if ifconfig_IF_descr`" + if [ ! -z "$_ifdescr" ]; then + ifconfig $_if descr "$_ifdescr" + fi + + return 0 What if the above fails? There are other potential problem areas as well in network.subr (ifscript_up for instance). Thanks, -Garrett > P.S. > Google marks patches as (application/octet-stream). Bad Google. Only if the extension isn't .patch (and it's not just Google -- blame it on other software like Mailman as well) :)... From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:02:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A9AF1065673; Fri, 19 Nov 2010 18:02:25 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 27DD78FC1C; Fri, 19 Nov 2010 18:02:24 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id oAJHHxBE063452; Fri, 19 Nov 2010 11:18:00 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=NzmAX76sTSLLZdCcrSWhxpglmhDuswJtwKJjVpDrZpvPLret0MnhOEHDw9M9FLOfB giYpVwhLCPM7Fq+OR6g/W+Vjm+I0v6KLfcWpV38eMPh9tavYkfP9HuWZUstcjGZYl+P 4Z4O2Kc9Qu7aS7gApwYpjNBuiRfsIkJwrqrLgw0= Message-ID: <4CE6B147.4060203@jrv.org> Date: Fri, 19 Nov 2010 11:17:59 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:02:25 -0000 Ivan Voras wrote: > Unfortunately, the kernel hangs on boot. The loader finishes, the twirly > starts spinning but then hangs. Enabling verbose booting results in > nothing new - no kernel messages at all. I don't think "loader finishes" is correct. Can you break to the loader command line at the beastie menu? At the time of the twirlie I think that the loader is copying the kernel to memory. Perhaps it is having trouble with disk reads, or has a bad memory map. How many disks are attached, and what filesystem type does /boot live on? And what does Fixit mode see (from whatever installed that system)? From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:05:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021261065670; Fri, 19 Nov 2010 18:05:47 +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 C9D9E8FC17; Fri, 19 Nov 2010 18:05:46 +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 6FC9A46B46; Fri, 19 Nov 2010 13:05:46 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81DCF8A01D; Fri, 19 Nov 2010 13:05:45 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Fri, 19 Nov 2010 11:58:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4CE2771F.8020109@freebsd.org> <201011160827.11628.jhb@freebsd.org> <4CE6A3B4.2080604@freebsd.org> In-Reply-To: <4CE6A3B4.2080604@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011191158.19118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 19 Nov 2010 13:05:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: taskqueue_create() name parameter lieftime X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 18:05:47 -0000 On Friday, November 19, 2010 11:20:04 am Andriy Gapon wrote: > on 16/11/2010 15:27 John Baldwin said the following: > > On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > >> > >> taskqueue_create() documentation never explicitly says this, but current > >> taskqueue_create() implementation just stores a 'name' pointer parameter > >> internally. Thus it depends on the 'name' having a life time encompassing that of > >> the taskqueue. > >> I think that alternatively we could have copied the name (or a portion of it) into > >> an internal buffer. > >> I don't any argument for either approach, just curious which one looks more > >> preferable from general (FreeBSD, kernel) programming practices point of view. > > > > Hmm, in many other places we store a separate copy (e.g. all the interrupt > > code uses separate MAXCOMLEN char arrays to hold names). If that is easy to > > do, that is probably the best approach. > > BTW, tq_name doesn't seem to be used anywhere at all. > Perhaps just drop it? But still could be useful in a debugger, though. If it's not used anywhere I would just drop it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:15:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD7E10656A7; Fri, 19 Nov 2010 18:15:33 +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 863F58FC16; Fri, 19 Nov 2010 18:15:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA17131; Fri, 19 Nov 2010 20:15:28 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CE6BEC0.8010908@freebsd.org> Date: Fri, 19 Nov 2010 20:15:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sean Bruno References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> <1290189723.3201.38.camel@home-yahoo> In-Reply-To: <1290189723.3201.38.camel@home-yahoo> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , Ivan Voras , Garrett Cooper Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:15:33 -0000 on 19/11/2010 20:02 Sean Bruno said the following: > What I've seen is that the long pause occurs between the display of the > SMAP (boot verbose) and the copywrite notice. The delay gets worse with > larger memory maps. How much memory do we talk about? I wonder if it could be the code that touches each page to test its usability. Some printf-profiling could be enlightening. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:21:09 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 697D11065670; Fri, 19 Nov 2010 18:21:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 19 Nov 2010 13:20:53 -0500 User-Agent: KMail/1.6.2 References: <4CE6ACEF.4000303@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201011191320.59156.jkim@FreeBSD.org> Cc: Ivan Voras , Andriy Gapon , Garrett Cooper Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:21:09 -0000 On Friday 19 November 2010 12:04 pm, Garrett Cooper wrote: > On Fri, Nov 19, 2010 at 8:59 AM, Andriy Gapon wrote: > > on 19/11/2010 18:57 Ivan Voras said the following: > >> On 19 November 2010 17:13, Gary Jennejohn wrote: > >>> On Fri, 19 Nov 2010 17:51:22 +0200 > >>> > >>> Andriy Gapon wrote: > >>>> on 19/11/2010 17:41 Ivan Voras said the following: > >>>>> Fujitsu TX300 > >>>> > >>>> [Thunderbird 3 sometimes fails quoting while replying - blame > >>>> it] > >>>> > >>>> Perhaps I am wrong, but isn't the "twirly" shown by the > >>>> loader, still? Not sure if the kernel does that. > >>> > >>> Yup, that's the boot loader.  The kernel spits out printfs. > >> > >> Good news, of sorts - I left while I went for dinner and > >> apparently it did boot in the meantime. So it's not a complete > >> hang, it just takes unexpectedly long (10+ minutes?) > >> > >> I'm currently running "make -j24 buildworld" and once it boots > >> it looks very fast! > > > > You ought to determine a cause of the long boot, though. > > No compromises or excuses! :-) > > A similar issue occurred with an HP box recently (in the last 3-4 > months?). I'd check the archives for more details. I bet these are "legacy free" machines, right? I recently noticed that recent Intel chipsets cause incredibly long delays when non-existent ISA ports are accessed, most notably AT keyboard ports. (My gut tells me it is going in and out of SMM repeatedly for nothing.) Back in the old days, when we had real ISA bus, it used to delay very short and fixed amount time. Those days, this behaviour was even (ab)used as a delay function where a real timer is not available yet. ;-) Try getting rid of all unnecessary device drivers from your kernel configuration. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:02:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A53C7106564A; Fri, 19 Nov 2010 18:02:42 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDB98FC0A; Fri, 19 Nov 2010 18:02:41 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id oAJI23Wq029781; Fri, 19 Nov 2010 10:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1290189724; bh=tSWtkG+60ambCVXZcnmJosE4KKIXzt9rz8FJgus468s=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=FrJICAwwscQQcd0K6GIlRe5dr04D9SE579FmrPIlZKDIvS8EZD18EJUKUazo4rANq a7dzPaTCOpYVjn1P2bXvHbTs10xPfjIZ3+JPhKBs1nF6AfxFJbL/Ru0AbYFgte+axH 0DtwU8JRn9o2fDN12iF2+FKR/HOsTtDKhK6/o7zE= From: Sean Bruno To: Ivan Voras In-Reply-To: References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 Nov 2010 10:02:03 -0800 Message-ID: <1290189723.3201.38.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Nov 2010 18:25:27 +0000 Cc: "freebsd-current@freebsd.org" , Andriy Gapon , Garrett Cooper Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:02:42 -0000 On Fri, 2010-11-19 at 09:08 -0800, Ivan Voras wrote: > On 19 November 2010 18:04, Garrett Cooper wrote: > > A similar issue occurred with an HP box recently (in the last 3-4 > > months?). I'd check the archives for more details. > > Yes, I remembered the post by Sean Bruno but then I also remembered > people replying they have successfully booted larger machines than his > or mine. > > What is the last thing the loader does before booting the kernel? > Enumberating memory regions? > _______________________________________________ > 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" What I've seen is that the long pause occurs between the display of the SMAP (boot verbose) and the copywrite notice. The delay gets worse with larger memory maps. Sean From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 18:54:32 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D6B04106566C; Fri, 19 Nov 2010 18:54:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 19 Nov 2010 13:54:21 -0500 User-Agent: KMail/1.6.2 References: <201011152036.48181.jkim@FreeBSD.org> <201011161530.20165.jkim@FreeBSD.org> In-Reply-To: <201011161530.20165.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011191354.25486.jkim@FreeBSD.org> Cc: Ed Schouten , freebsd-stable@freebsd.org, Hans Petter Selasky Subject: Re: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 18:54:33 -0000 On Tuesday 16 November 2010 03:30 pm, Jung-uk Kim wrote: > On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: > > Often times I hear complaints like "my Mac hangs after upgrading > > to 8.1" or "snapshot CD hangs on my brand new Mac". I know some > > of these complaints started happening when we switched to new PAT > > layout. It is so puzzling because it never happened on non-Apple > > hardware, AFAIK. I really like to fix this problem but I cannot > > afford a Mac. :-P > > > > If you are one of those lucky people, please test the attached > > patch and report your hardware model and any improvement or > > regression. > > > > Also, I added a new tunable "vm.pmap.pat_works" so that you can > > turn it off from loader (i.e., "set vm.pmap.pat_works=0") and > > restore old behaviour without recompiling a new kernel. > > I revised this patch to make it more robust. > > http://people.freebsd.org/~jkim/pat-current.diff > > Also, I prepared a patch for stable/8. If you have recent Apple > hardware and it hangs with 8.1 or stable/8, please test this patch. > > http://people.freebsd.org/~jkim/pat-stable.diff Anyone? I don't want to commit it blindly. :-( Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 19:08:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6603E106566B; Fri, 19 Nov 2010 19:08:51 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8E88FC0C; Fri, 19 Nov 2010 19:08:51 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-7-59.dsl.snfc21.pacbell.net [71.139.7.59]) by mail.root.org (Postfix) with ESMTP id 656AD615C; Fri, 19 Nov 2010 19:08:49 +0000 (UTC) Message-ID: <4CE6CB3E.70009@root.org> Date: Fri, 19 Nov 2010 11:08:46 -0800 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andriy Gapon References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> <4CE533DE.7010401@freebsd.org> <4CE68C0B.1080007@freebsd.org> In-Reply-To: <4CE68C0B.1080007@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 19:08:51 -0000 On 11/19/2010 6:39 AM, Andriy Gapon wrote: > > I am thinking about providing two APIs for this. > > 1. KPI > void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); > > 2. Userland > sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. > > But I am not sure where to put the code for both APIs. > Adding another device under cpu seems like an overkill. These can be exported as a common interface from cpufreq (dev,cpu.X.perf_stats) and supplied by the child acpi_perf driver on each cpu. -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 21:08:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E1E1065670; Fri, 19 Nov 2010 21:08:25 +0000 (UTC) (envelope-from lists@mawer.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 5258F8FC0A; Fri, 19 Nov 2010 21:08:25 +0000 (UTC) Received: by qwi4 with SMTP id 4so297821qwi.13 for ; Fri, 19 Nov 2010 13:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.82.85 with SMTP id a21mr2201131qcl.71.1290199375366; Fri, 19 Nov 2010 12:42:55 -0800 (PST) Received: by 10.229.91.66 with HTTP; Fri, 19 Nov 2010 12:42:55 -0800 (PST) In-Reply-To: <4CE69CFA.4030803@freebsd.org> References: <4CE69CFA.4030803@freebsd.org> Date: Sat, 20 Nov 2010 07:42:55 +1100 Message-ID: From: Antony Mawer To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 21:08:25 -0000 On Sat, Nov 20, 2010 at 2:51 AM, Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: >> Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] If you select any text in the message then click reply, it only quotes the selected text (not entirely intuitive, but that's the way they decided to make it work). --Antony From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 21:23:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C86FA106564A for ; Fri, 19 Nov 2010 21:23:01 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id AF42D8FC1B for ; Fri, 19 Nov 2010 21:23:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LC5000V7I2CN250@asmtp026.mac.com> for freebsd-current@freebsd.org; Fri, 19 Nov 2010 13:23:01 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011190186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-19_10:2010-11-19, 2010-11-19, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: Date: Fri, 19 Nov 2010 13:23:00 -0800 Message-id: References: <4CE69CFA.4030803@freebsd.org> To: Antony Mawer X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Current Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 21:23:01 -0000 On Nov 19, 2010, at 12:42 PM, Antony Mawer wrote: > If you select any text in the message then click reply, it only quotes > the selected text (not entirely intuitive, but that's the way they > decided to make it work). Ah, yes: https://bugzilla.mozilla.org/show_bug.cgi?id=23394 There's a standard for mail and news readers (GNKSA) which expects "Provides adequate quotation and attribution facilities"; it's expected that there should be a preference which allows a user to decide whether to quote all text or just the selected text when composing a reply. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 21:23:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFAA7106566B for ; Fri, 19 Nov 2010 21:23:41 +0000 (UTC) (envelope-from oliver.pntr@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 04BF48FC12 for ; Fri, 19 Nov 2010 21:23:40 +0000 (UTC) Received: by wyb35 with SMTP id 35so4128854wyb.13 for ; Fri, 19 Nov 2010 13:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ClZxLvr4eJglKO5vy7Esj/+aMf3wZVPDmlXtcU7bq/g=; b=BjWWJ+tnI+WW/yWtiAma98T38xJZPMy82D1fn8bIeAPTIpKU+IHTdkPV7Lx68fonGc Ih5Abqgqch36Djz/qfkd78r7z5Aok9bF7BKk2EfqiyuXy+bg7FejIVW1U578DR2twYZN 3gSAd7zqw1pae7DDZWfazjJVBUNdseZfb1IJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ID8svAz3NrIT3LxqEaR3qUkR/PVGupBLLq6KrifweQHLMh5R/Ac3HupMFV4ZqsxKNd EzP+9HYIrDnM+2FL3WOel0JvFDyS2+EBQifHXqICvXTHH144WXOLu5yWPHGYAJFFVQKe WPSIQqy15/AJCi7VVCNJdTVWG6HVvjlH2H7KM= MIME-Version: 1.0 Received: by 10.227.135.85 with SMTP id m21mr2863703wbt.227.1290201370669; Fri, 19 Nov 2010 13:16:10 -0800 (PST) Received: by 10.227.133.66 with HTTP; Fri, 19 Nov 2010 13:16:09 -0800 (PST) In-Reply-To: <20101119152855.GA34603@freebsd.org> References: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> <4CDF0F03.10703@freebsd.org> <20101115221924.GA38676@freebsd.org> <20101119152855.GA34603@freebsd.org> Date: Fri, 19 Nov 2010 22:16:09 +0100 Message-ID: From: Oliver Pinter To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-current@freebsd.org, "Robert N. M. Watson" , Garrett Cooper Subject: Re: www/chromium crashing whole system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 21:23:42 -0000 can you try disable the chrome sandbox feature? chmod -s chrome-sandbox mv chrome-sandbox chrome-sandbox.disabled_feature and after this, the problem is still represented? under linux with grsec path, with enabled sandbox, do not started, I know, that is a fully different problem On 11/19/10, Alexander Best wrote: > On Tue Nov 16 10, Robert N. M. Watson wrote: >> >> On 15 Nov 2010, at 22:19, Alexander Best wrote: >> >> > thanks for all your help. i've recently switched to chromium 6.0.472.63 >> > and so far my computer has been very stable. >> > >> > if i experience more lock ups i'll let you know and try to figure out a >> > way to >> > gain access to some more debugging data. >> >> I'd prefer we try to figure out why your system was crashing now -- the >> kernel bug has not gone away just because Chromium is no longer triggering >> it. Working around the bug means someone else gets to run into it later -- >> perhaps when it's 9.0-RELEASE rather than 9-CURRENT... > > "GOOD" news btw: the new chromium port just crashed my system. ;) so the > issue is still there. > > and be issue i mean the code that triggers the crash. > >> >> Robert > -- > a13x > _______________________________________________ > 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 19 21:35:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BADF1106566B; Fri, 19 Nov 2010 21:35:07 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 045E68FC18; Fri, 19 Nov 2010 21:35:06 +0000 (UTC) Received: by wwb17 with SMTP id 17so761067wwb.1 for ; Fri, 19 Nov 2010 13:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PsIHBlWEyPmN6HqKUL3brVtQee4UfxNPxql8LwGgqG0=; b=o3RDokiyqa8gOh1254/uN8hkdYQH1LoDRFWFpVIFjQhXkvNK3P4N0bP93X6xOnPJrw ZNwq0fR4XnJ1H2qJRxdDgoUAF33UpR6eysqJmP5jPlwoNPEJ+W2NKFQnaXzgzLDEvd/A IpohYac81miTFPnUD1MExXEbLyqZLINR888tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NTpl+pc0WxZCsTMPRIGoVbi3bhyY14lCm8lufs+O/SaYplA/tobR4A+HE8dTomzgzH 1Uxa2DUvb8UIX/oo1zNF9/MEbrishCFW9F01K7o5yXPd0Zzt3NyjtcRgM6qTIRITPb1y DAXcwukR3+ohIrg0buj27PbiWtJrVRLHAjYVE= MIME-Version: 1.0 Received: by 10.227.142.208 with SMTP id r16mr2878057wbu.140.1290201049361; Fri, 19 Nov 2010 13:10:49 -0800 (PST) Received: by 10.227.133.66 with HTTP; Fri, 19 Nov 2010 13:10:48 -0800 (PST) In-Reply-To: <4CE50849.106@zedat.fu-berlin.de> References: <4CE50849.106@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 22:10:48 +0100 Message-ID: From: Oliver Pinter To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-performance@freebsd.org, FreeBSD Current , FreeBSD Stable Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 21:35:07 -0000 http://lkml.org/lkml/2010/11/16/392 On 11/18/10, O. Hartmann wrote: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this > will make it in due time to FreeBSD's kernel. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 22:47:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FDD106566C; Fri, 19 Nov 2010 22:47:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 08B818FC16; Fri, 19 Nov 2010 22:47:19 +0000 (UTC) Received: by wyb35 with SMTP id 35so4204311wyb.13 for ; Fri, 19 Nov 2010 14:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=OKivmdL38kmUllIet02P14SJJSx6J4tTwf29wTSZyu0=; b=qv+BR7YYdKqvLC+3pbAo9AyERTfIbpoqX7YRxEkMNTw1F/VVLB83cG06psQIPQS0xQ N2x7G9lF3tYdZNhTC0h06G7t7KOo/uLL7qolTQNhvNtgItG8WT521pSoruF0op9/q4tD vDlPj+sD8v/GCaEQQx1vBOcDiUzSNHn1hSvcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=iqROAnHc5dMouhtLYDBTThJ5Jpa5eD6/cnxCOvyzSVsUJBxvE3VKLKMumQvFFmPxvJ r/lIdUnzOsXZOaeCYn31C6OjEx8ngu1aJeLA3zML9dl3FGi42uNsiMR9lXdyw7+mQBbh G33tdjUvBkSs7NIiIwK/YJSv2xbbqWXr1NaF0= MIME-Version: 1.0 Received: by 10.216.50.134 with SMTP id z6mr3080976web.15.1290206834004; Fri, 19 Nov 2010 14:47:14 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 14:46:51 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 14:46:51 -0800 X-Google-Sender-Auth: UWBQV1PqdJN4_V7UOuWPfL6gjXY Message-ID: From: Garrett Cooper To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 22:47:21 -0000 On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter wrote: > http://lkml.org/lkml/2010/11/16/392 > > On 11/18/10, O. Hartmann wrote: >> On 11/18/10 02:30, grarpamp wrote: >>> Just documenting regarding interactive performance things. >>> This one's from Linux. >>> >>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >> >> Well, >> it would be nice to have those improvements in FreeBSD, but I doubt this >> will make it in due time to FreeBSD's kernel. And my one line fix: renice 10 `pidof firefox-bin` Instantly my system is snappier (and in fact my system got really laggy after applying the preempt sysctl that everyone recommended before)... Performance issue with firefox maybe :P? I don't see the point of adding an additional layer to complicate the system (and essentially slow it down) if all you're trying to do is better describe the nice'ing problem, unless this logic is what you want to do strictly for desktop users in PCBSD, etc who may not have the technical wherewithal to accomplish this task. Besides, the Linux kernel has different compile time profiles for different workloads, so maybe it just works better for them because they already have a means for describing that functionality, whereas FreeBSD is more generic. It would be nice to describe this in a document though so people could also decide how to tune the system for themselves and not deal with a patch like what's noted above by the penguin crowd because it will invariably fail under some workloads or conditions (I have yet to see a one-size-fits-all solution in this area). SCHED_ULE improvements though should be looked into if possible, because there are some potential items that could be done to cluster processes together better, maybe. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 22:48:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C681065670; Fri, 19 Nov 2010 22:48:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFDE8FC21; Fri, 19 Nov 2010 22:48:51 +0000 (UTC) Received: by wyb35 with SMTP id 35so4205885wyb.13 for ; Fri, 19 Nov 2010 14:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=OKivmdL38kmUllIet02P14SJJSx6J4tTwf29wTSZyu0=; b=CxOCWEM4tSuYbm8sJrVTwvR49GlQL1vNjymk+PQ1OMRJShd41sUnTM57KnuR2DqGEX nNzq2h/PzPSQIvDWy//va9OHFppkqd0wXeRsRNKlbiaOStDh57+WpfIcwNdsMViFXNmC BJSUa77I4UrBaJ63oz9kZsUFrGENHCOhYgJEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=iqROAnHc5dMouhtLYDBTThJ5Jpa5eD6/cnxCOvyzSVsUJBxvE3VKLKMumQvFFmPxvJ r/lIdUnzOsXZOaeCYn31C6OjEx8ngu1aJeLA3zML9dl3FGi42uNsiMR9lXdyw7+mQBbh G33tdjUvBkSs7NIiIwK/YJSv2xbbqWXr1NaF0= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr1631469web.45.1290206829686; Fri, 19 Nov 2010 14:47:09 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 14:46:51 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 14:46:51 -0800 X-Google-Sender-Auth: UWBQV1PqdJN4_V7UOuWPfL6gjXY Message-ID: From: Garrett Cooper To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 22:48:52 -0000 On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter wrote: > http://lkml.org/lkml/2010/11/16/392 > > On 11/18/10, O. Hartmann wrote: >> On 11/18/10 02:30, grarpamp wrote: >>> Just documenting regarding interactive performance things. >>> This one's from Linux. >>> >>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >> >> Well, >> it would be nice to have those improvements in FreeBSD, but I doubt this >> will make it in due time to FreeBSD's kernel. And my one line fix: renice 10 `pidof firefox-bin` Instantly my system is snappier (and in fact my system got really laggy after applying the preempt sysctl that everyone recommended before)... Performance issue with firefox maybe :P? I don't see the point of adding an additional layer to complicate the system (and essentially slow it down) if all you're trying to do is better describe the nice'ing problem, unless this logic is what you want to do strictly for desktop users in PCBSD, etc who may not have the technical wherewithal to accomplish this task. Besides, the Linux kernel has different compile time profiles for different workloads, so maybe it just works better for them because they already have a means for describing that functionality, whereas FreeBSD is more generic. It would be nice to describe this in a document though so people could also decide how to tune the system for themselves and not deal with a patch like what's noted above by the penguin crowd because it will invariably fail under some workloads or conditions (I have yet to see a one-size-fits-all solution in this area). SCHED_ULE improvements though should be looked into if possible, because there are some potential items that could be done to cluster processes together better, maybe. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 19 22:52:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25FC1065673; Fri, 19 Nov 2010 22:52:22 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD648FC12; Fri, 19 Nov 2010 22:52:22 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id oAJMqKGI067295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 16:52:20 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id oAJMqKr7091910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 16:52:20 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id oAJMdriZ056350; Fri, 19 Nov 2010 16:39:53 -0600 (CST) (envelope-from dan) Date: Fri, 19 Nov 2010 16:39:52 -0600 From: Dan Nelson To: Alexander Leidinger Message-ID: <20101119223952.GK57869@dan.emsphone.com> References: <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101118182852.GR63683@over-yonder.net> <20101118185635.GA43706@freebsd.org> <20101118170623.7f9c14f3@kan.dnsalias.net> <20101118233731.GA10392@freebsd.org> <4CE5BA37.20604@freebsd.org> <20101119001710.GA14641@freebsd.org> <20101119120859.59361egrovtna9q8@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101119120859.59361egrovtna9q8@webmail.leidinger.net> X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.4 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Fri, 19 Nov 2010 16:52:20 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 X-Mailman-Approved-At: Fri, 19 Nov 2010 23:12:30 +0000 Cc: Andriy@freebsd.org, FreeBSD@freebsd.org, Stable , "O. Hartmann" , "Matthew D. Fuller" , Current , Gapon , Alexander Best , freebsd-performance@freebsd.org, Daniel Nebdal Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Nov 2010 22:52:22 -0000 In the last episode (Nov 19), Alexander Leidinger said: > Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 +0000): > > 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or thereabouts > > 17:51 @ Genesys : you could kldload new ones and switch to them on the fly > > 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it > > into src tree. by now it's probably outdated and needs to be reworked quite a bit. > > **** > > > > does anybody know something about this? > > I'm aware of the I/O scheduling code (which is now available at least > in -current), but I do not remember CPU scheduling code from Luigi. > Are you sure Genesys didn't mix up something by accident? I am rarely mixed up :) A quick search didn't bring up a direct reference, but here's a mention of it from Luigi: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-November/008891.html -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 00:20:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 499B81065672 for ; Sat, 20 Nov 2010 00:20:50 +0000 (UTC) (envelope-from ivoras@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 F412F8FC0A for ; Sat, 20 Nov 2010 00:20:49 +0000 (UTC) Received: by qwi4 with SMTP id 4so464308qwi.13 for ; Fri, 19 Nov 2010 16:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=5q/Z18Qzd8LgR0HY0lzRmieBqUcSNBgYKVV23rJpO2Q=; b=Mo+0q9xjQgWTcL5eA81Ry4XZctRLLI4iClW5rkUfHKNBpoeCPkYhkd5hKay1600RAb nUuabmRldoIjRbCCmH6d2uz2PRx04fCs6ACEhVBnw+RQHKBToJRsSbzP6FOCrHUG9g2B 2oteQRKUaHrMcK0x+PGF4ML1h8m62Br/pVKi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ZiQjpqHMs0gMGKGv2i6sX9V8XlEHdtHAjtQAYQk8bd83LaD7bu999V50R8w08mQVzS 06thneb9R9Q+JHiN/LiUD9LwyJLO/WSylhkPBHJuVm1Id2pYvaJ2+b99GO5abVQUM42L W4GJ9Rr1CE0AVj93y5J5zM9K87wgaAbIcCQJ8= Received: by 10.229.182.75 with SMTP id cb11mr2330353qcb.199.1290212448396; Fri, 19 Nov 2010 16:20:48 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Fri, 19 Nov 2010 16:20:07 -0800 (PST) In-Reply-To: <4CE6B147.4060203@jrv.org> References: <4CE6B147.4060203@jrv.org> From: Ivan Voras Date: Sat, 20 Nov 2010 01:20:07 +0100 X-Google-Sender-Auth: vT8Lz2IXjfyN8OTnvN_QAOoGNHE Message-ID: To: "James R. Van Artsdalen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 00:20:50 -0000 On 19 November 2010 18:17, James R. Van Artsdalen wrote: > Ivan Voras wrote: >> Unfortunately, the kernel hangs on boot. The loader finishes, the twirly >> starts spinning but then hangs. Enabling verbose booting results in >> nothing new - no kernel messages at all. > > I don't think "loader finishes" is correct. =C2=A0Can you break to the lo= ader > command line at the beastie menu? Yes. Everything in the loader itself works fine, including hardware detecti= on. > At the time of the twirlie I think that the loader is copying the kernel > to memory. =C2=A0Perhaps it is having trouble with disk reads, or has a b= ad > memory map. > > How many disks are attached, and what filesystem type does /boot live > on? =C2=A0And =C2=A0what does Fixit mode see (from whatever installed tha= t system)? There are three RAID volumes visible to the system, and all three are successfully detected and used. root and /boot are completely standard UFS. It is "legacy free" hardware in the sense that it doesn't have PS2 ports, and has the latest generation CPUs with a whole bunch of new technologies. From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 00:36:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EA5F106566B for ; Sat, 20 Nov 2010 00:36:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D68568FC0C for ; Sat, 20 Nov 2010 00:36:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJbRB-00038D-Ot for freebsd-current@freebsd.org; Sat, 20 Nov 2010 01:36:17 +0100 Received: from cpe-188-129-101-155.dynamic.amis.hr ([188.129.101.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 01:36:17 +0100 Received: from ivoras by cpe-188-129-101-155.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 01:36:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 20 Nov 2010 01:36:04 +0100 Lines: 102 Message-ID: References: <4CE69CFA.4030803@freebsd.org> <20101119171359.65b43213@ernst.jennejohn.org> <4CE6ACEF.4000303@freebsd.org> <1290189723.3201.38.camel@home-yahoo> <4CE6BEC0.8010908@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-101-155.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4CE6BEC0.8010908@freebsd.org> Subject: Re: A big-ish machine, cannot boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 00:36:19 -0000 On 11/19/10 19:15, Andriy Gapon wrote: > on 19/11/2010 20:02 Sean Bruno said the following: >> What I've seen is that the long pause occurs between the display of the >> SMAP (boot verbose) and the copywrite notice. The delay gets worse with >> larger memory maps. > > How much memory do we talk about? 24 GB. I think I saw reports of larger memories so I don't think this is critical (unless something's wrong). > I wonder if it could be the code that touches each page to test its usability. > Some printf-profiling could be enlightening. No printf debugging this time, I don't have physical access to it for the weekend (but have ssh). Here's the CPU topology (correctly parsed, thankfully :) ), if someone's interested: biggie# sysctl kern.sched.topology_spec kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 0, 1 THREAD groupSMT group 2, 3 THREAD groupSMT group 4, 5 THREAD groupSMT group 6, 7 THREAD groupSMT group 8, 9 THREAD groupSMT group 10, 11 THREAD groupSMT group 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 12, 13 THREAD groupSMT group 14, 15 THREAD groupSMT group 16, 17 THREAD groupSMT group 18, 19 THREAD groupSMT group 20, 21 THREAD groupSMT group 22, 23 THREAD groupSMT group From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 01:16:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01197106564A for ; Sat, 20 Nov 2010 01:16:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A5F0A8FC0C for ; Sat, 20 Nov 2010 01:16:40 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJc4F-0004Pi-L2 for freebsd-current@freebsd.org; Sat, 20 Nov 2010 02:16:39 +0100 Received: from cpe-188-129-101-155.dynamic.amis.hr ([188.129.101.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 02:16:39 +0100 Received: from ivoras by cpe-188-129-101-155.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 02:16:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 20 Nov 2010 02:16:24 +0100 Lines: 37 Message-ID: References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <4CE58CD8.2000407@mail.zedat.fu-berlin.de> <20101120004955.68c8af6a.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-101-155.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20101120004955.68c8af6a.taku@tackymt.homeip.net> Cc: freebsd-performance@freebsd.org, freebsd-stable@freebsd.org Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 01:16:41 -0000 On 11/19/10 16:49, Taku YAMAMOTO wrote: > I have a dumb local hack to grant ts_slice proportional to the duration > the waking thread slept rather than unconditionally reset to sched_slice. > > > --- sys/kern/sched_ule.c.orig > +++ sys/kern/sched_ule.c > @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) > u_int hzticks; > > hzticks = (ticks - slptick)<< SCHED_TICK_SHIFT; > + if (hzticks> SCHED_SLP_RUN_MAX) > + hzticks = SCHED_SLP_RUN_MAX; > ts->ts_slptime += hzticks; > + /* Grant additional slices after we sleep. */ > + ts->ts_slice += hzticks / tickincr; > + if (ts->ts_slice > sched_slice) > + ts->ts_slice = sched_slice; If I read it correctly, now instead of the slice given to the thread being always sched_slice, now it is reduced to a value smaller than sched_slice based on how long did the thread sleep? How does that help? > sched_interact_update(td); > sched_pctcpu_update(ts); > } > - /* Reset the slice value after we sleep. */ > - ts->ts_slice = sched_slice; > sched_add(td, SRQ_BORING); > } > > > From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 01:28:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED826106566B; Sat, 20 Nov 2010 01:28:03 +0000 (UTC) (envelope-from oliver.pntr@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 0A4C68FC1B; Sat, 20 Nov 2010 01:28:02 +0000 (UTC) Received: by wyb35 with SMTP id 35so4319483wyb.13 for ; Fri, 19 Nov 2010 17:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tdNpb1QEuoGB8Gal23sGmrl4q11vEcMsiq1Tq+aaUCs=; b=u0m0jsJkKbk+PawPHQtsBK7Wbjd0FFQaEuPHUItchgBNsl6hKhmrEG8rsmwxhA//R4 dLj5ED+6p2cyR5BgHZ9JFGgl4E87LUZ6AVRRML9y/Zgau7r2WIaSYoN1QQtPZuxzlbIn be08Us0ADuPSQ9ogf8YFdSFMRXcah8QFw0mu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vnwp9t8j3YW/jfdYkbfTcGhsfFoF60wwhFRslJqdXzCGm5aT+1edxgw31BEiuZEkzS OkD6T9ovRkjzyIJPvbkQGDJcRkBXdWfuykK3utWAMLp7fgk0sne15u+CbF0615D5PeUW ZFmtg6rj5aPUuuYb6IY4luI5A04j2NlJCYDwI= MIME-Version: 1.0 Received: by 10.227.157.133 with SMTP id b5mr3103975wbx.53.1290216480334; Fri, 19 Nov 2010 17:28:00 -0800 (PST) Received: by 10.227.133.66 with HTTP; Fri, 19 Nov 2010 17:27:59 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Sat, 20 Nov 2010 02:27:59 +0100 Message-ID: From: Oliver Pinter To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 01:28:04 -0000 My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system), I tested 8-STABLE, but that is not too responsive, the solution is: 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 After this setting, the system is likely responsive as 7-STABLE. On 11/19/10, Garrett Cooper wrote: > On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter > wrote: >> http://lkml.org/lkml/2010/11/16/392 >> >> On 11/18/10, O. Hartmann wrote: >>> On 11/18/10 02:30, grarpamp wrote: >>>> Just documenting regarding interactive performance things. >>>> This one's from Linux. >>>> >>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>> >>> Well, >>> it would be nice to have those improvements in FreeBSD, but I doubt this >>> will make it in due time to FreeBSD's kernel. > > And my one line fix: > > renice 10 `pidof firefox-bin` > > Instantly my system is snappier (and in fact my system got really > laggy after applying the preempt sysctl that everyone recommended > before)... Performance issue with firefox maybe :P? I don't see the > point of adding an additional layer to complicate the system (and > essentially slow it down) if all you're trying to do is better > describe the nice'ing problem, unless this logic is what you want to > do strictly for desktop users in PCBSD, etc who may not have the > technical wherewithal to accomplish this task. > > Besides, the Linux kernel has different compile time profiles for > different workloads, so maybe it just works better for them because > they already have a means for describing that functionality, whereas > FreeBSD is more generic. > > It would be nice to describe this in a document though so people could > also decide how to tune the system for themselves and not deal with a > patch like what's noted above by the penguin crowd because it will > invariably fail under some workloads or conditions (I have yet to see > a one-size-fits-all solution in this area). > > > SCHED_ULE improvements though should be looked into if possible, > because there are some potential items that could be done to cluster > processes together better, maybe. > > > Thanks, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 01:49:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFD61065670; Sat, 20 Nov 2010 01:49:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45DA08FC18; Sat, 20 Nov 2010 01:49:56 +0000 (UTC) Received: by wyb35 with SMTP id 35so4331934wyb.13 for ; Fri, 19 Nov 2010 17:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wZO0ulBRbTTkGcgy2Q32ThZN1QGyz5faGrbY6qdrhk4=; b=uMvThrM186fUIob7w7ojR5UPi6e+LsRZBxYjxmecGe53nMLZV7NcvbmWSIbIn6/Q36 tDFf7pr/s2OZPFI+ReQ8Jej7NPYOA8mItz7EwRqGIjRRCcYaBifN4IetxHTWhiczPM9k kKuDEdoFgnFI/TvI9p+77w5/mkP3PcF+xq3nI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QvOVQpuXF+ey5BdpdazZZWZEN5lEbfh7yHaXmQlED6WoTcrqpiYuW78hwoRMr2pThB TP9mMEO2wNMQzeiuUda4qpQPt/gulAT6pVzM/nyyNnwniq5k16Qh4aihLshY8EpR73/T EZvzUMGrY2qjvc90vH3hg3sRXrb27frZ5xJC4= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1774698wep.30.1290217795101; Fri, 19 Nov 2010 17:49:55 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 17:49:55 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 17:49:55 -0800 X-Google-Sender-Auth: Hg2MQh2qNfgfohc6PYyqzyksUxo Message-ID: From: Garrett Cooper To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 01:49:58 -0000 On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter wrote: > My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system), > I tested 8-STABLE, but that is not too responsive, the solution is: > 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 > After this setting, the system is likely responsive as 7-STABLE. > > On 11/19/10, Garrett Cooper wrote: >> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter >> wrote: >>> http://lkml.org/lkml/2010/11/16/392 >>> >>> On 11/18/10, O. Hartmann wrote: >>>> On 11/18/10 02:30, grarpamp wrote: >>>>> Just documenting regarding interactive performance things. >>>>> This one's from Linux. >>>>> >>>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>>> >>>> Well, >>>> it would be nice to have those improvements in FreeBSD, but I doubt this >>>> will make it in due time to FreeBSD's kernel. >> >> And my one line fix: >> >> renice 10 `pidof firefox-bin` >> >> Instantly my system is snappier (and in fact my system got really >> laggy after applying the preempt sysctl that everyone recommended >> before)... Performance issue with firefox maybe :P? I don't see the >> point of adding an additional layer to complicate the system (and >> essentially slow it down) if all you're trying to do is better >> describe the nice'ing problem, unless this logic is what you want to >> do strictly for desktop users in PCBSD, etc who may not have the >> technical wherewithal to accomplish this task. >> >> Besides, the Linux kernel has different compile time profiles for >> different workloads, so maybe it just works better for them because >> they already have a means for describing that functionality, whereas >> FreeBSD is more generic. >> >> It would be nice to describe this in a document though so people could >> also decide how to tune the system for themselves and not deal with a >> patch like what's noted above by the penguin crowd because it will >> invariably fail under some workloads or conditions (I have yet to see >> a one-size-fits-all solution in this area). >> >> >> SCHED_ULE improvements though should be looked into if possible, >> because there are some potential items that could be done to cluster >> processes together better, maybe. >> Ugh. Looks like this was the only machine that I setup recently where I didn't set kern.hz... Ok, will retry after building and installing a whole new world *queue lame Disney music here* and kernel. Thanks for the obvious reminder... -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 09:54:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A163106566B; Sat, 20 Nov 2010 09:54:07 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 468148FC12; Sat, 20 Nov 2010 09:54:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA26809; Sat, 20 Nov 2010 11:54:02 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJk8v-0000hl-V6; Sat, 20 Nov 2010 11:54:01 +0200 Message-ID: <4CE79AB9.1020303@freebsd.org> Date: Sat, 20 Nov 2010 11:54:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nate Lawson References: <4CE29718.2050508@freebsd.org> <4CE51CDA.6010202@freebsd.org> <4CE533DE.7010401@freebsd.org> <4CE68C0B.1080007@freebsd.org> <4CE6CB3E.70009@root.org> In-Reply-To: <4CE6CB3E.70009@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: aperf/mperf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 09:54:07 -0000 on 19/11/2010 21:08 Nate Lawson said the following: > On 11/19/2010 6:39 AM, Andriy Gapon wrote: >> >> I am thinking about providing two APIs for this. >> >> 1. KPI >> void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); >> >> 2. Userland >> sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. >> >> But I am not sure where to put the code for both APIs. >> Adding another device under cpu seems like an overkill. > > These can be exported as a common interface from cpufreq > (dev,cpu.X.perf_stats) and supplied by the child acpi_perf driver on > each cpu. This suggestion sounds quite appealing. But I have some concerns. What if hardware has the capability, but there is no cpufreq - could these MSRs be still useful? Or are they useful only with cpufreq? Probably the latter... Then, another exotic case - if a driver like est or hwpstate is attached "directly", i.e. there is no acpi_perf/_PSS - would the MSRs be still useful? Not sure. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 10:00:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0966A1065670; Sat, 20 Nov 2010 10:00:38 +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 A24BE8FC16; Sat, 20 Nov 2010 10:00:36 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26867; Sat, 20 Nov 2010 12:00:35 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJkFH-0000iT-3P; Sat, 20 Nov 2010 12:00:35 +0200 Message-ID: <4CE79C42.6000103@freebsd.org> Date: Sat, 20 Nov 2010 12:00:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <4CE2771F.8020109@freebsd.org> <201011160827.11628.jhb@freebsd.org> <4CE6A3B4.2080604@freebsd.org> <201011191158.19118.jhb@freebsd.org> In-Reply-To: <201011191158.19118.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: removing tq_name [Was: taskqueue_create() name parameter lieftime] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 10:00:38 -0000 on 19/11/2010 18:58 John Baldwin said the following: > On Friday, November 19, 2010 11:20:04 am Andriy Gapon wrote: >> BTW, tq_name doesn't seem to be used anywhere at all. >> Perhaps just drop it? But still could be useful in a debugger, though. > > If it's not used anywhere I would just drop it. > struct taskqueue is defined privately in sys/kern/subr_taskqueue.c and tq_name is used "write-only" in _taskqueue_create(). So, no use for tq_name at all? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 10:11:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 428E11065670; Sat, 20 Nov 2010 10:11:59 +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 58E9A8FC1A; Sat, 20 Nov 2010 10:11:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26967; Sat, 20 Nov 2010 12:11:55 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJkQF-0000jM-16; Sat, 20 Nov 2010 12:11:55 +0200 Message-ID: <4CE79EEA.9060200@freebsd.org> Date: Sat, 20 Nov 2010 12:11:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nate Lawson References: <4CE579DD.2030406@freebsd.org> <4CE5A282.1000300@root.org> In-Reply-To: <4CE5A282.1000300@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ideas for _PSD/_CSD/_TSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 10:11:59 -0000 on 19/11/2010 00:02 Nate Lawson said the following: > On 11/18/2010 11:09 AM, Andriy Gapon wrote: >> I am trying to solicit some architectural/design ideas for implementing logic that >> would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. >> Well, I am primarily interested in _PSD, but I think that some general principles >> could be shared. >> >> In simple terms. >> Currently we do only the "global" P-state management. cpufreq advertises a common >> set of frequencies/P-states and a single P-state/frequency is set on all (logical) >> processors by e.g. powerd based on global system load. >> The downsides are obvious, I think. >> >> Modern systems can provide _PSD method which describes grouping of logical >> processors into P-state domains and nature of dependency between the processors in >> the domain. E.g. on some systems putting a single processor from the domain into >> a Px state results in all the processors being put into that state. On other >> systems, all processors have to be put into the same state for it to become >> effective. On yet other systems there could be no coordination required between >> the processors (even when they are all cores in the same package), so each would >> be placed in its own domain. >> >> I think that this issue may get more prominence because of the new technologies >> that combine power saving with "turbo boosting". E.g. there could be a technology >> where some processor's performance would only be boosted if other processors are >> at or above some state Pt. With current cpufreq design we would not be able to >> take an advantage of that, because we always put all the processors into the same >> state. > > As you can see from the codebase, cpufreq was designed with this model > in mind. I spent a lot of work adding the cpu devices to newbus in order > to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq > setting. Yes, I do see that. Thanks! > Of course, there weren't any asymmetrical CPU Px states back then so > calculation of levels is shared as you point out. But since it's done in > cpufreq attach(), it is easy to make that independent while still > merging states with global settings (e.g., p4tcc relative levels that > apply system-wide, not per-cpu). Indeed. > What you want is to have a flag that indicates if Px states are global > or not. If global, you can still attach a cpufreq device to each cpu but > make changing any of their settings loop through changing all cpu > settings equally. This is how it currently works. If the flag is false, > then only apply a setting to the device it was received on. Yes. But I am not sure right now where to put and how query the _PSD information. Most likely this should to acpi_perf. Then the hardware-specific drivers under acpi_perf (if any) could obtain the information from acpi_perf. Some questions then - should we attach one instance of acpi_perf under each CPU or once per domain (to an arbitrary CPU in each domain). Ditto for the hardware specific drivers. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 13:44:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8173106564A for ; Sat, 20 Nov 2010 13:44:37 +0000 (UTC) (envelope-from reuf_m@hotmail.com) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by mx1.freebsd.org (Postfix) with ESMTP id AC8588FC0A for ; Sat, 20 Nov 2010 13:44:37 +0000 (UTC) Received: from BLU0-SMTP113 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Nov 2010 05:32:35 -0800 X-Originating-IP: [62.167.127.96] X-Originating-Email: [reuf_m@hotmail.com] Message-ID: Received: from reuf-mustabasics-imac.local ([62.167.127.96]) by BLU0-SMTP113.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Nov 2010 05:32:36 -0800 Content-Type: text/plain; charset="iso-8859-15"; format=flowed; delsp=yes To: freebsd-current@freebsd.org References: <201011152036.48181.jkim@FreeBSD.org> <201011161530.20165.jkim@FreeBSD.org> <201011191354.25486.jkim@FreeBSD.org> Date: Sat, 20 Nov 2010 14:32:34 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: RM In-Reply-To: <201011191354.25486.jkim@FreeBSD.org> User-Agent: Opera Mail/10.63 (MacIntel) X-OriginalArrivalTime: 20 Nov 2010 13:32:36.0153 (UTC) FILETIME=[64C9CA90:01CB88B7] Subject: Re: [Call for Tests] PAT issue on Apple hardware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 13:44:38 -0000 On Fri, 19 Nov 2010 19:54:21 +0100, Jung-uk Kim wrote: > On Tuesday 16 November 2010 03:30 pm, Jung-uk Kim wrote: >> On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: >> > Often times I hear complaints like "my Mac hangs after upgrading >> > to 8.1" or "snapshot CD hangs on my brand new Mac". I know some >> > of these complaints started happening when we switched to new PAT >> > layout. It is so puzzling because it never happened on non-Apple >> > hardware, AFAIK. I really like to fix this problem but I cannot >> > afford a Mac. :-P >> > >> > If you are one of those lucky people, please test the attached >> > patch and report your hardware model and any improvement or >> > regression. >> > >> > Also, I added a new tunable "vm.pmap.pat_works" so that you can >> > turn it off from loader (i.e., "set vm.pmap.pat_works=0") and >> > restore old behaviour without recompiling a new kernel. >> >> I revised this patch to make it more robust. >> >> http://people.freebsd.org/~jkim/pat-current.diff >> >> Also, I prepared a patch for stable/8. If you have recent Apple >> hardware and it hangs with 8.1 or stable/8, please test this patch. >> >> http://people.freebsd.org/~jkim/pat-stable.diff > > Anyone? I don't want to commit it blindly. :-( It works for me ! I have an iMac9,1 (Core2 Duo 2.93 GHz and nVidia GT9200) This is the first time it boots on FreeBSD 8.x (8.1-STABLE) Thank you ! From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 14:48:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51405106566C for ; Sat, 20 Nov 2010 14:48:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E37D18FC14 for ; Sat, 20 Nov 2010 14:48:12 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1BF7DE7218 for ; Sat, 20 Nov 2010 14:48:12 +0000 (GMT) Received: from unknown (client-86-27-40-229.glfd.adsl.virginmedia.com [86.27.40.229]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sat, 20 Nov 2010 14:48:11 +0000 (GMT) Date: Sat, 20 Nov 2010 14:48:15 +0000 From: Bruce Cran To: freebsd-current@freebsd.org Message-ID: <20101120144815.00003716@unknown> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: zfs/vm panic: vm_object_page_collect_flush failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 14:48:13 -0000 Hi, I've been building KDE on a new -CURRENT system with ZFS and hit a panic - "vm_object_page_collect_flush failed" (more info is at http://www.cran.org.uk/~brucec/freebsd/zfs_vm_panic.txt). #9 0xffffffff802a6190 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/head/sys/kern/kern_shutdown.c:574 #10 0xffffffff8043744e in vm_object_page_clean (object=Variable "object" is not available. ) at /usr/src/head/sys/vm/vm_object.c:823 #11 0xffffffff804376f6 in vm_object_terminate (object=0xffffff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:691 #12 0xffffffff804446d8 in vnode_destroy_vobject (vp=0xffffff00bd2acb40) at /usr/src/head/sys/vm/vnode_pager.c:167 #13 0xffffffff80a56252 in zfs_freebsd_reclaim (ap=Variable "ap" is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4836 #14 0xffffffff803396e5 in vgonel (vp=0xffffff00bd2acb40) at vnode_if.h:830 #15 0xffffffff80339a4c in vrecycle (vp=0xffffff00bd2acb40, td=Variable "td" is not available. ) at /usr/src/head/sys/kern/vfs_subr.c:2517 #16 0xffffffff80a3149a in zfs_zinactive (zp=0xffffff0096d06dc0) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1066 #17 0xffffffff80a55c96 in zfs_inactive (vp=0xffffff00bd2acb40, cr=Variable "cr" is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4059 #18 0xffffffff80a55e3a in zfs_freebsd_inactive (ap=Variable "ap" is not available. ) at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4792 #19 0xffffffff80338e92 in vinactive (vp=0xffffff00bd2acb40, td=0xffffff019871b450) at vnode_if.h:807 #20 0xffffffff8033c961 in vputx (vp=0xffffff00bd2acb40, func=1) at /usr/src/head/sys/kern/vfs_subr.c:2238 #21 0xffffffff80438dd7 in vm_object_deallocate (object=0xffffff011a96d5e8) at /usr/src/head/sys/vm/vm_object.c:447 #22 0xffffffff8042f68c in vm_map_entry_deallocate (entry=0xffffff00bd6054b0, system_map=0) at /usr/src/head/sys/vm/vm_map.c:2622 #23 0xffffffff8042f6c2 in vm_map_process_deferred () at /usr/src/head/sys/vm/vm_map.c:466 #24 0xffffffff80430d2f in vm_map_remove (map=0xffffff0093adac40, start=Variable "start" is not available. ) at /usr/src/head/sys/vm/vm_map.c:2793 #25 0xffffffff80434057 in vmspace_exit (td=0xffffff019871b450) at /usr/src/head/sys/vm/vm_map.c:333 #26 0xffffffff8027bea6 in exit1 (td=0xffffff019871b450, rv=0) at /usr/src/head/sys/kern/kern_exit.c:299 #27 0xffffffff8027c9ee in sys_exit (td=Variable "td" is not available. ) at /usr/src/head/sys/kern/kern_exit.c:109 #28 0xffffffff802e699a in syscallenter (td=0xffffff019871b450, sa=0xffffff81b832eba0) at /usr/src/head/sys/kern/subr_trap.c:318 #29 0xffffffff8046323c in syscall (frame=0xffffff81b832ec40) at /usr/src/head/sys/amd64/amd64/trap.c:938 #30 0xffffffff8044dd42 in Xfast_syscall () at /usr/src/head/sys/amd64/amd64/exception.S:381 #31 0x00000008006e567c in ?? () -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 14:52:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755A7106566B for ; Sat, 20 Nov 2010 14:52: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 0DD9C8FC4B for ; Sat, 20 Nov 2010 14:52:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAKEqGeA062360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Nov 2010 16:52:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAKEqGpI053189; Sat, 20 Nov 2010 16:52:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAKEqGQ6053188; Sat, 20 Nov 2010 16:52:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Nov 2010 16:52:16 +0200 From: Kostik Belousov To: Bruce Cran Message-ID: <20101120145216.GC2392@deviant.kiev.zoral.com.ua> References: <20101120144815.00003716@unknown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="364zuQ/klI8rPZ4E" Content-Disposition: inline In-Reply-To: <20101120144815.00003716@unknown> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: zfs/vm panic: vm_object_page_collect_flush failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 14:52:23 -0000 --364zuQ/klI8rPZ4E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 20, 2010 at 02:48:15PM +0000, Bruce Cran wrote: > Hi, >=20 > I've been building KDE on a new -CURRENT system with ZFS and hit a=20 > panic - "vm_object_page_collect_flush failed" (more info is at=20 > http://www.cran.org.uk/~brucec/freebsd/zfs_vm_panic.txt). >=20 > #9 0xffffffff802a6190 in panic (fmt=3DVariable "fmt" is not available. > ) > at /usr/src/head/sys/kern/kern_shutdown.c:574 > #10 0xffffffff8043744e in vm_object_page_clean (object=3DVariable "object= " is not available. > ) > at /usr/src/head/sys/vm/vm_object.c:823 > #11 0xffffffff804376f6 in vm_object_terminate (object=3D0xffffff011a96d5e= 8) > at /usr/src/head/sys/vm/vm_object.c:691 > #12 0xffffffff804446d8 in vnode_destroy_vobject (vp=3D0xffffff00bd2acb40) > at /usr/src/head/sys/vm/vnode_pager.c:167 > #13 0xffffffff80a56252 in zfs_freebsd_reclaim (ap=3DVariable "ap" is not = available. > ) > at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c= ommon/fs/zfs/zfs_vnops.c:4836 > #14 0xffffffff803396e5 in vgonel (vp=3D0xffffff00bd2acb40) at vnode_if.h:= 830 > #15 0xffffffff80339a4c in vrecycle (vp=3D0xffffff00bd2acb40, td=3DVariabl= e "td" is not available. > ) > at /usr/src/head/sys/kern/vfs_subr.c:2517 > #16 0xffffffff80a3149a in zfs_zinactive (zp=3D0xffffff0096d06dc0) > at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c= ommon/fs/zfs/zfs_znode.c:1066 > #17 0xffffffff80a55c96 in zfs_inactive (vp=3D0xffffff00bd2acb40, cr=3DVar= iable "cr" is not available. > ) > at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c= ommon/fs/zfs/zfs_vnops.c:4059 > #18 0xffffffff80a55e3a in zfs_freebsd_inactive (ap=3DVariable "ap" is not= available. > ) > at /usr/src/head/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c= ommon/fs/zfs/zfs_vnops.c:4792 > #19 0xffffffff80338e92 in vinactive (vp=3D0xffffff00bd2acb40, > td=3D0xffffff019871b450) at vnode_if.h:807 > #20 0xffffffff8033c961 in vputx (vp=3D0xffffff00bd2acb40, func=3D1) > at /usr/src/head/sys/kern/vfs_subr.c:2238 > #21 0xffffffff80438dd7 in vm_object_deallocate (object=3D0xffffff011a96d5= e8) > at /usr/src/head/sys/vm/vm_object.c:447 > #22 0xffffffff8042f68c in vm_map_entry_deallocate (entry=3D0xffffff00bd60= 54b0, > system_map=3D0) at /usr/src/head/sys/vm/vm_map.c:2622 > #23 0xffffffff8042f6c2 in vm_map_process_deferred () > at /usr/src/head/sys/vm/vm_map.c:466 > #24 0xffffffff80430d2f in vm_map_remove (map=3D0xffffff0093adac40, start= =3DVariable "start" is not available. > ) > at /usr/src/head/sys/vm/vm_map.c:2793 > #25 0xffffffff80434057 in vmspace_exit (td=3D0xffffff019871b450) > at /usr/src/head/sys/vm/vm_map.c:333 > #26 0xffffffff8027bea6 in exit1 (td=3D0xffffff019871b450, rv=3D0) > at /usr/src/head/sys/kern/kern_exit.c:299 > #27 0xffffffff8027c9ee in sys_exit (td=3DVariable "td" is not available. > ) > at /usr/src/head/sys/kern/kern_exit.c:109 > #28 0xffffffff802e699a in syscallenter (td=3D0xffffff019871b450, > sa=3D0xffffff81b832eba0) at /usr/src/head/sys/kern/subr_trap.c:318 > #29 0xffffffff8046323c in syscall (frame=3D0xffffff81b832ec40) > at /usr/src/head/sys/amd64/amd64/trap.c:938 > #30 0xffffffff8044dd42 in Xfast_syscall () > at /usr/src/head/sys/amd64/amd64/exception.S:381 > #31 0x00000008006e567c in ?? () Remove the KASSERT() at vm/vm_object.c:823. It is invalid, I will commit the fix later today. --364zuQ/klI8rPZ4E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzn4KAACgkQC3+MBN1Mb4jGpQCfQkbFwbxBiLpvKgm6de50R981 WDIAnj2t7jymAY91twUJujYwKNXVONNK =ox2J -----END PGP SIGNATURE----- --364zuQ/klI8rPZ4E-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 18:14:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D7AD106564A for ; Sat, 20 Nov 2010 18:14:13 +0000 (UTC) (envelope-from super_bisquit@yahoo.com) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by mx1.freebsd.org (Postfix) with SMTP id 58B3B8FC0C for ; Sat, 20 Nov 2010 18:14:13 +0000 (UTC) Received: from [98.139.91.67] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2010 18:00:29 -0000 Received: from [98.139.91.9] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2010 18:00:29 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 20 Nov 2010 18:00:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 154056.17591.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 60527 invoked by uid 60001); 20 Nov 2010 18:00:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1290276028; bh=f2OjjPccyFkQ4CLvls05Vk0/Bd679kC9y6vmxDwkeNw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=pFy83ZJFKyn4VNZCMhgGcVIGkXO7+QAN/OC7aNCxCDi+MXelE1NyHTWOEdQYijYPqf5Ajt4e3Xi4PhTGw3rLgTCWuY0G6yWevjjxDmFQd1FmvZHOonuoDD59+f2ho+ldGJ1Gs/F8SohnHYsRnGXOwwJzgPv3GrrUk4whEgJBrz8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ubSsNONPDC9RkQvwBTwiSONmZJVrApRusZu2Cu5VqjaCO7rc8+c17Gnssa01iYHJrbFkHVSl1r+Dvvrs9NfhAib7Rw3gIyos2zgsI0GnCWwcjkkfJLHA4ot4GEvouqwc/kb8KLF61EzByjlYEQei04gRNFVattUSYkXORG11YCs=; Message-ID: <681433.59433.qm@web110101.mail.gq1.yahoo.com> X-YMail-OSG: rCHwJfsVM1kfW3pdGubfi27mHLVm0D1zHdu_bkPUSnlOJLX nqGpzmc0DJogjvSxWVmvuCI0FkADn325cQcx9K5r5E9GnTD2LmWXMmZCQtjA 9PDSEgKFrw0InAoUbxXpnnMrAZiSXgWRMhkm8FTa9t4R8dyq0bwFp43AKhmV ALbeJyyXsBI0frLSzM2_pOch5We3Zbf2DYtrbPxffu6hiTaM33QJdc.hkCHP wLWWZMLZs5Yli4a.r0CN6H6la.r9UuNUSilhIrDJ.0.NDc3v4eyLyv80sIok MHB8EGv5cS3F9tUB6F5PofuUQyQ-- Received: from [98.192.248.233] by web110101.mail.gq1.yahoo.com via HTTP; Sat, 20 Nov 2010 10:00:28 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Sat, 20 Nov 2010 10:00:28 -0800 (PST) From: Super Biscuit To: current@freebsd.org, freebsd-x11@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: drm.ko does not build on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 18:14:13 -0000 I'm using SNAPSHOT-9 (Current) powerpc from people.freebsd.org/~whitehorn. The build in /usr/src/sys/.../drm/drm stops with specialreg.h Using find -f /|grep specialreg.h only shows the file in x86, amd64, and pc98. I already have agp.ko built. Does this require cross compiling or is a "prebuilt" drm.ko for ppc32 available? If it does require cross compiling or even importing- I have a few i386 machines- How would I enable or use it on ppc? Thanks/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 19:31:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7505106564A for ; Sat, 20 Nov 2010 19:31:46 +0000 (UTC) (envelope-from artur@bednarek.org.pl) Received: from bednarek.org.pl (bednarek.org.pl [89.206.35.81]) by mx1.freebsd.org (Postfix) with ESMTP id 51FB88FC12 for ; Sat, 20 Nov 2010 19:31:45 +0000 (UTC) Received: from [89.206.9.179] (host179-89-206-9.limes.com.pl [89.206.9.179]) by bednarek.org.pl (8.14.4/8.14.4) with ESMTP id oAKJEg8g000418 for ; Sat, 20 Nov 2010 20:14:42 +0100 (CET) (envelope-from artur@bednarek.org.pl) Message-ID: <4CE81012.40000@bednarek.org.pl> Date: Sat, 20 Nov 2010 19:14:42 +0100 From: Artur Bednarek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20101119212350.655EB106578C@hub.freebsd.org> In-Reply-To: <20101119212350.655EB106578C@hub.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: freebsd-current Digest, Vol 370, Issue 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: Sat, 20 Nov 2010 19:31:46 -0000 W dniu 2010-11-19 22:23, freebsd-current-request@freebsd.org pisze: > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org > > You can reach the person managing the list at > freebsd-current-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > > Today's Topics: > > 1. Re: old references to vfs_mountroot_try() (Alexander Best) > 2. Re: Testing /dev/fido ? (Ivan Voras) > 3. Re: TTY task group scheduling (Andriy Gapon) > 4. Re: TTY task group scheduling (Eric Masson) > 5. Re: TTY task group scheduling (Vincent Hoffman) > 6. Re: aperf/mperf (Andriy Gapon) > 7. Re: aperf/mperf (Daniel Nebdal) > 8. Re: TTY task group scheduling (Jeremy Chadwick) > 9. Re: www/chromium crashing whole system (Alexander Best) > 10. new cpuid bits (Andriy Gapon) > 11. A big-ish machine, cannot boot (Ivan Voras) > 12. Re: aperf/mperf (Andriy Gapon) > 13. Re: TTY task group scheduling (Taku YAMAMOTO) > 14. Re: A big-ish machine, cannot boot (Andriy Gapon) > 15. Re: A big-ish machine, cannot boot (Gary Jennejohn) > 16. Re: taskqueue_create() name parameter lieftime (Andriy Gapon) > 17. Re: new cpuid bits (Gary Jennejohn) > 18. Re: A big-ish machine, cannot boot (Ivan Voras) > 19. Re: A big-ish machine, cannot boot (Ivan Voras) > 20. Re: A big-ish machine, cannot boot (Andriy Gapon) > 21. Re: A big-ish machine, cannot boot (Garrett Cooper) > 22. Re: A big-ish machine, cannot boot (Ivan Voras) > 23. Re: A big-ish machine, cannot boot (Ivan Voras) > 24. Re: old references to vfs_mountroot_try() (Marcel Moolenaar) > 25. Re: [RFC] ifconfig description support in rc.d (Garrett Cooper) > 26. Re: A big-ish machine, cannot boot (James R. Van Artsdalen) > 27. Re: taskqueue_create() name parameter lieftime (John Baldwin) > 28. Re: A big-ish machine, cannot boot (Andriy Gapon) > 29. Re: A big-ish machine, cannot boot (Jung-uk Kim) > 30. Re: A big-ish machine, cannot boot (Sean Bruno) > 31. Re: [Call for Tests] PAT issue on Apple hardware (Jung-uk Kim) > 32. Re: aperf/mperf (Nate Lawson) > 33. Re: A big-ish machine, cannot boot (Antony Mawer) > 34. Re: A big-ish machine, cannot boot (Chuck Swiger) > 35. Re: www/chromium crashing whole system (Oliver Pinter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Nov 2010 12:40:55 +0000 > From: Alexander Best > Subject: Re: old references to vfs_mountroot_try() > To: Sergey Kandaurov > Cc: freebsd-current@freebsd.org > Message-ID:<20101119124055.GA11368@freebsd.org> > Content-Type: text/plain; charset=us-ascii > > On Fri Nov 19 10, Sergey Kandaurov wrote: >> On 19 November 2010 02:14, Alexander Best wrote: >>> hi there, >>> >>> vfs_mountroot_try() seems to have been removed, yet the src still contains >>> three references to it: >>> >>> vfs_mount.c:386 >>> vfs_mount.c:723 >>> freebsd32_misc.c:2368 >>> >> So, what about just to rename those comments to reflect function name change? > that looks fine. i don't know anything about vfs, so i simply figured out that > the reference to vfs_mountroot_try() was not right anymore, but couldn't find > where MNT_ROOTFS is now being set. > > ...so its parse_mount(). :) > > could you commit that? > > cheers. > alex > >> Index: sys/kern/vfs_mount.c >> =================================================================== >> --- sys/kern/vfs_mount.c (revision 215516) >> +++ sys/kern/vfs_mount.c (working copy) >> @@ -383,7 +383,7 @@ >> * Filter out MNT_ROOTFS. We do not want clients of nmount() in >> * userspace to set this flag, but we must filter it out if we want >> * MNT_UPDATE on the root file system to work. >> - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). >> + * MNT_ROOTFS should only be set in the kernel in parse_mount(). >> */ >> uap->flags&= ~MNT_ROOTFS; >> >> @@ -720,7 +720,7 @@ >> * Filter out MNT_ROOTFS. We do not want clients of mount() in >> * userspace to set this flag, but we must filter it out if we want >> * MNT_UPDATE on the root file system to work. >> - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). >> + * MNT_ROOTFS should only be set in the kernel in parse_mount(). >> */ >> uap->flags&= ~MNT_ROOTFS; >> >> Index: sys/compat/freebsd32/freebsd32_misc.c >> =================================================================== >> --- sys/compat/freebsd32/freebsd32_misc.c (revision 215516) >> +++ sys/compat/freebsd32/freebsd32_misc.c (working copy) >> @@ -2365,7 +2365,7 @@ >> * Filter out MNT_ROOTFS. We do not want clients of nmount() in >> * userspace to set this flag, but we must filter it out if we want >> * MNT_UPDATE on the root file system to work. >> - * MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). >> + * MNT_ROOTFS should only be set in the kernel in parse_mount(). >> */ >> uap->flags&= ~MNT_ROOTFS; >> >> -- >> wbr, >> pluknet mam impreze w warszawie do poniedziaƂku :) From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 20:02:10 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4274F106566B; Sat, 20 Nov 2010 20:02:10 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id B752F8FC0A; Sat, 20 Nov 2010 20:02:09 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id oAKJfaEW024490; Sat, 20 Nov 2010 20:41:37 +0100 (CET) (envelope-from andreast@FreeBSD.org) Message-ID: <4CE82470.4090606@FreeBSD.org> Date: Sat, 20 Nov 2010 20:41:36 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Super Biscuit References: <681433.59433.qm@web110101.mail.gq1.yahoo.com> In-Reply-To: <681433.59433.qm@web110101.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-x11@FreeBSD.org, current@FreeBSD.org Subject: Re: drm.ko does not build on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Nov 2010 20:02:10 -0000 On 20.11.10 19:00, Super Biscuit wrote: > I'm using SNAPSHOT-9 (Current) powerpc from people.freebsd.org/~whitehorn. Can you update the src to something after 16.11? Nathan did commit a (build) fix around the 16.11. Gruss, Andreas