From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 00:06:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC6FF16A49E; Sun, 22 Oct 2006 00:06:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6035443D46; Sun, 22 Oct 2006 00:06:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9M06vUd037898; Sat, 21 Oct 2006 20:06:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id k9M06ute086368; Sat, 21 Oct 2006 20:06:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C384373068; Sat, 21 Oct 2006 20:06:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061022000656.C384373068@freebsd-current.sentex.ca> Date: Sat, 21 Oct 2006 20:06:56 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 00:06:59 -0000 TB --- 2006-10-21 23:39:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-21 23:39:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-10-21 23:39:43 - cleaning the object tree TB --- 2006-10-21 23:40:20 - checking out the source tree TB --- 2006-10-21 23:40:20 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-10-21 23:40:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-21 23:47:48 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-21 23:47:48 - cd /src TB --- 2006-10-21 23:47:48 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 21 23:47:50 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/vwscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wbuf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wprintf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wsetup.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c /src/lib/libc/stdio/xprintf.c: In function `__v2printf': /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** 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 --- 2006-10-22 00:06:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-22 00:06:56 - ERROR: failed to build world TB --- 2006-10-22 00:06:56 - tinderbox aborted TB --- 0.74 user 2.30 system 1633.16 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 02:21:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D97716A412; Sun, 22 Oct 2006 02:21:43 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E8B443D5D; Sun, 22 Oct 2006 02:21:42 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [192.168.0.14] (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CFT67621 (AUTH peterg@ptree32.com.au); Sun, 22 Oct 2006 12:21:38 +1000 (EST) Message-ID: <453AD5C2.6030507@freebsd.org> Date: Sat, 21 Oct 2006 19:21:54 -0700 From: Peter Grehan User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: FreeBSD Tinderbox References: <20061022000656.C384373068@freebsd-current.sentex.ca> In-Reply-To: <20061022000656.C384373068@freebsd-current.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: powerpc@freebsd.org, kib@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 02:21:43 -0000 > cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c > /src/lib/libc/stdio/xprintf.c: In function `__v2printf': > /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type > *** Error code 1 I did a quick change of va_copy(ap, ap1); to va_copy(ap, (va_list) ap1); .. and ended up with: /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c: In function `__v2printf': /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c:279: error: cast specifies array type A va_list on powerpc is a struct, but va_copy should do the right thing. Any C language geeks out there with advice ? later, Peter. From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 05:12:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17BD116A403; Sun, 22 Oct 2006 05:12:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C5743D45; Sun, 22 Oct 2006 05:12:30 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k9M4uRZF060211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 07:56:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k9M5COaI073404; Sun, 22 Oct 2006 08:12:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k9M5COsF073302; Sun, 22 Oct 2006 08:12:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Oct 2006 08:12:24 +0300 From: Kostik Belousov To: Peter Grehan Message-ID: <20061022051224.GA45605@deviant.kiev.zoral.com.ua> References: <20061022000656.C384373068@freebsd-current.sentex.ca> <453AD5C2.6030507@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <453AD5C2.6030507@freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: powerpc@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc/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: Sun, 22 Oct 2006 05:12:36 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 21, 2006 at 07:21:54PM -0700, Peter Grehan wrote: > >cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include=20 > >-I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE=20 > >-I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc= =20 > >-I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_D= ES=20 > >-DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING=20 > >-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c=20 > >/src/lib/libc/stdio/xprintf.c > >/src/lib/libc/stdio/xprintf.c: In function `__v2printf': > >/src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of=20 > >`__builtin_va_copy' discards qualifiers from pointer target type > >*** Error code 1 >=20 > I did a quick change of >=20 > va_copy(ap, ap1); >=20 > to >=20 > va_copy(ap, (va_list) ap1); >=20 > .. and ended up with: >=20 > /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c: In=20 > function `__v2printf': > /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c:279:=20 > error: cast specifies array type >=20 > A va_list on powerpc is a struct, but va_copy should do the right thing. >=20 > Any C language geeks out there with advice ? >=20 > later, >=20 > Peter. I think that change below shall fix it. Sorry for breakage. Index: lib/libc/stdio/xprintf.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 RCS file: /usr/local/arch/ncvs/src/lib/libc/stdio/xprintf.c,v retrieving revision 1.4 diff -u -r1.4 xprintf.c --- lib/libc/stdio/xprintf.c 21 Oct 2006 11:49:07 -0000 1.4 +++ lib/libc/stdio/xprintf.c 22 Oct 2006 05:10:49 -0000 @@ -261,7 +261,7 @@ =20 =20 static int -__v2printf(FILE *fp, const char *fmt0, unsigned pct, const va_list ap1) +__v2printf(FILE *fp, const char *fmt0, unsigned pct, va_list ap) { struct printf_info *pi, *pil; const char *fmt; @@ -274,9 +274,7 @@ int ret =3D 0; int n; struct __printf_io io; - va_list ap; =20 - va_copy(ap, ap1); __printf_init(&io); io.fp =3D fp; =20 @@ -563,7 +561,6 @@ errx(1, "render[%c] =3D NULL", *fmt); } __printf_flush(&io); - va_end(ap); return (ret); } =20 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOv23C3+MBN1Mb4gRAvlwAJ466AN3zjmi9EMYEVqHlh6r9GnfQgCfU+N6 mWXd6iO9zjkkqPjEUvYi7pY= =sbwn -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 05:49:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B762316A417; Sun, 22 Oct 2006 05:49:00 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BED843D5D; Sun, 22 Oct 2006 05:48:58 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.0.5) with ESMTP id md50000580658.msg; Sun, 22 Oct 2006 09:48:27 +0400 Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 09:48:21 +0400 Date: Sun, 22 Oct 2006 09:49:49 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: Nicolas Blais In-Reply-To: <200610211540.02844.nb_root@videotron.ca> Message-ID: <20061022092137.E676@free.home.local> References: <200610211403.43055.nb_root@videotron.ca> <20061021231535.M702@free.home.local> <200610211540.02844.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Oct 2006 05:48:22.0714 (UTC) FILETIME=[AF58C9A0:01C6F59D] X-Spam-Processed: mx.gfk.ru, Sun, 22 Oct 2006 09:48:27 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDAV-Processed: mx.gfk.ru, Sun, 22 Oct 2006 09:48:28 +0400 Cc: John-Mark Gurney , Yuriy Tsibizov , freebsd-current@freebsd.org Subject: Re: Asus A8V hangs during pci probe on fresh-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 05:49:00 -0000 > skc0: port 0xb000-0xb0ff mem 0xf9c00000-0xf9c03fff > irq 17 at device 10.0 on pci0 FreeBSD sk driver reads only first two records before last pci/sk VPD changes. Now it reads it all, and it is possible that VPD data in your card is broken. If you boot verbose with old -CURRENT, can you see 'bad VPD resource id' messages? Linux sk98lin driver had some workarounds for 'buggy ASUS VPD on K8V Deluxe' (http://www.ussg.iu.edu/hypermail/linux/kernel/0404.3/0090.html). I'm not shure, is it applicable to your MB. Yuriy. From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 06:33:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE03C16A407; Sun, 22 Oct 2006 06:33:43 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA60443D49; Sun, 22 Oct 2006 06:33:40 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [192.168.0.14] (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CFT88679 (AUTH peterg@ptree32.com.au); Sun, 22 Oct 2006 16:33:34 +1000 (EST) Message-ID: <453B10D2.8010507@freebsd.org> Date: Sat, 21 Oct 2006 23:33:54 -0700 From: Peter Grehan User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Kostik Belousov References: <20061022000656.C384373068@freebsd-current.sentex.ca> <453AD5C2.6030507@freebsd.org> <20061022051224.GA45605@deviant.kiev.zoral.com.ua> In-Reply-To: <20061022051224.GA45605@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: powerpc@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 06:33:43 -0000 > I think that change below shall fix it. Thanks, that did the trick :) later, Peter. From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 06:42:34 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F265916A40F for ; Sun, 22 Oct 2006 06:42:34 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F65043D45 for ; Sun, 22 Oct 2006 06:42:34 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 7F5E5752E7 for ; Sun, 22 Oct 2006 08:42:33 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 64DD79E6C2 for ; Sun, 22 Oct 2006 06:43:22 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 2B44C405B; Sun, 22 Oct 2006 08:43:22 +0200 (CEST) Date: Sun, 22 Oct 2006 08:43:22 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20061022064322.GU53114@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Cannot unload if_iwi module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 06:42:35 -0000 Hi, when I try to unload if_iwi module, here is what happens: % jarjarbinks:/<3>dev/iwi:118# kldunload if_iwi % iwi0: detached % jarjarbinks:/<3>dev/iwi:119# iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 % iwi0: Ethernet address: 00:12:f0:2c:f3:6e % iwi0: [GIANT-LOCKED] The kld is reloaded automatically (I am sure it is reloaded because the id showed in kldstat(8) changes each time): % jarjarbinks:/<1>share/mk:137# kldstat % Id Refs Address Size Name % 1 20 0xc0400000 4ef910 kernel % 2 1 0xc08f0000 e5dc if_bge.ko % 3 1 0xc08ff000 4ce4 ums.ko % 4 1 0xc0904000 b180 umass.ko % 5 2 0xc382e000 25000 linux.ko % 6 1 0xc38cb000 2000 rtc.ko % 9 1 0xc3acf000 e000 if_iwi.ko % 10 2 0xc3add000 3000 firmware.ko % jarjarbinks:/<3>dev/iwi:122# kldstat % Id Refs Address Size Name % 1 19 0xc0400000 4ef910 kernel % 2 1 0xc08f0000 e5dc if_bge.ko % 3 1 0xc08ff000 4ce4 ums.ko % 4 1 0xc0904000 b180 umass.ko % 5 2 0xc382e000 25000 linux.ko % 6 1 0xc38cb000 2000 rtc.ko % 11 1 0xc3acf000 e000 if_iwi.ko % 12 1 0xc3add000 3000 firmware.ko Any clue how to disable this unwanted behaviour ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 09:58:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC5D16A403; Sun, 22 Oct 2006 09:58:15 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD68343D46; Sun, 22 Oct 2006 09:58:14 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 4C688386C0B; Sun, 22 Oct 2006 09:58:13 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 0E29B11434; Sun, 22 Oct 2006 11:58:12 +0200 (CEST) Date: Sun, 22 Oct 2006 11:58:12 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20061022095811.GA10743@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Hajimu UMEMOTO Subject: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 09:58:15 -0000 Hey, I think something odd is going on in the resolver. It seems like it doesn't resolve hostnames some of the time. It's not really easily reproducible, but I have seen it happen several times with cvsup where it can't resolve the cvsup server. If I re-run cvsup it works fine. I see it on recent -CURRNET's (server running cvsup below is October 12, system running host(1) is October 15). The cvsup log: CVSup update begins at 2006-10-18 17:29:00 Updating from cvsup3.dk.freebsd.org Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup failed Updating local ncvs CVSup update ends at 2006-10-18 17:29:01 I also seen odd things happen with host(1). These two commands were run right after each other. I don't know if it's related, but I suspect it is. $ host cvsup3.dk.freebsd.org cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. $ host cvsup3.dk.freebsd.org cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. mirror03.inet.tele.dk has address 195.41.53.219 cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. I only have one name-server in resolv.conf, so the problem isn't due to hitting different caching name-servers. Initially I thought it was a local problem for me, but joel@ has seen the same on RELENG_6 (from July 8), and xride@ has seen the same/similar with csup where his workaround was to ping the cvsup server before running csup. So, has anyone seen anything similar? Since I can't reproduce the issue at will I don't really know where to look for what's going on, and of course it could be DNS issue... -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:03:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3DD16A407; Sun, 22 Oct 2006 10:03:29 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C9A843D4C; Sun, 22 Oct 2006 10:03:28 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 5FED499FBCD; Sun, 22 Oct 2006 12:03:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r8Gb5ruK2+79; Sun, 22 Oct 2006 12:03:25 +0200 (CEST) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 65FBC99FB91; Sun, 22 Oct 2006 12:03:25 +0200 (CEST) Message-ID: <453B41EC.5060202@FreeBSD.org> Date: Sun, 22 Oct 2006 12:03:24 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Simon L. Nielsen" References: <20061022095811.GA10743@zaphod.nitro.dk> In-Reply-To: <20061022095811.GA10743@zaphod.nitro.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:03:29 -0000 Simon L. Nielsen wrote: > Hey, > > I think something odd is going on in the resolver. It seems like it > doesn't resolve hostnames some of the time. It's not really easily > reproducible, but I have seen it happen several times with cvsup where > it can't resolve the cvsup server. If I re-run cvsup it works fine. > > I see it on recent -CURRNET's (server running cvsup below is October > 12, system running host(1) is October 15). > > The cvsup log: > > CVSup update begins at 2006-10-18 17:29:00 > Updating from cvsup3.dk.freebsd.org > Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup failed > Updating local ncvs > CVSup update ends at 2006-10-18 17:29:01 > > I also seen odd things happen with host(1). These two commands were > run right after each other. I don't know if it's related, but I > suspect it is. > > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > mirror03.inet.tele.dk has address 195.41.53.219 > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > I only have one name-server in resolv.conf, so the problem isn't due > to hitting different caching name-servers. > > Initially I thought it was a local problem for me, but joel@ has seen > the same on RELENG_6 (from July 8), and xride@ has seen the > same/similar with csup where his workaround was to ping the cvsup > server before running csup. > > So, has anyone seen anything similar? Since I can't reproduce the > issue at will I don't really know where to look for what's going on, > and of course it could be DNS issue... > > Same here with csup vs. cvsup.hu.FreeBSD.org. If I resolve it elsewhere and specify the ip address manually, it works just fine. Tomorrow's -current here on i386. -- Cheers, Gabor From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:06:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B153516A40F for ; Sun, 22 Oct 2006 10:06:24 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id F235443D6A for ; Sun, 22 Oct 2006 10:06:14 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 8768E37F63; Sun, 22 Oct 2006 12:06:11 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 67E8837E4E; Sun, 22 Oct 2006 12:06:11 +0200 (CEST) Received: from dude.automatvapen.se (81-229-112-193-no21.tbcn.telia.com [81.229.112.193]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 4B76337E6F; Sun, 22 Oct 2006 12:06:11 +0200 (CEST) From: Joel Dahl To: "Simon L. Nielsen" In-Reply-To: <20061022095811.GA10743@zaphod.nitro.dk> References: <20061022095811.GA10743@zaphod.nitro.dk> Content-Type: text/plain Date: Sun, 22 Oct 2006 12:06:10 +0200 Message-Id: <1161511570.751.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:06:24 -0000 On Sun, 2006-10-22 at 11:58 +0200, Simon L. Nielsen wrote: > Hey, > > I think something odd is going on in the resolver. It seems like it > doesn't resolve hostnames some of the time. It's not really easily > reproducible, but I have seen it happen several times with cvsup where > it can't resolve the cvsup server. If I re-run cvsup it works fine. > > I see it on recent -CURRNET's (server running cvsup below is October > 12, system running host(1) is October 15). > > The cvsup log: > > CVSup update begins at 2006-10-18 17:29:00 > Updating from cvsup3.dk.freebsd.org > Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup failed > Updating local ncvs > CVSup update ends at 2006-10-18 17:29:01 > > I also seen odd things happen with host(1). These two commands were > run right after each other. I don't know if it's related, but I > suspect it is. > > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > mirror03.inet.tele.dk has address 195.41.53.219 > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > I only have one name-server in resolv.conf, so the problem isn't due > to hitting different caching name-servers. > > Initially I thought it was a local problem for me, but joel@ has seen > the same on RELENG_6 (from July 8), and xride@ has seen the > same/similar with csup where his workaround was to ping the cvsup > server before running csup. I could reproduce this quite easily on current a couple of days ago, running cvsup resulted in "Name lookup failure for cvsup.no.freebsd.org": Host name lookup failed" about (approximately) every other time I ran it. -- Joel From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:22:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C87A16A415; Sun, 22 Oct 2006 10:22:38 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 975B943D4C; Sun, 22 Oct 2006 10:22:37 +0000 (GMT) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id 1A1CA17119; Sun, 22 Oct 2006 13:22:36 +0300 (EEST) Date: Sun, 22 Oct 2006 13:22:25 +0300 From: Ion-Mihai "IOnut" Tetcu To: "Simon L. Nielsen" Message-ID: <20061022132225.13299ae6@it.buh.tecnik93.com> In-Reply-To: <20061022095811.GA10743@zaphod.nitro.dk> References: <20061022095811.GA10743@zaphod.nitro.dk> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_DGAUHnd6uGgaNf/qCZ_DCqZ"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:22:38 -0000 --Sig_DGAUHnd6uGgaNf/qCZ_DCqZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Oct 2006 11:58:12 +0200 "Simon L. Nielsen" wrote: > Hey, >=20 > I think something odd is going on in the resolver. It seems like it > doesn't resolve hostnames some of the time. It's not really easily > reproducible, but I have seen it happen several times with cvsup where > it can't resolve the cvsup server. If I re-run cvsup it works fine. >=20 > I see it on recent -CURRNET's (server running cvsup below is October > 12, system running host(1) is October 15). >=20 > The cvsup log: >=20 > CVSup update begins at 2006-10-18 17:29:00 > Updating from cvsup3.dk.freebsd.org > Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup > failed Updating local ncvs > CVSup update ends at 2006-10-18 17:29:01 >=20 > I also seen odd things happen with host(1). These two commands were > run right after each other. I don't know if it's related, but I > suspect it is. >=20 > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > mirror03.inet.tele.dk has address 195.41.53.219 > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. >=20 > I only have one name-server in resolv.conf, so the problem isn't due > to hitting different caching name-servers. >=20 > Initially I thought it was a local problem for me, but joel@ has seen > the same on RELENG_6 (from July 8), and xride@ has seen the > same/similar with csup where his workaround was to ping the cvsup > server before running csup. >=20 > So, has anyone seen anything similar? Since I can't reproduce the > issue at will I don't really know where to look for what's going on, > and of course it could be DNS issue... Seen the same, I believe it started sometime around 21 Jun in RELEND_6. At the time I believed it was due to switching to pf on that machine, but I saw it on other machines w/o pf, all running 6-STABLE, since. It's like the resolver it is giving up to early, if after the "Name lookup failure ..." message I hit Ctrl+C and run it again immediately it resolves OK. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 --Sig_DGAUHnd6uGgaNf/qCZ_DCqZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFO0ZrBX6fi0k6KXsRAmPQAKCabnbWAZz9dsVkQLJZE/IMC9rF2QCgwnOL N059Rm39qpic92ax40Dajg8= =GfRz -----END PGP SIGNATURE----- --Sig_DGAUHnd6uGgaNf/qCZ_DCqZ-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:25:55 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F99416A40F for ; Sun, 22 Oct 2006 10:25:55 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E62543D46 for ; Sun, 22 Oct 2006 10:25:54 +0000 (GMT) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp6-g19.free.fr (Postfix) with ESMTP id 6CF05423E6; Sun, 22 Oct 2006 12:25:53 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id D606011A13; Sun, 22 Oct 2006 12:25:50 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38417-08; Sun, 22 Oct 2006 12:25:46 +0200 (CEST) Received: from [193.120.13.130] (cream.xbsd.org [193.120.13.130]) by smtp.xbsd.org (Postfix) with ESMTP id 13D2611994; Sun, 22 Oct 2006 12:25:44 +0200 (CEST) From: Florent Thoumie To: Jeremie Le Hen In-Reply-To: <20061022064322.GU53114@obiwan.tataz.chchile.org> References: <20061022064322.GU53114@obiwan.tataz.chchile.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eAQu19W7DTwj0azwYV2o" Date: Sun, 22 Oct 2006 11:25:42 +0100 Message-Id: <1161512742.71755.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: Cannot unload if_iwi module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:25:55 -0000 --=-eAQu19W7DTwj0azwYV2o Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2006-10-22 at 08:43 +0200, Jeremie Le Hen wrote: > Hi, >=20 > when I try to unload if_iwi module, here is what happens: >=20 > % jarjarbinks:/<3>dev/iwi:118# kldunload if_iwi > % iwi0: detached > % jarjarbinks:/<3>dev/iwi:119# iwi0: mem 0= xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > % iwi0: [GIANT-LOCKED] >=20 > The kld is reloaded automatically (I am sure it is reloaded because > the id showed in kldstat(8) changes each time): >=20 > % jarjarbinks:/<1>share/mk:137# kldstat > % Id Refs Address Size Name > % 1 20 0xc0400000 4ef910 kernel > % 2 1 0xc08f0000 e5dc if_bge.ko > % 3 1 0xc08ff000 4ce4 ums.ko > % 4 1 0xc0904000 b180 umass.ko > % 5 2 0xc382e000 25000 linux.ko > % 6 1 0xc38cb000 2000 rtc.ko > % 9 1 0xc3acf000 e000 if_iwi.ko > % 10 2 0xc3add000 3000 firmware.ko >=20 > % jarjarbinks:/<3>dev/iwi:122# kldstat > % Id Refs Address Size Name > % 1 19 0xc0400000 4ef910 kernel > % 2 1 0xc08f0000 e5dc if_bge.ko > % 3 1 0xc08ff000 4ce4 ums.ko > % 4 1 0xc0904000 b180 umass.ko > % 5 2 0xc382e000 25000 linux.ko > % 6 1 0xc38cb000 2000 rtc.ko > % 11 1 0xc3acf000 e000 if_iwi.ko > % 12 1 0xc3add000 3000 firmware.ko >=20 > Any clue how to disable this unwanted behaviour ? No idea, but the same behavior can be seen with ipw(4) and experimental wpi(4). I seem to recall this didn't happen before the the support for firmware(9) was added. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --=-eAQu19W7DTwj0azwYV2o Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFO0cmMxEkbVFH3PQRAkrLAJ4scrLIjKkc523xrhQ6/ULDwyO8VgCfVkag Voxxf7WESUyyVvxSTUFQelE= =g5z4 -----END PGP SIGNATURE----- --=-eAQu19W7DTwj0azwYV2o-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:28:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C30316A40F; Sun, 22 Oct 2006 10:28:24 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74D6743D49; Sun, 22 Oct 2006 10:28:23 +0000 (GMT) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id 7633017124; Sun, 22 Oct 2006 13:28:22 +0300 (EEST) Date: Sun, 22 Oct 2006 13:28:22 +0300 From: Ion-Mihai "IOnut" Tetcu To: Ion-Mihai "IOnut" Tetcu Message-ID: <20061022132822.417e2693@it.buh.tecnik93.com> In-Reply-To: <20061022132225.13299ae6@it.buh.tecnik93.com> References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_CzH=DclyobdXNpM4YEu4nSO"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO , "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:28:24 -0000 --Sig_CzH=DclyobdXNpM4YEu4nSO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Oct 2006 13:22:25 +0300 Ion-Mihai "IOnut" Tetcu wrote: > On Sun, 22 Oct 2006 11:58:12 +0200 > "Simon L. Nielsen" wrote: >=20 > > Hey, > >=20 > > I think something odd is going on in the resolver. It seems like it > > doesn't resolve hostnames some of the time. It's not really easily > > reproducible, but I have seen it happen several times with cvsup > > where it can't resolve the cvsup server. If I re-run cvsup it > > works fine. > >=20 > > I see it on recent -CURRNET's (server running cvsup below is October > > 12, system running host(1) is October 15). > >=20 > > The cvsup log: > >=20 > > CVSup update begins at 2006-10-18 17:29:00 > > Updating from cvsup3.dk.freebsd.org > > Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup > > failed Updating local ncvs > > CVSup update ends at 2006-10-18 17:29:01 > >=20 > > I also seen odd things happen with host(1). These two commands were > > run right after each other. I don't know if it's related, but I > > suspect it is. > >=20 > > $ host cvsup3.dk.freebsd.org > > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > $ host cvsup3.dk.freebsd.org > > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > mirror03.inet.tele.dk has address 195.41.53.219 > > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > >=20 > > I only have one name-server in resolv.conf, so the problem isn't due > > to hitting different caching name-servers. > >=20 > > Initially I thought it was a local problem for me, but joel@ has > > seen the same on RELENG_6 (from July 8), and xride@ has seen the > > same/similar with csup where his workaround was to ping the cvsup > > server before running csup. > >=20 > > So, has anyone seen anything similar? Since I can't reproduce the > > issue at will I don't really know where to look for what's going on, > > and of course it could be DNS issue... >=20 > Seen the same, I believe it started sometime around 21 Jun in > RELEND_6. The machine in question, where I first observed this is: 6.1-STABLE #1: Fri Jun 9 13:26:04 EEST 2006 --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" "Get back to your stations!" "We're beaming down to the planet, -- Kirk and Mr. Leslie, "This Side of Paradise", stardate 3417.3 --Sig_CzH=DclyobdXNpM4YEu4nSO Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFO0fGBX6fi0k6KXsRAv5MAKDGiamUq61G7w8tkpyOhS499gctpQCfWA0q e+dRoB/lclquvCZM1WPMpLg= =TVkz -----END PGP SIGNATURE----- --Sig_CzH=DclyobdXNpM4YEu4nSO-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 10:56:36 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3542016A403; Sun, 22 Oct 2006 10:56:36 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A8743D66; Sun, 22 Oct 2006 10:56:35 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:VNmcFU15ErzhS7UP0D40VYjWM1c9uPa5+8OBk4xmi0ToZn9tgQEWMrxZ1P2nHtpy@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MAuTIa057596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 19:56:29 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 22 Oct 2006 19:56:28 +0900 Message-ID: From: Hajimu UMEMOTO To: "Simon L. Nielsen" In-Reply-To: <20061022095811.GA10743@zaphod.nitro.dk> References: <20061022095811.GA10743@zaphod.nitro.dk> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 22 Oct 2006 19:56:29 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 10:56:36 -0000 Hi, >>>>> On Sun, 22 Oct 2006 11:58:12 +0200 >>>>> "Simon L. Nielsen" said: simon> Initially I thought it was a local problem for me, but joel@ has seen simon> the same on RELENG_6 (from July 8), and xride@ has seen the simon> same/similar with csup where his workaround was to ping the cvsup simon> server before running csup. Is the date correct? Since I did MFC BIND9's resolver into RELENG_6 at July 17, this issue seems not related to resolver update. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:05:27 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00FBB16A407; Sun, 22 Oct 2006 11:05:27 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B3E143D5E; Sun, 22 Oct 2006 11:05:25 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:fcW198EiAUpxLLMqdWfILIUCBLry6DiUTquPhRJz72CO9gQc8KfDbyeQvRHP7EUM@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MB5JV5003907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 20:05:19 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 22 Oct 2006 20:05:19 +0900 Message-ID: From: Hajimu UMEMOTO To: Ion-Mihai "IOnut" Tetcu In-Reply-To: <20061022132225.13299ae6@it.buh.tecnik93.com> References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 22 Oct 2006 20:05:20 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org, Hajimu UMEMOTO , "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:05:27 -0000 Hi, >>>>> On Sun, 22 Oct 2006 13:22:25 +0300 >>>>> Ion-Mihai "IOnut" Tetcu said: itetcu> Seen the same, I believe it started sometime around 21 Jun in RELEND_6. itetcu> At the time I believed it was due to switching to pf on that machine, itetcu> but I saw it on other machines w/o pf, all running 6-STABLE, since. How recent of RELENG_6 are you using? There was a bug at the time when I did MFC BIND9's resolver. However, I believe it was fixed since Aug 7. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:08:57 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF8516A40F; Sun, 22 Oct 2006 11:08:57 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av7-2-sn3.vrr.skanova.net (av7-2-sn3.vrr.skanova.net [81.228.9.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4841143D5C; Sun, 22 Oct 2006 11:08:52 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id A3D3D37ED0; Sun, 22 Oct 2006 13:08:38 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8EC6F37E43; Sun, 22 Oct 2006 13:08:38 +0200 (CEST) Received: from dude.automatvapen.se (81-229-112-193-no21.tbcn.telia.com [81.229.112.193]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A457737E47; Sun, 22 Oct 2006 13:08:50 +0200 (CEST) From: Joel Dahl To: Hajimu UMEMOTO In-Reply-To: References: <20061022095811.GA10743@zaphod.nitro.dk> Content-Type: text/plain Date: Sun, 22 Oct 2006 13:08:50 +0200 Message-Id: <1161515330.751.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:08:57 -0000 On Sun, 2006-10-22 at 19:56 +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sun, 22 Oct 2006 11:58:12 +0200 > >>>>> "Simon L. Nielsen" said: > > simon> Initially I thought it was a local problem for me, but joel@ has seen > simon> the same on RELENG_6 (from July 8), and xride@ has seen the > simon> same/similar with csup where his workaround was to ping the cvsup > simon> server before running csup. > > Is the date correct? Since I did MFC BIND9's resolver into RELENG_6 > at July 17, this issue seems not related to resolver update. Yes, the date is correct. Also, itetcu@ is seeing the same thing with a RELENG_6 from June, so I guess your MFC isn't responsible for this. -- Joel From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:13:45 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3D2716A407; Sun, 22 Oct 2006 11:13:45 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BA5A43D75; Sun, 22 Oct 2006 11:13:44 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 63B07497BB; Sun, 22 Oct 2006 13:13:43 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 2BBDC9E6C2; Sun, 22 Oct 2006 11:14:32 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 17D74405B; Sun, 22 Oct 2006 13:14:32 +0200 (CEST) Date: Sun, 22 Oct 2006 13:14:32 +0200 From: Jeremie Le Hen To: Damien Bergamini Message-ID: <20061022111431.GV53114@obiwan.tataz.chchile.org> References: <20061021225146.GT53114@obiwan.tataz.chchile.org> <00aa01c6f5b1$d8e8a6a0$0300a8c0@COMETE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00aa01c6f5b1$d8e8a6a0$0300a8c0@COMETE> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: mlaier@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: not enough rates in struct iwi_rateset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:13:45 -0000 Damien, On Sun, Oct 22, 2006 at 10:12:41AM +0200, Damien Bergamini wrote: > Thanks a lot for pointing that out. > I think the correct fix would be to copy only the minimum > between 12 (sizeof rs.rsrates) and ni->ni_rates.rs_nrates. > You can't just extend the size of the iwi_rateset structure > which is a command sent to the firmware (I double-checked in > the Intel Linux driver and they also use a structure with 12 > (IPW_MAX_RATES) rates). > I wonder how ni->ni_rates.rs_nrates can be greater than 12 > though since we only have 12 rates max in ic->ic_sup_rates[] > and the rate set is supposed to be negotiated at that point > which means that any rate that we don't support should have > been removed from ni->ni_rates.rs_rates[]. > If you could show the content of ni->ni_rates.rs_rates[], > that might help. Here is the content of the ieee80211_rateset structure: % (kgdb) print ni->ni_rates % $6 = { % rs_nrates = 0x0, % rs_rates = "\000\000\214\n\000\000\2200\177\001\000\000\000\000\202" % } And a more readable version of rs_rates[]: % (kgdb) while ($i < 15) % >printf "%d\t%#x\n", ni->ni_rates.rs_rates[$i], ni->ni_rates.rs_rates[$i] % >set $i = $i + 1 % >end % 0 0 % 0 0 % 140 0x8c % 10 0xa % 0 0 % 0 0 % 144 0x90 % 48 0x30 % 127 0x7f % 1 0x1 % 0 0 % 0 0 % 0 0 % 0 0 % 130 0x82 Feel free to ask for more informations at need. Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:36:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5258316A4D2 for ; Sun, 22 Oct 2006 11:36:45 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.droso.net [193.88.12.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 584B143F43 for ; Sun, 22 Oct 2006 11:19:25 +0000 (GMT) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 563541CDB0; Sun, 22 Oct 2006 13:19:24 +0200 (CEST) Date: Sun, 22 Oct 2006 13:19:24 +0200 From: Erwin Lansing To: freebsd-current@freebsd.org Message-ID: <20061022111923.GU80328@droso.net> Mail-Followup-To: freebsd-current@freebsd.org References: <20061022095811.GA10743@zaphod.nitro.dk> <453B41EC.5060202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5wfsVCgeKAcINk2" Content-Disposition: inline In-Reply-To: <453B41EC.5060202@FreeBSD.org> X-Operating-System: FreeBSD/i386 6.2-PRERELEASE User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:36:45 -0000 --Y5wfsVCgeKAcINk2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 22, 2006 at 12:03:24PM +0200, Gbor Kvesdn wrote: > Simon L. Nielsen wrote: > >Hey, > > > >I think something odd is going on in the resolver. It seems like it > >doesn't resolve hostnames some of the time. It's not really easily > >reproducible, but I have seen it happen several times with cvsup where > >it can't resolve the cvsup server. If I re-run cvsup it works fine. > > > >I see it on recent -CURRNET's (server running cvsup below is October > >12, system running host(1) is October 15). > > > >The cvsup log: > > > >CVSup update begins at 2006-10-18 17:29:00 > >Updating from cvsup3.dk.freebsd.org > >Name lookup failure for "cvsup3.dk.freebsd.org": Host name lookup failed > >Updating local ncvs > >CVSup update ends at 2006-10-18 17:29:01 > > > >I also seen odd things happen with host(1). These two commands were > >run right after each other. I don't know if it's related, but I > >suspect it is. > > > >$ host cvsup3.dk.freebsd.org > >cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > >cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > >$ host cvsup3.dk.freebsd.org > >cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > >mirror03.inet.tele.dk has address 195.41.53.219 > >cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > >cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > > > >I only have one name-server in resolv.conf, so the problem isn't due > >to hitting different caching name-servers. > > > >Initially I thought it was a local problem for me, but joel@ has seen > >the same on RELENG_6 (from July 8), and xride@ has seen the > >same/similar with csup where his workaround was to ping the cvsup > >server before running csup. > > > >So, has anyone seen anything similar? Since I can't reproduce the > >issue at will I don't really know where to look for what's going on, > >and of course it could be DNS issue... > > > > =20 > Same here with csup vs. cvsup.hu.FreeBSD.org. If I resolve it elsewhere= =20 > and specify the ip address manually, it works just fine. Tomorrow's=20 > -current here on i386. >=20 Same problem after upgrading from 6.1-PRERELEASE to 6.2-PRERELEASE (yearh, real releases are for children) on beastie (danish half of ftp.f.o). I have not seen it anywhere else but in the cvsup jobs on that particular machine, so I blamed outside causes before. Data point: Old install March 13, new install October 3rd. -erwin --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --Y5wfsVCgeKAcINk2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFO1O7qy9aWxUlaZARAj1nAJ9u7ykj7R2mKHOTrskyGrRb1WJquACglYB4 7OYpHyJuWUb2SLMglTvQ46I= =Uq51 -----END PGP SIGNATURE----- --Y5wfsVCgeKAcINk2-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:48:09 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D89AB16A40F; Sun, 22 Oct 2006 11:48:09 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84F7F43D92; Sun, 22 Oct 2006 11:47:59 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:BjRYeAMKRrSwSotUhltch7f4bUpodD6eaZjiZ+RRD899F63zRaroeDguydee12ch@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MBlrKf081238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 20:47:53 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 22 Oct 2006 20:47:53 +0900 Message-ID: From: Hajimu UMEMOTO To: Ion-Mihai "IOnut" Tetcu In-Reply-To: <20061022132225.13299ae6@it.buh.tecnik93.com> References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 22 Oct 2006 20:47:54 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org, "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:48:09 -0000 Hi, >>>>> On Sun, 22 Oct 2006 13:22:25 +0300 >>>>> Ion-Mihai "IOnut" Tetcu said: itetcu> It's like the resolver it is giving up to early, if after the "Name itetcu> lookup failure ..." message I hit Ctrl+C and run it again immediately itetcu> it resolves OK. The default retry count was reduced from 4 to 2 since March 6, as BIND9 reduced it. It might bite you. Please increase retry count by putting something like `options retry: 4' into your resolv.conf, and see if it helps. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:53:24 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4AD216A53C; Sun, 22 Oct 2006 11:53:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D57E4428F; Sun, 22 Oct 2006 11:25:38 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9MBPcSP067469; Sun, 22 Oct 2006 07:25:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9MBPcx7048017; Sun, 22 Oct 2006 07:25:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0668373068; Sun, 22 Oct 2006 07:25:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061022112538.0668373068@freebsd-current.sentex.ca> Date: Sun, 22 Oct 2006 07:25:37 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 11:53:25 -0000 TB --- 2006-10-22 10:56:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-22 10:56:03 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-10-22 10:56:03 - cleaning the object tree TB --- 2006-10-22 10:56:28 - checking out the source tree TB --- 2006-10-22 10:56:28 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-10-22 10:56:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-22 11:06:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-22 11:06:26 - cd /src TB --- 2006-10-22 11:06:26 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 22 11:06:28 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/vwscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wbuf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wprintf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wsetup.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c /src/lib/libc/stdio/xprintf.c: In function `__v2printf': /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** 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 --- 2006-10-22 11:25:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-22 11:25:37 - ERROR: failed to build world TB --- 2006-10-22 11:25:37 - tinderbox aborted TB --- 0.20 user 0.68 system 1774.42 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 11:54:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F53616A56B; Sun, 22 Oct 2006 11:54:20 +0000 (UTC) (envelope-from andy@athame.co.uk) Received: from hex.athame.co.uk (salama58.adsl.netsonic.fi [81.17.207.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DA35440FB; Sun, 22 Oct 2006 11:22:21 +0000 (GMT) (envelope-from andy@athame.co.uk) Received: from ping.int.athame.co.uk ([192.168.10.8]) by hex.athame.co.uk with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GbbPF-000AoE-Jz; Sun, 22 Oct 2006 14:22:17 +0300 From: Andy Fawcett To: freebsd-current@freebsd.org Date: Sun, 22 Oct 2006 14:23:18 +0300 User-Agent: KMail/1.9.4 References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> In-Reply-To: <1161515330.751.9.camel@localhost> X-Face: ?fLK282oT!Ss!(krp%ft%TWfrkz*Mxz<2hwkRBzd); #D/=!=XjYKFBh1wVeov4K&<=?utf-8?q?Z6bi=5F=0A=09=7BBvAjk1diod2?=,DQo`Xz<\$~fX7B>U`u0HC\Gc+B9Hxu"bjBc16tg~i4.,2A1>=?utf-8?q?=7BrcRK=5Fi!i=0A=097e79f=7CT=3B9=23gfr=3DG1u=27xS=3D?=(}_NSP,Gs>HDq Cc: Hajimu UMEMOTO , "Simon L. Nielsen" , Joel Dahl Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 11:54:20 -0000 On Sunday 22 October 2006 14:08, Joel Dahl wrote: > On Sun, 2006-10-22 at 19:56 +0900, Hajimu UMEMOTO wrote: > > Hi, > > > > >>>>> On Sun, 22 Oct 2006 11:58:12 +0200 > > >>>>> "Simon L. Nielsen" said: > > > > simon> Initially I thought it was a local problem for me, but joel@ > > has seen simon> the same on RELENG_6 (from July 8), and xride@ has > > seen the simon> same/similar with csup where his workaround was to > > ping the cvsup simon> server before running csup. > > > > Is the date correct? Since I did MFC BIND9's resolver into > > RELENG_6 at July 17, this issue seems not related to resolver > > update. > > Yes, the date is correct. Also, itetcu@ is seeing the same thing > with a RELENG_6 from June, so I guess your MFC isn't responsible for > this. I'm seeing similar on one 6.x box here from time to time: $ uname -a FreeBSD ping.int.athame.co.uk 6.1-STABLE FreeBSD 6.1-STABLE #2: Mon Jul 31 02:25:05 EEST 2006 root@ping.int.athame.co.uk:/usr/obj/usr/src/sys/PING amd64 As with Simon's original report, trying again seems to work okay. I'm only seeing this effect (or maybe only noticing it) with csup/cvsup. Could be coincidence though. A. -- Andy Fawcett | andy@athame.co.uk | tap@kde.org "In an open world without walls and fences, | tap@lspace.org we wouldn't need Windows and Gates." -- anon | tap@fruitsalad.org From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 12:01:10 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE0016A4B3; Sun, 22 Oct 2006 12:01:10 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6889443D66; Sun, 22 Oct 2006 12:01:09 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:qeFT7E3/kMLX6YDwIJJo3zGEI5KTs3PkE/p34N/o2A7CoBXRTmACO51TOskJu7Zy@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MC12IC017964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 21:01:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 22 Oct 2006 21:01:02 +0900 Message-ID: From: Hajimu UMEMOTO To: Ion-Mihai "IOnut" Tetcu In-Reply-To: References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 22 Oct 2006 21:01:03 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org, "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 12:01:10 -0000 Hi, >>>>> On Sun, 22 Oct 2006 20:47:53 +0900 >>>>> Hajimu UMEMOTO said: ume> Please increase retry count by putting something like `options retry: 4' ume> into your resolv.conf, and see if it helps. Oops, it must be `options retry:4' Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 12:08:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96ACD16A403; Sun, 22 Oct 2006 12:08:46 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3940943DB4; Sun, 22 Oct 2006 12:08:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:3Z+PES0f3HzURVccIc32mGOXr8KOb2slghGgRXS32yTDCKxajxOcXMN/NrgsAkfg@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MC8CA6033030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 21:08:13 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 22 Oct 2006 21:08:12 +0900 Message-ID: From: Hajimu UMEMOTO To: Ion-Mihai "IOnut" Tetcu In-Reply-To: References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 22 Oct 2006 21:08:13 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org, "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 12:08:46 -0000 Hi, >>>>> On Sun, 22 Oct 2006 20:47:53 +0900 >>>>> Hajimu UMEMOTO said: ume> Please increase retry count by putting something like `options retry: 4' ume> into your resolv.conf, and see if it helps. Oops, `retry' was obsoleted. It must be `options attempts:4'. Sorry for the mess. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 12:08:52 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E69B816A4A0; Sun, 22 Oct 2006 12:08:52 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD2443D97; Sun, 22 Oct 2006 12:08:31 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 7BC5F99FBE4; Sun, 22 Oct 2006 14:08:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z+ZF24qh6azM; Sun, 22 Oct 2006 14:08:27 +0200 (CEST) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 0167F99FBCD; Sun, 22 Oct 2006 14:08:26 +0200 (CEST) Message-ID: <453B5F3A.3030804@FreeBSD.org> Date: Sun, 22 Oct 2006 14:08:26 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "Ion-Mihai \"IOnut\" Tetcu" , "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 12:08:53 -0000 Hajimu UMEMOTO wrote: > Hi, > > >>>>>> On Sun, 22 Oct 2006 13:22:25 +0300 >>>>>> Ion-Mihai "IOnut" Tetcu said: >>>>>> > > itetcu> It's like the resolver it is giving up to early, if after the "Name > itetcu> lookup failure ..." message I hit Ctrl+C and run it again immediately > itetcu> it resolves OK. > > The default retry count was reduced from 4 to 2 since March 6, as > BIND9 reduced it. It might bite you. > Please increase retry count by putting something like `options retry: 4' > into your resolv.conf, and see if it helps. > > options attempts: 4 is the correct form and it did help to me. Thanks. -- Cheers, Gabor From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 13:57:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A52B16A407; Sun, 22 Oct 2006 13:57:41 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D388343D79; Sun, 22 Oct 2006 13:57:40 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.77.103]) by VL-MO-MR003.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J7J00MTZIS3FX00@VL-MO-MR003.ip.videotron.ca>; Sun, 22 Oct 2006 09:57:40 -0400 (EDT) Date: Sun, 22 Oct 2006 09:57:34 -0400 From: Nicolas Blais In-reply-to: <20061022092137.E676@free.home.local> To: Yuriy Tsibizov Message-id: <200610220957.39431.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart2172621.pI1WHcMqbJ; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <200610211403.43055.nb_root@videotron.ca> <200610211540.02844.nb_root@videotron.ca> <20061022092137.E676@free.home.local> User-Agent: KMail/1.9.4 Cc: John-Mark Gurney , freebsd-current@freebsd.org Subject: Re: Asus A8V hangs during pci probe on fresh-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 13:57:41 -0000 --nextPart2172621.pI1WHcMqbJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 22 October 2006 01:49, Yuriy Tsibizov wrote: > > skc0: port 0xb000-0xb0ff mem > > 0xf9c00000-0xf9c03fff irq 17 at device 10.0 on pci0 > > FreeBSD sk driver reads only first two records before last pci/sk VPD > changes. Now it reads it all, and it is possible that VPD data in your > card is broken. > > If you boot verbose with old -CURRENT, can you see 'bad VPD resource id' > messages? > > Linux sk98lin driver had some workarounds for 'buggy ASUS VPD on K8V > Deluxe' (http://www.ussg.iu.edu/hypermail/linux/kernel/0404.3/0090.html). > I'm not shure, is it applicable to your MB. > > Yuriy. You can see me verbose dmesg here with the old kernel that works (oct 7th) : http://24.202.77.103:8081/FreeBSD/update/dmesgverb.txt and a screenshot of the new: http://24.202.77.103:8081/FreeBSD/update/kernelbootv.jpg I hope this may help, Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #1: Sat Oct 7 15:11:02 EDT 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart2172621.pI1WHcMqbJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFO3jT4wTBlvcsbJURAuKuAKCUPXnJB/Rqd1r8Hkt9sOt0JDxGMgCdHx3w KlvAxuhJCB1l3UNrjfSG72A= =yhdM -----END PGP SIGNATURE----- --nextPart2172621.pI1WHcMqbJ-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 14:00:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE67816A417 for ; Sun, 22 Oct 2006 14:00:55 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mta01.mail.t-online.hu (mta03.mail.t-online.hu [195.228.240.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB8E43D73 for ; Sun, 22 Oct 2006 14:00:46 +0000 (GMT) (envelope-from sziszi@bsd.hu) Received: from baranyfelhocske.buza.adamsfamily.xx (catv54033C7D.pool.t-online.hu [84.3.60.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.t-online.hu (Postfix) with ESMTP for ; Sun, 22 Oct 2006 16:00:45 +0200 (CEST) Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.13.8/8.13.8) with ESMTP id k9ME0jwh017431 for ; Sun, 22 Oct 2006 16:00:45 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.13.8/8.13.8/Submit) id k9ME0jJa017430 for freebsd-current@freebsd.org; Sun, 22 Oct 2006 16:00:45 +0200 (CEST) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Sun, 22 Oct 2006 16:00:45 +0200 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20061022140044.GA16932@baranyfelhocske.buza.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , freebsd-current@freebsd.org References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610221423.19817.andy@athame.co.uk> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 14:00:55 -0000 Hello everybody, Just as a datapoint, I also observed this on -CURRENT for a while (although I most certainly did not see it happen in July/August) with cvsup jobs. However, I no longer observe it with recent -CURRENT, for example the one I run now, which is from today morning local time, or the previous installment, which was from the 20th October. I did not change the default attempts option in resolv.conf. However, I do use a local named for caching. -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 14:04:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A81F316A40F; Sun, 22 Oct 2006 14:04:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D4A843D5A; Sun, 22 Oct 2006 14:04:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9ME4BLo076127; Sun, 22 Oct 2006 10:04:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id k9ME4B94077223; Sun, 22 Oct 2006 10:04:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 994EB73068; Sun, 22 Oct 2006 10:04:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061022140410.994EB73068@freebsd-current.sentex.ca> Date: Sun, 22 Oct 2006 10:04:10 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 14:04:12 -0000 TB --- 2006-10-22 13:36:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-22 13:36:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-10-22 13:36:45 - cleaning the object tree TB --- 2006-10-22 13:36:59 - checking out the source tree TB --- 2006-10-22 13:36:59 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-10-22 13:36:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-22 13:44:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-22 13:44:55 - cd /src TB --- 2006-10-22 13:44:55 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 22 13:44:56 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/vwscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wbuf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wprintf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wsetup.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c /src/lib/libc/stdio/xprintf.c: In function `__v2printf': /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** 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 --- 2006-10-22 14:04:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-22 14:04:10 - ERROR: failed to build world TB --- 2006-10-22 14:04:10 - tinderbox aborted TB --- 0.22 user 0.62 system 1644.63 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 15:59:57 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AF3216A40F; Sun, 22 Oct 2006 15:59:57 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF6043D46; Sun, 22 Oct 2006 15:59:55 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:mFzpkMbjrj4lr6WE5LqeHFbil1tOTvtnUmXiJOj4VdphnJOURTGnOA9JJQ9a9YGa@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9MFxnpx023116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Oct 2006 00:59:49 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 23 Oct 2006 00:59:48 +0900 Message-ID: From: Hajimu UMEMOTO To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= In-Reply-To: <453B5F3A.3030804@FreeBSD.org> References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> <453B5F3A.3030804@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 23 Oct 2006 00:59:50 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: freebsd-current@FreeBSD.org, "Ion-Mihai \"IOnut\" Tetcu" , "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 15:59:57 -0000 Hi, >>>>> On Sun, 22 Oct 2006 14:08:26 +0200 >>>>> G=E1bor K=F6vesd=E1n said: gabor> options attempts: 4 is the correct form and it did help to me. Thank= s. I found the timeout related fix in bind-9.3.3rc2: > 2005. [bug] libbind: Retransmission timeouts should be > based on which attempt it is to the nameserver > and not the nameserver itself. [RT #13548] It may solve your problem. So, could you try this patch, instead? Index: lib/libc/resolv/res_send.c diff -u -p lib/libc/resolv/res_send.c.orig lib/libc/resolv/res_send.c --- lib/libc/resolv/res_send.c.orig Tue Aug 8 04:14:55 2006 +++ lib/libc/resolv/res_send.c Mon Oct 23 00:36:41 2006 @@ -145,7 +145,7 @@ static int send_dg(res_state, int kq, #endif const u_char *, int, - u_char *, int, int *, int, + u_char *, int, int *, int, int, int *, int *); static void Aerror(const res_state, FILE *, const char *, int, const struct sockaddr *, int); @@ -490,7 +490,7 @@ res_nsend(res_state statp, kq, #endif buf, buflen, ans, anssiz, &terrno, - ns, &v_circuit, &gotsomewhere); + ns, try, &v_circuit, &gotsomewhere); if (n < 0) goto fail; if (n =3D=3D 0) @@ -812,8 +812,9 @@ send_dg(res_state statp, #ifdef USE_KQUEUE int kq, #endif - const u_char *buf, int buflen, u_char *ans, int anssiz, - int *terrno, int ns, int *v_circuit, int *gotsomewhere) + const u_char *buf, int buflen, u_char *ans, + int anssiz, int *terrno, int ns, int try, int *v_circuit, + int *gotsomewhere) { const HEADER *hp =3D (const HEADER *) buf; HEADER *anhp =3D (HEADER *) ans; @@ -914,7 +915,7 @@ send_dg(res_state statp, /* * Wait for reply. */ - seconds =3D (statp->retrans << ns); + seconds =3D (statp->retrans << try); if (ns > 0) seconds /=3D statp->nscount; if (seconds <=3D 0) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 16:24:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776A616A407; Sun, 22 Oct 2006 16:24:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679BD43D8A; Sun, 22 Oct 2006 16:24:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9MGOHco084373; Sun, 22 Oct 2006 12:24:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9MGOHPi038041; Sun, 22 Oct 2006 12:24:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 068BE73068; Sun, 22 Oct 2006 12:24:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061022162417.068BE73068@freebsd-current.sentex.ca> Date: Sun, 22 Oct 2006 12:24:16 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 16:24:19 -0000 TB --- 2006-10-22 15:19:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-22 15:19:00 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-10-22 15:19:00 - cleaning the object tree TB --- 2006-10-22 15:19:27 - checking out the source tree TB --- 2006-10-22 15:19:27 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-10-22 15:19:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-22 15:27:40 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-22 15:27:40 - cd /src TB --- 2006-10-22 15:27:40 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 22 15:27:43 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Oct 22 16:15:09 UTC 2006 TB --- 2006-10-22 16:15:09 - generating LINT kernel config TB --- 2006-10-22 16:15:09 - cd /src/sys/sun4v/conf TB --- 2006-10-22 16:15:09 - /usr/bin/make -B LINT TB --- 2006-10-22 16:15:10 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-10-22 16:15:10 - cd /src TB --- 2006-10-22 16:15:10 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Oct 22 16:15:10 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/t1_copy.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/ofw_bus.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/ofw_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/pmap.c /src/sys/sun4v/sun4v/pmap.c: In function `get_pv_entry': /src/sys/sun4v/sun4v/pmap.c:310: error: `PG_BUSY' undeclared (first use in this function) /src/sys/sun4v/sun4v/pmap.c:310: error: (Each undeclared identifier is reported only once /src/sys/sun4v/sun4v/pmap.c:310: error: for each function it appears in.) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-22 16:24:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-22 16:24:16 - ERROR: failed to build lint kernel TB --- 2006-10-22 16:24:16 - tinderbox aborted TB --- 0.69 user 1.87 system 3916.63 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 17:00:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C32F16A4D1 for ; Sun, 22 Oct 2006 17:00:46 +0000 (UTC) (envelope-from norgaard@locolomo.org) Received: from strange.daemonsecurity.com (59.Red-81-33-11.staticIP.rima-tde.net [81.33.11.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 323D143DA4 for ; Sun, 22 Oct 2006 17:00:34 +0000 (GMT) (envelope-from norgaard@locolomo.org) Received: from [10.35.4.65] (65.4-35-10-static.chueca.wifi [10.35.4.65]) by strange.daemonsecurity.com (Postfix) with ESMTP id E1AFB2E024; Sun, 22 Oct 2006 19:00:24 +0200 (CEST) Message-ID: <453BA34C.7010504@locolomo.org> Date: Sun, 22 Oct 2006 18:58:52 +0200 From: Erik Norgaard User-Agent: Thunderbird 1.5.0.7 (X11/20061022) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061022064322.GU53114@obiwan.tataz.chchile.org> In-Reply-To: <20061022064322.GU53114@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Cannot unload if_iwi module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 17:00:46 -0000 Jeremie Le Hen wrote: > Hi, > > when I try to unload if_iwi module, here is what happens: > > % jarjarbinks:/<3>dev/iwi:118# kldunload if_iwi > % iwi0: detached > % jarjarbinks:/<3>dev/iwi:119# iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > % iwi0: [GIANT-LOCKED] > > The kld is reloaded automatically (I am sure it is reloaded because > the id showed in kldstat(8) changes each time): > Any clue how to disable this unwanted behaviour ? Have you tried to bring down the interface first? A possible reason could be that the interface is "busy" or locked so the unload fails, are you running wpa_supplicant? Try stop wpa_supplicant if you use it and bring down the interface first. Also, you may get more info if you set debug.iwi=1. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9 From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 21:27:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8701316A412; Sun, 22 Oct 2006 21:27:33 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [193.85.228.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E682A43D4C; Sun, 22 Oct 2006 21:27:32 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [193.85.228.22]) by nxm.secservers.com (8.13.4/8.13.4) with ESMTP id k9MLRUqK012050; Sun, 22 Oct 2006 23:27:30 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Florent Thoumie In-Reply-To: <1161512742.71755.9.camel@localhost> References: <20061022064322.GU53114@obiwan.tataz.chchile.org> <1161512742.71755.9.camel@localhost> Content-Type: text/plain Date: Sun, 22 Oct 2006 23:27:23 +0200 Message-Id: <1161552443.41580.26.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: Cannot unload if_iwi module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 21:27:33 -0000 Florent Thoumie wrote: > On Sun, 2006-10-22 at 08:43 +0200, Jeremie Le Hen wrote: > > Hi, > > > > when I try to unload if_iwi module, here is what happens: > > > > % jarjarbinks:/<3>dev/iwi:118# kldunload if_iwi > > % iwi0: detached > > % jarjarbinks:/<3>dev/iwi:119# iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 > > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > > % iwi0: [GIANT-LOCKED] > > > > The kld is reloaded automatically (I am sure it is reloaded because > > the id showed in kldstat(8) changes each time): > > > > % jarjarbinks:/<1>share/mk:137# kldstat > > % Id Refs Address Size Name > > % 1 20 0xc0400000 4ef910 kernel > > % 2 1 0xc08f0000 e5dc if_bge.ko > > % 3 1 0xc08ff000 4ce4 ums.ko > > % 4 1 0xc0904000 b180 umass.ko > > % 5 2 0xc382e000 25000 linux.ko > > % 6 1 0xc38cb000 2000 rtc.ko > > % 9 1 0xc3acf000 e000 if_iwi.ko > > % 10 2 0xc3add000 3000 firmware.ko > > > > % jarjarbinks:/<3>dev/iwi:122# kldstat > > % Id Refs Address Size Name > > % 1 19 0xc0400000 4ef910 kernel > > % 2 1 0xc08f0000 e5dc if_bge.ko > > % 3 1 0xc08ff000 4ce4 ums.ko > > % 4 1 0xc0904000 b180 umass.ko > > % 5 2 0xc382e000 25000 linux.ko > > % 6 1 0xc38cb000 2000 rtc.ko > > % 11 1 0xc3acf000 e000 if_iwi.ko > > % 12 1 0xc3add000 3000 firmware.ko > > > > Any clue how to disable this unwanted behaviour ? > > No idea, but the same behavior can be seen with ipw(4) and experimental > wpi(4). I seem to recall this didn't happen before the the support for > firmware(9) was added. It also happens with em(4) to me. I found out it doesn't happen when devd is not running. I find it rather strange that the 'pciconf -l' command shows driver name (e.g. em0@pci...) even after (successfully and permanently) unloading the module for a device. The 'devinfo' command does not. Michal From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 23:18:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A7AD16A403 for ; Sun, 22 Oct 2006 23:18:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 8492D43D97 for ; Sun, 22 Oct 2006 23:18:11 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 19106 invoked by uid 399); 22 Oct 2006 23:18:10 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Oct 2006 23:18:10 -0000 Message-ID: <453BFC2A.5010501@FreeBSD.org> Date: Sun, 22 Oct 2006 16:18:02 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andy Fawcett References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> In-Reply-To: <200610221423.19817.andy@athame.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO , "Simon L. Nielsen" , Joel Dahl Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 23:18:19 -0000 Andy Fawcett wrote: > I'm only seeing this effect (or maybe only noticing it) with csup/cvsup. > Could be coincidence though. Hrrm, it's odd that it affects both csup _and_ cvsup, since the former is written in C, and links natively against our libraries. I'm wondering if we're seeing a situation where the name servers that those hostnames are delegated to are just taking a long time to respond, and neither app is patient enough. I think it would be an interesting experiment to see what happens if you increase the retry timeout. Is anyone else seeing this problem with other applications? Simon, I'll address your problems with host(1) in a separate mail. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 23:23:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7AC916A403 for ; Sun, 22 Oct 2006 23:23:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id B301C43D83 for ; Sun, 22 Oct 2006 23:23:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 24232 invoked by uid 399); 22 Oct 2006 23:23:52 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Oct 2006 23:23:52 -0000 Message-ID: <453BFD84.5050702@FreeBSD.org> Date: Sun, 22 Oct 2006 16:23:48 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Simon L. Nielsen" References: <20061022095811.GA10743@zaphod.nitro.dk> In-Reply-To: <20061022095811.GA10743@zaphod.nitro.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hajimu UMEMOTO Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 23:23:55 -0000 Simon L. Nielsen wrote: > I also seen odd things happen with host(1). These two commands were > run right after each other. I don't know if it's related, but I > suspect it is. > > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. You got a double answer here because by default host(1) searches for both A and AAAA records for hostnames. > $ host cvsup3.dk.freebsd.org > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. > mirror03.inet.tele.dk has address 195.41.53.219 You got an answer for the A query here for mirror03.inet.tele.dk. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. You got an answer here for the AAAA query for cvsup3.dk.freebsd.org. > cvsup3.dk.freebsd.org is an alias for mirror03.inet.tele.dk. This is probably an error, and if it's what I think it is this problem is fixed in the latest version of BIND. Whether this behavior of chasing AAAA by default is a good thing or not is an open question, but there you go. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 23:28:06 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0889E16A407; Sun, 22 Oct 2006 23:28:06 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36CD743D83; Sun, 22 Oct 2006 23:28:03 +0000 (GMT) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id 365B21711A; Mon, 23 Oct 2006 02:28:02 +0300 (EEST) Date: Mon, 23 Oct 2006 02:28:01 +0300 From: Ion-Mihai "IOnut" Tetcu To: Hajimu UMEMOTO Message-ID: <20061023022801.2dcaaa10@it.buh.tecnik93.com> In-Reply-To: References: <20061022095811.GA10743@zaphod.nitro.dk> <20061022132225.13299ae6@it.buh.tecnik93.com> <453B5F3A.3030804@FreeBSD.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_KAY7CxK/fMC9Vdt4vzlYsQ."; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@FreeBSD.org, =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , "Simon L. Nielsen" Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 23:28:06 -0000 --Sig_KAY7CxK/fMC9Vdt4vzlYsQ. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 23 Oct 2006 00:59:48 +0900 Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Sun, 22 Oct 2006 14:08:26 +0200 > >>>>> G=E1bor K=F6vesd=E1n said: >=20 > gabor> options attempts: 4 is the correct form and it did help to me. > gabor> Thanks. >=20 > I found the timeout related fix in bind-9.3.3rc2: >=20 > > 2005. [bug] libbind: Retransmission timeouts > > should be > > based on which attempt it is to the > > nameserver and not the nameserver itself. [RT #13548] >=20 > It may solve your problem. So, could you try this patch, instead? Thanks, I rebuilt a machine with this patch and I'll keep an aye on it and let you know if/when I see the problem again. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, "The Squire of Gothos", stardate 2124.5 --Sig_KAY7CxK/fMC9Vdt4vzlYsQ. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFO/6BBX6fi0k6KXsRAi+PAJwOJt5BCiirMcae1wNG3hwMJRuHygCgofgG YqRLd07McSb7o18rio1MnwU= =mJva -----END PGP SIGNATURE----- --Sig_KAY7CxK/fMC9Vdt4vzlYsQ.-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 23:29:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B57E316A415; Sun, 22 Oct 2006 23:29:31 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD48E43D70; Sun, 22 Oct 2006 23:29:29 +0000 (GMT) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id CDCF31711A; Mon, 23 Oct 2006 02:29:28 +0300 (EEST) Date: Mon, 23 Oct 2006 02:29:28 +0300 From: Ion-Mihai "IOnut" Tetcu To: Doug Barton Message-ID: <20061023022928.35b7b23c@it.buh.tecnik93.com> In-Reply-To: <453BFC2A.5010501@FreeBSD.org> References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_xkqawxwBfXWCwt4apSmAgVn; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: UMEMOTO , Joel, "Simon L. Nielsen" , freebsd-current@freebsd.org, Dahl , Hajimu Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 23:29:31 -0000 --Sig_xkqawxwBfXWCwt4apSmAgVn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Oct 2006 16:18:02 -0700 Doug Barton wrote: > Andy Fawcett wrote: >=20 > > I'm only seeing this effect (or maybe only noticing it) with > > csup/cvsup. Could be coincidence though. >=20 > Hrrm, it's odd that it affects both csup _and_ cvsup, since the > former is written in C, and links natively against our libraries. I'm=20 > wondering if we're seeing a situation where the name servers that=20 > those hostnames are delegated to are just taking a long time to=20 > respond, and neither app is patient enough. I think it would be an=20 > interesting experiment to see what happens if you increase the retry=20 > timeout. >=20 > Is anyone else seeing this problem with other applications? Simon,=20 > I'll address your problems with host(1) in a separate mail. I'm seeing it with squid. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" BOFH excuse #212: Of course it doesn't work, we've performed a software upgrade --Sig_xkqawxwBfXWCwt4apSmAgVn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFO/7YBX6fi0k6KXsRAjPvAJsEZiRCz/l7GKO8iFiWDtslih1YmACgpv+G x8yZNXDydy5K03DeTrij+F8= =88bL -----END PGP SIGNATURE----- --Sig_xkqawxwBfXWCwt4apSmAgVn-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 00:59:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB7AA16A412; Mon, 23 Oct 2006 00:59:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFF943D4C; Mon, 23 Oct 2006 00:59:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9N0x9rl092226; Sun, 22 Oct 2006 20:59:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9N0x9GL084230; Sun, 22 Oct 2006 20:59:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3896373068; Sun, 22 Oct 2006 20:59:09 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061023005909.3896373068@freebsd-current.sentex.ca> Date: Sun, 22 Oct 2006 20:59:09 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean 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: Mon, 23 Oct 2006 00:59:10 -0000 TB --- 2006-10-23 00:29:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-23 00:29:27 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-10-23 00:29:27 - cleaning the object tree TB --- 2006-10-23 00:29:51 - checking out the source tree TB --- 2006-10-23 00:29:51 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-10-23 00:29:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-23 00:39:50 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-23 00:39:50 - cd /src TB --- 2006-10-23 00:39:50 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 23 00:39:52 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/vwscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wbuf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wprintf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wsetup.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c /src/lib/libc/stdio/xprintf.c: In function `__v2printf': /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** 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 --- 2006-10-23 00:59:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-23 00:59:08 - ERROR: failed to build world TB --- 2006-10-23 00:59:08 - tinderbox aborted TB --- 0.29 user 0.58 system 1781.89 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 01:47:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE9ED16A540 for ; Mon, 23 Oct 2006 01:47:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 327B243D60 for ; Mon, 23 Oct 2006 01:47:49 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1019631uge for ; Sun, 22 Oct 2006 18:47:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lKCnKSF0f0fpUkYB8VMIq9ltxrNOSn0m1XK2Mp5a0P7KAThWu5yFGTJhExJabCAnUToKqaEPiIqwrOu43VQedPHHgGddIX3besxU9XpvfrFQYx8i6pT2PT6D3mj1kPERLzAX7jAkLS08+cj3OxIP8s3z3Z7mhTSbdQ563uhHz+Y= Received: by 10.66.220.17 with SMTP id s17mr6462357ugg; Sun, 22 Oct 2006 18:47:49 -0700 (PDT) Received: by 10.67.86.8 with HTTP; Sun, 22 Oct 2006 18:47:49 -0700 (PDT) Message-ID: <790a9fff0610221847u3494e76dsd3d8328d499d6200@mail.gmail.com> Date: Sun, 22 Oct 2006 20:47:49 -0500 From: "Scot Hetzel" To: kib@freebsd.org, current@freebsd.org In-Reply-To: <453AD5C2.6030507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061022000656.C384373068@freebsd-current.sentex.ca> <453AD5C2.6030507@freebsd.org> Cc: Subject: Re: [head tinderbox] failure on powerpc/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: Mon, 23 Oct 2006 01:47:53 -0000 On 10/21/06, Peter Grehan wrote: > > cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c > > /src/lib/libc/stdio/xprintf.c: In function `__v2printf': > > /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type > > *** Error code 1 > > I did a quick change of > > va_copy(ap, ap1); > > to > > va_copy(ap, (va_list) ap1); > > .. and ended up with: > > /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c: In > function `__v2printf': > /usr/home/grehan/freebsd/dev_head/src/lib/libc/stdio/xprintf.c:279: > error: cast specifies array type > > A va_list on powerpc is a struct, but va_copy should do the right thing. > I'm also seeing this problem on FreeBSD/amd64-CURRENT. I had reverted the change back to revision 1.3. And was able to sucessfully complete a buildworld. Maybe this change should be made I386 specific, since it is breaking builds for other arches. -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 03:37:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4A7B16A403; Mon, 23 Oct 2006 03:37:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38D1443D53; Mon, 23 Oct 2006 03:37:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9N3b58w002984; Sun, 22 Oct 2006 23:37:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9N3b5g4095562; Sun, 22 Oct 2006 23:37:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9A75373068; Sun, 22 Oct 2006 23:37:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061023033705.9A75373068@freebsd-current.sentex.ca> Date: Sun, 22 Oct 2006 23:37:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 03:37:15 -0000 TB --- 2006-10-23 03:10:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-23 03:10:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-10-23 03:10:09 - cleaning the object tree TB --- 2006-10-23 03:10:17 - checking out the source tree TB --- 2006-10-23 03:10:17 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-10-23 03:10:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-23 03:18:03 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-23 03:18:03 - cd /src TB --- 2006-10-23 03:18:03 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 23 03:18:05 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/vwscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wbuf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wprintf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wscanf.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/wsetup.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/stdio/xprintf.c /src/lib/libc/stdio/xprintf.c: In function `__v2printf': /src/lib/libc/stdio/xprintf.c:279: warning: passing arg 2 of `__builtin_va_copy' discards qualifiers from pointer target type *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** 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 --- 2006-10-23 03:37:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-23 03:37:05 - ERROR: failed to build world TB --- 2006-10-23 03:37:05 - tinderbox aborted TB --- 0.21 user 0.63 system 1616.16 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 06:20:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED16A16A403 for ; Mon, 23 Oct 2006 06:20:08 +0000 (UTC) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A8D043D49 for ; Mon, 23 Oct 2006 06:20:07 +0000 (GMT) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (localhost [IPv6:::1]) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id k9N6K5rQ087775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 23 Oct 2006 08:20:05 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.12.10/8.12.10/Submit) with UUCP id k9N6K5hS087774 for current@freebsd.org; Mon, 23 Oct 2006 08:20:05 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: from titan.klemm.apsfilter.org (localhost.klemm.apsfilter.org [127.0.0.1]) by klemm.apsfilter.org (8.13.8/8.13.4) with ESMTP id k9N6FdJ8017762 for ; Mon, 23 Oct 2006 08:15:39 +0200 (CEST) (envelope-from andreas@titan.klemm.apsfilter.org) Received: (from andreas@localhost) by titan.klemm.apsfilter.org (8.13.8/8.13.4/Submit) id k9N6FdIe017761 for current@freebsd.org; Mon, 23 Oct 2006 08:15:39 +0200 (CEST) (envelope-from andreas) Date: Mon, 23 Oct 2006 08:15:39 +0200 From: Andreas Klemm To: current@freebsd.org Message-ID: <20061023061539.GA17549@titan.klemm.apsfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 6.2-PRERELEASE X-Disclaimer: A free society is one where it is safe to be unpopular User-Agent: Mutt/1.5.11 Cc: Subject: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 06:20:09 -0000 Hi, I installed the latest amd64 -current snap from server (oct 2006). I installed only a "handfull" of ports to get xfce4 running. Then later I installed portupgrade and did a portupgrade -a. Some ports got upgraded, and then it hung at the configure stage of some ports. Funny thing is, building such a port manually by cd /usr/ports/xxx/yyy; make all install clean works. No problem with configure. Only portupgrade wasn't able to upgrade these ports. Is this a known -current problem or do I have to investigate more into this ? Or is it a special "portupgrade" problem in conjunction with only autoconf based ports ? If you need more data then tell, unluckily it got late yesterday evening, so I would provide "real info" later if you need. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 08:48:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB6E516A403 for ; Mon, 23 Oct 2006 08:48:44 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E4CE43D53 for ; Mon, 23 Oct 2006 08:48:41 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 64113 invoked from network); 23 Oct 2006 08:48:40 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 23 Oct 2006 08:48:40 -0000 X-pair-Authenticated: 80.165.155.106 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id k9N8mdgs004817 for ; Mon, 23 Oct 2006 10:48:39 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id k9N8mdqC004816 for current@freebsd.org; Mon, 23 Oct 2006 10:48:39 +0200 (CEST) (envelope-from pho) Date: Mon, 23 Oct 2006 10:48:39 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20061023084839.GA4523@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Deadlock while testing on a 64 MB filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 08:48:44 -0000 After some prodding by phk@ I made a test for problems seen with "newfs -b 32768 -f 4096". http://people.freebsd.org/~pho/stress/log/cons218.html I was using these watchdog options: -t 900 -e 'ls /tmp /dev /mnt > /dev/null; true' -s 60 and /mnt was the mount point for the test filesystem. -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 09:19:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D118F16A415 for ; Mon, 23 Oct 2006 09:19:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ADFD43D4C for ; Mon, 23 Oct 2006 09:19:09 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([81.18.142.225]:5386 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3376265AbWJWJS5 (ORCPT ); Mon, 23 Oct 2006 13:18:57 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <453C88FE.8010901@yandex.ru> Date: Mon, 23 Oct 2006 13:18:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------050808010202030501040901" Subject: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 09:19:12 -0000 This is a multi-part message in MIME format. --------------050808010202030501040901 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi, My system is CURRENT (~15.10.2006). When I try mounting a smbfs from windows server then mount_smbfs command is don't finished. And i can't interrupt or kill these processes. ps, top and trace output from ddb attached. -- WBR, Andrey V. Elsukov --------------050808010202030501040901 Content-Type: text/plain; name="trace.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="trace.txt" last pid: 2146; load averages: 0.00, 0.00, 0.00 up 0+05:28:50 13:07:20 32 processes: 1 running, 31 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 25M Active, 269M Inact, 73M Wired, 23M Cache, 53M Buf, 36M Free Swap: 1024M Total, 16K Used, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 859 root 1 -8 0 6120K 1528K devdrn 0:00 0.00% mount_smbfs 946 root 1 -8 0 6120K 1000K devdrn 0:00 0.00% mount_smbfs [btr-nb butcher]> ps ax | grep mount 1984 p1- DE 0:00,01 mount_smbfs -I 172.21.81.225 -E koi8-r:cp866 //butche 859 p2- DE 0:00,26 mount_smbfs -E koi8-r:cp866 -I 172.21.81.225 //elsuko 946 p4- DE 0:00,14 mount_smbfs -I 172.21.81.225 -E koi8-r:cp866 //elsuko [btr-nb butcher]> KDB: enter: manual escape to debugger [thread pid 19 tid 100026 ] Stopped at kdb_enter+0x2b: nop db> ps pid ppid pgrp uid state wmesg wchan cmd 2038 752 2038 1001 S+ ttyin 0xc27acc10 csh 1984 1 1984 0 SE+ devdrn 0xd3ac89d8 mount_smbfs 1950 635 635 125 S select 0xc07555b4 pickup 946 1 946 0 SE+ devdrn 0xd5c409d8 mount_smbfs 859 1 859 0 SE+ devdrn 0xd3af89d8 mount_smbfs 759 751 759 1001 S+ ttyin 0xc27b2410 csh 758 1 758 0 Ss+ ttyin 0xc27b6010 getty 757 1 757 0 Ss+ ttyin 0xc27b6410 getty 756 1 756 0 Ss+ ttyin 0xc27b6810 getty 755 1 755 0 Ss+ ttyin 0xc27b6c10 getty 754 1 754 0 Ss+ ttyin 0xc27b7010 getty 753 1 753 0 Ss+ ttyin 0xc27b7410 getty 752 1 752 0 Ss+ wait 0xc28da468 login 751 1 751 0 Ss+ wait 0xc28d869c login 711 1 711 0 Ss select 0xc07555b4 moused 679 1 679 0 Ss nanslp 0xc0751364 cron 658 635 635 125 S select 0xc07555b4 qmgr 635 1 635 0 Ss select 0xc07555b4 master 607 576 576 80 S accept 0xc298803a httpd db> trace 1984 Tracing pid 1984 tid 100088 td 0xc2995870 sched_switch(c2995870,0,1) at sched_switch+0x157 mi_switch(1,0,c2995870,d3ac8994,c05517b2,...) at mi_switch+0x1d4 sleepq_switch(d3ac89d8,c2995870,d3ac89b4,c0533c65,d3ac89d8,...) at sleepq_switch +0x8a sleepq_timedwait(d3ac89d8) at sleepq_timedwait+0x36 msleep(d3ac89d8,c074f7c4,4c,c06e9aa6,64) at msleep+0x21d destroy_devl(c322e700,d3ac8a18,c31edb35,c322e700,c32464e0,...) at destroy_devl+0 x155 destroy_dev(c322e700,c32464e0,c31ff180,c2995870,c31df300,...) at destroy_dev+0x1 0 nsmb_dev_close(c322e700,3,2000,c2995870) at nsmb_dev_close+0x69 giant_close(c322e700,3,2000,c2995870) at giant_close+0x4b devfs_close(d3ac8a80) at devfs_close+0x357 VOP_CLOSE_APV(c071c1c0,d3ac8a80) at VOP_CLOSE_APV+0x38 vn_close(c29ab71c,3,c31df300,c2995870) at vn_close+0x5a vn_closefile(c2a46ab0,c2995870,d3ac8b38,c050d630,c2a46ab0,...) at vn_closefile+0 xea devfs_close_f(c2a46ab0,c2995870) at devfs_close_f+0xf fdrop_locked(c2a46ab0,c2995870,c322e800,d3ac8bb8,c050bbaf,...) at fdrop_locked+0 xa8 fdrop(c2a46ab0,c2995870,d3ac8b94,c058d3d9,0,...) at fdrop+0x41 closef(c2a46ab0,c2995870) at closef+0x41f fdfree(c2995870) at fdfree+0x593 exit1(c2995870,100,d3ac8d30,c06a841e,c2995870,...) at exit1+0x4dc exit1(c2995870,d3ac8d04) at exit1 syscall(3b,3b,3b,0,bfbfec84,...) at syscall+0x2ae Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280eb413, esp = 0xbfbfe4fc, eb p = 0xbfbfe518 --- db> trace 946 Tracing pid 946 tid 100094 td 0xc31606c0 sched_switch(c31606c0,0,1) at sched_switch+0x157 mi_switch(1,0,c31606c0,d5c40994,c05517b2,...) at mi_switch+0x1d4 sleepq_switch(d5c409d8,c31606c0,d5c409b4,c0533c65,d5c409d8,...) at sleepq_switch +0x8a sleepq_timedwait(d5c409d8) at sleepq_timedwait+0x36 msleep(d5c409d8,c074f7c4,4c,c06e9aa6,64) at msleep+0x21d destroy_devl(c3264500,d5c40a18,c31edb35,c3264500,c2996dc0,...) at destroy_devl+0 x155 destroy_dev(c3264500,c2996dc0,c31ff180,c31606c0,c3239180,...) at destroy_dev+0x1 0 nsmb_dev_close(c3264500,3,2000,c31606c0) at nsmb_dev_close+0x69 giant_close(c3264500,3,2000,c31606c0) at giant_close+0x4b devfs_close(d5c40a80) at devfs_close+0x357 VOP_CLOSE_APV(c071c1c0,d5c40a80) at VOP_CLOSE_APV+0x38 vn_close(c323e000,3,c3239180,c31606c0) at vn_close+0x5a vn_closefile(c2a3be58,c31606c0,d5c40b38,c050d630,c2a3be58,...) at vn_closefile+0 xea devfs_close_f(c2a3be58,c31606c0) at devfs_close_f+0xf fdrop_locked(c2a3be58,c31606c0,c322ed00,d5c40bb8,c050bbaf,...) at fdrop_locked+0 xa8 fdrop(c2a3be58,c31606c0,d5c40b94,c058d3d9,0,...) at fdrop+0x41 closef(c2a3be58,c31606c0) at closef+0x41f fdfree(c31606c0) at fdfree+0x593 exit1(c31606c0,0,d5c40d30,c06a841e,c31606c0,...) at exit1+0x4dc exit1(c31606c0,d5c40d04) at exit1 syscall(3b,3b,3b,2805088c,bfbfeb20,...) at syscall+0x2ae Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280eb413, esp = 0xbfbfeaac, eb p = 0xbfbfeac8 --- db> cont [btr-nb butcher]> --------------050808010202030501040901-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 09:46:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B5CB16A49E for ; Mon, 23 Oct 2006 09:46:01 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E04B43D45 for ; Mon, 23 Oct 2006 09:45:59 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id k9N9jHXW031080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 12:45:37 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.8/8.13.8) with ESMTP id k9N9jnlx025248; Mon, 23 Oct 2006 12:45:52 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.8/8.13.8/Submit) id k9N9jhAL025247; Mon, 23 Oct 2006 12:45:43 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 23 Oct 2006 12:45:43 +0300 From: Giorgos Keramidas To: Philipp Ost Message-ID: <20061023094543.GA23628@gothmog.pc> References: <453922D2.7040309@smo.de> <20061021005229.GA62123@gothmog.pc> <453A04F9.4080909@smo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453A04F9.4080909@smo.de> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.56, required 5, AWL -0.16, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Can't install kernel with todays sources X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 09:46:01 -0000 On 2006-10-21 13:31, Philipp Ost wrote: > Giorgos Keramidas wrote: > >On 2006-10-20 21:26, Philipp Ost wrote: > > [error message snipped] > > > > >Are you absolutely sure a `buildkernel' with the same KERNCONF has > >completed successfully? > > Yes. That's odd. I just installed a custom (i.e. non-GENERIC) kernel from a CVS snapshot at 2006.10.23.03.33.27 and I don't see any problems here. From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 10:21:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6871F16A403 for ; Mon, 23 Oct 2006 10:21:35 +0000 (UTC) (envelope-from rainer.alves@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id E817643D45 for ; Mon, 23 Oct 2006 10:21:34 +0000 (GMT) (envelope-from rainer.alves@gmail.com) Received: by wx-out-0506.google.com with SMTP id t4so1554243wxc for ; Mon, 23 Oct 2006 03:21:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OfVQmZB3ZnyezsM3y88sTdmO0gjJ0gBK2iurZuwq7lnyeNto5GzsxKrOUAkqFAsFGg4DbF2/aNI1+IU04r7y03qudw6wW/idyRnF+sT4o/3VPa6b9+iwltHMvp7ZgETCZ35V863YPS0t4ySMoARSxNvPzlIz3DHsuDX5ITI7weo= Received: by 10.70.83.8 with SMTP id g8mr433292wxb; Mon, 23 Oct 2006 03:21:34 -0700 (PDT) Received: from ?127.0.0.1? ( [200.181.68.107]) by mx.google.com with ESMTP id h37sm1823032wxd.2006.10.23.03.21.33; Mon, 23 Oct 2006 03:21:34 -0700 (PDT) Message-ID: <453C9737.3000500@gmail.com> Date: Mon, 23 Oct 2006 07:19:35 -0300 From: Rainer Alves User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.7) Gecko/20061016 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <453C88FE.8010901@yandex.ru> In-Reply-To: <453C88FE.8010901@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 10:21:35 -0000 Andrey V. Elsukov wrote: > My system is CURRENT (~15.10.2006). > When I try mounting a smbfs from windows server then > mount_smbfs command is don't finished. And i can't > interrupt or kill these processes. Same symptoms here. But even though mount_smbfs never finishes, issuing a df/mount on a new terminal window shows that the samba filesystem is indeed mounted and usable. - Rainer From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 13:44:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1866E16A4F0; Mon, 23 Oct 2006 13:44:32 +0000 (UTC) (envelope-from fjoe@neo.samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED01F43D97; Mon, 23 Oct 2006 13:22:13 +0000 (GMT) (envelope-from fjoe@neo.samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 1000) id E605A170C5; Mon, 23 Oct 2006 20:22:04 +0700 (NOVST) Date: Mon, 23 Oct 2006 20:22:04 +0700 From: Max Khon To: Joerg Schilling Message-ID: <20061023132204.GB73780@samodelkin.net> References: <45223d3d.5Il+WW9HwkAuGvSH%Joerg.Schilling@fokus.fraunhofer.de> <4522AB6D.9050309@elischer.org> <4522aec5.4ZbRSHkZMuJ7r3BT%Joerg.Schilling@fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4522aec5.4ZbRSHkZMuJ7r3BT%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mutt/1.4.2i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, julian@elischer.org Subject: Re: Reliable hard links with mkisofs/ISO-9660/RR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 13:44:32 -0000 Hi! On Tue, Oct 03, 2006 at 08:41:09PM +0200, Joerg Schilling wrote: > > > I just started to implement a long planned extension to mkisofs > > > and Solaris hsfs that will allow hard links to work correctly. > > > > > > Is there any interest to also support this on FreeBSD? > > > > > > > Sorry to be obtuse, but if you write it in mkisofs then won't it > > automatically be supported > > on FreeBSD when we use mkisofs? > > > > Is it possible that you are asking about our kernel isofs support? > > FreeBSD currently seems to bascally implement the same fake inode algorithm > as SunOS does since ~ 1989. > > I did extend mkisofs during the past days and started to extend hsfs from > Solaris. Once I am ready, I could present the results in case there is someone > who is willing to work on the FreeBSD filesystem module, I could explain what > needs to be done. Please do. /fjoe From owner-freebsd-current@FreeBSD.ORG Sun Oct 22 08:13:25 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 760DB16A403; Sun, 22 Oct 2006 08:13:25 +0000 (UTC) (envelope-from damien.bergamini@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E8B343D45; Sun, 22 Oct 2006 08:13:24 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from COMETE (pas38-1-82-67-68-158.fbx.proxad.net [82.67.68.158]) by smtp2-g19.free.fr (Postfix) with SMTP id C905C759C7; Sun, 22 Oct 2006 10:13:23 +0200 (CEST) Message-ID: <00aa01c6f5b1$d8e8a6a0$0300a8c0@COMETE> From: "Damien Bergamini" To: "Jeremie Le Hen" , References: <20061021225146.GT53114@obiwan.tataz.chchile.org> Date: Sun, 22 Oct 2006 10:12:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailman-Approved-At: Mon, 23 Oct 2006 13:52:28 +0000 Cc: mlaier@FreeBSD.org Subject: Re: not enough rates in struct iwi_rateset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Oct 2006 08:13:25 -0000 Thanks a lot for pointing that out. I think the correct fix would be to copy only the minimum between 12 (sizeof rs.rsrates) and ni->ni_rates.rs_nrates. You can't just extend the size of the iwi_rateset structure which is a command sent to the firmware (I double-checked in the Intel Linux driver and they also use a structure with 12 (IPW_MAX_RATES) rates). I wonder how ni->ni_rates.rs_nrates can be greater than 12 though since we only have 12 rates max in ic->ic_sup_rates[] and the rate set is supposed to be negotiated at that point which means that any rate that we don't support should have been removed from ni->ni_rates.rs_rates[]. If you could show the content of ni->ni_rates.rs_rates[], that might help. Regards, Damien | Hi, | | I have compiled my kernel with ProPolice and if_iwi happened to | trigger the stack smashing protector, which means there has been | a buffer overflow in a buffer allocated in the stack. | | The buffer overflow occurs in iwi_auth_and_assoc(), and the only | buffer in this function is in struct iwi_rateset, which can | handle 12 rates, however according to kgdb ni->ni_rates.rs_nrates | has a value of 13. | | I am not confident with the net80211 code, but a quick glance at | sys/net80211/_ieee80211.h shows that there may be up to 15 rates. | Therefore I bumped up the number of rates in iwi_rateset to 15 | and there is no buffer overflow anymore, though I don't know if | this is the correct fix. | | Best regards, | -- | Jeremie Le Hen | < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 21:07:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8739E16A407; Mon, 23 Oct 2006 21:07:07 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E24543D60; Mon, 23 Oct 2006 21:07:03 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gc70g-0008M6-Uw; Mon, 23 Oct 2006 22:07:02 +0100 Date: Mon, 23 Oct 2006 22:07:02 +0100 From: Ceri Davies To: Brad Davis Message-ID: <20061023210702.GA30631@submonkey.net> Mail-Followup-To: Ceri Davies , Brad Davis , current@freebsd.org References: <20061018113518.GF92966@submonkey.net> <35ffa5710610201259g11c534f1g60a9f28143bff65b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <35ffa5710610201259g11c534f1g60a9f28143bff65b@mail.gmail.com> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: current@freebsd.org Subject: Re: What to do with quotacheck -l2 ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 21:07:07 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2006 at 01:59:45PM -0600, Brad Davis wrote: > On 10/18/06, Ceri Davies wrote: > >I found a -l option in quotacheck this morning, which has been there > >since revision 1.1 and never documented. The option controls the > >maximum number of concurrent filesystems that quotacheck will operate > >on during the second pass, and should almost certainly be documented. > > > >The -l option is ignored without -a, and using it without -a should > >result in some kind of warning. However, this behaviour has been > >unchanged for the entire lifetime of quotacheck in FreeBSD and I'm > >loathe to break anything, so I turn to you to see if this looks OK. >=20 > Hi Ceri, >=20 > Only comment is this: >=20 > + /* Setting maxrun (-l) makes no sense without the aflag, but >=20 > Should that be something like: >=20 > /* Setting maxrun (-l) makes no sense without the -a flag, but Sounds a bit more clear/exact, I suppose. I'll change it. If there are no other comments then I'll commit in the next couple of days. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPS72ocfcwTS3JF8RAt0/AKCk4CNv/mi9vKBeGv1Vs7v1A9K2XwCgjIDu uJ1sCSiHKSmcA8WmTtQ/Gp8= =H1hp -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 23 23:02:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F3D216A40F; Mon, 23 Oct 2006 23:02:27 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [193.85.228.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F215643D7E; Mon, 23 Oct 2006 23:02:16 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [193.85.228.22]) by nxm.secservers.com (8.13.4/8.13.4) with ESMTP id k9NN2BJ9071009; Tue, 24 Oct 2006 01:02:14 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: "Andrey V. Elsukov" In-Reply-To: <453C88FE.8010901@yandex.ru> References: <453C88FE.8010901@yandex.ru> Content-Type: text/plain Date: Tue, 24 Oct 2006 01:02:08 +0200 Message-Id: <1161644528.1054.76.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current , kib@freebsd.org Subject: Re: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2006 23:02:27 -0000 Andrey V. Elsukov wrote: > Hi, > > My system is CURRENT (~15.10.2006). > When I try mounting a smbfs from windows server then > mount_smbfs command is don't finished. And i can't > interrupt or kill these processes. > > ps, top and trace output from ddb attached. > last pid: 2146; load averages: 0.00, 0.00, 0.00 up 0+05:28:50 13:07:20 > 32 processes: 1 running, 31 sleeping > CPU states: % user, % nice, % system, % interrupt, % idle > Mem: 25M Active, 269M Inact, 73M Wired, 23M Cache, 53M Buf, 36M Free > Swap: 1024M Total, 16K Used, 1024M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 859 root 1 -8 0 6120K 1528K devdrn 0:00 0.00% mount_smbfs > 946 root 1 -8 0 6120K 1000K devdrn 0:00 0.00% mount_smbfs > Probably unrelated... Do you run with the alternative pseudo-terminal implementation (kern.pts.enable=1)? A situation like this - something stuck in devdrn, has been reported before. The problem reported was with portupgrade and xterm (gnome-terminal) being stuck (on exit?). I had the problem too until I switched back to the default ptys. CCing: kib@ who I believe has been around the changes before the first report. Michal From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 01:51:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 532F916A417 for ; Tue, 24 Oct 2006 01:51:01 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38F9A43D66 for ; Tue, 24 Oct 2006 01:50:58 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so25985nfc for ; Mon, 23 Oct 2006 18:50:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P9J/UOqQAl48NErkhy6OxEnqn9xbHeDJCgzdYlCPH1wlipnvSft7tj9xP4Z2fixFTK8mezJdQgR4G5BWc3G7HKVUNCB+AxzFX1tmlVEByHlSA+TnToG4glUuHUu15WOYWPLl4v/A6MnDgq8zSZwch6EDxcaO6Eae75reCHdL0eI= Received: by 10.49.75.2 with SMTP id c2mr169167nfl; Mon, 23 Oct 2006 18:50:56 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Mon, 23 Oct 2006 18:50:56 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 09:50:56 +0800 From: "Jiawei Ye" To: "Ion-Mihai IOnut Tetcu" In-Reply-To: <20061023022928.35b7b23c@it.buh.tecnik93.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> Cc: Doug Barton , UMEMOTO , "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Hajimu@freebsd.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 01:51:01 -0000 T24gMTAvMjMvMDYsIElvbi1NaWhhaSBJT251dCBUZXRjdSA8aXRldGN1QGZyZWVic2Qub3JnPiB3 cm90ZToKPiBPbiBTdW4sIDIyIE9jdCAyMDA2IDE2OjE4OjAyIC0wNzAwCj4gRG91ZyBCYXJ0b24g PGRvdWdiQEZyZWVCU0Qub3JnPiB3cm90ZToKPgo+ID4gQW5keSBGYXdjZXR0IHdyb3RlOgo+ID4K PiA+ID4gSSdtIG9ubHkgc2VlaW5nIHRoaXMgZWZmZWN0IChvciBtYXliZSBvbmx5IG5vdGljaW5n IGl0KSB3aXRoCj4gPiA+IGNzdXAvY3ZzdXAuIENvdWxkIGJlIGNvaW5jaWRlbmNlIHRob3VnaC4K PiA+Cj4gPiBIcnJtLCBpdCdzIG9kZCB0aGF0IGl0IGFmZmVjdHMgYm90aCBjc3VwIF9hbmRfIGN2 c3VwLCBzaW5jZSB0aGUKPiA+IGZvcm1lciBpcyB3cml0dGVuIGluIEMsIGFuZCBsaW5rcyBuYXRp dmVseSBhZ2FpbnN0IG91ciBsaWJyYXJpZXMuIEknbQo+ID4gd29uZGVyaW5nIGlmIHdlJ3JlIHNl ZWluZyBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgbmFtZSBzZXJ2ZXJzIHRoYXQKPiA+IHRob3NlIGhv c3RuYW1lcyBhcmUgZGVsZWdhdGVkIHRvIGFyZSBqdXN0IHRha2luZyBhIGxvbmcgdGltZSB0bwo+ ID4gcmVzcG9uZCwgYW5kIG5laXRoZXIgYXBwIGlzIHBhdGllbnQgZW5vdWdoLiBJIHRoaW5rIGl0 IHdvdWxkIGJlIGFuCj4gPiBpbnRlcmVzdGluZyBleHBlcmltZW50IHRvIHNlZSB3aGF0IGhhcHBl bnMgaWYgeW91IGluY3JlYXNlIHRoZSByZXRyeQo+ID4gdGltZW91dC4KPiA+Cj4gPiBJcyBhbnlv bmUgZWxzZSBzZWVpbmcgdGhpcyBwcm9ibGVtIHdpdGggb3RoZXIgYXBwbGljYXRpb25zPyBTaW1v biwKPiA+IEknbGwgYWRkcmVzcyB5b3VyIHByb2JsZW1zIHdpdGggaG9zdCgxKSBpbiBhIHNlcGFy YXRlIG1haWwuCj4KPiBJJ20gc2VlaW5nIGl0IHdpdGggc3F1aWQuCj4KPgo+IC0tCj4gSU9udXQg LSBVbl5kXmRyZWdpc3RlcmVkIDspIEZyZWVCU0QgInVzZXIiCj4gICAiSW50ZWxsZWN0dWFsIFBy b3BlcnR5IiBpcyAgIG5vd2hlcmUgbmVhciBhcyB2YWx1YWJsZSAgIGFzICJJbnRlbGxlY3QiCj4K PiBCT0ZIIGV4Y3VzZSAjMjEyOgo+IE9mIGNvdXJzZSBpdCBkb2Vzbid0IHdvcmssIHdlJ3ZlIHBl cmZvcm1lZCBhIHNvZnR3YXJlIHVwZ3JhZGUKPgo+Cj4KPgpJIGFtIHN0aWxsIHNlZWluZyB0aGlz IG9uIGEgZmFpcmx5IHJlY2VudCAtY3VycmVudAoKWyBsZWFmeUBzaC1tYWlsIH5dICQgdGFpbCAt ZiB1cGRhdGUubG9nCjIwMDblubQxMOaciDI05pelIOWRqOS6jCAwOeaZgjQ45YiGNTHnp5IgQ1NU Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4+PiBSdW5uaW5nIC91c3IvYmluL2NzdXAKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KTmFtZSBsb29rdXAgZmFpbHVy ZSBmb3IgImN2c3VwMTIuRnJlZUJTRC5vcmciOiBOb24tcmVjb3ZlcmFibGUgZmFpbHVyZQppbiBu YW1lIHJlc29sdXRpb24KV2lsbCByZXRyeSBhdCAwOTo1NDoxNwoKVGhlIHNlY29uZCB0cnkgc3Vj Y2VlZHMuCgpKaWF3ZWkgWWUKCgotLSAKIklmIGl0IGxvb2tzIGxpa2UgYSBkdWNrLCB3YWxrcyBs aWtlIGEgZHVjaywgYW5kIHF1YWNrcyBsaWtlIGEgZHVjaywKdGhlbiB0byB0aGUgZW5kIHVzZXIg aXQncyBhIGR1Y2ssIGFuZCBlbmQgdXNlcnMgaGF2ZSBtYWRlIGl0IHByZXR0eQpjbGVhciB0aGV5 IHdhbnQgYSBkdWNrOyB3aGV0aGVyIHRoZSBkdWNrIGRyaW5rcyBob3QgY2hvY29sYXRlIG9yCmNv ZmZlZSBpcyBpcnJlbGV2YW50LiIK From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 02:19:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E77B16A407; Tue, 24 Oct 2006 02:19:25 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADE8A43D58; Tue, 24 Oct 2006 02:19:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8DDFC1A3C1E; Mon, 23 Oct 2006 19:19:24 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DF57A513AD; Mon, 23 Oct 2006 22:19:21 -0400 (EDT) Date: Mon, 23 Oct 2006 22:19:20 -0400 From: Kris Kennaway To: Jiawei Ye Message-ID: <20061024021919.GA74370@xor.obsecurity.org> References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Doug Barton , UMEMOTO , "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu , Hajimu@freebsd.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 02:19:25 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 24, 2006 at 09:50:56AM +0800, Jiawei Ye wrote: > I am still seeing this on a fairly recent -current With the patch applied? Kris --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPXgnWry0BWjoQKURArEjAJ94zViVmvAIlvdmSde5imYWDZ3KWACfTjO+ 9EjsWm4c98zq6dGLRAU3hRI= =00gB -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 02:24:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F32F116A417 for ; Tue, 24 Oct 2006 02:24:18 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id D45B543D5D for ; Tue, 24 Oct 2006 02:24:15 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so35110nfc for ; Mon, 23 Oct 2006 19:24:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GwBw9z7PBUP0EcRSLHESTKPUUJZOe4/aFzRmyoI9+iBNBIPmU79R8PcBX568VZiTX955+bVXi6j/IwMUn2nu7LYNrZlQLvbv5NIxGr3fCSSeZuEVwsZ+6ZD1xT28QaIH7gLR2OFvTzUFWpEw5N5SvwLR3bZa5QIeTQJ/RG2geoQ= Received: by 10.49.90.18 with SMTP id s18mr176116nfl; Mon, 23 Oct 2006 19:24:14 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Mon, 23 Oct 2006 19:24:14 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 10:24:14 +0800 From: "Jiawei Ye" To: "Kris Kennaway" In-Reply-To: <20061024021919.GA74370@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> <20061024021919.GA74370@xor.obsecurity.org> Cc: Doug Barton , UMEMOTO , "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu , Hajimu@freebsd.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 02:24:19 -0000 On 10/24/06, Kris Kennaway wrote: > On Tue, Oct 24, 2006 at 09:50:56AM +0800, Jiawei Ye wrote: > > > I am still seeing this on a fairly recent -current > > With the patch applied? > > Kris With "options attempts:4" in resolv.conf Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 02:27:03 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9416E16A415; Tue, 24 Oct 2006 02:27:03 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A09B343D55; Tue, 24 Oct 2006 02:26:59 +0000 (GMT) (envelope-from conrads@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20061024022701.HXS13289.eastrmmtao01.cox.net@eastrmimpo02.cox.net>; Mon, 23 Oct 2006 22:27:01 -0400 Received: from serene.no-ip.org ([72.200.30.62]) by eastrmimpo02.cox.net with bizsmtp id e2Rh1V00S1LR1K40000000 Mon, 23 Oct 2006 22:26:19 -0400 Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.13.8/8.13.8) with ESMTP id k9O2Q0jG027333; Mon, 23 Oct 2006 21:26:01 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 23 Oct 2006 21:25:54 -0500 From: "Conrad J. Sabatier" To: Andreas Klemm Message-ID: <20061023212554.00062ff5@serene.no-ip.org> In-Reply-To: <20061023061539.GA17549@titan.klemm.apsfilter.org> References: <20061023061539.GA17549@titan.klemm.apsfilter.org> Organization: A Rag-Tag Band of Drug-Crazed Hippies X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; amd64-unknown-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 02:27:03 -0000 On Mon, 23 Oct 2006 08:15:39 +0200, Andreas Klemm wrote: > Hi, > > I installed the latest amd64 -current snap from server (oct 2006). > I installed only a "handfull" of ports to get xfce4 running. > > Then later I installed portupgrade and did a portupgrade -a. > > Some ports got upgraded, and then it hung at the configure > stage of some ports. > > Funny thing is, building such a port manually by > cd /usr/ports/xxx/yyy; make all install clean > works. No problem with configure. > > Only portupgrade wasn't able to upgrade these ports. > > Is this a known -current problem or do I have to investigate more > into this ? Or is it a special "portupgrade" problem in conjunction > with only autoconf based ports ? > > If you need more data then tell, unluckily it got late yesterday > evening, so I would provide "real info" later if you need. > > Andreas /// Not sure what's causing this, but I'm seeing the "script" child processes spawned by portupgrade consuming an inordinate amount of CPU, as much as 80+%. This does make the configure stage appear to hang interminably much of the time. This is under 7.0-CURRENT/amd64 with both portupgrade and portupgrade-devel. It's gotten so bad, in fact, that I find myself more and more resorting to manually upgrading ports, which works fine and does not hog CPU at all. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 03:32:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA6216A40F for ; Tue, 24 Oct 2006 03:32:08 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B2D843D46 for ; Tue, 24 Oct 2006 03:32:06 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so53208nfc for ; Mon, 23 Oct 2006 20:32:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IK4GgYrZua6v6n8rLFz7guQJTXE7snv6T+ikUXmLba/ls8oXm3ZdPyZthssvRaRQ6p6XJwjiwEhMjfYbbHZycscx/CltXkhTUE23HFEvqN7ok2JvakGz92R9yAUg7haZ6YxUQ8KySYAsGZoPEIgmNjCM0ksEyODyDMOMrlXLprE= Received: by 10.48.254.10 with SMTP id b10mr281173nfi; Mon, 23 Oct 2006 20:32:05 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Mon, 23 Oct 2006 20:32:05 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 11:32:05 +0800 From: "Jiawei Ye" To: "Michal Mertl" In-Reply-To: <1161644528.1054.76.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453C88FE.8010901@yandex.ru> <1161644528.1054.76.camel@genius.i.cz> Cc: "Andrey V. Elsukov" , kib@freebsd.org, freebsd-current Subject: Re: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 03:32:08 -0000 On 10/24/06, Michal Mertl wrote: > Probably unrelated... > > Do you run with the alternative pseudo-terminal implementation > (kern.pts.enable=1)? > > A situation like this - something stuck in devdrn, has been reported > before. The problem reported was with portupgrade and xterm > (gnome-terminal) being stuck (on exit?). I had the problem too until I > switched back to the default ptys. > > CCing: kib@ who I believe has been around the changes before the first > report. > > Michal I am seeing the same thing with [ leafy@sh-mail tmp] $ sysctl kern.pts kern.pts.enable: 0 The process is stuck in DE+ state. Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 04:49:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D81216A492 for ; Tue, 24 Oct 2006 04:49:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id B950B43D6B for ; Tue, 24 Oct 2006 04:49:02 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 32254 invoked by uid 399); 24 Oct 2006 04:49:02 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 24 Oct 2006 04:49:02 -0000 Message-ID: <453D9B3B.5090000@FreeBSD.org> Date: Mon, 23 Oct 2006 21:48:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jiawei Ye References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> <20061024021919.GA74370@xor.obsecurity.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: UMEMOTO , Kris Kennaway , "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu , Hajimu@freebsd.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 04:49:05 -0000 Jiawei Ye wrote: > On 10/24/06, Kris Kennaway wrote: >> On Tue, Oct 24, 2006 at 09:50:56AM +0800, Jiawei Ye wrote: >> >> > I am still seeing this on a fairly recent -current >> >> With the patch applied? >> >> Kris > With "options attempts:4" in resolv.conf Try applying the patch, and commenting out the options line. The patch fixes things in what should be a more robust way. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 07:12:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6647A16A417; Tue, 24 Oct 2006 07:12:12 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58FD543D67; Tue, 24 Oct 2006 07:12:07 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k9O7C2Q4028618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Oct 2006 09:12:02 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20061023212554.00062ff5@serene.no-ip.org> References: <20061023061539.GA17549@titan.klemm.apsfilter.org> <20061023212554.00062ff5@serene.no-ip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 24 Oct 2006 09:12:01 +0200 To: "Conrad J. Sabatier" X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org Subject: Re: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 07:12:12 -0000 Am 24.10.2006 um 04:25 schrieb Conrad J. Sabatier: > Not sure what's causing this, but I'm seeing the "script" child > processes spawned by portupgrade consuming an inordinate amount of > CPU, > as much as 80+%. This does make the configure stage appear to hang > interminably much of the time. I do get this when the port uses options (or otherwise invokes dialog (1)), and portupgrade is not on a terminal. On a number of machines, I update ports by a cron job, so I define - DBATCH in pkgtools.conf for all ports. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 09:52:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81F5516A416 for ; Tue, 24 Oct 2006 09:52:20 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AA443D5D for ; Tue, 24 Oct 2006 09:52:19 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1292516uge for ; Tue, 24 Oct 2006 02:52:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=c1A+axoHgD68FhENV82Oo3IOeFuuaiku7XWmm0nYDOPNSKL/GZ4mfFBTArmLNHAyhIH6NfstmOYLwAFhmz+K5W1BoeiMYtUcFDwYzlHYS5iqxmDEMMNwZORbuwplborrC7ZIxPSYGryAxReERPaWjpMxlyavuT4j4ur1ku2g7cA= Received: by 10.67.119.5 with SMTP id w5mr8508220ugm; Tue, 24 Oct 2006 02:52:18 -0700 (PDT) Received: by 10.66.237.14 with HTTP; Tue, 24 Oct 2006 02:52:18 -0700 (PDT) Message-ID: <755cb9fc0610240252x5746deb5q54dfda68c478232a@mail.gmail.com> Date: Tue, 24 Oct 2006 10:52:18 +0100 From: "Alexandre Vieira" To: "Josh Paetzel" , freebsd-questions@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <200610232029.28581.josh@tcbug.org> MIME-Version: 1.0 References: <755cb9fc0610230745h3e3aa0d8y920d07e90d43eee6@mail.gmail.com> <1161618250.13630.40.camel@buffy.york.ac.uk> <755cb9fc0610230914h16a639f5l6b491b0da9798945@mail.gmail.com> <200610232029.28581.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: SunFire V210/V240 (UltraSparc IIIi) and FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 09:52:20 -0000 On 10/24/06, Josh Paetzel wrote: > > On Monday 23 October 2006 11:14, Alexandre Vieira wrote: > > > > > Hello, > > > > I'm unable to boot 6.2-BETA2 on a SunFire V210. It stalls in the > > start of kernel boot: > > > > Right. It has an UltraSparc III CPU which just isn't supported. > > -- > Thanks, > > Josh Paetzel > I am aware that this CPI isn't supported, you can read the initial post. Thing is, there are several reports of successfull boots with this specific machine and since i'm a curious guy I would like to ride freebsd with one of these. cheers -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 09:56:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 457F816A403 for ; Tue, 24 Oct 2006 09:56:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E27943D46 for ; Tue, 24 Oct 2006 09:56:09 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k9O9cXGo044205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 12:38:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k9O9u4td069465; Tue, 24 Oct 2006 12:56:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k9O9u3Bp069464; Tue, 24 Oct 2006 12:56:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Oct 2006 12:56:03 +0300 From: Kostik Belousov To: Michal Mertl Message-ID: <20061024095603.GH45605@deviant.kiev.zoral.com.ua> References: <453C88FE.8010901@yandex.ru> <1161644528.1054.76.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: <1161644528.1054.76.camel@genius.i.cz> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: "Andrey V. Elsukov" , freebsd-current Subject: Re: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 09:56:10 -0000 --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 01:02:08AM +0200, Michal Mertl wrote: > Andrey V. Elsukov wrote: > > Hi, > >=20 > > My system is CURRENT (~15.10.2006). > > When I try mounting a smbfs from windows server then > > mount_smbfs command is don't finished. And i can't > > interrupt or kill these processes. > >=20 > > ps, top and trace output from ddb attached. >=20 > > last pid: 2146; load averages: 0.00, 0.00, 0.00 up 0+05:28:50 = 13:07:20 > > 32 processes: 1 running, 31 sleeping > > CPU states: % user, % nice, % system, % interrupt, = % idle > > Mem: 25M Active, 269M Inact, 73M Wired, 23M Cache, 53M Buf, 36M Free > > Swap: 1024M Total, 16K Used, 1024M Free > > =20 > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > > 859 root 1 -8 0 6120K 1528K devdrn 0:00 0.00% mount= _smbfs > > 946 root 1 -8 0 6120K 1000K devdrn 0:00 0.00% mount= _smbfs > >=20 >=20 >=20 > Probably unrelated... >=20 > Do you run with the alternative pseudo-terminal implementation > (kern.pts.enable=3D1)? >=20 > A situation like this - something stuck in devdrn, has been reported > before. The problem reported was with portupgrade and xterm > (gnome-terminal) being stuck (on exit?). I had the problem too until I > switched back to the default ptys. >=20 > CCing: kib@ who I believe has been around the changes before the first > report. The "devdrn" state was introduced by Tor Egge commit into sys/kern/kern_con= f.c, rev. 1.199. It prevents access to the freed kernel memory. Basically, some thread has declared use of the cdev, and thread that executing destroy_devl= () waits until all cdev users release it. Tty subsystem has problems with locking/reference counting. (At least) workarounds for them are under development now. In your case, smb_dev calls destroy_dev() from the d_close() routine. Since devfs_close() takes the thread reference on the device, that causes deadlock. --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPeMsC3+MBN1Mb4gRAhORAKDoyEGqF/tAcycaEns/lm1VgGYpBgCeJs/D fFPBcl7URxDcBMfoS67Z65w= =Tfir -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 10:05:59 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4954E16A407; Tue, 24 Oct 2006 10:05:59 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC60743D5A; Tue, 24 Oct 2006 10:05:58 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 023DF27642; Tue, 24 Oct 2006 12:05:58 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id A16999E6C2; Tue, 24 Oct 2006 10:06:41 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 841B0405B; Tue, 24 Oct 2006 12:06:41 +0200 (CEST) Date: Tue, 24 Oct 2006 12:06:41 +0200 From: Jeremie Le Hen To: Julian Elischer Message-ID: <20061024100641.GB20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-small@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 10:05:59 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Julian, (Sorry for cross-posting, but I haven't been able to make my mind.) I've created a small patch for tinybsd that allows to add files that do not come from the base system (I needed ${LOCALBASE}/sbin/hping). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tinybsd_nonstddirs.patch" Index: tinybsd =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/tinybsd,v retrieving revision 1.4 diff -u -r1.4 tinybsd --- tinybsd 11 Oct 2006 21:46:53 -0000 1.4 +++ tinybsd 24 Oct 2006 09:58:21 -0000 @@ -260,6 +260,15 @@ mtree -deU -f /etc/mtree/BSD.root.dist -p ${WORKDIR} mtree -deU -f /etc/mtree/BSD.usr.dist -p ${WORKDIR}/usr mtree -deU -f /etc/mtree/BSD.var.dist -p ${WORKDIR}/var + + for file in `cat ${CURRENTDIR}/conf/${CONF}/tinybsd.basefiles | grep -v "#" | \ + cut -f1 -d":" | sort | uniq` ; do + dir=`dirname ${file}` + if [ ! -d $WORKDIR/$dir ]; then + echo "Non-standard directory created: $dir." + mkdir -p $WORKDIR/$dir + fi + done } --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 11:18:40 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B50C116A416 for ; Tue, 24 Oct 2006 11:18:40 +0000 (UTC) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id ED93543D53 for ; Tue, 24 Oct 2006 11:18:37 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 9825 invoked by uid 0); 24 Oct 2006 09:18:53 -0200 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.149.10):. Processed in 0.523897 secs); 24 Oct 2006 11:18:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=capeta; d=freebsdbrasil.com.br; b=dfLYPJUw408H17//GyaLPDECXWa9QgxFHrzB4T19No9axdm3XfLQwVp/elLbggZZQscY7amwnUW/Dg+fJmsnUdLC47Yghh1cZcui5qhIYEepffVq0ZKkJh+x6r1YLVSG ; Received: from unknown (HELO ?10.69.69.66?) (jmelo@201.17.149.10) by capeta.freebsdbrasil.com.br with SMTP; 24 Oct 2006 09:18:52 -0200 Message-ID: <453DE863.7070305@freebsdbrasil.com.br> Date: Tue, 24 Oct 2006 08:18:11 -0200 From: Jean Milanez Melo User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061024100641.GB20405@obiwan.tataz.chchile.org> In-Reply-To: <20061024100641.GB20405@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 11:18:40 -0000 Jeremie Le Hen wrote: > Hi Julian, > > (Sorry for cross-posting, but I haven't been able to make my mind.) > > I've created a small patch for tinybsd that allows to add files that do not > come from the base system (I needed ${LOCALBASE}/sbin/hping). > > Regards, > > > ------------------------------------------------------------------------ > > Index: tinybsd > =================================================================== > RCS file: /home/ncvs/src/tools/tools/tinybsd/tinybsd,v > retrieving revision 1.4 > diff -u -r1.4 tinybsd > --- tinybsd 11 Oct 2006 21:46:53 -0000 1.4 > +++ tinybsd 24 Oct 2006 09:58:21 -0000 > @@ -260,6 +260,15 @@ > mtree -deU -f /etc/mtree/BSD.root.dist -p ${WORKDIR} > mtree -deU -f /etc/mtree/BSD.usr.dist -p ${WORKDIR}/usr > mtree -deU -f /etc/mtree/BSD.var.dist -p ${WORKDIR}/var > + > + for file in `cat ${CURRENTDIR}/conf/${CONF}/tinybsd.basefiles | grep -v "#" | \ > + cut -f1 -d":" | sort | uniq` ; do > + dir=`dirname ${file}` > + if [ ! -d $WORKDIR/$dir ]; then > + echo "Non-standard directory created: $dir." > + mkdir -p $WORKDIR/$dir > + fi > + done > } > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" Maybe it's not the better way to do this. I'm thinking a way to add third applications on tinybsd, so when this feature is done the directories will be automatically created. Thanks Jean From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 11:56:42 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1741A16A412; Tue, 24 Oct 2006 11:56:42 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 875AE43D69; Tue, 24 Oct 2006 11:56:41 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 5C9608ADA; Tue, 24 Oct 2006 13:56:40 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 94A099E6C2; Tue, 24 Oct 2006 11:57:27 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 81D2F405D; Tue, 24 Oct 2006 13:57:27 +0200 (CEST) Date: Tue, 24 Oct 2006 13:57:27 +0200 From: Jeremie Le Hen To: Jean Milanez Melo Message-ID: <20061024115727.GD20405@obiwan.tataz.chchile.org> References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453DE863.7070305@freebsdbrasil.com.br> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-small@FreeBSD.org, freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 11:56:42 -0000 Hi Jean, On Tue, Oct 24, 2006 at 08:18:11AM -0200, Jean Milanez Melo wrote: > Maybe it's not the better way to do this. I'm thinking a way to add > third applications on tinybsd, so when this feature is done the > directories will be automatically created. Actually I tried to make it straightforward, in the manner of the whole script. I daresay it is quite pleasant to have a simple script without too much magic in it, it is far more quicker to apprehend. What are you thinking about for inclusion of third-party apps on tinybsd ? I hope it won't bloat too much the code. Are you already expecting to provide it soon ? Thank you for your work, it is greatly appreciated. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 11:49:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C63A316A500; Tue, 24 Oct 2006 11:49:12 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F4C543D45; Tue, 24 Oct 2006 11:49:12 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id k9OBnBOd055700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 07:49:11 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id k9OBnBXR055699; Tue, 24 Oct 2006 07:49:11 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Andrey Chernov Date: Tue, 24 Oct 2006 07:49:10 -0400 User-Agent: KMail/1.9.1 References: <200609202304.25537@aldan> <200609261302.40964.mi+mx@aldan.algebra.com> <20060926184447.GA17862@nagual.pp.ru> In-Reply-To: <20060926184447.GA17862@nagual.pp.ru> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Tue, 24 Oct 2006 12:37:27 +0000 Cc: Mikhail Teterin , current@freebsd.org, tjr@freebsd.org Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 11:49:12 -0000 On Tuesday 26 September 2006 14:44, Andrey Chernov wrote: = On Tue, Sep 26, 2006 at 01:02:40PM -0400, Mikhail Teterin wrote: = > Any news on this? = = I basically look at locale stuff, they sypport multibyte which is good. = = Someone must test its compatibility with GNU regex and understand in = details nature of their changes/fixes/differences. Without this work we = can't blindly replace stable code with unknown one just for reason it is = actively maintained. What kind of test would be deemed sufficient? -mi = > > On Wed, Sep 20, 2006 at 11:04:24PM -0400, Mikhail Teterin wrote: = > > > A recent discussion on the gm4 and gnulib mailing lists over the = > > > merits of gm4's bundling of its own regex implementation has produced = > > > the suggestion, that we replace our src/gnu/lib/libregex (which is = > > > currently obtained from fedora-glibc-2_3_4-21) with gnulib's = > > > implementation. = > > > = > > > The latter is claimed to be more actively maintained and with more bug = > > > fixes, than glibc people have managed to incorporate. = > > > = > > > Does anyone have a strong preference for fedora/glibc implementation = > > > currently in use, or should we follow this advice (source -- regex' = > > > maintainer for gnulib -- CC-ed) and switch over? = > > = > > Please point to gnulib's regex sources to compare with. = = = -- = http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 12:38:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13E7816A403; Tue, 24 Oct 2006 12:38:46 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E7A243D6D; Tue, 24 Oct 2006 12:38:45 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id AC72E4859A; Tue, 24 Oct 2006 14:38:44 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 9FD169E6C5; Tue, 24 Oct 2006 12:39:31 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 8CE71405D; Tue, 24 Oct 2006 14:39:31 +0200 (CEST) Date: Tue, 24 Oct 2006 14:39:31 +0200 From: Jeremie Le Hen To: Julian Elischer , Jean Milanez Melo Message-ID: <20061024123931.GF20405@obiwan.tataz.chchile.org> References: <20061024100641.GB20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline In-Reply-To: <20061024100641.GB20405@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 12:38:46 -0000 --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, this next patch knows how to handle image file specified with an absolute path. Moreover if the creation of the final image has failed, the temporary "vnode file" is left for the user. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tinybsd_absolutepath.patch" Index: tinybsd =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/tinybsd,v retrieving revision 1.4 diff -u -p -r1.4 tinybsd --- tinybsd 11 Oct 2006 21:46:53 -0000 1.4 +++ tinybsd 24 Oct 2006 12:34:19 -0000 @@ -422,17 +431,29 @@ create_image() { sleep 1 umount ${IMGMNT} - dd if=/dev/${MD} of=${CURRENTDIR}/${IMG} bs=64k + case ${IMG} in + /*) dd if=/dev/${MD} of=${IMG} bs=64k ;; + *) dd if=/dev/${MD} of=${CURRENTDIR}/${IMG} bs=64k ;; + esac + DD_RET=$? - rm -vf ${VNODEFILE} rm -rvf ${IMGMNT} mdconfig -d -u ${MD} - echo "" - echo "${TS} Done!" - echo "${TS} Your configuration options were saved in ${FULLFILENAME}" - echo "${TS} You can see your build log in ${HOME}/tinybsd.log" - echo "${TS} Your final image is in ${CURRENTDIR}/${IMG}" - echo "${TS} Now use dd(1) to write it." + + if [ $DD_RET -eq 0 ]; then + rm -vf ${VNODEFILE} + echo "" + echo "${TS} Done!" + echo "${TS} Your configuration options were saved in ${FULLFILENAME}" + echo "${TS} You can see your build log in ${HOME}/tinybsd.log" + echo "${TS} Your final image is in ${CURRENTDIR}/${IMG}" + echo "${TS} Now use dd(1) to write it." + else + echo "" >&2 + echo "${TS} Failed to create ${CURRENTDIR}/${IMG}!" >&2 + echo "${TS} You can see your build log in ${HOME}/tinybsd.log" >&2 + echo "${TS} The temporary image is still in ${VNODEFILE}" >&2 + fi } --0ntfKIWw70PvrIHh-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 13:41:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4FCD16A417 for ; Tue, 24 Oct 2006 13:41:52 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC1A43D76 for ; Tue, 24 Oct 2006 13:41:45 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1334563uge for ; Tue, 24 Oct 2006 06:41:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=StYrQ9r1fQGakOhtQQrVk4S/ZDWA/xSLDps50ciiA9Ql0FZngOHiWmrfNqKWkysMvhU0MbDHY2dXht5GgAoAlvsBdQyxGqQjB1TwLbpKzOSEStYnjNiufFlcn8CBqKsMmX+PPXvu+WRdwfmKqX0BDP3fE8sJK18h6m4H7ypC57s= Received: by 10.67.24.13 with SMTP id b13mr8833730ugj; Tue, 24 Oct 2006 06:41:44 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Tue, 24 Oct 2006 06:41:44 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 21:41:44 +0800 From: "Jiawei Ye" To: "Doug Barton" In-Reply-To: <453D9B3B.5090000@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> <20061024021919.GA74370@xor.obsecurity.org> <453D9B3B.5090000@FreeBSD.org> Cc: UMEMOTO , Kris Kennaway , "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu , Hajimu@freebsd.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 13:41:52 -0000 On 10/24/06, Doug Barton wrote: > > Try applying the patch, and commenting out the options line. The patch > fixes things in what should be a more robust way. > > Doug > > -- > > This .signature sanitized for your protection This is much better. It would be great if this is commited. Thanks, Jiawei Ye -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 15:15:18 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9992016A4AB for ; Tue, 24 Oct 2006 15:15:18 +0000 (UTC) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B5FC43E01 for ; Tue, 24 Oct 2006 15:14:51 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 25503 invoked by uid 0); 24 Oct 2006 13:15:01 -0200 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.149.10):. Processed in 0.5198 secs); 24 Oct 2006 15:15:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=capeta; d=freebsdbrasil.com.br; b=cFLmhq916G52Ce42WIw5F7cimWZ+JA5tsQfQwEUvOPmrKs5v54S3PNWHgmbiEFDbrbQlJWpseXTXFfMYJcm352QQ57NFVEc7I9T4m0Aft0XC/rXU7HR3px3eklmKPHo2 ; Received: from unknown (HELO ?10.69.69.66?) (jmelo@201.17.149.10) by capeta.freebsdbrasil.com.br with SMTP; 24 Oct 2006 13:15:01 -0200 Message-ID: <453E1FBC.5060700@freebsdbrasil.com.br> Date: Tue, 24 Oct 2006 12:14:20 -0200 From: Jean Milanez Melo User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> In-Reply-To: <20061024115727.GD20405@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 15:15:18 -0000 Jeremie Le Hen wrote: > > What are you thinking about for inclusion of third-party apps on > tinybsd ? I hope it won't bloat too much the code. > Are you already expecting to provide it soon ? > I would like to use pkg_add. Maybe a file called tinybsd.apps and the users should add in this file what port name they want to install, so it'll copy binaries installation to workdir. Suggestions? Jean From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 15:20:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F315916A4CE; Tue, 24 Oct 2006 15:20:25 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B990443DDD; Tue, 24 Oct 2006 15:19:29 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:/2a+tNnFJOeWyCGX6/EF+b8EjpitV9lzkKrLK9ecvCg7L4DRijplWDrCuWf7jN3s@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id k9OFIVOa046922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Oct 2006 00:18:36 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 25 Oct 2006 00:18:31 +0900 Message-ID: From: Hajimu UMEMOTO To: "Jiawei Ye" In-Reply-To: References: <20061022095811.GA10743@zaphod.nitro.dk> <1161515330.751.9.camel@localhost> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> <20061024021919.GA74370@xor.obsecurity.org> <453D9B3B.5090000@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0rc3 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 25 Oct 2006 00:18:40 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on ameno.mahoroba.org Cc: Doug Barton , Kris Kennaway , nork@freebsd.org, "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 15:20:26 -0000 Hi, >>>>> On Tue, 24 Oct 2006 21:41:44 +0800 >>>>> "Jiawei Ye" said: leafy7382> On 10/24/06, Doug Barton wrote: > > Try applying the patch, and commenting out the options line. The patch > fixes things in what should be a more robust way. > > Doug > > -- > > This .signature sanitized for your protection leafy7382> This is much better. It would be great if this is commited. I've committed it into 7-CURRENT, and I'll MFC it into RELENG_6 after 3 days. The fix should help in certain case. However, it seems doesn't help for nork-san's case. He could reproduce it, and sent me his ktrace output. As far as I can see his output, his local name server (BIND 9.3.2-P1) returned the response with no answer record. As a result, his csup ended up with following error: Name lookup failure for "cvsup.jp.freebsd.org": hostname nor servname provided, or not known I suspect that the BIND9's named have some problem. 3434 csup CALL sendto(0x4,0x808f000,0x26,0,0,0) 3434 csup GIO fd 4 wrote 38 bytes 0x0000 855c 0100 0001 0000 0000 0000 0563 7673 |.\...........cvs| 0x0010 7570 026a 7007 6672 6565 6273 6403 6f72 |up.jp.freebsd.or| 0x0020 6700 0001 0001 |g.....| 3434 csup RET sendto 38/0x26 3434 csup CALL clock_gettime(0,0xbfbfcca8) 3434 csup RET clock_gettime 0 3434 csup CALL kevent(0x3,0xbfbfcda0,0x1,0xbfbfcda0,0x1,0xbfbfcd78) 3434 csup RET kevent 1 3434 csup CALL recvfrom(0x4,0x806f000,0x10000,0,0xbfbfcfc0,0xbfbfcd74) 3434 csup GIO fd 4 read 38 bytes 0x0000 855c 8180 0001 0000 0000 0000 0563 7673 |.\...........cvs| 0x0010 7570 026a 7007 6672 6565 6273 6403 6f72 |up.jp.freebsd.or| 0x0020 6700 0001 0001 |g.....| 3434 csup RET recvfrom 38/0x26 3434 csup CALL close(0x4) 3434 csup RET close 0 3434 csup CALL close(0x3) 3434 csup RET close 0 3434 csup CALL kqueue 3434 csup RET kqueue 3 3434 csup CALL socket(0x2,0x2,0) 3434 csup RET socket 4 3434 csup CALL connect(0x4,0x402b9490,0x10) 3434 csup RET connect 0 3434 csup CALL sendto(0x4,0x808f000,0x35,0,0,0) 3434 csup GIO fd 4 wrote 53 bytes 0x0000 855d 0100 0001 0000 0000 0000 0563 7673 |.]...........cvs| 0x0010 7570 026a 7007 6672 6565 6273 6403 6f72 |up.jp.freebsd.or| 0x0020 670a 6e69 6e74 682d 6e69 6e65 0363 6f6d |g.ninth-nine.com| 0x0030 0000 0100 01 |.....| 3434 csup RET sendto 53/0x35 3434 csup CALL clock_gettime(0,0xbfbfcca8) 3434 csup RET clock_gettime 0 3434 csup CALL kevent(0x3,0xbfbfcda0,0x1,0xbfbfcda0,0x1,0xbfbfcd78) 3434 csup RET kevent 1 3434 csup CALL recvfrom(0x4,0x806f000,0x10000,0,0xbfbfcfc0,0xbfbfcd74) 3434 csup GIO fd 4 read 104 bytes 0x0000 855d 8583 0001 0000 0001 0000 0563 7673 |.]...........cvs| 0x0010 7570 026a 7007 6672 6565 6273 6403 6f72 |up.jp.freebsd.or| 0x0020 670a 6e69 6e74 682d 6e69 6e65 0363 6f6d |g.ninth-nine.com| 0x0030 0000 0100 01c0 2100 0600 0100 0151 8000 |......!......Q..| 0x0040 2703 6e73 31c0 210a 686f 7374 6d61 7374 |'.ns1.!.hostmast| 0x0050 6572 c021 7792 15a4 0000 1c20 0000 0384 |er.!w...... ....| 0x0060 0024 ea00 0001 5180 |.$....Q.| 3434 csup RET recvfrom 104/0x68 3434 csup CALL close(0x4) 3434 csup RET close 0 3434 csup CALL close(0x3) 3434 csup RET close 0 3434 csup CALL break(0x807e000) 3434 csup RET break 0 3434 csup CALL fstat(0x1,0xbfbfdaf0) 3434 csup RET fstat 0 3434 csup CALL ioctl(0x1,TIOCGETA,0xbfbfdb30) 3434 csup RET ioctl 0 3434 csup CALL write(0x1,0x806e000,0x5d) 3434 csup GIO fd 1 wrote 93 bytes "Name lookup failure for "cvsup.jp.freebsd.org": hostname nor servname \ provided, or not known " Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 15:24:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D6F016A5A2 for ; Tue, 24 Oct 2006 15:24:55 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B5743DBD for ; Tue, 24 Oct 2006 15:24:21 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1362430uge for ; Tue, 24 Oct 2006 08:24:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pI0NSmiY41uBn5vNUrhXKlXyZ8Ze1G6gCobdRjn8M5zv4fVF9Q0Rkl1OxYtXnZ5Su//NHwrR3CA8Wt4LY5SFB4duCn6jp6IO2zvYkbEUzPSJvUlbcXme8NbFrMruTH0lYsrrnhrzNICeJtDfknU9jCQXM3tCejHqn1EnlhJ0npk= Received: by 10.66.244.10 with SMTP id r10mr9026320ugh; Tue, 24 Oct 2006 08:24:07 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Tue, 24 Oct 2006 08:24:06 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 23:24:06 +0800 From: "Jiawei Ye" To: "Hajimu UMEMOTO" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061022095811.GA10743@zaphod.nitro.dk> <200610221423.19817.andy@athame.co.uk> <453BFC2A.5010501@FreeBSD.org> <20061023022928.35b7b23c@it.buh.tecnik93.com> <20061024021919.GA74370@xor.obsecurity.org> <453D9B3B.5090000@FreeBSD.org> Cc: Doug Barton , Kris Kennaway , nork@freebsd.org, "Simon L. Nielsen" , freebsd-current@freebsd.org, Joel@freebsd.org, Ion-Mihai IOnut Tetcu Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 15:24:55 -0000 On 10/24/06, Hajimu UMEMOTO wrote: > leafy7382> This is much better. It would be great if this is commited. > > I've committed it into 7-CURRENT, and I'll MFC it into RELENG_6 after > 3 days. > > The fix should help in certain case. However, it seems doesn't help > for nork-san's case. He could reproduce it, and sent me his ktrace > output. As far as I can see his output, his local name server (BIND > 9.3.2-P1) returned the response with no answer record. As a result, > his csup ended up with following error: > > Name lookup failure for "cvsup.jp.freebsd.org": hostname nor > servname provided, or not known > > I suspect that the BIND9's named have some problem. > > "Name lookup failure for "cvsup.jp.freebsd.org": hostname nor servname \ > provided, or not known > " > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan You are correct, I just ran into that a few times in the last hour. But it is a lot less frequent than before. I also run a local BIND9 for our company. I think some commits happening after between Sept 30 and Oct 15th caused it, because I did not see such symptom before late Sept and I rebuilt my system around mid Oct. Best regards, Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 15:35:33 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EDA716A407; Tue, 24 Oct 2006 15:35:33 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E3F43D66; Tue, 24 Oct 2006 15:35:32 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id k9OFZNwY073717; Tue, 24 Oct 2006 19:35:23 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id k9OFZNVU073716; Tue, 24 Oct 2006 19:35:23 +0400 (MSD) (envelope-from ache) Date: Tue, 24 Oct 2006 19:35:23 +0400 From: Andrey Chernov To: Mikhail Teterin Message-ID: <20061024153523.GA73555@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mikhail Teterin , Mikhail Teterin , current@FreeBSD.ORG, tjr@FreeBSD.ORG References: <200609202304.25537@aldan> <200609261302.40964.mi+mx@aldan.algebra.com> <20060926184447.GA17862@nagual.pp.ru> <200610240749.11234@aldan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610240749.11234@aldan> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Mikhail Teterin , current@FreeBSD.ORG, tjr@FreeBSD.ORG Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 15:35:33 -0000 On Tue, Oct 24, 2006 at 07:49:10AM -0400, Mikhail Teterin wrote: > = Someone must test its compatibility with GNU regex and understand in > = details nature of their changes/fixes/differences. Without this work we > = can't blindly replace stable code with unknown one just for reason it is > = actively maintained. > > What kind of test would be deemed sufficient? I don't have anything at hand, but I saw a tests in some regex implementations I don't remember now. Perhaps someone else knows good regex test suits? The common bottle neck is locale: collating, multibyte and character classes handling. I can test it excepting multibyte, our multibyte-enabled developers needed. What must be tested before as primary target: general POSIX compatibility. What must be tested in second: GNU regex compatibility. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 16:04:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09E9216A403 for ; Tue, 24 Oct 2006 16:04:41 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E3C43D6D for ; Tue, 24 Oct 2006 16:04:36 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id k9OG4Ywv017378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Oct 2006 18:04:34 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id k9OG4Y4A017377 for current@freebsd.org; Tue, 24 Oct 2006 18:04:34 +0200 (CEST) Date: Tue, 24 Oct 2006 18:04:34 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20061024160433.GA17311@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: Subject: GENERIC build on recent -currento n amd64 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: Tue, 24 Oct 2006 16:04:41 -0000 In file included from ../../../kern/kern_module.c:433: ../../../compat/freebsd32/freebsd32_proto.h:301: error: redefinition of `struct audit_args' ../../../compat/freebsd32/freebsd32_proto.h:305: error: redefinition of `struct auditon_args' ../../../compat/freebsd32/freebsd32_proto.h:310: error: redefinition of `struct getauid_args' ../../../compat/freebsd32/freebsd32_proto.h:313: error: redefinition of `struct setauid_args' ../../../compat/freebsd32/freebsd32_proto.h:316: error: redefinition of `struct getaudit_args' ../../../compat/freebsd32/freebsd32_proto.h:319: error: redefinition of `struct setaudit_args' ../../../compat/freebsd32/freebsd32_proto.h:322: error: redefinition of `struct getaudit_addr_args' ../../../compat/freebsd32/freebsd32_proto.h:326: error: redefinition of `struct setaudit_addr_args' ../../../compat/freebsd32/freebsd32_proto.h:330: error: redefinition of `struct auditctl_args' ../../../compat/freebsd32/freebsd32_proto.h:395: warning: redundant redeclaration of 'audit' ../../../sys/sysproto.h:1760: warning: previous declaration of 'audit' was here ../../../compat/freebsd32/freebsd32_proto.h:396: warning: redundant redeclaration of 'auditon' ../../../sys/sysproto.h:1761: warning: previous declaration of 'auditon' was here pls fix From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 16:49:07 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4912716A4E1; Tue, 24 Oct 2006 16:49:07 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E3B543E64; Tue, 24 Oct 2006 16:47:25 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id k9OGlGig074277; Tue, 24 Oct 2006 20:47:16 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id k9OGlGqF074276; Tue, 24 Oct 2006 20:47:16 +0400 (MSD) (envelope-from ache) Date: Tue, 24 Oct 2006 20:47:15 +0400 From: Andrey Chernov To: Mikhail Teterin Message-ID: <20061024164715.GA74241@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mikhail Teterin , current@FreeBSD.ORG, tjr@FreeBSD.ORG References: <200609202304.25537@aldan> <200610240749.11234@aldan> <20061024153523.GA73555@nagual.pp.ru> <200610241140.43389.mi+mx@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200610241140.43389.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.ORG, tjr@FreeBSD.ORG Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 16:49:07 -0000 On Tue, Oct 24, 2006 at 11:40:43AM -0400, Mikhail Teterin wrote: > ×?×ÔÏÒÏË 24 ÖÏ×ÔÅÎØ 2006 11:35, Andrey Chernov ÎÁÐÉÓÁ×: > > The common bottle neck is locale: > > collating, multibyte and character classes handling. > > Is the currently used -lgnuregex passing these requirements? I remember some multibyte-related PRs assigned to tjr (inactive now?) No single byte locale problems found. > The proposed replacement is simply the newer version of the currently used Red > Hat -lgnuregex. > > I'd hate to go through the pain similar to that of the csh vs. tcsh debate... Well, go on and lets see what happens :) -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 16:54:26 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C7B616A412; Tue, 24 Oct 2006 16:54:26 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC5B743D4C; Tue, 24 Oct 2006 16:54:25 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id D4E2262EB; Tue, 24 Oct 2006 20:52:13 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 38B715F40; Tue, 24 Oct 2006 20:49:28 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9OGnS0d040126; Tue, 24 Oct 2006 20:49:28 +0400 (MSD) (envelope-from ru) Date: Tue, 24 Oct 2006 20:49:28 +0400 From: Ruslan Ermilov To: Divacky Roman Message-ID: <20061024164928.GF21304@rambler-co.ru> References: <20061024160433.GA17311@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w3uUfsyyY1Pqa/ej" Content-Disposition: inline In-Reply-To: <20061024160433.GA17311@stud.fit.vutbr.cz> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Robert Watson , current@FreeBSD.org Subject: Re: GENERIC build on recent -currento n amd64 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: Tue, 24 Oct 2006 16:54:26 -0000 --w3uUfsyyY1Pqa/ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 06:04:34PM +0200, Divacky Roman wrote: > In file included from ../../../kern/kern_module.c:433: > ../../../compat/freebsd32/freebsd32_proto.h:301: error: redefinition of `= struct audit_args' > ../../../compat/freebsd32/freebsd32_proto.h:305: error: redefinition of `= struct auditon_args' > ../../../compat/freebsd32/freebsd32_proto.h:310: error: redefinition of `= struct getauid_args' > ../../../compat/freebsd32/freebsd32_proto.h:313: error: redefinition of `= struct setauid_args' > ../../../compat/freebsd32/freebsd32_proto.h:316: error: redefinition of `= struct getaudit_args' > ../../../compat/freebsd32/freebsd32_proto.h:319: error: redefinition of `= struct setaudit_args' > ../../../compat/freebsd32/freebsd32_proto.h:322: error: redefinition of `= struct getaudit_addr_args' > ../../../compat/freebsd32/freebsd32_proto.h:326: error: redefinition of `= struct setaudit_addr_args' > ../../../compat/freebsd32/freebsd32_proto.h:330: error: redefinition of `= struct auditctl_args' > ../../../compat/freebsd32/freebsd32_proto.h:395: warning: redundant redec= laration of 'audit' > ../../../sys/sysproto.h:1760: warning: previous declaration of 'audit' wa= s here > ../../../compat/freebsd32/freebsd32_proto.h:396: warning: redundant redec= laration of 'auditon' > ../../../sys/sysproto.h:1761: warning: previous declaration of 'auditon' = was here >=20 Apply this patch, then type "make" while in sys/compat/freebsd32, then try to build kernel again. %%% Index: syscalls.master =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/compat/freebsd32/syscalls.master,v retrieving revision 1.84 diff -u -p -r1.84 syscalls.master --- syscalls.master 24 Oct 2006 13:49:44 -0000 1.84 +++ syscalls.master 24 Oct 2006 16:48:04 -0000 @@ -733,21 +733,23 @@ const struct timespec32 *timeout); } 443 AUE_NULL NOPROTO { int thr_wake(long id); } 444 AUE_MODUNLOAD NOPROTO { int kldunloadf(int fileid, int flags); } -445 AUE_AUDIT STD { int audit(const void *record, \ +445 AUE_AUDIT STD { int freebsd32_audit(const void *record, \ u_int length); } -446 AUE_AUDITON STD { int auditon(int cmd, void *data, \ +446 AUE_AUDITON STD { int freebsd32_auditon(int cmd, void *data, \ u_int length); } -447 AUE_GETAUID STD { int getauid(uid_t *auid); } -448 AUE_SETAUID STD { int setauid(uid_t *auid); } -449 AUE_GETAUDIT STD { int getaudit(struct auditinfo *auditinfo); } -450 AUE_SETAUDIT STD { int setaudit(struct auditinfo *auditinfo); } -451 AUE_GETAUDIT_ADDR STD { int getaudit_addr( \ +447 AUE_GETAUID STD { int freebsd32_getauid(uid_t *auid); } +448 AUE_SETAUID STD { int freebsd32_setauid(uid_t *auid); } +449 AUE_GETAUDIT STD { int freebsd32_getaudit( \ + struct auditinfo *auditinfo); } +450 AUE_SETAUDIT STD { int freebsd32_setaudit( \ + struct auditinfo *auditinfo); } +451 AUE_GETAUDIT_ADDR STD { int freebsd32_getaudit_addr( \ struct auditinfo_addr *auditinfo_addr, \ u_int length); } -452 AUE_SETAUDIT_ADDR STD { int setaudit_addr( \ +452 AUE_SETAUDIT_ADDR STD { int freebsd32_setaudit_addr( \ struct auditinfo_addr *auditinfo_addr, \ u_int length); } -453 AUE_AUDITCTL STD { int auditctl(char *path); } +453 AUE_AUDITCTL STD { int freebsd32_auditctl(char *path); } 454 AUE_NULL STD { int freebsd32_umtx_op(void *obj, int op,\ u_long val, void *uaddr, \ void *uaddr2); } %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --w3uUfsyyY1Pqa/ej Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPkQYqRfpzJluFF4RAh3jAKCOwltxw+M34IKI7F+mLBgCNHwC+gCgjkZC SdXNkvaKx+4MLo3hAUtYc6A= =jg1v -----END PGP SIGNATURE----- --w3uUfsyyY1Pqa/ej-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 16:57:03 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2711E16A412; Tue, 24 Oct 2006 16:57:03 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A11543D78; Tue, 24 Oct 2006 16:56:50 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 97E9B6436; Tue, 24 Oct 2006 20:56:48 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id B7F6D6320; Tue, 24 Oct 2006 20:53:56 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9OGrvoK040190; Tue, 24 Oct 2006 20:53:57 +0400 (MSD) (envelope-from ru) Date: Tue, 24 Oct 2006 20:53:57 +0400 From: Ruslan Ermilov To: Divacky Roman Message-ID: <20061024165357.GG21304@rambler-co.ru> References: <20061024160433.GA17311@stud.fit.vutbr.cz> <20061024164928.GF21304@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qf1oXS95uex85X0R" Content-Disposition: inline In-Reply-To: <20061024164928.GF21304@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Robert Watson , current@FreeBSD.org Subject: Re: GENERIC build on recent -currento n amd64 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: Tue, 24 Oct 2006 16:57:03 -0000 --Qf1oXS95uex85X0R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 08:49:28PM +0400, Ruslan Ermilov wrote: > Apply this patch, then type "make" while in sys/compat/freebsd32, > then try to build kernel again. >=20 Oops, try this patch instead: %%% Index: syscalls.master =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/compat/freebsd32/syscalls.master,v retrieving revision 1.84 diff -u -p -r1.84 syscalls.master --- syscalls.master 24 Oct 2006 13:49:44 -0000 1.84 +++ syscalls.master 24 Oct 2006 16:52:03 -0000 @@ -733,21 +733,21 @@ const struct timespec32 *timeout); } 443 AUE_NULL NOPROTO { int thr_wake(long id); } 444 AUE_MODUNLOAD NOPROTO { int kldunloadf(int fileid, int flags); } -445 AUE_AUDIT STD { int audit(const void *record, \ +445 AUE_AUDIT NOPROTO { int audit(const void *record, \ u_int length); } -446 AUE_AUDITON STD { int auditon(int cmd, void *data, \ +446 AUE_AUDITON NOPROTO { int auditon(int cmd, void *data, \ u_int length); } -447 AUE_GETAUID STD { int getauid(uid_t *auid); } -448 AUE_SETAUID STD { int setauid(uid_t *auid); } -449 AUE_GETAUDIT STD { int getaudit(struct auditinfo *auditinfo); } -450 AUE_SETAUDIT STD { int setaudit(struct auditinfo *auditinfo); } -451 AUE_GETAUDIT_ADDR STD { int getaudit_addr( \ +447 AUE_GETAUID NOPROTO { int getauid(uid_t *auid); } +448 AUE_SETAUID NOPROTO { int setauid(uid_t *auid); } +449 AUE_GETAUDIT NOPROTO { int getaudit(struct auditinfo *auditinfo); } +450 AUE_SETAUDIT NOPROTO { int setaudit(struct auditinfo *auditinfo); } +451 AUE_GETAUDIT_ADDR NOPROTO { int getaudit_addr( \ struct auditinfo_addr *auditinfo_addr, \ u_int length); } -452 AUE_SETAUDIT_ADDR STD { int setaudit_addr( \ +452 AUE_SETAUDIT_ADDR NOPROTO { int setaudit_addr( \ struct auditinfo_addr *auditinfo_addr, \ u_int length); } -453 AUE_AUDITCTL STD { int auditctl(char *path); } +453 AUE_AUDITCTL NOPROTO { int auditctl(char *path); } 454 AUE_NULL STD { int freebsd32_umtx_op(void *obj, int op,\ u_long val, void *uaddr, \ void *uaddr2); } %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Qf1oXS95uex85X0R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPkUlqRfpzJluFF4RAjWIAJ9Xw5nIHZ4YOQpj3Gj5v4cde6/QxgCfedND U3Xqaif1QZv7W4s7/MGKR10= =7bU7 -----END PGP SIGNATURE----- --Qf1oXS95uex85X0R-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 17:07:42 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A7316A407; Tue, 24 Oct 2006 17:07:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE71143D5D; Tue, 24 Oct 2006 17:07:41 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D76BB46D2D; Tue, 24 Oct 2006 13:07:40 -0400 (EDT) Date: Tue, 24 Oct 2006 18:07:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20061024165357.GG21304@rambler-co.ru> Message-ID: <20061024180714.I48521@fledge.watson.org> References: <20061024160433.GA17311@stud.fit.vutbr.cz> <20061024164928.GF21304@rambler-co.ru> <20061024165357.GG21304@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Divacky Roman , current@FreeBSD.org Subject: Re: GENERIC build on recent -currento n amd64 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: Tue, 24 Oct 2006 17:07:42 -0000 On Tue, 24 Oct 2006, Ruslan Ermilov wrote: > On Tue, Oct 24, 2006 at 08:49:28PM +0400, Ruslan Ermilov wrote: >> Apply this patch, then type "make" while in sys/compat/freebsd32, >> then try to build kernel again. >> > Oops, try this patch instead: Feel free to go ahead and commit this; I'll be offline for a few more hours. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > %%% > Index: syscalls.master > =================================================================== > RCS file: /home/ncvs/src/sys/compat/freebsd32/syscalls.master,v > retrieving revision 1.84 > diff -u -p -r1.84 syscalls.master > --- syscalls.master 24 Oct 2006 13:49:44 -0000 1.84 > +++ syscalls.master 24 Oct 2006 16:52:03 -0000 > @@ -733,21 +733,21 @@ > const struct timespec32 *timeout); } > 443 AUE_NULL NOPROTO { int thr_wake(long id); } > 444 AUE_MODUNLOAD NOPROTO { int kldunloadf(int fileid, int flags); } > -445 AUE_AUDIT STD { int audit(const void *record, \ > +445 AUE_AUDIT NOPROTO { int audit(const void *record, \ > u_int length); } > -446 AUE_AUDITON STD { int auditon(int cmd, void *data, \ > +446 AUE_AUDITON NOPROTO { int auditon(int cmd, void *data, \ > u_int length); } > -447 AUE_GETAUID STD { int getauid(uid_t *auid); } > -448 AUE_SETAUID STD { int setauid(uid_t *auid); } > -449 AUE_GETAUDIT STD { int getaudit(struct auditinfo *auditinfo); } > -450 AUE_SETAUDIT STD { int setaudit(struct auditinfo *auditinfo); } > -451 AUE_GETAUDIT_ADDR STD { int getaudit_addr( \ > +447 AUE_GETAUID NOPROTO { int getauid(uid_t *auid); } > +448 AUE_SETAUID NOPROTO { int setauid(uid_t *auid); } > +449 AUE_GETAUDIT NOPROTO { int getaudit(struct auditinfo *auditinfo); } > +450 AUE_SETAUDIT NOPROTO { int setaudit(struct auditinfo *auditinfo); } > +451 AUE_GETAUDIT_ADDR NOPROTO { int getaudit_addr( \ > struct auditinfo_addr *auditinfo_addr, \ > u_int length); } > -452 AUE_SETAUDIT_ADDR STD { int setaudit_addr( \ > +452 AUE_SETAUDIT_ADDR NOPROTO { int setaudit_addr( \ > struct auditinfo_addr *auditinfo_addr, \ > u_int length); } > -453 AUE_AUDITCTL STD { int auditctl(char *path); } > +453 AUE_AUDITCTL NOPROTO { int auditctl(char *path); } > 454 AUE_NULL STD { int freebsd32_umtx_op(void *obj, int op,\ > u_long val, void *uaddr, \ > void *uaddr2); } > %%% > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 17:39:29 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07AFB16A403; Tue, 24 Oct 2006 17:39:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F5E143D75; Tue, 24 Oct 2006 17:39:28 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.6) with ESMTP id k9OHdOq4031017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 10:39:25 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <453E4F8D.4040909@FreeBSD.org> Date: Tue, 24 Oct 2006 10:38:21 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Robert Watson References: <20061024160433.GA17311@stud.fit.vutbr.cz> <20061024164928.GF21304@rambler-co.ru> <20061024165357.GG21304@rambler-co.ru> <20061024180714.I48521@fledge.watson.org> In-Reply-To: <20061024180714.I48521@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Divacky Roman , Ruslan Ermilov , current@FreeBSD.org Subject: Re: GENERIC build on recent -currento n amd64 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: Tue, 24 Oct 2006 17:39:29 -0000 Should be fixed already. -Maxim Robert Watson wrote: > > On Tue, 24 Oct 2006, Ruslan Ermilov wrote: > >> On Tue, Oct 24, 2006 at 08:49:28PM +0400, Ruslan Ermilov wrote: >>> Apply this patch, then type "make" while in sys/compat/freebsd32, >>> then try to build kernel again. >>> >> Oops, try this patch instead: > > Feel free to go ahead and commit this; I'll be offline for a few more > hours. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> %%% >> Index: syscalls.master >> =================================================================== >> RCS file: /home/ncvs/src/sys/compat/freebsd32/syscalls.master,v >> retrieving revision 1.84 >> diff -u -p -r1.84 syscalls.master >> --- syscalls.master 24 Oct 2006 13:49:44 -0000 1.84 >> +++ syscalls.master 24 Oct 2006 16:52:03 -0000 >> @@ -733,21 +733,21 @@ >> const struct timespec32 *timeout); } >> 443 AUE_NULL NOPROTO { int thr_wake(long id); } >> 444 AUE_MODUNLOAD NOPROTO { int kldunloadf(int fileid, int >> flags); } >> -445 AUE_AUDIT STD { int audit(const void *record, \ >> +445 AUE_AUDIT NOPROTO { int audit(const void *record, \ >> u_int length); } >> -446 AUE_AUDITON STD { int auditon(int cmd, void *data, \ >> +446 AUE_AUDITON NOPROTO { int auditon(int cmd, void *data, \ >> u_int length); } >> -447 AUE_GETAUID STD { int getauid(uid_t *auid); } >> -448 AUE_SETAUID STD { int setauid(uid_t *auid); } >> -449 AUE_GETAUDIT STD { int getaudit(struct auditinfo >> *auditinfo); } >> -450 AUE_SETAUDIT STD { int setaudit(struct auditinfo >> *auditinfo); } >> -451 AUE_GETAUDIT_ADDR STD { int getaudit_addr( \ >> +447 AUE_GETAUID NOPROTO { int getauid(uid_t *auid); } >> +448 AUE_SETAUID NOPROTO { int setauid(uid_t *auid); } >> +449 AUE_GETAUDIT NOPROTO { int getaudit(struct auditinfo >> *auditinfo); } >> +450 AUE_SETAUDIT NOPROTO { int setaudit(struct auditinfo >> *auditinfo); } >> +451 AUE_GETAUDIT_ADDR NOPROTO { int getaudit_addr( \ >> struct auditinfo_addr *auditinfo_addr, \ >> u_int length); } >> -452 AUE_SETAUDIT_ADDR STD { int setaudit_addr( \ >> +452 AUE_SETAUDIT_ADDR NOPROTO { int setaudit_addr( \ >> struct auditinfo_addr *auditinfo_addr, \ >> u_int length); } >> -453 AUE_AUDITCTL STD { int auditctl(char *path); } >> +453 AUE_AUDITCTL NOPROTO { int auditctl(char *path); } >> 454 AUE_NULL STD { int freebsd32_umtx_op(void *obj, int op,\ >> u_long val, void *uaddr, \ >> void *uaddr2); } >> %%% >> >> >> Cheers, >> -- >> Ruslan Ermilov >> ru@FreeBSD.org >> FreeBSD committer >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 15:40:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AF6016A47C; Tue, 24 Oct 2006 15:40:51 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 820CC43D66; Tue, 24 Oct 2006 15:40:50 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k9OFemlI015278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 11:40:49 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Andrey Chernov Date: Tue, 24 Oct 2006 11:40:43 -0400 User-Agent: KMail/1.9.1 References: <200609202304.25537@aldan> <200610240749.11234@aldan> <20061024153523.GA73555@nagual.pp.ru> In-Reply-To: <20061024153523.GA73555@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200610241140.43389.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/2091/Tue Oct 24 09:27:53 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:11:04 +0000 Cc: current@freebsd.org, tjr@freebsd.org Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 15:40:51 -0000 צ×ÔÏÒÏË 24 ÖÏ×ÔÅÎØ 2006 11:35, Andrey Chernov ÎÁÐÉÓÁ×: > The common bottle neck is locale: > collating, multibyte and character classes handling. Is the currently used -lgnuregex passing these requirements? > I can test it excepting multibyte, our multibyte-enabled developers > needed. > What must be tested before as primary target: general POSIX compatibility. > What must be tested in second: GNU regex compatibility. The proposed replacement is simply the newer version of the currently used Red Hat -lgnuregex. I'd hate to go through the pain similar to that of the csh vs. tcsh debate... -mi From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 18:17:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6666516A40F for ; Tue, 24 Oct 2006 18:17:03 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA7643D46 for ; Tue, 24 Oct 2006 18:17:02 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id k9OIH0Zu002061 (8.13.4/1.4); Tue, 24 Oct 2006 20:17:00 +0200 (MEST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id k9OIH0cU017682 (8.13.2/2.02); Tue, 24 Oct 2006 20:17:00 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 24 Oct 2006 20:17:00 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: panic in ttwakeup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 18:17:03 -0000 Hi. Got this panic while fooling around with jails. Can't remember what I did unfortunately. kgdb barfed at the frame at address 0 in the backtrace command so I couldn't extract any more useful data except for the following. I guess this is related to kern/103520 kernel is from Mon Oct 23 10:42:06 CEST 2006 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xd59f892c frame pointer = 0x28:0xd59f8940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 31026 (script) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c2816bd0,28,d59f88ec,c,...) at kdb_backtrace+0x29 panic(c0642f3f,c06642d6,0,0,fffff,...) at panic+0xa8 trap_fatal(d59f88ec,0,c2816bd0,c280f71c,0,...) at trap_fatal+0x2b6 trap_pfault(d59f88ec,0,0) at trap_pfault+0x1cb trap(d59f0008,c0540028,c22f0028,c28f5400,c28c9a80,...) at trap+0x38d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0, esp = 0xd59f892c, ebp = 0xd59f8940 --- (null)(c219f888,0,0,c219f810,c219f800,...) at 0 ttwakeup(c219f800,c219f800,c219f800,c28c9a80,d59f8990,...) at ttwakeup+0x65 ttymodem(c219f800,1) at ttymodem+0x170 ptcopen(c28f5400,3,2000,c2816bd0) at ptcopen+0x8c giant_open(c28f5400,3,2000,c2816bd0) at giant_open+0x4b devfs_open(d59f8a20) at devfs_open+0x1cf VOP_OPEN_APV(c067b540,d59f8a20) at VOP_OPEN_APV+0x38 vn_open_cred(d59f8b88,d59f8c88,0,c2b20200,4,...) at vn_open_cred+0x453 vn_open(d59f8b88,d59f8c88,0,4) at vn_open+0x1e kern_open(c2816bd0,bfbfe2a0,0,3,0,...) at kern_open+0xb9 open(c2816bd0,d59f8d04) at open+0x18 syscall(3b,3b,3b,bfbfe2ab,ffffffff,...) at syscall+0x2ae Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x28146e0f, esp = 0xbfbfe26c, ebp = 0xbfbfe2c8 --- Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 19:09:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 814D716A40F for ; Tue, 24 Oct 2006 19:09:57 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5F9B43D46 for ; Tue, 24 Oct 2006 19:09:56 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id k9OJ9t3g010900 (8.13.4/1.4); Tue, 24 Oct 2006 21:09:55 +0200 (MEST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id k9OJ9t7H017778 (8.13.2/2.02); Tue, 24 Oct 2006 21:09:55 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 24 Oct 2006 21:09:55 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: 'ro' option in fstab not recognized? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 19:09:57 -0000 Hi. I must be extremely stupid. I have this in my fstab /usr/local /usr/j/usr/local nullfs ro 0 0 but /usr/j/usr/local still appears to be mounted read-write. Oh wait, I guess this is also already covered by PR 100164. Line 197 of sys/mount/mount.c explicitly adds an option "noro". Looks to me like this makes it impossible to mount *any* file system read-only, except by explicitly passing flags to mount. Surely this is not what fstab was designed for? :) From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 20:37:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 727D916A403 for ; Tue, 24 Oct 2006 20:37:07 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6D443D53 for ; Tue, 24 Oct 2006 20:37:05 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1445240uge for ; Tue, 24 Oct 2006 13:37:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JXQwbSBHXCbXik/qFQpllMwLgdIrhFPkNXS/A5wkFyTllUFkgkuGnX49/RngNqzEwnPAtxoDszP9Olb/pInezHtJWSxNm+95YiXUL6MrTgWaEqa8o7MGj7qJlx1Alf3TjWyESePJpFQf3ZYEwGKL4fzxqADUpMGxhveMq5O3R9o= Received: by 10.78.128.15 with SMTP id a15mr9911723hud; Tue, 24 Oct 2006 13:37:00 -0700 (PDT) Received: by 10.78.197.4 with HTTP; Tue, 24 Oct 2006 13:37:00 -0700 (PDT) Message-ID: <7579f7fb0610241337u10eceb27pba6adf65ebf19dab@mail.gmail.com> Date: Tue, 24 Oct 2006 13:37:00 -0700 From: "Matthew Jacob" To: "Michiel Boland" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: 'ro' option in fstab not recognized? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 20:37:07 -0000 No, you're not stupid. This has been happening in 6 and -current for months now. I just haven't had time to figure out what got broken. You can fix it after mount by doing mount -u -o ro /usr/j/usr/local On 10/24/06, Michiel Boland wrote: > Hi. I must be extremely stupid. I have this in my fstab > > /usr/local /usr/j/usr/local nullfs ro 0 0 > > but /usr/j/usr/local still appears to be mounted read-write. > > Oh wait, I guess this is also already covered by PR 100164. > > Line 197 of sys/mount/mount.c explicitly adds an option "noro". > Looks to me like this makes it impossible to mount *any* file system > read-only, except by explicitly passing flags to mount. > Surely this is not what fstab was designed for? :) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 22:06:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8580916A403 for ; Tue, 24 Oct 2006 22:06:13 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0986F43D5A for ; Tue, 24 Oct 2006 22:06:11 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 198E25E18; Wed, 25 Oct 2006 02:06:10 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 0FACA5DD4; Wed, 25 Oct 2006 02:06:10 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9OM6AU7001328; Wed, 25 Oct 2006 02:06:10 +0400 (MSD) (envelope-from ru) Date: Wed, 25 Oct 2006 02:06:10 +0400 From: Ruslan Ermilov To: Matthew Jacob Message-ID: <20061024220610.GB929@rambler-co.ru> References: <7579f7fb0610241337u10eceb27pba6adf65ebf19dab@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <7579f7fb0610241337u10eceb27pba6adf65ebf19dab@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Michiel Boland , freebsd-current@freebsd.org Subject: Re: 'ro' option in fstab not recognized? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2006 22:06:13 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 01:37:00PM -0700, Matthew Jacob wrote: > No, you're not stupid. This has been happening in 6 and -current for > months now. >=20 I cannot reproduce it on RELENG_6. On -CURRENT indeed there was a problem; I've just fixed it backing out rev. 1.86 to mount.c, see the commit log for details. > I just haven't had time to figure out what got broken. >=20 > You can fix it after mount by doing >=20 > mount -u -o ro /usr/j/usr/local >=20 >=20 > On 10/24/06, Michiel Boland wrote: > >Hi. I must be extremely stupid. I have this in my fstab > > > >/usr/local /usr/j/usr/local nullfs ro 0 0 > > > >but /usr/j/usr/local still appears to be mounted read-write. > > > >Oh wait, I guess this is also already covered by PR 100164. > > > >Line 197 of sys/mount/mount.c explicitly adds an option "noro". > >Looks to me like this makes it impossible to mount *any* file system > >read-only, except by explicitly passing flags to mount. > >Surely this is not what fstab was designed for? :) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPo5SqRfpzJluFF4RAvDUAJwO6rP05pcFBA877eihNcEgdLqe+gCffwB7 3gizIEAc5rIqyC5Frfu7U6U= =6Pt7 -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 04:27:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDCF16A415 for ; Wed, 25 Oct 2006 04:27:02 +0000 (UTC) (envelope-from nakaji@jp.freebsd.org) Received: from tksev.kankyo-u.ac.jp (tkserv.kankyo-u.ac.jp [202.216.78.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BA9B43D5D for ; Wed, 25 Oct 2006 04:27:00 +0000 (GMT) (envelope-from nakaji@jp.freebsd.org) Received: from mail.kankyo-u.ac.jp (mail [192.168.1.8]) by tksev.kankyo-u.ac.jp (unknown) with ESMTP id k9P4Qx2D025196 for ; Wed, 25 Oct 2006 13:26:59 +0900 (JST) Received: from fsvirusgw.kankyo-u.ac.jp (fsvirusgw.kankyo-u.ac.jp [192.168.1.60]) (authenticated) by mail.kankyo-u.ac.jp (unknown) with ESMTP id k9P4Qrt05613 for ; Wed, 25 Oct 2006 13:26:53 +0900 (JST) Received: from 10.44.195.2 (10.44.195.2) by fsvirusgw.kankyo-u.ac.jp (F-Secure/virusgw_smtp/221/fsvirusgw.kankyo-u.ac.jp); Wed, 25 Oct 2006 13:23:57 +0900 (JST) X-Virus-Status: clean(F-Secure/virusgw_smtp/221/fsvirusgw.kankyo-u.ac.jp) Received: from roddy.4407.kankyo-u.ac.jp.kankyo-u.ac.jp (localhost [IPv6:::1]) by localhost.kankyo-u.ac.jp (8.13.8/8.13.8) with ESMTP id k9P4QlSN040456 for ; Wed, 25 Oct 2006 13:26:49 +0900 (JST) (envelope-from nakaji@jp.freebsd.org) From: NAKAJI Hiroyuki To: freebsd-current@freebsd.org Date: Wed, 25 Oct 2006 13:26:47 +0900 Message-ID: <877iypggvs.fsf@roddy.4407.kankyo-u.ac.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: firefox and openoffice.org dump core at pthread_atfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2006 04:27:02 -0000 Hi, On my FreeBSD/i386 7.0-current on Dual Xeon box usually fails at pthread_atfork(). For example, 1. Print or just print preview from Firefox 2. Run OpenOffice.org, no operation and then exit $ uname -a FreeBSD roddy.4407.kankyo-u.ac.jp 7.0-CURRENT FreeBSD 7.0-CURRENT #72: Thu Oct 19 10:11:06 JST 2006 root@roddy.4407.kankyo-u.ac.jp:/usr/obj/usr/src/sys/RODDY i386 The latest soffice.bin.core shows that Segmentation fault occured at pthread_atfork(). (gdb) bt #0 0x290e07ef in pthread_atfork () from /lib/libpthread.so.2 #1 0x290d89ca in pthread_kill () from /lib/libpthread.so.2 #2 0x082302b0 in ?? () I sent simillar report to FreeBSD-users-jp http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/89635 Some guys have same experience and some not. And, because dmesg says "signal 11", I checked the memory with memtest86 but no errors are found. I'm confused very much. -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 06:10:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC91116A416 for ; Wed, 25 Oct 2006 06:10:21 +0000 (UTC) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD2A43D4C for ; Wed, 25 Oct 2006 06:10:20 +0000 (GMT) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (localhost [IPv6:::1]) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id k9P6AIrQ049951 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Oct 2006 08:10:19 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.12.10/8.12.10/Submit) with UUCP id k9P6AIs5049948; Wed, 25 Oct 2006 08:10:18 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: from titan.klemm.apsfilter.org (localhost.klemm.apsfilter.org [127.0.0.1]) by klemm.apsfilter.org (8.13.8/8.13.4) with ESMTP id k9P69QnB012803; Wed, 25 Oct 2006 08:09:26 +0200 (CEST) (envelope-from andreas@titan.klemm.apsfilter.org) Received: (from andreas@localhost) by titan.klemm.apsfilter.org (8.13.8/8.13.4/Submit) id k9P69PK9012802; Wed, 25 Oct 2006 08:09:25 +0200 (CEST) (envelope-from andreas) Date: Wed, 25 Oct 2006 08:09:25 +0200 From: Andreas Klemm To: Stefan Bethke Message-ID: <20061025060925.GA11697@titan.klemm.apsfilter.org> References: <20061023061539.GA17549@titan.klemm.apsfilter.org> <20061023212554.00062ff5@serene.no-ip.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.2-PRERELEASE X-Disclaimer: A free society is one where it is safe to be unpopular User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 06:10:21 -0000 On Tue, Oct 24, 2006 at 09:12:01AM +0200, Stefan Bethke wrote: > Am 24.10.2006 um 04:25 schrieb Conrad J. Sabatier: > > >Not sure what's causing this, but I'm seeing the "script" child > >processes spawned by portupgrade consuming an inordinate amount of > >CPU, > >as much as 80+%. This does make the configure stage appear to hang > >interminably much of the time. > > I do get this when the port uses options (or otherwise invokes dialog > (1)), and portupgrade is not on a terminal. > > On a number of machines, I update ports by a cron job, so I define - > DBATCH in pkgtools.conf for all ports. Was all interactive. Maybe at the weekend I can investigate more into this. Though it won't be the same situation as before, since I updated to -current of 2 days ago. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 10:42:27 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5066716A403; Wed, 25 Oct 2006 10:42:27 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EBD43D5E; Wed, 25 Oct 2006 10:42:26 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3E9C727A27; Wed, 25 Oct 2006 12:42:25 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 7BBEA9E6C2; Wed, 25 Oct 2006 10:43:06 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 56850405B; Wed, 25 Oct 2006 12:43:06 +0200 (CEST) Date: Wed, 25 Oct 2006 12:43:06 +0200 From: Jeremie Le Hen To: Jean Milanez Melo Message-ID: <20061025104306.GI20405@obiwan.tataz.chchile.org> References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453E1FBC.5060700@freebsdbrasil.com.br> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2006 10:42:27 -0000 Hi Jean, On Tue, Oct 24, 2006 at 12:14:20PM -0200, Jean Milanez Melo wrote: > >What are you thinking about for inclusion of third-party apps on > >tinybsd ? I hope it won't bloat too much the code. > >Are you already expecting to provide it soon ? > > > > I would like to use pkg_add. Maybe a file called tinybsd.apps and the > users should add in this file what port name they want to install, so > it'll copy binaries installation to workdir. Suggestions? Well, this is a neat idea. However I think this is not homogeneous in regard to the current behaviour of TinyBSD: while the base system would still be included on a per-file basis, library dependencies being brought in automatically, using pkg_add(1) for third-party apps would lead to include the whole package, including manpages, documentation, configuration files along with the binaries. Moreover, this may not be a desirable behaviour for an embedded system. My feeling is that TinyBSD has used the KISS principle so far. The code as well as the configuration is somewhat raw (no offence here), but it is thereby easy to use, debug and modify at needs. I am going to code this in my source tree this afternoon and I will be glad to provide you the patch. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 13:03:21 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DBC016A47B for ; Wed, 25 Oct 2006 13:03:21 +0000 (UTC) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id C440A43D66 for ; Wed, 25 Oct 2006 13:03:18 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 2514 invoked by uid 0); 25 Oct 2006 11:03:40 -0200 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.149.10):. Processed in 0.527831 secs); 25 Oct 2006 13:03:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=capeta; d=freebsdbrasil.com.br; b=UeccwhnePsRLVu30KilgKGQmeM9C6yJmiojqXxPWoJ7qNRAD0Mf9K4GL6JaupuVS1CmQIQJ9O9AFQOpRRj3TF6KtpX4Gju0FdPqzvDFb7BxKpsNSWwJLSicRuK+h99H2 ; Received: from unknown (HELO ?10.69.69.66?) (jmelo@201.17.149.10) by capeta.freebsdbrasil.com.br with SMTP; 25 Oct 2006 11:03:40 -0200 Message-ID: <453F5271.70309@freebsdbrasil.com.br> Date: Wed, 25 Oct 2006 10:02:57 -0200 From: Jean Milanez Melo User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> <20061025104306.GI20405@obiwan.tataz.chchile.org> In-Reply-To: <20061025104306.GI20405@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2006 13:03:21 -0000 Jeremie Le Hen wrote: to workdir. Suggestions? > > Well, this is a neat idea. However I think this is not homogeneous in > regard to the current behaviour of TinyBSD: while the base system would > still be included on a per-file basis, library dependencies being > brought in automatically, using pkg_add(1) for third-party apps would > lead to include the whole package, including manpages, documentation, > configuration files along with the binaries. Moreover, this may not be > a desirable behaviour for an embedded system. > Yes, but my idea was install it on temporary directory and remove all unnecessary files. > My feeling is that TinyBSD has used the KISS principle so far. The code > as well as the configuration is somewhat raw (no offence here), but it is > thereby easy to use, debug and modify at needs. I am going to code this > in my source tree this afternoon and I will be glad to provide you the > patch. > That's right, make tinybsd simpler is really our idea :) Send to me your patch and i'll take a look. Thanks Jean From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 17:33:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF5C716A47B; Wed, 25 Oct 2006 17:33:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E24943D5D; Wed, 25 Oct 2006 17:33:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k9PHXRDm019571; Wed, 25 Oct 2006 13:33:29 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 25 Oct 2006 13:19:59 -0400 User-Agent: KMail/1.9.1 References: <20061022064322.GU53114@obiwan.tataz.chchile.org> <1161512742.71755.9.camel@localhost> <1161552443.41580.26.camel@genius.i.cz> In-Reply-To: <1161552443.41580.26.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610251320.00498.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Oct 2006 13:33:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2098/Wed Oct 25 09:14:20 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Michal Mertl , Jeremie Le Hen , Florent Thoumie Subject: Re: Cannot unload if_iwi module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2006 17:33:37 -0000 On Sunday 22 October 2006 17:27, Michal Mertl wrote: > Florent Thoumie wrote: > > On Sun, 2006-10-22 at 08:43 +0200, Jeremie Le Hen wrote: > > > Hi, > > > > > > when I try to unload if_iwi module, here is what happens: > > > > > > % jarjarbinks:/<3>dev/iwi:118# kldunload if_iwi > > > % iwi0: detached > > > % jarjarbinks:/<3>dev/iwi:119# iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 > > > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > > > % iwi0: [GIANT-LOCKED] > > > > > > The kld is reloaded automatically (I am sure it is reloaded because > > > the id showed in kldstat(8) changes each time): > > > > > > % jarjarbinks:/<1>share/mk:137# kldstat > > > % Id Refs Address Size Name > > > % 1 20 0xc0400000 4ef910 kernel > > > % 2 1 0xc08f0000 e5dc if_bge.ko > > > % 3 1 0xc08ff000 4ce4 ums.ko > > > % 4 1 0xc0904000 b180 umass.ko > > > % 5 2 0xc382e000 25000 linux.ko > > > % 6 1 0xc38cb000 2000 rtc.ko > > > % 9 1 0xc3acf000 e000 if_iwi.ko > > > % 10 2 0xc3add000 3000 firmware.ko > > > > > > % jarjarbinks:/<3>dev/iwi:122# kldstat > > > % Id Refs Address Size Name > > > % 1 19 0xc0400000 4ef910 kernel > > > % 2 1 0xc08f0000 e5dc if_bge.ko > > > % 3 1 0xc08ff000 4ce4 ums.ko > > > % 4 1 0xc0904000 b180 umass.ko > > > % 5 2 0xc382e000 25000 linux.ko > > > % 6 1 0xc38cb000 2000 rtc.ko > > > % 11 1 0xc3acf000 e000 if_iwi.ko > > > % 12 1 0xc3add000 3000 firmware.ko > > > > > > Any clue how to disable this unwanted behaviour ? > > > > No idea, but the same behavior can be seen with ipw(4) and experimental > > wpi(4). I seem to recall this didn't happen before the the support for > > firmware(9) was added. > > It also happens with em(4) to me. I found out it doesn't happen when > devd is not running. I find it rather strange that the 'pciconf -l' > command shows driver name (e.g. em0@pci...) even after (successfully and > permanently) unloading the module for a device. The 'devinfo' command > does not. I bet devd is running /etc/pccard_ether which tries to use ifconfig to down your interface, and when ifconfig em0 down happens, ifconfig notices if_em isn't in the kernel and tries to load it. Handy. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 17:33:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24FFC16A4B3 for ; Wed, 25 Oct 2006 17:33:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D99943D53 for ; Wed, 25 Oct 2006 17:33:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k9PHXRDn019571; Wed, 25 Oct 2006 13:33:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 25 Oct 2006 13:33:41 -0400 User-Agent: KMail/1.9.1 References: <20061023084839.GA4523@peter.osted.lan> In-Reply-To: <20061023084839.GA4523@peter.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610251333.42114.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Oct 2006 13:33:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2098/Wed Oct 25 09:14:20 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: Deadlock while testing on a 64 MB filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 17:33:43 -0000 On Monday 23 October 2006 04:48, Peter Holm wrote: > After some prodding by phk@ I made a test for problems seen with > "newfs -b 32768 -f 4096". > > http://people.freebsd.org/~pho/stress/log/cons218.html > > I was using these watchdog options: -t 900 -e 'ls /tmp /dev > /mnt > /dev/null; true' -s 60 and /mnt was the mount point for the test > filesystem. Looks like the root is held by 97785: 0xc61292a0: tag ufs, type VDIR usecount 35, writecount 0, refcount 39 mountedhere 0 flags (VV_ROOT) v_object 0xc5c2f9d8 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc47ea6c0 (pid 97785) with 12 pending And it is blocked on another lockmgr lock: 97785 997 97785 1001 S+ getblk 0xd7f43588 ls lockmgr(d7f43588,202122,c6129368,c47ea6c0) at lockmgr+0x46e getblk(c61292a0,0,0,1000,0,...) at getblk+0x12f breadn(c61292a0,0,0,1000,0,...) at breadn+0x2f bread(c61292a0,0,0,1000,0,...) at bread+0x20 ffs_read(e69f7bac) at ffs_read+0x23f Can you find the bp in getblk and print out the associated lock? I'm guessing it's share locked by someone else? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 19:22:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57A6816A403 for ; Wed, 25 Oct 2006 19:22:44 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 9040F43D45 for ; Wed, 25 Oct 2006 19:22:43 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 33846 invoked from network); 25 Oct 2006 19:22:40 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 25 Oct 2006 19:22:40 -0000 X-pair-Authenticated: 80.165.155.106 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id k9PJMdAv025901; Wed, 25 Oct 2006 21:22:39 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id k9PJMcIJ025900; Wed, 25 Oct 2006 21:22:38 +0200 (CEST) (envelope-from pho) Date: Wed, 25 Oct 2006 21:22:38 +0200 From: Peter Holm To: John Baldwin Message-ID: <20061025192238.GA25846@peter.osted.lan> References: <20061023084839.GA4523@peter.osted.lan> <200610251333.42114.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610251333.42114.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Deadlock while testing on a 64 MB filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 19:22:44 -0000 On Wed, Oct 25, 2006 at 01:33:41PM -0400, John Baldwin wrote: > On Monday 23 October 2006 04:48, Peter Holm wrote: > > After some prodding by phk@ I made a test for problems seen with > > "newfs -b 32768 -f 4096". > > > > http://people.freebsd.org/~pho/stress/log/cons218.html > > > > I was using these watchdog options: -t 900 -e 'ls /tmp /dev > > /mnt > /dev/null; true' -s 60 and /mnt was the mount point for the test > > filesystem. > > Looks like the root is held by 97785: > > 0xc61292a0: tag ufs, type VDIR > usecount 35, writecount 0, refcount 39 mountedhere 0 > flags (VV_ROOT) > v_object 0xc5c2f9d8 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc47ea6c0 (pid 97785) with 12 > pending > > And it is blocked on another lockmgr lock: > > 97785 997 97785 1001 S+ getblk 0xd7f43588 ls > > lockmgr(d7f43588,202122,c6129368,c47ea6c0) at lockmgr+0x46e > getblk(c61292a0,0,0,1000,0,...) at getblk+0x12f > breadn(c61292a0,0,0,1000,0,...) at breadn+0x2f > bread(c61292a0,0,0,1000,0,...) at bread+0x20 > ffs_read(e69f7bac) at ffs_read+0x23f > > Can you find the bp in getblk and print out the associated lock? I'm guessing > it's share locked by someone else? > I have updated cons218 with what I hope is the requested info. - Peter > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 19:46:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A001616A416; Wed, 25 Oct 2006 19:46:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC03A43D7B; Wed, 25 Oct 2006 19:46:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k9PJk9k6020493; Wed, 25 Oct 2006 15:46:15 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Peter Holm Date: Wed, 25 Oct 2006 15:45:52 -0400 User-Agent: KMail/1.9.1 References: <20061023084839.GA4523@peter.osted.lan> <200610251333.42114.jhb@freebsd.org> <20061025192238.GA25846@peter.osted.lan> In-Reply-To: <20061025192238.GA25846@peter.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610251545.53454.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Oct 2006 15:46:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2098/Wed Oct 25 09:14:20 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: Deadlock while testing on a 64 MB filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 19:46:22 -0000 On Wednesday 25 October 2006 15:22, Peter Holm wrote: > On Wed, Oct 25, 2006 at 01:33:41PM -0400, John Baldwin wrote: > > On Monday 23 October 2006 04:48, Peter Holm wrote: > > > After some prodding by phk@ I made a test for problems seen with > > > "newfs -b 32768 -f 4096". > > > > > > http://people.freebsd.org/~pho/stress/log/cons218.html > > > > > > I was using these watchdog options: -t 900 -e 'ls /tmp /dev > > > /mnt > /dev/null; true' -s 60 and /mnt was the mount point for the test > > > filesystem. > > > > Looks like the root is held by 97785: > > > > 0xc61292a0: tag ufs, type VDIR > > usecount 35, writecount 0, refcount 39 mountedhere 0 > > flags (VV_ROOT) > > v_object 0xc5c2f9d8 ref 0 pages 1 > > lock type ufs: EXCL (count 1) by thread 0xc47ea6c0 (pid 97785) with 12 > > pending > > > > And it is blocked on another lockmgr lock: > > > > 97785 997 97785 1001 S+ getblk 0xd7f43588 ls > > > > lockmgr(d7f43588,202122,c6129368,c47ea6c0) at lockmgr+0x46e > > getblk(c61292a0,0,0,1000,0,...) at getblk+0x12f > > breadn(c61292a0,0,0,1000,0,...) at breadn+0x2f > > bread(c61292a0,0,0,1000,0,...) at bread+0x20 > > ffs_read(e69f7bac) at ffs_read+0x23f > > > > Can you find the bp in getblk and print out the associated lock? I'm guessing > > it's share locked by someone else? > > > > I have updated cons218 with what I hope is the requested info. Ah, it's got one of those "bogus" owners: lk_lockholder = 0xfffffffe aka LK_KERNPROC. I don't grok enough buf/bio stuff to dive into this further. Maybe phk (cc'd) can help. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 25 23:58:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D5D16A54E for ; Wed, 25 Oct 2006 23:58:22 +0000 (UTC) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B0E6441F2 for ; Wed, 25 Oct 2006 23:27:50 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h136.244.159.dialup.iptcom.net ([213.159.244.136]:31190 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1221703AbWJYX1s (INRCPT ); Thu, 26 Oct 2006 02:27:48 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.8/8.13.8) with ESMTP id k9PNRjsb001301 for ; Thu, 26 Oct 2006 02:27:45 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Thu, 26 Oct 2006 02:27:45 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: current@freebsd.org Message-ID: <20061026015618.E1706@kushnir1.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Asus A8V hangs during pci probe on fresh -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 23:58:23 -0000 Hi, Sorry if this is unrelated, but my amd64 -CURRENT displays precisely the same symptoms: for some weeks it hangs with fresh kernels at pci5: on pcib1 HW: Athlon64, MB Asus A8N-SLI (nForce4 based), according to pciconf on pci5 it's got TV card (V-Streams, BT878) and fwohci: bktr0@pci5:6:0: class=0x040000 card=0x00000000 chip=0x036e109e rev=0x11 hdr=0x00 vendor = 'Conexant (Was: Brooktree Corp)' device = 'Bt878/Fusion 878A Mediastream Controller' class = multimedia subclass = video none2@pci5:6:1: class=0x048000 card=0x00000000 chip=0x0878109e rev=0x11 hdr=0x00 vendor = 'Conexant (Was: Brooktree Corp)' device = 'Bt878/Fusion878A Video Capture (Audio Section)' class = multimedia fwohci0@pci5:11:0: class=0x0c0010 card=0x808b1043 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB22/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class = serial bus subclass = FireWire Is there anything I could do to help fixing this? Regards, Vladimir From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 13:35:54 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8276E16A40F; Thu, 26 Oct 2006 13:35:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01DBE43D5D; Thu, 26 Oct 2006 13:35:53 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 74C2C4A0C8; Thu, 26 Oct 2006 15:35:52 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 0445E9E6C2; Thu, 26 Oct 2006 13:36:38 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id D3CC0405B; Thu, 26 Oct 2006 15:36:37 +0200 (CEST) Date: Thu, 26 Oct 2006 15:36:37 +0200 From: Jeremie Le Hen To: Jean Milanez Melo Message-ID: <20061026133637.GJ20405@obiwan.tataz.chchile.org> References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> <20061025104306.GI20405@obiwan.tataz.chchile.org> <453F5271.70309@freebsdbrasil.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453F5271.70309@freebsdbrasil.com.br> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@FreeBSD.org, freebsd-small@FreeBSD.org, Julian Elischer Subject: Re: [fbsd] Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 13:35:54 -0000 Hi Jean, On Wed, Oct 25, 2006 at 10:02:57AM -0200, Jean Milanez Melo wrote: > >My feeling is that TinyBSD has used the KISS principle so far. The code > >as well as the configuration is somewhat raw (no offence here), but it is > >thereby easy to use, debug and modify at needs. I am going to code this > >in my source tree this afternoon and I will be glad to provide you the > >patch. > > That's right, make tinybsd simpler is really our idea :) > > Send to me your patch and i'll take a look. The patch is attached and works pretty well for me. In addition to tinybsd.localfiles, I've made a few improvements: - I've moved the configuration filenames in a variable ; - When computing "sub-dependencies", use a temporary alternate file and then merge it back to the main dependency file ; - "chflags 0" files that are to be turned into symlinks before unlinking them ; - Handle /boot.config correctly in the configuration directory. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 13:37:15 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBFE216A412; Thu, 26 Oct 2006 13:37:15 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A58243D8F; Thu, 26 Oct 2006 13:36:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 932FF27ABD; Thu, 26 Oct 2006 15:36:56 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 22B199E6C5; Thu, 26 Oct 2006 13:37:42 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 17732405D; Thu, 26 Oct 2006 15:37:42 +0200 (CEST) Date: Thu, 26 Oct 2006 15:37:42 +0200 From: Jeremie Le Hen To: Jean Milanez Melo Message-ID: <20061026133742.GK20405@obiwan.tataz.chchile.org> References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> <20061025104306.GI20405@obiwan.tataz.chchile.org> <453F5271.70309@freebsdbrasil.com.br> <20061026133637.GJ20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline In-Reply-To: <20061026133637.GJ20405@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-small@FreeBSD.org, freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 13:37:15 -0000 --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline And the patch... On Thu, Oct 26, 2006 at 03:36:37PM +0200, Jeremie Le Hen wrote: > Hi Jean, > > On Wed, Oct 25, 2006 at 10:02:57AM -0200, Jean Milanez Melo wrote: > > >My feeling is that TinyBSD has used the KISS principle so far. The code > > >as well as the configuration is somewhat raw (no offence here), but it is > > >thereby easy to use, debug and modify at needs. I am going to code this > > >in my source tree this afternoon and I will be glad to provide you the > > >patch. > > > > That's right, make tinybsd simpler is really our idea :) > > > > Send to me your patch and i'll take a look. > > The patch is attached and works pretty well for me. > In addition to tinybsd.localfiles, I've made a few improvements: > - I've moved the configuration filenames in a variable ; > - When computing "sub-dependencies", use a temporary alternate file > and then merge it back to the main dependency file ; > - "chflags 0" files that are to be turned into symlinks before unlinking > them ; > - Handle /boot.config correctly in the configuration directory. > > Thank you. > Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tinybsd_localfiles.patch" Index: README =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/README,v retrieving revision 1.1 diff -u -p -r1.1 README --- README 20 Sep 2006 22:24:17 -0000 1.1 +++ README 26 Oct 2006 13:32:02 -0000 @@ -69,6 +69,10 @@ usr/sbin/pw usr/sbin/pwd_mkdb usr/sbin/setkey +tinybsd.localfiles: Similar to tinybsd.basefiles but for /usr/local/. The +difference is that directories will have to be created by TinyBSD because +they are not handle by mtree(1). + etc/: This is the directory where you can put your custom /etc configuration. # ls /usr/src/tools/tools/tinybsd/tinybsd Index: tinybsd =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/tinybsd,v retrieving revision 1.4 diff -u -p -r1.4 tinybsd --- tinybsd 11 Oct 2006 21:46:53 -0000 1.4 +++ tinybsd 26 Oct 2006 13:32:02 -0000 @@ -14,6 +14,8 @@ else fi WORKDIR=/usr/obj/tinybsdbuild KERNCONF=TINYBSD +BASEFILE="tinybsd.basefiles" +LOCALFILE="tinybsd.localfiles" DEFINSTARGS="-o 0 -g 0 -m 555" TS="=====>" @@ -262,10 +264,26 @@ create_tree() { mtree -deU -f /etc/mtree/BSD.var.dist -p ${WORKDIR}/var } +create_missingdirs() { + local LISTFILE DIR + LISTFILE=$1 + + for file in `cat $LISTFILE | grep -v "#" | cut -f1 -d":" | sort | uniq`; do + DIR=`dirname ${file}` + if [ ! -d ${WORKDIR}/${DIR} ]; then + echo "Non-standard directory created manually: ${DIR}." + mkdir -p ${WORKDIR}/${DIR} + fi + done +} + copy_binaries() { #set -xv - for file in `cat ${CURRENTDIR}/conf/${CONF}/tinybsd.basefiles | grep -v "#" | \ + cd ${CURRENTDIR}/conf/${CONF} + create_missingdirs ${LOCALFILE} + + for file in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | \ cut -f1 -d":" | sort | uniq` ; do echo "${TS} Copying "/${file}" to "${WORKDIR}/${file} cp -fp /${file} ${WORKDIR}/${file} ; @@ -289,24 +307,31 @@ make_kernel() { copy_libraries() { #set -xv - TDEPFILE="`mktemp -t deps`" - TDEPFILES="`mktemp -t depsymlnk`" + TDEPFILE="`mktemp -t deps.XXX`" + TDEPFILE2="`mktemp -t deps.XXX`" + TDEPFILES="`mktemp -t depsymlnk.XXX`" cd ${CURRENTDIR}/conf/${CONF} - for file in `cat tinybsd.basefiles | grep -v "#" | cut -f1 -d":"`; do + for file in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | cut -f1 -d":"`; do ldd -f "%p\n" /${file} >> ${TDEPFILE} ; # don't worry on progs been "not dynamic" done for libdeplib in `cat ${TDEPFILE} | sort | uniq`; do - ldd -f "%p\n" /${libdeplib} >> ${TDEPFILE} ; + ldd -f "%p\n" /${libdeplib} >> ${TDEPFILE2} ; done + cat ${TDEPFILE2} >> ${TDEPFILE} for pamdep in `ls -1 /usr/lib/pam*`; do echo $pamdep >> ${TDEPFILE} ; ldd -f "%p\n" /${pamdep} >> ${TDEPFILE} ; done + + cat ${TDEPFILE} | sort | uniq > ${TDEPFILE2} + mv -f ${TDEPFILE2} ${TDEPFILE} + + create_missingdirs ${TDEPFILE} - for lib in `cat ${TDEPFILE} | sort | uniq`; do + for lib in `cat ${TDEPFILE}`; do echo "${TS} Copying "${lib}" to "${WORKDIR}${lib} cp -fp ${lib} ${WORKDIR}${lib} ; done @@ -321,6 +346,7 @@ copy_libraries() { TARGET_FILE=`echo $i | awk -F ":" '{print $2}'` echo "${TS} Unlinking ${WORKDIR}${TARGET_FILE}" + chroot ${WORKDIR} /bin/chflags 0 ${TARGET_FILE} chroot ${WORKDIR} /bin/rm -f ${TARGET_FILE} echo "${TS} Symlinking ${SOURCE_FILE} to ${TARGET_FILE}" @@ -349,16 +375,20 @@ create_ssh_keys() { ssh-keygen -t rsa -f ${WORKDIR}/etc/ssh/ssh_host_rsa_key -N '' } -personal_directories() { +personal_conf() { echo "${TS} Copying your custom configuration on conf/ ..." - for custom in `find ${CURRENTDIR}/conf/${CONF}/ -type d -depth 1`; do + for custom in `find ${CURRENTDIR}/conf/${CONF}/ -type d -depth 1 \! -name CVS`; do cp -Rp ${custom}/* ${WORKDIR}/${custom#${CURRENTDIR}/conf/${CONF}/}/ done + + if [ -f ${CURRENTDIR}/conf/${CONF}/boot.config ]; then + cp ${CURRENTDIR}/conf/${CONF}/boot.config ${WORKDIR}/boot.config + fi } symlinks() { #set -xv - for i in `cat tinybsd.basefiles | grep -v "#" | grep ":"`; do + for i in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | grep ":"`; do SOURCE_FILE=`echo $i | awk -F ":" {'print $1'}` TARGET_FILE=`echo $i | awk -F ":" {'print $2'}` chroot ${WORKDIR} /bin/ln -vs /${SOURCE_FILE} ${TARGET_FILE} @@ -460,7 +502,7 @@ saveconfig symlinks create_etc create_ssh_keys - personal_directories + personal_conf create_image #set +xv ) 2>&1 |tee -a ${HOME}/tinybsd.log --MnLPg7ZWsaic7Fhd-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 16:28:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD33916A403 for ; Thu, 26 Oct 2006 16:28:01 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id BC6EC43D55 for ; Thu, 26 Oct 2006 16:28:00 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 54727 invoked from network); 26 Oct 2006 16:27:58 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 Oct 2006 16:27:58 -0000 X-pair-Authenticated: 80.165.155.106 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id k9QGRwq5064801 for ; Thu, 26 Oct 2006 18:27:58 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id k9QGRwpf064800 for current@freebsd.org; Thu, 26 Oct 2006 18:27:58 +0200 (CEST) (envelope-from pho) Date: Thu, 26 Oct 2006 18:27:57 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20061026162757.GA64673@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: panic: mutex Giant not owned at vfs_subr.c:1968 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 16:28:01 -0000 While stress testing as root with GENERIC HEAD from Oct 25 15:57 UTC with "option QUOTA" with a filesystem running full I consistently get this panic: Tracing pid 42 tid 100046 td 0xc3fc0870 kdb_enter(c091f1d0) at kdb_enter+0x2b panic(c091e4e9,c0935110,c0929621,7b0,2002,...) at panic+0x14b _mtx_assert(c0a1f408,1,c0929621,7b0) at _mtx_assert+0x66 vget(c583c930,2002,c3fc0870) at vget+0x4a vfs_hash_get(c5ee1000,4,2,c3fc0870,e43f4cd4,0,0) at vfs_hash_get+0x8d ffs_vget(c5ee1000,4,2,e43f4cd4,c0a79618,0,...) at ffs_vget+0x27 clear_remove(c3fc0870,0,c07d7538,c07d7538,0,...) at clear_remove+0xb3 softdep_flush(0,e43f4d38) at softdep_flush+0x73 fork_exit(c07d7538,0,e43f4d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 http://people.freebsd.org/~pho/stress/log/cons219.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 18:22:14 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA0B16A47E; Thu, 26 Oct 2006 18:22:13 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (vlsi00.si.noda.tus.ac.jp [133.31.130.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id E46AB43D8D; Thu, 26 Oct 2006 18:22:04 +0000 (GMT) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p2118-ipbf608funabasi.chiba.ocn.ne.jp [125.175.93.118]) (authenticated bits=128) by mail.allbsd.org (8.13.1/8.13.4) with ESMTP id k9QIJ0dH084207; Fri, 27 Oct 2006 03:19:13 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id k9QIIOUj027221; Fri, 27 Oct 2006 03:18:26 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 27 Oct 2006 02:56:00 +0900 (JST) Message-Id: <20061027.025600.59733168.hrs@allbsd.org> To: leafy7382@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 5.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct_27_02_56_00_2006_818)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.allbsd.org [133.31.130.32]); Fri, 27 Oct 2006 03:19:14 +0900 (JST) Cc: dougb@FreeBSD.org, ume@FreeBSD.org, Joel@FreeBSD.org, nork@FreeBSD.org, simon@FreeBSD.org, freebsd-current@FreeBSD.org, kris@obsecurity.org, itetcu@FreeBSD.org Subject: Re: Resolver not always resolving hostnames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 18:22:14 -0000 ----Security_Multipart(Fri_Oct_27_02_56_00_2006_818)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Jiawei Ye" wrote in : le> On 10/24/06, Hajimu UMEMOTO wrote: le> > leafy7382> This is much better. It would be great if this is commited. le> > le> > I've committed it into 7-CURRENT, and I'll MFC it into RELENG_6 after le> > 3 days. le> > le> > The fix should help in certain case. However, it seems doesn't help le> > for nork-san's case. He could reproduce it, and sent me his ktrace le> > output. As far as I can see his output, his local name server (BIND le> > 9.3.2-P1) returned the response with no answer record. As a result, le> > his csup ended up with following error: le> > le> > Name lookup failure for "cvsup.jp.freebsd.org": hostname nor le> > servname provided, or not known le> > le> > I suspect that the BIND9's named have some problem. le> > le> > "Name lookup failure for "cvsup.jp.freebsd.org": hostname nor servname \ le> > provided, or not known le> > " le> > Sincerely, le> > le> > -- le> > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan le> You are correct, I just ran into that a few times in the last hour. le> But it is a lot less frequent than before. I also run a local BIND9 le> for our company. I think some commits happening after between Sept 30 le> and Oct 15th caused it, because I did not see such symptom before late le> Sept and I rebuilt my system around mid Oct. According to log files on my public cvsup server which is suffering from this problem, this happened on 22 September at least. I have not looked into the source files closely yet, but is it possible that the 9.3.2-P1 patch has a bug that can return 0/0/0 with NOERROR answer packet? I confirmed that behaviors of 4.x's resolver and 6.x's against such a malformed packet are the same, so I think it is not likely a bug in the resolver. -- | Hiroki SATO ----Security_Multipart(Fri_Oct_27_02_56_00_2006_818)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBFQPayTyzT2CeTzy0RAr7xAJ4jMCI1Qw1Uan2np1vCeR37PlcxzQCgiXxZ XxIDFMuHYvw0PpWLEDr+W5I= =Qpjj -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct_27_02_56_00_2006_818)---- From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 21:32:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE7C16A403 for ; Thu, 26 Oct 2006 21:32:17 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1612D43D4C for ; Thu, 26 Oct 2006 21:32:17 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 087BC140EC03; Thu, 26 Oct 2006 21:33:43 +0000 (GMT) Date: Thu, 26 Oct 2006 21:33:43 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20061026213343.GA29160@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 21:32:17 -0000 If you use a GENERIC kernel, then this change won't affect you because the KSE option will be on by default in GENERIC on all arches/machines except sun4v (which doesn't handle signals properly with the KSE code in the kernel). If you use a custom kernel, you need to add 'options KSE' to your kernel config to continue to use libpthread. If you use libmap to map libpthread.so.2 to libthr.so.2, then you can use a kernel with or without 'options KSE'. KSE has been declared as a kernel option in src/sys/conf/options for a while now, so even though I haven't committed any files which use it, you can add it to your kernel config right now so that you are ready for when the cvs changes make their way out to the cvsup mirrors. I am planning on getting DTrace into current by the end of this year and one of the first things I want to use it for is to measure the differences between libpthread and libthr to see where we suck compared to Linux and Solaris. To date people have anecdotal tales to tell about one being better than the other, but we haven't had a good way to measure exactly what it is that is causing the poor relative performance. With this change, it is possible to build a GENERIC kernel (with KSE support) and a !KSE kernel and alternately boot between the two while using the exact same installed ports of your favourite threaded applications. Hopefully, if you care about threaded performance in FreeBSD, you will be prepared to help run DTrace (when it becomes available) on _your_ system the way _you_ like it to measure which thread implementation is better for _you_. Out of this I hope to determine which thread implementation deserves to be the default, and possibly conclude that one thread implementation doesn't stand up in comparison with Linux and Solaris. I also hope to get enough info to write a paper about the use of DTrace in FreeBSD, possibly for BSDcan 2007. I realise that the source changes to make KSE a kernel option will offend some people because they are essentially a lot of #ifdefs. This is deliberate because it shows what code would remain if KSE support was to be ripped from the kernel. Yes, the code will be more complex to maintain. -- John Birrell (with flame suit on) From owner-freebsd-current@FreeBSD.ORG Thu Oct 26 23:32:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7440116A403 for ; Thu, 26 Oct 2006 23:32:01 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A77843D53 for ; Thu, 26 Oct 2006 23:32:01 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 96153140EC03; Thu, 26 Oct 2006 23:33:30 +0000 (GMT) Date: Thu, 26 Oct 2006 23:33:30 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20061026233330.GC29909@what-creek.com> References: <20061026213343.GA29160@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061026213343.GA29160@what-creek.com> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2006 23:32:01 -0000 [ replying to myself ] On Thu, Oct 26, 2006 at 09:33:43PM +0000, John Birrell wrote: > If you use a GENERIC kernel, then this change won't affect you > because the KSE option will be on by default in GENERIC on > all arches/machines except sun4v (which doesn't handle signals > properly with the KSE code in the kernel). scottl persuaded me to add the KSE option to DEFAULTS on all arches/machines (except sun4v) to avoid causing the same problem that the io/mem change from default to optional caused. This means that ou will get KSE by default in your kernel (as before it was an option) _unless_ you use add 'nooption KSE' to your kernel config. This isn't my preferred solution because it makes it too transparent, however scottl's point is that unnecessary grief will be caused if the change isn't completely transparent. Sorry for the confusion. And BTW, the commits are all in current now...and coming to a cvsup server near you. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 00:51:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3E03F16A40F; Fri, 27 Oct 2006 00:51:44 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Fri, 27 Oct 2006 08:51:39 +0800 User-Agent: KMail/1.8.2 References: <20061026213343.GA29160@what-creek.com> <20061026233330.GC29909@what-creek.com> In-Reply-To: <20061026233330.GC29909@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610270851.39444.davidxu@freebsd.org> Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 00:51:44 -0000 On Friday 27 October 2006 07:33, John Birrell wrote: > [ replying to myself ] > > On Thu, Oct 26, 2006 at 09:33:43PM +0000, John Birrell wrote: > > If you use a GENERIC kernel, then this change won't affect you > > because the KSE option will be on by default in GENERIC on > > all arches/machines except sun4v (which doesn't handle signals > > properly with the KSE code in the kernel). > > scottl persuaded me to add the KSE option to DEFAULTS on all > arches/machines (except sun4v) to avoid causing the same problem > that the io/mem change from default to optional caused. > > This means that ou will get KSE by default in your kernel (as > before it was an option) _unless_ you use add 'nooption KSE' > to your kernel config. > > This isn't my preferred solution because it makes it too > transparent, however scottl's point is that unnecessary grief > will be caused if the change isn't completely transparent. > > Sorry for the confusion. > > And BTW, the commits are all in current now...and coming to > a cvsup server near you. > > -- > John Birrell By compiling kernel without KSE option, super-smack's select-key.smack with 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise it can only get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. David Xu From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 00:51:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3E03F16A40F; Fri, 27 Oct 2006 00:51:44 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Fri, 27 Oct 2006 08:51:39 +0800 User-Agent: KMail/1.8.2 References: <20061026213343.GA29160@what-creek.com> <20061026233330.GC29909@what-creek.com> In-Reply-To: <20061026233330.GC29909@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610270851.39444.davidxu@freebsd.org> Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 00:51:44 -0000 On Friday 27 October 2006 07:33, John Birrell wrote: > [ replying to myself ] > > On Thu, Oct 26, 2006 at 09:33:43PM +0000, John Birrell wrote: > > If you use a GENERIC kernel, then this change won't affect you > > because the KSE option will be on by default in GENERIC on > > all arches/machines except sun4v (which doesn't handle signals > > properly with the KSE code in the kernel). > > scottl persuaded me to add the KSE option to DEFAULTS on all > arches/machines (except sun4v) to avoid causing the same problem > that the io/mem change from default to optional caused. > > This means that ou will get KSE by default in your kernel (as > before it was an option) _unless_ you use add 'nooption KSE' > to your kernel config. > > This isn't my preferred solution because it makes it too > transparent, however scottl's point is that unnecessary grief > will be caused if the change isn't completely transparent. > > Sorry for the confusion. > > And BTW, the commits are all in current now...and coming to > a cvsup server near you. > > -- > John Birrell By compiling kernel without KSE option, super-smack's select-key.smack with 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise it can only get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. David Xu From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 00:56:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D116A5C5; Fri, 27 Oct 2006 00:56:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0997643D7F; Fri, 27 Oct 2006 00:55:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9R0tKgJ003930; Thu, 26 Oct 2006 18:55:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <454158F8.9010200@samsco.org> Date: Thu, 26 Oct 2006 18:55:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: David Xu References: <20061026213343.GA29160@what-creek.com> <20061026233330.GC29909@what-creek.com> <200610270851.39444.davidxu@freebsd.org> In-Reply-To: <200610270851.39444.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org, John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 00:56:56 -0000 David Xu wrote: > On Friday 27 October 2006 07:33, John Birrell wrote: >> [ replying to myself ] >> >> On Thu, Oct 26, 2006 at 09:33:43PM +0000, John Birrell wrote: >>> If you use a GENERIC kernel, then this change won't affect you >>> because the KSE option will be on by default in GENERIC on >>> all arches/machines except sun4v (which doesn't handle signals >>> properly with the KSE code in the kernel). >> scottl persuaded me to add the KSE option to DEFAULTS on all >> arches/machines (except sun4v) to avoid causing the same problem >> that the io/mem change from default to optional caused. >> >> This means that ou will get KSE by default in your kernel (as >> before it was an option) _unless_ you use add 'nooption KSE' >> to your kernel config. >> >> This isn't my preferred solution because it makes it too >> transparent, however scottl's point is that unnecessary grief >> will be caused if the change isn't completely transparent. >> >> Sorry for the confusion. >> >> And BTW, the commits are all in current now...and coming to >> a cvsup server near you. >> >> -- >> John Birrell > > By compiling kernel without KSE option, super-smack's select-key.smack with > 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise it can only > get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. > I assume that you were using libthr for both the before and after tests? Scott From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 00:56:56 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D116A5C5; Fri, 27 Oct 2006 00:56:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0997643D7F; Fri, 27 Oct 2006 00:55:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9R0tKgJ003930; Thu, 26 Oct 2006 18:55:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <454158F8.9010200@samsco.org> Date: Thu, 26 Oct 2006 18:55:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: David Xu References: <20061026213343.GA29160@what-creek.com> <20061026233330.GC29909@what-creek.com> <200610270851.39444.davidxu@freebsd.org> In-Reply-To: <200610270851.39444.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org, John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 00:56:56 -0000 David Xu wrote: > On Friday 27 October 2006 07:33, John Birrell wrote: >> [ replying to myself ] >> >> On Thu, Oct 26, 2006 at 09:33:43PM +0000, John Birrell wrote: >>> If you use a GENERIC kernel, then this change won't affect you >>> because the KSE option will be on by default in GENERIC on >>> all arches/machines except sun4v (which doesn't handle signals >>> properly with the KSE code in the kernel). >> scottl persuaded me to add the KSE option to DEFAULTS on all >> arches/machines (except sun4v) to avoid causing the same problem >> that the io/mem change from default to optional caused. >> >> This means that ou will get KSE by default in your kernel (as >> before it was an option) _unless_ you use add 'nooption KSE' >> to your kernel config. >> >> This isn't my preferred solution because it makes it too >> transparent, however scottl's point is that unnecessary grief >> will be caused if the change isn't completely transparent. >> >> Sorry for the confusion. >> >> And BTW, the commits are all in current now...and coming to >> a cvsup server near you. >> >> -- >> John Birrell > > By compiling kernel without KSE option, super-smack's select-key.smack with > 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise it can only > get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. > I assume that you were using libthr for both the before and after tests? Scott From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 00:58:50 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46ECF16A40F; Fri, 27 Oct 2006 00:58:50 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2E9743E3E; Fri, 27 Oct 2006 00:56:10 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id BF799140EC06; Fri, 27 Oct 2006 00:57:33 +0000 (GMT) Date: Fri, 27 Oct 2006 00:57:33 +0000 From: John Birrell To: David Xu Message-ID: <20061027005733.GA31389@what-creek.com> References: <20061026213343.GA29160@what-creek.com> <20061026233330.GC29909@what-creek.com> <200610270851.39444.davidxu@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610270851.39444.davidxu@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 00:58:50 -0000 On Fri, Oct 27, 2006 at 08:51:39AM +0800, David Xu wrote: > By compiling kernel without KSE option, super-smack's select-key.smack with > 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise it can only > get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. So that must be the difference in context switch time? -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 02:02:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B0AC16A40F; Fri, 27 Oct 2006 02:02:33 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Fri, 27 Oct 2006 10:02:27 +0800 User-Agent: KMail/1.8.2 References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <454158F8.9010200@samsco.org> In-Reply-To: <454158F8.9010200@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610271002.28006.davidxu@freebsd.org> Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 02:02:33 -0000 On Friday 27 October 2006 08:55, Scott Long wrote: > > By compiling kernel without KSE option, super-smack's select-key.smack > > with 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise > > it can only get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. > > I assume that you were using libthr for both the before and after tests? > > Scott Yes, you are right. David Xu From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 02:02:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B0AC16A40F; Fri, 27 Oct 2006 02:02:33 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Fri, 27 Oct 2006 10:02:27 +0800 User-Agent: KMail/1.8.2 References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <454158F8.9010200@samsco.org> In-Reply-To: <454158F8.9010200@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610271002.28006.davidxu@freebsd.org> Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 02:02:33 -0000 On Friday 27 October 2006 08:55, Scott Long wrote: > > By compiling kernel without KSE option, super-smack's select-key.smack > > with 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise > > it can only get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. > > I assume that you were using libthr for both the before and after tests? > > Scott Yes, you are right. David Xu From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 02:06:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9197216A47B; Fri, 27 Oct 2006 02:06:43 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: John Birrell Date: Fri, 27 Oct 2006 10:06:38 +0800 User-Agent: KMail/1.8.2 References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <20061027005733.GA31389@what-creek.com> In-Reply-To: <20061027005733.GA31389@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610271006.38851.davidxu@freebsd.org> Cc: current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 02:06:43 -0000 On Friday 27 October 2006 08:57, John Birrell wrote: > On Fri, Oct 27, 2006 at 08:51:39AM +0800, David Xu wrote: > > By compiling kernel without KSE option, super-smack's select-key.smack > > with 10 clients on Athlon64 dual-core 3800+ breaks 31000 q/s, otherwise > > it can only get 29000 q/s. Mysql version is 5.0.24a, FreeBSD AMD64. > > So that must be the difference in context switch time? > > -- > John Birrell I assume that without KSE, the scheduler's code size is reduced, this saves I-CACHE and execution time. David Xu From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 06:20:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E1216A417 for ; Fri, 27 Oct 2006 06:20:42 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id A691843D58 for ; Fri, 27 Oct 2006 06:20:41 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so534300uge for ; Thu, 26 Oct 2006 23:20:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ThPGYjbaMgYdcl4tBkxuGcbhZfIdOea9GxE0oJ45Sbj6HOdFgBBs4VH2i0h2aV0QtbxjiUZsumpaxr1gogXYyDGe28atv4VUmsrvJHqb/BwS43jLXHKoGhHUESoYQvcNxRuxK+nJlqzSv+rmoPYoMXT81wEvrbWdLuJViMA3TE0= Received: by 10.67.119.13 with SMTP id w13mr4412701ugm; Thu, 26 Oct 2006 23:20:40 -0700 (PDT) Received: by 10.66.254.4 with HTTP; Thu, 26 Oct 2006 23:20:40 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 14:20:40 +0800 From: "Jiawei Ye" To: "David Xu" In-Reply-To: <200610271006.38851.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <20061027005733.GA31389@what-creek.com> <200610271006.38851.davidxu@freebsd.org> Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 06:20:43 -0000 On 10/27/06, David Xu wrote: > I assume that without KSE, the scheduler's code size is reduced, this saves > I-CACHE and execution time. > > David Xu Is SCHED_CORE compatible with this change? I get cc -c -mtune=pentium4 -march=pentium2 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/kern/sched_core.c /usr/src/sys/kern/sched_core.c:356: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:356: warning: its scope is only this definition or declaration, which is probably not what you want /usr/src/sys/kern/sched_core.c:372: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:374: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:618: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:619: error: conflicting types for 'sched_is_timeshare' /usr/src/sys/kern/sched_core.c:372: error: previous declaration of 'sched_is_timeshare' was here /usr/src/sys/kern/sched_core.c:619: error: conflicting types for 'sched_is_timeshare' /usr/src/sys/kern/sched_core.c:372: error: previous declaration of 'sched_is_timeshare' was here /usr/src/sys/kern/sched_core.c: In function `sched_is_timeshare': /usr/src/sys/kern/sched_core.c:620: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c: At top level: /usr/src/sys/kern/sched_core.c:624: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:625: error: conflicting types for 'sched_calc_pri' /usr/src/sys/kern/sched_core.c:374: error: previous declaration of 'sched_calc_pri' was here /usr/src/sys/kern/sched_core.c:625: error: conflicting types for 'sched_calc_pri' /usr/src/sys/kern/sched_core.c:374: error: previous declaration of 'sched_calc_pri' was here /usr/src/sys/kern/sched_core.c: In function `sched_calc_pri': /usr/src/sys/kern/sched_core.c:629: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:630: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:630: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:637: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c: In function `sched_recalc_pri': /usr/src/sys/kern/sched_core.c:647: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:649: warning: passing arg 1 of `sched_is_timeshare' from incompatible pointer type /usr/src/sys/kern/sched_core.c:650: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:661: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:663: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:671: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:673: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:675: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:683: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:686: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:687: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:691: warning: passing arg 1 of `sched_calc_pri' from incompatible pointer type /usr/src/sys/kern/sched_core.c: In function `sched_update_runtime': /usr/src/sys/kern/sched_core.c:698: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:700: warning: passing arg 1 of `sched_is_timeshare' from incompatible pointer type /usr/src/sys/kern/sched_core.c:708: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:709: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c: In function `sched_commit_runtime': /usr/src/sys/kern/sched_core.c:717: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:719: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:719: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:720: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:722: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:722: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:723: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c: In function `schedinit': /usr/src/sys/kern/sched_core.c:815: error: `ksegrp0' undeclared (first use in this function) /usr/src/sys/kern/sched_core.c:815: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/sched_core.c:815: error: for each function it appears in.) /usr/src/sys/kern/sched_core.c: In function `sched_unlend_prio': /usr/src/sys/kern/sched_core.c:911: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c: In function `sched_prio': /usr/src/sys/kern/sched_core.c:926: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c: At top level: /usr/src/sys/kern/sched_core.c:952: warning: "struct ksegrp" declared inside parameter list /usr/src/sys/kern/sched_core.c:953: error: conflicting types for 'sched_user_prio' /usr/src/sys/sys/sched.h:83: error: previous declaration of 'sched_user_prio' was here /usr/src/sys/kern/sched_core.c:953: error: conflicting types for 'sched_user_prio' /usr/src/sys/sys/sched.h:83: error: previous declaration of 'sched_user_prio' was here /usr/src/sys/kern/sched_core.c: In function `sched_user_prio': /usr/src/sys/kern/sched_core.c:957: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:961: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:963: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:967: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:970: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:971: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c: In function `sched_lend_user_prio': /usr/src/sys/kern/sched_core.c:984: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:985: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c: In function `sched_unlend_user_prio': /usr/src/sys/kern/sched_core.c:994: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:997: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sched_core.c:1000: warning: passing arg 1 of `sched_user_prio' from incompatible pointer type /usr/src/sys/kern/sched_core.c: In function `sched_switch': /usr/src/sys/kern/sched_core.c:1017: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:1030: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:1039: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:1039: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:1046: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c:1057: error: structure has no member named `td_ksegrp' /usr/src/sys/kern/sched_core.c: In function `sched_nice': /usr/src/sys/kern/sched_core.c:1094: warning: implicit declaration of function `FOREACH_KSEGRP_IN_PROC' /usr/src/sys/kern/sched_core.c:1094: warning: nested extern declaration of `FOREACH_KSEGRP_IN_PROC' /usr/src/sys/kern/sched_core.c:1094: error: syntax error before '{' token /usr/src/sys/kern/sched_core.c:1097: warning: implicit declaration of function `FOREACH_THREAD_IN_GROUP' /usr/src/sys/kern/sched_core.c:1097: warning: nested extern declaration of `FOREACH_THREAD_IN_GROUP' /usr/src/sys/kern/sched_core.c:1098: error: syntax error before "td" /usr/src/sys/kern/sched_core.c: At top level: /usr/src/sys/kern/sched_core.c:356: warning: 'slot_fill' declared `static' but never defined /usr/src/sys/kern/sched_core.c:578: warning: 'kseq_choose' defined but not used /usr/src/sys/kern/sched_core.c:372: warning: 'sched_is_timeshare' declared `static' but never defined /usr/src/sys/kern/sched_core.c:373: warning: 'sched_choose' declared `static' but never defined /usr/src/sys/kern/sched_core.c:374: warning: 'sched_calc_pri' declared `static' but never defined /usr/src/sys/kern/sched_core.c:375: warning: 'sched_starving' declared `static' but never defined /usr/src/sys/kern/sched_core.c:837: warning: 'sched_pctcpu_update' defined but not used /usr/src/sys/kern/sched_core.c:642: warning: 'sched_recalc_pri' defined but not used /usr/src/sys/kern/sched_core.c:716: warning: 'sched_commit_runtime' defined but not used /usr/src/sys/kern/sched_core.c:433: warning: 'krunq_check' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/MAIL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Jiawei Ye -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 06:23:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 27E8B16A403; Fri, 27 Oct 2006 06:22:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4541A5BB.8080908@freebsd.org> Date: Fri, 27 Oct 2006 14:22:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060725 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <20061027005733.GA31389@what-creek.com> <200610271006.38851.davidxu@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: John Birrell , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 06:23:01 -0000 Jiawei Ye wrote: > On 10/27/06, David Xu wrote: > >> I assume that without KSE, the scheduler's code size is reduced, this >> saves >> I-CACHE and execution time. >> >> David Xu > > Is SCHED_CORE compatible with this change? I get > I will fix it. From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 06:26:51 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9775F16A416 for ; Fri, 27 Oct 2006 06:26:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from relay1.wplus.net (relay1.wplus.net [195.131.52.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C3243D5C for ; Fri, 27 Oct 2006 06:26:50 +0000 (GMT) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru ([89.163.10.141]) by relay1.wplus.net (8.13.6/8.13.1/RELAY-DVD) with ESMTP id k9R6QiAo038751 for ; Fri, 27 Oct 2006 10:26:49 +0400 (MSD) Date: Fri, 27 Oct 2006 10:26:47 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v2.11.02) Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <917908193.20061027102647@serebryakov.spb.ru> To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lev Serebryakov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 06:26:51 -0000 Hello , I've was sure, that both libpthread and libthr use KSE to make multithreading. They use KSE in different ways: libpthread uses N:M model and libthr uses 1:1 model, but bot use KSE to work. How will be possible to sue these libraries (read: multithreaded programs) when KSE will be optional, on kernel without KSE?! -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 06:36:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B19E316A407; Fri, 27 Oct 2006 06:36:15 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A64143D46; Fri, 27 Oct 2006 06:36:15 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 44A13140EC03; Fri, 27 Oct 2006 06:37:44 +0000 (GMT) Date: Fri, 27 Oct 2006 06:37:44 +0000 From: John Birrell To: David Xu Message-ID: <20061027063744.GA33708@what-creek.com> References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <20061027005733.GA31389@what-creek.com> <200610271006.38851.davidxu@freebsd.org> <4541A5BB.8080908@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4541A5BB.8080908@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Jiawei Ye , current@freebsd.org Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 06:36:15 -0000 On Fri, Oct 27, 2006 at 02:22:51PM +0800, David Xu wrote: > Jiawei Ye wrote: > >On 10/27/06, David Xu wrote: > > > >>I assume that without KSE, the scheduler's code size is reduced, this > >>saves > >>I-CACHE and execution time. > >> > >>David Xu > > > >Is SCHED_CORE compatible with this change? I get > > > > I will fix it. Thanks. I deliberately left it out of my changes so that you could use it as a platform to optimise the !KSE/libthr case without KSE getting in the way for once. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 08:57:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13BC216A49E for ; Fri, 27 Oct 2006 08:57:44 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DD343D64 for ; Fri, 27 Oct 2006 08:57:34 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdNWQ-0000o5-Gw for freebsd-current@freebsd.org; Fri, 27 Oct 2006 10:57:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 10:57:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 10:57:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 27 Oct 2006 10:56:21 +0200 Lines: 7 Message-ID: References: <917908193.20061027102647@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <917908193.20061027102647@serebryakov.spb.ru> Sender: news Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 08:57:44 -0000 Lev Serebryakov wrote: > Hello , > > I've was sure, that both libpthread and libthr use KSE to make multithreading. They use KSE in different ways: libpthread uses N:M model and libthr uses 1:1 model, but bot use KSE to work. > How will be possible to use these libraries (read: multithreaded programs) when KSE will be optional, on kernel without KSE?! Yes, isn't KSE by definition "that thing that is scheduled in the kernel"? From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 09:50:36 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BEC016A49E for ; Fri, 27 Oct 2006 09:50:36 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C5EF43DD5 for ; Fri, 27 Oct 2006 09:49:32 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id E84856169; Fri, 27 Oct 2006 13:49:20 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id BC0E760EC; Fri, 27 Oct 2006 13:49:20 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9R9nMlM007858; Fri, 27 Oct 2006 13:49:22 +0400 (MSD) (envelope-from ru) Date: Fri, 27 Oct 2006 13:49:22 +0400 From: Ruslan Ermilov To: Ivan Voras Message-ID: <20061027094922.GC6613@rambler-co.ru> References: <917908193.20061027102647@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-current@FreeBSD.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 09:50:36 -0000 --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 27, 2006 at 10:56:21AM +0200, Ivan Voras wrote: > Lev Serebryakov wrote: > >Hello , > > > > I've was sure, that both libpthread and libthr use KSE to make=20 > > multithreading. They use KSE in different ways: libpthread uses N:M= =20 > > model and libthr uses 1:1 model, but bot use KSE to work. > > How will be possible to use these libraries (read: multithreaded=20 > > programs) when KSE will be optional, on kernel without KSE?! >=20 > Yes, isn't KSE by definition "that thing that is scheduled in the kernel"? >=20 KSE =3D=3D N:M threading A 1:1 threading (libthr) is much simpler than N:M threading (libpthread), and thus doesn't require KSE support in the kernel; see kse(2) manpage for details. Without the KSE option in the kernel, all kse(2) syscalls will return EOPNOTSUPP, and a lot of code becomes redundant. : /* : * Initialize global thread allocation resources. : */ : void : threadinit(void) : { :=20 : mtx_init(&tid_lock, "TID lock", NULL, MTX_DEF); : tid_unrhdr =3D new_unrhdr(PID_MAX + 1, INT_MAX, &tid_lock); :=20 : thread_zone =3D uma_zcreate("THREAD", sched_sizeof_thread(), : thread_ctor, thread_dtor, thread_init, thread_fini, : UMA_ALIGN_CACHE, 0); : #ifdef KSE : ksegrp_zone =3D uma_zcreate("KSEGRP", sched_sizeof_ksegrp(), : ksegrp_ctor, NULL, NULL, NULL, : UMA_ALIGN_CACHE, 0); : kseinit(); /* set up kse specific stuff e.g. upcall zone*/ : #endif : } Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFQdYiqRfpzJluFF4RApfUAJ9Q/CXmYqRCBcZ/uhZsn3a0BOMEuwCgjSwZ 8wMPpRfHKZOwXwYdtQrIv+w= =18KX -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 13:02:59 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFC7516A407; Fri, 27 Oct 2006 13:02:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3D043D53; Fri, 27 Oct 2006 13:02:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 57D8546D20; Fri, 27 Oct 2006 09:02:59 -0400 (EDT) Date: Fri, 27 Oct 2006 14:02:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lev Serebryakov In-Reply-To: <917908193.20061027102647@serebryakov.spb.ru> Message-ID: <20061027103924.F79313@fledge.watson.org> References: <917908193.20061027102647@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 13:02:59 -0000 On Fri, 27 Oct 2006, Lev Serebryakov wrote: > I've was sure, that both libpthread and libthr use KSE to make > multithreading. They use KSE in different ways: libpthread uses N:M model > and libthr uses 1:1 model, but bot use KSE to work. > How will be possible to sue these libraries (read: multithreaded programs) > when KSE will be optional, on kernel without KSE?! The answer to that rather critical question, not surprisingly, is complex. :-) The FreeBSD kernel actually implements a good three different threading models (at least): (1) Linux threads/rfork threads. These are based on the idea of multiple "struct proc"s floating around with varying degrees of sharing. Typically, they share file descriptor array, address space, etc. For those familiar with the Linux clone() system call, rfork() is notionally very similar. This model implies 1:1 threading, and leaves quite a bit to be desired in terms of overhead, as well as having some odd implications for POSIX-like compliance (i.e., the implementation of getpid()). (2) KSE. This provides a kernel<->userspace threading framework allowing the implementation of a broad array of threading and scheduling models. This is a fairly complex, but very flexible model, which has several levels of layering required to implement different scheduling policies using M:N threading. Notice that 1:1 scheduling is a subset of M:N, so you can implement 1:1 in this manner. One of the significant concerns about KSE is that it adds a great deal of complexity to the kernel scheduler architecture, making it quite difficult to optimize, further granularize the locking for, understand, etc. (3) thr. This is a simpler 1:1 threading API to the kernel, which make use of the same architectural structures present in the kernel for KSE, but without the full capability of M:N threading. In particular, it has simplifying assumptions regarding how user threads enter the kernel and are mapped into kernel threads, so doesn't need an upcall mechanism, or create new threads when an existing thread sleeps. The NO_KSE patch disables the code paths required only for (2), not for (1) or (3). One of the current theories bouncing around the kernel developer community is that the complexity and overhead of (2) outweighs many of the benefits of KSE, and that by making it an option, we can better evaluate the impact. Notice that this isn't just about code complexity, but also about scheduler overhead. David Xu has reported a non-trivial performance change from the reduced overhead of the scheduler paths. So now we're at a point where we can more fully evaluate the impact of KSE (since we can actually compile it out of the scheduler). Before anything further can be done, we now need to do that evaluation. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 13:07:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5F16A403 for ; Fri, 27 Oct 2006 13:07:45 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D9D343D69 for ; Fri, 27 Oct 2006 13:07:41 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdRQm-00025p-GN for freebsd-current@freebsd.org; Fri, 27 Oct 2006 15:07:28 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 15:07:28 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 15:07:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 27 Oct 2006 15:06:16 +0200 Lines: 16 Message-ID: References: <917908193.20061027102647@serebryakov.spb.ru> <20061027094922.GC6613@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <20061027094922.GC6613@rambler-co.ru> Sender: news Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 13:07:45 -0000 Ruslan Ermilov wrote: > On Fri, Oct 27, 2006 at 10:56:21AM +0200, Ivan Voras wrote: >> Lev Serebryakov wrote: >>> Hello , >>> >>> I've was sure, that both libpthread and libthr use KSE to make >>> multithreading. They use KSE in different ways: libpthread uses N:M >>> model and libthr uses 1:1 model, but bot use KSE to work. >>> How will be possible to use these libraries (read: multithreaded >>> programs) when KSE will be optional, on kernel without KSE?! >> Yes, isn't KSE by definition "that thing that is scheduled in the kernel"? >> > KSE == N:M threading Ok, I thought it was threading in general on FreeBSD, and libthr just mapped one KSE to one thread. From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 13:43:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 753E716A47B for ; Fri, 27 Oct 2006 13:43:25 +0000 (UTC) (envelope-from nuno.antunes@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id F39BD43D5A for ; Fri, 27 Oct 2006 13:43:23 +0000 (GMT) (envelope-from nuno.antunes@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1290927nfc for ; Fri, 27 Oct 2006 06:43:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A0T/QLPIVz5RpstIso3wZpXROitHe5ssXgDVjEDvJqbjpy5pZiiMEMBHHPiMRoNnF+H/3kIYeMerUJPtu5Udvb5vnC1h+JmJkwJ0tKyi6T/6ZUBgflD/YR3NMjjGhDI/Fcr4+KqkLjFSl64iAnFblnVbhF5pqoyC+k8s69MMk1w= Received: by 10.48.202.19 with SMTP id z19mr897263nff; Fri, 27 Oct 2006 06:43:22 -0700 (PDT) Received: by 10.49.81.16 with HTTP; Fri, 27 Oct 2006 06:43:21 -0700 (PDT) Message-ID: <262949390610270643i3ce7e9f6k35862587ac546d52@mail.gmail.com> Date: Fri, 27 Oct 2006 14:43:21 +0100 From: "Nuno Antunes" To: "Ruslan Ermilov" In-Reply-To: <20061027094922.GC6613@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <917908193.20061027102647@serebryakov.spb.ru> <20061027094922.GC6613@rambler-co.ru> Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 13:43:25 -0000 On 10/27/06, Ruslan Ermilov wrote: > KSE == N:M threading > > A 1:1 threading (libthr) is much simpler than N:M threading (libpthread), > and thus doesn't require KSE support in the kernel; see kse(2) manpage > for details. Without the KSE option in the kernel, all kse(2) syscalls > will return EOPNOTSUPP, and a lot of code becomes redundant. > IIRC, I can even remember libpthread being originaly named libkse. Regards, Nuno From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 13:53:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82DC916A403 for ; Fri, 27 Oct 2006 13:53:45 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F7D43D45 for ; Fri, 27 Oct 2006 13:53:44 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 1C0F05D40; Fri, 27 Oct 2006 17:53:44 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 13ACB5D2D; Fri, 27 Oct 2006 17:53:44 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9RDriok002414; Fri, 27 Oct 2006 17:53:44 +0400 (MSD) (envelope-from ru) Date: Fri, 27 Oct 2006 17:53:44 +0400 From: Ruslan Ermilov To: Nuno Antunes Message-ID: <20061027135344.GB1354@rambler-co.ru> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027094922.GC6613@rambler-co.ru> <262949390610270643i3ce7e9f6k35862587ac546d52@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <262949390610270643i3ce7e9f6k35862587ac546d52@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 13:53:45 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 27, 2006 at 02:43:21PM +0100, Nuno Antunes wrote: > On 10/27/06, Ruslan Ermilov wrote: > >KSE =3D=3D N:M threading > > > >A 1:1 threading (libthr) is much simpler than N:M threading (libpthread), > >and thus doesn't require KSE support in the kernel; see kse(2) manpage > >for details. Without the KSE option in the kernel, all kse(2) syscalls > >will return EOPNOTSUPP, and a lot of code becomes redundant. > > >=20 > IIRC, I can even remember libpthread being originaly named libkse. >=20 It's still named libkse on sparc64 and sun4v. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFQg9oqRfpzJluFF4RAnm2AJ45J/leyKrPIhOuOosMH5VwIn4TCgCeOjUp Msmo4ZsH9vSarx04A9Qz3Lk= =crJw -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 14:34:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E20216A412; Fri, 27 Oct 2006 14:34:14 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EDFC43D5C; Fri, 27 Oct 2006 14:34:08 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 13002345F; Fri, 27 Oct 2006 16:34:08 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 40F4F9E6C2; Fri, 27 Oct 2006 14:34:48 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 12FB5405B; Fri, 27 Oct 2006 16:34:48 +0200 (CEST) Date: Fri, 27 Oct 2006 16:34:48 +0200 From: Jeremie Le Hen To: "Conrad J. Sabatier" Message-ID: <20061027143447.GN20405@obiwan.tataz.chchile.org> References: <20061023061539.GA17549@titan.klemm.apsfilter.org> <20061023212554.00062ff5@serene.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061023212554.00062ff5@serene.no-ip.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 14:34:14 -0000 Hi, On Mon, Oct 23, 2006 at 09:25:54PM -0500, Conrad J. Sabatier wrote: > Not sure what's causing this, but I'm seeing the "script" child > processes spawned by portupgrade consuming an inordinate amount of CPU, > as much as 80+%. This does make the configure stage appear to hang > interminably much of the time. > > This is under 7.0-CURRENT/amd64 with both portupgrade and > portupgrade-devel. It's gotten so bad, in fact, that I find myself > more and more resorting to manually upgrading ports, which works fine > and does not hog CPU at all. I caught such a behaviour as well on my -CURRENT from Oct 21 (with SSP patch applied). I saw once script(1) eating most of the CPU and another time, this was dialog(1). I was running portupgrade -af with some MAKE_ARGS in pkgtools.conf. I haven't taken time to inverstigate, though. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 15:56:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB79F16A403; Fri, 27 Oct 2006 15:56:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id B277843D49; Fri, 27 Oct 2006 15:56:05 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9RFtOdV095831; Fri, 27 Oct 2006 08:55:24 -0700 (PDT) Date: Fri, 27 Oct 2006 17:55:20 +0200 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20061027103924.F79313@fledge.watson.org> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Lev Serebryakov , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 15:56:06 -0000 At Fri, 27 Oct 2006 14:02:59 +0100 (BST), rwatson wrote: > (3). One of the current theories bouncing around the kernel > developer community is that the complexity and overhead of (2) > outweighs many of the benefits of KSE, and that by making it an > option, we can better evaluate the impact. Notice that this isn't > just about code complexity, but also about scheduler overhead. > David Xu has reported a non-trivial performance change from the > reduced overhead of the scheduler paths. So now we're at a point > where we can more fully evaluate the impact of KSE (since we can > actually compile it out of the scheduler). Before anything further > can be done, we now need to do that evaluation. > And speaking of evaluation if people can follow the advice here: http://wikitest.freebsd.org/BenchmarkAdvice It would be greatly appreciated. Best, George From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 16:01:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6F1B16A589 for ; Fri, 27 Oct 2006 16:01:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD9D43D53 for ; Fri, 27 Oct 2006 16:01:15 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k9RG1Alr079548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 18:01:11 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20061027143447.GN20405@obiwan.tataz.chchile.org> References: <20061023061539.GA17549@titan.klemm.apsfilter.org> <20061023212554.00062ff5@serene.no-ip.org> <20061027143447.GN20405@obiwan.tataz.chchile.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 27 Oct 2006 18:02:34 +0200 To: Jeremie Le Hen X-Mailer: Apple Mail (2.752.2) Cc: "Conrad J. Sabatier" , current@freebsd.org Subject: Re: portupgrade not working for all ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 16:01:17 -0000 Am 27.10.2006 um 16:34 schrieb Jeremie Le Hen: > Hi, > > On Mon, Oct 23, 2006 at 09:25:54PM -0500, Conrad J. Sabatier wrote: >> Not sure what's causing this, but I'm seeing the "script" child >> processes spawned by portupgrade consuming an inordinate amount of >> CPU, >> as much as 80+%. This does make the configure stage appear to hang >> interminably much of the time. >> >> This is under 7.0-CURRENT/amd64 with both portupgrade and >> portupgrade-devel. It's gotten so bad, in fact, that I find myself >> more and more resorting to manually upgrading ports, which works fine >> and does not hog CPU at all. > > I caught such a behaviour as well on my -CURRENT from Oct 21 > (with SSP patch applied). I saw once script(1) eating most of > the CPU and another time, this was dialog(1). I was running > portupgrade -af with some MAKE_ARGS in pkgtools.conf. > I haven't taken time to inverstigate, though. Dialog doesn't like not talking to a tty. Just try $ dialog --yesno "foo" 6 20 yes /dev/null 2>&1 Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 16:50:51 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A6F616A416 for ; Fri, 27 Oct 2006 16:50:51 +0000 (UTC) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 5152243D53 for ; Fri, 27 Oct 2006 16:50:27 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 97328 invoked by uid 0); 27 Oct 2006 14:50:46 -0200 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.149.10):. Processed in 0.525763 secs); 27 Oct 2006 16:50:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=capeta; d=freebsdbrasil.com.br; b=JNcxNNKKEeg0/gzNqV2aVIfydq9tfCzMpW37+tCi2c+Ckx1pJqCmE3WWC1+SWhohys2b9bzZuLf4pqbKk6VJYvuqtU+P93L0K1201+w8zpr5ARurVebKOpHtxZkehy+w ; Received: from unknown (HELO ?10.69.69.66?) (jmelo@201.17.149.10) by capeta.freebsdbrasil.com.br with SMTP; 27 Oct 2006 14:50:45 -0200 Message-ID: <45422AA6.50309@freebsdbrasil.com.br> Date: Fri, 27 Oct 2006 13:49:58 -0200 From: Jean Milanez Melo User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> <20061025104306.GI20405@obiwan.tataz.chchile.org> <453F5271.70309@freebsdbrasil.com.br> <20061026133637.GJ20405@obiwan.tataz.chchile.org> <20061026133742.GK20405@obiwan.tataz.chchile.org> In-Reply-To: <20061026133742.GK20405@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-small@FreeBSD.org, freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 16:50:51 -0000 Jeremie Le Hen wrote: > And the patch... > > On Thu, Oct 26, 2006 at 03:36:37PM +0200, Jeremie Le Hen wrote: >> Hi Jean, >> >> On Wed, Oct 25, 2006 at 10:02:57AM -0200, Jean Milanez Melo wrote: >>>> My feeling is that TinyBSD has used the KISS principle so far. The code >>>> as well as the configuration is somewhat raw (no offence here), but it is >>>> thereby easy to use, debug and modify at needs. I am going to code this >>>> in my source tree this afternoon and I will be glad to provide you the >>>> patch. >>> That's right, make tinybsd simpler is really our idea :) >>> >>> Send to me your patch and i'll take a look. >> The patch is attached and works pretty well for me. >> In addition to tinybsd.localfiles, I've made a few improvements: >> - I've moved the configuration filenames in a variable ; >> - When computing "sub-dependencies", use a temporary alternate file >> and then merge it back to the main dependency file ; >> - "chflags 0" files that are to be turned into symlinks before unlinking >> them ; >> - Handle /boot.config correctly in the configuration directory. >> >> Thank you. >> Regards, > Thanks Jeremie, Looks good, i'll test it on saturday. Jean From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 17:13:47 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A62F16A40F; Fri, 27 Oct 2006 17:13:47 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C7C243D5D; Fri, 27 Oct 2006 17:13:46 +0000 (GMT) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp2-g19.free.fr (Postfix) with ESMTP id ACBB175E8A; Fri, 27 Oct 2006 19:13:45 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 0C05911AC3; Fri, 27 Oct 2006 19:13:44 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99040-10; Fri, 27 Oct 2006 19:13:39 +0200 (CEST) Received: from [193.120.13.130] (cream.xbsd.org [193.120.13.130]) by smtp.xbsd.org (Postfix) with ESMTP id 259BB119E6; Fri, 27 Oct 2006 19:13:37 +0200 (CEST) From: Florent Thoumie To: ports@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L4KRFECFGKFZ7ie7XPOR" Date: Fri, 27 Oct 2006 18:13:36 +0100 Message-Id: <1161969216.70654.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Bugathon, yeah it's time again X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 17:13:47 -0000 --=-L4KRFECFGKFZ7ie7XPOR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok, heads up folks. Ports have been frozen for some weeks now, and it's only a matter of time before ice starts melting. So we're planning to hold the next bugathon next week end (well, in one week). Same server, same channel (#freebsd-bugbusters @ EFNET), you have one week to grab a list of PR and start working on them. WWW: http://wikitest.freebsd.org/Bugathons/November2006 Note: Since I still don't receive much feedback from src-committers, I expect it to be mainly ports-related. Obviously I may be wrong and there will probably a few src-committers coming, this channel is still a good place to discuss bugs. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --=-L4KRFECFGKFZ7ie7XPOR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFQj5AMxEkbVFH3PQRArspAJ9FBhxxcJHscv8GeasSq/Iq+MCEbACfV5m/ ne8BgQZfBeS1fp8z8s2HVGQ= =2YfZ -----END PGP SIGNATURE----- --=-L4KRFECFGKFZ7ie7XPOR-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 18:08:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C497816A415 for ; Fri, 27 Oct 2006 18:08:10 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id C460A43D5A for ; Fri, 27 Oct 2006 18:08:09 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1358211nfc for ; Fri, 27 Oct 2006 11:08:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HIqcCx7dL4DnwjGngDcj9mMZ0HWejolrMu+6ANIECuSUTetm57agozOufUAI5laG2f3P9Fmw+zvqO9yFU/H/qnvOGeKlacKKllanTXJOfx4pSZz6Vw72NA8jJzmE78gA1Xv1hJA/FjrlGpyjrmqUXv9+hMV5U8JdZ/YISM9uOmw= Received: by 10.82.123.16 with SMTP id v16mr1711694buc; Fri, 27 Oct 2006 11:08:08 -0700 (PDT) Received: by 10.82.191.20 with HTTP; Fri, 27 Oct 2006 11:08:07 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 11:08:08 -0700 From: "Kip Macy" To: "Jiawei Ye" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061026213343.GA29160@what-creek.com> <200610270851.39444.davidxu@freebsd.org> <20061027005733.GA31389@what-creek.com> <200610271006.38851.davidxu@freebsd.org> Cc: current@freebsd.org, David Xu , John Birrell Subject: Re: HEADSUP: KSE about to become a kernel option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 18:08:10 -0000 Missed merge - should be easy to fix On 10/26/06, Jiawei Ye wrote: > On 10/27/06, David Xu wrote: > > I assume that without KSE, the scheduler's code size is reduced, this > saves > > I-CACHE and execution time. > > > > David Xu > Is SCHED_CORE compatible with this change? I get > > cc -c -mtune=pentium4 -march=pentium2 -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror > /usr/src/sys/kern/sched_core.c > /usr/src/sys/kern/sched_core.c:356: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:356: warning: its scope is only this > definition or declaration, which is probably not what you want > /usr/src/sys/kern/sched_core.c:372: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:374: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:618: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:619: error: conflicting types for > 'sched_is_timeshare' > /usr/src/sys/kern/sched_core.c:372: error: previous declaration of > 'sched_is_timeshare' was here > /usr/src/sys/kern/sched_core.c:619: error: conflicting types for > 'sched_is_timeshare' > /usr/src/sys/kern/sched_core.c:372: error: previous declaration of > 'sched_is_timeshare' was here > /usr/src/sys/kern/sched_core.c: In function `sched_is_timeshare': > /usr/src/sys/kern/sched_core.c:620: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c: At top level: > /usr/src/sys/kern/sched_core.c:624: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:625: error: conflicting types for > 'sched_calc_pri' > /usr/src/sys/kern/sched_core.c:374: error: previous declaration of > 'sched_calc_pri' was here > /usr/src/sys/kern/sched_core.c:625: error: conflicting types for > 'sched_calc_pri' > /usr/src/sys/kern/sched_core.c:374: error: previous declaration of > 'sched_calc_pri' was here > /usr/src/sys/kern/sched_core.c: In function `sched_calc_pri': > /usr/src/sys/kern/sched_core.c:629: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:630: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:630: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:637: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c: In function `sched_recalc_pri': > /usr/src/sys/kern/sched_core.c:647: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:649: warning: passing arg 1 of > `sched_is_timeshare' from incompatible pointer type > /usr/src/sys/kern/sched_core.c:650: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:661: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:663: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:671: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:673: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:675: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:683: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:686: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:687: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:691: warning: passing arg 1 of > `sched_calc_pri' from incompatible pointer type > /usr/src/sys/kern/sched_core.c: In function `sched_update_runtime': > /usr/src/sys/kern/sched_core.c:698: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:700: warning: passing arg 1 of > `sched_is_timeshare' from incompatible pointer type > /usr/src/sys/kern/sched_core.c:708: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:709: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c: In function `sched_commit_runtime': > /usr/src/sys/kern/sched_core.c:717: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:719: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:719: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:720: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:722: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:722: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:723: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c: In function `schedinit': > /usr/src/sys/kern/sched_core.c:815: error: `ksegrp0' undeclared (first > use in this function) > /usr/src/sys/kern/sched_core.c:815: error: (Each undeclared identifier > is reported only once > /usr/src/sys/kern/sched_core.c:815: error: for each function it appears in.) > /usr/src/sys/kern/sched_core.c: In function `sched_unlend_prio': > /usr/src/sys/kern/sched_core.c:911: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c: In function `sched_prio': > /usr/src/sys/kern/sched_core.c:926: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c: At top level: > /usr/src/sys/kern/sched_core.c:952: warning: "struct ksegrp" declared > inside parameter list > /usr/src/sys/kern/sched_core.c:953: error: conflicting types for > 'sched_user_prio' > /usr/src/sys/sys/sched.h:83: error: previous declaration of > 'sched_user_prio' was here > /usr/src/sys/kern/sched_core.c:953: error: conflicting types for > 'sched_user_prio' > /usr/src/sys/sys/sched.h:83: error: previous declaration of > 'sched_user_prio' was here > /usr/src/sys/kern/sched_core.c: In function `sched_user_prio': > /usr/src/sys/kern/sched_core.c:957: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:961: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:963: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:967: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:970: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:971: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c: In function `sched_lend_user_prio': > /usr/src/sys/kern/sched_core.c:984: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:985: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c: In function `sched_unlend_user_prio': > /usr/src/sys/kern/sched_core.c:994: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:997: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sched_core.c:1000: warning: passing arg 1 of > `sched_user_prio' from incompatible pointer type > /usr/src/sys/kern/sched_core.c: In function `sched_switch': > /usr/src/sys/kern/sched_core.c:1017: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:1030: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:1039: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:1039: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:1046: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c:1057: error: structure has no member > named `td_ksegrp' > /usr/src/sys/kern/sched_core.c: In function `sched_nice': > /usr/src/sys/kern/sched_core.c:1094: warning: implicit declaration of > function `FOREACH_KSEGRP_IN_PROC' > /usr/src/sys/kern/sched_core.c:1094: warning: nested extern > declaration of `FOREACH_KSEGRP_IN_PROC' > /usr/src/sys/kern/sched_core.c:1094: error: syntax error before '{' token > /usr/src/sys/kern/sched_core.c:1097: warning: implicit declaration of > function `FOREACH_THREAD_IN_GROUP' > /usr/src/sys/kern/sched_core.c:1097: warning: nested extern > declaration of `FOREACH_THREAD_IN_GROUP' > /usr/src/sys/kern/sched_core.c:1098: error: syntax error before "td" > /usr/src/sys/kern/sched_core.c: At top level: > /usr/src/sys/kern/sched_core.c:356: warning: 'slot_fill' declared > `static' but never defined > /usr/src/sys/kern/sched_core.c:578: warning: 'kseq_choose' defined but not > used > /usr/src/sys/kern/sched_core.c:372: warning: 'sched_is_timeshare' > declared `static' but never defined > /usr/src/sys/kern/sched_core.c:373: warning: 'sched_choose' declared > `static' but never defined > /usr/src/sys/kern/sched_core.c:374: warning: 'sched_calc_pri' declared > `static' but never defined > /usr/src/sys/kern/sched_core.c:375: warning: 'sched_starving' declared > `static' but never defined > /usr/src/sys/kern/sched_core.c:837: warning: 'sched_pctcpu_update' > defined but not used > /usr/src/sys/kern/sched_core.c:642: warning: 'sched_recalc_pri' > defined but not used > /usr/src/sys/kern/sched_core.c:716: warning: 'sched_commit_runtime' > defined but not used > /usr/src/sys/kern/sched_core.c:433: warning: 'krunq_check' defined but not > used > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MAIL. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > Jiawei Ye > -- > "If it looks like a duck, walks like a duck, and quacks like a duck, > then to the end user it's a duck, and end users have made it pretty > clear they want a duck; whether the duck drinks hot chocolate or > coffee is irrelevant." > _______________________________________________ > 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 Oct 27 18:33:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3D9916A494 for ; Fri, 27 Oct 2006 18:33:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0558843D60 for ; Fri, 27 Oct 2006 18:33:03 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so754225wxd for ; Fri, 27 Oct 2006 11:33:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aahWijd+uwrDReNvknVMJXg1L1lT5ii1fMc5JWp1eUWZvGHmTk9+Wu+brtkrwWuj8UL9LYEOiyqRcGkONf2+9GF/GQN4v/0E26SKUMbKNhhxFeQrGitqHNMDDFLc/3BLYmscyNwS4Dya5KGdrqJX0k0bv6y6Xjwr4PQ0XqIMaEE= Received: by 10.70.83.4 with SMTP id g4mr6122977wxb; Fri, 27 Oct 2006 11:33:00 -0700 (PDT) Received: by 10.70.12.2 with HTTP; Fri, 27 Oct 2006 11:33:00 -0700 (PDT) Message-ID: <3bbf2fe10610271133j27dd5a8eq7fea228c955c93e5@mail.gmail.com> Date: Fri, 27 Oct 2006 20:33:00 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org, "John Baldwin" , pho@freebsd.org, kris@freebsd.org, "Robert Watson" In-Reply-To: <3bbf2fe10610181518k68356528i154267c0bd1b1a77@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10610181518k68356528i154267c0bd1b1a77@mail.gmail.com> X-Google-Sender-Auth: 2b442901eab49f53 Cc: Subject: Re: sx locks rewriting - needs testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 18:33:06 -0000 2006/10/19, Attilio Rao : > In my P4 branch: //depot/user/attilio/attilio_smpng/... > you can find a sx locks rewriting using the optimized semantic of > rwlocks; in the end this might result in a valuable performance > improvement. > > Some hints about it: > - new sx locks alredy support inlined s*lock operations and try* operations; > (they have a fully functional support) > - new sx locks doesn't have support for adaptive spinning yet; this is beacause > the code is under revision even for mutex/rwlock. > - we could allow a sharers tracking in debugging mode, at least, in > order to detect > eventual recursion in slock operation > - currently, sx locks mantain the exclusive holder tracking even if this is not > really necessary (we can get rid of it). > > In this moment a strong phase of test is *very* welcome, so please, > for every people having a p4 account, dowload the kernel and try to > put it under stress (at this purpose I cc'ed, in particular, kris@, > pho@ and jhb@ in order to have tests, revisions, etc. etc.) Maybe I did a stupid thing not directly posting diffs (so that all the people interested can nicely check/try): http://users.gufi.org/~rookie/works/patches/smpng26102006.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 19:27:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA20516A412 for ; Fri, 27 Oct 2006 19:27:17 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E2943D7C for ; Fri, 27 Oct 2006 19:27:14 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 12:27:14 -0700 Message-ID: <45425D92.8060205@elischer.org> Date: Fri, 27 Oct 2006 12:27:14 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 19:27:17 -0000 John, I appreciate that you have made KSE an option, but the way you have done it shows a complete misundertanding of what is there. What you are calling "KSE" is in fact several different facilities that are orthogonal. The one that you have the most trouble with is in fact not SA based threading (refered to by most people as "KSE" but, rather the fair scheduling code). The aim of the fair scheduling code is to ensure that if you, as a user, make a process that starts 1000 threads, and I as a user, make an unthreaded process, then I can still get to the CPU at somewhat similar rates to you. A naive scheduler would give you 1000 cpu slots and me 1. the current fair scheduler tries to make sure that each process gets a fair crack at the CPU by holding back some of the runnable threads from the threadded process, until the ones it has in therun queu have been completed.. A bit like telling a young child, "yes you can have more ice-cream, when you've finished the ice-cream you already have". I note that David recently (in the last year) disabled the fair scheduling capacity of the libthr code, but he didn't do it quite right so that it still does all the work for it, and then disregarded the result. This means that not only does a 1000 thread process (libthr) completely push a nonthreaded process out of the system, but it pays all the costs in the scheduler for working out how to NOT do that. The fairness algorythm that you have made 'optional' is a very crude one and I had thought that by now someone would have written a better one, but no-one has. I suggest that you fix your patch in two ways: 1/ you need (at least) 2 options. KSE and FAIR_THREADS most of the improvements you are seeing comes from the second one. Especially all your changes that are in the scheduler. This removes the fair scheduling capability. It affects all threading libraries that do not deliberatly knacker it. In other words it should be orthogonal to what threading library is running. If it is made a project goal that threads should be unfair, then I have no objections to removing the code, but it needs to be a decision that is deliberately taken. It was an initial project goal that threads should be fair, and the fact that David has made it ineffective for libthr (though he still pays the full price for it) is not a reason to throw it out. (What he does is to assign a new KSEGRP for each thread, but he doesn't label it as exempt from fairness so it does all the work only to discover at the end that it is the only thread on the ksegrp, and therefore always eligible to run). If the correct flags were set, then then David's threads could probably get the same speedup as seen with the KSE option removed, as all the overhead would be skipped, but then we would be officially condoning unfair threading. teh chage to do thos would be to add a ksegrp or thread flag (possibly thread) called TDF_FAIR_SCHED and change the few lines in the scheduler that do: if ((td->td_proc->p_flag & P_HADTHREADS) == 0) { to be if ((td->flags & TDF_FAIR_SCHED) == 0) { and set that flag in the threading libraries when threads should be made fair. then probably the entire advantage seen by David in the supersmack tests from unsetting KSE would be seen by simply not setting that bit. (it might also just look for: if (td->ksegrp->kg_numthreads == 1) and achieve the same thing automatically. So, the question is: DO we as a project want to have fair threading or unfair threading? Should processes with a lot of threads be able to push out processes that do the same thing by using a state machine or an event loop? BTW another alternative would be to write a different scheduler, called sched_4bsd-unfair (or similar) and just strip out the fairness code. it would be another way of doing much the same thing. This is a completely different question to whether there should be an M:N threading library, the existance of which should make no noticable difference to the speed of processses that don't use it. My moral for this story is. "If you don't understand the bigger picture and you modify things then you can expect that your modifications may have unforseen circumstances." I as well as most other people fall foul of this at various times in our carreers. ============ Technical note: The current fairness code relies on a sub structure of the proc, called a ksegrp. This structure represents the "unit of fairness". Most processes have one of these so they act as if the unit of fairness is the entire process. The concept was that a threaded process would have one of these for it's directly allocated threads, and that they woudl act as a group, fairly towards the rest of the system. A process could also have a library that unbeknownst to the program propper, would create its own ksegrp, with its own threads that would act independently and as their own 'fairness' characteristics, priorities etc. The threads only the top N (= ncpu usually) threads are aloowed onto the system run queue to compete with other processes. By assigning a separate KSEGRP for each thread the libthr code assures that each thread is immediatly promoted to the system run queue, however because the system code doesn't realise that he is trying to subvert the fairness code, it still takes the code path the looks at the ksegrp run qieies and does all sorts of other checks. If someone can come up with a better fairness method (Please!) then I'm happy to see all that code in the shceduler replaced by whatever else is chosen (nothing if we REALLY want to see thread unfairness). I think that libthr should be moved back to be "fair" by default, and that unfair mode should be made optional (if you are root) so that dedicated servers, where the administrator wants to get all the performance, and is willing to state explicitly that fairness is not important to him, can do just that (and for benchmarks). From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 19:34:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ED7616A40F; Fri, 27 Oct 2006 19:34:27 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C8143D49; Fri, 27 Oct 2006 19:34:26 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 12:34:26 -0700 Message-ID: <45425F42.1070909@elischer.org> Date: Fri, 27 Oct 2006 12:34:26 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Ruslan Ermilov References: <917908193.20061027102647@serebryakov.spb.ru> <20061027094922.GC6613@rambler-co.ru> In-Reply-To: <20061027094922.GC6613@rambler-co.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 19:34:27 -0000 Ruslan Ermilov wrote: > On Fri, Oct 27, 2006 at 10:56:21AM +0200, Ivan Voras wrote: >> Lev Serebryakov wrote: >>> Hello , >>> >>> I've was sure, that both libpthread and libthr use KSE to make >>> multithreading. They use KSE in different ways: libpthread uses N:M >>> model and libthr uses 1:1 model, but bot use KSE to work. >>> How will be possible to use these libraries (read: multithreaded >>> programs) when KSE will be optional, on kernel without KSE?! >> Yes, isn't KSE by definition "that thing that is scheduled in the kernel"? >> > KSE == N:M threading > > A 1:1 threading (libthr) is much simpler than N:M threading (libpthread), > and thus doesn't require KSE support in the kernel; see kse(2) manpage > for details. Without the KSE option in the kernel, all kse(2) syscalls > will return EOPNOTSUPP, and a lot of code becomes redundant. KSE is a misnomer that I abandoned long ago.. mostly it is the thread fairness code that is independent of what threading library is running (see the other email I just sent) (or should be) > > : /* > : * Initialize global thread allocation resources. > : */ > : void > : threadinit(void) > : { > : > : mtx_init(&tid_lock, "TID lock", NULL, MTX_DEF); > : tid_unrhdr = new_unrhdr(PID_MAX + 1, INT_MAX, &tid_lock); > : > : thread_zone = uma_zcreate("THREAD", sched_sizeof_thread(), > : thread_ctor, thread_dtor, thread_init, thread_fini, > : UMA_ALIGN_CACHE, 0); > : #ifdef KSE > : ksegrp_zone = uma_zcreate("KSEGRP", sched_sizeof_ksegrp(), > : ksegrp_ctor, NULL, NULL, NULL, > : UMA_ALIGN_CACHE, 0); > : kseinit(); /* set up kse specific stuff e.g. upcall zone*/ > : #endif The KSEGRP is a part of the fairness code in general and independent of M:N and 1:1 > : } > > > Cheers, From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 19:39:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8D7116A47B; Fri, 27 Oct 2006 19:39:30 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E100F43D46; Fri, 27 Oct 2006 19:39:29 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 12:39:29 -0700 Message-ID: <45426071.7020403@elischer.org> Date: Fri, 27 Oct 2006 12:39:29 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Robert Watson References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> In-Reply-To: <20061027103924.F79313@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lev Serebryakov , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 19:39:31 -0000 Robert Watson wrote: > > On Fri, 27 Oct 2006, Lev Serebryakov wrote: > >> I've was sure, that both libpthread and libthr use KSE to make >> multithreading. They use KSE in different ways: libpthread uses N:M >> model and libthr uses 1:1 model, but bot use KSE to work. >> How will be possible to sue these libraries (read: multithreaded >> programs) when KSE will be optional, on kernel without KSE?! > > The answer to that rather critical question, not surprisingly, is > complex. :-) > > The FreeBSD kernel actually implements a good three different threading > models (at least): > > (1) Linux threads/rfork threads. These are based on the idea of multiple > "struct proc"s floating around with varying degrees of sharing. > Typically, they share file descriptor array, address space, etc. For > those familiar with the Linux clone() system call, rfork() is > notionally > very similar. This model implies 1:1 threading, and leaves quite a > bit to > be desired in terms of overhead, as well as having some odd > implications > for POSIX-like compliance (i.e., the implementation of getpid()). > > (2) KSE. This provides a kernel<->userspace threading framework > allowing the > implementation of a broad array of threading and scheduling models. > This > is a fairly complex, but very flexible model, which has several > levels of > layering required to implement different scheduling policies using M:N > threading. Notice that 1:1 scheduling is a subset of M:N, so you can > implement 1:1 in this manner. One of the significant concerns about > KSE > is that it adds a great deal of complexity to the kernel scheduler > architecture, making it quite difficult to optimize, further > granularize > the locking for, understand, etc. > > (3) thr. This is a simpler 1:1 threading API to the kernel, which make > use of > the same architectural structures present in the kernel for KSE, but > without the full capability of M:N threading. In particular, it has > simplifying assumptions regarding how user threads enter the kernel and > are mapped into kernel threads, so doesn't need an upcall mechanism, or > create new threads when an existing thread sleeps. > > The NO_KSE patch disables the code paths required only for (2), not for > (1) or (3). One of the current theories bouncing around the kernel > developer community is that the complexity and overhead of (2) outweighs > many of the benefits of KSE, and that by making it an option, we can > better evaluate the impact. Notice that this isn't just about code > complexity, but also about scheduler overhead. David Xu has reported a > non-trivial performance change from the reduced overhead of the > scheduler paths. So now we're at a point where we can more fully > evaluate the impact of KSE (since we can actually compile it out of the > scheduler). Before anything further can be done, we now need to do that > evaluation. As I mentioned in another email, most of the complexity does not come from the M:N code, but rather from the attempt to provide process fairness. Most of David's improved speed comes not from removing teh fairness code, but from an accidental removal of a bug in the 1:1 thread support code that, in an attempt to circumvent the fainess code to improve benchmark numbers failed to do it properly, and ends up being both 'unfair" to other processes, and the recipient of all the overhead of fairness calculations. Please let's understand all this before we throw out the baby with the bathwater. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 Oct 27 20:04:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7559116A403 for ; Fri, 27 Oct 2006 20:04:18 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 417E743D46 for ; Fri, 27 Oct 2006 20:04:18 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 13:04:17 -0700 Message-ID: <45426641.3030403@elischer.org> Date: Fri, 27 Oct 2006 13:04:17 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Julian Elischer References: <45425D92.8060205@elischer.org> In-Reply-To: <45425D92.8060205@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 20:04:18 -0000 I think I accidently deleted a line in my final note.. rewriting it below... Julian Elischer wrote: > John, I appreciate that you have made KSE an option, but the way you > have done it shows a complete misundertanding of what is there. > > What you are calling "KSE" is in fact several different facilities that > are orthogonal. The one that you have the most trouble with is in fact > not SA based threading (refered to by most people as "KSE" but, rather > the fair scheduling code). > > The aim of the fair scheduling code is to ensure that if you, as a user, > make a process that starts 1000 threads, and I as a user, make an > unthreaded process, then I can still get to the CPU at somewhat similar > rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > the current fair scheduler tries to make sure that each process gets > a fair crack at the CPU by holding back some of the runnable threads > from the threadded process, until the ones it has in therun queu have > been completed.. A bit like telling a young child, "yes you can have > more ice-cream, when you've finished the ice-cream you already have". > > I note that David recently (in the last year) disabled the fair > scheduling capacity of the libthr code, but he didn't do it quite right > so that it still does all the work for it, and then disregarded the > result. This means that not only does a 1000 thread process (libthr) > completely push a nonthreaded process out of the system, but it pays > all the costs in the scheduler for working out how to NOT do that. > > > The fairness algorythm that you have made 'optional' is a very crude one > and I had thought that by now someone would have written a better one, > but no-one has. > > I suggest that you fix your patch in this way: > you need (at least) 2 options. > KSE > and > FAIR_THREADS > > most of the improvements you are seeing comes from the second one. > Especially all your changes that are in the scheduler. This removes the > fair scheduling capability. It affects all threading libraries that > do not deliberatly knacker it. In other words it should be orthogonal > to what threading library is running. > > If it is made a project goal that threads should be unfair, then > I have no objections to removing the code, but it needs to be a decision > that is deliberately taken. It was an initial project goal that threads > should be fair, and the fact that David has made it ineffective for > libthr (though he still pays the full price for it) is not a reason to > throw it out. (What he does is to assign a new KSEGRP for each thread, > but he doesn't label it as exempt from fairness so it does all the > work only to discover at the end that it is the only thread on the > ksegrp, and therefore always eligible to run). > If the correct flags were set, then then David's threads > could probably get the same speedup as seen with the KSE option removed, > as all the overhead would be skipped, but then we would be officially > condoning unfair threading. > teh chage to do thos would be to add a ksegrp or thread flag (possibly > thread) called TDF_FAIR_SCHED > > and change the few lines in the scheduler that do: > if ((td->td_proc->p_flag & P_HADTHREADS) == 0) { > > to be > if ((td->flags & TDF_FAIR_SCHED) == 0) { > > > and set that flag in the threading libraries when threads should be > made fair. then probably the entire advantage seen by David in the > supersmack tests from unsetting KSE would be seen by simply not setting > that bit. > > (it might also just look for: > if (td->ksegrp->kg_numthreads == 1) > and achieve the same thing automatically. > > > So, the question is: > DO we as a project want to have fair threading or unfair threading? > > Should processes with a lot of threads be able to push out processes > that do the same thing by using a state machine or an event loop? > > BTW another alternative would be to write a different scheduler, > called sched_4bsd-unfair (or similar) and just strip out the fairness > code. it would be another way of doing much the same thing. > > This is a completely different question to whether there should be > an M:N threading library, the existance of which should make no > noticable difference to the speed of processses that don't use it. > > My moral for this story is. > "If you don't understand the bigger picture and you modify things > then you can expect that your modifications may have unforseen > circumstances." > > I as well as most other people fall foul of this at various times in our > carreers. > > > > ============ > Technical note: > > The current fairness code relies on a sub structure of the proc, > called a ksegrp. This structure represents the "unit of fairness". > Most processes have one of these so they act as if the unit of > fairness is the entire process. The concept was that a threaded > process would have one of these for it's directly allocated threads, > and that they would act, as a group, fairly towards the rest of the > system. A process could also have a library that unbeknownst to the > program propper, would create its own ksegrp, with its own threads, > that would act independently and have their own 'fairness' > characteristics, priorities etc. In a fair threaded process with may runnable threads, > only the top N (= ncpu usually) threads are allowed onto the system > run queue to compete with other processes. In libthr, > By assigning a separate > KSEGRP for each thread the code assures that each thread is > immediatly promoted to the system run queue, however because the > system code doesn't realise that he is trying to subvert the fairness > code, it still takes the code path that looks at the ksegrp run queues > and does all sorts of other checks. > > If someone can come up with a better fairness method (Please!) then > I'm happy to see all that code in the shceduler replaced by whatever > else is chosen (nothing if we REALLY want to see thread unfairness). > > I think that libthr should be moved back to be "fair" by default, and > that unfair mode should be made optional (if you are root) so that > dedicated servers, where the administrator wants to get all the > performance, and is willing to state explicitly that fairness is not > important to him, can do just that (and for benchmarks). > > > > > > > _______________________________________________ > 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 Oct 27 20:15:14 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6817E16A4AB; Fri, 27 Oct 2006 20:15:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from relay1.wplus.net (relay1.wplus.net [195.131.52.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FBE443D6E; Fri, 27 Oct 2006 20:15:00 +0000 (GMT) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru ([89.163.10.141]) by relay1.wplus.net (8.13.6/8.13.1/RELAY-DVD) with ESMTP id k9RKEkSW005616; Sat, 28 Oct 2006 00:14:50 +0400 (MSD) Date: Sat, 28 Oct 2006 00:14:49 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v2.11.02) Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <602423478.20061028001449@serebryakov.spb.ru> To: Julian Elischer In-Reply-To: <45426071.7020403@elischer.org> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Lev Serebryakov , Robert Watson , current@FreeBSD.org Subject: Re[2]: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lev Serebryakov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 20:15:14 -0000 Hello Julian, Friday, October 27, 2006, 11:39:29 PM, you wrote: JE> As I mentioned in another email, most of the complexity does not come JE> from the M:N code, but rather from the attempt to provide process JE> fairness. What is Process fairness? Situation, when process with 10 threads consumes same amount of CPU resource, as process with 1 thread (if they are equal in IO, sleeping, etc)? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:18:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD4CF16A403 for ; Fri, 27 Oct 2006 20:18:39 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C1BF43D73 for ; Fri, 27 Oct 2006 20:18:39 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 2A2BB45806; Fri, 27 Oct 2006 13:18:38 -0700 (PDT) Date: Fri, 27 Oct 2006 13:18:38 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20061027201838.GH30707@riyal.ugcs.caltech.edu> References: <45425D92.8060205@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45425D92.8060205@elischer.org> Sender: jd@ugcs.caltech.edu Cc: current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 20:18:39 -0000 >From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: > The aim of the fair scheduling code is to ensure that if you, as a user, > make a process that starts 1000 threads, and I as a user, make an > unthreaded process, then I can still get to the CPU at somewhat similar > rates to you. A naive scheduler would give you 1000 cpu slots and me 1. Ah. Let me be one of the first to take a crack at attacking this idea as a mistake. First the name-calling: What you're talking about is communist scheduling. It insists that I the user should conform to the scheduler's notion of the right ratio of processses to threads. Now the serious response: By fair-scheduling what you mean is recreating through quite a bit of computation some of the scheduling defects of libc_r: namely that threading is denied the same concurrency granted to multi-process based architectures. I now rather instantly apprehend why multi-threading has lagged behind so much on FreeBSD. Let me tell you right now, this is not an assumption people consider when multithreading their applications. Can you offer an explanation as to why the scheduler should care about the balance of active users/active threads/active processes? If you desire partitioning there is a simple answer: rlimits covering the number of threads, processes, threads per process, etc. And hint: almost everyone will turn these limits off. The only necessary fairness property is between threads. The scheduler cannot ascertain among several threads which are doing important work merely by virtue of how they are distributed among the vmspaces (processes). This sort of distinction should be left under the control of process priority, thread priority, and rlimits. Paul From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:41:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF1FB16A40F for ; Fri, 27 Oct 2006 20:41:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 658E043D5F for ; Fri, 27 Oct 2006 20:41:21 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9RKfG9A012544; Fri, 27 Oct 2006 16:41:16 -0400 (EDT) Date: Fri, 27 Oct 2006 16:41:16 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Paul Allen In-Reply-To: <20061027201838.GH30707@riyal.ugcs.caltech.edu> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 27 Oct 2006 16:41:16 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 20:41:21 -0000 On Fri, 27 Oct 2006, Paul Allen wrote: >> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: >> The aim of the fair scheduling code is to ensure that if you, as a user, >> make a process that starts 1000 threads, and I as a user, make an >> unthreaded process, then I can still get to the CPU at somewhat similar >> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > Ah. Let me be one of the first to take a crack at attacking this idea as > a mistake. No, it is POSIX. You, the application, can write a program with system scope or process scope threads and get whatever you behavior you want, within rlimits of course. If you want unfair scheduling, then create your threads with system scope contention, otherwise use process scope. The kernel should be designed to allow both, and have adjustable limits in place for (at least) system scope threads. Noone is saying that you can't have as many system scope threads as you want (and as allowed by limits), just that you must also be able to have process scope threads (with probably higher limits or possibly no limits). -- DE From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:44:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547C416A403 for ; Fri, 27 Oct 2006 20:44:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0F5A43D45 for ; Fri, 27 Oct 2006 20:44:47 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.4) with ESMTP id k9RKijOY045237; Fri, 27 Oct 2006 13:44:45 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id k9RKijTe045236; Fri, 27 Oct 2006 13:44:45 -0700 (PDT) Date: Fri, 27 Oct 2006 13:44:45 -0700 (PDT) From: Matthew Dillon Message-Id: <200610272044.k9RKijTe045236@apollo.backplane.com> To: Paul Allen References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 20:44:48 -0000 I think the real issue here is that it is fairly difficult... probably close to impossible in fact, to write a general purpose scheduler in the kernel that can handle the types of extreme cases that can occur when the kernel is made responsible for managing a user program's threads. A better approach would be to make the kernel responsible for scheduling cpu slots for programs, a far more manageable number, and if a program wants to have thousands of threads on a 4-cpu system it (i.e. libthr) should then have the responsibility of telling the kernel which threads to pop into those slots at any given moment. So, for example, if a machine has 4 cpus the kernel has 4 scheduling slots it can fill. The kernel can apportion those slots with its current scheduler technology. But if there is a program running on the system that has thousands of threads, then why in the world would you want to try to make the kernel scheduler deal with all those threads at once when it only has 4 cpus to assign them to anyhow? So what you would have instead would be the kernel saying to the program 'ok, I have 3 slots available for you at the moment' and make the program responsible for telling the kernel which threads to run in those 3 slots. And then a little while later the kernel might say 'I have 4 slots now', or 'now I only have 2 slots available', etc etc. This would then be a far more solvable problem for the kernel scheduler. If you as the user then want the kernel to give the program with thousands of threads more of the available cpu, it simply becomes a matter of running the program at a lower NICE value. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 20:50:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78ED516A417; Fri, 27 Oct 2006 20:50:34 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C25B843D70; Fri, 27 Oct 2006 20:50:33 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.4) with ESMTP id k9RKoX4U045281; Fri, 27 Oct 2006 13:50:33 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id k9RKoXo3045280; Fri, 27 Oct 2006 13:50:33 -0700 (PDT) Date: Fri, 27 Oct 2006 13:50:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200610272050.k9RKoXo3045280@apollo.backplane.com> To: Daniel Eischen References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> Cc: Paul Allen , Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 20:50:34 -0000 :No, it is POSIX. You, the application, can write a program with :system scope or process scope threads and get whatever you behavior :you want, within rlimits of course. : :If you want unfair scheduling, then create your threads with :system scope contention, otherwise use process scope. The :kernel should be designed to allow both, and have adjustable :limits in place for (at least) system scope threads. : :Noone is saying that you can't have as many system scope threads :as you want (and as allowed by limits), just that you must also :be able to have process scope threads (with probably higher limits :or possibly no limits). : :-- :DE This is a nice concept, but totally unrealistic in actual operation because you generally have no control over how the application programmer designed his application. It is the user running the application who needs to be able to control how the thread scope effects the overall system, not the application designer. The argument here is not how a program runs alone on a system, but how it effects the performance of other programs running on the system. Unless you are advocating that the system administrator or user perform surgery on every single application in the system (KDE, Firefox, and on down the line), the problem cannot be solved by depending on programmers to do the right thing vis-a-vie the POSIX standard. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:04:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6899116A40F; Fri, 27 Oct 2006 21:04:59 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94ECD43D45; Fri, 27 Oct 2006 21:04:58 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id B2358386C48; Fri, 27 Oct 2006 21:04:56 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 9615C1141D; Fri, 27 Oct 2006 23:04:56 +0200 (CEST) Date: Fri, 27 Oct 2006 23:04:56 +0200 From: "Simon L. Nielsen" To: gnn@freebsd.org Message-ID: <20061027210455.GA1073@zaphod.nitro.dk> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: Lev Serebryakov , Robert Watson , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 21:04:59 -0000 On 2006.10.27 17:55:20 +0200, gnn@freebsd.org wrote: > At Fri, 27 Oct 2006 14:02:59 +0100 (BST), > rwatson wrote: > > (3). One of the current theories bouncing around the kernel > > developer community is that the complexity and overhead of (2) > > outweighs many of the benefits of KSE, and that by making it an > > option, we can better evaluate the impact. Notice that this isn't > > just about code complexity, but also about scheduler overhead. > > David Xu has reported a non-trivial performance change from the > > reduced overhead of the scheduler paths. So now we're at a point > > where we can more fully evaluate the impact of KSE (since we can > > actually compile it out of the scheduler). Before anything further > > can be done, we now need to do that evaluation. > > > > And speaking of evaluation if people can follow the advice here: > > http://wikitest.freebsd.org/BenchmarkAdvice > > It would be greatly appreciated. Note that the text copy/pasted here is actually already in our developmers handbook (and has been since shortly after phk's mail): http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/testing.html -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:06:24 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02C0116A40F for ; Fri, 27 Oct 2006 21:06:24 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8299D43D7B for ; Fri, 27 Oct 2006 21:06:18 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9RL6Aoo005964; Fri, 27 Oct 2006 17:06:10 -0400 (EDT) Date: Fri, 27 Oct 2006 17:06:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matthew Dillon In-Reply-To: <200610272050.k9RKoXo3045280@apollo.backplane.com> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <200610272050.k9RKoXo3045280@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 27 Oct 2006 17:06:10 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 21:06:24 -0000 On Fri, 27 Oct 2006, Matthew Dillon wrote: > > :No, it is POSIX. You, the application, can write a program with > :system scope or process scope threads and get whatever you behavior > :you want, within rlimits of course. > : > :If you want unfair scheduling, then create your threads with > :system scope contention, otherwise use process scope. The > :kernel should be designed to allow both, and have adjustable > :limits in place for (at least) system scope threads. > : > :Noone is saying that you can't have as many system scope threads > :as you want (and as allowed by limits), just that you must also > :be able to have process scope threads (with probably higher limits > :or possibly no limits). > : > :-- > :DE > > This is a nice concept, but totally unrealistic in actual operation > because you generally have no control over how the application > programmer designed his application. It is the user running the > application who needs to be able to control how the thread scope > effects the overall system, not the application designer. > > The argument here is not how a program runs alone on a system, but how > it effects the performance of other programs running on the system. > > Unless you are advocating that the system administrator or user perform > surgery on every single application in the system (KDE, Firefox, and > on down the line), the problem cannot be solved by depending on > programmers to do the right thing vis-a-vie the POSIX standard. Two things. You kernel shouldn't be designed to make it impossible to support POSIX operations and behavior. There are various ways that you can force a threads library or kernel to use system or process scope threads. We do it now with environment variables in libpthread, or as a compile option when building libpthread. You could also have a sysctl that forces threads to be created one way or another. Users can, if they are unhappy with the performance of the threaded application, force it to use one or the other scheme, within limits as set by the administrator. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:14:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53D2516A407; Fri, 27 Oct 2006 21:14:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AC243D46; Fri, 27 Oct 2006 21:14:58 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9RLEwt6030103; Fri, 27 Oct 2006 17:14:58 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id k9RLEwKl038475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Oct 2006 17:14:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200610272114.k9RLEwKl038475@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Oct 2006 17:13:00 -0400 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Intel DG965SS MB ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 21:14:59 -0000 Has anyone got this motherboard to work with FreeBSD ? I tried fiddling with the BIOS but no matter what, 6.2Beta does not see the ad0 (PATA drive) nor ad4 (SATA drive)... It never sees the drive, although it does see the controller as a generic IDE controller The intel product code is BOXDG965SSCK Does this motherboard work in 7.x ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:31:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5980616A407; Fri, 27 Oct 2006 21:31:31 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0416343D7B; Fri, 27 Oct 2006 21:31:26 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id EE94845806; Fri, 27 Oct 2006 14:31:25 -0700 (PDT) Date: Fri, 27 Oct 2006 14:31:25 -0700 From: Paul Allen To: Daniel Eischen Message-ID: <20061027213125.GI30707@riyal.ugcs.caltech.edu> References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: jd@ugcs.caltech.edu Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 21:31:31 -0000 >From Daniel Eischen , Fri, Oct 27, 2006 at 04:41:16PM -0400: > On Fri, 27 Oct 2006, Paul Allen wrote: > > >>From Julian Elischer , Fri, Oct 27, 2006 at > >>12:27:14PM -0700: > >>The aim of the fair scheduling code is to ensure that if you, as a user, > >>make a process that starts 1000 threads, and I as a user, make an > >>unthreaded process, then I can still get to the CPU at somewhat similar > >>rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > > >Ah. Let me be one of the first to take a crack at attacking this idea as > >a mistake. > > No, it is POSIX. You, the application, can write a program with > system scope or process scope threads and get whatever you behavior > you want, within rlimits of course. So your argument is: "if I can find a spec that does it, its right" Sorry but if you participated in more spec writing--I do, in the IEEE-- you'd realize that was not a good position from which to argue. Plenty of mistakes are made in specs. Let me reiterate, that either because of poor education or choice, multithreading is not usually implemented in a manner consistent with your scheme. Threads are either busy (have work to do, in which case the kernel shouldn't be making value judgements except by way of priority) or they are sleeping in which case the point is moot. Preventing users from interfering with each other on a multiuser system is a problem for rlimits to solve. On a single user-system, having an imbalance of consumer/producer threads is a configuration problem which again the safety net necessary is an rlimits mechanism that will allow the machine to be saved before it falls over. The 1000 versus 1 is still some sort of strange academic fairness fetish. If the process with one thread is relatively (per thread) more valuable that should be reflected in the scheduling priorities and implemented in the scheduler using a mechanism similar to WFQ. Again though: this is priorities not thread grouping per process. Irrespective of that, the number of threads is usually set to match the workload and its importance. Don't you think its better for code-paths to optimized for the common case? Paul From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:46:41 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB69416A415 for ; Fri, 27 Oct 2006 21:46:41 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E732043D82 for ; Fri, 27 Oct 2006 21:46:40 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.130] (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.13.6/8.13.4) with ESMTP id k9RLkdQu054398; Fri, 27 Oct 2006 23:46:39 +0200 (CEST) (envelope-from sos@deepcore.dk) Message-ID: <45427E46.6000705@deepcore.dk> Date: Fri, 27 Oct 2006 23:46:46 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: Mike Tancsa References: <200610272114.k9RLEwKl038475@lava.sentex.ca> In-Reply-To: <200610272114.k9RLEwKl038475@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v2.0beta Cc: freebsd-current@FreeBSD.ORG Subject: Re: Intel DG965SS MB ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 21:46:41 -0000 Mike Tancsa wrote: > Has anyone got this motherboard to work with FreeBSD ? I tried > fiddling with the BIOS but no matter what, 6.2Beta does not see the > ad0 (PATA drive) nor ad4 (SATA drive)... It never sees the drive, > although it does see the controller as a generic IDE controller > > The intel product code is BOXDG965SSCK > > Does this motherboard work in 7.x ? Dont know that exact board,but the Gigabyte 965P- DS3 I've got here with the same chipset works fine. The SATA ports on the ICH8 are fully supported and should work on any board. However the ICH8 has *no* PATA port, so the PATA port on mine is a JMicron chip which we support including its extra 2 SATA ports. Some Intel boards use Marvell chips that should work as generic but early reports seems to indicate that is not the case. -Søren From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 21:54:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 308A616A4E2 for ; Fri, 27 Oct 2006 21:54:10 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951CB43DD6 for ; Fri, 27 Oct 2006 21:53:28 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 751DF5B5A; Fri, 27 Oct 2006 14:53:14 -0700 (PDT) To: Julian Elischer In-reply-to: Your message of "Fri, 27 Oct 2006 12:27:14 PDT." <45425D92.8060205@elischer.org> Date: Fri, 27 Oct 2006 14:53:14 -0700 From: Bakul Shah Message-Id: <20061027215314.751DF5B5A@mail.bitblocks.com> Cc: current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 21:54:10 -0000 > The aim of the fair scheduling code is to ensure that if you, as a user, > make a process that starts 1000 threads, and I as a user, make an > unthreaded process, then I can still get to the CPU at somewhat similar > rates to you. A naive scheduler would give you 1000 cpu slots and me 1. The default may be to give each process the same share but in general one would want even more control over scheduling. For instance I may want one group of processes to get 10% share (it may be encoding/serving a video stream in real time) and the remaining shared by everyone else. You need waited fair queuing or some such. This can allow one to structure an application in a natural way without having to worry about how scheduling will be impacted by a choice of threads vs processes. Have you guys looked at any networking related papers on scheduling? I see a lot of similarities in the goals and some algorithms may be useful. One can think of a tcp stream or traffic between two endpoints as equivalent of a thread. May be by throwing out all of KSE and simplifying the scheduler you/we have an opportunity to apply the lessons learned and come up with a leaner, more efficient and flexible design. The default scheduler can be dirt simple but easy to replace or enhance, may be with a loadble module, so that one can experiment with different algorithms without having to take the system down as well as punt to a user process for more complex decisions. This is assuming a very simple plugin API is possible (definitely not a given). FWIW. -- bakul From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 22:34:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB10F16A403; Fri, 27 Oct 2006 22:34:21 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE6C43D46; Fri, 27 Oct 2006 22:34:21 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 15:34:21 -0700 Message-ID: <4542896D.1050001@elischer.org> Date: Fri, 27 Oct 2006 15:34:21 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Lev Serebryakov References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> In-Reply-To: <602423478.20061028001449@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@FreeBSD.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 22:34:21 -0000 Lev Serebryakov wrote: > Hello Julian, > > Friday, October 27, 2006, 11:39:29 PM, you wrote: > > JE> As I mentioned in another email, most of the complexity does not come > JE> from the M:N code, but rather from the attempt to provide process > JE> fairness. > What is Process fairness? Situation, when process with 10 threads consumes same amount of CPU resource, as process with 1 thread (if they are equal in IO, sleeping, etc)? > > basically, if you and I both write programs to do a particular job on a timesharing system, and you use threads to do so and I use a sophisticated event handler/state machine, I shouldn't find that my program is running like a pig because yours has 1000 slots in the run queue and I only get run 1 in 1001 ticks. From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 22:37:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7155116A4AB for ; Fri, 27 Oct 2006 22:37:31 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAE3443D49 for ; Fri, 27 Oct 2006 22:37:17 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 15:37:17 -0700 Message-ID: <45428A1C.3020902@elischer.org> Date: Fri, 27 Oct 2006 15:37:16 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Matthew Dillon References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <200610272044.k9RKijTe045236@apollo.backplane.com> In-Reply-To: <200610272044.k9RKijTe045236@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Allen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 22:37:31 -0000 Matthew Dillon wrote: > I think the real issue here is that it is fairly difficult... probably > close to impossible in fact, to write a general purpose scheduler in > the kernel that can handle the types of extreme cases that can occur > when the kernel is made responsible for managing a user program's threads. > > A better approach would be to make the kernel responsible for scheduling > cpu slots for programs, a far more manageable number, and if a program > wants to have thousands of threads on a 4-cpu system it (i.e. libthr) > should then have the responsibility of telling the kernel which > threads to pop into those slots at any given moment. hey, wait, that's what the M:N library does! > > So, for example, if a machine has 4 cpus the kernel has 4 scheduling > slots it can fill. The kernel can apportion those slots with its current > scheduler technology. But if there is a program running on the system > that has thousands of threads, then why in the world would you want to > try to make the kernel scheduler deal with all those threads at once > when it only has 4 cpus to assign them to anyhow? So what you would > have instead would be the kernel saying to the program 'ok, I have 3 > slots available for you at the moment' and make the program responsible > for telling the kernel which threads to run in those 3 slots. And > then a little while later the kernel might say 'I have 4 slots now', > or 'now I only have 2 slots available', etc etc. > > This would then be a far more solvable problem for the kernel scheduler. > > If you as the user then want the kernel to give the program with > thousands of threads more of the available cpu, it simply becomes a > matter of running the program at a lower NICE value. > > -Matt From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 23:02:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB45316A407; Fri, 27 Oct 2006 23:02:43 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900F943D55; Fri, 27 Oct 2006 23:02:43 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 16:02:43 -0700 Message-ID: <45429013.90705@elischer.org> Date: Fri, 27 Oct 2006 16:02:43 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Paul Allen References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <20061027213125.GI30707@riyal.ugcs.caltech.edu> In-Reply-To: <20061027213125.GI30707@riyal.ugcs.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 23:02:44 -0000 Paul Allen wrote: >>From Daniel Eischen , Fri, Oct 27, 2006 at 04:41:16PM -0400: >> On Fri, 27 Oct 2006, Paul Allen wrote: >> >>> >From Julian Elischer , Fri, Oct 27, 2006 at >>>> 12:27:14PM -0700: >>>> The aim of the fair scheduling code is to ensure that if you, as a user, >>>> make a process that starts 1000 threads, and I as a user, make an >>>> unthreaded process, then I can still get to the CPU at somewhat similar >>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >>> Ah. Let me be one of the first to take a crack at attacking this idea as >>> a mistake. >> No, it is POSIX. You, the application, can write a program with >> system scope or process scope threads and get whatever you behavior >> you want, within rlimits of course. > So your argument is: "if I can find a spec that does it, its right" > Sorry but if you participated in more spec writing--I do, in the IEEE-- > you'd realize that was not a good position from which to argue. Plenty > of mistakes are made in specs. > > Let me reiterate, that either because of poor education or choice, > multithreading is not usually implemented in a manner consistent > with your scheme. That scheme is optional... if you want it you can use it, and if not you can turn it off.. At least, it was designed to be that way though some of it may have been obscured during the evolution of the code. What you are saying is that users on a multiuser system expect that if they make more threads they can monopolise the system? In machines that are dedicated to a single task the admin is welcome to let that task hog as much as possible. When it is supposed to be shared, that is probably NOT the expected behaviour. > > Threads are either busy (have work to do, in which case the kernel > shouldn't be making value judgements except by way of priority) or > they are sleeping in which case the point is moot. exactly, but often you get bursts of work where may many threads come to life. Does that mean everything else should stop? > > Preventing users from interfering with each other on a multiuser system > is a problem for rlimits to solve. What would you put in rlimit to solve this problem? Be specific! Please send diffs and code outlines. > On a single user-system, having an imbalance of consumer/producer threads > is a configuration problem which again the safety net necessary is > an rlimits mechanism that will allow the machine to be saved before it > falls over. On a single user system this can all be disabled anyhow.. which is why I suggest that the KSE option recently added be broken into a M:N option and a FAIRNESS option. > > The 1000 versus 1 is still some sort of strange academic fairness fetish. > If the process with one thread is relatively (per thread) more valuable > that should be reflected in the scheduling priorities and implemented > in the scheduler using a mechanism similar to WFQ. Again though: this > is priorities not thread grouping per process. This is a question for the project as a whole to decide. As I said.. "do we want 'fareness' or not?" If not then a lot of simplification can occur. But we need to be clear on the fact that when this is ripped out it will be a one way street. It will be hard to put back once evolution has moved the code a bit. If we DO want some fairness, then how much, and what sort? We probably need to implement a better version of it than the current version.. It's just that when we decided to go ahead with threading in 1998, we decided that we need some form of fairness, and I put in the simplest possible example of strict fairness that I could think of. It's not elegant and it is definitely expensive. I had expected that some PhD would have replaced it by now. > > Irrespective of that, the number of threads is usually set to match > the workload and its importance. But that depends if you are the only user, or a student doing a project on a shared machine. > > Don't you think its better for code-paths to optimized for the common case? the code paths can actually be optimised.. they just haven't been yet. > > Paul > From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 23:16:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35C3616A407; Fri, 27 Oct 2006 23:16:45 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3618E43D69; Fri, 27 Oct 2006 23:16:43 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id EEE4C45806; Fri, 27 Oct 2006 16:16:42 -0700 (PDT) Date: Fri, 27 Oct 2006 16:16:42 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20061027231642.GJ30707@riyal.ugcs.caltech.edu> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4542896D.1050001@elischer.org> Sender: jd@ugcs.caltech.edu Cc: Lev Serebryakov , Robert Watson , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 23:16:45 -0000 >From Julian Elischer , Fri, Oct 27, 2006 at 03:34:21PM -0700: > Lev Serebryakov wrote: > basically, if you and I both write programs to do a particular job > on a timesharing system, and you use threads to do so and I use > a sophisticated event handler/state machine, I shouldn't find that > my program is running like a pig because yours has 1000 slots in the > run queue and I only get run 1 in 1001 ticks. And if this hypothetical user with the 1000 threads instead uses 1000 processes we should just look the other way? Or worse we should encourage him to use processes instead of threads despite that the former ought to consume more wall-time because of the extra overhead? The answer to your situation is rlimits. Or put another way, absent such limits, if I can keep 1000 threads busy for the entire duration of your program, ipso facto I have more work to do than you do. I think what you are really saying is that you want an rlimit that allows WFQ by uid/gid/login classes. It isn't necessary for such a thing to run at the same frequency as the scheduler generally. Paul From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 23:32:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7081D16A4A0; Fri, 27 Oct 2006 23:32:25 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B33043D7C; Fri, 27 Oct 2006 23:32:20 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 16:32:20 -0700 Message-ID: <45429703.8070305@elischer.org> Date: Fri, 27 Oct 2006 16:32:19 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Paul Allen References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> <20061027231642.GJ30707@riyal.ugcs.caltech.edu> In-Reply-To: <20061027231642.GJ30707@riyal.ugcs.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lev Serebryakov , Robert Watson , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 23:32:25 -0000 Paul Allen wrote: >>From Julian Elischer , Fri, Oct 27, 2006 at 03:34:21PM -0700: >> Lev Serebryakov wrote: >> basically, if you and I both write programs to do a particular job >> on a timesharing system, and you use threads to do so and I use >> a sophisticated event handler/state machine, I shouldn't find that >> my program is running like a pig because yours has 1000 slots in the >> run queue and I only get run 1 in 1001 ticks. > And if this hypothetical user with the 1000 threads instead uses 1000 > processes we should just look the other way? Or worse we should encourage > him to use processes instead of threads despite that the former ought > to consume more wall-time because of the extra overhead? > > The answer to your situation is rlimits. there is class of problems (e.g. some java programs) that have THOUSANDS of threads, each representing an active aspect of some object. How do you put an rlimit on that without either 1/ stopping the program from working or 2/ allowing thousands of threads to exist but not screwing other users. As I said.. the fairness aspect we have is a prototype and I hoped it would be replaced by something more sophisticated. It hasn't happenned. > > Or put another way, absent such limits, if I can keep 1000 threads busy > for the entire duration of your program, ipso facto I have more work to > do than you do. no, I might have the same amount of work to do too, but I only get 1 in 1001 slots to do it in.. > > I think what you are really saying is that you want an rlimit that allows > WFQ by uid/gid/login classes. It isn't necessary for such a thing to run > at the same frequency as the scheduler generally. correct. Though WFQ is not nearly the only game in town. > > > Paul From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 23:40:24 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC1816A412 for ; Fri, 27 Oct 2006 23:40:24 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F65643D5D for ; Fri, 27 Oct 2006 23:40:23 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9RNeLtf044729; Fri, 27 Oct 2006 19:40:21 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id k9RNeKEf039181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Oct 2006 19:40:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200610272340.k9RNeKEf039181@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Oct 2006 19:38:23 -0400 To: =?iso-8859-1?Q?S=F8ren?= Schmidt From: Mike Tancsa In-Reply-To: <45427E46.6000705@deepcore.dk> References: <200610272114.k9RLEwKl038475@lava.sentex.ca> <45427E46.6000705@deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG Subject: Re: Intel DG965SS MB ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 23:40:24 -0000 At 05:46 PM 10/27/2006, S=F8ren Schmidt wrote: >Mike Tancsa wrote: >>Has anyone got this motherboard to work with=20 >>FreeBSD ? I tried fiddling with the BIOS but=20 >>no matter what, 6.2Beta does not see the ad0=20 >>(PATA drive) nor ad4 (SATA drive)... It never=20 >>sees the drive, although it does see the controller as a generic IDE= controller >> >>The intel product code is BOXDG965SSCK >> >>Does this motherboard work in 7.x ? >Dont know that exact board,but the Gigabyte=20 >965P- DS3 I've got here with the same chipset works fine. >The SATA ports on the ICH8 are fully supported and should work on any= board. >However the ICH8 has *no* PATA port, so the PATA=20 >port on mine is a JMicron chip which we support=20 >including its extra 2 SATA ports. >Some Intel boards use Marvell chips that should=20 >work as generic but early reports seems to indicate that is not the case. Hmmmm, I think the dmesg implied Intel parts for=20 the various controllers but I didnt have it on=20 serial console. However, I just got the board=20 at the end of the day and didt have time to=20 fiddle too much. I will try and update the BIOS=20 on Monday and try a few settings to see if I can get it booting. ---Mike=20 From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 23:44:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5956716A4CE; Fri, 27 Oct 2006 23:44:45 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB3D43D7E; Fri, 27 Oct 2006 23:44:30 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 02D0445806; Fri, 27 Oct 2006 16:44:29 -0700 (PDT) Date: Fri, 27 Oct 2006 16:44:29 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20061027234429.GK30707@riyal.ugcs.caltech.edu> References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <20061027213125.GI30707@riyal.ugcs.caltech.edu> <45429013.90705@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45429013.90705@elischer.org> Sender: jd@ugcs.caltech.edu Cc: Daniel Eischen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2006 23:44:45 -0000 >From Julian Elischer , Fri, Oct 27, 2006 at 04:02:43PM -0700: > In machines that are dedicated to a single task the admin is welcome > to let that task hog as much as possible. When it is supposed to > be shared, that is probably NOT the expected behaviour. When one admin controls the machine, he usually picks the number of threads per task to match the work-load. He also a good opportunity to adjust the relative priorities of the tasks. Still calling such a machine a single task system is too restrictive and presumptive. > > > >Threads are either busy (have work to do, in which case the kernel > >shouldn't be making value judgements except by way of priority) or > >they are sleeping in which case the point is moot. > > exactly, but often you get bursts of work where may many threads come to > life. Does that mean everything else should stop? Yes, precisely because the work must be done some how, some time. Now there are certain applications where latency is more critical. i.e., interactive jobs--for which the 4BSD scheduler already detects and gives a boost. Otherwise latency is something meant to be managed via user set priority levels. What business does the kernel have second guessing that? Where I am from, users are expected to nice long running computational tasks on their own. When they do not, they often discover that a sysop has done it for them. > >Preventing users from interfering with each other on a multiuser system > >is a problem for rlimits to solve. > > What would you put in rlimit to solve this problem? Be specific! > Please send diffs and code outlines. Except that it is not I who is concerned about the fairness of multiuser systems but yourself... (no offsense intended) > >On a single user-system, having an imbalance of consumer/producer threads > >is a configuration problem which again the safety net necessary is > >an rlimits mechanism that will allow the machine to be saved before it > >falls over. > > On a single user system this can all be disabled anyhow.. > which is why I suggest that the KSE option recently added be broken > into a M:N option and a FAIRNESS option. Actually, I agree that this makes a good amount of sense. Esp as I am under the impression that part of KSE is about ensuring proper signal delivery. No doubt there is no reason to break that just because "fairness" might not make sense. > >The 1000 versus 1 is still some sort of strange academic fairness fetish. > >If the process with one thread is relatively (per thread) more valuable > >that should be reflected in the scheduling priorities and implemented > >in the scheduler using a mechanism similar to WFQ. Again though: this > >is priorities not thread grouping per process. > > This is a question for the project as a whole to decide. > As I said.. "do we want 'fareness' or not?" > If not then a lot of simplification can occur. But we need to be clear > on the fact that when this is ripped out it will be a one way street. > It will be hard to put back once evolution has moved the code a bit. Fair enough. > >Irrespective of that, the number of threads is usually set to match > >the workload and its importance. > > But that depends if you are the only user, or a student doing a project > on a shared machine. It is true there are hogs in the world; such as the people who create hundreds of screen sessions that they forget to shutdown. Nonetheless, the prevailing assumption is though there are finite computational resources on a shared machine, the offered-load must be processed eventually therefore two much discrimination overhead is a waste of time. When such a community resource becomes abused--whether because of liberal intentions abused or an absense of desired rlimit knobs--deus ex machina (the sysop) is usually needed to sort the wheat from the chaff. Perhaps I've come down on your fairness too hard, but in my line of work-- networking, I often encounter the idea that the network ought to enforce fairness on flows--above and beyond the priority markers already available. i.e., by identifying and discriminating between differen tcp connections-- as if whether an offered-load is split into one-flow or two-flows or n-flows should be a determinate in the disposition thereof. I rather firmly believe that all traffic with a common CoS should be treated identically regardless of whether that traffic is predominated by some flows over others. I don't see why kernel scheduling should be different. Anyways, "the project" is probably too well versed in my opinion now. Thanks for listening, Paul From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 01:15:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E20FB16A403; Sat, 28 Oct 2006 01:15:16 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FEAC43D46; Sat, 28 Oct 2006 01:15:16 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.180.196]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J7T00B3UNH6FBB6@vms044.mailsrvcs.net>; Fri, 27 Oct 2006 20:15:07 -0500 (CDT) Date: Fri, 27 Oct 2006 21:15:04 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Daniel Eischen Message-id: <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> Cc: Paul Allen , Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 01:15:17 -0000 On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > On Fri, 27 Oct 2006, Paul Allen wrote: > > >> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: > >> The aim of the fair scheduling code is to ensure that if you, as a user, > >> make a process that starts 1000 threads, and I as a user, make an > >> unthreaded process, then I can still get to the CPU at somewhat similar > >> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > > > Ah. Let me be one of the first to take a crack at attacking this idea as > > a mistake. > > No, it is POSIX. You, the application, can write a program with > system scope or process scope threads and get whatever you behavior > you want, within rlimits of course. > > If you want unfair scheduling, then create your threads with > system scope contention, otherwise use process scope. The > kernel should be designed to allow both, and have adjustable > limits in place for (at least) system scope threads. > > Noone is saying that you can't have as many system scope threads > as you want (and as allowed by limits), just that you must also > be able to have process scope threads (with probably higher limits > or possibly no limits). > I might be missing something here, but OP was separating M:N (which is what you are referring to above), and "fairness" (not giving process with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I know the first one is POSIX and the second one is not. FWIW: as an application programmer who spent considerable amount of time lately trying to make heavily multithreaded application run most efficiently on 32-way machine, I would rather not have to deal with "fairness" -- M:N is bad enough. -- Alexandre "Sunny" Kovalenko From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 01:25:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 598F516A40F; Sat, 28 Oct 2006 01:25:09 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8AD643D53; Sat, 28 Oct 2006 01:25:06 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 18:25:06 -0700 Message-ID: <4542B171.8050601@elischer.org> Date: Fri, 27 Oct 2006 18:25:05 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 01:25:09 -0000 Alexandre "Sunny" Kovalenko wrote: > On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: >> On Fri, 27 Oct 2006, Paul Allen wrote: >> >>>> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: >>>> The aim of the fair scheduling code is to ensure that if you, as a user, >>>> make a process that starts 1000 threads, and I as a user, make an >>>> unthreaded process, then I can still get to the CPU at somewhat similar >>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >>> Ah. Let me be one of the first to take a crack at attacking this idea as >>> a mistake. >> No, it is POSIX. You, the application, can write a program with >> system scope or process scope threads and get whatever you behavior >> you want, within rlimits of course. >> >> If you want unfair scheduling, then create your threads with >> system scope contention, otherwise use process scope. The >> kernel should be designed to allow both, and have adjustable >> limits in place for (at least) system scope threads. >> >> Noone is saying that you can't have as many system scope threads >> as you want (and as allowed by limits), just that you must also >> be able to have process scope threads (with probably higher limits >> or possibly no limits). >> > I might be missing something here, but OP was separating M:N (which is > what you are referring to above), and "fairness" (not giving process > with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I > know the first one is POSIX and the second one is not. > > FWIW: as an application programmer who spent considerable amount of time > lately trying to make heavily multithreaded application run most > efficiently on 32-way machine, I would rather not have to deal with > "fairness" -- M:N is bad enough. > no, fairness is making sure that 1000 process scope threads do not negatively impact other processes. 1000 system scope threads are controlled by your ulimit settings (Each one counts as a process.) From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 01:36:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2295B16A415; Sat, 28 Oct 2006 01:36:57 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF71143D49; Sat, 28 Oct 2006 01:36:56 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.180.196]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J7T00CP5OGTN2Z1@vms044.mailsrvcs.net>; Fri, 27 Oct 2006 20:36:30 -0500 (CDT) Date: Fri, 27 Oct 2006 21:36:27 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <4542B171.8050601@elischer.org> To: Julian Elischer Message-id: <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542B171.8050601@elischer.org> Cc: Daniel Eischen , Paul Allen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 01:36:57 -0000 On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > >> On Fri, 27 Oct 2006, Paul Allen wrote: > >> > >>>> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: > >>>> The aim of the fair scheduling code is to ensure that if you, as a user, > >>>> make a process that starts 1000 threads, and I as a user, make an > >>>> unthreaded process, then I can still get to the CPU at somewhat similar > >>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > >>> Ah. Let me be one of the first to take a crack at attacking this idea as > >>> a mistake. > >> No, it is POSIX. You, the application, can write a program with > >> system scope or process scope threads and get whatever you behavior > >> you want, within rlimits of course. > >> > >> If you want unfair scheduling, then create your threads with > >> system scope contention, otherwise use process scope. The > >> kernel should be designed to allow both, and have adjustable > >> limits in place for (at least) system scope threads. > >> > >> Noone is saying that you can't have as many system scope threads > >> as you want (and as allowed by limits), just that you must also > >> be able to have process scope threads (with probably higher limits > >> or possibly no limits). > >> > > I might be missing something here, but OP was separating M:N (which is > > what you are referring to above), and "fairness" (not giving process > > with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I > > know the first one is POSIX and the second one is not. > > > > FWIW: as an application programmer who spent considerable amount of time > > lately trying to make heavily multithreaded application run most > > efficiently on 32-way machine, I would rather not have to deal with > > "fairness" -- M:N is bad enough. > > > > > no, fairness is making sure that 1000 process scope threads > do not negatively impact other processes. > 1000 system scope threads are controlled by your ulimit settings > (Each one counts as a process.) > > I apologize for misinterpreting your words. But then, if I have M:N set to 10:1, I would expect application with 1000 process scope threads to have as many CPU slots as 100 processes, or, if I have 10 system scope threads and 990 process scope threads, I would expect application to have as many CPU slots as 109 processes. Is this what you refer to as "fairness"? -- Alexandre "Sunny" Kovalenko From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 02:48:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED84516A407 for ; Sat, 28 Oct 2006 02:48:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573A643D67 for ; Sat, 28 Oct 2006 02:48:05 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9S2m1hO008230; Fri, 27 Oct 2006 22:48:01 -0400 (EDT) Date: Fri, 27 Oct 2006 22:48:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Paul Allen In-Reply-To: <20061027213125.GI30707@riyal.ugcs.caltech.edu> Message-ID: References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <20061027213125.GI30707@riyal.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 27 Oct 2006 22:48:01 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 02:48:06 -0000 On Fri, 27 Oct 2006, Paul Allen wrote: > From Daniel Eischen , Fri, Oct 27, 2006 at 04:41:16PM -0400: >> On Fri, 27 Oct 2006, Paul Allen wrote: >> >>>> From Julian Elischer , Fri, Oct 27, 2006 at >>>> 12:27:14PM -0700: >>>> The aim of the fair scheduling code is to ensure that if you, as a user, >>>> make a process that starts 1000 threads, and I as a user, make an >>>> unthreaded process, then I can still get to the CPU at somewhat similar >>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >>> >>> Ah. Let me be one of the first to take a crack at attacking this idea as >>> a mistake. >> >> No, it is POSIX. You, the application, can write a program with >> system scope or process scope threads and get whatever you behavior >> you want, within rlimits of course. > So your argument is: "if I can find a spec that does it, its right" > Sorry but if you participated in more spec writing--I do, in the IEEE-- > you'd realize that was not a good position from which to argue. Plenty > of mistakes are made in specs. If you want to argue about it, go argue in the POSIX working group, not here. We have what we have, and it IS something that is important to allow. Nothing about what you said previously is prevented by allowing both system and process scope threading. There are those that really want POSIX threading semantics, so please don't tell me that I can't have them. I certainly am not going to argue for removing system scope threading (which according to Julian is what libthr defaults to). -- DE From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 02:53:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C281616A403 for ; Sat, 28 Oct 2006 02:53:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E51A43D49 for ; Sat, 28 Oct 2006 02:53:34 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so686570nzf for ; Fri, 27 Oct 2006 19:53:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gyK74KLAA10azZouf+4rHSuAcGXknGeTNS1laF3Rjg/YbMdAZGA8Iik+rHa1lfbYhLOhvnn3cCKT2A170z5WmbKk7EWv6Dn4yLpVo/U8EFMopQj/ruOKhb8T1Soey5N8rVlXJ7to8HuEBkueol+wW/KZvlEJUNei1WhKbdT8nlw= Received: by 10.35.121.12 with SMTP id y12mr624880pym; Fri, 27 Oct 2006 19:53:33 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Fri, 27 Oct 2006 19:53:33 -0700 (PDT) Message-ID: <2a41acea0610271953l399c9b01oa2a73dcffe48cfc8@mail.gmail.com> Date: Fri, 27 Oct 2006 19:53:33 -0700 From: "Jack Vogel" To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: bogus em checkin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 02:53:34 -0000 I fat-fingered things and checked in the em driver code meant for RELENG_6 onto the HEAD. Then when I went to fix it it wouldnt let me for some reason, in any case, its being looked at. I actually think it may not break the build, but the driver you get wont be what you expect :) It should be resolved shortly, sorry bout that. Jack From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:17:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E523216A40F; Sat, 28 Oct 2006 03:17:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F9C143D49; Sat, 28 Oct 2006 03:17:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9S3HrEI093625; Fri, 27 Oct 2006 23:17:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9S3HrtK099861; Fri, 27 Oct 2006 23:17:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9483073068; Fri, 27 Oct 2006 23:17:53 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061028031753.9483073068@freebsd-current.sentex.ca> Date: Fri, 27 Oct 2006 23:17:53 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean 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: Sat, 28 Oct 2006 03:17:55 -0000 TB --- 2006-10-28 01:34:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-28 01:34:54 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-10-28 01:34:54 - cleaning the object tree TB --- 2006-10-28 01:35:32 - checking out the source tree TB --- 2006-10-28 01:35:32 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-10-28 01:35:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-28 01:44:46 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-28 01:44:46 - cd /src TB --- 2006-10-28 01:44:46 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 28 01:44:48 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 28 03:00:59 UTC 2006 TB --- 2006-10-28 03:00:59 - generating LINT kernel config TB --- 2006-10-28 03:00:59 - cd /src/sys/ia64/conf TB --- 2006-10-28 03:00:59 - /usr/bin/make -B LINT TB --- 2006-10-28 03:00:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-10-28 03:00:59 - cd /src TB --- 2006-10-28 03:00:59 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 28 03:00:59 UTC 2006 >>> 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/modules/em/../../dev/em/if_em.c:1416: warning: implicit declaration of function `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1606: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: redundant redeclaration of 'VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: previous implicit declaration of 'VLAN_TAG_VALUE' was here /src/sys/modules/em/../../dev/em/if_em.c: In function `em_rxeof': /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: implicit declaration of function `VLAN_INPUT_TAG_NEW' /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: nested extern declaration of `VLAN_INPUT_TAG_NEW' *** Error code 1 Stop in /src/sys/modules/em. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-28 03:17:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-28 03:17:53 - ERROR: failed to build lint kernel TB --- 2006-10-28 03:17:53 - tinderbox aborted TB --- 0.67 user 2.54 system 6178.85 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:32:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5008716A407; Sat, 28 Oct 2006 03:32:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 11:32:21 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> In-Reply-To: <45425D92.8060205@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281132.21466.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 03:32:31 -0000 On Saturday 28 October 2006 03:27, Julian Elischer wrote: > John, I appreciate that you have made KSE an option, but the way you > have done it shows a complete misundertanding of what is there. > > What you are calling "KSE" is in fact several different facilities that > are orthogonal. The one that you have the most trouble with is in fact > not SA based threading (refered to by most people as "KSE" but, rather > the fair scheduling code). > > The aim of the fair scheduling code is to ensure that if you, as a user, > make a process that starts 1000 threads, and I as a user, make an > unthreaded process, then I can still get to the CPU at somewhat similar > rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > the current fair scheduler tries to make sure that each process gets > a fair crack at the CPU by holding back some of the runnable threads > from the threadded process, until the ones it has in therun queu have > been completed.. A bit like telling a young child, "yes you can have > more ice-cream, when you've finished the ice-cream you already have". > > I note that David recently (in the last year) disabled the fair > scheduling capacity of the libthr code, but he didn't do it quite right > so that it still does all the work for it, and then disregarded the > result. This means that not only does a 1000 thread process (libthr) > completely push a nonthreaded process out of the system, but it pays > all the costs in the scheduler for working out how to NOT do that. > 1) I removed creating multiple threads in same ksegrp because the ksegrp implementation is broken, as I said earlier days, you have put a kg_user_pri in it and force each thread in the group to must have same user priority, this is completly broken, if I want to set different priority for each thread, how do I ? does POSIX say that every thread must have same priority? it does not and should not, when I implemented POSIX priority mutex in umtx code, I found I must throw away the ksegrp. 2) The ksegrp provided fairness is very naive since I saw weired behavior when testing David ButenHof pthread susp example. I saw the example even can not finish its test on a SMP machine. since I must throw away ksegrp because of 1), so kernel ksegrp can not help fairness for libthr. 3) Third, it adds overhead to scheduler (I have already post a number) and might make locking more diffcult for per-cpu queue like scheduler, since now you always have to contend the ksegrp runqueue lock between many CPUs, also because you have build the fairness in the scheduler and every scheduler must obey the ksegrp algorithm, it may make more diffcult to implement another alogrithm and replace it, see 4). 4) There is better fairness scheduling alogrithm published many years ago, http://www.cs.cornell.edu/Courses/cs614/2003SP/papers/KL89.pdf I believe it was implemented in Solaris. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:32:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5008716A407; Sat, 28 Oct 2006 03:32:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 11:32:21 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> In-Reply-To: <45425D92.8060205@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281132.21466.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Julian Elischer , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 03:32:31 -0000 On Saturday 28 October 2006 03:27, Julian Elischer wrote: > John, I appreciate that you have made KSE an option, but the way you > have done it shows a complete misundertanding of what is there. > > What you are calling "KSE" is in fact several different facilities that > are orthogonal. The one that you have the most trouble with is in fact > not SA based threading (refered to by most people as "KSE" but, rather > the fair scheduling code). > > The aim of the fair scheduling code is to ensure that if you, as a user, > make a process that starts 1000 threads, and I as a user, make an > unthreaded process, then I can still get to the CPU at somewhat similar > rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > > the current fair scheduler tries to make sure that each process gets > a fair crack at the CPU by holding back some of the runnable threads > from the threadded process, until the ones it has in therun queu have > been completed.. A bit like telling a young child, "yes you can have > more ice-cream, when you've finished the ice-cream you already have". > > I note that David recently (in the last year) disabled the fair > scheduling capacity of the libthr code, but he didn't do it quite right > so that it still does all the work for it, and then disregarded the > result. This means that not only does a 1000 thread process (libthr) > completely push a nonthreaded process out of the system, but it pays > all the costs in the scheduler for working out how to NOT do that. > 1) I removed creating multiple threads in same ksegrp because the ksegrp implementation is broken, as I said earlier days, you have put a kg_user_pri in it and force each thread in the group to must have same user priority, this is completly broken, if I want to set different priority for each thread, how do I ? does POSIX say that every thread must have same priority? it does not and should not, when I implemented POSIX priority mutex in umtx code, I found I must throw away the ksegrp. 2) The ksegrp provided fairness is very naive since I saw weired behavior when testing David ButenHof pthread susp example. I saw the example even can not finish its test on a SMP machine. since I must throw away ksegrp because of 1), so kernel ksegrp can not help fairness for libthr. 3) Third, it adds overhead to scheduler (I have already post a number) and might make locking more diffcult for per-cpu queue like scheduler, since now you always have to contend the ksegrp runqueue lock between many CPUs, also because you have build the fairness in the scheduler and every scheduler must obey the ksegrp algorithm, it may make more diffcult to implement another alogrithm and replace it, see 4). 4) There is better fairness scheduling alogrithm published many years ago, http://www.cs.cornell.edu/Courses/cs614/2003SP/papers/KL89.pdf I believe it was implemented in Solaris. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:51:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E45A16A40F; Sat, 28 Oct 2006 03:51:06 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0DF43D45; Sat, 28 Oct 2006 03:51:06 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 27 Oct 2006 20:51:04 -0700 Message-ID: <4542D3A8.1040500@elischer.org> Date: Fri, 27 Oct 2006 20:51:04 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542B171.8050601@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 03:51:06 -0000 Alexandre "Sunny" Kovalenko wrote: > On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote: >> Alexandre "Sunny" Kovalenko wrote: >>> On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: >>>> On Fri, 27 Oct 2006, Paul Allen wrote: >>>> >>>>>> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: >>>>>> The aim of the fair scheduling code is to ensure that if you, as a user, >>>>>> make a process that starts 1000 threads, and I as a user, make an >>>>>> unthreaded process, then I can still get to the CPU at somewhat similar >>>>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >>>>> Ah. Let me be one of the first to take a crack at attacking this idea as >>>>> a mistake. >>>> No, it is POSIX. You, the application, can write a program with >>>> system scope or process scope threads and get whatever you behavior >>>> you want, within rlimits of course. >>>> >>>> If you want unfair scheduling, then create your threads with >>>> system scope contention, otherwise use process scope. The >>>> kernel should be designed to allow both, and have adjustable >>>> limits in place for (at least) system scope threads. >>>> >>>> Noone is saying that you can't have as many system scope threads >>>> as you want (and as allowed by limits), just that you must also >>>> be able to have process scope threads (with probably higher limits >>>> or possibly no limits). >>>> >>> I might be missing something here, but OP was separating M:N (which is >>> what you are referring to above), and "fairness" (not giving process >>> with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I >>> know the first one is POSIX and the second one is not. >>> >>> FWIW: as an application programmer who spent considerable amount of time >>> lately trying to make heavily multithreaded application run most >>> efficiently on 32-way machine, I would rather not have to deal with >>> "fairness" -- M:N is bad enough. >>> >> >> no, fairness is making sure that 1000 process scope threads >> do not negatively impact other processes. >> 1000 system scope threads are controlled by your ulimit settings >> (Each one counts as a process.) >> >> > I apologize for misinterpreting your words. But then, if I have M:N set > to 10:1, I would expect application with 1000 process scope threads to > have as many CPU slots as 100 processes, or, if I have 10 system scope > threads and 990 process scope threads, I would expect application to > have as many CPU slots as 109 processes. Is this what you refer to as > "fairness"? > M:N is not a ratio, but rather the notation to say that M user threads are enacted using N kernel schedulable entities (kernel threads). usually N is limited to something like NCPU kernel schedulable entities running at a time. (not including sleeping threads waiting for IO) (NCPU is the number of CPUs). so in fact M:N is usually M user threads over over some number like 4 or 8 kernel threads (depending on #cpus) plus the number of threads waiting for IO. Julian From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:59:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F29916A407; Sat, 28 Oct 2006 03:59:51 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEBD743D46; Sat, 28 Oct 2006 03:59:50 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 27 Oct 2006 20:59:49 -0700 Message-ID: <4542D5B5.1000601@elischer.org> Date: Fri, 27 Oct 2006 20:59:49 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> In-Reply-To: <200610281132.21466.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 03:59:51 -0000 David Xu wrote: > On Saturday 28 October 2006 03:27, Julian Elischer wrote: >> John, I appreciate that you have made KSE an option, but the way you >> have done it shows a complete misundertanding of what is there. >> >> What you are calling "KSE" is in fact several different facilities that >> are orthogonal. The one that you have the most trouble with is in fact >> not SA based threading (refered to by most people as "KSE" but, rather >> the fair scheduling code). >> >> The aim of the fair scheduling code is to ensure that if you, as a user, >> make a process that starts 1000 threads, and I as a user, make an >> unthreaded process, then I can still get to the CPU at somewhat similar >> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >> >> the current fair scheduler tries to make sure that each process gets >> a fair crack at the CPU by holding back some of the runnable threads >> from the threadded process, until the ones it has in therun queu have >> been completed.. A bit like telling a young child, "yes you can have >> more ice-cream, when you've finished the ice-cream you already have". >> >> I note that David recently (in the last year) disabled the fair >> scheduling capacity of the libthr code, but he didn't do it quite right >> so that it still does all the work for it, and then disregarded the >> result. This means that not only does a 1000 thread process (libthr) >> completely push a nonthreaded process out of the system, but it pays >> all the costs in the scheduler for working out how to NOT do that. >> > > 1) I removed creating multiple threads in same ksegrp because the ksegrp > implementation is broken, as I said earlier days, you have put a kg_user_pri > in it and force each thread in the group to must have same user priority, > this is completly broken, if I want to set different priority for each thread, > how do I ? does POSIX say that every thread must have same priority? > it does not and should not, when I implemented POSIX priority mutex in > umtx code, I found I must throw away the ksegrp. I agree that it is not 'correct'. But I think it is better to fix it than remove it. > 2) The ksegrp provided fairness is very naive since I saw weired behavior > when testing David ButenHof pthread susp example. I saw the example even > can not finish its test on a SMP machine. since I must throw away ksegrp > because of 1), so kernel ksegrp can not help fairness for libthr. not necessarily.. but I agree that there can certainly be a better way to provide process scope. > 3) Third, it adds overhead to scheduler (I have already post a number) > and might make locking more diffcult for per-cpu queue like scheduler, > since now you always have to contend the ksegrp runqueue lock between > many CPUs, also because you have build the fairness in the scheduler and > every scheduler must obey the ksegrp algorithm, it may make more diffcult > to implement another alogrithm and replace it, see 4). if you do system scope threads properly then the overhead in the scheduler is small. As I indicated before. I think that by adjusting hte flags used it is possible to make system scope threads as efficient as they are in the "NOKSE" case (or very close to it.) > 4) There is better fairness scheduling alogrithm published many years ago, > http://www.cs.cornell.edu/Courses/cs614/2003SP/papers/KL89.pdf > I believe it was implemented in Solaris. I did say that what I have at the moment is not the best but w=rather the fastest for me to do. I would loke to see it replaced. My only comment is that getting rid of the KSEGRP is not required to change the fairness algorythm. I still think it is useful to have separate fairness "universes" for different groups of threads in the ssme process, no matter how it is achieved. > > David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 03:59:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F29916A407; Sat, 28 Oct 2006 03:59:51 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEBD743D46; Sat, 28 Oct 2006 03:59:50 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 27 Oct 2006 20:59:49 -0700 Message-ID: <4542D5B5.1000601@elischer.org> Date: Fri, 27 Oct 2006 20:59:49 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> In-Reply-To: <200610281132.21466.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 03:59:51 -0000 David Xu wrote: > On Saturday 28 October 2006 03:27, Julian Elischer wrote: >> John, I appreciate that you have made KSE an option, but the way you >> have done it shows a complete misundertanding of what is there. >> >> What you are calling "KSE" is in fact several different facilities that >> are orthogonal. The one that you have the most trouble with is in fact >> not SA based threading (refered to by most people as "KSE" but, rather >> the fair scheduling code). >> >> The aim of the fair scheduling code is to ensure that if you, as a user, >> make a process that starts 1000 threads, and I as a user, make an >> unthreaded process, then I can still get to the CPU at somewhat similar >> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. >> >> the current fair scheduler tries to make sure that each process gets >> a fair crack at the CPU by holding back some of the runnable threads >> from the threadded process, until the ones it has in therun queu have >> been completed.. A bit like telling a young child, "yes you can have >> more ice-cream, when you've finished the ice-cream you already have". >> >> I note that David recently (in the last year) disabled the fair >> scheduling capacity of the libthr code, but he didn't do it quite right >> so that it still does all the work for it, and then disregarded the >> result. This means that not only does a 1000 thread process (libthr) >> completely push a nonthreaded process out of the system, but it pays >> all the costs in the scheduler for working out how to NOT do that. >> > > 1) I removed creating multiple threads in same ksegrp because the ksegrp > implementation is broken, as I said earlier days, you have put a kg_user_pri > in it and force each thread in the group to must have same user priority, > this is completly broken, if I want to set different priority for each thread, > how do I ? does POSIX say that every thread must have same priority? > it does not and should not, when I implemented POSIX priority mutex in > umtx code, I found I must throw away the ksegrp. I agree that it is not 'correct'. But I think it is better to fix it than remove it. > 2) The ksegrp provided fairness is very naive since I saw weired behavior > when testing David ButenHof pthread susp example. I saw the example even > can not finish its test on a SMP machine. since I must throw away ksegrp > because of 1), so kernel ksegrp can not help fairness for libthr. not necessarily.. but I agree that there can certainly be a better way to provide process scope. > 3) Third, it adds overhead to scheduler (I have already post a number) > and might make locking more diffcult for per-cpu queue like scheduler, > since now you always have to contend the ksegrp runqueue lock between > many CPUs, also because you have build the fairness in the scheduler and > every scheduler must obey the ksegrp algorithm, it may make more diffcult > to implement another alogrithm and replace it, see 4). if you do system scope threads properly then the overhead in the scheduler is small. As I indicated before. I think that by adjusting hte flags used it is possible to make system scope threads as efficient as they are in the "NOKSE" case (or very close to it.) > 4) There is better fairness scheduling alogrithm published many years ago, > http://www.cs.cornell.edu/Courses/cs614/2003SP/papers/KL89.pdf > I believe it was implemented in Solaris. I did say that what I have at the moment is not the best but w=rather the fastest for me to do. I would loke to see it replaced. My only comment is that getting rid of the KSEGRP is not required to change the fairness algorythm. I still think it is useful to have separate fairness "universes" for different groups of threads in the ssme process, no matter how it is achieved. > > David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:06:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6D49C16A407; Sat, 28 Oct 2006 04:06:19 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 12:06:13 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> In-Reply-To: <4542D3A8.1040500@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281206.13588.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:06:20 -0000 On Saturday 28 October 2006 11:51, Julian Elischer wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote: > >> Alexandre "Sunny" Kovalenko wrote: > >>> On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > >>>> On Fri, 27 Oct 2006, Paul Allen wrote: > >>>>>> From Julian Elischer , Fri, Oct 27, 2006 at > >>>>>> 12:27:14PM -0700: The aim of the fair scheduling code is to ensure > >>>>>> that if you, as a user, make a process that starts 1000 threads, and > >>>>>> I as a user, make an unthreaded process, then I can still get to the > >>>>>> CPU at somewhat similar rates to you. A naive scheduler would give > >>>>>> you 1000 cpu slots and me 1. > >>>>> > >>>>> Ah. Let me be one of the first to take a crack at attacking this > >>>>> idea as a mistake. > >>>> > >>>> No, it is POSIX. You, the application, can write a program with > >>>> system scope or process scope threads and get whatever you behavior > >>>> you want, within rlimits of course. > >>>> > >>>> If you want unfair scheduling, then create your threads with > >>>> system scope contention, otherwise use process scope. The > >>>> kernel should be designed to allow both, and have adjustable > >>>> limits in place for (at least) system scope threads. > >>>> > >>>> Noone is saying that you can't have as many system scope threads > >>>> as you want (and as allowed by limits), just that you must also > >>>> be able to have process scope threads (with probably higher limits > >>>> or possibly no limits). > >>> > >>> I might be missing something here, but OP was separating M:N (which is > >>> what you are referring to above), and "fairness" (not giving process > >>> with 1000 *system scope* threads 1000 CPU scheduling slots). As far as > >>> I know the first one is POSIX and the second one is not. > >>> > >>> FWIW: as an application programmer who spent considerable amount of > >>> time lately trying to make heavily multithreaded application run most > >>> efficiently on 32-way machine, I would rather not have to deal with > >>> "fairness" -- M:N is bad enough. > >> > >> no, fairness is making sure that 1000 process scope threads > >> do not negatively impact other processes. > >> 1000 system scope threads are controlled by your ulimit settings > >> (Each one counts as a process.) > > > > I apologize for misinterpreting your words. But then, if I have M:N set > > to 10:1, I would expect application with 1000 process scope threads to > > have as many CPU slots as 100 processes, or, if I have 10 system scope > > threads and 990 process scope threads, I would expect application to > > have as many CPU slots as 109 processes. Is this what you refer to as > > "fairness"? > > M:N is not a ratio, but rather the notation to say that M user threads > are enacted using N kernel schedulable entities (kernel threads). > usually N is limited to something like NCPU kernel schedulable entities > running at a time. (not including sleeping threads waiting for IO) > (NCPU is the number of CPUs). > > so in fact M:N is usually M user threads over over some number like 4 or > 8 kernel threads (depending on #cpus) plus the number of threads waiting > for IO. > > Julian As you are emphasizing fairness, I must say I don't believe fairness in libpthread either, I don't think writting a fairness scheduler is an easy work, does kernel have made fairness for threads in same ksegrp, so does libpthread's userland scheduler ? they don't, it can make threads in same ksegrp misbehaviored, so what we have done is still process scheduling fairness even there is ksegrp in kernel, and now sacrificed fairness between threads. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:06:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6D49C16A407; Sat, 28 Oct 2006 04:06:19 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 12:06:13 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> In-Reply-To: <4542D3A8.1040500@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281206.13588.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:06:20 -0000 On Saturday 28 October 2006 11:51, Julian Elischer wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote: > >> Alexandre "Sunny" Kovalenko wrote: > >>> On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > >>>> On Fri, 27 Oct 2006, Paul Allen wrote: > >>>>>> From Julian Elischer , Fri, Oct 27, 2006 at > >>>>>> 12:27:14PM -0700: The aim of the fair scheduling code is to ensure > >>>>>> that if you, as a user, make a process that starts 1000 threads, and > >>>>>> I as a user, make an unthreaded process, then I can still get to the > >>>>>> CPU at somewhat similar rates to you. A naive scheduler would give > >>>>>> you 1000 cpu slots and me 1. > >>>>> > >>>>> Ah. Let me be one of the first to take a crack at attacking this > >>>>> idea as a mistake. > >>>> > >>>> No, it is POSIX. You, the application, can write a program with > >>>> system scope or process scope threads and get whatever you behavior > >>>> you want, within rlimits of course. > >>>> > >>>> If you want unfair scheduling, then create your threads with > >>>> system scope contention, otherwise use process scope. The > >>>> kernel should be designed to allow both, and have adjustable > >>>> limits in place for (at least) system scope threads. > >>>> > >>>> Noone is saying that you can't have as many system scope threads > >>>> as you want (and as allowed by limits), just that you must also > >>>> be able to have process scope threads (with probably higher limits > >>>> or possibly no limits). > >>> > >>> I might be missing something here, but OP was separating M:N (which is > >>> what you are referring to above), and "fairness" (not giving process > >>> with 1000 *system scope* threads 1000 CPU scheduling slots). As far as > >>> I know the first one is POSIX and the second one is not. > >>> > >>> FWIW: as an application programmer who spent considerable amount of > >>> time lately trying to make heavily multithreaded application run most > >>> efficiently on 32-way machine, I would rather not have to deal with > >>> "fairness" -- M:N is bad enough. > >> > >> no, fairness is making sure that 1000 process scope threads > >> do not negatively impact other processes. > >> 1000 system scope threads are controlled by your ulimit settings > >> (Each one counts as a process.) > > > > I apologize for misinterpreting your words. But then, if I have M:N set > > to 10:1, I would expect application with 1000 process scope threads to > > have as many CPU slots as 100 processes, or, if I have 10 system scope > > threads and 990 process scope threads, I would expect application to > > have as many CPU slots as 109 processes. Is this what you refer to as > > "fairness"? > > M:N is not a ratio, but rather the notation to say that M user threads > are enacted using N kernel schedulable entities (kernel threads). > usually N is limited to something like NCPU kernel schedulable entities > running at a time. (not including sleeping threads waiting for IO) > (NCPU is the number of CPUs). > > so in fact M:N is usually M user threads over over some number like 4 or > 8 kernel threads (depending on #cpus) plus the number of threads waiting > for IO. > > Julian As you are emphasizing fairness, I must say I don't believe fairness in libpthread either, I don't think writting a fairness scheduler is an easy work, does kernel have made fairness for threads in same ksegrp, so does libpthread's userland scheduler ? they don't, it can make threads in same ksegrp misbehaviored, so what we have done is still process scheduling fairness even there is ksegrp in kernel, and now sacrificed fairness between threads. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:36:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 883FD16A403; Sat, 28 Oct 2006 04:36:43 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B5643D45; Sat, 28 Oct 2006 04:36:42 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 27 Oct 2006 21:36:42 -0700 Message-ID: <4542DE59.5010500@elischer.org> Date: Fri, 27 Oct 2006 21:36:41 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> <200610281206.13588.davidxu@freebsd.org> In-Reply-To: <200610281206.13588.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , freebsd-current@freebsd.org, current@freebsd.org, "Alexandre \"Sunny\" Kovalenko" Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:36:43 -0000 >> Julian > > As you are emphasizing fairness, I must say I don't believe fairness in > libpthread either, you mean you don't think it is a good idea or that you don't think it works? (sorry, I know that your english is way better than my chinese ;-) > I don't think writing a fairness scheduler is an > easy work, does kernel have made fairness for threads in same ksegrp, > so does libpthread's userland scheduler ? The kernel is only responsible for making sure that one ksegrp (usually a process in my original idea) is not unfair to another ksegrp. What happens within the ksegrp is not it's interest. And no it isn't an easy thing to do which is why I had hoped that some PhD student would have taken it up by now :-) > they don't, it can make threads > in same ksegrp misbehaviored, so what we have done is still process > scheduling fairness even there is ksegrp in kernel, and now sacrificed > fairness between threads. once again, I'm not sure what you mean by that. > > David Xu > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:36:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 883FD16A403; Sat, 28 Oct 2006 04:36:43 +0000 (UTC) (envelope-from prvs=julian=449da6880@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B5643D45; Sat, 28 Oct 2006 04:36:42 +0000 (GMT) (envelope-from prvs=julian=449da6880@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 27 Oct 2006 21:36:42 -0700 Message-ID: <4542DE59.5010500@elischer.org> Date: Fri, 27 Oct 2006 21:36:41 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> <200610281206.13588.davidxu@freebsd.org> In-Reply-To: <200610281206.13588.davidxu@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , freebsd-current@freebsd.org, current@freebsd.org, "Alexandre \"Sunny\" Kovalenko" Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:36:43 -0000 >> Julian > > As you are emphasizing fairness, I must say I don't believe fairness in > libpthread either, you mean you don't think it is a good idea or that you don't think it works? (sorry, I know that your english is way better than my chinese ;-) > I don't think writing a fairness scheduler is an > easy work, does kernel have made fairness for threads in same ksegrp, > so does libpthread's userland scheduler ? The kernel is only responsible for making sure that one ksegrp (usually a process in my original idea) is not unfair to another ksegrp. What happens within the ksegrp is not it's interest. And no it isn't an easy thing to do which is why I had hoped that some PhD student would have taken it up by now :-) > they don't, it can make threads > in same ksegrp misbehaviored, so what we have done is still process > scheduling fairness even there is ksegrp in kernel, and now sacrificed > fairness between threads. once again, I'm not sure what you mean by that. > > David Xu > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:36:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C43CC16A415; Sat, 28 Oct 2006 04:36:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3107F43D49; Sat, 28 Oct 2006 04:36:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9S4agH5098800; Sat, 28 Oct 2006 00:36:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9S4agtC095450; Sat, 28 Oct 2006 00:36:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1F74F73068; Sat, 28 Oct 2006 00:36:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061028043642.1F74F73068@freebsd-current.sentex.ca> Date: Sat, 28 Oct 2006 00:36:42 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 04:36:44 -0000 TB --- 2006-10-28 03:17:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-28 03:17:53 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-10-28 03:17:53 - cleaning the object tree TB --- 2006-10-28 03:18:29 - checking out the source tree TB --- 2006-10-28 03:18:29 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-10-28 03:18:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-28 03:28:09 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-28 03:28:09 - cd /src TB --- 2006-10-28 03:28:09 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 28 03:28:10 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 28 04:24:57 UTC 2006 TB --- 2006-10-28 04:24:57 - generating LINT kernel config TB --- 2006-10-28 04:24:57 - cd /src/sys/sparc64/conf TB --- 2006-10-28 04:24:57 - /usr/bin/make -B LINT TB --- 2006-10-28 04:24:57 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-10-28 04:24:57 - cd /src TB --- 2006-10-28 04:24:57 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 28 04:24:57 UTC 2006 >>> 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/modules/em/../../dev/em/if_em.c:1416: warning: implicit declaration of function `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1606: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: redundant redeclaration of 'VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: previous implicit declaration of 'VLAN_TAG_VALUE' was here /src/sys/modules/em/../../dev/em/if_em.c: In function `em_rxeof': /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: implicit declaration of function `VLAN_INPUT_TAG_NEW' /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: nested extern declaration of `VLAN_INPUT_TAG_NEW' *** Error code 1 Stop in /src/sys/modules/em. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-28 04:36:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-28 04:36:41 - ERROR: failed to build lint kernel TB --- 2006-10-28 04:36:41 - tinderbox aborted TB --- 0.64 user 2.35 system 4728.17 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:56:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 581C216A417; Sat, 28 Oct 2006 04:56:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 12:55:56 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <200610281206.13588.davidxu@freebsd.org> <4542DE59.5010500@elischer.org> In-Reply-To: <4542DE59.5010500@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281255.57135.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:56:05 -0000 On Saturday 28 October 2006 12:36, Julian Elischer wrote: > >> Julian > > > > As you are emphasizing fairness, I must say I don't believe fairness in > > libpthread either, > > you mean you don't think it is a good idea or that you don't think it > works? (sorry, I know that your english is way better than my > chinese ;-) > I meant I don't think libpthread's userland scheduler + ksegrp in kernel has implemented fairness between threads correctly. > > I don't think writing a fairness scheduler is an > > easy work, does kernel have made fairness for threads in same ksegrp, > > so does libpthread's userland scheduler ? > > The kernel is only responsible for making sure that one ksegrp > (usually a process in my original idea) is not unfair to another > ksegrp. > What happens within the ksegrp is not it's interest. And no it > isn't an easy thing to do which is why I had hoped that some > PhD student would have taken it up by now :-) > > > they don't, it can make threads > > in same ksegrp misbehaviored, so what we have done is still process > > scheduling fairness even there is ksegrp in kernel, and now sacrificed > > fairness between threads. > > once again, I'm not sure what you mean by that. > From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 04:56:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 581C216A417; Sat, 28 Oct 2006 04:56:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 12:55:56 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <200610281206.13588.davidxu@freebsd.org> <4542DE59.5010500@elischer.org> In-Reply-To: <4542DE59.5010500@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610281255.57135.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Paul Allen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 04:56:05 -0000 On Saturday 28 October 2006 12:36, Julian Elischer wrote: > >> Julian > > > > As you are emphasizing fairness, I must say I don't believe fairness in > > libpthread either, > > you mean you don't think it is a good idea or that you don't think it > works? (sorry, I know that your english is way better than my > chinese ;-) > I meant I don't think libpthread's userland scheduler + ksegrp in kernel has implemented fairness between threads correctly. > > I don't think writing a fairness scheduler is an > > easy work, does kernel have made fairness for threads in same ksegrp, > > so does libpthread's userland scheduler ? > > The kernel is only responsible for making sure that one ksegrp > (usually a process in my original idea) is not unfair to another > ksegrp. > What happens within the ksegrp is not it's interest. And no it > isn't an easy thing to do which is why I had hoped that some > PhD student would have taken it up by now :-) > > > they don't, it can make threads > > in same ksegrp misbehaviored, so what we have done is still process > > scheduling fairness even there is ksegrp in kernel, and now sacrificed > > fairness between threads. > > once again, I'm not sure what you mean by that. > From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 05:03:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09FE716A403; Sat, 28 Oct 2006 05:03:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFAC143D49; Sat, 28 Oct 2006 05:03:04 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9S534Ji073259; Sat, 28 Oct 2006 01:03:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id k9S533qs015438; Sat, 28 Oct 2006 01:03:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BF71573068; Sat, 28 Oct 2006 01:03:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061028050303.BF71573068@freebsd-current.sentex.ca> Date: Sat, 28 Oct 2006 01:03:03 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 05:03:05 -0000 TB --- 2006-10-28 03:51:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-28 03:51:10 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-10-28 03:51:10 - cleaning the object tree TB --- 2006-10-28 03:51:42 - checking out the source tree TB --- 2006-10-28 03:51:42 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-10-28 03:51:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-10-28 04:01:30 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-28 04:01:30 - cd /src TB --- 2006-10-28 04:01:30 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 28 04:01:31 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 28 04:52:50 UTC 2006 TB --- 2006-10-28 04:52:50 - generating LINT kernel config TB --- 2006-10-28 04:52:50 - cd /src/sys/sun4v/conf TB --- 2006-10-28 04:52:50 - /usr/bin/make -B LINT TB --- 2006-10-28 04:52:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-10-28 04:52:50 - cd /src TB --- 2006-10-28 04:52:50 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 28 04:52:50 UTC 2006 >>> 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/modules/em/../../dev/em/if_em.c:1416: warning: implicit declaration of function `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1606: warning: nested extern declaration of `VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: redundant redeclaration of 'VLAN_TAG_VALUE' /src/sys/modules/em/../../dev/em/if_em.c:1416: warning: previous implicit declaration of 'VLAN_TAG_VALUE' was here /src/sys/modules/em/../../dev/em/if_em.c: In function `em_rxeof': /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: implicit declaration of function `VLAN_INPUT_TAG_NEW' /src/sys/modules/em/../../dev/em/if_em.c:3341: warning: nested extern declaration of `VLAN_INPUT_TAG_NEW' *** Error code 1 Stop in /src/sys/modules/em. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-28 05:03:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-28 05:03:03 - ERROR: failed to build lint kernel TB --- 2006-10-28 05:03:03 - tinderbox aborted TB --- 0.61 user 2.12 system 4313.48 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 05:34:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48B3216A412; Sat, 28 Oct 2006 05:34:38 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D851943D49; Sat, 28 Oct 2006 05:34:37 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k9S5YVJr018241; Sat, 28 Oct 2006 01:34:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200610281206.13588.davidxu@freebsd.org> References: <45425D92.8060205@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> <200610281206.13588.davidxu@freebsd.org> Date: Sat, 28 Oct 2006 01:34:30 -0400 To: David Xu , freebsd-current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: Daniel Eischen , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 05:34:38 -0000 At 12:06 PM +0800 10/28/06, David Xu wrote: >On Saturday 28 October 2006 11:51, Julian Elischer wrote: > > Alexandre "Sunny" Kovalenko wrote: > > > > > > I apologize for misinterpreting your words. But then, if I have > > > M:N set to 10:1, I would expect application with 1000 process > > > scope threads to have as many CPU slots as 100 processes, or, > > > if I have 10 system scope threads and 990 process scope threads, > > > I would expect application to have as many CPU slots as 109 > > > processes. Is this what you refer to as "fairness"? > > > > M:N is not a ratio, but rather the notation to say that M user > > threads are enacted using N kernel schedulable entities (kernel > > threads). Usually N is limited to something like NCPU kernel > > schedulable entities running at a time. (not including sleeping > > threads waiting for IO) > > (NCPU is the number of CPUs). > > > > so in fact M:N is usually M user threads over over some number > > like 4 or 8 kernel threads (depending on #cpus) plus the number > > of threads waiting for IO. > > >> Julian > >As you are emphasizing fairness, I must say I don't believe fairness >in libpthread either, I don't think writting a fairness scheduler is >an easy work, does kernel have made fairness for threads in same >ksegrp, so does libpthread's userland scheduler ? they don't, it can >make threads in same ksegrp misbehaviored, so what we have done is >still process scheduling fairness even there is ksegrp in kernel, >and now sacrificed fairness between threads. I think we have different ideas of what is the goal is with this claim of "fairness". If I understand it right, it is *not* that some static code in the kernel is going to decide which applications are fair and which ones are not fair. IIIRC, what Julian wants to do is provide a way that the administrator can make that decision. The administrator will have a way to throttle some thread-crazy process, but only if the *administrator* wants to do that. If the machine is for a single user, then that user will probably set "N" to a high value. But if the machine has a lot of users on it, then the administrator of that machine may want to set "N" to the number of CPU's on the system, or maybe the number of CPU's minus 1. And if the users don't like that, then they can go buy their own damn machine instead of using the machine someone else bought and is allowing them to access for free. At RPI we have both kinds of machines. Machines owned by a single user, and machines which have multiple students ssh'ed into at the same time. I can see wanting to throttle thread-crazy processes on some machines, and not wanting any throttling at all on others. ...but it has been a few years since the presentation that I remember Julian giving about this, so maybe I am not remembering it correctly. I do remember that whatever it was, it sounded pretty reasonable at the time. :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 07:19:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A318116A412; Sat, 28 Oct 2006 07:19:26 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 15:19:18 +0800 User-Agent: KMail/1.8.2 References: <45425D92.8060205@elischer.org> <200610281206.13588.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610281519.18843.davidxu@freebsd.org> Cc: Daniel Eischen , Garance A Drosihn , Julian Elischer , "Alexandre \"Sunny\" Kovalenko" Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 07:19:27 -0000 On Saturday 28 October 2006 13:34, Garance A Drosihn wrote: > I think we have different ideas of what is the goal is with this > claim of "fairness". > > If I understand it right, it is *not* that some static code in the > kernel is going to decide which applications are fair and which ones > are not fair. IIIRC, what Julian wants to do is provide a way that > the administrator can make that decision. The administrator will > have a way to throttle some thread-crazy process, but only if the > *administrator* wants to do that. > > If the machine is for a single user, then that user will probably > set "N" to a high value. But if the machine has a lot of users on > it, then the administrator of that machine may want to set "N" to > the number of CPU's on the system, or maybe the number of CPU's > minus 1. And if the users don't like that, then they can go buy > their own damn machine instead of using the machine someone else > bought and is allowing them to access for free. > > At RPI we have both kinds of machines. Machines owned by a single > user, and machines which have multiple students ssh'ed into at the > same time. I can see wanting to throttle thread-crazy processes on > some machines, and not wanting any throttling at all on others. > > ...but it has been a few years since the presentation that I remember > Julian giving about this, so maybe I am not remembering it correctly. > I do remember that whatever it was, it sounded pretty reasonable at > the time. :-) but you know pthread_create call() is more complex and diffcult to use than fork() which does not need any parameter, before freebsd has native thread support, the whole FreeBSD world is using fork(), and I have not seen a single complaint that postgresql should be rewritten because it is using too much CPU and driving other users out, same for Apache web server, why should threaded application be a culprit ? David Xu From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 08:19:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC3B16A40F for ; Sat, 28 Oct 2006 08:19:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A22043D49 for ; Sat, 28 Oct 2006 08:19:52 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so717374nzf for ; Sat, 28 Oct 2006 01:19:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ea85Bz7aL7z4co7Hy+Q/a4cwpBddVRVcMuRLf+84Lbmy/N0C0iaGZaLyWiaRjv8OhYjrLepoaKj3cJLl+BBrlCit53o/GiqU1oOdh/BVCMN2GmOJrbzy9WEEhWi0XA+wVFnHPoGX6twRv5krQEqxYZv9uLZHyHsjsFUvICCQ2Vw= Received: by 10.35.50.5 with SMTP id c5mr35031pyk; Sat, 28 Oct 2006 01:19:51 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Sat, 28 Oct 2006 01:19:51 -0700 (PDT) Message-ID: <2a41acea0610280119t4878f1c6q49224ac8da042d18@mail.gmail.com> Date: Sat, 28 Oct 2006 01:19:51 -0700 From: "Jack Vogel" To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: em brokenness fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 08:19:53 -0000 I've backed out the bad delta, so the world should be good again (at least as good as it was before, I can only do so much). Jack From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 09:04:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 177AA16A40F for ; Sat, 28 Oct 2006 09:04:21 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDDB643D46 for ; Sat, 28 Oct 2006 09:04:20 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9S94304032387 for ; Sat, 28 Oct 2006 02:04:04 -0700 (PDT) Date: Sat, 28 Oct 2006 11:04:00 +0200 Message-ID: From: gnn@freebsd.org To: freebsd-current@freebsd.org References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: KSE, threading, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 09:04:21 -0000 Hi, In order to try and get some more coordination around this I've emailed a few of the "principles" (how do you do that in open source?) around this issue to try and get a small plan in place to solve these problems. If you didn't get a mail from me and really care about this and also plan to write code around it, then let me know. Comments welcome, but code is often more useful ;-) Later, George From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 09:48:53 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CD9016A415; Sat, 28 Oct 2006 09:48:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADAC443D49; Sat, 28 Oct 2006 09:48:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3370F46CD2; Sat, 28 Oct 2006 05:48:52 -0400 (EDT) Date: Sat, 28 Oct 2006 10:48:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <45429703.8070305@elischer.org> Message-ID: <20061028104741.Q69980@fledge.watson.org> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> <20061027231642.GJ30707@riyal.ugcs.caltech.edu> <45429703.8070305@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Allen , Lev Serebryakov , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 09:48:53 -0000 On Fri, 27 Oct 2006, Julian Elischer wrote: > there is class of problems (e.g. some java programs) that have THOUSANDS of > threads, each representing an active aspect of some object. How do you put > an rlimit on that without either 1/ stopping the program from working or 2/ > allowing thousands of threads to exist but not screwing other users. Does the JVM actually expose thousands of threads to the OS, or does it actually do its own M:N threading internally based on its execution model? My impression is the latter, exposing threads to the OS only when it needs them to consume kernel or CPU resources. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 10:02:27 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F096716A407; Sat, 28 Oct 2006 10:02:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from relay1.wplus.net (relay1.wplus.net [195.131.52.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E8C43D46; Sat, 28 Oct 2006 10:02:26 +0000 (GMT) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru ([89.163.10.141]) by relay1.wplus.net (8.13.6/8.13.1/RELAY-DVD) with ESMTP id k9SA1eS8002903; Sat, 28 Oct 2006 14:01:44 +0400 (MSD) Date: Sat, 28 Oct 2006 14:01:44 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v2.11.02) Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <219211614.20061028140144@serebryakov.spb.ru> To: Robert Watson In-Reply-To: <20061028104741.Q69980@fledge.watson.org> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> <20061027231642.GJ30707@riyal.ugcs.caltech.edu> <45429703.8070305@elischer.org> <20061028104741.Q69980@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Allen , Julian Elischer , Lev Serebryakov , current@FreeBSD.org Subject: Re[2]: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lev Serebryakov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 10:02:28 -0000 Hello Robert, Saturday, October 28, 2006, 1:48:52 PM, you wrote: RW> Does the JVM actually expose thousands of threads to the OS, or does it RW> actually do its own M:N threading internally based on its execution RW> model? RW> My impression is the latter, exposing threads to the OS only when it RW> needs them to consume kernel or CPU resources. Wrong. Java used to be N:M ("green threads") a long time ago, and all actual versions (1.4, 1.5, future 1.6) uses 1:1 model. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 10:04:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CB0416A407; Sat, 28 Oct 2006 10:04:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E897D43D45; Sat, 28 Oct 2006 10:04:48 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5485046CC9; Sat, 28 Oct 2006 06:04:48 -0400 (EDT) Date: Sat, 28 Oct 2006 11:04:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: <200610281132.21466.davidxu@freebsd.org> Message-ID: <20061028105454.S69980@fledge.watson.org> References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 10:04:49 -0000 On Sat, 28 Oct 2006, David Xu wrote: > 3) Third, it adds overhead to scheduler (I have already post a number) and > might make locking more diffcult for per-cpu queue like scheduler, since now > you always have to contend the ksegrp runqueue lock between many CPUs, also > because you have build the fairness in the scheduler and every scheduler > must obey the ksegrp algorithm, it may make more diffcult to implement > another alogrithm and replace it, see 4). This is my single biggest concern: our scheduling, thread/process, and context management paths in the kernel are currently extremely complex. This has a number of impacts: it makes it extremely hard to read and understand, it adds significant overhead, and it makes it quite hard to modify and optimize for increasing numbers of processors. We need to be planning on a world of 128 hardware threads/machine on commodity server hardware in the immediate future, which means that the current "giant sched_lock" cannot continue much longer. Kip's prototypes of breaking out sched_lock as part of the sun4v work have been able to benefit significantly from the reduced complexity of a KSE-free kernel, and it's fairly clear that the task of improving schedule scalability is dramatically simpler when the kernel model for threading is more simple. Regardless of where the specific NO_KSE option in the kernel goes, reducing kernel scheduler/etc complexity should be a first order of business, because effective SMP work really depends on that happening. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 12:08:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65A016A40F for ; Sat, 28 Oct 2006 12:08:52 +0000 (UTC) (envelope-from thomas.sparrevohn@btinternet.com) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 5461A43D53 for ; Sat, 28 Oct 2006 12:08:51 +0000 (GMT) (envelope-from thomas.sparrevohn@btinternet.com) Received: (qmail 53005 invoked from network); 28 Oct 2006 12:08:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=q9iDNoK+kQF6LO84OtF54OCd0QKWS4wrmMjbeSachW35nRNhBCSHxn/dveq1ExRk5YlqJdFHeahBaPRaQe5VG4PQOR3++iEQaZQ+XdTKGTu3397wJbkdiBhPDCWRcWJl3LmZj6jn1PEeW6nw4G+sA6XmOxqu/fUYKwR7hz1Y1D0= ; Received: from unknown (HELO ?192.168.0.15?) (thomas.sparrevohn@btinternet.com@86.136.31.56 with plain) by smtp802.mail.ird.yahoo.com with SMTP; 28 Oct 2006 12:08:49 -0000 In-Reply-To: <20061028105454.S69980@fledge.watson.org> References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> <20061028105454.S69980@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <614921E1-9243-48BF-BB8D-BFECB5EAAD78@btinternet.com> Content-Transfer-Encoding: 7bit From: Thomas Sparrevohn Date: Sat, 28 Oct 2006 13:08:47 +0100 To: Robert Watson X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org, David Xu , Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 12:08:53 -0000 On 28 Oct 2006, at 11:04, Robert Watson wrote: > > On Sat, 28 Oct 2006, David Xu wrote: > >> 3) Third, it adds overhead to scheduler (I have already post a >> number) and might make locking more diffcult for per-cpu queue >> like scheduler, since now you always have to contend the ksegrp >> runqueue lock between many CPUs, also because you have build the >> fairness in the scheduler and every scheduler must obey the ksegrp >> algorithm, it may make more diffcult to implement another >> alogrithm and replace it, see 4). > > This is my single biggest concern: our scheduling, thread/process, > and context management paths in the kernel are currently extremely > complex. This has a number of impacts: it makes it extremely hard > to read and understand, it adds significant overhead, and it makes > it quite hard to modify and optimize for increasing numbers of > processors. We need to be planning on a world of 128 hardware > threads/machine on commodity server hardware in the immediate > future, which means that the current "giant sched_lock" cannot > continue much longer. Kip's prototypes of breaking out sched_lock > as part of the sun4v work have been able to benefit significantly > from the reduced complexity of a KSE-free kernel, and it's fairly > clear that the task of improving schedule scalability is > dramatically simpler when the kernel model for threading is more > simple. Regardless of where the specific NO_KSE option in the > kernel goes, reducing kernel scheduler/etc complexity should be a > first order of business, because effective SMP work really depends > on that happening. > I would add another concern - While I understand why fairness are useful in resource allocation - I do not think it makes sense unless the principle are use against all limited resources and hence in order for it to make sense it would mean a major rework of all allocation structures in the kernel. After all what is the use of getting CPU time of all file descriptors are used by another process etc. etc. In short the "fairness" proposed only a partial guarantee not a truly useful end-user situation. From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 14:12:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11D0816A403; Sat, 28 Oct 2006 14:12:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBF743D55; Sat, 28 Oct 2006 14:12:20 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9SECFWt022493; Sat, 28 Oct 2006 10:12:15 -0400 (EDT) Date: Sat, 28 Oct 2006 10:12:15 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200610281255.57135.davidxu@freebsd.org> Message-ID: References: <45425D92.8060205@elischer.org> <200610281206.13588.davidxu@freebsd.org> <4542DE59.5010500@elischer.org> <200610281255.57135.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Sat, 28 Oct 2006 10:12:15 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , freebsd-current@freebsd.org, Julian Elischer , "Alexandre \\Sunny\\ Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 14:12:21 -0000 On Sat, 28 Oct 2006, David Xu wrote: > On Saturday 28 October 2006 12:36, Julian Elischer wrote: >>>> Julian >>> >>> As you are emphasizing fairness, I must say I don't believe fairness in >>> libpthread either, >> >> you mean you don't think it is a good idea or that you don't think it >> works? (sorry, I know that your english is way better than my >> chinese ;-) >> > I meant I don't think libpthread's userland scheduler + ksegrp in kernel > has implemented fairness between threads correctly. I think it has, at least WRT POSIX RR and FIFO scheduling. If there are more than one ksegrps, then it depends. POSIX says that scheduling with multiple scheduling allocation domains (I think that is the wording) is implementation defined. But one of the things I want to do is to keep threads scheduled on the same kse/ksegrp, so there would be one run queue for each (libpthread's version of a) kse, and threads would stay on the same kse. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 14:12:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11D0816A403; Sat, 28 Oct 2006 14:12:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBF743D55; Sat, 28 Oct 2006 14:12:20 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9SECFWt022493; Sat, 28 Oct 2006 10:12:15 -0400 (EDT) Date: Sat, 28 Oct 2006 10:12:15 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200610281255.57135.davidxu@freebsd.org> Message-ID: References: <45425D92.8060205@elischer.org> <200610281206.13588.davidxu@freebsd.org> <4542DE59.5010500@elischer.org> <200610281255.57135.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Sat, 28 Oct 2006 10:12:15 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , freebsd-current@freebsd.org, Julian Elischer , "Alexandre \\Sunny\\ Kovalenko" , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 14:12:21 -0000 On Sat, 28 Oct 2006, David Xu wrote: > On Saturday 28 October 2006 12:36, Julian Elischer wrote: >>>> Julian >>> >>> As you are emphasizing fairness, I must say I don't believe fairness in >>> libpthread either, >> >> you mean you don't think it is a good idea or that you don't think it >> works? (sorry, I know that your english is way better than my >> chinese ;-) >> > I meant I don't think libpthread's userland scheduler + ksegrp in kernel > has implemented fairness between threads correctly. I think it has, at least WRT POSIX RR and FIFO scheduling. If there are more than one ksegrps, then it depends. POSIX says that scheduling with multiple scheduling allocation domains (I think that is the wording) is implementation defined. But one of the things I want to do is to keep threads scheduled on the same kse/ksegrp, so there would be one run queue for each (libpthread's version of a) kse, and threads would stay on the same kse. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 14:27:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D61716A416; Sat, 28 Oct 2006 14:27:19 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD50C43D6A; Sat, 28 Oct 2006 14:27:14 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k9SER31Z008780; Sat, 28 Oct 2006 10:27:03 -0400 (EDT) Date: Sat, 28 Oct 2006 10:27:03 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20061028104741.Q69980@fledge.watson.org> Message-ID: References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> <20061027231642.GJ30707@riyal.ugcs.caltech.edu> <45429703.8070305@elischer.org> <20061028104741.Q69980@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Sat, 28 Oct 2006 10:27:03 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Paul Allen , Lev Serebryakov , Julian Elischer , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 14:27:19 -0000 On Sat, 28 Oct 2006, Robert Watson wrote: > > On Fri, 27 Oct 2006, Julian Elischer wrote: > >> there is class of problems (e.g. some java programs) that have THOUSANDS of >> threads, each representing an active aspect of some object. How do you put >> an rlimit on that without either 1/ stopping the program from working or 2/ >> allowing thousands of threads to exist but not screwing other users. > > Does the JVM actually expose thousands of threads to the OS, or does it > actually do its own M:N threading internally based on its execution model? My > impression is the latter, exposing threads to the OS only when it needs them > to consume kernel or CPU resources. I think it exposes all threads to the OS. I think "green threads" was its own threading. You should ask -java, though. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 16:13:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BB8716A40F; Sat, 28 Oct 2006 16:13:25 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2D7343D49; Sat, 28 Oct 2006 16:13:24 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.1/8.13.3) with ESMTP id k9SGCdB3044218; Sat, 28 Oct 2006 09:12:39 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.1/8.13.3/Submit) id k9SGCcOW044217; Sat, 28 Oct 2006 09:12:38 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Sat, 28 Oct 2006 09:12:37 -0700 From: Greg Lewis To: Daniel Eischen Message-ID: <20061028161237.GA44174@misty.eyesbeyond.com> References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> <45426071.7020403@elischer.org> <602423478.20061028001449@serebryakov.spb.ru> <4542896D.1050001@elischer.org> <20061027231642.GJ30707@riyal.ugcs.caltech.edu> <45429703.8070305@elischer.org> <20061028104741.Q69980@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Lev Serebryakov , Paul Allen , Robert Watson , Julian Elischer , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 16:13:25 -0000 On Sat, Oct 28, 2006 at 10:27:03AM -0400, Daniel Eischen wrote: > On Sat, 28 Oct 2006, Robert Watson wrote: > >On Fri, 27 Oct 2006, Julian Elischer wrote: > > > >>there is class of problems (e.g. some java programs) that have THOUSANDS > >>of threads, each representing an active aspect of some object. How do you > >>put an rlimit on that without either 1/ stopping the program from working > >>or 2/ allowing thousands of threads to exist but not screwing other users. > > > >Does the JVM actually expose thousands of threads to the OS, or does it > >actually do its own M:N threading internally based on its execution model? > >My impression is the latter, exposing threads to the OS only when it needs > >them to consume kernel or CPU resources. > > I think it exposes all threads to the OS. I think "green threads" > was its own threading. You should ask -java, though. I believe you are correct. Since 1.4 (or 1.3 if you used "native" threads with it, which we didn't by default) its been 1:1. Green threads was a userland threading implementation entirely in the JVM, much like libc_r. It wasn't M:N but rather M:1 (since there were no system threads, just the JVMs own internal threads). -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 18:06:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E3EA16A403 for ; Sat, 28 Oct 2006 18:06:06 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F6FD43D5A for ; Sat, 28 Oct 2006 18:06:05 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.77.103]) by VL-MO-MR001.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J7U005FIYA4F6A0@VL-MO-MR001.ip.videotron.ca> for freebsd-current@freebsd.org; Sat, 28 Oct 2006 14:06:04 -0400 (EDT) Date: Sat, 28 Oct 2006 14:05:54 -0400 From: Nicolas Blais In-reply-to: <200610220957.39431.nb_root@videotron.ca> To: freebsd-current@freebsd.org Message-id: <200610281406.04246.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart116207072.hod2YsYep3; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <200610211403.43055.nb_root@videotron.ca> <20061022092137.E676@free.home.local> <200610220957.39431.nb_root@videotron.ca> User-Agent: KMail/1.9.4 Cc: Yuriy Tsibizov Subject: Re: Asus A8V hangs during pci probe on fresh-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 18:06:06 -0000 --nextPart116207072.hod2YsYep3 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > You can see me verbose dmesg here with the old kernel that works (oct 7th) > : http://24.202.77.103:8081/FreeBSD/update/dmesgverb.txt > > and a screenshot of the new: > > http://24.202.77.103:8081/FreeBSD/update/kernelbootv.jpg > > I hope this may help, > Nicolas. I'm still not able to boot today's kernel build (which makes me 3 weeks=20 behind -CURRENT) :( With : http://24.202.77.103:8081/FreeBSD/update/dmesgverb.txt http://24.202.77.103:8081/FreeBSD/update/kernelbootv.jpg I've also added : http://24.202.77.103:8081/FreeBSD/update/pciconf.txt Any help appreciated, Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #1: Sat Oct 7 15:11:02 EDT 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart116207072.hod2YsYep3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFQ5wM4wTBlvcsbJURAqPvAKCBfv8bUGsMl2UZ719QPPSEvER3PwCgxQRY ihPNaFMMqf9a1lDKRXnlrlU= =Ulqb -----END PGP SIGNATURE----- --nextPart116207072.hod2YsYep3-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 18:19:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36E9716A417; Sat, 28 Oct 2006 18:19:21 +0000 (UTC) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 670DA43D60; Sat, 28 Oct 2006 18:19:20 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([70.21.169.232]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J7U00M9RYVJ6LW0@vms042.mailsrvcs.net>; Sat, 28 Oct 2006 13:18:57 -0500 (CDT) Date: Sat, 28 Oct 2006 14:18:51 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <4542D3A8.1040500@elischer.org> To: Julian Elischer Message-id: <1162059531.872.45.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <45425D92.8060205@elischer.org> <20061027201838.GH30707@riyal.ugcs.caltech.edu> <1161998104.872.18.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542B171.8050601@elischer.org> <1161999387.872.29.camel@RabbitsDen.RabbitsLawn.verizon.net> <4542D3A8.1040500@elischer.org> Cc: Daniel Eischen , Paul Allen , current@freebsd.org Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 18:19:21 -0000 On Fri, 2006-10-27 at 20:51 -0700, Julian Elischer wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2006-10-27 at 18:25 -0700, Julian Elischer wrote: > >> Alexandre "Sunny" Kovalenko wrote: > >>> On Fri, 2006-10-27 at 16:41 -0400, Daniel Eischen wrote: > >>>> On Fri, 27 Oct 2006, Paul Allen wrote: > >>>> > >>>>>> From Julian Elischer , Fri, Oct 27, 2006 at 12:27:14PM -0700: > >>>>>> The aim of the fair scheduling code is to ensure that if you, as a user, > >>>>>> make a process that starts 1000 threads, and I as a user, make an > >>>>>> unthreaded process, then I can still get to the CPU at somewhat similar > >>>>>> rates to you. A naive scheduler would give you 1000 cpu slots and me 1. > >>>>> Ah. Let me be one of the first to take a crack at attacking this idea as > >>>>> a mistake. > >>>> No, it is POSIX. You, the application, can write a program with > >>>> system scope or process scope threads and get whatever you behavior > >>>> you want, within rlimits of course. > >>>> > >>>> If you want unfair scheduling, then create your threads with > >>>> system scope contention, otherwise use process scope. The > >>>> kernel should be designed to allow both, and have adjustable > >>>> limits in place for (at least) system scope threads. > >>>> > >>>> Noone is saying that you can't have as many system scope threads > >>>> as you want (and as allowed by limits), just that you must also > >>>> be able to have process scope threads (with probably higher limits > >>>> or possibly no limits). > >>>> > >>> I might be missing something here, but OP was separating M:N (which is > >>> what you are referring to above), and "fairness" (not giving process > >>> with 1000 *system scope* threads 1000 CPU scheduling slots). As far as I > >>> know the first one is POSIX and the second one is not. > >>> > >>> FWIW: as an application programmer who spent considerable amount of time > >>> lately trying to make heavily multithreaded application run most > >>> efficiently on 32-way machine, I would rather not have to deal with > >>> "fairness" -- M:N is bad enough. > >>> > >> > >> no, fairness is making sure that 1000 process scope threads > >> do not negatively impact other processes. > >> 1000 system scope threads are controlled by your ulimit settings > >> (Each one counts as a process.) > >> > >> > > I apologize for misinterpreting your words. But then, if I have M:N set > > to 10:1, I would expect application with 1000 process scope threads to > > have as many CPU slots as 100 processes, or, if I have 10 system scope > > threads and 990 process scope threads, I would expect application to > > have as many CPU slots as 109 processes. Is this what you refer to as > > "fairness"? > > > > M:N is not a ratio, but rather the notation to say that M user threads > are enacted using N kernel schedulable entities (kernel threads). > usually N is limited to something like NCPU kernel schedulable entities > running at a time. (not including sleeping threads waiting for IO) > (NCPU is the number of CPUs). > > so in fact M:N is usually M user threads over over some number like 4 or > 8 kernel threads (depending on #cpus) plus the number of threads waiting > for IO. > > Julian In the environment I am most familiar with -- IBM AIX -- M:N is the ratio and it is settable either systemwide or for the specific user using environment variable, e.g.: export AIXTHREAD_MNRATIO=8:1 with the minimum kernel threads allocated according to another setting: export AIXTHREAD_MINKTHREADS=4 Neither one depends on the physical CPU count in the box (which could change in the middle of application execution anyway). Both settings have known default values (8:1 and 8 respectively). Between the two I can always tell how many kernel threads given amount of the process scope threads will use. This gives me both flexibility and predictability. Am I understanding correctly that what you have implemented fixes number of kernel threads at boot time and changes the M:N ratio throughout the run time of the application? -- Alexandre "Sunny" Kovalenko From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 19:41:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 659B316A403; Sat, 28 Oct 2006 19:41:27 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2978743D46; Sat, 28 Oct 2006 19:41:27 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 14A8545806; Sat, 28 Oct 2006 12:41:25 -0700 (PDT) Date: Sat, 28 Oct 2006 12:41:25 -0700 From: Paul Allen To: Robert Watson Message-ID: <20061028194125.GL30707@riyal.ugcs.caltech.edu> References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> <20061028105454.S69980@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061028105454.S69980@fledge.watson.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org, David Xu , Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 19:41:27 -0000 >From Robert Watson , Sat, Oct 28, 2006 at 11:04:48AM +0100: > This is my single biggest concern: our scheduling, thread/process, and > context management paths in the kernel are currently extremely complex. > This has a number of impacts: it makes it extremely hard to read and > understand, it adds significant overhead, and it makes it quite hard to > modify and optimize for increasing numbers of processors. We need to be > planning on a world of 128 hardware threads/machine on commodity server > hardware in the immediate future, which means that the current "giant > sched_lock" cannot continue much longer. Kip's prototypes of breaking out > sched_lock as part of the sun4v work have been able to benefit > significantly from the reduced complexity of a KSE-free kernel, and it's > fairly clear that the task of improving schedule scalability is > dramatically simpler when the kernel model for threading is more simple. > Regardless of where the specific NO_KSE option in the kernel goes, reducing > kernel scheduler/etc complexity should be a first order of business, > because effective SMP work really depends on that happening. Let us suppose that this M:N business is important, perhaps something to consider is why and whether the kernel has so much knowledge of it. If I read Matt Dillon's comment closely enough, I believe his precise recommendation was not "something like kse as Julian read it" but rather something where this M:N component was entirely part of the userland threading support and therefore would just go away or not depending on which library you linked with. I think posix might require a global priority space though... Anyways it remains dubious in my mind that the kernel should allow a user to create many processes but penalize creating threads. The only reason I can think of is that you expect people to be sloppy with their threads and careful with their processes. Still if I am ray-tracing why should I need to make a point of picking my thread/process balance to get around your mechanism. If fairness is the goal why am I even allowed to do so? From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 19:47:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9682716A407; Sat, 28 Oct 2006 19:47:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F3B43D46; Sat, 28 Oct 2006 19:47:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B06EC46C7D; Sat, 28 Oct 2006 15:47:05 -0400 (EDT) Date: Sat, 28 Oct 2006 20:47:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20061028194125.GL30707@riyal.ugcs.caltech.edu> Message-ID: <20061028204357.A83519@fledge.watson.org> References: <45425D92.8060205@elischer.org> <200610281132.21466.davidxu@freebsd.org> <20061028105454.S69980@fledge.watson.org> <20061028194125.GL30707@riyal.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, David Xu , Julian Elischer Subject: Re: Comments on the KSE option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 19:47:09 -0000 On Sat, 28 Oct 2006, Paul Allen wrote: > From Robert Watson , Sat, Oct 28, 2006 at 11:04:48AM +0100: >> This is my single biggest concern: our scheduling, thread/process, and >> context management paths in the kernel are currently extremely complex. >> This has a number of impacts: it makes it extremely hard to read and >> understand, it adds significant overhead, and it makes it quite hard to >> modify and optimize for increasing numbers of processors. We need to be >> planning on a world of 128 hardware threads/machine on commodity server >> hardware in the immediate future, which means that the current "giant >> sched_lock" cannot continue much longer. Kip's prototypes of breaking out >> sched_lock as part of the sun4v work have been able to benefit >> significantly from the reduced complexity of a KSE-free kernel, and it's >> fairly clear that the task of improving schedule scalability is >> dramatically simpler when the kernel model for threading is more simple. >> Regardless of where the specific NO_KSE option in the kernel goes, reducing >> kernel scheduler/etc complexity should be a first order of business, >> because effective SMP work really depends on that happening. > > Let us suppose that this M:N business is important, perhaps something to > consider is why and whether the kernel has so much knowledge of it. > > If I read Matt Dillon's comment closely enough, I believe his precise > recommendation was not "something like kse as Julian read it" but rather > something where this M:N component was entirely part of the userland > threading support and therefore would just go away or not depending on which > library you linked with. > > I think posix might require a global priority space though... > > Anyways it remains dubious in my mind that the kernel should allow a user to > create many processes but penalize creating threads. > > The only reason I can think of is that you expect people to be sloppy with > their threads and careful with their processes. > > Still if I am ray-tracing why should I need to make a point of picking my > thread/process balance to get around your mechanism. If fairness is the > goal why am I even allowed to do so? I think the notion of fairness is orthogonal to M:N threading. M:N is about efficiently representing user threading to kernel space, as well as avoiding kernel involvement in user context switches when not needed. Fairness is about how the kernel allocates time slices to user processes/threads. Fairness can be implemented for both 1:1 and M:N, with the primary differences being in bookkeeping. Programmers often use threading based on a misunderstanding about performance. Threading actually increases kernel lock contention when compared with using processes for parallelism, so if the benefits from address space sharing don't outweigh the added costs of contention, threaded applications can run significantly slower than multi-process ones. Many programmers believe that threading is necessarily faster than using multiple processors, so I think we're fundamentally forced to deal with the way they do use them, rather than how they should use them. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 20:50:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8406416A403 for ; Sat, 28 Oct 2006 20:50:07 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0D4B43D5D for ; Sat, 28 Oct 2006 20:50:03 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id k9SKo16i087327 for ; Sat, 28 Oct 2006 17:50:01 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Sat, 28 Oct 2006 17:51:46 -0300 User-Agent: KMail/1.9.4 References: <200610211403.43055.nb_root@videotron.ca> <200610220957.39431.nb_root@videotron.ca> <200610281406.04246.nb_root@videotron.ca> In-Reply-To: <200610281406.04246.nb_root@videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200610281751.46929.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Asus A8V hangs during pci probe on fresh-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 20:50:07 -0000 On Saturday 28 October 2006 15:05, Nicolas Blais wrote: > > I'm still not able to boot today's kernel build (which makes me 3 weeks > behind -CURRENT) :( > > With : > http://24.202.77.103:8081/FreeBSD/update/dmesgverb.txt > http://24.202.77.103:8081/FreeBSD/update/kernelbootv.jpg > > I've also added : > http://24.202.77.103:8081/FreeBSD/update/pciconf.txt > > Any help appreciated, > Nicolas. did you try it without overclocking? I was just curious after your last msg and I tried it and it boots fine her= e,=20 but the pci slots were empty. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 21:00:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2397116A403 for ; Sat, 28 Oct 2006 21:00:10 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E1DF43D45 for ; Sat, 28 Oct 2006 21:00:10 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.77.103]) by VL-MO-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J7V00JX36C9MV50@VL-MO-MR002.ip.videotron.ca> for freebsd-current@freebsd.org; Sat, 28 Oct 2006 17:00:10 -0400 (EDT) Date: Sat, 28 Oct 2006 16:59:56 -0400 From: Nicolas Blais In-reply-to: <200610281751.46929.joao@matik.com.br> To: freebsd-current@freebsd.org Message-id: <200610281700.09301.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart2419230.Es7tsICC0R; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit References: <200610211403.43055.nb_root@videotron.ca> <200610281406.04246.nb_root@videotron.ca> <200610281751.46929.joao@matik.com.br> User-Agent: KMail/1.9.4 Cc: JoaoBR Subject: Re: Asus A8V hangs during pci probe on fresh-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 21:00:11 -0000 --nextPart2419230.Es7tsICC0R Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 28 October 2006 16:51, JoaoBR wrote: > On Saturday 28 October 2006 15:05, Nicolas Blais wrote: > > I'm still not able to boot today's kernel build (which makes me 3 weeks > > behind -CURRENT) :( > > > > With : > > http://24.202.77.103:8081/FreeBSD/update/dmesgverb.txt > > http://24.202.77.103:8081/FreeBSD/update/kernelbootv.jpg > > > > I've also added : > > http://24.202.77.103:8081/FreeBSD/update/pciconf.txt > > > > Any help appreciated, > > Nicolas. > > did you try it without overclocking? > I was just curious after your last msg and I tried it and it boots fine > here, but the pci slots were empty. I've been running this machine overclocked for about a year and a half, wit= h=20 multiple pci cards and it has been running -CURRENT fine so far.=20 Considering that, and also that I'm not the only one with the problem and t= hat=20 it happened with the update to pci.c, I'm pretty confident this is not an=20 overclocking issue, but thanks anyway. Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #1: Sat Oct 7 15:11:02 EDT 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart2419230.Es7tsICC0R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFQ8TZ4wTBlvcsbJURAphRAKDFCofhemoTGMnHsBtONjxsVsNV3gCgueqb ystD8x7mcPIJojtPmy0phrQ= =uPsc -----END PGP SIGNATURE----- --nextPart2419230.Es7tsICC0R-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 23:20:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E64916A40F; Sat, 28 Oct 2006 23:20:57 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACBC843D5F; Sat, 28 Oct 2006 23:20:53 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id k9SNKrs4077378; Sat, 28 Oct 2006 16:20:53 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id k9SNKrwd077375; Sat, 28 Oct 2006 16:20:53 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 28 Oct 2006 16:20:53 -0700 (PDT) From: mjacob@freebsd.org X-X-Sender: mjacob@ns1.feral.com To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Message-ID: <20061028161915.D77338@ns1.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: 'ncr' driver users? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@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: Sat, 28 Oct 2006 23:20:57 -0000 Does anyone out there *have* to have the old NCR driver for -current FreeBSD? -matt From owner-freebsd-current@FreeBSD.ORG Sat Oct 28 23:32:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5635916A40F for ; Sat, 28 Oct 2006 23:32:46 +0000 (UTC) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id BBA3143D58 for ; Sat, 28 Oct 2006 23:32:42 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 87973 invoked by uid 0); 28 Oct 2006 21:33:04 -0200 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.149.10):. Processed in 1.110136 secs); 28 Oct 2006 23:33:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=capeta; d=freebsdbrasil.com.br; b=AZ22AR+gHClpWRbkUkxD9RkyXmJPI20vBe78LqPoBri8GSiOXsd5ow3ohXj/0aJy+4Xgm5sRvaFYSfaIVSG9vEl0A+7xU0FeIiCpbYWVac0xklnijdh0DODsRFkoDiiH ; Received: from unknown (HELO ?10.69.69.66?) (jmelo@201.17.149.10) by capeta.freebsdbrasil.com.br with SMTP; 28 Oct 2006 21:33:01 -0200 Message-ID: <4543DA67.4030008@freebsdbrasil.com.br> Date: Sat, 28 Oct 2006 20:32:07 -0200 From: Jean Milanez Melo User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeremie Le Hen References: <20061024100641.GB20405@obiwan.tataz.chchile.org> <453DE863.7070305@freebsdbrasil.com.br> <20061024115727.GD20405@obiwan.tataz.chchile.org> <453E1FBC.5060700@freebsdbrasil.com.br> <20061025104306.GI20405@obiwan.tataz.chchile.org> <453F5271.70309@freebsdbrasil.com.br> <20061026133637.GJ20405@obiwan.tataz.chchile.org> <20061026133742.GK20405@obiwan.tataz.chchile.org> In-Reply-To: <20061026133742.GK20405@obiwan.tataz.chchile.org> Content-Type: multipart/mixed; boundary="------------060509030608050000020407" Cc: freebsd-small@FreeBSD.org, freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: Handling non-standard directories in tinybsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2006 23:32:46 -0000 This is a multi-part message in MIME format. --------------060509030608050000020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeremie Le Hen wrote: > And the patch... > > On Thu, Oct 26, 2006 at 03:36:37PM +0200, Jeremie Le Hen wrote: >> Hi Jean, >> >> On Wed, Oct 25, 2006 at 10:02:57AM -0200, Jean Milanez Melo wrote: >>>> My feeling is that TinyBSD has used the KISS principle so far. The code >>>> as well as the configuration is somewhat raw (no offence here), but it is >>>> thereby easy to use, debug and modify at needs. I am going to code this >>>> in my source tree this afternoon and I will be glad to provide you the >>>> patch. >>> That's right, make tinybsd simpler is really our idea :) >>> >>> Send to me your patch and i'll take a look. >> The patch is attached and works pretty well for me. >> In addition to tinybsd.localfiles, I've made a few improvements: >> - I've moved the configuration filenames in a variable ; >> - When computing "sub-dependencies", use a temporary alternate file >> and then merge it back to the main dependency file ; >> - "chflags 0" files that are to be turned into symlinks before unlinking >> them ; >> - Handle /boot.config correctly in the configuration directory. >> >> Thank you. >> Regards, > > Hi Jeremie, Your patch was good, but i've made some changes. Here the patch. Take a look and tell me what do you think, if it's ok for you i'll ask Julian to commit. Thanks. Jean --------------060509030608050000020407 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="tinybsd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tinybsd.diff" Index: README =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/README,v retrieving revision 1.1 diff -u -r1.1 README --- README 20 Sep 2006 22:24:17 -0000 1.1 +++ README 28 Oct 2006 23:22:41 -0000 @@ -69,6 +69,10 @@ usr/sbin/pwd_mkdb usr/sbin/setkey +tinybsd.localfiles: Similar to tinybsd.basefiles but for /usr/local/. The +difference is that directories will have to be created by TinyBSD because +they are not handle by mtree(1). + etc/: This is the directory where you can put your custom /etc configuration. # ls /usr/src/tools/tools/tinybsd/tinybsd Index: tinybsd =================================================================== RCS file: /home/ncvs/src/tools/tools/tinybsd/tinybsd,v retrieving revision 1.4 diff -u -r1.4 tinybsd --- tinybsd 11 Oct 2006 21:46:53 -0000 1.4 +++ tinybsd 28 Oct 2006 23:22:41 -0000 @@ -14,6 +14,8 @@ fi WORKDIR=/usr/obj/tinybsdbuild KERNCONF=TINYBSD +BASEFILE="tinybsd.basefiles" +LOCALFILE="tinybsd.localfiles" DEFINSTARGS="-o 0 -g 0 -m 555" TS="=====>" @@ -239,6 +241,10 @@ fi } +rotate_buidlog() { + mv -f ${HOME}/tinybsd.log ${HOME}/tinybsd.log.old +} + remove_workdir() { chflags -R noschg ${WORKDIR} echo "${TS} Removing "${WORKDIR} @@ -250,7 +256,7 @@ prework() { - remove_workdir + remove_workdir mkdir -p ${WORKDIR} } @@ -259,18 +265,18 @@ echo "${TS} Creating directory hierarchy... " mtree -deU -f /etc/mtree/BSD.root.dist -p ${WORKDIR} mtree -deU -f /etc/mtree/BSD.usr.dist -p ${WORKDIR}/usr + mtree -deU -f /etc/mtree/BSD.local.dist -p ${WORKDIR}/usr/local mtree -deU -f /etc/mtree/BSD.var.dist -p ${WORKDIR}/var } - copy_binaries() { -#set -xv - for file in `cat ${CURRENTDIR}/conf/${CONF}/tinybsd.basefiles | grep -v "#" | \ + cd ${CURRENTDIR}/conf/${CONF} + + for file in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | \ cut -f1 -d":" | sort | uniq` ; do echo "${TS} Copying "/${file}" to "${WORKDIR}/${file} cp -fp /${file} ${WORKDIR}/${file} ; done -#set +xv } make_kernel() { @@ -293,7 +299,7 @@ TDEPFILES="`mktemp -t depsymlnk`" cd ${CURRENTDIR}/conf/${CONF} - for file in `cat tinybsd.basefiles | grep -v "#" | cut -f1 -d":"`; do + for file in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | cut -f1 -d":"`; do ldd -f "%p\n" /${file} >> ${TDEPFILE} ; # don't worry on progs been "not dynamic" done @@ -305,7 +311,7 @@ echo $pamdep >> ${TDEPFILE} ; ldd -f "%p\n" /${pamdep} >> ${TDEPFILE} ; done - + for lib in `cat ${TDEPFILE} | sort | uniq`; do echo "${TS} Copying "${lib}" to "${WORKDIR}${lib} cp -fp ${lib} ${WORKDIR}${lib} ; @@ -321,6 +327,7 @@ TARGET_FILE=`echo $i | awk -F ":" '{print $2}'` echo "${TS} Unlinking ${WORKDIR}${TARGET_FILE}" + chroot ${WORKDIR} /bin/chflags 0 ${TARGET_FILE} chroot ${WORKDIR} /bin/rm -f ${TARGET_FILE} echo "${TS} Symlinking ${SOURCE_FILE} to ${TARGET_FILE}" @@ -349,27 +356,29 @@ ssh-keygen -t rsa -f ${WORKDIR}/etc/ssh/ssh_host_rsa_key -N '' } -personal_directories() { +personal_conf() { echo "${TS} Copying your custom configuration on conf/ ..." - for custom in `find ${CURRENTDIR}/conf/${CONF}/ -type d -depth 1`; do + for custom in `find ${CURRENTDIR}/conf/${CONF}/ -type d -depth 1 \! -name CVS`; do cp -Rp ${custom}/* ${WORKDIR}/${custom#${CURRENTDIR}/conf/${CONF}/}/ done + + if [ -f ${CURRENTDIR}/conf/${CONF}/boot.config ]; then + cp ${CURRENTDIR}/conf/${CONF}/boot.config ${WORKDIR}/boot.config + fi } symlinks() { -#set -xv - for i in `cat tinybsd.basefiles | grep -v "#" | grep ":"`; do +set -xv + for i in `cat ${BASEFILE} ${LOCALFILE} | grep -v "#" | grep ":"`; do SOURCE_FILE=`echo $i | awk -F ":" {'print $1'}` TARGET_FILE=`echo $i | awk -F ":" {'print $2'}` chroot ${WORKDIR} /bin/ln -vs /${SOURCE_FILE} ${TARGET_FILE} done -#set +xv +set +xv } create_image() { - #set -ex - VNODEFILE=`mktemp -t tinybsd` IMGMNT=`mktemp -d -t tinybsd` @@ -448,6 +457,9 @@ loadconfig saveconfig +# Rotate build log +rotate_buidlog + # Now start logging. ( # Do the build @@ -460,7 +472,7 @@ symlinks create_etc create_ssh_keys - personal_directories + personal_conf create_image #set +xv ) 2>&1 |tee -a ${HOME}/tinybsd.log Index: conf/bridge/tinybsd.localfiles =================================================================== RCS file: conf/bridge/tinybsd.localfiles diff -N conf/bridge/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/bridge/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/default/tinybsd.localfiles =================================================================== RCS file: conf/default/tinybsd.localfiles diff -N conf/default/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/default/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/firewall/tinybsd.localfiles =================================================================== RCS file: conf/firewall/tinybsd.localfiles diff -N conf/firewall/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/firewall/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/minimal/tinybsd.localfiles =================================================================== RCS file: conf/minimal/tinybsd.localfiles diff -N conf/minimal/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/minimal/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/vpn/tinybsd.localfiles =================================================================== RCS file: conf/vpn/tinybsd.localfiles diff -N conf/vpn/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/vpn/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/wireless/tinybsd.localfiles =================================================================== RCS file: conf/wireless/tinybsd.localfiles diff -N conf/wireless/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/wireless/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + Index: conf/wrap/tinybsd.localfiles =================================================================== RCS file: conf/wrap/tinybsd.localfiles diff -N conf/wrap/tinybsd.localfiles --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ conf/wrap/tinybsd.localfiles 28 Oct 2006 23:22:41 -0000 @@ -0,0 +1,6 @@ +# $FreeBSD$ +# Add here your third-party applications that are already installed on /usr/local +# Make sure you have enough space to add it. +# Example: +# usr/local/sbin/httpd + --------------060509030608050000020407--