From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 01:27:21 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EC1716A417; Sun, 15 Oct 2006 01:27:21 +0000 (UTC) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9393043D46; Sun, 15 Oct 2006 01:27:20 +0000 (GMT) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from [84.173.204.149] (helo=[192.168.0.136]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GYumd12Vn-0003My; Sun, 15 Oct 2006 03:27:19 +0200 From: Ekkehard Morgenstern To: David Xu Date: Sun, 15 Oct 2006 03:26:03 +0200 User-Agent: KMail/1.9.1 References: <200610141540.09999.ekkehard.morgenstern@onlinehome.de> <200610150732.06291.davidxu@freebsd.org> In-Reply-To: <200610150732.06291.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9985dda5cbe98f4670734048a5dbacd9 Cc: freebsd-hackers@freebsd.org Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 01:27:21 -0000 On Sunday 15 October 2006 01:32, David Xu wrote: > You are going to be unable to use libc if you create raw thread in your > program, libc uses pthread APIs, if you create a raw thread, your > program will crash if you use any libc function which needs pthread > interface. I don't want to link to libc. So, how do I create a raw thread? From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 01:31:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A91E416A403; Sun, 15 Oct 2006 01:31:52 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Ekkehard Morgenstern Date: Sun, 15 Oct 2006 09:31:44 +0800 User-Agent: KMail/1.8.2 References: <200610141540.09999.ekkehard.morgenstern@onlinehome.de> <200610150732.06291.davidxu@freebsd.org> <200610150326.03279.ekkehard.morgenstern@onlinehome.de> In-Reply-To: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610150931.44220.davidxu@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 01:31:53 -0000 On Sunday 15 October 2006 09:26, Ekkehard Morgenstern wrote: > On Sunday 15 October 2006 01:32, David Xu wrote: > > You are going to be unable to use libc if you create raw thread in your > > program, libc uses pthread APIs, if you create a raw thread, your > > program will crash if you use any libc function which needs pthread > > interface. > > I don't want to link to libc. So, how do I create a raw thread? You can use KSE syscalls or THR syscalls, for KSE syscalls you should use bound thread, otherwise you have to support UPCALLS and other complex things. David Xu From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 08:13:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B912C16A591; Sun, 15 Oct 2006 08:13:11 +0000 (UTC) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 192BB43D45; Sun, 15 Oct 2006 08:13:11 +0000 (GMT) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from [84.173.236.84] (helo=[192.168.0.136]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GZ17N3ZCC-0002hL; Sun, 15 Oct 2006 10:13:10 +0200 From: Ekkehard Morgenstern To: David Xu Date: Sun, 15 Oct 2006 10:11:53 +0200 User-Agent: KMail/1.9.1 References: <200610141540.09999.ekkehard.morgenstern@onlinehome.de> <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <200610150931.44220.davidxu@freebsd.org> In-Reply-To: <200610150931.44220.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610151011.53724.ekkehard.morgenstern@onlinehome.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9985dda5cbe98f4670734048a5dbacd9 Cc: freebsd-hackers@freebsd.org Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 08:13:11 -0000 On Sunday 15 October 2006 03:31, David Xu wrote: > You can use KSE syscalls or THR syscalls, for KSE syscalls you > should use bound thread, otherwise you have to support > UPCALLS and other complex things. How do I use THR syscalls? From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 09:05:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40F6816A412 for ; Sun, 15 Oct 2006 09:05:01 +0000 (UTC) (envelope-from usleepless@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E9A443D58 for ; Sun, 15 Oct 2006 09:05:00 +0000 (GMT) (envelope-from usleepless@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1485151nfc for ; Sun, 15 Oct 2006 02:04:59 -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=cfRvc4l8HV8fJhK2IfABVy0DvXrTU5ZOLbxBJmVJCavSSpHz7lI3wlK1Ey3Wp1EpdW6C5xlGAaxWTXkxmypx6kU+1D/aWzGp42IRaiLxBmiCuiy/vAT4rycyHp7+1lbbo9l8mJ6Pyw4uVCgiDCJM7Nt3revJ6TjJ/rU30vAaUlU= Received: by 10.78.134.12 with SMTP id h12mr6182020hud; Sun, 15 Oct 2006 02:04:59 -0700 (PDT) Received: by 10.78.124.12 with HTTP; Sun, 15 Oct 2006 02:04:58 -0700 (PDT) Message-ID: Date: Sun, 15 Oct 2006 11:04:58 +0200 From: usleepless@gmail.com To: freebsd-hackers@freebsd.org 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: Subject: Fwd: Removing Giant from a driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 09:05:01 -0000 ---------- Forwarded message ---------- From: usleepless@gmail.com Date: Oct 14, 2006 10:32 PM Subject: Removing Giant from a driver To: freebsd-questions@freebsd.org Hi All, i have been tweaking the pvr250 driver to support pvr150s/500s. now i want to remove Giant from the code. problem is, i am not sure what to do. i have created a mutex which replaces the spltty and splx calls. but this crashes my box :-) the original code looks like this: /* * Allocate a DMA tag for the scatter / gather list. */ error = bus_dma_tag_create(sc->parent_dmat, 1, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, CXM_SG_BUFFERS * sizeof(struct cxm_sg_entry), 1, BUS_SPACE_MAXSIZE_32BIT, 0, #if __FreeBSD_version >= 501102 busdma_lock_mutex, &Giant, #endif &sc->enc_sg.dmat); what should it look like? and how will i prevent the interrupt routine from interfering with userland operations? can i place a "mtx_lock()" call in the interrupt routine? is there a howto somewhere? regards, usleep From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 13:56:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA15016A412; Sun, 15 Oct 2006 13:56:40 +0000 (UTC) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from FreeBSD.csie.nctu.edu.tw (freebsd.csie.nctu.edu.tw [140.113.17.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B5E43D49; Sun, 15 Oct 2006 13:56:40 +0000 (GMT) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from localhost (localhost.csie.nctu.edu.tw [127.0.0.1]) by FreeBSD.csie.nctu.edu.tw (Postfix) with ESMTP id 4F9FA7E908; Sun, 15 Oct 2006 21:57:11 +0800 (CST) Received: from FreeBSD.csie.nctu.edu.tw ([127.0.0.1]) by localhost (FreeBSD.csie.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJoBqNjAdz1R; Sun, 15 Oct 2006 21:57:10 +0800 (CST) Received: by FreeBSD.csie.nctu.edu.tw (Postfix, from userid 1038) id A28897E98D; Sun, 15 Oct 2006 21:57:10 +0800 (CST) To: FreeBSD-gnats-submit@freebsd.org From: Cheng-Lung Sung X-send-pr-version: 3.113 X-GNATS-Notify: Message-Id: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> Date: Sun, 15 Oct 2006 21:57:10 +0800 (CST) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cheng-Lung Sung List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 13:56:41 -0000 >Submitter-Id: current-users >Originator: Cheng-Lung Sung >Organization: FreeBSD @ Taiwan >Confidential: no >Synopsis: [PATCH] sys/sem.h should include sys/types.h >Severity: non-critical >Priority: low >Category: kern >Class: sw-bug >Release: FreeBSD 6.1-PRERELEASE i386 >Environment: System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Thu May 11 14:31:45 CST 2006 root@FreeBSD.csie.nctu.edu.tw:/home/usr.obj/usr/src/sys/FREEBSD i386 >Description: - sys/sem.h has included sys/ipc.h, which includes sys/_types.h but it (and its including files) does not include sys/types.h - therefore, in sys/sem.h struct semid_ds declares "time_t sem_otime;" ...etc - if we only compile a program which do not include sys/types.h, it will fail. >How-To-Repeat: test the following program (copy from devel/ruby-sysvipc), named conftest.c: 1: #include 2: 3: /*top*/ 4: int 5: main () 6: { 7: if ((union semun *) 0) 8: return 0; 9: if (sizeof (union semun)) 10: return 0; 11: ; 12: return 0; 13: } We will got the following result: In file included from conftest.c:1: /usr/include/sys/sem.h:21: error: syntax error before "time_t" /usr/include/sys/sem.h:23: error: syntax error before "time_t" >Fix: Index: sys/sys/sem.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sem.h,v retrieving revision 1.29 diff -u -r1.29 sem.h --- sys/sys/sem.h 17 Nov 2004 13:12:06 -0000 1.29 +++ sys/sys/sem.h 15 Oct 2006 13:47:37 -0000 @@ -10,6 +10,7 @@ #ifndef _SYS_SEM_H_ #define _SYS_SEM_H_ +#include #include struct sem; From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 15:22:22 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A22C16A412; Sun, 15 Oct 2006 15:22:22 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B01843D99; Sun, 15 Oct 2006 15:22:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 44DB210B17D; Mon, 16 Oct 2006 01:22:01 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 466C58C02; Mon, 16 Oct 2006 01:22:00 +1000 (EST) Date: Mon, 16 Oct 2006 01:21:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Cheng-Lung Sung In-Reply-To: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> Message-ID: <20061016011559.W61639@delplex.bde.org> References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 15 Oct 2006 15:24:38 +0000 Cc: freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-bugs@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 15:22:22 -0000 On Sun, 15 Oct 2006, Cheng-Lung Sung wrote: > System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Thu May 11 14:31:45 CST 2006 root@FreeBSD.csie.nctu.edu.tw:/home/usr.obj/usr/src/sys/FREEBSD i386 > >> Description: > - sys/sem.h has included sys/ipc.h, which includes sys/_types.h > but it (and its including files) does not include sys/types.h > - therefore, in sys/sem.h struct semid_ds declares "time_t sem_otime;" ...etc > - if we only compile a program which do not include sys/types.h, it will fail. Including sys/types.h would add lots of namespace pollution which sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too hard -- POSIX requires it to declare time_t (and pid_t, key_t and size_t, which it already declares). Bruce From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 15 23:12:51 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5101016A407 for ; Sun, 15 Oct 2006 23:12:51 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-hackers@freebsd.org Date: Mon, 16 Oct 2006 07:12:42 +0800 User-Agent: KMail/1.8.2 References: <200610141540.09999.ekkehard.morgenstern@onlinehome.de> <200610150931.44220.davidxu@freebsd.org> <200610151011.53724.ekkehard.morgenstern@onlinehome.de> In-Reply-To: <200610151011.53724.ekkehard.morgenstern@onlinehome.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610160712.42534.davidxu@freebsd.org> Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 23:12:51 -0000 On Sunday 15 October 2006 16:11, Ekkehard Morgenstern wrote: > On Sunday 15 October 2006 03:31, David Xu wrote: > > You can use KSE syscalls or THR syscalls, for KSE syscalls you > > should use bound thread, otherwise you have to support > > UPCALLS and other complex things. > > How do I use THR syscalls? Yes, you can use THR syscalls, they are more simple. you can use thr_new to create a thread, and use thr_exit to exit a thread. You can learn how to use them by reading some code in libthr, note, this interfaces are only for thread library implementation, it is not advocated to use them in application. David Xu From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 01:21:01 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7FC816A403; Mon, 16 Oct 2006 01:21:01 +0000 (UTC) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from FreeBSD.csie.nctu.edu.tw (freebsd.csie.nctu.edu.tw [140.113.17.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EED643D4C; Mon, 16 Oct 2006 01:21:00 +0000 (GMT) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from localhost (localhost.csie.nctu.edu.tw [127.0.0.1]) by FreeBSD.csie.nctu.edu.tw (Postfix) with ESMTP id 48D7F7E9C6; Mon, 16 Oct 2006 09:21:32 +0800 (CST) Received: from FreeBSD.csie.nctu.edu.tw ([127.0.0.1]) by localhost (FreeBSD.csie.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfri3moTYYQS; Mon, 16 Oct 2006 09:21:31 +0800 (CST) Received: by FreeBSD.csie.nctu.edu.tw (Postfix, from userid 1038) id 9D2987E9C7; Mon, 16 Oct 2006 09:21:31 +0800 (CST) Date: Mon, 16 Oct 2006 09:21:31 +0800 From: Cheng-Lung Sung To: Bruce Evans Message-ID: <20061016012131.GA22894@FreeBSD.csie.nctu.edu.tw> References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> <20061016011559.W61639@delplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20061016011559.W61639@delplex.bde.org> X-Fingerprint: E0BC 57F9 F44B 46C6 DB53 8462 F807 89F3 956E 8BC1 X-Public-Key: http://sungsung.dragon2.net/pubring.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@FreeBSD.org, freebsd-bugs@FreeBSD.org, Cheng-Lung Sung , FreeBSD-gnats-submit@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 01:21:01 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=big5 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2006 at 01:21:59AM +1000, Bruce Evans wrote: > On Sun, 15 Oct 2006, Cheng-Lung Sung wrote: >=20 > >System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Thu M= ay=20 > >11 14:31:45 CST 2006 =20 > >root@FreeBSD.csie.nctu.edu.tw:/home/usr.obj/usr/src/sys/FREEBSD i386 > > > >>Description: > >- sys/sem.h has included sys/ipc.h, which includes sys/_types.h > > but it (and its including files) does not include sys/types.h > >- therefore, in sys/sem.h struct semid_ds declares "time_t sem_otime;"= =20 > >...etc > >- if we only compile a program which do not include sys/types.h, it will= =20 > >fail. >=20 > Including sys/types.h would add lots of namespace pollution which > sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too > hard -- POSIX requires it to declare time_t (and pid_t, key_t and size_t, > which it already declares). >=20 > Bruce You're right, I should try to pass COMMON_HEADERS to ruby-sysipc=20 instead of polluting namespace. Thanks, --=20 Cheng-Lung Sung - clsung@ --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFMt6a+AeJ85Vui8ERAkpiAKCT0qnMLSJa1lUsjqBA7XOpvkKeQgCfc0sn r/6xcrfx71DYTCstiZC8GPA= =P6zp -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 07:49:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1741A16A403 for ; Mon, 16 Oct 2006 07:49:08 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7ED743D55 for ; Mon, 16 Oct 2006 07:49:05 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 6E35C3F17; Mon, 16 Oct 2006 09:49:04 +0200 (CEST) Date: Mon, 16 Oct 2006 09:49:04 +0200 From: VANHULLEBUS Yvan To: freebsd-hackers@freebsd.org Message-ID: <20061016074904.GA30889@zen.inc> References: <20061013074136.GA31459@zen.inc> <20061013080407.GA26522@britannica.bec.de> <20061013174215.GB83555@keira.kiwi-computer.com> <200610131416.51379.jhb@freebsd.org> <20061013185757.GA88689@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061013185757.GA88689@keira.kiwi-computer.com> Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 07:49:08 -0000 On Fri, Oct 13, 2006 at 01:57:58PM -0500, Rick C. Petty wrote: > On Fri, Oct 13, 2006 at 02:16:51PM -0400, John Baldwin wrote: [fscking a RO partition] > > I think it's broken in 5.x as well. It's fallout from GEOM IIRC, and it is > > annoying. > > Grr, I meant 4.x not 5.x, and I thought the problem started about the time > bg fsck was introduced... Right: I just tried on a FreeBSD 4.11, and I can fsck a partition which has just been remounted RO. Could it be interesting (and quite safe !) to recompile 4.X's fsck under FreeBSD6 and do the test again on FreeBSD 6 ? Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 08:15:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD9C916A4CA for ; Mon, 16 Oct 2006 08:15:59 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C5C743D5C for ; Mon, 16 Oct 2006 08:15:59 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 607C13F17; Mon, 16 Oct 2006 10:15:58 +0200 (CEST) Date: Mon, 16 Oct 2006 10:15:58 +0200 From: VANHULLEBUS Yvan To: freebsd-hackers@freebsd.org Message-ID: <20061016081558.GA31560@zen.inc> References: <20061013074136.GA31459@zen.inc> <20061013080407.GA26522@britannica.bec.de> <20061013174215.GB83555@keira.kiwi-computer.com> <200610131416.51379.jhb@freebsd.org> <20061013185757.GA88689@keira.kiwi-computer.com> <20061016074904.GA30889@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016074904.GA30889@zen.inc> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 08:15:59 -0000 On Mon, Oct 16, 2006 at 09:49:04AM +0200, VANHULLEBUS Yvan wrote: > On Fri, Oct 13, 2006 at 01:57:58PM -0500, Rick C. Petty wrote: [fscking a RO partition] > > Grr, I meant 4.x not 5.x, and I thought the problem started about the time > > bg fsck was introduced... > > Right: I just tried on a FreeBSD 4.11, and I can fsck a partition > which has just been remounted RO. > > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > under FreeBSD6 and do the test again on FreeBSD 6 ? 4.X's fsck doesn't compile directly on FreeBSD 6..... But I had a quick look at setup.c in both versions (this is the location of the "NO WRITE ACCESS" error), and looks like there is exactly the same code in both versions, except the background flag test in FreeBSD6 (which does not change anything, as I am NOT using that flag). Is this a bug "somewhere" in the kernel ? Shall I run fsck with the background flag in my situation (but it will still have no write access, it just won't generate the output message) ? Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 12:13:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0CC516A4E1; Mon, 16 Oct 2006 12:13:24 +0000 (UTC) (envelope-from marcov@stack.nl) Received: from mx1.stack.nl (meestal.stack.nl [131.155.140.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C5EE43D81; Mon, 16 Oct 2006 12:09:16 +0000 (GMT) (envelope-from marcov@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EEE044B26D; Mon, 16 Oct 2006 14:08:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 816) id E146C2287D; Mon, 16 Oct 2006 14:08:59 +0200 (CEST) In-Reply-To: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> To: Ekkehard Morgenstern Date: Mon, 16 Oct 2006 14:08:59 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL123] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20061016120859.E146C2287D@snail.stack.nl> From: marcov@stack.nl (Marco van de Voort) Cc: freebsd-hackers@freebsd.org, David Xu Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 12:13:24 -0000 > > On Sunday 15 October 2006 01:32, David Xu wrote: > > You are going to be unable to use libc if you create raw thread in your > > program, libc uses pthread APIs, if you create a raw thread, your > > program will crash if you use any libc function which needs pthread > > interface. > > I don't want to link to libc. So, how do I create a raw thread? (digging deep into memory) Have a look how the linuxator emulates the clone() syscall with (IIRC) rfork. A limited route, but iirc it works. The Free Pascal 1.0 compiler (2000) uses this for a form of threading (4.x though, and 2.0+ uses pthreads) From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 13:10:37 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A95A516A403 for ; Mon, 16 Oct 2006 13:10:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0071D43D7B for ; Mon, 16 Oct 2006 13:10:36 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qjylqn@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k9GDAU9Y007508; Mon, 16 Oct 2006 15:10:35 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k9GDAK40007507; Mon, 16 Oct 2006 15:10:20 +0200 (CEST) (envelope-from olli) Date: Mon, 16 Oct 2006 15:10:20 +0200 (CEST) Message-Id: <200610161310.k9GDAK40007507@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, babkin@users.sourceforge.net In-Reply-To: <392921.500871160788419415.JavaMail.root@vms062.mailsrvcs.net> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 16 Oct 2006 15:10:36 +0200 (CEST) X-Mailman-Approved-At: Mon, 16 Oct 2006 13:17:40 +0000 Cc: Subject: Re: "tar -c|gzip" faster than "tar -cz"?!? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, babkin@users.sourceforge.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 13:10:37 -0000 Sergey Babkin wrote: > From: Oliver Fromme wrote: > > The difference in CPU time (and wall clock time) seems > > simply to be caused by different compression code. gzip > > is noticeably more efficient than libz, at least on the > > OS/processor combination where I tested it (Athlon64 with > > FreeBSD/i386 6.2-PRERELEASE). > > Any chance that gzip uses a different version of libz? I've only had a quick look at the gzip code, but it doesn't seem to use libz at all.. > Or maybe the buffer size is different? Yet another > possibility could be if tar calls zlib with the SYNC > (or is that FLUSH? something like that) flag on each > chunk, this would kill both the performance and the > compression rate. Then again, the default compression > level may be different (but it should be making the > speed higher if the ratio falls lower). The default compression level seems to be the same in both cases (-6). The sizes of the compressed archives differ slightly, but when I change the compression level with gzip manually (in either direction), then there's a much larger difference. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 19:16:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73CA816A403 for ; Mon, 16 Oct 2006 19:16:37 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 6250E43DB4 for ; Mon, 16 Oct 2006 19:16:27 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 80880 invoked by uid 2001); 16 Oct 2006 19:16:26 -0000 Date: Mon, 16 Oct 2006 14:16:26 -0500 From: "Rick C. Petty" To: VANHULLEBUS Yvan Message-ID: <20061016191626.GD77730@keira.kiwi-computer.com> References: <20061013074136.GA31459@zen.inc> <20061013080407.GA26522@britannica.bec.de> <20061013174215.GB83555@keira.kiwi-computer.com> <200610131416.51379.jhb@freebsd.org> <20061013185757.GA88689@keira.kiwi-computer.com> <20061016074904.GA30889@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016074904.GA30889@zen.inc> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 19:16:37 -0000 On Mon, Oct 16, 2006 at 09:49:04AM +0200, VANHULLEBUS Yvan wrote: > > Right: I just tried on a FreeBSD 4.11, and I can fsck a partition > which has just been remounted RO. > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > under FreeBSD6 and do the test again on FreeBSD 6 ? I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if any GEOM-related stuff ever made it into fsck, but certainly the background checking code and softupdates changes were introduced about that time. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 19:19:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCFC516A416 for ; Mon, 16 Oct 2006 19:19:37 +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 048D743D96 for ; Mon, 16 Oct 2006 19:19:18 +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 k9GJJ9OO041974; Mon, 16 Oct 2006 15:19:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Oct 2006 14:26:14 -0400 User-Agent: KMail/1.9.1 References: <20061013074136.GA31459@zen.inc> <20061016074904.GA30889@zen.inc> <20061016081558.GA31560@zen.inc> In-Reply-To: <20061016081558.GA31560@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610161426.14575.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]); Mon, 16 Oct 2006 15:19:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2037/Mon Oct 16 12:41:42 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: VANHULLEBUS Yvan Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 19:19:38 -0000 On Monday 16 October 2006 04:15, VANHULLEBUS Yvan wrote: > On Mon, Oct 16, 2006 at 09:49:04AM +0200, VANHULLEBUS Yvan wrote: > > On Fri, Oct 13, 2006 at 01:57:58PM -0500, Rick C. Petty wrote: > [fscking a RO partition] > > > Grr, I meant 4.x not 5.x, and I thought the problem started about the time > > > bg fsck was introduced... > > > > Right: I just tried on a FreeBSD 4.11, and I can fsck a partition > > which has just been remounted RO. > > > > > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > > under FreeBSD6 and do the test again on FreeBSD 6 ? No, as you've seen. :) > Is this a bug "somewhere" in the kernel ? Yes. GEOM is in the kernel. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 16 19:19:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F93F16A6DD; Mon, 16 Oct 2006 19:19:40 +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 48E9243D5E; Mon, 16 Oct 2006 19:19:22 +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 k9GJJ9OP041974; Mon, 16 Oct 2006 15:19:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Oct 2006 14:31:24 -0400 User-Agent: KMail/1.9.1 References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> <20061016011559.W61639@delplex.bde.org> In-Reply-To: <20061016011559.W61639@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610161431.25228.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]); Mon, 16 Oct 2006 15:19:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2037/Mon Oct 16 12:41:42 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-bugs@freebsd.org, Cheng-Lung Sung , FreeBSD-gnats-submit@freebsd.org, Bruce Evans , freebsd-current@freebsd.org Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 19:19:43 -0000 On Sunday 15 October 2006 11:21, Bruce Evans wrote: > On Sun, 15 Oct 2006, Cheng-Lung Sung wrote: > > > System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Thu May 11 14:31:45 CST 2006 root@FreeBSD.csie.nctu.edu.tw:/home/usr.obj/usr/src/sys/FREEBSD i386 > > > >> Description: > > - sys/sem.h has included sys/ipc.h, which includes sys/_types.h > > but it (and its including files) does not include sys/types.h > > - therefore, in sys/sem.h struct semid_ds declares "time_t sem_otime;" ...etc > > - if we only compile a program which do not include sys/types.h, it will fail. > > Including sys/types.h would add lots of namespace pollution which > sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too > hard -- POSIX requires it to declare time_t (and pid_t, key_t and size_t, > which it already declares). Is this better? Index: sem.h =================================================================== RCS file: /usr/cvs/src/sys/sys/sem.h,v retrieving revision 1.29 diff -c -r1.29 sem.h *** sem.h 17 Nov 2004 13:12:06 -0000 1.29 --- sem.h 16 Oct 2006 18:30:05 -0000 *************** *** 111,116 **** --- 111,121 ---- #define _SIZE_T_DECLARED #endif + #ifndef _TIME_T_DECLARED + typedef __time_t time_t; + #define _TIME_T_DECLARED + #endif + #ifndef _PID_T_DECLARED typedef __pid_t pid_t; #define _PID_T_DECLARED (it looks like pid_t should be before size_t in sem.h btw) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 02:13:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 813E916A403; Tue, 17 Oct 2006 02:13:34 +0000 (UTC) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from FreeBSD.csie.nctu.edu.tw (freebsd.csie.nctu.edu.tw [140.113.17.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1DE843D53; Tue, 17 Oct 2006 02:13:33 +0000 (GMT) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from localhost (localhost.csie.nctu.edu.tw [127.0.0.1]) by FreeBSD.csie.nctu.edu.tw (Postfix) with ESMTP id A50077E93C; Tue, 17 Oct 2006 10:14:08 +0800 (CST) Received: from FreeBSD.csie.nctu.edu.tw ([127.0.0.1]) by localhost (FreeBSD.csie.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In-c55vOFY8P; Tue, 17 Oct 2006 10:14:08 +0800 (CST) Received: by FreeBSD.csie.nctu.edu.tw (Postfix, from userid 1038) id 0A4DD7E93D; Tue, 17 Oct 2006 10:14:08 +0800 (CST) Date: Tue, 17 Oct 2006 10:14:07 +0800 From: Cheng-Lung Sung To: John Baldwin Message-ID: <20061017021407.GA738@FreeBSD.csie.nctu.edu.tw> References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> <20061016011559.W61639@delplex.bde.org> <200610161431.25228.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200610161431.25228.jhb@freebsd.org> X-Fingerprint: E0BC 57F9 F44B 46C6 DB53 8462 F807 89F3 956E 8BC1 X-Public-Key: http://sungsung.dragon2.net/pubring.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-bugs@freebsd.org, FreeBSD-gnats-submit@freebsd.org, Bruce Evans , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Cheng-Lung Sung Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 02:13:34 -0000 On Mon, Oct 16, 2006 at 02:31:24PM -0400, John Baldwin wrote: > On Sunday 15 October 2006 11:21, Bruce Evans wrote: > > On Sun, 15 Oct 2006, Cheng-Lung Sung wrote: > >=20 > > > System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Th= u May=20 > 11 14:31:45 CST 2006 =20 > root@FreeBSD.csie.nctu.edu.tw:/home/usr.obj/usr/src/sys/FREEBSD i386 > > > > > >> Description: > > > - sys/sem.h has included sys/ipc.h, which includes sys/_types.h > > > but it (and its including files) does not include sys/types.h > > > - therefore, in sys/sem.h struct semid_ds declares "time_t=20 > sem_otime;" ...etc > > > - if we only compile a program which do not include sys/types.h, it w= ill=20 > fail. > >=20 > > Including sys/types.h would add lots of namespace pollution which > > sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too > > hard -- POSIX requires it to declare time_t (and pid_t, key_t and size_= t, > > which it already declares). >=20 > Is this better? >=20 > Index: sem.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/cvs/src/sys/sys/sem.h,v > retrieving revision 1.29 > diff -c -r1.29 sem.h > *** sem.h 17 Nov 2004 13:12:06 -0000 1.29 > --- sem.h 16 Oct 2006 18:30:05 -0000 > *************** > *** 111,116 **** > --- 111,121 ---- > #define _SIZE_T_DECLARED > #endif > =20 > + #ifndef _TIME_T_DECLARED > + typedef __time_t time_t; > + #define _TIME_T_DECLARED > + #endif > +=20 > #ifndef _PID_T_DECLARED > typedef __pid_t pid_t; > #define _PID_T_DECLARED >=20 > (it looks like pid_t should be before size_t in sem.h btw) >=20 > --=20 > John Baldwin Thanks, I didn't go through the whole sem.h. Also, it seems we should put these parts before 'sturct semid_ds'.=20 or say, after we include sys/ipc.h (which include sys/_types.h) --=20 Cheng-Lung Sung - clsung@ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 01:39:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE4F716A403; Tue, 17 Oct 2006 01:39:13 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EDF643D53; Tue, 17 Oct 2006 01:39:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 342D4509051; Tue, 17 Oct 2006 11:39:11 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 20B752742C; Tue, 17 Oct 2006 11:39:10 +1000 (EST) Date: Tue, 17 Oct 2006 11:39:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200610161431.25228.jhb@freebsd.org> Message-ID: <20061017113234.V67620@delplex.bde.org> References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> <20061016011559.W61639@delplex.bde.org> <200610161431.25228.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 17 Oct 2006 02:20:25 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, Cheng-Lung Sung , FreeBSD-gnats-submit@freebsd.org, freebsd-current@freebsd.org Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 01:39:13 -0000 [This is still being sent to too many mailing lists since I don't know which ones it should go to except gnats.] On Mon, 16 Oct 2006, John Baldwin wrote: >> Including sys/types.h would add lots of namespace pollution which >> sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too >> hard -- POSIX requires it to declare time_t (and pid_t, key_t and size_t, >> which it already declares). > > Is this better? > > Index: sem.h > =================================================================== > RCS file: /usr/cvs/src/sys/sys/sem.h,v > retrieving revision 1.29 > diff -c -r1.29 sem.h > *** sem.h 17 Nov 2004 13:12:06 -0000 1.29 > --- sem.h 16 Oct 2006 18:30:05 -0000 > *************** > *** 111,116 **** > --- 111,121 ---- > #define _SIZE_T_DECLARED > #endif > > + #ifndef _TIME_T_DECLARED > + typedef __time_t time_t; > + #define _TIME_T_DECLARED > + #endif > + > #ifndef _PID_T_DECLARED > typedef __pid_t pid_t; > #define _PID_T_DECLARED > > (it looks like pid_t should be before size_t in sem.h btw) Good. (I didn't check if there are any other missing typedefs.) Please commit. The old typedefs also have non-KNF whitespace. sys/ipc.h is better. Bruce From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 02:41:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A128A16A416; Tue, 17 Oct 2006 02:41:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B95543D7E; Tue, 17 Oct 2006 02:41:07 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 9597D24D390; Tue, 17 Oct 2006 12:41:06 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 60CF827403; Tue, 17 Oct 2006 12:41:05 +1000 (EST) Date: Tue, 17 Oct 2006 12:41:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Cheng-Lung Sung In-Reply-To: <20061017021407.GA738@FreeBSD.csie.nctu.edu.tw> Message-ID: <20061017123629.X67815@delplex.bde.org> References: <20061015135710.A28897E98D@FreeBSD.csie.nctu.edu.tw> <20061016011559.W61639@delplex.bde.org> <200610161431.25228.jhb@freebsd.org> <20061017021407.GA738@FreeBSD.csie.nctu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 17 Oct 2006 02:58:36 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, freebsd-current@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 02:41:10 -0000 On Tue, 17 Oct 2006, Cheng-Lung Sung wrote: > On Mon, Oct 16, 2006 at 02:31:24PM -0400, John Baldwin wrote: >> Is this better? >> ... > Thanks, I didn't go through the whole sem.h. > Also, it seems we should put these parts before 'sturct semid_ds'. > or say, after we include sys/ipc.h (which include sys/_types.h) Yes, that is especially needed for time_t, since it is the only one of the typedef'ed types used early in sys/sem.h. The others might be needed later when the non-typedefed types are cleaned up. (sys/ipc.h needs cleaning up more. It still spells uid_t as "unsigned short", but uids aren't that short...) Bruce From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 08:06:48 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A77A16A4A0 for ; Tue, 17 Oct 2006 08:06:48 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ABB343D69 for ; Tue, 17 Oct 2006 08:06:43 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (xoxqvc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k9H86b8t060546; Tue, 17 Oct 2006 10:06:42 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k9H86adn060545; Tue, 17 Oct 2006 10:06:36 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Oct 2006 10:06:36 +0200 (CEST) Message-Id: <200610170806.k9H86adn060545@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, rick-freebsd@kiwi-computer.com In-Reply-To: <20061016191626.GD77730@keira.kiwi-computer.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Oct 2006 10:06:42 +0200 (CEST) Cc: Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 08:06:48 -0000 Rick C. Petty wrote: > VANHULLEBUS Yvan wrote: > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > > under FreeBSD6 and do the test again on FreeBSD 6 ? > > I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if > any GEOM-related stuff ever made it into fsck, but certainly the background > checking code and softupdates changes were introduced about that time. Does 4.x fsck even support UFS2? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 08:11:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7379F16A403; Tue, 17 Oct 2006 08:11:01 +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 15ABC43D7E; Tue, 17 Oct 2006 08:10:59 +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 k9H8AuaY073322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 10:10:56 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id k9H8AuLG073321; Tue, 17 Oct 2006 10:10:56 +0200 (CEST) Date: Tue, 17 Oct 2006 10:10:56 +0200 From: Divacky Roman To: Marco van de Voort Message-ID: <20061017081056.GA73188@stud.fit.vutbr.cz> References: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <20061016120859.E146C2287D@snail.stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016120859.E146C2287D@snail.stack.nl> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-hackers@freebsd.org, Ekkehard Morgenstern , David Xu Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 08:11:01 -0000 On Mon, Oct 16, 2006 at 02:08:59PM +0200, Marco van de Voort wrote: > > > > On Sunday 15 October 2006 01:32, David Xu wrote: > > > You are going to be unable to use libc if you create raw thread in your > > > program, libc uses pthread APIs, if you create a raw thread, your > > > program will crash if you use any libc function which needs pthread > > > interface. > > > > I don't want to link to libc. So, how do I create a raw thread? > > (digging deep into memory) > > Have a look how the linuxator emulates the clone() syscall with (IIRC) > rfork. A limited route, but iirc it works. linuxolator clone() uses fork1() which is unaccessible from outside kernel. there is a "user space implementation" of clone() in linuxthreads which uses rfork() but rfork creates "normal processes". but you can pass flags to rfork() thus emulation most of the needs of threads (shared memory etc.) roman From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 09:17:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 90E3116A403; Tue, 17 Oct 2006 09:17:34 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Divacky Roman Date: Tue, 17 Oct 2006 17:17:30 +0800 User-Agent: KMail/1.8.2 References: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <20061016120859.E146C2287D@snail.stack.nl> <20061017081056.GA73188@stud.fit.vutbr.cz> In-Reply-To: <20061017081056.GA73188@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610171717.30834.davidxu@freebsd.org> Cc: freebsd-hackers@freebsd.org, Ekkehard Morgenstern Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 09:17:35 -0000 On Tuesday 17 October 2006 16:10, Divacky Roman wrote: > On Mon, Oct 16, 2006 at 02:08:59PM +0200, Marco van de Voort wrote: > > > On Sunday 15 October 2006 01:32, David Xu wrote: > > > > You are going to be unable to use libc if you create raw thread in > > > > your program, libc uses pthread APIs, if you create a raw thread, > > > > your program will crash if you use any libc function which needs > > > > pthread interface. > > > > > > I don't want to link to libc. So, how do I create a raw thread? > > > > (digging deep into memory) > > > > Have a look how the linuxator emulates the clone() syscall with (IIRC) > > rfork. A limited route, but iirc it works. > > linuxolator clone() uses fork1() which is unaccessible from outside kernel. > there is a "user space implementation" of clone() in linuxthreads which > uses rfork() but rfork creates "normal processes". but you can pass flags > to rfork() thus emulation most of the needs of threads (shared memory etc.) > > roman You can use rfork() to create kernel threads, but you won't have POSIX signal and job control support in kernel, this is also one of important threading work in the past. Also rfork() does not allow you to specify user stack, you have to add some tricky code to make it safe before new thread really can do real work, plus if you want TLS to work, you have to do more work, this is why we invent THR syscalls to do all the initializing work in a single syscall, there are other problems of rfork I can not think of at the moment. David Xu From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 13:48:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 412EE16A412 for ; Tue, 17 Oct 2006 13:48:42 +0000 (UTC) (envelope-from rosmir@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 2106043D86 for ; Tue, 17 Oct 2006 13:48:38 +0000 (GMT) (envelope-from rosmir@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so916479uge for ; Tue, 17 Oct 2006 06:48:38 -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=LFBHo0FFIkAMHoy9L8tnVM+WNIo49s6uxvPumUzqgSnMU85nJGN/A2buBhJ8uF/NIauOu7U1JSR3qlHqSGzLZCG0IBFZQaHuNOxF/A2lhyd7EPJv0sD/li/07es9RYcTGxOv84GNm85sjnjFS8nnDpOEEQKdGbwg5S0J/dQgBfA= Received: by 10.78.188.19 with SMTP id l19mr9330654huf; Tue, 17 Oct 2006 06:48:37 -0700 (PDT) Received: by 10.78.116.5 with HTTP; Tue, 17 Oct 2006 06:48:37 -0700 (PDT) Message-ID: <9c6e52b10610170648x20222494ncfebdac21e1f0f99@mail.gmail.com> Date: Tue, 17 Oct 2006 17:48:37 +0400 From: "Stepan A. Baranov" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: delete 2 macros from queue.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 13:48:42 -0000 Hello, I made the Russian translation of queue(3) and found out that in sys/sys/queue.h there are macros SLIST_FOREACH_PREVPTR and STAILQ_REMOVE_HEAD_UNTIL which are not described in queue(3). The macros SLIST_FOREACH_PREVPTR is used only in sys/kern/sysv_sem.c and the macros STAILQ_REMOVE_HEAD_UNTIL is used only in sys/dev/ubsec/ubsec.c . Thus, I think that these macros must be described in queue(3) or be deleted. I made the patch for removing such macros from sys/sys/queue.h . The patch can be fetched from http://www.rosmir.org/freebsd/patches/patch-queue . Please, test it and fix it. Stepan Baranov. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 17 17:39:20 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F02FE16A407 for ; Tue, 17 Oct 2006 17:39:20 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 8808543D5C for ; Tue, 17 Oct 2006 17:39:19 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 10739 invoked by uid 2001); 17 Oct 2006 17:39:18 -0000 Date: Tue, 17 Oct 2006 12:39:18 -0500 From: "Rick C. Petty" To: freebsd-hackers@FreeBSD.ORG Message-ID: <20061017173918.GA10662@keira.kiwi-computer.com> References: <20061016191626.GD77730@keira.kiwi-computer.com> <200610170806.k9H86adn060545@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610170806.k9H86adn060545@lurza.secnetix.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Fscking a partition mounted Read only... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 17:39:21 -0000 On Tue, Oct 17, 2006 at 10:06:36AM +0200, Oliver Fromme wrote: > Rick C. Petty wrote: > > I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if > > any GEOM-related stuff ever made it into fsck, but certainly the background > > checking code and softupdates changes were introduced about that time. > > Does 4.x fsck even support UFS2? No it does not, so that would be a problem as well =) -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 01:16:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1743116A417; Wed, 18 Oct 2006 01:16:00 +0000 (UTC) (envelope-from Johannes.Kruger@nokia.com) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53CFC43D5F; Wed, 18 Oct 2006 01:15:58 +0000 (GMT) (envelope-from Johannes.Kruger@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9I1FveB015788; Wed, 18 Oct 2006 04:15:57 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 04:15:57 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 20:15:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Oct 2006 20:15:52 -0500 Message-ID: In-Reply-To: <7579f7fb0610121617n2b6b4cdap67eeb0c9b5a58da8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LSI1064 and LSI1064E and mpt Thread-Index: AcbuVKMS2IOE1JenRCCfFI+Hd0lTVAD/OWww From: To: X-OriginalArrivalTime: 18 Oct 2006 01:15:53.0244 (UTC) FILETIME=[F4A6A5C0:01C6F252] X-Mailman-Approved-At: Wed, 18 Oct 2006 01:21:49 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org Subject: RE: LSI1064 and LSI1064E and mpt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 01:16:00 -0000 Hi Matthew. I gave up on the PCI-express version of the card for the time being. The PCI-X running the same firmware works fine, except for the slow RAID of course. I still have the main problem I try to get to the bottom off, and that is that the RAID-1 volume da0 is very slow. - Slow with even just 1 disk. - Slow when sync completed or not. Without RAID configured , and having 2 disks mounted, the disks are fast ~ 30 Mbytes/sec The disks are Fujitsu SATA laptop drives. I was poking around the MPI libraries of Linux, and I see they have some extra entries related to SAS. Also the file mptsas.c in Linux sets up the link speed and so on on the PHY. Do not know if something there is needed yet. Any idea of where I can start looking for the problem ? - link speed - dma - caching - etc ..etc ..=20 P.S. A way earlier version of the MPI , somewhere in 2005, behaves the same as far as the RAID speed is concerned. Johan -----Original Message----- From: ext Matthew Jacob [mailto:lydianconcepts@gmail.com]=20 Sent: Thursday, October 12, 2006 7:17 PM To: Kruger Johannes (Nokia-ES/Boston) Cc: freebsd-scsi@freebsd.org; freebsd-hackers@freebsd.org Subject: Re: LSI1064 and LSI1064E and mpt And the problem is....? On 10/12/06, Johannes.Kruger@nokia.com wrote: > Hi. > I figured I'll give this mailing list a shot in helping me figure out a > problem I have. > > I have 2 reference boards from LSI, using the mpt driver. > Each one has MPI FW revision 1.5.13.0 > They repond differently. > The PCI-X version LSI1064 reports running in RAID-1 and do NOT get the > error message. > The PCI-express do get the error message, and thus reports RAID-0 > Both are configured as RAID-1 Integrated mirroring. Using the same 2 > disks on both, swapping them out back and forth between the testing. > > NOTE: the behavior is the same with FW version 1.5.12.0 except with > 1.5.12.0 I get notify events on which I can report sync percentage. > > ---------------- ERROR MESSAGE ----------------------- > . > . > mpt_read_cfg_page: Config Info Status 22 > mpt_refresh_raid_vol: Failed to read RAID Vol Page(0) > mpt0:vol0(mpt0:0:0): Settings (netlog:mpt .. ) > mpt0:vol0(mpt0:0:0): 0 Members: > mpt0:vol0(mpt0:0:0): RAID-0 - Optimal > . > . > ------------------------------------------------------ > > > Johan > > > . > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 01:26:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EF1716A519; Wed, 18 Oct 2006 01:26:37 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mail.digitalfreaks.org (arbitor.digitalfreaks.org [216.151.95.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 116A943E04; Wed, 18 Oct 2006 01:26:00 +0000 (GMT) (envelope-from lavalamp@spiritual-machines.org) Received: by mail.digitalfreaks.org (Postfix, from userid 1022) id 5BA4D17EDD; Tue, 17 Oct 2006 21:25:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.digitalfreaks.org (Postfix) with ESMTP id 539F617ED2; Tue, 17 Oct 2006 21:25:52 -0400 (EDT) Date: Tue, 17 Oct 2006 21:25:52 -0400 (EDT) From: "Brian A. Seklecki" X-X-Sender: lavalamp@arbitor.digitalfreaks.org To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86sljvli0m.fsf@xps.des.no> Message-ID: <20061017205906.U63561@arbitor.digitalfreaks.org> References: <44E040CF.9080205@alphaque.com> <44E05598.20004@alphaque.com> <20060816123731.GE45370@cdnetworks.co.kr> <44E4073C.9010008@alphaque.com> <86sljvli0m.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2019366847-1161133148=:63561" Content-ID: <20061017210143.J63561@arbitor.digitalfreaks.org> X-Mailman-Approved-At: Wed, 18 Oct 2006 01:49:31 +0000 Cc: pyunyh@gmail.com, freebsd-hackers@freebsd.org, yamt@netbsd.org, wpaul@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 01:26:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2019366847-1161133148=:63561 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <20061017205919.G63561@arbitor.digitalfreaks.org> Dinesh et al: Did this problem ever get resolved? I'm tracking down a very similar bug with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. Dinish: What platform are you using? You said you had a 4x re(4) SBC, but never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network appliance. URL below. My platform is netbsd-3, but I just tried -current to see if recent rtl8169.c changes fix it. No dice. No dice with NetBSD -current either. FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 probes then fails the diagnostic function, then detatches. re1, re2, re3 all then sucsessfully probe on my system, but then they show no media status and tcpdump(8)/arp(8) show no activity. They're dead in the water. There has also been some mention of the errors below on NetBSD and OpenBSD probably because of the bitrot/driver drift: http://marc.theaimsgroup.com/?t=111658040100001&r=1&w=2 http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a go. I see a 8139C+ fix was commited 5 weeks ago by yongar@. Based on some other threads I've been reading on "8139C+ Watchdog Timeouts" and "Diag failed, failing to attach" related messages, I imagine FreeBSD has this covered. re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX re0: interrupting at irq 5 re0: Ethernet address 00:60:e0:e1:3e:31 re0: using 64 tx descriptors ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x000000, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re: diagnostic failed, failed to receive packet in loopback mode re0: attach aborted due to hardware diag failure ukphy0 detached ----- Full dmesg(8): NetBSD 3.1_RC3 (CFRDMDROOT.MPACPI-$Revision: 1.21.4.5 $) #9: Sat Oct 14 21:19:14 EDT 2006 root@thunderwing:/home/nbsd/obj.i386/temp/sys/arch/i386/compile/CFRDMDROOT.MPACPI total memory = 189 MB avail memory = 166 MB BIOS32 rev. 0 found at 0xfb570 mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: VIA C3 Samuel 2/Ezra (686-class), 800.11 MHz, id 0x673 cpu0: features 80803035 cpu0: features 80803035 cpu0: features 80803035<3DNOW> cpu0: "VIA Samuel 2" cpu0: I-cache 64 KB 32B/line 4-way, D-cache 64 KB 32B/line 4-way cpu0: L2 cache 64 KB 32B/line 4-way cpu0: ITLB 128 4 KB entries 8-way cpu0: DTLB 128 4 KB entries 8-way cpu0: 4 page colors acpi0 at mainbus0 acpi0: using Intel ACPI CA subsystem version 20040211 acpi0: X/RSDT: OemId , AslId acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present ACPI Object Type 'Processor' (0x0c) at acpi0 not configured acpibut0 at acpi0 (PNP0C0C): ACPI Power Button PNP0C01 [System Board] at acpi0 not configured PNP0A03 [PCI Bus] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured PNP0000 [AT Interrupt Controller] at acpi0 not configured PNP0200 [AT DMA Controller] at acpi0 not configured PNP0100 [AT Timer] at acpi0 not configured PNP0B00 [AT Real-Time Clock] at acpi0 not configured PNP0800 [AT-style speaker sound] at acpi0 not configured npx1 at acpi0 (PNP0C04) npx1: io 0xf0-0xff irq 13 npx1: using exception 16 fdc0 at acpi0 (PNP0700) fdc0: io 0x3f0-0x3f5,0x3f7 irq 6 drq 2 com0 at acpi0 (PNP0501-1) com0: io 0x3f8-0x3ff irq 4 com0: ns16550a, working fifo com1 at acpi0 (PNP0501-2) com1: io 0x2f8-0x2ff irq 3 com1: ns16550a, working fifo lpt0 at acpi0 (PNP0400-1) lpt0: io 0x378-0x37f irq 7 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: VIA Technologies product 0x0601 (rev. 0x05) agp0 at pchb0: aperture at 0xe8000000, size 0x10000000 ppb0 at pci0 dev 1 function 0: VIA Technologies product 0x8601 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 0 function 0: Trident Microsystems product 0x8500 (rev. 0x6a) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) wsmux1: connecting to wsdisplay0 pcib0 at pci0 dev 7 function 0 pcib0: VIA Technologies VT82C686A PCI-ISA Bridge (rev. 0x40) viaide0 at pci0 dev 7 function 1 viaide0: VIA Technologies VT82C686A (Apollo KX133) ATA100 controller viaide0: bus-master DMA support present viaide0: primary channel configured to compatibility mode viaide0: primary channel interrupting at irq 14 atabus0 at viaide0 channel 0 viaide0: secondary channel configured to compatibility mode viaide0: secondary channel interrupting at irq 15 atabus1 at viaide0 channel 1 uhci0 at pci0 dev 7 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x1a) uhci0: interrupting at irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 7 function 3: VIA Technologies VT83C572 USB Controller (rev. 0x1a) uhci1: interrupting at irq 10 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered VIA Technologies VT82C686A SMBus Controller (miscellaneous bridge, revision 0x40) at pci0 dev 7 function 4 not configured re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX re0: interrupting at irq 5 re0: Ethernet address 00:60:e0:e1:3e:31 re0: using 64 tx descriptors ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x000000, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re: diagnostic failed, failed to receive packet in loopback mode re0: attach aborted due to hardware diag failure ukphy0 detached re1 at pci0 dev 17 function 0: RealTek 8139C+ 10/100BaseTX re1: interrupting at irq 12 re1: Ethernet address 00:60:e0:e1:3e:30 re1: using 64 tx descriptors ukphy0 at re1 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x000000, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2 at pci0 dev 18 function 0: RealTek 8139C+ 10/100BaseTX re2: interrupting at irq 10 re2: Ethernet address 00:60:e0:e1:3e:2f re2: using 64 tx descriptors ukphy1 at re2 phy 0: Generic IEEE 802.3u media interface ukphy1: OUI 0x000000, model 0x0000, rev. 0 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re3 at pci0 dev 19 function 0: RealTek 8139C+ 10/100BaseTX re3: interrupting at irq 11 re3: Ethernet address 00:60:e0:e1:3e:2e re3: using 64 tx descriptors ukphy2 at re3 phy 0: Generic IEEE 802.3u media interface ukphy2: OUI 0x000000, model 0x0000, rev. 0 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isa0 at pcib0 pcppi0 at isa0 port 0x61 sysbeep0 at pcppi0 isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support isapnp0: no ISA Plug 'n Play devices found md0: internal 10500 KB image area IPsec: Initialized Security Association Processing. uhidev0 at uhub0 port 1 configuration 1 interface 0 uhidev0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 2, iclass 3/1 ukbd0 at uhidev0 wskbd0 at ukbd0 mux 1 wskbd0: connecting to wsdisplay0 wd0 at atabus0 drive 0: wd0: drive supports 4-sector PIO transfers, LBA addressing wd0: 1953 MB, 3970 cyl, 16 head, 63 sec, 512 bytes/sect x 4001760 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2 wd0(viaide0:0:0): using PIO mode 4, DMA mode 2 (using DMA) atapibus0 at atabus1: 2 targets cd0 at atapibus0 drive 1: cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33) cd0(viaide0:1:1): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA) boot device: wd0 root on md0a dumps on md0b root file system type: ffs wsdisplay0: screen 1 added (80x25, vt100 emulation) wsdisplay0: screen 2 added (80x25, vt100 emulation) wsdisplay0: screen 3 added (80x25, vt100 emulation) wsdisplay0: screen 4 added (80x25, vt100 emulation) On Thu, 17 Aug 2006, Dag-Erling Smørgrav wrote: > Dinesh Nair writes: >> i never got re(4) working, and the patch i'm currently using forces >> the use of rl(4) instead of using re(4). using rl(4) still shows >> media as none, but it works the way it should with packets going in >> and out. i've yet to try dag-erling's suggestion of disabling rx and >> tx checksums. i'll also try with the patch you sent it to see if >> that works. > > If you can receive but not transmit (as I understood from other posts > in the thread, though you never answered my question about tcpdump), > disabling tx checksum offloading should be the *first* thing to try, > especially as there is a known bug in some RealTek chipsets which will > cause tx checksums to be computed incorrectly for short packets (such > as ICMP echo replies, or TCP handshake frames). > > DES > -- > Dag-Erling Smørgrav - des@des.no > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." --0-2019366847-1161133148=:63561-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 01:57:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DE4916A407 for ; Wed, 18 Oct 2006 01:57:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF4243D91 for ; Wed, 18 Oct 2006 01:56:41 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so137615pye for ; Tue, 17 Oct 2006 18:56:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=N1d9S8ARzp7BaKQj+EtM7zvKNGEVlHUkmMZjopdNfqTm5FFQZWyrkR83RSWiZo5Uzjg71WqzU4zq/Fjr7oWeH1oCOs2tyswKBM7rZp2Cas2FnVEb1Imvcujsz8ENi73wLjwOlkuT6qMOQp1W2gNBD5r03lQYq0ASRkXzDU0/k9Q= Received: by 10.35.8.13 with SMTP id l13mr16592214pyi; Tue, 17 Oct 2006 18:56:07 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 16sm279706nzo.2006.10.17.18.56.05; Tue, 17 Oct 2006 18:56:07 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k9I1tIFQ002289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 10:55:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k9I1tDZK002288; Wed, 18 Oct 2006 10:55:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Oct 2006 10:55:11 +0900 From: Pyun YongHyeon To: "Brian A. Seklecki" Message-ID: <20061018015511.GC1756@cdnetworks.co.kr> References: <44E040CF.9080205@alphaque.com> <44E05598.20004@alphaque.com> <20060816123731.GE45370@cdnetworks.co.kr> <44E4073C.9010008@alphaque.com> <86sljvli0m.fsf@xps.des.no> <20061017205906.U63561@arbitor.digitalfreaks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061017205906.U63561@arbitor.digitalfreaks.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, yamt@netbsd.org, wpaul@freebsd.org, freebsd-hardware@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 01:57:10 -0000 On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: > > Dinesh et al: > > Did this problem ever get resolved? I'm tracking down a very similar bug > with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. > > Dinish: What platform are you using? You said you had a 4x re(4) SBC, but > never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network > appliance. URL below. My platform is netbsd-3, but I just tried -current > to see if recent rtl8169.c changes fix it. No dice. > > No dice with NetBSD -current either. > > FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 > probes then fails the diagnostic function, then detatches. re1, re2, > re3 all then sucsessfully probe on my system, but then they show no > media status and tcpdump(8)/arp(8) show no activity. They're dead in > the water. > > There has also been some mention of the errors below on NetBSD and OpenBSD > probably because of the bitrot/driver drift: > > http://marc.theaimsgroup.com/?t=111658040100001&r=1&w=2 > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 > > I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a > go. I see a 8139C+ fix was commited 5 weeks ago by yongar@. Based on > some other threads I've been reading on "8139C+ Watchdog Timeouts" and > "Diag failed, failing to attach" related messages, I imagine FreeBSD has > this covered. > > re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX > re0: interrupting at irq 5 > re0: Ethernet address 00:60:e0:e1:3e:31 > re0: using 64 tx descriptors > ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface > ukphy0: OUI 0x000000, model 0x0000, rev. 0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re: diagnostic failed, failed to receive packet in loopback mode > re0: attach aborted due to hardware diag failure > ukphy0 detached > Long ago re_diag() code was disabled by default(rev 1.68). So I think you should never see the "diagnostic failed" message on FreeBSD. The other odd thing I see from your demsg output is ukphy(4) attachment. If you boot system with bootverbose mode ukphy(4) would have printed PHY OID and model number. Please let me know the OID/model number. I guess it should use rlphy(4). (If you should use NetBSD you may need to define MIIVERBOSE to active verbose message.) -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 02:54:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190A916A417 for ; Wed, 18 Oct 2006 02:54:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7E2443D53 for ; Wed, 18 Oct 2006 02:53:59 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so157605pye for ; Tue, 17 Oct 2006 19:53:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WyV1to7EA8Z/hoD6Zudl2sAkkwPi4544BmwF94Uc342RhWbgQ5latYIBZQOApiK9FNKz4PaqqwlqX7zNCZeuMlZGnx5qUk0SODGAGZ6rEsJ/EaKT+UIZRq9knPtUBHwtbDm/bFDQZNmcwgCHJenRmzMXkDjXMVE9r6Nfiz7M6Zk= Received: by 10.35.48.15 with SMTP id a15mr16658494pyk; Tue, 17 Oct 2006 19:53:58 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 10sm545172nzo.2006.10.17.19.53.54; Tue, 17 Oct 2006 19:53:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k9I2r7K2002481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 11:53:07 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k9I2r6LE002480; Wed, 18 Oct 2006 11:53:06 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Oct 2006 11:53:06 +0900 From: Pyun YongHyeon To: "Brian A. Seklecki" Message-ID: <20061018025306.GE1756@cdnetworks.co.kr> References: <44E040CF.9080205@alphaque.com> <44E05598.20004@alphaque.com> <20060816123731.GE45370@cdnetworks.co.kr> <44E4073C.9010008@alphaque.com> <86sljvli0m.fsf@xps.des.no> <20061017205906.U63561@arbitor.digitalfreaks.org> <20061018015511.GC1756@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061018015511.GC1756@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, yamt@netbsd.org, wpaul@freebsd.org, freebsd-hardware@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 02:54:04 -0000 On Wed, Oct 18, 2006 at 10:55:11AM +0900, To Brian A. Seklecki wrote: > On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: > > > > Dinesh et al: > > > > Did this problem ever get resolved? I'm tracking down a very similar bug > > with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. > > > > Dinish: What platform are you using? You said you had a 4x re(4) SBC, but > > never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network > > appliance. URL below. My platform is netbsd-3, but I just tried -current > > to see if recent rtl8169.c changes fix it. No dice. > > > > No dice with NetBSD -current either. > > > > FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 > > probes then fails the diagnostic function, then detatches. re1, re2, > > re3 all then sucsessfully probe on my system, but then they show no > > media status and tcpdump(8)/arp(8) show no activity. They're dead in > > the water. > > > > There has also been some mention of the errors below on NetBSD and OpenBSD > > probably because of the bitrot/driver drift: > > > > http://marc.theaimsgroup.com/?t=111658040100001&r=1&w=2 > > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 > > > > I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a > > go. I see a 8139C+ fix was commited 5 weeks ago by yongar@. Based on > > some other threads I've been reading on "8139C+ Watchdog Timeouts" and > > "Diag failed, failing to attach" related messages, I imagine FreeBSD has > > this covered. > > > > re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX > > re0: interrupting at irq 5 > > re0: Ethernet address 00:60:e0:e1:3e:31 > > re0: using 64 tx descriptors > > ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface > > ukphy0: OUI 0x000000, model 0x0000, rev. 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oops, I've missed OID/model number showed on your message. Sorry. Since ukphy(4) showed bogus model number I have no idea what PHY hardware the NIC has. Would you show me "pciconf -lv" output? > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re: diagnostic failed, failed to receive packet in loopback mode > > re0: attach aborted due to hardware diag failure > > ukphy0 detached > > > > Long ago re_diag() code was disabled by default(rev 1.68). So I think > you should never see the "diagnostic failed" message on FreeBSD. > The other odd thing I see from your demsg output is ukphy(4) > attachment. If you boot system with bootverbose mode ukphy(4) would > have printed PHY OID and model number. Please let me know the > OID/model number. I guess it should use rlphy(4). > (If you should use NetBSD you may need to define MIIVERBOSE to active > verbose message.) -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 15:40:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 808F016A407 for ; Wed, 18 Oct 2006 15:40:13 +0000 (UTC) (envelope-from lydianconcepts@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 8E5C143E9A for ; Wed, 18 Oct 2006 15:36:29 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so707610nfc for ; Wed, 18 Oct 2006 08:36:09 -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=HvvWfzGl6d6rGYTJEJJ+lehXQIsPyQ9+hw9XKhF12sJqWFuzDh37FCJkWw21QhJwBD23NInGn6hw8pIRpfijFBRKBZIQw+E9A8LStHFLl5/CCx7JzVWK4OhwGWBvTOqAu97/KKM9psmbN/g5oNSCpCtsT5Z2OdBun3ZbVMEVyXI= Received: by 10.82.106.14 with SMTP id e14mr2258837buc; Wed, 18 Oct 2006 08:35:53 -0700 (PDT) Received: by 10.78.197.4 with HTTP; Wed, 18 Oct 2006 08:35:53 -0700 (PDT) Message-ID: <7579f7fb0610180835wf89cbc8lef04d1a4f1a73cb1@mail.gmail.com> Date: Wed, 18 Oct 2006 08:35:53 -0700 From: "Matthew Jacob" To: "Johannes.Kruger@nokia.com" 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: <7579f7fb0610121617n2b6b4cdap67eeb0c9b5a58da8@mail.gmail.com> X-Mailman-Approved-At: Wed, 18 Oct 2006 16:50:13 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: LSI1064 and LSI1064E and mpt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 15:40:13 -0000 On 10/17/06, Johannes.Kruger@nokia.com wrote: > Hi Matthew. > I gave up on the PCI-express version of the card for the time being. My contact at LSI hasn't gotten back to me. > The PCI-X running the same firmware works fine, except for the slow RAID > of course. > > I still have the main problem I try to get to the bottom off, and that > is that the RAID-1 volume da0 is very slow. > - Slow with even just 1 disk. > - Slow when sync completed or not. > Without RAID configured , and having 2 disks mounted, the disks are fast > ~ 30 Mbytes/sec > The disks are Fujitsu SATA laptop drives. Integrated Mirroring has always been a problem. For parallel SCSI, you have to negotiate with the physical drives themselves. This *shouldn't* be an issue with SAS, but you never know. > > I was poking around the MPI libraries of Linux, and I see they have some > extra entries related to SAS. > Also the file mptsas.c in Linux sets up the link speed and so on on the > PHY. > Do not know if something there is needed yet. > > Any idea of where I can start looking for the problem ? > - link speed > - dma > - caching > - etc ..etc .. > Don't know yet. The RAID stuff for mpt was written solely for SPI. It's a miracle it works at all for SAS or FC. I have a sunfire4100 on loan which supports this and when I have a spare moment (hah) I'll look into it. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 18 22:35:17 2006 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E65116A407 for ; Wed, 18 Oct 2006 22:35:17 +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 2875A43D76 for ; Wed, 18 Oct 2006 22:35:15 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GaK0G-0003Jc-ME; Wed, 18 Oct 2006 23:35:12 +0100 Date: Wed, 18 Oct 2006 23:35:12 +0100 From: Ceri Davies To: hackers@FreeBSD.org Message-ID: <20061018223512.GA89117@submonkey.net> Mail-Followup-To: Ceri Davies , hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: Subject: Where was that iSCSI initiator? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 22:35:17 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Could anyone please let me know the status of the iSCSI initiator that was floated here some time ago? Is it in a commitable state and, if not, can I help with testing (we have some Netware targets)? Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFNqwgocfcwTS3JF8RAmcYAKCLoGuS7U8aOHGgnr7HCq5LnKcgBACgpfOa q+LD3H0Og+tgjwQF76uEvTw= =MGDQ -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 00:15:04 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 943BE16A403 for ; Thu, 19 Oct 2006 00:15:04 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBACD43D6D for ; Thu, 19 Oct 2006 00:15:03 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.124] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GaLYf1b2U-00008O; Thu, 19 Oct 2006 02:14:50 +0200 From: Max Laier Organization: FreeBSD To: Ceri Davies , hackers@freebsd.org Date: Thu, 19 Oct 2006 02:14:41 +0200 User-Agent: KMail/1.9.4 References: <20061018223512.GA89117@submonkey.net> In-Reply-To: <20061018223512.GA89117@submonkey.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5527741.995mRJ8Thf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610190214.47815.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: Where was that iSCSI initiator? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 00:15:04 -0000 --nextPart5527741.995mRJ8Thf Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 19 October 2006 00:35, Ceri Davies wrote: > Could anyone please let me know the status of the iSCSI initiator that > was floated here some time ago? Is it in a commitable state and, if > not, can I help with testing (we have some Netware targets)? ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-17.5.tar.bz2 is that the= =20 one you were thinking about? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5527741.995mRJ8Thf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFNsN3XyyEoT62BG0RAg79AJoCXuQ7lfOLiu4twt/n1QupVx43vgCfcwgr FR+B6oT5ZCUNrxI2MtyFYAo= =LbGk -----END PGP SIGNATURE----- --nextPart5527741.995mRJ8Thf-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 07:05:12 2006 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C97D116A415; Thu, 19 Oct 2006 07:05:11 +0000 (UTC) (envelope-from so14k@so14k.com) Received: from ender.liquidneon.com (ender.liquidneon.com [216.38.206.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0669043D58; Thu, 19 Oct 2006 07:05:09 +0000 (GMT) (envelope-from so14k@so14k.com) Received: from localhost (localhost [127.0.0.1]) by ender.liquidneon.com (Postfix) with ESMTP id 9A3462E0C0; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Received: from ender.liquidneon.com ([127.0.0.1]) by localhost (ender.liquidneon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39466-01; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Received: by ender.liquidneon.com (Postfix, from userid 1000) id 0BB002E0BE; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Date: Thu, 19 Oct 2006 01:05:08 -0600 From: Brad Davis To: hackers@FreeBSD.org Message-ID: <20061019070508.GE35452@ender.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at ender.liquidneon.com Cc: announce@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Project Status Report - Fourth Quarter of 2006 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 07:05:12 -0000 FreeBSD Status Report Introduction This report covers FreeBSD related projects between June and October 2006. This includes the conclusion of this year's Google Summer of Code with 13 successful students. Some of last year's and the current SoC participants have meanwhile joined the committer ranks, kept working on their projects, and improving FreeBSD in general. This year's EuroBSDCon in Milan, Italy has meanwhile published an exciting program. Many developers will be there to discuss these current and future projects at the Developer Summit prior the conference. Next year's conference calendar has a new entry - in addition to the now well established BSDCan in Ottawa - AsiaBSDCon will take place in Tokyo at the begining of March. As we are closing in on FreeBSD 6.2 release many bugs are being fixed and new features have been MFCed. On the other hand a lot of the projects below already are focusing on FreeBSD 7.0 and promise a lot of exciting news and features to come. Thanks to all the reporters for the excellent work! We hope you enjoy reading. _________________________________________________________________ Google Summer of Code * Analyze and Improve the Interrupt Handling Infrastructure * Bundled PXE Installer * Gvirstor * IPv6 Stack Vulnerabilities * Jail Resource Limits * Nss-LDAP importing and nsswitch subsystem improvement * Porting the seref policy and setools to SEBSD * Porting Xen to FreeBSD * SNMP monitoring (BSNMP) * Summer of Code Summary * Update of the Linux compatibility environment in the kernel Projects * CScout on the FreeBSD Source Code Base * DTrace * Embedded FreeBSD * FreeSBIE * GJournal * iSCSI Initiator * Porting ZFS to FreeBSD * Summer of FreeBSD security development * TrustedBSD Audit * USB FreeBSD Team Reports * FreeBSD Security Officer and Security Team * Ports Collection * Release Engineering * The FreeBSD Foundation Network Infrastructure * Bridge Spanning Tree Protocol Improvements * FAST_IPSEC Upgrade * Highly improved implementations of sendfile(2), sosend_*() and soreceive_stream() * SCTP Integration * TSO - TCP Segmentation Offload committed Kernel * Gvinum improvements * MMC/SD Support * Sound Subsystem Improvements Documentation * Chinese (Simplified) Project * Hungarian translation of the webpages Userland Programs * Libelf * OpenBSD dhclient Architectures * CPU Microcode Update Software * FreeBSD/arm on Atmel AT91RM9200 * Sun Niagara port * Xen Port Ports * Enlightenment DR17 support in the ports tree * FreshPorts * Improving FreeBSD Ports Collection Infrastructure * OCaml language support in ports Miscellaneous * AsiaBSDCon 2007 * BSDCan 2007 * EuroBSDCon 2006 * FreeBSD Multimedia Resources List _________________________________________________________________ Analyze and Improve the Interrupt Handling Infrastructure URL: http://wikitest.freebsd.org/Interrupts Contact: Paolo Pisati Contact: John Baldwin This project consisted in the improvement of the Interrupt Handling System in FreeBSD: while retaining backward compatibility with the previous models (FAST and ITHREAD), a new method called 'Interrupt filtering' was added. With interrupt filtering, the interrupt handler is divided into 2 parts: the filter (that checks if the actual interrupt belong to this device) and the ithread (that is scheduled in case some blocking work has to be done). The main benefits of interrupt filtering are: * Feedback from filters (the system finally knows if any handler has serviced an interrupt or not, and can react consequently). * Lower latency/overhead for shared interrupt line. * Previous experiments with interrupt filtering showed an increase in performance against the plain ithread model Moreover, during the development of interrupt filtering, some MD dependent code was converted into MI code, PPC was fixed to support multiple FAST handlers per line and an interrupt stray storm detection logic was added. While the framework is done, there are still machine dependent bits to be written (the support for ppc, sparc64, arm and itanium has to be written/reviewed) and a serious analysis of the performance of this model against the previous one is a work-in-progress _________________________________________________________________ AsiaBSDCon 2007 URL: http://www.asiabsdcon.org/ Contact: Hiroki Sato Contact: George Neville-Neil Contact: Web site is up and we're soliciting papers and presentations. Some tutorials are already scheduled. Email secretary@asibsdcon.org if you have questions or submissions. Open tasks: 1. Send in more papers! _________________________________________________________________ Bridge Spanning Tree Protocol Improvements Contact: Andrew Thompson Work is almost finished to implement the Rapid Spanning Tree Protocol (RSTP) which supersedes Spanning Tree Protocol (STP). RSTP has a much faster link failover time of around one second compared to 30-60 seconds for STP, this is very important on modern networks. The code will be posted shortly for testing and feedback. _________________________________________________________________ BSDCan 2007 URL: http://www.bsdcan.org/ Contact: Dan Langille The dates for BSDCan 2007 has been set: 11-12 May 2007. As is usual, BSDCan will be held at University of Ottawa, with two days of tutorials prior to the conference starting. The call for papers will go out in mid December. Start thinking about your submissions now! _________________________________________________________________ Bundled PXE Installer URL: http://wikitest.freebsd.org/MarkusBoelter Contact: Markus Boelter Contact: Paul Saab For me, the Google Summer of Code was a new and very exciting experience. I got actively involved in doing Open Source Software and giving something back to the community. Facing some challenges within the project forced me to look behind the scenery of FreeBSD. The result was a better understanding of the overall project. Working with a lot of developers directly also gave a very special spirit to the Google Summer of Code. I really enjoyed the time and will continue to work on the project after the deadline. For me, it was a great chance to get involved in active development and not just some scripts and hacks at home. Getting paid for the work was just a small part of the overall feeling. Thanks to the people at the FreeBSD Project and Google for the really, really great time! _________________________________________________________________ Chinese (Simplified) Project URL: http://cnsnap.cn.FreeBSD.org/zh_CN/ URL: http://cnsnap.cn.FreeBSD.org/doc/zh_CN.GB2312/ Contact: Xin LI In the previous quarter we primarily focused on overall quality of the translation rather than just increasing the number of translations, and we have strived to make sure that these translated stuff are up-to-date with their English revisions. Also, we have merged the translated website into the central repository. In the next quarter we will focus on developing documentation that will help to attract more developers. Open tasks: 1. Translate more development related documentation. 2. Review more of the currently translated documentation. _________________________________________________________________ CPU Microcode Update Software Contact: Stanislav Sedov Last month I was working on a driver/module to update the microcode of Intel or AMD CPUs that support having their microcode updated. As you might know these processors are microcode-driven and this firmware can be updated. Intel(R) often releases microcode updates, and AMD(R) updates can be found in BIOS programs. The work is almost finished now, I just need to find a bit of time to test it on AMD64 systems and perform some code cleanup. The driver also provide a way for userland programs to access the Machine Specific Registers (MSR) and CPUID info for a certain cpu. This will allow some programs like x86info to provide more accurate information about cpus in SMP systems and make assumptions based on the contents of the MSR. Thanks to John Baldwin, Kostik Belousov, John-Mark Gurney and Divacky Roman for helping during development. Open tasks: 1. Perform testing on the AMD64-based systems. 2. Write manpage. 3. Code cleanup/checks. _________________________________________________________________ CScout on the FreeBSD Source Code Base URL: http://wikitest.freebsd.org/CScout Contact: Diomidis Spinellis CScout is a refactoring editor and source code browser for collections of C code. The aim of the project is to make it easy for FreeBSD developers to use CScout and to improve the FreeBSD source code quality through CScout-based queries and refactorings. CScout was first applied to the FreeBSD kernel in 2003. Its application at that point involved substantial tinkering with the build system. The version released in October 2006 makes the running of CScout on the three Tier-1 architectures a fairly straightforward procedure. The current version can also draw a number of call graphs; this might help developers better understand foreign code. Open tasks: 1. Use CScout to locate problematic code areas (for example unused or too liberaly visible objects). 2. Use CScout to globaly rename identifiers in a more consistent fashion. 3. Apply CScout to the userland code. 4. Identify CScout extensions that would help us improve the quality of our code. 5. Arrange for the continous availability of a live CScout kernel session on the current version of the source code. _________________________________________________________________ DTrace Contact: John Birrell Progress this month has been limited due to my sea-change, moving house to the country. Sun's OpenSolaris developers have followed through and released the DTrace test suite as part of the OpenSolaris distribution. jkoshy@'s work on libbsdelf is nearing feature completion for DTrace and will make life easier in FreeBSD for DTrace, given that we have more architectures to support than Sun has. The FreeBSD project has made available a dual processor AMD64 machine for DTrace porting. I am currently working through the diffs between the DTrace project in P4 and -current, committing files to -current if they are ready, _________________________________________________________________ Embedded FreeBSD URL: http://www.embeddedfreebsd.org/ Contact: George Neville-Neil Moved the HTML pages into the project CVS tree. Open tasks: 1. Setup the web site to be served from projects CVS so that it can be updated by others. 2. Complete the ARM port. 3. Work on the MIPS port. 4. Update the documentation to include common tasks for embedded engineers. _________________________________________________________________ Enlightenment DR17 support in the ports tree Contact: Stanislav Sedov Integration of the new innovative e17 window manager into the ports tree is almost completed. A lot of new e17-related applications was ported, all old ports were updated to the latest stable cvs snapshot. The special framework (bsd.efl.mk) was created to support the whole thing and simplify the creation of dependent ports. I'll commit the changes in the days before the ports freeze. Thanks to Sergey Matveychuk (sem@) for providing a machine to place CVS snapshots on. Without his help it will be impossible. Open tasks: 1. Port Entrance (xdm-like app, but very appealing). 2. Port Net and Wlan e17 module. 3. Develop FreeBSD-specific e17 apps/modules to use The Ports Collection, system configs, etc. _________________________________________________________________ EuroBSDCon 2006 URL: http://www.eurobsdcon.org/ URL: http://www.eurobsdcon.org/register/ Contact: EuroBSDCon Organizing Committee EuroBSDCon 2006 is taking place in Milan (Italy), from the 10th to the 12th of November. EuroBSDCon represents the biggest gathering for BSD developers from the old continent, as well as users and passionates from around the World. It is also a chance to share experiences, know-how, and cultures. The program is rich in talks about FreeBSD, with topics ranging from "How the FreeBSD ports collection works" to "Interrupt Filtering in FreeBSD". This means that both the novice and the hacker can enjoy the conference. Registration is open. The EuroBSDCon Organizing Committee hopes to see you in Milan. _________________________________________________________________ FAST_IPSEC Upgrade URL: www.freebsd.org/~gnn/fast_ipv6.patch Contact: George Neville-Neil Contact: Bjoern Zeeb First working version of code. Does not pass all TAHI tests, but does pass packets correctly and does not panic. Open tasks: 1. More testing of the patch needed. _________________________________________________________________ FreeBSD Multimedia Resources List URL: http://www.mavetju.org/unix/multimedia.php URL: http://www.mavetju.org/unix/multimedia-rss.php Contact: Edwin Groothuis I have setup the FreeBSD Multimedia Resources List, a one-stop-shop for FreeBSD related podcasts, vodcasts and audio/video resources. Hopefully this list will make it easier for people to find and keep up to date with these recordings. The overview is available as a normal HTML page and as an XML/RSS feed. The ultimate goal is to have this list to reside under the www.FreeBSD.org umbrella. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In the time since the last status report, six security advisories have been issued concerning problems in the base system of FreeBSD; of these, five problems were in "contributed" code, while one was in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 57 new entries have been added, bringing the total up to 814. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.11, FreeBSD 5.3, FreeBSD 5.4, FreeBSD 5.5, FreeBSD 6.0, and FreeBSD 6.1. The respective End of Life dates of supported releases are listed on the web site; of particular note, FreeBSD 5.3 and FreeBSD 5.4 will cease to be supported at the end of October 2006, while FreeBSD 6.0 will cease to be supported at the end of November 2006 (or possibly a short time thereafter in order to allow time for upgrades to the upcoming FreeBSD 6.2). _________________________________________________________________ FreeBSD/arm on Atmel AT91RM9200 Contact: Warner Losh Contact: Olivier Houchard The FreeBSD/arm port has grown support for the Atmel AT91RM9200. Boards based on this machine are booting to multiuser off either NFS or an SD card. The onboard serial ports, PIO, ethernet and SD/MMC card controllers are well supported. Support for the SSC, IIC and SPI flash parts in the kernel will be forthcoming shortly. In addition to normal kernel support, the port includes a boot loader that can initialize memory and boot off IIC eeprom, SPI DataFlash, BOOTP/TFTP and SD memory cards. The port will be included in forth coming commercial products. Open tasks: 1. Add support for other members of the AT91 family of arm9 processors. 2. Finish support for AT45D* flash parts. 3. Finish support for USB ports 4. Write support for USB Device functionality _________________________________________________________________ FreeSBIE URL: http://www.FreeSBIE.org URL: http://liste.gufi.org/mailman/listinfo/freesbie URL: http://people.freebsd.org/~matteo/GMV/GMVAnnounce.txt Contact: FreeSBIE Staff Contact: Matteo Riondato FreeSBIE is a FreeBSD based LiveCD. On August 19th, Matteo Riondato, a member of the FreeSBIE staff, released an unofficial ISO, codename FreeSBIE GMV, based on FreeBSD -CURRENT (read the Announcement to download it). This is supposed to be the first in a series of four ISOs that will end up with the release of FreeSBIE 2.0. Matteo is now working on another ISO, codename FreeSBIE LVC, which is scheduled to be released October 12th. FreeSBIE 2.0 will be based on FreeBSD 6.2-RELEASE and will hopefully be released at EuroBSDCon 2006 in Milan. It will be available for the i386 and AMD64 platforms. Open tasks: 1. Test the released ISO in preparation for the release. 2. Suggest software to include in the ISO. 3. Submit a simple and clear but complete fluxbox configuration. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille The new 2U server mentioned in the last report now has a collection of Raptor drives in a RAID-10 configuration. Thanks to very generous donations from the community, I purchased eight of these drives at very good prices. The server will be deployed in the next few weeks. There has been quite a bit of work since the last report in June. Some highlights include: * New news feed formats, including newsfeeds for your watch list. * Better pages caching for faster response. * Sanity Test Failures now available online. * Ability to search for all commits (ports, doc, src, etc) under a given point in the tree. For more detail, please review the FreshPorts Blog . _________________________________________________________________ GJournal URL: http://people.freebsd.org/~pjd/patches/gjournal_20060930.patch URL: http://people.freebsd.org/~pjd/patches/gjournal6_20060930.patch Contact: Pawel Jakub Dawidek GJournal seems to be finished. I fixed the last serious bug and it is now stable and reliable in our tests. I'm planning to commit it really soon now. The work was sponsored by home.pl _________________________________________________________________ Gvinum improvements URL: http://folk.ntnu.no/lulf/patches/freebsd/gvinum/gvinum_all_current.dif f Contact: Ulf Lilleengen I thought that since I sent a status report the last time, I might as well send one now. Since the last status report I have done work on several of the remaining commands as attach, detach, and finally the concat command to be able to create concatenated volumes with one easy command. The mirror and stripe commands are the next step after this. The most important thing I've been working on is maybe the implementation of drivegroups. I have posted a bit information on this mailinglists, but basically, it's a way to group drives with the same configuration. This way, you can make many commands operate on groups instead of drives, and the group-abstraction will handle how the underlying subdisks are created on the drives. In the future one will be able to move groups to different machines, etc. I've created a patch of all my work that is not in HEAD yet here (this is a snapshot of my developement branch, so how thing's are done might be changed quite fast): http://folk.ntnu.no/lulf/patches/freebsd/gvinum/gvinum_all_current.dif f Be aware that a there will probably be bugs in the code, so don't use it in production yet! Thanks to Greg Lehey for offering to help me on getting this into CVS, and all feedback on this has been good. Open tasks: 1. Remaining components, mirror, stripe and some info commands. _________________________________________________________________ Gvirstor URL: http://wiki.freebsd.org/gvirstor Contact: Ivan Voras Gvirstor is a GEOM class providing virtual ("overcommit") storage devices larger than physical available storage, with possibility to add physical storage on-line when the need arises. Current status is that it's done and waiting commit to HEAD, scheduled for some time after 6.2 is released. Open tasks: 1. The project is in need of testing! If you have the equipment and time, please give it a try so possible bugs can be fixed before it goes into -CURRENT. _________________________________________________________________ Highly improved implementations of sendfile(2), sosend_*() and soreceive_stream() URL: http://lists.freebsd.org/pipermail/freebsd-current/2006-September/0659 97.html URL: http://lists.freebsd.org/pipermail/freebsd-current/2006-September/0661 99.html URL: http://people.freebsd.org/~andre/sendfile+sosend+soreceive-20061006.di ff Contact: Andre Oppermann The addition of TSO (TCP Segmentation Offload) has highlighted some shortcomings in the sendfile(2) and sosend_*() kernel implementations. The current sendfile(2) code simply loops over the file, turns each 4K page into an mbuf and sends it off. This has the effect that TSO can only generate 2 packets per send instead of up to 44 at its maximum of 64K. kern_sendfile() has been rewritten to work in two loops, the inner which turns as many pages into mbufs as it can -- up to the free send socket buffer space. The outer loop then drops the whole mbuf chain into the send socket buffer, calls tcp_output() on it and then waits until 50% of the socket buffer are free again to repeat the cycle. This way tcp_output() gets the full amount of data to work with and can issue up to 64K sends for TSO to chop up in the network adapter without using any CPU cycles. Thus it gets very efficient especially with the readahead the VM and I/O system do. Looking at the benchmarks we see some very nice improvements: 181% faster with new sendfile vs. old sendfile (non-TSO), 570% faster with new sendfile vs. old sendfile (TSO). The current sosend_*() code uses a sosend_copyin() function that loops over the supplied struct uio and does interleaved mbuf allocations and uiomove() calls. m_getm() has been rewritten to be simpler and to allocate PAGE_SIZE sized jumbo mbuf clusters (4k on most architectures). m_uiotombuf() has been rewritten to use the new m_getm() to obtain all mbuf space in one go. It then loops over it and copies the data into the mbufs by using uiomove(). sosend_dgram() and sosend_generic() have been changed to use m_uiotombuf() instead of sosend_copyin(). Looking at the benchmarks we see some very nice improvements: 290% faster with new sosend vs. old sosend (non-TSO), 280% faster with new sosend vs. old sosend (TSO). Newly written is a specific soreceive_stream() function for stream protocols (primarily TCP) that does only one socket buffer lock per socket read instead of one per data mbuf copied to userland. When doing netperf tests with WITNESS (full lock tracking and validation enabled) the receive performance increases from ~360Mbit/s to ~520Mbit/s. Without WITNESS I could not measure any statistically significant improvement on a otherwise unloaded machine. The reason is two-fold: 1) per packet we do a wakeup and readv() is pretty much as many times as packets come it, thus the general overhead dominates; 2) the packet input path has a pretty high overhead too. On heavily loaded machines which do a lot of high speed receives a performance increase should be measureable. The patches are scheduled to be committed to FreeBSD-current at end of October or early November 2006. This work was sponsored by the TCP/IP Optimization Fundraiser 2005. _________________________________________________________________ Hungarian translation of the webpages URL: http://gabor.t-hosting.hu/data/hu/ Contact: Gábor Kövesdán Since the last status report, there has been a lot of progress. I investigated a lot of charset issues and found out that HTML tidy breaks some entities when using iso-8859-2, so HTML tidy had to be disabled for Hungarian pages. Open tasks: 1. Translate 4 pages. 2. Review, fix typos and improve the wording where necessary. _________________________________________________________________ Improving FreeBSD Ports Collection Infrastructure URL: http://wikitest.freebsd.org/G%C3%A1borK%C3%B6vesd%C3%A1n Contact: Gábor Kövesdán Contact: Erwin Lansing During the Google Summer of Code 2006, Gábor worked on several ideas to improve the ports infrastructure: 1. New handling for i386 binary ports. 2. Cleanup: use ECHO_CMD and ECHO_MSG in bsd.port.mk properly. 3. Add a basic infrastructure support for debugging. 4. Installing ports with different destination (DESTDIR macro). 5. Cleanup: Move fetch shell scripts out of bsd.port.mk. 6. Make ports respect CC and CFLAGS. 7. Cross-compiling Ports. 8. Plist generator tool. The first three items have been completed and the next two items are being worked on. The DESTDIR support was more complicated than presumed and took more time than expected to complete. Gábor will continue working to finish these tasks and other ports related tasks. FreeBSD is happy to have interested him to keep working on ports and ports infrastructure. _________________________________________________________________ IPv6 Stack Vulnerabilities URL: http://wikitest.freebsd.org/ClementLecigne URL: http://pcs.sf.net Contact: George Neville-Neil Contact: Clement Lecigne The focus of this project was to review past vulnerabilities, create vulnerability testing tools and to discover new vulnerabilities in the FreeBSD IPv6 stack which is derived from the KAME project code. During the summer Clement took two libraries, the popular libnet, and his mentor's Packet Construction Set (PCS) and created tools to find security problems in the IPv6 code. Several issues were found, bugs filed, and patches created. At the moment Clement and George are editing a 50 page paper that describes the project which will be submitted for conference publication. All of the code from the project, including the tools, is on line and is described in the paper. By all measures, this was a successful project. Both student and mentor gained valuable insight into a previously externally maintained set of code. In addition to the new tools development in this effort, the FreeBSD Project has gained a new developer to help work on the code. _________________________________________________________________ iSCSI Initiator URL: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-17.5.tar.bz2 Contact: Damiel Braniss This iSCSI initiator kernel module and its companion control program are still under development, but the main parts are working. Open tasks: 1. Network Disconnect Recovery. 2. Sysctl Interface and Instrumentation. 3. Rewrite the userland side of iscontrol. _________________________________________________________________ Jail Resource Limits URL: http://wikitest.freebsd.org/JailResourceLimits Contact: Chris Jones Contact: Kip Macy We now have support for limiting CPU and memory use in jails. This allows fairer sharing of a systems' resources between divergent uses by preventing one jail from monopolizing the available memory and CPU time, if other users and jails have processes to run. The code is currently available as patches against RELENG_6, and Chris is in the process of applying it to -CURRENT. More details can be found at JailResourceLimits on the wiki. Open tasks: 1. Port patches against -CURRENT. _________________________________________________________________ Libelf URL: http://wiki.freebsd.org/LibElf URL: http://wiki.freebsd.org/PmcTools URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement/ Contact: Joseph Koshy Libelf is a BSD-licensed library for ELF parsing & manipulation implementing the SysV/SVR4 (g)ELF[3] API. Current status: Implementation of the library is nearly complete. A TET-based test suite for the API is being worked on. Open tasks: 1. Reviewers are needed for the code and the test suite. If you have extensions to the stock SysV/SVR4 ELF(3) API that you would like to see in -lelf, please send Joseph an email. _________________________________________________________________ MMC/SD Support Contact: Warner Losh Contact: Bernd Walter The MMC/SD stack got a significant boost this quarter. Warner Losh and Bernd Walter have written a generic MMC/SD flash card stack for FreeBSD, and have implemented a host controller for the AT91RM9200 embedded ARM controller they are each using in separate projects. The stack is presently experimental in quality. It is being used as the root file system for these embedded projects. There's been no work done to support hot insertion and removal of cards (neither board wires up the pins necessary, and besides, / disappearing is very bad). There are still many rough edges. This is a freshly written stack. It has been written using the SD 1.0 (and recently 2.0) simplified specification, with the SanDisk MMC application notes supplementing. The Linux stack looks good, although not entirely standards conforming (there's work in progress that I've not seen that is supposed to fix this) and it is contaminated with the GPL. The OpenBSD stack also looks interesting, but Warner's experience porting NEWCARD over from NetBSD suggested that a fresh rewrite may be faster, at least for the bus and driver level. Since MMC is fairly simple, a port of the sdhci driver might be possible. Please see the open tasks list. Open tasks: 1. Write sdhci driver, and integrate it into the current stack. 2. Add support for hot plugging of cards. 3. Add support for MMC cards (SD cards were the first target). 4. Expand SD support to include SDIO cards as well as the new SDHC standard cards. 5. Export stats via sysctl for each of the cards that are found as a debugging and usage monitoring aid. 6. Add support for reading/writing multiple blocks at a time to improve performance. 7. Implement any other host controller. 8. Add proper support for timeouts. _________________________________________________________________ Nss-LDAP importing and nsswitch subsystem improvement URL: http://wikitest.freebsd.org/MichaelBushkov URL: http://wikitest.freebsd.org/LdapCachedOriginalProposal URL: http://wikitest.freebsd.org/LdapCachedDetailedDescription Contact: Michael Bushkov Contact: Hajimu UMEMOTO The Project consisted of five parts: 1. Nsswitch modules and libc separation. The idea was to move the source code for different nsswitch sources (such as "files", "dns", "nis") out of the libc into the separate shared libraries. This task was successfully finished and the patch is available. 2. Regression tests for nsswitch. A set of regression tests to test the correctness of all nsswitch-related functions and the invariance of their behavior between system upgrades. The task can be considered successfully completed, the patch is available. 3. Rewriting nss_ldap. Though, this task was not clearly mentioned in the original proposal, during the SoC we found it would be easier, not to simply import PADL's nss_ldap, but to rewrite it from scratch (licensing issues were among the basic reasons for this). The resulting module behaves similarly to PADL's module, but has a different architecture that is more flexiable. Though it's basically finished, several useful features from the PADL's nss_ldap still need to be implemented. Despite the lack of some features, this task can be considered successfully completed. Missing features will be implemented as soon as possible, hopefully during September. 4. Importing nss_ldap into the Base System. The task was to prepare a patch, that will allow users to use nss_ldap from the base system. The task was successfully completed (the patch is available), but required importing OpenLDAP into the base in order for nss_ldap to work properly, and it had led to a long discussion in the mailing list. This discussion, however, have concluded with mostly positive opinions about nss_ldap and OpenLDAP importing. 5. Cached performance optimization. The caching daemon performance needs to be as high as possible in order for cached to be as close (in terms of speed) to "files" nsswitch source as possible. Cached's performance analysis was made and nsswitch database pre-caching was introduced as the optimization. This task was completed (the patch is available). However there is room for improvement. More precise and extensive performance analysis should be made and more optimizations need to be introduces. This will be done in the near future. Though none of the code was committed yet into the official FreeBSD tree, my experience from the previous year makes me think that this situation is normal. I hope, that the code will be reviewed and committed in the coming months. _________________________________________________________________ OCaml language support in ports URL: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ocaml/bsd. ocaml.mk?rev=1.3&content-type=text/plain Contact: Stanislav Sedov There were a number of OCaml ports in our tree, and each of them was doing the same work by maintaining OCaml ld.conf in the correct state, installing/removing their files/entries etc. To simplify the task of OCaml-language ports creationm the special framework (bsd.ocamk.mk) was developed and most of the ports was converted to use this framework. This allowed a lot of duplicate code to be removed. This new framework handles all the things required to install an OCaml-language library and properly register it. bsd.ocaml.mk also contains knobs to deal with findlib-powered libraries, modify ld.conf in the proper way, etc. Also, a lot of new Ocaml-related ports were added. _________________________________________________________________ OpenBSD dhclient Contact: Brooks Davis Most dhclient changes in HEAD have been merged to 6-STABLE for 6.2-RELEASE. The highlight of these changes is a fix for runaway dhclient processes when packets are not 4 byte aligned. Further changes including always sending client identifiers are scheduled for merge before the release. Work is ongoing to improve dhclient's interaction with alternate methods of setting interface addresses. _________________________________________________________________ Porting the seref policy and setools to SEBSD URL: http://wikitest.freebsd.org/DongmeiLiu Contact: Dongmei Liu Contact: Christian Peron Dongmei Liu spent the summer working on the basic footwork required to port the SEREF policy to SEBSD. This work has been submitted and can be viewed in the soc2006/dongmei_sebsd Perforce branch. This work was originated from the SEBSD branch: //depot/projects/trustedbsd/sebsd. Additionally setools-2.3 was ported from Linux and can be found in contrib/sebsd/setools directory. It is hoped that this work will be merged into the main SEBSD development branch. _________________________________________________________________ Porting Xen to FreeBSD URL: http://www.yuanjue.net/xen/howto.html URL: http://wikitest.freebsd.org/YuanJue Contact: Jue Yuan As a participant of Google's Summer of Code 2006, I am focusing on porting Xen to FreeBSD these months. The result of this summer's work include a domU kernel that could be used for installation, a guide for getting started with FreeBSD on Xen, and some other trivial improvements. But there are still a lot of work needing to be done in this area, e.g, the long-expeted dom0 support. So I will continue my work here and try to keep up with the update of Xen itself. Open tasks: 1. dom0 support is the most urgent _________________________________________________________________ Porting ZFS to FreeBSD URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd /zfs URL: http://www.opensolaris.org/os/community/zfs/porting/ URL: http://docs.freebsd.org/cgi/mid.cgi?20060822104516.GB16033 Contact: Pawel Jakub Dawidek My work is moving slowly forward. ZVOL is, I believe, fully functional (I recently fixed snapshots and clones on zvols), which means you can put UFS on top of RAID-Z volume, take a snapshot of the volume, clone it if needed, etc. Very cool. The hardest part is the ZPL layer, I'm still working on it. Most file system methods work, but probably need detailed review and many fixes. Most of the time these days I'm spending on implementing mmap(2) correctly. It works more or less in simple tests but fails under fsx program. On the other hand, 'fsx -RW' works very stable and reliable. Other test programs (those that don't use mmap(2)) also work quite well. There is still a lot of work to do, mostly in ZPL area, many clean-ups, etc. Some functionality (like ACLs) I haven't even tried to touch yet. _________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports / URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com/ Contact: Mark Linimon The ports PRs surged (especially due to a large number of new port submissions), but with some hard work we have been able to get back down to around 900. We are rapidly approaching 16,000 ports. Due to this acceleration in adding new ports, portmgr is now very concerned that we are outstripping the capacity of both the build infrastructure and our volunteers to keep up with build errors and port updates. Accordingly, we've added a guideline (not a rule) that ports should be of more than just theoretical use to be added to the Ports Collection (e.g. we can't support all of CPAN + all of Sourceforge + everything else). Basically, use common sense as a guideline; certainly no one wants to see any kind of "gateway" procedure to get incoming ports approved. Seven sets of changes have been added to the infrastructure, mostly refactoring and bugfixing. As part of a Summer of Code project, we have also incorporated some of gabor@'s changes to incorporate better DESTDIR support. However, due to some unanticipated side-effects, more work is going to be needed in this area. gabor@ is continuing to work on the changes. netchild@ and bsam@ have been doing a great deal of work to bring the linux emulator ports closer to sanity, including bringing up a regression-test suite. The long-anticipated import of X.Org 7 has stalled due to developer time, mostly to deal with documentation and upgrade instructions. Hopefully this can get done in the early 6.3 development cycle. See the wiki for more information. As a part of that work, the decision has been made to move away from using X11BASE and just put everything into LOCALBASE; /usr/X11R6 is simply an artifact at this point. A plan for a transition process is underway; a great deal of testing will need to be done, but in the end the ports tree will be much cleaner. The GNOME team has already done the work to move all of their ports over, and it will be incorporated after the 6.2 release is shipped. tmclaugh@ is looking for someone to take over the C# ports. He has maintained them for over a year and wants more time to be able to work on other projects. Some work has been done to get rid of FreeBSD 2.X cruft in ports. Further work is needed to get the 3.X cruft removed. linimon@ did another pass through resetting inactive maintainers. Another list is waiting in the wings. linimon@ is also working on adding the ability for portsmon to analyze successful packages (not just failed ones), so that queries such as "show me packages that build on i386 but not amd64" and "show me why dependent package foo was not built on bar". This is currently in alpha testing. We have added 4 new committers since the last report. Open tasks: 1. We still need help getting back to our modern low of 500 PRs. 2. We have nearly 4400 unmaintained ports (see, for instance, the list on portsmon ). Although there has been a welcome upsurge in new maintainers recently which has dropped the percentage down below 28%, we still need much more help. 3. A test run of gcc4.1 on the ports tree showed around 1000 new build errors. Kris@ has posted some results so that people can start working on the problems now. In particular, it seems that certain older versions of GCC cannot be built with GCC 4.1, so ports that depend on those older versions are going to have to be fixed as well. Although the import of GCC 4.1 to -CURRENT is not imminent, the time to start planning is now. 4. The state of the packages on AMD64 and sparc64 significantly lags that of i386. In many of these cases, packages are not attempted because NOT_FOR_ARCH is used instead of more accurately only setting BROKEN based on ARCH. (pointyhat can be forced to build packages that are marked BROKEN, but not NOT_FOR_ARCH). NOT_FOR_ARCH is supposed to denote only "will never work on this ARCH". Although we have volunteers who have expressed interest in sparc64 (and ia64), we need more people who are running amd64 (especially as a desktop) to help us get more packages working. _________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ URL: http://www.FreeBSD.org/releases/ URL: http://www.FreeBSD.org/snapshots/ Contact: Release Engineering Team The FreeBSD Release Engineering team is currently working on FreeBSD 6.2-RELEASE, which is scheduled for release in early November 2006. Some notable features of this release include the debut of security event auditing as an experimental feature, Xbox support, the FreeBSD Update binary updating utility, and of course many fixes and updates for existing programs. Pre-release images for all Tier-1 architectures are available for testing now; feedback on these builds is greatly appreciated. More information about release engineering activities can be found at the links above. _________________________________________________________________ SCTP Integration URL: http://www.sctp.org/ Contact: Randall Stewart Contact: George Neville-Neil There are currently patches available for testing. A planned integration to HEAD is set to happen in October. Open tasks: 1. The code still needs plenty of testing. See patches on sctp.org and in -CURRENT soon. _________________________________________________________________ SNMP monitoring (BSNMP) URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/soc %2dshteryana/bsnmp&HIDEDEL=NOe URL: http://wikitest.freebsd.org/CategorySNMP URL: http://wiki.freebsd.org/SnmpBridgeModule URL: http://www.freshports.org/net-mgmt/bsnmptools/ Contact: Shteryana Shopova Contact: Bjoern A. Zeeb A BRIDGE monitoring module for FreeBSD's BSNMP daemon has been implemented. In addition to RFC 4188 single bridge support and extending the kernel to get access to all the information, a private MIB was designed in order to be able to monitor multiple bridges supported by FreeBSD. The kernel part has already been committed to -CURRENT (thanks to thompsa@), for -STABLE a patch is available (see the wiki), code has already been reviewed. SoC 2005 work on SNMP client tools is now available too via port (net-mgmt/bsnmptools), thanks to Andrew Pantyukhin for the port. Open tasks: 1. More testing is very welcome. 2. if_vlan(4) monitoring module. 3. jail(8) monitoring module. _________________________________________________________________ Sound Subsystem Improvements URL: http://people.FreeBSD.org/~ariff/ URL: http://www.FreeBSD.org/projects/ideas/ URL: http://wiki.FreeBSD.org/soundsystem Contact: Ariff Abdullah Contact: Alexander Leidinger Contact: Ryan Beasley Contact: Multimedia Mailinglist Since the last status report we added basic support for envy24ht chips, imported the emu10kx driver into the base system and added support for High Definition Audio (HDA) compatible chips. Additionally the work of Ryan Beasley as part of his Google Summer of Code 2006 participation is committed. It adds compatibility to the Open Sound System (OSS) v4 API as far as this was possible. This allows for more sophisticated programs to be written. For example it is now possible to synchronize the start of multiple sound channels. It is also possible for a driver to support more than the AC97 mixer devices, but so far no driver has been extended to support this yet. More about it can be found in the wiki and in the official OSS documentation. The wiki page about the sound system was started to describe the current status of the sound system and to provide some information about where we are heading. But more work needs to be done to reach this goal. So far we collected some information about the status of the most recent work in the soundsystem. So if you have a look at it and you think that something important is missing, just tell us about it. While fully prepared content is very welcome, we are even happy about some ideas what we should list on the wiki page. Open tasks: 1. Have a look at the sound related entries on the ideas list. 2. sndctl(1): tool to control non-mixer parts of the sound system (e.g. spdif switching, virtual-3D effects) by an user (instead of the sysctl approach in -current); pcmplay(1), pcmrec(1), pcmutil(1). 3. Plugable FEEDER infrastructure. For ease of debugging various feeder stuff and/or as userland library and test suite. 4. Extend the wiki page. _________________________________________________________________ Summer of Code Summary URL: http://www.FreeBSD.org/projects/summerofcode-2006.html URL: http://wikitest.freebsd.org/SummerOfCode2006 URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects /soc2006/ Contact: Murray Stokely We had another successful summer taking part in the Google Summer of Code. By all accounts, the FreeBSD participation in this program was an unqualified success. We received over 150 applications for student projects, amongst which 13 were selected for funding. All successful students received the full $4,500. These student projects included security research, improved installation tools, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program. At least 2 of our FreeBSD mentors will be meeting with Google organizers in Mountain View this month to discuss the program at the Mentor Summit. _________________________________________________________________ Summer of FreeBSD security development URL: http://people.freebsd.org/~cperciva/funding.html URL: http://www.daemonology.net/freebsd-upgrade-6.0-to-6.1/ Contact: Colin Percival I spent the months of May through August working on improving Portsnap, FreeBSD Update, and devoting more time to my (continuing) role as Security Officer. FreeBSD Update is now part of the FreeBSD base system and is fully supported by the FreeBSD Security Team; updates are currently only being built for the i386 architecture, but AMD64 updates will become available soon. In an attempt to reduce the number of people running out of date (and unsupported) FreeBSD releases, I wrote an automatic binary upgrade script for upgrading systems from FreeBSD 6.0 to FreeBSD 6.1; I will be releasing a new script for upgrading to FreeBSD 6.2-(RC*|RELEASE) soon (possibly before this status report is published). Further improvements to Portsnap are still ongoing. _________________________________________________________________ Sun Niagara port Contact: Kip Macy Support for the UltraSparc T1 (Niagara) continues to improve. The code has recently been checked into public CVS under sys/sun4v. It isn't clear whether or not I will have time to implement full logical domaining support before the APIs become publicly available. Testing indicates that substantial work will be needed before FreeBSD can take full advantage of all 32 threads. Open tasks: 1. Random testing and bug fixes. 2. Import and extend improved mutex profiling support. 3. Virtual network and virtual disk device drivers for logical domains. _________________________________________________________________ The FreeBSD Foundation URL: http://www.freebsdfoundation.org Contact: Deb Goodkin The FreeBSD Foundation continued to support the FreeBSD project and community through various activities. These activities include creating strategies for fund development and actively seeking funding for the FreeBSD community, coordinating a new IBM Bladeserver project, and protecting the image and integrity of FreeBSD by governing the use of the trademarks. We are pleased to be a sponsor of EuroBSDCon and will be sponsoring a few developers to attend the conference through our travel grant program. And finally, we have secured funds for a major project that will be announced later this month. _________________________________________________________________ TrustedBSD Audit URL: http://www.TrustedBSD.org/audit.html URL: http://www.OpenBSM.org/ Contact: Robert Watson Contact: Christian Peron Contact: Wayne Salamon The TrustedBSD audit implementation provides fine-grained security event logging throughout the FreeBSD operating system. The big news for the last quarter is that the TrustedBSD audit implementation has been merged into RELENG_6 branch, and appeared in 6.2-BETA2. Over the past few months, work has also occurred in the following areas: * OpenBSM 1.0 alpha 8 through alpha 12 have been released and merged into FreeBSD CVS. Changes include significant numbers of bug fixes, documentation improvements, and feature enhancements. These include regular expression based matching for auditreduce, auditd management of kernel audit policy (such as maximum trail file size), improvements in printing support for a variety of tokens including execve argument support. * Significant enhancements to the FreeBSD Handbook chapter on Audit. * Full audit support for execve events, including optional auditing of command line arguments and environmental variables, as well as audit support for a broad range of other additional kernel events. * Kqueue support for audit pipes. * Robustness improvements in the presence of low disk space conditions. * Support for system call capture on additional platforms, such as ppc and ia64. * Improved support for very large audit record sizes (as required for extensive execve support). * id(1) now supports a -A argument to query audit state for the process. * An audit_warn(5) event for trail rotation, which can be used for archiving, reduction, and other administrative activities. Lots of testing as part of the 6.2-BETA cycle would be much appreciated. Audit support will be considered an experimental feature in FreeBSD 6.2-RELEASE, but we hope that it will be a production feature in 6.3-RELEASE. Open tasks: 1. Continue expanding auditing of syscall arguments. 2. Continue expanding auditing of administrative tools. 3. More testing! 4. Continue to explore improvements of the administrative model for audit trails, etc. _________________________________________________________________ TSO - TCP Segmentation Offload committed URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/068524.html URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/068610.html URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/069493.html Contact: Andre Oppermann TSO - TCP Segmentation Offload support has been committed to the network stack of FreeBSD-current in September 2006. With TSO, TCP can send data in the send socket buffer in bulk down to the network card which then does the splitting into MTU sized packets. On bulk high speed sending the performance is increased by 25% (normal writes) to 108% (sendfile). Jack Vogel and Prafulla Deuskar of Intel committed the driver changes for TSO hardware support of em(4) based network cards. These changes are scheduled to be backported to FreeBSD 6-STABLE shortly after FreeBSD 6.2-RELEASE is published to appear in upcoming FreeBSD 6.3 early next year. This work was sponsored by the TCP/IP Optimization Fundraiser 2005. Open tasks: _________________________________________________________________ Update of the Linux compatibility environment in the kernel URL: http://wiki.FreeBSD.org/linux-kernel Contact: Alexander Leidinger Contact: Roman Divacky Contact: Emulation Mailinglist Roman Divacky participated in the Google Summer of Code 2006 and implemented a major part of the syscall compatibility to the 2.6.16 Linux kernel. The work has been committed to -CURRENT (the default compatibility still being a 2.4.2 Linux kernel) and we are working on fixing the remaining bugs as time permits. "Intron" submitted an implementation for the linux aio syscalls. His work has been committed to the Perforce repository. We also started to consolidate a list of known bugs, open issues and helpful stuff (e.g. regression tests and their status) in -CURRENT on a page in the FreeBSD wiki (see the links-section). It also contains a link to a more or less up-to-date patch with stuff we have in the Perforce repository so that interested people can help with testing. Thanks to the help of Marcin Cieslak we already fixed some bugs (some of the fixes are already MFCed to -STABLE). Thanks to the nice regression tests of the Linux Test Project (LTP) we have a list of small (and not so small) things which need to be looked at. This list makes up for a quick start into kernel hacking. So if you have a little bit of knowledge about C programming, and if you want to help us a little bit in improving FreeBSD, feel free to have a look at the list and to try to fix a problem or two. Sometimes it is as easy as "if (error condition) return Esomething;" (but you should coordinate with the emulation mailinglist, so that nobody does some work someone else just did too). Even if you do not know how to program, you can help. Have a look at the wiki page and tell us about things which should get mentioned there too. Or download the patch and test it. _________________________________________________________________ USB URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects /usb/src/sys/dev/usb&HIDEDEL=NO URL: http://www.turbocat.net/~hselasky/usb4bsd Contact: Hans Petter Sirevaag Selasky During the last three months I have finished reworking nearly all USB device drivers found in FreeBSD-7-CURRENT. Only two USB drivers are left and that is ubser(4) and slhci. Some still use Giant, but most have been brought out of Giant. At the moment I am looking for testers that can test the various USB device drivers. Some have already been tested, and confirmed to work, while others have problems which need to be fixed. If you want to test, checkout the USB perforce tree or download the SVN version of the USB driver that is available on my homepage. At the moment the tarballs are a little out of date. Ideas and comments with regard to the new USB API are welcome at: freebsd-usb@freebsd.org. _________________________________________________________________ Xen Port Contact: Kip Macy Work on Xen support has slowly been continuing in perforce. The SOC student fixed several bugs and is continuing to work on it. Someone is needed who has the time to complete dom0 support and shepherd it production level stability. Sufficient interest has been expressed in it that it probably makes sense to check it in to public CVS so that more people can try it out. Time permitting, I will bring it up to date and check it in the next month. Open tasks: 1. dom0 support. 2. General testing and bug fixing. _________________________________________________________________ News Home | Status Home Legal Notices | © 1995-2006 The FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 07:27:48 2006 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EDDA16A407; Thu, 19 Oct 2006 07:27:48 +0000 (UTC) (envelope-from so14k@so14k.com) Received: from ender.liquidneon.com (ender.liquidneon.com [216.38.206.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E9443D7B; Thu, 19 Oct 2006 07:27:44 +0000 (GMT) (envelope-from so14k@so14k.com) Received: from localhost (localhost [127.0.0.1]) by ender.liquidneon.com (Postfix) with ESMTP id 359BE2E0DD; Thu, 19 Oct 2006 01:27:44 -0600 (MDT) Received: from ender.liquidneon.com ([127.0.0.1]) by localhost (ender.liquidneon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39741-04; Thu, 19 Oct 2006 01:27:43 -0600 (MDT) Received: by ender.liquidneon.com (Postfix, from userid 1000) id DCCA12E0C9; Thu, 19 Oct 2006 01:27:43 -0600 (MDT) Date: Thu, 19 Oct 2006 01:27:43 -0600 From: Brad Davis To: hackers@FreeBSD.org Message-ID: <20061019072743.GA39924@ender.liquidneon.com> References: <20061019070508.GE35452@ender.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061019070508.GE35452@ender.liquidneon.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at ender.liquidneon.com Cc: announce@FreeBSD.org, current@FreeBSD.org Subject: Re: FreeBSD Project Status Report - Fourth Quarter of 2006 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 07:27:48 -0000 Hi, The subject should read "FreeBSD Project Status Report - Third Quarter of 2006" Sorry for the confusion. Regards, Brad Davis From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 13:57:29 2006 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03F5E16A415; Thu, 19 Oct 2006 13:57:29 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from linkfe02.link.net (linkfe02.link.net [196.205.62.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72B3043DB9; Thu, 19 Oct 2006 13:56:53 +0000 (GMT) (envelope-from brd@FreeBSD.org) Received: from antispam3 ([213.131.64.223]) by linkfe02.link.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:53:59 +0200 Received: from Gateway1.link.net (Not Verified[213.131.64.208]) by antispam3 with MailMarshal (v6, 1, 6, 1172) id ; Thu, 19 Oct 2006 15:55:53 +0200 Received: from mail pickup service by Gateway1.link.net with Microsoft SMTPSVC; Thu, 19 Oct 2006 15:52:43 +0200 Received: from mx2.freebsd.org ([216.136.204.119]) by Gateway1.link.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:15:09 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id DA5EE14B880; Thu, 19 Oct 2006 12:12:44 +0000 (GMT) (envelope-from owner-freebsd-announce@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6735016A5D1; Thu, 19 Oct 2006 12:12:29 +0000 (UTC) (envelope-from owner-freebsd-announce@freebsd.org) X-Original-To: announce@FreeBSD.org Delivered-To: freebsd-announce@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C97D116A415; Thu, 19 Oct 2006 07:05:11 +0000 (UTC) (envelope-from so14k@so14k.com) Received: from ender.liquidneon.com (ender.liquidneon.com [216.38.206.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0669043D58; Thu, 19 Oct 2006 07:05:09 +0000 (GMT) (envelope-from so14k@so14k.com) Received: from localhost (localhost [127.0.0.1]) by ender.liquidneon.com (Postfix) with ESMTP id 9A3462E0C0; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Received: from ender.liquidneon.com ([127.0.0.1]) by localhost (ender.liquidneon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39466-01; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Received: by ender.liquidneon.com (Postfix, from userid 1000) id 0BB002E0BE; Thu, 19 Oct 2006 01:05:09 -0600 (MDT) Date: Thu, 19 Oct 2006 01:05:08 -0600 From: Brad Davis To: hackers@FreeBSD.org Message-ID: <20061019070508.GE35452@ender.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at ender.liquidneon.com X-Mailman-Approved-At: Thu, 19 Oct 2006 12:12:21 +0000 X-BeenThere: freebsd-announce@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-announce@freebsd.org Errors-To: owner-freebsd-announce@freebsd.org Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Oct 2006 12:15:10.0104 (UTC) FILETIME=[38CA3980:01C6F378] Cc: announce@FreeBSD.org, current@FreeBSD.org Subject: [FreeBSD-Announce] FreeBSD Project Status Report - Fourth Quarter of 2006 X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 13:57:29 -0000 FreeBSD Status Report Introduction This report covers FreeBSD related projects between June and October 2006. This includes the conclusion of this year's Google Summer of Code with 13 successful students. Some of last year's and the current SoC participants have meanwhile joined the committer ranks, kept working on their projects, and improving FreeBSD in general. This year's EuroBSDCon in Milan, Italy has meanwhile published an exciting program. Many developers will be there to discuss these current and future projects at the Developer Summit prior the conference. Next year's conference calendar has a new entry - in addition to the now well established BSDCan in Ottawa - AsiaBSDCon will take place in Tokyo at the begining of March. As we are closing in on FreeBSD 6.2 release many bugs are being fixed and new features have been MFCed. On the other hand a lot of the projects below already are focusing on FreeBSD 7.0 and promise a lot of exciting news and features to come. Thanks to all the reporters for the excellent work! We hope you enjoy reading. _________________________________________________________________ Google Summer of Code * Analyze and Improve the Interrupt Handling Infrastructure * Bundled PXE Installer * Gvirstor * IPv6 Stack Vulnerabilities * Jail Resource Limits * Nss-LDAP importing and nsswitch subsystem improvement * Porting the seref policy and setools to SEBSD * Porting Xen to FreeBSD * SNMP monitoring (BSNMP) * Summer of Code Summary * Update of the Linux compatibility environment in the kernel Projects * CScout on the FreeBSD Source Code Base * DTrace * Embedded FreeBSD * FreeSBIE * GJournal * iSCSI Initiator * Porting ZFS to FreeBSD * Summer of FreeBSD security development * TrustedBSD Audit * USB FreeBSD Team Reports * FreeBSD Security Officer and Security Team * Ports Collection * Release Engineering * The FreeBSD Foundation Network Infrastructure * Bridge Spanning Tree Protocol Improvements * FAST_IPSEC Upgrade * Highly improved implementations of sendfile(2), sosend_*() and soreceive_stream() * SCTP Integration * TSO - TCP Segmentation Offload committed Kernel * Gvinum improvements * MMC/SD Support * Sound Subsystem Improvements Documentation * Chinese (Simplified) Project * Hungarian translation of the webpages Userland Programs * Libelf * OpenBSD dhclient Architectures * CPU Microcode Update Software * FreeBSD/arm on Atmel AT91RM9200 * Sun Niagara port * Xen Port Ports * Enlightenment DR17 support in the ports tree * FreshPorts * Improving FreeBSD Ports Collection Infrastructure * OCaml language support in ports Miscellaneous * AsiaBSDCon 2007 * BSDCan 2007 * EuroBSDCon 2006 * FreeBSD Multimedia Resources List _________________________________________________________________ Analyze and Improve the Interrupt Handling Infrastructure URL: http://wikitest.freebsd.org/Interrupts Contact: Paolo Pisati Contact: John Baldwin This project consisted in the improvement of the Interrupt Handling System in FreeBSD: while retaining backward compatibility with the previous models (FAST and ITHREAD), a new method called 'Interrupt filtering' was added. With interrupt filtering, the interrupt handler is divided into 2 parts: the filter (that checks if the actual interrupt belong to this device) and the ithread (that is scheduled in case some blocking work has to be done). The main benefits of interrupt filtering are: * Feedback from filters (the system finally knows if any handler has serviced an interrupt or not, and can react consequently). * Lower latency/overhead for shared interrupt line. * Previous experiments with interrupt filtering showed an increase in performance against the plain ithread model Moreover, during the development of interrupt filtering, some MD dependent code was converted into MI code, PPC was fixed to support multiple FAST handlers per line and an interrupt stray storm detection logic was added. While the framework is done, there are still machine dependent bits to be written (the support for ppc, sparc64, arm and itanium has to be written/reviewed) and a serious analysis of the performance of this model against the previous one is a work-in-progress _________________________________________________________________ AsiaBSDCon 2007 URL: http://www.asiabsdcon.org/ Contact: Hiroki Sato Contact: George Neville-Neil Contact: Web site is up and we're soliciting papers and presentations. Some tutorials are already scheduled. Email secretary@asibsdcon.org if you have questions or submissions. Open tasks: 1. Send in more papers! _________________________________________________________________ Bridge Spanning Tree Protocol Improvements Contact: Andrew Thompson Work is almost finished to implement the Rapid Spanning Tree Protocol (RSTP) which supersedes Spanning Tree Protocol (STP). RSTP has a much faster link failover time of around one second compared to 30-60 seconds for STP, this is very important on modern networks. The code will be posted shortly for testing and feedback. _________________________________________________________________ BSDCan 2007 URL: http://www.bsdcan.org/ Contact: Dan Langille The dates for BSDCan 2007 has been set: 11-12 May 2007. As is usual, BSDCan will be held at University of Ottawa, with two days of tutorials prior to the conference starting. The call for papers will go out in mid December. Start thinking about your submissions now! _________________________________________________________________ Bundled PXE Installer URL: http://wikitest.freebsd.org/MarkusBoelter Contact: Markus Boelter Contact: Paul Saab For me, the Google Summer of Code was a new and very exciting experience. I got actively involved in doing Open Source Software and giving something back to the community. Facing some challenges within the project forced me to look behind the scenery of FreeBSD. The result was a better understanding of the overall project. Working with a lot of developers directly also gave a very special spirit to the Google Summer of Code. I really enjoyed the time and will continue to work on the project after the deadline. For me, it was a great chance to get involved in active development and not just some scripts and hacks at home. Getting paid for the work was just a small part of the overall feeling. Thanks to the people at the FreeBSD Project and Google for the really, really great time! _________________________________________________________________ Chinese (Simplified) Project URL: http://cnsnap.cn.FreeBSD.org/zh_CN/ URL: http://cnsnap.cn.FreeBSD.org/doc/zh_CN.GB2312/ Contact: Xin LI In the previous quarter we primarily focused on overall quality of the translation rather than just increasing the number of translations, and we have strived to make sure that these translated stuff are up-to-date with their English revisions. Also, we have merged the translated website into the central repository. In the next quarter we will focus on developing documentation that will help to attract more developers. Open tasks: 1. Translate more development related documentation. 2. Review more of the currently translated documentation. _________________________________________________________________ CPU Microcode Update Software Contact: Stanislav Sedov Last month I was working on a driver/module to update the microcode of Intel or AMD CPUs that support having their microcode updated. As you might know these processors are microcode-driven and this firmware can be updated. Intel(R) often releases microcode updates, and AMD(R) updates can be found in BIOS programs. The work is almost finished now, I just need to find a bit of time to test it on AMD64 systems and perform some code cleanup. The driver also provide a way for userland programs to access the Machine Specific Registers (MSR) and CPUID info for a certain cpu. This will allow some programs like x86info to provide more accurate information about cpus in SMP systems and make assumptions based on the contents of the MSR. Thanks to John Baldwin, Kostik Belousov, John-Mark Gurney and Divacky Roman for helping during development. Open tasks: 1. Perform testing on the AMD64-based systems. 2. Write manpage. 3. Code cleanup/checks. _________________________________________________________________ CScout on the FreeBSD Source Code Base URL: http://wikitest.freebsd.org/CScout Contact: Diomidis Spinellis CScout is a refactoring editor and source code browser for collections of C code. The aim of the project is to make it easy for FreeBSD developers to use CScout and to improve the FreeBSD source code quality through CScout-based queries and refactorings. CScout was first applied to the FreeBSD kernel in 2003. Its application at that point involved substantial tinkering with the build system. The version released in October 2006 makes the running of CScout on the three Tier-1 architectures a fairly straightforward procedure. The current version can also draw a number of call graphs; this might help developers better understand foreign code. Open tasks: 1. Use CScout to locate problematic code areas (for example unused or too liberaly visible objects). 2. Use CScout to globaly rename identifiers in a more consistent fashion. 3. Apply CScout to the userland code. 4. Identify CScout extensions that would help us improve the quality of our code. 5. Arrange for the continous availability of a live CScout kernel session on the current version of the source code. _________________________________________________________________ DTrace Contact: John Birrell Progress this month has been limited due to my sea-change, moving house to the country. Sun's OpenSolaris developers have followed through and released the DTrace test suite as part of the OpenSolaris distribution. jkoshy@'s work on libbsdelf is nearing feature completion for DTrace and will make life easier in FreeBSD for DTrace, given that we have more architectures to support than Sun has. The FreeBSD project has made available a dual processor AMD64 machine for DTrace porting. I am currently working through the diffs between the DTrace project in P4 and -current, committing files to -current if they are ready, _________________________________________________________________ Embedded FreeBSD URL: http://www.embeddedfreebsd.org/ Contact: George Neville-Neil Moved the HTML pages into the project CVS tree. Open tasks: 1. Setup the web site to be served from projects CVS so that it can be updated by others. 2. Complete the ARM port. 3. Work on the MIPS port. 4. Update the documentation to include common tasks for embedded engineers. _________________________________________________________________ Enlightenment DR17 support in the ports tree Contact: Stanislav Sedov Integration of the new innovative e17 window manager into the ports tree is almost completed. A lot of new e17-related applications was ported, all old ports were updated to the latest stable cvs snapshot. The special framework (bsd.efl.mk) was created to support the whole thing and simplify the creation of dependent ports. I'll commit the changes in the days before the ports freeze. Thanks to Sergey Matveychuk (sem@) for providing a machine to place CVS snapshots on. Without his help it will be impossible. Open tasks: 1. Port Entrance (xdm-like app, but very appealing). 2. Port Net and Wlan e17 module. 3. Develop FreeBSD-specific e17 apps/modules to use The Ports Collection, system configs, etc. _________________________________________________________________ EuroBSDCon 2006 URL: http://www.eurobsdcon.org/ URL: http://www.eurobsdcon.org/register/ Contact: EuroBSDCon Organizing Committee EuroBSDCon 2006 is taking place in Milan (Italy), from the 10th to the 12th of November. EuroBSDCon represents the biggest gathering for BSD developers from the old continent, as well as users and passionates from around the World. It is also a chance to share experiences, know-how, and cultures. The program is rich in talks about FreeBSD, with topics ranging from "How the FreeBSD ports collection works" to "Interrupt Filtering in FreeBSD". This means that both the novice and the hacker can enjoy the conference. Registration is open. The EuroBSDCon Organizing Committee hopes to see you in Milan. _________________________________________________________________ FAST_IPSEC Upgrade URL: www.freebsd.org/~gnn/fast_ipv6.patch Contact: George Neville-Neil Contact: Bjoern Zeeb First working version of code. Does not pass all TAHI tests, but does pass packets correctly and does not panic. Open tasks: 1. More testing of the patch needed. _________________________________________________________________ FreeBSD Multimedia Resources List URL: http://www.mavetju.org/unix/multimedia.php URL: http://www.mavetju.org/unix/multimedia-rss.php Contact: Edwin Groothuis I have setup the FreeBSD Multimedia Resources List, a one-stop-shop for FreeBSD related podcasts, vodcasts and audio/video resources. Hopefully this list will make it easier for people to find and keep up to date with these recordings. The overview is available as a normal HTML page and as an XML/RSS feed. The ultimate goal is to have this list to reside under the www.FreeBSD.org umbrella. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In the time since the last status report, six security advisories have been issued concerning problems in the base system of FreeBSD; of these, five problems were in "contributed" code, while one was in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 57 new entries have been added, bringing the total up to 814. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.11, FreeBSD 5.3, FreeBSD 5.4, FreeBSD 5.5, FreeBSD 6.0, and FreeBSD 6.1. The respective End of Life dates of supported releases are listed on the web site; of particular note, FreeBSD 5.3 and FreeBSD 5.4 will cease to be supported at the end of October 2006, while FreeBSD 6.0 will cease to be supported at the end of November 2006 (or possibly a short time thereafter in order to allow time for upgrades to the upcoming FreeBSD 6.2). _________________________________________________________________ FreeBSD/arm on Atmel AT91RM9200 Contact: Warner Losh Contact: Olivier Houchard The FreeBSD/arm port has grown support for the Atmel AT91RM9200. Boards based on this machine are booting to multiuser off either NFS or an SD card. The onboard serial ports, PIO, ethernet and SD/MMC card controllers are well supported. Support for the SSC, IIC and SPI flash parts in the kernel will be forthcoming shortly. In addition to normal kernel support, the port includes a boot loader that can initialize memory and boot off IIC eeprom, SPI DataFlash, BOOTP/TFTP and SD memory cards. The port will be included in forth coming commercial products. Open tasks: 1. Add support for other members of the AT91 family of arm9 processors. 2. Finish support for AT45D* flash parts. 3. Finish support for USB ports 4. Write support for USB Device functionality _________________________________________________________________ FreeSBIE URL: http://www.FreeSBIE.org URL: http://liste.gufi.org/mailman/listinfo/freesbie URL: http://people.freebsd.org/~matteo/GMV/GMVAnnounce.txt Contact: FreeSBIE Staff Contact: Matteo Riondato FreeSBIE is a FreeBSD based LiveCD. On August 19th, Matteo Riondato, a member of the FreeSBIE staff, released an unofficial ISO, codename FreeSBIE GMV, based on FreeBSD -CURRENT (read the Announcement to download it). This is supposed to be the first in a series of four ISOs that will end up with the release of FreeSBIE 2.0. Matteo is now working on another ISO, codename FreeSBIE LVC, which is scheduled to be released October 12th. FreeSBIE 2.0 will be based on FreeBSD 6.2-RELEASE and will hopefully be released at EuroBSDCon 2006 in Milan. It will be available for the i386 and AMD64 platforms. Open tasks: 1. Test the released ISO in preparation for the release. 2. Suggest software to include in the ISO. 3. Submit a simple and clear but complete fluxbox configuration. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille The new 2U server mentioned in the last report now has a collection of Raptor drives in a RAID-10 configuration. Thanks to very generous donations from the community, I purchased eight of these drives at very good prices. The server will be deployed in the next few weeks. There has been quite a bit of work since the last report in June. Some highlights include: * New news feed formats, including newsfeeds for your watch list. * Better pages caching for faster response. * Sanity Test Failures now available online. * Ability to search for all commits (ports, doc, src, etc) under a given point in the tree. For more detail, please review the FreshPorts Blog . _________________________________________________________________ GJournal URL: http://people.freebsd.org/~pjd/patches/gjournal_20060930.patch URL: http://people.freebsd.org/~pjd/patches/gjournal6_20060930.patch Contact: Pawel Jakub Dawidek GJournal seems to be finished. I fixed the last serious bug and it is now stable and reliable in our tests. I'm planning to commit it really soon now. The work was sponsored by home.pl _________________________________________________________________ Gvinum improvements URL: http://folk.ntnu.no/lulf/patches/freebsd/gvinum/gvinum_all_current.dif f Contact: Ulf Lilleengen I thought that since I sent a status report the last time, I might as well send one now. Since the last status report I have done work on several of the remaining commands as attach, detach, and finally the concat command to be able to create concatenated volumes with one easy command. The mirror and stripe commands are the next step after this. The most important thing I've been working on is maybe the implementation of drivegroups. I have posted a bit information on this mailinglists, but basically, it's a way to group drives with the same configuration. This way, you can make many commands operate on groups instead of drives, and the group-abstraction will handle how the underlying subdisks are created on the drives. In the future one will be able to move groups to different machines, etc. I've created a patch of all my work that is not in HEAD yet here (this is a snapshot of my developement branch, so how thing's are done might be changed quite fast): http://folk.ntnu.no/lulf/patches/freebsd/gvinum/gvinum_all_current.dif f Be aware that a there will probably be bugs in the code, so don't use it in production yet! Thanks to Greg Lehey for offering to help me on getting this into CVS, and all feedback on this has been good. Open tasks: 1. Remaining components, mirror, stripe and some info commands. _________________________________________________________________ Gvirstor URL: http://wiki.freebsd.org/gvirstor Contact: Ivan Voras Gvirstor is a GEOM class providing virtual ("overcommit") storage devices larger than physical available storage, with possibility to add physical storage on-line when the need arises. Current status is that it's done and waiting commit to HEAD, scheduled for some time after 6.2 is released. Open tasks: 1. The project is in need of testing! If you have the equipment and time, please give it a try so possible bugs can be fixed before it goes into -CURRENT. _________________________________________________________________ Highly improved implementations of sendfile(2), sosend_*() and soreceive_stream() URL: http://lists.freebsd.org/pipermail/freebsd-current/2006-September/0659 97.html URL: http://lists.freebsd.org/pipermail/freebsd-current/2006-September/0661 99.html URL: http://people.freebsd.org/~andre/sendfile+sosend+soreceive-20061006.di ff Contact: Andre Oppermann The addition of TSO (TCP Segmentation Offload) has highlighted some shortcomings in the sendfile(2) and sosend_*() kernel implementations. The current sendfile(2) code simply loops over the file, turns each 4K page into an mbuf and sends it off. This has the effect that TSO can only generate 2 packets per send instead of up to 44 at its maximum of 64K. kern_sendfile() has been rewritten to work in two loops, the inner which turns as many pages into mbufs as it can -- up to the free send socket buffer space. The outer loop then drops the whole mbuf chain into the send socket buffer, calls tcp_output() on it and then waits until 50% of the socket buffer are free again to repeat the cycle. This way tcp_output() gets the full amount of data to work with and can issue up to 64K sends for TSO to chop up in the network adapter without using any CPU cycles. Thus it gets very efficient especially with the readahead the VM and I/O system do. Looking at the benchmarks we see some very nice improvements: 181% faster with new sendfile vs. old sendfile (non-TSO), 570% faster with new sendfile vs. old sendfile (TSO). The current sosend_*() code uses a sosend_copyin() function that loops over the supplied struct uio and does interleaved mbuf allocations and uiomove() calls. m_getm() has been rewritten to be simpler and to allocate PAGE_SIZE sized jumbo mbuf clusters (4k on most architectures). m_uiotombuf() has been rewritten to use the new m_getm() to obtain all mbuf space in one go. It then loops over it and copies the data into the mbufs by using uiomove(). sosend_dgram() and sosend_generic() have been changed to use m_uiotombuf() instead of sosend_copyin(). Looking at the benchmarks we see some very nice improvements: 290% faster with new sosend vs. old sosend (non-TSO), 280% faster with new sosend vs. old sosend (TSO). Newly written is a specific soreceive_stream() function for stream protocols (primarily TCP) that does only one socket buffer lock per socket read instead of one per data mbuf copied to userland. When doing netperf tests with WITNESS (full lock tracking and validation enabled) the receive performance increases from ~360Mbit/s to ~520Mbit/s. Without WITNESS I could not measure any statistically significant improvement on a otherwise unloaded machine. The reason is two-fold: 1) per packet we do a wakeup and readv() is pretty much as many times as packets come it, thus the general overhead dominates; 2) the packet input path has a pretty high overhead too. On heavily loaded machines which do a lot of high speed receives a performance increase should be measureable. The patches are scheduled to be committed to FreeBSD-current at end of October or early November 2006. This work was sponsored by the TCP/IP Optimization Fundraiser 2005. _________________________________________________________________ Hungarian translation of the webpages URL: http://gabor.t-hosting.hu/data/hu/ Contact: G=E1bor K=F6vesd=E1n Since the last status report, there has been a lot of progress. I investigated a lot of charset issues and found out that HTML tidy breaks some entities when using iso-8859-2, so HTML tidy had to be disabled for Hungarian pages. Open tasks: 1. Translate 4 pages. 2. Review, fix typos and improve the wording where necessary. _________________________________________________________________ Improving FreeBSD Ports Collection Infrastructure URL: http://wikitest.freebsd.org/G%C3%A1borK%C3%B6vesd%C3%A1n Contact: G=E1bor K=F6vesd=E1n Contact: Erwin Lansing During the Google Summer of Code 2006, G=E1bor worked on several ideas to improve the ports infrastructure: 1. New handling for i386 binary ports. 2. Cleanup: use ECHO_CMD and ECHO_MSG in bsd.port.mk properly. 3. Add a basic infrastructure support for debugging. 4. Installing ports with different destination (DESTDIR macro). 5. Cleanup: Move fetch shell scripts out of bsd.port.mk. 6. Make ports respect CC and CFLAGS. 7. Cross-compiling Ports. 8. Plist generator tool. The first three items have been completed and the next two items are being worked on. The DESTDIR support was more complicated than presumed and took more time than expected to complete. G=E1bor will continue working to finish these tasks and other ports related tasks. FreeBSD is happy to have interested him to keep working on ports and ports infrastructure. _________________________________________________________________ IPv6 Stack Vulnerabilities URL: http://wikitest.freebsd.org/ClementLecigne URL: http://pcs.sf.net Contact: George Neville-Neil Contact: Clement Lecigne The focus of this project was to review past vulnerabilities, create vulnerability testing tools and to discover new vulnerabilities in the FreeBSD IPv6 stack which is derived from the KAME project code. During the summer Clement took two libraries, the popular libnet, and his mentor's Packet Construction Set (PCS) and created tools to find security problems in the IPv6 code. Several issues were found, bugs filed, and patches created. At the moment Clement and George are editing a 50 page paper that describes the project which will be submitted for conference publication. All of the code from the project, including the tools, is on line and is described in the paper. By all measures, this was a successful project. Both student and mentor gained valuable insight into a previously externally maintained set of code. In addition to the new tools development in this effort, the FreeBSD Project has gained a new developer to help work on the code. _________________________________________________________________ iSCSI Initiator URL: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-17.5.tar.bz2=20 Contact: Damiel Braniss This iSCSI initiator kernel module and its companion control program are still under development, but the main parts are working. Open tasks: 1. Network Disconnect Recovery. 2. Sysctl Interface and Instrumentation. 3. Rewrite the userland side of iscontrol. _________________________________________________________________ Jail Resource Limits URL: http://wikitest.freebsd.org/JailResourceLimits Contact: Chris Jones Contact: Kip Macy We now have support for limiting CPU and memory use in jails. This allows fairer sharing of a systems' resources between divergent uses by preventing one jail from monopolizing the available memory and CPU time, if other users and jails have processes to run. The code is currently available as patches against RELENG_6, and Chris is in the process of applying it to -CURRENT. More details can be found at JailResourceLimits on the wiki. Open tasks: 1. Port patches against -CURRENT. _________________________________________________________________ Libelf URL: http://wiki.freebsd.org/LibElf URL: http://wiki.freebsd.org/PmcTools URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement/ Contact: Joseph Koshy Libelf is a BSD-licensed library for ELF parsing & manipulation implementing the SysV/SVR4 (g)ELF[3] API. Current status: Implementation of the library is nearly complete. A TET-based test suite for the API is being worked on. Open tasks: 1. Reviewers are needed for the code and the test suite. If you have extensions to the stock SysV/SVR4 ELF(3) API that you would like to see in -lelf, please send Joseph an email. _________________________________________________________________ MMC/SD Support Contact: Warner Losh Contact: Bernd Walter The MMC/SD stack got a significant boost this quarter. Warner Losh and Bernd Walter have written a generic MMC/SD flash card stack for FreeBSD, and have implemented a host controller for the AT91RM9200 embedded ARM controller they are each using in separate projects. The stack is presently experimental in quality. It is being used as the root file system for these embedded projects. There's been no work done to support hot insertion and removal of cards (neither board wires up the pins necessary, and besides, / disappearing is very bad). There are still many rough edges. This is a freshly written stack. It has been written using the SD 1.0 (and recently 2.0) simplified specification, with the SanDisk MMC application notes supplementing. The Linux stack looks good, although not entirely standards conforming (there's work in progress that I've not seen that is supposed to fix this) and it is contaminated with the GPL. The OpenBSD stack also looks interesting, but Warner's experience porting NEWCARD over from NetBSD suggested that a fresh rewrite may be faster, at least for the bus and driver level. Since MMC is fairly simple, a port of the sdhci driver might be possible. Please see the open tasks list. Open tasks: 1. Write sdhci driver, and integrate it into the current stack. 2. Add support for hot plugging of cards. 3. Add support for MMC cards (SD cards were the first target). 4. Expand SD support to include SDIO cards as well as the new SDHC standard cards. 5. Export stats via sysctl for each of the cards that are found as a debugging and usage monitoring aid. 6. Add support for reading/writing multiple blocks at a time to improve performance. 7. Implement any other host controller. 8. Add proper support for timeouts. _________________________________________________________________ Nss-LDAP importing and nsswitch subsystem improvement URL: http://wikitest.freebsd.org/MichaelBushkov URL: http://wikitest.freebsd.org/LdapCachedOriginalProposal URL: http://wikitest.freebsd.org/LdapCachedDetailedDescription Contact: Michael Bushkov Contact: Hajimu UMEMOTO The Project consisted of five parts: 1. Nsswitch modules and libc separation. The idea was to move the source code for different nsswitch sources (such as "files", "dns", "nis") out of the libc into the separate shared libraries. This task was successfully finished and the patch is available. 2. Regression tests for nsswitch. A set of regression tests to test the correctness of all nsswitch-related functions and the invariance of their behavior between system upgrades. The task can be considered successfully completed, the patch is available. 3. Rewriting nss_ldap. Though, this task was not clearly mentioned in the original proposal, during the SoC we found it would be easier, not to simply import PADL's nss_ldap, but to rewrite it from scratch (licensing issues were among the basic reasons for this). The resulting module behaves similarly to PADL's module, but has a different architecture that is more flexiable. Though it's basically finished, several useful features from the PADL's nss_ldap still need to be implemented. Despite the lack of some features, this task can be considered successfully completed. Missing features will be implemented as soon as possible, hopefully during September. 4. Importing nss_ldap into the Base System. The task was to prepare a patch, that will allow users to use nss_ldap from the base system. The task was successfully completed (the patch is available), but required importing OpenLDAP into the base in order for nss_ldap to work properly, and it had led to a long discussion in the mailing list. This discussion, however, have concluded with mostly positive opinions about nss_ldap and OpenLDAP importing. 5. Cached performance optimization. The caching daemon performance needs to be as high as possible in order for cached to be as close (in terms of speed) to "files" nsswitch source as possible. Cached's performance analysis was made and nsswitch database pre-caching was introduced as the optimization. This task was completed (the patch is available). However there is room for improvement. More precise and extensive performance analysis should be made and more optimizations need to be introduces. This will be done in the near future. Though none of the code was committed yet into the official FreeBSD tree, my experience from the previous year makes me think that this situation is normal. I hope, that the code will be reviewed and committed in the coming months. _________________________________________________________________ OCaml language support in ports URL: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ocaml/bsd. ocaml.mk?rev=3D1.3&content-type=3Dtext/plain Contact: Stanislav Sedov There were a number of OCaml ports in our tree, and each of them was doing the same work by maintaining OCaml ld.conf in the correct state, installing/removing their files/entries etc. To simplify the task of OCaml-language ports creationm the special framework (bsd.ocamk.mk) was developed and most of the ports was converted to use this framework. This allowed a lot of duplicate code to be removed. This new framework handles all the things required to install an OCaml-language library and properly register it. bsd.ocaml.mk also contains knobs to deal with findlib-powered libraries, modify ld.conf in the proper way, etc. Also, a lot of new Ocaml-related ports were added. _________________________________________________________________ OpenBSD dhclient Contact: Brooks Davis Most dhclient changes in HEAD have been merged to 6-STABLE for 6.2-RELEASE. The highlight of these changes is a fix for runaway dhclient processes when packets are not 4 byte aligned. Further changes including always sending client identifiers are scheduled for merge before the release. Work is ongoing to improve dhclient's interaction with alternate methods of setting interface addresses. _________________________________________________________________ Porting the seref policy and setools to SEBSD URL: http://wikitest.freebsd.org/DongmeiLiu Contact: Dongmei Liu Contact: Christian Peron Dongmei Liu spent the summer working on the basic footwork required to port the SEREF policy to SEBSD. This work has been submitted and can be viewed in the soc2006/dongmei_sebsd Perforce branch. This work was originated from the SEBSD branch: //depot/projects/trustedbsd/sebsd. Additionally setools-2.3 was ported from Linux and can be found in contrib/sebsd/setools directory. It is hoped that this work will be merged into the main SEBSD development branch. _________________________________________________________________ Porting Xen to FreeBSD URL: http://www.yuanjue.net/xen/howto.html URL: http://wikitest.freebsd.org/YuanJue Contact: Jue Yuan As a participant of Google's Summer of Code 2006, I am focusing on porting Xen to FreeBSD these months. The result of this summer's work include a domU kernel that could be used for installation, a guide for getting started with FreeBSD on Xen, and some other trivial improvements. But there are still a lot of work needing to be done in this area, e.g, the long-expeted dom0 support. So I will continue my work here and try to keep up with the update of Xen itself. Open tasks: 1. dom0 support is the most urgent _________________________________________________________________ Porting ZFS to FreeBSD URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/p= jd /zfs URL: http://www.opensolaris.org/os/community/zfs/porting/ URL: http://docs.freebsd.org/cgi/mid.cgi?20060822104516.GB16033 Contact: Pawel Jakub Dawidek My work is moving slowly forward. ZVOL is, I believe, fully functional (I recently fixed snapshots and clones on zvols), which means you can put UFS on top of RAID-Z volume, take a snapshot of the volume, clone it if needed, etc. Very cool. The hardest part is the ZPL layer, I'm still working on it. Most file system methods work, but probably need detailed review and many fixes. Most of the time these days I'm spending on implementing mmap(2) correctly. It works more or less in simple tests but fails under fsx program. On the other hand, 'fsx -RW' works very stable and reliable. Other test programs (those that don't use mmap(2)) also work quite well. There is still a lot of work to do, mostly in ZPL area, many clean-ups, etc. Some functionality (like ACLs) I haven't even tried to touch yet. _________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports / URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com/ Contact: Mark Linimon The ports PRs surged (especially due to a large number of new port submissions), but with some hard work we have been able to get back down to around 900. We are rapidly approaching 16,000 ports. Due to this acceleration in adding new ports, portmgr is now very concerned that we are outstripping the capacity of both the build infrastructure and our volunteers to keep up with build errors and port updates. Accordingly, we've added a guideline (not a rule) that ports should be of more than just theoretical use to be added to the Ports Collection (e.g. we can't support all of CPAN + all of Sourceforge + everything else). Basically, use common sense as a guideline; certainly no one wants to see any kind of "gateway" procedure to get incoming ports approved. Seven sets of changes have been added to the infrastructure, mostly refactoring and bugfixing. As part of a Summer of Code project, we have also incorporated some of gabor@'s changes to incorporate better DESTDIR support. However, due to some unanticipated side-effects, more work is going to be needed in this area. gabor@ is continuing to work on the changes. netchild@ and bsam@ have been doing a great deal of work to bring the linux emulator ports closer to sanity, including bringing up a regression-test suite. The long-anticipated import of X.Org 7 has stalled due to developer time, mostly to deal with documentation and upgrade instructions. Hopefully this can get done in the early 6.3 development cycle. See the wiki for more information. As a part of that work, the decision has been made to move away from using X11BASE and just put everything into LOCALBASE; /usr/X11R6 is simply an artifact at this point. A plan for a transition process is underway; a great deal of testing will need to be done, but in the end the ports tree will be much cleaner. The GNOME team has already done the work to move all of their ports over, and it will be incorporated after the 6.2 release is shipped. tmclaugh@ is looking for someone to take over the C# ports. He has maintained them for over a year and wants more time to be able to work on other projects. Some work has been done to get rid of FreeBSD 2.X cruft in ports. Further work is needed to get the 3.X cruft removed. linimon@ did another pass through resetting inactive maintainers. Another list is waiting in the wings. linimon@ is also working on adding the ability for portsmon to analyze successful packages (not just failed ones), so that queries such as "show me packages that build on i386 but not amd64" and "show me why dependent package foo was not built on bar". This is currently in alpha testing. We have added 4 new committers since the last report. Open tasks: 1. We still need help getting back to our modern low of 500 PRs. 2. We have nearly 4400 unmaintained ports (see, for instance, the list on portsmon ). Although there has been a welcome upsurge in new maintainers recently which has dropped the percentage down below 28%, we still need much more help. 3. A test run of gcc4.1 on the ports tree showed around 1000 new build errors. Kris@ has posted some results so that people can start working on the problems now. In particular, it seems that certain older versions of GCC cannot be built with GCC 4.1, so ports that depend on those older versions are going to have to be fixed as well. Although the import of GCC 4.1 to -CURRENT is not imminent, the time to start planning is now. 4. The state of the packages on AMD64 and sparc64 significantly lags that of i386. In many of these cases, packages are not attempted because NOT_FOR_ARCH is used instead of more accurately only setting BROKEN based on ARCH. (pointyhat can be forced to build packages that are marked BROKEN, but not NOT_FOR_ARCH). NOT_FOR_ARCH is supposed to denote only "will never work on this ARCH". Although we have volunteers who have expressed interest in sparc64 (and ia64), we need more people who are running amd64 (especially as a desktop) to help us get more packages working. _________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ URL: http://www.FreeBSD.org/releases/ URL: http://www.FreeBSD.org/snapshots/ Contact: Release Engineering Team The FreeBSD Release Engineering team is currently working on FreeBSD 6.2-RELEASE, which is scheduled for release in early November 2006. Some notable features of this release include the debut of security event auditing as an experimental feature, Xbox support, the FreeBSD Update binary updating utility, and of course many fixes and updates for existing programs. Pre-release images for all Tier-1 architectures are available for testing now; feedback on these builds is greatly appreciated. More information about release engineering activities can be found at the links above. _________________________________________________________________ SCTP Integration URL: http://www.sctp.org/ Contact: Randall Stewart Contact: George Neville-Neil There are currently patches available for testing. A planned integration to HEAD is set to happen in October. Open tasks: 1. The code still needs plenty of testing. See patches on sctp.org and in -CURRENT soon. _________________________________________________________________ SNMP monitoring (BSNMP) URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/s= oc %2dshteryana/bsnmp&HIDEDEL=3DNOe URL: http://wikitest.freebsd.org/CategorySNMP URL: http://wiki.freebsd.org/SnmpBridgeModule URL: http://www.freshports.org/net-mgmt/bsnmptools/ Contact: Shteryana Shopova Contact: Bjoern A. Zeeb A BRIDGE monitoring module for FreeBSD's BSNMP daemon has been implemented. In addition to RFC 4188 single bridge support and extending the kernel to get access to all the information, a private MIB was designed in order to be able to monitor multiple bridges supported by FreeBSD. The kernel part has already been committed to -CURRENT (thanks to thompsa@), for -STABLE a patch is available (see the wiki), code has already been reviewed. SoC 2005 work on SNMP client tools is now available too via port (net-mgmt/bsnmptools), thanks to Andrew Pantyukhin for the port. Open tasks: 1. More testing is very welcome. 2. if_vlan(4) monitoring module. 3. jail(8) monitoring module. _________________________________________________________________ Sound Subsystem Improvements URL: http://people.FreeBSD.org/~ariff/ URL: http://www.FreeBSD.org/projects/ideas/ URL: http://wiki.FreeBSD.org/soundsystem Contact: Ariff Abdullah Contact: Alexander Leidinger Contact: Ryan Beasley Contact: Multimedia Mailinglist Since the last status report we added basic support for envy24ht chips, imported the emu10kx driver into the base system and added support for High Definition Audio (HDA) compatible chips. Additionally the work of Ryan Beasley as part of his Google Summer of Code 2006 participation is committed. It adds compatibility to the Open Sound System (OSS) v4 API as far as this was possible. This allows for more sophisticated programs to be written. For example it is now possible to synchronize the start of multiple sound channels. It is also possible for a driver to support more than the AC97 mixer devices, but so far no driver has been extended to support this yet. More about it can be found in the wiki and in the official OSS documentation. The wiki page about the sound system was started to describe the current status of the sound system and to provide some information about where we are heading. But more work needs to be done to reach this goal. So far we collected some information about the status of the most recent work in the soundsystem. So if you have a look at it and you think that something important is missing, just tell us about it. While fully prepared content is very welcome, we are even happy about some ideas what we should list on the wiki page. Open tasks: 1. Have a look at the sound related entries on the ideas list. 2. sndctl(1): tool to control non-mixer parts of the sound system (e.g. spdif switching, virtual-3D effects) by an user (instead of the sysctl approach in -current); pcmplay(1), pcmrec(1), pcmutil(1). 3. Plugable FEEDER infrastructure. For ease of debugging various feeder stuff and/or as userland library and test suite. 4. Extend the wiki page. _________________________________________________________________ Summer of Code Summary URL: http://www.FreeBSD.org/projects/summerofcode-2006.html URL: http://wikitest.freebsd.org/SummerOfCode2006 URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projec= ts /soc2006/ Contact: Murray Stokely We had another successful summer taking part in the Google Summer of Code. By all accounts, the FreeBSD participation in this program was an unqualified success. We received over 150 applications for student projects, amongst which 13 were selected for funding. All successful students received the full $4,500. These student projects included security research, improved installation tools, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program. At least 2 of our FreeBSD mentors will be meeting with Google organizers in Mountain View this month to discuss the program at the Mentor Summit. _________________________________________________________________ Summer of FreeBSD security development URL: http://people.freebsd.org/~cperciva/funding.html URL: http://www.daemonology.net/freebsd-upgrade-6.0-to-6.1/ Contact: Colin Percival I spent the months of May through August working on improving Portsnap, FreeBSD Update, and devoting more time to my (continuing) role as Security Officer. FreeBSD Update is now part of the FreeBSD base system and is fully supported by the FreeBSD Security Team; updates are currently only being built for the i386 architecture, but AMD64 updates will become available soon. In an attempt to reduce the number of people running out of date (and unsupported) FreeBSD releases, I wrote an automatic binary upgrade script for upgrading systems from FreeBSD 6.0 to FreeBSD 6.1; I will be releasing a new script for upgrading to FreeBSD 6.2-(RC*|RELEASE) soon (possibly before this status report is published). Further improvements to Portsnap are still ongoing. _________________________________________________________________ Sun Niagara port Contact: Kip Macy Support for the UltraSparc T1 (Niagara) continues to improve. The code has recently been checked into public CVS under sys/sun4v. It isn't clear whether or not I will have time to implement full logical domaining support before the APIs become publicly available. Testing indicates that substantial work will be needed before FreeBSD can take full advantage of all 32 threads. Open tasks: 1. Random testing and bug fixes. 2. Import and extend improved mutex profiling support. 3. Virtual network and virtual disk device drivers for logical domains. _________________________________________________________________ The FreeBSD Foundation URL: http://www.freebsdfoundation.org Contact: Deb Goodkin The FreeBSD Foundation continued to support the FreeBSD project and community through various activities. These activities include creating strategies for fund development and actively seeking funding for the FreeBSD community, coordinating a new IBM Bladeserver project, and protecting the image and integrity of FreeBSD by governing the use of the trademarks. We are pleased to be a sponsor of EuroBSDCon and will be sponsoring a few developers to attend the conference through our travel grant program. And finally, we have secured funds for a major project that will be announced later this month. _________________________________________________________________ TrustedBSD Audit URL: http://www.TrustedBSD.org/audit.html URL: http://www.OpenBSM.org/ Contact: Robert Watson Contact: Christian Peron Contact: Wayne Salamon The TrustedBSD audit implementation provides fine-grained security event logging throughout the FreeBSD operating system. The big news for the last quarter is that the TrustedBSD audit implementation has been merged into RELENG_6 branch, and appeared in 6.2-BETA2. Over the past few months, work has also occurred in the following areas: * OpenBSM 1.0 alpha 8 through alpha 12 have been released and merged into FreeBSD CVS. Changes include significant numbers of bug fixes, documentation improvements, and feature enhancements. These include regular expression based matching for auditreduce, auditd management of kernel audit policy (such as maximum trail file size), improvements in printing support for a variety of tokens including execve argument support. * Significant enhancements to the FreeBSD Handbook chapter on Audit. * Full audit support for execve events, including optional auditing of command line arguments and environmental variables, as well as audit support for a broad range of other additional kernel events. * Kqueue support for audit pipes. * Robustness improvements in the presence of low disk space conditions. * Support for system call capture on additional platforms, such as ppc and ia64. * Improved support for very large audit record sizes (as required for extensive execve support). * id(1) now supports a -A argument to query audit state for the process. * An audit_warn(5) event for trail rotation, which can be used for archiving, reduction, and other administrative activities. Lots of testing as part of the 6.2-BETA cycle would be much appreciated. Audit support will be considered an experimental feature in FreeBSD 6.2-RELEASE, but we hope that it will be a production feature in 6.3-RELEASE. Open tasks: 1. Continue expanding auditing of syscall arguments. 2. Continue expanding auditing of administrative tools. 3. More testing! 4. Continue to explore improvements of the administrative model for audit trails, etc. _________________________________________________________________ TSO - TCP Segmentation Offload committed URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/068524.html URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/068610.html URL: http://lists.freebsd.org/pipermail/cvs-src/2006-September/069493.html Contact: Andre Oppermann TSO - TCP Segmentation Offload support has been committed to the network stack of FreeBSD-current in September 2006. With TSO, TCP can send data in the send socket buffer in bulk down to the network card which then does the splitting into MTU sized packets. On bulk high speed sending the performance is increased by 25% (normal writes) to 108% (sendfile). Jack Vogel and Prafulla Deuskar of Intel committed the driver changes for TSO hardware support of em(4) based network cards. These changes are scheduled to be backported to FreeBSD 6-STABLE shortly after FreeBSD 6.2-RELEASE is published to appear in upcoming FreeBSD 6.3 early next year. This work was sponsored by the TCP/IP Optimization Fundraiser 2005. Open tasks: _________________________________________________________________ Update of the Linux compatibility environment in the kernel URL: http://wiki.FreeBSD.org/linux-kernel Contact: Alexander Leidinger Contact: Roman Divacky Contact: Emulation Mailinglist Roman Divacky participated in the Google Summer of Code 2006 and implemented a major part of the syscall compatibility to the 2.6.16 Linux kernel. The work has been committed to -CURRENT (the default compatibility still being a 2.4.2 Linux kernel) and we are working on fixing the remaining bugs as time permits. "Intron" submitted an implementation for the linux aio syscalls. His work has been committed to the Perforce repository. We also started to consolidate a list of known bugs, open issues and helpful stuff (e.g. regression tests and their status) in -CURRENT on a page in the FreeBSD wiki (see the links-section). It also contains a link to a more or less up-to-date patch with stuff we have in the Perforce repository so that interested people can help with testing. Thanks to the help of Marcin Cieslak we already fixed some bugs (some of the fixes are already MFCed to -STABLE). Thanks to the nice regression tests of the Linux Test Project (LTP) we have a list of small (and not so small) things which need to be looked at. This list makes up for a quick start into kernel hacking. So if you have a little bit of knowledge about C programming, and if you want to help us a little bit in improving FreeBSD, feel free to have a look at the list and to try to fix a problem or two. Sometimes it is as easy as "if (error condition) return Esomething;" (but you should coordinate with the emulation mailinglist, so that nobody does some work someone else just did too). Even if you do not know how to program, you can help. Have a look at the wiki page and tell us about things which should get mentioned there too. Or download the patch and test it. _________________________________________________________________ USB URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projec= ts /usb/src/sys/dev/usb&HIDEDEL=3DNO URL: http://www.turbocat.net/~hselasky/usb4bsd Contact: Hans Petter Sirevaag Selasky During the last three months I have finished reworking nearly all USB device drivers found in FreeBSD-7-CURRENT. Only two USB drivers are left and that is ubser(4) and slhci. Some still use Giant, but most have been brought out of Giant. At the moment I am looking for testers that can test the various USB device drivers. Some have already been tested, and confirmed to work, while others have problems which need to be fixed. If you want to test, checkout the USB perforce tree or download the SVN version of the USB driver that is available on my homepage. At the moment the tarballs are a little out of date. Ideas and comments with regard to the new USB API are welcome at: freebsd-usb@freebsd.org. _________________________________________________________________ Xen Port Contact: Kip Macy Work on Xen support has slowly been continuing in perforce. The SOC student fixed several bugs and is continuing to work on it. Someone is needed who has the time to complete dom0 support and shepherd it production level stability. Sufficient interest has been expressed in it that it probably makes sense to check it in to public CVS so that more people can try it out. Time permitting, I will bring it up to date and check it in the next month. Open tasks: 1. dom0 support. 2. General testing and bug fixing. _________________________________________________________________ News Home | Status Home Legal Notices | =A9 1995-2006 The FreeBSD Project. All rights reserved= _______________________________________________ freebsd-announce@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-announce To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.or= g" From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 14:53:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D4D16A412 for ; Thu, 19 Oct 2006 14:53:42 +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 C481943D46 for ; Thu, 19 Oct 2006 14:53:41 +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 k9JErWN6066690; Thu, 19 Oct 2006 10:53:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 19 Oct 2006 10:09:52 -0400 User-Agent: KMail/1.9.1 References: <5e4707340608181226u131be51ak547c5912a35cfcec@mail.gmail.com> In-Reply-To: <5e4707340608181226u131be51ak547c5912a35cfcec@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610191009.53148.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]); Thu, 19 Oct 2006 10:53:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2050/Thu Oct 19 03:58:33 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: Alex Unleashed Subject: Re: devfs deadlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 14:53:43 -0000 On Friday 18 August 2006 15:26, Alex Unleashed wrote: > Hello, > > Before anything else I'd like to say I'm working on a SoC project for > Gentoo for which I have to port a sandbox-like application wrapper (in > userspace) to FreeBSD, which deals with the building and installing of > software so that nothing gets screwed in the filesystem. It's > finished, but unfortunately it gets frozen at random points, > preventing the system from launching new programs or saving to disk, > which suggested a kernel bug, as was later confirmed looking at the > waitchannels and debugging. I know there is someone working out issues > in devfs code in 6.x, so this might also be interesting to him. > > I've been able to reproduce both in 6.1-RELEASE-p3 and 6-STABLE > (snapshot from August 16th ~01:00 GMT) a deadlock in devfs code which > leaves the system unable to access the disk. I've come up with some > interesting debugging info, and it looks to me like there are vnode > problems while a sx lock is being held. > > My take at it is that the deadlock occurs when a process gets a lock > on a vnode (tagged "devfs") and another process xlocks an sx lock > ("devfsmount"). For some reason the one holding the sx lock wants to > get the lock on the vnode through devfs_allocv(), and the other > process wants to get the sx lock through devfs_lookup(). From this > point on, pretty much anything wanting to touch the filesystem waits > forever on devfs_root() for another vnode flagged as VV_ROOT and > locked by the process holding the sx lock. > > Patching the devfs code with fixes from -CURRENT didn't work out. This deadlock is fixed in current as of this: kib 2006-09-18 13:23:08 UTC FreeBSD src repository Modified files: sys/fs/devfs devfs.h devfs_devs.c devfs_vfsops.c devfs_vnops.c Log: Resolve the devfs deadlock caused by LOR between devfs_mount->dm_lock and vnode lock in devfs_allocv. Do this by temporary dropping dm_lock around vnode locking. For safe operation, add hold counters for both devfs_mount and devfs_dirent, and DE_DOOMED flag for devfs_dirent. The facilities allow to continue after dropping of the dm_lock, by making sure that referenced memory does not disappear. Reviewed by: tegge Tested by: kris Approved by: kan (mentor) PR: kern/102335 Revision Changes Path 1.30 +11 -0 src/sys/fs/devfs/devfs.h 1.47 +12 -1 src/sys/fs/devfs/devfs_devs.c 1.51 +20 -4 src/sys/fs/devfs/devfs_vfsops.c 1.134 +70 -11 src/sys/fs/devfs/devfs_vnops.c and kib 2006-09-19 14:03:02 UTC FreeBSD src repository Modified files: sys/fs/devfs devfs_vnops.c Log: Fix the bug in rev. 1.134. In devfs_allocv_drop_refs(), when not_found == 2 and drop_dm_lock is true, no unlocking shall be attempted. The lock is already dropped and memory is freed. Found with: Coverity Prevent(tm) CID: 1536 Approved by: pjd (mentor) Revision Changes Path 1.135 +1 -1 src/sys/fs/devfs/devfs_vnops.c -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 19 20:02:49 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9F9916A403 for ; Thu, 19 Oct 2006 20:02:49 +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 AE09543D4C for ; Thu, 19 Oct 2006 20:02:47 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gae6H-000JlE-KE; Thu, 19 Oct 2006 21:02:45 +0100 Date: Thu, 19 Oct 2006 21:02:45 +0100 From: Ceri Davies To: Max Laier Message-ID: <20061019200245.GI92966@submonkey.net> Mail-Followup-To: Ceri Davies , Max Laier , hackers@freebsd.org, danny@cs.huji.ac.il References: <20061018223512.GA89117@submonkey.net> <200610190214.47815.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+JUInw4efm7IfTNU" Content-Disposition: inline In-Reply-To: <200610190214.47815.max@love2party.net> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: hackers@freebsd.org Subject: Re: Where was that iSCSI initiator? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 20:02:49 -0000 --+JUInw4efm7IfTNU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 19, 2006 at 02:14:41AM +0200, Max Laier wrote: > On Thursday 19 October 2006 00:35, Ceri Davies wrote: > > Could anyone please let me know the status of the iSCSI initiator that > > was floated here some time ago? Is it in a commitable state and, if > > not, can I help with testing (we have some Netware targets)? >=20 > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-17.5.tar.bz2 is that th= e=20 > one you were thinking about? That's the one. Thanks, Max. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --+JUInw4efm7IfTNU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFN9nlocfcwTS3JF8RAgv4AJ0fQ52sNX59keOVeF1QV5y4JbIJ8ACePOah 6NIp8coIQdhrKw5agsjzCqQ= =pInu -----END PGP SIGNATURE----- --+JUInw4efm7IfTNU-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 10:56:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D877916A412 for ; Fri, 20 Oct 2006 10:56:14 +0000 (UTC) (envelope-from kpielorz@tdx.co.uk) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [62.13.130.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D5643D45 for ; Fri, 20 Oct 2006 10:56:13 +0000 (GMT) (envelope-from kpielorz@tdx.co.uk) Received: from Unsupported (thebrick.dmpriest.net.uk [62.13.130.30]) by caladan.tdx.co.uk (8.13.6/8.13.6/Kp) with ESMTP id k9KAuCDm095058 for ; Fri, 20 Oct 2006 11:56:12 +0100 (BST) Date: Fri, 20 Oct 2006 11:56:33 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 10:56:14 -0000 Hi All, We've got an HP DL380 server, stacked out with drives running Sendmail. The machine is quite busy (LA rarely below 4 - and it's three 'spindle' sets of RAID drives are always busy). It's probably constantly running 200-300 copies of sendmail, plus an assortment of other processes (mostly admin scripts that kind of thing). It's got a Xeon 3.2Ghz CPU (HT disabled), w/2Gb of RAM running a generic kernel, w/out IPv6 support (and with DDB/KDB included obviously) This machine just 'hangs' every couple of days. I have DDB/KDB compiled in - and if I throw it into DDB I get the following: [first couple of lines missed courtesy of screen-dump] db> bt Tracing pid 38 tid 100027 td 0xc6495180 acpi_timer_read(c0aba3c0,c09035c0,e6a05bbc,c0662ef3,c0aba3c0) at acpi_timer_read+0x13 acpi_timer_get_timecout_safe(c0aba3c0) at acpi_timer_get_timecount_safe+0xa binuptime(e6a05be8) at binuptime+0x43 mi_switch(6,c6395900,c639a54,c639500,e6a05c34) at mi_swtich+0x33 maybe_preempt(c6395900) at maybe_preempt+0xc4 sched_add(c639500,4,c6495180,c6395900,c637f280) at sched_add+0x27 setrunqueue(c6395900,4) at setrunqueue+0x63 intr_even_schedule_thread(c637f280) at intr_event_schedule_thread+0xb5 intr_exectue_handlers(c638d6e0,e6a05cac,13,46a05cf4,c08189f3) at intr_execute_handlers+0x118 ... I have a crash dump from it - which I've saved (I'm moderately familiar with working with dumps, but this one is split into two?) If anyone has any pointers, or can do some hand holding to get more info from the dump, or what to do next time it happens? Cheers, -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 11:02:05 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E49BD16A415 for ; Fri, 20 Oct 2006 11:02:05 +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 D6D4143D6D for ; Fri, 20 Oct 2006 11:01:56 +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 k9KAl9Xt089854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Oct 2006 13:47:09 +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 k9KB1qqu002584; Fri, 20 Oct 2006 14:01:52 +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 k9KB1pdK002583; Fri, 20 Oct 2006 14:01:51 +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: Fri, 20 Oct 2006 14:01:51 +0300 From: Kostik Belousov To: Karl Pielorz Message-ID: <20061020110151.GU55428@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XAEV7zm15O60d1Zf" Content-Disposition: inline In-Reply-To: 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: freebsd-hackers@freebsd.org Subject: Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 11:02:06 -0000 --XAEV7zm15O60d1Zf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2006 at 11:56:33AM +0100, Karl Pielorz wrote: >=20 > I have a crash dump from it - which I've saved (I'm moderately familiar= =20 > with working with dumps, but this one is split into two?) >=20 > If anyone has any pointers, or can do some hand holding to get more info= =20 > from the dump, or what to do next time it happens? See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html --XAEV7zm15O60d1Zf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOKyfC3+MBN1Mb4gRAr1nAKCmaDzsWqtyQzMRZhsx8O/jRwJTogCgg8BP 28RfnmeUAodyGgWJUybuGBA= =mAKg -----END PGP SIGNATURE----- --XAEV7zm15O60d1Zf-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 11:09:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E98FC16A47B for ; Fri, 20 Oct 2006 11:09:00 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mailhost.graphdata.co.uk (mailhost.graphdata.co.uk [195.12.22.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C181E43D58 for ; Fri, 20 Oct 2006 11:08:55 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mailhost.graphdata.co.uk (Postfix) with ESMTP id D752411405B for ; Fri, 20 Oct 2006 12:08:51 +0100 (BST) X-Virus-Scanned: amavisd-new at graphdata.co.uk Received: from mailhost.graphdata.co.uk ([127.0.0.1]) by localhost (mailhost.graphdata.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG56ge9sZH1C for ; Fri, 20 Oct 2006 12:08:49 +0100 (BST) Received: from gdc083.internal.graphdata.co.uk (gdc083.internal.graphdata.co.uk [192.168.0.86]) by mailhost.graphdata.co.uk (Postfix) with SMTP id 73E9A11401E for ; Fri, 20 Oct 2006 12:08:49 +0100 (BST) Date: Fri, 20 Oct 2006 12:08:49 +0100 From: Dominic Marks To: freebsd-hackers@freebsd.org Message-Id: <20061020120849.8ab1e2f9.dom@helenmarks.co.uk> In-Reply-To: References: X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 11:09:01 -0000 On Fri, 20 Oct 2006 11:56:33 +0100 Karl Pielorz wrote: > > Hi All, > > We've got an HP DL380 server, stacked out with drives running Sendmail. The > machine is quite busy (LA rarely below 4 - and it's three 'spindle' sets of > RAID drives are always busy). It's probably constantly running 200-300 > copies of sendmail, plus an assortment of other processes (mostly admin > scripts that kind of thing). > > It's got a Xeon 3.2Ghz CPU (HT disabled), w/2Gb of RAM running a generic > kernel, w/out IPv6 support (and with DDB/KDB included obviously) > > This machine just 'hangs' every couple of days. I have DDB/KDB compiled in > - and if I throw it into DDB I get the following: > > [first couple of lines missed courtesy of screen-dump] > db> bt > Tracing pid 38 tid 100027 td 0xc6495180 > acpi_timer_read(c0aba3c0,c09035c0,e6a05bbc,c0662ef3,c0aba3c0) at > acpi_timer_read+0x13 > acpi_timer_get_timecout_safe(c0aba3c0) at acpi_timer_get_timecount_safe+0xa > binuptime(e6a05be8) at binuptime+0x43 > mi_switch(6,c6395900,c639a54,c639500,e6a05c34) at mi_swtich+0x33 > maybe_preempt(c6395900) at maybe_preempt+0xc4 > sched_add(c639500,4,c6495180,c6395900,c637f280) at sched_add+0x27 > setrunqueue(c6395900,4) at setrunqueue+0x63 > intr_even_schedule_thread(c637f280) at intr_event_schedule_thread+0xb5 > intr_exectue_handlers(c638d6e0,e6a05cac,13,46a05cf4,c08189f3) at > intr_execute_handlers+0x118 > ... > > I have a crash dump from it - which I've saved (I'm moderately familiar > with working with dumps, but this one is split into two?) > > If anyone has any pointers, or can do some hand holding to get more info > from the dump, or what to do next time it happens? Have you tried changing kern.timecounter.hardware to something else? TSC? Dominic From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 11:50:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D31A16A412 for ; Fri, 20 Oct 2006 11:50:25 +0000 (UTC) (envelope-from kpielorz@tdx.co.uk) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [62.13.130.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F84743D55 for ; Fri, 20 Oct 2006 11:50:13 +0000 (GMT) (envelope-from kpielorz@tdx.co.uk) Received: from Unsupported (thebrick.dmpriest.net.uk [62.13.130.30]) by caladan.tdx.co.uk (8.13.6/8.13.6/Kp) with ESMTP id k9KBoCgT095641; Fri, 20 Oct 2006 12:50:12 +0100 (BST) Date: Fri, 20 Oct 2006 12:50:33 +0100 From: Karl Pielorz To: Kostik Belousov Message-ID: <82C14B40C9061504218D7585@Unsupported> In-Reply-To: <20061020110151.GU55428@deviant.kiev.zoral.com.ua> References: <20061020110151.GU55428@deviant.kiev.zoral.com.ua> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 11:50:25 -0000 --On 20 October 2006 14:01 +0300 Kostik Belousov wrote: > On Fri, Oct 20, 2006 at 11:56:33AM +0100, Karl Pielorz wrote: >> >> I have a crash dump from it - which I've saved (I'm moderately familiar >> with working with dumps, but this one is split into two?) >> >> If anyone has any pointers, or can do some hand holding to get more info >> from the dump, or what to do next time it happens? > > See > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern > eldebug-deadlocks.html Thanks for the link! Anyone know much is all that lot (such as INVARIANTS/WITNESS) etc. likely to slow the machine down? - A few percent? More? I'm just a little hesitant to put it all in, and end up with a machine that's 80% slower :( -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 12:19:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F15E16A412 for ; Fri, 20 Oct 2006 12:19:08 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ADC043D46 for ; Fri, 20 Oct 2006 12:19:07 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GatL7-0004Gz-PJ for freebsd-hackers@freebsd.org; Fri, 20 Oct 2006 14:19:05 +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, 20 Oct 2006 14:19:05 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 14:19:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 20 Oct 2006 14:18:57 +0200 Lines: 14 Message-ID: References: <20061020110151.GU55428@deviant.kiev.zoral.com.ua> <82C14B40C9061504218D7585@Unsupported> 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: <82C14B40C9061504218D7585@Unsupported> Sender: news Subject: Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 12:19:08 -0000 Karl Pielorz wrote: > Thanks for the link! Anyone know much is all that lot (such as > INVARIANTS/WITNESS) etc. likely to slow the machine down? - A few > percent? More? Huge. See http://wikitest.freebsd.org/WitnessPerformance > > I'm just a little hesitant to put it all in, and end up with a machine > that's 80% slower :( Try switching timecounter to TSC, and keep an eye on ntpd to see if your time drifts too much. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 12:47:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05C016A403 for ; Fri, 20 Oct 2006 12:47:37 +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 7A7C643D4C for ; Fri, 20 Oct 2006 12:47:37 +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 185F046DA6; Fri, 20 Oct 2006 08:47:37 -0400 (EDT) Date: Fri, 20 Oct 2006 13:47:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karl Pielorz In-Reply-To: <82C14B40C9061504218D7585@Unsupported> Message-ID: <20061020134552.H38852@fledge.watson.org> References: <20061020110151.GU55428@deviant.kiev.zoral.com.ua> <82C14B40C9061504218D7585@Unsupported> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 12:47:38 -0000 On Fri, 20 Oct 2006, Karl Pielorz wrote: >> On Fri, Oct 20, 2006 at 11:56:33AM +0100, Karl Pielorz wrote: >>> >>> I have a crash dump from it - which I've saved (I'm moderately familiar >>> with working with dumps, but this one is split into two?) >>> >>> If anyone has any pointers, or can do some hand holding to get more info >>> from the dump, or what to do next time it happens? >> >> See >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern >> eldebug-deadlocks.html > > Thanks for the link! Anyone know much is all that lot (such as > INVARIANTS/WITNESS) etc. likely to slow the machine down? - A few percent? > More? > > I'm just a little hesitant to put it all in, and end up with a machine > that's 80% slower :( Depends a lot on your workload. WITNESS used to really, really slow things down for kernel lock intensive workloads (VFS especially); now it just really slows things down. INVARIANTS overhead is generally measurable, but for most workloads it is likely <20%. The place INVARIANTS hits you is when the kernel is allocating and freeing lots of memory, during which INVARIANTS will be scrubbing and checking for use after free, etc. It's worth running with WITNESS when debugging deadlocks if possible, because it is, essentially, a deadlock debugging tool. A moderate number of people run with INVARIANTS in production, but you generally don't want to do that with WITNESS. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 15:08:01 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2EFE16A47B for ; Fri, 20 Oct 2006 15:08:01 +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 5550D43D53 for ; Fri, 20 Oct 2006 15:08:01 +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 6C29C75C62 for ; Fri, 20 Oct 2006 17:08:00 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 49ACE9E6C2 for ; Fri, 20 Oct 2006 15:08:48 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3A486405B; Fri, 20 Oct 2006 17:08:48 +0200 (CEST) Date: Fri, 20 Oct 2006 17:08:48 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20061020150848.GQ53114@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: src.conf(5) seems to affect ports build X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 15:08:02 -0000 Hi, src.conf(5) manual page states: % The src.conf file contains settings that will apply to every build % involving the FreeBSD source tree; see build(7). % ... % The only purpose of src.conf is to control the compilation of the FreeBSD % sources, which are usually found in /usr/src. However, share/mk/bsd.port.mk includes which in turn includes /etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it which affects CFLAGS, they will be taken into account even for port builds. Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid modifying CFLAGS (though I think this might become useful in the near future). Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 19:13:53 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1762216A403 for ; Fri, 20 Oct 2006 19:13:53 +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 C4E1843D5C for ; Fri, 20 Oct 2006 19:13:47 +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 6BB7B62C5; Fri, 20 Oct 2006 23:13:45 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 94F2A625E; Fri, 20 Oct 2006 23:13:28 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9KJDWCj060151; Fri, 20 Oct 2006 23:13:32 +0400 (MSD) (envelope-from ru) Date: Fri, 20 Oct 2006 23:13:32 +0400 From: Ruslan Ermilov To: Jeremie Le Hen Message-ID: <20061020191332.GC59856@rambler-co.ru> References: <20061020150848.GQ53114@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5Mfx4RzfBqgnTE/w" Content-Disposition: inline In-Reply-To: <20061020150848.GQ53114@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-hackers@FreeBSD.org Subject: Re: src.conf(5) seems to affect ports build X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 19:13:53 -0000 --5Mfx4RzfBqgnTE/w Content-Type: multipart/mixed; boundary="VUDLurXRWRKrGuMn" Content-Disposition: inline --VUDLurXRWRKrGuMn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote: > Hi, >=20 > src.conf(5) manual page states: >=20 > % The src.conf file contains settings that will apply to every build > % involving the FreeBSD source tree; see build(7). > % ... > % The only purpose of src.conf is to control the compilation of the FreeB= SD > % sources, which are usually found in /usr/src. >=20 > However, share/mk/bsd.port.mk includes which in turn includes > /etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it > which affects CFLAGS, they will be taken into account even for port build= s. >=20 > Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid > modifying CFLAGS (though I think this might become useful in the near > future). >=20 See if the attached patch helps. If it does, I'll commit. I've never heard back on this patch after I sent it to obrien@. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --VUDLurXRWRKrGuMn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Content-Transfer-Encoding: quoted-printable Index: bsd.own.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/share/mk/bsd.own.mk,v retrieving revision 1.57 diff -u -p -r1.57 bsd.own.mk --- bsd.own.mk 30 Sep 2006 11:32:46 -0000 1.57 +++ bsd.own.mk 30 Sep 2006 20:31:16 -0000 @@ -104,10 +104,12 @@ .if !target(____) ____: =20 +.if !defined(_WITHOUT_SRCCONF) SRCCONF?=3D /etc/src.conf .if exists(${SRCCONF}) .include "${SRCCONF}" .endif +.endif =20 # Binaries BINOWN?=3D root @@ -170,6 +172,7 @@ STRIP?=3D -s COMPRESS_CMD?=3D gzip -cn COMPRESS_EXT?=3D .gz =20 +.if !defined(_WITHOUT_SRCCONF) # # Define MK_* variables (which are either "yes" or "no") for users # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the @@ -447,5 +450,6 @@ MK_${var}_SUPPORT:=3D no MK_${var}_SUPPORT:=3D yes .endif .endfor +.endif # !_WITHOUT_SRCCONF =20 .endif # !target(____) Index: bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/share/mk/bsd.port.mk,v retrieving revision 1.308 diff -u -p -r1.308 bsd.port.mk --- bsd.port.mk 24 Aug 2006 18:04:49 -0000 1.308 +++ bsd.port.mk 26 Aug 2006 13:55:59 -0000 @@ -3,8 +3,9 @@ PORTSDIR?=3D /usr/ports BSDPORTMK?=3D ${PORTSDIR}/Mk/bsd.port.mk =20 -# Needed to keep bsd.own.mk from reading in /etc/src.conf when building po= rts. -SRCCONF=3D /dev/null +# Needed to keep bsd.own.mk from reading in /etc/src.conf +# and setting MK_* variables when building ports. +_WITHOUT_SRCCONF=3D =20 .include .include "${BSDPORTMK}" --VUDLurXRWRKrGuMn-- --5Mfx4RzfBqgnTE/w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOR/cqRfpzJluFF4RAsvzAKCIAwd+jNts1htDjUnIF0S0cvZ9PQCeOZZN JI2jg4o3JycW6uJkggYaJOg= =zTXx -----END PGP SIGNATURE----- --5Mfx4RzfBqgnTE/w-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 21:25:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 696C616A416; Fri, 20 Oct 2006 21:25:50 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A6EF43D72; Fri, 20 Oct 2006 21:25:02 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (h1yw8kzrn8sznd5b@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k9KLP1id028102; Fri, 20 Oct 2006 14:25:01 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k9KLOwYS028094; Fri, 20 Oct 2006 14:24:58 -0700 (PDT) (envelope-from jmg) Date: Fri, 20 Oct 2006 14:24:57 -0700 From: John-Mark Gurney To: David Xu Message-ID: <20061020212457.GQ23971@funkthat.com> Mail-Followup-To: David Xu , Divacky Roman , freebsd-hackers@freebsd.org, Ekkehard Morgenstern References: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <20061016120859.E146C2287D@snail.stack.nl> <20061017081056.GA73188@stud.fit.vutbr.cz> <200610171717.30834.davidxu@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610171717.30834.davidxu@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org, Divacky Roman , Ekkehard Morgenstern Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 21:25:50 -0000 David Xu wrote this message on Tue, Oct 17, 2006 at 17:17 +0800: > work in the past. Also rfork() does not allow you to specify user stack, you > have to add some tricky code to make it safe before new > thread really can do real work, [...] That's why you use rfork_thread(3)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 21:37:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E8F216A4D2 for ; Fri, 20 Oct 2006 21:37:25 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B5D043E0F for ; Fri, 20 Oct 2006 21:35:10 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (jt36ko66jxmi8ps8@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k9KLYr7H028248; Fri, 20 Oct 2006 14:34:53 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k9KLYriD028247; Fri, 20 Oct 2006 14:34:53 -0700 (PDT) (envelope-from jmg) Date: Fri, 20 Oct 2006 14:34:53 -0700 From: John-Mark Gurney To: usleepless@gmail.com Message-ID: <20061020213453.GR23971@funkthat.com> Mail-Followup-To: usleepless@gmail.com, freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Removing Giant from a driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 21:37:25 -0000 usleepless@gmail.com wrote this message on Sun, Oct 15, 2006 at 11:04 +0200: > i have been tweaking the pvr250 driver to support pvr150s/500s. now i > want to remove Giant from the code. > > problem is, i am not sure what to do. i have created a mutex which > replaces the spltty and splx calls. but this crashes my box :-) > > the original code looks like this: > /* > * Allocate a DMA tag for the scatter / gather list. > */ > error = bus_dma_tag_create(sc->parent_dmat, 1, 0, > BUS_SPACE_MAXADDR_32BIT, > BUS_SPACE_MAXADDR, NULL, NULL, > CXM_SG_BUFFERS > * sizeof(struct cxm_sg_entry), 1, > BUS_SPACE_MAXSIZE_32BIT, 0, > #if __FreeBSD_version >= 501102 > busdma_lock_mutex, &Giant, > #endif > &sc->enc_sg.dmat); > > what should it look like? You should be creating a mutex (using mtx_init) at attach time, and pass that mutex instead of Giant... > and how will i prevent the interrupt routine from interfering with > userland operations? can i place a "mtx_lock()" call in the interrupt > routine? Correct.... Fast interrupt handlers cannot use a sleeping mutex, but I doubt this driver is using a fast interrupt handler... > is there a howto somewhere? There are man pages on how to use the various locking primitives, but it is assumed that you have knowlege of concurrent programming... You can take a look at books on pthreads and other related matierals for info on using locks... If you figure out the licensing issues w/ the firmware, I'll import the driver into FreeBSD... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 20 22:50:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B4EE16A415 for ; Fri, 20 Oct 2006 22:50:20 +0000 (UTC) (envelope-from usleepless@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5088343D4C for ; Fri, 20 Oct 2006 22:50:14 +0000 (GMT) (envelope-from usleepless@gmail.com) Received: by ug-out-1314.google.com with SMTP id k3so424913ugf for ; Fri, 20 Oct 2006 15:50:13 -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=cicHfpwjY39L6VxEW6ymcbr6aYyA10FU8LyH0E/TjceT2Nb2YlJ1MSmhE5O73kq18QTIrphA6mZWzY/CqcQJsxgxo8+ciAYjY5B7+ydvmGwkptxefbetdSCiKmvrf+xqXQQJYzaAYCAuIJ/aIciAGKjCVMLAQuXVLIB6ddioykc= Received: by 10.78.203.15 with SMTP id a15mr2893039hug; Fri, 20 Oct 2006 15:50:12 -0700 (PDT) Received: by 10.78.124.8 with HTTP; Fri, 20 Oct 2006 15:50:12 -0700 (PDT) Message-ID: Date: Sat, 21 Oct 2006 00:50:12 +0200 From: usleepless@gmail.com To: "John-Mark Gurney" , usleepless@gmail.com, freebsd-hackers@freebsd.org In-Reply-To: <20061020213453.GR23971@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061020213453.GR23971@funkthat.com> Cc: Subject: Re: Fwd: Removing Giant from a driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 22:50:20 -0000 Dear John-Mark, > > what should it look like? > > You should be creating a mutex (using mtx_init) at attach time, and > pass that mutex instead of Giant... and don't touch busdma_lock_mutex? ( i am passing NULL, NULL at the moment ) > > and how will i prevent the interrupt routine from interfering with > > userland operations? can i place a "mtx_lock()" call in the interrupt > > routine? > > Correct.... Fast interrupt handlers cannot use a sleeping mutex, but > I doubt this driver is using a fast interrupt handler... what is the benefit of a fast interrupt handler? ( i assume a taskqueue is involved ). the interrupt-dma-code of this driver includes tsleep-calls. does that hurt? i have a shared intterupt with the second tuner-module and my soundcard. i ask because the performance on my FBSD 6.x, P4 2.4ghz, 1 card, 2 tuners setup dissapoints me compared to my 4.11, P3 1.0ghz(!), 2 cards, 4 tuners setup. the 4.11 machine is headless, the 6.x machine has 2 lcds through 1 ati-radeon. it is on the 6.x machine i try to run mythfrontend and use the card at the same time. i can imagine this is very complex: the 6.x machine is dealing with: - capturing video ( using this driver ) - running mythfrontend ( driving XVideo and OSS ) - mythbackend reading from the cxm device, and writing to a NFS-share this driver is generating about 1 megabyte per second. the 4.11 machine is handling 4 x 1 megabyte per second just fine writing it to disk, and doing other stuff ( apache, postgresql, hylafax, firewall, natd, nfs-server, mythbackends ). > > is there a howto somewhere? > > There are man pages on how to use the various locking primitives, but > it is assumed that you have knowlege of concurrent programming... i have, i know mutexes, semaphores, critical sections etc. heck, i implemented 32-bits threading for watson-c on w3.11 once. i have read http://www.freebsd.org/projects/busdma/ - this driver uses the busdma framework - i have registered the interrupt INTR_MPSAFE - SMPng locked: i have employed a mutex instead of spltty() - p!=a safety: i don't think this is relevant right now but i lack the connection with the freebsd-kernel. for example: i don't understand what Giant is good for. i can imagine Giant is important for a network-interface-driver because of the framework. but what does the cxm driver has to do with it? is transforming this driver to use fast-interrupts worthwhile? ( like the if-em driver ) > You can take a look at books on pthreads and other related > matierals for info on using locks... > > If you figure out the licensing issues w/ the firmware, I'll import > the driver into FreeBSD... i suppose that will never happen: - hauppauge firmware is needed - i used GPLed linux/v4l2 headers and sourefiles to make the pvr150s/500s work thank you for your time, regards, usleep From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 21 00:31:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8C616A417 for ; Sat, 21 Oct 2006 00:31:01 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id F246143D77 for ; Sat, 21 Oct 2006 00:30:47 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (tef1ed83ueta6qqv@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k9L0UlCk031119; Fri, 20 Oct 2006 17:30:47 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k9L0Ulxv031118; Fri, 20 Oct 2006 17:30:47 -0700 (PDT) (envelope-from jmg) Date: Fri, 20 Oct 2006 17:30:47 -0700 From: John-Mark Gurney To: usleepless@gmail.com Message-ID: <20061021003047.GS23971@funkthat.com> Mail-Followup-To: usleepless@gmail.com, freebsd-hackers@freebsd.org References: <20061020213453.GR23971@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Removing Giant from a driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 00:31:01 -0000 usleepless@gmail.com wrote this message on Sat, Oct 21, 2006 at 00:50 +0200: > >> what should it look like? > > > >You should be creating a mutex (using mtx_init) at attach time, and > >pass that mutex instead of Giant... > > and don't touch busdma_lock_mutex? ( i am passing NULL, NULL at the moment ) see bus_dma(9) for more information... but yes, if you use a MTX_DEF mutex, busdma_lock_mutex is fine... > >> and how will i prevent the interrupt routine from interfering with > >> userland operations? can i place a "mtx_lock()" call in the interrupt > >> routine? > > > >Correct.... Fast interrupt handlers cannot use a sleeping mutex, but > >I doubt this driver is using a fast interrupt handler... > > what is the benefit of a fast interrupt handler? ( i assume a > taskqueue is involved ). the interrupt-dma-code of this driver > includes tsleep-calls. does that hurt? i have a shared intterupt with > the second tuner-module and my soundcard. A fast interrupt handler doesn't context switch, is uses the stack that was currently running, so it can't sleep since the stack it is running on may be the stack that needs to run to unlock the lock you would sleep to aquire... > i ask because the performance on my FBSD 6.x, P4 2.4ghz, 1 card, 2 > tuners setup dissapoints me compared to my 4.11, P3 1.0ghz(!), 2 > cards, 4 tuners setup. tsleep'ing from an interrupt handler can be really bad... if the interrupt handler is shared, the other interrupt handler won't run till the first one returns... I have no issues w/ performance on my HDTV capture driver... It's something like 2-5% cpu usage when I capture.. Though I've only ever tried one card in it... > the 4.11 machine is headless, the 6.x machine has 2 lcds through 1 > ati-radeon. it is on the 6.x machine i try to run mythfrontend and use > the card at the same time. > > i can imagine this is very complex: the 6.x machine is dealing with: > - capturing video ( using this driver ) > - running mythfrontend ( driving XVideo and OSS ) > - mythbackend reading from the cxm device, and writing to a NFS-share > > this driver is generating about 1 megabyte per second. the 4.11 > machine is handling 4 x 1 megabyte per second just fine writing it to > disk, and doing other stuff ( apache, postgresql, hylafax, firewall, > natd, nfs-server, mythbackends ). > > >> is there a howto somewhere? > > > >There are man pages on how to use the various locking primitives, but > >it is assumed that you have knowlege of concurrent programming... > > i have, i know mutexes, semaphores, critical sections etc. heck, i > implemented 32-bits threading for watson-c on w3.11 once. > > i have read http://www.freebsd.org/projects/busdma/ > - this driver uses the busdma framework > - i have registered the interrupt INTR_MPSAFE > - SMPng locked: i have employed a mutex instead of spltty() > - p!=a safety: i don't think this is relevant right now > > but i lack the connection with the freebsd-kernel. for example: i > don't understand what Giant is good for. i can imagine Giant is Giant is just one big lock that protects things that aren't properly locked yet... This lets you serialize parts of the kernel w/o having to do tons of work figuring out exactly where all the locks should go... In the 4.x days, the kernel could only be running on one cpu at a time, the Giant emulates that behavior... > important for a network-interface-driver because of the framework. but > what does the cxm driver has to do with it? is transforming this > driver to use fast-interrupts worthwhile? ( like the if-em driver ) If you are truely MPSAFE, you should not use Giant... Network drivers only used Giant when they hadn't been locked yet... > >You can take a look at books on pthreads and other related > >matierals for info on using locks... > > > >If you figure out the licensing issues w/ the firmware, I'll import > >the driver into FreeBSD... > > i suppose that will never happen: > - hauppauge firmware is needed Well, there was some work about getting licensing from Hauppauge to let FreeBSD distribute it... But the original author disappeared, and I haven't heard anything... I do have a pvr250 card, but what's the point when I have my HD driver working now? :) > - i used GPLed linux/v4l2 headers and sourefiles to make the pvr150s/500s > work well, those can go in gnu, and it'd be great if we could make the driver not require them, though I don't know how integrated the new work is... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 21 16:26:12 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F1C516A40F; Sat, 21 Oct 2006 16:26:12 +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 97A3243D55; Sat, 21 Oct 2006 16:26:07 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (unknown [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id B1A27758E4; Sat, 21 Oct 2006 18:26:06 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id C201E9E6C2; Sat, 21 Oct 2006 16:26:35 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id A7B95405B; Sat, 21 Oct 2006 18:26:35 +0200 (CEST) Date: Sat, 21 Oct 2006 18:26:35 +0200 From: Jeremie Le Hen To: Ruslan Ermilov Message-ID: <20061021162635.GS53114@obiwan.tataz.chchile.org> References: <20061020150848.GQ53114@obiwan.tataz.chchile.org> <20061020191332.GC59856@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061020191332.GC59856@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-hackers@FreeBSD.org, Jeremie Le Hen Subject: Re: src.conf(5) seems to affect ports build X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 16:26:12 -0000 Hi Ruslan, On Fri, Oct 20, 2006 at 11:13:32PM +0400, Ruslan Ermilov wrote: > On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote: > > Hi, > > > > src.conf(5) manual page states: > > > > % The src.conf file contains settings that will apply to every build > > % involving the FreeBSD source tree; see build(7). > > % ... > > % The only purpose of src.conf is to control the compilation of the FreeBSD > > % sources, which are usually found in /usr/src. > > > > However, share/mk/bsd.port.mk includes which in turn includes > > /etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it > > which affects CFLAGS, they will be taken into account even for port builds. > > > > Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid > > modifying CFLAGS (though I think this might become useful in the near > > future). > > > See if the attached patch helps. If it does, I'll commit. I've > never heard back on this patch after I sent it to obrien@. This patch works correctly. Would you explain me why assigning /dev/null to _SRCCONF don't work in the current version of bsd.port.mk ? Also, your patch avoids performing the WITH(OUT)_* stuff for ports in order to prevent from polluting the namespace. If there is to be some WITH(OUT)_* knobs which leads to CFLAGS modification in the future (I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it be worth benefiting this framework for ports ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 21 17:30:25 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A33E16A416 for ; Sat, 21 Oct 2006 17:30:25 +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 9340743D55 for ; Sat, 21 Oct 2006 17:30:21 +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 E5FB16659; Sat, 21 Oct 2006 21:30:18 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 38D3C6335; Sat, 21 Oct 2006 21:25:27 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9LHPXgo069606; Sat, 21 Oct 2006 21:25:33 +0400 (MSD) (envelope-from ru) Date: Sat, 21 Oct 2006 21:25:33 +0400 From: Ruslan Ermilov To: Jeremie Le Hen Message-ID: <20061021172533.GA69551@rambler-co.ru> References: <20061020150848.GQ53114@obiwan.tataz.chchile.org> <20061020191332.GC59856@rambler-co.ru> <20061021162635.GS53114@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <20061021162635.GS53114@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-hackers@FreeBSD.org Subject: Re: src.conf(5) seems to affect ports build X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 17:30:25 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 21, 2006 at 06:26:35PM +0200, Jeremie Le Hen wrote: > Hi Ruslan, >=20 > On Fri, Oct 20, 2006 at 11:13:32PM +0400, Ruslan Ermilov wrote: > > On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote: > > > Hi, > > >=20 > > > src.conf(5) manual page states: > > >=20 > > > % The src.conf file contains settings that will apply to every build > > > % involving the FreeBSD source tree; see build(7). > > > % ... > > > % The only purpose of src.conf is to control the compilation of the F= reeBSD > > > % sources, which are usually found in /usr/src. > > >=20 > > > However, share/mk/bsd.port.mk includes which in turn inc= ludes > > > /etc/src.conf. Therefore if I have some WITH_/WITHOUT_ knob in it > > > which affects CFLAGS, they will be taken into account even for port b= uilds. > > >=20 > > > Is it the expected behaviour ? Maybe WITH(OUT)_ should simply avoid > > > modifying CFLAGS (though I think this might become useful in the near > > > future). > > >=20 > > See if the attached patch helps. If it does, I'll commit. I've > > never heard back on this patch after I sent it to obrien@. >=20 > This patch works correctly. Would you explain me why assigning > /dev/null to _SRCCONF don't work in the current version of bsd.port.mk ? >=20 1) It's spelled SRCCONF. 2) Even if spelled correctly, setting it to /dev/null doesn't prevent MK_* variables to be set to their default values: cd /usr/src && make showconfig SRCCONF=3D/dev/null > Also, your patch avoids performing the WITH(OUT)_* stuff for ports in > order to prevent from polluting the namespace. If there is to be > some WITH(OUT)_* knobs which leads to CFLAGS modification in the future > (I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it > be worth benefiting this framework for ports ? >=20 It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put WITH(OUT)_* in /etc/make.conf it will still be picked up. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOlgNqRfpzJluFF4RApsRAJ4hSp2dJw34mracQEvuNSBFxaMZCgCfXzhW h+rGw5MjSLsYJe3iJH99nYI= =0yR/ -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 21 19:03:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B95BB16A407; Sat, 21 Oct 2006 19:03:34 +0000 (UTC) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1258343D5D; Sat, 21 Oct 2006 19:03:34 +0000 (GMT) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from [84.173.242.137] (helo=[192.168.0.136]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GbM843z6Q-0003Sl; Sat, 21 Oct 2006 21:03:33 +0200 From: Ekkehard Morgenstern To: freebsd-hackers@freebsd.org Date: Sat, 21 Oct 2006 21:02:00 +0200 User-Agent: KMail/1.9.1 References: <200610141540.09999.ekkehard.morgenstern@onlinehome.de> <200610151011.53724.ekkehard.morgenstern@onlinehome.de> <200610160712.42534.davidxu@freebsd.org> In-Reply-To: <200610160712.42534.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610212102.00456.ekkehard.morgenstern@onlinehome.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9985dda5cbe98f4670734048a5dbacd9 Cc: David Xu Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 19:03:34 -0000 On Monday 16 October 2006 01:12, David Xu wrote: > > How do I use THR syscalls? > > Yes, you can use THR syscalls, they are more simple. > you can use thr_new to create a thread, and use thr_exit to exit > a thread. > You can learn how to use them by reading some code in libthr, > note, this interfaces are only for thread library implementation, > it is not advocated to use them in application. OK, thank you. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 21 21:28:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70D4916A4C2; Sat, 21 Oct 2006 21:28:46 +0000 (UTC) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id E607C43D64; Sat, 21 Oct 2006 21:28:38 +0000 (GMT) (envelope-from ekkehard.morgenstern@onlinehome.de) Received: from [84.173.242.137] (helo=[192.168.0.136]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GbOOO3BPx-0005gA; Sat, 21 Oct 2006 23:28:33 +0200 From: Ekkehard Morgenstern To: John-Mark Gurney Date: Sat, 21 Oct 2006 23:27:13 +0200 User-Agent: KMail/1.9.1 References: <200610150326.03279.ekkehard.morgenstern@onlinehome.de> <200610171717.30834.davidxu@freebsd.org> <20061020212457.GQ23971@funkthat.com> In-Reply-To: <20061020212457.GQ23971@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610212327.13790.ekkehard.morgenstern@onlinehome.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9985dda5cbe98f4670734048a5dbacd9 Cc: freebsd-hackers@freebsd.org, Divacky Roman , David Xu Subject: Re: Threading system calls (int 80h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 21:28:46 -0000 On Friday 20 October 2006 23:24, John-Mark Gurney wrote: > That's why you use rfork_thread(3)... Thanks! That really helps! :-) What I'm trying to do is to write a virtual machine in assembly language on FreeBSD that can be run right after the kernel has been loaded. I would like to avoid external library dependencies, so, for threading, I need some mechanism to make it possible with kernel calls only. I'll be looking at the THR calls as well, but it helps my confidence that rfork(2) and rfork_thread(3) are documented. I'm not sure if I understood the FreeBSD threading mechanism correctly. Are threads always processes? Then it would make no difference if I fork instead of using specific threading calls. I would like to enable the users of my VM to take advantage of multiple CPUs, so a process-based solution doesn't look so bad. How much overhead is involved in FreeBSD multitasking? I will probably also implement a virtual threading mechanism, because every VM process or thread can also multiplex instruction streams scheduled to run concurrently, at least as long as they're interpreted and not converted to native code yet. When the number of virtual threads exceeds a configurable limit, a real thread or process can be created that can run further virtual threads. Does anyone of you have any further recommendations or advice? I would like to pick a solution that can perform optimally on FreeBSD. - Ekkehard.