From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 18 05:41:00 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87B9A1065679 for ; Sun, 18 Jul 2010 05:41:00 +0000 (UTC) (envelope-from freebsd-hackers@chrisbowman.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2688B8FC15 for ; Sun, 18 Jul 2010 05:40:59 +0000 (UTC) Received: by wyf22 with SMTP id 22so3897954wyf.13 for ; Sat, 17 Jul 2010 22:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.138.138 with SMTP id a10mr2617764wbu.13.1279431658962; Sat, 17 Jul 2010 22:40:58 -0700 (PDT) Received: by 10.227.140.161 with HTTP; Sat, 17 Jul 2010 22:40:58 -0700 (PDT) X-Originating-IP: [70.143.83.15] In-Reply-To: <20100712.204623.519459540419523199.imp@bsdimp.com> References: <4C393D36.1050905@feral.com> <20100712.204623.519459540419523199.imp@bsdimp.com> Date: Sat, 17 Jul 2010 22:40:58 -0700 Message-ID: From: Christopher Bowman To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Missing files device_if.h and bus_if.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, 18 Jul 2010 05:41:00 -0000 Can a pci/pcie dirver be loaded and unloaded like a kld? On Mon, Jul 12, 2010 at 7:46 PM, M. Warner Losh wrote: > Not quite. Make creates them... > > Matthew Jacob writes: > : config(8) creates them I believe > : > : > line 523 of bus.h > : > > : > tries to include the following files: > : > > : > #include "device_if.h" > : > #include "bus_if.h" > : > > : > however, I don't see them any where in my source tree. Are these > : > missing or am I suppose to create them or are they built as part of > : > the build process and if the latter then why didn't I get a copy when > : > I built a custom kernel? > : > > : > Where do I get these files? Could someone please clue me in here? > : > > : > And since I am asking questions here, I see BUS_READ_IVAR used a > : > couple of places but can't find it's definition. Where is it defined? > : > > : > Thanks > : > Christopher > : > _______________________________________________ > : > freebsd-hackers@freebsd.org mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > : > To unsubscribe, send any mail to > : > "freebsd-hackers-unsubscribe@freebsd.org" > : > > : > : _______________________________________________ > : freebsd-hackers@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > : To unsubscribe, send any mail to > : "freebsd-hackers-unsubscribe@freebsd.org" > : > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:09:24 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6763106566B for ; Mon, 19 Jul 2010 05:09:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 713078FC17 for ; Mon, 19 Jul 2010 05:09:24 +0000 (UTC) Received: by iwn35 with SMTP id 35so5311468iwn.13 for ; Sun, 18 Jul 2010 22:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=4ThkaUcz/EEiWPhClTmRGggOj0bLipQX98kpJglp3OQ=; b=UZBRmH1koSQUAXjUoZlBDbPcDyutTNKwFsQCJAin2+iT/C1o2C85v/i2PVRKsHhKZf kn0PgyLjRCEER3KCNHmGSjkSRS5G5Tqn4SDhCb8BgABB+jqqmpLmsChwFhYXoZuqWMBT j8H/qbPE80FVFne3jzl3ePtSxC+SpDy+Bru9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=HpbAWfFh1MtRA6HHzB/72/9opxnXKq4PSwz0W/uKJE6mZAEkhRdedN6JmpyXMPMhEv OR4YIuYIlElfYvGZYAisqh8Ha7GHBhrwLSn2qTS09iab1ChLvO96tbUKQjj3e2oD6YvX dARzxxbaA2HR+J7QV86LxlPBH+7MGK6PDhHU0= MIME-Version: 1.0 Received: by 10.231.148.83 with SMTP id o19mr5201523ibv.112.1279516163431; Sun, 18 Jul 2010 22:09:23 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:09:23 -0700 (PDT) Date: Sun, 18 Jul 2010 22:09:23 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: [PATCH] Catch errors with sigaddset(3) in sigaddset (sigrelse) 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, 19 Jul 2010 05:09:24 -0000 sigrelse has the same problem as (*sigset) as far as not catching sigaddset(3) errors is concerned. Thanks, -Garrett Index: compat-43/sigcompat.c =================================================================== --- compat-43/sigcompat.c (revision 210226) +++ compat-43/sigcompat.c (working copy) @@ -151,7 +151,8 @@ sigset_t set; sigemptyset(&set); - sigaddset(&set, sig); + if (sigaddset(&set, sig) == -1) + return (-1); return (_sigprocmask(SIG_UNBLOCK, &set, NULL)); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:10:09 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25EA21065674 for ; Mon, 19 Jul 2010 05:10:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF9348FC08 for ; Mon, 19 Jul 2010 05:10:08 +0000 (UTC) Received: by iwn35 with SMTP id 35so5312097iwn.13 for ; Sun, 18 Jul 2010 22:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YcIL07Bh8bpcf2sNPvWy75nguMJIVtaDF62d0aDIVwQ=; b=Axl+l2jIs/yIcXp5t4q/LMNDL/BbKgJA8BC2d7Qs5XX3gZCjNTUwXexno78EmvhaYF Aq58C4yatx0c06/5TuvnB/UrX3iQoXBpOTp6NIJDupGOo3v0YgLAqYHflgK6Xt0VpdMO AKzTqubXHuCgGDFEmymjQ5V4FHP7L22c5KVJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v6xu1POvcNzv2A9kXbiurgBL/e41ct/GEVeC7H3NgYAlsUOfikLGh1vuDMrdFJtw9W kCEiQeKs8hWQkiJ1jBa3y+lh9yJmtZTz3THk8DUZwl+UKx0JXgfFMj+sHfpkSAKX3SfG tkerhzsn1gdpmTOpTS6rLKlIhsprMGJNIeu/c= MIME-Version: 1.0 Received: by 10.231.14.201 with SMTP id h9mr4496927iba.135.1279516208241; Sun, 18 Jul 2010 22:10:08 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:10:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Jul 2010 22:10:08 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov Subject: Fwd: [PATCH] Catch errors with sigaddset(3) in sigaddset (*sigset) 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, 19 Jul 2010 05:10:09 -0000 CCing hackers@. ---------- Forwarded message ---------- From: Garrett Cooper Date: Sun, Jul 18, 2010 at 10:06 PM Subject: [PATCH] Catch errors with sigaddset(3) in sigaddset (*sigset) To: Kostik Belousov =A0 =A0None of the sigprocmask(2) code actually checks to see whether or not the signal set is valid. This fixes that. Thanks, -Garrett Index: compat-43/sigcompat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- compat-43/sigcompat.c =A0 =A0 =A0 (revision 210226) +++ compat-43/sigcompat.c =A0 =A0 =A0 (working copy) @@ -163,7 +163,9 @@ =A0 =A0 =A0 =A0int error; =A0 =A0 =A0 =A0sigemptyset(&set); - =A0 =A0 =A0 sigaddset(&set, sig); + =A0 =A0 =A0 error =3D sigaddset(&set, sig); + =A0 =A0 =A0 if (error =3D=3D -1) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (SIG_ERR); =A0 =A0 =A0 =A0error =3D _sigprocmask(SIG_BLOCK, NULL, &pset); =A0 =A0 =A0 =A0if (error =3D=3D -1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_ERR); From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:10:26 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A33CA1065670 for ; Mon, 19 Jul 2010 05:10:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 692438FC1D for ; Mon, 19 Jul 2010 05:10:26 +0000 (UTC) Received: by mail-iw0-f182.google.com with SMTP id 35so5312097iwn.13 for ; Sun, 18 Jul 2010 22:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tUJtEHRcaXql6/Z2jatZeYcb6Ux4E/CD4kuXSDRuDzI=; b=MAiKKd8YOLNQEeOVucu2+wmMivUoDaZ+8Ko4Qa/bPLPurq1kavGJr5yHU7Bv1XJxxY J7LoN0VqLtT5iF5wud+j/S5Q+flZXOlBHJtVBRQ59FkqfSMPeVojqa94XKBcuETw6X1Y PV8T6dZUjE3urr1jF8RAgbIKL25NfAd4bgODk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WHvyDWJPxxe7tg97fSZIVx53LHpGIneWh7vNaYW2jV8pFzijsx/cIuPc5iw6EtcdhJ b3t51vTTVh83iXDdZR7Pho094/1BlZ+2lSVia33YwnWzf3178cgLb5xHXYzlxryNWJSr bbgQVRAEpgpzqgdK0365XxhxTTyfhylGvaox0= MIME-Version: 1.0 Received: by 10.231.146.136 with SMTP id h8mr4975389ibv.0.1279516226260; Sun, 18 Jul 2010 22:10:26 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:10:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Jul 2010 22:10:26 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: [PATCH] Fix sigismember(3) manpage ambiguity 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, 19 Jul 2010 05:10:26 -0000 CCing hackers@. On Sun, Jul 18, 2010 at 9:52 PM, Garrett Cooper wrote: > =A0 =A0The following patch resolves a missing requirement that's defined > by POSIX 2001.3 for sigismember(3) (the tort follows more of what's > stated in the POSIX spec [1]). > > Index: libc/gen/sigsetops.3 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- libc/gen/sigsetops.3 =A0 =A0 =A0 =A0(revision 210226) > +++ libc/gen/sigsetops.3 =A0 =A0 =A0 =A0(working copy) > @@ -92,8 +92,11 @@ > =A0The > =A0.Fn sigismember > =A0function returns 1 > -if the signal is a member of the set, > -0 otherwise. > +if the signal is a member of the set, or 0 if it is not. > +Otherwise, it returns \-1 and the global variable > +.Va errno > +is set to indicate the reason. > +.Bl > =A0The other functions return 0 upon success. > =A0A \-1 return value > =A0indicates an error occurred and the global variable > > 1. http://opengroup.org/onlinepubs/007908799/xsh/sigismember.html > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:15:33 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E1A106564A for ; Mon, 19 Jul 2010 05:15:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23F618FC15 for ; Mon, 19 Jul 2010 05:15:32 +0000 (UTC) Received: by iwn35 with SMTP id 35so5316515iwn.13 for ; Sun, 18 Jul 2010 22:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=fXcLHm72/oFiNGnxKlYy08uFM2gvEvfw1QhKLBR14To=; b=S2eLsibNge7X2HTA5sTruqEBdjKFcBI9z13gtXi1yfLylSx54B1aG2OK/XPDYwJYoq 3/d6wPZQ5NkHkDZeBIzF2BBYvYWXK0HrFJEmdIBt+4FIctrsWwtcauZeTDNI4kYx47bc t/yl3CDiWIZy/xK71I6h3j8rbxKdk6IK1kia8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Nt+0P4yWYJqACwjH47rqQg7QUGTRjahqiVB4LFh0+5ldcu72wU4IKJvMxKXZzJyhJ4 S+087p9jMVrg6zFoQjtW7jqXf5DJoBOzorl4ardi28+dEPYIWNY6BzbWGD3CBQ5D44zR Zo/5dpuLOlHl2bdAMNi2V245/6ds+1KRSeOrY= MIME-Version: 1.0 Received: by 10.231.146.136 with SMTP id h8mr4980676ibv.0.1279516532402; Sun, 18 Jul 2010 22:15:32 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:15:32 -0700 (PDT) Date: Sun, 18 Jul 2010 22:15:32 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: [PATCH] sigpause(2) doesn't check signal validity before setting mask 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, 19 Jul 2010 05:15:33 -0000 The following patch fixes the case where the value for sigmask specified is invalid (to match the requirements stated in the manpage and POSIX), and also converts the parameter name -- mask -- to match the manpage. Thanks, -Garrett Index: compat-43/sigcompat.c =================================================================== --- compat-43/sigcompat.c (revision 210226) +++ compat-43/sigcompat.c (working copy) @@ -99,12 +99,16 @@ } int -sigpause(int mask) +sigpause(int sigmask) { sigset_t set; + if (!_SIG_VALID(sigmask)) { + errno = EINVAL; + return (-1); + } sigemptyset(&set); - set.__bits[0] = mask; + set.__bits[0] = sigmask; return (_sigsuspend(&set)); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:22:30 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B2761065670 for ; Mon, 19 Jul 2010 05:22:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1675E8FC12 for ; Mon, 19 Jul 2010 05:22:29 +0000 (UTC) Received: by iwn35 with SMTP id 35so5322670iwn.13 for ; Sun, 18 Jul 2010 22:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=+rj9u0CnIPHMtvxcGlx2456uUJKuKL1mVJHFYZ5kh8s=; b=gfhavaAFAhU7tdM698RrtygZPVGzmMp2TPbJntb4Y1lbIVy2K2TcB2lDqrJP4Y0W0I K1x1oXScEtyOH3tYLJfELZ9Pm1uhpByS0CGBItJwfw7Sxf7xUqahYgLM5uArw8J9WB7W gRs97nrI1XFtIrvHbgMPAJV1rMtIcBnnjg4gs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=lM20pdHCacKX+mI+QOKcl0aGfmbpsIhRzZTdM+8qzsQilS84l8hmWfZLI2IHN5ts4L MfGZzZxjIWJK4g2uQQNQgDoCvCVvdorrkbc68K9qs4nGTg/ahgDaI5VD/4qtug4oHBDQ dwMUCpm8J0aRLbbuAWN88snizzRbc6hXkWNNQ= MIME-Version: 1.0 Received: by 10.231.174.5 with SMTP id r5mr5363318ibz.132.1279516949122; Sun, 18 Jul 2010 22:22:29 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:22:29 -0700 (PDT) Date: Sun, 18 Jul 2010 22:22:29 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: [PATCH] Make xsi_sigpause prototype match manpage 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, 19 Jul 2010 05:22:30 -0000 Looks like kib@ checked in a version with the sigdelset fixes for xsi_sigpause(3). This goes one step further by changing the prototype to follow the declaration in the manpage. Thanks, -Garrett Index: compat-43/sigcompat.c =================================================================== --- compat-43/sigcompat.c (revision 210226) +++ compat-43/sigcompat.c (working copy) @@ -109,19 +109,19 @@ } int -xsi_sigpause(int sig) +xsi_sigpause(int sigmask) { sigset_t set; int error; - if (!_SIG_VALID(sig)) { + if (!_SIG_VALID(sigmask)) { errno = EINVAL; return (-1); } error = _sigprocmask(SIG_BLOCK, NULL, &set); if (error != 0) return (error); - sigdelset(&set, sig); + sigdelset(&set, sigmask); return (_sigsuspend(&set)); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 05:46:26 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF981065673 for ; Mon, 19 Jul 2010 05:46:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 499348FC14 for ; Mon, 19 Jul 2010 05:46:26 +0000 (UTC) Received: by iwn35 with SMTP id 35so5342715iwn.13 for ; Sun, 18 Jul 2010 22:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=HS/SOsc8FpYZTlWYj71IlA5TemtkU23aT49eG1+i2u8=; b=YAsxg3r0m1bKgyGOM8kBzZ+xHglR/CHtJ/8s8fdebEvNwqA+OzcmcjMJ7ECrMOvYCS rQr2/LOm91jDveT1vEotzesYbD+LDt0q3tYdI11zxlqBM5tEHMQgstuVEtXfJW1sxE01 WNnG2/V5g2M3nHHYWMeb3lgMDjTSdFuw+uJ9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=RPEsEXMa9CWKp68nC60Zp9bJfzq56saQdhpMflLEaCHGQ8546QLzzpYbbMpalMIG09 s3CeNiCRMCxTEAE7ZyKGJ0ClC8U35NNrK0sv1s8Pwnw89JhosQ6liAXxIHHivise+IPY mEp063GATg7/aRMO2nZ3vJ4XIK+sJbWaxPd+c= MIME-Version: 1.0 Received: by 10.231.35.10 with SMTP id n10mr4450477ibd.161.1279518385613; Sun, 18 Jul 2010 22:46:25 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Sun, 18 Jul 2010 22:46:25 -0700 (PDT) Date: Sun, 18 Jul 2010 22:46:25 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: [PATCH] Catch errors with sigaddset(3) in sigaddset (sighold) 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, 19 Jul 2010 05:46:26 -0000 sighold(3) doesn't determine whether or not the signal added is valid today (and sigprocmask doesn't verify that either). This fixes that. Thanks, -Garrett Index: sigcompat.c =================================================================== --- sigcompat.c (revision 210226) +++ sigcompat.c (working copy) @@ -131,7 +131,8 @@ sigset_t set; sigemptyset(&set); - sigaddset(&set, sig); + if (sigaddset(&set, sig) == -1) + return (-1); return (_sigprocmask(SIG_BLOCK, &set, NULL)); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 12:09:21 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6473C106566B for ; Mon, 19 Jul 2010 12:09:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 005408FC24 for ; Mon, 19 Jul 2010 12:09:20 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6JC9GVV029802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 15:09:16 +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.14.4/8.14.4) with ESMTP id o6JC9GCR045908; Mon, 19 Jul 2010 15:09:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6JC9Gmw045907; Mon, 19 Jul 2010 15:09:16 +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: Mon, 19 Jul 2010 15:09:16 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20100719120916.GX2381@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hdMwqcnXK86+cyrC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: [PATCH] Catch errors with sigaddset(3) in sigaddset (sighold) 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, 19 Jul 2010 12:09:21 -0000 --hdMwqcnXK86+cyrC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2010 at 10:46:25PM -0700, Garrett Cooper wrote: > sighold(3) doesn't determine whether or not the signal added is > valid today (and sigprocmask doesn't verify that either). This fixes > that. > Thanks, > -Garrett >=20 > Index: sigcompat.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sigcompat.c (revision 210226) > +++ sigcompat.c (working copy) > @@ -131,7 +131,8 @@ > sigset_t set; >=20 > sigemptyset(&set); > - sigaddset(&set, sig); > + if (sigaddset(&set, sig) =3D=3D -1) > + return (-1); > return (_sigprocmask(SIG_BLOCK, &set, NULL)); > } I added checks for failures of sig{add,del}set to the sigcompat.c, and unified style to not assign intermediate error to local variable. This is what I am going to commit shortly. diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c index 6841eeb..199846f 100644 --- a/lib/libc/compat-43/sigcompat.c +++ b/lib/libc/compat-43/sigcompat.c @@ -112,16 +112,11 @@ int xsi_sigpause(int sig) { sigset_t set; - int error; =20 - if (!_SIG_VALID(sig)) { - errno =3D EINVAL; + if (_sigprocmask(SIG_BLOCK, NULL, &set) =3D=3D -1) + return (-1); + if (sigdelset(&set, sig) =3D=3D -1) return (-1); - } - error =3D _sigprocmask(SIG_BLOCK, NULL, &set); - if (error !=3D 0) - return (error); - sigdelset(&set, sig); return (_sigsuspend(&set)); } =20 @@ -131,7 +126,8 @@ sighold(int sig) sigset_t set; =20 sigemptyset(&set); - sigaddset(&set, sig); + if (sigaddset(&set, sig) =3D=3D -1) + return (-1); return (_sigprocmask(SIG_BLOCK, &set, NULL)); } =20 @@ -151,7 +147,8 @@ sigrelse(int sig) sigset_t set; =20 sigemptyset(&set); - sigaddset(&set, sig); + if (sigaddset(&set, sig) =3D=3D -1) + return (-1); return (_sigprocmask(SIG_UNBLOCK, &set, NULL)); } =20 @@ -160,35 +157,30 @@ void { sigset_t set, pset; struct sigaction sa, psa; - int error; =20 sigemptyset(&set); - sigaddset(&set, sig); - error =3D _sigprocmask(SIG_BLOCK, NULL, &pset); - if (error =3D=3D -1) + if (sigaddset(&set, sig) =3D=3D -1) + return (SIG_ERR); + if (_sigprocmask(SIG_BLOCK, NULL, &pset) =3D=3D -1) return (SIG_ERR); if ((__sighandler_t *)disp =3D=3D SIG_HOLD) { - error =3D _sigprocmask(SIG_BLOCK, &set, &pset); - if (error =3D=3D -1) + if (_sigprocmask(SIG_BLOCK, &set, &pset) =3D=3D -1) return (SIG_ERR); if (sigismember(&pset, sig)) return (SIG_HOLD); else { - error =3D _sigaction(sig, NULL, &psa); - if (error =3D=3D -1) + if (_sigaction(sig, NULL, &psa) =3D=3D -1) return (SIG_ERR); return (psa.sa_handler); } } else { - error =3D _sigprocmask(SIG_UNBLOCK, &set, &pset); - if (error =3D=3D -1) + if (_sigprocmask(SIG_UNBLOCK, &set, &pset) =3D=3D -1) return (SIG_ERR); } =20 bzero(&sa, sizeof(sa)); sa.sa_handler =3D disp; - error =3D _sigaction(sig, &sa, &psa); - if (error =3D=3D -1) + if (_sigaction(sig, &sa, &psa) =3D=3D -1) return (SIG_ERR); if (sigismember(&pset, sig)) return (SIG_HOLD); --hdMwqcnXK86+cyrC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxEQGwACgkQC3+MBN1Mb4j7qgCePmu2WNnCAob9fpaYJSyx19w4 sAkAoJ7xYJ6eYUY20CGmMw6dzfg0Y1t3 =Xpz6 -----END PGP SIGNATURE----- --hdMwqcnXK86+cyrC-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 03:50:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888DF106564A for ; Tue, 20 Jul 2010 03:50:38 +0000 (UTC) (envelope-from tajudd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 51E0C8FC13 for ; Tue, 20 Jul 2010 03:50:38 +0000 (UTC) Received: by iwn35 with SMTP id 35so6761179iwn.13 for ; Mon, 19 Jul 2010 20:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PemRpEPaLMSxlDLAuJdLErqezFRrxZdhzM6K7ctRqAg=; b=ByNoCEZBJQZjKM/YMMGK1KTR+zUMtltWUO+4ILV2hpUZdP7p4qvHvM32AV3OPrExzl akqS/QEGtBQ+cNIgfw/4WiXSE3KQeomoKSOzi+P53s1RXLsFJjZoR5aY11gY1Dvz/Co/ 8XgyAPVcflZuXw89A5Lh0A0leDwm3LDNp8f18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=G44t85u+GUdORA+jh6K14ExrCk2kKSDpEgNed9q1jWQPp3PUYj5HJKMmlIwuRpQX8I 4R9vWjVF44HPORr3JCuXEgraN3wt0tRVgkTRQyb+5gc4h5FUE1+ntF5PZWSHUMlv2+8r EqqiWmXL2S4B26GA/iRaek9qFYMc1aUM713Dc= MIME-Version: 1.0 Received: by 10.231.35.77 with SMTP id o13mr457846ibd.92.1279597837457; Mon, 19 Jul 2010 20:50:37 -0700 (PDT) Received: by 10.231.180.135 with HTTP; Mon, 19 Jul 2010 20:50:37 -0700 (PDT) Date: Mon, 19 Jul 2010 21:50:37 -0600 Message-ID: From: Tim Judd To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: kernel modules into static kernel 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, 20 Jul 2010 03:50:38 -0000 Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? I love to torture myself by putting BSD in environments it's not normally in, and this round is trying to get a (UNDOCUMENTED?) GEOM_UZIP root filesystem Thanks for any pointers, --Tim From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 06:00:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 150FE1065670 for ; Tue, 20 Jul 2010 06:00:16 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C29D68FC08 for ; Tue, 20 Jul 2010 06:00:15 +0000 (UTC) Received: by qyk7 with SMTP id 7so3067977qyk.13 for ; Mon, 19 Jul 2010 23:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PyhRe4AfwTcTgaCVQTECigeCDqJMCm/EXLMw0yqcA+I=; b=UJMMKGC1z1cWwkpxi7sx9SrHtihRddOODp6RnC569hnhR/Nk8/OhFvD4Ww0sEGe+p2 dbAFVmDKFX6eTdw/FWs8p3lkiX2BzGFrdNz1Gp8XeD55fepumRTrZ+0ENE+ywzLDf6tN 1YQrKKmItM1NzzuPQ8o4s6pipaan528e+w7Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tIKJwamRPCtg3+0oN9jsvqShJjLBxIO6AnGd1bJnwsGBRZ0pI1D25U8bT1TdD9DyHs 1tFxXemUFNI9AQ39XZCZky9rYvw8tOQEywEfTN3Du1hbNeWnyuzZOfHWWRPhXAi+sX9c 4ZTFlkmpAuTNJkpv6fB5NX9C8dXtd2OIdwBrI= MIME-Version: 1.0 Received: by 10.224.53.150 with SMTP id m22mr5293872qag.316.1279605614999; Mon, 19 Jul 2010 23:00:14 -0700 (PDT) Received: by 10.229.84.84 with HTTP; Mon, 19 Jul 2010 23:00:04 -0700 (PDT) Date: Tue, 20 Jul 2010 11:30:04 +0530 Message-ID: From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [DTrace] DIF DIF_OP_LDUW replaced with DIF_OP_RLDUW 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, 20 Jul 2010 06:00:16 -0000 I see the the instruction DIF_OP_LDUW (when observed with the option verbose in script) is getting replaced with a DIF_OP_RLDUW. Maybe this is intentional, but with DIF_OP_RLDUW the check 'dtrace_canstore' fails giving 'CPU_DTRACE_KPRIV' fault for whatever variables I query. * Is this intentional replacement? * If yes, then my args[0] variables are all outside the range being checked in dtrace_canstore which gets called when dtrace_dif_emulate sees DIF_OP_RLDUW? ** This is FreeBSD cross compiler environment... Here is the script #pragma D option verbose BEGIN { } fbt::kernel_nudge_client:entry { trace(args[0]->client_num); } --------------------------------------------------------------------------------------- root%dtrace -s fbt_test.d DIFO 0x0x80b1280 returns D type (integer) (size 4) OFF OPCODE INSTRUCTION 00: 25000001 setx DT_INTEGER[0], %r1 ! 0x0 01: 28000101 ldga DT_VAR(0), %r1, %r1 02: 25000102 setx DT_INTEGER[1], %r2 ! 0x20 03: 04010201 sll %r1, %r2, %r1 04: 05010201 srl %r1, %r2, %r1 05: 25000202 setx DT_INTEGER[2], %r2 ! 0xc 06: 07010201 add %r1, %r2, %r1 07: 21010001 lduw [%r1], %r1 <== LDUW here 08: 23000001 ret %r1 dtrace: script 'fbt_test.d' matched 2 probes CPU ID FUNCTION:NAME 0 1 :BEGIN --------------------------------------------------------------------------------------- But when the probe is hit, I compare what DIFO is present in kernel space (kgdb) p /x text[7] $12 = 0x4c010001 whereas the instruction 07 in the above dump is 0x21010001 '4c' says it is a "rlduw" instruction. The problem is the args[0]->client_num address is showing up as [0xc45b3d2c] and the check in dtrace_canstore shows all ranges for 'dtms_scratch_base', 'dtvs_dynvars.dtds_base' are above the "0xc45b3d2c". Hence dtrace_canstore returns 0 and CPU_DTRACE_KPRIV gets returned. (kgdb) fr #3 0xc4ff9863 in dtrace_dif_emulate... (kgdb) p /x 0xc45b3d2c <== &args[0]->client_num $19 = 0xc45b3d2c (kgdb) p /x mstate->dtms_scratch_base $20 = 0xc5cc0008 (kgdb) p /x mstate->dtms_scratch_size $21 = 0xbffff8 (kgdb) p /x vstate->dtvs_dynvars.dtds_base $22 = 0xc74c0000 (kgdb) p /x vstate->dtvs_dynvars.dtds_size $23 = 0x100000 -------------------------------------------------------------------------------------------- Here is o/p for root%dtrace -l -f kernel_nudge_client -v ID PROVIDER MODULE FUNCTION NAME 58 fbt kernel kernel_nudge_client entry Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Types args[0]: kernel_client * args[1]: int -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 17:30:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 289CD106566C for ; Tue, 20 Jul 2010 17:30:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id C497A8FC18 for ; Tue, 20 Jul 2010 17:30:00 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 7FDCDA55D88; Wed, 21 Jul 2010 01:29:59 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 4rN3pOY7Dwv7; Wed, 21 Jul 2010 01:29:53 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 18960A55851; Wed, 21 Jul 2010 01:29:51 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Kx8dyERb/v3CjNH9tlzI/0UAxkk9hgf7IrlzW0UMpG1DUc5fSgXMUl/+IMgh9eERh tUS8xA00y71n+pBrLKo2Q== Message-ID: <4C45DD0A.1070104@delphij.net> Date: Tue, 20 Jul 2010 10:29:46 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: Tim Judd References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: kernel modules into static kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:30:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/19 20:50, Tim Judd wrote: > Hellos, > > > Of interest, I can get GEOM_UZIP kernel module as part of the kernel, > but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build > a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the > kernel? Yes. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRd0KAAoJEATO+BI/yjfB9EEH/38i8b0LdphAnpKEmKO0u1eU tCqM0LiSd8iJM3ZxilBvrIVofDXEqQW6PoDZ3m3KTRu39muZRqhRB1aVt3vbTCev xhDFEAgVrC0G16/JI9OE3h4Qtg0WT85Oyt/pZOTpzlaSXySByYyLHL2WbcC2FAMg t1R3ej35jqdmo2heSq3TnuRHQ6ykeqWqtHN18SMFrs+ywC6FYvgpR7rA2gsSa194 tiHEleR0IiBeklksHX38GPwWytYhgVwOAEdy+6JlFqcHAulFON47jjhq/9YAa6sq xAYBoJStnIVqIf4pjvzMzUrn07DUVbs9P4xbgJkTU0NXuuFvyaiH0VgzuU/zHt8= =Q7Yq -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 18:16:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E041D106564A; Tue, 20 Jul 2010 18:16:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE7D18FC17; Tue, 20 Jul 2010 18:16:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 33E7C46B5C; Tue, 20 Jul 2010 14:16:10 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2F2DB8A050; Tue, 20 Jul 2010 14:16:09 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 20 Jul 2010 10:46:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <20100712.204623.519459540419523199.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201046.51631.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Jul 2010 14:16:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: hackers@freebsd.org, Christopher Bowman Subject: Re: Missing files device_if.h and bus_if.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, 20 Jul 2010 18:16:11 -0000 On Sunday, July 18, 2010 1:40:58 am Christopher Bowman wrote: > Can a pci/pcie dirver be loaded and unloaded like a kld? Yes. Typically Makefiles for driver modules list 'driver_if.h' and 'bus_if.h' in their SRCS line and bsd.kmod.mk generates them during the build. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 18:16:10 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E041D106564A; Tue, 20 Jul 2010 18:16:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE7D18FC17; Tue, 20 Jul 2010 18:16:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 33E7C46B5C; Tue, 20 Jul 2010 14:16:10 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2F2DB8A050; Tue, 20 Jul 2010 14:16:09 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 20 Jul 2010 10:46:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <20100712.204623.519459540419523199.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201046.51631.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Jul 2010 14:16:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: hackers@freebsd.org, Christopher Bowman Subject: Re: Missing files device_if.h and bus_if.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, 20 Jul 2010 18:16:11 -0000 On Sunday, July 18, 2010 1:40:58 am Christopher Bowman wrote: > Can a pci/pcie dirver be loaded and unloaded like a kld? Yes. Typically Makefiles for driver modules list 'driver_if.h' and 'bus_if.h' in their SRCS line and bsd.kmod.mk generates them during the build. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 18:16:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BBE106566C for ; Tue, 20 Jul 2010 18:16:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C71928FC19 for ; Tue, 20 Jul 2010 18:16:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 750E646B52; Tue, 20 Jul 2010 14:16:11 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 845C48A04E; Tue, 20 Jul 2010 14:16:10 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 20 Jul 2010 10:52:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201052.03140.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Jul 2010 14:16:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tim Judd Subject: Re: kernel modules into static kernel 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, 20 Jul 2010 18:16:12 -0000 On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: > Hellos, > > > Of interest, I can get GEOM_UZIP kernel module as part of the kernel, > but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build > a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the > kernel? Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for 'uzip' to see what GEOM_UZIP includes in the build). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 18:55:24 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BE20106568C for ; Tue, 20 Jul 2010 18:55:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 074FE8FC15 for ; Tue, 20 Jul 2010 18:55:23 +0000 (UTC) Received: by gxk24 with SMTP id 24so3840063gxk.13 for ; Tue, 20 Jul 2010 11:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=Znz5PbIcMxtavTP66fAN9ujQ9hl9fUD5IxBQ6I4LfkY=; b=YDUClfmIpUB2+6cd0qO+qyHzU6Q8o4kZ8GDiIN0H6s9hqM8UJeKFyOQ53NYhRAH4Te aU8OE6hgoNXc7ynMwL7RwY0J30M9/pOB+UTTyjgiIBvjs6m+9+sSrbuvjyLJWaT+wyQM AKdxb7K/viocdqGlVcjMa80jO8NPmmp/E8N3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=UWJHe8vVAwZEP1+EQ5+mwwthF8OEx3+wvzzKequiAg3g2kbFpts5DhuP9Kb9zpvvYp fhL4EA6SKmDrsafPUNwJZNmkQGgHqXbJJNjGVzBAoNyCLdzX5t/RHDPtOVFV27cDUtXh /HlMUbVfVXzbkdAfP/hrM79/EXyuTzFM6paSU= MIME-Version: 1.0 Received: by 10.100.124.1 with SMTP id w1mr1040764anc.265.1279652122708; Tue, 20 Jul 2010 11:55:22 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Tue, 20 Jul 2010 11:55:22 -0700 (PDT) Date: Tue, 20 Jul 2010 11:55:22 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: standards@freebsd.org Subject: Chasing down bugs with access(2) 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, 20 Jul 2010 18:55:24 -0000 Hi Hackers, I ran into an issue last night where apparently several apps make faulty assumptions w.r.t. whether or not access(2) returns functional data when running as a superuser. POSIX says: In early proposals, some inadequacies in the access() function led to the creation of an eaccess() function because: 1. Historical implementations of access() do not test file access correctly when the process' real user ID is superuser. In particular, they always return zero when testing execute permissions without regard to whether the file is executable. 2. The superuser has complete access to all files on a system. As a consequence, programs started by the superuser and switched to the effective user ID with lesser privileges cannot use access() to test their file access permissions. However, the historical model of eaccess() does not resolve problem (1), so this volume of IEEE Std 1003.1-2001 now allows access() to behave in the desired way because several implementations have corrected the problem. It was also argued that problem (2) is more easily solved by using open(), chdir(), or one of the exec functions as appropriate and responding to the error, rather than creating a new function that would not be as reliable. Therefore, eaccess() is not included in this volume of IEEE Std 1003.1-2001. The sentence concerning appropriate privileges and execute permission bits reflects the two possibilities implemented by historical implementations when checking superuser access for X_OK. New implementations are discouraged from returning X_OK unless at least one execution permission bit is set. FreeBSD says: Even if a process's real or effective user has appropriate privileges and indicates success for X_OK, the file may not actually have execute per- mission bits set. Likewise for R_OK and W_OK. This results in: sh/test - ok-ish (a guy on bash-bugs challenged the fact that the syscall was buggy based on the details returned). bash - broken (builtin test(1) always returns true) csh - not really ok (uses whacky stat-like detection; doesn't check for ACLs, or MAC info) perl - ok (uses eaccess(2) for our OS). python - broken (uses straight access(2), so os.access is broken). So now the question is how to fix this? Linux reports the correct mode for the file (when operating as superuser or not), and there's a lot of code outside of *BSD that builds upon that assumption because stat(2) doesn't test for permissions via POSIX ACLs, MAC, etc. I tried munging through the code to determine where VOP_ACCESS was coming from but I got lost. Where should I look for this? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 20 19:00:46 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2C31065670 for ; Tue, 20 Jul 2010 19:00:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D63EA8FC08 for ; Tue, 20 Jul 2010 19:00:45 +0000 (UTC) Received: by iwn35 with SMTP id 35so7483758iwn.13 for ; Tue, 20 Jul 2010 12:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yqkzPvz/67n/P7rPm78riSo1GCjy7mVJFfDAU/8m8QA=; b=qHCA87N5E8DtEL+NM12CnETIy3RyFdK6S/07RY+iJX2nhaPeSQTGYzmiKPq04oHasm 5MrQ2lF3eIP86hELhMukpsNcF6NLfdbiA2Z1miS2XNpqpKQem4cuWngxNXtaxPxJsAsX VuQuf2jj7NU3hCnFPPQTfEsEQgPI4YZybUvgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ahKrrGORmAWIFcS066PAl0qUnRDXQ2ax/ETCZEIsD1DZvsbn13eFoqJp6ac84BtunE OA5DtfdOf9SOMzQ2O/WQv9oWTZWJ3QmqjaZBByaW7Iqp+0GVGlwKXHKItdgYfqUBQVrX zgdBN4A6i8wiRD5J1sd/XdzT5+CxwrQEXiYE4= MIME-Version: 1.0 Received: by 10.231.172.83 with SMTP id k19mr8253552ibz.114.1279652444654; Tue, 20 Jul 2010 12:00:44 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Tue, 20 Jul 2010 12:00:44 -0700 (PDT) In-Reply-To: <20100719120916.GX2381@deviant.kiev.zoral.com.ua> References: <20100719120916.GX2381@deviant.kiev.zoral.com.ua> Date: Tue, 20 Jul 2010 12:00:44 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: [PATCH] Catch errors with sigaddset(3) in sigaddset (sighold) 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, 20 Jul 2010 19:00:46 -0000 On Mon, Jul 19, 2010 at 5:09 AM, Kostik Belousov wrot= e: > On Sun, Jul 18, 2010 at 10:46:25PM -0700, Garrett Cooper wrote: >> =A0 =A0 sighold(3) doesn't determine whether or not the signal added is >> valid today (and sigprocmask doesn't verify that either). This fixes >> that. >> Thanks, >> -Garrett >> >> Index: sigcompat.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sigcompat.c =A0 =A0 =A0 (revision 210226) >> +++ sigcompat.c =A0 =A0 =A0 (working copy) >> @@ -131,7 +131,8 @@ >> =A0 =A0 =A0 sigset_t set; >> >> =A0 =A0 =A0 sigemptyset(&set); >> - =A0 =A0 sigaddset(&set, sig); >> + =A0 =A0 if (sigaddset(&set, sig) =3D=3D -1) >> + =A0 =A0 =A0 =A0 =A0 =A0 return (-1); >> =A0 =A0 =A0 return (_sigprocmask(SIG_BLOCK, &set, NULL)); >> =A0} > > I added checks for failures of sig{add,del}set to the sigcompat.c, > and unified style to not assign intermediate error to local variable. > > This is what I am going to commit shortly. > > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompa= t.c > index 6841eeb..199846f 100644 > --- a/lib/libc/compat-43/sigcompat.c > +++ b/lib/libc/compat-43/sigcompat.c > @@ -112,16 +112,11 @@ int > =A0xsi_sigpause(int sig) > =A0{ > =A0 =A0 =A0 =A0sigset_t set; > - =A0 =A0 =A0 int error; > > - =A0 =A0 =A0 if (!_SIG_VALID(sig)) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 errno =3D EINVAL; > + =A0 =A0 =A0 if (_sigprocmask(SIG_BLOCK, NULL, &set) =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-1); > + =A0 =A0 =A0 if (sigdelset(&set, sig) =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (-1); > - =A0 =A0 =A0 } > - =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, NULL, &set); > - =A0 =A0 =A0 if (error !=3D 0) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); > - =A0 =A0 =A0 sigdelset(&set, sig); > =A0 =A0 =A0 =A0return (_sigsuspend(&set)); > =A0} > > @@ -131,7 +126,8 @@ sighold(int sig) > =A0 =A0 =A0 =A0sigset_t set; > > =A0 =A0 =A0 =A0sigemptyset(&set); > - =A0 =A0 =A0 sigaddset(&set, sig); > + =A0 =A0 =A0 if (sigaddset(&set, sig) =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-1); > =A0 =A0 =A0 =A0return (_sigprocmask(SIG_BLOCK, &set, NULL)); > =A0} > > @@ -151,7 +147,8 @@ sigrelse(int sig) > =A0 =A0 =A0 =A0sigset_t set; > > =A0 =A0 =A0 =A0sigemptyset(&set); > - =A0 =A0 =A0 sigaddset(&set, sig); > + =A0 =A0 =A0 if (sigaddset(&set, sig) =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-1); > =A0 =A0 =A0 =A0return (_sigprocmask(SIG_UNBLOCK, &set, NULL)); > =A0} > > @@ -160,35 +157,30 @@ void > =A0{ > =A0 =A0 =A0 =A0sigset_t set, pset; > =A0 =A0 =A0 =A0struct sigaction sa, psa; > - =A0 =A0 =A0 int error; > > =A0 =A0 =A0 =A0sigemptyset(&set); > - =A0 =A0 =A0 sigaddset(&set, sig); > - =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, NULL, &pset); > - =A0 =A0 =A0 if (error =3D=3D -1) > + =A0 =A0 =A0 if (sigaddset(&set, sig) =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (SIG_ERR); > + =A0 =A0 =A0 if (_sigprocmask(SIG_BLOCK, NULL, &pset) =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_ERR); > =A0 =A0 =A0 =A0if ((__sighandler_t *)disp =3D=3D SIG_HOLD) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D _sigprocmask(SIG_BLOCK, &set, &ps= et); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (_sigprocmask(SIG_BLOCK, &set, &pset) = =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_ERR); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (sigismember(&pset, sig)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_HOLD); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D _sigaction(sig, N= ULL, &psa); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (_sigaction(sig, NULL, &= psa) =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SI= G_ERR); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (psa.sa_handler); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0} else { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D _sigprocmask(SIG_UNBLOCK, &set, &= pset); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D -1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (_sigprocmask(SIG_UNBLOCK, &set, &pset) = =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_ERR); > =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0bzero(&sa, sizeof(sa)); > =A0 =A0 =A0 =A0sa.sa_handler =3D disp; > - =A0 =A0 =A0 error =3D _sigaction(sig, &sa, &psa); > - =A0 =A0 =A0 if (error =3D=3D -1) > + =A0 =A0 =A0 if (_sigaction(sig, &sa, &psa) =3D=3D -1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_ERR); > =A0 =A0 =A0 =A0if (sigismember(&pset, sig)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (SIG_HOLD); The results when I ran the tests manually outside of the shell script were ok. I need to track down why they're failing in the script itself. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 03:02:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45715106564A; Wed, 21 Jul 2010 03:02:53 +0000 (UTC) (envelope-from tajudd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EFD4A8FC12; Wed, 21 Jul 2010 03:02:52 +0000 (UTC) Received: by iwn35 with SMTP id 35so8051078iwn.13 for ; Tue, 20 Jul 2010 20:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=j88cdHhVg7Wak8uQp0q0VO06ZsKB+im4G5wx8+7zGnc=; b=G92u+pXqRFc/W9fn4wRxvdUBBuLEBMZg8T94hhggqqlRH4z/VFOddocIY/isWSIuJr U9NA79541IzczGJIkue5KdGJa11Ax2gQom245sAvF7z7jBmOtpKTcC7UUadvViySFS4+ aL7GNhITQe5RUmDquUYSJ+0xZHFmvF+q16MSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nr90H/pp/KnN0RlQ4+/VonwvWfGmK/aaEj6MSUj6O8xo416C9uoqE1CopGJ74w7taF QKNQUahqerWvZ1CHRbBvy1OABe455W3GCxaB8sxIuR/39wi/al9PBHWEcvx2mtj6P0Dk H7z/G9j8Ko4bJ9qCFViMS8wiE5H3u9NqcS4io= MIME-Version: 1.0 Received: by 10.231.30.130 with SMTP id u2mr7399776ibc.111.1279681372281; Tue, 20 Jul 2010 20:02:52 -0700 (PDT) Received: by 10.231.180.135 with HTTP; Tue, 20 Jul 2010 20:02:52 -0700 (PDT) In-Reply-To: <201007201052.03140.jhb@freebsd.org> References: <201007201052.03140.jhb@freebsd.org> Date: Tue, 20 Jul 2010 21:02:52 -0600 Message-ID: From: Tim Judd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel modules into static kernel 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, 21 Jul 2010 03:02:53 -0000 On 7/20/10, John Baldwin wrote: > On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: >> Hellos, >> >> >> Of interest, I can get GEOM_UZIP kernel module as part of the kernel, >> but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build >> a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the >> kernel? > > Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for > 'uzip' to see what GEOM_UZIP includes in the build). > > -- > John Baldwin > Extremely appreciated. Thanks John From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 07:40:08 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901651065676; Wed, 21 Jul 2010 07:40:08 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 4B86F8FC16; Wed, 21 Jul 2010 07:40:08 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id F08AF2167AD; Wed, 21 Jul 2010 10:22:25 +0300 (EEST) Date: Wed, 21 Jul 2010 10:22:25 +0300 From: Jaakko Heinonen To: Garrett Cooper Message-ID: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: standards@freebsd.org, hackers@freebsd.org Subject: Re: Chasing down bugs with access(2) 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, 21 Jul 2010 07:40:08 -0000 Hi, On 2010-07-20, Garrett Cooper wrote: > I ran into an issue last night where apparently several apps make > faulty assumptions w.r.t. whether or not access(2) returns functional > data when running as a superuser. > New implementations are discouraged from returning X_OK unless at > least one execution permission bit is set. See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009). Here is the latest version of the vaccess*() patch which also changes vaccess_acl_nfs4(): http://people.freebsd.org/~jh/patches/vaccess-VEXEC.diff The patch is not a complete fix however. Not all file systems use vaccess*() for VEXEC in their VOP_ACCESS() (ZFS confirmed). Thus the patch doesn't work with ZFS. -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 10:34:41 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED3BA1065676; Wed, 21 Jul 2010 10:34:41 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4E7E8FC12; Wed, 21 Jul 2010 10:34:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so8465736iwn.13 for ; Wed, 21 Jul 2010 03:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iiGO5+L2mjGmUIsd0GgnQK44tBX79u0TgzmdJXPe0TI=; b=UKsLGO2Axf3NJtnKaNmKygJFMbn5+VMfjMD3Lvo6DHElQbdNaBhCw+zW5s+E4szi7M 5/3eSZJ2p1z3LiZlkAvp27n6dyAF9zLJ8XNTQplkfd3G0mwN71X1W0XKC6ru2F5/4JkS QTmqHVBaZdWxHcfAcUrTy87AlBNz1UVg7C9QI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dcScXkXK9byPpyGDeXkrMirq/vtYXKjzm5bLqlkieNgPNOLNKtEB1R6KGgwODvc1Be W9dGA42iHgCoHEB4rzEwCz5Nt8RoC/EXalagndc6YWKXlTLXS3j3edsutzhdBSqtJfoT I38SXQQB/fQ3788QRG0b5I0M6+MTpCfVR8u3o= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr8986308iba.67.1279708480674; Wed, 21 Jul 2010 03:34:40 -0700 (PDT) Received: by 10.231.169.18 with HTTP; Wed, 21 Jul 2010 03:34:40 -0700 (PDT) In-Reply-To: <20100721162044.N7348@delplex.bde.org> References: <20100721162044.N7348@delplex.bde.org> Date: Wed, 21 Jul 2010 03:34:40 -0700 Message-ID: From: Garrett Cooper To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: standards@freebsd.org, hackers@freebsd.org Subject: Re: Chasing down bugs with access(2) 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, 21 Jul 2010 10:34:42 -0000 On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans wrote: > On Tue, 20 Jul 2010, Garrett Cooper wrote: ... > This seems wrong for directories. =A0It should say "... unless the file > is 'executable'". =A0'executable' means searchable for directories, and > the above shouldn't apply. =A0'executable' actually means executable for > regular files, and the above should only apply indirectly: it is > executability that should be required to have an X perm bit set, and > then access() should just track the capability. =A0The usual weaseling > with "appropriate privilege" allows the X perm bits to have any control > on executablity including none, and at least the old POSIX spec doesn't > get in the way of this, since it doesn't mention the X perm bits in > connection with the exec functions. =A0The spec goes too far in the other > direction for the access function. Agreed (for all of the above). >> FreeBSD says: >> >> =A0 =A0Even if a process's real or effective user has appropriate privil= eges >> and >> =A0 =A0indicates success for X_OK, the file may not actually have execut= e per- >> =A0 =A0mission bits set. =A0Likewise for R_OK and W_OK. > > Perhaps it is time to fix this. =A0The part about X_OK never applied to a= ny > version of FreeBSD. =A0Perhaps it applied to the version o= f > execve() in Net/2 and 4.4BSD, but FreeBSD had to reimplement execve() and > it never had this bug. =A0But^2, the access() syscall and man page weren'= t > changed to match. =A0See the end of this reply for more details on execve= (). > See the next paragraph about more bugs in the above paragraph. > > Other bugs: > - R_OK and W_OK are far from likewise. =A0Everone knows that root can rea= d > =A0and write any file. Yes. Thankfully Linux also agrees on this point (I say this, because portability between Linux and BSD helps ease porting pains). > - The permission bits are relatively uninteresting. =A0access() should tr= ack > =A0the capability, not the bits. =A0The bits used to map to the capabilit= y > =A0directly for non-root, but now with ACLs, MAC, etc. they don't even do > =A0that. > - access(2) has no mention of ACLs, MAC, etc. No, sadly it doesn't (and of course POSIX leaves that open in the File permissions section, for good reason: http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap04.html#tag_= 04_04 ). That's the one thing that one of the folks on the bash list brought up that was a valid argument for using access(2), eaccess(2), or faccessat(2) vs stat(2). If you use a straight stat(2) call to determine whether or not a file is executable, the `hint' could be completely bogus as the file itself could be non-executable when the ACL or MAC denies the capability, whereas many implementations of access(2) support this additional permissions checking. > - See a recent PR about unifdefed CAPABILITIES code in vaccess(). =A0(The > =A0comment says that the code is always ifdefed out, but it now always > =A0unifdefed in.) =A0 I don't quite understand this code -- does it give > =A0all of ACLs, MAC and etc. at this level? Interestingly standard permissions bypass ACLs/MAC if standard permissions on the file/directory allow the requested permissions to succeed; note the return (0) vs the priv_check_cred calls -- this is where the the ACL/MAC for the inode is checked. This seems backwards, but I could be missing something.. >> =A0 This results in: >> >> =A0 sh/test - ok-ish (a guy on bash-bugs challenged the fact that the >> syscall was buggy based on the details returned). >> =A0 bash - broken (builtin test(1) always returns true) >> =A0 csh =A0- not really ok (uses whacky stat-like detection; doesn't >> check for ACLs, or MAC info) >> =A0 perl - ok (uses eaccess(2) for our OS). >> =A0 python - broken (uses straight access(2), so os.access is broken). ... > -current also has a MAC check here. =A0I can't see how vaccess(9) does an > equivalent check, or if it does, but if it did then we wouldn't need a > special MAC check here. Agreed. > % =A0 =A0 =A0 /* > % =A0 =A0 =A0 =A0* 1) Check if file execution is disabled for the filesys= tem that > this > % =A0 =A0 =A0 =A0* =A0 =A0 =A0file resides on. > % =A0 =A0 =A0 =A0* 2) Insure that at least one execute bit is on - otherw= ise root > % =A0 =A0 =A0 =A0* =A0 =A0 =A0will always succeed, and we don't want to h= appen unless the > % =A0 =A0 =A0 =A0* =A0 =A0 =A0file really is executable. > % =A0 =A0 =A0 =A0* 3) Insure that the file is a regular file. > % =A0 =A0 =A0 =A0*/ > % =A0 =A0 =A0 if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || > % =A0 =A0 =A0 =A0 =A0 ((attr->va_mode & 0111) =3D=3D 0) || > % =A0 =A0 =A0 =A0 =A0 (attr->va_type !=3D VREG)) { > % =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EACCES); > % =A0 =A0 =A0 } > > 0111 is an old spelling of the S_IX* bits. =A0We check these directly > since we know that VOP_ACCESS() is broken for root. =A0It is also good > to avoid calling VOP_ACCESS() first, since VOP_ACCESS() would record > our use of suser() privilege when in fact we won't use it. > > Yet 2 more bugs: not just point 2, but points 1 and 3 in the above > comment are undocumented in execve(2) and access(2). =A0The usual weaseli= ng > with "appropriate privilege" should allow these too, but (as I forgot > to mention above) I think "appropriate privilege" is supposed to be > documented somewhere, so the man pages are still missing details. Agreed on the former statement, and I understand the reasoning for the latter statement, but at least for 1., this is a feature of mount(2) (of course): MNT_NOEXEC Do not allow files to be executed from the file syste= m. ... Yes. The usual warning about the `hinting' being done by *access(2) is fine= :). -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 09:03:05 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5999106564A; Wed, 21 Jul 2010 09:03:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 365758FC18; Wed, 21 Jul 2010 09:03:04 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L930EU007859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 19:03:01 +1000 Date: Wed, 21 Jul 2010 19:03:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jaakko Heinonen In-Reply-To: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> Message-ID: <20100721185227.N7492@delplex.bde.org> References: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 21 Jul 2010 11:15:57 +0000 Cc: Garrett Cooper , standards@freebsd.org, hackers@freebsd.org Subject: Re: Chasing down bugs with access(2) 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, 21 Jul 2010 09:03:05 -0000 On Wed, 21 Jul 2010, Jaakko Heinonen wrote: > On 2010-07-20, Garrett Cooper wrote: >> I ran into an issue last night where apparently several apps make >> faulty assumptions w.r.t. whether or not access(2) returns functional >> data when running as a superuser. > >> New implementations are discouraged from returning X_OK unless at >> least one execution permission bit is set. > > See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009). > > Here is the latest version of the vaccess*() patch which also changes > vaccess_acl_nfs4(): > > http://people.freebsd.org/~jh/patches/vaccess-VEXEC.diff > > The patch is not a complete fix however. Not all file systems use > vaccess*() for VEXEC in their VOP_ACCESS() (ZFS confirmed). Thus the > patch doesn't work with ZFS. I looked at the patches in the PR. It seems reasonable to require an X but for VEXEC for all file types except directories, like I think the vaccess() version of your patch does. Keeping the existing behaviour for directories seems necessary. E.g., suppose a user changes all his files and directories to mode 000. It should still be possible for root to search, not to mention back up, all those files and directories, without clobbering any of their metadata (including atimes, but those are a different problem). Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 10:47:30 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DBE1106566B; Wed, 21 Jul 2010 10:47:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id C3CEF8FC0A; Wed, 21 Jul 2010 10:47:29 +0000 (UTC) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L8ehRa027766; Wed, 21 Jul 2010 18:40:43 +1000 Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6L8ebFA010071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 18:40:39 +1000 Date: Wed, 21 Jul 2010 18:40:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20100721162044.N7348@delplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 21 Jul 2010 11:16:20 +0000 Cc: standards@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Chasing down bugs with access(2) 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, 21 Jul 2010 10:47:30 -0000 On Tue, 20 Jul 2010, Garrett Cooper wrote: > Hi Hackers, > I ran into an issue last night where apparently several apps make > faulty assumptions w.r.t. whether or not access(2) returns functional > data when running as a superuser. > > POSIX says: > In early proposals, some inadequacies in the access() function led > to the creation of an eaccess() function because: > > 1. Historical implementations of access() do not test file > access correctly when the process' real user ID is superuser. In > particular, they always return zero when testing execute permissions > without regard to whether the file is executable. > 2. The superuser has complete access to all files on a system. > As a consequence, programs started by the superuser and switched to > the effective user ID with lesser privileges cannot use access() to > test their file access permissions. > > However, the historical model of eaccess() does not resolve > problem (1), so this volume of IEEE Std 1003.1-2001 now allows > access() to behave in the desired way because several implementations > have corrected the problem. It was also argued that problem (2) is > more easily solved by using open(), chdir(), or one of the exec > functions as appropriate and responding to the error, rather than > creating a new function that would not be as reliable. Therefore, > eaccess() is not included in this volume of IEEE Std 1003.1-2001. > > The sentence concerning appropriate privileges and execute > permission bits reflects the two possibilities implemented by > historical implementations when checking superuser access for X_OK. > > New implementations are discouraged from returning X_OK unless at > least one execution permission bit is set. This seems wrong for directories. It should say "... unless the file is 'executable'". 'executable' means searchable for directories, and the above shouldn't apply. 'executable' actually means executable for regular files, and the above should only apply indirectly: it is executability that should be required to have an X perm bit set, and then access() should just track the capability. The usual weaseling with "appropriate privilege" allows the X perm bits to have any control on executablity including none, and at least the old POSIX spec doesn't get in the way of this, since it doesn't mention the X perm bits in connection with the exec functions. The spec goes too far in the other direction for the access function. > FreeBSD says: > > Even if a process's real or effective user has appropriate privileges and > indicates success for X_OK, the file may not actually have execute per- > mission bits set. Likewise for R_OK and W_OK. Perhaps it is time to fix this. The part about X_OK never applied to any version of FreeBSD. Perhaps it applied to the version of execve() in Net/2 and 4.4BSD, but FreeBSD had to reimplement execve() and it never had this bug. But^2, the access() syscall and man page weren't changed to match. See the end of this reply for more details on execve(). See the next paragraph about more bugs in the above paragraph. Other bugs: - R_OK and W_OK are far from likewise. Everone knows that root can read and write any file. - The permission bits are relatively uninteresting. access() should track the capability, not the bits. The bits used to map to the capability directly for non-root, but now with ACLs, MAC, etc. they don't even do that. - access(2) has no mention of ACLs, MAC, etc. - See a recent PR about unifdefed CAPABILITIES code in vaccess(). (The comment says that the code is always ifdefed out, but it now always unifdefed in.) I don't quite understand this code -- does it give all of ACLs, MAC and etc. at this level? > > This results in: > > sh/test - ok-ish (a guy on bash-bugs challenged the fact that the > syscall was buggy based on the details returned). > bash - broken (builtin test(1) always returns true) > csh - not really ok (uses whacky stat-like detection; doesn't > check for ACLs, or MAC info) > perl - ok (uses eaccess(2) for our OS). > python - broken (uses straight access(2), so os.access is broken). > > So now the question is how to fix this? Linux reports the correct > mode for the file (when operating as superuser or not), and there's a > lot of code outside of *BSD that builds upon that assumption because > stat(2) doesn't test for permissions via POSIX ACLs, MAC, etc. > I tried munging through the code to determine where VOP_ACCESS was > coming from but I got lost. Where should I look for this? Mostly it is in vaccess(9). But execve() mostly doesn't use VOP_ACCESS(). Here is the FreeBSD-1 version, which is a bit shorter and thus easier to understand than the current version, and shows that FreeBSD has always required 1 exec bit for execve(): % /* % * Check permissions of file to execute. % * Return 0 for success or error code on failure. % */ % int % exec_check_permissions(iparams) % struct image_params *iparams; % { % struct proc *p = iparams->proc; % struct vnode *vnodep = iparams->vnodep; % struct vattr *attr = iparams->attr; % int error; % % /* % * Check number of open-for-writes on the file and deny execution % * if there are any. % */ % if (vnodep->v_writecount) { % return (ETXTBSY); % } % % /* Get file attributes */ % error = VOP_GETATTR(vnodep, attr, p->p_ucred, p); % if (error) % return (error); % -current also has a MAC check here. I can't see how vaccess(9) does an equivalent check, or if it does, but if it did then we wouldn't need a special MAC check here. % /* % * 1) Check if file execution is disabled for the filesystem that this % * file resides on. % * 2) Insure that at least one execute bit is on - otherwise root % * will always succeed, and we don't want to happen unless the % * file really is executable. % * 3) Insure that the file is a regular file. % */ % if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || % ((attr->va_mode & 0111) == 0) || % (attr->va_type != VREG)) { % return (EACCES); % } 0111 is an old spelling of the S_IX* bits. We check these directly since we know that VOP_ACCESS() is broken for root. It is also good to avoid calling VOP_ACCESS() first, since VOP_ACCESS() would record our use of suser() privilege when in fact we won't use it. Yet 2 more bugs: not just point 2, but points 1 and 3 in the above comment are undocumented in execve(2) and access(2). The usual weaseling with "appropriate privilege" should allow these too, but (as I forgot to mention above) I think "appropriate privilege" is supposed to be documented somewhere, so the man pages are still missing details. % % /* % * Zero length files can't be exec'd % */ % if (attr->va_size == 0) % return (ENOEXEC); % % /* % * Disable setuid/setgid if the filesystem prohibits it or if % * the process is being traced. % */ % if ((vnodep->v_mount->mnt_flag & MNT_NOSUID) || (p->p_flag & STRC)) % attr->va_mode &= ~(VSUID | VSGID); % % /* % * Check for execute permission to file based on current credentials. % * Then call filesystem specific open routine (which does nothing % * in the general case). % */ % error = VOP_ACCESS(vnodep, VEXEC, p->p_ucred, p); % if (error) % return (error); We still use VOP_ACCESS() to handle the access checking in the usual case where 1 X bit is set. But this is not quite access(2) -- it uses the effective credentials, so is close to eaccess(2). % % error = VOP_OPEN(vnodep, FREAD, p->p_ucred, p); % if (error) % return (error); % % return (0); % } FreeBSD's man page also says: % SECURITY CONSIDERATIONS % The access() system call is a potential security hole due to race condi- % tions and should never be used. Set-user-ID and set-group-ID applica- % tions should restore the effective user or group ID, and perform actions % directly rather than use access() to simulate access checks for the real % user or group ID. The eaccess() system call likewise may be subject to % races if used inappropriately. This covers more than POSIX's point 2. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 13:13:56 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D07DE106566C; Wed, 21 Jul 2010 13:13:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4F69F8FC14; Wed, 21 Jul 2010 13:13:55 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6LDDqo5002550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 23:13:53 +1000 Date: Wed, 21 Jul 2010 23:13:52 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20100721221551.B7582@delplex.bde.org> References: <20100721162044.N7348@delplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-468481727-1279718032=:7582" X-Mailman-Approved-At: Wed, 21 Jul 2010 15:43:39 +0000 Cc: standards@FreeBSD.org, hackers@FreeBSD.org, Bruce Evans Subject: Re: Chasing down bugs with access(2) 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, 21 Jul 2010 13:13:56 -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-468481727-1279718032=:7582 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Jul 2010, Garrett Cooper wrote: > On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans wrote= : >> - See a recent PR about unifdefed CAPABILITIES code in vaccess(). =A0(Th= e >> =A0comment says that the code is always ifdefed out, but it now always >> =A0unifdefed in.) =A0 I don't quite understand this code -- does it give >> =A0all of ACLs, MAC and etc. at this level? > > Interestingly standard permissions bypass ACLs/MAC if standard > permissions on the file/directory allow the requested permissions to > succeed; note the return (0) vs the priv_check_cred calls -- this is > where the the ACL/MAC for the inode is checked. This seems backwards, > but I could be missing something.. I was wrong to say that vaccess() does most of the checking. This is only correct if there are no ACLs, etc. Otherwise, e.g., for ffs, the layering is more like VOP_ACCESS() -> ufs_access() =3D check r/o ffs check quota (bogusly in the clause whose comment says that it checks =09for a r/o fs, deep in the case statement for that clause. This =09was readable when that clause was only 16 lines long, but now =09it has messy locking for quotas, and large comments about this, =09so it is 44 lines long, with the number of lines for locking =09up from 4 to 32) check immutability. Another bug in access()'s man page is that it =09doesn't mention either immutability or the errno EPERM that at =09least ufs_access() returns for it. check acls call vaccess(). The MAC checks seem to be at the end of this and are unrelated to acls. But for exec_check_permissions(), the MAC checks are first. > ... >> % =A0 =A0 =A0 /* >> % =A0 =A0 =A0 =A0* 1) Check if file execution is disabled for the filesy= stem that >> this >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0file resides on. >> % =A0 =A0 =A0 =A0* 2) Insure that at least one execute bit is on - other= wise root >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0will always succeed, and we don't want to = happen unless the >> % =A0 =A0 =A0 =A0* =A0 =A0 =A0file really is executable. >> % =A0 =A0 =A0 =A0* 3) Insure that the file is a regular file. >> % =A0 =A0 =A0 =A0*/ >> % =A0 =A0 =A0 if ((vnodep->v_mount->mnt_flag & MNT_NOEXEC) || >> % =A0 =A0 =A0 =A0 =A0 ((attr->va_mode & 0111) =3D=3D 0) || >> % =A0 =A0 =A0 =A0 =A0 (attr->va_type !=3D VREG)) { >> % =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EACCES); >> % =A0 =A0 =A0 } Your mail program seems to be responsible for making the above unreadable by changing tabs to hard \xa0's (which are displayed as tabs by my mail client(s?), but soft \xa0's followed by a space by my editor. >> 0111 is an old spelling of the S_IX* bits. =A0We check these directly Maybe the changes weren't of tabs. In this paragraphs, sentence breaks of 2 spaces got changed to 1 space followed by a hard \xa0. >> Yet 2 more bugs: not just point 2, but points 1 and 3 in the above >> comment are undocumented in execve(2) and access(2). =A0The usual weasel= ing >> with "appropriate privilege" should allow these too, but (as I forgot >> to mention above) I think "appropriate privilege" is supposed to be >> documented somewhere, so the man pages are still missing details. > > Agreed on the former statement, and I understand the reasoning for the > latter statement, but at least for 1., this is a feature of mount(2) > (of course): > > MNT_NOEXEC Do not allow files to be executed from the file syst= em. How is a newbie supposed to know to look in mount(2) to find extra failure cases? execve(2) even cross-references mount(8), but this was in connectio= n with the nosuid mount option in a wrong man page: % Index: execve.2 % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/lib/libc/sys/execve.2,v % retrieving revision 1.11 % retrieving revision 1.12 % diff -u -2 -r1.11 -r1.12 % --- execve.2=0911 Jan 1998 21:43:38 -0000=091.11 % +++ execve.2=0927 Apr 1999 03:56:10 -0000=091.12 % @@ -31,5 +31,5 @@ % .\" % .\" @(#)execve.2=098.5 (Berkeley) 6/1/94 % -.\" $Id$ % +.\" $Id: execve.2,v 1.11 1998/01/11 21:43:38 alex Exp $ % .\" % .Dd June 1, 1994 % @@ -144,4 +144,9 @@ % .ne 1i % .Pp % +The set-ID bits are not honored if the respective file system has the % +.Ar nosuid % +option enabled or if the new process file is an interpreter file. Sysca= ll % +tracing is disabled if effective IDs are changed. % +.Pp % The new process also inherits the following attributes from % the calling process: % @@ -274,4 +279,6 @@ % .Xr exit 3 , % .Xr sysctl 3 , % +.Xr mount 1 , This dangling pointer was fixed to mount(8) in the next commit. But it should have been to mount(2) for MNT_NOSUID. % +.Xr ktrace 1 , % .Xr environ 7 % .Sh HISTORY I strongly dislike general references to man pages for 1 detail. There should be an Xr where each of the nosuid and tracing details is described and none at the end. There are actually many details of interest here, but how is a newbie going to notice this when the committers didn't? Details of interest are at least: - MNT_RDONLY (related to EROFS error) - MNT_NOSUID - MNT_NOEXEC - MNT_ACLS (new) - MNT_QUOTA Better yet, nmount() allows any number of new mount options that might affect access(), and you should have to read all the section 5 or 7 man pages for file systems to find them all (unless access() documents them all), but these man pages mostly don't exist and/or have few details, so you would have to read all section 8 man pages for mount utilities. Bruce --0-468481727-1279718032=:7582-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 14:28:55 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26F5106564A; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 768308FC27; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MEStP6035807; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MEStnW035806; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger) Date: Thu, 22 Jul 2010 14:28:55 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20100722142855.GA35739@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Report April-June, 2010 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 14:28:55 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between April and June 2010. It is the second of the four reports planned for 2010, and contains 47 entries. During this period, a lot of work has gone into the development of new minor version of FreeBSD, 8.1-RELEASE, which should be released within days. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Please note that the deadline for submissions covering the period between July and September 2010 is October 15th, 2010. __________________________________________________________________ Google Summer of Code * Binary Package Patch Infrastructure -- pkg_patch * Collective Resource Limits (aka. Jobs) * ExtFS Status Report * File System Changes Notification * Google Summer of Code 2010 * Making Ports Work with Clang * Namecache Improvements -- dircache * Package Management Library -- libpkg * Packet-Capturing Stack -- ringmap Projects * Clang Replacing GCC in the Base System * DAHDI/FreeBSD Project * Distributed Audit * General-Purpose DMA Framework * GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid * GPIO Framework * New System Installer -- pc-sysinstall * OpenAFS Port * Resource Containers * V4L Support in Linux Emulator FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Core Team Election * Release Engineering Team * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * libnetstat(3) Kernel * Interrupt Threads * Jail-Based Virtualization * Kernel Event Timers Infrastructure * ZFS Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Japanese Documentation Project * The FreeBSD Spanish Documentation Project Userland Programs * BSD-Licensed grep in Base System * BSD-Licensed iconv in Base System * FreeBSD Services Control -- fsc Architectures * Flattened Device Tree for Embedded FreeBSD * FreeBSD on the Sony Playstation 3 * FreeBSD/avr32 * FreeBSD/powerpc64 * FreeBSD/sparc64 Ports * Chromium Web Browser * FreeBSD Haskell * Ports Collection Miscellaneous * BSD-Day@2010 * BSDCan * meetBSD 2010 -- The BSD Conference __________________________________________________________________ Binary Package Patch Infrastructure -- pkg_patch URL: http://wiki.FreeBSD.org/IvanVoras/pkg_patch Contact: Ivan Voras The pkg_patch project is about creating a binary package patch infrastructure which would allow users to patch their live system's packages in an easy and efficient way. It is a C program written to interface with libpkg (for things which are common to all pkg utilities) meant to be included in the base system when it is done. It comes with built-in mass patch creation and application commands. It is funded by Google Summer of Code 2010. Open tasks: 1. Finish the project. 2. Get some testing for it. 3. Convince the Port Management Team it is actually a Good Thing to have even as an experimental feature. 4. Agree upon the policy on which package patches will be created (i.e. from which point in time to which point in time), assuming the "stable" package tree idea has still not gotten traction. __________________________________________________________________ BSD-Day@2010 URL: http://wiki.freebsd.org/BSDDay_2010 Contact: Gábor Páli The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organization, and to provide an interface for real-life communication. There are no formalities, no papers, and no registration or participation fee. However the invited developers are encouraged to give a talk on their favorite BSD-related topic or join the live forum, then have a beer with the other folks around. The goal is to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Budapest, Hungary at Eötvös Loránd University, Faculty of Informatics on November 20, 2010. Open tasks: 1. Apply as a developer, we are still looking for BSD people in the area. __________________________________________________________________ BSD-Licensed grep in Base System URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc/grep Contact: Gábor Kövesdán A portbuild test showed that grep is basically ready to enter HEAD, but there were a few failures that seem to be related. These have to be investigated and fixed before committing grep to 9-CURRENT. Open tasks: 1. Investigate and fix some minor issues. __________________________________________________________________ BSD-Licensed iconv in Base System URL: http://kovesdan.org/patches/iconv-20100708.diff Contact: Gábor Kövesdán The work has been completed and the GNU compatibility levels seems to be quite high. One exception is the fallback support. It is difficult to implement that facility in this implementation because the design is somewhat different. Probably, it will not be a big problem because that functionality is not even documented in the GNU version so few applications might use it. Open tasks: 1. Run a portbuild test and solve possible problems that show up. __________________________________________________________________ BSDCan URL: http://www.BSDCan.org/2010/ Contact: Dan Langille BSDCan 2010 was our 7th conference. As has become the custom, a FreeBSD developer summit was held in the two days before the conference. Record numbers attended the Dev Summit which carried over into the conference proper. It was great to see representatives from so many more companies. I saw many great ideas take root and the start of cooperation on several projects. The talks during the Dev Summit are beginning to attract a wider audience, and we have been talking about opening this up to the general audience by creating a fourth track at BSDCan 2011. As impossible as it sounds, each year has seen an increase in the quality of talks and the number of proposals submitted. Open tasks: 1. I need people to help with various pre-conference tasks: website updates, booking travel, etc. __________________________________________________________________ Chromium Web Browser URL: http://chromium.hybridsource.org URL: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=146302 Contact: Ruben Chromium is a Webkit-based web browser that is largely BSD-licensed. It works very well on FreeBSD and supports new features like HTML 5 video. This effort uses a new hybrid-source model, where the FreeBSD patches are largely kept closed for a limited time. I submitted Chromium to ports a couple of months ago and recently updated the submission to the stable 5.0.375 branch. The port is ready to be committed pending final legal approval by the FreeBSD Foundation. Further work remains to port Chromium to FreeBSD completely, such as porting the task manager fully and making sure extensions work properly. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach In the past quarter we imported Clang into FreeBSD and it is being built by default on i386/amd64/powerpc. We have not yet commited the necessary changes to let world compile with Clang. Some bugs and warnings were fixed in HEAD as a result of the Clang import and people are exploring more and more areas (DTrace, etc). There are some bug fixes in Clang/LLVM as well that stem from the import (unknown pragmas warnings, etc). Roman Divacky and Matthew Fleming are working on ELF writer in LLVM. This is meant as a replacement for assembler (currently we use an outdated GNU as(1)). This work is progressing nice, currently it is able to produce working variants of hello world in C and C++, and some other small programs from "configure run". Open tasks: 1. Import of newer Clang/LLVM into HEAD. 2. Help with ARM/MIPS/SPARC64. 3. Start pushing src patches into HEAD. 4. More testing of Clang on third-party applications (ports). 5. More work on the ELF writer. __________________________________________________________________ Collective Resource Limits (aka. Jobs) URL: http://wiki.FreeBSD.org/G%C3%A1borSoC2010 URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 010/gabor_jobs/irix_jobs Contact: Gábor Kövesdán The SGI IRIX operating system has a concept, called job, which is used to group processes together and then apply resource limits on them. The purpose of this project is to implement this facility on FreeBSD. I spent most of the time familiarizing myself with how things are done inside the kernel, how syscalls work, etc. So far, I have the basic understanding needed and I added the most important syscalls to group processes together into jobs and manipulate collective resource limits on them. There is a bug, which I am tracking down at the moment, after this I can start to implement actual resource limit enforcement. For some of the limit types, it will be relatively easy but some others will take more effort and studies. Open tasks: 1. Fix the showstopper bug, which prevent me working on actual limit enforcement. 2. Implement limit enforcements for all of the limits supported by IRIX. 3. Add support for userland facilities and make utilities jobs-aware, like showing jobs in ps(1), etc. __________________________________________________________________ DAHDI/FreeBSD Project URL: http://www.asterisk.org/dahdi/ URL: https://spreadsheets.google.com/pub?key=0Arw6eRL10yIwdGhLdGJWUHF4b3ExQz Bsd3BGd2tublE&hl=en&single=true&gid=0&output=html Contact: Max Khon The purpose of DAHDI/FreeBSD project is to make it possible to use FreeBSD as a base system for software PBX solutions. DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source device driver framework and a set of hardware drivers for E1/T1, ISDN digital, and FXO/FXS analog cards [1]. Asterisk is one of the most popular open-source software PBX solutions [2]. The project includes porting DAHDI framework and hardware drivers for E1/T1, FXO/FXS analog, and ISDN digital cards to FreeBSD. This also includes TDMoE support, software and HW echo cancellation (Octasic, VPMADT032), and hardware transcoding support (TC400B). The work is ongoing in the official DAHDI SVN repository with the close collaboration with DAHDI folks at Digium. The project is nearing completion. The DAHDI framework and hardware drivers telephony cards have been ported and tested. There are a number of success stories from early adopters who have been using E1/T1 and FXO/FXS cards on FreeBSD for several months. __________________________________________________________________ Distributed Audit URL: http://p4web.freebsd.org/@md=d&cd=//&c=wHa@//depot/projects/soc2010/dis audit/?ac=83 URL: http://wiki.FreeBSD.org/SOC2010SergioLigregni Contact: Sergio Ligregni 90% of the functionality is working, the daemons sync two systems in a master-slave paradigm. Open tasks: 1. Standardize the code to meet FreeBSD requirements. 2. Implement SSL in network communication. 3. Perform security improvements and bug fixing, strlxxx() functions, memcpy() instead of strcpy() when using non-char variables. 4. Integrate with the current Audit subsystem. __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDfoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart SIFTR was recently imported into HEAD and will be backported to 8-STABLE in time to be included in 8.2-RELEASE. TCP reassembly queue autotuning will be ready for public testing within the next week and will be committed soon after. It too will be backported to 8-STABLE after an appropriate burn in period. Open tasks: 1. Try SIFTR out and let me know if you run into any problems. 2. Solicit external testing for and commit the reassembly queue autotuning patch. __________________________________________________________________ ExtFS Status Report URL: http://wiki.FreeBSD.org/SOC2010ZhengLiu Contact: Zheng Liu This project has two goals: pre-allocation algorithm and ext4 read-only mode. The aim of pre-allocation algorithm is to implement a reservation window mechanism. Now this mechanism has been introduced. The performance comparison can be found on the wiki. The aim of ext4 read-only mode is to make it possible to read ext4 file system in read-only mode when the hard disk is formatted with default features. Currently it only supports a few features, such as extents, huge_file. Others features will be added, such as dir_index, uninit_bg, dir_nlink, flex_bg and extra_isize. My work resides in extfs and ext4fs branch of Perforce. __________________________________________________________________ File System Changes Notification Contact: Ilya Putsikau The aim of the project is to implement an inotify-compatible file system change notification mechanism for FreeBSD and later, and add inotify support to linuxulator. The result, fsnotify is already functional but not yet compatible with inotify in some details. Open tasks: 1. Add access permissions checks. 2. Port inotify test cases. 3. Fix compatibility issues. 4. Add linuxulator support. __________________________________________________________________ Flattened Device Tree for Embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree Contact: Rafal Jaworowski The purpose of this project was to provide FreeBSD with support for the Flattened Device Tree (FDT) technology. A mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, MIPS, PowerPC), where a lot of designs are based on similar chips, but have different assignment of pins, memory layout, addresses ranges, interrupts routing and other resources. Current state highlights: * All code and documentation developed during the course of this project was merged with HEAD, which covers FDT support for the following platforms and systems: * Marvell ARM + DB-88F5182 + DB-88F5281 + DB-88F6281 + DB-78100 + SheevaPlug * Freescale PowerPC + MPC8555CDS + MPC8572DS * The FDT infrastructure (bus drivers, helper libraries, and routines shared across architectures and platforms) allows for easier porting to new platforms or variations. The initially supported systems offer a working example of how to migrate towards FDT approach. Work on this project was sponsored by the FreeBSD Foundation. Open tasks: 1. Improve how-to and guidelines for new adopters (how to convert to FDT and so on). 2. Migrate more existing embedded FreeBSD platforms (ARM, MIPS) to FDT approach. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://wiki.FreeBSD.org/Bugathons URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/easy_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/prs_for_all_groups.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth After a long hiatus, we aim to hold a bugathon on the weekend of the 6th - 9th August. Everybody is welcome to help resolve or progress PRs from the database. We appreciate the help of committers and non-committers alike, please join us on IRC in #freebsd-bugbusters on EFnet if you are free at any time over that weekend and can help. Please see the "Bugathon" URL for more information. Mark Linimon and Gavin Atkinson held a session on the State of Bugbusting at BSDCan, which was well attended and led to some interesting discussions. Time was also found to sit down with several committers to discuss long-standing PRs. The bugbusting team continue work on trying to make the GNATS PR database more accessible and easier for committers to find and resolve PRs. As a result, PRs continue to be classified as they arrive, by adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. Reports are generated from these nightly, grouping related PRs in one place, sorted by tag or man page. Mark Linimon continues work on producing a new report, Summary Chart of PRs with Tags, which sorts tagged PRs into logical groups such as file system, network drivers, libraries, and so forth. The slice labels are clickable and may further subdivide the groups. The chart is updated once a day. You can consider it as a prototype for browsing "subcategories" of kernel PRs. The "recommended list" has been split up into "non-trivial PRs which need committer evaluation" and the "easy list" of trivial PRs, to try to focus some attention on the latter. Various new reports exist, including "PRs containing code for new device drivers", "PRs which are from FreeBSD vendors or OEMs", and "PRs referencing other BSDs". It is now possible for interested parties to be emailed a weekly, customized, report similar in style to the above. If you are interested in setting one up, contact linimon@FreeBSD.org. Our clearance rate of PRs, especially in kern and bin, seems to be improving. The number of non-ports PRs has stayed almost constant since the last status report. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Plan and manage the bugathon in August, and get as many people as possible interested in participating. 2. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Core Team Election Contact: Core Team The 2010 FreeBSD core team election was recently completed. The FreeBSD core team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The core team has been elected by FreeBSD developers every 2 years since 2000, and this marks our 6th democratically elected core team. The new core team would like to thank outgoing members Kris Kennaway, Giorgos Keramidas, George V. Neville-Neil, Murray Stokely, and Peter Wemm for their service over the past two (and in some cases, many more) years. The core team would also especially like to thank Dag-Erling SmÅ™grav for running the election. The newly elected core team members are: * John Baldwin * Konstantin Belousov * Warner Losh * Pav Lucistnik * Colin Percival The returning core team members are: * Wilko Bulte * Brooks Davis * Hiroki Sato * Robert Watson __________________________________________________________________ FreeBSD Haskell URL: http://wiki.FreeBSD.org/Haskell URL: http://www.FreeBSD.org/ports/haskell.html URL: http://www.haskell.org/mailman/listinfo/freebsd-haskell Contact: Gábor Páli Contact: Giuseppe Pilichi Contact: Ashish Shukla Our efforts on porting the generalized, general-purpose purely functional programming language, Haskell has rallied, since two new committers, Giuseppe Pilichi and Ashish Shukla joined recently, forming the FreeBSD Haskell Team. Over the last months, FreeBSD/i386 and FreeBSD/amd64 have become Tier-1 platforms, featuring officially supported vanilla binary distributions for the Glasgow Haskell Compiler starting from version 6.12.1. We introduced a unified ports infrastructure for Haskell Cabal ports, which also makes possible the direct translation of Cabal package descriptions to FreeBSD ports. The number of Haskell package ports increases steadily. Open tasks: 1. Improve support for Haskell Cabal packages and their translation. 2. Create a port for Haskell Platform. 3. Add more Haskell package ports. 4. Test and send feedback. __________________________________________________________________ FreeBSD on the Sony Playstation 3 URL: http://svn.FreeBSD.org/viewvc/base/user/nwhitehorn/ps3/ Contact: Nathan Whitehorn Work has begun to port FreeBSD/powerpc64 to the IBM Cell-based Sony Playstation 3, using the OtherOS feature present on some models of the console. As of July 14, the FreeBSD boot loader is ported, and it is possible to netboot a kernel, which has support for the framebuffer, MMU, and device discovery. Once work on drivers for the network interface and interrupt controller is complete, it will be possible to boot the console multi-user. __________________________________________________________________ FreeBSD Services Control -- fsc URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very few resources. The fsc daemon (fscd) runs in the background once the system has started. Services are then added to this daemon via the fscadm control utility, and from there they will be monitored. When they die, depending on the reason, they will be restarted. Certain signals may be ignored (list not decided) and fscd will remove that service from monitoring. Every action is logged to the system logging daemon. Additionally, the fscadm utility may be used to inquire about what services are monitored, their pidfile location, and current process ID. FSC provides several advantages over the third-party daemontools package. For example, fscd uses push notifications instead of polling; fscd is an internal, FreeBSD-maintained software package accessible to all developers, where daemontools would have to be a port and require us to maintain patches; fscd could be easily integrated with the current rc.d infrastructure. Partially based on the ideas of daemontools and Solaris Service Service Mangement Facility (SMF), this could be an extremely useful tool for FreeBSD systems. Open tasks: 1. Testing. Get feedback on how it works in various environments. 2. Code review. 3. Other ideas on the rc.d integration. 4. Update the manual pages. __________________________________________________________________ FreeBSD/avr32 URL: http://wiki.FreeBSD.org/FreeBSD/avr32 Contact: Oleksandr Tymoshenko The FreeBSD/avr32 project was started by Arnar Mar Sing, and actively developed by him and Ulf Lilleengen. It successfully reached single-user stage but since then has not progressed much. At the moment I am trying to get it back into shape. So far some problems with toolchain on i386 host have been fixed, buildkernel succeeds, buildworld succeeds with some exceptions. Next step would be fixing pmap and bringing port back to single-user stage. __________________________________________________________________ FreeBSD/powerpc64 URL: http://people.FreeBSD.org/~nwhitehorn/FreeBSD-9.0-20100715-SNAP-powerpc 64/ Contact: Nathan Whitehorn On July 13, FreeBSD/powerpc64 was integrated into HEAD. This provides support for fully 64-bit operation on 64-bit PowerPC machines conforming to the Book-S specification, including the PowerPC 970, Cell, and POWER4-7. Hardware support is currently limited to Apple machines, although this should expand in the near future. Currently supported hardware: * Apple Xserve G5 * Apple Power Macintosh G5 * Apple iMac G5 __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Since the last status report some issues with cas(4) have been fixed, allowing it to work with Sun GigaSwift Ethernet 1.0 MMF cards (Cassini Kuheen, part no. 501-5524) as well as the on-board interfaces of Sun Fire B100s server blades (for the Sun Fire B1600 platform). Support for Fujitsu (Siemens) PRIMEPOWER 250 based on SPARC64 V CPUs has been added. PRIMEPOWER 450, 650, and 850 likely also work but have not been tested. This also means that the building blocks for support of machines based on SPARC64 VI and VII CPUs like the Fujitsu/Sun SPARC Enterprise Mx000 series are now in place, but they need testing as well. The problems with Schizo version 7 bridges (actually the firmware of these machines) triggering panics during boot finally should be solved. The work on getting Sun Fire V1280 supported has been stalled due to access to such machines no longer being available. The above mentioned improvements are/will be available in FreeBSD 8.1-RELEASE and 7.4-RELEASE. Open tasks: 1. Access to machines based on SPARC64 VI and VII CPUs, like the Fujitsu/Sun SPARC Enterprise Mx000 series would be appreciated. 2. Someone adding support for 64-bit SPARC V9 to Clang/LLVM, and getting it on par with GCC would be appreciated. __________________________________________________________________ General-Purpose DMA Framework URL: http://wiki.FreeBSD.org/SOC2010JakubKlama URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=eCv@//depot/projects/soc2010/jce el_dma/?ac=83 Contact: Jakub Klama This project purpose is adding support for general purpose DMA engines found in most embedded devices. GPDMA framework provides a unified KOBJ interface to DMA engine drivers and unified programming interface to use direct memory transfers in kernel and userspace applications. This project is a part of Google Summer of Code 2010 and it is a work in progress. Current status can be observed on the wiki page. Open tasks: 1. Add support for more DMA engines. 2. Complete, clean up, and merge with HEAD. __________________________________________________________________ GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid URL: http://acm.poly.edu/~spawk/geom_pseudoraid-20100715.tbz Contact: Boris Kochergin The old ata(4) driver is believed to be going away sometime in the future, to be replaced with ATA_CAM [1]. However, ATA pseudo-RAID support in FreeBSD, ataraid(4), is implemented as part of said ata(4) driver, which means that it, too, will be going away. It was decided that pseudo-RAID support is desirable and that it should be reimplemented in GEOM [2] [ 3], which this project aims to do. Currently, RAID-1 arrays can be used on VIA Tech V-RAID and Adaptec HostRAID controllers in a limited capacity. There is no support for writing metadata yet, so disks are not marked degraded, there is no rebuild support, etc. These features are planned, along with support for more hardware and RAID-0 and SPAN arrays. A major setback for the current code is that it uses the device(9) family of functions to identify ATA pseudo-RAID controllers and constructs arrays based on that information. Unfortunately, ATA_CAM does not appear to add its devices to the device tree, so that tactic cannot be used with ATA_CAM. While this is fine for development of the actual RAID parts of the code, the project will be somewhat useless in the absence of the old ata(4) driver. There has been talk of exporting PCI information to GEOM [4] [5], but the work does not appear to have been completed yet. Open tasks: 1. Obtain documentation for or reverse-engineer metadata formats for which there is no write support in the ataraid(4) driver (for example, Adaptec HostRAID). 2. Add CAM support for exporting PCI information to GEOM. __________________________________________________________________ Google Summer of Code 2010 URL: http://wiki.FreeBSD.org/SummerOfCode2010Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson We are once again participating in the Google Summer of Code. This is our 6th year of participation and we hope to once again see great results from our 18 students. Coding officially began May 24th, and we are in the middle of the mid-term evaluation period. You can see and comment on weekly status reports on the mailing list or on the wiki. __________________________________________________________________ GPIO Framework URL: http://wiki.FreeBSD.org/GPIO Contact: Luiz Otavio O Souza Contact: Oleksandr Tymoshenko Implementation of General Purpose Input/Output interface for FreeBSD. Current GPIO bus implementation allows user to control pins from userland and it could be expanded to support various type of peripheral devices. So far there are two drivers: * gpioled provides simple led(4) functionality. * gpioiic implements I2C over GPIO. Framework is used in Alexandr Rybalko's port of FreeBSD to D-Link DIR-320 and in Luis Otavio O Souza's work of bringing FreeBSD to RouterBoard. __________________________________________________________________ Interrupt Threads Contact: John Baldwin For a while I have wanted to rework interrupt threads to address a few issues. The new design uses per-CPU queues of interrupt handlers. Interrupt threads are allocated by a CPU from a pool and bound to that CPU while draining that CPU's queue of handlers. Non-filter handlers can also reschedule themselves at the back of the current CPU's queue while executing. Filters with handlers are now always enabled and should provide a full replacement for the various uses of filters with "fast" taskqueues. A new class of "manual" handlers are also available which are not automatically scheduled, but are only explicitly scheduled from a filter. Thus, a filter can potentially schedule multiple handlers. The code has been tested on amd64, but it needs wider review and testing. I hope to start soliciting review and feedback soon with the goal of getting the code into 9.0. __________________________________________________________________ Jail-Based Virtualization URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#Bjoern URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=Z8Q@//depot/user/bz/vimage/src/? ac=83 Contact: Bjoern A. Zeeb The project started with some cleanup on the network stack after all the import work and adjustments for virtualization to minimize changes to earlier branches. These made it into the tree already and to 8-STABLE, and it will be included in the upcoming 8.1 release. The first major task was to generalize the virtualization framework, so that virtualization of further subsystems would be easier and could be achieved with less duplication. In addition some documentation on the virtual network stack programming was written to help developers virtualizing their code. The interactive kernel debugger support was improved and libjail along with jls and netstat can work on core dumps now and query individual jails and attached virtual network stacks. The second major task was network stack teardown, a concept introduced with the network stack virtualization. The primary goal was to prototype a shutdown of the (virtual) network stacks from top to bottom, which means letting interfaces go last rather than first. Work in this area is still in progress and will have to continue to allow long term stability and a leak and panic free shutdown. The work on this project had been sponsored by the FreeBSD Foundation and CK Software GmbH. Special thanks also to John Baldwin and Philip Paeps for helping with review and suggestions. Open tasks: 1. Merge stabilised change sets. 2. Work further down the network stack freeing all resources for a stable, safe teardown. __________________________________________________________________ Kernel Event Timers Infrastructure Contact: Alexander Motin Modern x86 systems include four different types of event timers: i8254, RTC, LAPIC, and HPET. First three are already supported by FreeBSD. Depending on hardware and loader tunables, periodic interrupts from them are used to trigger all time-based events in kernel. That code has a long history, that made it tangled and at the same time limited and hard-coded. New kernel event timers infrastructure was started to allow different event timer hardware to be operated in uniform way and to allow more features to be supported. Work consists of three main parts: writing machine-independent timer driver API and management code, updating existing drivers and improving HPET driver to support event timers. The new driver API provides unified support for both per-CPU (independent for every CPU core) and global timers in periodic and one-shot modes. Management code at this moment uses only periodic mode, while one-shot mode use is planned by later tickless kernel work. Different kinds of timers have different capabilities and could be present in hardware in different combinations. In every situation the infrastructure automatically chooses two best event timers to supply system with hardclock(), statclock(), and profclock() events. If some timer is not functioning -- it will be replaced. If there is no second timer -- it will be emulated. The administrator may affect that choice using loader tunables during boot and sysctl variables in run-time (kern.eventtimer.*, and so on). Most of the code was recently committed to HEAD. Now it is used by i386 and amd64 architectures. Open tasks: 1. Troubleshoot possible hardware and software issues. 2. Port other architectures to the new infrastructure. 3. Implement tickless kernel, utilizing new features, such as per-CPU and one-shot timers. __________________________________________________________________ libnetstat(3) URL: http://wiki.FreeBSD.org/LibNetstat URL: http://people.FreeBSD.org/~pgj/libnetstat/ URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2009/&c=mGl@//dep ot/projects/soc2009/pgj_libstat/?ac=83 Contact: Gábor Páli Contact: Aman Jassal This project is about creating a wrapper library to support monitoring and management of networking with avoiding direct use of the FreeBSD kvm(3) and sysctl(3) interfaces. This approach would allow the kernel implementation to change and monitoring applications to be extended without breaking applications and requiring them to be recompiled. We decided to merge the sources from the last year's Summer of Code project back to the FreeBSD src/ repository piece by piece, and we have defined several phases of integration. * Standardize the in-kernel networking statistics structures. * Build a sysctl(3) interface, and add export routines. * Add a library, libnetstat(3) to work with the exported information, and to provide further functions in order to support extracting information via kvm(3). This library implements abstractions over the gathered data. * Adapt sources of the existing applications, i.e. netstat(1) and bsnmpd(1) to use the abstractions offered by the library, resulting in a cleaner and simpler code. * Add new applications on the top of the library, e.g. nettop(1). The first phase has been already posted for review. Note that we are looking for a sponsor with an src commit bit and enough time to represent the effort towards the Project. Open tasks: 1. Review the sources. 2. Pick a task from the list, and send patches. 3. Comment the patches, help them to improve. __________________________________________________________________ Making Ports Work with Clang URL: http://wiki.FreeBSD.org/SOC2010AndriusMorkunas URL: http://wiki.FreeBSD.org/PortsAndClang URL: http://rainbow-runner.nl/~andrius/soc/ URL: http://rainbow-runner.nl/clang/patches/ Contact: Andrius Morkunas First part of the project is mostly complete. I added support for new PORTS_CC variable which should be used in make.conf instead of CC to change ports compiler. This allows user to change ports compiler easily, while still respecting USE_GCC. Some patches were written to get ports to work with Clang, and a lot of old patches written prior to the Google Summer of Code project were updated. There are still a lot of broken ports, and some that cannot be built because of Clang/LLVM bugs, but at this point, Clang can build most ports. Open tasks: 1. Fix broken ports that do not work with Clang. 2. Test patched ports with Clang, report Clang bugs. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetbsd.org URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day1# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day2# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010SocialEvent# Contact: meetBSD Information meetBSD 2010 took place on July 2 - 3 in Krakow, Poland at the Faculty of Mathematics and Computer Science building of the Jagiellonian University. The gathering was a much successful event which brought together developers, contributors, and users of the BSD systems from around the world. We had many interesting presentations, of various character and appeal for the diversified audience. Attendees had a chance for taking the BSD Certification exam during the conference, as well as the advantage of face to face side conversations and discussions, which continued long during the social event on Friday night! The conference presentation slides are already available for download. Video recordings edition is being finalized, and their publication is expected shortly. We hope you enjoyed the event and had great time in Krakow. See you again soon! __________________________________________________________________ Namecache Improvements -- dircache URL: http://wiki.FreeBSD.org/SOC2010GlebKurtsov Contact: Gleb Kurtsou I have been reimplementing VFS namecache to make it granularly locked and supporting reliable full-path lookup without calling underlying file system routines. I have successfully implemented directory cache that works in idealized environment with tmpfs. I am currently working on adding support for entries without associated vnodes and for "weak" entries and incomplete cached path. __________________________________________________________________ New System Installer -- pc-sysinstall URL: http://lists.FreeBSD.org/pipermail/svn-src-all/2010-June/025660.html URL: http://www.BSDCan.org/2010/schedule/attachments/142_pc-sysinstall-kris- moore-2010.pdf Contact: Kris Moore Contact: M. Warner Losh The new system installation backend, pc-sysinstall, was merged into HEAD recently and work is already underway to make it more functional and useful as a complete replacement to standard "sysinstall". It is written 100% in shell, not requiring any additional tools from what is standard to FreeBSD. The backend already supports a number of exciting features such as: * ZFS (Including support for raidz/mirror/multiple device pool setups). * Disk encryption via GELI(8). * Auto labeling of file systems with glabel(8). * Big disk support using GPT/EFI. * Full Installation Logging, which is saved to disk for post-install inspection. In addition to the features above, pc-sysinstall is unique, in that every install ends up being a scripted install. Front-ends, be it GUI- or text-based, simply generate the appropriate system configuration file, and pc-sysinstall does the grunt work of the actual installation. This is important for a couple of reasons. First, it makes the task of front-end development much easier by not needing to worry about a backend-driven program flow. Second it means that any front-end can be used to generate the installation configuration file, which can then be copied or modified to perform automated installs. While pc-sysinstall is still relatively new, it is already in use as the default backend for PC-BSD 8.0 and 8.1, and has been getting a very good reception and any bugs found are fixed quickly. A text-based front-end is already in the works which will allow installation media to be created without X11 support. __________________________________________________________________ OpenAFS Port URL: http://openafs.org URL: http://web.mit.edu/freebsd/openafs/openafs.shar Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University; the OpenAFS client implementation has not been particularly useful on FreeBSD since the 4.X releases. Recent work on the OpenAFS codebase has updated it to be consistent with current versions of FreeBSD, and the client, though still considered experimental, is now relatively stable for light (single-threaded) use on 9-CURRENT. The auxiliary utilities for managing and examining the filesystem are functional, and reading and writing files works sufficiently well to copy /usr/src into and out of AFS. Compiling and running executables in AFS is unsuccessful, though, as mmap() is not always reliable. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Fix the {get,put}pages vnode operations for more reliable mmap() operation. 2. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 3. Track down races and deadlocks that appear under load. 4. Integrate with the bsd.kmod.mk kernel-module build infrastructure. __________________________________________________________________ Package Management Library -- libpkg URL: http://wiki.FreeBSD.org/SOC2010DavidForsythe URL: http://code.google.com/p/libpkg Contact: David Forsythe The libpkg library will allow for fairly fine grained control over package management. Presently libpkg has complete read functionality. Info and delete tools that have most of the current package tool features have already been implemented, and once they are completed they can be considered replacements for their counterparts. Once the write and logging aspects of the library are more mature, add and create tools can be created quickly. A new set of more maintainable package tools that leverage libpkg will hopefully be available soon after. __________________________________________________________________ Packet-Capturing Stack -- ringmap URL: http://code.google.com/p/ringmap/ URL: http://ringmap.googlecode.com/files/ringmap_slides.pdf Contact: Alexander Fiveg The ringmap stack is a complete FreeBSD packet-capturing mplementation specialized for very high-speed networks. Similar to the "zero-copy BPF" implementation, the idea of ringmap is to eliminate packet copy operations by using shared memory buffers. However, unlike the "zero-copy BPF" model, ringmap eliminates ALL packet copies during capturing: the network adapter's DMA buffer is mapped directly into user-space. The ringmap stack also adapts libpcap accordingly to provide userspace applications with access to the captured packets without any additional overhead. In the context of Google Summer of Code 2010: * The ringmap software was ported to 9-CURRENT. * Ringmap was redesigned to make it easier to port to other adapters and to integrate it with other network drivers. * Also ringmap was extended to be multi-threaded. Open tasks: 1. Porting ringmap to 10GbE (integrating with ixgbe driver). 2. Porting the entire ringmap code from 9-CURRENT to -STABLE. 3. Evaluation tests. 4. Documentation. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team A significant part of quarter two was spent coordinating efforts for inclusion of Xorg 7.5, KDE 4, GNOME 2, plus preparation of ports for the 8.1 release process. Due to the success of enforcing Feature Safe ports commits during 7.3-RELEASE, it was continued for the recent src/ freeze. The port count is approaching 22,000 ports. The open PR count currently floats at about 1200 entries. Since the last report, we added four new committers, and had two old committers rejoin us. The Ports Management Team is very grateful to the FreeBSD Foundation for sponsoring two new head nodes for the ports building cluster, pointyhat. Each of the new head nodes has a larger capacity, both with regard to performance but also in amount of space available for the staging areas, allowing for faster, and thus more, build cycles. Additionally, having two head nodes will allow us to dedicate one of them for building production-ready binary packages, adding predicability for our users to when what types of packages are available for installation, and dedicate the other for regression testing of large port updates, ports infrastructure improvements, the cluster scheduling code, and FreeBSD itself. Over the last few weeks, Mark Linimon has been working hard to get the first of the two new nodes online and has already completed its first package build. This has involved a substantial rework of our custom codebase. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * ale: Update of math/gmp. * delphij: Changes to Mk/bsd.ldap.mk. * gahr: Inclusion of USE_GL=glew. * pgollucci: Changes to Mk/bsd.*apache.mk plus updates to devel/apr and www/apache*. * Testing of x11/xorg, x11/gnome2, x11/kde4, and lang/mono * A test run make fetch run. * A test run for devel/gettext. * mm: Inclusion of USE_XZ. * ale: Request to switch default mysql from 5.0-EOL to 5.1-GA. alepulver's Licensing Framework Summer of Code project has made it into the tree and the Port Management Team is currently assessing the fallout and it will come up with guidelines and documentation in due time. Open tasks: 1. Looking for help fixing ports broken on 9-CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing, and closing. __________________________________________________________________ Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has been working on the FreeBSD 8.1-RELEASE. At the time of this writing the final builds have been completed and uploaded to the master FTP site. The release announcement should be made within the next couple of days. __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napieral/a As of now, FreeBSD only offers very rudimentary resource controls -- resource limits for many resources (e.g. SysV IPC) are missing, and there is no way to set resource limits for jails. As a result, users who want to run many different workloads on a single physical machine often have to replace jails with several FreeBSD instances running in virtual machines. The goal of this project is to implement resource containers and a simple per-jail resource limits mechanism. Resource containers are also a prerequisite for other resource management mechanisms, such as Hierarchical Resource Limits, for "Collective Limits on Set of Processes (aka. Jobs)" Google Summer of Code 2010 project, for implementing mechanism similar to Linux cgroups, and might be also used to e.g. provide precise resource usage accounting for administrative or billing purposes. This project is being sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for BSDCan in May. We also committed to sponsoring MeetBSD 2010 Poland and California. We provided 12 travel grants for BSDCan. The Foundation and Core Team held a summit on BSD-licensed toolchains at BSDCan 2010. We officially kicked off five new projects that we are funding. They are BSNMP Improvements by Shteryana Shopova, Userland DTrace by Rui Paulo, FreeBSD jail-based virtualization by Bjoern Zeeb, DAHDI FreeBSD driver port by Max Khon, and Resource Containers project by Edward Tomasz Napieral/a. We continued our work on infrastructure projects to beef up hardware for package building, network testing, etc. This includes purchasing equipment as well as managing equipment donations. We are half way through the year and we have raised around $48,000 towards our goal of $350,000. Find out how to make a donation at http://www.FreeBSDFoundation.org/donate/. Our semi-annual newsletter will be published soon. Check out our website to find out more! __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de URL: http://www.FreeBSD.de/mailinglists.html Contact: Johann Kois Contact: Benedict Reuschling A number of updates to the documentation were made since the last status report. We are especially grateful for the contributions from external people who sent the translations. People like Fabian Ruch, who updated the porters-handbook to the latest version (which had been on his to-do list for quite some time), and Benjamin Lukas, who did a great job with the from-scratch translation of the MAC chapter of the German handbook. We thank them both for their contributions and hope they will continue their efforts to enhance the German documentation. Frank Börner was released from Benedicts mentorship and is now a full committer to the German Documentation Project. We are always looking for fresh blood that is willing to be mentored by us as a first step in becoming committers for the documentation project themselves. Johann is keeping up the German website with the latest version. But we could use more translators for sections that are not fully translated yet. Open tasks: 1. Read the translations and report bugs that you have found (even small ones). 2. Translate new parts of the documentation and the website. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli Thanks to Katalin Konkoly, the first few chapters of the FreeBSD Handbook translation have been reviewed, therefore many typos and mistranslations were spotted and fixed. Apart from this, we are still keeping the existing documentation and web page translations up to date, currently without plans on further work. If you are interested in helping us, or you have any comments, or requests regarding the translations, do not hesitate to contact the project via the email addresses mentioned in the entry. Open tasks: 1. Review translations and send feedback. 2. Translate release notes. 3. Add more article translations. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki This project focuses on updating the www/ja and doc/ja_JP.eucJP/ trees. Since last year www/ja tree has been mostly synchronized with the English counterpart and doc/ja_JP.eucJP has also been updated steadily. We are now working on FreeBSD Handbook and Porter's Handbook. Open tasks: 1. More Japanese translation of FreeBSD Handbook and contents of www.FreeBSD.org. 2. Pre-/post-commit review of the translation. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ Contact: Gábor Kövesdán Contact: Vicente Carrasco Vayá We need manpower. Existing documentation set has not been updated for quite some time because of lack of volunteers. Current members are busy with other projects and real life at the moment and we have not received anything from outside contributors. It is a shame because there are lots of users in Spain and Latin-America, as well. Besides, the world's first Free Software Street has been recently inaugurated in Spain. This obviously means that there is interest in free software but unfortunately, this translation project is not going very well nowadays. Open tasks: 1. Review and update existing translations. __________________________________________________________________ V4L Support in Linux Emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd Some bug fixes were applied, and the code was also tested and made to work with the cuse4bsd webcam driver, which supports a great many camera chipsets. The code is still only in 9-CURRENT. We were going to MFC it to 8.x but ran into the code freeze for 8.1, so missed that. However, the code does work on 8-STABLE. We will try to get it MFC'd for 8.2. __________________________________________________________________ ZFS URL: http://wiki.FreeBSD.org/ZFS URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/ zfs Contact: Pawel Jakub Dawidek Contact: Martin Matuska Contact: Xin Li The ZFS file system has been updated to version 15 on HEAD and it will be MFC'ed to 8-STABLE around September 13th, 2010. Work is in progress on porting the recent ZFS version 26 with deduplication functionality. Open tasks: 1. Fix bugs, unresolved issues and to-dos in Perforce. __________________________________________________________________ (c) 1995-2010 The FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 15:19:43 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD7E106564A for ; Thu, 22 Jul 2010 15:19:43 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id AAD798FC08 for ; Thu, 22 Jul 2010 15:19:42 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6MFJQqB069136; Thu, 22 Jul 2010 17:19:41 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6MFJPP2069135; Thu, 22 Jul 2010 17:19:25 +0200 (CEST) (envelope-from olli) Date: Thu, 22 Jul 2010 17:19:25 +0200 (CEST) Message-Id: <201007221519.o6MFJPP2069135@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, rizzo@iet.unipi.it In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 22 Jul 2010 17:19:41 +0200 (CEST) Cc: Subject: Re: an alternative to powerpoint 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, 22 Jul 2010 15:19:43 -0000 Ivan Voras wrote: > On 07/13/10 06:15, Luigi Rizzo wrote: > > Have fun, it would be great if you could report how it works > > on fancy devices (iphone, ipad, androids...) > > For what it's worth, it doesn't work at all on Android :) (and the > layout is messed up) It works pretty well on my Nexus One (Android 2.2) with the default browser. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 21:15:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61294106564A for ; Thu, 22 Jul 2010 21:15:24 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEEA78FC08 for ; Thu, 22 Jul 2010 21:15:23 +0000 (UTC) Received: by wyj26 with SMTP id 26so1221267wyj.13 for ; Thu, 22 Jul 2010 14:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PYOwz8C/4XTAAAEqn73mRv5tDKyeYM0gAullHprRi5Y=; b=dh97cku/NL055b4ou+rpPVRk7bhTrBAeuD/rmzdB2uCBQs/0oA4k9N1YpUD69ZWBSh LGBE9NQ+ovYQ1S1AmecgDUom/8E05tKoTCRUXqlrBHhxZ3AfhcGn+h7Jdl+yfwD0ejoc kW0xLVxCFLI+cYvH/r/xI+wnl/5L8akOQlNIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=A8sPXDlFeff5zhMiweYcSdyLfuJ7fVsQbsTqgiRWnAq7GI2iZ3AdvPAJ2ggysqDaJS TdajSmQBrJrofBlOThzIVxjYkc2DRpYPROFkOyzpuYvB7ACqYHyz+LuM8S4xEJEEb7YD T6uwiJWS8d5DKQ2ohPaTai+07+p/mdXDV8kIE= MIME-Version: 1.0 Received: by 10.216.170.200 with SMTP id p50mr2486277wel.96.1279833322175; Thu, 22 Jul 2010 14:15:22 -0700 (PDT) Received: by 10.216.63.131 with HTTP; Thu, 22 Jul 2010 14:15:22 -0700 (PDT) Date: Thu, 22 Jul 2010 14:15:22 -0700 Message-ID: From: Jerry Toung To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Giant free GEOM/CAM XPT 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, 22 Jul 2010 21:15:24 -0000 Hello List, while going through the xpt code (8.0 RELEASE), it seems to me that some gains can be had in src/sys/geom/geom_disk.c where dp->d_strategy(bp2) is surrounded by Giant lock. Especially in the case where one has 2+ controllers on the system with /dev/daXX attached to them during heavy I/O. I am currently trying to get rid of giant there, but it branches in sys/cam and sys/dev/twa. Definitely not a trivial exercise. The dependency on Giant seems to come from the XPT code. would be neat if I could just use the SIM lock, which is per controller. Question: do you think it's worth the effort? right now I always get a crash (race condition most likely) in xpt_run_dev_allocq->camq_remove Jerry From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 18:04:23 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD1F106566C; Thu, 22 Jul 2010 18:04:23 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 12F908FC13; Thu, 22 Jul 2010 18:04:22 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6MHNtNm009233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jul 2010 13:23:55 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6MHNtKt024199; Thu, 22 Jul 2010 13:23:55 -0400 Message-ID: <4C487EAB.50302@aldan.algebra.com> Date: Thu, 22 Jul 2010 13:23:55 -0400 From: mi@aldan.algebra.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: x11@FreeBSD.org, usb@FreeBSD.org, hackers@FreeBSD.org X-Mailman-Approved-At: Thu, 22 Jul 2010 21:45:25 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: UCLogic tablets on FreeBSD 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, 22 Jul 2010 18:04:23 -0000 Hello! chuckr@ seems to have implemented support for UC-LOGIC tablets for FreeBSD. I have a user with just such a device using FreeBSD-8.1/i386. The device is seen by usbconfig(8) as: ugen1.4: at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON but I can't find anything in ports, that mentions "UC-LOGIC"... How would I go about making the device usable? I tried e-mailing Chuck twice, but, evidently, am not reaching him :-( Thanks for any ideas. Yours, -mi From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 22 23:51:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBEC3106564A for ; Thu, 22 Jul 2010 23:51:56 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id 868CC8FC16 for ; Thu, 22 Jul 2010 23:51:56 +0000 (UTC) Received: from orion.SpringDaemons.com (207.47.0.2.static.nextweb.net [207.47.0.2]) by mx0.deglitch.com (Postfix) with ESMTPA id 297808FC4E; Fri, 23 Jul 2010 03:33:00 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 1359A39C24; Thu, 22 Jul 2010 16:32:57 -0700 (PDT) Date: Thu, 22 Jul 2010 16:32:56 -0700 From: Stanislav Sedov To: freebsd-hackers@freebsd.org Message-Id: <20100722163256.24953414.stas@FreeBSD.org> In-Reply-To: <20100709151544.GA42131@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> <20100709151544.GA42131@logik.internal.network> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: xorquewasp@googlemail.com Subject: Re: envy24 driver broken 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, 22 Jul 2010 23:51:56 -0000 On Fri, 9 Jul 2010 15:15:44 +0000 xorquewasp@googlemail.com mentioned: > So, anyway, I have both an Audiophile 2496 and a Delta 66 card that > I can send to any developer interested in getting them working (ideally > I'd like them back some day). > > Is there anyone interested in fixing these drivers? > > Bare in mind I have no idea how much work this is. The audio subsystem > seems to have had a major upgrade last year but it seems that these > envy24 drivers are incomplete. > Hi, xw! I have Audiophile 2496, and it works great for me including the mixer. Do you know where exactly these messages come from? -- Stanislav Sedov ST4096-RIPE From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 01:02:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D911065670; Fri, 23 Jul 2010 01:02:22 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 67B388FC1F; Fri, 23 Jul 2010 01:02:22 +0000 (UTC) Received: by gwj23 with SMTP id 23so575205gwj.13 for ; Thu, 22 Jul 2010 18:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=oYzx/hVIaUleQWBpS5Qi9iAilAy/8Q4tnqL7DGqEiWs=; b=Rbdx4AFTYGn23MD/ozCedp7kPZqts7SRozZzhkJHBN3qgV0E6SMSAg3hfyfhjdIJQX 2lbNqF21j/1/fnYGLzFAI+J28+9Xqh0i1kGQZ+IjjXWQFtb7yAd3wUWYuYQveLixA4yR vI4p9Vd3WTbTTOUr5+d7m8+vSPi3j5M+g4DaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Sm4PGDKc8sedsvTbP+vAlLwVA3xcizrXF9yPxa9GnCOOU4Ac/JPdIcDdr2Lz+zcozU 2tHBRkSu5Uc3Un7WmU5YgYuwZgsNUnC0UsVszBUFC2yC/WE1ARtD8Lp3Wn9ssT/7ZiWb DRFW0dPB9bzT2+8C1kAubr4UuSfEAAVtCwS1k= MIME-Version: 1.0 Received: by 10.100.111.7 with SMTP id j7mr3089132anc.30.1279845269103; Thu, 22 Jul 2010 17:34:29 -0700 (PDT) Received: by 10.100.123.3 with HTTP; Thu, 22 Jul 2010 17:34:29 -0700 (PDT) Date: Thu, 22 Jul 2010 17:34:29 -0700 Message-ID: From: alan yang To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: interface for import/export flowtable 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, 23 Jul 2010 01:02:22 -0000 Hello, Wonder people had implemented interface to import / export flowtable. Thanks in advance for sharing the info. Alan From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 05:47:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77EA61065687 for ; Fri, 23 Jul 2010 05:47:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 007058FC1A for ; Fri, 23 Jul 2010 05:47:16 +0000 (UTC) Received: by fxm13 with SMTP id 13so5268113fxm.13 for ; Thu, 22 Jul 2010 22:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=LIFdsQb8a29o//jBedTZ8v+XFiUHqGE5y/eaxkJKynw=; b=dyK2KlS3KmzD6UzrA1ZeqO1WVxamTgEuB6GtyImTMmJX//xIF4sTV7GiqCei9cSV6l PJ120456YZ36lQbBb9pCoH2fscUXkmu+Ee6PXnSWoLfoxyuLWjN+eMHKpphCCCzT1mrP vLYNYa5fJBHvIGz7sCi23IC1TNuu6EuI/Ea7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=PZ5qTFPfkDPt3i7GAIhn6hYcL+TRS/uURyUUqGGuHUuXXUQJBSH/Q+RaRWfZckSQJv i4Vf7bkG4Te77m96GgQxN3lXTnUyDjK9E85YKBLiHV9K5DiqK/u6xri2MDoBKlNNqXlL JaV5Xeg7SaOmm3osq5KzM79hYJSX8+f6ex3GM= Received: by 10.223.119.210 with SMTP id a18mr2844713far.52.1279864035785; Thu, 22 Jul 2010 22:47:15 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q17sm3599809faa.45.2010.07.22.22.47.14 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 22:47:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C492CE0.3050105@FreeBSD.org> Date: Fri, 23 Jul 2010 08:47:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Jerry Toung , freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Giant free GEOM/CAM XPT 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, 23 Jul 2010 05:47:17 -0000 Jerry Toung wrote: > Hello List, > while going through the xpt code (8.0 RELEASE), it seems to me that some > gains can be had > in src/sys/geom/geom_disk.c where dp->d_strategy(bp2) is surrounded by Giant > lock. Especially in the case > where one has 2+ controllers on the system with /dev/daXX attached to them > during heavy I/O. Giant locked there only if DISKFLAG_NEEDSGIANT flag is set, which da driver is not doing. > I am currently trying to get rid of giant there, but it branches in sys/cam > and sys/dev/twa. Definitely not a > trivial exercise. The dependency on Giant seems to come from the XPT code. > > would be neat if I could just use the SIM lock, which is per controller. > > Question: do you think it's worth the effort? I think you misunderstood something. Most of CAM protected by SIM locks. If some SIMs use Giant for that purpose - it is their own problem. But as I can see, twa uses own lock, not Giant. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 07:04:49 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C0E4106564A; Fri, 23 Jul 2010 07:04:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 2283C8FC17; Fri, 23 Jul 2010 07:04:47 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=9IIj2yEt9mCpiLyep4f0BnD2ZC7rS3PjQbiokY3Mrg0= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=LaogzpLLAAAA:8 a=Vt2AcnKqAAAA:8 a=6I5d2MoRAAAA:8 a=Nt_ACCoGAAAA:8 a=HxvaxCTpGF_A6aDpUHkA:9 a=zBv2Xaw-z4498wxkYiqBDcjJ6vUA:4 a=wPNLvfGTeEIA:10 a=JDxsqQ4uBBwA:10 a=SV7veod9ZcQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1658134; Fri, 23 Jul 2010 09:04:39 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Fri, 23 Jul 2010 09:01:45 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <4C487EAB.50302@aldan.algebra.com> In-Reply-To: <4C487EAB.50302@aldan.algebra.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007230901.46080.hselasky@c2i.net> Cc: usb@freebsd.org, hackers@freebsd.org, x11@freebsd.org, mi@aldan.algebra.com Subject: Re: UCLogic tablets on FreeBSD 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, 23 Jul 2010 07:04:49 -0000 On Thursday 22 July 2010 19:23:55 mi@aldan.algebra.com wrote: > Hello! > > chuckr@ seems > > to have implemented support for UC-LOGIC tablets > for FreeBSD. I > have a user with just such a device using FreeBSD-8.1/i386. The device > is seen by usbconfig(8) as: > > ugen1.4: at usbus1, cfg=0 md=HOST spd=LOW > (1.5Mbps) pwr=ON > > but I can't find anything in ports, that mentions "UC-LOGIC"... > > How would I go about making the device usable? I tried e-mailing Chuck > twice, but, evidently, am not reaching him :-( > > Thanks for any ideas. Yours, I recommend using libusb (see man libusb) on FreeBSD 8+, to communicate with the device. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 09:42:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E2271065687; Fri, 23 Jul 2010 09:42:38 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE168FC17; Fri, 23 Jul 2010 09:42:36 +0000 (UTC) Received: by wyj26 with SMTP id 26so5228wyj.13 for ; Fri, 23 Jul 2010 02:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=3oq53R78IorB5FyPvg3JkDErXbgHD5uueYVs7dJZG20=; b=ew6DglLOnfW5IO2dYIT/AmUZ/rr9Bc0i+yicQUjNUwTD94R7C1YbkBCxR6LxXDR8H0 lClzEgsC3KNLner22ctawYRT/c2VCeAhfV3ACiXPgFyfo+DUjBldka2zUIESPAS7Vvrh vMVBrAd0DV/CBRckJLJztKMVOPmb1nOD8HSYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=im+4U1NoU8O9/zOrrAKB10UU5ebtISGnZwTZFBcT+YEZ1Omxc+WLxD08eJedW6yisb DpcGLOH3yPNRa6cb6UwTBIxFT0oPoABGy7cIhVFIoBndPCAhfyiuWIb/xz8z9HpadDNb eRy1ARQqW+7YtgmmXbGN1wogZ8d4BonZAtteQ= MIME-Version: 1.0 Received: by 10.227.136.194 with SMTP id s2mr3176893wbt.173.1279876744900; Fri, 23 Jul 2010 02:19:04 -0700 (PDT) Received: by 10.216.187.70 with HTTP; Fri, 23 Jul 2010 02:19:04 -0700 (PDT) Date: Fri, 23 Jul 2010 11:19:04 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: trhodes@FreeBSD.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: my first try with fscd 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, 23 Jul 2010 09:42:38 -0000 Hi i try fscd and it looks realy nice. but i need to add a sleep before restart of process to make it works: --- fscd.c.orig 2010-06-17 21:35:48.000000000 +0200 +++ fscd.c 2010-07-23 11:04:18.479760991 +0200 @@ -253,6 +253,7 @@ if (child == 0) { close(1); close(2); + sleep(1); if (execv(argz[0], argz) == -1) { syslog(LOG_ERR, "Could not start %s\n", svs->svname); whithout this, fscd say that the process is restarted but nothing appends. another problem: after a restart, fscd import nothing from previous database. tested on: FreeBSD home.freelooser.fr 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #17 r210105: Thu Jul 15 08:27:38 CEST 2010 root@home.freelooser.fr:/usr/obj/usr/src/sys/FNEUZFS amd64 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 15:07:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CE51065673 for ; Fri, 23 Jul 2010 15:07:38 +0000 (UTC) (envelope-from sg@sg.org.ua) Received: from mail.redtram.com (mail.redtram.com [213.186.114.162]) by mx1.freebsd.org (Postfix) with ESMTP id B34968FC08 for ; Fri, 23 Jul 2010 15:07:38 +0000 (UTC) Received: from mail.tbilisi.kiev.ua ([193.254.217.230] helo=sg.intra) by mail.redtram.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OcJEq-000Px6-4G for freebsd-hackers@freebsd.org; Fri, 23 Jul 2010 17:28:36 +0300 From: Alexander Mogilny Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jul 2010 17:28:35 +0300 Message-Id: <4D6BCA32-2819-41AD-B650-51A2A83F2DB3@sg.org.ua> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: UDLR implementation 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, 23 Jul 2010 15:07:39 -0000 Hello! I have been searching on Internet for implementation of UDLR protocol = (RFC 3077). AFAI see this protocol support is implemented only for Cisco platform. I am thinking of implementing some kind of virtual network device which = uses TX of one NIC and RX of another NIC. As a result I will get a device with = similar to RFC 3077 functionality. I am a little new to low level kernel development so the question is: = what would be the staff to start with? Thanks for help! --=20 AIM-UANIC | AIM-RIPE +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@sg.org.ua +---------------------+ From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 16:09:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45481065673; Fri, 23 Jul 2010 16:09:52 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 44EE98FC13; Fri, 23 Jul 2010 16:09:52 +0000 (UTC) Received: by wyj26 with SMTP id 26so415924wyj.13 for ; Fri, 23 Jul 2010 09:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SqR/a1TBbKIZJAjF5oxHMQvrJPjkbrSrqUnSwkzBkQ8=; b=gw+jgXLIRflvsuu3gMBlX0iKtnXZYP0emNbReotDZPJt8C1O/6b/NVwk8W+J4gU27r LyW6t4/74Apt0WOE/KnXnoIGOS8g6xYE1BrczQTyWW9aUIuHmRd70ShQmefKr2yQD23i 35SiwLfW5b/Bx2/tSSphCyKtv4JuDjgrrVNNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UPy8tnMZ39j/9ZWYZC7bToto1dJe3s+m0SRR9c1zbux+rxjH7rI5kYZNEgDzOLKpEH UdM9Va8KKVzZe7/Ln5wByPlAGHN1Md+yvyQoJkEkdL7yx2UgJUpHjoB7l/XaNrYfYpGw R041tiPkPYznWFFn0yabOagTuryNF8+Gyi3oM= MIME-Version: 1.0 Received: by 10.227.156.12 with SMTP id u12mr3671035wbw.213.1279901391097; Fri, 23 Jul 2010 09:09:51 -0700 (PDT) Received: by 10.216.63.131 with HTTP; Fri, 23 Jul 2010 09:09:51 -0700 (PDT) In-Reply-To: <4C492CE0.3050105@FreeBSD.org> References: <4C492CE0.3050105@FreeBSD.org> Date: Fri, 23 Jul 2010 09:09:51 -0700 Message-ID: From: Jerry Toung To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Giant free GEOM/CAM XPT 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, 23 Jul 2010 16:09:52 -0000 On Thu, Jul 22, 2010 at 10:47 PM, Alexander Motin wrote: > > Giant locked there only if DISKFLAG_NEEDSGIANT flag is set, which da > driver is not doing. > > > Alexander, my mistake. I am working on 2 branches at the moment 6.3 and 8.0. I got them all mixed up while going through my trees. 8.0 scsi_da.c doesn't need giant. Jerry From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 18:51:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D77AB1065677; Fri, 23 Jul 2010 18:51:14 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFAB8FC13; Fri, 23 Jul 2010 18:51:13 +0000 (UTC) Received: by eyh6 with SMTP id 6so131921eyh.13 for ; Fri, 23 Jul 2010 11:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=iqwkXAfInYKWllCAVMMBTtwkgZZpuARBtEDbfmjz9gk=; b=JJKZRGYq3/VcvqOPKETusPckGT+r2FFLE7E/DUnMVSMLblGEw4hO6SmbvM7i+EquVO WkzmhwfGg52ZbbaP+R/XzXohEXtAH/1pVlcth0Jgm3APieMGkQ4Vyu8FyANbJjp75+tq HVGN7mTDW+YmNLwc6l9/LJfNH0S3TWKfxjSNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=xxU2wVixK7guCVXaZQK8mAj7ArvLYDYvymI8IsLm4bRg1HVZRUqD5lvzTYtwVwr4aM re8vgNJD6pfXkBdj+8hY8EvrtGZYcNZiD8DOzVKw8UN9PxENMF21UeTXp3S6Xmmb66RL Mtr0jh0ImdEqeLlDhgdwMjTTE3aD6fAMNg1ag= Received: by 10.213.35.6 with SMTP id n6mr3668685ebd.0.1279911072921; Fri, 23 Jul 2010 11:51:12 -0700 (PDT) Received: from viper.internal.network (dsl78-143-208-62.in-addr.fast.co.uk [78.143.208.62]) by mx.google.com with ESMTPS id z55sm809113eeh.21.2010.07.23.11.51.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Jul 2010 11:51:11 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 24B964AC08; Fri, 23 Jul 2010 18:51:10 +0000 (UTC) Date: Fri, 23 Jul 2010 18:51:10 +0000 From: xorquewasp@googlemail.com To: Stanislav Sedov Message-ID: <20100723185110.GB37045@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> <20100709151544.GA42131@logik.internal.network> <20100722163256.24953414.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100722163256.24953414.stas@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: envy24 driver broken 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, 23 Jul 2010 18:51:14 -0000 On 2010-07-22 16:32:56, Stanislav Sedov wrote: > Hi, xw! > > I have Audiophile 2496, and it works great for me including the mixer. > Do you know where exactly these messages come from? > Hi. It seems to be when /etc/rc.d/mixer attempts to restore mixer settings on boot. I took the cards out, but I remember that most if not all of the mixer settings resulted in a "deviced not configured" error. I just discovered the hw.snd.verbose sysctl. Do you think this would help? I'll retry the cards again later and try to get more info. I should mention that I'm using 8.0 amd64. Could this maybe be an amd64 issue? Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 20:19:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEEB3106566B for ; Fri, 23 Jul 2010 20:19:58 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id A476F8FC0C for ; Fri, 23 Jul 2010 20:19:58 +0000 (UTC) Received: from orion.SpringDaemons.com (207.47.0.2.static.nextweb.net [207.47.0.2]) by mx0.deglitch.com (Postfix) with ESMTPA id 3CB888FC54; Sat, 24 Jul 2010 00:19:26 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 4751239C24; Fri, 23 Jul 2010 13:19:26 -0700 (PDT) Date: Fri, 23 Jul 2010 13:18:46 -0700 From: Stanislav Sedov To: xorquewasp@googlemail.com Message-Id: <20100723131846.e7116b60.stas@FreeBSD.org> In-Reply-To: <20100723185110.GB37045@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> <20100709151544.GA42131@logik.internal.network> <20100722163256.24953414.stas@FreeBSD.org> <20100723185110.GB37045@logik.internal.network> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Date: Fri, 23 Jul 2010 13:19:26 -0700 Resent-From: Stanislav Sedov Resent-To: xorquewasp@googlemail.com Resent-Cc: freebsd-hackers@freebsd.org Resent-Message-Id: <20100723131926.24996c61.stas@FreeBSD.org> Cc: Subject: Re: envy24 driver broken 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, 23 Jul 2010 20:19:59 -0000 On Fri, 23 Jul 2010 18:51:10 +0000 xorquewasp@googlemail.com mentioned: > On 2010-07-22 16:32:56, Stanislav Sedov wrote: > > Hi, xw! > > > > I have Audiophile 2496, and it works great for me including the mixer. > > Do you know where exactly these messages come from? > > > > Hi. > > It seems to be when /etc/rc.d/mixer attempts to restore mixer settings > on boot. > > I took the cards out, but I remember that most if not all of the mixer > settings resulted in a "deviced not configured" error. I just discovered > the hw.snd.verbose sysctl. Do you think this would help? I'll retry the > cards again later and try to get more info. Yeah, that might be helpful. > > I should mention that I'm using 8.0 amd64. Could this maybe be an amd64 > issue? > Nope, I'm using amd64 as well. I have not tested mixer, though. BTW, this card (2496) doesn't have any mixer at all (as far as I remeber), so this might be issue. I'll take a look. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 23 23:30:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444EE106566C for ; Fri, 23 Jul 2010 23:30:28 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E75E8FC13 for ; Fri, 23 Jul 2010 23:30:27 +0000 (UTC) Received: by pvh1 with SMTP id 1so4298204pvh.13 for ; Fri, 23 Jul 2010 16:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=oAU4bGL3YlWWixD/Axaw4Sr6imr5RE12KreSVZNYY7E=; b=Sz4k2qHq2ZKhanogdf6bv2AVgPMmP7U8Wp8LZphD6HOPRrVc2QqJLmbkDLyjkAKdRF nzJyhh2sY0JhUsjxAPCIlriZYt5/+8X7bDygxRneZ8GGqoNMVM8eEKDaQhf8FIaru19C kN2Q+BYtrn1DRvz0/Sc0oIh0AO2/bLEkLr5FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RbNYvk/dZJPn16tTtSSMFuN7VmzvzQN1cUWiwqMz2CIVDgw+2VowVMQnuvRtyJc/ck ZhLK21bJlW1KBCOK7NkpTAF7Wp2iLlxMQLTfT2LcEF+0C0GAFYHWrPxHWRo2/n9gauWK F/XvO7l/U+Yhx41gxhmv4mxifStXMgbK4RLRw= MIME-Version: 1.0 Received: by 10.142.172.15 with SMTP id u15mr4955950wfe.65.1279925936970; Fri, 23 Jul 2010 15:58:56 -0700 (PDT) Received: by 10.142.139.19 with HTTP; Fri, 23 Jul 2010 15:58:56 -0700 (PDT) Date: Fri, 23 Jul 2010 15:58:56 -0700 Message-ID: From: Neel Natu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: PATCH: pciconf -a 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, 23 Jul 2010 23:30:28 -0000 Hi, This patch makes "pciconf -a" do the right thing as opposed to always failing with this message: pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device Any objections if I commit this? best Neel Index: sys/dev/pci/pci_user.c =================================================================== --- sys/dev/pci/pci_user.c (revision 210396) +++ sys/dev/pci/pci_user.c (working copy) @@ -735,6 +735,16 @@ bio->pbi_enabled = (value & PCIM_CMD_PORTEN) != 0; error = 0; break; + case PCIOCATTACHED: + error = 0; + io = (struct pci_io *)data; + pcidev = pci_find_dbsf(io->pi_sel.pc_domain, io->pi_sel.pc_bus, + io->pi_sel.pc_dev, io->pi_sel.pc_func); + if (pcidev != NULL) + io->pi_data = device_is_attached(pcidev); + else + error = ENODEV; + break; default: error = ENOTTY; break; From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 08:44:28 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7D31065675 for ; Sat, 24 Jul 2010 08:44:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 569F28FC18 for ; Sat, 24 Jul 2010 08:44:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EA6B073098; Sat, 24 Jul 2010 10:55:32 +0200 (CEST) Date: Sat, 24 Jul 2010 10:55:32 +0200 From: Luigi Rizzo To: Oliver Fromme Message-ID: <20100724085532.GA95339@onelab2.iet.unipi.it> References: <201007221519.o6MFJPP2069135@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007221519.o6MFJPP2069135@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: an alternative to powerpoint 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, 24 Jul 2010 08:44:28 -0000 On Thu, Jul 22, 2010 at 05:19:25PM +0200, Oliver Fromme wrote: > Ivan Voras wrote: > > On 07/13/10 06:15, Luigi Rizzo wrote: > > > Have fun, it would be great if you could report how it works > > > on fancy devices (iphone, ipad, androids...) > > > > For what it's worth, it doesn't work at all on Android :) (and the > > layout is messed up) > > It works pretty well on my Nexus One (Android 2.2) with > the default browser. good. There were several changes since the initial version just to improve compatibility with other browsers -- among other things, in included navigation buttons on the bottom line so you can use it on phones and similar devices. At the moment the 'distributed' version does not work with opera-mini due to the peculiar way opera-mini handles javascript cheers luigi > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "A language that doesn't have everything is actually easier > to program in than some that do." > -- Dennis M. Ritchie From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 12:03:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A548106566C; Sat, 24 Jul 2010 12:03:27 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id BBDDB8FC13; Sat, 24 Jul 2010 12:03:26 +0000 (UTC) Received: by eyh6 with SMTP id 6so241352eyh.13 for ; Sat, 24 Jul 2010 05:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=fSoiYUfy03PihWQVCaXpJNm09c+PgA/AmBfSlcVyAXQ=; b=qgg4hy4xGGdMrbBwEqW2x/X3xnqYSYf7sE5FtOuJdxDGUeyq384GY+Q/CYAPQaC18z HIWIo3nAl7mOkFNrBhErpWTpCoZSvzUrg/fWGwDIaEXfPXpxEGnLi3QSX9LC3DvL/y0E IeuxaYgbzX4DL/MJKu9B1FQ3nCtN7GeNFOL0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=BuGhOsd/j6JHiGXddfZWqJLUBDRl//G89oZ8DPQw5+NVHeO/1Slojy/WTJVz+N8cRu K3Tt15PtwujerHaLpDPkc5H0n42ZH4gF9odQ78IZRopbe3DMfMRbEqY5WERpOtaXwNEG 17O4fJWUehPFjf8kIsMpwm3j7p6ehRqEp8uZg= Received: by 10.213.4.81 with SMTP id 17mr451624ebq.97.1279973005448; Sat, 24 Jul 2010 05:03:25 -0700 (PDT) Received: from viper.internal.network (dsl78-143-208-62.in-addr.fast.co.uk [78.143.208.62]) by mx.google.com with ESMTPS id v59sm2045290eeh.4.2010.07.24.05.03.23 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Jul 2010 05:03:24 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 544FA4AC08; Sat, 24 Jul 2010 12:03:22 +0000 (UTC) Date: Sat, 24 Jul 2010 12:03:22 +0000 From: xorquewasp@googlemail.com To: Stanislav Sedov Message-ID: <20100724120322.GA76854@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> <20100709151544.GA42131@logik.internal.network> <20100722163256.24953414.stas@FreeBSD.org> <20100723185110.GB37045@logik.internal.network> <20100723131846.e7116b60.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100723131846.e7116b60.stas@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: envy24 driver broken 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, 24 Jul 2010 12:03:27 -0000 Ok, here's where I am with this. I'm currently using the Audiophile for the sake of simplicity (I'm assuming that if the Audiophile works properly, the Delta 66 probably will too). /dev/sndstat, at maximum verbosity, looks like: FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: at io 0xac00:32,0xa880:16,0xa800:16,0xa480:64 irq 17 [MPSAFE] (5p:1v/3r:1v channels duplex default) snddev flags=0x2e2 [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000004 interrupts 0, underruns 0, feed 0, ready 0 [b:16384/2048/8|bs:16384/8192/2] channel flags=0x2100 {userland} -> feeder_mixer(0x00200010) -> {hardware} [pcm0:play:dsp0.p1]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {userland} -> feeder_root(0x00000000) -> {hardware} [pcm0:play:dsp0.p2]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {userland} -> feeder_root(0x00000000) -> {hardware} [pcm0:play:dsp0.p3]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {userland} -> feeder_root(0x00000000) -> {hardware} [pcm0:play:dsp0.p4]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {userland} -> feeder_root(0x00000000) -> {hardware} pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0] channel flags=0x10000000 {userland} -> feeder_root(0x00000000) -> {hardware} [pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000005 interrupts 0, overruns 0, feed 0, hfree 16384, sfree 16384 [b:16384/2048/8|bs:16384/8192/2] channel flags=0x2100 {hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) -> {userland} [pcm0:record:dsp0.r1]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, overruns 0, feed 0, hfree 32768, sfree 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {hardware} -> feeder_root(0x00000000) -> {userland} [pcm0:record:dsp0.r2]: spd 8000, fmt 0x00100008, flags 0x00000000, 0x00000000 interrupts 0, overruns 0, feed 0, hfree 32768, sfree 0 [b:32768/16384/2|bs:0/0/0] channel flags=0x0 {hardware} -> feeder_root(0x00000000) -> {userland} pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000 interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0] channel flags=0x10000000 {hardware} -> feeder_root(0x00000000) -> {userland} File Versions: $FreeBSD: src/sys/dev/sound/pci/envy24.c,v 1.17.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/isa/sndbuf_dma.c,v 1.4.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_format.c,v 1.1.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/vchan.c,v 1.37.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.123.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_eq.c,v 1.1.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder.c,v 1.45.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_chain.c,v 1.1.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/sndstat.c,v 1.29.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_volume.c,v 1.7.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/buffer.c,v 1.38.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/mixer.c,v 1.66.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/ac97_patch.c,v 1.12.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/ac97.c,v 1.75.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/dsp.c,v 1.114.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_rate.c,v 1.29.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/channel.c,v 1.124.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_mixer.c,v 1.1.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ $FreeBSD: src/sys/dev/sound/pcm/feeder_matrix.c,v 1.1.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $ The relevant part of dmesg: pcm0: port 0xac00-0xac1f,0xa880-0xa88f,0xa800-0xa80f,0xa480-0xa4bf irq 17 at device 6.0 on pci1 pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0xd634 XIN2 Clock Source: 22.5792MHz(44.1kHz*512) MPU-401 UART(s) #: 1 AC'97 codec: not exist ADC #: 1 DAC #: 1 Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0x04/0xfb/0xfe Trying to use the mixer on anything other than the vol, pcm or line channels results in: $ mixer mic 100 Setting the mixer mic from 0:0 to 100:100. mixer: WRITE_MIXER: Device not configured Which is fair enough - if it doesn't have them, it doesn't have them. The card, however, doesn't seem to work in full duplex mode (pretty essential for "pro" audio work). As a test of full duplex capability, I'm using jackd from ports: $ /usr/local/bin/jackd -d oss jackd 0.116.2 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. oss_driver: /dev/dsp : 0x10/2/48000 (4096) oss_driver: indevbuf 4096 B, outdevbuf 4096 B oss_driver: not using barrier mode, (single thread) OSS: write() failed: oss_driver.c@1054, count=-1/4096, errno=22 Having spoken to the jackd developers at length whilst picking through the OSS backend source code, we came to the conclusion that this error (EINVAL) occurs because the envy24 driver can't work in full duplex mode (essential for jackd without the workaround below). The same problem occurs with the Delta 66. The EINVAL error occurs as soon as a jack client connects. Starting jackd with some flags to tell it not to open any inputs allows it to work (for a given value of "work"): $ /usr/local/bin/jackd -d oss -i 0 jackd 0.116.2 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. oss_driver: /dev/dsp : 0x10/2/48000 (4096) oss_driver: indevbuf 0 B, outdevbuf 4096 B oss_driver: not using barrier mode, (single thread) Using the card as a plain recording device (ie, reading from /dev/dsp) fails too. I can get audio output to my speakers writing to /dev/dsp I can only get an endless stream of 0x80 from any audio input: $ cat /dev/dsp0.0 | hd -v 00000000 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000040 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000050 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| 00000060 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| If you need any more information, please let me know. Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 12:20:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626701065673; Sat, 24 Jul 2010 12:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1E49B8FC13; Sat, 24 Jul 2010 12:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 204A941C5D0; Sat, 24 Jul 2010 14:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 8D2V4vkD1is2; Sat, 24 Jul 2010 14:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 72A4741C757; Sat, 24 Jul 2010 14:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 507B34448EC; Sat, 24 Jul 2010 12:17:13 +0000 (UTC) Date: Sat, 24 Jul 2010 12:17:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: alan yang In-Reply-To: Message-ID: <20100724121539.D57851@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: interface for import/export flowtable 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, 24 Jul 2010 12:20:07 -0000 On Thu, 22 Jul 2010, alan yang wrote: Hey, > Wonder people had implemented interface to import / export flowtable. what exactly do you want to accomplish with that? -- Bjoern A. Zeeb From August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 13:54:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E859F1065672 for ; Sat, 24 Jul 2010 13:54:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 74ACC8FC13 for ; Sat, 24 Jul 2010 13:54:25 +0000 (UTC) Received: by fxm13 with SMTP id 13so5985754fxm.13 for ; Sat, 24 Jul 2010 06:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=7JVcqq3uEKxPBISQ1Dm9Lwx8feU0ezKVm6y2MQYqwco=; b=haGJlr+b573RE6SDFKT+L4w7lzbid8eM8BgvHB+vV7wSPRZ7HaLH5qxSs9UT9Y+C+M oLBgiO4OwGZ7e8P5XgrKYgrw+R0hoDiKK7JB0tINBZC9/PHpFhvZ9NKro0v1e4+SHs49 gRRmavv5j4NHi0/K0aI1QB02zZCxSXu1YZ4kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=ltVw/MrbkrHEPmJuf0WF3tF2NYlLkMfSHvmsi9VRlYiOALyefFxux1uuPJUgo+gG3i 8LQKg0PYhdLAm3AKp5JAyeIS606xRrcHyGhth37LojV52OhIt35LfDT8JM4pFAS7Q3e+ jW9U0Q43nfK//a3eghnSxiLB+S/e6nB5MxvCM= Received: by 10.86.33.3 with SMTP id g3mr3382717fgg.73.1279979663693; Sat, 24 Jul 2010 06:54:23 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id k15sm521713fai.40.2010.07.24.06.54.22 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Jul 2010 06:54:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4AF046.40507@FreeBSD.org> Date: Sat, 24 Jul 2010 16:53:10 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Intel TurboBoost in practice 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, 24 Jul 2010 13:54:27 -0000 Hi. I've make small observations of Intel TurboBoost technology under FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency of some cores if other cores are idle and power/thermal conditions permit. CPU core counted as idle, if it has been put into C3 or deeper power state (may reflect ACPI C2/C3 states). So to reach maximal effectiveness, some tuning may be needed. Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was measuring building time of the net/mpd5 from sources, using only one CPU core (cpuset -l 0 time make). Untuned system (hz=1000): 14.15 sec Enabled ACPI C2 (hz=1000+C2): 13.85 sec Enabled ACPI C3 (hz=1000+C3): 13.91 sec Reduced HZ (hz=100): 14.16 sec Enabled ACPI C2 (hz=100+C2): 13.85 sec Enabled ACPI C3 (hz=100+C3): 13.86 sec Timers tuned* (hz=100): 14.10 sec Enabled ACPI C2 (hz=100+C2): 13.71 sec Enabled ACPI C3 (hz=100+C3): 13.73 sec All numbers tested few times and are repeatable up to +/-0.01sec. *) Timers were tuned to reduce interrupt rates and respectively increase idle cores sleep time. These lines were added to loader.conf: sysctl kern.eventtimer.timer1=i8254 sysctl kern.eventtimer.timer2=NONE kern.eventtimer.singlemul=1 kern.hz="100" PS: In this case benefit is small, but it is the least that can be achieved, depending on CPU model. Some models allow frequency to be risen by up to 6 steps (+798MHz). PPS: I expect even better effect achieved by further reducing interrupt rates on idle CPUs. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 16:58:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE781065675; Sat, 24 Jul 2010 16:58:59 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8373E8FC0A; Sat, 24 Jul 2010 16:58:58 +0000 (UTC) Received: by qwk3 with SMTP id 3so1032656qwk.13 for ; Sat, 24 Jul 2010 09:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=NSndOLtx6dFrCtibNbGmOn2fSi09dAGSpCjqWH1NdUA=; b=K4S6ly3V886mYJ14D4of4Mg9gSkOnHR75g18wn2UpgTXJMhIfZzjqSx4GEjPiytecH Cu3vZaA0kF/lDac5tL13FtTDFJEOU9AuVLGAIuL+bhT+ZMylQhA6My9wbEz6EJqf+BlO PE5wUwU+zRnKPY5s9d0jZLTJy6VN7zzP2/Dck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=KNzBR/j8hvwqBHREV+jSO9q+SHJ0Wsyisqkz+J11+4+O6mDs20W7SB8s6TzpOBch6V nE5qqJccHZv9NA39slAdUx2x3xUP/sF/0lFwIDaLJ51l4PKhV+CERlblvXWH7Xq8WuQ+ RwWflWm650cdavpp+ltCivS/qH80wXWXjc45E= MIME-Version: 1.0 Received: by 10.224.2.85 with SMTP id 21mr4026542qai.74.1279990737006; Sat, 24 Jul 2010 09:58:57 -0700 (PDT) Received: by 10.229.239.5 with HTTP; Sat, 24 Jul 2010 09:58:56 -0700 (PDT) In-Reply-To: <4C4AF046.40507@FreeBSD.org> References: <4C4AF046.40507@FreeBSD.org> Date: Sat, 24 Jul 2010 11:58:56 -0500 Message-ID: From: Alan Cox To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 16:58:59 -0000 2010/7/24 Alexander Motin > Hi. > > I've make small observations of Intel TurboBoost technology under > FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency > of some cores if other cores are idle and power/thermal conditions > permit. CPU core counted as idle, if it has been put into C3 or deeper > power state (may reflect ACPI C2/C3 states). So to reach maximal > effectiveness, some tuning may be needed. > > [snip] > > PPS: I expect even better effect achieved by further reducing interrupt > rates on idle CPUs. > > I'm currently testing a patch that eliminates another 31% of the global TLB shootdowns for a "buildworld" on an amd64 machine. So, you can expect improvement in this area. Alan From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 17:13:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920751065670; Sat, 24 Jul 2010 17:13:23 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4E55D8FC0A; Sat, 24 Jul 2010 17:13:23 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 553E6157557; Sat, 24 Jul 2010 11:18:57 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id L8XA8AD94AJ4; Sat, 24 Jul 2010 11:18:57 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=l+aMJL/LfnbeJ4XKHCZDtoUzIETWHdqkMTjbIYyf+Y0qEfv22Y87QBYyjw0WbrYy07rcoLBX4xOed9QOiUB0lfuZLIc+hVSHzvtrM5RfOom4LgblcSg2q6ARcDytXCKNOkFNkUjJU2pcVDiljGBn0C++4tJdCn/Bks1Ko26ME8Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4C4AF046.40507@FreeBSD.org> Date: Sat, 24 Jul 2010 17:18:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C4AF046.40507@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sat, 24 Jul 2010 18:32:43 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice 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, 24 Jul 2010 17:13:23 -0000 On 24 Jul 2010, at 14:53, Alexander Motin wrote: > Hi. >=20 > I've make small observations of Intel TurboBoost technology under > FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise = frequency > of some cores if other cores are idle and power/thermal conditions > permit. CPU core counted as idle, if it has been put into C3 or deeper > power state (may reflect ACPI C2/C3 states). So to reach maximal > effectiveness, some tuning may be needed. >=20 > Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + = 1/2 > TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I = was > measuring building time of the net/mpd5 from sources, using only one = CPU > core (cpuset -l 0 time make). >=20 > Untuned system (hz=3D1000): 14.15 sec > Enabled ACPI C2 (hz=3D1000+C2): 13.85 sec > Enabled ACPI C3 (hz=3D1000+C3): 13.91 sec > Reduced HZ (hz=3D100): 14.16 sec > Enabled ACPI C2 (hz=3D100+C2): 13.85 sec > Enabled ACPI C3 (hz=3D100+C3): 13.86 sec > Timers tuned* (hz=3D100): 14.10 sec > Enabled ACPI C2 (hz=3D100+C2): 13.71 sec > Enabled ACPI C3 (hz=3D100+C3): 13.73 sec >=20 > All numbers tested few times and are repeatable up to +/-0.01sec. >=20 > *) Timers were tuned to reduce interrupt rates and respectively = increase > idle cores sleep time. These lines were added to loader.conf: > sysctl kern.eventtimer.timer1=3Di8254 > sysctl kern.eventtimer.timer2=3DNONE > kern.eventtimer.singlemul=3D1 > kern.hz=3D"100" >=20 > PS: In this case benefit is small, but it is the least that can be > achieved, depending on CPU model. Some models allow frequency to be > risen by up to 6 steps (+798MHz). The numbers that you are showing doesn't show much difference. Have you = tried buildworld? >=20 > PPS: I expect even better effect achieved by further reducing = interrupt > rates on idle CPUs. >=20 > --=20 > Alexander Motin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 > = __________________________________________________________________________= __________ > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=3D1225540&key=3D3283483970 > = __________________________________________________________________________= __________ Regards, -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 18:45:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F281065677; Sat, 24 Jul 2010 18:45:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF998FC1A; Sat, 24 Jul 2010 18:45:31 +0000 (UTC) Received: by iwn35 with SMTP id 35so1746749iwn.13 for ; Sat, 24 Jul 2010 11:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=x8WrFernJS3ixnlIu0yCG6CERO/SGfoJmJpVQxg4qc4=; b=vzIYX1R8uy+GFctqG53jC9RJnuIggzjOiGbjG7DQ5rFe6Q82bxTOA0mzqMzUA8AQ4/ StTT6gnRpBnj7IKEW1kOQyiJ5QGS0wc/OVOwS9jgGtnD6m+/kbyWcisKpd3aAuaBByA7 cw+d64vTbxSBX/CpZ5IGQkTtjYAnROYGUy+Vs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=C8IaIwN94o+BfH5sJCsbeKRXXbgpgafHg+DkhAdVI/WKkAGjJwphAjcDhGgpLnVX4F GkKTdN+F7VZSSNR3cDmGsTvduyqvAIu9UvHab7/Gk44JLWNNRtzZsJiY574TMiWKKTvY KRbn/vTYpOVhDpt5F1BvWOMWusWb8FZtveul0= MIME-Version: 1.0 Received: by 10.231.184.1 with SMTP id ci1mr6027814ibb.39.1279997130674; Sat, 24 Jul 2010 11:45:30 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.169.18 with HTTP; Sat, 24 Jul 2010 11:45:30 -0700 (PDT) In-Reply-To: References: <4C4AF046.40507@FreeBSD.org> Date: Sat, 24 Jul 2010 11:45:30 -0700 X-Google-Sender-Auth: DYycNkdElj3oewjlwGwek8Qanfw Message-ID: From: Garrett Cooper To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alexander Motin , freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice 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, 24 Jul 2010 18:45:32 -0000 On Sat, Jul 24, 2010 at 9:18 AM, Rui Paulo wrote: > > On 24 Jul 2010, at 14:53, Alexander Motin wrote: > >> Hi. >> >> I've make small observations of Intel TurboBoost technology under >> FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency >> of some cores if other cores are idle and power/thermal conditions >> permit. CPU core counted as idle, if it has been put into C3 or deeper >> power state (may reflect ACPI C2/C3 states). So to reach maximal >> effectiveness, some tuning may be needed. >> >> Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 >> TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was >> measuring building time of the net/mpd5 from sources, using only one CPU >> core (cpuset -l 0 time make). >> >> Untuned system (hz=3D1000): =A0 =A0 14.15 sec >> Enabled ACPI C2 (hz=3D1000+C2): 13.85 sec >> Enabled ACPI C3 (hz=3D1000+C3): 13.91 sec >> Reduced HZ (hz=3D100): =A0 =A0 =A0 =A0 =A014.16 sec >> Enabled ACPI C2 (hz=3D100+C2): =A013.85 sec >> Enabled ACPI C3 (hz=3D100+C3): =A013.86 sec >> Timers tuned* (hz=3D100): =A0 =A0 =A0 14.10 sec >> Enabled ACPI C2 (hz=3D100+C2): =A013.71 sec >> Enabled ACPI C3 (hz=3D100+C3): =A013.73 sec >> >> All numbers tested few times and are repeatable up to +/-0.01sec. >> >> *) Timers were tuned to reduce interrupt rates and respectively increase >> idle cores sleep time. These lines were added to loader.conf: >> sysctl kern.eventtimer.timer1=3Di8254 >> sysctl kern.eventtimer.timer2=3DNONE >> kern.eventtimer.singlemul=3D1 >> kern.hz=3D"100" >> >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > The numbers that you are showing doesn't show much difference. Have you t= ried buildworld? Agreed. The numbers are small enough that there could be a large degree of variation just based on environmental factors alone; there are other things that go into that as well, such as disk I/O, etc, that probably shouldn't be factored into a CPU performance test. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 20:23:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F49106564A for ; Sat, 24 Jul 2010 20:23:10 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D64498FC14 for ; Sat, 24 Jul 2010 20:23:09 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA26368 for ; Sat, 24 Jul 2010 23:23:08 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OclFT-000A3g-Rn for freebsd-hackers@FreeBSD.org; Sat, 24 Jul 2010 23:23:07 +0300 Message-ID: <4C4B4BAB.3000005@freebsd.org> Date: Sat, 24 Jul 2010 23:23:07 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: pageout question 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, 24 Jul 2010 20:23:10 -0000 There is a good deal of comments in the vm_pageout.c code that imply that we use a hysteresis approach to deal with low available pages condition. Evidence 1: /* * v_free_target and v_cache_min control pageout hysteresis. Note * that these are more a measure of the VM cache queue hysteresis * then the VM free queue. Specifically, v_free_target is the * high water mark (free+cache pages). * * v_free_reserved + v_cache_min (mostly means v_cache_min) is the * low water mark, while v_free_min is the stop. [...] Evidence 2: /* * [...] Do * not clear vm_pages_needed until we reach our target, * otherwise we may be woken up over and over again and * waste a lot of cpu. */ In general, the hysteresis, the comments and the code make sense. My doubt, though, is about the block of code that is right below the comment quoted above: if (vm_pages_needed && !vm_page_count_min()) { if (!vm_paging_needed()) vm_pages_needed = 0; wakeup(&cnt.v_free_count); } If I read this code correctly, pagedaemon would go idle as soon as vm_paging_needed() becomes false. Given the defintion of vm_paging_needed as (v_free_reserved + v_cache_min) > (v_free_count + v_cache_count) this means that pagedaemon quits paging as soon as available page count is above _low_ watermark. Which contradicts the comments and the general logic of the code. (Paging also generally starts only when vm_paging_needed() is true). I think that it also means that vm_pageout_scan is called with pass > 0 only in very very low memory conditions, where the first pass (pass=0) wasn't able to free up memory even above low watermark. But my impression is that the intention was to keep pagedaemon working until high watermark was reached (vm_paging_target() < 0). Plus, perhaps, some more depending on vm_pageout_deficit. And, yes, I see that vm_pageout_scan() has a goal of reaching vm_paging_target() + vm_pageout_deficit, but I am speaking of the case where it is unable to do so on the first pass. Do I misunderstand something? Is there a flaw in the code or are the comments outdated/misleading/not-descriptive-enough? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 20:48:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 407841065673; Sat, 24 Jul 2010 20:48:02 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 25 Jul 2010 05:48:01 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100725054801.ffb36259.nork@FreeBSD.org> In-Reply-To: <4C4AF046.40507@FreeBSD.org> References: <4C4AF046.40507@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice 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, 24 Jul 2010 20:48:03 -0000 Hi mav. On Sat, 24 Jul 2010 16:53:10 +0300 Alexander Motin wrote: > PS: In this case benefit is small, but it is the least that can be > achieved, depending on CPU model. Some models allow frequency to be > risen by up to 6 steps (+798MHz). I tested on Core i7 640UM (Arrandale 1.2GHz -> 2.26GHz) with openssl speed (w/o aesni(4)) and /usr/src/tools/tools/crypto/cryptotest.c (w/ aesni(4)). http://people.freebsd.org/~nork/aesni/aes128cbc-noaesni.pdf [1] http://people.freebsd.org/~nork/aesni/aes128cbc-aesni.pdf [2] [1] $ /usr/bin/cpuset -l$i /usr/bin/openssl speed -elapsed -mr -multi $n aes128-cbc $i = 0 1 2 3 0,1 0,2 0,3 1,2 1,3 2,3 0,1,2 0,1,3 0,2,3 1,2,3 0,1,2,3 $n = numbers of core, $((`echo $i | wc -c`/2)) [2] $ /usr/bin/cpuset -l$i ./cryptotest -t $n -z 50000 8192 $i = 0 1 2 3 0,1 0,2 0,3 1,2 1,3 2,3 0,1,2 0,1,3 0,2,3 1,2,3 0,1,2,3 $n = numbers of core, $((`echo $i | wc -c`/2)) In my environment, according to aes128cbc-noaesni.pdf, at least, 30% performace up by Turbo Boost (I think). And according to aes128cbc-aesni.pdf, at least, 100% performance up by Turbo Boost (I think). And I understand reducing single thread performance by Hyper Threading:-). -- Norikatsu Shigemura From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 22:03:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8A381065673; Sat, 24 Jul 2010 22:03:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECB578FC19; Sat, 24 Jul 2010 22:03:55 +0000 (UTC) Received: by fxm13 with SMTP id 13so6100387fxm.13 for ; Sat, 24 Jul 2010 15:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=bH8L3Uu/0DXElub7Uq7OzmKvMSgl1fQCcm6R+CydrXE=; b=vpb8BwcdPfJhlG2LN3hLVBNgXlEM6cpC9tKKI46NBt3WPvXfrQPfSZbnIfahhMtx8f An+G+23iNma5iUpPqNeDYxOxk0lQK/jThnID0Gqf6U08Suewaq/HAdyyvJMUUg8LtfBi nELX5mwU+NiodG0fBMfzDyWN8lsP3Fjo5OuAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=uSOaHu/f4DqOIB4DEEo9gAPEIGbVBsGL2Ihouis6m0m7A0zaONYoxhoBZbfZWnDyoe qamHRmkY6VbWzAsXBO2AfwMU5S1yBhqVCWuQGS4/T/cAOyrqsaaGtDT7prPXvdMIGHqu 5t0WfFeMKhrKgOoUBek1sR7zlkRNBjtqg9fBw= Received: by 10.86.70.9 with SMTP id s9mr3673877fga.7.1280009034815; Sat, 24 Jul 2010 15:03:54 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r10sm670729faq.29.2010.07.24.15.03.53 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Jul 2010 15:03:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4B6347.1070802@FreeBSD.org> Date: Sun, 25 Jul 2010 01:03:51 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Norikatsu Shigemura , freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org References: <4C4AF046.40507@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Intel TurboBoost in practice 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, 24 Jul 2010 22:03:56 -0000 Norikatsu Shigemura wrote: > On Sat, 24 Jul 2010 16:53:10 +0300 > Alexander Motin wrote: >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > I tested on Core i7 640UM (Arrandale 1.2GHz -> 2.26GHz) with > openssl speed (w/o aesni(4)) and > /usr/src/tools/tools/crypto/cryptotest.c (w/ aesni(4)). > > http://people.freebsd.org/~nork/aesni/aes128cbc-noaesni.pdf [1] > http://people.freebsd.org/~nork/aesni/aes128cbc-aesni.pdf [2] > > In my environment, according to aes128cbc-noaesni.pdf, at least, > 30% performace up by Turbo Boost (I think). The numbers are interesting, though they are not proving much, because of many other factors may influence on result. It would be more informative to do the tests with C1 and C2/C3 states used. > And according to aes128cbc-aesni.pdf, at least, 100% performance > up by Turbo Boost (I think). This IMHO is even more questionable. Single, even boosted core shouldn't be faster then 2, 3 and 4. I would say there is some scalability problem. May be context switches, locking, or something else. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 23:06:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33081065672; Sat, 24 Jul 2010 23:06:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4118FC12; Sat, 24 Jul 2010 23:06:55 +0000 (UTC) Received: by fxm13 with SMTP id 13so6110651fxm.13 for ; Sat, 24 Jul 2010 16:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=oF/QTcyggo/Ns82j6M4wI8yk7etZ8ON5En1aM9oUpkA=; b=JgX2InMMxUmCy50M0li4wSVWBFOQgfTQRqFmBemIdg/ERUTmQyLJmdZPeBEyk9IJwC 785LsPbFk3AK9DV4krjYI/bP8a8Omj2VaXFDW1lLj2Elmge3R786cE49DvBlVVLIdMCa pken2i8RN6R1hV8XtqpJDfk/B8TXw+hD5Mo8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=SBR0kxHnKeo52rH8kd1eLoMUgmz2/msIEtvxj5e8xMUHB7Ha1+rqfa7wIKhg1I7szy eS/4/Lv0t6GqC7WBqrm/7dfzwuHP0l6mAFCSzmBfET6DjnPiciB/8SKZ9b9wVTnUBhXz AEN707NP/c98DXsjNxjAglJ2aoEPTCBL8BoTo= Received: by 10.223.126.68 with SMTP id b4mr4713168fas.96.1280012814031; Sat, 24 Jul 2010 16:06:54 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r8sm690903faq.10.2010.07.24.16.06.52 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Jul 2010 16:06:53 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4B720A.6020802@FreeBSD.org> Date: Sun, 25 Jul 2010 02:06:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Rui Paulo References: <4C4AF046.40507@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel TurboBoost in practice 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, 24 Jul 2010 23:06:56 -0000 Rui Paulo wrote: > On 24 Jul 2010, at 14:53, Alexander Motin wrote: >> Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 >> TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was >> measuring building time of the net/mpd5 from sources, using only one CPU >> core (cpuset -l 0 time make). >> >> Untuned system (hz=1000): 14.15 sec >> Enabled ACPI C2 (hz=1000+C2): 13.85 sec >> Enabled ACPI C3 (hz=1000+C3): 13.91 sec >> Reduced HZ (hz=100): 14.16 sec >> Enabled ACPI C2 (hz=100+C2): 13.85 sec >> Enabled ACPI C3 (hz=100+C3): 13.86 sec >> Timers tuned* (hz=100): 14.10 sec >> Enabled ACPI C2 (hz=100+C2): 13.71 sec >> Enabled ACPI C3 (hz=100+C3): 13.73 sec >> >> All numbers tested few times and are repeatable up to +/-0.01sec. >> >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > The numbers that you are showing doesn't show much difference. Have you tried buildworld? If you mean relative difference -- as I have told, it's mostly because of my CPU. It's maximal boost is 266MHz (8.3%), but 133MHz of them is enabled most of time if CPU is not overheated. It probably doesn't, as it works on clear table under air conditioner. So maximal effect I can expect on is 4.2%. In such situation 2.8% probably not so bad to illustrate that feature works and there is space for further improvements. If I had Core i5-750S I would expect 33% boost. If you mean absolute difference, here are results or four buildworld runs: hw.acpi.cpu.cx_lowest=C1: 4654.23 sec hw.acpi.cpu.cx_lowest=C2: 4556.37 sec hw.acpi.cpu.cx_lowest=C2: 4570.85 sec hw.acpi.cpu.cx_lowest=C1: 4679.83 sec Benefit is about 2.1%. Each time results were erased and sources pre-cached into RAM. Storage was SSD, so disk should not be an issue. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 23:31:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A04F1065675 for ; Sat, 24 Jul 2010 23:31:51 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id F401C8FC1D for ; Sat, 24 Jul 2010 23:31:50 +0000 (UTC) Received: by wwf26 with SMTP id 26so1830920wwf.1 for ; Sat, 24 Jul 2010 16:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=c/Zz3jJxC6Em1dcecFq5UHhBvR6yJtQ6bvacf/+T+Tg=; b=uqXWuT5I4zb+2m8AqkQQKcuEv3NWNtpkxwQ4cuZYD8NwZxZWQpzJCnHVM+q9c/mFvK 8aSVUg/XbQayLUC23IK67+5haxPc4tzS7Ngbd1VwRZZ75M9CAytlxyU17FnBohJ4MwTM KRdImLIX3SdKZJ0Yp8DqhSZYEt7kooCcJuX7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=bbY+6hgMkc+q1XkfTs/6tXuCiIfsnW1a7mWtTvpCfcDVwtZlU218A6yHAMMO/2siJG uqwgLaTruJ1KihS+4v4ToD9XlmMUzZHgOCCkmZsmMwyniXgQZdueQhEdwMfkLDnSXegt EBAU6DEhc0sPEuQXHhj567Fgry8ETmZYyv68c= Received: by 10.227.148.2 with SMTP id n2mr5297342wbv.216.1280014309884; Sat, 24 Jul 2010 16:31:49 -0700 (PDT) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id i25sm1566575wbi.10.2010.07.24.16.31.46 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Jul 2010 16:31:46 -0700 (PDT) Date: Sun, 25 Jul 2010 00:31:44 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20100725003144.3cfead39@gumby.homeunix.com> In-Reply-To: <4C4B4BAB.3000005@freebsd.org> References: <4C4B4BAB.3000005@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: pageout question 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, 24 Jul 2010 23:31:51 -0000 On Sat, 24 Jul 2010 23:23:07 +0300 Andriy Gapon wrote: > > There is a good deal of comments in the vm_pageout.c code that imply > that we use a hysteresis approach to deal with low available pages > condition. > > > In general, the hysteresis, the comments and the code make sense. > My doubt, though, is about the block of code that is right below the > comment quoted above: > if (vm_pages_needed && !vm_page_count_min()) { > if (!vm_paging_needed()) > vm_pages_needed = 0; > wakeup(&cnt.v_free_count); > } As I understand it the hysteresis is done inside vm_pageout_scan, and the expectation is that one pass will typically satisfy this because the design aims to keep enough clean pages in the inactive queue. I'm not sure if the vm_paging_needed() call is correct or not, but it may be that that the intent is to avoid immediately going back to a depleted inactive queue when cache+free is within normal bounds, because it could result in avoidable paging to swap.