From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 00:09:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9F0F1065673 for ; Sun, 18 Dec 2011 00:09:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 815AD8FC0C for ; Sun, 18 Dec 2011 00:09:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Rc4JO-00012i-7D>; Sun, 18 Dec 2011 01:09:06 +0100 Received: from e178010078.adsl.alicedsl.de ([85.178.10.78] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Rc4JO-0005Cf-2q>; Sun, 18 Dec 2011 01:09:06 +0100 Message-ID: <4EED2F1C.2060409@zedat.fu-berlin.de> Date: Sun, 18 Dec 2011 01:09:00 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C0317AB12CA28D1EA0BF612" X-Originating-IP: 85.178.10.78 Subject: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 00:09:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C0317AB12CA28D1EA0BF612 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since three days for now I get a panic when I shutdown or reboot my FreeBSD 10.0-CURREN/amd64 box: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid =3D 0 PID 16 is always USB on my box. Any advice or tip to get rid of it? Oliver --------------enig5C0317AB12CA28D1EA0BF612 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO7S8hAAoJEOgBcD7A/5N80IQIAJ/D9grCWEHsnPLtp6jLwl8+ R/FN9AHjmySzamDCFb31f59olDM8L0nD9xbcju0Ba2E3BXdVuyGOwZLbuYjAqmWQ UWXji+t1WOPXcJpGptdiGWKKasJQ3NPazKsW/LwTP2Mt+ex2YXFSytO6dbS8q33W iFp9Xm7N5POEgVKFADJNgSTYahBgLfCcd5+HbWXNvrt54ahtJSOLO4vR/SQlXl2L 5qQMlA/N3pcQQ2oKfpFcJoGfK3Hz4FSHUllOi8xcIcQPbnZ9gPT66gr3S61gNBqu +tORwbqYq55yingGj9ImFum/XcYPKe5r7n6M9HUPXVO3d4PLDc2AwIkoursKbUs= =JAso -----END PGP SIGNATURE----- --------------enig5C0317AB12CA28D1EA0BF612-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 02:07:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8554F106564A for ; Sun, 18 Dec 2011 02:07:43 +0000 (UTC) (envelope-from kabaev@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 3B1328FC08 for ; Sun, 18 Dec 2011 02:07:42 +0000 (UTC) Received: by qcse13 with SMTP id e13so3734465qcs.13 for ; Sat, 17 Dec 2011 18:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=ZWbTuj3cOV1mBd/8kp7LqC1cYvvOOhwrXvrAPYaQ4Bc=; b=EsMxjgHg/jA6GNn3aO64fW0u5mTT84A93cEdmwkpBpw3bznwNalg28Ng6pJ7ioFswI jdDjF8hD6RTefeOMx2Usbqo3SOFycnPdqJCmMGx7an0oiqlSMT2oPjeezCNA23BwlhA+ fTKnJmw+kJBv+BNZWyW0c0XHN5r87XE1+2yWE= Received: by 10.224.96.80 with SMTP id g16mr19285577qan.13.1324172726349; Sat, 17 Dec 2011 17:45:26 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id z1sm29972013qao.1.2011.12.17.17.45.21 (version=SSLv3 cipher=OTHER); Sat, 17 Dec 2011 17:45:21 -0800 (PST) Date: Sat, 17 Dec 2011 20:45:14 -0500 From: Alexander Kabaev To: "O. Hartmann" Message-ID: <20111217204514.2fa77ea2@kan.dyndns.org> In-Reply-To: <4EED2F1C.2060409@zedat.fu-berlin.de> References: <4EED2F1C.2060409@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/iGAQuXUzLIabBzWEpzkO5Pb"; protocol="application/pgp-signature" Cc: Current FreeBSD Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 02:07:43 -0000 --Sig_/iGAQuXUzLIabBzWEpzkO5Pb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 18 Dec 2011 01:09:00 +0100 "O. Hartmann" wrote: > Sleeping thread (tid 100033, pid 16) owns a non sleepable lock > panic: sleeping thread > cpuid =3D 0 >=20 > PID 16 is always USB on my box. You really need to give us a backtrace when you quote panics. It is impossible to make any sense of the above panic message without more context. --=20 Alexander Kabaev --Sig_/iGAQuXUzLIabBzWEpzkO5Pb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFO7UWwQ6z1jMm+XZYRAv13AJ4sz+CW1SCYVIhNA2HsnSI8Pt98VACfS/Ss oM+ZW71iYTpxZq2j6NKedBo= =MdEi -----END PGP SIGNATURE----- --Sig_/iGAQuXUzLIabBzWEpzkO5Pb-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 02:37:54 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B124106566C; Sun, 18 Dec 2011 02:37:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B56E8FC12; Sun, 18 Dec 2011 02:37:54 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 223BDE6217; Sun, 18 Dec 2011 02:37:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=I57RAsWs1zbv so7bCeVdM/pSSpY=; b=b6xdib3FGaFnhcNsw3HKpuL4Frw9pbafcxRDLlUcF1dV LSQlIiGLb8icVSinnb31b5Y/4+uboqW3AV5yu0K+xR/EmzZqyzjNkgZn3Nypl3lh eRfxB0wmw2hfAUD/5fu8YgI9/UAqU9zBahZncIOTXnciT7/n2wvcJbPXhuEvUYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=CKJuiw y+HKDldo71dYnwUmH4Sg61hlB5edwnD3fANdRZy6r6HaTq653wVIdL3t1LdL1zfn VWUgIvEAyYeEdSx9L/TYy7J9dmj0qSvuiXN4khsu6ZFZlIUAFnyvXXT/nyUSF+sX gTCE50iAGB2qWGMJqXKqHSnabClkPOMoFA7j4= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id CDA1BE6216; Sun, 18 Dec 2011 02:37:52 +0000 (GMT) Message-ID: <4EED5200.20302@cran.org.uk> Date: Sun, 18 Dec 2011 02:37:52 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andrey Chernov , Ivan Klymenko , Doug Barton , "O. Hartmann" , Current FreeBSD , freebsd-stable@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> In-Reply-To: <20111213090051.GA3339@vniz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 02:37:54 -0000 On 13/12/2011 09:00, Andrey Chernov wrote: > I observe ULE interactivity slowness even on single core machine > (Pentium 4) in very visible places, like 'ps ax' output stucks in the > middle by ~1 second. When I switch back to SHED_4BSD, all slowness is > gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 buildworld" then logging into another console can take several seconds. Sometimes even the "Password:" prompt can take a couple of seconds to appear after typing my username. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 03:41:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A94106566B for ; Sun, 18 Dec 2011 03:41:16 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDF78FC0A for ; Sun, 18 Dec 2011 03:41:16 +0000 (UTC) Received: by dakp5 with SMTP id p5so4375643dak.13 for ; Sat, 17 Dec 2011 19:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1j5oa1/cEIgg1krGUAxzfzj2PNUUu2C3o6A40AsGykw=; b=Icpq6C/gXrsOpM2YdjJc0vBh5BYy8fOr8kzcktLXqz0Dzdcv0rbHtkc5A0lMJH9Djd KEdSPw3AhROK6UBD1QFaxK8TqRQfkPIsDfQ0uTdsDSuxOQCuLtZfugP5BBZKfmVFwhyK WvHjPfHh1OnlZ/gdDu25mltTq5qFHZL+BoXns= MIME-Version: 1.0 Received: by 10.68.73.228 with SMTP id o4mr28661869pbv.34.1324179675860; Sat, 17 Dec 2011 19:41:15 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.197.198 with HTTP; Sat, 17 Dec 2011 19:41:15 -0800 (PST) In-Reply-To: <20111217204514.2fa77ea2@kan.dyndns.org> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> Date: Sat, 17 Dec 2011 19:41:15 -0800 X-Google-Sender-Auth: 57i0k8WaMRG2uikcDWIZj0Ta42s Message-ID: From: mdf@FreeBSD.org To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 03:41:16 -0000 On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote: > On Sun, 18 Dec 2011 01:09:00 +0100 > "O. Hartmann" wrote: > >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> panic: sleeping thread >> cpuid = 0 >> >> PID 16 is always USB on my box. > > You really need to give us a backtrace when you quote panics. It is > impossible to make any sense of the above panic message without more > context. In the case of this panic, the stack of the thread which panics is useless; it's someone trying to propagate priority that discovered it. A backtrace on tid 100033 would be useful. With WITNESS enabled, it's possible to have this panic display the stack of the incorrectly sleeping thread at the time it acquired the lock, as well, but this code isn't in CURRENT or any release. I have a patch at $WORK I can dig up on Monday. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 07:52:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1ACA106564A; Sun, 18 Dec 2011 07:52:50 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF108FC17; Sun, 18 Dec 2011 07:52:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pBI7qhPc045514; Sun, 18 Dec 2011 11:52:43 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pBI7qgIB045513; Sun, 18 Dec 2011 11:52:42 +0400 (MSK) (envelope-from ache) Date: Sun, 18 Dec 2011 11:52:42 +0400 From: Andrey Chernov To: Ian Smith Message-ID: <20111218075241.GA45367@vniz.net> Mail-Followup-To: Andrey Chernov , Ian Smith , Bruce Cran , Ivan Klymenko , Doug Barton , "O. Hartmann" , Current FreeBSD , freebsd-stable@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111218164924.L64681@sola.nimnet.asn.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Bruce Cran , Ivan Klymenko , Doug Barton , freebsd-stable@FreeBSD.ORG, "O. Hartmann" , Current FreeBSD , freebsd-performance@FreeBSD.ORG Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 07:52:50 -0000 On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > On Sun, 18 Dec 2011 02:37:52 +0000, Bruce Cran wrote: > > On 13/12/2011 09:00, Andrey Chernov wrote: > > > I observe ULE interactivity slowness even on single core machine (Pentium > > > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 > > > second. When I switch back to SHED_4BSD, all slowness is gone. > > > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine > > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > > buildworld" then logging into another console can take several seconds. > > Sometimes even the "Password:" prompt can take a couple of seconds to appear > > after typing my username. > > I'd resigned myself to expecting this sort of behaviour as 'normal' on > my single core 1133MHz PIII-M. As a reproducable data point, running > 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat > the CPU while testing my manual fan control script, hogs it up pretty > much while regularly running the script below in another konsole to > check values - which often gets stuck half way, occasionally pausing > _twice_ before finishing. Switching back to the first konsole (on > another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 08:44:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05767106566C for ; Sun, 18 Dec 2011 08:44:12 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id B21A88FC12 for ; Sun, 18 Dec 2011 08:44:11 +0000 (UTC) Received: from exit-01d.noisetor.net ([173.254.216.69]:50361 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RcCLo-00028S-Ul; Sun, 18 Dec 2011 03:44:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=rQ8lBIGEg3vXhMR/7oyksbEPiUMryW0ZOF0pKPoJoh0=; b=iw+sKXVhlXuTAy2Rj50e4+Y5xBcQ36QTZEak8gKOvkmD0lk9Viwkt3BDVwh2gLvP7Li6XviSC5hQ8fJAtwP3beB4UbQVFs1Qqhyj+t+FhTwOJHYvP5N9r9SdIhtCbYGslSY7zeBu7ZN0d8GUnM1in9I23eTmdXiNvVSFrTohYXY=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RcCLJ-000MeI-MC; Sun, 18 Dec 2011 08:43:40 +0000 From: Jan Beich To: David Chisnall Date: Sun, 18 Dec 2011 17:40:36 +0900 References: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RcCLJ-000MeI-MC@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@FreeBSD.org Subject: Re: Heads up: New C++ stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 08:44:12 -0000 David Chisnall writes: [...] > libcxxrt and libc++ are now in contrib and building with the base > system, but are not used by anything (and are only built if you set > WITH_LIBCPLUSPLUS=yes when building world, not by default). If you > want to test some code with the new stack, you need to build it and > then specify -stdlib=libc++ to clang++ (both when compiling and > linking). Does the option work when building world with -jX ? $ make -sj2 buildworld [...] ===> lib/libcompiler_rt (obj,depend,all,install) ===> lib/libc (obj,depend,all,install) ===> lib/libcxxrt (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [libcxxrt.so.1] Error code 1 And later in silent build --verbose in LDFLAGS for libc++ produces noise that's neither a warning nor a build directory. ===> lib/libcxxrt (all) ===> lib/libc++ (all) FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210 Target: x86_64-unknown-freebsd10.0 Thread model: posix "/usr/obj/usr/src/tmp/usr/bin/ld" --eh-frame-hdr -Bshareable -o libc++.so.1 /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginS.o -L/usr/obj/usr/src/lib/libc++/../libcxxrt/ -L/usr/obj/usr/src/tmp/usr/lib -x --fatal-warnings --warn-shared-textrel -soname libc++.so.1 valarray.So utility.So strstream.So regex.So random.So iostream.So debug.So chrono.So bind.So algorithm.So hash.So thread.So future.So new.So locale.So typeinfo.So mutex.So memory.So ios.So condition_variable.So system_error.So string.So stdexcept.So exception.So -lcxxrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/obj/usr/src/tmp/usr/lib/crtendS.o /usr/obj/usr/src/tmp/usr/lib/crtn.o From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 10:24:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 389D41065670; Sun, 18 Dec 2011 10:24:01 +0000 (UTC) Date: Sun, 18 Dec 2011 10:24:01 +0000 From: Alexander Best To: Andrey Chernov , Ian Smith , Bruce Cran , Ivan Klymenko , Doug Barton , "O. Hartmann" , Current FreeBSD , freebsd-stable@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG Message-ID: <20111218102401.GA42627@freebsd.org> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111218075241.GA45367@vniz.net> Cc: Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:24:01 -0000 On Sun Dec 18 11, Andrey Chernov wrote: > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > > On Sun, 18 Dec 2011 02:37:52 +0000, Bruce Cran wrote: > > > On 13/12/2011 09:00, Andrey Chernov wrote: > > > > I observe ULE interactivity slowness even on single core machine (Pentium > > > > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 > > > > second. When I switch back to SHED_4BSD, all slowness is gone. > > > > > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine > > > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > > > buildworld" then logging into another console can take several seconds. > > > Sometimes even the "Password:" prompt can take a couple of seconds to appear > > > after typing my username. > > > > I'd resigned myself to expecting this sort of behaviour as 'normal' on > > my single core 1133MHz PIII-M. As a reproducable data point, running > > 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat > > the CPU while testing my manual fan control script, hogs it up pretty > > much while regularly running the script below in another konsole to > > check values - which often gets stuck half way, occasionally pausing > > _twice_ before finishing. Switching back to the first konsole (on > > another desktop) to kill the dd can also take a couple/few seconds. > > This issue not about slow machine under load, because the same > slow machine under exact the same load, but with SCHED_4BSD is very fast > to response interactively. > > I think we should not misinterpret interactivity with speed. I see no big > speed (i.e. compilation time) differences, switching schedulers, but see > big _interactivity_ difference. ULE in general tends to underestimate > interactive processes in favour of background ones. It perhaps helps to > compilation, but looks like slowpoke OS from the interactive user > experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used "direcory = /var/db/portsnap", because that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes > 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data -> change data -> writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex > > -- > http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 10:26:00 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id B25331065679; Sun, 18 Dec 2011 10:26:00 +0000 (UTC) Date: Sun, 18 Dec 2011 10:26:00 +0000 From: Alexander Best To: Andrey Chernov , Ian Smith , Bruce Cran , Ivan Klymenko , Doug Barton , "O. Hartmann" , Current FreeBSD , freebsd-stable@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG Message-ID: <20111218102600.GA44118@freebsd.org> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111218102401.GA42627@freebsd.org> Cc: Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:26:00 -0000 On Sun Dec 18 11, Alexander Best wrote: > On Sun Dec 18 11, Andrey Chernov wrote: > > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > > > On Sun, 18 Dec 2011 02:37:52 +0000, Bruce Cran wrote: > > > > On 13/12/2011 09:00, Andrey Chernov wrote: > > > > > I observe ULE interactivity slowness even on single core machine (Pentium > > > > > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 > > > > > second. When I switch back to SHED_4BSD, all slowness is gone. > > > > > > > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine > > > > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > > > > buildworld" then logging into another console can take several seconds. > > > > Sometimes even the "Password:" prompt can take a couple of seconds to appear > > > > after typing my username. > > > > > > I'd resigned myself to expecting this sort of behaviour as 'normal' on > > > my single core 1133MHz PIII-M. As a reproducable data point, running > > > 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat > > > the CPU while testing my manual fan control script, hogs it up pretty > > > much while regularly running the script below in another konsole to > > > check values - which often gets stuck half way, occasionally pausing > > > _twice_ before finishing. Switching back to the first konsole (on > > > another desktop) to kill the dd can also take a couple/few seconds. > > > > This issue not about slow machine under load, because the same > > slow machine under exact the same load, but with SCHED_4BSD is very fast > > to response interactively. > > > > I think we should not misinterpret interactivity with speed. I see no big > > speed (i.e. compilation time) differences, switching schedulers, but see > > big _interactivity_ difference. ULE in general tends to underestimate > > interactive processes in favour of background ones. It perhaps helps to > > compilation, but looks like slowpoke OS from the interactive user > > experience. > > +1 > > i've also experienced issues with ULE and performed several tests to compare > it to the historical 4BSD scheduler. the difference between the two does *not* > seem to be speed (at least not a huge difference), but interactivity. > > one of the tests i performed was the following > > ttyv0: untar a *huge* (+10G) archive > ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory > contains a lot of files. i used "direcory = /var/db/portsnap", because s/portsnap/portsnap\/files/ > that directory contains 23117 files on my machine. > > measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes > 15 > seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. > io operations usually get a high priority, because statistics have shown that > - unlike computational tasks - io intensive tasks only run for a small fraction > of time and then exit: read data -> change data -> writeback data. > > so SCHED_ULE might take these statistics too literaly and gives tasks like > bsdtar(1) (in my case) too many ressources, so other tasks which require io are > struggling to get some ressources assigned to them (ls(1) in my case). > > of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 > testsuite. your whole system will grind to a halt. mouse input drops below > 1 HZ. even after killing all the stress2 tests, it will take a few minutes > after the system becomes snappy again. > > cheers. > alex > > > > > -- > > http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 13:06:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44465106566B; Sun, 18 Dec 2011 13:06:31 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E8FE58FC15; Sun, 18 Dec 2011 13:06:30 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1F7D9E6217; Sun, 18 Dec 2011 13:06:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=CE3PwiyBFxMN P4zTc90HsRMiDFw=; b=NACr+W25m0muexI8+wm1yE6bU1nUAjs7VqpSHaaIte1m NODToyjY5WJEFYtXhzmm+9yNDUn2sxvrIRUes62OcNdBNAXW+s9k95Ukm1QhRHOi 2fY97x8pZrL+G52iSEACbf7IRsAzqym1DOXwmUXScEXo1i+yYLShkjPC/1WsSZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=UYQWJe SDJtZ2NR0gXrJ+2QIcy7VTd4je7kCbkXZdXAC9VegGI8DZLPhNR9JMH4iu7KSzk6 flV8ZvD3628mmgL58RCVag2p5fjpDlB3soYyhcbTNpSZDn+euUnS3g3Ce+Tt/wvB L5wZLpkueRjPESaAww3xDqQQkgrQUOYGPHha4= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id E9B67E61F0; Sun, 18 Dec 2011 13:06:29 +0000 (GMT) Message-ID: <4EEDE554.6050303@cran.org.uk> Date: Sun, 18 Dec 2011 13:06:28 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Adrian Chadd References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Current FreeBSD Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 13:06:31 -0000 On 18/12/2011 10:34, Adrian Chadd wrote: > I applaud reppie for trying to make it as easy as possible for people > to use KTR to provide scheduler traces for him to go digging with, so > please, if you have these issues and you can absolutely reproduce > them, please follow his instructions and work with him to get him what > he needs. Who's 'reppie'? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 13:13:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81E46106566C for ; Sun, 18 Dec 2011 13:13:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3846E8FC14 for ; Sun, 18 Dec 2011 13:13:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RcGYN-0002rz-8Z>; Sun, 18 Dec 2011 14:13:23 +0100 Received: from e178040031.adsl.alicedsl.de ([85.178.40.31] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RcGYM-00045N-4S>; Sun, 18 Dec 2011 14:13:23 +0100 Message-ID: <4EEDE6EA.9080101@zedat.fu-berlin.de> Date: Sun, 18 Dec 2011 14:13:14 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Kabaev References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> In-Reply-To: <20111217204514.2fa77ea2@kan.dyndns.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1159A2A0E504D95061D0D347" X-Originating-IP: 85.178.40.31 Cc: Current FreeBSD Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 13:13:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1159A2A0E504D95061D0D347 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/18/11 02:45, Alexander Kabaev wrote: > On Sun, 18 Dec 2011 01:09:00 +0100 > "O. Hartmann" wrote: >=20 >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> panic: sleeping thread >> cpuid =3D 0 >> >> PID 16 is always USB on my box. >=20 > You really need to give us a backtrace when you quote panics. It is > impossible to make any sense of the above panic message without more > context. >=20 Sorry, will do this immediately when I'm back in the lab. Regards, Oliver --------------enig1159A2A0E504D95061D0D347 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO7ebvAAoJEOgBcD7A/5N85ssH/3h9oLIT9j7kVYwLENn7hoS4 sAqaP/j0GW859liCMP7gCWPDJ1pML+4jfEgKhkaG4BdX0fD0igszeg+5Kzl4VQ/a q7NUaXhVMtdYTiTG86JvjbYRD1Qb9IWfsdhJte49aVx7mF833s1NlkW2NaQiLxhO h/DPGednHKUPwjM2soA9rR/vEsoWZILpL6Sl5sVV5y+VJwvwr6pV8RnM7lIbiiAN ikQR7weCTa7bNDstNcle0w6ws54GNWHvQq3KSdPOFe+zNwqrKU0y3Q1SjZVnUlNj FhJOhotE5e/Aq4UFRK8VRnvY3K5RroosP8LnAtc9rpYtlBYeFus60Yn0RlB3pFQ= =LChu -----END PGP SIGNATURE----- --------------enig1159A2A0E504D95061D0D347-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 13:44:33 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC67F106566B; Sun, 18 Dec 2011 13:44:33 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD558FC08; Sun, 18 Dec 2011 13:44:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RcH2V-0005UK-Q5>; Sun, 18 Dec 2011 14:44:31 +0100 Received: from e178040031.adsl.alicedsl.de ([85.178.40.31] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RcH2V-0005T0-9K>; Sun, 18 Dec 2011 14:44:31 +0100 Message-ID: <4EEDEE38.10802@zedat.fu-berlin.de> Date: Sun, 18 Dec 2011 14:44:24 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Bruce Cran References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> In-Reply-To: <4EED5200.20302@cran.org.uk> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2AFB91AE4784E4B43C44794" X-Originating-IP: 85.178.40.31 Cc: Ivan Klymenko , Doug Barton , freebsd-stable@FreeBSD.ORG, "O. Hartmann" , Current FreeBSD , freebsd-performance@FreeBSD.ORG Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 13:44:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2AFB91AE4784E4B43C44794 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/18/11 03:37, Bruce Cran wrote: > On 13/12/2011 09:00, Andrey Chernov wrote: >> I observe ULE interactivity slowness even on single core machine >> (Pentium 4) in very visible places, like 'ps ax' output stucks in the >> middle by ~1 second. When I switch back to SHED_4BSD, all slowness is >> gone.=20 >=20 > I'm also seeing problems with ULE on a dual-socket quad-core Xeon > machine with 16 logical CPUs. If I run "tar xf somefile.tar" and "make > -j16 buildworld" then logging into another console can take several > seconds. Sometimes even the "Password:" prompt can take a couple of > seconds to appear after typing my username. >=20 I reported ages ago several problems using SCHED_ULE on FreeBSD 8/9 when doing heavy I/O, either disk or network bound (that time I realised the problem on servers doing heavy disk I/O or net I/O). It was suspected that X could be the problem, but we also have a Dell PowerEdge 1950III running FreeBSD 8.2-STABLE (by next week 9.0-RC[2/3]/STABLE) without X, but the same problems, but no so prominent as with X. The box has 8 cores, 4 cores per socket each and 16 GB RAM, SAS 6/iR controller and two PCI-X attached Broacom NexTreme NICs, so the hardware shouldn't be any kind of trouble. But that time (over the past two years for now), the problem was considered "a personal" problem. Bah! By the beginning of next year my working group expects new hardware. Since we use for Linux for scientific work (due to OpenCL and CUDA on TESLA cards), I can't use the Blade system. The boxes I expect is one Dell Precission T7500, 96 GB RAM, two sockets, two Westmere XEONs each socket with a summary of 12 cores/24 threads. I'll start a dual OS installation with FreeBSD 10 and the most recent Suse (since the development is mostly done by my colleagues on Suse for the C2075 TESLA board, I need Suse Linux). I will then being capable of performing some benchmarks on both boxes on the very same hardware. The other box will be my desk's box, a brand new Sandy-Bridge E CPU (i7-3960X) with 32 GB RAM. I'm also inclined to install a dual boot box (I rejected this up to now since I do not like to install GRUB2 for having multiboot when using GPT on FreeBSD). The box will run with FreeBSD 9 and an Ubuntu or Gentoo Linux, if. I'm unsure in the question of Linux, but I tend to have Gentoo for compiling everything myself. On this box, I also can perform benchmarks with several setups. I see forward getting some help and/or tips to proof the issues we discussed here. Oliver --------------enigF2AFB91AE4784E4B43C44794 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO7e44AAoJEOgBcD7A/5N8JXIH/2jHjjXDyixlNuzilTAjLsCC gIG+hgdaUPpFIgNabsAEKQAyVzds3XnaxKXa6GO4LfZt0HNS0Cvi+HlAsjecVkBA 0zszqtIH69VS9HNjilTb9V3gWtOqZDjcuHAHHTjk1NguCRVhKwysH02LNi4ZABvB ZqabSecsa0aNdWPE3g8FjuItRvG32SpghXh4eYzNdgOqv5mlFbWR4Wh2QogOD5FI YNGWq95ZzAqVpvOj70RgnqRLVzWHRzGO9fEi/ePLABERKn6nJJzJImCU6R4QQU65 n5nWWtdGbTQs38ZL7K3lT4u15bpDq1pn+spkKSAldcFLjfJoNUYm0gptpSYDjxc= =xVHZ -----END PGP SIGNATURE----- --------------enigF2AFB91AE4784E4B43C44794-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 16:30:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 252A9106566B; Sun, 18 Dec 2011 16:30:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E1C828FC0C; Sun, 18 Dec 2011 16:30:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBIGUb2p041260; Sun, 18 Dec 2011 11:30:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBIGUbcf041259; Sun, 18 Dec 2011 16:30:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Dec 2011 16:30:37 GMT Message-Id: <201112181630.pBIGUbcf041259@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 16:30:39 -0000 TB --- 2011-12-18 15:26:46 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-18 15:26:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-12-18 15:26:46 - cleaning the object tree TB --- 2011-12-18 15:26:57 - cvsupping the source tree TB --- 2011-12-18 15:26:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-12-18 15:27:43 - building world TB --- 2011-12-18 15:27:43 - CROSS_BUILD_TESTING=YES TB --- 2011-12-18 15:27:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-18 15:27:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-18 15:27:43 - SRCCONF=/dev/null TB --- 2011-12-18 15:27:43 - TARGET=sparc64 TB --- 2011-12-18 15:27:43 - TARGET_ARCH=sparc64 TB --- 2011-12-18 15:27:43 - TZ=UTC TB --- 2011-12-18 15:27:43 - __MAKE_CONF=/dev/null TB --- 2011-12-18 15:27:43 - cd /src TB --- 2011-12-18 15:27:43 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 18 15:27:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 18 16:25:50 UTC 2011 TB --- 2011-12-18 16:25:50 - generating LINT kernel config TB --- 2011-12-18 16:25:50 - cd /src/sys/sparc64/conf TB --- 2011-12-18 16:25:50 - /usr/bin/make -B LINT TB --- 2011-12-18 16:25:50 - cd /src/sys/sparc64/conf TB --- 2011-12-18 16:25:50 - /usr/sbin/config -m LINT TB --- 2011-12-18 16:25:50 - building LINT kernel TB --- 2011-12-18 16:25:50 - CROSS_BUILD_TESTING=YES TB --- 2011-12-18 16:25:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-18 16:25:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-18 16:25:50 - SRCCONF=/dev/null TB --- 2011-12-18 16:25:50 - TARGET=sparc64 TB --- 2011-12-18 16:25:50 - TARGET_ARCH=sparc64 TB --- 2011-12-18 16:25:50 - TZ=UTC TB --- 2011-12-18 16:25:50 - __MAKE_CONF=/dev/null TB --- 2011-12-18 16:25:50 - cd /src TB --- 2011-12-18 16:25:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 18 16:25:50 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors In file included from /src/sys/dev/e1000/if_em.c:400: /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' pointer /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt' in something not a structure or union *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-18 16:30:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-18 16:30:37 - ERROR: failed to build LINT kernel TB --- 2011-12-18 16:30:37 - 3031.62 user 703.09 system 3830.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 16:41:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB517106564A for ; Sun, 18 Dec 2011 16:41:56 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 239FE8FC12 for ; Sun, 18 Dec 2011 16:41:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBIGfs1n048972; Sun, 18 Dec 2011 20:41:54 +0400 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBIGfsAX048971; Sun, 18 Dec 2011 20:41:54 +0400 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 18 Dec 2011 20:41:54 +0400 From: Gleb Smirnoff To: Alexander Leidinger Message-ID: <20111218164154.GH67033@glebius.int.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 16:41:56 -0000 Alexander, On Sat, Dec 17, 2011 at 03:08:43PM +0100, Alexander Leidinger wrote: A> we never had a kernel part in the list. Reinstallkernel is not a valid target after updating the sources. The renaming will only take effekt after updating. And we already hat issues because the list was too long. A> Your entry for the carp module is completely out of question for this list. Please remove it. The file /boot/kernel/if_carp.ko had been installed on older installations. It is not overwritten now. Thus, it may happen in a some weird case, that it is left intact. 'make installkernel' is not the only way to upgrade FreeBSD. To cover these potential cases I have added an entry. This entry doesn't hurt anybody or anything. The argument for getting list of ObsoleteFiles.inc can't be taken seriously. The fact is that this file is going to instantly grow in any forseen future. It is never going to get shorter. Thus, if we are getting problems with the list getting too long, then we need to enhance the script that delete old files, not try to reduce it by 0.0235% removing one of recent entries, that is uncertain. I am adding current@ to CC, may be someone can take role of negotiator on this issue, or just has opinion. A> A> Bye, A> Alexander. A> A> -- A> Send via an Android device, please forgive brevity and typographic and spelling errors.šGleb Smirnoff hat geschrieben:ššAlexander, A> A> On Fri, Dec 16, 2011 at 05:49:03PM +0100, Alexander Leidinger wrote: A> A> the ObsoleteFiles part ist not necessary, please remove. The installkernel moves the old stuff to kernel.old. A> A> I know that it does, and for 99% people this entry won't be needed. A> But let it be here for those, who install new kernel some other way, A> for example 'make reinstallkernel' or even copying by hand. A> A> The superfluous entry in ObsoleteFiles.inc has zero negative impact, A> anyway. A> A> -- A> Totus tuus, Glebius. A> -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 18:24:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125BC106564A; Sun, 18 Dec 2011 18:24:00 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BA7508FC08; Sun, 18 Dec 2011 18:23:59 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3338B6FE5; Sun, 18 Dec 2011 18:07:51 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D111A899E; Sun, 18 Dec 2011 19:07:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD Tinderbox References: <201112181630.pBIGUbcf041259@freebsd-current.sentex.ca> Date: Sun, 18 Dec 2011 19:07:50 +0100 In-Reply-To: <201112181630.pBIGUbcf041259@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Sun, 18 Dec 2011 16:30:37 GMT") Message-ID: <86sjkh21op.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 18:24:00 -0000 FreeBSD Tinderbox writes: > In file included from /src/sys/dev/e1000/if_em.c:400: > /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': > /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' p= ointer > /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt'= in something not a structure or union > *** Error code 1 I made a mistake when I added support for additional LINT kernels (e.g. LINT-NOINET) so the additional kernels got built, but plain LINT didn't. As a result, this error has gone unnoticed by the tinderbox, even though it's been there for quite a while (or so I've been told). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 19:30:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3088A106566B; Sun, 18 Dec 2011 19:30:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 869458FC13; Sun, 18 Dec 2011 19:30:22 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6136989vcb.13 for ; Sun, 18 Dec 2011 11:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pEMdRrRcg5AdO9mTsB5TVaSe5Rr8mYJWphMeEd5LAQU=; b=fMxLrJpJs/kTvqbQG2tV/S2y1ll4h8EeAc41ApKIh6AXe1lCNazURdMyop/PEna306 WpeUWl6lohIKrYLLoi+/hM5ExM3EnmhQ8Qmq/UJrjWP6sUR3e2QSciK5F27nAbWQqQNr 1NOQvwFuP7x4jCbqHHHD3J94WljX3eEwxhl58= MIME-Version: 1.0 Received: by 10.220.230.67 with SMTP id jl3mr8014809vcb.60.1324236621811; Sun, 18 Dec 2011 11:30:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 11:30:21 -0800 (PST) In-Reply-To: <4EEDEE38.10802@zedat.fu-berlin.de> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <4EEDEE38.10802@zedat.fu-berlin.de> Date: Sun, 18 Dec 2011 11:30:21 -0800 X-Google-Sender-Auth: WbSSY3HSHYssZHOU3fhvNmQzWNs Message-ID: From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , Ivan Klymenko , Doug Barton , freebsd-stable@freebsd.org, "O. Hartmann" , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 19:30:23 -0000 Hi, What Attilllo and others need are KTR traces in the most stripped down example of interactive-busting workload you can find. Eg: if you're doing 32 concurrent buildworlds and trying to test interactivity - fine, but that's going to result in a lot of KTR stuff. If you can reproduce it using a dd via /dev/null and /dev/random (like another poster did) with nothing else running, then even better. If you can do it without X running, even better. I honestly suggest ignoring benchmarks for now and concentrating on interactivity. Adrian From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 20:14:17 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3992D106566B for ; Sun, 18 Dec 2011 20:14:17 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A66D8FC12 for ; Sun, 18 Dec 2011 20:14:17 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 16B0C6100 for ; Sun, 18 Dec 2011 15:14:16 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=POCSbfOBPwDqR4bcQvgLl446pJRZjO64brwr7SH9CYo+hOhz9PB1xsUT5JnxmxEW/ 2B6C9lSrN0LNX76ntQXvn8lvNThts3vacRX9Zvm0VYnmtczb3WnTwFffzozAueV Message-ID: <4EEE4996.3060308@protected-networks.net> Date: Sun, 18 Dec 2011 15:14:14 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: undefined OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: openpam oddity? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 20:14:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7uSZYACgkQQv9rrgRC1JIrRQCgqygegBs0ibpRs83I+OwnDDiC LPMAn33nPgvJFqNxPOFXlzNL27hHVv/0 =Pp8J -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 20:20:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757A1106564A for ; Sun, 18 Dec 2011 20:20:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 432588FC15 for ; Sun, 18 Dec 2011 20:20:24 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2052245obb.13 for ; Sun, 18 Dec 2011 12:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FjMWGUz1WkszIBOzt+LJM8nIZerDHvaIosyL+boU5og=; b=OShpndeP2Di6MOn3wlzcmfi2irt5m2S9sRHW3mJMkuLemNLs69GKObjwOGgzC7FneH izWMsAq6LGKQFX/ETQ/mpeBVYCSxNGHLWV5OCLIi1N1I7rlwYAZNbN+LidEWNtewoCQY 1K8GsQsV++Anrk3MoHracVceFZn7jkBobrvp0= MIME-Version: 1.0 Received: by 10.182.115.5 with SMTP id jk5mr8937874obb.6.1324239624695; Sun, 18 Dec 2011 12:20:24 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sun, 18 Dec 2011 12:20:24 -0800 (PST) In-Reply-To: <4EEE4996.3060308@protected-networks.net> References: <4EEE4996.3060308@protected-networks.net> Date: Sun, 18 Dec 2011 12:20:24 -0800 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: openpam oddity? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 20:20:25 -0000 On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Any ideas why courier-authdaemon is now reporting .. > > authdaemond: in openpam_dynamic(): No error: 0 > authdaemond: in openpam_load_module(): no pam_unix.so found > > I've recompiled libpam and courier from scratch :-( What version of CURRENT are you using? -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 20:22:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9690E106564A for ; Sun, 18 Dec 2011 20:22:30 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6325C8FC08 for ; Sun, 18 Dec 2011 20:22:30 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 96A4B6100; Sun, 18 Dec 2011 15:22:29 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=JPZcQaV3yvJzKf6ItzCXQxIt0KADxjcz7yQ2MrsDzpPSeveQxDaYu3Z7PLcFCIV5Q OHyQj4Ddy6D4VvWvphey2LG5N96OP5MQh2NoNVjTG1cHX4ENxKZDMD3zf+e9u2t Message-ID: <4EEE4B83.9090401@protected-networks.net> Date: Sun, 18 Dec 2011 15:22:27 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EEE4996.3060308@protected-networks.net> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: openpam oddity? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 20:22:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/18/11 15:20, Garrett Cooper wrote: > On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Any ideas why courier-authdaemon is now reporting .. >> >> authdaemond: in openpam_dynamic(): No error: 0 >> authdaemond: in openpam_load_module(): no pam_unix.so found >> >> I've recompiled libpam and courier from scratch :-( > > What version of CURRENT are you using? > -Garrett SVN r228663: Sat Dec 17 17:33:23 EST 2011 imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7uS4MACgkQQv9rrgRC1JKmmQCfTn4S4CNBKtcDAje9nrGtvk+/ vdAAoKaAENaXFvSOrIycJrgqv1t878Hp =K7Yq -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 01:25:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C05C106566B; Wed, 14 Dec 2011 01:25:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3139C8FC12; Wed, 14 Dec 2011 01:25:18 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBE1PEwA000923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Dec 2011 12:25:14 +1100 Date: Wed, 14 Dec 2011 12:25:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ivan Klymenko In-Reply-To: <20111214013906.068f69df@nonamehost.> Message-ID: <20111214115809.T1563@besplex.bde.org> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213230441.GB42285@stack.nl> <20111214013906.068f69df@nonamehost.> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1963381402-1323825914=:1563" X-Mailman-Approved-At: Sun, 18 Dec 2011 21:56:49 +0000 Cc: Doug Barton , freebsd-stable@freebsd.org, Jilles Tjoelker , "O. Hartmann" , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 01:25:19 -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-1963381402-1323825914=:1563 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 14 Dec 2011, Ivan Klymenko wrote: > =D0=92 Wed, 14 Dec 2011 00:04:42 +0100 > Jilles Tjoelker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote: >>> If the algorithm ULE does not contain problems - it means the >>> problem has Core2Duo, or in a piece of code that uses the ULE >>> scheduler. I already wrote in a mailing list that specifically in >>> my case (Core2Duo) partially helps the following patch: >>> --- sched_ule.c.orig=092011-11-24 18:11:48.000000000 +0200 >>> +++ sched_ule.c=092011-12-10 22:47:08.000000000 +0200 >>> ... >>> @@ -2118,13 +2119,21 @@ >>> =09struct td_sched *ts; >>> >>> =09THREAD_LOCK_ASSERT(td, MA_OWNED); >>> +=09if (td->td_pri_class & PRI_FIFO_BIT) >>> +=09=09return; >>> +=09ts =3D td->td_sched; >>> +=09/* >>> +=09 * We used up one time slice. >>> +=09 */ >>> +=09if (--ts->ts_slice > 0) >>> +=09=09return; >> >> This skips most of the periodic functionality (long term load >> balancer, saving switch count (?), insert index (?), interactivity >> score update for long running thread) if the thread is not going to >> be rescheduled right now. >> >> It looks wrong but it is a data point if it helps your workload. > > Yes, I did it for as long as possible to delay the execution of the code = in section: I don't understand what you are doing here, but recently noticed that the timeslicing in SCHED_4BSD is completely broken. This bug may be a feature. SCHED_4BSD doesn't have its own timeslice counter like ts_slice above. It uses `switchticks' instead. But switchticks hasn't been usable for this purpose since long before SCHED_4BSD started using it for this purpose. switchticks is reset on every context switch, so it is useless for almost all purposes -- any interrupt activity on a non-fast interrupt clobbers it. Removing the check of ts_slice in the above and always returning might give a similar bug to the SCHED_4BSD one. I noticed this while looking for bugs in realtime scheduling. In the above, returning early for PRI_FIFO_BIT also skips most of the periodic functionality. In SCHED_4BSD, returning early is the usual case, so the PRI_FIFO_BIT might as well not be checked, and it is the unusual fifo scheduling case (which is supposed to only apply to realtime priority threads) which has a chance of working as intended, while the usual roundrobin case degenerates to an impure form of fifo scheduling (iit is impure since priority decay still works so it is only fifo among threads of the same priority). >>... >>> @@ -2144,9 +2153,6 @@ >>> =09=09if >>> (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx])) >>> tdq->tdq_ridx =3D tdq->tdq_idx; } >>> -=09ts =3D td->td_sched; >>> -=09if (td->td_pri_class & PRI_FIFO_BIT) >>> -=09=09return; >>> =09if (PRI_BASE(td->td_pri_class) =3D=3D PRI_TIMESHARE) { >>> =09=09/* >>> =09=09 * We used a tick; charge it to the thread so >>> @@ -2157,11 +2163,6 @@ >>> =09=09sched_priority(td); >>> =09} >>> =09/* >>> -=09 * We used up one time slice. >>> -=09 */ >>> -=09if (--ts->ts_slice > 0) >>> -=09=09return; >>> -=09/* >>> =09 * We're out of time, force a requeue at userret(). >>> =09 */ >>> =09ts->ts_slice =3D sched_slice; With the ts_slice check here before you moved it, removing it might give buggy behaviour closer to SCHED_4BSD. >>> and refusal to use options FULL_PREEMPTION 4-5 years ago, I found that any form of PREMPTION was a pessimization for at least makeworld (since it caused too many context switches). PREEMPTION was needed for the !SMP case, at least partly because of the broken switchticks (switchticks, when it works, gives voluntary yielding by some CPU hogs in the kernel. PREEMPTION, if it works, should do this better). So I used PREEMPTION in the !SMP case and not for the SMP case. I didn't worry about the CPU hogs in the SMP case since it is rare to have more than 1 of them and 1 will use at most 1/2 of a multi-CPU system. >>> But no one has unsubscribed to my letter, my patch helps or not in >>> the case of Core2Duo... >>> There is a suspicion that the problems stem from the sections of >>> code associated with the SMP... >>> Maybe I'm in something wrong, but I want to help in solving this >>> problem ... The main point of SCHED_ULE is to give better affinity for multi-CPU systems. But the `multi' apparently needs to be strictly more than 2 for it to brak even. Bruce --0-1963381402-1323825914=:1563-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 10:41:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EFDF106564A; Thu, 15 Dec 2011 10:41:16 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id E745C8FC08; Thu, 15 Dec 2011 10:41:15 +0000 (UTC) Received: from [188.108.237.120] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rb8kU-0008KX-Lp; Thu, 15 Dec 2011 11:41:14 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Michael Larabel" References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> Date: Thu, 15 Dec 2011 11:41:05 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <4EE9C79B.7080607@phoronix.com> User-Agent: Opera Mail/11.60 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.3/14124/Wed Dec 14 16:10:02 2011) X-Mailman-Approved-At: Sun, 18 Dec 2011 21:58:39 +0000 Cc: FreeBSD Stable Mailing List , freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 10:41:16 -0000 Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel : > On 12/15/2011 02:48 AM, Michael Ross wrote: >> Anyway these tests were performed on different hardware, FWIW. >> And with different filesystems, different compilers, different GUIs... >> >> > > No, the same hardware was used for each OS. > The picture under the heading "System Hardware / Software" does not reflect that. Motherboard description differs, Chipset description for FreeBSD is empty. Regards, Michael > In terms of the software, the stock software stack for each OS was used. > > -- Michael From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 10:55:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0498106566C; Thu, 15 Dec 2011 10:55:21 +0000 (UTC) (envelope-from michael.larabel@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9892D8FC16; Thu, 15 Dec 2011 10:55:21 +0000 (UTC) Received: from c-98-193-96-120.hsd1.il.comcast.net ([98.193.96.120] helo=[172.16.93.133]) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rb8y8-0001HY-46; Thu, 15 Dec 2011 04:55:20 -0600 Message-ID: <4EE9D214.3070906@phoronix.com> Date: Thu, 15 Dec 2011 04:55:16 -0600 From: Michael Larabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Ross References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Sun, 18 Dec 2011 21:58:55 +0000 Cc: "O. Hartmann" , freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 10:55:21 -0000 On 12/15/2011 04:41 AM, Michael Ross wrote: > Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel > : > >> On 12/15/2011 02:48 AM, Michael Ross wrote: > >>> Anyway these tests were performed on different hardware, FWIW. >>> And with different filesystems, different compilers, different GUIs... >>> >>> >> >> No, the same hardware was used for each OS. >> > > The picture under the heading "System Hardware / Software" does not > reflect that. > > Motherboard description differs, Chipset description for FreeBSD is > empty. > I was the on that carried out the testing and know that it was on the same system. All of the testing, including the system tables, is fully automated. Under FreeBSD sometimes the parsing of some component strings isn't as nice as Linux and other supported operating systems by the Phoronix Test Suite. For the BSD motherboard string parsing it's grabbing hw.vendor/hw.product from sysctl. Is there a better place to read the motherboard DMI information from? -- Michael > > Regards, > > Michael > > >> In terms of the software, the stock software stack for each OS was used. >> >> -- Michael > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 11:19:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D734106564A; Thu, 15 Dec 2011 11:19:10 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id 50C488FC12; Thu, 15 Dec 2011 11:19:09 +0000 (UTC) Received: from [188.108.237.120] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rb9L7-0005Np-8H; Thu, 15 Dec 2011 12:19:07 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Michael Larabel" References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> <4EE9D214.3070906@phoronix.com> Date: Thu, 15 Dec 2011 12:18:55 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <4EE9D214.3070906@phoronix.com> User-Agent: Opera Mail/11.60 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.3/14124/Wed Dec 14 16:10:02 2011) X-Mailman-Approved-At: Sun, 18 Dec 2011 21:59:30 +0000 Cc: "O. Hartmann" , freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 11:19:10 -0000 Am 15.12.2011, 11:55 Uhr, schrieb Michael Larabel : > On 12/15/2011 04:41 AM, Michael Ross wrote: >> Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel >> : >> >>> On 12/15/2011 02:48 AM, Michael Ross wrote: >> >>>> Anyway these tests were performed on different hardware, FWIW. >>>> And with different filesystems, different compilers, different GUIs... >>>> >>>> >>> >>> No, the same hardware was used for each OS. >>> >> >> The picture under the heading "System Hardware / Software" does not >> reflect that. >> >> Motherboard description differs, Chipset description for FreeBSD is >> empty. >> > > I was the on that carried out the testing and know that it was on the > same system. No offense. I'm not doubting you. But I didn't know this: > All of the testing, including the system tables, is fully automated. > Under FreeBSD sometimes the parsing of some component strings isn't as > nice as Linux and other supported operating systems by the Phoronix Test > Suite. For the BSD motherboard string parsing it's grabbing > hw.vendor/hw.product from sysctl. so maybe you can understand how I got my impression. NVidia Audio and Realtek Audio. Looks different to me :-) > Is there a better place to read the motherboard DMI information from? > Following Steven Hartlands' suggestion, from one of my machines: /usr/ports/sysutils/dmidecode/#sysctl -a | egrep "hw.vendor|hw.product" /usr/ports/sysutils/dmidecode/#dmidecode -t 2 # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: FUJITSU Product Name: D2759 Version: S26361-D2759-A13 WGS04 GS02 Serial Number: 35838599 Asset Tag: - Features: Board is a hosting board Board is removable Location In Chassis: - Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Nice. Didn't know about that. Regards, Michael From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 11:41:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607A5106564A; Thu, 15 Dec 2011 11:41:09 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id B46488FC0A; Thu, 15 Dec 2011 11:41:08 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id pBFBS2Se088641; Thu, 15 Dec 2011 12:28:02 +0100 (CET) Received: from [217.29.45.158] ([217.29.45.158]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id pBFBS1ub088347; Thu, 15 Dec 2011 12:28:01 +0100 (CET) (envelope-from hausen@punkt.de) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: "Patrick M. Hausen" In-Reply-To: Date: Thu, 15 Dec 2011 12:28:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F38630E-D884-4B33-B64F-2631218C60E4@punkt.de> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> <4EE9D214.3070906@phoronix.com> To: "Michael Ross" X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Sun, 18 Dec 2011 21:59:41 +0000 Cc: Michael Larabel , FreeBSD Stable Mailing List , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 11:41:09 -0000 Hi, all, Am 15.12.2011 um 12:18 schrieb Michael Ross: > Following Steven Hartlands' suggestion, > from one of my machines: >=20 > /usr/ports/sysutils/dmidecode/#sysctl -a | egrep = "hw.vendor|hw.product" >=20 > /usr/ports/sysutils/dmidecode/#dmidecode -t 2 > # dmidecode 2.11 > SMBIOS 2.6 present. >=20 > Handle 0x0002, DMI type 2, 15 bytes > Base Board Information > Manufacturer: FUJITSU > Product Name: D2759 > Version: S26361-D2759-A13 WGS04 GS02 > Serial Number: 35838599 > Asset Tag: - > Features: > Board is a hosting board > Board is removable > Location In Chassis: - > Chassis Handle: 0x0003 > Type: Motherboard > Contained Object Handles: 0 Without the need to install an additional port: datatomb2# kenv =85 smbios.bios.reldate=3D"11/03/2011" smbios.bios.vendor=3D"FUJITSU // American Megatrends Inc." smbios.bios.version=3D"V4.6.4.1 R1.18.0 for D3034-A1x" smbios.chassis.maker=3D"FUJITSU" smbios.chassis.serial=3D"YLAP004857" smbios.chassis.tag=3D"System Asset Tag " smbios.chassis.version=3D"RX100S7R2" smbios.memory.enabled=3D"8388608" smbios.planar.maker=3D"FUJITSU" smbios.planar.product=3D"D3034-A1" smbios.planar.serial=3D"LJ1B-P00996" smbios.planar.version=3D"S26361-D3034-A100 WGS01 GS02" smbios.socket.enabled=3D"1" smbios.socket.populated=3D"1" smbios.system.maker=3D"FUJITSU" smbios.system.product=3D"PRIMERGY RX100 S7" smbios.system.serial=3D"YLAP004857" smbios.system.uuid=3D"f0493081-f5ca-e011-b8a5-a1c4d143da5f" smbios.system.version=3D"GS02" smbios.version=3D"2.7" =85 Kind regards, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 12:06:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8CE9106564A for ; Thu, 15 Dec 2011 12:06:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id B78208FC0C for ; Thu, 15 Dec 2011 12:06:07 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 9Pou1i0061vN32cA3Psp4m; Thu, 15 Dec 2011 11:52:49 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id 9Q9m1i0071t3BNj8iQ9mXM; Thu, 15 Dec 2011 12:09:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 95117102C19; Thu, 15 Dec 2011 03:52:54 -0800 (PST) Date: Thu, 15 Dec 2011 03:52:54 -0800 From: Jeremy Chadwick To: Michael Larabel Message-ID: <20111215115254.GA21530@icarus.home.lan> References: <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> <4EE9D214.3070906@phoronix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE9D214.3070906@phoronix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 18 Dec 2011 22:00:02 +0000 Cc: "O. Hartmann" , Michael Ross , freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 12:06:07 -0000 On Thu, Dec 15, 2011 at 04:55:16AM -0600, Michael Larabel wrote: > On 12/15/2011 04:41 AM, Michael Ross wrote: > >Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel > >: > > > >>On 12/15/2011 02:48 AM, Michael Ross wrote: > > > >>>Anyway these tests were performed on different hardware, FWIW. > >>>And with different filesystems, different compilers, different GUIs... > >>> > >>> > >> > >>No, the same hardware was used for each OS. > >> > > > >The picture under the heading "System Hardware / Software" does > >not reflect that. > > > >Motherboard description differs, Chipset description for FreeBSD > >is empty. > > > > I was the on that carried out the testing and know that it was on > the same system. > > All of the testing, including the system tables, is fully automated. > Under FreeBSD sometimes the parsing of some component strings isn't > as nice as Linux and other supported operating systems by the > Phoronix Test Suite. For the BSD motherboard string parsing it's > grabbing hw.vendor/hw.product from sysctl. > > Is there a better place to read the motherboard DMI information from? I *think* what you're referring to is SMBIOS strings -- and these are available from kenv(1) / kenv(2), not sysctl. But keep reading for why SMBIOS data is not 100% reliable (greatly depends on the hardware). For actual device strings/etc. for all devices on busses (PCI, AGP, etc.) you can use pciconf -lvcb. That's about as good as it's going to get via software. SMBIOS data (e.g. smbios.{bios,chassis,planar,system}) is never going to give you fully-identifiable data; I can point you to tons of systems where the data inserted there is nonsense, sometimes even just ASCII spaces (and that is the fault of the system vendor/BIOS manufacturer, not FreeBSD). Sometimes identical strings are used across completely different systems/boards (sometimes even server-class boards like ones from Supermicro). And PCI vendor strings don't give you things like speeds, frequency/voltages, etc.. Sometimes this matters. For example (just making something up): "the video benchmark was horrible on FreeBSD", when in fact it turned out that a run of "pciconf -lvcb" showed your PCIe card was running at x4 link speed instead of x16. The best place to get your specifications from are: * The box * The physical hardware (by physically inspecting it) * The user manual / product documentation/ * Purchase orders from whoever bought the hardware * And, of course, operational speed (if possible) from the OS/userland utilities When I read a benchmark/review, I have to assume the person is doing them on a system they have 100% control over, all the way down to the hardware. Thus, they should know what exact hardware they have. Also, when publishing results online, you should take the time to proofread everything (with a 2nd set of eyes if possible) and be patient and thorough. People like accuracy, especially when there's hard data/evidence to back it up that can be made available for download. Try to understand: so many review-esque sites consist of individuals who do not understand even remotely what they're doing. I'm going to give you two examples -- one personal, one word-of-mouth but from someone I trust dearly. I have a "reverse analysis" of Anantech's Intel 510 SSD review that has been sitting in my "draft" folder on my blog for a month now because I'm downright afraid to publish how their data seems completely and totally wrong (with evidence to prove it). I'm afraid/stalling because I want to make absolutely damn sure I'm not missing some key piece of evidence that explains it, and I've had multiple people read it and go "...wow, I didn't notice that, that benchmark data makes no sense", but I'm STILL reluctant. The last thing I want to do is "publish" something that sparks a controversy where it turns out I'm wrong (and I AM wrong, quite often!). As for the other: http://www.overclockers.com/bulldozer-architecture-explained/ The author of this "review" talks about CPU arch and is praised for writing a "wonderful article that speaks the truth". But sadly that doesn't appear to be the case. A colleague of mine is long-time friends with another individual who is getting his Ph.D in computer architecture and recently submit a paper to a journal (and was published/accepted) which has published papers on things like RAID (when it was first introduced as a concept/method), and hardware watchpoints. Said individual read the above "review" and described it as, quote, "the worst article on computer architecture on the entire Internet". One of the amusing quotes (that got me laughing since I did understand it; my understanding of CPUs on a silicon level is limited, I'm just an old 65xxx assembly programmer...) was how the article states "this is the first time AMD has implemented branch prediction". Sigh. Here's the kicker: said individual immediately recognised that the article was a near dry cut-and-paste from one of two commonly-used computer architecture books in college/universities; the first book is basically a "beginner's guide to CPU architecture". The book is also a bit old at that. Individual proceeded to look up where the article author went to school, and noted that said school's CPU architecture course **ends** with that book. The user/viewer demographic of overclockers.com is going to be significantly different from that of phoronix.com -- you know that I'm sure. The point is that you should be aware that there is going to be significant discussions that come from publishing such benchmark comparisons with such a demographic. Things that indicate severe performance differential (e.g. "10x to 100x worse") are going to be focused on and criticised -- and hopefully in a socially-agreeable manner[1] -- and in a much different way than, say, a 3D video card review site ("lol ur pc sux if u spend onl $4000 on it lol"). The first step is to try and figure out what exactly you're seeing and why it's so significantly different when compared to other OSes. [1]: I'm sure by now you know that the BSDs in general tend to harbour a community of folks who are more argumentative/aggressive than, say, Linux (generally speaking). In this thread though, I think all of us really want to assist in some way to figure out what exactly is going on here, scheduler-wise, and see if we can put something together to hand developers who are "responsible" for said code and see what comes of it. Remember, we're all here to try and make things better... I hope. :-) Footnote: It's nice meeting you (indirectly), I was always curious who did the phoronix.com reviews/"stuff" when it came to FreeBSD. Greetings! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 12:56:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04486106564A; Thu, 15 Dec 2011 12:56:03 +0000 (UTC) (envelope-from sjg@evilcode.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0658FC12; Thu, 15 Dec 2011 12:56:02 +0000 (UTC) Received: by iakl21 with SMTP id l21so5157427iak.13 for ; Thu, 15 Dec 2011 04:56:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.161.10 with SMTP id r10mr2375060icx.22.1323952367276; Thu, 15 Dec 2011 04:32:47 -0800 (PST) Received: by 10.50.163.106 with HTTP; Thu, 15 Dec 2011 04:32:47 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> Date: Thu, 15 Dec 2011 05:32:47 -0700 Message-ID: From: "Samuel J. Greear" To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 18 Dec 2011 22:00:16 +0000 Cc: FreeBSD Stable Mailing List , freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 12:56:03 -0000 > Well, the only way it's going to get fixed is if someone sits down, > replicates it, and starts to document exactly what it is that these > benchmarks are/aren't doing. > I think you will find that investigation is largely a waste of time, because not only are some of these benchmarks just downright silly, there are huge differences in the environments (compiler versions), etc., etc. leading to a largely apples/oranges comparison. But also the the analysis and reporting of the results by Phoronix is simply moronic to the point of being worse than useful, they are spreading misinformation. Take the first test as an example, Blogbench read. This doesn't raise any red flags, right? At least not until you realize that Blogbench isn't a read test, it's a read/write test. So what they have done here is run a read/write test and then thrown away the write results for both platforms and reported only the read results. If you dig down into the actual results, http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will see two Blogbench numbers, one for read and another for write. These were both taken from the same Blogbench run, so FreeBSD optimizes writes over reads, that's probably a good thing for your data but a bad thing when someone totally misrepresents benchmark results. Other benchmarks in the Phoronix suite and their representations are similarly flawed, _ALL_ of these results should be ignored and no time should be wasted by any FreeBSD committer further evaluating this garbage. (Yes, I have been down this rabbit hole). Best, Sam From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 13:36:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34DC31065670; Thu, 15 Dec 2011 13:36:23 +0000 (UTC) (envelope-from michael.larabel@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id C962E8FC0C; Thu, 15 Dec 2011 13:36:22 +0000 (UTC) Received: from c-98-193-96-120.hsd1.il.comcast.net ([98.193.96.120] helo=[172.16.93.133]) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RbBTx-0005eR-HR; Thu, 15 Dec 2011 07:36:21 -0600 Message-ID: <4EE9F7D2.4050607@phoronix.com> Date: Thu, 15 Dec 2011 07:36:18 -0600 From: Michael Larabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Stefan Esser References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> <4EE9F546.6060503@freebsd.org> In-Reply-To: <4EE9F546.6060503@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Sun, 18 Dec 2011 22:00:29 +0000 Cc: FreeBSD Stable Mailing List , Current FreeBSD , Michael Ross , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 13:36:23 -0000 On 12/15/2011 07:25 AM, Stefan Esser wrote: > Am 15.12.2011 11:10, schrieb Michael Larabel: >> No, the same hardware was used for each OS. >> >> In terms of the software, the stock software stack for each OS was used. > Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with > journaling enabled) should be an obvious choice since it is more similar > in concept to ext4 and since that is what most FreeBSD users will use > with FreeBSD? I was running some ZFS vs. UFS tests as well and this happened to have ZFS on when I was running some other tests. > > Did you tune the ZFS ARC (e.g. vfs.zfs.arc_max="6G") for the tests? The OS was left in its stock configuration. > > And BTW: Did your measured run times account for the effect, that Linux > keeps much more dirty data in the buffer cache (FreeBSD has a low limit > on dirty buffers since under realistic load the already cached data is > much more likely to be reused and thus more valuable than freshly > written data; aggressively caching dirty data would significantly reduce > throughput and responsiveness under high load). Given the hardware specs > of the test system, I guess that Linux accepts at least 100 times the > dirty data in the buffer cache, compared to FreeBSD (where this number > is at most in the tens of megabyte range). > > If you did not, then your results do not represent a server load (which > I'd expect relevant, if you are testing against Oracle Linux 6.1 > server), where continuous performance is required. Tests that run on an > idle system starting in a clean state and ignoring background flushing > of the buffer cache after the timed program has stopped are perhaps > useful for a very lowly loaded PC, but not for a system with high load > average as the default. > > I bet that if you compared the systems under higher load (which > admittedly makes it much harder to get sensible numbers for the program > under test) or with reduced buffer cache size (or raise the dirty buffer > limit in FreeBSD accordingly, which ought to be possible with sysctl > and/or boot time tuneables, e.g. "vfs.hidirtybuffers"). > > And a last remark: Single benchmark runs do not provide reliable data. > FreeBSD comes with "ministat" to check the significance of benchmark > results. Each test should be repeated at least 5 times for meaningful > averages with acceptable confidence level. The Phoronix Test Suite runs most tests a minimum of three times and if the standard deviation exceeds 3.5% the run count is dynamically increased, among other safeguards. -- Michael > > Regards, STefan > From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 13:48:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC03106564A for ; Thu, 15 Dec 2011 13:48:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id B527C8FC17 for ; Thu, 15 Dec 2011 13:48:56 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 9RXc1i00627AodY5BRoxSR; Thu, 15 Dec 2011 13:48:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id 9Rov1i00Y1t3BNj3fRov2n; Thu, 15 Dec 2011 13:48:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F0D36102C19; Thu, 15 Dec 2011 05:48:53 -0800 (PST) Date: Thu, 15 Dec 2011 05:48:53 -0800 From: Jeremy Chadwick To: "Samuel J. Greear" Message-ID: <20111215134853.GA24753@icarus.home.lan> References: <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 18 Dec 2011 22:00:42 +0000 Cc: "O. Hartmann" , Adrian Chadd , Current FreeBSD , FreeBSD Stable Mailing List , freebsd-performance@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 13:48:57 -0000 On Thu, Dec 15, 2011 at 05:32:47AM -0700, Samuel J. Greear wrote: > > Well, the only way it's going to get fixed is if someone sits down, > > replicates it, and starts to document exactly what it is that these > > benchmarks are/aren't doing. > > > > I think you will find that investigation is largely a waste of time, > because not only are some of these benchmarks just downright silly, > there are huge differences in the environments (compiler versions), > etc., etc. leading to a largely apples/oranges comparison. But also > the the analysis and reporting of the results by Phoronix is simply > moronic to the point of being worse than useful, they are spreading > misinformation. > > Take the first test as an example, Blogbench read. This doesn't raise > any red flags, right? At least not until you realize that Blogbench > isn't a read test, it's a read/write test. So what they have done here > is run a read/write test and then thrown away the write results for > both platforms and reported only the read results. If you dig down > into the actual results, > http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will > see two Blogbench numbers, one for read and another for write. These > were both taken from the same Blogbench run, so FreeBSD optimizes > writes over reads, that's probably a good thing for your data but a > bad thing when someone totally misrepresents benchmark results. > > Other benchmarks in the Phoronix suite and their representations are > similarly flawed, _ALL_ of these results should be ignored and no time > should be wasted by any FreeBSD committer further evaluating this > garbage. (Yes, I have been down this rabbit hole). For sake of argument, let's say we throw out the Phoronix benchmarks as a data source (I don't think the benchmark specifically implied or stated "this is all because of SCHED_ULE" though; remember, that's what we're supposed to be focusing on. There may not be a direct correlation between the Phoronix benchmarks and the ULE issue reported here...). That said: thrown out, data ignored, done. Now what? Where are we? We're right back where we were a day or two ago; meaning no closer to solving the dilemma reported by users and SCHED_ULE. Heck, we're not even sure if there is an issue, other than some folks confirming that SCHED_4BSD performs better for them (that's what started this whole thread), and there are at least a couple which have stated this. So given the above semi-devil's-advocate response -- Sam, do you have something positive or progressive to offer so we can move forward on the ULE vs. 4BSD debacle? :-) The smiley is meant to be sincere, not sarcastic. I'm getting to the point where I'm considering formulating a private mail to Jeff Roberson, requesting that he be aware of the discussion that's happening (not that he necessarily follow or read it), and that based on what I can tell we're at a roadblock -- nobody so far is absolutely certain how to "benchmark" and compare ULE vs. 4BSD in multiple ways, so that those of us involved here can run such utilities and provide the data somewhere central for devs to review. I only mention this because so far I haven't seen anyone really say "okay, this is what we should be using for these kinds of tests". Yay nature of the beast. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 14:28:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D4B106564A; Thu, 15 Dec 2011 14:28:26 +0000 (UTC) (envelope-from michael.larabel@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBED8FC13; Thu, 15 Dec 2011 14:28:26 +0000 (UTC) Received: from c-98-193-96-120.hsd1.il.comcast.net ([98.193.96.120] helo=[172.16.93.133]) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RbCIL-00079g-BN; Thu, 15 Dec 2011 08:28:25 -0600 Message-ID: <4EEA0406.2010002@phoronix.com> Date: Thu, 15 Dec 2011 08:28:22 -0600 From: Michael Larabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Sergey Matveychuk References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EE9C79B.7080607@phoronix.com> <4EE9F546.6060503@freebsd.org> <4EE9F7D2.4050607@phoronix.com> <4EEA0388.7010605@FreeBSD.org> In-Reply-To: <4EEA0388.7010605@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Sun, 18 Dec 2011 22:00:54 +0000 Cc: FreeBSD Stable Mailing List , Current FreeBSD , Michael Ross , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 14:28:26 -0000 On 12/15/2011 08:26 AM, Sergey Matveychuk wrote: > 15.12.2011 17:36, Michael Larabel пишет: >> On 12/15/2011 07:25 AM, Stefan Esser wrote: >>> Am 15.12.2011 11:10, schrieb Michael Larabel: >>>> No, the same hardware was used for each OS. >>>> >>>> In terms of the software, the stock software stack for each OS was >>>> used. >>> Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with >>> journaling enabled) should be an obvious choice since it is more >>> similar >>> in concept to ext4 and since that is what most FreeBSD users will use >>> with FreeBSD? >> >> I was running some ZFS vs. UFS tests as well and this happened to have >> ZFS on when I was running some other tests. >> > > Can we look at the tests? > My opinion is ZFS without tuning is much slower than UFS2. > http://www.phoronix.com/scan.php?page=news_item&px=MTAyNjg From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 16:54:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9D681065676 for ; Thu, 15 Dec 2011 16:54:46 +0000 (UTC) (envelope-from schulra@earlham.edu) Received: from chkenon.earlham.edu (chkenon.earlham.edu [159.28.1.87]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2818FC25 for ; Thu, 15 Dec 2011 16:54:42 +0000 (UTC) X-ASG-Debug-ID: 1323967030-037b9f16aa150e90001-XDYc8F Received: from tdream.lly.earlham.edu (tdream.lly.earlham.edu [159.28.7.241]) by chkenon.earlham.edu with ESMTP id C4amwHprtB3nCyz5; Thu, 15 Dec 2011 11:37:10 -0500 (EST) X-Barracuda-Envelope-From: schulra@earlham.edu X-Barracuda-Apparent-Source-IP: 159.28.7.241 Date: Thu, 15 Dec 2011 11:38:20 -0500 (EST) From: Randy Schultz X-X-Sender: schulra@tdream.lly.earlham.edu To: Pieter de Goeje In-Reply-To: <4EEA16D1.2010900@degoeje.nl> X-ASG-Orig-Subj: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server Message-ID: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EEA16D1.2010900@degoeje.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: tdream.lly.earlham.edu[159.28.7.241] X-Barracuda-Start-Time: 1323967030 X-Barracuda-URL: http://159.28.1.87:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at earlham.edu X-Barracuda-Spam-Score: 0.89 X-Barracuda-Spam-Status: No, SCORE=0.89 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 tests=BSF_SC5_SA210e, SARE_ADLTSUB4 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.83162 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.89 SARE_ADLTSUB4 Apparent spam seems to contain porn subject 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Mailman-Approved-At: Sun, 18 Dec 2011 22:01:07 +0000 Cc: freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 16:54:46 -0000 On Thu, 15 Dec 2011, Pieter de Goeje spaketh thusly: -}Detailed results here: -}http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 LOL! Pretty much 2 entirely different systems, even running different screen resolutions. Tnx for this link. -} -}As usual, the phoronix benchmarks are very misleading. Also, they tested fbsd RC2. This same thing has come up repeatedly. Seems to me "big waves" happened when fbsd 8.0 was coming out and phoronix tested RC1 or RC2. Unless my memory is in error (and it may well be), on the 8.0 "comparison" fiasco, it was pointed out that testing a fbsd RC release is like racing but being preventing from going full throttle. There are debugging hooks and various extra code bits that slow things down and are not taken out until the stable release. They *can* be taken out by the end-SA, but phoronix stated they used a stock kernel. That phoronix did this again makes me wonder... I have to agree with and cannot stress enough the importance of testing in the environment it is to be run in, with the software that is to be run on it. I used to be a massive linux fan, right up until the day I put freebsd up against several *nix boxen (IIRC Redhat, Debian, SuSE and IRIX) in a particular application I was re-working. I had to run the test several times, the difference was so great. Fbsd didn't just beat the others, it rolled 'em, smoked 'em and tapped them in the ashtray. But this was with _our_ hardware configurations and _our_ software configurations and tweaks. Currently we have a mixture of linux and fbsd in production and test. Some of the things we do run better on linux, some run better on fbsd. And if they're close, I'll pick fbsd mostly for personal reasons, e.g. it just makes more sense to me, some things I like to do are more easily done in fbsd, ... FWIW, YMMV, yadda yadda. ;> -- Randy (schulra@earlham.edu) 765.983.1283 <*> nosce te ipsum From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 17:49:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51DB21065672 for ; Thu, 15 Dec 2011 17:49:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id AF99A8FC15 for ; Thu, 15 Dec 2011 17:48:59 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 9Rwj1i0031ap0As5BVozfB; Thu, 15 Dec 2011 17:48:59 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id 9Voy1i01K1t3BNj3iVoydW; Thu, 15 Dec 2011 17:48:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2B4DD102C19; Thu, 15 Dec 2011 09:48:57 -0800 (PST) Date: Thu, 15 Dec 2011 09:48:57 -0800 From: Jeremy Chadwick To: Attilio Rao Message-ID: <20111215174857.GA28551@icarus.home.lan> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <20111213073615.GA69641@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 18 Dec 2011 22:01:24 +0000 Cc: "O. Hartmann" , Current FreeBSD , freebsd-stable@freebsd.org, freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 17:49:00 -0000 On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote: > 2011/12/13 Jeremy Chadwick : > > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote: > >> > Not fully right, boinc defaults to run on idprio 31 so this isn't an > >> > issue. And yes, there are cases where SCHED_ULE shows much better > >> > performance then SCHED_4BSD. ??[...] > >> > >> Do we have any proof at hand for such cases where SCHED_ULE performs > >> much better than SCHED_4BSD? Whenever the subject comes up, it is > >> mentioned, that SCHED_ULE has better performance on boxes with a ncpu > > >> 2. But in the end I see here contradictionary statements. People > >> complain about poor performance (especially in scientific environments), > >> and other give contra not being the case. > >> > >> Within our department, we developed a highly scalable code for planetary > >> science purposes on imagery. It utilizes present GPUs via OpenCL if > >> present. Otherwise it grabs as many cores as it can. > >> By the end of this year I'll get a new desktop box based on Intels new > >> Sandy Bridge-E architecture with plenty of memory. If the colleague who > >> developed the code is willing performing some benchmarks on the same > >> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most > >> recent Suse. For FreeBSD I intent also to look for performance with both > >> different schedulers available. > > > > This is in no way shape or form the same kind of benchmark as what > > you're planning to do, but I thought I'd throw it out there for folks to > > take in as they see fit. > > > > I know folks were focused mainly on buildworld. > > > > I personally would find it interesting if someone with a higher-end > > system (e.g. 2 physical CPUs, with 6 or 8 cores per CPU) was to do the > > same test (changing -jX to -j{numofcores} of course). > > > > -- > > | Jeremy Chadwick ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??jdc at parodius.com | > > | Parodius Networking ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? http://www.parodius.com/ | > > | UNIX Systems Administrator ?? ?? ?? ?? ?? ?? ?? ?? ?? Mountain View, CA, US | > > | Making life hard for others since 1977. ?? ?? ?? ?? ?? ?? ?? PGP 4BD6C0CB | > > > > > > sched_ule > > =========== > > - time make -j2 buildworld > > ??1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io 4565pf+0w > > - time make -j2 buildkernel > > ??640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w > > > > > > sched_4bsd > > ============ > > - time make -j2 buildworld > > ??1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io 6451pf+0w > > - time make -j2 buildkernel > > ??638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w > > > > > > software > > ========== > > * sched_ule test: ??FreeBSD 8.2-STABLE, Thu Dec ??1 04:37:29 PST 2011 > > * sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST 2011 > > Hi Jeremy, > thanks for the time you spent on this. > > However, I wanted to ask/let you note 3 things: > 1) Did you use 2 different code base for the test? (one updated on > December 1 and another one on December 12) No; src-all (/usr/src on this system) was not updated between December 1st and December 12th PST. I do believe I updated it today (15th PST). I can/will obviously hold off so that we have a consistent code base for comparing numbers between schedulers during buildworld and/or buildkernel. > 2) Please note that you should have repeated this test several times > (basically until you don't get a standard deviation which is > acceptable with ministat) and report the ministat output This is the first time I have heard of ministat(1). I'm pretty sure I see what it's for and how it applies to this situation, but boy that man page could use some clarification (I have 3 people looking at this thing right now trying to figure out what means what in the graph :-) ). Anyway, graph or not, I see the point. Regarding multiple tests: yup, you're absolutely right, the only way to do it would be to run a sequence of tests repeatedly (probably 10 per scheduler). Reboots and rm -fr /usr/obj/* would be required after each test too, to guarantee empty kernel caches (of all types) consistently every time. What I posted was supposed to give people just a "general idea" if there was any gigantic difference between the two, and there really isn't. But, as others have stated (and you below), buildworld may not be an effective way to "benchmark" what we're trying to test. Hence me wondering exactly what would make for a good test. Example: 1. Run + background some program that "beats on things" (I really don't know what; creation/deletion of threads? CPU benchmark? bonnie++?), with output going to /dev/null. 2. Run + background "time make -j2 buildworld" with output going to /dev/null 3. Record/save output from "time". 4. rm -fr /usr/obj && shutdown -r now 5. Repeat all steps ~10 times 6. Adjust kernel configuration file to use other scheduler 7. Repeat steps 1-5. What I'm trying to figure out is what #1 and #2 should be in the above example. > 3) The difference is less than 2% which I suspect is really > statistically unuseful/the same Understood. > I'm not really even surprised ULE is not faster than 4BSD in this case > because usually buildworld/buildkernel tests are driven for the vast > majority by I/O overhead rather than scheduler capacity. It would be > more interesting to analyze how buildworld does while another type of > workload is going on. Yup, agreed/understood, hence me trying to find out what would classify as a good stress test for all of this. I have a testbed system in my garage which I could set up to literally do all of this in a loop, meaning automate the entire above process and just let it go, writing stderr from time to a file (which wouldn't skew the results at all). Let me know what #1 and #2 above, re: "the workloads", should be and I'll be happy to set it up. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 18:02:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5C1106566B; Fri, 16 Dec 2011 18:02:10 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id A75978FC13; Fri, 16 Dec 2011 18:02:10 +0000 (UTC) Received: from mobile-166-205-138-224.mycingular.net ([166.205.138.224] helo=www.palm.com) by phx1.phoronix.com with esmtpa (Exim 4.69) (envelope-from ) id 1RbbOg-0006dP-AI; Fri, 16 Dec 2011 11:16:39 -0600 Date: Fri, 16 Dec 2011 09:16:36 -0800 From: To: "Adrian Chadd" , "Stefan Esser" In-Reply-To: X-Mailer: Palm webOS X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com Message-Id: <20111216180210.DA5C1106566B@hub.freebsd.org> X-Mailman-Approved-At: Sun, 18 Dec 2011 22:02:27 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Joe Holden , FreeBSD Stable Mailing List , Michael Larabel , Current FreeBSD , Arnaud Lacombe , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:02:10 -0000 Thanks. My request for the person documenting the tunings also runs = the benchmark to ensure expected behaviour. The installation, execut= ion and comparison against the benchmarks in the article is fairly simple.<= br> Note that some tuning may not be relevant or recommended (ie: some o= f the fs benchmarks are sensitive to barriers and other synchronous operati= ons). I'd recommend bowing out of a benchmark with a 'we're going to = be slower since the default configuration is this way for the following rea= son' if this is the case. Thanks 'someone'. Matthew Dec 16, 2011 8:46 AM,= Adrian Chadd wrote: Can someone please write up a nice, concise blog post somewhere=0D= outlining all of this?=0D =0D Extra bonus points if it's a blog t= hat is picked up by=0D blogs.freebsdish.org and/or some of the other BSD= sites.=0D =0D Guys/girls/fuzzy things - this is 2011; people look at= shiny blog=0D sites with graphs rather than mailing lists. Sorry, we lo= st that=0D battle. :)=0D =0D =0D =0D Adrian=0D __________= _____________________________________=0D freebsd-performance@freebsd.org= mailing list=0D http://lists.freebsd.org/mailman/listinfo/freebsd-perfo= rmance=0D To unsubscribe, send any mail to "freebsd-performance-unsubscr= ibe@freebsd.org"=0D From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 07:26:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF20106566B; Sun, 18 Dec 2011 07:26:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 57CB88FC0C; Sun, 18 Dec 2011 07:26:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id pBI6plub093109; Sun, 18 Dec 2011 17:51:47 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 18 Dec 2011 17:51:47 +1100 (EST) From: Ian Smith To: Bruce Cran In-Reply-To: <4EED5200.20302@cran.org.uk> Message-ID: <20111218164924.L64681@sola.nimnet.asn.au> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 18 Dec 2011 22:02:40 +0000 Cc: Ivan Klymenko , Doug Barton , freebsd-stable@freebsd.org, "O. Hartmann" , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 07:26:44 -0000 On Sun, 18 Dec 2011 02:37:52 +0000, Bruce Cran wrote: > On 13/12/2011 09:00, Andrey Chernov wrote: > > I observe ULE interactivity slowness even on single core machine (Pentium > > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 > > second. When I switch back to SHED_4BSD, all slowness is gone. > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > buildworld" then logging into another console can take several seconds. > Sometimes even the "Password:" prompt can take a couple of seconds to appear > after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. t23# cat /root/bin/t23stat #!/bin/sh echo -n "`date` " sysctl dev.cpu.0.freq dev.cpu.0.cx_usage sysctl dev.acpi_ibm | egrep 'fan_|thermal' sysctl hw.acpi.thermal.tz0.temperature acpiconf -i0 | egrep 'State|Remain|Present|Volt' Sure it's a slow machine, but it normally runs pretty smoothly. Anything with a bit of disk i/o, like buildworld, runs smooth as. This is on 8.2-R GENERIC, HZ=1000, 768MB with lots free, no swap in use. I'll definitely be trying SCHED_4BSD after updating to 8-stable unless a 'miracle cure' appears beforehand. cheers, Ian From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 10:34:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 652C6106564A; Sun, 18 Dec 2011 10:34:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEF08FC13; Sun, 18 Dec 2011 10:34:40 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5897013vcb.13 for ; Sun, 18 Dec 2011 02:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s6kIoTrilkDgvCqa7CBeAusmCWmQmTPCl4RVMTG7W7o=; b=odf2/KQtLGeZG11305gEP1KiG7+ubW+oPsc0+7Eh8JLQguv73H4Ua8edlUNJ1tn3Ls hdqo8DlYC7pwZkaRQP3wBMZf+fswsbnnmZ0+DEwryKtpV3YdRC0aQLf6dR9SSXKf4uFk cVdOKApp/s6YE6A3yN8lV+o80IFCotsTmKyKA= MIME-Version: 1.0 Received: by 10.220.151.204 with SMTP id d12mr7411703vcw.40.1324204479840; Sun, 18 Dec 2011 02:34:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 02:34:39 -0800 (PST) In-Reply-To: <20111218102600.GA44118@freebsd.org> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> Date: Sun, 18 Dec 2011 02:34:39 -0800 X-Google-Sender-Auth: uHpK_GNrw2hgPHGTKxPMp-CpkzM Message-ID: From: Adrian Chadd To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 18 Dec 2011 22:02:50 +0000 Cc: Bruce Cran , Ivan Klymenko , Doug Barton , Ian Smith , "O. Hartmann" , Current FreeBSD , freebsd-stable@freebsd.org, freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:34:41 -0000 The trouble is that there's lots of anecdotal evidence, but noone's really gone digging deep into _their_ example of why it's broken. The developers who know this stuff don't see anything wrong. That hints to me it may be something a little more creepy - as an example, the interplay between netisr/swi/taskqueue/callbacks and such. It may be that something is being starved that isn't obviously obvious. It's just a stab in the dark, but it sounds somewhat plausible based on what I've seen ULE do in my network throughput hacking. I applaud reppie for trying to make it as easy as possible for people to use KTR to provide scheduler traces for him to go digging with, so please, if you have these issues and you can absolutely reproduce them, please follow his instructions and work with him to get him what he needs. Adrian (wow, lots of personal pronouns packed into one sentence. It must be sleep time.) From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 22:27:27 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E601C106567B for ; Sun, 18 Dec 2011 22:27:27 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A7E8F8FC15 for ; Sun, 18 Dec 2011 22:27:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0E06360AC; Sun, 18 Dec 2011 22:27:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 635BA89F0; Sun, 18 Dec 2011 23:27:22 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Butler References: <4EEE4996.3060308@protected-networks.net> Date: Sun, 18 Dec 2011 23:27:22 +0100 In-Reply-To: <4EEE4996.3060308@protected-networks.net> (Michael Butler's message of "Sun, 18 Dec 2011 15:14:14 -0500") Message-ID: <86obv51po5.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org Subject: Re: openpam oddity? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 22:27:28 -0000 Michael Butler writes: > Any ideas why courier-authdaemon is now reporting .. > > authdaemond: in openpam_dynamic(): No error: 0 > authdaemond: in openpam_load_module(): no pam_unix.so found > > I've recompiled libpam and courier from scratch :-( Can you ktrace courier-authdaemon? # env LD_UTRACE /usr/local/etc/rc.d/courier-authdaemond restart # ktrace -di -tcntu -p $(cat /var/run/authdaemond/pid) then reproduce the error, then # /usr/local/etc/rc.d/courier-authdaemond restart to stop the trace, and # kdump >courier-authdaemond-trace.txt to translate it to human-readable form. The trace will *not* include any passwords, just a list of system calls, filename lookups and linker operations. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 22:57:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A475106564A; Sun, 18 Dec 2011 22:57:56 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id BF0298FC0A; Sun, 18 Dec 2011 22:57:55 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A4B0925D3811; Sun, 18 Dec 2011 22:57:54 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8F5D6BD74A8; Sun, 18 Dec 2011 22:57:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id TPWQGyj9kasD; Sun, 18 Dec 2011 22:57:52 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4BAD6BD74A7; Sun, 18 Dec 2011 22:57:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: "Bjoern A. Zeeb" In-Reply-To: <86sjkh21op.fsf@ds4.des.no> Date: Sun, 18 Dec 2011 22:57:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201112181630.pBIGUbcf041259@freebsd-current.sentex.ca> <86sjkh21op.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1084) Cc: sparc64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 22:57:56 -0000 On 18. Dec 2011, at 18:07 , Dag-Erling Sm=F8rgrav wrote: > FreeBSD Tinderbox writes: >> In file included from /src/sys/dev/e1000/if_em.c:400: >> /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': >> /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void = *' pointer >> /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member = 'dt_mt' in something not a structure or union >> *** Error code 1 >=20 > I made a mistake when I added support for additional LINT kernels > (e.g. LINT-NOINET) so the additional kernels got built, but plain LINT > didn't. As a result, this error has gone unnoticed by the tinderbox, > even though it's been there for quite a while (or so I've been told). Thanks a lot for fixing the tinderbox (I remember I had seen the = original expression and had missed that LINT case). On the error: I have seen it for at least 4 days but hadn't removed my obj tree entirely. I also followed up to one of the later commits with jfv and luigi discussing the last driver update, so hope they'll fix it = soon. Thanks a lot again for promptly fixing the script and compiling LINT = again as well! /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 08:27:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91256106566C; Mon, 19 Dec 2011 08:27:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 251198FC13; Mon, 19 Dec 2011 08:27:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2831:a229:70d2:ba0b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 099D14AC1C; Mon, 19 Dec 2011 12:27:22 +0400 (MSK) Date: Mon, 19 Dec 2011 12:27:21 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <6140271.20111219122721@serebryakov.spb.ru> To: "Samuel J. Greear" In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , FreeBSD Stable Mailing List , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 08:27:25 -0000 Hello, Samuel. You wrote 15 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 16:32:47: > Other benchmarks in the Phoronix suite and their representations are > similarly flawed, _ALL_ of these results should be ignored and no time > should be wasted by any FreeBSD committer further evaluating this > garbage. (Yes, I have been down this rabbit hole). Here is one problem: we have choice from three items: (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix (communication with them, convincing, that they benchamrks are unfare / meaningless, ets) (3) Lose [potential] userbase. You know, that these benchmarks are bad. I know. But potential (and even some current!) user doesn't. And it seems, that these benchmarks become popular over Internet. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 08:30:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1A81065689 for ; Mon, 19 Dec 2011 08:30:06 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE668FC0C for ; Mon, 19 Dec 2011 08:30:06 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2436877obb.13 for ; Mon, 19 Dec 2011 00:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=khu2//8jt0p373dsHCTHc/reVUNAXjdgwX51D3Vy1wY=; b=mnAaEa+nl1UTT9RVERK63w0aiMR+ySuPGG+sCferJJdweGXzfC+FbqKVsHWNMGP/qe A0Cro8iMfRw3x5/o1Ue6NpSoQdQiJu2hWbewJDBLt85gNWJAJ5KPb62lgYCxs9Afu9ea ygJhu+lyRZvIsqvN9Zub1hY5HQz02oXN7C2k8= MIME-Version: 1.0 Received: by 10.182.5.198 with SMTP id u6mr9594377obu.14.1324283405831; Mon, 19 Dec 2011 00:30:05 -0800 (PST) Received: by 10.182.150.70 with HTTP; Mon, 19 Dec 2011 00:30:05 -0800 (PST) In-Reply-To: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Mon, 19 Dec 2011 10:30:05 +0200 Message-ID: From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 08:30:06 -0000 If anyone interested, I got here [1] VirtualBox Image: FreeBSD-10-amd64-r228694-2011-12-19.vdi.xz Anyone who's looking to test 10 can get to test it :) It contains package-installed partial system with openbox; Image configured to run DHCP on em0, you can change this in /etc/rc.conf, as usually. When you'll get internet working, you can add packages (9 ones), running /root/addpackage.sh $1 To get X, login as root, start /root/runx.sh In a few seconds (there's delays for safety) you should get X with openbox. BTW, it contains also qt 4.8.0 and qtcreator 2.4.0, you can test something and help a bit for KDE/QT team with any feedbacks. It's installed with default settings in their default prefixes (qt in /usr/local/Trolltech, and qtcreator in / ), so, to run something you probably must set correct LD_PATH. As for qtcreator, I created script for launch it, placed in root, which is also launched when you start X. 1. http://gits.kiev.ua/FreeBSD/ P.S. As always, I'm looking for anyone who will lend me a hand in enhancing build scripts. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 09:13:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B13106567B for ; Mon, 19 Dec 2011 09:13:18 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA718FC15 for ; Mon, 19 Dec 2011 09:13:18 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id pBJ9DApi074173 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 09:13:10 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.1 smtp.infracaninophile.co.uk pBJ9DApi074173 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1324285990; bh=dbEH/cCltO1EZf2rU6eEaxhDyajO98nXIeW6uQlzqeQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=jLQhT4rhGfWV8VgHyAarvb5prt2fL6hLoLEoXPieOfR/fXusX3CGCdtLBdj1rFtgJ 0/oUIag25IZ8EiMTFnNOXTFciHXaKd3OibQ6kWUgKW9YIiUI0IangSHqsRRUWc2cID k34WX06t09z121C0+Sq8cRoCDAu1IaFjmKH8Enxo= Message-ID: <4EEF0025.6040205@infracaninophile.co.uk> Date: Mon, 19 Dec 2011 09:13:09 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> In-Reply-To: <6140271.20111219122721@serebryakov.spb.ru> X-Enigmail-Version: 1.3.4 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig51A31B145ADAD5210DDFB260" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED, AWL, DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:13:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig51A31B145ADAD5210DDFB260 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable On 19/12/2011 08:27, Lev Serebryakov wrote: > Here is one problem: we have choice from three items: >=20 > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >=20 > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > (communication with them, convincing, that they benchamrks are unfare > / meaningless, ets) (2a) Ignore Phoronix, other than explaining concisely why their numbers are complete balderdash. Publish our own benchmarks, done with care and rigour and using well defined, repeatable, peer reviewed methodology that anyone can repeat. Aggressively publicise these results. > (3) Lose [potential] userbase. Indeed. Unfortunately "performance" is /the/ deciding factor in many OS choices, never mind that it is an impossibly complex subject to generalise to a few management-friendly numbers in a one-size-fits-all abstract way. Having only one source of published numbers suggesting that "OS Foo is better" *even if those numbers are completely bogus* will have a disproportionate effect. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig51A31B145ADAD5210DDFB260 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7vACYACgkQ8Mjk52CukIyprwCfdBSflN+g1ON0ZQhfhBNzlyPM eYUAnjgrAFW1/QlDQHwQ0a3Cff5KwHlh =lCiv -----END PGP SIGNATURE----- --------------enig51A31B145ADAD5210DDFB260-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 09:17:29 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 79E0B1065672 for ; Mon, 19 Dec 2011 09:17:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2637614F4DB for ; Mon, 19 Dec 2011 09:17:25 +0000 (UTC) Message-ID: <4EEF0124.4000902@FreeBSD.org> Date: Mon, 19 Dec 2011 01:17:24 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:17:29 -0000 I updated to r228700 from 228122 and dhclient exits immediately saying that em0 doesn't exist. However ifconfig seems to disagree: em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:24:e8:30:10:9b nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 nd6 options=21 Interestingly, some of the options are different in that version, vs. the working version: em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:24:e8:30:10:9b inet 172.17.198.245 netmask 0xffff0000 broadcast 172.17.255.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 09:44:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904F0106566B; Mon, 19 Dec 2011 09:44:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2191A8FC16; Mon, 19 Dec 2011 09:44:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2831:a229:70d2:ba0b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0E0B94AC1C; Mon, 19 Dec 2011 13:44:10 +0400 (MSK) Date: Mon, 19 Dec 2011 13:44:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1902268932.20111219134409@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EEAE8DF.40303@rewt.org.uk> <4EEAEDE1.50604@zedat.fu-berlin.de> <4EEB42B1.1000506@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Joe Holden , FreeBSD Stable Mailing List , Current FreeBSD , Arnaud Lacombe , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:44:13 -0000 Hello, Adrian. You wrote 16 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 20:43:27: > Guys/girls/fuzzy things - this is 2011; people look at shiny blog > sites with graphs rather than mailing lists. Sorry, we lost that > battle. :) My thoughts exactly. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 09:44:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755021065780 for ; Mon, 19 Dec 2011 09:44:48 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E81388FC12 for ; Mon, 19 Dec 2011 09:44:47 +0000 (UTC) Received: from outgoing.leidinger.net (p5796DF89.dip.t-dialin.net [87.150.223.137]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 0A4CB84403D; Mon, 19 Dec 2011 10:19:46 +0100 (CET) Received: from localhost (unknown [85.94.224.21]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 82BFD5ED9; Mon, 19 Dec 2011 10:19:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1324286383; bh=GdbktkJ5k5WZLVm4GLUbOaR9Dk4SPxSrM1XyJ7hJR28=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=xwnAUiE3jOFpflqQf0DpXUpaeXtBPeh455yL3/Ah+8SksEsjv7GoPVlZ6YXu9SnOd S2mjF7C3rtu9wWPYQ2YisC6qWq6bn/dzb7uJ6H/WOz8u7sSVBpju8sVf3BgVwgKXhJ G0Wd0Vxe1cOM3o4CZLyDJjTFqh7N1Bg4AmcG+5cjp/oJERFVionXQhFKhl9BJaPdIy g7e1xD9+FMcq0ISaAfCvFmjfv6WB+qfkpN1rDizmJxjseFD9gDcEHqCLDRRgssrmn5 A+vQVO9Sed1C4QG9diIimqC4vrSgjtXvy4ohVRiFKx7agUeVoYt5I5YwwZ0JpXqYjs DBDAyAZEhU0Eg== Date: Mon, 19 Dec 2011 10:18:44 +0100 Message-ID: Importance: normal From: Alexander Leidinger To: glebius@freebsd.org MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 0A4CB84403D.A49DD X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.422, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, J_CHICKENPOX_63 0.60, TW_SV 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1324891187.21611@gQcKQNcg6KM+qQ68fZ3O9Q X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:44:48 -0000 SGksCgp3ZSBzdXBwb3J0IHRoZSBvZmZpY2lhbCB3YXlzIHRvIHVwZGF0ZSBGcmVlQlNEIHdpdGgg ZGVsZXRlLW9sZC4gVGhpcyBtZWFucyBpbnN0YWxsa2VybmVsIHJlc3AuIGluc3RhbGwgaW4gdGhl IGtlcm5lbCBjb25maWcgZGlyZWN0b3J5LCBhbmQgZnJlZWJzZC11cGRhdGUuIEkgaG9wZSBmcmVl YnNkLXVwZGF0ZSBkb2VzIHRoZSByaWdodCB0aGluZyBhbmQgbW92ZXMgdGhlIG9sZCBrZXJuZWwg ZGlyZWN0b3J5IG91dCBvZiB0aGUgd2F5LgoKV2UgZG8gbm90IHN1cHBvcnQgd2VpcmQgY2FzZXMg d2l0aCBkZWxldGUtb2xkLiBBcyBzdWNoIHRoZSBlbnRyeSBkb2VzIG5vdCBiZW9uZyBpbm8gT2Jz b2xldGVGaWxlcy4KCkJ5ZSwKQWxleGFuZGVyLgoKLS0gClNlbmQgdmlhIGFuIEFuZHJvaWQgZGV2 aWNlLCBwbGVhc2UgZm9yZ2l2ZSBicmV2aXR5IGFuZCB0eXBvZ3JhcGhpYyBhbmQgc3BlbGxpbmcg ZXJyb3JzLsKgR2xlYiBTbWlybm9mZiA8Z2xlYml1c0BmcmVlYnNkLm9yZz4gaGF0IGdlc2Nocmll YmVuOsKgwqBBbGV4YW5kZXIsCgpPbiBTYXQsIERlYyAxNywgMjAxMSBhdCAwMzowODo0M1BNICsw MTAwLCBBbGV4YW5kZXIgTGVpZGluZ2VyIHdyb3RlOgpBPiB3ZSBuZXZlciBoYWQgYSBrZXJuZWwg cGFydCBpbiB0aGUgbGlzdC4gUmVpbnN0YWxsa2VybmVsIGlzIG5vdCBhIHZhbGlkIHRhcmdldCBh ZnRlciB1cGRhdGluZyB0aGUgc291cmNlcy4gVGhlIHJlbmFtaW5nIHdpbGwgb25seSB0YWtlIGVm ZmVrdCBhZnRlciB1cGRhdGluZy4gQW5kIHdlIGFscmVhZHkgaGF0IGlzc3VlcyBiZWNhdXNlIHRo ZSBsaXN0IHdhcyB0b28gbG9uZy4KQT4gWW91ciBlbnRyeSBmb3IgdGhlIGNhcnAgbW9kdWxlIGlz IGNvbXBsZXRlbHkgb3V0IG9mIHF1ZXN0aW9uIGZvciB0aGlzIGxpc3QuIFBsZWFzZSByZW1vdmUg aXQuCgpUaGUgZmlsZSAvYm9vdC9rZXJuZWwvaWZfY2FycC5rbyBoYWQgYmVlbiBpbnN0YWxsZWQg b24gb2xkZXIgaW5zdGFsbGF0aW9ucy4gSXQKaXMgbm90IG92ZXJ3cml0dGVuIG5vdy4gVGh1cywg aXQgbWF5IGhhcHBlbiBpbiBhIHNvbWUgd2VpcmQgY2FzZSwgdGhhdCBpdCBpcwpsZWZ0IGludGFj dC4gJ21ha2UgaW5zdGFsbGtlcm5lbCcgaXMgbm90IHRoZSBvbmx5IHdheSB0byB1cGdyYWRlIEZy ZWVCU0QuClRvIGNvdmVyIHRoZXNlIHBvdGVudGlhbCBjYXNlcyBJIGhhdmUgYWRkZWQgYW4gZW50 cnkuIFRoaXMgZW50cnkgZG9lc24ndApodXJ0IGFueWJvZHkgb3IgYW55dGhpbmcuCgpUaGUgYXJn dW1lbnQgZm9yIGdldHRpbmcgbGlzdCBvZiBPYnNvbGV0ZUZpbGVzLmluYyBjYW4ndCBiZSB0YWtl biBzZXJpb3VzbHkuIFRoZQpmYWN0IGlzIHRoYXQgdGhpcyBmaWxlIGlzIGdvaW5nIHRvIGluc3Rh bnRseSBncm93IGluIGFueSBmb3JzZWVuIGZ1dHVyZS4gSXQKaXMgbmV2ZXIgZ29pbmcgdG8gZ2V0 IHNob3J0ZXIuIFRodXMsIGlmIHdlIGFyZSBnZXR0aW5nIHByb2JsZW1zIHdpdGggdGhlCmxpc3Qg Z2V0dGluZyB0b28gbG9uZywgdGhlbiB3ZSBuZWVkIHRvIGVuaGFuY2UgdGhlIHNjcmlwdCB0aGF0 IGRlbGV0ZSBvbGQgZmlsZXMsCm5vdCB0cnkgdG8gcmVkdWNlIGl0IGJ5IDAuMDIzNSUgcmVtb3Zp bmcgb25lIG9mIHJlY2VudCBlbnRyaWVzLCB0aGF0IGlzCnVuY2VydGFpbi4KCkkgYW0gYWRkaW5n IGN1cnJlbnRAIHRvIENDLCBtYXkgYmUgc29tZW9uZSBjYW4gdGFrZSByb2xlIG9mIG5lZ290aWF0 b3Igb24gdGhpcwppc3N1ZSwgb3IganVzdCBoYXMgb3Bpbmlvbi4KCkE+IApBPiBCeWUsCkE+IEFs ZXhhbmRlci4KQT4gCkE+IC0tIApBPiBTZW5kIHZpYSBhbiBBbmRyb2lkIGRldmljZSwgcGxlYXNl IGZvcmdpdmUgYnJldml0eSBhbmQgdHlwb2dyYXBoaWMgYW5kIHNwZWxsaW5nIGVycm9ycy7CoEds ZWIgU21pcm5vZmYgPGdsZWJpdXNAZnJlZWJzZC5vcmc+IGhhdCBnZXNjaHJpZWJlbjrCoMKgQWxl eGFuZGVyLApBPiAKQT4gT24gRnJpLCBEZWMgMTYsIDIwMTEgYXQgMDU6NDk6MDNQTSArMDEwMCwg QWxleGFuZGVyIExlaWRpbmdlciB3cm90ZToKQT4gQT4gdGhlIE9ic29sZXRlRmlsZXMgcGFydCBp c3Qgbm90IG5lY2Vzc2FyeSwgcGxlYXNlIHJlbW92ZS4gVGhlIGluc3RhbGxrZXJuZWwgbW92ZXMg dGhlIG9sZCBzdHVmZiB0byBrZXJuZWwub2xkLgpBPiAKQT4gSSBrbm93IHRoYXQgaXQgZG9lcywg YW5kIGZvciA5OSUgcGVvcGxlIHRoaXMgZW50cnkgd29uJ3QgYmUgbmVlZGVkLgpBPiBCdXQgbGV0 IGl0IGJlIGhlcmUgZm9yIHRob3NlLCB3aG8gaW5zdGFsbCBuZXcga2VybmVsIHNvbWUgb3RoZXIg d2F5LApBPiBmb3IgZXhhbXBsZSAnbWFrZSByZWluc3RhbGxrZXJuZWwnIG9yIGV2ZW4gY29weWlu ZyBieSBoYW5kLgpBPiAKQT4gVGhlIHN1cGVyZmx1b3VzIGVudHJ5IGluIE9ic29sZXRlRmlsZXMu aW5jIGhhcyB6ZXJvIG5lZ2F0aXZlIGltcGFjdCwKQT4gYW55d2F5LgpBPiAKQT4gLS0gCkE+IFRv dHVzIHR1dXMsIEdsZWJpdXMuCkE+IAoKLS0gClRvdHVzIHR1dXMsIEdsZWJpdXMuCgo= From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 09:47:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8201065678 for ; Mon, 19 Dec 2011 09:47:24 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DC25B8FC1E for ; Mon, 19 Dec 2011 09:47:23 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2831:a229:70d2:ba0b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id BA31A4AC34; Mon, 19 Dec 2011 13:47:22 +0400 (MSK) Date: Mon, 19 Dec 2011 13:47:20 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1704813846.20111219134720@serebryakov.spb.ru> To: Matthew Seaman In-Reply-To: <4EEF0025.6040205@infracaninophile.co.uk> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF0025.6040205@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:47:24 -0000 Hello, Matthew. You wrote 19 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 13:13:09: >> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >>=20 >> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >> (communication with them, convincing, that they benchamrks are unfare >> / meaningless, ets) > (2a) Ignore Phoronix, other than explaining concisely why their numbers > are complete balderdash. Publish our own benchmarks, done with care and > rigour and using well defined, repeatable, peer reviewed methodology > that anyone can repeat. Aggressively publicise these results. Ok, it is The Way too, I agree. But in modern world, unfortunately (for me, and I'm sure, for many FreeBSD hackers), keywords are "Aggressive= ly publicise" but not "done with care and rigour and using well defined, repeatable, peer reviewed methodology that anyone can repeat" >> (3) Lose [potential] userbase. > Indeed. Unfortunately "performance" is /the/ deciding factor in many OS > choices, never mind that it is an impossibly complex subject to > generalise to a few management-friendly numbers in a one-size-fits-all > abstract way. Having only one source of published numbers suggesting > that "OS Foo is better" *even if those numbers are completely bogus* > will have a disproportionate effect. Yep. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 10:40:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B95E106566B for ; Mon, 19 Dec 2011 10:40:01 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id C541C8FC12 for ; Mon, 19 Dec 2011 10:40:00 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 4E41E6A61CD; Mon, 19 Dec 2011 11:39:59 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id aangjlmx5l_s; Mon, 19 Dec 2011 11:39:59 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 027186A61CB; Mon, 19 Dec 2011 11:39:58 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id pBJAdw5Y051338; Mon, 19 Dec 2011 11:39:58 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id pBJAdwxF050297; Mon, 19 Dec 2011 11:39:58 +0100 (CET) (envelope-from lars) Date: Mon, 19 Dec 2011 11:39:58 +0100 From: Lars Engels To: Matthew Seaman Message-ID: <20111219103958.GB12597@e-new.0x20.net> References: <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF0025.6040205@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <4EEF0025.6040205@infracaninophile.co.uk> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:40:01 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2011 at 09:13:09AM +0000, Matthew Seaman wrote: > On 19/12/2011 08:27, Lev Serebryakov wrote: > > Here is one problem: we have choice from three items: > >=20 > > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD > >=20 > > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > > (communication with them, convincing, that they benchamrks are unfare > > / meaningless, ets) >=20 > (2a) Ignore Phoronix, other than explaining concisely why their numbers > are complete balderdash. Publish our own benchmarks, done with care and > rigour and using well defined, repeatable, peer reviewed methodology > that anyone can repeat. Aggressively publicise these results. >=20 Slashdot and others don't ignore Phoronix, so (2a) is only and option if you accept (3). My personal opinion: Phoronix may compare apples to oranges from time to time and it might be possible to catch up with Linux' results by tweaking some system parameters, but Joe Average expects a fast and working OS out-of-the-box and after reading a Phoronix benchmark, he will probably prefer Linux over FreeBSD. /me thinks that our userbase is not big enough to put off potential new or existing users, so we should question our default config values or clearly and publicly explain why the results for FreeBSD are slower because of data integrity / security / $other_reasons. > > (3) Lose [potential] userbase. >=20 > Indeed. Unfortunately "performance" is /the/ deciding factor in many OS > choices, never mind that it is an impossibly complex subject to > generalise to a few management-friendly numbers in a one-size-fits-all > abstract way. Having only one source of published numbers suggesting > that "OS Foo is better" *even if those numbers are completely bogus* > will have a disproportionate effect. --K8nIJk4ghYZn606h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7vFH4ACgkQKc512sD3afgDcACgr9HKuz+iZPbDPIUXp30JbKM7 3UUAoIzS9N61djU8ogO+RzHcN72x1iFf =P+Np -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 10:43:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 143A1106564A; Mon, 19 Dec 2011 10:43:21 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B2A8A8FC14; Mon, 19 Dec 2011 10:43:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rcagh-0006Da-77>; Mon, 19 Dec 2011 11:43:19 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rcagh-0005tu-3r>; Mon, 19 Dec 2011 11:43:19 +0100 Message-ID: <4EEF1541.3020009@mail.zedat.fu-berlin.de> Date: Mon, 19 Dec 2011 11:43:13 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: lev@FreeBSD.org References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> In-Reply-To: <6140271.20111219122721@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig42E820DE89A492B418570B73" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Mon, 19 Dec 2011 11:52:54 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , Current FreeBSD , "Samuel J. Greear" , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42E820DE89A492B418570B73 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable On 12/19/11 09:27, Lev Serebryakov wrote: > Hello, Samuel. > You wrote 15 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 16:32:47: >=20 >> Other benchmarks in the Phoronix suite and their representations are >> similarly flawed, _ALL_ of these results should be ignored and no time= >> should be wasted by any FreeBSD committer further evaluating this >> garbage. (Yes, I have been down this rabbit hole). > Here is one problem: we have choice from three items: >=20 > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >=20 > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > (communication with them, convincing, that they benchamrks are unfare > / meaningless, ets) >=20 > (3) Lose [potential] userbase. >=20 > You know, that these benchmarks are bad. I know. But potential (and > even some current!) user doesn't. And it seems, that these benchmarks > become popular over Internet. >=20 +1 It is not about a faky way to let a specific OS look good by any means. I'M afraid of (3), which also implies pushing more towards beeing meaningless and not anymore a alternative with a unique, remarkable criteria to be choosen as __the__ operating system of the first choice for several purposes. By the way, how such a development could look alaike is very clear when it comes to GPGPU/HPC, highly related to the availability of proper graphics card drivers, X11 development and the necessary libraries, APIs and even compilers. None of those "professionals" out here, none of those pushing the eyewhitness of bad performance into very deep-insight-talks about what could cause the problem has obviously ever negotiated with people of the "upper floor" when it comes to the choice of the OS. Within my department, the *BSD aren't even considered an option, even if they would perform best for the specified purpose (which, I regeret, is a shrinking basis now since also Linux will have ZFS). Sometimes I feel like Don Quixote, fighting against windmills. Sorry having brought up this thread and I beg for pardon for putting another scrtach into the autoerotic world of the "core". --------------enig42E820DE89A492B418570B73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7vFUcACgkQU6Ni+wtCKv9T5QD/SOTCNVyyf6NlJowS3L0ui56j xOjYEv9qTcg9rDKxwZYA/1i6XhGlfyysh26mCTKtLsRPIA/qoBmszBE6DHj2BVnm =kznr -----END PGP SIGNATURE----- --------------enig42E820DE89A492B418570B73-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 11:49:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A55B1065675; Mon, 19 Dec 2011 11:49:19 +0000 (UTC) (envelope-from sjg@evilcode.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B249D8FC08; Mon, 19 Dec 2011 11:49:18 +0000 (UTC) Received: by qcse13 with SMTP id e13so4457735qcs.13 for ; Mon, 19 Dec 2011 03:49:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.106.230 with SMTP id y38mr5306405qco.83.1324295357936; Mon, 19 Dec 2011 03:49:17 -0800 (PST) Received: by 10.229.6.142 with HTTP; Mon, 19 Dec 2011 03:49:17 -0800 (PST) In-Reply-To: <6140271.20111219122721@serebryakov.spb.ru> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> Date: Mon, 19 Dec 2011 04:49:17 -0700 Message-ID: From: "Samuel J. Greear" To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 19 Dec 2011 12:09:29 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 11:49:19 -0000 2011/12/19 Lev Serebryakov : > Hello, Samuel. > You wrote 15 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16:= 32:47: > >> Other benchmarks in the Phoronix suite and their representations are >> similarly flawed, _ALL_ of these results should be ignored and no time >> should be wasted by any FreeBSD committer further evaluating this >> garbage. (Yes, I have been down this rabbit hole). > =C2=A0Here is one problem: we have choice from three items: > > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD > > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > (communication with them, convincing, that they benchamrks are unfare > / meaningless, ets) > > (3) Lose [potential] userbase. > > =C2=A0You know, that these benchmarks are bad. I know. But potential (and > =C2=A0even some current!) user doesn't. And it seems, that these benchmar= ks > =C2=A0become popular over Internet. > > -- > // Black Lion AKA Lev Serebryakov > Here is where you completely derail the train, let me paste again what I said before. ... Take the first test as an example, Blogbench read. This doesn't raise any red flags, right? At least not until you realize that Blogbench isn't a read test, it's a read/write test. So what they have done here is run a read/write test and then thrown away the write results for both platforms and reported only the read results. If you dig down into the actual results, http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will see two Blogbench numbers, one for read and another for write. These were both taken from the same Blogbench run, so FreeBSD optimizes writes over reads, that's probably a good thing for your data but a bad thing when someone totally misrepresents benchmark results. ... FreeBSD actually does _BETTER_ (subjectively) in this test than the Linux system when you look at what is really going on. FreeBSD is favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, the benchmarks need to be fixed to represent reality rather than throwing half of the results in the trash. To be quite frank, "fixing" FreeBSD to look good on this benchmark will make it a worse real-world OS. But you guys go ahead and foot-shoot over these ridiculous benchmarks all you want. Sam From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 12:16:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF21106566C for ; Mon, 19 Dec 2011 12:16:21 +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 6BBB28FC18 for ; Mon, 19 Dec 2011 12:16:19 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA05527; Mon, 19 Dec 2011 14:16:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rcc8g-000FxF-Hw; Mon, 19 Dec 2011 14:16:18 +0200 Message-ID: <4EEF2B11.6080802@FreeBSD.org> Date: Mon, 19 Dec 2011 14:16:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky X-Enigmail-Version: undefined Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: FreeBSD current , freebsd-usb@FreeBSD.org Subject: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:16:21 -0000 Hans Petter, I think that I see some issues in the USB code that could cause problems in some edge cases. >From easiest to hardest: 1. I think that currently there is a LOR in usb_bus_shutdown. I think that the following patch should fix it: =========================================================================== --- a/sys/dev/usb/controller/usb_controller.c +++ b/sys/dev/usb/controller/usb_controller.c @@ -479,6 +481,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) bus_generic_shutdown(bus->bdev); + USB_BUS_UNLOCK(bus); usbd_enum_lock(udev); err = usbd_set_config_index(udev, USB_UNCONFIG_INDEX); @@ -497,6 +500,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) (bus->methods->set_hw_power_sleep) (bus, USB_HW_POWER_SHUTDOWN); usbd_enum_unlock(udev); + USB_BUS_LOCK(bus); } static void =========================================================================== Otherwise there are a lot of nasty reports like: lock order reversal: (sleepable after non-sleepable) 1st 0xffffff80006b0688 ohci0 (ohci0) @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2nd 0xfffffe00023cf070 USB config SX lock (USB config SX lock) @ /usr/src/sys/dev/usb/usb_device.c:2643 usbd_transfer_unsetup can sleep! with the following non-sleepable locks held: exclusive sleep mutex ohci0 (ohci0) r = 0 (0xffffff80006b0688) locked @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2. Somewhat related to the above. I think that because the USB subsystem implements the shutdown method and detaches all its drivers, then the ukbd driver won't be able to properly handle the 'shutdown -h' case where the kernel asks to "press any key to reboot" at the end. Depending on which thread wins the race (the one that executes the mainline shutdown code or the USB explore thread that detaches USB devices) there will either an immediate reboot or a later crash when any key is pressed. This is not critical, but OTOH perhaps the USB subsystem doesn't have to do the shutdown. As far as I can see a lot of the drivers just do nothing for the shutdown, for better or for worth. A side note: perhaps it would be a good idea to pass the 'how' value as an additional parameter to device_shutdown. 3. Looking at usbd_transfer_poll I see that it touches a lot of locks, including taking the bus lock. As we've discussed before, this is not safe in a particular context where the polling is supposed to be used - in the kdb/ddb context. If the lock is already taken by another thread, then instead of being able to use a USB keyboard a user would get even less debug-able crash. Also, it seems that usbd_transfer_poll calls into the usual state machine with various callbacks and dynamically made decisions about whether to execute some actions directly or defer their execution to a different thread. That code also touches locks in various places. I think that it would be more preferable to have a method that does the job in a more straight-forward way, without touching any locks, ignoring the usual code paths and assuming that no other treads are running in parallel. Ditto for the method to submit a request. As a side note: we probably need a flag to mark certain things such as e.g. the ukbd driver as "non recoverable", meaning that once those are used in the kdb context then there is no safe way to go back to normal system operation. What do you think? Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 12:37:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE951065670; Mon, 19 Dec 2011 12:37:06 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4628FC17; Mon, 19 Dec 2011 12:37:04 +0000 (UTC) Received: by eaaf13 with SMTP id f13so6620577eaa.13 for ; Mon, 19 Dec 2011 04:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0wi/Wbuip3cH9qeu6x1992gVofK4PoRs2fI3qt+7/7w=; b=Hhw9GlA7hYve4ei9ITL5GoYQOrvx3lahn1SRvQO3RusmfZiq0mpU/ur70Z1djS3X+y T68iITu4eQp7L47Y2z16MtGnnxR+7i27PHup87WCS8KXTunlIorO0ZpaUu920U5WlLjT MO4OHxeaqleC3X8xrO74p8VxjUeolKNAPRg2U= Received: by 10.204.153.12 with SMTP id i12mr1363806bkw.134.1324296890338; Mon, 19 Dec 2011 04:14:50 -0800 (PST) MIME-Version: 1.0 Sender: edhoprima@gmail.com Received: by 10.204.99.148 with HTTP; Mon, 19 Dec 2011 04:14:29 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> From: Edho Arief Date: Mon, 19 Dec 2011 19:14:29 +0700 X-Google-Sender-Auth: f60fFL58ifrd7aLVCLxH6cjeNFk Message-ID: To: "Samuel J. Greear" Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , lev@freebsd.org, FreeBSD Stable Mailing List , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:37:06 -0000 On Mon, Dec 19, 2011 at 6:49 PM, Samuel J. Greear wrote: > FreeBSD actually does _BETTER_ (subjectively) in this test than the > Linux system when you look at what is really going on. FreeBSD is > favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, > the benchmarks need to be fixed to represent reality rather than > throwing half of the results in the trash. To be quite frank, "fixing" > FreeBSD to look good on this benchmark will make it a worse real-world > OS. But you guys go ahead and foot-shoot over these ridiculous > benchmarks all you want. > Would you prefer a blog which allows you to: A: - create/write 100 posts/s - serve/read 1000 posts/s or B: - create/write 80 posts/s - serve/read 3000 posts/s ? I would personally choose B. -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 12:46:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBE0106566C; Mon, 19 Dec 2011 12:46:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id D0CE28FC1A; Mon, 19 Dec 2011 12:46:02 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C6DE225D3810; Mon, 19 Dec 2011 12:46:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0C7ACBD754E; Mon, 19 Dec 2011 12:46:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id yODAahEFYbgZ; Mon, 19 Dec 2011 12:46:00 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E2DBDBD754C; Mon, 19 Dec 2011 12:45:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 19 Dec 2011 12:45:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B3C99A3-9F39-49A6-89E3-CD4945B24E87@lists.zabbadoz.net> References: To: Alexander Leidinger X-Mailer: Apple Mail (2.1084) Cc: glebius@freebsd.org, current@freebsd.org Subject: Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:46:03 -0000 On 19. Dec 2011, at 09:18 , Alexander Leidinger wrote: I think in general Alexander is right here. We usually do not allow for atomic replacements of individual modules in /boot/kernel/ unless you = know what you are doing, in which case the ObsoleteFiles.inc doesn't seem to be what you are running either. Also please remember that for the user (not a developers) hitting this = means a major version upgrade to 10.x and that will never keep the same = /boot/kernel anyway. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:16:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F29106566C for ; Mon, 19 Dec 2011 13:16:56 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB0A38FC12 for ; Mon, 19 Dec 2011 13:16:55 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2641917obb.13 for ; Mon, 19 Dec 2011 05:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3lafZdW7FjQwsg/ddhWPav/+PadBzHpHigeVEwEYI50=; b=S7xgKsi5Y4gAvXSK00qaNwcVLkjUVxbQFSSrGtPSxzDWHrJVb1XQU4HtyQmEfBgy++ SVs1eb7xSV30VxDf6+TN78KtA6l75KSyzEv2BtoePCcMgWhMX7vc0iRZLp219AcdfTmI UdWfIueepxrteTZf4Dukc98KCmh0SYHDQ01A8= MIME-Version: 1.0 Received: by 10.182.112.9 with SMTP id im9mr2072693obb.74.1324300615141; Mon, 19 Dec 2011 05:16:55 -0800 (PST) Received: by 10.182.150.70 with HTTP; Mon, 19 Dec 2011 05:16:55 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> Date: Mon, 19 Dec 2011 15:16:55 +0200 Message-ID: From: Alexander Yerenkow To: Edho Arief Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:16:56 -0000 IMHO, no offence, as always. As were told, Phoronix used "default" setup, not tuned. So? Is average user will tune it after setup? No, he'll get same defaults, and would expect same performance as in tests, and he probably get it. The problem of FreeBSD is not it's default settings, some kind of very-safe defaults really should be there. But problem really is lacking of choosing them (defaults) during install, for average users. For example, few checkboxes with common sysctl tuning would be perfect, even if they would be marked as "Experimental", or not recommended. I'm thinking it's better way to make something in one place (like in installer) rather than require make almost same actions in many (hundreds of thousands?... more?...) places (end-users forced to read mail-lists/handbooks/forums over and over for same solutions). Simple example - many connections for PostgreSQL is not available on FreeBSD out-of-box. Just google "postgresql freebsd max connection" and you'll see how many there bikesheds requested and same solutions posted again and again :) FreeBSD currently have very obscure, closed community. To get in touch, you need to subscribe to several mail lists, constantly read them, I've just found recently (my shame of course) in mail list that there is service ( pub.allbsd.org) which constantly building current versions. This is great, but at homepage of freebsd.org there is no word about it :) I hope we all do something good about this, and things will going to change. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:24:53 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E90106564A; Mon, 19 Dec 2011 13:24:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id E954F8FC08; Mon, 19 Dec 2011 13:24:52 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c128:98f8:6426:c74d] (unknown [IPv6:2001:7b8:3a7:0:c128:98f8:6426:c74d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 92F4B5C37; Mon, 19 Dec 2011 14:24:51 +0100 (CET) Message-ID: <4EEF3B22.8010401@FreeBSD.org> Date: Mon, 19 Dec 2011 14:24:50 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4EEF0124.4000902@FreeBSD.org> In-Reply-To: <4EEF0124.4000902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:24:53 -0000 On 2011-12-19 10:17, Doug Barton wrote: > I updated to r228700 from 228122 and dhclient exits immediately saying > that em0 doesn't exist. However ifconfig seems to disagree: > > > em0: flags=8843 metric 0 mtu 1500 > > options=4219b > ether 00:24:e8:30:10:9b > nd6 options=29 > media: Ethernet autoselect (100baseTX) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > nd6 options=21 > > > Interestingly, some of the options are different in that version, vs. > the working version: > > em0: flags=8843 metric 0 mtu 1500 > options=219b > ether 00:24:e8:30:10:9b > inet 172.17.198.245 netmask 0xffff0000 broadcast 172.17.255.255 > nd6 options=29 > media: Ethernet autoselect (100baseTX) > status: active I saw this too, when my kernel and userland were out of sync (e.g. just after installing a new kernel, and before installworld). I suspect it is caused by the changes in r228571, which cause old ifconfig and dhclient to not recognize any interfaces. I'm not 100% sure though... From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 12:43:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90F9C1065670; Mon, 19 Dec 2011 12:43:35 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76E908FC12; Mon, 19 Dec 2011 12:43:34 +0000 (UTC) Received: by eaaf13 with SMTP id f13so6629679eaa.13 for ; Mon, 19 Dec 2011 04:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FQVOCcpkzlD7NzWddQVT3iYX1aJO/J5QVY5rRxYEaxY=; b=evT7zSp1kNTjCvTgiS9RujfehmeSMY2HcIifI0CFV8kxtBgRQVm8bcF3UQl1HhxwSU XCsVRud5+KaswrU6a2wIXHdkChfYxGEOPv36te5Bh/vA9oskmN3gtZaE7tArQYKN5W4g 2JyM6W8oJBwr9qPcHuutAiNmX3tXu7OalIFXU= Received: by 10.204.145.86 with SMTP id c22mr1307688bkv.61.1324297303797; Mon, 19 Dec 2011 04:21:43 -0800 (PST) References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> In-Reply-To: Mime-Version: 1.0 (1.0) From: Andreas Nilsson Date: Mon, 19 Dec 2011 13:21:35 +0100 Message-ID: <-4802855903238902044@unknownmsgid> To: "Samuel J. Greear" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 19 Dec 2011 13:44:27 +0000 Cc: Adrian Chadd , "lev@freebsd.org" , FreeBSD Stable Mailing List , Current FreeBSD , "freebsd-performance@freebsd.org" , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:43:35 -0000 On 19 dec 2011, at 12:50, "Samuel J. Greear" wrote: > 2011/12/19 Lev Serebryakov : >> Hello, Samuel. >> You wrote 15 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16= :32:47: >> >>> Other benchmarks in the Phoronix suite and their representations are >>> similarly flawed, _ALL_ of these results should be ignored and no time >>> should be wasted by any FreeBSD committer further evaluating this >>> garbage. (Yes, I have been down this rabbit hole). >> Here is one problem: we have choice from three items: >> >> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >> >> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >> (communication with them, convincing, that they benchamrks are unfare >> / meaningless, ets) >> >> (3) Lose [potential] userbase. >> >> You know, that these benchmarks are bad. I know. But potential (and >> even some current!) user doesn't. And it seems, that these benchmarks >> become popular over Internet. >> >> -- >> // Black Lion AKA Lev Serebryakov >> > > Here is where you completely derail the train, let me paste again what > I said before. > > ... > Take the first test as an example, Blogbench read. This doesn't raise > any red flags, right? At least not until you realize that Blogbench > isn't a read test, it's a read/write test. So what they have done here > is run a read/write test and then thrown away the write results for > both platforms and reported only the read results. If you dig down > into the actual results, > http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will > see two Blogbench numbers, one for read and another for write. These > were both taken from the same Blogbench run, so FreeBSD optimizes > writes over reads, that's probably a good thing for your data but a > bad thing when someone totally misrepresents benchmark results. > ... > > FreeBSD actually does _BETTER_ (subjectively) in this test than the > Linux system when you look at what is really going on. FreeBSD is > favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, > the benchmarks need to be fixed to represent reality rather than > throwing half of the results in the trash. To be quite frank, "fixing" > FreeBSD to look good on this benchmark will make it a worse real-world > OS. But you guys go ahead and foot-shoot over these ridiculous > benchmarks all you want. > > Sam > I seem to remember that before ULE people were fleeing to Linux as the os to run apache on since 4BSD didn't scale all too well. That may have changed over time though. However ULE could perhaps be made aware technologies like turbo-boost, ie with few threads higher performance might be gained by utilizing all virtual cores on a physical core before spreading tasks to too different cores. Just my speculations though :) Regards Andreas Nilsson From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:40:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E271065783; Mon, 19 Dec 2011 13:40:21 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id A510F8FC13; Mon, 19 Dec 2011 13:40:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RcdRy-0005wV-Vs>; Mon, 19 Dec 2011 14:40:19 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RcdRy-00011A-Sa>; Mon, 19 Dec 2011 14:40:18 +0100 Message-ID: <4EEF3EBD.5070804@mail.zedat.fu-berlin.de> Date: Mon, 19 Dec 2011 14:40:13 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Andreas Nilsson References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <-4802855903238902044@unknownmsgid> In-Reply-To: <-4802855903238902044@unknownmsgid> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig29BC4489A3A49561FC71552C" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Mon, 19 Dec 2011 13:44:39 +0000 Cc: Adrian Chadd , "lev@freebsd.org" , FreeBSD Stable Mailing List , Current FreeBSD , "Samuel J. Greear" , "freebsd-performance@freebsd.org" , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29BC4489A3A49561FC71552C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/19/11 13:21, Andreas Nilsson wrote: > On 19 dec 2011, at 12:50, "Samuel J. Greear" wrote: >=20 >> 2011/12/19 Lev Serebryakov : >>> Hello, Samuel. >>> You wrote 15 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3.,= 16:32:47: >>> >>>> Other benchmarks in the Phoronix suite and their representations are= >>>> similarly flawed, _ALL_ of these results should be ignored and no ti= me >>>> should be wasted by any FreeBSD committer further evaluating this >>>> garbage. (Yes, I have been down this rabbit hole). >>> Here is one problem: we have choice from three items: >>> >>> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >>> >>> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >>> (communication with them, convincing, that they benchamrks are unfare= >>> / meaningless, ets) >>> >>> (3) Lose [potential] userbase. >>> >>> You know, that these benchmarks are bad. I know. But potential (and >>> even some current!) user doesn't. And it seems, that these benchmark= s >>> become popular over Internet. >>> >>> -- >>> // Black Lion AKA Lev Serebryakov >>> >> >> Here is where you completely derail the train, let me paste again what= >> I said before. >> >> ... >> Take the first test as an example, Blogbench read. This doesn't raise >> any red flags, right? At least not until you realize that Blogbench >> isn't a read test, it's a read/write test. So what they have done here= >> is run a read/write test and then thrown away the write results for >> both platforms and reported only the read results. If you dig down >> into the actual results, >> http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will >> see two Blogbench numbers, one for read and another for write. These >> were both taken from the same Blogbench run, so FreeBSD optimizes >> writes over reads, that's probably a good thing for your data but a >> bad thing when someone totally misrepresents benchmark results. >> ... >> >> FreeBSD actually does _BETTER_ (subjectively) in this test than the >> Linux system when you look at what is really going on. FreeBSD is >> favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, >> the benchmarks need to be fixed to represent reality rather than >> throwing half of the results in the trash. To be quite frank, "fixing"= >> FreeBSD to look good on this benchmark will make it a worse real-world= >> OS. But you guys go ahead and foot-shoot over these ridiculous >> benchmarks all you want. >> >> Sam >> >=20 > I seem to remember that before ULE people were fleeing to Linux as the > os to run apache on since 4BSD didn't scale all too well. That may > have changed over time though. >=20 > However ULE could perhaps be made aware technologies like turbo-boost, > ie with few threads higher performance might be gained by utilizing > all virtual cores on a physical core before spreading tasks to too > different cores. >=20 > Just my speculations though :) >=20 > Regards > Andreas Nilsson Such a scheduling stratey is definitely necessary on AMDs new "Bulldozer" architecture, which seems to be very pitty about threads locked on the same module. Microsoft just offered a patch for Windows 7 to implant such a "Bulldozer" awarenes but they withdraw the patch as invalid two days after the release. The seults seem to favour FPU performance over integer performance. As Samuel Greear wrote, FreeBSD looks not that bad in some of the benchmarks but there are obviosly issues, at least the fact that Phoronix/openbenchmark.org are the only sites offering benchmarks at all.= People outside the FreeBSD realm looking for opportunities, what do you think they will look first after? Phoronix/Openbenchmark.org made the first step and they seem to make FreeBSD look bad (in my opinion), whether righteous or not. Compared to several subjective impressions I have in our heterogeneous environment at the lab, Linux on the same hardware looks in several aspects much bett= er. Oliver --------------enig29BC4489A3A49561FC71552C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7vPsIACgkQU6Ni+wtCKv9F6gD+L6Yl43PugtrH2aCjeNsAAURl UlEQkfMGOI2jl0hz1sAA/2kbm5jV1Gg1LCzkX4CurY8Q7fMkNnNVpONHIyW0wI3Q =a3fR -----END PGP SIGNATURE----- --------------enig29BC4489A3A49561FC71552C-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:45:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24FD1065670 for ; Mon, 19 Dec 2011 13:45:45 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 070A68FC26 for ; Mon, 19 Dec 2011 13:45:43 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBJDjU9g020323 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 15:45:35 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EEF3FF9.7070307@digsys.bg> Date: Mon, 19 Dec 2011 15:45:29 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:45:45 -0000 I have already canceled few replies to this thread, but... On 19.12.11 15:16, Alexander Yerenkow wrote: > IMHO, no offence, as always. I feel obliged to include the same disclaimer :-) > As were told, Phoronix used "default" setup, not tuned. Not really. They created some weird test environment, at least for FreeBSD -- who knows, possibly for Linux as well. For example, ZFS is by no means a default file system in FreeBSD. You need to go trough manual steps, to enable it, to build the pool, filesystems etc. This is because ZFS is very powerful file system and storage manager that needs some thinking before you implement it -- then it may reward you with features not found anywhere else. Funny, ZFS is available in Linux too, and at least the file system tests might benefit from using one and the same file system. One would expect that ZFS was used for both, in a multiple-disk (way over 4 disks) setup, as one would expect to be the case for a 'server'. > So? Is average user will tune it after setup? No, he'll get same defaults, > and would expect same performance as in tests, and he probably get it. You forget, that the "FreeBSD type" and the "Linux type" are quite different. This is why both worlds exist. The FreeBSD way is to understand what you do and configure your environment accordingly. FreeBSD gives you flexibility to do as you please and in most of the possible configurations it will work. Maybe not optimally, but will not break on you. With FreeBSD there is never "one true way" to do things. The Linux way on the other hand is to follow a "HowTo" instruction. The Linux OS is typically optimized for these setups and as long as you follow the HOWTO you are safe and well performance-wise. If you go way out of the prescriptions in the HOWTO, you may end up with losing data, crashing system or extremely poor performance. I know, things are not that black and white, but this is the general difference. > But problem really is lacking of choosing them (defaults) during install, > for average users. Who are the average users? It has been repeatedly said, that the "PC" user is always better to start with PC-BSD, because it is FreeBSD with "safe defaults suitable for a desktop". > For example, few checkboxes with common sysctl tuning would be perfect, > even if they would be marked as "Experimental", or not recommended. By following this, we push FreeBSD into the Linux style of doing things: someone else decides what is good for you, without having a clue of your circumstances. > Simple example - many connections for PostgreSQL is not available on > FreeBSD out-of-box. Just google "postgresql freebsd max connection" and > you'll see how many there bikesheds requested and same solutions posted > again and again :) Still, PostgreSQL is not part of FreeBSD. The PostgreSQL port clearly says what you need to adjust in your setup in order to use it. As do most other ports. Computers do what people ask them to do -- we are far from the AI times, when the computers will assembe, configure and run themselves the way we think they should. > FreeBSD currently have very obscure, closed community. Some say this is a feature ;-) > To get in touch, you need to subscribe to several mail lists, constantly read them, I've just found recently (my shame of course) in mail list that there is service (pub.allbsd.org) which constantly building current versions. This is great, > but at homepage of freebsd.org there is no word about it :) There is a menu "Community" on www.freebsd.org and an "Forums" entry there. You don't have to use mailing lists, of you prefer forums. > I hope we all do something good about this, and things will going to change. Many bright people do a lot of things about all of these issues. If there is a problem, one needs to understand the problem, what causes the problem and what are the implications. Merely reacting on the symptoms never helps in the long run, as the core problem is not resolved. So far in this thread there is no evidence of where the problem is. There is no evidence even if there is a real problem -- except that many people get overly excited by benchmarks. To the last point I could add that, with experience, one learns that: the benchmarks done in your environment, with your settings, with your OS version, on your hardware and with your set of applications does not help me much on my hardware/software/configuration -- except if these happen to be very similar. /usr/ports/benchmarks is your friend. Daniel From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 14:22:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118BD106564A for ; Mon, 19 Dec 2011 14:22:11 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm20-vm1.bullet.mail.ne1.yahoo.com (nm20-vm1.bullet.mail.ne1.yahoo.com [98.138.91.21]) by mx1.freebsd.org (Postfix) with SMTP id BE4288FC15 for ; Mon, 19 Dec 2011 14:22:10 +0000 (UTC) Received: from [98.138.90.51] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 14:22:10 -0000 Received: from [98.138.226.127] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 14:22:10 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 14:22:10 -0000 X-Yahoo-Newman-Id: 63919.51508.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3amkN_wVM1m8NHj0sD00uS43_xbUiYzZgCl4qD5NG8uJTu7 gcJMaNrSO8UFGRQQuLLiH0Them0MNWJurHs5ceUC9FrLUw.Q9Orfk6baPmwU YZpmenlAdHwdHD5nVYzEY97r3KixSsQnjNwfVEJrMmPPBykWjIEeCbs71Bz3 AuwpvuDhLIW2eIv2cV6WtLkCAedUUeyrel7T2oTiY1OJGUy7.RMKzQlXemE1 fnVMaPg0I.HwwWpyMWsuOiF5V8jTm6bWf5Ksvs89kq6OSZYASr014Wkl.Blv skutvJnePVz9PzZRzg9x_L0g10oRAJyw_XkouDQkqK.gSuuKMd3u9fochexu QGASsOWCnkM8v5LBeJOG.HBXz.WbqhYSbHTgPiHVGJ5Hq2QHy22jAwS9Wukn kifPkeYt2eEsxd.Y- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.154.224 with plain) by smtp206.mail.ne1.yahoo.com with SMTP; 19 Dec 2011 06:22:09 -0800 PST Message-ID: <4EEF488E.1030904@freebsd.org> Date: Mon, 19 Dec 2011 15:22:06 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:22:11 -0000 Hi ZFS users, for quite some time I have observed an uneven distribution of load between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of a longer log of 10 second averages logged with gstat: dT: 10.001s w: 10.000s filter: ^a?da?.$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 132 104 4036 4.2 27 1129 5.3 45.2| ada0 0 129 103 3679 4.5 26 1115 6.8 47.6| ada1 1 91 61 2133 4.6 30 1129 1.9 29.6| ada2 0 81 56 1985 4.8 24 1102 6.0 29.4| ada3 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 148 108 4084 5.3 39 2511 7.2 55.5| ada0 1 141 104 3693 5.1 36 2505 10.4 54.4| ada1 1 102 62 2112 5.6 39 2508 5.5 35.4| ada2 0 99 60 2064 6.0 39 2483 3.7 36.1| ada3 This goes on for minutes, without a change of roles (I had assumed that other 10 minute samples might show relatively higher load on another subset of the drives, but it's always the first two, which receive some 50% more read requests than the other two. The test consisted of minidlna rebuilding its content database for a media collection held on that pool. The unbalanced distribution of requests does not depend on the particular application and the distribution of requests does not change when the drives with highest load approach 100% busy. This is a -CURRENT built from yesterdays sources, but the problem exists for quite some time (and should definitely be reproducible on -STABLE, too). The pool consists of a 4 drive raidz1 on an ICH10 (H67) without cache or log devices and without much ZFS tuning (only max. ARC size, should not at all be relevant in this context): zpool status -v pool: raid1 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM raid1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 ada2p2 ONLINE 0 0 0 ada3p2 ONLINE 0 0 0 errors: No known data errors Cached configuration: version: 28 name: 'raid1' state: 0 txg: 153899 pool_guid: 10507751750437208608 hostid: 3558706393 hostname: 'se.local' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 10507751750437208608 children[0]: type: 'raidz' id: 0 guid: 7821125965293497372 nparity: 1 metaslab_array: 30 metaslab_shift: 36 ashift: 12 asize: 7301425528832 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 7487684108701568404 path: '/dev/ada0p2' phys_path: '/dev/ada0p2' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 12000329414109214882 path: '/dev/ada1p2' phys_path: '/dev/ada1p2' whole_disk: 1 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 2926246868795008014 path: '/dev/ada2p2' phys_path: '/dev/ada2p2' whole_disk: 1 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 5226543136138409733 path: '/dev/ada3p2' phys_path: '/dev/ada3p2' whole_disk: 1 create_txg: 4 I'd be interested to know, whether this behavior can be reproduced on other systems with raidz1 pools consisting of 4 or more drives. All it takes is generating some disk load and running the command: gstat -I 10000000 -f '^a?da?.$' to obtain 10 second averages. I have not even tried to look at the scheduling of requests in ZFS, but I'm surprised to see higher than average load on just 2 of the 4 drives, since RAID parity should be evenly spread over all drives and for each file system block a different subset of 3 out of 4 drives should be able to deliver the data without need to reconstruct it from parity (that would lead to an even distribution of load). I've got two theories what might cause the obtained behavior: 1) There is some meta data that is only kept on the first two drives. Data is evenly spread, but meta data accesses lead to additional reads. 2) The read requests are distributed in such a way, that 1/3 goes to ada0, another 1/3 to ada1, while the remaining 1/3 is evenly distributed to ada2 and ada3. So: Can anybody reproduce this distribution requests? Any idea, why this is happening and whether something should be changed in ZFS to better distribute the load (leading to higher file system performance)? Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 14:33:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E27106566C; Mon, 19 Dec 2011 14:33:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1908FC14; Mon, 19 Dec 2011 14:33:09 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 216678899; Mon, 19 Dec 2011 15:33:07 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Mon, 19 Dec 2011 15:30:40 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EEF2B11.6080802@FreeBSD.org> In-Reply-To: <4EEF2B11.6080802@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?windows-1252?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?windows-1252?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201112191530.40526.hselasky@c2i.net> Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:33:11 -0000 On Monday 19 December 2011 13:16:17 Andriy Gapon wrote: > Hans Petter, > > I think that I see some issues in the USB code that could cause problems in > some edge cases. > From easiest to hardest: > Hi, > 1. I think that currently there is a LOR in usb_bus_shutdown. I think > that the following patch should fix it: > =========================================================================== > --- a/sys/dev/usb/controller/usb_controller.c > +++ b/sys/dev/usb/controller/usb_controller.c > @@ -479,6 +481,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) > > bus_generic_shutdown(bus->bdev); > > + USB_BUS_UNLOCK(bus); > usbd_enum_lock(udev); > > err = usbd_set_config_index(udev, USB_UNCONFIG_INDEX); > @@ -497,6 +500,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) > (bus->methods->set_hw_power_sleep) (bus, USB_HW_POWER_SHUTDOWN); > > usbd_enum_unlock(udev); > + USB_BUS_LOCK(bus); > } > You are right! I believe my kernel tests were run without WITNESS. > 2. Somewhat related to the above. I think that because the USB subsystem > implements the shutdown method and detaches all its drivers, then the ukbd > driver won't be able to properly handle the 'shutdown -h' case where the > kernel asks to "press any key to reboot" at the end. Depending on which > thread wins the race (the one that executes the mainline shutdown code or > the USB explore thread that detaches USB devices) there will either an > immediate reboot or a later crash when any key is pressed. > This is not critical, but OTOH perhaps the USB subsystem doesn't have to do > the shutdown. As far as I can see a lot of the drivers just do nothing > for the shutdown, for better or for worth. > > A side note: perhaps it would be a good idea to pass the 'how' value as an > additional parameter to device_shutdown. The shutdown of USB is done to give USB devices at last chance to turn off or reduce their current consumption. In the old code the Host controller itself would be disabled, so keyboard wouldn't have worked I believe like you suggest. BTW: Shutdown should be executed after any "Press any key to reboot." and shutdown should be given time to complete, hence for USB this needs to happen in sync with the rest of the USB system. > 3. Looking at usbd_transfer_poll I see that it touches a lot of locks, > including taking the bus lock. As we've discussed before, this is not safe > in a particular context where the polling is supposed to be used - in the > kdb/ddb context. If the lock is already taken by another thread, then > instead of being able to use a USB keyboard a user would get even less > debug-able crash. Also, it seems that usbd_transfer_poll calls into the > usual state machine with various callbacks and dynamically made decisions > about whether to execute some actions directly or defer their execution to > a different thread. This is an optimisation. If the current thread can do the job without a LOR, then we do it right away. Else we let another thread do it. It is possible to have a more simple model, but then you will also get more task switches. > That code also touches locks in various places. I > think that it would be more preferable to have a method that does the job > in a more straight-forward way, without touching any locks, ignoring the > usual code paths and assuming that no other treads are running in > parallel. Ditto for the method to submit a request. The current USB code can be run fine without real locks, if you do a few tricks. I have a single-threaded BSD-kernel replacement for this which works like a charm for non-FreeBSD projects. I'm going to paste a few lines FYI: Why not extend "struct mtx" to have two fields which are only used in case of system polling (no scheduler running): struct mtx { xxx; int owned_polling = 0; struct mtx *parent_polling; }; void mtx_init(struct mtx *mtx, const char *name, const char *type, int opt) { mtx->owned = 0; mtx->parent = mtx; } void mtx_lock(struct mtx *mtx) { mtx = mtx->parent; mtx->owned++; } void mtx_unlock(struct mtx *mtx) { mtx = mtx->parent; mtx->owned--; } int mtx_owned(struct mtx *mtx) { mtx = mtx->parent; return (mtx->owned != 0); } void mtx_destroy(struct mtx *mtx) { /* NOP */ } Maybe mtx_init, mtx_lock, mtx_unlock mtx_owned, mtx_destroy, etc, could be function pointers, which are swapped at panic. USB is SMP! To run SMP code from a single thread, you need to create a hiherachy of the threads: 1) Callbacks (Giant) 2) Callbacks (non-Giant) 3) Control EP (non-Giant) 4) Explore thread (non-Giant) When the explore thread is busy, we look for work in the level above and so on. The USB stack implements this principle, which is maybe not documented anywhere btw. If you want more than code, you can hire me to do that. The mtx-code above I believe is far less work than to make new code which handles the polling case only. The reason for the parent mutex field, is to allow easy grouping of mutexes, so that USB easily can figure out what can run or not. > > As a side note: we probably need a flag to mark certain things such as e.g. > the ukbd driver as "non recoverable", meaning that once those are used in > the kdb context then there is no safe way to go back to normal system > operation. I think you need to do shutdown _after_ the "Press any key to reboot". A flag won't help. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:00:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A6E4106566C for ; Mon, 19 Dec 2011 15:00:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id D20088FC1C for ; Mon, 19 Dec 2011 15:00:48 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 220976267 for freebsd-current@freebsd.org; Mon, 19 Dec 2011 16:00:23 +0100 To: FreeBSD current From: Hans Petter Selasky X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= Date: Mon, 19 Dec 2011 15:57:56 +0100 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112191557.56271.hselasky@c2i.net> Subject: USB testers wanted for system suspend and resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:00:49 -0000 Hi, Can someone which have access to computer hardware which support system suspend and resume please test FreeBSD-10-current after this commit: http://svn.freebsd.org/changeset/base/228709 Part of the test: Remove any custom rc.d scripts which load/unload ehci/ohci/uhci/xhci during suspend and resume. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:02:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02718106566C for ; Mon, 19 Dec 2011 15:02:13 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id BF3DA8FC14 for ; Mon, 19 Dec 2011 15:02:12 +0000 (UTC) Received: by qadb17 with SMTP id b17so2799369qad.13 for ; Mon, 19 Dec 2011 07:02:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.183.145 with SMTP id cg17mr25192598qab.11.1324305389523; Mon, 19 Dec 2011 06:36:29 -0800 (PST) Received: by 10.229.94.205 with HTTP; Mon, 19 Dec 2011 06:36:29 -0800 (PST) In-Reply-To: <4EEF488E.1030904@freebsd.org> References: <4EEF488E.1030904@freebsd.org> Date: Mon, 19 Dec 2011 15:36:29 +0100 Message-ID: From: Olivier Smedts To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:02:13 -0000 2011/12/19 Stefan Esser : > Hi ZFS users, > > for quite some time I have observed an uneven distribution of load > between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of > a longer log of 10 second averages logged with gstat: > > dT: 10.001s =A0w: 10.000s =A0filter: ^a?da?.$ > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A00 =A0 =A0130 =A0 =A0106 =A0 4134 =A0 =A04.5 =A0 =A0 23 =A0 1033 = =A0 =A05.2 =A0 48.8| ada0 > =A0 =A00 =A0 =A0131 =A0 =A0111 =A0 3784 =A0 =A04.2 =A0 =A0 19 =A0 1007 = =A0 =A04.0 =A0 47.6| ada1 > =A0 =A00 =A0 =A0 90 =A0 =A0 66 =A0 2219 =A0 =A04.5 =A0 =A0 24 =A0 1031 = =A0 =A05.1 =A0 31.7| ada2 > =A0 =A01 =A0 =A0 81 =A0 =A0 58 =A0 2007 =A0 =A04.6 =A0 =A0 22 =A0 1023 = =A0 =A02.3 =A0 28.1| ada3 > > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A01 =A0 =A0132 =A0 =A0104 =A0 4036 =A0 =A04.2 =A0 =A0 27 =A0 1129 = =A0 =A05.3 =A0 45.2| ada0 > =A0 =A00 =A0 =A0129 =A0 =A0103 =A0 3679 =A0 =A04.5 =A0 =A0 26 =A0 1115 = =A0 =A06.8 =A0 47.6| ada1 > =A0 =A01 =A0 =A0 91 =A0 =A0 61 =A0 2133 =A0 =A04.6 =A0 =A0 30 =A0 1129 = =A0 =A01.9 =A0 29.6| ada2 > =A0 =A00 =A0 =A0 81 =A0 =A0 56 =A0 1985 =A0 =A04.8 =A0 =A0 24 =A0 1102 = =A0 =A06.0 =A0 29.4| ada3 > > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A01 =A0 =A0148 =A0 =A0108 =A0 4084 =A0 =A05.3 =A0 =A0 39 =A0 2511 = =A0 =A07.2 =A0 55.5| ada0 > =A0 =A01 =A0 =A0141 =A0 =A0104 =A0 3693 =A0 =A05.1 =A0 =A0 36 =A0 2505 10= .4 54.4| ada1 > =A0 =A01 =A0 =A0102 =A0 =A0 62 =A0 2112 =A0 =A05.6 =A0 =A0 39 =A0 2508 = =A0 =A05.5 =A0 35.4| ada2 > =A0 =A00 =A0 =A0 99 =A0 =A0 60 =A0 2064 =A0 =A06.0 =A0 =A0 39 =A0 2483 = =A0 =A03.7 =A0 36.1| ada3 > > This goes on for minutes, without a change of roles (I had assumed that > other 10 minute samples might show relatively higher load on another > subset of the drives, but it's always the first two, which receive some > 50% more read requests than the other two. > > The test consisted of minidlna rebuilding its content database for a > media collection held on that pool. The unbalanced distribution of > requests does not depend on the particular application and the > distribution of requests does not change when the drives with highest > load approach 100% busy. > > This is a -CURRENT built from yesterdays sources, but the problem exists > for quite some time (and should definitely be reproducible on -STABLE, to= o). > > The pool consists of a 4 drive raidz1 on an ICH10 (H67) without cache or > log devices and without much ZFS tuning (only max. ARC size, should not > at all be relevant in this context): > > zpool status -v > =A0pool: raid1 > =A0state: ONLINE > =A0scan: none requested > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0raid1 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0raidz1-0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ada0p2 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ada1p2 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ada2p2 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ada3p2 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > errors: No known data errors > > Cached configuration: > =A0 =A0 =A0 =A0version: 28 > =A0 =A0 =A0 =A0name: 'raid1' > =A0 =A0 =A0 =A0state: 0 > =A0 =A0 =A0 =A0txg: 153899 > =A0 =A0 =A0 =A0pool_guid: 10507751750437208608 > =A0 =A0 =A0 =A0hostid: 3558706393 > =A0 =A0 =A0 =A0hostname: 'se.local' > =A0 =A0 =A0 =A0vdev_children: 1 > =A0 =A0 =A0 =A0vdev_tree: > =A0 =A0 =A0 =A0 =A0 =A0type: 'root' > =A0 =A0 =A0 =A0 =A0 =A0id: 0 > =A0 =A0 =A0 =A0 =A0 =A0guid: 10507751750437208608 > =A0 =A0 =A0 =A0 =A0 =A0children[0]: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type: 'raidz' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id: 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0guid: 7821125965293497372 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nparity: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0metaslab_array: 30 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0metaslab_shift: 36 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ashift: 12 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0asize: 7301425528832 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is_log: 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create_txg: 4 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0children[0]: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type: 'disk' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id: 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0guid: 7487684108701568404 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path: '/dev/ada0p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phys_path: '/dev/ada0p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0whole_disk: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create_txg: 4 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0children[1]: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type: 'disk' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0guid: 12000329414109214882 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path: '/dev/ada1p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phys_path: '/dev/ada1p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0whole_disk: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create_txg: 4 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0children[2]: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type: 'disk' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id: 2 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0guid: 2926246868795008014 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path: '/dev/ada2p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phys_path: '/dev/ada2p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0whole_disk: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create_txg: 4 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0children[3]: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type: 'disk' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id: 3 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0guid: 5226543136138409733 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0path: '/dev/ada3p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phys_path: '/dev/ada3p2' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0whole_disk: 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create_txg: 4 > > I'd be interested to know, whether this behavior can be reproduced on > other systems with raidz1 pools consisting of 4 or more drives. All it > takes is generating some disk load and running the command: > > =A0 =A0 =A0 =A0gstat -I 10000000 -f '^a?da?.$' > > to obtain 10 second averages. > > I have not even tried to look at the scheduling of requests in ZFS, but > I'm surprised to see higher than average load on just 2 of the 4 drives, > since RAID parity should be evenly spread over all drives and for each > file system block a different subset of 3 out of 4 drives should be able > to deliver the data without need to reconstruct it from parity (that > would lead to an even distribution of load). > > I've got two theories what might cause the obtained behavior: > > 1) There is some meta data that is only kept on the first two drives. > Data is evenly spread, but meta data accesses lead to additional reads. > > 2) The read requests are distributed in such a way, that 1/3 goes to > ada0, another 1/3 to ada1, while the remaining 1/3 is evenly distributed > to ada2 and ada3. > > > So: Can anybody reproduce this distribution requests? Hello, Stupid question, but are your drives all exactly the same ? I noticed "ashift: 12" so I think you should have at least one 4k-sector drive, are you sure they're not mixed with 512B per sector drives ? > > Any idea, why this is happening and whether something should be changed > in ZFS to better distribute the load (leading to higher file system > performance)? > > Best regards, STefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:06:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7E61065680; Mon, 19 Dec 2011 15:06:21 +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 57ABA8FC0A; Mon, 19 Dec 2011 15:06:19 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08656; Mon, 19 Dec 2011 17:06:15 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rcen9-000G52-8n; Mon, 19 Dec 2011 17:06:15 +0200 Message-ID: <4EEF52E5.8020102@FreeBSD.org> Date: Mon, 19 Dec 2011 17:06:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> In-Reply-To: <201112191530.40526.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:06:21 -0000 First replying just to couple of points where there seems to be a misunderstanding. on 19/12/2011 16:30 Hans Petter Selasky said the following: >> 2. Somewhat related to the above. I think that because the USB subsystem >> implements the shutdown method and detaches all its drivers, then the ukbd >> driver won't be able to properly handle the 'shutdown -h' case where the >> kernel asks to "press any key to reboot" at the end. Depending on which >> thread wins the race (the one that executes the mainline shutdown code or >> the USB explore thread that detaches USB devices) there will either an >> immediate reboot or a later crash when any key is pressed. >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to do >> the shutdown. As far as I can see a lot of the drivers just do nothing >> for the shutdown, for better or for worth. >> >> A side note: perhaps it would be a good idea to pass the 'how' value as an >> additional parameter to device_shutdown. > > The shutdown of USB is done to give USB devices at last chance to turn off or > reduce their current consumption. > > In the old code the Host controller itself would be disabled, so keyboard > wouldn't have worked I believe like you suggest. I am not sure about the old code, I have never checked it. But the atkbd definitely works at this stage. > BTW: Shutdown should be executed after any "Press any key to reboot." and > shutdown should be given time to complete, hence for USB this needs to happen > in sync with the rest of the USB system. Have you actually ever done "shutdown -h"? In other words do you know what the "system halt" is? :) I am not sure if it would be a good idea to declare a system as "halted" before shutdown_final hooks are executed. I would rather sacrifice the whole "press a key" interactivity and simply executed hlt. That's because I think that the system halt has a very limited usage, mostly in combination with UPS, where interactivity via console/keyboard is not very important. BTW, the reason that I suggested to pass 'how' to device_shutdown is to give drivers some choice. E.g. USB could the whole shutdown thing for the cases of poweroff and reboot, but keep the devices going for halt. But probably right now we just need to make a decision whether ukbd is going to support system halt or not. If not, then I think that usb_shutdown() must wait until the explore_proc terminates. If yes, then usb_shutdown() should become a noop. Or it could become quite smart to detach/poweroff other devices in such a way that ukbd still stays usable. But that's probably harder to implement. [snip] >> As a side note: we probably need a flag to mark certain things such as e.g. >> the ukbd driver as "non recoverable", meaning that once those are used in >> the kdb context then there is no safe way to go back to normal system >> operation. > > I think you need to do shutdown _after_ the "Press any key to reboot". A flag > won't help. Umm, this suggestion was about entering and exiting KDB/DDB, not about shutdown/reboot. P.S. I've just looked at the code in stable/7 and it seems that it didn't actually unconfigured USB and detached device drivers. At least ohci_shutdown and ohci_shutdown are not called on FreeBSD. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:13:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF641065677; Mon, 19 Dec 2011 15:13:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id CB0F58FC0A; Mon, 19 Dec 2011 15:13:45 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 219701462; Mon, 19 Dec 2011 16:13:42 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Mon, 19 Dec 2011 16:11:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> <4EEF52E5.8020102@FreeBSD.org> In-Reply-To: <4EEF52E5.8020102@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201112191611.15432.hselasky@c2i.net> Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:13:47 -0000 On Monday 19 December 2011 16:06:13 Andriy Gapon wrote: > First replying just to couple of points where there seems to be a > misunderstanding. > > on 19/12/2011 16:30 Hans Petter Selasky said the following: > >> 2. Somewhat related to the above. I think that because the USB > >> subsystem implements the shutdown method and detaches all its drivers, > >> then the ukbd driver won't be able to properly handle the 'shutdown -h' > >> case where the kernel asks to "press any key to reboot" at the end. > >> Depending on which thread wins the race (the one that executes the > >> mainline shutdown code or the USB explore thread that detaches USB > >> devices) there will either an immediate reboot or a later crash when > >> any key is pressed. > >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to > >> do the shutdown. As far as I can see a lot of the drivers just do > >> nothing for the shutdown, for better or for worth. > >> > >> A side note: perhaps it would be a good idea to pass the 'how' value as > >> an additional parameter to device_shutdown. > > > > The shutdown of USB is done to give USB devices at last chance to turn > > off or reduce their current consumption. > > > > In the old code the Host controller itself would be disabled, so keyboard > > wouldn't have worked I believe like you suggest. > > I am not sure about the old code, I have never checked it. But the atkbd > definitely works at this stage. ATKBD is no comparison to UKBD :-) > > > BTW: Shutdown should be executed after any "Press any key to reboot." and > > shutdown should be given time to complete, hence for USB this needs to > > happen in sync with the rest of the USB system. > > Have you actually ever done "shutdown -h"? In other words do you know what > the "system halt" is? :) No, I'm usually "shutdown -p now". > I am not sure if it would be a good idea to declare a system as "halted" > before shutdown_final hooks are executed. I would rather sacrifice the > whole "press a key" interactivity and simply executed hlt. That's because > I think that the system halt has a very limited usage, mostly in > combination with UPS, where interactivity via console/keyboard is not very > important. > > BTW, the reason that I suggested to pass 'how' to device_shutdown is to > give drivers some choice. E.g. USB could the whole shutdown thing for the > cases of poweroff and reboot, but keep the devices going for halt. I see. > > But probably right now we just need to make a decision whether ukbd is > going to support system halt or not. > If not, then I think that usb_shutdown() must wait until the explore_proc > terminates. > If yes, then usb_shutdown() should become a noop. Or it could become quite > smart to detach/poweroff other devices in such a way that ukbd still stays > usable. But that's probably harder to implement. I will fix that. I see a missing wait there. Can I assume that we are allowed to sleep from device_shutdown() and that system timers still work? > P.S. I've just looked at the code in stable/7 and it seems that it didn't > actually unconfigured USB and detached device drivers. At least > ohci_shutdown and ohci_shutdown are not called on FreeBSD. Hmm. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:42:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ADC6106566C for ; Mon, 19 Dec 2011 15:42:23 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1044D8FC08 for ; Mon, 19 Dec 2011 15:42:22 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MATjG-1RR8lz3iVG-00B1mT; Mon, 19 Dec 2011 16:42:22 +0100 Message-ID: <4EEF5B5C.90905@brockmann-consult.de> Date: Mon, 19 Dec 2011 16:42:20 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EEF488E.1030904@freebsd.org> In-Reply-To: <4EEF488E.1030904@freebsd.org> X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:bPqgbp5OjsoLqDCTFJyDn6hh3bG4/hn6HInIUlQIzuI lfZ1WGZYecDCsClCJ02/xbx+LO0UWvl4hWCxd24L6Azv8TUJHu asNsg3scCXkK3kAYPptA9TW198lHOcEkuuCqjTmaIV3IFFfTyh tu9BHu+AfiHSqaE+XpLYhQMRuIAoP426clq98u52XVXmleKh12 kD3O31Wze8U3Ez839sWjZIvmbMC/I2A69T2dqogtbe2yLYpwDZ OI/ndwLTi9KTjAGtuxfT4+AHtekRMOIaXnfc1/zeQAYxgifvT1 otj1TMlxQs8AngBUD+AV+4lG9V1SjE1wwkeAQ2QaItnldHU7Rn /5rFPb9QPQytoexLpkQtoKrz/SWOFzPYIkwXt14nX Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:42:23 -0000 On 12/19/2011 03:22 PM, Stefan Esser wrote: > Hi ZFS users, > > for quite some time I have observed an uneven distribution of load > between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of > a longer log of 10 second averages logged with gstat: > > dT: 10.001s w: 10.000s filter: ^a?da?.$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 > 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 > 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 > 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 1 132 104 4036 4.2 27 1129 5.3 45.2| ada0 > 0 129 103 3679 4.5 26 1115 6.8 47.6| ada1 > 1 91 61 2133 4.6 30 1129 1.9 29.6| ada2 > 0 81 56 1985 4.8 24 1102 6.0 29.4| ada3 > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 1 148 108 4084 5.3 39 2511 7.2 55.5| ada0 > 1 141 104 3693 5.1 36 2505 10.4 54.4| ada1 > 1 102 62 2112 5.6 39 2508 5.5 35.4| ada2 > 0 99 60 2064 6.0 39 2483 3.7 36.1| ada3 > > ... > So: Can anybody reproduce this distribution requests? I don't have a raidz1 machine, and no time to make you a special raidz1 pool out of spare disks, but on my raidz2 I can only ever see unevenness when a disk is bad, or between different vdevs. But you only have one vdev. Check is that your disks are identical (are they? we can only assume so since you didn't say so). Show us output from: smartctl -i /dev/ada0 smartctl -i /dev/ada1 smartctl -i /dev/ada2 smartctl -i /dev/ada3 Since your tests show read ms/r to be pretty even, I guess your disks are not broken. But the ms/w is slightly different. So I think it seems that the first 2 disks are slower for writing (someone once said that refurbished disks are like this, even if identical), or the hard disk controller ports they use are slower. For example, maybe your motherboard has 6 ports, and you plugged disks 1,2,3 into port 1,2,3 and disk 4 into port 5. Disk 3 and 4 would have their own channel, but disk 1 and 2 share one. So if the disks are identical, I would guess your hard disk controller is to blame. To test this, first back it up. Then *fix your setup by using labels*. ie. use gpt/somelabel0 or gptid/....... rather than ada0p2. Check "ls /dev/gpt*" output for options on what labels you have already. Then try swapping disks around to see if the load changes. Make sure to back up... Swapping disks (or even removing one depending on controller, etc. when it fails) without labels can be bad. eg. You have ada1 ada2 ada3 ada4. Someone spills coffee on ada2; it fries and cannot be detected anymore, and you reboot. Now you have ada1 ada2 ada3. Then things are usually still fine (even though ada3 is now ada2 and ada4 is now ada3, because there is some zfs superblock stuff to keep track of things), but if you also had an ada5 that was not part of the pool, or was a spare or a log or something other than another disk in the same vdev as ada1, etc., bad things happen when it becomes ada4. Unfortunately, I don't know exactly what people do to cause the "bad things" that happen. When this happened to me, it just said my pool was faulted or degraded or something, and set a disk or two to UNAVAIL or FAULTED. I don't remember it automatically resilvering them, but when I read about these problems, I think it seems like some disks were resilvered afterwards. And last thing I can think of is to make sure your partitions are aligned, and identical. Show us output from: gpart show > Any idea, why this is happening and whether something should be changed > in ZFS to better distribute the load (leading to higher file system > performance)? > > Best regards, STefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:50:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4015E1065673 for ; Mon, 19 Dec 2011 15:50:56 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4198FC1D for ; Mon, 19 Dec 2011 15:50:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LWG00M0KK0UBF00@smtpauth2.wiscmail.wisc.edu>; Mon, 19 Dec 2011 09:50:54 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.77.223]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LWG00GLOK0RRM10@smtpauth2.wiscmail.wisc.edu>; Mon, 19 Dec 2011 09:50:51 -0600 (CST) Date: Mon, 19 Dec 2011 09:50:50 -0600 From: Nathan Whitehorn In-reply-to: To: freebsd-current@freebsd.org, freebsd-performance@freebsd.org Message-id: <4EEF5D5A.5050700@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.77.223 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.19.154214, SenderIP=76.210.77.223 References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111113 Thunderbird/8.0 Cc: Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:50:56 -0000 On 12/18/11 04:34, Adrian Chadd wrote: > The trouble is that there's lots of anecdotal evidence, but noone's > really gone digging deep into _their_ example of why it's broken. The > developers who know this stuff don't see anything wrong. That hints to > me it may be something a little more creepy - as an example, the > interplay between netisr/swi/taskqueue/callbacks and such. It may be > that something is being starved that isn't obviously obvious. It's > just a stab in the dark, but it sounds somewhat plausible based on > what I've seen ULE do in my network throughput hacking. > > I applaud reppie for trying to make it as easy as possible for people > to use KTR to provide scheduler traces for him to go digging with, so > please, if you have these issues and you can absolutely reproduce > them, please follow his instructions and work with him to get him what > he needs. > The thing I've seen is that ULE is substantially more enthusiastic about migrating processes between cores than 4BSD. Often, this is a good thing, but can increase the rate of cache misses, hurting performance for cache-bound processes (I see this particularly in HPC-type scientific workloads). It might be interesting to add some kind of tunable here. Another more interesting and slightly longer-term possibility if someone wants a project would be to integrate scheduling decisions with hwpmc counters, to accumulate statistics on cache hits at each context switch and preferentially keep processes with a high hits/misses ratio on the same thread/cache domain relative to processes with a low one. -Nathan P.S. The other thing that could be very interesting from a research and scheduling standpoint would be to integrate heterogeneous SMP support into the operating system, with a FreeBSD-4 "Application Processor" syscall model. We seem to be going down the road where GPGPU computing has MMUs, timer interrupts, IPIs, etc. (the next AMD Fusions, IBM Cell), as well as potential systems with both x86 and ARM cores. This is something that no operating system currently supports well, and would be a place for BSD to shine. If anyone has a free graduate student... From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:36:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6DC106564A; Mon, 19 Dec 2011 16:36:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id B95438FC16; Mon, 19 Dec 2011 16:36:11 +0000 (UTC) Received: by yhfq46 with SMTP id q46so4964861yhf.13 for ; Mon, 19 Dec 2011 08:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Wb5FEzJdhWwJ+aevr+mXYgQGzr7YA1RriJJ5JruHh7Q=; b=B+iIPkiXvo1MTohvmZ0/O8Ibjk7pyf63mnrbQNo3ES3+LauXmloMSnF4FM1icQKy7f KMLpPqug7r/i+dZBNn547zubeuGkKUBWwBpkX+OCXODj31xaqldVFkwkqfinAPkFJB5L sxQUZqdVgF3cQb/LrzOEGjYyH4ZGBtyhaN5E4= Received: by 10.236.77.232 with SMTP id d68mr28566968yhe.98.1324312571098; Mon, 19 Dec 2011 08:36:11 -0800 (PST) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id i50sm30763891yhk.11.2011.12.19.08.36.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 08:36:10 -0800 (PST) References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> In-Reply-To: <4EEF3B22.8010401@FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Mon, 19 Dec 2011 08:36:06 -0800 To: Dimitry Andric Cc: freebsd-current , Doug Barton Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:36:12 -0000 On Dec 19, 2011, at 5:24 AM, Dimitry Andric wrote: > On 2011-12-19 10:17, Doug Barton wrote: >> I updated to r228700 from 228122 and dhclient exits immediately saying >> that em0 doesn't exist. However ifconfig seems to disagree: >>=20 >>=20 >> em0: flags=3D8843 metric 0 mtu 1= 500 >>=20 >> options=3D4219b >> ether 00:24:e8:30:10:9b >> nd6 options=3D29 >> media: Ethernet autoselect (100baseTX) >> status: active >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D3 >> nd6 options=3D21 >>=20 >>=20 >> Interestingly, some of the options are different in that version, vs. >> the working version: >>=20 >> em0: flags=3D8843 metric 0 mtu 1= 500 >> options=3D219b >> ether 00:24:e8:30:10:9b >> inet 172.17.198.245 netmask 0xffff0000 broadcast 172.17.255.255 >> nd6 options=3D29 >> media: Ethernet autoselect (100baseTX) >> status: active >=20 > I saw this too, when my kernel and userland were out of sync (e.g. just > after installing a new kernel, and before installworld). I suspect it > is caused by the changes in r228571, which cause old ifconfig and > dhclient to not recognize any interfaces. I'm not 100% sure though. This makes sense because the structs that describe addresses changed recentl= y. -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:36:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9A41065679; Mon, 19 Dec 2011 16:36:51 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:32:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 9811E8FC22; Mon, 19 Dec 2011 16:36:50 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 2D8411802C66; Mon, 19 Dec 2011 17:36:49 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 43BAF1C00124; Mon, 19 Dec 2011 17:36:49 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id jHAlzghSZ0Kz; Mon, 19 Dec 2011 17:36:45 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-61-230.dynamic.mnet-online.de [93.104.61.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Mon, 19 Dec 2011 17:36:44 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 1A71C24B83; Mon, 19 Dec 2011 17:36:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 106D724B82; Mon, 19 Dec 2011 17:36:43 +0100 (CET) Date: Mon, 19 Dec 2011 17:36:42 +0100 (CET) From: Michael Reifenberger To: Stefan Esser In-Reply-To: <4EEF488E.1030904@freebsd.org> Message-ID: References: <4EEF488E.1030904@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:36:51 -0000 Hi, a quick test using `dd if=/dev/zero of=/test ...` shows: dT: 10.004s w: 10.000s filter: ^a?da?.$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 378 0 0 12.5 376 36414 11.9 60.6| ada0 0 380 0 0 12.2 378 36501 11.8 60.0| ada1 0 382 0 0 7.7 380 36847 11.6 59.2| ada2 0 375 0 0 7.4 374 36164 9.6 51.3| ada3 0 377 0 1 10.2 375 36325 10.1 53.3| ada4 10 391 0 0 39.3 389 38064 15.7 80.2| ada5 Seems to be sufficiently equally distributed for a life system... zpool status shows: ... NAME STATE READ WRITE CKSUM boot ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 ada4p3 ONLINE 0 0 0 ada5p3 ONLINE 0 0 0 ... The only cases I've seen (and expected to see) unequal load distributions on ZFS was after extending a nearly full four disk mirror pool by additional two disks. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:40:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD41E106566C for ; Mon, 19 Dec 2011 16:40:39 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 81F7A8FC12 for ; Mon, 19 Dec 2011 16:40:39 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id pBJGMKdt043093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 10:22:21 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id pBJGMK9b055483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 10:22:20 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id pBJGMKSe055480; Mon, 19 Dec 2011 10:22:20 -0600 (CST) (envelope-from dan) Date: Mon, 19 Dec 2011 10:22:20 -0600 From: Dan Nelson To: Stefan Esser Message-ID: <20111219162220.GK53453@dan.emsphone.com> References: <4EEF488E.1030904@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEF488E.1030904@freebsd.org> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 19 Dec 2011 10:22:21 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:40:39 -0000 In the last episode (Dec 19), Stefan Esser said: > for quite some time I have observed an uneven distribution of load between > drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of a longer > log of 10 second averages logged with gstat: > > dT: 10.001s w: 10.000s filter: ^a?da?.$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 > 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 > 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 > 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 [...] > zpool status -v > pool: raid1 > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > raid1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > ada0p2 ONLINE 0 0 0 > ada1p2 ONLINE 0 0 0 > ada2p2 ONLINE 0 0 0 > ada3p2 ONLINE 0 0 0 Any read from your raidz device will hit three disks (the checksum is applied across the stripe, not on each block, so a full stripe is always read) so I think your extra IOs are coming from somewhere else. What's on p1 on these disks? Could that be the cause of your extra I/Os? Does "zpool iostat -v 10" give you even numbers across all disks? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:49:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8893F106564A for ; Mon, 19 Dec 2011 16:49:05 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:32:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1692F8FC1E for ; Mon, 19 Dec 2011 16:49:04 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id C278C1802EF9; Mon, 19 Dec 2011 17:49:03 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 714641C0011E; Mon, 19 Dec 2011 17:49:03 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id 24akbetp1gI7; Mon, 19 Dec 2011 17:48:58 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-61-230.dynamic.mnet-online.de [93.104.61.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Mon, 19 Dec 2011 17:48:58 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 0179924B97; Mon, 19 Dec 2011 17:48:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id F271924B96; Mon, 19 Dec 2011 17:48:56 +0100 (CET) Date: Mon, 19 Dec 2011 17:48:56 +0100 (CET) From: Michael Reifenberger To: Peter Maloney In-Reply-To: <4EEF5B5C.90905@brockmann-consult.de> Message-ID: References: <4EEF488E.1030904@freebsd.org> <4EEF5B5C.90905@brockmann-consult.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:49:05 -0000 On Mon, 19 Dec 2011, Peter Maloney wrote: > Swapping disks (or even removing one depending on controller, etc. when > it fails) without labels can be bad. > eg. Since ZFS uses (and searches for) its own UUID partition signatures s disk wapping shouldn't matter as long enough disks are found. Set vfs.zfs.debug=1 during boot to watch what is searched for. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:05:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18643106564A; Mon, 19 Dec 2011 17:05:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC3FF8FC16; Mon, 19 Dec 2011 17:05:20 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2795566obb.13 for ; Mon, 19 Dec 2011 09:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7hLMRkgWqFY0kO9sk2oWVJSuomSe5vidSQ/zqLaoMwg=; b=RDU8ZBrPyuQxvvVm03y0mKGc74hTgEbtBRTeBEP6r+ESD7idKhLYI6gHAafce52e3S cncEgg7xmKlWaISQaihYVtyoC83prEqaOTSmGpm7+bj0ET+NX9aOR8TX64w2nsmRlaDp e10Zo7w+d0t0WpDKrSuR0RV6zgZtTu7nNoDx8= MIME-Version: 1.0 Received: by 10.182.17.102 with SMTP id n6mr10778933obd.56.1324314320418; Mon, 19 Dec 2011 09:05:20 -0800 (PST) Received: by 10.182.62.227 with HTTP; Mon, 19 Dec 2011 09:05:20 -0800 (PST) In-Reply-To: <4EEF488E.1030904@freebsd.org> References: <4EEF488E.1030904@freebsd.org> Date: Mon, 19 Dec 2011 09:05:20 -0800 Message-ID: From: Garrett Cooper To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:05:21 -0000 On Mon, Dec 19, 2011 at 6:22 AM, Stefan Esser wrote: > Hi ZFS users, > > for quite some time I have observed an uneven distribution of load > between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of > a longer log of 10 second averages logged with gstat: > > dT: 10.001s =A0w: 10.000s =A0filter: ^a?da?.$ > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A00 =A0 =A0130 =A0 =A0106 =A0 4134 =A0 =A04.5 =A0 =A0 23 =A0 1033 = =A0 =A05.2 =A0 48.8| ada0 > =A0 =A00 =A0 =A0131 =A0 =A0111 =A0 3784 =A0 =A04.2 =A0 =A0 19 =A0 1007 = =A0 =A04.0 =A0 47.6| ada1 > =A0 =A00 =A0 =A0 90 =A0 =A0 66 =A0 2219 =A0 =A04.5 =A0 =A0 24 =A0 1031 = =A0 =A05.1 =A0 31.7| ada2 > =A0 =A01 =A0 =A0 81 =A0 =A0 58 =A0 2007 =A0 =A04.6 =A0 =A0 22 =A0 1023 = =A0 =A02.3 =A0 28.1| ada3 > > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A01 =A0 =A0132 =A0 =A0104 =A0 4036 =A0 =A04.2 =A0 =A0 27 =A0 1129 = =A0 =A05.3 =A0 45.2| ada0 > =A0 =A00 =A0 =A0129 =A0 =A0103 =A0 3679 =A0 =A04.5 =A0 =A0 26 =A0 1115 = =A0 =A06.8 =A0 47.6| ada1 > =A0 =A01 =A0 =A0 91 =A0 =A0 61 =A0 2133 =A0 =A04.6 =A0 =A0 30 =A0 1129 = =A0 =A01.9 =A0 29.6| ada2 > =A0 =A00 =A0 =A0 81 =A0 =A0 56 =A0 1985 =A0 =A04.8 =A0 =A0 24 =A0 1102 = =A0 =A06.0 =A0 29.4| ada3 > > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 ms/= w =A0 %busy Name > =A0 =A01 =A0 =A0148 =A0 =A0108 =A0 4084 =A0 =A05.3 =A0 =A0 39 =A0 2511 = =A0 =A07.2 =A0 55.5| ada0 > =A0 =A01 =A0 =A0141 =A0 =A0104 =A0 3693 =A0 =A05.1 =A0 =A0 36 =A0 2505 = =A0 10.4 =A0 54.4| ada1 > =A0 =A01 =A0 =A0102 =A0 =A0 62 =A0 2112 =A0 =A05.6 =A0 =A0 39 =A0 2508 = =A0 =A05.5 =A0 35.4| ada2 > =A0 =A00 =A0 =A0 99 =A0 =A0 60 =A0 2064 =A0 =A06.0 =A0 =A0 39 =A0 2483 = =A0 =A03.7 =A0 36.1| ada3 This suggests (note that I said suggests) that there might be a slight difference in the data path speeds or physical media as someone else suggested; look at zpool iostat -v though before making a firm statement as to whether or not a drive is truly not performing to your assumed spec. gstat and zpool iostat -v suggest performance though -- they aren't the end-all-be-all for determining drive performance. If the latency numbers were high enough, I would suggest dd'ing out to the individual drives (i.e. remove the drive from the RAIDZ) to see if there's a noticeable discrepancy, as this can indicate a bad cable, backplane, or drive; from there I would start doing the physical swap routine and see if the issue moves with the drive or stays static with the controller channel and/or chassis slot. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:34:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A11106564A; Mon, 19 Dec 2011 17:34:09 +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 ED13C8FC1A; Mon, 19 Dec 2011 17:34:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA10851; Mon, 19 Dec 2011 19:34:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rch6C-000GBf-FP; Mon, 19 Dec 2011 19:34:04 +0200 Message-ID: <4EEF758C.5090904@FreeBSD.org> Date: Mon, 19 Dec 2011 19:34:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> <4EEF52E5.8020102@FreeBSD.org> <201112191611.15432.hselasky@c2i.net> In-Reply-To: <201112191611.15432.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:34:09 -0000 on 19/12/2011 17:11 Hans Petter Selasky said the following: > I will fix that. I see a missing wait there. Can I assume that we are allowed > to sleep from device_shutdown() and that system timers still work? I don't see any reason why either of these should be not true. Oh, and I see that you've already committed the change - thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 18:04:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6061065673; Mon, 19 Dec 2011 18:04:04 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 9C29D8FC0C; Mon, 19 Dec 2011 18:04:03 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBJI3mkp021354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 20:03:55 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Daniel Kalchev In-Reply-To: <4EEF488E.1030904@freebsd.org> Date: Mon, 19 Dec 2011 20:03:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> References: <4EEF488E.1030904@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:04:04 -0000 I have observed similar behavior, even more extreme on a spool with = dedup enabled. Is dedup enabled on this spool? Might be that the DDT tables somehow end up unevenly distributed to = disks. My observation was on a 6 disk raidz2. Daniel= From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 18:17:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 009221065675 for ; Mon, 19 Dec 2011 18:17:40 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm20.bullet.mail.ne1.yahoo.com (nm20.bullet.mail.ne1.yahoo.com [98.138.90.83]) by mx1.freebsd.org (Postfix) with SMTP id BAE618FC1A for ; Mon, 19 Dec 2011 18:17:39 +0000 (UTC) Received: from [98.138.90.48] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 18:17:39 -0000 Received: from [98.138.226.62] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 18:17:39 -0000 Received: from [127.0.0.1] by smtp213.mail.ne1.yahoo.com with NNFMP; 19 Dec 2011 18:17:39 -0000 X-Yahoo-Newman-Id: 108984.58477.bm@smtp213.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lbaIyusVM1lzv9pVpzn0s2MMlFJkYIVNhsHbESsUr9.Wa6w 390PsksyF3lsf5twOkW0_8H8YlcNP5rwjBfeEXZgZ81KR.5.nS5fbNc.3yGV OGKpt8CAOab0cbfkG5aKuqbuOsKQhIrwgE.cP3kk9UQUc2vCcgWyV26mhQrW UPUuol2BwrvcyNoLrH4PSJcxum2Yd0jSGpBs8P6oOLF8ylOBnxqCqJnhrtvp efIXAt7PcY4hOVit09yli980d11E7Dpa4sUcqvf8fL.rETKMfe73vx.arWBO pPSN0aKkY9ZdjzQrGHTnmGORYaDIlMONXsvoQGrBagfMajwGWoCkWU15uzOn lXk97tSidAr_31O5ttwWLkZm32tfEmB8Q4OiLpnE1FETSXtyY1SDOyg0vbWo 94UJ1v473dzPiA9Q- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp213.mail.ne1.yahoo.com with SMTP; 19 Dec 2011 10:17:38 -0800 PST Message-ID: <4EEF7FC0.8030801@freebsd.org> Date: Mon, 19 Dec 2011 19:17:36 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Olivier Smedts References: <4EEF488E.1030904@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:17:40 -0000 Am 19.12.2011 15:36, schrieb Olivier Smedts: > 2011/12/19 Stefan Esser : >> So: Can anybody reproduce this distribution requests? > > Hello, > > Stupid question, but are your drives all exactly the same ? I noticed > "ashift: 12" so I think you should have at least one 4k-sector drive, > are you sure they're not mixed with 512B per sector drives ? All drives are identical: at scbus3 target 0 lun 0 (ada0,pass2) at scbus4 target 0 lun 0 (ada1,pass3) at scbus5 target 0 lun 0 (ada2,pass4) at scbus6 target 0 lun 0 (ada3,pass5) These are 4KB sector drives. Everything is correctly aligned and all drives have identical partition (created by a script that was run once for each drive, so there is no risk of typoes leading to differences). Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:09:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA78106564A for ; Mon, 19 Dec 2011 19:09:03 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by mx1.freebsd.org (Postfix) with SMTP id 0306E8FC0A for ; Mon, 19 Dec 2011 19:09:02 +0000 (UTC) Received: from [98.139.212.152] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 18:56:05 -0000 Received: from [98.139.211.160] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 18:56:05 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 18:56:05 -0000 X-Yahoo-Newman-Id: 790478.17084.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oOD4608VM1kxG_WG2IlB9jQ4XE2n_quCNmxmmaRJWBimubf b386LqdH.Fua49Bj_w8uOFcT1Z7350T3SpXMU28Oji5zOXsPGJjMmOyURZMt TR36EhCDEILTH2TAIgoqLE2unIGtmfuZdxPaRbMpyQU7U2ig4kEUewUeeYou LBUmzybBIvxEt.ezY.b7U.8bJ19BAB8V4PiIQqzcEWbd1rp7jtYXpFuIiRxl 90BShb6ftTtlL67pO5xkWvW1yEgXN7c8vGpIyi7oqybHEMHrO19AmlNtwYqZ NkkDML4sJmvtuR7j.Ly6qM98x3rT0cB_OmhGtVmSeiUGxk15h.xrV5mudpAq rc2AN_cDQWbG28z8RsWSEsxxlBV7zsnj0INjkat17v847R_yhzWuRP2oR_e8 CDQHtZKAO_3HS0.c- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp217.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 10:56:05 -0800 PST Message-ID: <4EEF88C3.4010600@freebsd.org> Date: Mon, 19 Dec 2011 19:56:03 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Maloney References: <4EEF488E.1030904@freebsd.org> <4EEF5B5C.90905@brockmann-consult.de> In-Reply-To: <4EEF5B5C.90905@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:09:03 -0000 Am 19.12.2011 16:42, schrieb Peter Maloney: > On 12/19/2011 03:22 PM, Stefan Esser wrote: >> So: Can anybody reproduce this distribution requests? > I don't have a raidz1 machine, and no time to make you a special raidz1 > pool out of spare disks, but on my raidz2 I can only ever see unevenness > when a disk is bad, or between different vdevs. But you only have one vdev. Thanks for replying. In my previous raidz1 pool consisting of 3*1TB, one of the drives had to be replaced because it showed lots of recoverable errors when I initially created the pool. The effects where much more drastic than what I see now: Given identical request rates, the failed drive was 100% busy when the other drives had busy percentages in the one digit range. But the observed differences seem to be caused by a different rate of read requests issued towards the drives (the first two receive 30% of the reads, each, while the last two receive 20% each). And this ratio has been stable over months (I had already noticed this in summer, but did not have time to start a thread at that time). > Check is that your disks are identical (are they? we can only assume so > since you didn't say so). Yes, all 4 are identical. > Show us output from: > smartctl -i /dev/ada0 Model Family: SAMSUNG SpinPoint F4 EG (AFT) Device Model: SAMSUNG HD204UI Serial Number: S2H7JD1B116957 LU WWN Device Id: 5 0024e9 0049bee63 Firmware Version: 1AQ10001 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Mon Dec 19 19:23:36 2011 CET ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 067 067 025 Pre-fail Always - 10127 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 254 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2300 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 1 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 228 181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 621067 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 4 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 055 000 Old_age Always - 28 (Min/Max 15/48) 195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 2 223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 1 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 264 > smartctl -i /dev/ada1 Model Family: SAMSUNG SpinPoint F4 EG (AFT) Device Model: SAMSUNG HD204UI Serial Number: S2H7JD1B116947 LU WWN Device Id: 5 0024e9 0049bee49 Firmware Version: 1AQ10001 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Mon Dec 19 19:23:22 2011 CET ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 067 067 025 Pre-fail Always - 10096 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 255 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2316 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 1 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 231 181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 2175909 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 055 000 Old_age Always - 26 (Min/Max 16/47) 195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 1 223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 1 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 264 > smartctl -i /dev/ada2 Model Family: SAMSUNG SpinPoint F4 EG (AFT) Device Model: SAMSUNG HD204UI Serial Number: S2H7JD1B116956 LU WWN Device Id: 5 0024e9 0049bee60 Firmware Version: 1AQ10001 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Mon Dec 19 19:24:24 2011 CET 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 067 066 025 Pre-fail Always - 10254 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 246 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2300 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 227 181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 105259 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 056 000 Old_age Always - 28 (Min/Max 16/45) 195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 0 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 256 > smartctl -i /dev/ada3 Model Family: SAMSUNG SpinPoint F4 EG (AFT) Device Model: SAMSUNG HD204UI Serial Number: S2H7JD1B116946 LU WWN Device Id: 5 0024e9 0049bee47 Firmware Version: 1AQ10001 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Mon Dec 19 19:24:55 2011 CET 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 066 066 025 Pre-fail Always - 10472 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 250 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2302 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 227 181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 239254 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 055 000 Old_age Always - 27 (Min/Max 16/47) 195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 2 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 259 > Since your tests show read ms/r to be pretty even, I guess your disks > are not broken. But the ms/w is slightly different. So I think it seems > that the first 2 disks are slower for writing (someone once said that My interpretation is, that the first two have higher write latencies since they receive more read requests. > refurbished disks are like this, even if identical), or the hard disk > controller ports they use are slower. For example, maybe your > motherboard has 6 ports, and you plugged disks 1,2,3 into port 1,2,3 and > disk 4 into port 5. Disk 3 and 4 would have their own channel, but disk > 1 and 2 share one. This is an ICH10 and the drives are connected to SATA II channels (the SATA III channels are reserved for a planned SSD cache). > So if the disks are identical, I would guess your hard disk controller > is to blame. To test this, first back it up. Then *fix your setup by > using labels*. ie. use gpt/somelabel0 or gptid/....... rather than > ada0p2. Check "ls /dev/gpt*" output for options on what labels you have > already. Then try swapping disks around to see if the load changes. Make > sure to back up... The drives are lalready abelled and I can easily modify the pool to refer to GPT labels. But swapping drives should not cause any harm in ZFS, whether labels are device names are used (the drives in the pool are identified by their GUID). > Swapping disks (or even removing one depending on controller, etc. when > it fails) without labels can be bad. Yes, I know (having seen my first Unix system more than 30 years ago). I'll re-import the drives with "zpool import -d /dev/gpt ..." but need to boot from an alternate boot device first. > eg. > You have ada1 ada2 ada3 ada4. > Someone spills coffee on ada2; it fries and cannot be detected anymore, > and you reboot. > Now you have ada1 ada2 ada3. > Then things are usually still fine (even though ada3 is now ada2 and > ada4 is now ada3, because there is some zfs superblock stuff to keep > track of things), but if you also had an ada5 that was not part of the > pool, or was a spare or a log or something other than another disk in > the same vdev as ada1, etc., bad things happen when it becomes ada4. > Unfortunately, I don't know exactly what people do to cause the "bad > things" that happen. When this happened to me, it just said my pool was > faulted or degraded or something, and set a disk or two to UNAVAIL or > FAULTED. I don't remember it automatically resilvering them, but when I > read about these problems, I think it seems like some disks were > resilvered afterwards. The recovery from partial pool failures and the collection of drives to form a pool has been modified several times in the last two years and should be quite robust by now. One thing to look out for is to not copy a pool to new disk drives (I used to have 3*1TB, copied to 4*2TB) and later connect a drive from the original pool with its ZFS metadata intact at the end of the drive (I had cleared the first 1MB, but not the last 1MB). This causes confusion, if the name of the pool has not changed. But other than that, I do not see much risk in ZFS pools built from /dev nodes. > And last thing I can think of is to make sure your partitions are > aligned, and identical. Show us output from: > gpart show They have all been created by a script that takes the device node name as parameter and thus are identical. => 34 3907029101 ada0 GPT (1.8T) 34 30 - free - (15k) 64 192 1 freebsd-boot (96k) 256 3565158400 2 freebsd-zfs (1.7T) 3565158656 341870479 3 freebsd (163G) => 34 3907029101 ada1 GPT (1.8T) 34 30 - free - (15k) 64 192 1 freebsd-boot (96k) 256 3565158400 2 freebsd-zfs (1.7T) 3565158656 341870479 3 freebsd (163G) => 34 3907029101 ada2 GPT (1.8T) 34 30 - free - (15k) 64 192 1 freebsd-boot (96k) 256 3565158400 2 freebsd-zfs (1.7T) 3565158656 341870479 3 freebsd (163G) => 34 3907029101 ada3 GPT (1.8T) 34 30 - free - (15k) 64 192 1 freebsd-boot (96k) 256 3565158400 2 freebsd-zfs (1.7T) 3565158656 1792 - free - (896k) 3565160448 341868544 3 freebsd-swap (163G) 3907028992 143 - free - (71k) There is an unused 10% at the end of each device, and I have recently made ada3p3 a swap device, just to be able to collect kernel dumps (no swpa is actually used; this is an 8GB RAM machine with 6GB assigned to ARC and mostly low load). Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:57:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAF941065670 for ; Mon, 19 Dec 2011 19:57:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC0F8FC08 for ; Mon, 19 Dec 2011 19:57:50 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBJJpc2O051219 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 12:51:42 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 19 Dec 2011 12:50:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <554C031E-531F-4A1F-B315-8F61D33D70A7@bsdimp.com> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> To: Lyndon Nerenberg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 19 Dec 2011 12:51:43 -0700 (MST) Cc: freebsd-current@FreeBSD.org, Ryan Stone Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:57:51 -0000 On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote: >> Using profiled libs and gprof to profile your code has been obsolete >> in FreeBSD on i386 and amd64 for over six years now. >=20 > Funny, it still seems to work on my systems. Worked for me last time I tried as well. Was able to find the problems = w/o a hassle. turning them off is plain wrong. Can we at least ship profiled libraries for the release? Warner From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:58:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F7810656D0; Mon, 19 Dec 2011 19:58:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA858FC0C; Mon, 19 Dec 2011 19:58:01 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBJJlLfb051153 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 12:47:24 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111202223716.GA35140@troutmask.apl.washington.edu> Date: Mon, 19 Dec 2011 12:46:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A7C9A6F-34F6-4BEB-AFE7-D6D7C50D7AB2@bsdimp.com> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> <20111202223716.GA35140@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 19 Dec 2011 12:47:25 -0700 (MST) Cc: freebsd-current@FreeBSD.org, Doug Barton , Max Khon Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:58:01 -0000 On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote: > On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote: >>=20 >> The most important thing is to have reasonable defaults. >> Having WITH_PROFILE by default does not seem to be a reasonable = default to me. >>=20 Now all users that want to profile anything need to build their own = custom FreeBSD? That seems even more nuts to me. Warner From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:25:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B13010656D5 for ; Mon, 19 Dec 2011 20:25:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 447768FC1C for ; Mon, 19 Dec 2011 20:25:33 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so7492882vbb.13 for ; Mon, 19 Dec 2011 12:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9uwecGt57vANjoG94Nid+7szHlJyGjOAFWWMFe9JEI8=; b=EnWltmi3/rzzMDvX5623REUVbYSdNhWCQwic3smcjPuIHxG2L2iFDWwc/IXoUh7lAZ NOqBjQcHWyHBDCeczB517jz7LYDnTojRWIyhTecnZuqNkoAECbqKXaJSYxOgpJ7awWo0 LOfY1p/AksAKJPnDsy6VvHNPCeDDbgbJ5XW8c= MIME-Version: 1.0 Received: by 10.52.90.164 with SMTP id bx4mr12247122vdb.128.1324326333553; Mon, 19 Dec 2011 12:25:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Mon, 19 Dec 2011 12:25:33 -0800 (PST) In-Reply-To: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Mon, 19 Dec 2011 12:25:33 -0800 X-Google-Sender-Auth: SGj38MjhNtbxtdZFgg30PxwivfM Message-ID: From: Adrian Chadd To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:25:34 -0000 Hi, Hm, so this lets us create a virtualbox image from what, a set of install tarballs? Or /usr/src build? Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:31:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47B50106566B for ; Mon, 19 Dec 2011 20:31:52 +0000 (UTC) (envelope-from yerenkow@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 E11108FC0A for ; Mon, 19 Dec 2011 20:31:51 +0000 (UTC) Received: by ggnp1 with SMTP id p1so6315475ggn.13 for ; Mon, 19 Dec 2011 12:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bj5wJrU9UJGAdQiyX4hbEavCMqZc/kvApTqUn+ULOY4=; b=sd8+5lWjlnHceqaftv9mz1f5MzDtgVphfM8q+IvhjCgcTobUWvWhmqvai+iXJjsWCV jM6a5wPgTTLIjdE1lHqTj5EAU9gxLRrp8AbZtcdBn7bCSjVMrhumgwo+Z/prhd9I2ENA Gco0D56cKttLB2cysvvu1bRRLaqwtkhUOCnTg= MIME-Version: 1.0 Received: by 10.182.112.9 with SMTP id im9mr3198408obb.74.1324326711133; Mon, 19 Dec 2011 12:31:51 -0800 (PST) Received: by 10.182.150.70 with HTTP; Mon, 19 Dec 2011 12:31:51 -0800 (PST) In-Reply-To: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Mon, 19 Dec 2011 22:31:51 +0200 Message-ID: From: Alexander Yerenkow To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:31:52 -0000 2011/12/19 Adrian Chadd > Hi, > > Hm, so this lets us create a virtualbox image from what, a set of > install tarballs? Or /usr/src build? > > I'm using cross-build and installation from sources dir (which is after that got svn-up'ed and all goes again). It shouldn't be complex to install to image from installation media and/or tarballs, but mine main idea is to have rolling image for making some automated tests. Currently I'm establishing building and providing images scheme, will do images with KMS+small graphical programs, with qt+unstable KDE, and probably with BHyVe. I think that's most useful setups currently. And maybe some image for benchmarking :) > > Adrian > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:36:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1F71065689 for ; Mon, 19 Dec 2011 20:36:51 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm35-vm0.bullet.mail.bf1.yahoo.com (nm35-vm0.bullet.mail.bf1.yahoo.com [72.30.238.72]) by mx1.freebsd.org (Postfix) with SMTP id 4637A8FC1E for ; Mon, 19 Dec 2011 20:36:50 +0000 (UTC) Received: from [98.139.212.148] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:36:50 -0000 Received: from [98.139.211.200] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:36:50 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:36:50 -0000 X-Yahoo-Newman-Id: 402535.36399.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oDWwmAoVM1lwQB8CY4o9kk_W3Ay050_TjuSnOEAENw361qb ery.MflUvfYgz7g7CerI2ZZa3632Ah6i1PXfSwe.i_haRlnJqQ7UUHb8T_ic I7iboDchrpgYCGY4tiOdQ6hJke9U4dvTiuUu_1VcohLyZCHvAwpJWXLBR1Vf KbvjTyeiLMve_GB7EF3whdFibxNEjolp.8DflUhSUMgqRvi5bTNZZmhqRrJK nQqJE8ktNg6QFpZtHgjK1PtWdlwweHKJykgQ8Z1kxG2dCBb9DT_1.V21raLW 1Z1KuSPN0NfRAm2C8HKxCrCloYXiwhaYKKfdAlOxBSFBrqr5OdVHwvKIbwJw yjSDUYP61D2mS4_nQZm54NXy4fvqTiivddIstfSZJ6PyD7ilntIYAA_OIYiJ I64NuoekpLYht8i4- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp209.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 12:36:49 -0800 PST Message-ID: <4EEFA05E.7090507@freebsd.org> Date: Mon, 19 Dec 2011 21:36:46 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dan Nelson References: <4EEF488E.1030904@freebsd.org> <20111219162220.GK53453@dan.emsphone.com> In-Reply-To: <20111219162220.GK53453@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:36:51 -0000 Am 19.12.2011 17:22, schrieb Dan Nelson: > In the last episode (Dec 19), Stefan Esser said: >> for quite some time I have observed an uneven distribution of load between >> drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of a longer >> log of 10 second averages logged with gstat: >> >> dT: 10.001s w: 10.000s filter: ^a?da?.$ >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 >> 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 >> 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 >> 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 > [...] >> zpool status -v >> pool: raid1 >> state: ONLINE >> scan: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> raid1 ONLINE 0 0 0 >> raidz1-0 ONLINE 0 0 0 >> ada0p2 ONLINE 0 0 0 >> ada1p2 ONLINE 0 0 0 >> ada2p2 ONLINE 0 0 0 >> ada3p2 ONLINE 0 0 0 > > Any read from your raidz device will hit three disks (the checksum is > applied across the stripe, not on each block, so a full stripe is always > read) so I think your extra IOs are coming from somewhere else. > > What's on p1 on these disks? Could that be the cause of your extra I/Os? > Does "zpool iostat -v 10" give you even numbers across all disks? This is a ZFS only system. The first partition on each drive holds just the gptzfsloader. pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- raid1 4.41T 2.21T 139 72 12.3M 818K raidz1 4.41T 2.21T 139 72 12.3M 818K ada0p2 - - 114 17 4.24M 332K ada1p2 - - 106 15 3.82M 305K ada2p2 - - 65 20 2.09M 337K ada3p2 - - 58 18 2.18M 329K capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- raid1 4.41T 2.21T 150 45 12.8M 751K raidz1 4.41T 2.21T 150 45 12.8M 751K ada0p2 - - 113 14 4.34M 294K ada1p2 - - 111 14 3.94M 277K ada2p2 - - 62 16 2.23M 294K ada3p2 - - 68 14 2.32M 277K ---------- ----- ----- ----- ----- ----- ----- capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- raid1 4.41T 2.21T 157 86 12.3M 6.41M raidz1 4.41T 2.21T 157 86 12.3M 6.41M ada0p2 - - 119 39 4.21M 2.24M ada1p2 - - 106 31 3.78M 2.21M ada2p2 - - 81 59 2.23M 2.23M ada3p2 - - 57 39 2.06M 2.22M ---------- ----- ----- ----- ----- ----- ----- capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- raid1 4.41T 2.21T 187 45 14.2M 1.04M raidz1 4.41T 2.21T 187 45 14.2M 1.04M ada0p2 - - 117 13 4.27M 398K ada1p2 - - 120 12 4.01M 384K ada2p2 - - 89 12 2.97M 403K ada3p2 - - 85 13 2.91M 386K ---------- ----- ----- ----- ----- ----- ----- The same difference of read operations per second as shown by gstat ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:40:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3589D106566C for ; Mon, 19 Dec 2011 20:40:35 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7B08FC0C for ; Mon, 19 Dec 2011 20:40:34 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2QV8d370WOpHNjtl+s= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-4d06f6f1.pool.mediaWays.net [77.6.246.241]) by smtp.strato.de (cohen mo51) (RZmta 26.15 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a03c31nBJJcI94 ; Mon, 19 Dec 2011 21:40:14 +0100 (MET) Message-ID: <4EEFA12D.2070803@brockmann-consult.de> Date: Mon, 19 Dec 2011 21:40:13 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Reifenberger References: <4EEF488E.1030904@freebsd.org> <4EEF5B5C.90905@brockmann-consult.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:40:35 -0000 Am 19.12.2011 17:48, schrieb Michael Reifenberger: > On Mon, 19 Dec 2011, Peter Maloney wrote: > >> Swapping disks (or even removing one depending on controller, etc. when >> it fails) without labels can be bad. >> eg. > > Since ZFS uses (and searches for) its own UUID partition signatures s > disk wapping shouldn't matter as long enough disks are found. > > Set vfs.zfs.debug=1 during boot to watch what is searched for. > > Bye/2 > --- > Michael Reifenberger > Michael@Reifenberger.com > http://www.Reifenberger.com > Thanks for the info. But I am confused by it, because when my disks moved around randomly on reboot, it really did mess things up. The first few times it happened, there was no issue, but when a spare took the place of a pool disk, it messed things up. I can see the UUIDs when I look at zdb output, so I really have no idea why it messed things up. ... but it did, so I will always caution people anyway. I can't point you to any relevant lines of code that cause the problem, but I know it can happen... and it will when you least expect it. ;) And I also see the opposite... people talking about their very old pools, with many disks exchanged, and wonder why mine was so easily messed up and theirs survived so long without labels. I just assumed it was the way the controller arranged the disks. (and by the way, mine now orders the disks perfectly consistently now that it is in IT mode, not mostly random like before... could be a factor) I am always very busy, but when I get the chance, it shouldn't take too long, so I will try to recreate it on a virtual machine and try vfs.zfs.debug=1.Thanks for the suggestion. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:42:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC33B106566B for ; Mon, 19 Dec 2011 20:42:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) by mx1.freebsd.org (Postfix) with SMTP id 89D9A8FC19 for ; Mon, 19 Dec 2011 20:42:56 +0000 (UTC) Received: from [98.139.212.145] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:42:55 -0000 Received: from [98.139.213.7] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:42:55 -0000 Received: from [127.0.0.1] by smtp107.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:42:55 -0000 X-Yahoo-Newman-Id: 842931.99377.bm@smtp107.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vcKI.vYVM1mt9XADgJzJryq6KBAePBJWfQKblOV3vd36GaC Xbzc.cy0oVfj6PrvWhroKaldRN6vIg5nRx_tzAomsC91YGlpEJhtD.7HUq0U 3sR42tt3VBNVdMvDeUt1KavC1f87QT_D8FpgUrRCrlms6TphgVfa27zvfQWQ u0FICzuLk_kl17MPO1Qra1TN8hB2LtH9dO.hpLX.sVYaJx3aa3TW6Hk4Sgoy OdHUI2qNYLkzJ89sqcb8IvqyPx8hgXZgl5iFST8MOu30Inyl0woXUP2hiMor x8lqxWuwBwSOleVGfBp3FlHbvSrSQ0yIevOMRoMUYtTOC104dcOp75iAhkkY wwhH1ibG9Z034uIr12j4MNU9ms.nKobCouvxkbuKp2zTVsy58_ZmEdts8f.L QunIFEU5VzFqsCWE- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp107.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 12:42:55 -0800 PST Message-ID: <4EEFA1CD.4040001@freebsd.org> Date: Mon, 19 Dec 2011 21:42:53 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Reifenberger References: <4EEF488E.1030904@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:42:58 -0000 Am 19.12.2011 17:36, schrieb Michael Reifenberger: > Hi, > a quick test using `dd if=/dev/zero of=/test ...` shows: > > dT: 10.004s w: 10.000s filter: ^a?da?.$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 378 0 0 12.5 376 36414 11.9 60.6| ada0 > 0 380 0 0 12.2 378 36501 11.8 60.0| ada1 > 0 382 0 0 7.7 380 36847 11.6 59.2| ada2 > 0 375 0 0 7.4 374 36164 9.6 51.3| ada3 > 0 377 0 1 10.2 375 36325 10.1 53.3| ada4 > 10 391 0 0 39.3 389 38064 15.7 80.2| ada5 Thanks! There are surprising differences (ada5 has a queue length of 10 and much higher latency than the other drives). > Seems to be sufficiently equally distributed for a life system... Hmmm, 50%-55% busy on ada3 and ada4 contrasts with 80% busy on ada5. > zpool status shows: > ... > NAME STATE READ WRITE CKSUM > boot ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > ada1p3 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > ada3p3 ONLINE 0 0 0 > ada4p3 ONLINE 0 0 0 > ada5p3 ONLINE 0 0 0 > ... > > The only cases I've seen (and expected to see) unequal load > distributions on ZFS was after extending a nearly full four disk mirror > pool by additional two disks. In my case the pool was created from disk drives with nearly identical serial numbers in its current configuration. Some of the drives have a few more power-on hours, since I performed some tests with them, before moving all data from the old pool the new one, but else everything should be symmetric. Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:54:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B0F21065677 for ; Mon, 19 Dec 2011 20:54:14 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by mx1.freebsd.org (Postfix) with SMTP id 2B0048FC1D for ; Mon, 19 Dec 2011 20:54:13 +0000 (UTC) Received: from [98.139.212.153] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:54:13 -0000 Received: from [98.139.211.204] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:54:13 -0000 Received: from [127.0.0.1] by smtp213.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 20:54:13 -0000 X-Yahoo-Newman-Id: 315247.55574.bm@smtp213.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DaM2Lv8VM1n2fdLoMLztGDCUd8eSMhPuUgKfFxRkjhC40T3 .3pQwD0uaQ0tuSWKvC8PvPcWiXbFws0sTi5PnKfgXleACG5lmuWEHmEBgCKL 7Wk_MheoC3Wa.VGxu7pkcqTs.9dnWoxIYphCiQb6_BNXr0q_mVljezJPdjd1 rbtc0zdO4UBLCsYQS2K4sG5qJcwJCnND7O5Cxuxty_e2XZ08SlunYaS6ORjW RoczNOqXoKkKDLqVDtbviZqrWnlkBlRp7q3IlAFdNsJeoPh01zrrdZRji69e 9kJIzMlr2XJWamWm4w1FdQcb5aK0D3C0I4SWPpxFmzQJrfJgUzXtWvYDt9HE RumuBknZu6vLXnV3sltmE3wNuS8sSos6chZJ8KcjGc0OyV0oYCOvw8qbnt1v m3RmcdW6m0WtSEPww X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp213.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 12:54:12 -0800 PST Message-ID: <4EEFA472.5020509@freebsd.org> Date: Mon, 19 Dec 2011 21:54:10 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EEF488E.1030904@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:54:14 -0000 Am 19.12.2011 18:05, schrieb Garrett Cooper: > On Mon, Dec 19, 2011 at 6:22 AM, Stefan Esser wrote: >> Hi ZFS users, >> >> for quite some time I have observed an uneven distribution of load >> between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt of >> a longer log of 10 second averages logged with gstat: >> >> dT: 10.001s w: 10.000s filter: ^a?da?.$ >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 >> 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 >> 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 >> 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 >> >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 1 132 104 4036 4.2 27 1129 5.3 45.2| ada0 >> 0 129 103 3679 4.5 26 1115 6.8 47.6| ada1 >> 1 91 61 2133 4.6 30 1129 1.9 29.6| ada2 >> 0 81 56 1985 4.8 24 1102 6.0 29.4| ada3 >> >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 1 148 108 4084 5.3 39 2511 7.2 55.5| ada0 >> 1 141 104 3693 5.1 36 2505 10.4 54.4| ada1 >> 1 102 62 2112 5.6 39 2508 5.5 35.4| ada2 >> 0 99 60 2064 6.0 39 2483 3.7 36.1| ada3 > > This suggests (note that I said suggests) that there might be a slight > difference in the data path speeds or physical media as someone else > suggested; look at zpool iostat -v though before making a > firm statement as to whether or not a drive is truly not performing to > your assumed spec. gstat and zpool iostat -v suggest performance > though -- they aren't the end-all-be-all for determining drive > performance. I doubt there is a difference in the data path speeds, since all drives are connected to the SATA II ports of an Intel H67 chip. The drives seem to perform equally well, just with a ratio of read requests of 30% / 30% / 20% / 20% for ada0 .. ada3. But neither queue length nor command latencies indicate a problem or differences in the drives. It seems that a different number of commands is scheduled for 2 of the 4 drives, compared to the other 2, and that scheduling should be part of the ZFS code. I'm quite convinced, that neither the drives nor the other hardware plays a role, but I'll follow the suggestion to swap drives between controller ports and to observe whether the increased read load moves with the drives (indicating something on disk causes the anomaly) or stays with the SATA ports (indicating that lower numbered ports see higher load). > If the latency numbers were high enough, I would suggest dd'ing out to > the individual drives (i.e. remove the drive from the RAIDZ) to see if > there's a noticeable discrepancy, as this can indicate a bad cable, > backplane, or drive; from there I would start doing the physical swap > routine and see if the issue moves with the drive or stays static with > the controller channel and/or chassis slot. I do not expect a hardware problem, since command latencies are very similar over all drives, despite the higher read load on some of them. These are more busy by exactly the factor to be expected by only the higher command rate. But it seems that others do not observe the asymmetric distribution of requests, which makes me wonder whether I happen to have meta data arranged in such a way that it is always read from ada0 or ada1, but not (or rarely) from ada2 or ada3. That could explain it, including the fact that raidz1 over other numbers of drives 8e.g. 3 or 6) apparently show a much more symmetric distribution of read requests. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:54:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A634F106577C; Mon, 19 Dec 2011 20:54:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 78D098FC15; Mon, 19 Dec 2011 20:54:30 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c128:98f8:6426:c74d] (unknown [IPv6:2001:7b8:3a7:0:c128:98f8:6426:c74d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 969F75C37; Mon, 19 Dec 2011 21:54:29 +0100 (CET) Message-ID: <4EEFA482.8060102@FreeBSD.org> Date: Mon, 19 Dec 2011 21:54:26 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , freebsd-current Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:54:31 -0000 On 2011-12-19 17:36, Garrett Cooper wrote: > On Dec 19, 2011, at 5:24 AM, Dimitry Andric wrote: >> On 2011-12-19 10:17, Doug Barton wrote: >>> I updated to r228700 from 228122 and dhclient exits immediately saying >>> that em0 doesn't exist. However ifconfig seems to disagree: ... >> I saw this too, when my kernel and userland were out of sync (e.g. just >> after installing a new kernel, and before installworld). I suspect it >> is caused by the changes in r228571, which cause old ifconfig and >> dhclient to not recognize any interfaces. I'm not 100% sure though. > This makes sense because the structs that describe addresses changed recently. It may make sense, but it is very annoying when you want to installworld over NFS, or have any other network access before or during installation. :( From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:00:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC18C106566B; Mon, 19 Dec 2011 21:00:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C99C8FC14; Mon, 19 Dec 2011 21:00:22 +0000 (UTC) Received: by ghrr16 with SMTP id r16so666298ghr.13 for ; Mon, 19 Dec 2011 13:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=D0iiDIy7FaONMN0V90hOEylzyTF9FhBpmlAk3Ll6iyI=; b=eglpe5F63MeBru5e5Busycmq+Y/My03TA9z8RPsm6sPTsze3jmuNsWY1fFu2BKzQI+ 4D2Y5cOh0jEsFprnicDdkDMhpZc45uSfAaan0PYZMJQBj+lmFpQK8qPJqL5Qefh+yQm+ IaknPDugt/QijC8FUbUnBuV7B7UEmj4opMtwE= Received: by 10.101.115.18 with SMTP id s18mr9451444anm.40.1324328421522; Mon, 19 Dec 2011 13:00:21 -0800 (PST) Received: from kruse-111.3.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id i67sm31914220yhm.16.2011.12.19.13.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 13:00:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4EEFA472.5020509@freebsd.org> Date: Mon, 19 Dec 2011 13:00:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0AE9C160-81EC-4A41-985B-EF63E4B0CD9B@gmail.com> References: <4EEF488E.1030904@freebsd.org> <4EEFA472.5020509@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:00:23 -0000 On Dec 19, 2011, at 12:54 PM, Stefan Esser wrote: > Am 19.12.2011 18:05, schrieb Garrett Cooper: >> On Mon, Dec 19, 2011 at 6:22 AM, Stefan Esser wrote: >>> Hi ZFS users, >>>=20 >>> for quite some time I have observed an uneven distribution of load >>> between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt = of >>> a longer log of 10 second averages logged with gstat: >>>=20 >>> dT: 10.001s w: 10.000s filter: ^a?da?.$ >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >>> 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 >>> 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 >>> 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 >>> 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 >>>=20 >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >>> 1 132 104 4036 4.2 27 1129 5.3 45.2| ada0 >>> 0 129 103 3679 4.5 26 1115 6.8 47.6| ada1 >>> 1 91 61 2133 4.6 30 1129 1.9 29.6| ada2 >>> 0 81 56 1985 4.8 24 1102 6.0 29.4| ada3 >>>=20 >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >>> 1 148 108 4084 5.3 39 2511 7.2 55.5| ada0 >>> 1 141 104 3693 5.1 36 2505 10.4 54.4| ada1 >>> 1 102 62 2112 5.6 39 2508 5.5 35.4| ada2 >>> 0 99 60 2064 6.0 39 2483 3.7 36.1| ada3 >>=20 >> This suggests (note that I said suggests) that there might be a = slight >> difference in the data path speeds or physical media as someone else >> suggested; look at zpool iostat -v though before making a >> firm statement as to whether or not a drive is truly not performing = to >> your assumed spec. gstat and zpool iostat -v suggest performance >> though -- they aren't the end-all-be-all for determining drive >> performance. >=20 > I doubt there is a difference in the data path speeds, since all = drives > are connected to the SATA II ports of an Intel H67 chip. >=20 > The drives seem to perform equally well, just with a ratio of read > requests of 30% / 30% / 20% / 20% for ada0 .. ada3. But neither queue > length nor command latencies indicate a problem or differences in the > drives. It seems that a different number of commands is scheduled for = 2 > of the 4 drives, compared to the other 2, and that scheduling should = be > part of the ZFS code. I'm quite convinced, that neither the drives nor > the other hardware plays a role, but I'll follow the suggestion to = swap > drives between controller ports and to observe whether the increased > read load moves with the drives (indicating something on disk causes = the > anomaly) or stays with the SATA ports (indicating that lower numbered > ports see higher load). >=20 >> If the latency numbers were high enough, I would suggest dd'ing out = to >> the individual drives (i.e. remove the drive from the RAIDZ) to see = if >> there's a noticeable discrepancy, as this can indicate a bad cable, >> backplane, or drive; from there I would start doing the physical swap >> routine and see if the issue moves with the drive or stays static = with >> the controller channel and/or chassis slot. >=20 > I do not expect a hardware problem, since command latencies are very > similar over all drives, despite the higher read load on some of them. > These are more busy by exactly the factor to be expected by only the > higher command rate. >=20 > But it seems that others do not observe the asymmetric distribution of > requests, which makes me wonder whether I happen to have meta data > arranged in such a way that it is always read from ada0 or ada1, but = not > (or rarely) from ada2 or ada3. That could explain it, including the = fact > that raidz1 over other numbers of drives 8e.g. 3 or 6) apparently show = a > much more symmetric distribution of read requests. Basic question: does one set of drives vibrate differently than the = other set? -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:00:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0591065675 for ; Mon, 19 Dec 2011 21:00:23 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm12.bullet.mail.bf1.yahoo.com (nm12.bullet.mail.bf1.yahoo.com [98.139.212.171]) by mx1.freebsd.org (Postfix) with SMTP id 776538FC15 for ; Mon, 19 Dec 2011 21:00:23 +0000 (UTC) Received: from [98.139.212.146] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:00:22 -0000 Received: from [98.139.213.15] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:00:22 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:00:22 -0000 X-Yahoo-Newman-Id: 591539.5237.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4VXzduwVM1lvKFUnABLpb.zdxRUFlbQhXuwi5r2GxkLzQo5 QuG2Pr2iSI9oP8x_bOax3blTtg_ftA4tsxoGY7QvBtjRkpFAyrzCdUZpciSR BsY9UsTULR6tS4YrALt6OlrF8EgO4LYypYdEmKVmN_BgoepcX9JtTMNhygiT 4m4uvJEanF5qeT4VZhG6iOLkmgYXQBkBdTyX2JVYzFRXH8aNrctcxdGGWxCU 6FVP4pDaRqqR_4V06wvk66OxN04ettoCxHr.l7ZUYBdcGCprmEa8QSI6NDwu urUHv6VmgYkjU8bT5rAQ8onwjaWhRyHIL6WvBclYm06t8Ke1Ce1XDL7UtBfV rcFe_11aN0.LilkD8ebQ0ee86wNqMOXcwyKh_YTOJV94tMwAP3nHZ04eQ_oA vHVN6_h7aA9FAmhw3 X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp115.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 13:00:22 -0800 PST Message-ID: <4EEFA5E4.9070803@freebsd.org> Date: Mon, 19 Dec 2011 22:00:20 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Daniel Kalchev References: <4EEF488E.1030904@freebsd.org> <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> In-Reply-To: <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:00:24 -0000 Am 19.12.2011 19:03, schrieb Daniel Kalchev: > I have observed similar behavior, even more extreme on a spool with dedup enabled. Is dedup enabled on this spool? Thank you for the report! Well, I had dedup enabled for a few short tests. But since I have got "only" 8GB of RAM and dedup seems to require an order of magnitude more to be working well, I switched dedup off again after a few hours. > Might be that the DDT tables somehow end up unevenly distributed to disks. My observation was on a 6 disk raidz2. Hmmm, there was another report of even distribution of load on a 6 disk raidz1 (but in fact, in that case the first half seems to have got some 10% to 15 higher load than the second half; the sixth drive showed quite different queue length and latencies and I think these might be caused either by a defect (soft-errors) or another partition being actively used only on that drive). Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:07:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63677106566C; Mon, 19 Dec 2011 21:07:50 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id DFEEF8FC0A; Mon, 19 Dec 2011 21:07:49 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBJL7b0Q021839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 23:07:42 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Daniel Kalchev In-Reply-To: <4EEFA5E4.9070803@freebsd.org> Date: Mon, 19 Dec 2011 23:07:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEF488E.1030904@freebsd.org> <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> <4EEFA5E4.9070803@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:07:50 -0000 On Dec 19, 2011, at 11:00 PM, Stefan Esser wrote: > Am 19.12.2011 19:03, schrieb Daniel Kalchev: >> I have observed similar behavior, even more extreme on a spool with = dedup enabled. Is dedup enabled on this spool? >=20 > Thank you for the report! >=20 > Well, I had dedup enabled for a few short tests. But since I have got > "only" 8GB of RAM and dedup seems to require an order of magnitude = more > to be working well, I switched dedup off again after a few hours. You will need to get rid of the DDT, as those are read nevertheless even = with dedup (already) disabled. The tables refer to already deduped data. In my case, I had about 2-3TB of deduced data, with 24GB RAM. There was = no shortage of RAM and I could not confirm that ARC is full.. but = somehow the pool was placing heavy read on one or two disks only (all = others, nearly idle) -- apparently many small size reads. I resolved my issue by copying the data to a newly created filesystem in = the same pool -- luckily there was enough space available, then removing = the 'deduped' filesystems. That last operation was particularly slow and at one time I had = spontaneous reboot -- the pool was 'impossible to mount', and as weird = as it sounds, I had 'out of swap space' killing the 'zpool list' = process. I let it sit for few hours, until it has cleared itself. I/O in that pool is back to normal now. There is something terribly wrong with the dedup code. Well, if your test data is not valuable, you can just delete it. :) Daniel From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:14:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B36F51065670; Mon, 19 Dec 2011 21:14:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBE38FC12; Mon, 19 Dec 2011 21:14:51 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2959428obb.13 for ; Mon, 19 Dec 2011 13:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9t20RZ7VdM7HbT6m2wvypFO3PNnpyFwauSGfkYkpKlE=; b=aIh0KyDZ/jPzpiWxvyLQL+4X2Z2ydb/TRpbF8K7ceZGH7y2Qb7RP9v4l4O+i48ZL0c kS55aONaO2xpcWUu78FJJuQCgoUrH5jAGoWANTGxWst7hv8mnsx0KcCIQko13HcCYlrX RRiZo1JSYrSHbaplEkdeIst0BYxUmXg0pdYBs= MIME-Version: 1.0 Received: by 10.182.73.42 with SMTP id i10mr11208633obv.76.1324329290959; Mon, 19 Dec 2011 13:14:50 -0800 (PST) Received: by 10.182.62.227 with HTTP; Mon, 19 Dec 2011 13:14:50 -0800 (PST) In-Reply-To: References: <4EEF488E.1030904@freebsd.org> <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> <4EEFA5E4.9070803@freebsd.org> Date: Mon, 19 Dec 2011 13:14:50 -0800 Message-ID: From: Garrett Cooper To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:14:51 -0000 On Mon, Dec 19, 2011 at 1:07 PM, Daniel Kalchev wrote: > > On Dec 19, 2011, at 11:00 PM, Stefan Esser wrote: > >> Am 19.12.2011 19:03, schrieb Daniel Kalchev: >>> I have observed similar behavior, even more extreme on a spool with ded= up enabled. Is dedup enabled on this spool? >> >> Thank you for the report! >> >> Well, I had dedup enabled for a few short tests. But since I have got >> "only" 8GB of RAM and dedup seems to require an order of magnitude more >> to be working well, I switched dedup off again after a few hours. > > You will need to get rid of the DDT, as those are read nevertheless even = with dedup (already) disabled. The tables refer to already deduped data. > > In my case, I had about 2-3TB of deduced data, with 24GB RAM. There was n= o shortage of RAM and I could not confirm that ARC is full.. but somehow th= e pool was placing heavy read on one or two disks only (all others, nearly = idle) -- apparently many small size reads. > > I resolved my issue by copying the data to a newly created filesystem in = the same pool -- luckily there was enough space available, then removing th= e 'deduped' filesystems. > > That last operation was particularly slow and at one time I had spontaneo= us reboot -- the pool was 'impossible to mount', and as weird as it sounds,= I had 'out of swap space' killing the 'zpool list' process. > I let it sit for few hours, until it has cleared itself. > > I/O in that pool is back to normal now. > > There is something terribly wrong with the dedup code. Dedup in the ZFS manual claims that it needs 2GB of memory per TB of data, but in reality it's closer to 5GB of memory per TB of data on average. So if you turn it on on large datasets or pools and don't limit the ARC, it ties your box in knots after it wires down all of the physical memory (even when you're doing a reimport when it's replaying the ZIL -- either on the array or on your dedicated ZIL device). This of course either causes your machine to dig into swap and slow to a crawl, and/or blows away your userland (and now you're pretty much SoL). Bottom line is that dedup is a poorly articulated feature and causes lots of issues if enabled. Compression is a much better feature to enable. > Well, if your test data is not valuable, you can just delete it. :) +1, but I suggest limiting the ARC first. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:22:47 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720BB1065672 for ; Mon, 19 Dec 2011 21:22:47 +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 836868FC08 for ; Mon, 19 Dec 2011 21:22:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA13903; Mon, 19 Dec 2011 23:22:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RckfS-000GLT-HD; Mon, 19 Dec 2011 23:22:42 +0200 Message-ID: <4EEFAB20.4070300@FreeBSD.org> Date: Mon, 19 Dec 2011 23:22:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Nathan Whitehorn References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> <4EEF5D5A.5050700@freebsd.org> In-Reply-To: <4EEF5D5A.5050700@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:22:47 -0000 on 19/12/2011 17:50 Nathan Whitehorn said the following: > The thing I've seen is that ULE is substantially more enthusiastic about > migrating processes between cores than 4BSD. Hmm, this seems to be contrary to my theoretical expectations. I thought that with 4BSD all threads that were not in one of the following categories: - temporary pinned - bound to cpu in kernel via sched_bind - belong to a cpu set which a strict subset of a total set were placed onto a common queue that was shared by all cpus. And as such I expected them to get picked up by the cpus semi-randomly. In other words, I thought that it was ULE that took into account cpu/cache affinities while 4BSD was deliberately entirely ignorant of those details. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:26:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E3F106567B for ; Mon, 19 Dec 2011 21:26:21 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm30.bullet.mail.bf1.yahoo.com (nm30.bullet.mail.bf1.yahoo.com [98.139.212.189]) by mx1.freebsd.org (Postfix) with SMTP id 57F7A8FC12 for ; Mon, 19 Dec 2011 21:26:21 +0000 (UTC) Received: from [98.139.212.150] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:26:20 -0000 Received: from [98.139.213.6] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:26:20 -0000 Received: from [127.0.0.1] by smtp106.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:26:20 -0000 X-Yahoo-Newman-Id: 605905.77712.bm@smtp106.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Sm8uAmUVM1l_V.aeYjSz2YNju0l.oEB_y2L0rVEUc3jQ6LT 1gPym4JLQ__6jBgMSnDHJODeYNkhYzz5fbC9KzuwDOQe8uPM6xOxU6P8WKVN rSGNhvWpg_6E_k70zOkbKWA86Fy_xdQefeGQnWkmD501aQ8VLWDmv1mLsGav 5FZEFq_om_Za6C7ZiK9Nj5KqU9bFv2pANQfUuKt9hc5QQ2OdvqEQssRCphl3 KB_r_zyXNDlMP.wS9ZgJKUudy0eMZIWI9EoRmWdgxfdLVFh68JgQKeayoIO3 psU6Ehf7ClHZ0iEmLQSRhZDeMRDW8yZHlwZXEngl.NCcid._egh6eYhrubJY uWXteoZDKPfULR2s.ZgBZzTFJf3uGPxRDbDXrWUVr9B796i.cykg_awK0U42 4y83Zi2p8owjRsFc8 X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp106.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 13:26:20 -0800 PST Message-ID: <4EEFABFA.4090907@freebsd.org> Date: Mon, 19 Dec 2011 22:26:18 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EEF488E.1030904@freebsd.org> <4EEFA472.5020509@freebsd.org> <0AE9C160-81EC-4A41-985B-EF63E4B0CD9B@gmail.com> In-Reply-To: <0AE9C160-81EC-4A41-985B-EF63E4B0CD9B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:26:21 -0000 Am 19.12.2011 22:00, schrieb Garrett Cooper: > On Dec 19, 2011, at 12:54 PM, Stefan Esser wrote: >> But it seems that others do not observe the asymmetric distribution of >> requests, which makes me wonder whether I happen to have meta data >> arranged in such a way that it is always read from ada0 or ada1, but not >> (or rarely) from ada2 or ada3. That could explain it, including the fact >> that raidz1 over other numbers of drives 8e.g. 3 or 6) apparently show a >> much more symmetric distribution of read requests. > > Basic question: does one set of drives vibrate differently than the other set? No: All drives are mounted in similar cages in a midi tower case (and since I did not like the temperature rising to 45C, last summer, I added case fans to keep the temperature of all drives equally low, too). But I'll try swapping drives (or rather SATA ports) tomorrow. If the drives are different (hardware or data on the drives), then the higher load will move, but if it's in the ZFS code, then I expect the higher request rate to stay on the first two drives. I'll report the outcome. (And repeating what I wrote before: The drives seem to behave perfectly well, they do just receive different numbers of read requests although the pool appears to be symmetric with regard to all factors that could have an impact. I really doubt this is caused by hardware, else there would be observable differences in latency or queue length.) Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:34:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7912106564A for ; Mon, 19 Dec 2011 21:34:39 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm17.bullet.mail.bf1.yahoo.com (nm17.bullet.mail.bf1.yahoo.com [98.139.212.176]) by mx1.freebsd.org (Postfix) with SMTP id 6588C8FC08 for ; Mon, 19 Dec 2011 21:34:39 +0000 (UTC) Received: from [98.139.212.151] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:34:38 -0000 Received: from [98.139.213.14] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:34:38 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 19 Dec 2011 21:34:38 -0000 X-Yahoo-Newman-Id: 591835.80793.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: c6vMCwwVM1lzohz8tBaQk0p4m1d12caxyVdab8_LCGEjlnh 785ioZxTkPsLDbt.rdE0QT3rcedRrZAgQA3_WNZvn4xwbSh.BzVv1n2zUEWq AAGt0rnmDfxfQlnbErOxsAQ8sZwAkRODWql63yky6WxavWhT7duAHIdte3X7 AJCywS1sF6Pk217nwihUc.Yim0_CLNL3xtZYcHDNLFRYbL.gMbSwNbClUc4n vlS22Dx9hJNjEq4VThC4K9JOx2RH3BMJEtfHIuLK2C4Ld3L.b1MDdKlnF.tP nP2HUg_QLidjGffW4Eo2ZSEZeFhaFQqDX2Zh4YBopX5wmFfMxnT3dy3jEZW0 WNkVtt0yUIEqRMjdWnUW36lRxN87YGYWLcF8K7ZkvOrOksz_HqoDnP578u1l OMktz1SE5ZhgyEsA- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.234 with plain) by smtp114.mail.bf1.yahoo.com with SMTP; 19 Dec 2011 13:34:38 -0800 PST Message-ID: <4EEFADEB.4070009@freebsd.org> Date: Mon, 19 Dec 2011 22:34:35 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Daniel Kalchev References: <4EEF488E.1030904@freebsd.org> <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> <4EEFA5E4.9070803@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Stefan Esser Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:34:40 -0000 Am 19.12.2011 22:07, schrieb Daniel Kalchev: > On Dec 19, 2011, at 11:00 PM, Stefan Esser wrote: >> Well, I had dedup enabled for a few short tests. But since I have got >> "only" 8GB of RAM and dedup seems to require an order of magnitude more >> to be working well, I switched dedup off again after a few hours. > > You will need to get rid of the DDT, as those are read nevertheless > even with dedup (already) disabled. The tables refer to already > deduped data. Thanks for the hint! Is there an easy way to identify the file systems that ever had dedup enabled? (I don't mind to extract the information from zdb output, in case that the UI of choice.) I seem to remember that I tried it with my /usr/svn (which obviously had lots of duplicated files), but I do not remember on which other file systems I tried it ... (I've created some 20-25 filesystems on this pool.) > In my case, I had about 2-3TB of deduced data, with 24GB RAM. There > was no shortage of RAM and I could not confirm that ARC is full.. but > somehow the pool was placing heavy read on one or two disks only (all > others, nearly idle) -- apparently many small size reads. > > I resolved my issue by copying the data to a newly created filesystem > in the same pool -- luckily there was enough space available, then > removing the 'deduped' filesystems. This should be easy in the case of /usr/svn, thanks for the suggestion! > That last operation was particularly slow and at one time I had > spontaneous reboot -- the pool was 'impossible to mount', and as > weird as it sounds, I had 'out of swap space' killing the 'zpool > list' process. > I let it sit for few hours, until it has cleared itself. > > I/O in that pool is back to normal now. > > There is something terribly wrong with the dedup code. > > Well, if your test data is not valuable, you can just delete it. :) I could also start over with a clean SVN check-out, but since I've got the free disk space to copy the data over, I'll try that first. Thanks again and best regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:33:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6B4AF106566B; Mon, 19 Dec 2011 21:33:45 +0000 (UTC) Date: Mon, 19 Dec 2011 21:33:45 +0000 From: Alexander Best To: Nathan Whitehorn Message-ID: <20111219213345.GA64578@freebsd.org> References: <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> <4EEF5CC1.7020709@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEF5CC1.7020709@freebsd.org> X-Mailman-Approved-At: Mon, 19 Dec 2011 21:50:41 +0000 Cc: Bruce Cran , Ivan Klymenko , Adrian Chadd , Doug Barton , freebsd-stable@freebsd.org, Ian Smith , "O. Hartmann" , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:33:45 -0000 On Mon Dec 19 11, Nathan Whitehorn wrote: > On 12/18/11 04:34, Adrian Chadd wrote: > >The trouble is that there's lots of anecdotal evidence, but noone's > >really gone digging deep into _their_ example of why it's broken. The > >developers who know this stuff don't see anything wrong. That hints to > >me it may be something a little more creepy - as an example, the > >interplay between netisr/swi/taskqueue/callbacks and such. It may be > >that something is being starved that isn't obviously obvious. It's > >just a stab in the dark, but it sounds somewhat plausible based on > >what I've seen ULE do in my network throughput hacking. > > > >I applaud reppie for trying to make it as easy as possible for people > >to use KTR to provide scheduler traces for him to go digging with, so > >please, if you have these issues and you can absolutely reproduce > >them, please follow his instructions and work with him to get him what > >he needs. > > The thing I've seen is that ULE is substantially more enthusiastic about > migrating processes between cores than 4BSD. Often, this is a good > thing, but can increase the rate of cache misses, hurting performance > for cache-bound processes (I see this particularly in HPC-type > scientific workloads). It might be interesting to add some kind of > tunable here. does r228718 have any impact regarding this behaviour? cheers. alex > > Another more interesting and slightly longer-term possibility if someone > wants a project would be to integrate scheduling decisions with hwpmc > counters, to accumulate statistics on cache hits at each context switch > and preferentially keep processes with a high hits/misses ratio on the > same thread/cache domain relative to processes with a low one. > -Nathan > > P.S. The other thing that could be very interesting from a research and > scheduling standpoint would be to integrate heterogeneous SMP support > into the operating system, with a FreeBSD-4 "Application Processor" > syscall model. We seem to be going down the road where GPGPU computing > has MMUs, timer interrupts, IPIs, etc. (the next AMD Fusions, IBM Cell). > This is something that no operating system currently supports well, and > would be a place for BSD to shine. If anyone has a free graduate student... From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:53:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D6FB1065670; Mon, 19 Dec 2011 21:53:22 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id E028A8FC16; Mon, 19 Dec 2011 21:53:21 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id pBJLrHhV076442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 15:53:18 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id pBJLrHLC050116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 15:53:17 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id pBJLrHZH050112; Mon, 19 Dec 2011 15:53:17 -0600 (CST) (envelope-from dan) Date: Mon, 19 Dec 2011 15:53:17 -0600 From: Dan Nelson To: Stefan Esser Message-ID: <20111219215317.GL53453@dan.emsphone.com> References: <4EEF488E.1030904@freebsd.org> <20111219162220.GK53453@dan.emsphone.com> <4EEFA05E.7090507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEFA05E.7090507@freebsd.org> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 19 Dec 2011 15:53:18 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:53:22 -0000 In the last episode (Dec 19), Stefan Esser said: > Am 19.12.2011 17:22, schrieb Dan Nelson: > > In the last episode (Dec 19), Stefan Esser said: > >> for quite some time I have observed an uneven distribution of load > >> between drives in a 4 * 2TB RAIDZ1 pool. The following is an excerpt > >> of a longer log of 10 second averages logged with gstat: > >> > >> dT: 10.001s w: 10.000s filter: ^a?da?.$ > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > >> 0 130 106 4134 4.5 23 1033 5.2 48.8| ada0 > >> 0 131 111 3784 4.2 19 1007 4.0 47.6| ada1 > >> 0 90 66 2219 4.5 24 1031 5.1 31.7| ada2 > >> 1 81 58 2007 4.6 22 1023 2.3 28.1| ada3 > > [...] > > This is a ZFS only system. The first partition on each drive holds just > the gptzfsloader. > > pool alloc free read write read write > ---------- ----- ----- ----- ----- ----- ----- > raid1 4.41T 2.21T 139 72 12.3M 818K > raidz1 4.41T 2.21T 139 72 12.3M 818K > ada0p2 - - 114 17 4.24M 332K > ada1p2 - - 106 15 3.82M 305K > ada2p2 - - 65 20 2.09M 337K > ada3p2 - - 58 18 2.18M 329K > > The same difference of read operations per second as shown by gstat ... I was under the impression that the parity blocks were scattered evenly across all disks, but from reading vdev_raidz.c, it looks like that isn't always the case. See the comment at the bottom of the vdev_raidz_map_alloc() function; it looks like it will toggle parity between the first two disks in a stripe every 1MB. It's not necessarily the first two disks assigned to the zvol, since stripes don't have to span all disks as long as there's one parity block (a small sync write may just hit two disks, essentially being written mirrored). The imbalance is only visible if you're writing full-width stripes in sequence, so if you write a 1TB file in one long stream, chances are that that file's parity blocks will be concentrated on just two disks, so those two disks will get less I/O on later reads. I don't know why the code toggles parity between just the first two columns; rotating it between all columns would give you an even balance. Is it always the last two disks that have less load, or does it slowly rotate to different disks depending on the data that you are reading? An interesting test would be to idle the system, run a "tar cvf /dev/null /raidz1" in one window, and watch iostat output on another window. If the load moves from disk to disk as tar reads different files, then my parity guess is probably right. If ada0 and ada1 are always busier, than you can ignore me :) Since it looks like the algorithm ends up creating two half-cold parity disks instead of one cold disk, I bet a 3-disk RAIDZ would exhibit even worse balancing, and a 5-disk set would be more even. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:16:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5B4581065670; Mon, 19 Dec 2011 22:16:17 +0000 (UTC) Date: Mon, 19 Dec 2011 22:16:17 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20111219221617.GA70383@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-fs@freebsd.org Subject: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:16:17 -0000 hi there, i'm using a usb hdd with the following specs: otaku% sudo smartctl -i /dev/da0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 10.0-CURRENT amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital My Passport Essential SE (USB, Adv. Format) Device Model: WDC WD10TMVW-11ZSMS4 Serial Number: WD-WXJ1A81C1845 LU WWN Device Id: 5 0014ee 1af1e4483 Firmware Version: 01.01A01 User Capacity: 1,000,204,886,016 bytes [1,00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Mon Dec 19 23:00:43 2011 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled unfortunately i didn't align it properly using gpart(8)'s -a switch. performance wise it shouldn't cause any issues, because i'm accessing this hdd through usb 2 exclusively. however my concern is that using an alignment of 512 will put an extra workload onto the hdd (doing the conversion -> 4096). will this reduce my hdd's life expectancy? in that case i might consider re-partitioning it (with proper alignment settings). cheers. alex ps: the hdd only gets mounted read-only! From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:20:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A031065676 for ; Mon, 19 Dec 2011 22:20:43 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 384F98FC14 for ; Mon, 19 Dec 2011 22:20:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:content-type; b=axcoXb97KTY9PhrfxrKMkKok/Es68rWE3+4K0l5JWFB9UJ6TJI7zcme5DQwT/WVQKzZ3Y+xQuZnT +JwBbs8RTu5QLuo6tm7BJCx66wOI/mx5DbpLM9sHCUUTIuOcrs82 Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1324333242566909.7016519470201; Mon, 19 Dec 2011 14:20:42 -0800 (PST) Message-ID: <4EEFB8B6.8010203@zoho.com> Date: Mon, 19 Dec 2011 19:20:38 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Subject: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:20:43 -0000 Hi people! I'm writing here because I'm having issues with compiling world from a > Symphony# uname -a > FreeBSD Symphony 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #2: Fri Dec 16 > 18:52:44 ART 2011 vertex@Symphony:/usr/obj/usr/src/sys/GENERIC i386 Machine with latest source from that date. I'm using this git mirror (Sorry guys, if I don't tolerate SVN, the less I'll tolerate CVS) → https://github.com/freebsd/freebsd-head (I've pulled and got this as last commit → https://github.com/freebsd/freebsd-head/commit/f700576aa6240ea7133ce4812aec810266bcbfe7 ) With this /etc/make.conf (I have to clean it up btw) > Symphony# cat /etc/make.conf > ################# > # Make.conf > > WITHOUT_NOUVEAU= > # added by use.perl 2011-11-10 19:36:38 > PERL_VERSION=5.12.4 > > ############## > # Clang for kernel+world > > .if ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj/*} || > ${.CURDIR:M/sys/*} > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > .if !defined(CPP) || ${CPP} == "cpp" > CPP=clang-cpp > .endif > > # Don't die on warnings > NO_WERROR= > WERROR= > # Don't forget this when using Jails! > NO_FSCHG= > > > .if defined(WITH_FLAGS) > WITH_LIBCPLUSPLUS=YES > .endif > > > .endif > And /usr/obj was properly rm -rf'ed The problem comes with undefined stuff when I'm compiling libc : > > clang -fpic -DPIC -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa > -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body > -c _fcntl.S -o _fcntl.So > clang -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa > -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body > -c _sigwait.S > clang -fpic -DPIC -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa > -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body > -c _sigwait.S -o _sigwait.So > clang -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa > -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body > -c /usr/src/lib/libc/db/btree/bt_close.c -o bt_close.o > In file included from /usr/src/lib/libc/db/btree/bt_close.c:44: > /usr/src/lib/libc/../../include/stdlib.h:79:1: error: unknown type > name '_Noreturn' > _Noreturn void abort(void); > ^ > /usr/src/lib/libc/../../include/stdlib.h:79:11: error: expected > identifier or '(' > _Noreturn void abort(void); > ^ > /usr/src/lib/libc/../../include/stdlib.h:89:1: error: unknown type > name '_Noreturn' > _Noreturn void exit(int); > ^ > /usr/src/lib/libc/../../include/stdlib.h:89:11: error: expected > identifier or '(' > _Noreturn void exit(int); > ^ > /usr/src/lib/libc/../../include/stdlib.h:148:1: error: unknown type > name '_Noreturn' > _Noreturn void _Exit(int); > ^ > /usr/src/lib/libc/../../include/stdlib.h:148:11: error: expected > identifier or '(' > _Noreturn void _Exit(int); > ^ > 6 errors generated. > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > Symphony# Sorry for the long mail, if you need any information, just tell me. Thanks for your time ! From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:22:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99197106564A for ; Mon, 19 Dec 2011 22:22:23 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD5F8FC18 for ; Mon, 19 Dec 2011 22:22:23 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3D2C05DD3; Mon, 19 Dec 2011 22:22:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJMMMjF042200; Mon, 19 Dec 2011 22:22:22 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Best From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 22:16:17 GMT." <20111219221617.GA70383@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 22:22:22 +0000 Message-ID: <42198.1324333342@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:22:23 -0000 In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: >ps: the hdd only gets mounted read-only! There is no known wear-effects in flash storage as long as you only read. You may need to do refresh-writes every 5-10 years to avoid tunnel-leakage bit errors, but most flash controllers use semi-long ECC syndromes and will do so on first bit that gives an read error. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:29:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E88B106566B for ; Mon, 19 Dec 2011 22:29:19 +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 C68DC8FC16 for ; Mon, 19 Dec 2011 22:29:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 250E67300A; Mon, 19 Dec 2011 23:45:45 +0100 (CET) Date: Mon, 19 Dec 2011 23:45:45 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20111219224545.GA22631@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:29:19 -0000 Hi, recently I have tried to build picobsd image for a different architecture than the current one, with only partial success. In particular, three weeks ago i committed some changes to the picobsd script so now i can build working amd64 images on amd64. However when i try a cross build (e.g. i386 image on an amd64 host) the kernel stops right after trying to mount the root partition. The error message is the following: ... Timecounter "TSC" frequency 1858691100 Hz quality 800 Trying to mount root from ufs:/dev/md0 []... panic: mutex Giant owned at .../sys/kern/kern_exit.c:128 cpuid = 0 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x3b: movl $0,kdb_why db> The backtrace indicates the following (i omit the numbers, as i am manually copying the text) kdb_enter panic _mtx_assert exit1 kern_execve sys_execve exec_shell_imgact fork_exit fork_trampoline --- trap 0, eip = 0, esp = 0xc3708d60, ebp = 0 --- any idea on what could be going wrong ? On a related topic, does anyone have experience on cross-building nanobsd images ? thanks luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:32:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFF0106573B; Mon, 19 Dec 2011 22:32:12 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 007A78FC0C; Mon, 19 Dec 2011 22:32:11 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBJMVsNV022033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Dec 2011 00:32:01 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Daniel Kalchev In-Reply-To: <20111219215317.GL53453@dan.emsphone.com> Date: Tue, 20 Dec 2011 00:31:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEF488E.1030904@freebsd.org> <20111219162220.GK53453@dan.emsphone.com> <4EEFA05E.7090507@freebsd.org> <20111219215317.GL53453@dan.emsphone.com> To: Dan Nelson X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:32:12 -0000 On Dec 19, 2011, at 11:53 PM, Dan Nelson wrote: >=20 > Since it looks like the algorithm ends up creating two half-cold = parity > disks instead of one cold disk, I bet a 3-disk RAIDZ would exhibit = even > worse balancing, and a 5-disk set would be more even. There were some experiments a year or two ago with different number of = disks in raidz and the results suggested that certain number of disks = had better performance, contrary to theory that writes should be evenly = distributed. Worse, this is in the official theory of how raidz = operates=85 Perhaps the code can be fixed to spread the writes to all devices in = raidz, but compatibility issues need to be considered. Perhaps DDT is stored in the 'worst case' write size, because it clearly = exhibits such poor distribution. Daniel= From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:36:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6D3106566B for ; Mon, 19 Dec 2011 22:36:42 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7DBE78FC12 for ; Mon, 19 Dec 2011 22:36:42 +0000 (UTC) Received: from [172.16.1.34] (float34.in1.lcl [172.16.1.34]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id pBJMafJY033458 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 14:36:42 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4EEFBC74.4030109@feral.com> Date: Mon, 19 Dec 2011 14:36:36 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <42198.1324333342@critter.freebsd.dk> In-Reply-To: <42198.1324333342@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Mon, 19 Dec 2011 14:36:42 -0800 (PST) Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:36:42 -0000 Putting it better: http://en.wikipedia.org/wiki/Flash_memory#Read_disturb From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:47:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1F42F1065672; Mon, 19 Dec 2011 22:47:00 +0000 (UTC) Date: Mon, 19 Dec 2011 22:47:00 +0000 From: Alexander Best To: Poul-Henning Kamp Message-ID: <20111219224700.GA75581@freebsd.org> References: <20111219221617.GA70383@freebsd.org> <42198.1324333342@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42198.1324333342@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:47:00 -0000 On Mon Dec 19 11, Poul-Henning Kamp wrote: > In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: > > >ps: the hdd only gets mounted read-only! > > There is no known wear-effects in flash storage as long as you > only read. > > You may need to do refresh-writes every 5-10 years to avoid > tunnel-leakage bit errors, but most flash controllers use semi-long > ECC syndromes and will do so on first bit that gives an read error. this is a regular hdd i believe -- no ssd. at least when i plug it into my usb drive i hear the hdd spinning up and causing vibrations. i don't think that would be the case with an ssd. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:49:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467221065672; Mon, 19 Dec 2011 22:49:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F32CC8FC0C; Mon, 19 Dec 2011 22:49:29 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E81255DAA; Mon, 19 Dec 2011 22:49:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJMnSU3032198; Mon, 19 Dec 2011 22:49:28 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Best From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 22:47:00 GMT." <20111219224700.GA75581@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 22:49:28 +0000 Message-ID: <32197.1324334968@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:49:30 -0000 In message <20111219224700.GA75581@freebsd.org>, Alexander Best writes: >On Mon Dec 19 11, Poul-Henning Kamp wrote: >> In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: >> >> >ps: the hdd only gets mounted read-only! >> >> There is no known wear-effects in flash storage as long as you >> only read. >> >> You may need to do refresh-writes every 5-10 years to avoid >> tunnel-leakage bit errors, but most flash controllers use semi-long >> ECC syndromes and will do so on first bit that gives an read error. > >this is a regular hdd i believe -- no ssd. at least when i plug it into my >usb drive i hear the hdd spinning up and causing vibrations. i don't think >that would be the case with an ssd. Ahh, sorry, I don't know why I thought it was flash. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:56:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3C98B1065673; Mon, 19 Dec 2011 22:56:33 +0000 (UTC) Date: Mon, 19 Dec 2011 22:56:33 +0000 From: Alexander Best To: Poul-Henning Kamp Message-ID: <20111219225633.GA77147@freebsd.org> References: <20111219224700.GA75581@freebsd.org> <32197.1324334968@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32197.1324334968@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:56:33 -0000 On Mon Dec 19 11, Poul-Henning Kamp wrote: > In message <20111219224700.GA75581@freebsd.org>, Alexander Best writes: > >On Mon Dec 19 11, Poul-Henning Kamp wrote: > >> In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: > >> > >> >ps: the hdd only gets mounted read-only! > >> > >> There is no known wear-effects in flash storage as long as you > >> only read. > >> > >> You may need to do refresh-writes every 5-10 years to avoid > >> tunnel-leakage bit errors, but most flash controllers use semi-long > >> ECC syndromes and will do so on first bit that gives an read error. > > > >this is a regular hdd i believe -- no ssd. at least when i plug it into my > >usb drive i hear the hdd spinning up and causing vibrations. i don't think > >that would be the case with an ssd. > > Ahh, sorry, I don't know why I thought it was flash. no problem. so will the improper alignment also not cause a life expectancy shortage in case of a hdd (non-flash-based)? and one other question: the hdd also supports usb 3. will the improper alignment have any effect (speed wise) when connected via usb 3, or is even usb 3 too slow to notice the performance drop due to the improper alignment? cheers. alex > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:01:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE1E9106566B; Mon, 19 Dec 2011 23:01:16 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 697848FC0A; Mon, 19 Dec 2011 23:01:16 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 57F6E5DBE; Mon, 19 Dec 2011 23:01:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJN1FXV078666; Mon, 19 Dec 2011 23:01:15 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Best From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 22:56:33 GMT." <20111219225633.GA77147@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 23:01:15 +0000 Message-ID: <78665.1324335675@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:01:16 -0000 In message <20111219225633.GA77147@freebsd.org>, Alexander Best writes: >no problem. so will the improper alignment also not cause a life expectancy >shortage in case of a hdd (non-flash-based)? Well, theoretically you will have more track-to-track seeks, as some blocks will span cylinders, but I doubt that will have measurable impact on lifetime, compared with the gains you could harvest if you spin it down for even just 1 hour a day... Read-Only/Read-Write makes no difference that I know of for hard-disks. >and one other question: the hdd also supports usb 3. will the improper >alignment have any effect (speed wise) when connected via usb 3, or is even >usb 3 too slow to notice the performance drop due to the improper alignment? Again: I doubt it will be measurable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:05:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 972DB106564A for ; Mon, 19 Dec 2011 23:05:03 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 42E798FC0A for ; Mon, 19 Dec 2011 23:05:03 +0000 (UTC) Received: from [172.16.1.34] (float34.in1.lcl [172.16.1.34]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id pBJMQ09H033402 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 14:26:01 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4EEFB9F3.80603@feral.com> Date: Mon, 19 Dec 2011 14:25:55 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <42198.1324333342@critter.freebsd.dk> In-Reply-To: <42198.1324333342@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Mon, 19 Dec 2011 14:26:01 -0800 (PST) Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:05:03 -0000 On 12/19/2011 2:22 PM, Poul-Henning Kamp wrote: > In message<20111219221617.GA70383@freebsd.org>, Alexander Best writes: > >> ps: the hdd only gets mounted read-only! > There is no known wear-effects in flash storage as long as you > only read. No, sorry, that's not really true. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:07:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA1E106564A for ; Mon, 19 Dec 2011 23:07:59 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0B4F58FC08 for ; Mon, 19 Dec 2011 23:07:58 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3E5A15DD3; Mon, 19 Dec 2011 23:07:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pBJN7uJK092955; Mon, 19 Dec 2011 23:07:57 GMT (envelope-from phk@phk.freebsd.dk) To: mj@feral.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 19 Dec 2011 14:25:55 PST." <4EEFB9F3.80603@feral.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 19 Dec 2011 23:07:56 +0000 Message-ID: <92954.1324336076@critter.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:07:59 -0000 In message <4EEFB9F3.80603@feral.com>, Matthew Jacob writes: >On 12/19/2011 2:22 PM, Poul-Henning Kamp wrote: >> In message<20111219221617.GA70383@freebsd.org>, Alexander Best writes: >> >>> ps: the hdd only gets mounted read-only! >> There is no known wear-effects in flash storage as long as you >> only read. > >No, sorry, that's not really true. Pray tell! There will always be charge leakage, but last I talked to silicon-pushers, that was (almost) entirely independent of read-access and correlated strongly with temperature*duration. Obviously, if your flash controller lies to you and do needless writes anyway, we are not talking read-only. Those are the only two effects I know of ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:43:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 25E501065688; Mon, 19 Dec 2011 23:43:10 +0000 (UTC) Date: Mon, 19 Dec 2011 23:43:10 +0000 From: Alexander Best To: Jeremy Chadwick Message-ID: <20111219234310.GA84478@freebsd.org> References: <20111219224700.GA75581@freebsd.org> <32197.1324334968@critter.freebsd.dk> <20111219225633.GA77147@freebsd.org> <20111219232010.GA31612@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219232010.GA31612@icarus.home.lan> Cc: freebsd-fs@freebsd.org, Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:43:10 -0000 On Mon Dec 19 11, Jeremy Chadwick wrote: > On Mon, Dec 19, 2011 at 10:56:33PM +0000, Alexander Best wrote: > > On Mon Dec 19 11, Poul-Henning Kamp wrote: > > > In message <20111219224700.GA75581@freebsd.org>, Alexander Best writes: > > > >On Mon Dec 19 11, Poul-Henning Kamp wrote: > > > >> In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: > > > >> > > > >> >ps: the hdd only gets mounted read-only! > > > >> > > > >> There is no known wear-effects in flash storage as long as you > > > >> only read. > > > >> > > > >> You may need to do refresh-writes every 5-10 years to avoid > > > >> tunnel-leakage bit errors, but most flash controllers use semi-long > > > >> ECC syndromes and will do so on first bit that gives an read error. > > > > > > > >this is a regular hdd i believe -- no ssd. at least when i plug it into my > > > >usb drive i hear the hdd spinning up and causing vibrations. i don't think > > > >that would be the case with an ssd. > > > > > > Ahh, sorry, I don't know why I thought it was flash. > > > > no problem. so will the improper alignment also not cause a life expectancy > > shortage in case of a hdd (non-flash-based)? > > The improper alignment will result in sub-par write performance, and a > slight decrease in read performance writes -- but will not impact life > expectancy or "harm" the drive in any way. > > I recommend strongly that you rectify the situation before you get too > carried away with software installations, etc.. > > And yes I am aware what you have is a mechanical HDD not an SSD (I say > in this advance of what I'm about to write). > > If you need a ""safe"" alignment value, most software on Windows > (including Windows 7) pick a value of 2MBytes as the alignment offset, > which I believe is LBA 4095, since everything software-wise uses > 512-byte sectors. That's calculated via: 2097152 / 512. > > This number is also evenly divisible by 4096 bytes (which is what you're > trying to ensure for performance). > > Readers, as well as you, may wonder where the "magical" 2MByte value > comes from, and can you pick something smaller. Yes you can pick > something smaller, but the value itself stems from the added complexity > of SSDs and NAND erase page size vs. NAND page size. A value of 2MBytes > works well on all brands of SSDs on the market (as of this writing). > > Which reminds me -- I need to go back and redo most of our systems that > use Intel SSDs, since at the time I picked the default offset in > sysinstall (LBA 63, thus 64 * 512 = 32KBytes), which though divisible by > 4096, is not optimal for NAND erase page size. > > I would love to advocate FreeBSD change sysinstall/bsdinstall to use a > default offset of 2MBytes, but I imagine that would upset a lot of > people who install FreeBSD on "limited space" devices (CF, etc.). > Honestly though, with the size of media these days........ thanks a lot for the explanation. i'm going to get another drive, soon, and will then be able to "fix" the alignment, as i currently have no place where i can backup the data of my current (misaligned) hdd. > > > and one other question: the hdd also supports usb 3. will the improper > > alignment have any effect (speed wise) when connected via usb 3, or is even > > usb 3 too slow to notice the performance drop due to the improper alignment? > > USB 3.0 vs. 2.0 vs. eSATA vs. native SATA has no bearing on the > situation. Those are transport protocols that define "maximum > bandwidth". > > By the way, the hard disk itself does not "support USB 3.0" -- your > drive is in an enclosure that contains a SATA<->USB3.0 conversion > chipset inside. If you open the enclosure, you will find the hard disk > is SATA, and probably supports SATA600. i was ware of this fact. what i meant by speed in connection with usb 3 was the following example-case (please don't take the numbers literally) 1) the drive itself can do 500 mb/sec when aligned properly 2) the drive does 350 mb/sec when aligned improperly (512 boundry) 3) usb 3 can do 100 mb/sec ... so in this case the improper alignment wouldn't have an impact, since even with proper alignment only 100 mb/sec were possible. however in the following example: 1) 500 mb/sec 2) 100 mb/sec 3) 200 mb/sec the improper alignment would have an impact, since usb 3 *could* perform at 200 mb/sec with proper alignment, but will drop to 100 mb/sec in the case of improper alignment. again...please don't take the transfer rates literaly. they're most defenately bogus. cheers. alex > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:20:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B44A106568D for ; Mon, 19 Dec 2011 23:20:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4B98FC12 for ; Mon, 19 Dec 2011 23:20:12 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta13.emeryville.ca.mail.comcast.net with comcast id BBJf1i0061bwxycADBL5UW; Mon, 19 Dec 2011 23:20:05 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id BBtN1i0121t3BNj8eBtNg6; Mon, 19 Dec 2011 23:53:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B3562102C19; Mon, 19 Dec 2011 15:20:10 -0800 (PST) Date: Mon, 19 Dec 2011 15:20:10 -0800 From: Jeremy Chadwick To: Alexander Best Message-ID: <20111219232010.GA31612@icarus.home.lan> References: <20111219224700.GA75581@freebsd.org> <32197.1324334968@critter.freebsd.dk> <20111219225633.GA77147@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219225633.GA77147@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 19 Dec 2011 23:46:53 +0000 Cc: freebsd-fs@freebsd.org, Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:20:12 -0000 On Mon, Dec 19, 2011 at 10:56:33PM +0000, Alexander Best wrote: > On Mon Dec 19 11, Poul-Henning Kamp wrote: > > In message <20111219224700.GA75581@freebsd.org>, Alexander Best writes: > > >On Mon Dec 19 11, Poul-Henning Kamp wrote: > > >> In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: > > >> > > >> >ps: the hdd only gets mounted read-only! > > >> > > >> There is no known wear-effects in flash storage as long as you > > >> only read. > > >> > > >> You may need to do refresh-writes every 5-10 years to avoid > > >> tunnel-leakage bit errors, but most flash controllers use semi-long > > >> ECC syndromes and will do so on first bit that gives an read error. > > > > > >this is a regular hdd i believe -- no ssd. at least when i plug it into my > > >usb drive i hear the hdd spinning up and causing vibrations. i don't think > > >that would be the case with an ssd. > > > > Ahh, sorry, I don't know why I thought it was flash. > > no problem. so will the improper alignment also not cause a life expectancy > shortage in case of a hdd (non-flash-based)? The improper alignment will result in sub-par write performance, and a slight decrease in read performance writes -- but will not impact life expectancy or "harm" the drive in any way. I recommend strongly that you rectify the situation before you get too carried away with software installations, etc.. And yes I am aware what you have is a mechanical HDD not an SSD (I say in this advance of what I'm about to write). If you need a ""safe"" alignment value, most software on Windows (including Windows 7) pick a value of 2MBytes as the alignment offset, which I believe is LBA 4095, since everything software-wise uses 512-byte sectors. That's calculated via: 2097152 / 512. This number is also evenly divisible by 4096 bytes (which is what you're trying to ensure for performance). Readers, as well as you, may wonder where the "magical" 2MByte value comes from, and can you pick something smaller. Yes you can pick something smaller, but the value itself stems from the added complexity of SSDs and NAND erase page size vs. NAND page size. A value of 2MBytes works well on all brands of SSDs on the market (as of this writing). Which reminds me -- I need to go back and redo most of our systems that use Intel SSDs, since at the time I picked the default offset in sysinstall (LBA 63, thus 64 * 512 = 32KBytes), which though divisible by 4096, is not optimal for NAND erase page size. I would love to advocate FreeBSD change sysinstall/bsdinstall to use a default offset of 2MBytes, but I imagine that would upset a lot of people who install FreeBSD on "limited space" devices (CF, etc.). Honestly though, with the size of media these days........ > and one other question: the hdd also supports usb 3. will the improper > alignment have any effect (speed wise) when connected via usb 3, or is even > usb 3 too slow to notice the performance drop due to the improper alignment? USB 3.0 vs. 2.0 vs. eSATA vs. native SATA has no bearing on the situation. Those are transport protocols that define "maximum bandwidth". By the way, the hard disk itself does not "support USB 3.0" -- your drive is in an enclosure that contains a SATA<->USB3.0 conversion chipset inside. If you open the enclosure, you will find the hard disk is SATA, and probably supports SATA600. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:22:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78EB4106564A for ; Mon, 19 Dec 2011 23:22:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 37ACF8FC08 for ; Mon, 19 Dec 2011 23:22:18 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id B65L1i0011swQuc55BNJDr; Mon, 19 Dec 2011 23:22:18 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id BBNH1i01B1t3BNj3bBNJAQ; Mon, 19 Dec 2011 23:22:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 65077102C19; Mon, 19 Dec 2011 15:22:16 -0800 (PST) Date: Mon, 19 Dec 2011 15:22:16 -0800 From: Jeremy Chadwick To: Alexander Best Message-ID: <20111219232216.GA31865@icarus.home.lan> References: <20111219224700.GA75581@freebsd.org> <32197.1324334968@critter.freebsd.dk> <20111219225633.GA77147@freebsd.org> <20111219232010.GA31612@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219232010.GA31612@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 19 Dec 2011 23:47:05 +0000 Cc: freebsd-fs@freebsd.org, Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:22:18 -0000 On Mon, Dec 19, 2011 at 03:20:10PM -0800, Jeremy Chadwick wrote: > On Mon, Dec 19, 2011 at 10:56:33PM +0000, Alexander Best wrote: > > On Mon Dec 19 11, Poul-Henning Kamp wrote: > > > In message <20111219224700.GA75581@freebsd.org>, Alexander Best writes: > > > >On Mon Dec 19 11, Poul-Henning Kamp wrote: > > > >> In message <20111219221617.GA70383@freebsd.org>, Alexander Best writes: > > > >> > > > >> >ps: the hdd only gets mounted read-only! > > > >> > > > >> There is no known wear-effects in flash storage as long as you > > > >> only read. > > > >> > > > >> You may need to do refresh-writes every 5-10 years to avoid > > > >> tunnel-leakage bit errors, but most flash controllers use semi-long > > > >> ECC syndromes and will do so on first bit that gives an read error. > > > > > > > >this is a regular hdd i believe -- no ssd. at least when i plug it into my > > > >usb drive i hear the hdd spinning up and causing vibrations. i don't think > > > >that would be the case with an ssd. > > > > > > Ahh, sorry, I don't know why I thought it was flash. > > > > no problem. so will the improper alignment also not cause a life expectancy > > shortage in case of a hdd (non-flash-based)? > > The improper alignment will result in sub-par write performance, and a > slight decrease in read performance writes -- but will not impact life > expectancy or "harm" the drive in any way. This should have read "...slight decrease in read performance", not "read performance writes". Editing mistake on my part. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 00:54:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F087106566C for ; Tue, 20 Dec 2011 00:54:03 +0000 (UTC) (envelope-from petro.rossini@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C0D228FC12 for ; Tue, 20 Dec 2011 00:54:02 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so7735293vbb.13 for ; Mon, 19 Dec 2011 16:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wjkG0rSYu3FLNFWC6xn+NgW/jJ+boOV+5VvREiwIJk=; b=o+XmxEKdVRsSb71mHoOk35NFXhKBGQbnxFCZaqpLbWmm9HvwPxTZS/Biny3x7/teKu phYvz1lIDod/5ssv19fyqrNV4n57IzULzdsyRAYtGmXCMwPAXVi5FZXPret6C2Yzi0GH FHt9+zKRoq7ZcZCDFjRwVjqIMMbbkUJ0gCSWg= MIME-Version: 1.0 Received: by 10.52.74.162 with SMTP id u2mr12547247vdv.69.1324340938039; Mon, 19 Dec 2011 16:28:58 -0800 (PST) Received: by 10.220.152.71 with HTTP; Mon, 19 Dec 2011 16:28:57 -0800 (PST) In-Reply-To: <4EEF3FF9.7070307@digsys.bg> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF3FF9.7070307@digsys.bg> Date: Tue, 20 Dec 2011 11:28:57 +1100 Message-ID: From: Petro Rossini To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:54:03 -0000 Hi all, just a thought here: On Tue, Dec 20, 2011 at 12:45 AM, Daniel Kalchev wrote: >> As were told, Phoronix used "default" setup, not tuned. > Not really. They created some weird test environment, at least for FreeBSD > -- who knows, possibly for Linux as well. > > For example, ZFS is by no means a default file system in FreeBSD. You need > to go trough manual steps, to enable it, to build the pool, filesystems etc. .. Of course the benchmark setup and procedure is strange but.. it could be improved, I think. Have a good collection of tuning parameters for "popular cases", advertised properly so it gets hard "to miss them". I am a sysadmin and, over the years, I had to run file servers, database servers, web servers, tomcats... Well, most of the time I set it up and "it just works" because the system in question is not maxed out, not even close to it. But if I want to squeeze the last 20% out of it googling starts, and here and there I find hints how to tune the OS, the file system, what scheduler to use etc. It would be great to have a set of case studies at hand, e.g. under the /usr/share/examples directory, that describes tweaks to have a performing postgresql server, or mysql, or apache or a desktop or.. Things I find, for example, in the BSD Magazine. Maybe benchmarks become more meaningful then.. A general remark for people doing benchmarks for comparison: you need a well-informed system engineer for the systems you compare. So, if you compare a Linux system with FreeBSD, have two experienced admins that know their OS well. Regards Peter From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 01:21:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94664106564A for ; Tue, 20 Dec 2011 01:21:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 19A448FC16 for ; Tue, 20 Dec 2011 01:21:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAL/h706DaFvO/2dsb2JhbABDhQ6nYoIcgQsCDRkCiHSYBY4CkXyBL4dDggSBFgSINoxIkkw X-IronPort-AV: E=Sophos;i="4.71,379,1320642000"; d="scan'208";a="151057512" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Dec 2011 20:21:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 21F2BB3F3A for ; Mon, 19 Dec 2011 20:21:45 -0500 (EST) Date: Mon, 19 Dec 2011 20:21:45 -0500 (EST) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 01:21:46 -0000 Hi, A recent NFS client crash: http://glebius.int.ru/tmp/nfs_panic.jpg appears to have happened because some field is bogus when crfree() is called. I've asked Gleb to disassemble crfree() for me, so I can try and see exactly which field causes the crash, however... Basically, the code: newcred = crdup(cred); - does read with newcred crfree(newcred); <-- which crashes at 0x65 into crfree() Looking at crdup(), it calls crcopy(), which copies 4 pointers and then ref. counts them: cr_uidinfo, cr_ruidinfo, cr_prison and cr_loginclass It seems some lock should be held while crcopy() does this, so that the pointers don't get deref'd during the copy/ref. count? (Or is there some rule that guarantees these won't change. ie. No no calls to change_euid() or similar.) Is there such a lock and should crdup() use it? Thanks in advance for any info, rick From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 02:24:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA96106566B for ; Tue, 20 Dec 2011 02:24:04 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id C67668FC0A for ; Tue, 20 Dec 2011 02:24:04 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=UyzVBRRm6DoR111jZsypWM8LXWsN0JsNW7P6OE+yWVh9e4iRgPJn8JW0Q9p32dKLyaydC8NAWWkq t8EeCF48LH77T+Bi1qeFlnzQ6zTLMudheaTqm7mhWrjruln0Vcqk Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1324347844212148.96927583593538; Mon, 19 Dec 2011 18:24:04 -0800 (PST) Message-ID: <4EEFF1C0.5000408@zoho.com> Date: Mon, 19 Dec 2011 23:24:00 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EEFB8B6.8010203@zoho.com> In-Reply-To: <4EEFB8B6.8010203@zoho.com> X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 02:24:05 -0000 http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_unreachable http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1453.htm Apparently this is the problem: > _Noreturn void abort(void); > // [...] more declarations > _Noreturn void exit(int); Those noreturns are supposed to be written with GCC syntax and this can be workarounded with this : > |#define _Noreturn __attribute__ ((noreturn))| | Maybe the compiler can be checked in preprocessor and add that compatibility line so the code compiles correctly ||Any opinion on this?| | Thanks for your time and for reading ! | From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 03:31:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11032106564A for ; Tue, 20 Dec 2011 03:31:56 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id EEA0E8FC14 for ; Tue, 20 Dec 2011 03:31:55 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=H+vAh8lE4rIAINg3EGnCil0FLAWqqWMMWxrwGNSo3saIexQX465JMHbCpjYAvAdmT0zh9IsQLXuS zHlqn69IhHkiNLn+6Q6hkKE758YVniD3mwy+3hqalkvzSQr9dl9K Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1324351914772434.64214162968346; Mon, 19 Dec 2011 19:31:54 -0800 (PST) Message-ID: <4EF001A7.4030602@zoho.com> Date: Tue, 20 Dec 2011 00:31:51 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EEFB8B6.8010203@zoho.com> In-Reply-To: <4EEFB8B6.8010203@zoho.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Subject: Re: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 03:31:56 -0000 A follow-up on this is libc not building because of missing SCTP_REMOTE_UDP_ENCAPS_PORT apparently the Makefile doesn't include /sys/ into the includes of the libc. My current version (/usr/include/netinet/sctp.h) lacks that definition, it should look in the headers of the source, not the current system headers ... so I just added that to the Makefile ( lib/libc/net/Makefile.inc ). I'm leaving note if anyone else experiences the same problem. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 04:10:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E71B21065675; Tue, 20 Dec 2011 04:10:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A247C8FC15; Tue, 20 Dec 2011 04:10:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pBK4AG4h002046; Mon, 19 Dec 2011 21:10:16 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pBK4AGO8002043; Mon, 19 Dec 2011 21:10:16 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 19 Dec 2011 21:10:16 -0700 (MST) From: Warren Block To: Alexander Best In-Reply-To: <20111219225633.GA77147@freebsd.org> Message-ID: References: <20111219224700.GA75581@freebsd.org> <32197.1324334968@critter.freebsd.dk> <20111219225633.GA77147@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 19 Dec 2011 21:10:16 -0700 (MST) Cc: freebsd-fs@freebsd.org, Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: can a wrong alignment cause a decrease in a hdd's life expectancy? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 04:10:18 -0000 On Mon, 19 Dec 2011, Alexander Best wrote: > no problem. so will the improper alignment also not cause a life expectancy > shortage in case of a hdd (non-flash-based)? > > and one other question: the hdd also supports usb 3. will the improper > alignment have any effect (speed wise) when connected via usb 3, or is even > usb 3 too slow to notice the performance drop due to the improper alignment? Many variables: file system, file size, drive firmware... The only reason not to fix it is time. And space for a temporary copy... two, two reasons not to fix it. Benchmark it as-is, back up, realign, restore, benchmark again. Or live with the gnawing, creeping doubt of not knowing for sure. Every day wondering "is that drive slower than it could be just from a simple alignment error? Is every read a mere fraction of its potential? But it's probably fine. No pressure. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 05:36:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB35B106564A for ; Tue, 20 Dec 2011 05:36:49 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id A1EF28FC18 for ; Tue, 20 Dec 2011 05:36:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=c54lYhRiXGLHdeTBG2QsjzlcNe9TPjeyj4kVXOPqCMBWU1/xHgL+CbKjdrdwljMRDjPwSRS1cWOI dTqiLIL2F1ydNbQqQ4zy+/yZOcwtjjt0Vr6h2Fopm2nqoGaLDc6y Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1324359408642661.3376350442907; Mon, 19 Dec 2011 21:36:48 -0800 (PST) Message-ID: <4EF01EEC.9030204@zoho.com> Date: Tue, 20 Dec 2011 02:36:44 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper , freebsd-current@freebsd.org References: <4EEFB8B6.8010203@zoho.com> <4EF001A7.4030602@zoho.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: Subject: Re: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 05:36:49 -0000 On 12/20/2011 01:52, Garrett Cooper wrote: > On Mon, Dec 19, 2011 at 7:31 PM, Alex Kuster wrote: >> A follow-up on this is libc not building because of missing >> SCTP_REMOTE_UDP_ENCAPS_PORT >> apparently the Makefile doesn't include /sys/ into the includes of the libc. >> >> My current version (/usr/include/netinet/sctp.h) lacks that definition, it >> should look in the headers of the source, not the current system headers ... >> so I just added that to the Makefile ( lib/libc/net/Makefile.inc ). >> >> I'm leaving note if anyone else experiences the same problem. > Please file a PR for this and other similar build issues. The > mantra I've gotten in the past is that "builds aren't guaranteed to > work in a subdirs", but I would really like for this to become a > reality because I really wouldn't want to have to installworld (or > installincludes) a whole system just to get some headers installed for > a trivial program in the base system :). > Just to make sure though, did you do make depend all , or just make all? > Thanks! > -Garrett > Hi Garett ... Well, those issues were raised by a simple "make buildworld" in the traditional /usr/src When I found the first issue with libc i just went to /usr/src/lib/libc, fixed and ran a make in there, so the second issue appeared and libc was built with no problems. Now I'm facing another one which I'll find out and see how to fix to get a compiling/working system. Thanks for your time! P.S → I didn't know about installincludes, I'll read about that P.S 2 → I never-ever-ever filed a PR From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:38:54 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 11D52106566C; Tue, 20 Dec 2011 08:38:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 829FD14DA52; Tue, 20 Dec 2011 08:38:53 +0000 (UTC) Message-ID: <4EF0499D.4070000@FreeBSD.org> Date: Tue, 20 Dec 2011 00:38:53 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Dimitry Andric References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> In-Reply-To: <4EEF3B22.8010401@FreeBSD.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 08:38:54 -0000 On 12/19/2011 05:24, Dimitry Andric wrote: > On 2011-12-19 10:17, Doug Barton wrote: >> I updated to r228700 from 228122 and dhclient exits immediately saying >> that em0 doesn't exist. However ifconfig seems to disagree: >> >> >> em0: flags=8843 metric 0 mtu >> 1500 >> >> options=4219b >> >> ether 00:24:e8:30:10:9b >> nd6 options=29 >> media: Ethernet autoselect (100baseTX) >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> options=3 >> nd6 options=21 >> >> >> Interestingly, some of the options are different in that version, vs. >> the working version: >> >> em0: flags=8843 metric 0 mtu >> 1500 >> options=219b >> >> ether 00:24:e8:30:10:9b >> inet 172.17.198.245 netmask 0xffff0000 broadcast 172.17.255.255 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX) >> status: active > > I saw this too, when my kernel and userland were out of sync (e.g. just > after installing a new kernel, and before installworld). I suspect it > is caused by the changes in r228571, which cause old ifconfig and > dhclient to not recognize any interfaces. I'm not 100% sure though... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. The traditional (and documented) upgrade process for many years has been to boot the new kernel, make sure it's Ok, then update world. Obviously something different is needed this time, so it needs an UPDATING entry (assuming that all this is not just a bug). Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:13:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A81F1065675 for ; Tue, 20 Dec 2011 09:13:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 13A578FC16 for ; Tue, 20 Dec 2011 09:13:50 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3489797obb.13 for ; Tue, 20 Dec 2011 01:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gB1NBah1Z/Upuh06L4Ev0BNV9RpqPvGaQ01wWYQWdPQ=; b=E6wk8faAZsqJrzx/PKjQBn7/JCba0nXzZP6ohcHWOqU77HvkdDgyE4sAHiiMUvP6uD pwAN/52KFkyvMzs06eQhGhYx0cimFcbNnXsVvdJOH2/p8wTHMwFWqgHjazlRPmo0m3M1 wkxObSC55Ibp24dkUaYY6IQmg42aoi6aUaQXc= MIME-Version: 1.0 Received: by 10.182.231.38 with SMTP id td6mr883851obc.66.1324372430207; Tue, 20 Dec 2011 01:13:50 -0800 (PST) Received: by 10.182.62.227 with HTTP; Tue, 20 Dec 2011 01:13:49 -0800 (PST) In-Reply-To: <4EF01EEC.9030204@zoho.com> References: <4EEFB8B6.8010203@zoho.com> <4EF001A7.4030602@zoho.com> <4EF01EEC.9030204@zoho.com> Date: Tue, 20 Dec 2011 01:13:49 -0800 Message-ID: From: Garrett Cooper To: Alex Kuster Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:13:51 -0000 On Mon, Dec 19, 2011 at 9:36 PM, Alex Kuster wrot= e: > On 12/20/2011 01:52, Garrett Cooper wrote: >> >> On Mon, Dec 19, 2011 at 7:31 PM, Alex Kuster >> =C2=A0wrote: >>> >>> A follow-up on this is libc not building because of missing >>> SCTP_REMOTE_UDP_ENCAPS_PORT >>> apparently the Makefile doesn't include /sys/ into the includes of the >>> libc. >>> >>> My current version (/usr/include/netinet/sctp.h) lacks that definition, >>> it >>> should look in the headers of the source, not the current system header= s >>> ... >>> so I just added that to the Makefile ( lib/libc/net/Makefile.inc ). >>> >>> I'm leaving note if anyone else experiences the same problem. >> >> =C2=A0 =C2=A0 Please file a PR for this and other similar build issues. = The >> mantra I've gotten in the past is that "builds aren't guaranteed to >> work in a subdirs", but I would really like for this to become a >> reality because I really wouldn't want to have to installworld (or >> installincludes) a whole system just to get some headers installed for >> a trivial program in the base system :). >> =C2=A0 =C2=A0 Just to make sure though, did you do make depend all , or = just make >> all? >> Thanks! >> -Garrett >> > > Hi Garett ... Well, those issues were raised by a simple "make buildworld= " > in the traditional /usr/src > When I found the first issue with libc i just went to /usr/src/lib/libc, > fixed and ran a make in there, so the second issue appeared and libc was > built with no problems. Hmm.. yeah, that's a bug then. > Now I'm facing another one which I'll find out and see how to fix to get = a > compiling/working system. Ok. > Thanks for your time! Np! > P.S =E2=86=92 I didn't know about installincludes, I'll read about that make distribution does more than that too (and mergemaster runs that). man build has some other interesting tricks that may or may not be of value to you. > P.S 2 =E2=86=92 I never-ever-ever filed a PR http://www.freebsd.org/send-pr.html Cheers! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:15:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6530A1065670 for ; Tue, 20 Dec 2011 09:15:08 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E49478FC0C for ; Tue, 20 Dec 2011 09:15:07 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so12034576wgb.31 for ; Tue, 20 Dec 2011 01:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=6HiSaVqw3mlfYlOl+vtm/jBqvpZlW2Qn/bpRSD4c6gI=; b=t3K90MY+gORuo7pU7YQPE7rdbHq7xUIA/qVC1mJrPVc/Zmgfqk3f7aelh2OBT3sp2V oMm8Q92nYy0iUmlmddtD7/eCGN69Ubzzzy4MgLsbixezNLMn4rwo0dS0aIiJH1Gifsqu TQinH2sml4GpOTwqmzYL5ZY6DBIJO/4HQ+qlg= Received: by 10.227.200.204 with SMTP id ex12mr1171229wbb.7.1324372019323; Tue, 20 Dec 2011 01:06:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.57.82 with HTTP; Tue, 20 Dec 2011 01:06:38 -0800 (PST) In-Reply-To: <5A7C9A6F-34F6-4BEB-AFE7-D6D7C50D7AB2@bsdimp.com> References: <20111202015133.GA4111@dragon.NUXI.org> <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> <20111202223716.GA35140@troutmask.apl.washington.edu> <5A7C9A6F-34F6-4BEB-AFE7-D6D7C50D7AB2@bsdimp.com> From: Christer Solskogen Date: Tue, 20 Dec 2011 10:06:38 +0100 Message-ID: To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Max Khon , Steve Kargl , Doug Barton Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:15:08 -0000 On Mon, Dec 19, 2011 at 8:46 PM, Warner Losh wrote: > > On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote: > >> On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote: >>> >>> The most important thing is to have reasonable defaults. >>> Having WITH_PROFILE by default does not seem to be a reasonable default= to me. >>> > > Now all users that want to profile anything need to build their own custo= m FreeBSD? =C2=A0That seems even more nuts to me. So that all users that do not want to profile anything need to build their own "custom" FreeBSD? --=20 chs, From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:17:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D04106566B for ; Tue, 20 Dec 2011 09:17:42 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B761E8FC19 for ; Tue, 20 Dec 2011 09:17:41 +0000 (UTC) Received: (qmail 78202 invoked from network); 20 Dec 2011 09:17:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 20 Dec 2011 09:17:39 -0000 Date: Tue, 20 Dec 2011 10:17:39 +0100 (CET) Message-Id: <20111220.101739.74674744.sthaug@nethelp.no> To: christer.solskogen@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20111202223716.GA35140@troutmask.apl.washington.edu> <5A7C9A6F-34F6-4BEB-AFE7-D6D7C50D7AB2@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dougb@freebsd.org, freebsd-current@freebsd.org, sgk@troutmask.apl.washington.edu, imp@bsdimp.com, fjoe@samodelkin.net Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:17:42 -0000 > > Now all users that want to profile anything need to build their own= custom FreeBSD? =A0That seems even more nuts to me. > = > So that all users that do not want to profile anything need to build > their own "custom" FreeBSD? No. It simply means these users will have profiled libraries available that they don't use. FWIW, I support keeping the build of profiled libraries. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:30:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE73106564A; Tue, 20 Dec 2011 09:30:00 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4B4F8FC12; Tue, 20 Dec 2011 09:29:59 +0000 (UTC) Received: by eekc50 with SMTP id c50so7341739eek.13 for ; Tue, 20 Dec 2011 01:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=3t0Usdm1HKG61fuGPfVDA7MaB10LmXBKnzyAXpm8tLM=; b=aX8WXLG6TU6LcTtrr/I7te38dqJ/+x13hm9cw0NAYC/Tz+Mo0DdPw38cQIqRZ7iRmW 1UwDfYKEmGLMhppPLoKTTSsff98w8nPjpLJAluO65sAaFrH3OYS3Bdx0CPqKHxvdceZd /YY0LHJvGVFue/+vkENeK7rCla9R52h1z+f7o= Received: by 10.213.110.6 with SMTP id l6mr344419ebp.71.1324373398491; Tue, 20 Dec 2011 01:29:58 -0800 (PST) Received: from ernst.jennejohn.org (p578E26BF.dip.t-dialin.net. [87.142.38.191]) by mx.google.com with ESMTPS id s16sm4547200eef.2.2011.12.20.01.29.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 01:29:57 -0800 (PST) Date: Tue, 20 Dec 2011 10:29:55 +0100 From: Gary Jennejohn To: Andriy Gapon Message-ID: <20111220102955.068bb756@ernst.jennejohn.org> In-Reply-To: <4EEFAB20.4070300@FreeBSD.org> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost> <20111213090051.GA3339@vniz.net> <4EED5200.20302@cran.org.uk> <20111218164924.L64681@sola.nimnet.asn.au> <20111218075241.GA45367@vniz.net> <20111218102401.GA42627@freebsd.org> <20111218102600.GA44118@freebsd.org> <4EEF5D5A.5050700@freebsd.org> <4EEFAB20.4070300@FreeBSD.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org, freebsd-current@FreeBSD.org, Nathan Whitehorn Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:30:00 -0000 On Mon, 19 Dec 2011 23:22:40 +0200 Andriy Gapon wrote: > on 19/12/2011 17:50 Nathan Whitehorn said the following: > > The thing I've seen is that ULE is substantially more enthusiastic about > > migrating processes between cores than 4BSD. > > Hmm, this seems to be contrary to my theoretical expectations. I thought that > with 4BSD all threads that were not in one of the following categories: > - temporary pinned > - bound to cpu in kernel via sched_bind > - belong to a cpu set which a strict subset of a total set > were placed onto a common queue that was shared by all cpus. And as such I > expected them to get picked up by the cpus semi-randomly. > > In other words, I thought that it was ULE that took into account cpu/cache > affinities while 4BSD was deliberately entirely ignorant of those details. > I have a 6-core AMD CPU running FreeeBSD 10.0 and SCHED_4BSD. I've noticed with large ports builds which are not MAKE_JOBS_SAFE that the compile load migrates between the cores pretty quickly, but I haven't compared it to ULE. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:32:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71516106566C; Tue, 20 Dec 2011 09:32:19 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 941FA8FC13; Tue, 20 Dec 2011 09:32:18 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so2567919wib.13 for ; Tue, 20 Dec 2011 01:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yuWdyf7Fw56Lo6gbnvRnGyn2QVHW7uYejRRUOH85lzY=; b=LUraSKFBVdU3/BgtIgOqc2qBE0ooMQUByClekkZAy/QLElhNiJFqfL0kmYi0hZvgSA Xs3/xZrj/6qZwsJtmKCzDt7JoOIA1IIJUHOXKIZrCGsGbiy/Ft+O/ZsFMpNaBfRKeZLU y2qlpPSin5+RJcg6oROYFqj1ro8ocKV5f6pSE= Received: by 10.180.19.138 with SMTP id f10mr3389515wie.3.1324371697282; Tue, 20 Dec 2011 01:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.57.82 with HTTP; Tue, 20 Dec 2011 01:01:16 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> From: Christer Solskogen Date: Tue, 20 Dec 2011 10:01:16 +0100 Message-ID: To: Alexander Yerenkow Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List , freebsd-performance@freebsd.org, Current FreeBSD , Edho Arief Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:32:19 -0000 On Mon, Dec 19, 2011 at 2:16 PM, Alexander Yerenkow wrote: > FreeBSD currently have very obscure, closed community. To get in touch, you > need to subscribe to several mail lists, constantly read them, I've just > found recently (my shame of course) in mail list that there is service ( > pub.allbsd.org) which constantly building current versions. This is great, > but at homepage of freebsd.org there is no word about it :) That's because it's not official. Do you take the risk? Would a multi-milion-dollar company do that? For your private server, sure it's probably fine. But how do you know that those files are not contaminated? (That being said, the purpose of that service is good. And the files there a most probably 100% fine. But if it's not official... then..) -- chs, if there is only one candiate, there is one one choice! From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:42:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2CF1065676; Tue, 20 Dec 2011 09:42:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 470508FC1B; Tue, 20 Dec 2011 09:42:32 +0000 (UTC) Received: by yenl9 with SMTP id l9so4698412yen.13 for ; Tue, 20 Dec 2011 01:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kVd8UBTZMv7IHwY6VOwz8O9ZZkkAnvhEJYsyHGg7Gw8=; b=rxjC/xC7pVllkHy/Dz3hhG0JYGh/0YXi2gWwjW++U0XZ03zmJFfvH0/cxX0/QvdyE1 se1tmo3gADIAy7Min460houA3KPAtTrbmaZHlf1GcWEvkkq3evzCa8JW2t1Dcxmpenj4 HR+W38EhbBCgp3/tv87gqANxsO7MaqG/y57Ag= Received: by 10.236.201.137 with SMTP id b9mr1991915yho.124.1324374152574; Tue, 20 Dec 2011 01:42:32 -0800 (PST) Received: from starr-wireless.local (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id n5sm2321003yhk.1.2011.12.20.01.42.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 01:42:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Tue, 20 Dec 2011 01:42:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> To: Christer Solskogen X-Mailer: Apple Mail (2.1084) Cc: Edho Arief , freebsd-performance@freebsd.org, Alexander Yerenkow , FreeBSD Stable Mailing List , Current FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:42:33 -0000 On Dec 20, 2011, at 1:01 AM, Christer Solskogen wrote: > On Mon, Dec 19, 2011 at 2:16 PM, Alexander Yerenkow = wrote: >> FreeBSD currently have very obscure, closed community. To get in = touch, you >> need to subscribe to several mail lists, constantly read them, I've = just >> found recently (my shame of course) in mail list that there is = service ( >> pub.allbsd.org) which constantly building current versions. This is = great, >> but at homepage of freebsd.org there is no word about it :) >=20 > That's because it's not official. Do you take the risk? Would a > multi-milion-dollar company do that? > For your private server, sure it's probably fine. But how do you know > that those files are not contaminated? > (That being said, the purpose of that service is good. And the files > there a most probably 100% fine. But if it's not official... then..) As long as I have reliable checksums that match the what the upstream = source says is the real thing, it doesn't practically matter where I get = my images from. -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:51:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE631106566B; Tue, 20 Dec 2011 09:51:41 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0258FC12; Tue, 20 Dec 2011 09:51:40 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so2581487wib.13 for ; Tue, 20 Dec 2011 01:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eZXzKbhJ/aJknufgoUTuGgSuDXqIapHqOQEL7vQhu4k=; b=j4u6NEKLCDEzdH9jBfkKHZsqJUCIJxJVxh2TOHVK67tNhTyXyRG1/VebqEzTm30iXO 8QPEHxCxHDfiqOr/8iruMylRUKZexA6K5PoHekfmSaGj+hbhBKQMbmyen6dT5QacLOwQ rLGs7ItwAbRn1ZcH/qyG7noESUMQplM9Fth04= Received: by 10.180.19.138 with SMTP id f10mr3861498wie.3.1324374700162; Tue, 20 Dec 2011 01:51:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.57.82 with HTTP; Tue, 20 Dec 2011 01:51:19 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> From: Christer Solskogen Date: Tue, 20 Dec 2011 10:51:19 +0100 Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Edho Arief , freebsd-performance@freebsd.org, Alexander Yerenkow , FreeBSD Stable Mailing List , Current FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:51:42 -0000 On Tue, Dec 20, 2011 at 10:42 AM, Garrett Cooper wrote: > > As long as I have reliable checksums that match the what the upstream source says is the real thing, it doesn't practically matter where I get my images from. Checksums compared to what? How would you know what the correct checksums for OpenBSD-current is, if it's not built by Theo? -- chs, From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:55:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D7881065672; Tue, 20 Dec 2011 09:55:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8FE58FC1A; Tue, 20 Dec 2011 09:55:36 +0000 (UTC) Received: by ghrr16 with SMTP id r16so941401ghr.13 for ; Tue, 20 Dec 2011 01:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MDysFyqsbkr7dTfBbRyLi93e+kOxXhoDK8XikFwcsuw=; b=weev6e8nHr19Ba5tb2NpTCt1YkeMK7K7ikWTq2c5gcqiM3jNyr5/3W+CZRKrhWvWQ7 uvODo6d7Lv3xmHXM9iSOBErvHWqyWJEIOhg0IgLBWOl9zt5cg3HP6wN2Ei3NImOZ2nRz NDKr9U2qgnCICg7W+iORdF4PnaYX8EwN/nIq8= Received: by 10.236.175.72 with SMTP id y48mr2291729yhl.17.1324374936200; Tue, 20 Dec 2011 01:55:36 -0800 (PST) Received: from starr-wireless.local (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id m38sm3707595anq.16.2011.12.20.01.55.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 01:55:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Tue, 20 Dec 2011 01:55:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> To: Christer Solskogen X-Mailer: Apple Mail (2.1084) Cc: Edho Arief , freebsd-performance@freebsd.org, Alexander Yerenkow , FreeBSD Stable Mailing List , Current FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:55:37 -0000 On Dec 20, 2011, at 1:51 AM, Christer Solskogen wrote: > On Tue, Dec 20, 2011 at 10:42 AM, Garrett Cooper = wrote: >>=20 >> As long as I have reliable checksums that match the what the upstream = source says is the real thing, it doesn't practically matter where I get = my images from. >=20 > Checksums compared to what? How would you know what the correct > checksums for OpenBSD-current is, if it's not built by Theo? Release engineering for FreeBSD produces SHA256 checksums for = all official releases. AFAIK though they're only in the announcement = emails and not stored anywhere else. I can't speak for OpenBSD's release process. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:01:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1DE1065670 for ; Tue, 20 Dec 2011 10:01:20 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by mx1.freebsd.org (Postfix) with ESMTP id A8AFC8FC12 for ; Tue, 20 Dec 2011 10:01:18 +0000 (UTC) Received: from localhost ([109.223.129.60]) by mwinf5d30 with ME id BN1G1i00C1JKkXh03N1HtH; Tue, 20 Dec 2011 11:01:17 +0100 Message-ID: <4EF05CEC.6080603@orange.fr> Date: Tue, 20 Dec 2011 11:01:16 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.24) Gecko/20111114 Thunderbird/3.1.16 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Is the svn2cvs gateway down ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:01:20 -0000 Hi, It seems (from my own csup's and cvswe.cgi) that the src commits are lost, starting with r228697 Sun Dec 18 22:04:55 2011) What is going on (or off) ? Claude Buisson From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:07:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03531065673 for ; Tue, 20 Dec 2011 10:07:13 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by mx1.freebsd.org (Postfix) with SMTP id 691898FC22 for ; Tue, 20 Dec 2011 10:07:13 +0000 (UTC) Received: from [98.139.212.148] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2011 10:07:12 -0000 Received: from [98.139.211.160] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2011 10:07:12 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 20 Dec 2011 10:07:12 -0000 X-Yahoo-Newman-Id: 622425.95073.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Nm.s6asVM1n2rD75Qct_2AMBeiPHN2ANIpV0SUzV6awPdav xql8.NTCAB836kbqGaT4ScB5WmiFiksChF.MNbQhVrhJ_YLyxSvtcq8LSVBa DOXPWmz2gqYZ357pg7qQd.J5XTU7plwAHfJnAbgjDhcnjA_Qko99U3v75kGH ChvvI7kuUyai5MjWTdmWqflxUD.85ppyllEqrWzA5gpre8.J7jqmF1hoQgZT 2XVzRHp6l7pu.66ZCniT8LpHSybzGXSB_5uixKIl47XydYZX8MkIqM9kn5d4 ghl6j2qD7lM96ChWR21X6FcrYjaNzQZZ2uYQTkwPgfBIcS.cIkR_4dFG7O.B fF_kknJsGcGJhJH91F.2uWCDDR8p7ZHnzX1VB.Od5URP_ZHU1AilwmtmqCl9 5MoWRi4X.LV2IY9mw X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.153.254 with plain) by smtp217.mail.bf1.yahoo.com with SMTP; 20 Dec 2011 02:07:12 -0800 PST Message-ID: <4EF05E4C.5090702@freebsd.org> Date: Tue, 20 Dec 2011 11:07:08 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Reifenberger References: <4EEF488E.1030904@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:07:14 -0000 Am 19.12.2011 17:36, schrieb Michael Reifenberger: > Hi, > a quick test using `dd if=/dev/zero of=/test ...` shows: > > dT: 10.004s w: 10.000s filter: ^a?da?.$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 378 0 0 12.5 376 36414 11.9 60.6| ada0 > 0 380 0 0 12.2 378 36501 11.8 60.0| ada1 > 0 382 0 0 7.7 380 36847 11.6 59.2| ada2 > 0 375 0 0 7.4 374 36164 9.6 51.3| ada3 > 0 377 0 1 10.2 375 36325 10.1 53.3| ada4 > 10 391 0 0 39.3 389 38064 15.7 80.2| ada5 > > Seems to be sufficiently equally distributed for a life system... Hi Michael, in an earlier reply I mentioned the suspicious queue length and %busy of ada5, which may be the result of other load (not caused by the dd command) or of a hardware problem (I'd check drive health ...). (Hmmm, the numbers look strange: ops/s is not the sum of r/s and w/s, but misses that value by 2. I could understand a rounding difference of 1, but not 2 counts per second. But this is a different issue ...) Anyway: The imbalance that I observe on my system is specific to reads, not writes. Could you please check, whether sending a large (multi-GB) file to /dev/null shows identical read load over all drives? I suspect that 2 of the drives will see slightly (some 20%, perhaps) less read requests than the rest. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:39:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C4B1106564A for ; Tue, 20 Dec 2011 10:39:53 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAC28FC13 for ; Tue, 20 Dec 2011 10:39:52 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBKAdebw025066 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 20 Dec 2011 12:39:45 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF065EB.5090601@digsys.bg> Date: Tue, 20 Dec 2011 12:39:39 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:39:53 -0000 On 20.12.11 11:42, Garrett Cooper wrote: > As long as I have reliable checksums that match the what the upstream > source says is the real thing, it doesn't practically matter where I > get my images from. Relying on checksums that are published on the same web site where you download the files from and given that most of these sites do not even use SSL.... so much about 'security'. Daniel From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:50:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF2C106566C for ; Tue, 20 Dec 2011 10:50:23 +0000 (UTC) (envelope-from cochard@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 9DEB38FC0C for ; Tue, 20 Dec 2011 10:50:23 +0000 (UTC) Received: by qabg14 with SMTP id g14so4724918qab.13 for ; Tue, 20 Dec 2011 02:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=yJlXDoOx4xHn4XHUBnvVQ6qwX1UyBLYIjFj2YUCh+jo=; b=s0aG3xyriHmBqVXcP82WndF7OdTMRcF8qjUQyeXwR88Q3YH01DEWKxL8i8s12k8ZfN 4xSK5Bf0zc6/M1UJu4PdBQw2ojmxQfduFQjSUMy9H0mJmHhBB9MVH9WdBpHxss+1AmcS qZSxxQY7QEnomTD+XJLlPzuY1t06vr5H3sshE= Received: by 10.224.107.200 with SMTP id c8mr1562935qap.18.1324376363438; Tue, 20 Dec 2011 02:19:23 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.229.83.148 with HTTP; Tue, 20 Dec 2011 02:19:02 -0800 (PST) In-Reply-To: <20111219224545.GA22631@onelab2.iet.unipi.it> References: <20111219224545.GA22631@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 20 Dec 2011 11:19:02 +0100 X-Google-Sender-Auth: -F3CAAv8-Ea17X42GsuOUOM7c8o Message-ID: To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:50:23 -0000 On Mon, Dec 19, 2011 at 11:45 PM, Luigi Rizzo wrote: > > On a related topic, does anyone have experience on cross-building > nanobsd images ? Hi Luigi, I using "little" cross-building nanobsd images (i386 on amd64 and vice versa). All my patchs for nanobsd are available on BSD Router Project (http://bsdrp.net) including a patch for compiling ports from nanobsd too. Right now I'm working on adding cross-build mips (RouterStation Pro) nanobsd patch but without the "compiling ports" feature, because I can only cross-compile word/kernel and I didn't know how to cross-compile ports. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 11:46:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20813106564A for ; Tue, 20 Dec 2011 11:46:54 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by mx1.freebsd.org (Postfix) with SMTP id F322F8FC1D for ; Tue, 20 Dec 2011 11:46:53 +0000 (UTC) Received: from [98.139.91.65] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 20 Dec 2011 11:46:53 -0000 Received: from [208.71.42.193] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 20 Dec 2011 11:45:53 -0000 Received: from [127.0.0.1] by smtp204.mail.gq1.yahoo.com with NNFMP; 20 Dec 2011 11:45:53 -0000 X-Yahoo-Newman-Id: 384385.72963.bm@smtp204.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xuowPBAVM1mdX.fF1oalsu9xmQfKPqOSJGToJy6FcoLJFGE pinKueq2.uKMFTzTFCdwc8.L45IT4l72.xIHJybCQhwJePabMgjUqbNMCJ_H 4c8jpu1hx8DcWPiISbZossCLfiW_UdzIm3KSl0LN6B_tTNkbZyvnvGH9IaVT lvd1ZRcBOXO6TWLj59NsQqHiMptF2n2JeB9jMYZXGY24LpUFZwxc3lA_bcmq d2Rn4nLLK80i5Nsx58Zyp4deDHiGewnvHVXzCdM.NLEAftV0yFyXonBRYKAb fKLH_ABP9YlV7OPZFmhgRbO5wTOpDg04aFEhlFJd14hwvEP243FHIRwNOTmA 7uCVpfoxpUEBECx4buQSn8iNSutm3vjRTfVe89hOZBTjykCvxgZo6KnWNRn8 mqd6LWvJRbyF7zn0- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.153.254 with plain) by smtp204.mail.gq1.yahoo.com with SMTP; 20 Dec 2011 03:45:52 -0800 PST Message-ID: <4EF0756C.3030804@freebsd.org> Date: Tue, 20 Dec 2011 12:45:48 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dan Nelson References: <4EEF488E.1030904@freebsd.org> <20111219162220.GK53453@dan.emsphone.com> <4EEFA05E.7090507@freebsd.org> <20111219215317.GL53453@dan.emsphone.com> In-Reply-To: <20111219215317.GL53453@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 11:46:54 -0000 Am 19.12.2011 22:53, schrieb Dan Nelson: > In the last episode (Dec 19), Stefan Esser said: >> pool alloc free read write read write >> ---------- ----- ----- ----- ----- ----- ----- >> raid1 4.41T 2.21T 139 72 12.3M 818K >> raidz1 4.41T 2.21T 139 72 12.3M 818K >> ada0p2 - - 114 17 4.24M 332K >> ada1p2 - - 106 15 3.82M 305K >> ada2p2 - - 65 20 2.09M 337K >> ada3p2 - - 58 18 2.18M 329K >> >> The same difference of read operations per second as shown by gstat ... > > I was under the impression that the parity blocks were scattered evenly > across all disks, but from reading vdev_raidz.c, it looks like that isn't > always the case. See the comment at the bottom of the > vdev_raidz_map_alloc() function; it looks like it will toggle parity between > the first two disks in a stripe every 1MB. It's not necessarily the first Thanks, this is very interesting information, indeed. I observed the problem when minidlna rebuild its index database, which scans all media files, many of them GBytes in length and sequentially written. This is a typical scenario that should trigger the code you point at. The comment explains that an attempt has been made to spread the (read) load more evenly, if large files are sequentially written: * If all data stored spans all columns, there's a danger that parity * will always be on the same device and, since parity isn't read * during normal operation, that that device's I/O bandwidth won't be * used effectively. We therefore switch the parity every 1MB. But they later found, that they failed to implement a good solution: * ... at least that was, ostensibly, the theory. As a practical * matter unless we juggle the parity between all devices evenly, we * won't see any benefit. Further, occasional writes that aren't a * multiple of the LCM of the number of children and the minimum * stripe width are sufficient to avoid pessimal behavior. But I do not understand the reasoning behind: * Unfortunately, this decision created an implicit on-disk format * requirement that we need to support for all eternity, but only * for single-parity RAID-Z. I see how the devidx and offset are swapped between col[0] and col[1], and it appears that this swapping is not explicitly reflected in the meta data. But there is no reason, that the algorithm could not be modified to cover all drives, if some flag is set (which effectively would lead to a 2nd generation raidz1 with incompatible block layout). Anyway, I do not think that the current behavior is so bad, that it needs immediate fixing. > two disks assigned to the zvol, since stripes don't have to span all disks > as long as there's one parity block (a small sync write may just hit two > disks, essentially being written mirrored). The imbalance is only visible > if you're writing full-width stripes in sequence, so if you write a 1TB file > in one long stream, chances are that that file's parity blocks will be > concentrated on just two disks, so those two disks will get less I/O on > later reads. I don't know why the code toggles parity between just the > first two columns; rotating it between all columns would give you an even > balance. Yes, but as the comment indicates, this would require introduction of a different raidz1 (a higher ZFS revision or a flag could trigger that). > Is it always the last two disks that have less load, or does it slowly > rotate to different disks depending on the data that you are reading? An > interesting test would be to idle the system, run a "tar cvf /dev/null > /raidz1" in one window, and watch iostat output on another window. If the > load moves from disk to disk as tar reads different files, then my parity > guess is probably right. If ada0 and ada1 are always busier, than you can > ignore me :) Yes, you are perfectly right! I tested the tar on a spool directory holding DVB-C recordings (typical files length 2GB to 8GB). The dT: 10.001s w: 10.000s filter: ^a?da?.$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 935 921 40216 0.4 13 139 0.5 32.8| ada0 0 927 913 36530 0.3 13 108 1.5 31.8| ada1 0 474 460 20110 0.7 14 141 0.9 32.4| ada2 0 474 461 20102 0.7 13 141 0.7 31.6| ada3 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 1046 1041 45503 0.3 5 35 0.9 31.5| ada0 0 1039 1035 41353 0.3 4 23 0.4 31.6| ada1 0 531 526 22827 0.6 5 38 0.4 33.4| ada2 1 523 518 22772 0.6 5 38 0.6 30.8| ada3 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 384 377 16414 0.8 7 46 3.3 30.2| ada0 0 380 373 15857 0.8 6 42 0.4 30.5| ada1 0 553 547 23937 0.5 6 47 1.7 28.0| ada2 1 551 545 22004 0.6 6 38 0.7 32.2| ada3 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 667 656 28633 0.4 11 123 0.6 29.6| ada0 1 660 650 26010 0.5 10 109 0.6 33.4| ada1 0 338 327 14328 0.8 11 126 0.9 25.7| ada2 0 339 328 14303 1.0 11 120 1.0 32.7| ada3 $ iostat -d -n4 3 ada0 ada1 ada2 ada3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 44.0 860 36.94 40.0 860 33.60 44.0 429 18.44 44.0 431 18.50 43.9 814 34.86 39.9 813 31.67 43.8 408 17.45 43.7 408 17.44 43.4 900 38.10 39.4 899 34.64 42.5 463 19.18 42.7 459 19.14 44.0 904 38.86 40.0 904 35.33 44.0 453 19.44 44.0 452 19.42 ! 43.1 571 24.01 41.5 571 23.17 43.4 799 33.85 40.0 801 31.27 ! 44.0 461 19.79 44.0 460 19.74 44.0 920 39.52 40.0 920 35.93 ! 43.9 435 18.65 43.9 435 18.68 44.0 868 37.29 40.0 868 33.91 ! 42.8 390 16.29 42.8 390 16.28 43.4 765 32.42 39.4 767 29.48 ! 44.0 331 14.22 44.0 329 14.12 44.0 659 28.32 40.0 659 25.75 ! 41.8 332 13.55 42.1 326 13.38 42.9 640 26.84 39.0 640 24.38 44.0 452 19.40 42.2 451 18.58 44.0 597 25.66 40.7 595 23.65 = 42.3 589 24.33 39.8 585 22.75 42.1 562 23.14 39.7 561 21.77 = 43.0 569 23.93 40.8 570 22.72 43.0 641 26.95 40.1 642 25.14 44.0 709 30.48 40.9 710 28.41 44.0 607 26.10 41.8 606 24.73 44.0 785 33.73 40.6 784 31.07 44.0 567 24.36 42.4 568 23.50 44.0 899 38.62 40.0 899 35.11 44.0 449 19.30 44.0 450 19.32 44.0 881 37.87 40.0 881 34.43 44.0 441 18.94 44.0 441 18.93 43.4 841 35.61 39.4 841 32.37 42.7 428 17.87 42.7 428 17.84 Hmmm, looking back through hundreds of lines of iostat output I see that ada0 and ada1 see similar request rates, as do ada2 and ada3. But I know that I also observed other combinations on earlier tests (with different data?). > Since it looks like the algorithm ends up creating two half-cold parity > disks instead of one cold disk, I bet a 3-disk RAIDZ would exhibit even > worse balancing, and a 5-disk set would be more even. Yes, this sounds very reasonable. Some iostat results were posted for a 6 disk raidz1, but they were for writes, not reads. I've kept the 3*1TB drives that formed the pool before I replaced them by 4*2TB. I can create a 3 drive raidz1 on them and perform some tests ... BTW: Read throughput in the tar test was far lower than I had expected. The CPU load was 3% user and some 0,2 system time (on an i2600K) and the effective transfer speed of the RAID was only some 115MB/s. The pool has 1/3 empty space and the test files were written in one go and should have been layed out in an optimal way. A dd of a large file (~10GB) gives similar results, independently of the block size (128k vs. 1m). Transfer sizes were only 43KB on average, which matches MAXPHYS=128KB distributed over 3 drives (plus parity in case of writes). This indicates, that in order to be able to read MAXPHYS bytes from each drive, the original request size should have covered 3*MAXPHYS. But the small transfer length does not seem to be the cause of the low transfer rate: # dd if=/dev/ada2p2 of=/dev/null bs=10k count=10000 10000+0 records in 10000+0 records out 102400000 bytes transferred in 0.853374 secs (119994281 bytes/sec) # dd if=/dev/ada1p2 of=/dev/null bs=2k count=50000 50000+0 records in 50000+0 records out 102400000 bytes transferred in 2.668089 secs (38379531 bytes/sec) Even a block size of 2KB will result in 35-40MB/s read throughput ... Any idea, why the read performance is so much lower than possible given the hardware? Regards, STefan From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 11:50:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1254106566B for ; Tue, 20 Dec 2011 11:50:44 +0000 (UTC) (envelope-from io.chir0n@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 713A58FC15 for ; Tue, 20 Dec 2011 11:50:43 +0000 (UTC) Received: by yhfq46 with SMTP id q46so5484518yhf.13 for ; Tue, 20 Dec 2011 03:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=kswvVXvpvpEhlaMR5hKo58MehrpqEG/kp/hDtEVk/20=; b=AytZLUxDYhSThZfODmPhmcbgTrIsWLBOpDjod487maHmwabWR1+6QjgyXz0In0O7Jh oGKKNIJ+UQuiAoI3TlljRtnN8xWPpnnrrGpcSN/EwwUb0B8+fpekPxzDBfcMCxg/2fZT Pd1GL4Oibv8O/2YQaz1DIhShOd+SlEzQfAydc= Received: by 10.236.76.201 with SMTP id b49mr2072338yhe.11.1324380475394; Tue, 20 Dec 2011 03:27:55 -0800 (PST) Received: from [192.168.0.41] ([201.22.249.146]) by mx.google.com with ESMTPS id r68sm2711462yhm.18.2011.12.20.03.27.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 03:27:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Chiron IO In-Reply-To: Date: Tue, 20 Dec 2011 09:28:47 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28E4047A-356A-4CCE-A134-9B24A7444806@gmail.com> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF3FF9.7070307@digsys.bg> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 11:50:44 -0000 Guys, I have a question about these benchmarks. Why worry about that if the CURRENT comes with debug enabled by default? = http://joaobarros.blogspot.com/2005/07/freebsd-how-to-turn-off-debug-optio= ns.html On 19/12/2011, at 22:28, Petro Rossini wrote: > Hi all, >=20 > just a thought here: >=20 > On Tue, Dec 20, 2011 at 12:45 AM, Daniel Kalchev = wrote: >>> As were told, Phoronix used "default" setup, not tuned. >> Not really. They created some weird test environment, at least for = FreeBSD >> -- who knows, possibly for Linux as well. >>=20 >> For example, ZFS is by no means a default file system in FreeBSD. You = need >> to go trough manual steps, to enable it, to build the pool, = filesystems etc. >=20 > .. >=20 > Of course the benchmark setup and procedure is strange but.. >=20 > it could be improved, I think. >=20 > Have a good collection of tuning parameters for "popular cases", > advertised properly so it gets hard "to miss them". >=20 > I am a sysadmin and, over the years, I had to run file servers, > database servers, web servers, tomcats... >=20 > Well, most of the time I set it up and "it just works" because the > system in question is not maxed out, not even close to it. >=20 > But if I want to squeeze the last 20% out of it googling starts, and > here and there I find hints how to tune the OS, the file system, what > scheduler to use etc. >=20 > It would be great to have a set of case studies at hand, e.g. under > the /usr/share/examples directory, that describes tweaks to have a > performing postgresql server, or mysql, or apache or a desktop or.. >=20 > Things I find, for example, in the BSD Magazine. >=20 > Maybe benchmarks become more meaningful then.. >=20 > A general remark for people doing benchmarks for comparison: you need > a well-informed system engineer for the systems you compare. So, if > you compare a Linux system with FreeBSD, have two experienced admins > that know their OS well. >=20 > Regards > Peter > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 12:25:29 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BF971065676; Tue, 20 Dec 2011 12:25:29 +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 35FF98FC13; Tue, 20 Dec 2011 12:25:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29815; Tue, 20 Dec 2011 14:25:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rcyl1-000JIh-47; Tue, 20 Dec 2011 14:25:23 +0200 Message-ID: <4EF07EB0.9000209@FreeBSD.org> Date: Tue, 20 Dec 2011 14:25:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> In-Reply-To: <201112191530.40526.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 12:25:29 -0000 Now the juicy stuff :) on 19/12/2011 16:30 Hans Petter Selasky said the following: >> 3. Looking at usbd_transfer_poll I see that it touches a lot of locks, >> including taking the bus lock. As we've discussed before, this is not safe >> in a particular context where the polling is supposed to be used - in the >> kdb/ddb context. If the lock is already taken by another thread, then >> instead of being able to use a USB keyboard a user would get even less >> debug-able crash. Also, it seems that usbd_transfer_poll calls into the >> usual state machine with various callbacks and dynamically made decisions >> about whether to execute some actions directly or defer their execution to >> a different thread. > > This is an optimisation. If the current thread can do the job without a LOR, > then we do it right away. Else we let another thread do it. It is possible to > have a more simple model, but then you will also get more task switches. I think that you are speaking here about the code behavior in the general context. And I want to limit this part of discussion to the contexts where usbd_transfer_poll is actually used - kdb and panic. In those contexts there is one and only one thread that must do all the work. Other threads are stopped and "frozen" in the middle of whatever they were doing before kdb was entered or panic called (provided SCHEDULER_STOPPED() == true). >> That code also touches locks in various places. I >> think that it would be more preferable to have a method that does the job >> in a more straight-forward way, without touching any locks, ignoring the >> usual code paths and assuming that no other treads are running in >> parallel. Ditto for the method to submit a request. > > The current USB code can be run fine without real locks, if you do a few > tricks. I have a single-threaded BSD-kernel replacement for this which works > like a charm for non-FreeBSD projects. That's very cool. I believe that various implementations of USB stack for BIOS and similar are also non-threaded. > I'm going to paste a few lines FYI: > > Why not extend "struct mtx" to have two fields which are only used in case of > system polling (no scheduler running): > > struct mtx { > xxx; > int owned_polling = 0; > struct mtx *parent_polling; > }; > > void > mtx_init(struct mtx *mtx, const char *name, const char *type, int opt) > { > mtx->owned = 0; > mtx->parent = mtx; > } > > void > mtx_lock(struct mtx *mtx) > { > mtx = mtx->parent; > mtx->owned++; > } > > void > mtx_unlock(struct mtx *mtx) > { > mtx = mtx->parent; > mtx->owned--; > } > > int > mtx_owned(struct mtx *mtx) > { > mtx = mtx->parent; > return (mtx->owned != 0); > } > > void > mtx_destroy(struct mtx *mtx) > { > /* NOP */ > } > > Maybe mtx_init, mtx_lock, mtx_unlock mtx_owned, mtx_destroy, etc, could be > function pointers, which are swapped at panic. I am not sure if I got your idea right based on the pseudo-code above. Right now in the head we already skip all locks when SCHEDULER_STOPPED() is true. But, but, that doesn't cover all polling cases as the automatic lock skipping is _not_ done for kdb. There are various reasons for that. That's why the kdb_active flag should be checked by the code that can be executed in the kdb context when dealing with locking or shared resources in general. > USB is SMP! Right and that's good, but there are cases where SMP is effectively stopped. Those are panic and kdb. > To run SMP code from a single thread, you need to create a > hiherachy of the threads: > > 1) Callbacks (Giant) > 2) Callbacks (non-Giant) > 3) Control EP (non-Giant) > 4) Explore thread (non-Giant) > > When the explore thread is busy, we look for work in the level above and so > on. The USB stack implements this principle, which is maybe not documented > anywhere btw. If you want more than code, you can hire me to do that. > > The mtx-code above I believe is far less work than to make new code which > handles the polling case only. > > The reason for the parent mutex field, is to allow easy grouping of mutexes, > so that USB easily can figure out what can run or not. This all is really above my level of knowledge. Basically my current intention is the following: make ukbd/usb code work in panic+SCHEDULER_STOPPED case in the same way (or not worse, at least) as it currently works for the kdb case. I don't have enough knowledge (and time) to go beyond that. I just wanted to draw your attention to the fact that obtaining any locks in the kdb context (or USB polling code in general, even) is not a good idea. Chances of getting into trouble on those locks are probably quite moderate or even low, but they do exist. I am not sure if you are getting any bug reports about such troubles :-) Regular users probably do not use kdb too often and a panic for them is just a "crash", so they likely do not expect anything usable/debuggable after that :-) P.S. Since most (but not all) locking operations in the USB code are already wrapped under USB-specific macros, then probably it could make sense to implement your suggestion locally to the USB code. Just need to take some care to cover the cases that are not wrapped yet (direct calls to mtx_lock and similar) and to handle cases where important decisions are made based on mtx_owned return value (especially in loops). For example, below are some macros that I want to use in the ukbd code: #define KBD_LOCK() \ do { \ if (!kdb_active) \ mtx_lock(&Giant); \ } while (0) #define KBD_UNLOCK() \ do { \ if (!kdb_active) \ mtx_unlock(&Giant); \ } while (0) #ifdef INVARIANTS #define KBD_LOCK_ASSERT() \ do { \ if (!cold && !kdb_active && panicstr == NULL) \ mtx_assert(&Giant, MA_OWNED); \ } while (0) #else #define KBD_LOCK_ASSERT() (void)0 #endif P.P.S. Did you have a chance to look at http://wiki.freebsd.org/AvgSyscons yet? Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:13:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805501065677; Tue, 20 Dec 2011 10:13:16 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 36AC28FC27; Tue, 20 Dec 2011 10:13:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rcwh8-0002vm-Vg>; Tue, 20 Dec 2011 11:13:15 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rcwh8-0005bj-SA>; Tue, 20 Dec 2011 11:13:14 +0100 Message-ID: <4EF05FBA.8030303@mail.zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 11:13:14 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD , FreeBSD Stable Mailing List X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8F543234D0CFDE0730DB881A" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 20 Dec 2011 12:38:16 +0000 Cc: Subject: x11/sessreg: build fails with CLANG in FreeBSD 9.0-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:13:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F543234D0CFDE0730DB881A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On a freshly updated box the installation of x11/sessreg fails with the shown message below. On all boxes I run with FBSD 9 or 10 (all amd64, CLANG build) the build and installation works fine. Since I update the box from 8.2-STABLE to 9.0-PRE last night, cleaning up all ports and having them rebuilt from scratch, I guess I have a problem with remnants (or missing compatibility?) in the system. Where to start looking? ttyslot looks like a base system function. Regards, thanks in advance, Oliver =3D=3D=3D> Building for sessreg-1.0.7 /usr/bin/make all-recursive Making all in man GEN filenames.sed GEN sessreg.1 CC sessreg.o sessreg.c:281:27: warning: implicit declaration of function 'ttyslot' is invalid in C99 [-Wimplicit-function-declaration] sysnerr (slot_number =3D ttyslot (), "ttyslot"); ^ 1 warning generated. CCLD sessreg sessreg.o: In function `main': sessreg.c:(.text+0x7bf): undefined reference to `ttyslot' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. *** Error code 1 Stop in /usr/ports/x11/sessreg. --------------enig8F543234D0CFDE0730DB881A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7wX7oACgkQU6Ni+wtCKv+2bgD/Tv1Cz6LAL79PZ1XnB1u54N3x Vmc0ZQ4VvWUCDufkN5kA/1LqUnO+FMRNqCw8TIjyJ+wQro/lgPRFnWk3NTfeDl3I =LTAu -----END PGP SIGNATURE----- --------------enig8F543234D0CFDE0730DB881A-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 10:32:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74ABF106564A; Tue, 20 Dec 2011 10:32:25 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4B38FC14; Tue, 20 Dec 2011 10:32:24 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rcwzg-0000pb-6K>; Tue, 20 Dec 2011 11:32:24 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rcwzg-0006wJ-3B>; Tue, 20 Dec 2011 11:32:24 +0100 Message-ID: <4EF06432.8020001@mail.zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 11:32:18 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD , FreeBSD Stable Mailing List References: <4EF05FBA.8030303@mail.zedat.fu-berlin.de> In-Reply-To: <4EF05FBA.8030303@mail.zedat.fu-berlin.de> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0F2296DBBA2AA2D47BD9FF1A" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 20 Dec 2011 12:38:32 +0000 Cc: Subject: Re: x11/sessreg: build fails with CLANG in FreeBSD 9.0-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 10:32:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F2296DBBA2AA2D47BD9FF1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/20/11 11:13, O. Hartmann wrote: > On a freshly updated box the installation of x11/sessreg fails with the= > shown message below. > On all boxes I run with FBSD 9 or 10 (all amd64, CLANG build) the build= > and installation works fine. >=20 > Since I update the box from 8.2-STABLE to 9.0-PRE last night, cleaning > up all ports and having them rebuilt from scratch, I guess I have a > problem with remnants (or missing compatibility?) in the system. >=20 > Where to start looking? ttyslot looks like a base system function. >=20 >=20 > Regards, thanks in advance, > Oliver >=20 > =3D=3D=3D> Building for sessreg-1.0.7 > /usr/bin/make all-recursive > Making all in man > GEN filenames.sed > GEN sessreg.1 > CC sessreg.o > sessreg.c:281:27: warning: implicit declaration of function 'ttyslot' i= s > invalid in C99 [-Wimplicit-function-declaration] > sysnerr (slot_number =3D ttyslot (), "ttyslot")= ; > ^ > 1 warning generated. > CCLD sessreg > sessreg.o: In function `main': > sessreg.c:(.text+0x7bf): undefined reference to `ttyslot' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 >=20 > Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. > *** Error code 1 >=20 > Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. > *** Error code 1 >=20 > Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.7. > *** Error code 1 >=20 > Stop in /usr/ports/x11/sessreg. Sorry for the noise. As I gave myself the answer, some remnants polluted the system and I got rid by simply call the propper make delete-old-libs/files in /usr/src. Oliver --------------enig0F2296DBBA2AA2D47BD9FF1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7wZDgACgkQU6Ni+wtCKv+23gD9Fngc8YG5GliCNSv4BcTLbJAm hIFms0fnaaI1UrOt4fcA/27ei3GiuGsokHWF4ItTjnslKi1hBk3uMCNHCjhzXo2Q =nDF7 -----END PGP SIGNATURE----- --------------enig0F2296DBBA2AA2D47BD9FF1A-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 13:46:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069B41065675 for ; Tue, 20 Dec 2011 13:46:05 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id B53578FC0A for ; Tue, 20 Dec 2011 13:46:03 +0000 (UTC) Received: from vhoffman-macbooklocal.local ([10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id pBKDk1Wf064926 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 20 Dec 2011 13:46:02 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4EF0919A.3040003@unsane.co.uk> Date: Tue, 20 Dec 2011 13:46:02 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EF065EB.5090601@digsys.bg> In-Reply-To: <4EF065EB.5090601@digsys.bg> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:46:05 -0000 On 20/12/2011 10:39, Daniel Kalchev wrote: > > > On 20.12.11 11:42, Garrett Cooper wrote: >> As long as I have reliable checksums that match the what the upstream >> source says is the real thing, it doesn't practically matter where I >> get my images from. > > Relying on checksums that are published on the same web site where you > download the files from and given that most of these sites do not even > use SSL.... so much about 'security'. > This does remind me of one issue that while a little off topic for this thread.... If i wanted to get, for example the SHA265 checksums from a verified source, how would i verify this currently? There doesnt seem to be an SSL site for www.freebsd.org and its not too hard to redirect someone to a fake website. What would be a more reasonable list to request this on? Vince > Daniel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 13:52:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D412A106564A; Tue, 20 Dec 2011 13:52:25 +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 93AAB8FC18; Tue, 20 Dec 2011 13:52:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2FA9846B09; Tue, 20 Dec 2011 08:52:25 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7D32DB955; Tue, 20 Dec 2011 08:52:24 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2011 08:52:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112200852.23300.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 08:52:24 -0500 (EST) Cc: Robert Watson , mdf@freebsd.org, "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:52:26 -0000 On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: > On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote: > > On Sun, 18 Dec 2011 01:09:00 +0100 > > "O. Hartmann" wrote: > > > >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock > >> panic: sleeping thread > >> cpuid = 0 > >> > >> PID 16 is always USB on my box. > > > > You really need to give us a backtrace when you quote panics. It is > > impossible to make any sense of the above panic message without more > > context. > > In the case of this panic, the stack of the thread which panics is > useless; it's someone trying to propagate priority that discovered it. > A backtrace on tid 100033 would be useful. > > With WITNESS enabled, it's possible to have this panic display the > stack of the incorrectly sleeping thread at the time it acquired the > lock, as well, but this code isn't in CURRENT or any release. I have > a patch at $WORK I can dig up on Monday. Huh? The stock kernel dumps a stack trace of the offending thread if you have DDB enabled: /* * If the thread is asleep, then we are probably about * to deadlock. To make debugging this easier, just * panic and tell the user which thread misbehaved so * they can hopefully get a stack trace from the truly * misbehaving thread. */ if (TD_IS_SLEEPING(td)) { printf( "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", td->td_tid, td->td_proc->p_pid); #ifdef DDB db_trace_thread(td, -1); #endif panic("sleeping thread"); } It may be that we can make use of the STACK API here instead to output this trace even when DDB isn't enabled. The patch below tries to do that (untested). It does some odd thigns though since it is effectively running from a panic context already, so it uses a statically allocated 'struct stack' rather than using stack_create() and uses stack_print_ddb() since it is holding spin locks and can't possibly grab an sx lock: Index: subr_turnstile.c =================================================================== --- subr_turnstile.c (revision 228534) +++ subr_turnstile.c (working copy) @@ -72,6 +72,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -175,6 +176,7 @@ static void turnstile_fini(void *mem, int size); static void propagate_priority(struct thread *td) { + static struct stack st; struct turnstile *ts; int pri; @@ -217,8 +219,10 @@ propagate_priority(struct thread *td) printf( "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", td->td_tid, td->td_proc->p_pid); -#ifdef DDB - db_trace_thread(td, -1); +#ifdef STACK + stack_zero(&st); + stack_save_td(&st, td); + stack_print_ddb(&st); #endif panic("sleeping thread"); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:00:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25132106564A; Tue, 20 Dec 2011 14:00:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BED1D8FC0A; Tue, 20 Dec 2011 14:00:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA01667; Tue, 20 Dec 2011 16:00:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rd0Eq-000JNY-QV; Tue, 20 Dec 2011 16:00:16 +0200 Message-ID: <4EF094EF.6000005@FreeBSD.org> Date: Tue, 20 Dec 2011 16:00:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> <201112200852.23300.jhb@freebsd.org> In-Reply-To: <201112200852.23300.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mdf@FreeBSD.org, "O. Hartmann" , freebsd-current@FreeBSD.org, Robert Watson Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:00:21 -0000 on 20/12/2011 15:52 John Baldwin said the following: > -#ifdef DDB > - db_trace_thread(td, -1); > +#ifdef STACK > + stack_zero(&st); > + stack_save_td(&st, td); > + stack_print_ddb(&st); > #endif This leads to an idea - what about an umbrella stack_print() that would call the best stack printing routine, if any, based on their availabilities (STACK, DDB, etc?). P.S. Sorry to hijack the thread. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:08:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39D8106566C; Tue, 20 Dec 2011 14:08:58 +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 A8DAE8FC0C; Tue, 20 Dec 2011 14:08:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 4B85146B23; Tue, 20 Dec 2011 09:08:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CAF48B914; Tue, 20 Dec 2011 09:08:57 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2011 08:54:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111218164154.GH67033@glebius.int.ru> In-Reply-To: <20111218164154.GH67033@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201112200854.06897.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:08:57 -0500 (EST) Cc: Alexander Leidinger , Gleb Smirnoff , current@freebsd.org Subject: Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:08:58 -0000 On Sunday, December 18, 2011 11:41:54 am Gleb Smirnoff wrote: > Alexander, > > On Sat, Dec 17, 2011 at 03:08:43PM +0100, Alexander Leidinger wrote: > A> we never had a kernel part in the list. Reinstallkernel is not a valid target after updating the sources. The renaming will only take effekt after updating. And we already hat issues because the list was too long. > A> Your entry for the carp module is completely out of question for this list. Please remove it. > > The file /boot/kernel/if_carp.ko had been installed on older installations. It > is not overwritten now. Thus, it may happen in a some weird case, that it is > left intact. 'make installkernel' is not the only way to upgrade FreeBSD. > To cover these potential cases I have added an entry. This entry doesn't > hurt anybody or anything. 'make installkernel' is the only supported way of upgrading. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:08:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39D8106566C; Tue, 20 Dec 2011 14:08:58 +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 A8DAE8FC0C; Tue, 20 Dec 2011 14:08:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 4B85146B23; Tue, 20 Dec 2011 09:08:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CAF48B914; Tue, 20 Dec 2011 09:08:57 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2011 08:54:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111218164154.GH67033@glebius.int.ru> In-Reply-To: <20111218164154.GH67033@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201112200854.06897.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:08:57 -0500 (EST) Cc: Alexander Leidinger , Gleb Smirnoff , current@freebsd.org Subject: Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:08:58 -0000 On Sunday, December 18, 2011 11:41:54 am Gleb Smirnoff wrote: > Alexander, > > On Sat, Dec 17, 2011 at 03:08:43PM +0100, Alexander Leidinger wrote: > A> we never had a kernel part in the list. Reinstallkernel is not a valid target after updating the sources. The renaming will only take effekt after updating. And we already hat issues because the list was too long. > A> Your entry for the carp module is completely out of question for this list. Please remove it. > > The file /boot/kernel/if_carp.ko had been installed on older installations. It > is not overwritten now. Thus, it may happen in a some weird case, that it is > left intact. 'make installkernel' is not the only way to upgrade FreeBSD. > To cover these potential cases I have added an entry. This entry doesn't > hurt anybody or anything. 'make installkernel' is the only supported way of upgrading. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:09:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D841065675 for ; Tue, 20 Dec 2011 14:09:00 +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 17EE48FC12 for ; Tue, 20 Dec 2011 14:09:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C45FA46B06; Tue, 20 Dec 2011 09:08:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 33F25B93E; Tue, 20 Dec 2011 09:08:59 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2011 09:00:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112200900.39087.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:08:59 -0500 (EST) Cc: Rick Macklem Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:09:00 -0000 On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote: > Hi, > > A recent NFS client crash: > http://glebius.int.ru/tmp/nfs_panic.jpg > appears to have happened because some field is > bogus when crfree() is called. I've asked Gleb > to disassemble crfree() for me, so I can try and > see exactly which field causes the crash, however... > > Basically, the code: > newcred = crdup(cred); > - does read with newcred > crfree(newcred); <-- which crashes at 0x65 into > crfree() > > Looking at crdup(), it calls crcopy(), which copies > 4 pointers and then ref. counts them: > cr_uidinfo, cr_ruidinfo, cr_prison and cr_loginclass > > It seems some lock should be held while crcopy() does this, > so that the pointers don't get deref'd during the copy/ref. count? > (Or is there some rule that guarantees these won't change. ie. No > no calls to change_euid() or similar.) > > Is there such a lock and should crdup() use it? In general the caller of crdup is expected to hold a reference on cred or some other lock to ensure that cred remains valid and cannot be free'd while it is being duplicated. There is no global lock that crdup can hold for that, instead the caller is required to guarantee that. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:12:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33C8C1065676 for ; Tue, 20 Dec 2011 14:12:53 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id E583E8FC14 for ; Tue, 20 Dec 2011 14:12:51 +0000 (UTC) Received: from [195.93.240.5] (port=17673 helo=lissyara.moskb.local) by mx.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RczsS-0004y4-Gi for freebsd-current@freebsd.org; Tue, 20 Dec 2011 16:37:08 +0300 Message-ID: <4EF08F84.4060500@lissyara.su> Date: Tue, 20 Dec 2011 17:37:08 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Current FreeBSD Content-Type: multipart/mixed; boundary="------------010809080106000808030407" X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Subject: regression: Xorg get 100% cpu and freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:12:53 -0000 This is a multi-part message in MIME format. --------------010809080106000808030407 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit I use CURRENT from 2011-11-18 - all OK After update to today - I have problem - on start, Xorg get 100% CPU and freeze (monitor go to turn off) I recompile Xorg, all modules - no happy. I try update x11-drivers/xf86-video-ati to 6.14.3 - no happy If I delete /boot/kernel/drm.ko - all work OK, but very slow... ===== FreeBSD lissyara.moskb.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228726: Tue Dec 20 08:24:56 MSK 2011 root@lissyara.moskb.local:/usr/obj/usr/src/sys/GENERIC amd64 ===== pciconf, Xorg.log with and without drm.ko - in attached files --------------010809080106000808030407 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciconf.txt" hostb0@pci0:0:0:0: class=0x060000 card=0x12ff103c chip=0x79101002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RS690 Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x12ff103c chip=0x79121002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RS690 PCI to PCI Bridge (Internal gfx)' class = bridge subclass = PCI-PCI cap 08[44] = HT MSI fixed address window enabled at 0xfee00000 cap 0d[b0] = PCI Bridge card=0x12ff103c pcib2@pci0:0:7:0: class=0x060400 card=0x12ff103c chip=0x79171002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'RS690 PCI to PCI Bridge (PCI Express Port 3)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[b0] = PCI Bridge card=0x12ff103c cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ecap 0002[100] = VC 1 max VC0 ahci0@pci0:0:18:0: class=0x01018f card=0x2813103c chip=0x43801002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 Non-Raid-5 SATA' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x2130, size 8, enabled bar [14] = type I/O Port, range 32, base 0x2150, size 4, enabled bar [18] = type I/O Port, range 32, base 0x2138, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x2154, size 4, enabled bar [20] = type I/O Port, range 32, base 0x2100, size 16, enabled bar [24] = type Memory, range 32, base 0xd8909000, size 1024, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 ohci0@pci0:0:19:0: class=0x0c0310 card=0x12ff103c chip=0x43871002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB (OHCI0)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8904000, size 4096, enabled ohci1@pci0:0:19:1: class=0x0c0310 card=0x12ff103c chip=0x43881002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB (OHCI1)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8905000, size 4096, enabled ohci2@pci0:0:19:2: class=0x0c0310 card=0x12ff103c chip=0x43891002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB (OHCI2)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8906000, size 4096, enabled ohci3@pci0:0:19:3: class=0x0c0310 card=0x12ff103c chip=0x438a1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB (OHCI3)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8907000, size 4096, enabled ohci4@pci0:0:19:4: class=0x0c0310 card=0x12ff103c chip=0x438b1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB (OHCI4)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8908000, size 4096, enabled ehci0@pci0:0:19:5: class=0x0c0320 card=0x12ff103c chip=0x43861002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 USB Controller (EHCI)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xd8909400, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 none0@pci0:0:20:0: class=0x0c0500 card=0x12ff103c chip=0x43851002 rev=0x13 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SBx00 SMBus Controller' class = serial bus subclass = SMBus bar [10] = type I/O Port, range 32, base 0xfc00, size 16, enabled cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 atapci0@pci0:0:20:1: class=0x01018f card=0x12ff103c chip=0x438c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 IDE' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x2140, size 8, enabled bar [14] = type I/O Port, range 32, base 0x2158, size 4, enabled bar [18] = type I/O Port, range 32, base 0x2148, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x215c, size 4, enabled bar [20] = type I/O Port, range 32, base 0x2120, size 16, enabled hdac0@pci0:0:20:2: class=0x040300 card=0x12ff103c chip=0x43831002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SBx00 Azalia (Intel HDA)' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xd8900000, size 16384, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 isab0@pci0:0:20:3: class=0x060100 card=0x12ff103c chip=0x438d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB600 PCI to LPC Bridge' class = bridge subclass = PCI-ISA pcib3@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc' device = 'SBx00 PCI to PCI Bridge' class = bridge subclass = PCI-PCI hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'K8 [Athlon64/Opteron] HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI cap 08[80] = HT host hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'K8 [Athlon64/Opteron] Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'K8 [Athlon64/Opteron] DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'K8 [Athlon64/Opteron] Miscellaneous Control' class = bridge subclass = HOST-PCI cap 0f[f0] = unknown vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c chip=0x791e1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RS690 [Radeon X1200 Series]' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, size 134217728, enabled bar [18] = type Memory, range 64, base 0xd8500000, size 65536, enabled bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled bar [24] = type Memory, range 32, base 0xd8400000, size 1048576, enabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[80] = MSI supports 1 message, 64 bit bge0@pci0:63:0:0: class=0x020000 card=0x12ff103c chip=0x167b14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5755 Gigabit Ethernet PCI Express' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xd8800000, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[13c] = VC 1 max VC0 ecap 0003[160] = Serial 1 001cc4fffe9877a8 ecap 0004[16c] = unknown 1 --------------010809080106000808030407 Content-Type: text/plain; name="Xorg.0.log_freeze" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Xorg.0.log_freeze" ClguT3JnIFggU2VydmVyIDEuNy43ClJlbGVhc2UgRGF0ZTogMjAxMC0wNS0wNApYIFByb3Rv Y29sIFZlcnNpb24gMTEsIFJldmlzaW9uIDAKQnVpbGQgT3BlcmF0aW5nIFN5c3RlbTogRnJl ZUJTRCA5LjktQ1VSUkVOVCBhbWQ2NCAKQ3VycmVudCBPcGVyYXRpbmcgU3lzdGVtOiBGcmVl QlNEIGxpc3N5YXJhLm1vc2tiLmxvY2FsIDEwLjAtQ1VSUkVOVCBGcmVlQlNEIDEwLjAtQ1VS UkVOVCAjMCByMjI4NzI2OiBUdWUgRGVjIDIwIDA4OjI0OjU2IE1TSyAyMDExICAgICByb290 QGxpc3N5YXJhLm1vc2tiLmxvY2FsOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1k NjQKQnVpbGQgRGF0ZTogMTIgRGVjZW1iZXIgMjAxMSAgMTI6MjQ6MDdQTQogCkN1cnJlbnQg dmVyc2lvbiBvZiBwaXhtYW46IDAuMjQuMAoJQmVmb3JlIHJlcG9ydGluZyBwcm9ibGVtcywg Y2hlY2sgaHR0cDovL3dpa2kueC5vcmcKCXRvIG1ha2Ugc3VyZSB0aGF0IHlvdSBoYXZlIHRo ZSBsYXRlc3QgdmVyc2lvbi4KTWFya2VyczogKC0tKSBwcm9iZWQsICgqKikgZnJvbSBjb25m aWcgZmlsZSwgKD09KSBkZWZhdWx0IHNldHRpbmcsCgkoKyspIGZyb20gY29tbWFuZCBsaW5l LCAoISEpIG5vdGljZSwgKElJKSBpbmZvcm1hdGlvbmFsLAoJKFdXKSB3YXJuaW5nLCAoRUUp IGVycm9yLCAoTkkpIG5vdCBpbXBsZW1lbnRlZCwgKD8/KSB1bmtub3duLgooPT0pIExvZyBm aWxlOiAiL3Zhci9sb2cvWG9yZy4wLmxvZyIsIFRpbWU6IFR1ZSBEZWMgMjAgMTY6NTc6Mjgg MjAxMQooSUkpIExvYWRlciBtYWdpYzogMHg3YmE1MDAKKElJKSBNb2R1bGUgQUJJIHZlcnNp b25zOgoJWC5PcmcgQU5TSSBDIEVtdWxhdGlvbjogMC40CglYLk9yZyBWaWRlbyBEcml2ZXI6 IDYuMAoJWC5PcmcgWElucHV0IGRyaXZlciA6IDcuMAoJWC5PcmcgU2VydmVyIEV4dGVuc2lv biA6IDIuMAooLS0pIFVzaW5nIHN5c2NvbnMgZHJpdmVyIHdpdGggWCBzdXBwb3J0ICh2ZXJz aW9uIDIuMCkKKC0tKSB1c2luZyBWVCBudW1iZXIgOQoKKC0tKSBQQ0k6KigwOjE6NTowKSAx MDAyOjc5MWU6MTAzYzoxMmZmIEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gbmVlIEFU SSBSUzY5MCBbUmFkZW9uIFgxMjAwIFNlcmllc10gcmV2IDAsIE1lbSBAIDB4ZDAwMDAwMDAv MTM0MjE3NzI4LCAweGQ4NTAwMDAwLzY1NTM2LCAweGQ4NDAwMDAwLzEwNDg1NzYsIEkvTyBA IDB4MDAwMDExMDAvMjU2LCBCSU9TIEAgMHg/Pz8/Pz8/Py82NTUzNgooPT0pIFVzaW5nIGRl ZmF1bHQgYnVpbHQtaW4gY29uZmlndXJhdGlvbiAoMzAgbGluZXMpCig9PSkgLS0tIFN0YXJ0 IG9mIGJ1aWx0LWluIGNvbmZpZ3VyYXRpb24gLS0tCglTZWN0aW9uICJEZXZpY2UiCgkJSWRl bnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IGF0aSBEZXZpY2UgMCIKCQlEcml2ZXIJImF0aSIK CUVuZFNlY3Rpb24KCVNlY3Rpb24gIlNjcmVlbiIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERl ZmF1bHQgYXRpIFNjcmVlbiAwIgoJCURldmljZQkiQnVpbHRpbiBEZWZhdWx0IGF0aSBEZXZp Y2UgMCIKCUVuZFNlY3Rpb24KCVNlY3Rpb24gIkRldmljZSIKCQlJZGVudGlmaWVyCSJCdWls dGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKCQlEcml2ZXIJInZlc2EiCglFbmRTZWN0aW9u CglTZWN0aW9uICJTY3JlZW4iCgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IHZlc2Eg U2NyZWVuIDAiCgkJRGV2aWNlCSJCdWlsdGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKCUVu ZFNlY3Rpb24KCVNlY3Rpb24gIkRldmljZSIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERlZmF1 bHQgZmJkZXYgRGV2aWNlIDAiCgkJRHJpdmVyCSJmYmRldiIKCUVuZFNlY3Rpb24KCVNlY3Rp b24gIlNjcmVlbiIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERlZmF1bHQgZmJkZXYgU2NyZWVu IDAiCgkJRGV2aWNlCSJCdWlsdGluIERlZmF1bHQgZmJkZXYgRGV2aWNlIDAiCglFbmRTZWN0 aW9uCglTZWN0aW9uICJTZXJ2ZXJMYXlvdXQiCgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZh dWx0IExheW91dCIKCQlTY3JlZW4JIkJ1aWx0aW4gRGVmYXVsdCBhdGkgU2NyZWVuIDAiCgkJ U2NyZWVuCSJCdWlsdGluIERlZmF1bHQgdmVzYSBTY3JlZW4gMCIKCQlTY3JlZW4JIkJ1aWx0 aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIKCUVuZFNlY3Rpb24KKD09KSAtLS0gRW5kIG9m IGJ1aWx0LWluIGNvbmZpZ3VyYXRpb24gLS0tCig9PSkgU2VydmVyTGF5b3V0ICJCdWlsdGlu IERlZmF1bHQgTGF5b3V0IgooKiopIHwtLT5TY3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCBhdGkg U2NyZWVuIDAiICgwKQooKiopIHwgICB8LS0+TW9uaXRvciAiPGRlZmF1bHQgbW9uaXRvcj4i CigqKikgfCAgIHwtLT5EZXZpY2UgIkJ1aWx0aW4gRGVmYXVsdCBhdGkgRGV2aWNlIDAiCig9 PSkgTm8gbW9uaXRvciBzcGVjaWZpZWQgZm9yIHNjcmVlbiAiQnVpbHRpbiBEZWZhdWx0IGF0 aSBTY3JlZW4gMCIuCglVc2luZyBhIGRlZmF1bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgoo KiopIHwtLT5TY3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCB2ZXNhIFNjcmVlbiAwIiAoMSkKKCoq KSB8ICAgfC0tPk1vbml0b3IgIjxkZWZhdWx0IG1vbml0b3I+IgooKiopIHwgICB8LS0+RGV2 aWNlICJCdWlsdGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKKD09KSBObyBtb25pdG9yIHNw ZWNpZmllZCBmb3Igc2NyZWVuICJCdWlsdGluIERlZmF1bHQgdmVzYSBTY3JlZW4gMCIuCglV c2luZyBhIGRlZmF1bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgooKiopIHwtLT5TY3JlZW4g IkJ1aWx0aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIgKDIpCigqKikgfCAgIHwtLT5Nb25p dG9yICI8ZGVmYXVsdCBtb25pdG9yPiIKKCoqKSB8ICAgfC0tPkRldmljZSAiQnVpbHRpbiBE ZWZhdWx0IGZiZGV2IERldmljZSAwIgooPT0pIE5vIG1vbml0b3Igc3BlY2lmaWVkIGZvciBz Y3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIuCglVc2luZyBhIGRlZmF1 bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgooPT0pIEF1dG9tYXRpY2FsbHkgYWRkaW5nIGRl dmljZXMKKD09KSBBdXRvbWF0aWNhbGx5IGVuYWJsaW5nIGRldmljZXMKKD09KSBGb250UGF0 aCBzZXQgdG86CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvbWlzYy8sCgkvdXNyL2xvY2Fs L2xpYi9YMTEvZm9udHMvVFRGLywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYsCgkv dXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVHlwZTEvLAoJL3Vzci9sb2NhbC9saWIvWDExL2Zv bnRzLzEwMGRwaS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvCig9PSkgTW9k dWxlUGF0aCBzZXQgdG8gIi91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcyIKKElJKSBDYW5u b3QgbG9jYXRlIGEgY29yZSBwb2ludGVyIGRldmljZS4KKElJKSBDYW5ub3QgbG9jYXRlIGEg Y29yZSBrZXlib2FyZCBkZXZpY2UuCihJSSkgVGhlIHNlcnZlciByZWxpZXMgb24gSEFMIHRv IHByb3ZpZGUgdGhlIGxpc3Qgb2YgaW5wdXQgZGV2aWNlcy4KCUlmIG5vIGRldmljZXMgYmVj b21lIGF2YWlsYWJsZSwgcmVjb25maWd1cmUgSEFMIG9yIGRpc2FibGUgQXV0b0FkZERldmlj ZXMuCihJSSkgTG9hZE1vZHVsZTogImV4dG1vZCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zL2xpYmV4dG1vZC5zbwooSUkpIE1vZHVsZSBl eHRtb2Q6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywg bW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0 ZW5zaW9uCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4w CihJSSkgTG9hZGluZyBleHRlbnNpb24gTUlULVNDUkVFTi1TQVZFUgooSUkpIExvYWRpbmcg ZXh0ZW5zaW9uIFhGcmVlODYtVmlkTW9kZUV4dGVuc2lvbgooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIFhGcmVlODYtREdBCihJSSkgTG9hZGluZyBleHRlbnNpb24gRFBNUwooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIFhWaWRlbwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhWaWRlby1Nb3Rp b25Db21wZW5zYXRpb24KKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYLVJlc291cmNlCihJSSkg TG9hZE1vZHVsZTogImRiZSIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9k dWxlcy9leHRlbnNpb25zL2xpYmRiZS5zbwooSUkpIE1vZHVsZSBkYmU6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRl bnNpb24gRE9VQkxFLUJVRkZFUgooSUkpIExvYWRNb2R1bGU6ICJnbHgiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy9saWJnbHguc28KKElJ KSBNb2R1bGUgZ2x4OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVy IEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKD09KSBBSUdMWCBkaXNhYmxlZAooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIEdMWAooSUkpIExvYWRNb2R1bGU6ICJyZWNvcmQiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy9saWJyZWNvcmQuc28K KElJKSBNb2R1bGUgcmVjb3JkOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxl ZCBmb3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS4xMy4wCglNb2R1bGUgY2xhc3M6IFgu T3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lv biwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBSRUNPUkQKKElJKSBMb2Fk TW9kdWxlOiAiZHJpIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVz L2V4dGVuc2lvbnMvbGliZHJpLnNvCihJSSkgTW9kdWxlIGRyaTogdmVuZG9yPSJYLk9yZyBG b3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4w CglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkg TG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1EUkkKKElJKSBMb2FkTW9kdWxlOiAiZHJpMiIK KElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zL2xp YmRyaTIuc28KKElJKSBNb2R1bGUgZHJpMjogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMS4wCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRl bnNpb24gRFJJMgooSUkpIExvYWRNb2R1bGU6ICJhdGkiCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZHJpdmVycy9hdGlfZHJ2LnNvCihJSSkgTW9kdWxlIGF0 aTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1 bGUgdmVyc2lvbiA9IDYuMTQuMwoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIK CUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIExvYWRN b2R1bGU6ICJyYWRlb24iCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvZHJpdmVycy9yYWRlb25fZHJ2LnNvCihJSSkgTW9kdWxlIHJhZGVvbjogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9 IDYuMTQuMwoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBjbGFzczog WC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIExvYWRNb2R1bGU6ICJ2ZXNh IgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2RyaXZlcnMvdmVz YV9kcnYuc28KKElJKSBNb2R1bGUgdmVzYTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDIuMy4wCglNb2R1bGUgY2xh c3M6IFguT3JnIFZpZGVvIERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIs IHZlcnNpb24gNi4wCihJSSkgTG9hZE1vZHVsZTogImZiZGV2IgooV1cpIFdhcm5pbmcsIGNv dWxkbid0IG9wZW4gbW9kdWxlIGZiZGV2CihJSSkgVW5sb2FkTW9kdWxlOiAiZmJkZXYiCihF RSkgRmFpbGVkIHRvIGxvYWQgbW9kdWxlICJmYmRldiIgKG1vZHVsZSBkb2VzIG5vdCBleGlz dCwgMCkKKElJKSBSQURFT046IERyaXZlciBmb3IgQVRJIFJhZGVvbiBjaGlwc2V0czoKCUFU SSBSYWRlb24gTW9iaWxpdHkgWDYwMCAoTTI0KSAzMTUwIChQQ0lFKSwgQVRJIEZpcmVNViAy NDAwIChQQ0kpLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBYMzAwIChNMjQpIDMxNTIgKFBDSUUp LAoJQVRJIEZpcmVHTCBNMjQgR0wgMzE1NCAoUENJRSksIEFUSSBGaXJlTVYgMjQwMCAzMTU1 IChQQ0kpLAoJQVRJIFJhZGVvbiBYNjAwIChSVjM4MCkgM0U1MCAoUENJRSksCglBVEkgRmly ZUdMIFYzMjAwIChSVjM4MCkgM0U1NCAoUENJRSksIEFUSSBSYWRlb24gSUdQMzIwIChBMykg NDEzNiwKCUFUSSBSYWRlb24gSUdQMzMwLzM0MC8zNTAgKEE0KSA0MTM3LCBBVEkgUmFkZW9u IDk1MDAgQUQgKEFHUCksCglBVEkgUmFkZW9uIDk1MDAgQUUgKEFHUCksIEFUSSBSYWRlb24g OTYwMFRYIEFGIChBR1ApLAoJQVRJIEZpcmVHTCBaMSBBRyAoQUdQKSwgQVRJIFJhZGVvbiA5 ODAwU0UgQUggKEFHUCksCglBVEkgUmFkZW9uIDk4MDAgQUkgKEFHUCksIEFUSSBSYWRlb24g OTgwMCBBSiAoQUdQKSwKCUFUSSBGaXJlR0wgWDIgQUsgKEFHUCksIEFUSSBSYWRlb24gOTYw MCBBUCAoQUdQKSwKCUFUSSBSYWRlb24gOTYwMFNFIEFRIChBR1ApLCBBVEkgUmFkZW9uIDk2 MDBYVCBBUiAoQUdQKSwKCUFUSSBSYWRlb24gOTYwMCBBUyAoQUdQKSwgQVRJIEZpcmVHTCBU MiBBVCAoQUdQKSwgQVRJIFJhZGVvbiA5NjUwLAoJQVRJIEZpcmVHTCBSVjM2MCBBViAoQUdQ KSwgQVRJIFJhZGVvbiA3MDAwIElHUCAoQTQrKSA0MjM3LAoJQVRJIFJhZGVvbiA4NTAwIEFJ VyBCQiAoQUdQKSwgQVRJIFJhZGVvbiBJR1AzMjBNIChVMSkgNDMzNiwKCUFUSSBSYWRlb24g SUdQMzMwTS8zNDBNLzM1ME0gKFUyKSA0MzM3LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA3MDAw IElHUCA0NDM3LCBBVEkgUmFkZW9uIDkwMDAvUFJPIElmIChBR1AvUENJKSwKCUFUSSBSYWRl b24gOTAwMCBJZyAoQUdQL1BDSSksIEFUSSBSYWRlb24gWDgwMCAoUjQyMCkgSkggKEFHUCks CglBVEkgUmFkZW9uIFg4MDBQUk8gKFI0MjApIEpJIChBR1ApLAoJQVRJIFJhZGVvbiBYODAw U0UgKFI0MjApIEpKIChBR1ApLCBBVEkgUmFkZW9uIFg4MDAgKFI0MjApIEpLIChBR1ApLAoJ QVRJIFJhZGVvbiBYODAwIChSNDIwKSBKTCAoQUdQKSwgQVRJIEZpcmVHTCBYMyAoUjQyMCkg Sk0gKEFHUCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IDk4MDAgKE0xOCkgSk4gKEFHUCksCglB VEkgUmFkZW9uIFg4MDAgU0UgKFI0MjApIChBR1ApLCBBVEkgUmFkZW9uIFg4MDBYVCAoUjQy MCkgSlAgKEFHUCksCglBVEkgUmFkZW9uIFg4MDAgVkUgKFI0MjApIEpUIChBR1ApLCBBVEkg UmFkZW9uIFg4NTAgKFI0ODApIChBR1ApLAoJQVRJIFJhZGVvbiBYODUwIFhUIChSNDgwKSAo QUdQKSwgQVRJIFJhZGVvbiBYODUwIFNFIChSNDgwKSAoQUdQKSwKCUFUSSBSYWRlb24gWDg1 MCBQUk8gKFI0ODApIChBR1ApLCBBVEkgUmFkZW9uIFg4NTAgWFQgUEUgKFI0ODApIChBR1Ap LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBNNyBMVyAoQUdQKSwKCUFUSSBNb2JpbGl0eSBGaXJl R0wgNzgwMCBNNyBMWCAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgTTYgTFkgKEFHUCks IEFUSSBSYWRlb24gTW9iaWxpdHkgTTYgTFogKEFHUCksCglBVEkgRmlyZUdMIE1vYmlsaXR5 IDkwMDAgKE05KSBMZCAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTAwMCAoTTkpIExm IChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MDAwIChNOSkgTGcgKEFHUCksIEFUSSBS YWRlb24gOTcwMCBQcm8gTkQgKEFHUCksCglBVEkgUmFkZW9uIDk3MDAvOTUwMFBybyBORSAo QUdQKSwgQVRJIFJhZGVvbiA5NjAwVFggTkYgKEFHUCksCglBVEkgRmlyZUdMIFgxIE5HIChB R1ApLCBBVEkgUmFkZW9uIDk4MDBQUk8gTkggKEFHUCksCglBVEkgUmFkZW9uIDk4MDAgTkkg KEFHUCksIEFUSSBGaXJlR0wgWDIgTksgKEFHUCksCglBVEkgUmFkZW9uIDk4MDBYVCBOSiAo QUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMC85NzAwIChNMTAvTTExKSBOUCAoQUdQ KSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMCAoTTEwKSBOUSAoQUdQKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgOTYwMCAoTTExKSBOUiAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkg OTYwMCAoTTEwKSBOUyAoQUdQKSwKCUFUSSBGaXJlR0wgTW9iaWxpdHkgVDIgKE0xMCkgTlQg KEFHUCksCglBVEkgRmlyZUdMIE1vYmlsaXR5IFQyZSAoTTExKSBOViAoQUdQKSwgQVRJIFJh ZGVvbiBRRCAoQUdQKSwKCUFUSSBSYWRlb24gUUUgKEFHUCksIEFUSSBSYWRlb24gUUYgKEFH UCksIEFUSSBSYWRlb24gUUcgKEFHUCksCglBVEkgRmlyZUdMIDg3MDAvODgwMCBRSCAoQUdQ KSwgQVRJIFJhZGVvbiA4NTAwIFFMIChBR1ApLAoJQVRJIFJhZGVvbiA5MTAwIFFNIChBR1Ap LCBBVEkgUmFkZW9uIDc1MDAgUVcgKEFHUC9QQ0kpLAoJQVRJIFJhZGVvbiA3NTAwIFFYIChB R1AvUENJKSwgQVRJIFJhZGVvbiBWRS83MDAwIFFZIChBR1AvUENJKSwKCUFUSSBSYWRlb24g VkUvNzAwMCBRWiAoQUdQL1BDSSksIEFUSSBFUzEwMDAgNTE1RSAoUENJKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgWDMwMCAoTTIyKSA1NDYwIChQQ0lFKSwKCUFUSSBSYWRlb24gTW9iaWxp dHkgWDYwMCBTRSAoTTI0QykgNTQ2MiAoUENJRSksCglBVEkgRmlyZUdMIE0yMiBHTCA1NDY0 IChQQ0lFKSwgQVRJIFJhZGVvbiBYODAwIChSNDIzKSBVSCAoUENJRSksCglBVEkgUmFkZW9u IFg4MDBQUk8gKFI0MjMpIFVJIChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMExFIChSNDIzKSBV SiAoUENJRSksCglBVEkgUmFkZW9uIFg4MDBTRSAoUjQyMykgVUsgKFBDSUUpLAoJQVRJIFJh ZGVvbiBYODAwIFhUUCAoUjQzMCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4MDAgWEwgKFI0MzAp IChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMCBTRSAoUjQzMCkgKFBDSUUpLCBBVEkgUmFkZW9u IFg4MDAgKFI0MzApIChQQ0lFKSwKCUFUSSBGaXJlR0wgVjcxMDAgKFI0MjMpIChQQ0lFKSwg QVRJIEZpcmVHTCBWNTEwMCAoUjQyMykgVVEgKFBDSUUpLAoJQVRJIEZpcmVHTCB1bmtub3du IChSNDIzKSBVUiAoUENJRSksCglBVEkgRmlyZUdMIHVua25vd24gKFI0MjMpIFVUIChQQ0lF KSwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjUwMDAgKE0yNikgKFBDSUUpLAoJQVRJIE1vYmls aXR5IEZpcmVHTCBWNTAwMCAoTTI2KSAoUENJRSksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg3 MDAgWEwgKE0yNikgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYNzAwIChNMjYpIChQ Q0lFKSwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDcwMCAoTTI2KSAoUENJRSksCglBVEkgUmFk ZW9uIFg1NTBYVFggNTY1NyAoUENJRSksIEFUSSBSYWRlb24gOTEwMCBJR1AgKEE1KSA1ODM0 LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MTAwIElHUCAoVTMpIDU4MzUsCglBVEkgUmFkZW9u IFhQUkVTUyAyMDAgNTk1NCAoUENJRSksCglBVEkgUmFkZW9uIFhQUkVTUyAyMDBNIDU5NTUg KFBDSUUpLCBBVEkgUmFkZW9uIDkyNTAgNTk2MCAoQUdQKSwKCUFUSSBSYWRlb24gOTIwMCA1 OTYxIChBR1ApLCBBVEkgUmFkZW9uIDkyMDAgNTk2MiAoQUdQKSwKCUFUSSBSYWRlb24gOTIw MFNFIDU5NjQgKEFHUCksIEFUSSBGaXJlTVYgMjIwMCAoUENJKSwKCUFUSSBFUzEwMDAgNTk2 OSAoUENJKSwgQVRJIFJhZGVvbiBYUFJFU1MgMjAwIDU5NzQgKFBDSUUpLAoJQVRJIFJhZGVv biBYUFJFU1MgMjAwTSA1OTc1IChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwMCA1QTQx IChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwME0gNUE0MiAoUENJRSksCglBVEkgUmFk ZW9uIFhQUkVTUyAyMDAgNUE2MSAoUENJRSksCglBVEkgUmFkZW9uIFhQUkVTUyAyMDBNIDVB NjIgKFBDSUUpLAoJQVRJIFJhZGVvbiBYMzAwIChSVjM3MCkgNUI2MCAoUENJRSksCglBVEkg UmFkZW9uIFg2MDAgKFJWMzcwKSA1QjYyIChQQ0lFKSwKCUFUSSBSYWRlb24gWDU1MCAoUlYz NzApIDVCNjMgKFBDSUUpLAoJQVRJIEZpcmVHTCBWMzEwMCAoUlYzNzApIDVCNjQgKFBDSUUp LAoJQVRJIEZpcmVNViAyMjAwIFBDSUUgKFJWMzcwKSA1QjY1IChQQ0lFKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgOTIwMCAoTTkrKSA1QzYxIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0 eSA5MjAwIChNOSspIDVDNjMgKEFHUCksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg4MDAgWFQg KE0yOCkgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTEwMCAoTTI4KSAoUENJRSks CglBVEkgTW9iaWxpdHkgUmFkZW9uIFg4MDAgKE0yOCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4 NTAgNUQ0QyAoUENJRSksCglBVEkgUmFkZW9uIFg4NTAgWFQgUEUgKFI0ODApIChQQ0lFKSwK CUFUSSBSYWRlb24gWDg1MCBTRSAoUjQ4MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4NTAgUFJP IChSNDgwKSAoUENJRSksCglBVEkgdW5rbm93biBSYWRlb24gLyBGaXJlR0wgKFI0ODApIDVE NTAgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODUwIFhUIChSNDgwKSAoUENJRSksCglBVEkgUmFk ZW9uIFg4MDBYVCAoUjQyMykgNUQ1NyAoUENJRSksCglBVEkgRmlyZUdMIFY1MDAwIChSVjQx MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgWFQgKFJWNDEwKSAoUENJRSksCglBVEkgUmFk ZW9uIFg3MDAgUFJPIChSVjQxMCkgKFBDSUUpLAoJQVRJIFJhZGVvbiBYNzAwIFNFIChSVjQx MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgKFJWNDEwKSAoUENJRSksCglBVEkgUmFkZW9u IFg3MDAgU0UgKFJWNDEwKSAoUENJRSksIEFUSSBSYWRlb24gWDE4MDAsCglBVEkgTW9iaWxp dHkgUmFkZW9uIFgxODAwIFhULCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxODAwLAoJQVRJIE1v YmlsaXR5IEZpcmVHTCBWNzIwMCwgQVRJIEZpcmVHTCBWNzIwMCwgQVRJIEZpcmVHTCBWNTMw MCwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjcxMDAsIEFUSSBSYWRlb24gWDE4MDAsIEFUSSBS YWRlb24gWDE4MDAsCglBVEkgUmFkZW9uIFgxODAwLCBBVEkgUmFkZW9uIFgxODAwLCBBVEkg UmFkZW9uIFgxODAwLAoJQVRJIEZpcmVHTCBWNzMwMCwgQVRJIEZpcmVHTCBWNzM1MCwgQVRJ IFJhZGVvbiBYMTYwMCwgQVRJIFJWNTA1LAoJQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwgQVRJ IFJhZGVvbiBYMTU1MCwgQVRJIE01NC1HTCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDE0MDAs IEFUSSBSYWRlb24gWDEzMDAvWDE1NTAsCglBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJ IE1vYmlsaXR5IFJhZGVvbiBYMTMwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDEzMDAsIEFU SSBNb2JpbGl0eSBSYWRlb24gWDEzMDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgxMzAwLCBB VEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxMzAwLAoJQVRJIFJWNTA1LCBBVEkgUlY1 MDUsIEFUSSBGaXJlR0wgVjMzMDAsIEFUSSBGaXJlR0wgVjMzNTAsCglBVEkgUmFkZW9uIFgx MzAwLCBBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwK CUFUSSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDEzMDAvWDE1NTAsIEFUSSBNb2JpbGl0 eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAwL1gxNTUwLCBBVEkgTW9iaWxpdHkg UmFkZW9uIFgyMzAwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYMjMwMCwgQVRJIE1vYmlsaXR5 IFJhZGVvbiBYMTM1MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDEzNTAsIEFUSSBNb2JpbGl0 eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxNTUwLCBB VEkgTW9iaWxpdHkgUmFkZW9uIFgxMzUwLAoJQVRJIEZpcmVNViAyMjUwLCBBVEkgUmFkZW9u IFgxNTUwIDY0LWJpdCwgQVRJIFJhZGVvbiBYMTYwMCwKCUFUSSBSYWRlb24gWDE2NTAsIEFU SSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDE2MDAsCglBVEkgTW9iaWxpdHkgRmlyZUdM IFY1MjAwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNjAwLAoJQVRJIFJhZGVvbiBYMTY1MCwg QVRJIFJhZGVvbiBYMTY1MCwgQVRJIFJhZGVvbiBYMTYwMCwKCUFUSSBSYWRlb24gWDEzMDAg WFQvWDE2MDAgUHJvLCBBVEkgRmlyZUdMIFYzNDAwLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBW NTI1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTcwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24g WDE3MDAgWFQsIEFUSSBGaXJlR0wgVjUyMDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNzAw LCBBVEkgUmFkZW9uIFgyMzAwSEQsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDIzMDAsIEFU SSBNb2JpbGl0eSBSYWRlb24gSEQgMjMwMCwKCUFUSSBSYWRlb24gWDE5NTAsIEFUSSBSYWRl b24gWDE5MDAsIEFUSSBSYWRlb24gWDE5NTAsCglBVEkgUmFkZW9uIFgxOTAwLCBBVEkgUmFk ZW9uIFgxOTAwLCBBVEkgUmFkZW9uIFgxOTAwLAoJQVRJIFJhZGVvbiBYMTkwMCwgQVRJIFJh ZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTkwMCwKCUFUSSBSYWRlb24gWDE5MDAsIEFUSSBS YWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5MDAsCglBVEkgQU1EIFN0cmVhbSBQcm9jZXNz b3IsIEFUSSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5NTAsCglBVEkgUlY1NjAsIEFU SSBSVjU2MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTkwMCwgQVRJIFJWNTYwLAoJQVRJIFJh ZGVvbiBYMTk1MCBHVCwgQVRJIFJWNTcwLCBBVEkgUlY1NzAsIEFUSSBGaXJlR0wgVjc0MDAs CglBVEkgUlY1NjAsIEFUSSBSYWRlb24gWDE2NTAsIEFUSSBSYWRlb24gWDE2NTAsIEFUSSBS VjU2MCwKCUFUSSBSYWRlb24gOTEwMCBQUk8gSUdQIDc4MzQsIEFUSSBSYWRlb24gTW9iaWxp dHkgOTIwMCBJR1AgNzgzNSwKCUFUSSBSYWRlb24gWDEyMDAsIEFUSSBSYWRlb24gWDEyMDAs IEFUSSBSYWRlb24gWDEyMDAsCglBVEkgUmFkZW9uIFgxMjAwLCBBVEkgUmFkZW9uIFgxMjAw LCBBVEkgUlM3NDAsIEFUSSBSUzc0ME0sIEFUSSBSUzc0MCwKCUFUSSBSUzc0ME0sIEFUSSBS YWRlb24gSEQgMjkwMCBYVCwgQVRJIFJhZGVvbiBIRCAyOTAwIFhULAoJQVRJIFJhZGVvbiBI RCAyOTAwIFhULCBBVEkgUmFkZW9uIEhEIDI5MDAgUHJvLCBBVEkgUmFkZW9uIEhEIDI5MDAg R1QsCglBVEkgRmlyZUdMIFY4NjUwLCBBVEkgRmlyZUdMIFY4NjAwLCBBVEkgRmlyZUdMIFY3 NjAwLAoJQVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA0ODcwIHgyLAoJ QVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA0ODUwIHgyLAoJQVRJIEZp cmVQcm8gVjg3NTAgKEZpcmVHTCksIEFUSSBGaXJlUHJvIFY3NzYwIChGaXJlR0wpLAoJQVRJ IE1vYmlsaXR5IFJBREVPTiBIRCA0ODUwLCBBVEkgTW9iaWxpdHkgUkFERU9OIEhEIDQ4NTAg WDIsCglBVEkgUmFkZW9uIDQ4MDAgU2VyaWVzLCBBVEkgRmlyZVBybyBSVjc3MCwgQU1EIEZp cmVTdHJlYW0gOTI3MCwKCUFNRCBGaXJlU3RyZWFtIDkyNTAsIEFUSSBGaXJlUHJvIFY4NzAw IChGaXJlR0wpLAoJQVRJIE1vYmlsaXR5IFJBREVPTiBIRCA0ODcwLCBBVEkgTW9iaWxpdHkg UkFERU9OIE05OCwKCUFUSSBNb2JpbGl0eSBSQURFT04gSEQgNDg3MCwgQVRJIFJhZGVvbiA0 ODAwIFNlcmllcywKCUFUSSBSYWRlb24gNDgwMCBTZXJpZXMsIEFUSSBGaXJlUHJvIE03NzUw LCBBVEkgTTk4LCBBVEkgTTk4LCBBVEkgTTk4LAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0 NjUwLCBBVEkgUmFkZW9uIFJWNzMwIChBR1ApLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0 NjcwLCBBVEkgRmlyZVBybyBNNTc1MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgNDY3MCwg QVRJIFJhZGVvbiBSVjczMCAoQUdQKSwKCUFUSSBSVjczMFhUIFtSYWRlb24gSEQgNDY3MF0s IEFUSSBSQURFT04gRTQ2MDAsCglBVEkgUmFkZW9uIEhEIDQ2MDAgU2VyaWVzLCBBVEkgUlY3 MzAgUFJPIFtSYWRlb24gSEQgNDY1MF0sCglBVEkgRmlyZVBybyBWNzc1MCAoRmlyZUdMKSwg QVRJIEZpcmVQcm8gVjU3MDAgKEZpcmVHTCksCglBVEkgRmlyZVBybyBWMzc1MCAoRmlyZUdM KSwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0ODMwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBI RCA0ODUwLCBBVEkgRmlyZVBybyBNNzc0MCwgQVRJIFJWNzQwLAoJQVRJIFJhZGVvbiBIRCA0 NzcwLCBBVEkgUmFkZW9uIEhEIDQ3MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDQ3NzAsCglB VEkgRmlyZVBybyBNNTc1MCwgQVRJIFJWNjEwLCBBVEkgUmFkZW9uIEhEIDI0MDAgWFQsCglB VEkgUmFkZW9uIEhEIDI0MDAgUHJvLCBBVEkgUmFkZW9uIEhEIDI0MDAgUFJPIEFHUCwgQVRJ IEZpcmVHTCBWNDAwMCwKCUFUSSBSVjYxMCwgQVRJIFJhZGVvbiBIRCAyMzUwLCBBVEkgTW9i aWxpdHkgUmFkZW9uIEhEIDI0MDAgWFQsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI0MDAs IEFUSSBSQURFT04gRTI0MDAsIEFUSSBSVjYxMCwKCUFUSSBGaXJlTVYgMjI2MCwgQVRJIFJW NjcwLCBBVEkgUmFkZW9uIEhEMzg3MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg1MCwg QVRJIFJhZGVvbiBIRDM4NTAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM4NTAgWDIsIEFU SSBSVjY3MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg3MCwgQVRJIE1vYmlsaXR5IFJh ZGVvbiBIRCAzODcwIFgyLAoJQVRJIFJhZGVvbiBIRDM4NzAgWDIsIEFUSSBGaXJlR0wgVjc3 MDAsIEFUSSBSYWRlb24gSEQzODUwLAoJQVRJIFJhZGVvbiBIRDM2OTAsIEFNRCBGaXJlc3Ry ZWFtIDkxNzAsIEFUSSBSYWRlb24gSEQgNDU1MCwKCUFUSSBSYWRlb24gUlY3MTAsIEFUSSBS YWRlb24gUlY3MTAsIEFUSSBSYWRlb24gUlY3MTAsCglBVEkgUmFkZW9uIEhEIDQzNTAsIEFU SSBNb2JpbGl0eSBSYWRlb24gNDMwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1 MDAgU2VyaWVzLCBBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1MDAgU2VyaWVzLAoJQVRJIEZpcmVQ cm8gUkcyMjAsIEFUSSBNb2JpbGl0eSBSYWRlb24gNDMzMCwgQVRJIFJWNjMwLAoJQVRJIE1v YmlsaXR5IFJhZGVvbiBIRCAyNjAwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI2MDAgWFQs CglBVEkgUmFkZW9uIEhEIDI2MDAgWFQgQUdQLCBBVEkgUmFkZW9uIEhEIDI2MDAgUHJvIEFH UCwKCUFUSSBSYWRlb24gSEQgMjYwMCBYVCwgQVRJIFJhZGVvbiBIRCAyNjAwIFBybywgQVRJ IEdlbWluaSBSVjYzMCwKCUFUSSBHZW1pbmkgTW9iaWxpdHkgUmFkZW9uIEhEIDI2MDAgWFQs IEFUSSBGaXJlR0wgVjU2MDAsCglBVEkgRmlyZUdMIFYzNjAwLCBBVEkgUmFkZW9uIEhEIDI2 MDAgTEUsCglBVEkgTW9iaWxpdHkgRmlyZUdMIEdyYXBoaWNzIFByb2Nlc3NvciwgQVRJIFJh ZGVvbiBIRCAzNDcwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNDMwLCBBVEkgTW9iaWxp dHkgUmFkZW9uIEhEIDM0MDAgU2VyaWVzLAoJQVRJIFJhZGVvbiBIRCAzNDUwLCBBVEkgUmFk ZW9uIEhEIDM0NTAsIEFUSSBSYWRlb24gSEQgMzQzMCwKCUFUSSBSYWRlb24gSEQgMzQ1MCwg QVRJIEZpcmVQcm8gVjM3MDAsIEFUSSBGaXJlTVYgMjQ1MCwKCUFUSSBGaXJlTVYgMjI2MCwg QVRJIEZpcmVNViAyMjYwLCBBVEkgUmFkZW9uIEhEIDM2MDAgU2VyaWVzLAoJQVRJIFJhZGVv biBIRCAzNjUwIEFHUCwgQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywKCUFUSSBSYWRlb24gSEQg MzYwMCBYVCwgQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywKCUFUSSBNb2JpbGl0eSBSYWRlb24g SEQgMzY1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNjcwLAoJQVRJIE1vYmlsaXR5IEZp cmVHTCBWNTcwMCwgQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTcyNSwKCUFUSSBSYWRlb24gSEQg MzIwMCBHcmFwaGljcywgQVRJIFJhZGVvbiAzMTAwIEdyYXBoaWNzLAoJQVRJIFJhZGVvbiBI RCAzMjAwIEdyYXBoaWNzLCBBVEkgUmFkZW9uIDMxMDAgR3JhcGhpY3MsCglBVEkgUmFkZW9u IEhEIDMzMDAgR3JhcGhpY3MsIEFUSSBSYWRlb24gSEQgMzIwMCBHcmFwaGljcywKCUFUSSBS YWRlb24gMzAwMCBHcmFwaGljcywgU1VNTywgU1VNTywgU1VNTzIsIFNVTU8yLCBTVU1PMiwg U1VNTzIsCglTVU1PLCBTVU1PLCBTVU1PLCBTVU1PLCBTVU1PLCBBVEkgUmFkZW9uIEhEIDQy MDAsIEFUSSBSYWRlb24gNDEwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgNDIwMCwgQVRJ IE1vYmlsaXR5IFJhZGVvbiA0MTAwLAoJQVRJIFJhZGVvbiBIRCA0MjkwLCBBVEkgUmFkZW9u IEhEIDQyNTAsIEFNRCBSYWRlb24gSEQgNjMxMCBHcmFwaGljcywKCUFNRCBSYWRlb24gSEQg NjMxMCBHcmFwaGljcywgQU1EIFJhZGVvbiBIRCA2MjUwIEdyYXBoaWNzLAoJQU1EIFJhZGVv biBIRCA2MjUwIEdyYXBoaWNzLCBBTUQgUmFkZW9uIEhEIDYzMDAgU2VyaWVzIEdyYXBoaWNz LAoJQU1EIFJhZGVvbiBIRCA2MjAwIFNlcmllcyBHcmFwaGljcywgQ1lQUkVTUywKCUFUSSBG aXJlUHJvIChGaXJlR0wpIEdyYXBoaWNzIEFkYXB0ZXIsCglBVEkgRmlyZVBybyAoRmlyZUdM KSBHcmFwaGljcyBBZGFwdGVyLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRh cHRlciwgQU1EIEZpcmVzdHJlYW0gOTM3MCwKCUFNRCBGaXJlc3RyZWFtIDkzNTAsIEFUSSBS YWRlb24gSEQgNTgwMCBTZXJpZXMsCglBVEkgUmFkZW9uIEhEIDU4MDAgU2VyaWVzLCBBVEkg UmFkZW9uIEhEIDU4MDAgU2VyaWVzLAoJQVRJIFJhZGVvbiBIRCA1ODAwIFNlcmllcywgQVRJ IFJhZGVvbiBIRCA1OTAwIFNlcmllcywKCUFUSSBSYWRlb24gSEQgNTkwMCBTZXJpZXMsIEFU SSBNb2JpbGl0eSBSYWRlb24gSEQgNTgwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9u IEhEIDU4MDAgU2VyaWVzLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRl ciwKCUFUSSBGaXJlUHJvIChGaXJlR0wpIEdyYXBoaWNzIEFkYXB0ZXIsCglBVEkgTW9iaWxp dHkgUmFkZW9uIEhEIDU4MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDU3MDAgU2VyaWVzLAoJ QVRJIFJhZGVvbiBIRCA1NzAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA2NzAwIFNlcmllcywK CUFUSSBSYWRlb24gSEQgNTcwMCBTZXJpZXMsIEFUSSBSYWRlb24gSEQgNjcwMCBTZXJpZXMs CglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDUwMDAgU2VyaWVzLAoJQVRJIE1vYmlsaXR5IFJh ZGVvbiBIRCA1MDAwIFNlcmllcywgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA1NTcwLAoJQVRJ IEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRlciwKCUFUSSBGaXJlUHJvIChGaXJl R0wpIEdyYXBoaWNzIEFkYXB0ZXIsIEFUSSBSYWRlb24gSEQgNTY3MCwKCUFUSSBSYWRlb24g SEQgNTU3MCwgQVRJIFJhZGVvbiBIRCA1NTAwIFNlcmllcywgUkVEV09PRCwKCUFUSSBNb2Jp bGl0eSBSYWRlb24gSEQgNTAwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDUw MDAgU2VyaWVzLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEdyYXBoaWNzLAoJQVRJIE1vYmlsaXR5 IFJhZGVvbiBHcmFwaGljcywgQ0VEQVIsCglBVEkgRmlyZVBybyAoRmlyZUdMKSBHcmFwaGlj cyBBZGFwdGVyLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRlciwgQVRJ IEZpcmVQcm8gMjI3MCwgQ0VEQVIsCglBVEkgUmFkZW9uIEhEIDU0NTAsIENFREFSLCBDQVlN QU4sIENBWU1BTiwgQ0FZTUFOLCBDQVlNQU4sIENBWU1BTiwKCUNBWU1BTiwgQ0FZTUFOLCBD QVlNQU4sIENBWU1BTiwgQ0FZTUFOLCBBTUQgUmFkZW9uIEhEIDY5MDAgU2VyaWVzLAoJQU1E IFJhZGVvbiBIRCA2OTAwIFNlcmllcywgQ0FZTUFOLCBDQVlNQU4sIENBWU1BTiwKCUFNRCBS YWRlb24gSEQgNjkwME0gU2VyaWVzLCBNb2JpbGl0eSBSYWRlb24gSEQgNjAwMCBTZXJpZXMs IEJBUlRTLAoJQkFSVFMsIE1vYmlsaXR5IFJhZGVvbiBIRCA2MDAwIFNlcmllcywKCU1vYmls aXR5IFJhZGVvbiBIRCA2MDAwIFNlcmllcywgQkFSVFMsIEJBUlRTLCBCQVJUUywgQkFSVFMs CglBTUQgUmFkZW9uIEhEIDY4MDAgU2VyaWVzLCBBTUQgUmFkZW9uIEhEIDY4MDAgU2VyaWVz LAoJQU1EIFJhZGVvbiBIRCA2NzAwIFNlcmllcywgVFVSS1MsIFRVUktTLCBUVVJLUywgVFVS S1MsIFRVUktTLCBUVVJLUywKCVRVUktTLCBUVVJLUywgVFVSS1MsIFRVUktTLCBUVVJLUywg VFVSS1MsIFRVUktTLCBUVVJLUywgQ0FJQ09TLAoJQ0FJQ09TLCBDQUlDT1MsIENBSUNPUywg Q0FJQ09TLCBDQUlDT1MsIENBSUNPUywgQ0FJQ09TLCBDQUlDT1MsCglDQUlDT1MsIENBSUNP UywgQ0FJQ09TCihJSSkgVkVTQTogZHJpdmVyIGZvciBWRVNBIGNoaXBzZXRzOiB2ZXNhCihJ SSkgUHJpbWFyeSBEZXZpY2UgaXM6IFBDSSAwMUAwMDowNTowCihXVykgRmFsbGluZyBiYWNr IHRvIG9sZCBwcm9iZSBtZXRob2QgZm9yIHZlc2EKKFdXKSBWR0EgYXJiaXRlcjogY2Fubm90 IG9wZW4ga2VybmVsIGFyYml0ZXIsIG5vIG11bHRpLWNhcmQgc3VwcG9ydAooSUkpIFJBREVP TigwKTogVE9UTyBTQVlTIDAwMDAwMDAwZDg1MDAwMDAKKElJKSBSQURFT04oMCk6IE1NSU8g cmVnaXN0ZXJzIGF0IDB4MDAwMDAwMDBkODUwMDAwMDogc2l6ZSA2NEtCCihJSSkgUkFERU9O KDApOiBQQ0kgYnVzIDEgY2FyZCA1IGZ1bmMgMAooSUkpIFJBREVPTigwKTogQ3JlYXRpbmcg ZGVmYXVsdCBEaXNwbGF5IHN1YnNlY3Rpb24gaW4gU2NyZWVuIHNlY3Rpb24KCSJCdWlsdGlu IERlZmF1bHQgYXRpIFNjcmVlbiAwIiBmb3IgZGVwdGgvZmJicHAgMjQvMzIKKD09KSBSQURF T04oMCk6IERlcHRoIDI0LCAoLS0pIGZyYW1lYnVmZmVyIGJwcCAzMgooSUkpIFJBREVPTigw KTogUGl4ZWwgZGVwdGggPSAyNCBiaXRzIHN0b3JlZCBpbiA0IGJ5dGVzICgzMiBicHAgcGl4 bWFwcykKKD09KSBSQURFT04oMCk6IERlZmF1bHQgdmlzdWFsIGlzIFRydWVDb2xvcgooSUkp IExvYWRpbmcgc3ViIG1vZHVsZSAidmdhaHciCihJSSkgTG9hZE1vZHVsZTogInZnYWh3Igoo SUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2xpYnZnYWh3LnNvCihJ SSkgTW9kdWxlIHZnYWh3OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMC4xLjAKCUFCSSBjbGFzczogWC5PcmcgVmlk ZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIFJBREVPTigwKTogdmdhSFdHZXRJT0Jhc2U6 IGh3cC0+SU9CYXNlIGlzIDB4MDNkMCwgaHdwLT5QSU9PZmZzZXQgaXMgMHgwMDAwCig9PSkg UkFERU9OKDApOiBSR0Igd2VpZ2h0IDg4OAooSUkpIFJBREVPTigwKTogVXNpbmcgOCBiaXRz IHBlciBSR0IgKDggYml0IERBQykKKC0tKSBSQURFT04oMCk6IENoaXBzZXQ6ICJBVEkgUmFk ZW9uIFgxMjAwIiAoQ2hpcElEID0gMHg3OTFlKQooLS0pIFJBREVPTigwKTogTGluZWFyIGZy YW1lYnVmZmVyIGF0IDB4MDAwMDAwMDBkMDAwMDAwMAooSUkpIFJBREVPTigwKTogUENJIGNh cmQgZGV0ZWN0ZWQKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImludDEwIgooSUkpIExvYWRN b2R1bGU6ICJpbnQxMCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxl cy9saWJpbnQxMC5zbwooSUkpIE1vZHVsZSBpbnQxMDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0 aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkg Y2xhc3M6IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiA2LjAKKElJKSBSQURFT04oMCk6 IGluaXRpYWxpemluZyBpbnQxMAooPT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweGEwMDAwLDB4MjAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgUkFERU9OKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YzAwMDAsMHg0MDAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKElJKSBSQURFT04oMCk6IFByaW1hcnkgVl9CSU9TIHNlZ21lbnQgaXM6IDB4YzAw MAooPT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooSUkpIFJBREVPTigwKTogQVRPTSBCSU9TIGRldGVjdGVkCihJ SSkgUkFERU9OKDApOiBBVE9NIEJJT1MgUm9tOiAKCVN1YnN5c3RlbVZlbmRvcklEOiAweDEw M2MgU3Vic3lzdGVtSUQ6IDB4MTJmZgoJSU9CYXNlQWRkcmVzczogMHgxMTAwCglGaWxlbmFt ZTogYnIyNjM3My5iaW4gCglCSU9TIEJvb3R1cCBNZXNzYWdlOiANCkFUSSBSYWRlb24gWHBy ZXNzID8xMjUwPyBmb3IgTW9yYXkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCgooSUkpIFJBREVPTigwKTogRnJhbWVidWZmZXIgc3BhY2UgdXNlZCBieSBG aXJtd2FyZSAoa2IpOiAxNgooSUkpIFJBREVPTigwKTogU3RhcnQgb2YgVlJBTSBhcmVhIHVz ZWQgYnkgRmlybXdhcmU6IDB4N2ZmYzAwMAooSUkpIFJBREVPTigwKTogQXRvbUJJT1MgcmVx dWVzdHMgMTZrQiBvZiBWUkFNIHNjcmF0Y2ggc3BhY2UKKElJKSBSQURFT04oMCk6IEF0b21C SU9TIFZSQU0gc2NyYXRjaCBiYXNlOiAweDdmZmMwMDAKKElJKSBSQURFT04oMCk6IENhbm5v dCBnZXQgVlJBTSBzY3JhdGNoIHNwYWNlLiBBbGxvY2F0aW5nIGluIG1haW4gbWVtb3J5IGlu c3RlYWQKKElJKSBSQURFT04oMCk6IERlZmF1bHQgRW5naW5lIENsb2NrOiA0MDAwMDAKKElJ KSBSQURFT04oMCk6IERlZmF1bHQgTWVtb3J5IENsb2NrOiAyMDAwMDAKKElJKSBSQURFT04o MCk6IE1heGltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJlcXVlbmN5IE91dHB1dDogMTIwMDAwMAoo SUkpIFJBREVPTigwKTogTWluaW11bSBQaXhlbCBDbG9ja1BMTCBGcmVxdWVuY3kgT3V0cHV0 OiAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBpeGVsIENsb2NrUExMIEZyZXF1ZW5jeSBJ bnB1dDogMTM1MDAKKElJKSBSQURFT04oMCk6IE1pbmltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJl cXVlbmN5IElucHV0OiAxMDAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBpeGVsIENsb2Nr OiA0MDAwMDAKKElJKSBSQURFT04oMCk6IFJlZmVyZW5jZSBDbG9jazogMTQzMjAKZHJtT3Bl bkRldmljZTogbm9kZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCkZhaWxlZCB0byBjaGFuZ2Ug b3duZXIgb3IgZ3JvdXAgZm9yIGZpbGUgL2Rldi9kcmkhIDI6IE5vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnkKRmFpbGVkIHRvIGNoYW5nZSBvd25lciBvciBncm91cCBmb3IgZmlsZSAvZGV2 L2RyaS9jYXJkMCEgMjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpkcm1PcGVuRGV2aWNl OiBvcGVuIHJlc3VsdCBpcyAtMSwgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCkZhaWxl ZCB0byBjaGFuZ2Ugb3duZXIgb3IgZ3JvdXAgZm9yIGZpbGUgL2Rldi9kcmkvY2FyZDAhIDI6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQg aXMgLTEsIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpkcm1PcGVuRGV2aWNlOiBPcGVu IGZhaWxlZApkcm1PcGVuQnlCdXNpZDogU2VhcmNoaW5nIGZvciBCdXNJRCBwY2k6MDAwMDow MTowNS4wCmRybU9wZW5EZXZpY2U6IG5vZGUgbmFtZSBpcyAvZGV2L2RyaS9jYXJkMApkcm1P cGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBpcyA4LCAoT0spCmRybU9wZW5CeUJ1c2lkOiBkcm1P cGVuTWlub3IgcmV0dXJucyA4CmRybU9wZW5CeUJ1c2lkOiBkcm1HZXRCdXNpZCByZXBvcnRz IHBjaTowMDAwOjAxOjA1LjAKKElJKSBSQURFT04oMCk6IFtkcmldIEZvdW5kIERSSSBsaWJy YXJ5IHZlcnNpb24gMS4zLjAgYW5kIGtlcm5lbCBtb2R1bGUgdmVyc2lvbiAxLjMxLjAKKD09 KSBSQURFT04oMCk6IFBhZ2UgRmxpcHBpbmcgZGlzYWJsZWQgb24gcjV4eCBhbmQgbmV3ZXIg Y2hpcHMuCgooSUkpIFJBREVPTigwKTogV2lsbCB0cnkgdG8gdXNlIERNQSBmb3IgWHYgaW1h Z2UgdHJhbnNmZXJzCihJSSkgUkFERU9OKDApOiBHZW5lcmF0aW9uIDIgUENJIGludGVyZmFj ZSwgdXNpbmcgbWF4IGFjY2Vzc2libGUgbWVtb3J5CihJSSkgUkFERU9OKDApOiBEZXRlY3Rl ZCB0b3RhbCB2aWRlbyBSQU09MTMxMDcySywgYWNjZXNzaWJsZT0xMzEwNzJLIChQQ0kgQkFS PTEzMTA3MkspCigtLSkgUkFERU9OKDApOiBNYXBwZWQgVmlkZW9SQU06IDEzMTA3MiBrQnl0 ZSAoMTI4IGJpdCBERFIgU0RSQU0pCihJSSkgUkFERU9OKDApOiBDb2xvciB0aWxpbmcgZW5h YmxlZCBieSBkZWZhdWx0CihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJkZGMiCihJSSkgTG9h ZE1vZHVsZTogImRkYyIKKElJKSBNb2R1bGUgImRkYyIgYWxyZWFkeSBidWlsdC1pbgooSUkp IExvYWRpbmcgc3ViIG1vZHVsZSAiaTJjIgooSUkpIExvYWRNb2R1bGU6ICJpMmMiCihJSSkg TW9kdWxlICJpMmMiIGFscmVhZHkgYnVpbHQtaW4KKElJKSBSQURFT04oMCk6IFBMTCBwYXJh bWV0ZXJzOiByZj0xNDMyIHJkPTEyIG1pbj04MDAwMCBtYXg9MTIwMDAwOyB4Y2xrPTQwMDAw CihJSSkgUkFERU9OKDApOiBPdXRwdXQgVkdBLTAgaGFzIG5vIG1vbml0b3Igc2VjdGlvbgoo SUkpIFJBREVPTigwKTogSTJDIGJ1cyAiVkdBLTAiIGluaXRpYWxpemVkLgooSUkpIFJBREVP TigwKTogT3V0cHV0IEhETUktMCBoYXMgbm8gbW9uaXRvciBzZWN0aW9uCihJSSkgUkFERU9O KDApOiBJMkMgYnVzICJIRE1JLTAiIGluaXRpYWxpemVkLgooSUkpIFJBREVPTigwKTogUG9y dDA6CiAgWFJBTkRSIG5hbWU6IFZHQS0wCiAgQ29ubmVjdG9yOiBWR0EKICBDUlQxOiBJTlRF Uk5BTF9LTERTQ1BfREFDMQogIEREQyByZWc6IDB4N2U1MAooSUkpIFJBREVPTigwKTogUG9y dDE6CiAgWFJBTkRSIG5hbWU6IEhETUktMAogIENvbm5lY3RvcjogSERNSS1BCiAgREZQMzog SU5URVJOQUxfTFZUTTEKICBEREMgcmVnOiAweDdlNDAKKElJKSBSQURFT04oMCk6IEkyQyBk ZXZpY2UgIlZHQS0wOmRkYzIiIHJlZ2lzdGVyZWQgYXQgYWRkcmVzcyAweEEwLgpEYWMgZGV0 ZWN0aW9uIHN1Y2Nlc3MKKElJKSBSQURFT04oMCk6IE91dHB1dDogVkdBLTAsIERldGVjdGVk IE1vbml0b3IgVHlwZTogMApmaW5pc2hlZCBvdXRwdXQgZGV0ZWN0OiAwCihJSSkgUkFERU9O KDApOiBJMkMgZGV2aWNlICJIRE1JLTA6ZGRjMiIgcmVnaXN0ZXJlZCBhdCBhZGRyZXNzIDB4 QTAuCihJSSkgUkFERU9OKDApOiBJMkMgZGV2aWNlICJIRE1JLTA6RERDIGNvbnRyb2wgaW50 ZXJmYWNlIiByZWdpc3RlcmVkIGF0IGFkZHJlc3MgMHg2RS4KKElJKSBSQURFT04oMCk6IE91 dHB1dDogSERNSS0wLCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDMKKElJKSBSQURFT04oMCk6 IEVESUQgZGF0YSBmcm9tIHRoZSBkaXNwbGF5IG9uIG91dHB1dDogSERNSS0wIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KKElJKSBSQURFT04oMCk6IE1hbnVmYWN0dXJlcjogTkVDICBNb2Rl bDogNjY4ZSAgU2VyaWFsIzogMTY4NDMwMDkKKElJKSBSQURFT04oMCk6IFllYXI6IDIwMDcg IFdlZWs6IDI0CihJSSkgUkFERU9OKDApOiBFRElEIFZlcnNpb246IDEuMwooSUkpIFJBREVP TigwKTogRGlnaXRhbCBEaXNwbGF5IElucHV0CihJSSkgUkFERU9OKDApOiBNYXggSW1hZ2Ug U2l6ZSBbY21dOiBob3Jpei46IDM4ICB2ZXJ0LjogMzAKKElJKSBSQURFT04oMCk6IEdhbW1h OiAyLjIwCihJSSkgUkFERU9OKDApOiBEUE1TIGNhcGFiaWxpdGllczogU3RhbmRCeSBTdXNw ZW5kIE9mZgooSUkpIFJBREVPTigwKTogU3VwcG9ydGVkIGNvbG9yIGVuY29kaW5nczogUkdC IDQ6NDo0IFlDckNiIDQ6NDo0IAooSUkpIFJBREVPTigwKTogRmlyc3QgZGV0YWlsZWQgdGlt aW5nIGlzIHByZWZlcnJlZCBtb2RlCihJSSkgUkFERU9OKDApOiByZWRYOiAwLjY0MSByZWRZ OiAwLjM1MyAgIGdyZWVuWDogMC4yODkgZ3JlZW5ZOiAwLjYyNgooSUkpIFJBREVPTigwKTog Ymx1ZVg6IDAuMTQyIGJsdWVZOiAwLjA3OCAgIHdoaXRlWDogMC4zMTMgd2hpdGVZOiAwLjMy OQooSUkpIFJBREVPTigwKTogU3VwcG9ydGVkIGVzdGFibGlzaGVkIHRpbWluZ3M6CihJSSkg UkFERU9OKDApOiA3MjB4NDAwQDcwSHoKKElJKSBSQURFT04oMCk6IDY0MHg0ODBANjBIegoo SUkpIFJBREVPTigwKTogNjQweDQ4MEA2N0h6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDcy SHoKKElJKSBSQURFT04oMCk6IDY0MHg0ODBANzVIegooSUkpIFJBREVPTigwKTogODAweDYw MEA1Nkh6CihJSSkgUkFERU9OKDApOiA4MDB4NjAwQDYwSHoKKElJKSBSQURFT04oMCk6IDgw MHg2MDBANzJIegooSUkpIFJBREVPTigwKTogODAweDYwMEA3NUh6CihJSSkgUkFERU9OKDAp OiA4MzJ4NjI0QDc1SHoKKElJKSBSQURFT04oMCk6IDEwMjR4NzY4QDYwSHoKKElJKSBSQURF T04oMCk6IDEwMjR4NzY4QDcwSHoKKElJKSBSQURFT04oMCk6IDEwMjR4NzY4QDc1SHoKKElJ KSBSQURFT04oMCk6IDEyODB4MTAyNEA3NUh6CihJSSkgUkFERU9OKDApOiAxMTUyeDg2NEA3 NUh6CihJSSkgUkFERU9OKDApOiBNYW51ZmFjdHVyZXIncyBtYXNrOiAwCihJSSkgUkFERU9O KDApOiBTdXBwb3J0ZWQgc3RhbmRhcmQgdGltaW5nczoKKElJKSBSQURFT04oMCk6ICMwOiBo c2l6ZTogMTE1MiAgdnNpemUgODY0ICByZWZyZXNoOiA3NSAgdmlkOiAyMDMzNwooSUkpIFJB REVPTigwKTogIzE6IGhzaXplOiAxMjgwICB2c2l6ZSA5NjAgIHJlZnJlc2g6IDYwICB2aWQ6 IDE2NTEzCihJSSkgUkFERU9OKDApOiAjMjogaHNpemU6IDEyODAgIHZzaXplIDEwMjQgIHJl ZnJlc2g6IDYwICB2aWQ6IDMyODk3CihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgZGV0YWls ZWQgdGltaW5nOgooSUkpIFJBREVPTigwKTogY2xvY2s6IDEwOC4wIE1IeiAgIEltYWdlIFNp emU6ICAzNzYgeCAzMDEgbW0KKElJKSBSQURFT04oMCk6IGhfYWN0aXZlOiAxMjgwICBoX3N5 bmM6IDEzMjggIGhfc3luY19lbmQgMTQ0MCBoX2JsYW5rX2VuZCAxNjg4IGhfYm9yZGVyOiAw CihJSSkgUkFERU9OKDApOiB2X2FjdGl2ZTogMTAyNCAgdl9zeW5jOiAxMDI1ICB2X3N5bmNf ZW5kIDEwMjggdl9ibGFua2luZzogMTA2NiB2X2JvcmRlcjogMAooSUkpIFJBREVPTigwKTog UmFuZ2VzOiBWIG1pbjogNTYgViBtYXg6IDc1IEh6LCBIIG1pbjogMzEgSCBtYXg6IDgxIGtI eiwgUGl4Q2xvY2sgbWF4IDE0MCBNSHoKKElJKSBSQURFT04oMCk6IE1vbml0b3IgbmFtZTog TENEMTk3ME5YcAooSUkpIFJBREVPTigwKTogU2VyaWFsIE5vOiA3NkQwNTExOFlCCihJSSkg UkFERU9OKDApOiBFRElEIChpbiBoZXgpOgooSUkpIFJBREVPTigwKTogCTAwZmZmZmZmZmZm ZmZmMDAzOGEzOGU2NjAxMDEwMTAxCihJSSkgUkFERU9OKDApOiAJMTgxMTAxMDM4MDI2MWU3 OGVhMTE0NWE0NWE0YWEwMjQKKElJKSBSQURFT04oMCk6IAkxNDUwNTRiZmVmODA3MTRmODE0 MDgxODAwMTAxMDEwMQooSUkpIFJBREVPTigwKTogCTAxMDEwMTAxMDEwMTMwMmEwMDk4NTEw MDJhNDAzMDcwCihJSSkgUkFERU9OKDApOiAJMTMwMDc4MmQxMTAwMDAxZTAwMDAwMGZkMDAz ODRiMWYKKElJKSBSQURFT04oMCk6IAk1MTBlMDAwYTIwMjAyMDIwMjAyMDAwMDAwMGZjMDA0 YwooSUkpIFJBREVPTigwKTogCTQzNDQzMTM5MzczMDRlNTg3MDBhMjAyMDAwMDAwMGZmCihJ SSkgUkFERU9OKDApOiAJMDAzNzM2NDQzMDM1MzEzMTM4NTk0MjBhMjAyMDAwN2MKZmluaXNo ZWQgb3V0cHV0IGRldGVjdDogMQpmaW5pc2hlZCBhbGwgZGV0ZWN0CkRhYyBkZXRlY3Rpb24g c3VjY2VzcwooSUkpIFJBREVPTigwKTogT3V0cHV0OiBWR0EtMCwgRGV0ZWN0ZWQgTW9uaXRv ciBUeXBlOiAwCihJSSkgUkFERU9OKDApOiBPdXRwdXQ6IEhETUktMCwgRGV0ZWN0ZWQgTW9u aXRvciBUeXBlOiAzCihJSSkgUkFERU9OKDApOiBFRElEIGRhdGEgZnJvbSB0aGUgZGlzcGxh eSBvbiBvdXRwdXQ6IEhETUktMCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCihJSSkgUkFERU9O KDApOiBNYW51ZmFjdHVyZXI6IE5FQyAgTW9kZWw6IDY2OGUgIFNlcmlhbCM6IDE2ODQzMDA5 CihJSSkgUkFERU9OKDApOiBZZWFyOiAyMDA3ICBXZWVrOiAyNAooSUkpIFJBREVPTigwKTog RURJRCBWZXJzaW9uOiAxLjMKKElJKSBSQURFT04oMCk6IERpZ2l0YWwgRGlzcGxheSBJbnB1 dAooSUkpIFJBREVPTigwKTogTWF4IEltYWdlIFNpemUgW2NtXTogaG9yaXouOiAzOCAgdmVy dC46IDMwCihJSSkgUkFERU9OKDApOiBHYW1tYTogMi4yMAooSUkpIFJBREVPTigwKTogRFBN UyBjYXBhYmlsaXRpZXM6IFN0YW5kQnkgU3VzcGVuZCBPZmYKKElJKSBSQURFT04oMCk6IFN1 cHBvcnRlZCBjb2xvciBlbmNvZGluZ3M6IFJHQiA0OjQ6NCBZQ3JDYiA0OjQ6NCAKKElJKSBS QURFT04oMCk6IEZpcnN0IGRldGFpbGVkIHRpbWluZyBpcyBwcmVmZXJyZWQgbW9kZQooSUkp IFJBREVPTigwKTogcmVkWDogMC42NDEgcmVkWTogMC4zNTMgICBncmVlblg6IDAuMjg5IGdy ZWVuWTogMC42MjYKKElJKSBSQURFT04oMCk6IGJsdWVYOiAwLjE0MiBibHVlWTogMC4wNzgg ICB3aGl0ZVg6IDAuMzEzIHdoaXRlWTogMC4zMjkKKElJKSBSQURFT04oMCk6IFN1cHBvcnRl ZCBlc3RhYmxpc2hlZCB0aW1pbmdzOgooSUkpIFJBREVPTigwKTogNzIweDQwMEA3MEh6CihJ SSkgUkFERU9OKDApOiA2NDB4NDgwQDYwSHoKKElJKSBSQURFT04oMCk6IDY0MHg0ODBANjdI egooSUkpIFJBREVPTigwKTogNjQweDQ4MEA3Mkh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgw QDc1SHoKKElJKSBSQURFT04oMCk6IDgwMHg2MDBANTZIegooSUkpIFJBREVPTigwKTogODAw eDYwMEA2MEh6CihJSSkgUkFERU9OKDApOiA4MDB4NjAwQDcySHoKKElJKSBSQURFT04oMCk6 IDgwMHg2MDBANzVIegooSUkpIFJBREVPTigwKTogODMyeDYyNEA3NUh6CihJSSkgUkFERU9O KDApOiAxMDI0eDc2OEA2MEh6CihJSSkgUkFERU9OKDApOiAxMDI0eDc2OEA3MEh6CihJSSkg UkFERU9OKDApOiAxMDI0eDc2OEA3NUh6CihJSSkgUkFERU9OKDApOiAxMjgweDEwMjRANzVI egooSUkpIFJBREVPTigwKTogMTE1Mng4NjRANzVIegooSUkpIFJBREVPTigwKTogTWFudWZh Y3R1cmVyJ3MgbWFzazogMAooSUkpIFJBREVPTigwKTogU3VwcG9ydGVkIHN0YW5kYXJkIHRp bWluZ3M6CihJSSkgUkFERU9OKDApOiAjMDogaHNpemU6IDExNTIgIHZzaXplIDg2NCAgcmVm cmVzaDogNzUgIHZpZDogMjAzMzcKKElJKSBSQURFT04oMCk6ICMxOiBoc2l6ZTogMTI4MCAg dnNpemUgOTYwICByZWZyZXNoOiA2MCAgdmlkOiAxNjUxMwooSUkpIFJBREVPTigwKTogIzI6 IGhzaXplOiAxMjgwICB2c2l6ZSAxMDI0ICByZWZyZXNoOiA2MCAgdmlkOiAzMjg5NwooSUkp IFJBREVPTigwKTogU3VwcG9ydGVkIGRldGFpbGVkIHRpbWluZzoKKElJKSBSQURFT04oMCk6 IGNsb2NrOiAxMDguMCBNSHogICBJbWFnZSBTaXplOiAgMzc2IHggMzAxIG1tCihJSSkgUkFE RU9OKDApOiBoX2FjdGl2ZTogMTI4MCAgaF9zeW5jOiAxMzI4ICBoX3N5bmNfZW5kIDE0NDAg aF9ibGFua19lbmQgMTY4OCBoX2JvcmRlcjogMAooSUkpIFJBREVPTigwKTogdl9hY3RpdmU6 IDEwMjQgIHZfc3luYzogMTAyNSAgdl9zeW5jX2VuZCAxMDI4IHZfYmxhbmtpbmc6IDEwNjYg dl9ib3JkZXI6IDAKKElJKSBSQURFT04oMCk6IFJhbmdlczogViBtaW46IDU2IFYgbWF4OiA3 NSBIeiwgSCBtaW46IDMxIEggbWF4OiA4MSBrSHosIFBpeENsb2NrIG1heCAxNDAgTUh6CihJ SSkgUkFERU9OKDApOiBNb25pdG9yIG5hbWU6IExDRDE5NzBOWHAKKElJKSBSQURFT04oMCk6 IFNlcmlhbCBObzogNzZEMDUxMThZQgooSUkpIFJBREVPTigwKTogRURJRCAoaW4gaGV4KToK KElJKSBSQURFT04oMCk6IAkwMGZmZmZmZmZmZmZmZjAwMzhhMzhlNjYwMTAxMDEwMQooSUkp IFJBREVPTigwKTogCTE4MTEwMTAzODAyNjFlNzhlYTExNDVhNDVhNGFhMDI0CihJSSkgUkFE RU9OKDApOiAJMTQ1MDU0YmZlZjgwNzE0ZjgxNDA4MTgwMDEwMTAxMDEKKElJKSBSQURFT04o MCk6IAkwMTAxMDEwMTAxMDEzMDJhMDA5ODUxMDAyYTQwMzA3MAooSUkpIFJBREVPTigwKTog CTEzMDA3ODJkMTEwMDAwMWUwMDAwMDBmZDAwMzg0YjFmCihJSSkgUkFERU9OKDApOiAJNTEw ZTAwMGEyMDIwMjAyMDIwMjAwMDAwMDBmYzAwNGMKKElJKSBSQURFT04oMCk6IAk0MzQ0MzEz OTM3MzA0ZTU4NzAwYTIwMjAwMDAwMDBmZgooSUkpIFJBREVPTigwKTogCTAwMzczNjQ0MzAz NTMxMzEzODU5NDIwYTIwMjAwMDdjCihJSSkgUkFERU9OKDApOiBQYW5lbCBpbmZvcyBmb3Vu ZCBmcm9tIEREQyBkZXRhaWxlZDogMTI4MHgxMDI0CihJSSkgUkFERU9OKDApOiBFRElEIHZl bmRvciAiTkVDIiwgcHJvZCBpZCAyNjI1NAooSUkpIFJBREVPTigwKTogT3V0cHV0IFZHQS0w IGRpc2Nvbm5lY3RlZAooSUkpIFJBREVPTigwKTogT3V0cHV0IEhETUktMCBjb25uZWN0ZWQK KElJKSBSQURFT04oMCk6IFVzaW5nIGV4YWN0IHNpemVzIGZvciBpbml0aWFsIG1vZGVzCihJ SSkgUkFERU9OKDApOiBPdXRwdXQgSERNSS0wIHVzaW5nIGluaXRpYWwgbW9kZSAxMjgweDEw MjQKKElJKSBSQURFT04oMCk6IFVzaW5nIGRlZmF1bHQgZ2FtbWEgb2YgKDEuMCwgMS4wLCAx LjApIHVubGVzcyBvdGhlcndpc2Ugc3RhdGVkLgooPT0pIFJBREVPTigwKTogRFBJIHNldCB0 byAoOTYsIDk2KQooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiZmIiCihJSSkgTG9hZE1vZHVs ZTogImZiIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2xpYmZi LnNvCihJSSkgTW9kdWxlIGZiOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxl ZCBmb3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5Pcmcg QU5TSSBDIEVtdWxhdGlvbiwgdmVyc2lvbiAwLjQKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUg InJhbWRhYyIKKElJKSBMb2FkTW9kdWxlOiAicmFtZGFjIgooSUkpIE1vZHVsZSAicmFtZGFj IiBhbHJlYWR5IGJ1aWx0LWluCig9PSkgUkFERU9OKDApOiBVc2luZyBFWEEgYWNjZWxlcmF0 aW9uIGFyY2hpdGVjdHVyZQooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiZXhhIgooSUkpIExv YWRNb2R1bGU6ICJleGEiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvbGliZXhhLnNvCihJSSkgTW9kdWxlIGV4YTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9u IgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDIuNS4wCglBQkkgY2xh c3M6IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiA2LjAKKD09KSBSQURFT04oMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKCEh KSBSQURFT04oMCk6IE1lcmdlZEZCIHN1cHBvcnQgaGFzIGJlZW4gcmVtb3ZlZCBhbmQgcmVw bGFjZWQgd2l0aCB4cmFuZHIgMS4yIHN1cHBvcnQKKElJKSBVbmxvYWRNb2R1bGU6ICJ2ZXNh IgooSUkpIFVubG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZHJpdmVycy92 ZXNhX2Rydi5zbwooLS0pIERlcHRoIDI0IHBpeG1hcCBmb3JtYXQgaXMgMzIgYnBwCihJSSkg UkFERU9OKDApOiBSQURFT05TY3JlZW5Jbml0IGQwMDAwMDAwIDAgMAooPT0pIFJBREVPTigw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweGEwMDAwLDB4MTAwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCk91dHB1dCBERlAzIGRpc2FibGUgc3VjY2VzcwpCbGFuayBDUlRDIDAgc3VjY2Vz cwpEaXNhYmxlIENSVEMgMCBzdWNjZXNzCkJsYW5rIENSVEMgMSBzdWNjZXNzCkRpc2FibGUg Q1JUQyAxIHN1Y2Nlc3MKKElJKSBSQURFT04oMCk6IER5bmFtaWMgUG93ZXIgTWFuYWdlbWVu dCBEaXNhYmxlZAooPT0pIFJBREVPTigwKTogVXNpbmcgMjQgYml0IGRlcHRoIGJ1ZmZlcgoo SUkpIFJBREVPTigwKTogUkFERU9OSW5pdE1lbW9yeU1hcCgpIDogCihJSSkgUkFERU9OKDAp OiAgIG1lbV9zaXplICAgICAgICAgOiAweDA4MDAwMDAwCihJSSkgUkFERU9OKDApOiAgIE1D X0ZCX0xPQ0FUSU9OICAgOiAweGNmZmZjODAwCihJSSkgUkFERU9OKDApOiAgIE1DX0FHUF9M T0NBVElPTiAgOiAweDAwM2YwMDAwCihJSSkgUkFERU9OKDApOiBEZXB0aCBtb3ZlcyBkaXNh YmxlZCBieSBkZWZhdWx0CihJSSkgUkFERU9OKDApOiBBbGxvY2F0aW5nIGZyb20gYSBzY3Jl ZW4gb2YgMTMxMDcyIGtiCihJSSkgUkFERU9OKDApOiBXaWxsIHVzZSAzMiBrYiBmb3IgaGFy ZHdhcmUgY3Vyc29yIDAgYXQgb2Zmc2V0IDB4MDA2NDAwMDAKKElJKSBSQURFT04oMCk6IFdp bGwgdXNlIDMyIGtiIGZvciBoYXJkd2FyZSBjdXJzb3IgMSBhdCBvZmZzZXQgMHgwMDY0NDAw MAooSUkpIFJBREVPTigwKTogV2lsbCB1c2UgNjQwMCBrYiBmb3IgZnJvbnQgYnVmZmVyIGF0 IG9mZnNldCAweDAwMDAwMDAwCihJSSkgUkFERU9OKDApOiBXaWxsIHVzZSA2NDAwIGtiIGZv ciBiYWNrIGJ1ZmZlciBhdCBvZmZzZXQgMHgwMDY0ODAwMAooSUkpIFJBREVPTigwKTogV2ls bCB1c2UgNjQwMCBrYiBmb3IgZGVwdGggYnVmZmVyIGF0IG9mZnNldCAweDAwYzg4MDAwCihJ SSkgUkFERU9OKDApOiBXaWxsIHVzZSA1NTgwOCBrYiBmb3IgdGV4dHVyZXMgYXQgb2Zmc2V0 IDB4MDEyYzgwMDAKKElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDU2MDMyIGtiIGZvciBYIFNl cnZlciBvZmZzY3JlZW4gYXQgb2Zmc2V0IDB4MDQ5NDgwMDAKZHJtT3BlbkRldmljZTogbm9k ZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlz IDgsIChPSykKZHJtT3BlbkRldmljZTogbm9kZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCmRy bU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlzIDgsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IFNl YXJjaGluZyBmb3IgQnVzSUQgcGNpOjAwMDA6MDE6MDUuMApkcm1PcGVuRGV2aWNlOiBub2Rl IG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMg OCwgKE9LKQpkcm1PcGVuQnlCdXNpZDogZHJtT3Blbk1pbm9yIHJldHVybnMgOApkcm1PcGVu QnlCdXNpZDogZHJtR2V0QnVzaWQgcmVwb3J0cyBwY2k6MDAwMDowMTowNS4wCihJSSkgW2Ry bV0gRFJNIGludGVyZmFjZSB2ZXJzaW9uIDEuMgooSUkpIFtkcm1dIERSTSBvcGVuIG1hc3Rl ciBzdWNjZWVkZWQuCihJSSkgUkFERU9OKDApOiBbZHJtXSBVc2luZyB0aGUgRFJNIGxvY2sg U0FSRUEgYWxzbyBmb3IgZHJhd2FibGVzLgooSUkpIFJBREVPTigwKTogW2RybV0gZnJhbWVi dWZmZXIgaGFuZGxlID0gMHgzMDAwMDAwMDAwMAooSUkpIFJBREVPTigwKTogW2RybV0gYWRk ZWQgMSByZXNlcnZlZCBjb250ZXh0IGZvciBrZXJuZWwKKElJKSBSQURFT04oMCk6IFggY29u dGV4dCBoYW5kbGUgPSAweDEKKElJKSBSQURFT04oMCk6IFtkcm1dIGluc3RhbGxlZCBEUk0g c2lnbmFsIGhhbmRsZXIKKElJKSBSQURFT04oMCk6IFtwY2ldIDMyNzY4IGtCIGFsbG9jYXRl ZCB3aXRoIGhhbmRsZSAweDE0NWViMDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSByaW5nIGhh bmRsZSA9IDB4MDAwMDAwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFJpbmcgbWFwcGVkIGF0 IDB4ODAwODkzMDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSBSaW5nIGNvbnRlbnRzIDB4MDAw MDAwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIHJpbmcgcmVhZCBwdHIgaGFuZGxlID0gMHgw MDAwMDAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gUmluZyByZWFkIHB0ciBtYXBwZWQgYXQg MHg4MDA4MzUwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFJpbmcgcmVhZCBwdHIgY29udGVu dHMgMHgwMDAwMDAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gdmVydGV4L2luZGlyZWN0IGJ1 ZmZlcnMgaGFuZGxlID0gMHgwMDAwMDAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gVmVydGV4 L2luZGlyZWN0IGJ1ZmZlcnMgbWFwcGVkIGF0IDB4ODA0NzgzMDAwCihJSSkgUkFERU9OKDAp OiBbcGNpXSBWZXJ0ZXgvaW5kaXJlY3QgYnVmZmVycyBjb250ZW50cyAweDAwMDAwMDAwCihJ SSkgUkFERU9OKDApOiBbcGNpXSBHQVJUIHRleHR1cmUgbWFwIGhhbmRsZSA9IDB4MDAwMDAw MDAKKElJKSBSQURFT04oMCk6IFtwY2ldIEdBUlQgVGV4dHVyZSBtYXAgbWFwcGVkIGF0IDB4 ODBkMmY3MDAwCihJSSkgUkFERU9OKDApOiBbZHJtXSByZWdpc3RlciBoYW5kbGUgPSAweDAw MDAwMDAwCihJSSkgUkFERU9OKDApOiBbZHJpXSBWaXN1YWwgY29uZmlncyBpbml0aWFsaXpl ZAooSUkpIFJBREVPTigwKTogUkFERU9OUmVzdG9yZU1lbU1hcFJlZ2lzdGVycygpIDogCihJ SSkgUkFERU9OKDApOiAgIE1DX0ZCX0xPQ0FUSU9OICAgOiAweGNmZmZjODAwIDB4Y2ZmZmM4 MDAKKElJKSBSQURFT04oMCk6ICAgTUNfQUdQX0xPQ0FUSU9OICA6IDB4MDAzZjAwMDAKKD09 KSBSQURFT04oMCk6IEJhY2tpbmcgc3RvcmUgZGlzYWJsZWQKKElJKSBSQURFT04oMCk6IFtE UkldIGluc3RhbGxhdGlvbiBjb21wbGV0ZQooSUkpIFJBREVPTigwKTogW2RybV0gQWRkZWQg MzIgNjU1MzYgYnl0ZSB2ZXJ0ZXgvaW5kaXJlY3QgYnVmZmVycwooSUkpIFJBREVPTigwKTog W2RybV0gTWFwcGVkIDMyIHZlcnRleC9pbmRpcmVjdCBidWZmZXJzCihJSSkgUkFERU9OKDAp OiBbZHJtXSBkbWEgY29udHJvbCBpbml0aWFsaXplZCwgdXNpbmcgSVJRIDI1NwooSUkpIFJB REVPTigwKTogW2RybV0gSW5pdGlhbGl6ZWQga2VybmVsIEdBUlQgaGVhcCBtYW5hZ2VyLCAy OTg4NDQxNgooV1cpIFJBREVPTigwKTogRFJJIGluaXQgY2hhbmdlZCBtZW1vcnkgbWFwLCBh ZGp1c3RpbmcgLi4uCihXVykgUkFERU9OKDApOiAgIE1DX0ZCX0xPQ0FUSU9OICB3YXM6IDB4 Y2ZmZmM4MDAgaXM6IDB4Y2ZmZmM4MDAKKFdXKSBSQURFT04oMCk6ICAgTUNfQUdQX0xPQ0FU SU9OIHdhczogMHgwMDNmMDAwMCBpczogMHhkMWZmZDAwMAooSUkpIFJBREVPTigwKTogUkFE RU9OUmVzdG9yZU1lbU1hcFJlZ2lzdGVycygpIDogCihJSSkgUkFERU9OKDApOiAgIE1DX0ZC X0xPQ0FUSU9OICAgOiAweGNmZmZjODAwIDB4Y2ZmZmM4MDAKKElJKSBSQURFT04oMCk6ICAg TUNfQUdQX0xPQ0FUSU9OICA6IDB4ZDFmZmQwMDAKKElJKSBSQURFT04oMCk6IERpcmVjdCBy ZW5kZXJpbmcgZW5hYmxlZAooSUkpIFJBREVPTigwKTogUmVuZGVyIGFjY2VsZXJhdGlvbiBl bmFibGVkIGZvciBSMzAwL1I0MDAvUjUwMCB0eXBlIGNhcmRzLgooSUkpIFJBREVPTigwKTog U2V0dGluZyBFWEEgbWF4UGl0Y2hCeXRlcwooSUkpIFJBREVPTigwKTogbnVtIHF1YWQtcGlw ZXMgaXMgMQooSUkpIEVYQSgwKTogT2Zmc2NyZWVuIHBpeG1hcCBhcmVhIG9mIDU3Mzc2NzY4 IGJ5dGVzCihJSSkgRVhBKDApOiBEcml2ZXIgcmVnaXN0ZXJlZCBzdXBwb3J0IGZvciB0aGUg Zm9sbG93aW5nIG9wZXJhdGlvbnM6CihJSSkgICAgICAgICBTb2xpZAooSUkpICAgICAgICAg Q29weQooSUkpICAgICAgICAgQ29tcG9zaXRlIChSRU5ERVIgYWNjZWxlcmF0aW9uKQooSUkp ICAgICAgICAgVXBsb2FkVG9TY3JlZW4KKElJKSAgICAgICAgIERvd25sb2FkRnJvbVNjcmVl bgooSUkpIFJBREVPTigwKTogQWNjZWxlcmF0aW9uIGVuYWJsZWQKKD09KSBSQURFT04oMCk6 IERQTVMgZW5hYmxlZAooPT0pIFJBREVPTigwKTogU2lsa2VuIG1vdXNlIGVuYWJsZWQKKElJ KSBSQURFT04oMCk6IFNldCB1cCB0ZXh0dXJlZCB2aWRlbwooSUkpIFJBREVPTigwKTogW1h2 TUNdIEFzc29jaWF0ZWQgd2l0aCBSYWRlb24gVGV4dHVyZWQgVmlkZW8uCihJSSkgUkFERU9O KDApOiBbWHZNQ10gRXh0ZW5zaW9uIGluaXRpYWxpemVkLgpPdXRwdXQgQ1JUMSBkaXNhYmxl IHN1Y2Nlc3MKT3V0cHV0IERGUDMgZGlzYWJsZSBzdWNjZXNzCkJsYW5rIENSVEMgMCBzdWNj ZXNzCkRpc2FibGUgQ1JUQyAwIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAxIHN1Y2Nlc3MKRGlzYWJs ZSBDUlRDIDEgc3VjY2Vzcwo= --------------010809080106000808030407 Content-Type: text/plain; name="Xorg.0.log_with.out.drm.ko" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Xorg.0.log_with.out.drm.ko" ClguT3JnIFggU2VydmVyIDEuNy43ClJlbGVhc2UgRGF0ZTogMjAxMC0wNS0wNApYIFByb3Rv Y29sIFZlcnNpb24gMTEsIFJldmlzaW9uIDAKQnVpbGQgT3BlcmF0aW5nIFN5c3RlbTogRnJl ZUJTRCA5LjktQ1VSUkVOVCBhbWQ2NCAKQ3VycmVudCBPcGVyYXRpbmcgU3lzdGVtOiBGcmVl QlNEIGxpc3N5YXJhLm1vc2tiLmxvY2FsIDEwLjAtQ1VSUkVOVCBGcmVlQlNEIDEwLjAtQ1VS UkVOVCAjMCByMjI4NzI2OiBUdWUgRGVjIDIwIDA4OjI0OjU2IE1TSyAyMDExICAgICByb290 QGxpc3N5YXJhLm1vc2tiLmxvY2FsOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1k NjQKQnVpbGQgRGF0ZTogMTIgRGVjZW1iZXIgMjAxMSAgMTI6MjQ6MDdQTQogCkN1cnJlbnQg dmVyc2lvbiBvZiBwaXhtYW46IDAuMjQuMAoJQmVmb3JlIHJlcG9ydGluZyBwcm9ibGVtcywg Y2hlY2sgaHR0cDovL3dpa2kueC5vcmcKCXRvIG1ha2Ugc3VyZSB0aGF0IHlvdSBoYXZlIHRo ZSBsYXRlc3QgdmVyc2lvbi4KTWFya2VyczogKC0tKSBwcm9iZWQsICgqKikgZnJvbSBjb25m aWcgZmlsZSwgKD09KSBkZWZhdWx0IHNldHRpbmcsCgkoKyspIGZyb20gY29tbWFuZCBsaW5l LCAoISEpIG5vdGljZSwgKElJKSBpbmZvcm1hdGlvbmFsLAoJKFdXKSB3YXJuaW5nLCAoRUUp IGVycm9yLCAoTkkpIG5vdCBpbXBsZW1lbnRlZCwgKD8/KSB1bmtub3duLgooPT0pIExvZyBm aWxlOiAiL3Zhci9sb2cvWG9yZy4wLmxvZyIsIFRpbWU6IFR1ZSBEZWMgMjAgMTc6MTk6NDEg MjAxMQooSUkpIExvYWRlciBtYWdpYzogMHg3YmE1MDAKKElJKSBNb2R1bGUgQUJJIHZlcnNp b25zOgoJWC5PcmcgQU5TSSBDIEVtdWxhdGlvbjogMC40CglYLk9yZyBWaWRlbyBEcml2ZXI6 IDYuMAoJWC5PcmcgWElucHV0IGRyaXZlciA6IDcuMAoJWC5PcmcgU2VydmVyIEV4dGVuc2lv biA6IDIuMAooLS0pIFVzaW5nIHN5c2NvbnMgZHJpdmVyIHdpdGggWCBzdXBwb3J0ICh2ZXJz aW9uIDIuMCkKKC0tKSB1c2luZyBWVCBudW1iZXIgOQoKKC0tKSBQQ0k6KigwOjE6NTowKSAx MDAyOjc5MWU6MTAzYzoxMmZmIEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gbmVlIEFU SSBSUzY5MCBbUmFkZW9uIFgxMjAwIFNlcmllc10gcmV2IDAsIE1lbSBAIDB4ZDAwMDAwMDAv MTM0MjE3NzI4LCAweGQ4NTAwMDAwLzY1NTM2LCAweGQ4NDAwMDAwLzEwNDg1NzYsIEkvTyBA IDB4MDAwMDExMDAvMjU2LCBCSU9TIEAgMHg/Pz8/Pz8/Py82NTUzNgooPT0pIFVzaW5nIGRl ZmF1bHQgYnVpbHQtaW4gY29uZmlndXJhdGlvbiAoMzAgbGluZXMpCig9PSkgLS0tIFN0YXJ0 IG9mIGJ1aWx0LWluIGNvbmZpZ3VyYXRpb24gLS0tCglTZWN0aW9uICJEZXZpY2UiCgkJSWRl bnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IGF0aSBEZXZpY2UgMCIKCQlEcml2ZXIJImF0aSIK CUVuZFNlY3Rpb24KCVNlY3Rpb24gIlNjcmVlbiIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERl ZmF1bHQgYXRpIFNjcmVlbiAwIgoJCURldmljZQkiQnVpbHRpbiBEZWZhdWx0IGF0aSBEZXZp Y2UgMCIKCUVuZFNlY3Rpb24KCVNlY3Rpb24gIkRldmljZSIKCQlJZGVudGlmaWVyCSJCdWls dGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKCQlEcml2ZXIJInZlc2EiCglFbmRTZWN0aW9u CglTZWN0aW9uICJTY3JlZW4iCgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZhdWx0IHZlc2Eg U2NyZWVuIDAiCgkJRGV2aWNlCSJCdWlsdGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKCUVu ZFNlY3Rpb24KCVNlY3Rpb24gIkRldmljZSIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERlZmF1 bHQgZmJkZXYgRGV2aWNlIDAiCgkJRHJpdmVyCSJmYmRldiIKCUVuZFNlY3Rpb24KCVNlY3Rp b24gIlNjcmVlbiIKCQlJZGVudGlmaWVyCSJCdWlsdGluIERlZmF1bHQgZmJkZXYgU2NyZWVu IDAiCgkJRGV2aWNlCSJCdWlsdGluIERlZmF1bHQgZmJkZXYgRGV2aWNlIDAiCglFbmRTZWN0 aW9uCglTZWN0aW9uICJTZXJ2ZXJMYXlvdXQiCgkJSWRlbnRpZmllcgkiQnVpbHRpbiBEZWZh dWx0IExheW91dCIKCQlTY3JlZW4JIkJ1aWx0aW4gRGVmYXVsdCBhdGkgU2NyZWVuIDAiCgkJ U2NyZWVuCSJCdWlsdGluIERlZmF1bHQgdmVzYSBTY3JlZW4gMCIKCQlTY3JlZW4JIkJ1aWx0 aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIKCUVuZFNlY3Rpb24KKD09KSAtLS0gRW5kIG9m IGJ1aWx0LWluIGNvbmZpZ3VyYXRpb24gLS0tCig9PSkgU2VydmVyTGF5b3V0ICJCdWlsdGlu IERlZmF1bHQgTGF5b3V0IgooKiopIHwtLT5TY3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCBhdGkg U2NyZWVuIDAiICgwKQooKiopIHwgICB8LS0+TW9uaXRvciAiPGRlZmF1bHQgbW9uaXRvcj4i CigqKikgfCAgIHwtLT5EZXZpY2UgIkJ1aWx0aW4gRGVmYXVsdCBhdGkgRGV2aWNlIDAiCig9 PSkgTm8gbW9uaXRvciBzcGVjaWZpZWQgZm9yIHNjcmVlbiAiQnVpbHRpbiBEZWZhdWx0IGF0 aSBTY3JlZW4gMCIuCglVc2luZyBhIGRlZmF1bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgoo KiopIHwtLT5TY3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCB2ZXNhIFNjcmVlbiAwIiAoMSkKKCoq KSB8ICAgfC0tPk1vbml0b3IgIjxkZWZhdWx0IG1vbml0b3I+IgooKiopIHwgICB8LS0+RGV2 aWNlICJCdWlsdGluIERlZmF1bHQgdmVzYSBEZXZpY2UgMCIKKD09KSBObyBtb25pdG9yIHNw ZWNpZmllZCBmb3Igc2NyZWVuICJCdWlsdGluIERlZmF1bHQgdmVzYSBTY3JlZW4gMCIuCglV c2luZyBhIGRlZmF1bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgooKiopIHwtLT5TY3JlZW4g IkJ1aWx0aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIgKDIpCigqKikgfCAgIHwtLT5Nb25p dG9yICI8ZGVmYXVsdCBtb25pdG9yPiIKKCoqKSB8ICAgfC0tPkRldmljZSAiQnVpbHRpbiBE ZWZhdWx0IGZiZGV2IERldmljZSAwIgooPT0pIE5vIG1vbml0b3Igc3BlY2lmaWVkIGZvciBz Y3JlZW4gIkJ1aWx0aW4gRGVmYXVsdCBmYmRldiBTY3JlZW4gMCIuCglVc2luZyBhIGRlZmF1 bHQgbW9uaXRvciBjb25maWd1cmF0aW9uLgooPT0pIEF1dG9tYXRpY2FsbHkgYWRkaW5nIGRl dmljZXMKKD09KSBBdXRvbWF0aWNhbGx5IGVuYWJsaW5nIGRldmljZXMKKD09KSBGb250UGF0 aCBzZXQgdG86CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvbWlzYy8sCgkvdXNyL2xvY2Fs L2xpYi9YMTEvZm9udHMvVFRGLywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYsCgkv dXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVHlwZTEvLAoJL3Vzci9sb2NhbC9saWIvWDExL2Zv bnRzLzEwMGRwaS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvCig9PSkgTW9k dWxlUGF0aCBzZXQgdG8gIi91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcyIKKElJKSBDYW5u b3QgbG9jYXRlIGEgY29yZSBwb2ludGVyIGRldmljZS4KKElJKSBDYW5ub3QgbG9jYXRlIGEg Y29yZSBrZXlib2FyZCBkZXZpY2UuCihJSSkgVGhlIHNlcnZlciByZWxpZXMgb24gSEFMIHRv IHByb3ZpZGUgdGhlIGxpc3Qgb2YgaW5wdXQgZGV2aWNlcy4KCUlmIG5vIGRldmljZXMgYmVj b21lIGF2YWlsYWJsZSwgcmVjb25maWd1cmUgSEFMIG9yIGRpc2FibGUgQXV0b0FkZERldmlj ZXMuCihJSSkgTG9hZE1vZHVsZTogImV4dG1vZCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zL2xpYmV4dG1vZC5zbwooSUkpIE1vZHVsZSBl eHRtb2Q6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywg bW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0 ZW5zaW9uCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4w CihJSSkgTG9hZGluZyBleHRlbnNpb24gTUlULVNDUkVFTi1TQVZFUgooSUkpIExvYWRpbmcg ZXh0ZW5zaW9uIFhGcmVlODYtVmlkTW9kZUV4dGVuc2lvbgooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIFhGcmVlODYtREdBCihJSSkgTG9hZGluZyBleHRlbnNpb24gRFBNUwooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIFhWaWRlbwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhWaWRlby1Nb3Rp b25Db21wZW5zYXRpb24KKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYLVJlc291cmNlCihJSSkg TG9hZE1vZHVsZTogImRiZSIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9k dWxlcy9leHRlbnNpb25zL2xpYmRiZS5zbwooSUkpIE1vZHVsZSBkYmU6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRl bnNpb24gRE9VQkxFLUJVRkZFUgooSUkpIExvYWRNb2R1bGU6ICJnbHgiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy9saWJnbHguc28KKElJ KSBNb2R1bGUgZ2x4OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVy IEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKD09KSBBSUdMWCBkaXNhYmxlZAooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIEdMWAooSUkpIExvYWRNb2R1bGU6ICJyZWNvcmQiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy9saWJyZWNvcmQuc28K KElJKSBNb2R1bGUgcmVjb3JkOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxl ZCBmb3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS4xMy4wCglNb2R1bGUgY2xhc3M6IFgu T3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lv biwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBSRUNPUkQKKElJKSBMb2Fk TW9kdWxlOiAiZHJpIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVz L2V4dGVuc2lvbnMvbGliZHJpLnNvCihJSSkgTW9kdWxlIGRyaTogdmVuZG9yPSJYLk9yZyBG b3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4w CglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkg TG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1EUkkKKElJKSBMb2FkTW9kdWxlOiAiZHJpMiIK KElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zL2xp YmRyaTIuc28KKElJKSBNb2R1bGUgZHJpMjogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMS4wCglBQkkgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRl bnNpb24gRFJJMgooSUkpIExvYWRNb2R1bGU6ICJhdGkiCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZHJpdmVycy9hdGlfZHJ2LnNvCihJSSkgTW9kdWxlIGF0 aTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1 bGUgdmVyc2lvbiA9IDYuMTQuMwoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIK CUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIExvYWRN b2R1bGU6ICJyYWRlb24iCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvZHJpdmVycy9yYWRlb25fZHJ2LnNvCihJSSkgTW9kdWxlIHJhZGVvbjogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9 IDYuMTQuMwoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBjbGFzczog WC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIExvYWRNb2R1bGU6ICJ2ZXNh IgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2RyaXZlcnMvdmVz YV9kcnYuc28KKElJKSBNb2R1bGUgdmVzYTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDIuMy4wCglNb2R1bGUgY2xh c3M6IFguT3JnIFZpZGVvIERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIs IHZlcnNpb24gNi4wCihJSSkgTG9hZE1vZHVsZTogImZiZGV2IgooV1cpIFdhcm5pbmcsIGNv dWxkbid0IG9wZW4gbW9kdWxlIGZiZGV2CihJSSkgVW5sb2FkTW9kdWxlOiAiZmJkZXYiCihF RSkgRmFpbGVkIHRvIGxvYWQgbW9kdWxlICJmYmRldiIgKG1vZHVsZSBkb2VzIG5vdCBleGlz dCwgMCkKKElJKSBSQURFT046IERyaXZlciBmb3IgQVRJIFJhZGVvbiBjaGlwc2V0czoKCUFU SSBSYWRlb24gTW9iaWxpdHkgWDYwMCAoTTI0KSAzMTUwIChQQ0lFKSwgQVRJIEZpcmVNViAy NDAwIChQQ0kpLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBYMzAwIChNMjQpIDMxNTIgKFBDSUUp LAoJQVRJIEZpcmVHTCBNMjQgR0wgMzE1NCAoUENJRSksIEFUSSBGaXJlTVYgMjQwMCAzMTU1 IChQQ0kpLAoJQVRJIFJhZGVvbiBYNjAwIChSVjM4MCkgM0U1MCAoUENJRSksCglBVEkgRmly ZUdMIFYzMjAwIChSVjM4MCkgM0U1NCAoUENJRSksIEFUSSBSYWRlb24gSUdQMzIwIChBMykg NDEzNiwKCUFUSSBSYWRlb24gSUdQMzMwLzM0MC8zNTAgKEE0KSA0MTM3LCBBVEkgUmFkZW9u IDk1MDAgQUQgKEFHUCksCglBVEkgUmFkZW9uIDk1MDAgQUUgKEFHUCksIEFUSSBSYWRlb24g OTYwMFRYIEFGIChBR1ApLAoJQVRJIEZpcmVHTCBaMSBBRyAoQUdQKSwgQVRJIFJhZGVvbiA5 ODAwU0UgQUggKEFHUCksCglBVEkgUmFkZW9uIDk4MDAgQUkgKEFHUCksIEFUSSBSYWRlb24g OTgwMCBBSiAoQUdQKSwKCUFUSSBGaXJlR0wgWDIgQUsgKEFHUCksIEFUSSBSYWRlb24gOTYw MCBBUCAoQUdQKSwKCUFUSSBSYWRlb24gOTYwMFNFIEFRIChBR1ApLCBBVEkgUmFkZW9uIDk2 MDBYVCBBUiAoQUdQKSwKCUFUSSBSYWRlb24gOTYwMCBBUyAoQUdQKSwgQVRJIEZpcmVHTCBU MiBBVCAoQUdQKSwgQVRJIFJhZGVvbiA5NjUwLAoJQVRJIEZpcmVHTCBSVjM2MCBBViAoQUdQ KSwgQVRJIFJhZGVvbiA3MDAwIElHUCAoQTQrKSA0MjM3LAoJQVRJIFJhZGVvbiA4NTAwIEFJ VyBCQiAoQUdQKSwgQVRJIFJhZGVvbiBJR1AzMjBNIChVMSkgNDMzNiwKCUFUSSBSYWRlb24g SUdQMzMwTS8zNDBNLzM1ME0gKFUyKSA0MzM3LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA3MDAw IElHUCA0NDM3LCBBVEkgUmFkZW9uIDkwMDAvUFJPIElmIChBR1AvUENJKSwKCUFUSSBSYWRl b24gOTAwMCBJZyAoQUdQL1BDSSksIEFUSSBSYWRlb24gWDgwMCAoUjQyMCkgSkggKEFHUCks CglBVEkgUmFkZW9uIFg4MDBQUk8gKFI0MjApIEpJIChBR1ApLAoJQVRJIFJhZGVvbiBYODAw U0UgKFI0MjApIEpKIChBR1ApLCBBVEkgUmFkZW9uIFg4MDAgKFI0MjApIEpLIChBR1ApLAoJ QVRJIFJhZGVvbiBYODAwIChSNDIwKSBKTCAoQUdQKSwgQVRJIEZpcmVHTCBYMyAoUjQyMCkg Sk0gKEFHUCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IDk4MDAgKE0xOCkgSk4gKEFHUCksCglB VEkgUmFkZW9uIFg4MDAgU0UgKFI0MjApIChBR1ApLCBBVEkgUmFkZW9uIFg4MDBYVCAoUjQy MCkgSlAgKEFHUCksCglBVEkgUmFkZW9uIFg4MDAgVkUgKFI0MjApIEpUIChBR1ApLCBBVEkg UmFkZW9uIFg4NTAgKFI0ODApIChBR1ApLAoJQVRJIFJhZGVvbiBYODUwIFhUIChSNDgwKSAo QUdQKSwgQVRJIFJhZGVvbiBYODUwIFNFIChSNDgwKSAoQUdQKSwKCUFUSSBSYWRlb24gWDg1 MCBQUk8gKFI0ODApIChBR1ApLCBBVEkgUmFkZW9uIFg4NTAgWFQgUEUgKFI0ODApIChBR1Ap LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBNNyBMVyAoQUdQKSwKCUFUSSBNb2JpbGl0eSBGaXJl R0wgNzgwMCBNNyBMWCAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgTTYgTFkgKEFHUCks IEFUSSBSYWRlb24gTW9iaWxpdHkgTTYgTFogKEFHUCksCglBVEkgRmlyZUdMIE1vYmlsaXR5 IDkwMDAgKE05KSBMZCAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTAwMCAoTTkpIExm IChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MDAwIChNOSkgTGcgKEFHUCksIEFUSSBS YWRlb24gOTcwMCBQcm8gTkQgKEFHUCksCglBVEkgUmFkZW9uIDk3MDAvOTUwMFBybyBORSAo QUdQKSwgQVRJIFJhZGVvbiA5NjAwVFggTkYgKEFHUCksCglBVEkgRmlyZUdMIFgxIE5HIChB R1ApLCBBVEkgUmFkZW9uIDk4MDBQUk8gTkggKEFHUCksCglBVEkgUmFkZW9uIDk4MDAgTkkg KEFHUCksIEFUSSBGaXJlR0wgWDIgTksgKEFHUCksCglBVEkgUmFkZW9uIDk4MDBYVCBOSiAo QUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMC85NzAwIChNMTAvTTExKSBOUCAoQUdQ KSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMCAoTTEwKSBOUSAoQUdQKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgOTYwMCAoTTExKSBOUiAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkg OTYwMCAoTTEwKSBOUyAoQUdQKSwKCUFUSSBGaXJlR0wgTW9iaWxpdHkgVDIgKE0xMCkgTlQg KEFHUCksCglBVEkgRmlyZUdMIE1vYmlsaXR5IFQyZSAoTTExKSBOViAoQUdQKSwgQVRJIFJh ZGVvbiBRRCAoQUdQKSwKCUFUSSBSYWRlb24gUUUgKEFHUCksIEFUSSBSYWRlb24gUUYgKEFH UCksIEFUSSBSYWRlb24gUUcgKEFHUCksCglBVEkgRmlyZUdMIDg3MDAvODgwMCBRSCAoQUdQ KSwgQVRJIFJhZGVvbiA4NTAwIFFMIChBR1ApLAoJQVRJIFJhZGVvbiA5MTAwIFFNIChBR1Ap LCBBVEkgUmFkZW9uIDc1MDAgUVcgKEFHUC9QQ0kpLAoJQVRJIFJhZGVvbiA3NTAwIFFYIChB R1AvUENJKSwgQVRJIFJhZGVvbiBWRS83MDAwIFFZIChBR1AvUENJKSwKCUFUSSBSYWRlb24g VkUvNzAwMCBRWiAoQUdQL1BDSSksIEFUSSBFUzEwMDAgNTE1RSAoUENJKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgWDMwMCAoTTIyKSA1NDYwIChQQ0lFKSwKCUFUSSBSYWRlb24gTW9iaWxp dHkgWDYwMCBTRSAoTTI0QykgNTQ2MiAoUENJRSksCglBVEkgRmlyZUdMIE0yMiBHTCA1NDY0 IChQQ0lFKSwgQVRJIFJhZGVvbiBYODAwIChSNDIzKSBVSCAoUENJRSksCglBVEkgUmFkZW9u IFg4MDBQUk8gKFI0MjMpIFVJIChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMExFIChSNDIzKSBV SiAoUENJRSksCglBVEkgUmFkZW9uIFg4MDBTRSAoUjQyMykgVUsgKFBDSUUpLAoJQVRJIFJh ZGVvbiBYODAwIFhUUCAoUjQzMCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4MDAgWEwgKFI0MzAp IChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMCBTRSAoUjQzMCkgKFBDSUUpLCBBVEkgUmFkZW9u IFg4MDAgKFI0MzApIChQQ0lFKSwKCUFUSSBGaXJlR0wgVjcxMDAgKFI0MjMpIChQQ0lFKSwg QVRJIEZpcmVHTCBWNTEwMCAoUjQyMykgVVEgKFBDSUUpLAoJQVRJIEZpcmVHTCB1bmtub3du IChSNDIzKSBVUiAoUENJRSksCglBVEkgRmlyZUdMIHVua25vd24gKFI0MjMpIFVUIChQQ0lF KSwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjUwMDAgKE0yNikgKFBDSUUpLAoJQVRJIE1vYmls aXR5IEZpcmVHTCBWNTAwMCAoTTI2KSAoUENJRSksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg3 MDAgWEwgKE0yNikgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYNzAwIChNMjYpIChQ Q0lFKSwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDcwMCAoTTI2KSAoUENJRSksCglBVEkgUmFk ZW9uIFg1NTBYVFggNTY1NyAoUENJRSksIEFUSSBSYWRlb24gOTEwMCBJR1AgKEE1KSA1ODM0 LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MTAwIElHUCAoVTMpIDU4MzUsCglBVEkgUmFkZW9u IFhQUkVTUyAyMDAgNTk1NCAoUENJRSksCglBVEkgUmFkZW9uIFhQUkVTUyAyMDBNIDU5NTUg KFBDSUUpLCBBVEkgUmFkZW9uIDkyNTAgNTk2MCAoQUdQKSwKCUFUSSBSYWRlb24gOTIwMCA1 OTYxIChBR1ApLCBBVEkgUmFkZW9uIDkyMDAgNTk2MiAoQUdQKSwKCUFUSSBSYWRlb24gOTIw MFNFIDU5NjQgKEFHUCksIEFUSSBGaXJlTVYgMjIwMCAoUENJKSwKCUFUSSBFUzEwMDAgNTk2 OSAoUENJKSwgQVRJIFJhZGVvbiBYUFJFU1MgMjAwIDU5NzQgKFBDSUUpLAoJQVRJIFJhZGVv biBYUFJFU1MgMjAwTSA1OTc1IChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwMCA1QTQx IChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwME0gNUE0MiAoUENJRSksCglBVEkgUmFk ZW9uIFhQUkVTUyAyMDAgNUE2MSAoUENJRSksCglBVEkgUmFkZW9uIFhQUkVTUyAyMDBNIDVB NjIgKFBDSUUpLAoJQVRJIFJhZGVvbiBYMzAwIChSVjM3MCkgNUI2MCAoUENJRSksCglBVEkg UmFkZW9uIFg2MDAgKFJWMzcwKSA1QjYyIChQQ0lFKSwKCUFUSSBSYWRlb24gWDU1MCAoUlYz NzApIDVCNjMgKFBDSUUpLAoJQVRJIEZpcmVHTCBWMzEwMCAoUlYzNzApIDVCNjQgKFBDSUUp LAoJQVRJIEZpcmVNViAyMjAwIFBDSUUgKFJWMzcwKSA1QjY1IChQQ0lFKSwKCUFUSSBSYWRl b24gTW9iaWxpdHkgOTIwMCAoTTkrKSA1QzYxIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0 eSA5MjAwIChNOSspIDVDNjMgKEFHUCksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg4MDAgWFQg KE0yOCkgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTEwMCAoTTI4KSAoUENJRSks CglBVEkgTW9iaWxpdHkgUmFkZW9uIFg4MDAgKE0yOCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4 NTAgNUQ0QyAoUENJRSksCglBVEkgUmFkZW9uIFg4NTAgWFQgUEUgKFI0ODApIChQQ0lFKSwK CUFUSSBSYWRlb24gWDg1MCBTRSAoUjQ4MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4NTAgUFJP IChSNDgwKSAoUENJRSksCglBVEkgdW5rbm93biBSYWRlb24gLyBGaXJlR0wgKFI0ODApIDVE NTAgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODUwIFhUIChSNDgwKSAoUENJRSksCglBVEkgUmFk ZW9uIFg4MDBYVCAoUjQyMykgNUQ1NyAoUENJRSksCglBVEkgRmlyZUdMIFY1MDAwIChSVjQx MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgWFQgKFJWNDEwKSAoUENJRSksCglBVEkgUmFk ZW9uIFg3MDAgUFJPIChSVjQxMCkgKFBDSUUpLAoJQVRJIFJhZGVvbiBYNzAwIFNFIChSVjQx MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgKFJWNDEwKSAoUENJRSksCglBVEkgUmFkZW9u IFg3MDAgU0UgKFJWNDEwKSAoUENJRSksIEFUSSBSYWRlb24gWDE4MDAsCglBVEkgTW9iaWxp dHkgUmFkZW9uIFgxODAwIFhULCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxODAwLAoJQVRJIE1v YmlsaXR5IEZpcmVHTCBWNzIwMCwgQVRJIEZpcmVHTCBWNzIwMCwgQVRJIEZpcmVHTCBWNTMw MCwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjcxMDAsIEFUSSBSYWRlb24gWDE4MDAsIEFUSSBS YWRlb24gWDE4MDAsCglBVEkgUmFkZW9uIFgxODAwLCBBVEkgUmFkZW9uIFgxODAwLCBBVEkg UmFkZW9uIFgxODAwLAoJQVRJIEZpcmVHTCBWNzMwMCwgQVRJIEZpcmVHTCBWNzM1MCwgQVRJ IFJhZGVvbiBYMTYwMCwgQVRJIFJWNTA1LAoJQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwgQVRJ IFJhZGVvbiBYMTU1MCwgQVRJIE01NC1HTCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDE0MDAs IEFUSSBSYWRlb24gWDEzMDAvWDE1NTAsCglBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJ IE1vYmlsaXR5IFJhZGVvbiBYMTMwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDEzMDAsIEFU SSBNb2JpbGl0eSBSYWRlb24gWDEzMDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgxMzAwLCBB VEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxMzAwLAoJQVRJIFJWNTA1LCBBVEkgUlY1 MDUsIEFUSSBGaXJlR0wgVjMzMDAsIEFUSSBGaXJlR0wgVjMzNTAsCglBVEkgUmFkZW9uIFgx MzAwLCBBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJIFJhZGVvbiBYMTMwMC9YMTU1MCwK CUFUSSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDEzMDAvWDE1NTAsIEFUSSBNb2JpbGl0 eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAwL1gxNTUwLCBBVEkgTW9iaWxpdHkg UmFkZW9uIFgyMzAwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBYMjMwMCwgQVRJIE1vYmlsaXR5 IFJhZGVvbiBYMTM1MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDEzNTAsIEFUSSBNb2JpbGl0 eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxNTUwLCBB VEkgTW9iaWxpdHkgUmFkZW9uIFgxMzUwLAoJQVRJIEZpcmVNViAyMjUwLCBBVEkgUmFkZW9u IFgxNTUwIDY0LWJpdCwgQVRJIFJhZGVvbiBYMTYwMCwKCUFUSSBSYWRlb24gWDE2NTAsIEFU SSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDE2MDAsCglBVEkgTW9iaWxpdHkgRmlyZUdM IFY1MjAwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNjAwLAoJQVRJIFJhZGVvbiBYMTY1MCwg QVRJIFJhZGVvbiBYMTY1MCwgQVRJIFJhZGVvbiBYMTYwMCwKCUFUSSBSYWRlb24gWDEzMDAg WFQvWDE2MDAgUHJvLCBBVEkgRmlyZUdMIFYzNDAwLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBW NTI1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTcwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24g WDE3MDAgWFQsIEFUSSBGaXJlR0wgVjUyMDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNzAw LCBBVEkgUmFkZW9uIFgyMzAwSEQsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDIzMDAsIEFU SSBNb2JpbGl0eSBSYWRlb24gSEQgMjMwMCwKCUFUSSBSYWRlb24gWDE5NTAsIEFUSSBSYWRl b24gWDE5MDAsIEFUSSBSYWRlb24gWDE5NTAsCglBVEkgUmFkZW9uIFgxOTAwLCBBVEkgUmFk ZW9uIFgxOTAwLCBBVEkgUmFkZW9uIFgxOTAwLAoJQVRJIFJhZGVvbiBYMTkwMCwgQVRJIFJh ZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTkwMCwKCUFUSSBSYWRlb24gWDE5MDAsIEFUSSBS YWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5MDAsCglBVEkgQU1EIFN0cmVhbSBQcm9jZXNz b3IsIEFUSSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5NTAsCglBVEkgUlY1NjAsIEFU SSBSVjU2MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTkwMCwgQVRJIFJWNTYwLAoJQVRJIFJh ZGVvbiBYMTk1MCBHVCwgQVRJIFJWNTcwLCBBVEkgUlY1NzAsIEFUSSBGaXJlR0wgVjc0MDAs CglBVEkgUlY1NjAsIEFUSSBSYWRlb24gWDE2NTAsIEFUSSBSYWRlb24gWDE2NTAsIEFUSSBS VjU2MCwKCUFUSSBSYWRlb24gOTEwMCBQUk8gSUdQIDc4MzQsIEFUSSBSYWRlb24gTW9iaWxp dHkgOTIwMCBJR1AgNzgzNSwKCUFUSSBSYWRlb24gWDEyMDAsIEFUSSBSYWRlb24gWDEyMDAs IEFUSSBSYWRlb24gWDEyMDAsCglBVEkgUmFkZW9uIFgxMjAwLCBBVEkgUmFkZW9uIFgxMjAw LCBBVEkgUlM3NDAsIEFUSSBSUzc0ME0sIEFUSSBSUzc0MCwKCUFUSSBSUzc0ME0sIEFUSSBS YWRlb24gSEQgMjkwMCBYVCwgQVRJIFJhZGVvbiBIRCAyOTAwIFhULAoJQVRJIFJhZGVvbiBI RCAyOTAwIFhULCBBVEkgUmFkZW9uIEhEIDI5MDAgUHJvLCBBVEkgUmFkZW9uIEhEIDI5MDAg R1QsCglBVEkgRmlyZUdMIFY4NjUwLCBBVEkgRmlyZUdMIFY4NjAwLCBBVEkgRmlyZUdMIFY3 NjAwLAoJQVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA0ODcwIHgyLAoJ QVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA0ODUwIHgyLAoJQVRJIEZp cmVQcm8gVjg3NTAgKEZpcmVHTCksIEFUSSBGaXJlUHJvIFY3NzYwIChGaXJlR0wpLAoJQVRJ IE1vYmlsaXR5IFJBREVPTiBIRCA0ODUwLCBBVEkgTW9iaWxpdHkgUkFERU9OIEhEIDQ4NTAg WDIsCglBVEkgUmFkZW9uIDQ4MDAgU2VyaWVzLCBBVEkgRmlyZVBybyBSVjc3MCwgQU1EIEZp cmVTdHJlYW0gOTI3MCwKCUFNRCBGaXJlU3RyZWFtIDkyNTAsIEFUSSBGaXJlUHJvIFY4NzAw IChGaXJlR0wpLAoJQVRJIE1vYmlsaXR5IFJBREVPTiBIRCA0ODcwLCBBVEkgTW9iaWxpdHkg UkFERU9OIE05OCwKCUFUSSBNb2JpbGl0eSBSQURFT04gSEQgNDg3MCwgQVRJIFJhZGVvbiA0 ODAwIFNlcmllcywKCUFUSSBSYWRlb24gNDgwMCBTZXJpZXMsIEFUSSBGaXJlUHJvIE03NzUw LCBBVEkgTTk4LCBBVEkgTTk4LCBBVEkgTTk4LAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0 NjUwLCBBVEkgUmFkZW9uIFJWNzMwIChBR1ApLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0 NjcwLCBBVEkgRmlyZVBybyBNNTc1MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgNDY3MCwg QVRJIFJhZGVvbiBSVjczMCAoQUdQKSwKCUFUSSBSVjczMFhUIFtSYWRlb24gSEQgNDY3MF0s IEFUSSBSQURFT04gRTQ2MDAsCglBVEkgUmFkZW9uIEhEIDQ2MDAgU2VyaWVzLCBBVEkgUlY3 MzAgUFJPIFtSYWRlb24gSEQgNDY1MF0sCglBVEkgRmlyZVBybyBWNzc1MCAoRmlyZUdMKSwg QVRJIEZpcmVQcm8gVjU3MDAgKEZpcmVHTCksCglBVEkgRmlyZVBybyBWMzc1MCAoRmlyZUdM KSwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0ODMwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBI RCA0ODUwLCBBVEkgRmlyZVBybyBNNzc0MCwgQVRJIFJWNzQwLAoJQVRJIFJhZGVvbiBIRCA0 NzcwLCBBVEkgUmFkZW9uIEhEIDQ3MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDQ3NzAsCglB VEkgRmlyZVBybyBNNTc1MCwgQVRJIFJWNjEwLCBBVEkgUmFkZW9uIEhEIDI0MDAgWFQsCglB VEkgUmFkZW9uIEhEIDI0MDAgUHJvLCBBVEkgUmFkZW9uIEhEIDI0MDAgUFJPIEFHUCwgQVRJ IEZpcmVHTCBWNDAwMCwKCUFUSSBSVjYxMCwgQVRJIFJhZGVvbiBIRCAyMzUwLCBBVEkgTW9i aWxpdHkgUmFkZW9uIEhEIDI0MDAgWFQsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI0MDAs IEFUSSBSQURFT04gRTI0MDAsIEFUSSBSVjYxMCwKCUFUSSBGaXJlTVYgMjI2MCwgQVRJIFJW NjcwLCBBVEkgUmFkZW9uIEhEMzg3MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg1MCwg QVRJIFJhZGVvbiBIRDM4NTAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM4NTAgWDIsIEFU SSBSVjY3MCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg3MCwgQVRJIE1vYmlsaXR5IFJh ZGVvbiBIRCAzODcwIFgyLAoJQVRJIFJhZGVvbiBIRDM4NzAgWDIsIEFUSSBGaXJlR0wgVjc3 MDAsIEFUSSBSYWRlb24gSEQzODUwLAoJQVRJIFJhZGVvbiBIRDM2OTAsIEFNRCBGaXJlc3Ry ZWFtIDkxNzAsIEFUSSBSYWRlb24gSEQgNDU1MCwKCUFUSSBSYWRlb24gUlY3MTAsIEFUSSBS YWRlb24gUlY3MTAsIEFUSSBSYWRlb24gUlY3MTAsCglBVEkgUmFkZW9uIEhEIDQzNTAsIEFU SSBNb2JpbGl0eSBSYWRlb24gNDMwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1 MDAgU2VyaWVzLCBBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1MDAgU2VyaWVzLAoJQVRJIEZpcmVQ cm8gUkcyMjAsIEFUSSBNb2JpbGl0eSBSYWRlb24gNDMzMCwgQVRJIFJWNjMwLAoJQVRJIE1v YmlsaXR5IFJhZGVvbiBIRCAyNjAwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDI2MDAgWFQs CglBVEkgUmFkZW9uIEhEIDI2MDAgWFQgQUdQLCBBVEkgUmFkZW9uIEhEIDI2MDAgUHJvIEFH UCwKCUFUSSBSYWRlb24gSEQgMjYwMCBYVCwgQVRJIFJhZGVvbiBIRCAyNjAwIFBybywgQVRJ IEdlbWluaSBSVjYzMCwKCUFUSSBHZW1pbmkgTW9iaWxpdHkgUmFkZW9uIEhEIDI2MDAgWFQs IEFUSSBGaXJlR0wgVjU2MDAsCglBVEkgRmlyZUdMIFYzNjAwLCBBVEkgUmFkZW9uIEhEIDI2 MDAgTEUsCglBVEkgTW9iaWxpdHkgRmlyZUdMIEdyYXBoaWNzIFByb2Nlc3NvciwgQVRJIFJh ZGVvbiBIRCAzNDcwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNDMwLCBBVEkgTW9iaWxp dHkgUmFkZW9uIEhEIDM0MDAgU2VyaWVzLAoJQVRJIFJhZGVvbiBIRCAzNDUwLCBBVEkgUmFk ZW9uIEhEIDM0NTAsIEFUSSBSYWRlb24gSEQgMzQzMCwKCUFUSSBSYWRlb24gSEQgMzQ1MCwg QVRJIEZpcmVQcm8gVjM3MDAsIEFUSSBGaXJlTVYgMjQ1MCwKCUFUSSBGaXJlTVYgMjI2MCwg QVRJIEZpcmVNViAyMjYwLCBBVEkgUmFkZW9uIEhEIDM2MDAgU2VyaWVzLAoJQVRJIFJhZGVv biBIRCAzNjUwIEFHUCwgQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywKCUFUSSBSYWRlb24gSEQg MzYwMCBYVCwgQVRJIFJhZGVvbiBIRCAzNjAwIFBSTywKCUFUSSBNb2JpbGl0eSBSYWRlb24g SEQgMzY1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAzNjcwLAoJQVRJIE1vYmlsaXR5IEZp cmVHTCBWNTcwMCwgQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTcyNSwKCUFUSSBSYWRlb24gSEQg MzIwMCBHcmFwaGljcywgQVRJIFJhZGVvbiAzMTAwIEdyYXBoaWNzLAoJQVRJIFJhZGVvbiBI RCAzMjAwIEdyYXBoaWNzLCBBVEkgUmFkZW9uIDMxMDAgR3JhcGhpY3MsCglBVEkgUmFkZW9u IEhEIDMzMDAgR3JhcGhpY3MsIEFUSSBSYWRlb24gSEQgMzIwMCBHcmFwaGljcywKCUFUSSBS YWRlb24gMzAwMCBHcmFwaGljcywgU1VNTywgU1VNTywgU1VNTzIsIFNVTU8yLCBTVU1PMiwg U1VNTzIsCglTVU1PLCBTVU1PLCBTVU1PLCBTVU1PLCBTVU1PLCBBVEkgUmFkZW9uIEhEIDQy MDAsIEFUSSBSYWRlb24gNDEwMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgNDIwMCwgQVRJ IE1vYmlsaXR5IFJhZGVvbiA0MTAwLAoJQVRJIFJhZGVvbiBIRCA0MjkwLCBBVEkgUmFkZW9u IEhEIDQyNTAsIEFNRCBSYWRlb24gSEQgNjMxMCBHcmFwaGljcywKCUFNRCBSYWRlb24gSEQg NjMxMCBHcmFwaGljcywgQU1EIFJhZGVvbiBIRCA2MjUwIEdyYXBoaWNzLAoJQU1EIFJhZGVv biBIRCA2MjUwIEdyYXBoaWNzLCBBTUQgUmFkZW9uIEhEIDYzMDAgU2VyaWVzIEdyYXBoaWNz LAoJQU1EIFJhZGVvbiBIRCA2MjAwIFNlcmllcyBHcmFwaGljcywgQ1lQUkVTUywKCUFUSSBG aXJlUHJvIChGaXJlR0wpIEdyYXBoaWNzIEFkYXB0ZXIsCglBVEkgRmlyZVBybyAoRmlyZUdM KSBHcmFwaGljcyBBZGFwdGVyLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRh cHRlciwgQU1EIEZpcmVzdHJlYW0gOTM3MCwKCUFNRCBGaXJlc3RyZWFtIDkzNTAsIEFUSSBS YWRlb24gSEQgNTgwMCBTZXJpZXMsCglBVEkgUmFkZW9uIEhEIDU4MDAgU2VyaWVzLCBBVEkg UmFkZW9uIEhEIDU4MDAgU2VyaWVzLAoJQVRJIFJhZGVvbiBIRCA1ODAwIFNlcmllcywgQVRJ IFJhZGVvbiBIRCA1OTAwIFNlcmllcywKCUFUSSBSYWRlb24gSEQgNTkwMCBTZXJpZXMsIEFU SSBNb2JpbGl0eSBSYWRlb24gSEQgNTgwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9u IEhEIDU4MDAgU2VyaWVzLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRl ciwKCUFUSSBGaXJlUHJvIChGaXJlR0wpIEdyYXBoaWNzIEFkYXB0ZXIsCglBVEkgTW9iaWxp dHkgUmFkZW9uIEhEIDU4MDAgU2VyaWVzLCBBVEkgUmFkZW9uIEhEIDU3MDAgU2VyaWVzLAoJ QVRJIFJhZGVvbiBIRCA1NzAwIFNlcmllcywgQVRJIFJhZGVvbiBIRCA2NzAwIFNlcmllcywK CUFUSSBSYWRlb24gSEQgNTcwMCBTZXJpZXMsIEFUSSBSYWRlb24gSEQgNjcwMCBTZXJpZXMs CglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDUwMDAgU2VyaWVzLAoJQVRJIE1vYmlsaXR5IFJh ZGVvbiBIRCA1MDAwIFNlcmllcywgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA1NTcwLAoJQVRJ IEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRlciwKCUFUSSBGaXJlUHJvIChGaXJl R0wpIEdyYXBoaWNzIEFkYXB0ZXIsIEFUSSBSYWRlb24gSEQgNTY3MCwKCUFUSSBSYWRlb24g SEQgNTU3MCwgQVRJIFJhZGVvbiBIRCA1NTAwIFNlcmllcywgUkVEV09PRCwKCUFUSSBNb2Jp bGl0eSBSYWRlb24gSEQgNTAwMCBTZXJpZXMsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDUw MDAgU2VyaWVzLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEdyYXBoaWNzLAoJQVRJIE1vYmlsaXR5 IFJhZGVvbiBHcmFwaGljcywgQ0VEQVIsCglBVEkgRmlyZVBybyAoRmlyZUdMKSBHcmFwaGlj cyBBZGFwdGVyLAoJQVRJIEZpcmVQcm8gKEZpcmVHTCkgR3JhcGhpY3MgQWRhcHRlciwgQVRJ IEZpcmVQcm8gMjI3MCwgQ0VEQVIsCglBVEkgUmFkZW9uIEhEIDU0NTAsIENFREFSLCBDQVlN QU4sIENBWU1BTiwgQ0FZTUFOLCBDQVlNQU4sIENBWU1BTiwKCUNBWU1BTiwgQ0FZTUFOLCBD QVlNQU4sIENBWU1BTiwgQ0FZTUFOLCBBTUQgUmFkZW9uIEhEIDY5MDAgU2VyaWVzLAoJQU1E IFJhZGVvbiBIRCA2OTAwIFNlcmllcywgQ0FZTUFOLCBDQVlNQU4sIENBWU1BTiwKCUFNRCBS YWRlb24gSEQgNjkwME0gU2VyaWVzLCBNb2JpbGl0eSBSYWRlb24gSEQgNjAwMCBTZXJpZXMs IEJBUlRTLAoJQkFSVFMsIE1vYmlsaXR5IFJhZGVvbiBIRCA2MDAwIFNlcmllcywKCU1vYmls aXR5IFJhZGVvbiBIRCA2MDAwIFNlcmllcywgQkFSVFMsIEJBUlRTLCBCQVJUUywgQkFSVFMs CglBTUQgUmFkZW9uIEhEIDY4MDAgU2VyaWVzLCBBTUQgUmFkZW9uIEhEIDY4MDAgU2VyaWVz LAoJQU1EIFJhZGVvbiBIRCA2NzAwIFNlcmllcywgVFVSS1MsIFRVUktTLCBUVVJLUywgVFVS S1MsIFRVUktTLCBUVVJLUywKCVRVUktTLCBUVVJLUywgVFVSS1MsIFRVUktTLCBUVVJLUywg VFVSS1MsIFRVUktTLCBUVVJLUywgQ0FJQ09TLAoJQ0FJQ09TLCBDQUlDT1MsIENBSUNPUywg Q0FJQ09TLCBDQUlDT1MsIENBSUNPUywgQ0FJQ09TLCBDQUlDT1MsCglDQUlDT1MsIENBSUNP UywgQ0FJQ09TCihJSSkgVkVTQTogZHJpdmVyIGZvciBWRVNBIGNoaXBzZXRzOiB2ZXNhCihJ SSkgUHJpbWFyeSBEZXZpY2UgaXM6IFBDSSAwMUAwMDowNTowCihXVykgRmFsbGluZyBiYWNr IHRvIG9sZCBwcm9iZSBtZXRob2QgZm9yIHZlc2EKKFdXKSBWR0EgYXJiaXRlcjogY2Fubm90 IG9wZW4ga2VybmVsIGFyYml0ZXIsIG5vIG11bHRpLWNhcmQgc3VwcG9ydAooSUkpIFJBREVP TigwKTogVE9UTyBTQVlTIDAwMDAwMDAwZDg1MDAwMDAKKElJKSBSQURFT04oMCk6IE1NSU8g cmVnaXN0ZXJzIGF0IDB4MDAwMDAwMDBkODUwMDAwMDogc2l6ZSA2NEtCCihJSSkgUkFERU9O KDApOiBQQ0kgYnVzIDEgY2FyZCA1IGZ1bmMgMAooSUkpIFJBREVPTigwKTogQ3JlYXRpbmcg ZGVmYXVsdCBEaXNwbGF5IHN1YnNlY3Rpb24gaW4gU2NyZWVuIHNlY3Rpb24KCSJCdWlsdGlu IERlZmF1bHQgYXRpIFNjcmVlbiAwIiBmb3IgZGVwdGgvZmJicHAgMjQvMzIKKD09KSBSQURF T04oMCk6IERlcHRoIDI0LCAoLS0pIGZyYW1lYnVmZmVyIGJwcCAzMgooSUkpIFJBREVPTigw KTogUGl4ZWwgZGVwdGggPSAyNCBiaXRzIHN0b3JlZCBpbiA0IGJ5dGVzICgzMiBicHAgcGl4 bWFwcykKKD09KSBSQURFT04oMCk6IERlZmF1bHQgdmlzdWFsIGlzIFRydWVDb2xvcgooSUkp IExvYWRpbmcgc3ViIG1vZHVsZSAidmdhaHciCihJSSkgTG9hZE1vZHVsZTogInZnYWh3Igoo SUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2xpYnZnYWh3LnNvCihJ SSkgTW9kdWxlIHZnYWh3OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMC4xLjAKCUFCSSBjbGFzczogWC5PcmcgVmlk ZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAooSUkpIFJBREVPTigwKTogdmdhSFdHZXRJT0Jhc2U6 IGh3cC0+SU9CYXNlIGlzIDB4MDNkMCwgaHdwLT5QSU9PZmZzZXQgaXMgMHgwMDAwCig9PSkg UkFERU9OKDApOiBSR0Igd2VpZ2h0IDg4OAooSUkpIFJBREVPTigwKTogVXNpbmcgOCBiaXRz IHBlciBSR0IgKDggYml0IERBQykKKC0tKSBSQURFT04oMCk6IENoaXBzZXQ6ICJBVEkgUmFk ZW9uIFgxMjAwIiAoQ2hpcElEID0gMHg3OTFlKQooLS0pIFJBREVPTigwKTogTGluZWFyIGZy YW1lYnVmZmVyIGF0IDB4MDAwMDAwMDBkMDAwMDAwMAooSUkpIFJBREVPTigwKTogUENJIGNh cmQgZGV0ZWN0ZWQKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImludDEwIgooSUkpIExvYWRN b2R1bGU6ICJpbnQxMCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxl cy9saWJpbnQxMC5zbwooSUkpIE1vZHVsZSBpbnQxMDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0 aW9uIgoJY29tcGlsZWQgZm9yIDEuNy43LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkg Y2xhc3M6IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiA2LjAKKElJKSBSQURFT04oMCk6 IGluaXRpYWxpemluZyBpbnQxMAooPT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweGEwMDAwLDB4MjAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgUkFERU9OKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YzAwMDAsMHg0MDAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKElJKSBSQURFT04oMCk6IFByaW1hcnkgVl9CSU9TIHNlZ21lbnQgaXM6IDB4YzAw MAooPT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooSUkpIFJBREVPTigwKTogQVRPTSBCSU9TIGRldGVjdGVkCihJ SSkgUkFERU9OKDApOiBBVE9NIEJJT1MgUm9tOiAKCVN1YnN5c3RlbVZlbmRvcklEOiAweDEw M2MgU3Vic3lzdGVtSUQ6IDB4MTJmZgoJSU9CYXNlQWRkcmVzczogMHgxMTAwCglGaWxlbmFt ZTogYnIyNjM3My5iaW4gCglCSU9TIEJvb3R1cCBNZXNzYWdlOiANCkFUSSBSYWRlb24gWHBy ZXNzID8xMjUwPyBmb3IgTW9yYXkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCgooSUkpIFJBREVPTigwKTogRnJhbWVidWZmZXIgc3BhY2UgdXNlZCBieSBG aXJtd2FyZSAoa2IpOiAxNgooSUkpIFJBREVPTigwKTogU3RhcnQgb2YgVlJBTSBhcmVhIHVz ZWQgYnkgRmlybXdhcmU6IDB4N2ZmYzAwMAooSUkpIFJBREVPTigwKTogQXRvbUJJT1MgcmVx dWVzdHMgMTZrQiBvZiBWUkFNIHNjcmF0Y2ggc3BhY2UKKElJKSBSQURFT04oMCk6IEF0b21C SU9TIFZSQU0gc2NyYXRjaCBiYXNlOiAweDdmZmMwMDAKKElJKSBSQURFT04oMCk6IENhbm5v dCBnZXQgVlJBTSBzY3JhdGNoIHNwYWNlLiBBbGxvY2F0aW5nIGluIG1haW4gbWVtb3J5IGlu c3RlYWQKKElJKSBSQURFT04oMCk6IERlZmF1bHQgRW5naW5lIENsb2NrOiA0MDAwMDAKKElJ KSBSQURFT04oMCk6IERlZmF1bHQgTWVtb3J5IENsb2NrOiAyMDAwMDAKKElJKSBSQURFT04o MCk6IE1heGltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJlcXVlbmN5IE91dHB1dDogMTIwMDAwMAoo SUkpIFJBREVPTigwKTogTWluaW11bSBQaXhlbCBDbG9ja1BMTCBGcmVxdWVuY3kgT3V0cHV0 OiAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBpeGVsIENsb2NrUExMIEZyZXF1ZW5jeSBJ bnB1dDogMTM1MDAKKElJKSBSQURFT04oMCk6IE1pbmltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJl cXVlbmN5IElucHV0OiAxMDAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBpeGVsIENsb2Nr OiA0MDAwMDAKKElJKSBSQURFT04oMCk6IFJlZmVyZW5jZSBDbG9jazogMTQzMjAKZHJtT3Bl bkRldmljZTogbm9kZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCkZhaWxlZCB0byBjaGFuZ2Ug b3duZXIgb3IgZ3JvdXAgZm9yIGZpbGUgL2Rldi9kcmkhIDI6IE5vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnkKRmFpbGVkIHRvIGNoYW5nZSBvd25lciBvciBncm91cCBmb3IgZmlsZSAvZGV2 L2RyaS9jYXJkMCEgMjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpkcm1PcGVuRGV2aWNl OiBvcGVuIHJlc3VsdCBpcyAtMSwgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCkZhaWxl ZCB0byBjaGFuZ2Ugb3duZXIgb3IgZ3JvdXAgZm9yIGZpbGUgL2Rldi9kcmkvY2FyZDAhIDI6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQg aXMgLTEsIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpkcm1PcGVuRGV2aWNlOiBPcGVu IGZhaWxlZApbZHJtXSBmYWlsZWQgdG8gbG9hZCBrZXJuZWwgbW9kdWxlICJyYWRlb24iCihF RSkgUkFERU9OKDApOiBbZHJpXSBSQURFT05EUklHZXRWZXJzaW9uIGZhaWxlZCB0byBvcGVu IHRoZSBEUk0KW2RyaV0gRGlzYWJsaW5nIERSSS4KKElJKSBSQURFT04oMCk6IEdlbmVyYXRp b24gMiBQQ0kgaW50ZXJmYWNlLCB1c2luZyBtYXggYWNjZXNzaWJsZSBtZW1vcnkKKElJKSBS QURFT04oMCk6IERldGVjdGVkIHRvdGFsIHZpZGVvIFJBTT0xMzEwNzJLLCBhY2Nlc3NpYmxl PTEzMTA3MksgKFBDSSBCQVI9MTMxMDcySykKKC0tKSBSQURFT04oMCk6IE1hcHBlZCBWaWRl b1JBTTogMTMxMDcyIGtCeXRlICgxMjggYml0IEREUiBTRFJBTSkKKElJKSBSQURFT04oMCk6 IENvbG9yIHRpbGluZyBlbmFibGVkIGJ5IGRlZmF1bHQKKElJKSBMb2FkaW5nIHN1YiBtb2R1 bGUgImRkYyIKKElJKSBMb2FkTW9kdWxlOiAiZGRjIgooSUkpIE1vZHVsZSAiZGRjIiBhbHJl YWR5IGJ1aWx0LWluCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJpMmMiCihJSSkgTG9hZE1v ZHVsZTogImkyYyIKKElJKSBNb2R1bGUgImkyYyIgYWxyZWFkeSBidWlsdC1pbgooSUkpIFJB REVPTigwKTogUExMIHBhcmFtZXRlcnM6IHJmPTE0MzIgcmQ9MTIgbWluPTgwMDAwIG1heD0x MjAwMDA7IHhjbGs9NDAwMDAKKElJKSBSQURFT04oMCk6IE91dHB1dCBWR0EtMCBoYXMgbm8g bW9uaXRvciBzZWN0aW9uCihJSSkgUkFERU9OKDApOiBJMkMgYnVzICJWR0EtMCIgaW5pdGlh bGl6ZWQuCihJSSkgUkFERU9OKDApOiBPdXRwdXQgSERNSS0wIGhhcyBubyBtb25pdG9yIHNl Y3Rpb24KKElJKSBSQURFT04oMCk6IEkyQyBidXMgIkhETUktMCIgaW5pdGlhbGl6ZWQuCihJ SSkgUkFERU9OKDApOiBQb3J0MDoKICBYUkFORFIgbmFtZTogVkdBLTAKICBDb25uZWN0b3I6 IFZHQQogIENSVDE6IElOVEVSTkFMX0tMRFNDUF9EQUMxCiAgRERDIHJlZzogMHg3ZTUwCihJ SSkgUkFERU9OKDApOiBQb3J0MToKICBYUkFORFIgbmFtZTogSERNSS0wCiAgQ29ubmVjdG9y OiBIRE1JLUEKICBERlAzOiBJTlRFUk5BTF9MVlRNMQogIEREQyByZWc6IDB4N2U0MAooSUkp IFJBREVPTigwKTogSTJDIGRldmljZSAiVkdBLTA6ZGRjMiIgcmVnaXN0ZXJlZCBhdCBhZGRy ZXNzIDB4QTAuCkRhYyBkZXRlY3Rpb24gc3VjY2VzcwooSUkpIFJBREVPTigwKTogT3V0cHV0 OiBWR0EtMCwgRGV0ZWN0ZWQgTW9uaXRvciBUeXBlOiAwCmZpbmlzaGVkIG91dHB1dCBkZXRl Y3Q6IDAKKElJKSBSQURFT04oMCk6IEkyQyBkZXZpY2UgIkhETUktMDpkZGMyIiByZWdpc3Rl cmVkIGF0IGFkZHJlc3MgMHhBMC4KKElJKSBSQURFT04oMCk6IEkyQyBkZXZpY2UgIkhETUkt MDpEREMgY29udHJvbCBpbnRlcmZhY2UiIHJlZ2lzdGVyZWQgYXQgYWRkcmVzcyAweDZFLgoo SUkpIFJBREVPTigwKTogT3V0cHV0OiBIRE1JLTAsIERldGVjdGVkIE1vbml0b3IgVHlwZTog MwooSUkpIFJBREVPTigwKTogRURJRCBkYXRhIGZyb20gdGhlIGRpc3BsYXkgb24gb3V0cHV0 OiBIRE1JLTAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQooSUkpIFJBREVPTigwKTogTWFudWZh Y3R1cmVyOiBORUMgIE1vZGVsOiA2NjhlICBTZXJpYWwjOiAxNjg0MzAwOQooSUkpIFJBREVP TigwKTogWWVhcjogMjAwNyAgV2VlazogMjQKKElJKSBSQURFT04oMCk6IEVESUQgVmVyc2lv bjogMS4zCihJSSkgUkFERU9OKDApOiBEaWdpdGFsIERpc3BsYXkgSW5wdXQKKElJKSBSQURF T04oMCk6IE1heCBJbWFnZSBTaXplIFtjbV06IGhvcml6LjogMzggIHZlcnQuOiAzMAooSUkp IFJBREVPTigwKTogR2FtbWE6IDIuMjAKKElJKSBSQURFT04oMCk6IERQTVMgY2FwYWJpbGl0 aWVzOiBTdGFuZEJ5IFN1c3BlbmQgT2ZmCihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgY29s b3IgZW5jb2RpbmdzOiBSR0IgNDo0OjQgWUNyQ2IgNDo0OjQgCihJSSkgUkFERU9OKDApOiBG aXJzdCBkZXRhaWxlZCB0aW1pbmcgaXMgcHJlZmVycmVkIG1vZGUKKElJKSBSQURFT04oMCk6 IHJlZFg6IDAuNjQxIHJlZFk6IDAuMzUzICAgZ3JlZW5YOiAwLjI4OSBncmVlblk6IDAuNjI2 CihJSSkgUkFERU9OKDApOiBibHVlWDogMC4xNDIgYmx1ZVk6IDAuMDc4ICAgd2hpdGVYOiAw LjMxMyB3aGl0ZVk6IDAuMzI5CihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgZXN0YWJsaXNo ZWQgdGltaW5nczoKKElJKSBSQURFT04oMCk6IDcyMHg0MDBANzBIegooSUkpIFJBREVPTigw KTogNjQweDQ4MEA2MEh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDY3SHoKKElJKSBSQURF T04oMCk6IDY0MHg0ODBANzJIegooSUkpIFJBREVPTigwKTogNjQweDQ4MEA3NUh6CihJSSkg UkFERU9OKDApOiA4MDB4NjAwQDU2SHoKKElJKSBSQURFT04oMCk6IDgwMHg2MDBANjBIegoo SUkpIFJBREVPTigwKTogODAweDYwMEA3Mkh6CihJSSkgUkFERU9OKDApOiA4MDB4NjAwQDc1 SHoKKElJKSBSQURFT04oMCk6IDgzMng2MjRANzVIegooSUkpIFJBREVPTigwKTogMTAyNHg3 NjhANjBIegooSUkpIFJBREVPTigwKTogMTAyNHg3NjhANzBIegooSUkpIFJBREVPTigwKTog MTAyNHg3NjhANzVIegooSUkpIFJBREVPTigwKTogMTI4MHgxMDI0QDc1SHoKKElJKSBSQURF T04oMCk6IDExNTJ4ODY0QDc1SHoKKElJKSBSQURFT04oMCk6IE1hbnVmYWN0dXJlcidzIG1h c2s6IDAKKElJKSBSQURFT04oMCk6IFN1cHBvcnRlZCBzdGFuZGFyZCB0aW1pbmdzOgooSUkp IFJBREVPTigwKTogIzA6IGhzaXplOiAxMTUyICB2c2l6ZSA4NjQgIHJlZnJlc2g6IDc1ICB2 aWQ6IDIwMzM3CihJSSkgUkFERU9OKDApOiAjMTogaHNpemU6IDEyODAgIHZzaXplIDk2MCAg cmVmcmVzaDogNjAgIHZpZDogMTY1MTMKKElJKSBSQURFT04oMCk6ICMyOiBoc2l6ZTogMTI4 MCAgdnNpemUgMTAyNCAgcmVmcmVzaDogNjAgIHZpZDogMzI4OTcKKElJKSBSQURFT04oMCk6 IFN1cHBvcnRlZCBkZXRhaWxlZCB0aW1pbmc6CihJSSkgUkFERU9OKDApOiBjbG9jazogMTA4 LjAgTUh6ICAgSW1hZ2UgU2l6ZTogIDM3NiB4IDMwMSBtbQooSUkpIFJBREVPTigwKTogaF9h Y3RpdmU6IDEyODAgIGhfc3luYzogMTMyOCAgaF9zeW5jX2VuZCAxNDQwIGhfYmxhbmtfZW5k IDE2ODggaF9ib3JkZXI6IDAKKElJKSBSQURFT04oMCk6IHZfYWN0aXZlOiAxMDI0ICB2X3N5 bmM6IDEwMjUgIHZfc3luY19lbmQgMTAyOCB2X2JsYW5raW5nOiAxMDY2IHZfYm9yZGVyOiAw CihJSSkgUkFERU9OKDApOiBSYW5nZXM6IFYgbWluOiA1NiBWIG1heDogNzUgSHosIEggbWlu OiAzMSBIIG1heDogODEga0h6LCBQaXhDbG9jayBtYXggMTQwIE1IegooSUkpIFJBREVPTigw KTogTW9uaXRvciBuYW1lOiBMQ0QxOTcwTlhwCihJSSkgUkFERU9OKDApOiBTZXJpYWwgTm86 IDc2RDA1MTE4WUIKKElJKSBSQURFT04oMCk6IEVESUQgKGluIGhleCk6CihJSSkgUkFERU9O KDApOiAJMDBmZmZmZmZmZmZmZmYwMDM4YTM4ZTY2MDEwMTAxMDEKKElJKSBSQURFT04oMCk6 IAkxODExMDEwMzgwMjYxZTc4ZWExMTQ1YTQ1YTRhYTAyNAooSUkpIFJBREVPTigwKTogCTE0 NTA1NGJmZWY4MDcxNGY4MTQwODE4MDAxMDEwMTAxCihJSSkgUkFERU9OKDApOiAJMDEwMTAx MDEwMTAxMzAyYTAwOTg1MTAwMmE0MDMwNzAKKElJKSBSQURFT04oMCk6IAkxMzAwNzgyZDEx MDAwMDFlMDAwMDAwZmQwMDM4NGIxZgooSUkpIFJBREVPTigwKTogCTUxMGUwMDBhMjAyMDIw MjAyMDIwMDAwMDAwZmMwMDRjCihJSSkgUkFERU9OKDApOiAJNDM0NDMxMzkzNzMwNGU1ODcw MGEyMDIwMDAwMDAwZmYKKElJKSBSQURFT04oMCk6IAkwMDM3MzY0NDMwMzUzMTMxMzg1OTQy MGEyMDIwMDA3YwpmaW5pc2hlZCBvdXRwdXQgZGV0ZWN0OiAxCmZpbmlzaGVkIGFsbCBkZXRl Y3QKRGFjIGRldGVjdGlvbiBzdWNjZXNzCihJSSkgUkFERU9OKDApOiBPdXRwdXQ6IFZHQS0w LCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDAKKElJKSBSQURFT04oMCk6IE91dHB1dDogSERN SS0wLCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDMKKElJKSBSQURFT04oMCk6IEVESUQgZGF0 YSBmcm9tIHRoZSBkaXNwbGF5IG9uIG91dHB1dDogSERNSS0wIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KKElJKSBSQURFT04oMCk6IE1hbnVmYWN0dXJlcjogTkVDICBNb2RlbDogNjY4ZSAg U2VyaWFsIzogMTY4NDMwMDkKKElJKSBSQURFT04oMCk6IFllYXI6IDIwMDcgIFdlZWs6IDI0 CihJSSkgUkFERU9OKDApOiBFRElEIFZlcnNpb246IDEuMwooSUkpIFJBREVPTigwKTogRGln aXRhbCBEaXNwbGF5IElucHV0CihJSSkgUkFERU9OKDApOiBNYXggSW1hZ2UgU2l6ZSBbY21d OiBob3Jpei46IDM4ICB2ZXJ0LjogMzAKKElJKSBSQURFT04oMCk6IEdhbW1hOiAyLjIwCihJ SSkgUkFERU9OKDApOiBEUE1TIGNhcGFiaWxpdGllczogU3RhbmRCeSBTdXNwZW5kIE9mZgoo SUkpIFJBREVPTigwKTogU3VwcG9ydGVkIGNvbG9yIGVuY29kaW5nczogUkdCIDQ6NDo0IFlD ckNiIDQ6NDo0IAooSUkpIFJBREVPTigwKTogRmlyc3QgZGV0YWlsZWQgdGltaW5nIGlzIHBy ZWZlcnJlZCBtb2RlCihJSSkgUkFERU9OKDApOiByZWRYOiAwLjY0MSByZWRZOiAwLjM1MyAg IGdyZWVuWDogMC4yODkgZ3JlZW5ZOiAwLjYyNgooSUkpIFJBREVPTigwKTogYmx1ZVg6IDAu MTQyIGJsdWVZOiAwLjA3OCAgIHdoaXRlWDogMC4zMTMgd2hpdGVZOiAwLjMyOQooSUkpIFJB REVPTigwKTogU3VwcG9ydGVkIGVzdGFibGlzaGVkIHRpbWluZ3M6CihJSSkgUkFERU9OKDAp OiA3MjB4NDAwQDcwSHoKKElJKSBSQURFT04oMCk6IDY0MHg0ODBANjBIegooSUkpIFJBREVP TigwKTogNjQweDQ4MEA2N0h6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDcySHoKKElJKSBS QURFT04oMCk6IDY0MHg0ODBANzVIegooSUkpIFJBREVPTigwKTogODAweDYwMEA1Nkh6CihJ SSkgUkFERU9OKDApOiA4MDB4NjAwQDYwSHoKKElJKSBSQURFT04oMCk6IDgwMHg2MDBANzJI egooSUkpIFJBREVPTigwKTogODAweDYwMEA3NUh6CihJSSkgUkFERU9OKDApOiA4MzJ4NjI0 QDc1SHoKKElJKSBSQURFT04oMCk6IDEwMjR4NzY4QDYwSHoKKElJKSBSQURFT04oMCk6IDEw MjR4NzY4QDcwSHoKKElJKSBSQURFT04oMCk6IDEwMjR4NzY4QDc1SHoKKElJKSBSQURFT04o MCk6IDEyODB4MTAyNEA3NUh6CihJSSkgUkFERU9OKDApOiAxMTUyeDg2NEA3NUh6CihJSSkg UkFERU9OKDApOiBNYW51ZmFjdHVyZXIncyBtYXNrOiAwCihJSSkgUkFERU9OKDApOiBTdXBw b3J0ZWQgc3RhbmRhcmQgdGltaW5nczoKKElJKSBSQURFT04oMCk6ICMwOiBoc2l6ZTogMTE1 MiAgdnNpemUgODY0ICByZWZyZXNoOiA3NSAgdmlkOiAyMDMzNwooSUkpIFJBREVPTigwKTog IzE6IGhzaXplOiAxMjgwICB2c2l6ZSA5NjAgIHJlZnJlc2g6IDYwICB2aWQ6IDE2NTEzCihJ SSkgUkFERU9OKDApOiAjMjogaHNpemU6IDEyODAgIHZzaXplIDEwMjQgIHJlZnJlc2g6IDYw ICB2aWQ6IDMyODk3CihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgZGV0YWlsZWQgdGltaW5n OgooSUkpIFJBREVPTigwKTogY2xvY2s6IDEwOC4wIE1IeiAgIEltYWdlIFNpemU6ICAzNzYg eCAzMDEgbW0KKElJKSBSQURFT04oMCk6IGhfYWN0aXZlOiAxMjgwICBoX3N5bmM6IDEzMjgg IGhfc3luY19lbmQgMTQ0MCBoX2JsYW5rX2VuZCAxNjg4IGhfYm9yZGVyOiAwCihJSSkgUkFE RU9OKDApOiB2X2FjdGl2ZTogMTAyNCAgdl9zeW5jOiAxMDI1ICB2X3N5bmNfZW5kIDEwMjgg dl9ibGFua2luZzogMTA2NiB2X2JvcmRlcjogMAooSUkpIFJBREVPTigwKTogUmFuZ2VzOiBW IG1pbjogNTYgViBtYXg6IDc1IEh6LCBIIG1pbjogMzEgSCBtYXg6IDgxIGtIeiwgUGl4Q2xv Y2sgbWF4IDE0MCBNSHoKKElJKSBSQURFT04oMCk6IE1vbml0b3IgbmFtZTogTENEMTk3ME5Y cAooSUkpIFJBREVPTigwKTogU2VyaWFsIE5vOiA3NkQwNTExOFlCCihJSSkgUkFERU9OKDAp OiBFRElEIChpbiBoZXgpOgooSUkpIFJBREVPTigwKTogCTAwZmZmZmZmZmZmZmZmMDAzOGEz OGU2NjAxMDEwMTAxCihJSSkgUkFERU9OKDApOiAJMTgxMTAxMDM4MDI2MWU3OGVhMTE0NWE0 NWE0YWEwMjQKKElJKSBSQURFT04oMCk6IAkxNDUwNTRiZmVmODA3MTRmODE0MDgxODAwMTAx MDEwMQooSUkpIFJBREVPTigwKTogCTAxMDEwMTAxMDEwMTMwMmEwMDk4NTEwMDJhNDAzMDcw CihJSSkgUkFERU9OKDApOiAJMTMwMDc4MmQxMTAwMDAxZTAwMDAwMGZkMDAzODRiMWYKKElJ KSBSQURFT04oMCk6IAk1MTBlMDAwYTIwMjAyMDIwMjAyMDAwMDAwMGZjMDA0YwooSUkpIFJB REVPTigwKTogCTQzNDQzMTM5MzczMDRlNTg3MDBhMjAyMDAwMDAwMGZmCihJSSkgUkFERU9O KDApOiAJMDAzNzM2NDQzMDM1MzEzMTM4NTk0MjBhMjAyMDAwN2MKKElJKSBSQURFT04oMCk6 IFBhbmVsIGluZm9zIGZvdW5kIGZyb20gRERDIGRldGFpbGVkOiAxMjgweDEwMjQKKElJKSBS QURFT04oMCk6IEVESUQgdmVuZG9yICJORUMiLCBwcm9kIGlkIDI2MjU0CihJSSkgUkFERU9O KDApOiBPdXRwdXQgVkdBLTAgZGlzY29ubmVjdGVkCihJSSkgUkFERU9OKDApOiBPdXRwdXQg SERNSS0wIGNvbm5lY3RlZAooSUkpIFJBREVPTigwKTogVXNpbmcgZXhhY3Qgc2l6ZXMgZm9y IGluaXRpYWwgbW9kZXMKKElJKSBSQURFT04oMCk6IE91dHB1dCBIRE1JLTAgdXNpbmcgaW5p dGlhbCBtb2RlIDEyODB4MTAyNAooSUkpIFJBREVPTigwKTogVXNpbmcgZGVmYXVsdCBnYW1t YSBvZiAoMS4wLCAxLjAsIDEuMCkgdW5sZXNzIG90aGVyd2lzZSBzdGF0ZWQuCig9PSkgUkFE RU9OKDApOiBEUEkgc2V0IHRvICg5NiwgOTYpCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJm YiIKKElJKSBMb2FkTW9kdWxlOiAiZmIiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94 b3JnL21vZHVsZXMvbGliZmIuc28KKElJKSBNb2R1bGUgZmI6IHZlbmRvcj0iWC5PcmcgRm91 bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJ QUJJIGNsYXNzOiBYLk9yZyBBTlNJIEMgRW11bGF0aW9uLCB2ZXJzaW9uIDAuNAooSUkpIExv YWRpbmcgc3ViIG1vZHVsZSAicmFtZGFjIgooSUkpIExvYWRNb2R1bGU6ICJyYW1kYWMiCihJ SSkgTW9kdWxlICJyYW1kYWMiIGFscmVhZHkgYnVpbHQtaW4KKD09KSBSQURFT04oMCk6IFVz aW5nIFhBQSBhY2NlbGVyYXRpb24gYXJjaGl0ZWN0dXJlCihJSSkgTG9hZGluZyBzdWIgbW9k dWxlICJ4YWEiCihJSSkgTG9hZE1vZHVsZTogInhhYSIKKElJKSBMb2FkaW5nIC91c3IvbG9j YWwvbGliL3hvcmcvbW9kdWxlcy9saWJ4YWEuc28KKElJKSBNb2R1bGUgeGFhOiB2ZW5kb3I9 IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9u ID0gMS4yLjEKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDYuMAoo PT0pIFJBREVPTigwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooISEpIFJBREVPTigwKTogTWVyZ2VkRkIgc3VwcG9ydCBoYXMgYmVl biByZW1vdmVkIGFuZCByZXBsYWNlZCB3aXRoIHhyYW5kciAxLjIgc3VwcG9ydAooSUkpIFVu bG9hZE1vZHVsZTogInZlc2EiCihJSSkgVW5sb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcv bW9kdWxlcy9kcml2ZXJzL3Zlc2FfZHJ2LnNvCigtLSkgRGVwdGggMjQgcGl4bWFwIGZvcm1h dCBpcyAzMiBicHAKKElJKSBSQURFT04oMCk6IFJBREVPTlNjcmVlbkluaXQgZDAwMDAwMDAg MCAwCig9PSkgUkFERU9OKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YTAwMDAsMHgx MDAwMCkgd2FzIGFscmVhZHkgY2xlYXIKT3V0cHV0IERGUDMgZGlzYWJsZSBzdWNjZXNzCkJs YW5rIENSVEMgMCBzdWNjZXNzCkRpc2FibGUgQ1JUQyAwIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAx IHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDEgc3VjY2VzcwooSUkpIFJBREVPTigwKTogRHluYW1p YyBQb3dlciBNYW5hZ2VtZW50IERpc2FibGVkCihJSSkgUkFERU9OKDApOiBSQURFT05Jbml0 TWVtb3J5TWFwKCkgOiAKKElJKSBSQURFT04oMCk6ICAgbWVtX3NpemUgICAgICAgICA6IDB4 MDgwMDAwMDAKKElJKSBSQURFT04oMCk6ICAgTUNfRkJfTE9DQVRJT04gICA6IDB4Y2ZmZmM4 MDAKKElJKSBSQURFT04oMCk6ICAgTUNfQUdQX0xPQ0FUSU9OICA6IDB4MDAzZjAwMDAKKElJ KSBSQURFT04oMCk6IERlcHRoIG1vdmVzIGRpc2FibGVkIGJ5IGRlZmF1bHQKKElJKSBSQURF T04oMCk6IE1lbW9yeSBtYW5hZ2VyIGluaXRpYWxpemVkIHRvICgwLDApICgxMjgwLDgxOTEp CihJSSkgUkFERU9OKDApOiBSZXNlcnZlZCBhcmVhIGZyb20gKDAsMTI4MCkgdG8gKDEyODAs MTI4MikKKElJKSBSQURFT04oMCk6IExhcmdlc3Qgb2Zmc2NyZWVuIGFyZWEgYXZhaWxhYmxl OiAxMjgwIHggNjkwOQooSUkpIFJBREVPTigwKTogUkFERU9OUmVzdG9yZU1lbU1hcFJlZ2lz dGVycygpIDogCihJSSkgUkFERU9OKDApOiAgIE1DX0ZCX0xPQ0FUSU9OICAgOiAweGNmZmZj ODAwIDB4Y2ZmZmM4MDAKKElJKSBSQURFT04oMCk6ICAgTUNfQUdQX0xPQ0FUSU9OICA6IDB4 MDAzZjAwMDAKKD09KSBSQURFT04oMCk6IEJhY2tpbmcgc3RvcmUgZGlzYWJsZWQKKFdXKSBS QURFT04oMCk6IERpcmVjdCByZW5kZXJpbmcgZGlzYWJsZWQKKElJKSBSQURFT04oMCk6IFJl bmRlciBhY2NlbGVyYXRpb24gZGlzYWJsZWQKKElJKSBSQURFT04oMCk6IG51bSBxdWFkLXBp cGVzIGlzIDEKKElJKSBSQURFT04oMCk6IFVzaW5nIFhGcmVlODYgQWNjZWxlcmF0aW9uIEFy Y2hpdGVjdHVyZSAoWEFBKQoJU2NyZWVuIHRvIHNjcmVlbiBiaXQgYmxpdHMKCVNvbGlkIGZp bGxlZCByZWN0YW5nbGVzCgk4eDggbW9ubyBwYXR0ZXJuIGZpbGxlZCByZWN0YW5nbGVzCglJ bmRpcmVjdCBDUFUgdG8gU2NyZWVuIGNvbG9yIGV4cGFuc2lvbgoJU29saWQgTGluZXMKCVNj YW5saW5lIEltYWdlIFdyaXRlcwoJU2V0dGluZyB1cCB0aWxlIGFuZCBzdGlwcGxlIGNhY2hl OgoJCTMyIDEyOHgxMjggc2xvdHMKCQkzMiAyNTZ4MjU2IHNsb3RzCgkJMTYgNTEyeDUxMiBz bG90cwooSUkpIFJBREVPTigwKTogQWNjZWxlcmF0aW9uIGVuYWJsZWQKKD09KSBSQURFT04o MCk6IERQTVMgZW5hYmxlZAooPT0pIFJBREVPTigwKTogU2lsa2VuIG1vdXNlIGVuYWJsZWQK KElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDMyIGtiIGZvciBoYXJkd2FyZSBjdXJzb3IgMCBh dCBvZmZzZXQgMHgwMDY0MzAwMAooSUkpIFJBREVPTigwKTogV2lsbCB1c2UgMzIga2IgZm9y IGhhcmR3YXJlIGN1cnNvciAxIGF0IG9mZnNldCAweDAwNjQ4MDAwCihJSSkgUkFERU9OKDAp OiBMYXJnZXN0IG9mZnNjcmVlbiBhcmVhIGF2YWlsYWJsZTogMTI4MCB4IDY5MDEKKElJKSBS QURFT04oMCk6IFRleHR1cmVkIHZpZGVvIHJlcXVpcmVzIENQIG9uIFI1eHgvUjZ4eC9SN3h4 L0lHUApPdXRwdXQgQ1JUMSBkaXNhYmxlIHN1Y2Nlc3MKT3V0cHV0IERGUDMgZGlzYWJsZSBz dWNjZXNzCkJsYW5rIENSVEMgMCBzdWNjZXNzCkRpc2FibGUgQ1JUQyAwIHN1Y2Nlc3MKQmxh bmsgQ1JUQyAxIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDEgc3VjY2VzcwpPdXRwdXQgREZQMyBk aXNhYmxlIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAwIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDAgc3Vj Y2VzcwpTZXQgQ1JUQyAwIFNvdXJjZSBzdWNjZXNzCk1vZGUgMTI4MHgxMDI0IC0gMTY4OCAx MDY2IDUKKElJKSBSQURFT04oMCk6IFJBREVPTlJlc3RvcmVNZW1NYXBSZWdpc3RlcnMoKSA6 IAooSUkpIFJBREVPTigwKTogICBNQ19GQl9MT0NBVElPTiAgIDogMHhjZmZmYzgwMCAweGNm ZmZjODAwCihJSSkgUkFERU9OKDApOiAgIE1DX0FHUF9MT0NBVElPTiAgOiAweDAwM2YwMDAw ClBpY2tlZCBQTEwgMApiZXN0X2ZyZXE6IDEwODA1MApiZXN0X2ZlZWRiYWNrX2RpdjogMTY2 CmJlc3RfZnJhY19mZWVkYmFja19kaXY6IDAKYmVzdF9yZWZfZGl2OiAyCmJlc3RfcG9zdF9k aXY6IDExCihJSSkgUkFERU9OKDApOiBjcnRjKDApIENsb2NrOiBtb2RlIDEwODAwMCwgUExM IDEwODA1MDAKKElJKSBSQURFT04oMCk6IGNydGMoMCkgUExMICA6IHJlZmRpdiAyLCBmYmRp diAweEE2KDE2NiksIGZyYWNmYmRpdiAwLCBwZGl2IDExClNldCBDUlRDIDAgUExMIHN1Y2Nl c3MKU2V0IENSVEMgVGltaW5nIHN1Y2Nlc3MKU2V0IENSVEMgMCBPdmVyc2NhbiBzdWNjZXNz Ck5vdCB1c2luZyBSTVgKc2NhbGVyIDAgc2V0dXAgc3VjY2VzcwpTZXQgQ1JUQyAwIFNvdXJj ZSBzdWNjZXNzCmNydGMgMCBZVVYgZGlzYWJsZSBzZXR1cCBzdWNjZXNzCihJSSkgUkFERU9O KDApOiBDb2hlcmVudCBNb2RlIGVuYWJsZWQKT3V0cHV0IGRpZ2l0YWwgc2V0dXAgc3VjY2Vz cwpPdXRwdXQgREZQMyBlbmFibGUgc3VjY2VzcwpFbmFibGUgQ1JUQyAwIHN1Y2Nlc3MKVW5i bGFuayBDUlRDIDAgc3VjY2VzcwpPdXRwdXQgQ1JUMSBkaXNhYmxlIHN1Y2Nlc3MKQmxhbmsg Q1JUQyAxIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDEgc3VjY2VzcwooSUkpIFJBREVPTigwKTog UmFuZFIgMS4yIGVuYWJsZWQsIGlnbm9yZSB0aGUgZm9sbG93aW5nIFJhbmRSIGRpc2FibGVk IG1lc3NhZ2UuCk91dHB1dCBERlAzIGRpc2FibGUgc3VjY2VzcwpCbGFuayBDUlRDIDAgc3Vj Y2VzcwpEaXNhYmxlIENSVEMgMCBzdWNjZXNzClNldCBDUlRDIDAgU291cmNlIHN1Y2Nlc3MK TW9kZSAxMjgweDEwMjQgLSAxNjg4IDEwNjYgNQooSUkpIFJBREVPTigwKTogUkFERU9OUmVz dG9yZU1lbU1hcFJlZ2lzdGVycygpIDogCihJSSkgUkFERU9OKDApOiAgIE1DX0ZCX0xPQ0FU SU9OICAgOiAweGNmZmZjODAwIDB4Y2ZmZmM4MDAKKElJKSBSQURFT04oMCk6ICAgTUNfQUdQ X0xPQ0FUSU9OICA6IDB4MDAzZjAwMDAKUGlja2VkIFBMTCAwCmJlc3RfZnJlcTogMTA4MDUw CmJlc3RfZmVlZGJhY2tfZGl2OiAxNjYKYmVzdF9mcmFjX2ZlZWRiYWNrX2RpdjogMApiZXN0 X3JlZl9kaXY6IDIKYmVzdF9wb3N0X2RpdjogMTEKKElJKSBSQURFT04oMCk6IGNydGMoMCkg Q2xvY2s6IG1vZGUgMTA4MDAwLCBQTEwgMTA4MDUwMAooSUkpIFJBREVPTigwKTogY3J0Yygw KSBQTEwgIDogcmVmZGl2IDIsIGZiZGl2IDB4QTYoMTY2KSwgZnJhY2ZiZGl2IDAsIHBkaXYg MTEKU2V0IENSVEMgMCBQTEwgc3VjY2VzcwpTZXQgQ1JUQyBUaW1pbmcgc3VjY2VzcwpTZXQg Q1JUQyAwIE92ZXJzY2FuIHN1Y2Nlc3MKTm90IHVzaW5nIFJNWApzY2FsZXIgMCBzZXR1cCBz dWNjZXNzClNldCBDUlRDIDAgU291cmNlIHN1Y2Nlc3MKY3J0YyAwIFlVViBkaXNhYmxlIHNl dHVwIHN1Y2Nlc3MKKElJKSBSQURFT04oMCk6IENvaGVyZW50IE1vZGUgZW5hYmxlZApPdXRw dXQgZGlnaXRhbCBzZXR1cCBzdWNjZXNzCk91dHB1dCBERlAzIGVuYWJsZSBzdWNjZXNzCkVu YWJsZSBDUlRDIDAgc3VjY2VzcwpVbmJsYW5rIENSVEMgMCBzdWNjZXNzCigtLSkgUmFuZFIg ZGlzYWJsZWQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIEdlbmVyaWMg RXZlbnQgRXh0ZW5zaW9uCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBT SEFQRQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gTUlULVNITQooSUkp IEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gWElucHV0RXh0ZW5zaW9uCihJSSkg SW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYVEVTVAooSUkpIEluaXRpYWxpemlu ZyBidWlsdC1pbiBleHRlbnNpb24gQklHLVJFUVVFU1RTCihJSSkgSW5pdGlhbGl6aW5nIGJ1 aWx0LWluIGV4dGVuc2lvbiBTWU5DCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVu c2lvbiBYS0VZQk9BUkQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhD LU1JU0MKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhJTkVSQU1BCihJ SSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYRklYRVMKKElJKSBJbml0aWFs aXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFJFTkRFUgooSUkpIEluaXRpYWxpemluZyBidWls dC1pbiBleHRlbnNpb24gUkFORFIKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5z aW9uIENPTVBPU0lURQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gREFN QUdFCihJSSkgQUlHTFg6IExvYWRlZCBhbmQgaW5pdGlhbGl6ZWQgL3Vzci9sb2NhbC9saWIv ZHJpL3N3cmFzdF9kcmkuc28KKElJKSBHTFg6IEluaXRpYWxpemVkIERSSVNXUkFTVCBHTCBw cm92aWRlciBmb3Igc2NyZWVuIDAKKElJKSBSQURFT04oMCk6IFNldHRpbmcgc2NyZWVuIHBo eXNpY2FsIHNpemUgdG8gMzM4IHggMjcwCihJSSkgY29uZmlnL2hhbDogQWRkaW5nIGlucHV0 IGRldmljZSBVU0ItUFMyIE9wdGljYWwgTW91c2UKKElJKSBMb2FkTW9kdWxlOiAibW91c2Ui CihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvaW5wdXQvbW91c2Vf ZHJ2LnNvCihJSSkgTW9kdWxlIG1vdXNlOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCglj b21waWxlZCBmb3IgMS43LjcsIG1vZHVsZSB2ZXJzaW9uID0gMS42LjAKCU1vZHVsZSBjbGFz czogWC5PcmcgWElucHV0IERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBYSW5wdXQgZHJpdmVy LCB2ZXJzaW9uIDcuMAooKiopIFVTQi1QUzIgT3B0aWNhbCBNb3VzZTogRGV2aWNlOiAiL2Rl di9zeXNtb3VzZSIKKD09KSBVU0ItUFMyIE9wdGljYWwgTW91c2U6IFByb3RvY29sOiAiQXV0 byIKKCoqKSBVU0ItUFMyIE9wdGljYWwgTW91c2U6IGFsd2F5cyByZXBvcnRzIGNvcmUgZXZl bnRzCigqKikgT3B0aW9uICJEZXZpY2UiICIvZGV2L3N5c21vdXNlIgooPT0pIFVTQi1QUzIg T3B0aWNhbCBNb3VzZTogRW11bGF0ZTNCdXR0b25zLCBFbXVsYXRlM1RpbWVvdXQ6IDUwCigq KikgVVNCLVBTMiBPcHRpY2FsIE1vdXNlOiBaQXhpc01hcHBpbmc6IGJ1dHRvbnMgNCBhbmQg NQooKiopIFVTQi1QUzIgT3B0aWNhbCBNb3VzZTogQnV0dG9uczogOQooKiopIFVTQi1QUzIg T3B0aWNhbCBNb3VzZTogU2Vuc2l0aXZpdHk6IDEKKElJKSBYSU5QVVQ6IEFkZGluZyBleHRl bmRlZCBpbnB1dCBkZXZpY2UgIlVTQi1QUzIgT3B0aWNhbCBNb3VzZSIgKHR5cGU6IE1PVVNF KQooKiopIFVTQi1QUzIgT3B0aWNhbCBNb3VzZTogKGFjY2VsKSBrZWVwaW5nIGFjY2VsZXJh dGlvbiBzY2hlbWUgMQooKiopIFVTQi1QUzIgT3B0aWNhbCBNb3VzZTogKGFjY2VsKSBhY2Nl bGVyYXRpb24gcHJvZmlsZSAwCihJSSkgVVNCLVBTMiBPcHRpY2FsIE1vdXNlOiBTZXR1cEF1 dG86IGh3LmlmdHlwZSBpcyA0LCBody5tb2RlbCBpcyAwCihJSSkgVVNCLVBTMiBPcHRpY2Fs IE1vdXNlOiBTZXR1cEF1dG86IHByb3RvY29sIGlzIFN5c01vdXNlCihJSSkgY29uZmlnL2hh bDogQWRkaW5nIGlucHV0IGRldmljZSBVU0IgTXVsdGltZWRpYSBLZXlib2FyZAooSUkpIExv YWRNb2R1bGU6ICJrYmQiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvaW5wdXQva2JkX2Rydi5zbwooSUkpIE1vZHVsZSBrYmQ6IHZlbmRvcj0iWC5PcmcgRm91 bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjcuNywgbW9kdWxlIHZlcnNpb24gPSAxLjUuMAoJ TW9kdWxlIGNsYXNzOiBYLk9yZyBYSW5wdXQgRHJpdmVyCglBQkkgY2xhc3M6IFguT3JnIFhJ bnB1dCBkcml2ZXIsIHZlcnNpb24gNy4wCigqKikgVVNCIE11bHRpbWVkaWEgS2V5Ym9hcmQ6 IGFsd2F5cyByZXBvcnRzIGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJQcm90b2NvbCIgInN0 YW5kYXJkIgooKiopIFVTQiBNdWx0aW1lZGlhIEtleWJvYXJkOiBQcm90b2NvbDogc3RhbmRh cmQKKCoqKSBPcHRpb24gIlhrYlJ1bGVzIiAiYmFzZSIKKCoqKSBVU0IgTXVsdGltZWRpYSBL ZXlib2FyZDogWGtiUnVsZXM6ICJiYXNlIgooKiopIE9wdGlvbiAiWGtiTW9kZWwiICJwYzEw NSIKKCoqKSBVU0IgTXVsdGltZWRpYSBLZXlib2FyZDogWGtiTW9kZWw6ICJwYzEwNSIKKCoq KSBPcHRpb24gIlhrYkxheW91dCIgInVzIgooKiopIFVTQiBNdWx0aW1lZGlhIEtleWJvYXJk OiBYa2JMYXlvdXQ6ICJ1cyIKKCoqKSBPcHRpb24gIkN1c3RvbUtleWNvZGVzIiAib2ZmIgoo KiopIFVTQiBNdWx0aW1lZGlhIEtleWJvYXJkOiBDdXN0b21LZXljb2RlcyBkaXNhYmxlZAoo SUkpIFhJTlBVVDogQWRkaW5nIGV4dGVuZGVkIGlucHV0IGRldmljZSAiVVNCIE11bHRpbWVk aWEgS2V5Ym9hcmQiICh0eXBlOiBLRVlCT0FSRCkKKElJKSBjb25maWcvaGFsOiBBZGRpbmcg aW5wdXQgZGV2aWNlIEFUIEtleWJvYXJkCigqKikgQVQgS2V5Ym9hcmQ6IGFsd2F5cyByZXBv cnRzIGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJQcm90b2NvbCIgInN0YW5kYXJkIgooKiop IEFUIEtleWJvYXJkOiBQcm90b2NvbDogc3RhbmRhcmQKKCoqKSBPcHRpb24gIlhrYlJ1bGVz IiAiYmFzZSIKKCoqKSBBVCBLZXlib2FyZDogWGtiUnVsZXM6ICJiYXNlIgooKiopIE9wdGlv biAiWGtiTW9kZWwiICJwYzEwNSIKKCoqKSBBVCBLZXlib2FyZDogWGtiTW9kZWw6ICJwYzEw NSIKKCoqKSBPcHRpb24gIlhrYkxheW91dCIgInVzIgooKiopIEFUIEtleWJvYXJkOiBYa2JM YXlvdXQ6ICJ1cyIKKCoqKSBPcHRpb24gIkN1c3RvbUtleWNvZGVzIiAib2ZmIgooKiopIEFU IEtleWJvYXJkOiBDdXN0b21LZXljb2RlcyBkaXNhYmxlZAooSUkpIFhJTlBVVDogQWRkaW5n IGV4dGVuZGVkIGlucHV0IGRldmljZSAiQVQgS2V5Ym9hcmQiICh0eXBlOiBLRVlCT0FSRCkK RGFjIGRldGVjdGlvbiBzdWNjZXNzCihJSSkgUkFERU9OKDApOiBPdXRwdXQ6IFZHQS0wLCBE ZXRlY3RlZCBNb25pdG9yIFR5cGU6IDAKKElJKSBSQURFT04oMCk6IEVESUQgdmVuZG9yICJO RUMiLCBwcm9kIGlkIDI2MjU0CihJSSkgUkFERU9OKDApOiBVc2luZyBFRElEIHJhbmdlIGlu Zm8gZm9yIGhvcml6b250YWwgc3luYwooSUkpIFJBREVPTigwKTogVXNpbmcgRURJRCByYW5n ZSBpbmZvIGZvciB2ZXJ0aWNhbCByZWZyZXNoCihJSSkgUkFERU9OKDApOiBQcmludGluZyBE REMgZ2F0aGVyZWQgTW9kZWxpbmVzOgooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjEyODB4 MTAyNCJ4MC4wICAxMDguMDAgIDEyODAgMTMyOCAxNDQwIDE2ODggIDEwMjQgMTAyNSAxMDI4 IDEwNjYgK2hzeW5jICt2c3luYyAoNjQuMCBrSHopCihJSSkgUkFERU9OKDApOiBNb2RlbGlu ZSAiODAweDYwMCJ4MC4wICAgNDAuMDAgIDgwMCA4NDAgOTY4IDEwNTYgIDYwMCA2MDEgNjA1 IDYyOCAraHN5bmMgK3ZzeW5jICgzNy45IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5l ICI4MDB4NjAwIngwLjAgICAzNi4wMCAgODAwIDgyNCA4OTYgMTAyNCAgNjAwIDYwMSA2MDMg NjI1ICtoc3luYyArdnN5bmMgKDM1LjIga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUg IjY0MHg0ODAieDAuMCAgIDMxLjUwICA2NDAgNjU2IDcyMCA4NDAgIDQ4MCA0ODEgNDg0IDUw MCAtaHN5bmMgLXZzeW5jICgzNy41IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICI2 NDB4NDgwIngwLjAgICAzMS41MCAgNjQwIDY2NCA3MDQgODMyICA0ODAgNDg5IDQ5MiA1MjAg LWhzeW5jIC12c3luYyAoMzcuOSBrSHopCihJSSkgUkFERU9OKDApOiBNb2RlbGluZSAiNjQw eDQ4MCJ4MC4wICAgMzAuMjQgIDY0MCA3MDQgNzY4IDg2NCAgNDgwIDQ4MyA0ODYgNTI1IC1o c3luYyAtdnN5bmMgKDM1LjAga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjY0MHg0 ODAieDAuMCAgIDI1LjE4ICA2NDAgNjU2IDc1MiA4MDAgIDQ4MCA0OTAgNDkyIDUyNSAtaHN5 bmMgLXZzeW5jICgzMS41IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICI3MjB4NDAw IngwLjAgICAyOC4zMiAgNzIwIDczOCA4NDYgOTAwICA0MDAgNDEyIDQxNCA0NDkgLWhzeW5j ICt2c3luYyAoMzEuNSBrSHopCihJSSkgUkFERU9OKDApOiBNb2RlbGluZSAiMTI4MHgxMDI0 IngwLjAgIDEzNS4wMCAgMTI4MCAxMjk2IDE0NDAgMTY4OCAgMTAyNCAxMDI1IDEwMjggMTA2 NiAraHN5bmMgK3ZzeW5jICg4MC4wIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICIx MDI0eDc2OCJ4MC4wICAgNzguNzUgIDEwMjQgMTA0MCAxMTM2IDEzMTIgIDc2OCA3NjkgNzcy IDgwMCAraHN5bmMgK3ZzeW5jICg2MC4wIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5l ICIxMDI0eDc2OCJ4MC4wICAgNzUuMDAgIDEwMjQgMTA0OCAxMTg0IDEzMjggIDc2OCA3NzEg Nzc3IDgwNiAtaHN5bmMgLXZzeW5jICg1Ni41IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVs aW5lICIxMDI0eDc2OCJ4MC4wICAgNjUuMDAgIDEwMjQgMTA0OCAxMTg0IDEzNDQgIDc2OCA3 NzEgNzc3IDgwNiAtaHN5bmMgLXZzeW5jICg0OC40IGtIeikKKElJKSBSQURFT04oMCk6IE1v ZGVsaW5lICI4MzJ4NjI0IngwLjAgICA1Ny4yOCAgODMyIDg2NCA5MjggMTE1MiAgNjI0IDYy NSA2MjggNjY3IC1oc3luYyAtdnN5bmMgKDQ5Ljcga0h6KQooSUkpIFJBREVPTigwKTogTW9k ZWxpbmUgIjgwMHg2MDAieDAuMCAgIDQ5LjUwICA4MDAgODE2IDg5NiAxMDU2ICA2MDAgNjAx IDYwNCA2MjUgK2hzeW5jICt2c3luYyAoNDYuOSBrSHopCihJSSkgUkFERU9OKDApOiBNb2Rl bGluZSAiODAweDYwMCJ4MC4wICAgNTAuMDAgIDgwMCA4NTYgOTc2IDEwNDAgIDYwMCA2Mzcg NjQzIDY2NiAraHN5bmMgK3ZzeW5jICg0OC4xIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVs aW5lICIxMTUyeDg2NCJ4MC4wICAxMDguMDAgIDExNTIgMTIxNiAxMzQ0IDE2MDAgIDg2NCA4 NjUgODY4IDkwMCAraHN5bmMgK3ZzeW5jICg2Ny41IGtIeikKKElJKSBSQURFT04oMCk6IE1v ZGVsaW5lICIxMjgweDk2MCJ4MC4wICAxMDguMDAgIDEyODAgMTM3NiAxNDg4IDE4MDAgIDk2 MCA5NjEgOTY0IDEwMDAgK2hzeW5jICt2c3luYyAoNjAuMCBrSHopCihJSSkgUkFERU9OKDAp OiBPdXRwdXQ6IEhETUktMCwgRGV0ZWN0ZWQgTW9uaXRvciBUeXBlOiAzCihJSSkgUkFERU9O KDApOiBFRElEIGRhdGEgZnJvbSB0aGUgZGlzcGxheSBvbiBvdXRwdXQ6IEhETUktMCAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tCihJSSkgUkFERU9OKDApOiBNYW51ZmFjdHVyZXI6IE5FQyAg TW9kZWw6IDY2OGUgIFNlcmlhbCM6IDE2ODQzMDA5CihJSSkgUkFERU9OKDApOiBZZWFyOiAy MDA3ICBXZWVrOiAyNAooSUkpIFJBREVPTigwKTogRURJRCBWZXJzaW9uOiAxLjMKKElJKSBS QURFT04oMCk6IERpZ2l0YWwgRGlzcGxheSBJbnB1dAooSUkpIFJBREVPTigwKTogTWF4IElt YWdlIFNpemUgW2NtXTogaG9yaXouOiAzOCAgdmVydC46IDMwCihJSSkgUkFERU9OKDApOiBH YW1tYTogMi4yMAooSUkpIFJBREVPTigwKTogRFBNUyBjYXBhYmlsaXRpZXM6IFN0YW5kQnkg U3VzcGVuZCBPZmYKKElJKSBSQURFT04oMCk6IFN1cHBvcnRlZCBjb2xvciBlbmNvZGluZ3M6 IFJHQiA0OjQ6NCBZQ3JDYiA0OjQ6NCAKKElJKSBSQURFT04oMCk6IEZpcnN0IGRldGFpbGVk IHRpbWluZyBpcyBwcmVmZXJyZWQgbW9kZQooSUkpIFJBREVPTigwKTogcmVkWDogMC42NDEg cmVkWTogMC4zNTMgICBncmVlblg6IDAuMjg5IGdyZWVuWTogMC42MjYKKElJKSBSQURFT04o MCk6IGJsdWVYOiAwLjE0MiBibHVlWTogMC4wNzggICB3aGl0ZVg6IDAuMzEzIHdoaXRlWTog MC4zMjkKKElJKSBSQURFT04oMCk6IFN1cHBvcnRlZCBlc3RhYmxpc2hlZCB0aW1pbmdzOgoo SUkpIFJBREVPTigwKTogNzIweDQwMEA3MEh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDYw SHoKKElJKSBSQURFT04oMCk6IDY0MHg0ODBANjdIegooSUkpIFJBREVPTigwKTogNjQweDQ4 MEA3Mkh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDc1SHoKKElJKSBSQURFT04oMCk6IDgw MHg2MDBANTZIegooSUkpIFJBREVPTigwKTogODAweDYwMEA2MEh6CihJSSkgUkFERU9OKDAp OiA4MDB4NjAwQDcySHoKKElJKSBSQURFT04oMCk6IDgwMHg2MDBANzVIegooSUkpIFJBREVP TigwKTogODMyeDYyNEA3NUh6CihJSSkgUkFERU9OKDApOiAxMDI0eDc2OEA2MEh6CihJSSkg UkFERU9OKDApOiAxMDI0eDc2OEA3MEh6CihJSSkgUkFERU9OKDApOiAxMDI0eDc2OEA3NUh6 CihJSSkgUkFERU9OKDApOiAxMjgweDEwMjRANzVIegooSUkpIFJBREVPTigwKTogMTE1Mng4 NjRANzVIegooSUkpIFJBREVPTigwKTogTWFudWZhY3R1cmVyJ3MgbWFzazogMAooSUkpIFJB REVPTigwKTogU3VwcG9ydGVkIHN0YW5kYXJkIHRpbWluZ3M6CihJSSkgUkFERU9OKDApOiAj MDogaHNpemU6IDExNTIgIHZzaXplIDg2NCAgcmVmcmVzaDogNzUgIHZpZDogMjAzMzcKKElJ KSBSQURFT04oMCk6ICMxOiBoc2l6ZTogMTI4MCAgdnNpemUgOTYwICByZWZyZXNoOiA2MCAg dmlkOiAxNjUxMwooSUkpIFJBREVPTigwKTogIzI6IGhzaXplOiAxMjgwICB2c2l6ZSAxMDI0 ICByZWZyZXNoOiA2MCAgdmlkOiAzMjg5NwooSUkpIFJBREVPTigwKTogU3VwcG9ydGVkIGRl dGFpbGVkIHRpbWluZzoKKElJKSBSQURFT04oMCk6IGNsb2NrOiAxMDguMCBNSHogICBJbWFn ZSBTaXplOiAgMzc2IHggMzAxIG1tCihJSSkgUkFERU9OKDApOiBoX2FjdGl2ZTogMTI4MCAg aF9zeW5jOiAxMzI4ICBoX3N5bmNfZW5kIDE0NDAgaF9ibGFua19lbmQgMTY4OCBoX2JvcmRl cjogMAooSUkpIFJBREVPTigwKTogdl9hY3RpdmU6IDEwMjQgIHZfc3luYzogMTAyNSAgdl9z eW5jX2VuZCAxMDI4IHZfYmxhbmtpbmc6IDEwNjYgdl9ib3JkZXI6IDAKKElJKSBSQURFT04o MCk6IFJhbmdlczogViBtaW46IDU2IFYgbWF4OiA3NSBIeiwgSCBtaW46IDMxIEggbWF4OiA4 MSBrSHosIFBpeENsb2NrIG1heCAxNDAgTUh6CihJSSkgUkFERU9OKDApOiBNb25pdG9yIG5h bWU6IExDRDE5NzBOWHAKKElJKSBSQURFT04oMCk6IFNlcmlhbCBObzogNzZEMDUxMThZQgoo SUkpIFJBREVPTigwKTogRURJRCAoaW4gaGV4KToKKElJKSBSQURFT04oMCk6IAkwMGZmZmZm ZmZmZmZmZjAwMzhhMzhlNjYwMTAxMDEwMQooSUkpIFJBREVPTigwKTogCTE4MTEwMTAzODAy NjFlNzhlYTExNDVhNDVhNGFhMDI0CihJSSkgUkFERU9OKDApOiAJMTQ1MDU0YmZlZjgwNzE0 ZjgxNDA4MTgwMDEwMTAxMDEKKElJKSBSQURFT04oMCk6IAkwMTAxMDEwMTAxMDEzMDJhMDA5 ODUxMDAyYTQwMzA3MAooSUkpIFJBREVPTigwKTogCTEzMDA3ODJkMTEwMDAwMWUwMDAwMDBm ZDAwMzg0YjFmCihJSSkgUkFERU9OKDApOiAJNTEwZTAwMGEyMDIwMjAyMDIwMjAwMDAwMDBm YzAwNGMKKElJKSBSQURFT04oMCk6IAk0MzQ0MzEzOTM3MzA0ZTU4NzAwYTIwMjAwMDAwMDBm ZgooSUkpIFJBREVPTigwKTogCTAwMzczNjQ0MzAzNTMxMzEzODU5NDIwYTIwMjAwMDdjCihJ SSkgUkFERU9OKDApOiBFRElEIHZlbmRvciAiTkVDIiwgcHJvZCBpZCAyNjI1NApGcmVlVHlw ZTogY291bGRuJ3QgZmluZCBlbmNvZGluZyAnc3VuZXUtZ3JlZWsnIGZvciAnL3Vzci9sb2Nh bC9saWIvWDExL2ZvbnRzL1dpblhQL2NvdXIudHRmJwooSUkpIDNyZCBCdXR0b24gZGV0ZWN0 ZWQ6IGRpc2FibGluZyBlbXVsYXRlM0J1dHRvbgo= --------------010809080106000808030407-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:20:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73DF91065673; Tue, 20 Dec 2011 14:20:12 +0000 (UTC) (envelope-from asmrookie@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 233FE8FC0A; Tue, 20 Dec 2011 14:20:10 +0000 (UTC) Received: by faaf16 with SMTP id f16so5151323faa.13 for ; Tue, 20 Dec 2011 06:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uAIsjEAGUTKvHhoIdNsd7Mo43gxVZUnjeRFLz1fuqZE=; b=kgYrB6Ydn8uHzaWcBJxMzUkT2p4ZiEmQ5UCXxGowGENK/Qy4mksld08TQoTpGT9UTc IR1rKyOwCs1JtBaifkO0IbW3IYEbGvpiKoRocOqkc3TgIFELxoZpT/x6PvIvsvwXlnNc W6mqbqIggpM9QQLynvICqVobsoPHOMDOUy5vQ= MIME-Version: 1.0 Received: by 10.181.12.43 with SMTP id en11mr5181885wid.6.1324390809951; Tue, 20 Dec 2011 06:20:09 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.18.130 with HTTP; Tue, 20 Dec 2011 06:20:09 -0800 (PST) In-Reply-To: <201112200852.23300.jhb@freebsd.org> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> <201112200852.23300.jhb@freebsd.org> Date: Tue, 20 Dec 2011 15:20:09 +0100 X-Google-Sender-Auth: R-HaLQYTlHfsF1AxRZuc7maCJtY Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "O. Hartmann" , freebsd-current@freebsd.org, Robert Watson Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:20:12 -0000 2011/12/20 John Baldwin : > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wro= te: >> > On Sun, 18 Dec 2011 01:09:00 +0100 >> > "O. Hartmann" wrote: >> > >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> >> panic: sleeping thread >> >> cpuid =3D 0 >> >> >> >> PID 16 is always USB on my box. >> > >> > You really need to give us a backtrace when you quote panics. It is >> > impossible to make any sense of the above panic message without more >> > context. >> >> In the case of this panic, the stack of the thread which panics is >> useless; it's someone trying to propagate priority that discovered it. >> =C2=A0A backtrace on tid 100033 would be useful. >> >> With WITNESS enabled, it's possible to have this panic display the >> stack of the incorrectly sleeping thread at the time it acquired the >> lock, as well, but this code isn't in CURRENT or any release. =C2=A0I ha= ve >> a patch at $WORK I can dig up on Monday. > > Huh? =C2=A0The stock kernel dumps a stack trace of the offending thread i= f you have > DDB enabled: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If the thread i= s asleep, then we are probably about > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * to deadlock. = =C2=A0To make debugging this easier, just > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * panic and tell = the user which thread misbehaved so > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * they can hopefu= lly get a stack trace from the truly > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * misbehaving thr= ead. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (TD_IS_SLEEPING= (td)) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0printf( > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Sleeping thread (= tid %d, pid %d) owns a non-sleepable lock\n", > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0td->td_tid, td->td_proc->p_pid); > #ifdef DDB > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0db_trace_thread(td, -1); > #endif > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0panic("sleeping thread"); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > It may be that we can make use of the STACK API here instead to output th= is > trace even when DDB isn't enabled. =C2=A0The patch below tries to do that > (untested). =C2=A0It does some odd thigns though since it is effectively = running > from a panic context already, so it uses a statically allocated 'struct s= tack' > rather than using stack_create() and uses stack_print_ddb() since it is > holding spin locks and can't possibly grab an sx lock: > > Index: subr_turnstile.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 > --- subr_turnstile.c =C2=A0 =C2=A0(revision 228534) > +++ subr_turnstile.c =C2=A0 =C2=A0(working copy) > @@ -72,6 +72,7 @@ __FBSDID("$FreeBSD$"); > =C2=A0#include > =C2=A0#include > =C2=A0#include > +#include > =C2=A0#include > =C2=A0#include > > @@ -175,6 +176,7 @@ static void turnstile_fini(void *mem, int size); > =C2=A0static void > =C2=A0propagate_priority(struct thread *td) > =C2=A0{ > + =C2=A0 =C2=A0 =C2=A0 static struct stack st; > =C2=A0 =C2=A0 =C2=A0 =C2=A0struct turnstile *ts; > =C2=A0 =C2=A0 =C2=A0 =C2=A0int pri; > > @@ -217,8 +219,10 @@ propagate_priority(struct thread *td) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0printf( > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Sleeping thread (= tid %d, pid %d) owns a non-sleepable lock\n", > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0td->td_tid, td->td_proc->p_pid); > -#ifdef DDB > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 db_trace_thread(td, -1); > +#ifdef STACK > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 stack_zero(&st); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 stack_save_td(&st, td); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 stack_print_ddb(&st); > =C2=A0#endif > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0panic("sleeping thread"); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > -- I'm not sure it is a wise idea to trimm the DDB part, because it is much more common than STACK enabled. Note that stack(9) is working if you define DDB too, so I'd say to do that for both. Also, I don't think you need the stack_zero() prior to set it. As we are here, however, I have a question for Robert here: do you think we should support the _ddb() variant of options even in the case DDB is not enabled in the kernel? Probabilly the way it is nowadays is easier to have stack(9) both defined for DDB and STACK, but in general I wouldn't advertise that. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:22:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0931065672; Tue, 20 Dec 2011 14:22:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 012CF8FC15; Tue, 20 Dec 2011 14:22:48 +0000 (UTC) Received: by pbcc3 with SMTP id c3so5033568pbc.13 for ; Tue, 20 Dec 2011 06:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SD8indK1BDTgbKxQw7lYb8FCo6hwQEP/ejFzXdi/cK4=; b=CLm/Ff6EBS4O4NoxeUD9hTGlaULF9z0NpucXtZewuOlsblSgqnhm+xpMF+TOVAkn1u j/FzEBYCBoSMdHDTY4pUPgBmA+otwsge8A9oZsSU+d7zcamOZt/ro1d0Wdr2CGnwVBrx gZxcv+6qBSVS6Cf7h/9/HFEz8346dct3Y0eyY= MIME-Version: 1.0 Received: by 10.68.73.101 with SMTP id k5mr3648946pbv.122.1324390968534; Tue, 20 Dec 2011 06:22:48 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.136 with HTTP; Tue, 20 Dec 2011 06:22:48 -0800 (PST) In-Reply-To: <201112200852.23300.jhb@freebsd.org> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> <201112200852.23300.jhb@freebsd.org> Date: Tue, 20 Dec 2011 06:22:48 -0800 X-Google-Sender-Auth: mnkUkb6MWSseGNviJa12zeNpdJo Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Watson , freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:22:49 -0000 On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote: > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wro= te: >> > On Sun, 18 Dec 2011 01:09:00 +0100 >> > "O. Hartmann" wrote: >> > >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> >> panic: sleeping thread >> >> cpuid =3D 0 >> >> >> >> PID 16 is always USB on my box. >> > >> > You really need to give us a backtrace when you quote panics. It is >> > impossible to make any sense of the above panic message without more >> > context. >> >> In the case of this panic, the stack of the thread which panics is >> useless; it's someone trying to propagate priority that discovered it. >> =A0A backtrace on tid 100033 would be useful. >> >> With WITNESS enabled, it's possible to have this panic display the >> stack of the incorrectly sleeping thread at the time it acquired the >> lock, as well, but this code isn't in CURRENT or any release. =A0I have >> a patch at $WORK I can dig up on Monday. > > Huh? =A0The stock kernel dumps a stack trace of the offending thread if y= ou have > DDB enabled: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If the thread is asleep, then we are pr= obably about > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to deadlock. =A0To make debugging this = easier, just > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * panic and tell the user which thread mi= sbehaved so > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * they can hopefully get a stack trace fr= om the truly > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * misbehaving thread. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (TD_IS_SLEEPING(td)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Sleeping thread (tid %d, pid %d) owns a n= on-sleepable lock\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0td->td_tid, td->td= _proc->p_pid); > #ifdef DDB > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0db_trace_thread(td, -1); > #endif > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0panic("sleeping thread"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} Hmm, maybe this wasn't in 7, or maybe I'm just remembering that we added code to print *which* lock it holds (using WITNESS data). I do recall that this panic alone was often not sufficient to debug the problem. Thanks, matthew > It may be that we can make use of the STACK API here instead to output th= is > trace even when DDB isn't enabled. =A0The patch below tries to do that > (untested). =A0It does some odd thigns though since it is effectively run= ning > from a panic context already, so it uses a statically allocated 'struct s= tack' > rather than using stack_create() and uses stack_print_ddb() since it is > holding spin locks and can't possibly grab an sx lock: > > Index: subr_turnstile.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 > --- subr_turnstile.c =A0 =A0(revision 228534) > +++ subr_turnstile.c =A0 =A0(working copy) > @@ -72,6 +72,7 @@ __FBSDID("$FreeBSD$"); > =A0#include > =A0#include > =A0#include > +#include > =A0#include > =A0#include > > @@ -175,6 +176,7 @@ static void turnstile_fini(void *mem, int size); > =A0static void > =A0propagate_priority(struct thread *td) > =A0{ > + =A0 =A0 =A0 static struct stack st; > =A0 =A0 =A0 =A0struct turnstile *ts; > =A0 =A0 =A0 =A0int pri; > > @@ -217,8 +219,10 @@ propagate_priority(struct thread *td) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Sleeping thread (tid %d, pid %d) owns a n= on-sleepable lock\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0td->td_tid, td->td= _proc->p_pid); > -#ifdef DDB > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 db_trace_thread(td, -1); > +#ifdef STACK > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stack_zero(&st); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stack_save_td(&st, td); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stack_print_ddb(&st); > =A0#endif > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0panic("sleeping thread"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:29:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 792B01065673 for ; Tue, 20 Dec 2011 14:29:45 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42FEE8FC14 for ; Tue, 20 Dec 2011 14:29:44 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3743176obb.13 for ; Tue, 20 Dec 2011 06:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OPrhOEq4u+rfNoEpYzGIRPebHG3whvVaD9ZShLPtSok=; b=QbOCBOsYvSN2HxOMt13H1y/WhqyjV2e/Bcmd7TiyKg0+B2Ygd6HL9ilnrYA/mDr7/c a/OA93xccTJYHIMjT1farEMBfFtApK8oqvpAjvL3opM8jw78Ejd79y//Ej8sJIoiF6Rw GcwG5tYDcwFcSECut0pP9JvBC9ytcqNDgi1jU= MIME-Version: 1.0 Received: by 10.182.111.7 with SMTP id ie7mr1926027obb.4.1324391384555; Tue, 20 Dec 2011 06:29:44 -0800 (PST) Received: by 10.182.150.70 with HTTP; Tue, 20 Dec 2011 06:29:44 -0800 (PST) In-Reply-To: <4EF08F84.4060500@lissyara.su> References: <4EF08F84.4060500@lissyara.su> Date: Tue, 20 Dec 2011 16:29:44 +0200 Message-ID: From: Alexander Yerenkow To: Alex Keda Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current FreeBSD Subject: Re: regression: Xorg get 100% cpu and freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:29:45 -0000 20 =C4=C5=CB=C1=C2=D2=D1 2011 =C7. 15:37 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC= =D8 Alex Keda =CE=C1=D0=C9=D3=C1=CC: > I use CURRENT from 2011-11-18 - all OK > After update to today - I have problem - on start, Xorg get 100% CPU and > freeze (monitor go to turn off) > I recompile Xorg, all modules - no happy. > I try update x11-drivers/xf86-video-ati to 6.14.3 - no happy > > If I delete /boot/kernel/drm.ko - all work OK, but very slow... > BTW, mine test images built from sources with KMS do the same thing - start xorg, and it just totally hangs pc. I think it's about a month I have such situation. > > =3D=3D=3D=3D=3D > FreeBSD lissyara.moskb.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228726= : > Tue Dec 20 08:24:56 MSK 2011 root@lissyara.moskb.local:/usr/obj/usr/s= rc/sys/GENERIC > amd64 > =3D=3D=3D=3D=3D > pciconf, Xorg.log with and without drm.ko - in attached files > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:52:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A95106564A; Tue, 20 Dec 2011 14:52:50 +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 851828FC14; Tue, 20 Dec 2011 14:52:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 3C0EA46B2A; Tue, 20 Dec 2011 09:52:50 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7D03FB968; Tue, 20 Dec 2011 09:52:49 -0500 (EST) From: John Baldwin To: mdf@freebsd.org Date: Tue, 20 Dec 2011 09:32:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EED2F1C.2060409@zedat.fu-berlin.de> <201112200852.23300.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112200932.21223.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:52:49 -0500 (EST) Cc: Robert Watson , freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:52:50 -0000 On Tuesday, December 20, 2011 9:22:48 am mdf@freebsd.org wrote: > On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote: > > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: > >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote: > >> > On Sun, 18 Dec 2011 01:09:00 +0100 > >> > "O. Hartmann" wrote: > >> > > >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock > >> >> panic: sleeping thread > >> >> cpuid = 0 > >> >> > >> >> PID 16 is always USB on my box. > >> > > >> > You really need to give us a backtrace when you quote panics. It is > >> > impossible to make any sense of the above panic message without more > >> > context. > >> > >> In the case of this panic, the stack of the thread which panics is > >> useless; it's someone trying to propagate priority that discovered it. > >> A backtrace on tid 100033 would be useful. > >> > >> With WITNESS enabled, it's possible to have this panic display the > >> stack of the incorrectly sleeping thread at the time it acquired the > >> lock, as well, but this code isn't in CURRENT or any release. I have > >> a patch at $WORK I can dig up on Monday. > > > > Huh? The stock kernel dumps a stack trace of the offending thread if you have > > DDB enabled: > > > > /* > > * If the thread is asleep, then we are probably about > > * to deadlock. To make debugging this easier, just > > * panic and tell the user which thread misbehaved so > > * they can hopefully get a stack trace from the truly > > * misbehaving thread. > > */ > > if (TD_IS_SLEEPING(td)) { > > printf( > > "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", > > td->td_tid, td->td_proc->p_pid); > > #ifdef DDB > > db_trace_thread(td, -1); > > #endif > > panic("sleeping thread"); > > } > > Hmm, maybe this wasn't in 7, or maybe I'm just remembering that we > added code to print *which* lock it holds (using WITNESS data). I do > recall that this panic alone was often not sufficient to debug the > problem. I think the db_trace_thread() has been around for a while (since 5 or 6), but it is true that we don't tell you which lock is held even with this. That might be a useful thing to output before the panic. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:52:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 222461065672; Tue, 20 Dec 2011 14:52:51 +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 DABA58FC15; Tue, 20 Dec 2011 14:52:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8E45C46B0A; Tue, 20 Dec 2011 09:52:50 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 15AF8B93E; Tue, 20 Dec 2011 09:52:50 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Tue, 20 Dec 2011 09:35:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EED2F1C.2060409@zedat.fu-berlin.de> <201112200852.23300.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112200935.30772.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:52:50 -0500 (EST) Cc: mdf@freebsd.org, "O. Hartmann" , freebsd-current@freebsd.org, Robert Watson Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:52:51 -0000 On Tuesday, December 20, 2011 9:20:09 am Attilio Rao wrote: > 2011/12/20 John Baldwin : > > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: > >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote: > >> > On Sun, 18 Dec 2011 01:09:00 +0100 > >> > "O. Hartmann" wrote: > >> > > >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock > >> >> panic: sleeping thread > >> >> cpuid = 0 > >> >> > >> >> PID 16 is always USB on my box. > >> > > >> > You really need to give us a backtrace when you quote panics. It is > >> > impossible to make any sense of the above panic message without more > >> > context. > >> > >> In the case of this panic, the stack of the thread which panics is > >> useless; it's someone trying to propagate priority that discovered it. > >> A backtrace on tid 100033 would be useful. > >> > >> With WITNESS enabled, it's possible to have this panic display the > >> stack of the incorrectly sleeping thread at the time it acquired the > >> lock, as well, but this code isn't in CURRENT or any release. I have > >> a patch at $WORK I can dig up on Monday. > > > > Huh? The stock kernel dumps a stack trace of the offending thread if you have > > DDB enabled: > > > > /* > > * If the thread is asleep, then we are probably about > > * to deadlock. To make debugging this easier, just > > * panic and tell the user which thread misbehaved so > > * they can hopefully get a stack trace from the truly > > * misbehaving thread. > > */ > > if (TD_IS_SLEEPING(td)) { > > printf( > > "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", > > td->td_tid, td->td_proc->p_pid); > > #ifdef DDB > > db_trace_thread(td, -1); > > #endif > > panic("sleeping thread"); > > } > > > > It may be that we can make use of the STACK API here instead to output this > > trace even when DDB isn't enabled. The patch below tries to do that > > (untested). It does some odd thigns though since it is effectively running > > from a panic context already, so it uses a statically allocated 'struct stack' > > rather than using stack_create() and uses stack_print_ddb() since it is > > holding spin locks and can't possibly grab an sx lock: > > > > Index: subr_turnstile.c > > =================================================================== > > --- subr_turnstile.c (revision 228534) > > +++ subr_turnstile.c (working copy) > > @@ -72,6 +72,7 @@ __FBSDID("$FreeBSD$"); > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -175,6 +176,7 @@ static void turnstile_fini(void *mem, int size); > > static void > > propagate_priority(struct thread *td) > > { > > + static struct stack st; > > struct turnstile *ts; > > int pri; > > > > @@ -217,8 +219,10 @@ propagate_priority(struct thread *td) > > printf( > > "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", > > td->td_tid, td->td_proc->p_pid); > > -#ifdef DDB > > - db_trace_thread(td, -1); > > +#ifdef STACK > > + stack_zero(&st); > > + stack_save_td(&st, td); > > + stack_print_ddb(&st); > > #endif > > panic("sleeping thread"); > > } > > > > -- > > I'm not sure it is a wise idea to trimm the DDB part, because it is > much more common than STACK enabled. Note that stack(9) is working if > you define DDB too, so I'd say to do that for both. > Also, I don't think you need the stack_zero() prior to set it. Err, STACK is enabled in GENERIC in release kernels but DDB is not, so I think STACK is the more common one. As far as stack_zero(), I was just being paranoid. > As we are here, however, I have a question for Robert here: do you > think we should support the _ddb() variant of options even in the case > DDB is not enabled in the kernel? > Probabilly the way it is nowadays is easier to have stack(9) both > defined for DDB and STACK, but in general I wouldn't advertise that. The _ddb variants are always enabled by my reading. They just use different entry points into the linker that don't use locking. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:52:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 115FE106567B; Tue, 20 Dec 2011 14:52:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D9C868FC18; Tue, 20 Dec 2011 14:52:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8FF5F46B37; Tue, 20 Dec 2011 09:52:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC689B998; Tue, 20 Dec 2011 09:52:50 -0500 (EST) From: John Baldwin To: Pawel Jakub Dawidek Date: Tue, 20 Dec 2011 09:52:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <201112121100.23567.jhb@freebsd.org> <20111217232125.GA1685@garage.freebsd.pl> In-Reply-To: <20111217232125.GA1685@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112200952.44690.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:52:51 -0500 (EST) Cc: Kostik Belousov , Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:52:52 -0000 On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote: > On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: > > An update. I've sent Pawel a testing patch to see if my hypothesis is correct > > (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is then I intend > > to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fix. > > Unfortunately it paniced today. Take a look at: > > http://people.freebsd.org/~pjd/misc/tcp_panic.jpg Ok, the one use case I was worried about is happening regularly before your panic, so that is good. Can you use gdb to figure out which call to tcp_output() is actually panic'ing? I wonder if it is this case: /* * Return any desired output. */ if (needoutput || (tp->t_flags & TF_ACKNOW)) { (void) tcp_output(tp); /* XXX: Debug */ KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), ("tcp_input: negative window after ACK")); And if 'needoutput' is true, but TF_ACKNOW is not set, and tcp_output() decides to not do anything. I've updated tcp_negwin_test.patch to not panic if that call to tcp_output() doesn't actually send a packet. Please re-test. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:10:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E09A1065673; Tue, 20 Dec 2011 15:10:34 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id C4BC88FC15; Tue, 20 Dec 2011 15:10:33 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B412525D39FE; Tue, 20 Dec 2011 15:10:32 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E60DEBD7688; Tue, 20 Dec 2011 15:10:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id xm04MeSuT5Tu; Tue, 20 Dec 2011 15:10:31 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1CC81BD768D; Tue, 20 Dec 2011 15:10:30 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4EF05CEC.6080603@orange.fr> Date: Tue, 20 Dec 2011 15:10:30 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <4EF05CEC.6080603@orange.fr> To: Claude Buisson X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org, FreeBSD Current Subject: Re: Is the svn2cvs gateway down ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:10:34 -0000 On 20. Dec 2011, at 10:01 , Claude Buisson wrote: > It seems (from my own csup's and cvswe.cgi) that the src commits are lost, > starting with r228697 Sun Dec 18 22:04:55 2011) > > What is going on (or off) ? Re $subject -- yes. It will be worked on. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:16:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D57DD1065672; Tue, 20 Dec 2011 15:16:42 +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 D5FE28FC17; Tue, 20 Dec 2011 15:16:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA03060; Tue, 20 Dec 2011 17:16:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rd1Qj-000JR2-70; Tue, 20 Dec 2011 17:16:37 +0200 Message-ID: <4EF0A6D4.2020107@FreeBSD.org> Date: Tue, 20 Dec 2011 17:16:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EF088C8.8090906@FreeBSD.org> In-Reply-To: <4EF088C8.8090906@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-usb@FreeBSD.org Subject: Re: ukbd locking update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:16:42 -0000 And the new patch: http://people.freebsd.org/~avg/usb.new.diff -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:17:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50515106564A; Tue, 20 Dec 2011 15:17:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5038FC25; Tue, 20 Dec 2011 15:17:48 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so12619911wgb.31 for ; Tue, 20 Dec 2011 07:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YsG1CUJ/Sa8GJf9frrdySgIN5dCZjnRRyoIEKDoS0vQ=; b=xK6+4ujg/lWvYf5ujXaAJt/yk9OFT4vFj9IY3RIAoR5mH35cDLlELFImKA15O1F4Og zO66qsw5POjM8BcTh/YsHkAQ6mPvU34D/aD+lruPZhTjfJ/FJIws015rdSl0bzkSPH5v 3L+WtLkZkLmHxsZXeWUG3lhQdW2/rD7BvB3jg= MIME-Version: 1.0 Received: by 10.227.207.15 with SMTP id fw15mr2454483wbb.15.1324394267574; Tue, 20 Dec 2011 07:17:47 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.18.130 with HTTP; Tue, 20 Dec 2011 07:17:46 -0800 (PST) In-Reply-To: <201112200935.30772.jhb@freebsd.org> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <201112200852.23300.jhb@freebsd.org> <201112200935.30772.jhb@freebsd.org> Date: Tue, 20 Dec 2011 16:17:46 +0100 X-Google-Sender-Auth: 2_yp9qY4qs3mk2bgydurTF8shng Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "O. Hartmann" , freebsd-current@freebsd.org, Robert Watson Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:17:50 -0000 2011/12/20 John Baldwin : > On Tuesday, December 20, 2011 9:20:09 am Attilio Rao wrote: >> 2011/12/20 John Baldwin : >> > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: >> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev = wrote: >> >> > On Sun, 18 Dec 2011 01:09:00 +0100 >> >> > "O. Hartmann" wrote: >> >> > >> >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> >> >> panic: sleeping thread >> >> >> cpuid =3D 0 >> >> >> >> >> >> PID 16 is always USB on my box. >> >> > >> >> > You really need to give us a backtrace when you quote panics. It is >> >> > impossible to make any sense of the above panic message without mor= e >> >> > context. >> >> >> >> In the case of this panic, the stack of the thread which panics is >> >> useless; it's someone trying to propagate priority that discovered it= . >> >> =C2=A0A backtrace on tid 100033 would be useful. >> >> >> >> With WITNESS enabled, it's possible to have this panic display the >> >> stack of the incorrectly sleeping thread at the time it acquired the >> >> lock, as well, but this code isn't in CURRENT or any release. =C2=A0I= have >> >> a patch at $WORK I can dig up on Monday. >> > >> > Huh? =C2=A0The stock kernel dumps a stack trace of the offending threa= d if you have >> > DDB enabled: >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If the threa= d is asleep, then we are probably about >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * to deadlock.= =C2=A0To make debugging this easier, just >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * panic and te= ll the user which thread misbehaved so >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * they can hop= efully get a stack trace from the truly >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * misbehaving = thread. >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (TD_IS_SLEEP= ING(td)) { >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0printf( >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Sleeping threa= d (tid %d, pid %d) owns a non-sleepable lock\n", >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_tid, td->td_proc->p_pid); >> > #ifdef DDB >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0db_trace_thread(td, -1); >> > #endif >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0panic("sleeping thread"); >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> > >> > It may be that we can make use of the STACK API here instead to output= this >> > trace even when DDB isn't enabled. =C2=A0The patch below tries to do t= hat >> > (untested). =C2=A0It does some odd thigns though since it is effective= ly running >> > from a panic context already, so it uses a statically allocated 'struc= t stack' >> > rather than using stack_create() and uses stack_print_ddb() since it i= s >> > holding spin locks and can't possibly grab an sx lock: >> > >> > Index: subr_turnstile.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 >> > --- subr_turnstile.c =C2=A0 =C2=A0(revision 228534) >> > +++ subr_turnstile.c =C2=A0 =C2=A0(working copy) >> > @@ -72,6 +72,7 @@ __FBSDID("$FreeBSD$"); >> > =C2=A0#include >> > =C2=A0#include >> > =C2=A0#include >> > +#include >> > =C2=A0#include >> > =C2=A0#include >> > >> > @@ -175,6 +176,7 @@ static void turnstile_fini(void *mem, int size); >> > =C2=A0static void >> > =C2=A0propagate_priority(struct thread *td) >> > =C2=A0{ >> > + =C2=A0 =C2=A0 =C2=A0 static struct stack st; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0struct turnstile *ts; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0int pri; >> > >> > @@ -217,8 +219,10 @@ propagate_priority(struct thread *td) >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0printf( >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Sleeping threa= d (tid %d, pid %d) owns a non-sleepable lock\n", >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_tid, td->td_proc->p_pid); >> > -#ifdef DDB >> > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 db_trace_thread(td, -1); >> > +#ifdef STACK >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 stack_zero(&st); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 stack_save_td(&st, td); >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 stack_print_ddb(&st); >> > =C2=A0#endif >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0panic("sleeping thread"); >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> > >> > -- >> >> I'm not sure it is a wise idea to trimm the DDB part, because it is >> much more common than STACK enabled. Note that stack(9) is working if >> you define DDB too, so I'd say to do that for both. >> Also, I don't think you need the stack_zero() prior to set it. > > Err, STACK is enabled in GENERIC in release kernels but DDB is not, so I = think > STACK is the more common one. =C2=A0As far as stack_zero(), I was just be= ing paranoid. And what is the point for not having #ifdef STACK as #if defined(STACK) || defined(DDB) ? >> As we are here, however, I have a question for Robert here: do you >> think we should support the _ddb() variant of options even in the case >> DDB is not enabled in the kernel? >> Probabilly the way it is nowadays is easier to have stack(9) both >> defined for DDB and STACK, but in general I wouldn't advertise that. > > The _ddb variants are always enabled by my reading. =C2=A0They just use d= ifferent > entry points into the linker that don't use locking. My question is different: why we define them anyway even when DDB is not enabled? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:38:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D169C1065670; Tue, 20 Dec 2011 15:38:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE868FC14; Tue, 20 Dec 2011 15:38:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAAALSr8E6DaFvO/2dsb2JhbABDhQ6WHJFagXIBAQEEAQEBIAQnIAsbDgoCAg0ZAikBCSYGCAcEARwEh2GlPpFlgS+JR4EWBIg3iiOCJZJO X-IronPort-AV: E=Sophos;i="4.71,382,1320642000"; d="scan'208";a="151133848" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Dec 2011 10:38:35 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0A918B4008; Tue, 20 Dec 2011 10:38:34 -0500 (EST) Date: Tue, 20 Dec 2011 10:38:34 -0500 (EST) From: Rick Macklem To: John Baldwin Message-ID: <511423305.448605.1324395514934.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201112200900.39087.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:38:38 -0000 John Baldwin wrote: > On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote: > > Hi, > > > > A recent NFS client crash: > > http://glebius.int.ru/tmp/nfs_panic.jpg > > appears to have happened because some field is > > bogus when crfree() is called. I've asked Gleb > > to disassemble crfree() for me, so I can try and > > see exactly which field causes the crash, however... > > > > Basically, the code: > > newcred = crdup(cred); > > - does read with newcred > > crfree(newcred); <-- which crashes at 0x65 into > > crfree() > > > > Looking at crdup(), it calls crcopy(), which copies > > 4 pointers and then ref. counts them: > > cr_uidinfo, cr_ruidinfo, cr_prison and cr_loginclass > > > > It seems some lock should be held while crcopy() does this, > > so that the pointers don't get deref'd during the copy/ref. count? > > (Or is there some rule that guarantees these won't change. ie. No > > no calls to change_euid() or similar.) > > > > Is there such a lock and should crdup() use it? > > In general the caller of crdup is expected to hold a reference on cred > or some > other lock to ensure that cred remains valid and cannot be free'd > while it is > being duplicated. There is no global lock that crdup can hold for > that, > instead the caller is required to guarantee that. > Well, I think it does hold a reference on cred. I think the problem is that this doesn't stop another process from changing the pointer fields: cr_uidinfo, cr_ruidinfo, cr_loginclass and cr_prison For example, change_euid() replaces cr_uidinfo. There is something called cr_copysafe(), which assumes PROC_LOCK(p) is held. However, for the case that crashed, it is an iod read-ahead thread, so I don't think I know what the correct "p" argument is? It also appears that PROC_LOCK(p) is used to lock change_euid(), when it replaces cr_uidinfo with a different pointer. (Basically, it appears that the cr_uidinfo, cr_ruidinfo, cr_loginclass and cr_prison are protected by PROC_LOCK(p), but it isn't obvious to me that the NFS iod thread can know what the correct "p" is. In fact, that process may have already exited, since the "cred" is refenenced by b_rcred for the buffer in the buffer cache that is being read-ahead. For my NFS client case, I need a "new" cred, but it has to have cr_uidinfo etc filled in, since the kernel rpc does a crdup() and the cr_uidinfo field is used in socket calls further down. Basically, the NFS client fills in uid, gid-list for the "new" cred and doesn't care about other fields, except whatever the kernel rpc and socket ops care about. Would it be ok if, instead of using crdup(), I create the "new" cred via: cr = crget(); - do the same as crcopy(), except for the pointer fields, which would be set as follows cr->cr_uidinfo = uifind(0); /* This means that chgsbsize() will record * the change for uid 0, but since this is * an iod thread for the NFS client, that * seems ok? */ cr->cr_ruidinfo = uifind(0); cr->cr_loginclass = loginclass_find("default"); /* For cr_prison, I think what crcopy() does is safe, since cr_prison * doesn't normally get changed after a process does I/O, I think? * Alternately, it could be set to &prison0. Does setting it to &prison0 * break anything? */ prison_hold(cr->cr_prison); crfree() does check for these fields being non-NULL before freeing them, but crdup() does not check for the NULL case before incrementing ref cnts on them. If crdup() were changed to check for non-NULL, then I think the only one of the above that would need to be set is cr_uidinfo, since that appears to be the only one used by socket ops. Comments? Am I missing something? Thanks, rick > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:43:22 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AACE31065673; Tue, 20 Dec 2011 15:43:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 693E18FC1B; Tue, 20 Dec 2011 15:43:22 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:885d:8801:7070:a497] (unknown [IPv6:2001:7b8:3a7:0:885d:8801:7070:a497]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B33B35C37; Tue, 20 Dec 2011 16:43:21 +0100 (CET) Message-ID: <4EF0AD19.2000603@FreeBSD.org> Date: Tue, 20 Dec 2011 16:43:21 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> In-Reply-To: <4EF0499D.4070000@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:43:22 -0000 On 2011-12-20 09:38, Doug Barton wrote: ... > I tried replacing both ifconfig and dhclient with the versions that were > built along with the new kernel, and that didn't work. Looking at the changes in r228571, it seems they also affect libc, so installing that is probably also needed. Since all my test systems are already upgraded to post-r228571, can somebody please confirm it works after doing: make -C $srcdir/lib/libc install make -C $srcdir/sbin/dhclient install make -C $srcdir/sbin/ifconfig install > The traditional (and documented) upgrade process for many years has been > to boot the new kernel, make sure it's Ok, then update world. Obviously > something different is needed this time, so it needs an UPDATING entry > (assuming that all this is not just a bug). Well, if there *is* any method of getting your network working before installworld, it should be added to UPDATING... :) From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 15:55:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E48D1065672; Tue, 20 Dec 2011 15:55:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0398FC0C; Tue, 20 Dec 2011 15:55:12 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D788946B06; Tue, 20 Dec 2011 10:55:11 -0500 (EST) Date: Tue, 20 Dec 2011 15:55:11 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> <201112200852.23300.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@freebsd.org, freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:55:12 -0000 On Tue, 20 Dec 2011, Attilio Rao wrote: > As we are here, however, I have a question for Robert here: do you think we > should support the _ddb() variant of options even in the case DDB is not > enabled in the kernel? It's possible that _ddb() should be spelled _unlocked(), or perhaps _debug(), but neither really suggests what the name should actually imply: using it is safe only in a marginal (debugging) sense, and not in a production code sense. One might also reasonable call them stack_foo_dontusethis(). The _ddb() variants are used in at least two not strictly DDB cases: redzone support, and Solaris memory allocation. And, I guess, the current lock debugging case that we're talking about now, but I'm not sure if those debugging features specifically require DDB in the kernel themselves? Robert From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:13:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A405106564A for ; Tue, 20 Dec 2011 16:13:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C388C8FC15 for ; Tue, 20 Dec 2011 16:13:49 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3826050obb.13 for ; Tue, 20 Dec 2011 08:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zqRsDfE3VzpG4C+LRNyLplOrWjpNey3J+xu9jByW0YM=; b=ZuXeVEjsmo0Hin+0EXtOuiUFEV2K+ElOhGMNGkJJUMSA/YeOvoxzRzQcbTsuL2DCmc TZYbGjmLPLamFpt7KZ6MUTRKS+O/F/OmvhEF6NIYAUEc3zZ1Fg+2Nsz6/MHn4Scykc6/ uSOxh2YsNrGxltFOyMwykYrenAngJb1tBP7V0= MIME-Version: 1.0 Received: by 10.182.231.38 with SMTP id td6mr2203727obc.66.1324397629230; Tue, 20 Dec 2011 08:13:49 -0800 (PST) Received: by 10.182.62.227 with HTTP; Tue, 20 Dec 2011 08:13:48 -0800 (PST) In-Reply-To: References: <20111219224545.GA22631@onelab2.iet.unipi.it> Date: Tue, 20 Dec 2011 08:13:48 -0800 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo , current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:13:50 -0000 2011/12/20 Olivier Cochard-Labb=E9 : > On Mon, Dec 19, 2011 at 11:45 PM, Luigi Rizzo wrote: >> >> On a related topic, does anyone have experience on cross-building >> nanobsd images ? Hello Mr. Olivier! > I using "little" cross-building nanobsd images (i386 on amd64 and vice ve= rsa). > All my patchs for nanobsd are available on BSD Router Project > (http://bsdrp.net) including a patch for compiling ports from nanobsd > too. Yeah, FreeNAS 8.x employs a similar semi-hacky way of doing a full-blown chroot with a clean environment setup [that you might want to steal ;)..[1]] > Right now I'm working on adding cross-build mips (RouterStation Pro) > nanobsd patch but without the "compiling ports" feature, because I can > only cross-compile word/kernel and I didn't know how to cross-compile > ports. Let's work together on this. It's a non-trivial project that I'd like to see come true for FreeNAS to build an ARM platform on x86 hardware (someday..). Also, I'd pick up some of the recent changes we made to nanobsd [2] -- it might help your cause. Cheers, -Garrett 1. http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common (look for the CR function; follow the history back for credits to the original inspiration). 2. http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/build/nanobsd/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:19:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6061065675 for ; Tue, 20 Dec 2011 16:19:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8563A8FC18 for ; Tue, 20 Dec 2011 16:19:43 +0000 (UTC) Received: by ghrr16 with SMTP id r16so1216436ghr.13 for ; Tue, 20 Dec 2011 08:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Tceuw5JExhmYUk3w2CFAvATnucXSCZ2mjQ4J6OjB2pk=; b=Vo8zqNDDL1n1F3jyVqHMetItF9MVO+uDJxQNmy5tK6nGjYiih7pmH3eKcHxerfnHZK SjEiX+r7AD9UtwodkU5omyNDXVlTXobDw45RHGkIjNLY3ez8cJXpUU3tByQhUaj75Q6R PdaJZ1ZC5MbADtH/AhEbqtQ0PZM1nmjZIOh5c= Received: by 10.236.191.5 with SMTP id f5mr4765833yhn.122.1324397982633; Tue, 20 Dec 2011 08:19:42 -0800 (PST) Received: from starr-wireless.local (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id u47sm4061146yhl.0.2011.12.20.08.19.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 08:19:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=koi8-r From: Garrett Cooper In-Reply-To: Date: Tue, 20 Dec 2011 08:19:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9252B536-3C27-428A-8B61-4DC9C774BDA4@gmail.com> References: <4EF08F84.4060500@lissyara.su> To: Alexander Yerenkow X-Mailer: Apple Mail (2.1084) Cc: Alex Keda , Current FreeBSD Subject: Re: regression: Xorg get 100% cpu and freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:19:44 -0000 On Dec 20, 2011, at 6:29 AM, Alexander Yerenkow wrote: > 20 =C4=C5=CB=C1=C2=D2=D1 2011 =C7. 15:37 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC= =D8 Alex Keda =CE=C1=D0=C9=D3=C1=CC: >=20 >> I use CURRENT from 2011-11-18 - all OK >> After update to today - I have problem - on start, Xorg get 100% CPU = and >> freeze (monitor go to turn off) >> I recompile Xorg, all modules - no happy. >> I try update x11-drivers/xf86-video-ati to 6.14.3 - no happy >>=20 >> If I delete /boot/kernel/drm.ko - all work OK, but very slow... >>=20 >=20 > BTW, mine test images built from sources with KMS do the same thing - = start > xorg, and it just totally hangs pc. > I think it's about a month I have such situation. +1 for my machine with the nvidia-driver. It ran out of swap = over the weekend after the drive disconnected from the bus after 2 = months or so of uptime. /var/log/messages for everyone might help = isolate the issue... Previous version was r226140; new version is = r227801. Thanks, -Garrett Dec 19 10:28:12 streetfighter kernel: = (ada0:g_vfs_done():ahcich0:0:0:ada0p2[READ(offset=3D836907008, = length=3D4096)]0): error =3D 6 Dec 19 10:28:12 streetfighter kernel: lost device Dec 19 10:28:12 streetfighter kernel: swap_pager: I/O error - pagein = failed; blkno 17914,size 12288, error 6 Dec 19 10:28:12 streetfighter kernel: vnode_pager_getpages: I/O read = error Dec 19 10:28:12 streetfighter kernel: vm_fault: pager read error, pid = 1291 (syslogd) Dec 19 10:28:12 streetfighter kernel: vm_fault: pager read error, pid = 79074 (smartd) Dec 19 10:28:12 streetfighter kernel: = g_vfs_done():ada0p2[READ(offset=3D131072, length=3D32768)]error =3D 6 Dec 19 10:28:12 streetfighter kernel: = g_vfs_done():ada0p2[READ(offset=3D131072, length=3D32768)]error =3D 6 Dec 19 10:28:12 streetfighter kernel: = g_vfs_done():ada0p2[WRITE(offset=3D797257728, length=3D4096)]error =3D 6 Dec 19 10:28:12 streetfighter kernel: /: got error 6 while accessing = filesystem Dec 19 10:28:12 streetfighter kernel: panic: = softdep_deallocate_dependencies: unrecovered I/O error Dec 19 10:28:12 streetfighter kernel: cpuid =3D 0 Dec 19 10:28:12 streetfighter kernel: KDB: enter: panic Dec 19 10:28:12 streetfighter kernel: Dec 19 10:28:12 streetfighter kernel: Dec 19 10:28:12 streetfighter kernel: Fatal trap 3: breakpoint = instruction fault while in kernel mode Dec 19 10:28:12 streetfighter kernel: cpuid =3D 0; apic id =3D 00 Dec 19 10:28:12 streetfighter kernel: instruction pointer =3D = 0x20:0xffffffff804b482b Dec 19 10:28:12 streetfighter kernel: stack pointer =3D = 0x28:0xffffff80002759f0 Dec 19 10:28:12 streetfighter kernel: frame pointer =3D = 0x28:0xffffff8000275a10 Dec 19 10:28:12 streetfighter kernel: code segment =3D base = 0x0, limit 0xfffff, type 0x1b Dec 19 10:28:12 streetfighter kernel: =3D DPL 0, pres 1, long 1, def32 = 0, gran 1 Dec 19 10:28:12 streetfighter kernel: processor eflags =3D interrupt = enabled, IOPL =3D 0 Dec 19 10:28:12 streetfighter kernel: current process =3D 13 = (g_up) Dec 19 10:28:12 streetfighter kernel: trap number =3D 3 Dec 19 10:28:12 streetfighter kernel: panic: breakpoint instruction = fault Dec 19 10:28:12 streetfighter kernel: cpuid =3D 0 Dec 19 10:28:12 streetfighter kernel: KDB: enter: panic= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:29:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A37F106566C for ; Tue, 20 Dec 2011 16:29:04 +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 3AB108FC08 for ; Tue, 20 Dec 2011 16:29:03 +0000 (UTC) Received: by ggnp1 with SMTP id p1so7131483ggn.13 for ; Tue, 20 Dec 2011 08:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uUlzRHdNNvgmtpX0REZCpfxbFMgdujeTu9QqVAvDuvk=; b=WsV0ddwDVP+taz9hripDWqhpTpq2d42lCU7hW5M2XbHxFrzEt6qMX1Q713z5muUT9A wlEICAZCBb1S1m5gtoQ2e/2LK0iaz4Nsqc6Yg+dDs6SaFh3ttTScM54nT/mnucnc6USC vsjt3FYCtd8CL7CZTYIYt8QnSN/46Uv+zXXZs= MIME-Version: 1.0 Received: by 10.182.73.42 with SMTP id i10mr2245660obv.76.1324398543265; Tue, 20 Dec 2011 08:29:03 -0800 (PST) Received: by 10.182.62.227 with HTTP; Tue, 20 Dec 2011 08:29:03 -0800 (PST) In-Reply-To: <4EF0919A.3040003@unsane.co.uk> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EF065EB.5090601@digsys.bg> <4EF0919A.3040003@unsane.co.uk> Date: Tue, 20 Dec 2011 08:29:03 -0800 Message-ID: From: Garrett Cooper To: Vincent Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:29:04 -0000 On Tue, Dec 20, 2011 at 5:46 AM, Vincent Hoffman wrote: > On 20/12/2011 10:39, Daniel Kalchev wrote: >> >> >> On 20.12.11 11:42, Garrett Cooper wrote: >>> As long as I have reliable checksums that match the what the upstream >>> source says is the real thing, it doesn't practically matter where I >>> get my images from. >> >> Relying on checksums that are published on the same web site where you >> download the files from and given that most of these sites do not even >> use SSL.... so much about 'security'. >> > This does remind me of one issue that while a little off topic for this > thread.... > If i wanted to get, for example the SHA265 checksums from a verified > source, how would i verify this currently? There doesnt seem to be an > SSL site for www.freebsd.org and its not too hard to redirect someone to > a fake website. > What would be a more reasonable list to request this on? And so the masses go off on a quest to answer how to obtain releases instead of staying focused on the original problem at hand.. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:42:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075AC106566C; Tue, 20 Dec 2011 16:42:26 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id BDA3B8FC0A; Tue, 20 Dec 2011 16:42:25 +0000 (UTC) Received: by dakp5 with SMTP id p5so6259628dak.13 for ; Tue, 20 Dec 2011 08:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mNUudw+a+ceD+iQgLNVYTEoAF3bCCXTnO+q8V2xCjAE=; b=Dby2f5r+hLwVE6zGUmHEey0HFwm8peOE1Y33K3YiWkOxC3jBzAttKXWA64UPisj42r 5vjhyeBs3BhkgNgJycvODH3pMs4PwtGaU6564lmDW8l2Z1b+kKP13sbwHS6LyqH2VMWk Q7Hcp9aGd0Hf8ndB7Trltw2P1QxHyfJbFqjBw= MIME-Version: 1.0 Received: by 10.68.75.163 with SMTP id d3mr4335720pbw.88.1324399345167; Tue, 20 Dec 2011 08:42:25 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.136 with HTTP; Tue, 20 Dec 2011 08:42:25 -0800 (PST) In-Reply-To: <201112200932.21223.jhb@freebsd.org> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <201112200852.23300.jhb@freebsd.org> <201112200932.21223.jhb@freebsd.org> Date: Tue, 20 Dec 2011 08:42:25 -0800 X-Google-Sender-Auth: 5tWe4cu3Mrgv3ioHTEmlyDYjlSI Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Watson , freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:42:26 -0000 On Tue, Dec 20, 2011 at 6:32 AM, John Baldwin wrote: > On Tuesday, December 20, 2011 9:22:48 am mdf@freebsd.org wrote: >> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote: >> > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote: >> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev = wrote: >> >> > On Sun, 18 Dec 2011 01:09:00 +0100 >> >> > "O. Hartmann" wrote: >> >> > >> >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock >> >> >> panic: sleeping thread >> >> >> cpuid =3D 0 >> >> >> >> >> >> PID 16 is always USB on my box. >> >> > >> >> > You really need to give us a backtrace when you quote panics. It is >> >> > impossible to make any sense of the above panic message without mor= e >> >> > context. >> >> >> >> In the case of this panic, the stack of the thread which panics is >> >> useless; it's someone trying to propagate priority that discovered it= . >> >> =A0A backtrace on tid 100033 would be useful. >> >> >> >> With WITNESS enabled, it's possible to have this panic display the >> >> stack of the incorrectly sleeping thread at the time it acquired the >> >> lock, as well, but this code isn't in CURRENT or any release. =A0I ha= ve >> >> a patch at $WORK I can dig up on Monday. >> > >> > Huh? =A0The stock kernel dumps a stack trace of the offending thread i= f you have >> > DDB enabled: >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If the thread is asleep, then we are= probably about >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to deadlock. =A0To make debugging th= is easier, just >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * panic and tell the user which thread= misbehaved so >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * they can hopefully get a stack trace= from the truly >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * misbehaving thread. >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (TD_IS_SLEEPING(td)) { >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf( >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Sleeping thread (tid %d, pid %d) owns = a non-sleepable lock\n", >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0td->td_tid, td-= >td_proc->p_pid); >> > #ifdef DDB >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0db_trace_thread(td, -1)= ; >> > #endif >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0panic("sleeping thread"= ); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> Hmm, maybe this wasn't in 7, or maybe I'm just remembering that we >> added code to print *which* lock it holds (using WITNESS data). =A0I do >> recall that this panic alone was often not sufficient to debug the >> problem. > > I think the db_trace_thread() has been around for a while (since 5 or 6), > but it is true that we don't tell you which lock is held even with this. > That might be a useful thing to output before the panic. This patch isn't quite right since I had to hand-edit it. There's a small chance I can commit this in the near future, but of someone else wants to take it, feel free. Style isn't yet fixed up to be FreeBSD standard either. --- /data/sb/bsd.git/sys/kern/subr_turnstile.c 2011-12-12 10:23:12.542196632 -0800 +++ kern/subr_turnstile.c 2011-12-09 10:59:29.882643558 -0800 @@ -165,10 +165,43 @@ static void turnstile_dtor(void *mem, int size, void *arg); #endif static int turnstile_init(void *mem, int size, int flags); static void turnstile_fini(void *mem, int size); +#ifdef INVARIANTS +static void +sleeping_thread_owns_a_nonsleepable_lock(struct thread *td) +{ + printf("Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", + td->td_tid, td->td_proc->p_pid); +#ifdef DDB + db_trace_thread(td, -1); +#endif +#ifdef WITNESS + struct lock_list_entry *lock_list, *lle; + int i; + + lock_list =3D td->td_sleeplocks; + if (lock_list =3D=3D NULL || lock_list->ll_count =3D=3D 0) { + printf("Thread does not appear to hold any mutexes!\n"); + return; + } + + for (lle =3D lock_list; lle !=3D NULL; lle =3D lle->ll_next) { + for (i =3D lle->ll_count - 1; i >=3D 0; i--) { + struct lock_instance *li =3D &lle->ll_children[i]; + + printf("Lock %s acquired at %s:%d\n", + li->li_lock->lo_name, li->li_file, li->li_line); + } + } +#endif /* WITNESS */ +} +#else +#define sleeping_thread_owns_a_nonsleepable_lock(td) do { } while (0) +#endif /* INVARIANTS */ + /* * Walks the chain of turnstiles and their owners to propagate the priorit= y * of the thread being blocked to all the threads holding locks that have = to * release their locks before this thread can run again. */ @@ -210,19 +243,31 @@ * If the thread is asleep, then we are probably about * to deadlock. To make debugging this easier, just * panic and tell the user which thread misbehaved so * they can hopefully get a stack trace from the truly * misbehaving thread. */ if (TD_IS_SLEEPING(td)) { - printf( - "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", - td->td_tid, td->td_proc->p_pid); -#ifdef DDB - db_trace_thread(td, -1); -#endif - panic("sleeping thread"); + sleeping_thread_owns_a_nonsleepable_lock(td); + panic("sleeping thread %p owns a nonsleepable lock", + td); } /* * If this thread already has higher priority than the * thread that is being blocked, we are finished. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:43:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA17A1065675; Tue, 20 Dec 2011 16:43:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id CAF298FC29; Tue, 20 Dec 2011 16:43:46 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 218384289; Tue, 20 Dec 2011 17:43:44 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Tue, 20 Dec 2011 17:41:18 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EF088C8.8090906@FreeBSD.org> <4EF0A6D4.2020107@FreeBSD.org> In-Reply-To: <4EF0A6D4.2020107@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112201741.18428.hselasky@c2i.net> Cc: FreeBSD-Current , freebsd-usb@freebsd.org Subject: Re: ukbd locking update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:43:47 -0000 On Tuesday 20 December 2011 16:16:36 Andriy Gapon wrote: > And the new patch: > http://people.freebsd.org/~avg/usb.new.diff Patch looks OK. I will give it a spin later today. Feel free to commit if you've tested the three use-cases I listed in a previous e-mail. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:52:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9AC106564A; Tue, 20 Dec 2011 16:52:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id F415E8FC19; Tue, 20 Dec 2011 16:52:41 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pBKGpZNF078921; Tue, 20 Dec 2011 10:51:35 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pBKGpYqk078920; Tue, 20 Dec 2011 10:51:34 -0600 (CST) (envelope-from brooks) Date: Tue, 20 Dec 2011 10:51:34 -0600 From: Brooks Davis To: Dimitry Andric Message-ID: <20111220165134.GA68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <4EF0AD19.2000603@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:52:42 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: > On 2011-12-20 09:38, Doug Barton wrote: > ... > > I tried replacing both ifconfig and dhclient with the versions that were > > built along with the new kernel, and that didn't work. >=20 > Looking at the changes in r228571, it seems they also affect libc, so > installing that is probably also needed. Since all my test systems are > already upgraded to post-r228571, can somebody please confirm it works > after doing: >=20 > make -C $srcdir/lib/libc install > make -C $srcdir/sbin/dhclient install > make -C $srcdir/sbin/ifconfig install We almost certainly need to back r228571 out. This is not an acceptable upgrade path that would be acceptable historically. Specially, we have effectively promised users that an X.Y world will work on an X+1.0 kernel for most of history. There are obvious exceptions to this, but we have never allowed ifconfig to be one of them (I broke it many years ago with my first attempt to add if_epoch to if_data and had to back that out). -- Brooks --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8L0WXY6L6fI4GtQRArjHAKDix0K0bP6i8Qs2khJj0U8FKPHN2gCcD+YW 91RqsPLfBykDw5uW07oEeF4= =MH8F -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:58:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B531065672 for ; Tue, 20 Dec 2011 16:58:22 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:32:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id BAEE98FC13 for ; Tue, 20 Dec 2011 16:58:21 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 354691802680; Tue, 20 Dec 2011 17:58:20 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 8C08A1C0007C; Tue, 20 Dec 2011 17:58:20 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id 3p+nIJX2b9ht; Tue, 20 Dec 2011 17:58:19 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-43-176.dynamic.mnet-online.de [93.104.43.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Tue, 20 Dec 2011 17:58:19 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id AABCF24205; Tue, 20 Dec 2011 17:58:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 8365024200; Tue, 20 Dec 2011 17:58:17 +0100 (CET) Date: Tue, 20 Dec 2011 17:58:16 +0100 (CET) From: Michael Reifenberger To: Peter Maloney In-Reply-To: <4EEFA12D.2070803@brockmann-consult.de> Message-ID: References: <4EEF488E.1030904@freebsd.org> <4EEF5B5C.90905@brockmann-consult.de> <4EEFA12D.2070803@brockmann-consult.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:58:22 -0000 On Mon, 19 Dec 2011, Peter Maloney wrote: ... > Thanks for the info. But I am confused by it, because when my disks > moved around randomly on reboot, it really did mess things up. The first > few times it happened, there was no issue, but when a spare took the > place of a pool disk, it messed things up. I can see the UUIDs when I > look at zdb output, so I really have no idea why it messed things up. > ... but it did, so I will always caution people anyway. I can't point > you to any relevant lines of code that cause the problem, but I know it > can happen... and it will when you least expect it. ;) > Normaly spare disks are not part of the pool so it can't replace a pools disk automatically (except the property 'autoreplace' is set to 'on'). But as allways no software is error free and your issue could be an uncaught edge case of something. Theoretically it could be an timing issue during boot too due to the async GEOM/CAM nature... Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:09:06 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C09C106566B; Tue, 20 Dec 2011 17:09:06 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABCE8FC15; Tue, 20 Dec 2011 17:09:06 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id E9D745619E; Tue, 20 Dec 2011 11:09:05 -0600 (CST) Date: Tue, 20 Dec 2011 11:09:05 -0600 From: Mark Linimon To: current@FreeBSD.org Message-ID: <20111220170905.GE10143@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: linimon@FreeBSD.org Subject: status of ports and clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:09:06 -0000 I have recently been able to get the new build cluster on pointyhat-west set up to run full builds of ports with clang on amd64-9. I have documented the latest results on the wiki: http://wiki.freebsd.org/PortsAndClang If you are interested in working on ports being built via clang, this is your place to start. Please also note that now that we have up-to-date builds going, it is not as useful to us to report individual clang build failures. Patches to fix problems are, of course, highly welcome. mcl From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:26:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C221C106564A for ; Tue, 20 Dec 2011 17:26:34 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:32:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCEE8FC13 for ; Tue, 20 Dec 2011 17:26:34 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 18F21180025B; Tue, 20 Dec 2011 18:26:32 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 71B641C00155; Tue, 20 Dec 2011 18:26:32 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id 2juHqk2HIeLr; Tue, 20 Dec 2011 18:26:27 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-43-176.dynamic.mnet-online.de [93.104.43.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Tue, 20 Dec 2011 18:26:27 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id DAC4424441; Tue, 20 Dec 2011 18:26:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id AB6812443E; Tue, 20 Dec 2011 18:26:25 +0100 (CET) Date: Tue, 20 Dec 2011 18:26:25 +0100 (CET) From: Michael Reifenberger To: Luigi Rizzo In-Reply-To: <20111219224545.GA22631@onelab2.iet.unipi.it> Message-ID: References: <20111219224545.GA22631@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:26:34 -0000 Hi, I used to build a few ARM images (on amd64 host) using /usr/src/tools/tools/nanobsd/gateworks/ and regularly i386 images (on amd64 host too) using /usr/src/tools/tools/nanobsd/pcengines/ Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:31:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9F4106564A for ; Tue, 20 Dec 2011 17:31:01 +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 C07E18FC08 for ; Tue, 20 Dec 2011 17:31:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5AFF646B0D; Tue, 20 Dec 2011 12:31:00 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9975B914; Tue, 20 Dec 2011 12:30:59 -0500 (EST) From: John Baldwin To: Rick Macklem Date: Tue, 20 Dec 2011 10:47:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <511423305.448605.1324395514934.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <511423305.448605.1324395514934.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112201047.37789.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 12:31:00 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:31:01 -0000 On Tuesday, December 20, 2011 10:38:34 am Rick Macklem wrote: > John Baldwin wrote: > > On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote: > > > Hi, > > > > > > A recent NFS client crash: > > > http://glebius.int.ru/tmp/nfs_panic.jpg > > > appears to have happened because some field is > > > bogus when crfree() is called. I've asked Gleb > > > to disassemble crfree() for me, so I can try and > > > see exactly which field causes the crash, however... > > > > > > Basically, the code: > > > newcred = crdup(cred); > > > - does read with newcred > > > crfree(newcred); <-- which crashes at 0x65 into > > > crfree() > > > > > > Looking at crdup(), it calls crcopy(), which copies > > > 4 pointers and then ref. counts them: > > > cr_uidinfo, cr_ruidinfo, cr_prison and cr_loginclass > > > > > > It seems some lock should be held while crcopy() does this, > > > so that the pointers don't get deref'd during the copy/ref. count? > > > (Or is there some rule that guarantees these won't change. ie. No > > > no calls to change_euid() or similar.) > > > > > > Is there such a lock and should crdup() use it? > > > > In general the caller of crdup is expected to hold a reference on cred > > or some > > other lock to ensure that cred remains valid and cannot be free'd > > while it is > > being duplicated. There is no global lock that crdup can hold for > > that, > > instead the caller is required to guarantee that. > > > Well, I think it does hold a reference on cred. I think the problem is > that this doesn't stop another process from changing the pointer fields: > cr_uidinfo, cr_ruidinfo, cr_loginclass and cr_prison No, a credential with more than one reference is immutable and can not be changed. > For example, change_euid() replaces cr_uidinfo. There is something called > cr_copysafe(), which assumes PROC_LOCK(p) is held. However, for the case > that crashed, it is an iod read-ahead thread, so I don't think I know > what the correct "p" argument is? It also appears that PROC_LOCK(p) is > used to lock change_euid(), when it replaces cr_uidinfo with a different > pointer. (Basically, it appears that the cr_uidinfo, cr_ruidinfo, > cr_loginclass and cr_prison are protected by PROC_LOCK(p), but it isn't > obvious to me that the NFS iod thread can know what the correct "p" is. > In fact, that process may have already exited, since the "cred" is refenenced > by b_rcred for the buffer in the buffer cache that is being read-ahead. No, change_euid() only operates on a private credential where the caller knows that it holds the only reference to the credential. The various system calls like setuid(), etc. all allocate a new credential, grab the PROC_LOCK to protect what p_ucred refers to (and to serialize updates to p_ucred for a given process), copy the existing credential from p_ucred into the new credential, update the new credential as appropriate, then change p_ucred to point to the new credential before dropping the PROC_LOCK. The old credential then has its reference count dropped (since p_ucred no longer references it) via crfree(). However, that old credential is not changed and will remain immutable until the last reference is dropped and it is freed. > For my NFS client case, I need a "new" cred, but it has to have cr_uidinfo > etc filled in, since the kernel rpc does a crdup() and the cr_uidinfo > field is used in socket calls further down. Basically, the NFS client > fills in uid, gid-list for the "new" cred and doesn't care about other > fields, except whatever the kernel rpc and socket ops care about. > > Would it be ok if, instead of using crdup(), I create the "new" cred via: > cr = crget(); > - do the same as crcopy(), except for the pointer fields, which would be > set as follows > cr->cr_uidinfo = uifind(0); /* This means that chgsbsize() will record > * the change for uid 0, but since this is > * an iod thread for the NFS client, that > * seems ok? > */ > cr->cr_ruidinfo = uifind(0); > cr->cr_loginclass = loginclass_find("default"); > /* For cr_prison, I think what crcopy() does is safe, since cr_prison > * doesn't normally get changed after a process does I/O, I think? > * Alternately, it could be set to &prison0. Does setting it to &prison0 > * break anything? > */ > prison_hold(cr->cr_prison); > > crfree() does check for these fields being non-NULL before freeing them, > but crdup() does not check for the NULL case before incrementing ref cnts > on them. If crdup() were changed to check for non-NULL, then I think the > only one of the above that would need to be set is cr_uidinfo, since that > appears to be the only one used by socket ops. > > Comments? Am I missing something? Thanks, rick Using crdup() should be fine. Your old credential should not be changed out from under you since you hold a reference to it. I think there is some other bug that trashed your temporary credential before it was free'd. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:58:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD42E1065670 for ; Tue, 20 Dec 2011 17:58:48 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82AAA8FC12 for ; Tue, 20 Dec 2011 17:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=G9UIIYzffSZ9vTLBj719bY7bJJXWMAm2xV3osrKu0G0=; b=CQL28PKLQcw8xxV/8ITQgzgv5ZXtti55cDwQU4OCFifkw0v9hA58kISyWrSwDrV+cLzorEd42Y2l2yDrpEKHWG5le8XcG7d5GLDtnHJbJhfaV9+aUkL95q95w2HlD38Wcm7hiblfsgzg72YWr6BzZDu5QSf7FLmw5lzhh4uvjQU=; Received: from [32.97.110.60] (port=62625 helo=[9.41.58.142]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rd3xe-000NLg-DW for freebsd-current@freebsd.org; Tue, 20 Dec 2011 11:58:47 -0600 Message-ID: <4EF0CCC6.6060606@lerctr.org> Date: Tue, 20 Dec 2011 11:58:30 -0600 From: Larry Rosenman Organization: LERCTR Consulting User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.3.4 OpenPGP: id=2F035CE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-LERCTR-Spam-Score: 0.5 (/) X-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 Subject: clang (__builtin_ffs) vs /usr/include/string.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:58:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is anyone going to fix the following in the clang or FreeBSD system? In file included from /usr/include/string.h:45: /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' int ffs(int) __pure2; ^ /usr/include/machine/cpufunc.h:140:24: note: expanded from: #define ffs(x) __builtin_ffs(x) ^ /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' 7 warnings and 1 error generated. *** Error code 1 This looks like something that needs to change in clang/FreeBSD headers. - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO8MzGAAoJENC8dtAvA1zmaJAH/iQFOp2253yJgCCz8vbFotyY zV04olNDrLTYlKLZ8XNJ01qyiDnOXm/gL6TMZMvRiSNQg3e78ZYYPl2ufn0a1VNg lnaQ7SO4qCT1o/66HJKr9YGyjZ12IYQwCkHnzGc+OURlQ/ZLYfOrOVvuE1tFsNUH 5PEuZ2ywOGWdBf9BlzN8PaBp6fJ+zBMvTOamy5jjYhD5pd3E2io/DwGUGJogsACa 3ETUrZdnoxjdfuC3VxEy0kSuW7iaODbbI1AMVAR3eWivjayiAo26HnuJ6rW7GSiN Amn02uueCEQhl4d+Qvj4fDhMBg4PI+0blklheNJ9bjcxwtJDLk/KbevSU7SSCYg= =Nvdn -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 18:48:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D0D106566C; Tue, 20 Dec 2011 18:48:45 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 485488FC08; Tue, 20 Dec 2011 18:48:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6B27E25D385D; Tue, 20 Dec 2011 18:48:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 98F38BD76B6; Tue, 20 Dec 2011 18:48:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5l7X95eJN6db; Tue, 20 Dec 2011 18:48:42 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0E855BD76B5; Tue, 20 Dec 2011 18:48:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111220165134.GA68792@lor.one-eyed-alien.net> Date: Tue, 20 Dec 2011 18:48:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) Cc: freebsd-current , Gleb Smirnoff Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:48:46 -0000 On 20. Dec 2011, at 16:51 , Brooks Davis wrote: > On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: >> On 2011-12-20 09:38, Doug Barton wrote: >> ... >>> I tried replacing both ifconfig and dhclient with the versions that = were >>> built along with the new kernel, and that didn't work. >>=20 >> Looking at the changes in r228571, it seems they also affect libc, so >> installing that is probably also needed. Since all my test systems = are >> already upgraded to post-r228571, can somebody please confirm it = works >> after doing: >>=20 >> make -C $srcdir/lib/libc install >> make -C $srcdir/sbin/dhclient install >> make -C $srcdir/sbin/ifconfig install >=20 Depends on what you are trying to achieve. There is more software = affected. > We almost certainly need to back r228571 out. This is not an = acceptable > upgrade path that would be acceptable historically. Specially, we = have > effectively promised users that an X.Y world will work on an X+1.0 I am not sure we supported that but X. to X+1.Y maybe? > kernel for most of history. There are obvious exceptions to this, but > we have never allowed ifconfig to be one of them (I broke it many = years > ago with my first attempt to add if_epoch to if_data and had to back > that out). There is a couple of issues here. The one that's on me is struct ifa_msghdr / getifaddrs() and the problem = here is that software incl. getifaddrs() doesn't use the in structs embedded = lengths in first place. In if_data only a spare was reused, so no changes = there. That's certainly something we can and should fix in 9 before 10.0 will = happen. If that was the problem back then, it's certainly a pity it wasn't fixed = as we wouldn't have that problem these days then. It would allow appending = more stuff. For the appended int to ifaliasreq, in_aliasreq, in6_aliasreq I haven't looked at the actual problem in the upgrade paths. I guess it's not = much outside of ifconfig and probably ppp at least for the in_ in6_ variants. Backing r228571 out completely will be harder with every change glebius = commits on top. So if we think it'll be needed we should stop those commits now = and think first. Just breaking carp and backing out the user space API parts is only a = usable path with a plan B on how to fix carp as well in the same go really. Ingoring 9.0 -> 10-CURRENT or an update on HEAD (neither of which is not = a normal user upgrade path an supported) I am still wondering how much of = that can be mitigated and if it might make sense to ponder that direction = (also for further future changes for sure to happen) to not be stuck forever? I fear we'll see/want to do more of these kinds as more people look at = the if/ll layer... /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:09:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15C2106566C for ; Tue, 20 Dec 2011 19:09:29 +0000 (UTC) (envelope-from sjg@evilcode.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFE908FC17 for ; Tue, 20 Dec 2011 19:09:29 +0000 (UTC) Received: by iadj38 with SMTP id j38so9953286iad.13 for ; Tue, 20 Dec 2011 11:09:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.159.72 with SMTP id k8mr2993028icx.14.1324408169088; Tue, 20 Dec 2011 11:09:29 -0800 (PST) Received: by 10.50.163.106 with HTTP; Tue, 20 Dec 2011 11:09:28 -0800 (PST) In-Reply-To: <28E4047A-356A-4CCE-A134-9B24A7444806@gmail.com> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF3FF9.7070307@digsys.bg> <28E4047A-356A-4CCE-A134-9B24A7444806@gmail.com> Date: Tue, 20 Dec 2011 12:09:28 -0700 Message-ID: From: "Samuel J. Greear" To: Chiron IO X-Mailman-Approved-At: Tue, 20 Dec 2011 19:11:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:09:30 -0000 On Tue, Dec 20, 2011 at 4:28 AM, Chiron IO wrote: > Guys, > > I have a question about these benchmarks. > > Why worry about that if the CURRENT comes with debug enabled by default? > > > http://joaobarros.blogspot.com/2005/07/freebsd-how-to-turn-off-debug-options.html > > > In the real world problems happen and someone has to be able to, in some fashion, identify and resolve those problems. As such, shipping FreeBSD releases with INVARIANTS disabled is a mistake and any benchmarks done without INVARIANTS enabled will fail to reflect most reasonable real world use-cases. Although these benchmarks cannot stand on their own merits for many reasons, I do not see how any benchmark is automatically invalidated by using the default development configuration. Sam From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:15:22 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583EF1065678; Tue, 20 Dec 2011 19:15:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id C92BE8FC17; Tue, 20 Dec 2011 19:15:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJFKXH071293; Tue, 20 Dec 2011 23:15:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJFKeA071292; Tue, 20 Dec 2011 23:15:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:15:20 +0400 From: Gleb Smirnoff To: Doug Barton Message-ID: <20111220191520.GA70684@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF0499D.4070000@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:15:22 -0000 Doug, On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote: D> > I saw this too, when my kernel and userland were out of sync (e.g. just D> > after installing a new kernel, and before installworld). I suspect it D> > is caused by the changes in r228571, which cause old ifconfig and D> > dhclient to not recognize any interfaces. I'm not 100% sure though... D> D> I tried replacing both ifconfig and dhclient with the versions that were D> built along with the new kernel, and that didn't work. This shouldn't happen. If you did 'make buildworld buildkernel', then your world in objdir would have binaries compiled with includes from source tree, not from /usr/include, thus compatible with new kernel. 'make buildworld buildkernel' always produces compatible kernel and worlds. However, if you did 'cd /usr/src/sbin/ifconfig && make all install' then that didn't work, since used headers from /usr/include. D> The traditional (and documented) upgrade process for many years has been D> to boot the new kernel, make sure it's Ok, then update world. Obviously D> something different is needed this time, so it needs an UPDATING entry D> (assuming that all this is not just a bug). The documented one says 'Reboot into single user mode' and then install new world. This path was not broken, since single user mode doesn't imply network support. The undocumented brave way 'make installkernel installworld && reboot' works also, without any problems. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:23:56 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6EF106566B; Tue, 20 Dec 2011 19:23:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id AE73C8FC1B; Tue, 20 Dec 2011 19:23:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJNshl071360; Tue, 20 Dec 2011 23:23:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJNsYd071359; Tue, 20 Dec 2011 23:23:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:23:54 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <20111220192354.GB70684@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111220165134.GA68792@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-current , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:23:56 -0000 Brooks, On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote: B> We almost certainly need to back r228571 out. This is not an acceptable B> upgrade path that would be acceptable historically. Specially, we have B> effectively promised users that an X.Y world will work on an X+1.0 B> kernel for most of history. There are obvious exceptions to this, but B> we have never allowed ifconfig to be one of them (I broke it many years B> ago with my first attempt to add if_epoch to if_data and had to back B> that out). Pardon, where did we promise that? The applications in jail should work, but not kernel configuration tools. The network facilities like ipfw and pf has changed their ABI numerous times, making a new kernel with older world inaccessible via network after boot. Considering r228571: we need to specify vhid as additional address attribute in atomic manner, via one ioctl(). Address can't be first configured, and then made redundant, that would lead it to being static for a short period, sending gratutious ARP announcement, etc. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:25:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01DA6106566B; Tue, 20 Dec 2011 19:25:21 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6E38FC14; Tue, 20 Dec 2011 19:25:20 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJPJ06071382; Tue, 20 Dec 2011 23:25:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJPJNs071381; Tue, 20 Dec 2011 23:25:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:25:19 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <20111220192519.GC70684@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <20111220192354.GB70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111220192354.GB70684@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:25:21 -0000 T> An assumption that we are not allowed to change ABI for our own tools T> strongly discourages bringing in new features :( P.S. Quoting documentation: "The old world might not run correctly on the new kernel, so you must install the new world immediately upon installing the new kernel." http://www.freebsd.org/doc/en/books/handbook/makeworld.html -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:31:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8AAD106564A; Tue, 20 Dec 2011 19:31:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 537DD8FC13; Tue, 20 Dec 2011 19:31:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJVe5Z071432; Tue, 20 Dec 2011 23:31:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJVeQC071431; Tue, 20 Dec 2011 23:31:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:31:40 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20111220193139.GD70684@FreeBSD.org> References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> <201112200900.39087.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <201112200900.39087.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, Rick Macklem Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:31:42 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=koi8-r Content-Disposition: inline John, On Tue, Dec 20, 2011 at 09:00:39AM -0500, John Baldwin wrote: J> In general the caller of crdup is expected to hold a reference on cred or some J> other lock to ensure that cred remains valid and cannot be free'd while it is J> being duplicated. There is no global lock that crdup can hold for that, J> instead the caller is required to guarantee that. I already noticed to Rick in a private email, that there is suspisious place in new NFS, where newly allocated (via crdup) cred is temporarily placed on td_ucred, and then removed at the end of function. The function may sleep in malloc() and also block on mutexes. I suspect, that it may happen, that some other kernel facility performs crfree(td->td_ucred), and later on we are using already freed cred. However, I can't imagine which facility may do this. What if process gets SIGKILL while its thread is blocked on mutex or sleeping? Would it be reaped after it yields or before? Attached patch demonstrates what I am trying to address, but I'm not sure that this temporary placing on td_ucred is really unsafe. Can you please look at this? -- Totus tuus, Glebius. --FCuugMFkClbJLl1L Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="nfs_cred.diff" Index: nfs_commonkrpc.c =================================================================== --- nfs_commonkrpc.c (revision 228700) +++ nfs_commonkrpc.c (working copy) @@ -186,9 +186,9 @@ * Use the credential in nr_cred, if not NULL. */ if (nrp->nr_cred != NULL) - td->td_ucred = nrp->nr_cred; + td->td_ucred = NFSHOLDCRED(nrp->nr_cred); else - td->td_ucred = cred; + td->td_ucred = NFSHOLDCRED(cred); saddr = nrp->nr_nam; if (saddr->sa_family == AF_INET) @@ -220,10 +220,8 @@ saddr = NFSSOCKADDR(nrp->nr_nam, struct sockaddr *); error = socreate(saddr->sa_family, &so, nrp->nr_sotype, nrp->nr_soproto, td->td_ucred, td); - if (error) { - td->td_ucred = origcred; + if (error) goto out; - } do { if (error != 0 && pktscale > 2) pktscale--; @@ -251,10 +249,8 @@ error = soreserve(so, sndreserve, rcvreserve); } while (error != 0 && pktscale > 2); soclose(so); - if (error) { - td->td_ucred = origcred; + if (error) goto out; - } client = clnt_reconnect_create(nconf, saddr, nrp->nr_prog, nrp->nr_vers, sndreserve, rcvreserve); @@ -305,10 +301,11 @@ mtx_unlock(&nrp->nr_mtx); } +out: /* Restore current thread's credentials. */ + NFSFREECRED(td->td_ucred); td->td_ucred = origcred; -out: NFSEXITCODE(error); return (error); } Index: nfsport.h =================================================================== --- nfsport.h (revision 228700) +++ nfsport.h (working copy) @@ -515,6 +515,7 @@ #define NFSNEWCRED(c) (crdup(c)) #define NFSPROCCRED(p) ((p)->td_ucred) #define NFSFREECRED(c) (crfree(c)) +#define NFSHOLDCRED(c) (crhold(c)) #define NFSUIOPROC(u, p) ((u)->uio_td = NULL) #define NFSPROCP(p) ((p)->td_proc) --FCuugMFkClbJLl1L-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:31:43 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7AE8106564A; Tue, 20 Dec 2011 19:31:43 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 990998FC17; Tue, 20 Dec 2011 19:31:41 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pBKJUYJS079917; Tue, 20 Dec 2011 13:30:34 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pBKJUYQj079916; Tue, 20 Dec 2011 13:30:34 -0600 (CST) (envelope-from brooks) Date: Tue, 20 Dec 2011 13:30:34 -0600 From: Brooks Davis To: "Bjoern A. Zeeb" Message-ID: <20111220193034.GC68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline In-Reply-To: <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Gleb Smirnoff Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:31:44 -0000 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 06:48:40PM +0000, Bjoern A. Zeeb wrote: > On 20. Dec 2011, at 16:51 , Brooks Davis wrote: >=20 > > On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: > >> On 2011-12-20 09:38, Doug Barton wrote: > >> ... > >>> I tried replacing both ifconfig and dhclient with the versions that w= ere > >>> built along with the new kernel, and that didn't work. > >>=20 > >> Looking at the changes in r228571, it seems they also affect libc, so > >> installing that is probably also needed. Since all my test systems are > >> already upgraded to post-r228571, can somebody please confirm it works > >> after doing: > >>=20 > >> make -C $srcdir/lib/libc install > >> make -C $srcdir/sbin/dhclient install > >> make -C $srcdir/sbin/ifconfig install > >=20 >=20 > Depends on what you are trying to achieve. There is more software affect= ed. >=20 > > We almost certainly need to back r228571 out. This is not an acceptable > > upgrade path that would be acceptable historically. Specially, we have > > effectively promised users that an X.Y world will work on an X+1.0 >=20 > I am not sure we supported that but X. to X+1.Y maybe? That's the guarantee we've advertised, but the breakage we've supported has mostly been for more narrowly focused tools that grovel around in KVM space. We've usually allowed an old world to work with only a few shims (ps for instance). Adding a new ifconfig to the list would be an expansion there. I also worry about the problem that once you've installed world there is no easy way back. > > kernel for most of history. There are obvious exceptions to this, but > > we have never allowed ifconfig to be one of them (I broke it many years > > ago with my first attempt to add if_epoch to if_data and had to back > > that out). >=20 > There is a couple of issues here. >=20 > The one that's on me is struct ifa_msghdr / getifaddrs() and the problem = here > is that software incl. getifaddrs() doesn't use the in structs embedded l= engths > in first place. In if_data only a spare was reused, so no changes there. > That's certainly something we can and should fix in 9 before 10.0 will ha= ppen. > If that was the problem back then, it's certainly a pity it wasn't fixed = as > we wouldn't have that problem these days then. It would allow appending = more > stuff. It would nice to fix, but allowing append to if_data means reving the routing socket API. I looked at it a bit and then gave up because there were too many consumers (many out of tree), pretty much all of which ignore the version number. I didn't have time to rev the whole API which is probably where the bar is for breaking the API. > For the appended int to ifaliasreq, in_aliasreq, in6_aliasreq I haven't > looked at the actual problem in the upgrade paths. I guess it's not much > outside of ifconfig and probably ppp at least for the in_ in6_ variants. Those many have few enough consumers that we can come up with a reasonable path forward. > Backing r228571 out completely will be harder with every change glebius c= ommits > on top. So if we think it'll be needed we should stop those commits now = and > think first. >=20 > Just breaking carp and backing out the user space API parts is only a usa= ble > path with a plan B on how to fix carp as well in the same go really. >=20 > Ingoring 9.0 -> 10-CURRENT or an update on HEAD (neither of which is not a > normal user upgrade path an supported) I am still wondering how much of t= hat > can be mitigated and if it might make sense to ponder that direction (also > for further future changes for sure to happen) to not be stuck forever? > I fear we'll see/want to do more of these kinds as more people look at the > if/ll layer... If we can identify all the changed interfaces and we can teach 9-STABLE to deal with them then this change is probably OK and we just need to do the appropriate libc and ifconfig spackling and merge it. We can't let this slide too long though because the current state requires an installkernel+installworld for all intents and purposes and that means that if the kernel is broken you are dead in the water. I agree we could really use some sort of way forward that increases our abilty to make these sorts of changes. - Brooks > /bz >=20 > --=20 > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. >=20 --4ZLFUWh1odzi/v6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8OJZXY6L6fI4GtQRAtqsAKCPlHGT7HmRos6MCvew0YgQFoKkyACfa10D O3dKBTHnoiMqlCSHkPjdcRw= =Fzh4 -----END PGP SIGNATURE----- --4ZLFUWh1odzi/v6L-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:35:18 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AFA106566B; Tue, 20 Dec 2011 19:35:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B315E8FC15; Tue, 20 Dec 2011 19:35:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJZGCx071505; Tue, 20 Dec 2011 23:35:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJZGmb071504; Tue, 20 Dec 2011 23:35:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:35:16 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <20111220193516.GE70684@glebius.int.ru> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> <20111220193034.GC68792@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111220193034.GC68792@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , "Bjoern A. Zeeb" Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:35:18 -0000 On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote: B> I also worry about the problem that once you've installed world there is B> no easy way back. When working on the patch for last months I did numerous 'make installkernel installworld' switching between a patched sources and unpatched, and everything goes fine. B> If we can identify all the changed interfaces and we can teach 9-STABLE B> to deal with them then this change is probably OK and we just need to B> do the appropriate libc and ifconfig spackling and merge it. We can't B> let this slide too long though because the current state requires an B> installkernel+installworld for all intents and purposes and that means B> that if the kernel is broken you are dead in the water. B> B> I agree we could really use some sort of way forward that increases our B> abilty to make these sorts of changes. Why 9-STABLE? This change isn't going to be merged. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:39:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41AD8106566B for ; Tue, 20 Dec 2011 19:39:22 +0000 (UTC) (envelope-from io.chir0n@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDAD98FC1C for ; Tue, 20 Dec 2011 19:39:21 +0000 (UTC) Received: by ghrr16 with SMTP id r16so1393202ghr.13 for ; Tue, 20 Dec 2011 11:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=PzfbowD9iF6omf1390W8sPeNneJUisTLAhpBTwwxRFo=; b=dySM+G21clXmMYw4Si78xKPN18B/NUZt9ZYsL/sgLXVjjeXh6Eb+T7d4iBd7OCRLwX 4PyaJ+rRX/NGBDv7/n3bSslqMu+BuI6M9mDUTArYORGRT9lwD5WwpRNLD63SRKsdB4bU 364T1/9uFUKYiVraBGcVkd0GTK1CzOdbgypQI= Received: by 10.101.127.1 with SMTP id e1mr1857244ann.42.1324409961095; Tue, 20 Dec 2011 11:39:21 -0800 (PST) Received: from [192.168.0.41] ([201.22.249.146]) by mx.google.com with ESMTPS id l11sm7722066anm.22.2011.12.20.11.39.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 11:39:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: Chiron IO In-Reply-To: Date: Tue, 20 Dec 2011 17:40:10 -0200 Message-Id: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <6140271.20111219122721@serebryakov.spb.ru> <4EEF3FF9.7070307@digsys.bg> <28E4047A-356A-4CCE-A134-9B24A7444806@gmail.com> To: Samuel J. Greear X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:39:22 -0000 http://wiki.freebsd.org/DefaultDebuggingKnobs I am not aware of any linux distribution that comes with debug enabled = by default, even on RC releases. It seems that this approach (debug by default) is welcome to help solve = problems that might appear, but I would be happy if these benchmarks = were made without such config (debug) enabled. On 20/12/2011, at 17:09, Samuel J. Greear wrote: > On Tue, Dec 20, 2011 at 4:28 AM, Chiron IO = wrote: > Guys, >=20 > I have a question about these benchmarks. >=20 > Why worry about that if the CURRENT comes with debug enabled by = default? >=20 > = http://joaobarros.blogspot.com/2005/07/freebsd-how-to-turn-off-debug-optio= ns.html >=20 >=20 >=20 > In the real world problems happen and someone has to be able to, in = some fashion, identify and resolve those problems. As such, shipping = FreeBSD releases with INVARIANTS disabled is a mistake and any = benchmarks done without INVARIANTS enabled will fail to reflect most = reasonable real world use-cases. >=20 > Although these benchmarks cannot stand on their own merits for many = reasons, I do not see how any benchmark is automatically invalidated by = using the default development configuration. >=20 > Sam From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:46:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928EB106564A; Tue, 20 Dec 2011 19:46:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 427228FC08; Tue, 20 Dec 2011 19:46:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 547A525D37C7; Tue, 20 Dec 2011 19:46:15 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BC7BBBD76C0; Tue, 20 Dec 2011 19:46:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 02ptHUB9glV6; Tue, 20 Dec 2011 19:46:13 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 90FFABD76BF; Tue, 20 Dec 2011 19:46:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111220193516.GE70684@glebius.int.ru> Date: Tue, 20 Dec 2011 19:46:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5C93DF5B-B722-4FAF-8AD3-7918974C9A12@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> <20111220193034.GC68792@lor.one-eyed-alien.net> <20111220193516.GE70684@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) Cc: freebsd-current , Brooks Davis Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:46:16 -0000 On 20. Dec 2011, at 19:35 , Gleb Smirnoff wrote: > On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote: > B> I also worry about the problem that once you've installed world = there is > B> no easy way back. >=20 > When working on the patch for last months I did numerous 'make = installkernel > installworld' switching between a patched sources and unpatched, and = everything > goes fine. Yeah for the time being but we are talking about a 4-5 year timeframe. > B> If we can identify all the changed interfaces and we can teach = 9-STABLE > B> to deal with them then this change is probably OK and we just need = to > B> do the appropriate libc and ifconfig spackling and merge it. We = can't > B> let this slide too long though because the current state requires = an > B> installkernel+installworld for all intents and purposes and that = means > B> that if the kernel is broken you are dead in the water. > B>=20 > B> I agree we could really use some sort of way forward that increases = our > B> abilty to make these sorts of changes. >=20 > Why 9-STABLE? This change isn't going to be merged. Because we'd need to make sure that "fixes" go backward to work with the new stuff for the update path - the "fixes", not your change. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 20:43:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA6B106566B; Tue, 20 Dec 2011 20:43:13 +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 A17BF8FC12; Tue, 20 Dec 2011 20:43:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA07645; Tue, 20 Dec 2011 22:43:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rd6Wg-000Jdg-W2; Tue, 20 Dec 2011 22:43:07 +0200 Message-ID: <4EF0F359.3090008@FreeBSD.org> Date: Tue, 20 Dec 2011 22:43:05 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EF088C8.8090906@FreeBSD.org> <4EF0A6D4.2020107@FreeBSD.org> <201112201741.18428.hselasky@c2i.net> In-Reply-To: <201112201741.18428.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-usb@FreeBSD.org Subject: Re: ukbd locking update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:43:13 -0000 on 20/12/2011 18:41 Hans Petter Selasky said the following: > On Tuesday 20 December 2011 16:16:36 Andriy Gapon wrote: >> And the new patch: >> http://people.freebsd.org/~avg/usb.new.diff > > Patch looks OK. I will give it a spin later today. Feel free to commit if > you've tested the three use-cases I listed in a previous e-mail. Thank you for the quick review. My tests were all successful, including those 3 scenarios. Please let me know if you have any questions and how your testing goes. I will try to commit this tomorrow morning. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 20:48:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D4EC106564A; Tue, 20 Dec 2011 20:48:14 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BFA2C8FC1A; Tue, 20 Dec 2011 20:48:13 +0000 (UTC) Received: by pbcc3 with SMTP id c3so5312078pbc.13 for ; Tue, 20 Dec 2011 12:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/CaEm1Px9Ljrz2CxJ7e4Ko5mcSwakpZcL4rqV3nij4w=; b=WUGe0HQf5q8d5HsXXUv7p7CZiDfulGL/J15RyvgOb+XcguAgWqrHEPNkyE5k9vk+rJ PYyA6UmVhYcuyVD2nC1OFMj9IdocI0SZCEb/HEUTdt5Ex7YBDOfnu1k2pSBnJg48KMGn J4XcYq6WKyd+BnYlYWruu3OSFmtNVrpRGjjPg= Received: by 10.68.74.98 with SMTP id s2mr5591159pbv.46.1324412493178; Tue, 20 Dec 2011 12:21:33 -0800 (PST) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.68.51.133 with HTTP; Tue, 20 Dec 2011 12:20:52 -0800 (PST) In-Reply-To: <4EE9A2A0.80607@zedat.fu-berlin.de> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> From: Igor Mozolevsky Date: Tue, 20 Dec 2011 20:20:52 +0000 X-Google-Sender-Auth: sq1TBiXB5HA-vy4_GqUuXWzzqyM Message-ID: To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:48:14 -0000 Interestingly, while people seem to be (arguably rightly) focused on criticising Phoronix's benchmarking, nobody has offered an alternative benchmark; and while (again, arguably rightly) it is important to benchmark real world performance, equally, nobody has offered any numbers in relation to, for example, HTTP or SMTP, or any other "real world"-application torture tests done on the aforementioned two platforms... IMO, this just goes to show that "doing is hard" and "criticising is much easier" (yes, I am aware of the irony involved in making this statement, but someone has to!) Cheers, Igor M :-) From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 20:54:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E142B1065672; Tue, 20 Dec 2011 20:54:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B354E8FC19; Tue, 20 Dec 2011 20:54:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5005346B0D; Tue, 20 Dec 2011 15:54:52 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB180B91A; Tue, 20 Dec 2011 15:54:51 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Tue, 20 Dec 2011 15:54:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> <201112200900.39087.jhb@freebsd.org> <20111220193139.GD70684@FreeBSD.org> In-Reply-To: <20111220193139.GD70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112201554.51120.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 15:54:51 -0500 (EST) Cc: freebsd-current@freebsd.org, Rick Macklem Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:54:53 -0000 On Tuesday, December 20, 2011 2:31:40 pm Gleb Smirnoff wrote: > John, > > On Tue, Dec 20, 2011 at 09:00:39AM -0500, John Baldwin wrote: > J> In general the caller of crdup is expected to hold a reference on cred or some > J> other lock to ensure that cred remains valid and cannot be free'd while it is > J> being duplicated. There is no global lock that crdup can hold for that, > J> instead the caller is required to guarantee that. > > I already noticed to Rick in a private email, that there is suspisious > place in new NFS, where newly allocated (via crdup) cred is temporarily > placed on td_ucred, and then removed at the end of function. The function > may sleep in malloc() and also block on mutexes. None of that matters. Only curthread touches td_ucred. It isn't going to free its own credential while it is asleep. :) > I suspect, that it may happen, that some other kernel facility performs > crfree(td->td_ucred), and later on we are using already freed cred. > > However, I can't imagine which facility may do this. What if process gets > SIGKILL while its thread is blocked on mutex or sleeping? Would it > be reaped after it yields or before? No, a signal is merely marked as pending. It isn't delivered to a thread in the kernel until it exits back out of the kernel and prepares to return to userland (e.g. in userret()). Only at that time will the thread actually be killed. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 21:39:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60458106566B; Tue, 20 Dec 2011 21:39:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 02F7F8FC17; Tue, 20 Dec 2011 21:39:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rd7P8-0003XO-F9>; Tue, 20 Dec 2011 22:39:22 +0100 Received: from e178016253.adsl.alicedsl.de ([85.178.16.253] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rd7P8-0004Ye-9D>; Tue, 20 Dec 2011 22:39:22 +0100 Message-ID: <4EF10088.1010409@zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 22:39:20 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Igor Mozolevsky References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8C1553888582332653719232" X-Originating-IP: 85.178.16.253 Cc: freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 21:39:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C1553888582332653719232 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/20/11 21:20, Igor Mozolevsky wrote: > Interestingly, while people seem to be (arguably rightly) focused on > criticising Phoronix's benchmarking, nobody has offered an alternative > benchmark; and while (again, arguably rightly) it is important to > benchmark real world performance, equally, nobody has offered any > numbers in relation to, for example, HTTP or SMTP, or any other "real > world"-application torture tests done on the aforementioned two > platforms... IMO, this just goes to show that "doing is hard" and > "criticising is much easier" (yes, I am aware of the irony involved in > making this statement, but someone has to!) >=20 >=20 > Cheers, > Igor M :-) Unfortunately, M. Larabel is the only one who's performing benchmarks on FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, there is a lot of criticism, but no alternative. I said unfortunately - not offensive - since Larabel and Phoronix are sadly the only ones who do actually such bechmarking. It would be much more nicer and kind to support those people. Well, in January/February we get new hardware. One box is supposed to do number crunching via 12 cores and a TESLA GPU. My colleague is developing a high parallelized peice of software for satellite data transformation. The software package is CPU bound, partially GPU, but massively memory hungry (96 to 128 GB RAM is needed). What I can offer is, since I will also work on that machine and I've free hand to administer, in the spare time of doing my PhD, installing FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS data storage drive for homes, so both systems can perform on a most recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional programmer/developer. My skills are sufficient for the daily scientific work. So, without pressure, I'm willing to perform some HPC benchmarks under advice if the day comes and those interested in bare numbers of FreeBSD vs. Linux performance with a real-world-scientific application. I would appreciate to see some of the developers and/or FreeBSD hackers to help Phoronix setting up a proper testenvironment instead of bashing M. Larabel and his fellows. Regards, Oliver --------------enig8C1553888582332653719232 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO8QCJAAoJEOgBcD7A/5N8EoQIAMj9hcl5dL2gB5V7lkebJIWI hrxXPCISgYoRq3nLa/YbH+Ub532VB4t6ftfI+C6UE5/3/NBFujnI9My5bV9Xnys6 +yUbzdxY7t9SRujf8rhg8JpwwgUySwhMa4v9pnefUML9Pi+fN2U35ZjDCWFbFlpS IRfcsueq4OgKr9PWa06eeZmlbp2AYoKsnlV+bM1TvI4pDAvpqgHkzci526h/TzAc gbPhw+Wjn/JvH7ZWxKnF3pG8U+zAuOSI0g7JC6wy59O71UJEpEiEVwAvmv/dFDgx 61GvOy0cZ/zLMkN0ag7D8Zy/1byNnaIa7Rli42bJV8Ho3SRp7joYrBryf2L3J2Q= =6hh+ -----END PGP SIGNATURE----- --------------enig8C1553888582332653719232-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 21:43:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AB1D1065688; Tue, 20 Dec 2011 21:43:53 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E89AA8FC16; Tue, 20 Dec 2011 21:43:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rd7TU-0003zE-45>; Tue, 20 Dec 2011 22:43:52 +0100 Received: from e178016253.adsl.alicedsl.de ([85.178.16.253] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rd7TT-0004lg-VV>; Tue, 20 Dec 2011 22:43:52 +0100 Message-ID: <4EF10197.9040207@zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 22:43:51 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Robert Watson References: <4EED2F1C.2060409@zedat.fu-berlin.de> <20111217204514.2fa77ea2@kan.dyndns.org> <201112200852.23300.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20A5A43AF2403D4621E827F7" X-Originating-IP: 85.178.16.253 Cc: Attilio Rao , mdf@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 21:43:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20A5A43AF2403D4621E827F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/20/11 16:55, Robert Watson wrote: > On Tue, 20 Dec 2011, Attilio Rao wrote: >=20 >> As we are here, however, I have a question for Robert here: do you >> think we should support the _ddb() variant of options even in the case= >> DDB is not enabled in the kernel? >=20 > It's possible that _ddb() should be spelled _unlocked(), or perhaps > _debug(), but neither really suggests what the name should actually > imply: using it is safe only in a marginal (debugging) sense, and not i= n > a production code sense. One might also reasonable call them > stack_foo_dontusethis(). >=20 > The _ddb() variants are used in at least two not strictly DDB cases: > redzone support, and Solaris memory allocation. And, I guess, the > current lock debugging case that we're talking about now, but I'm not > sure if those debugging features specifically require DDB in the kernel= > themselves? >=20 > Robert Sorry, I have to come back to the topic of my hijacked thread ;-) I realized that the problem occured when I enabled, just for fun, some features in the kernel config file, in particular were these device ipmi device smbios device vdp device tpm My box in question does not have any IPMI facility, nor does it have a TPM chip or vdp. So I commented out vdp and tpm and the problem seems to be gone. I didn't find any manpage for smbios, the NOTES in amd64 says, it is for DMI informations, but dmidecide works also without explicitely enabling smbios in the kernel. If someone wish that I have to perform another try with those modules enabled, let me know. oh --------------enig20A5A43AF2403D4621E827F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO8QGXAAoJEOgBcD7A/5N8u9sH/3sK9pN1sIdX8w36eYS5uxrH zWznFtLNuguwYDynDlihC8nYeU5rYnZPu5VVT+FQVvKjJqcMLLAC/HRPsHNp9Xtn oeM6JTxf+iTaKA6XSFfxoVMPlQVjnzKud2W3ovZQHTYXGT7vZp+YKX4atjrFB+HI fnGC2z4ZW52qDjd5gl4CgvmBRek4LvV665DX1C0N+AcBwc+k0dDtd1IdgLtecFus 73C5aAcOxUMa6HfzCrW/eBT3wCg28HBxM2FGYObnJ1Mq4JzUXxs2csde+0+Q+fF5 b2W1cYHoSvfpZpu9ME/uN6V1Tsw3x+PGVw3dQtSWBknoctlkKOy1SAvZLegngX4= =PzsA -----END PGP SIGNATURE----- --------------enig20A5A43AF2403D4621E827F7-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 21:49:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8CE91065672; Tue, 20 Dec 2011 21:49:07 +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 BECCB8FC08; Tue, 20 Dec 2011 21:49:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7516E46B2A; Tue, 20 Dec 2011 16:49:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0AEB3B93A; Tue, 20 Dec 2011 16:49:07 -0500 (EST) From: John Baldwin To: Robert Watson Date: Tue, 20 Dec 2011 16:49:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112201649.06265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 16:49:07 -0500 (EST) Cc: current@freebsd.org Subject: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 21:49:08 -0000 Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 21:45:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8AC21065670; Tue, 20 Dec 2011 21:45:54 +0000 (UTC) (envelope-from sjg@evilcode.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5863C8FC19; Tue, 20 Dec 2011 21:45:54 +0000 (UTC) Received: by qcse13 with SMTP id e13so5904734qcs.13 for ; Tue, 20 Dec 2011 13:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.205.134 with SMTP id fq6mr5166209qab.99.1324417553722; Tue, 20 Dec 2011 13:45:53 -0800 (PST) Received: by 10.229.6.142 with HTTP; Tue, 20 Dec 2011 13:45:53 -0800 (PST) In-Reply-To: References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 14:45:53 -0700 Message-ID: From: "Samuel J. Greear" To: Igor Mozolevsky X-Mailman-Approved-At: Tue, 20 Dec 2011 22:12:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Mailing List , freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 21:45:55 -0000 http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux and Solaris. Steps to reproduce these benchmarks provided. Sam On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky wrote: > Interestingly, while people seem to be (arguably rightly) focused on > criticising Phoronix's benchmarking, nobody has offered an alternative > benchmark; and while (again, arguably rightly) it is important to > benchmark real world performance, equally, nobody has offered any > numbers in relation to, for example, HTTP or SMTP, or any other "real > world"-application torture tests done on the aforementioned two > platforms... IMO, this just goes to show that "doing is hard" and > "criticising is much easier" (yes, I am aware of the irony involved in > making this statement, but someone has to!) > > > Cheers, > Igor M :-) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 22:22:57 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1657106564A; Tue, 20 Dec 2011 22:22:57 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 642328FC0A; Tue, 20 Dec 2011 22:22:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBKMMvZ7024837; Tue, 20 Dec 2011 22:22:57 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBKMMvLx024836; Tue, 20 Dec 2011 22:22:57 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:22:53 +0100 From: Baptiste Daroussin To: Alexander Yerenkow Message-ID: <20111220222253.GC55364@azathoth.lan> References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-current Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:22:57 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2011 at 10:31:51PM +0200, Alexander Yerenkow wrote: > 2011/12/19 Adrian Chadd >=20 > > Hi, > > > > Hm, so this lets us create a virtualbox image from what, a set of > > install tarballs? Or /usr/src build? > > > > I'm using cross-build and installation from sources dir (which is after > that got svn-up'ed and all goes again). > It shouldn't be complex to install to image from installation media and/or > tarballs, but mine main idea is to have rolling image for making some > automated tests. > Currently I'm establishing building and providing images scheme, will do > images with KMS+small graphical programs, with qt+unstable KDE, and > probably with BHyVe. I think that's most useful setups currently. And may= be > some image for benchmarking :) >=20 >=20 FYI I have been working on a ova file generator for the release, I manage to create ova images that do work on VirtualBox without problems, there are st= ill some problems with vmware for now, the goal is to have a standard vm ready = image (ova is standard) that would work on every system that do support it. the image can be easily created from the release. regards, Bapt --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7xCr0ACgkQ8kTtMUmk6ExTLgCfWMo6gBe+wjpNhnqFN9Xb8kKD 1AYAn3ntS1hYClnioKgSo2E7sT3pxOJF =fChJ -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 22:44:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92F681065675 for ; Tue, 20 Dec 2011 22:44:58 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68E578FC0C for ; Tue, 20 Dec 2011 22:44:58 +0000 (UTC) Received: by pbcc3 with SMTP id c3so5384283pbc.13 for ; Tue, 20 Dec 2011 14:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9+0yvq1Xq7oGlhY7rWhTUclRGlw+yyWi+L3TTCz9aXc=; b=WGzDojvab81lifekKtlmNs6qq40bcvYrhEzTdNua1JuXw5xappXVUg0bMbRd2aFlQe ENOwXp6Q/nmo1l9AYTGxrk3EuMHh1U/yKXq7iwZSSRXAcbulvCzymLc9JZk3vqHlmB+k NlNWBgaU0rpdeo3b6WjW/9LXT08chAHCUtpHI= MIME-Version: 1.0 Received: by 10.68.213.41 with SMTP id np9mr6295989pbc.71.1324419538520; Tue, 20 Dec 2011 14:18:58 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.136 with HTTP; Tue, 20 Dec 2011 14:18:58 -0800 (PST) In-Reply-To: <201112201649.06265.jhb@freebsd.org> References: <201112201649.06265.jhb@freebsd.org> Date: Tue, 20 Dec 2011 14:18:58 -0800 X-Google-Sender-Auth: ywbe_POGLVZUiOxaacEltPOAQxY Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:44:58 -0000 On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > Hmm, if these functions are expected to operate like 'write(2)' and are > supposed to return the number of bytes written, shouldn't their return va= lue > be 'ssize_t' instead of 'int'? =A0It looks like the system calls themselv= es > already do the right thing in setting td_retval[] (they assign a ssize_t = to it > and td_retval[0] can hold a ssize_t on all of our current platforms). =A0= It > would seem that the only change would be to the header and probably > syscalls.master. =A0I guess this would require a symver bump to fix thoug= h. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 22:54:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA5A106566B; Tue, 20 Dec 2011 22:54:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 81BE08FC08; Tue, 20 Dec 2011 22:54:26 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rd8Zl-0002HE-1k>; Tue, 20 Dec 2011 23:54:25 +0100 Received: from e178016253.adsl.alicedsl.de ([85.178.16.253] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rd8Zk-0008C4-Pd>; Tue, 20 Dec 2011 23:54:25 +0100 Message-ID: <4EF1121F.9010209@zedat.fu-berlin.de> Date: Tue, 20 Dec 2011 23:54:23 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: "Samuel J. Greear" References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1D490B63A11258175672D7F" X-Originating-IP: 85.178.16.253 Cc: freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:54:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1D490B63A11258175672D7F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/20/11 22:45, Samuel J. Greear wrote: > http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Signific= antly_Improved >=20 > PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Lin= ux > and Solaris. Steps to reproduce these benchmarks provided. >=20 > Sam >=20 > On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky wrote: >=20 >> Interestingly, while people seem to be (arguably rightly) focused on >> criticising Phoronix's benchmarking, nobody has offered an alternative= >> benchmark; and while (again, arguably rightly) it is important to >> benchmark real world performance, equally, nobody has offered any >> numbers in relation to, for example, HTTP or SMTP, or any other "real >> world"-application torture tests done on the aforementioned two >> platforms... IMO, this just goes to show that "doing is hard" and >> "criticising is much easier" (yes, I am aware of the irony involved in= >> making this statement, but someone has to!) >> >> >> Cheers, >> Igor M :-) >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> Thanks for those numbers. Impressive how Matthew Dillon's project jumps forward now. And it is still impressive to see that the picture is still in the right place when it comes to a comparison to Linux. Also, OpenIndiana shows an impressive performance. But this is only one suite of testing. Scientific Linux is supposed to give the best performance for scientifi purposes, i.e. for longhaul calculations, much numerical stuff. It outperforms in a typical server application FreeBSd, were "FreeBSD shoulkd have the power to serve". Is the postgresql benchmark the only way to benchmark? Well, this inspires me to gather together all the benchmarks someone could find. There were lots of compalins about FreeBSD's poor performance with BIND - once a domain of FreeBSD. Network performance seems also to be an issue if it comes to scalability. It would be nice to see what portion of the raw CPU/GPU power the OS (FreeBSD, Linux ...) delivers to scientific applications. I only know some kind of benchmarks, BYTE UNIX benchmark, LINPACK test =2E.. Does someone know a site to look for a couple of benchmarks to test= a) memory system b) scalability (apart from pgbench) c) network performance/throughput/network scalability d) portion of CPU performance the system delivers for numerical applications to the user apart from the system's own consumption e) disk I/O performance and scalability it would also be nice to discuss some nice settings and performance tunings for FreeBSD for several scenarios. I guess, starting developing benchmarking test scenarios for several purposes would lead faster to real numbers and non polemic than weird discussions ... --------------enigB1D490B63A11258175672D7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO8RIfAAoJEOgBcD7A/5N8dhQIANomh6qezYWsQVSYv3QYaLQR /ooQAaxCODCdunq3ZGmDl41YH3UTUvmOTpUoxTgSCeiycMRQW74DGm7mYHDb72hY 6PaxU2c5Ehh9bFT7TUsolZFHY0xHysHcQCpu9tqoj5hvuXAAZG6SO7PUxTDDyjAc VgWGaX3iYF0W3H1dNqYz4970Z1E1Zhb4X2rFvWkpPYEqinvNbwsz3YImeLCCVNVL r+nru3JMwwnu1XUSd7InYySbQFGW42YQ5hXwvc84NzbCR+pMGL3LYh9QIaZMlVtQ vgFjvMOSPWLCjJepq5jrMg7EiYUIRnTqVHDOJe4WgXxPzuzQq+s7UaMwEcabtWU= =8iuY -----END PGP SIGNATURE----- --------------enigB1D490B63A11258175672D7F-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 23:29:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A22F1065672 for ; Tue, 20 Dec 2011 23:29:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id DC1AE8FC15 for ; Tue, 20 Dec 2011 23:29:28 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id BbBu1i0031vXlb85DbVU9a; Tue, 20 Dec 2011 23:29:28 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id BbVT1i00c1t3BNj3dbVTkp; Tue, 20 Dec 2011 23:29:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DAF21102C19; Tue, 20 Dec 2011 15:29:25 -0800 (PST) Date: Tue, 20 Dec 2011 15:29:25 -0800 From: Jeremy Chadwick To: "O. Hartmann" Message-ID: <20111220232925.GA55953@icarus.home.lan> References: <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF1121F.9010209@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF1121F.9010209@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 20 Dec 2011 23:37:44 +0000 Cc: FreeBSD Stable Mailing List , freebsd-performance@freebsd.org, Current FreeBSD , "Samuel J. Greear" , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:29:29 -0000 On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote: > On 12/20/11 22:45, Samuel J. Greear wrote: > > http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved > > > > PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux > > and Solaris. Steps to reproduce these benchmarks provided. > > > > Sam > > > > On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky wrote: > > > >> Interestingly, while people seem to be (arguably rightly) focused on > >> criticising Phoronix's benchmarking, nobody has offered an alternative > >> benchmark; and while (again, arguably rightly) it is important to > >> benchmark real world performance, equally, nobody has offered any > >> numbers in relation to, for example, HTTP or SMTP, or any other "real > >> world"-application torture tests done on the aforementioned two > >> platforms... IMO, this just goes to show that "doing is hard" and > >> "criticising is much easier" (yes, I am aware of the irony involved in > >> making this statement, but someone has to!) > >> > >> > >> Cheers, > >> Igor M :-) > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> > > Thanks for those numbers. > Impressive how Matthew Dillon's project jumps forward now. And it is > still impressive to see that the picture is still in the right place > when it comes to a comparison to Linux. > Also, OpenIndiana shows an impressive performance. Preface to my long post below: The things being discussed here are benchmarks, as in "how much work can you get out of Thing". This is VERY DIFFERENT from testing interactivity in a scheduler, which is more of a test that says "when Thing X is executed while heavier-Thing Y is also being executed, how much interaction is lost in Thing X". The reason people notice this when using Xorg is because it's visual, in an environment where responsiveness is absolutely mandatory above all else. Nobody is going to put up with a system where during a buildworld they go to move a window or click a mouse button or type a key and find that the window doesn't move, the mouse click is lost, or the key typed has gone into the bit bucket -- or, that those things are SEVERELY delayed, to the point where interactivity is crap. I just want to make that clear to folks. This immense thread has been with regards to the latter -- bad interactivity/responsiveness on a system which was undergoing load that SHOULD be distributed "more evenly" across the system *while* keeping interactivity/responsiveness high. Historically nice/renice has been used for this task, but that was when kernels were a little less complex and I/O subsystems were less complex. Remember: we've now got schedulers for each type of thing, and who gets what priority? You get my point I'm sure. So remember: this was to discuss that aspect, with regards to ULE vs. 4BSD schedulers. Now, back to the benchmarks: This also interested me: * Linux system crashed http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html * OpenIndiana system crashed same way as Linux system http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html I cannot help but wonder if the Linux and OpenIndiana installations were more stressful on the hardware -- getting more out of the system, maybe resulting in increased power/load, which in turn resulted in the systems locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). My point is that Francois states these things in such a way to imply that "DragonflyBSD was more stable", when in fact I happen to wonder the opposite point -- that is to say, Linux and OpenIndiana were trying to use the hardware more-so than DragonflyBSD, thus tickled what may be a hardware-level problem. > But this is only one suite of testing. Scientific Linux is supposed to > give the best performance for scientifi purposes, i.e. for longhaul > calculations, much numerical stuff. It outperforms in a typical server > application FreeBSd, were "FreeBSD shoulkd have the power to serve". > > Is the postgresql benchmark the only way to benchmark? I sure hope not. But you know what's equally as interesting? This: http://people.freebsd.org/~kris/scaling/ Specifically circa 2008: http://people.freebsd.org/~kris/scaling/4cpu-pgsql.png http://people.freebsd.org/~kris/scaling/pgsql-16cpu-2.png http://people.freebsd.org/~kris/scaling/pgsql-16cpu.png Now, I don't know if what was used in those ("pgsql sysbench") was the same thing as "pg_bench" in the DragonflyBSD tests, but if so, the numbers are different to a point that is preposterous. There's also this: http://people.freebsd.org/~kris/scaling/pgsql-ncpu.png Now, compare those numbers to the TPS numbers shown here: http://dl.wolfpond.org/Pg-benchmarks.pdf So um... yeah. Now, if someone here is going to say "well, what was tested by Kris was FreeBSD 7.0, while what was tested by Francois was FreeBSD 9.0, and there have been improvements", then I ask that someone show me where the improvements are that would exhibit a 4-8x performance increase in some cases. This rambling of mine is the same rambling I posted earlier in this thread. There needs to be a consistent, standardised way of testing this stuff. Every system tested tuned the exact same way, software configured the same way, absolutely no quirks applied, etc.. Otherwise we end up with "mixed results" as shown above. Much to the disapproval of others, the Phoronix test suite is supposed to be that "standard". Meaning, it's a suite you're supposed to be able to install and thus ensures that, aside from compiler used and any system tests, that the same code is being used regardless of what system and OS it's on. Have I ever used it? No. And it's important that I admit that up front, because being honest is necessary. > Well, this inspires me to gather together all the benchmarks someone > could find. There were lots of compalins about FreeBSD's poor > performance with BIND - once a domain of FreeBSD. Network performance > seems also to be an issue if it comes to scalability. > It would be nice to see what portion of the raw CPU/GPU power the OS > (FreeBSD, Linux ...) delivers to scientific applications. Kris Kenneway's "BIND benchmark" that was released a long time ago touched base on this. Remember: these plots show nothing other than number of queries per second correlated with number of DNS server threads (since BIND does have a 1:1 thread-to-CPU creation ratio): http://people.freebsd.org/~kris/scaling/bind-pt.png http://people.freebsd.org/~kris/scaling/bind-pt-2.png http://people.freebsd.org/~kris/scaling/bind-pt-gige.png > I only know some kind of benchmarks, BYTE UNIX benchmark, LINPACK test > ... Does someone know a site to look for a couple of benchmarks to test > > a) memory system > b) scalability (apart from pgbench) > c) network performance/throughput/network scalability > d) portion of CPU performance the system delivers for numerical > applications to the user apart from the system's own consumption > e) disk I/O performance and scalability > > it would also be nice to discuss some nice settings and performance > tunings for FreeBSD for several scenarios. I guess, starting developing > benchmarking test scenarios for several purposes would lead faster to > real numbers and non polemic than weird discussions ... All I wish is that we had some kind of "test suite" of our own, maybe as a port, maybe in the base system, which could really help with all of this. Something consistent. Now I'm switching back to discussing interactivity/responsiveness tests: Attilio Rao did comment in this thread to me, giving me some test methodologies for testing interactivity during two types of simultaneous loads -- but one involves dnetc, which I imagine means I'd need to get familiar with that whole thing. http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064936.html I haven't responded to his post yet (this thread is so long and tedious that I'm having serious problems following it + remembering all the details -- am I the only one who feels daunted by this? God I hope not), but his insights are, as always, beneficial, but also overwhelming. Furthermore, I do not have 16-core or 24-core systems to test on -- I have single-CPU, quad-core and dual-core systems to test on. I am a firm believer these are going to make up the majority of the FreeBSD userbase (desktop and server environments). Extreme hardware (e.g. quad CPU with 12 cores per CPU) can be tested too, but let's at least pick a demographic to start with. Again: the FreeBSD users and administrative community want to help. All of us do. We just need to know exactly what we should be doing to test, and what exactly we're testing for. I'll be blunt while choosing to play the Idiot Admin for a moment: I'd be much happier if someone had a tarball of shell scripts and things which could be used to test these things. Lots of things need to be kept in mind, such as if someone is running the "client" test on the same box as the "server" test, and things like "the test data is written to a local filesystem, with echo/printf statements constantly flushed" (great, now we're causing I/O load on top of our tests!), which to me means we should probably be using something like mdconfig(8) to create a temporary filesystem to store logs/data results. The KTR stuff Atillio and many others have requested, I think, will be the most beneficial way to get the developers the data they need. I had no idea about it until I found out that KTR was something completely different than ktrace. I still haven't found the time to do all of this, BTW, and for that I apologise. The reason has to do with time at work + personal desire to do it. When I get a daunting task, I tend to get... well, not depressed, but "scared" of the massive undertaking since it involves lots of recurring tests, reboots, etc. -- hours of work -- and if I get that wrong, it's wasted effort (thus wasted developer time). I want to get it right. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 23:33:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780C71065670; Tue, 20 Dec 2011 23:33:49 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEA18FC12; Tue, 20 Dec 2011 23:33:48 +0000 (UTC) Received: from palm-64-28-152-131.palm.com ([64.28.152.131] helo=LT740055CZ0L1.palm1.palmone.com) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rd9Bq-000144-UL; Tue, 20 Dec 2011 17:33:46 -0600 Message-ID: <4EF11B57.7090007@phoronix.com> Date: Tue, 20 Dec 2011 15:33:43 -0800 From: Matthew Tippett User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF1121F.9010209@zedat.fu-berlin.de> In-Reply-To: <4EF1121F.9010209@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Tue, 20 Dec 2011 23:37:59 +0000 Cc: FreeBSD Stable Mailing List , Current FreeBSD , Igor Mozolevsky , "Samuel J. Greear" , freebsd-performance@freebsd.org, Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:33:49 -0000 Bottom post this time to follow Oliver :). On 12/20/2011 02:54 PM, O. Hartmann wrote: > On 12/20/11 22:45, Samuel J. Greear wrote: >> http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved >> >> PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux >> and Solaris. Steps to reproduce these benchmarks provided. >> >> Sam There are still possible issues with those benchmarks. The Xeon has known problems scaling from 6 to 12 cores (well enabling the hyperthreading), so you may find that some platforms are penalized in performance if HT is turned on. See the scaling that Phoronix has done in http://openbenchmarking.org/result/1112166-AR-1112153AR03 Most systems are good with scaling on real cores, the hyperthreading (and for that matter the Bulldozer thread affinity) can really break performance. Different platforms have different behaviours. Benchmarking is a mucky business.. Note that the benchmarks with Phoronix test suite are repeatable, once installed, you can just run "./phoronix-test-suite benchmark 1112113-AR-ORACLELIN37" to repeat (as close as the system allows) the benchmarks that started this thread. >> Is the postgresql benchmark the only way to benchmark? pgbench is already included in the Phoronix Test Suite (at least 9.0.1 TPC-B benchmark. >> >> Well, this inspires me to gather together all the benchmarks someone >> could find. There were lots of compalins about FreeBSD's poor >> performance with BIND - once a domain of FreeBSD. Network performance >> seems also to be an issue if it comes to scalability. >> It would be nice to see what portion of the raw CPU/GPU power the OS >> (FreeBSD, Linux ...) delivers to scientific applications. >> >> I only know some kind of benchmarks, BYTE UNIX benchmark, LINPACK test >> ... Does someone know a site to look for a couple of benchmarks to test >> >> a) memory system >> b) scalability (apart from pgbench) >> c) network performance/throughput/network scalability >> d) portion of CPU performance the system delivers for numerical >> applications to the user apart from the system's own consumption >> e) disk I/O performance and scalability The majority of these benchmarks are already in Phoronix Test Suite. There is monitoring capability (temp, load, CPU states, etc). The question is the mapping from system attribute to benchmark, as well as determine what the ambigious terms mean (scaling can mean on increasing workloads, as memory is increased, as cpus are increased). >> >> it would also be nice to discuss some nice settings and performance >> tunings for FreeBSD for several scenarios. I guess, starting developing >> benchmarking test scenarios for several purposes would lead faster to >> real numbers and non polemic than weird discussions ... >> This is what Michael and I are wanting to see. Adrian Chadd has offerered to help facilitate within the FreeBSD community. As mentioned before, what I'd like to see is 1) Recommendations for more rounded benchmarks from the FreeBSD perspective 2) Tuning guide documented somewhere within the community 3) Comparative results based on the communities testing. All concrete, and all achievable. Regards, Matthew From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 23:52:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84545106564A; Tue, 20 Dec 2011 23:52:41 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 268BA8FC13; Tue, 20 Dec 2011 23:52:40 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so4179617obb.13 for ; Tue, 20 Dec 2011 15:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q8BiBId5IQbLzZg350oQVjnqPaZur64reBR6Wlc0OaU=; b=hDTo23MP0xFpVHRwJY7ah+cxdbJ4WuexNPpMRGRz5gNAmWCbDRpOZW6IBM6vl9UIiF XK+bQgE5t0aEEfb7DQXhudj2o+Txwk4zQEPclr+ZsHkDHUs9tDrdKn8hruuopiahilzT RMCUHcLWdGu3HmD6Ya4aEc30TmOUqvkqbfOUw= MIME-Version: 1.0 Received: by 10.182.193.41 with SMTP id hl9mr3710658obc.44.1324425160540; Tue, 20 Dec 2011 15:52:40 -0800 (PST) Received: by 10.182.150.70 with HTTP; Tue, 20 Dec 2011 15:52:40 -0800 (PST) In-Reply-To: <20111220222253.GC55364@azathoth.lan> References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> <20111220222253.GC55364@azathoth.lan> Date: Wed, 21 Dec 2011 01:52:40 +0200 Message-ID: From: Alexander Yerenkow To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd , freebsd-current Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:52:41 -0000 2011/12/21 Baptiste Daroussin > On Mon, Dec 19, 2011 at 10:31:51PM +0200, Alexander Yerenkow wrote: > > 2011/12/19 Adrian Chadd > > > > > Hi, > > > > > > Hm, so this lets us create a virtualbox image from what, a set of > > > install tarballs? Or /usr/src build? > > > > > > I'm using cross-build and installation from sources dir (which is after > > that got svn-up'ed and all goes again). > > It shouldn't be complex to install to image from installation media > and/or > > tarballs, but mine main idea is to have rolling image for making some > > automated tests. > > Currently I'm establishing building and providing images scheme, will do > > images with KMS+small graphical programs, with qt+unstable KDE, and > > probably with BHyVe. I think that's most useful setups currently. And > maybe > > some image for benchmarking :) > > > > > > FYI I have been working on a ova file generator for the release, I manage > to > create ova images that do work on VirtualBox without problems, there are > still > some problems with vmware for now, the goal is to have a standard vm ready > image > (ova is standard) that would work on every system that do support it. > This is good :) Do you have some scripts left? > the image can be easily created from the release. > Well, I'm trying to build custom images, like rolling from svn [+ patches] [+ packages] [+ some initial config]. A way for building images from release I think can be taken from PC-BSD, they distribute upcoming 9 in VM formats too. > > regards, > Bapt > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 00:23:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E74E1106566C for ; Wed, 21 Dec 2011 00:23:16 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCD58FC16 for ; Wed, 21 Dec 2011 00:23:15 +0000 (UTC) Received: by lahl5 with SMTP id l5so3896024lah.13 for ; Tue, 20 Dec 2011 16:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RbETVobEUAxkK6l2+ZLR+lvY5W/Kg156undR0ovC1CI=; b=FXSA4Z0J126fQtifurHzy8jb1hjccNG8pFgkdBMNg8K3KOfh3abYPjrghJiQa7X61Q cj3yZedYHIdkah7ReaQZwgRHniCVTp4B4aEsG3sgz/SOfOOwAMMNvhcYARNOVba/qCpt XOeMWUi653IU/AH51X+3vk8BSkA05gE8SjTMs= MIME-Version: 1.0 Received: by 10.152.131.131 with SMTP id om3mr3947608lab.38.1324425680469; Tue, 20 Dec 2011 16:01:20 -0800 (PST) Received: by 10.152.24.195 with HTTP; Tue, 20 Dec 2011 16:01:20 -0800 (PST) In-Reply-To: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> <20111220222253.GC55364@azathoth.lan> Date: Tue, 20 Dec 2011 19:01:20 -0500 Message-ID: From: Outback Dingo To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Cc: Baptiste Daroussin , freebsd-current , Adrian Chadd Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 00:23:17 -0000 On Tue, Dec 20, 2011 at 6:52 PM, Alexander Yerenkow wrote: > 2011/12/21 Baptiste Daroussin > >> On Mon, Dec 19, 2011 at 10:31:51PM +0200, Alexander Yerenkow wrote: >> > 2011/12/19 Adrian Chadd >> > >> > > Hi, >> > > >> > > Hm, so this lets us create a virtualbox image from what, a set of >> > > install tarballs? Or /usr/src build? >> > > >> > > I'm using cross-build and installation from sources dir (which is after >> > that got svn-up'ed and all goes again). >> > It shouldn't be complex to install to image from installation media >> and/or >> > tarballs, but mine main idea is to have rolling image for making some >> > automated tests. >> > Currently I'm establishing building and providing images scheme, will do >> > images with KMS+small graphical programs, with qt+unstable KDE, and >> > probably with BHyVe. I think that's most useful setups currently. And >> maybe >> > some image for benchmarking :) >> > >> > >> >> FYI I have been working on a ova file generator for the release, I manage >> to >> create ova images that do work on VirtualBox without problems, there are >> still >> some problems with vmware for now, the goal is to have a standard vm ready >> image >> (ova is standard) that would work on every system that do support it. >> > How about in XEN 4.1 a .vhd image would be awesome, especially boot from zfs > This is good :) > Do you have some scripts left? > > >> the image can be easily created from the release. >> > > Well, I'm trying to build custom images, like rolling from svn [+ patches] > [+ packages] [+ some initial config]. > A way for building images from release I think can be taken from PC-BSD, > they distribute upcoming 9 in VM formats too. > > > >> >> regards, >> Bapt >> > > > > -- > Regards, > Alexander Yerenkow > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 00:28:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 239181065670; Wed, 21 Dec 2011 00:28:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8E64C8FC0C; Wed, 21 Dec 2011 00:28:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RdA2Q-0002E4-Ou>; Wed, 21 Dec 2011 01:28:06 +0100 Received: from e178016253.adsl.alicedsl.de ([85.178.16.253] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RdA2Q-0003rz-DI>; Wed, 21 Dec 2011 01:28:06 +0100 Message-ID: <4EF12815.2090805@zedat.fu-berlin.de> Date: Wed, 21 Dec 2011 01:28:05 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF1121F.9010209@zedat.fu-berlin.de> <20111220232925.GA55953@icarus.home.lan> In-Reply-To: <20111220232925.GA55953@icarus.home.lan> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B0CE417BCECAA1895E10BDC" X-Originating-IP: 85.178.16.253 Cc: "Samuel J. Greear" , freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 00:28:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B0CE417BCECAA1895E10BDC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/21/11 00:29, Jeremy Chadwick wrote: > On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote: >> On 12/20/11 22:45, Samuel J. Greear wrote: >>> http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Signif= icantly_Improved >>> >>> PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, L= inux >>> and Solaris. Steps to reproduce these benchmarks provided. >>> >>> Sam >>> >>> On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky wrote: >>> >>>> Interestingly, while people seem to be (arguably rightly) focused on= >>>> criticising Phoronix's benchmarking, nobody has offered an alternati= ve >>>> benchmark; and while (again, arguably rightly) it is important to >>>> benchmark real world performance, equally, nobody has offered any >>>> numbers in relation to, for example, HTTP or SMTP, or any other "rea= l >>>> world"-application torture tests done on the aforementioned two >>>> platforms... IMO, this just goes to show that "doing is hard" and >>>> "criticising is much easier" (yes, I am aware of the irony involved = in >>>> making this statement, but someone has to!) >>>> >>>> >>>> Cheers, >>>> Igor M :-) >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" >>>> >> >> Thanks for those numbers. >> Impressive how Matthew Dillon's project jumps forward now. And it is >> still impressive to see that the picture is still in the right place >> when it comes to a comparison to Linux. >> Also, OpenIndiana shows an impressive performance. >=20 > Preface to my long post below: >=20 > The things being discussed here are benchmarks, as in "how much work > can you get out of Thing". This is VERY DIFFERENT from testing > interactivity in a scheduler, which is more of a test that says "when > Thing X is executed while heavier-Thing Y is also being executed, how > much interaction is lost in Thing X". >=20 > The reason people notice this when using Xorg is because it's visual, > in an environment where responsiveness is absolutely mandatory above al= l > else. Nobody is going to put up with a system where during a buildworl= d > they go to move a window or click a mouse button or type a key and find= > that the window doesn't move, the mouse click is lost, or the key typed= > has gone into the bit bucket -- or, that those things are SEVERELY > delayed, to the point where interactivity is crap. I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD servers (serving homes, NFS/SAMBA and PostgreSQL database (small)). Those "seconds" where enough to cut a ssh line. Not funny. Network traffic droped significantly. X/Desktop makes the problem visible, indeed. But not seeing it does not mean it isn't there. This might be the reason why FreeBSD is so much behind when it comes to X= ? >=20 > I just want to make that clear to folks. This immense thread has been > with regards to the latter -- bad interactivity/responsiveness on a > system which was undergoing load that SHOULD be distributed "more > evenly" across the system *while* keeping interactivity/responsiveness > high. Historically nice/renice has been used for this task, but that > was when kernels were a little less complex and I/O subsystems were les= s > complex. Remember: we've now got schedulers for each type of thing, > and who gets what priority? You get my point I'm sure. >=20 > So remember: this was to discuss that aspect, with regards to ULE vs. > 4BSD schedulers. >=20 > Now, back to the benchmarks: >=20 > This also interested me: >=20 > * Linux system crashed > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html= >=20 > * OpenIndiana system crashed same way as Linux system > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html= >=20 > I cannot help but wonder if the Linux and OpenIndiana installations wer= e > more stressful on the hardware -- getting more out of the system, maybe= > resulting in increased power/load, which in turn resulted in the system= s > locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). Is FreeBSD supposed to run on dumpyard equipment? In former times, freeBSD was used on high value hardware, not the decomissioned crap with shoddy PSUs or whatsoever. If I need a server, I care about quality hardware as I do for my lab's box and my own box at home. I expect a "server garde" hardware to act like that and I expect the operating system to get the maximum out of that hardware. Otherwise it is not worth one shot. >=20 > My point is that Francois states these things in such a way to imply > that "DragonflyBSD was more stable", when in fact I happen to wonder th= e > opposite point -- that is to say, Linux and OpenIndiana were trying to > use the hardware more-so than DragonflyBSD, thus tickled what may be a > hardware-level problem. >=20 >> But this is only one suite of testing. Scientific Linux is supposed to= >> give the best performance for scientifi purposes, i.e. for longhaul >> calculations, much numerical stuff. It outperforms in a typical server= >> application FreeBSd, were "FreeBSD shoulkd have the power to serve". >> >> Is the postgresql benchmark the only way to benchmark? >=20 > I sure hope not. But you know what's equally as interesting? This: >=20 > http://people.freebsd.org/~kris/scaling/ >=20 > Specifically circa 2008: >=20 > http://people.freebsd.org/~kris/scaling/4cpu-pgsql.png > http://people.freebsd.org/~kris/scaling/pgsql-16cpu-2.png > http://people.freebsd.org/~kris/scaling/pgsql-16cpu.png >=20 > Now, I don't know if what was used in those ("pgsql sysbench") was the > same thing as "pg_bench" in the DragonflyBSD tests, but if so, the > numbers are different to a point that is preposterous. >=20 > There's also this: >=20 > http://people.freebsd.org/~kris/scaling/pgsql-ncpu.png >=20 > Now, compare those numbers to the TPS numbers shown here: >=20 > http://dl.wolfpond.org/Pg-benchmarks.pdf >=20 > So um... yeah. Now, if someone here is going to say "well, what > was tested by Kris was FreeBSD 7.0, while what was tested by Francois > was FreeBSD 9.0, and there have been improvements", then I ask that > someone show me where the improvements are that would exhibit a 4-8x > performance increase in some cases. >=20 > This rambling of mine is the same rambling I posted earlier in this > thread. There needs to be a consistent, standardised way of testing > this stuff. Every system tested tuned the exact same way, software > configured the same way, absolutely no quirks applied, etc.. Otherwise= > we end up with "mixed results" as shown above. Didn't got M. Larabel at Phoronix this half the way, except the ZFS fault= ? >=20 > Much to the disapproval of others, the Phoronix test suite is supposed > to be that "standard". Meaning, it's a suite you're supposed to be abl= e > to install and thus ensures that, aside from compiler used and any > system tests, that the same code is being used regardless of what syste= m > and OS it's on. Have I ever used it? No. And it's important that I > admit that up front, because being honest is necessary. >=20 >> Well, this inspires me to gather together all the benchmarks someone >> could find. There were lots of compalins about FreeBSD's poor >> performance with BIND - once a domain of FreeBSD. Network performance >> seems also to be an issue if it comes to scalability. >> It would be nice to see what portion of the raw CPU/GPU power the OS >> (FreeBSD, Linux ...) delivers to scientific applications. >=20 > Kris Kenneway's "BIND benchmark" that was released a long time ago > touched base on this. Remember: these plots show nothing other than > number of queries per second correlated with number of DNS server > threads (since BIND does have a 1:1 thread-to-CPU creation ratio): >=20 > http://people.freebsd.org/~kris/scaling/bind-pt.png > http://people.freebsd.org/~kris/scaling/bind-pt-2.png > http://people.freebsd.org/~kris/scaling/bind-pt-gige.png >=20 >> I only know some kind of benchmarks, BYTE UNIX benchmark, LINPACK test= >> ... Does someone know a site to look for a couple of benchmarks to tes= t >> >> a) memory system >> b) scalability (apart from pgbench) >> c) network performance/throughput/network scalability >> d) portion of CPU performance the system delivers for numerical >> applications to the user apart from the system's own consumption >> e) disk I/O performance and scalability >> >> it would also be nice to discuss some nice settings and performance >> tunings for FreeBSD for several scenarios. I guess, starting developin= g >> benchmarking test scenarios for several purposes would lead faster to >> real numbers and non polemic than weird discussions ... >=20 > All I wish is that we had some kind of "test suite" of our own, maybe a= s > a port, maybe in the base system, which could really help with all of > this. Something consistent. Why not supporting those guys at Phoronix? If we start with "our own", then we end up as you described above - not comparable, different numbers on different platforms, no normalization possible. >=20 > Now I'm switching back to discussing interactivity/responsiveness tests= : >=20 > Attilio Rao did comment in this thread to me, giving me some test > methodologies for testing interactivity during two types of simultaneou= s > loads -- but one involves dnetc, which I imagine means I'd need to get > familiar with that whole thing. >=20 > http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064936.= html >=20 > I haven't responded to his post yet (this thread is so long and tedious= > that I'm having serious problems following it + remembering all the > details -- am I the only one who feels daunted by this? God I hope > not), but his insights are, as always, beneficial, but also > overwhelming. Furthermore, I do not have 16-core or 24-core systems > to test on -- I have single-CPU, quad-core and dual-core systems to tes= t > on. I am a firm believer these are going to make up the majority of th= e > FreeBSD userbase (desktop and server environments). Extreme hardware (= e.g. > quad CPU with 12 cores per CPU) can be tested too, but let's at least > pick a demographic to start with. >=20 > Again: the FreeBSD users and administrative community want to help. Al= l > of us do. We just need to know exactly what we should be doing to test= , > and what exactly we're testing for. I'll be blunt while choosing to > play the Idiot Admin for a moment: I'd be much happier if someone had a= > tarball of shell scripts and things which could be used to test these > things. Lots of things need to be kept in mind, such as if someone is > running the "client" test on the same box as the "server" test, and > things like "the test data is written to a local filesystem, with > echo/printf statements constantly flushed" (great, now we're causing I/= O > load on top of our tests!), which to me means we should probably be > using something like mdconfig(8) to create a temporary filesystem to > store logs/data results. >=20 > The KTR stuff Atillio and many others have requested, I think, will be > the most beneficial way to get the developers the data they need. I ha= d > no idea about it until I found out that KTR was something completely > different than ktrace. >=20 > I still haven't found the time to do all of this, BTW, and for that I > apologise. The reason has to do with time at work + personal desire to= > do it. When I get a daunting task, I tend to get... well, not > depressed, but "scared" of the massive undertaking since it involves > lots of recurring tests, reboots, etc. -- hours of work -- and if I get= > that wrong, it's wasted effort (thus wasted developer time). I want to= > get it right. :-) >=20 --------------enig3B0CE417BCECAA1895E10BDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO8SgVAAoJEOgBcD7A/5N8hgIH/3OXj5P3KAZ7bAx0Xdcg93EP qU1qvXqmbf/H4QCYxWIEk7NG+TT5MoTIoRN9393F1n1+nkn8QRjU27NLqnPwFsbx cRk8VWQXtJ58DImkfHnAhmuScfScPrS5u5CDRs5LXS7cPT9r6NPZ6uyNr6qcEA7i Y5urmT8RLtPMZIcJRJx4i8BU0Wg314QxfH2AiOjiiS8vbIcXk3gYB+2C7VnPM2Le nvo2OYPW5T3t6KSwW/T2ikXSTNgKqy6YL9hX6Q/xZOvG/ZvXS/QkVNmnKuUgroqU A28ILznYmqnACfXrV4yzJAb04SrzxxCN8BgOwOs/zdzzzuQximfETIDNn44GYpY= =rq59 -----END PGP SIGNATURE----- --------------enig3B0CE417BCECAA1895E10BDC-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:29:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EA01065675; Wed, 21 Dec 2011 01:29:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 992F88FC13; Wed, 21 Dec 2011 01:29:30 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so9273525vcb.13 for ; Tue, 20 Dec 2011 17:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uiHoaCecTy8i62ljEyDn8TNea/c6xahUxa/A1fPBeb8=; b=Pzqnx0y4tN2mVFfGo8rcVLAmixoHR43lvNtAchgG9UNe85vmr3QyydHPk94wcKAioF 0jQgWZ7uYvYfOk3KxQ6DzFXzKcAC6VHaL1F4RX94LCRuNSvmQ2VySZRbDGvqAVwuLEph QJ3m2D6h7ZlDla07+qPflASsqkV+8ZJMLdHE4= MIME-Version: 1.0 Received: by 10.220.232.10 with SMTP id js10mr3491829vcb.2.1324430969838; Tue, 20 Dec 2011 17:29:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Tue, 20 Dec 2011 17:29:29 -0800 (PST) In-Reply-To: <4EF133D0.4050800@phoronix.com> References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF10088.1010409@zedat.fu-berlin.de> <4EF133D0.4050800@phoronix.com> Date: Tue, 20 Dec 2011 17:29:29 -0800 X-Google-Sender-Auth: 62l0R5YMedc4zy-sUOAXdflMBKE Message-ID: From: Adrian Chadd To: Matthew Tippett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List , Current FreeBSD , Igor Mozolevsky , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 01:29:31 -0000 Is there a specific version of the test suite that should be used, to compare against the published results? Adrian On 20 December 2011 17:18, Matthew Tippett wrote: > For such a system, the greatest immediate value would be to attempt to > reproduce the benchmarks in question. > > Install PTS from www.phoronix-test-suite.com or freshports.org. > > Run the benchmark against those used in the article > > =A0 =A0phoronix-test-suite benchmark 1112113-AR-ORACLELIN37 > > You will be asked to push the comparison up to openbenchmarking at the en= d. > > Matthew > > > On 12/20/2011 01:39 PM, O. Hartmann wrote: >> >> On 12/20/11 21:20, Igor Mozolevsky wrote: >>> >>> Interestingly, while people seem to be (arguably rightly) focused on >>> criticising Phoronix's benchmarking, nobody has offered an alternative >>> benchmark; and while (again, arguably rightly) it is important to >>> benchmark real world performance, equally, nobody has offered any >>> numbers in relation to, for example, HTTP or SMTP, or any other "real >>> world"-application torture tests done on the aforementioned two >>> platforms... IMO, this just goes to show that "doing is hard" and >>> "criticising is much easier" (yes, I am aware of the irony involved in >>> making this statement, but someone has to!) >>> >>> >>> Cheers, >>> Igor M :-) >> >> Unfortunately, M. Larabel is the only one who's performing benchmarks on >> FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, >> there is a lot of criticism, but no alternative. >> I said unfortunately - not offensive - since Larabel and Phoronix are >> sadly the only ones who do actually such bechmarking. >> >> It would be much more nicer and kind to support those people. >> >> Well, in January/February we get new hardware. One box is supposed to do >> number crunching via 12 cores and a TESLA GPU. My colleague is >> developing a high parallelized peice of software for satellite data >> transformation. The software package is CPU bound, partially GPU, but >> massively memory hungry (96 to 128 GB RAM is needed). >> What I can offer is, since I will also work on that machine and I've >> free hand to administer, in the spare time of doing my PhD, installing >> FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS >> data storage drive for homes, so both systems can perform on a most >> recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional >> programmer/developer. My skills are sufficient for the daily scientific >> work. So, without pressure, I'm willing to perform some HPC benchmarks >> under advice if the day comes and those interested in bare numbers of >> FreeBSD vs. Linux performance with a real-world-scientific application. >> >> I would appreciate to see some of the developers and/or FreeBSD hackers >> to help Phoronix setting up a proper testenvironment instead of bashing >> M. Larabel and his fellows. >> >> Regards, >> Oliver >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:18:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6B2106566B; Wed, 21 Dec 2011 01:18:14 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3263C8FC13; Wed, 21 Dec 2011 01:18:13 +0000 (UTC) Received: from palm-64-28-152-131.palm.com ([64.28.152.131] helo=LT740055CZ0L1.palm1.palmone.com) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RdAot-0007Xv-N9; Tue, 20 Dec 2011 19:18:11 -0600 Message-ID: <4EF133D0.4050800@phoronix.com> Date: Tue, 20 Dec 2011 17:18:08 -0800 From: Matthew Tippett User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF10088.1010409@zedat.fu-berlin.de> In-Reply-To: <4EF10088.1010409@zedat.fu-berlin.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Wed, 21 Dec 2011 01:43:05 +0000 Cc: freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , Jeremy Chadwick , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 01:18:14 -0000 For such a system, the greatest immediate value would be to attempt to reproduce the benchmarks in question. Install PTS from www.phoronix-test-suite.com or freshports.org. Run the benchmark against those used in the article phoronix-test-suite benchmark 1112113-AR-ORACLELIN37 You will be asked to push the comparison up to openbenchmarking at the end. Matthew On 12/20/2011 01:39 PM, O. Hartmann wrote: > On 12/20/11 21:20, Igor Mozolevsky wrote: >> Interestingly, while people seem to be (arguably rightly) focused on >> criticising Phoronix's benchmarking, nobody has offered an alternative >> benchmark; and while (again, arguably rightly) it is important to >> benchmark real world performance, equally, nobody has offered any >> numbers in relation to, for example, HTTP or SMTP, or any other "real >> world"-application torture tests done on the aforementioned two >> platforms... IMO, this just goes to show that "doing is hard" and >> "criticising is much easier" (yes, I am aware of the irony involved in >> making this statement, but someone has to!) >> >> >> Cheers, >> Igor M :-) > Unfortunately, M. Larabel is the only one who's performing benchmarks on > FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, > there is a lot of criticism, but no alternative. > I said unfortunately - not offensive - since Larabel and Phoronix are > sadly the only ones who do actually such bechmarking. > > It would be much more nicer and kind to support those people. > > Well, in January/February we get new hardware. One box is supposed to do > number crunching via 12 cores and a TESLA GPU. My colleague is > developing a high parallelized peice of software for satellite data > transformation. The software package is CPU bound, partially GPU, but > massively memory hungry (96 to 128 GB RAM is needed). > What I can offer is, since I will also work on that machine and I've > free hand to administer, in the spare time of doing my PhD, installing > FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS > data storage drive for homes, so both systems can perform on a most > recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional > programmer/developer. My skills are sufficient for the daily scientific > work. So, without pressure, I'm willing to perform some HPC benchmarks > under advice if the day comes and those interested in bare numbers of > FreeBSD vs. Linux performance with a real-world-scientific application. > > I would appreciate to see some of the developers and/or FreeBSD hackers > to help Phoronix setting up a proper testenvironment instead of bashing > M. Larabel and his fellows. > > Regards, > Oliver > From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:37:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE8E106566B; Wed, 21 Dec 2011 01:37:33 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 888C58FC14; Wed, 21 Dec 2011 01:37:33 +0000 (UTC) Received: from mobile-166-205-136-198.mycingular.net ([166.205.136.198] helo=www.palm.com) by phx1.phoronix.com with esmtpa (Exim 4.69) (envelope-from ) id 1RdB7b-0007Hu-W1; Tue, 20 Dec 2011 19:37:32 -0600 Date: Tue, 20 Dec 2011 17:37:29 -0800 From: To: "Adrian Chadd" In-Reply-To: X-Mailer: Palm webOS X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com Message-Id: <20111221013733.BDE8E106566B@hub.freebsd.org> X-Mailman-Approved-At: Wed, 21 Dec 2011 01:43:14 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Mailing List , Current FreeBSD , Igor Mozolevsky , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 01:37:33 -0000 The benchmarks themselves are versioned. So in general most of the av= ailable versions of PTS itself should be fine. PTS can be considered = an execution shell that doesn't affect the benchmark itself. Note th= at you'll download a pile of the benchmarks, build and install them. = Then you run about 49 individual steps. Matthew -- Sent from my HP Pre3 _________________________________________________________________ On Dec 20, 2011 5:30 PM, Adrian Chadd = ; wrote: Is there a specific version of the test suite that = should be used, to=0D compare against the published results?=0D =0D=0D Adrian=0D =0D On 20 December 2011 17:18, Matthew Tippett <= ;matthew@phoronix.com> wrote:=0D > For such a system, the greatest= immediate value would be to attempt to=0D > reproduce the benchmarks= in question.=0D >=0D > Install PTS from www.phoronix-test-suit= e.com or freshports.org.=0D >=0D > Run the benchmark against th= ose used in the article=0D >=0D > =C2=A0 =C2=A0phoronix-test-su= ite benchmark 1112113-AR-ORACLELIN37=0D >=0D > You will be aske= d to push the comparison up to openbenchmarking at the end.=0D >=0D> Matthew=0D >=0D >=0D > On 12/20/2011 01:39 PM, O. = Hartmann wrote:=0D >>=0D >> On 12/20/11 21:20, Igor Mozol= evsky wrote:=0D >>>=0D >>> Interestingly, while peo= ple seem to be (arguably rightly) focused on=0D >>> criticising= Phoronix's benchmarking, nobody has offered an alternative=0D >>&= gt; benchmark; and while (again, arguably rightly) it is important to=0D >>> benchmark real world performance, equally, nobody has offered= any=0D >>> numbers in relation to, for example, HTTP or SMTP, = or any other "real=0D >>> world"-application torture tests done= on the aforementioned two=0D >>> platforms... IMO, this just g= oes to show that "doing is hard" and=0D >>> "criticising is muc= h easier" (yes, I am aware of the irony involved in=0D >>> maki= ng this statement, but someone has to!)=0D >>>=0D >>&g= t;=0D >>> Cheers,=0D >>> Igor M :-)=0D >>= =0D >> Unfortunately, M. Larabel is the only one who's performing = benchmarks on=0D >> FreeBSD, comparing its performance to the Linu= x-opponents. Adn indeed,=0D >> there is a lot of criticism, but no= alternative.=0D >> I said unfortunately - not offensive - since L= arabel and Phoronix are=0D >> sadly the only ones who do actually = such bechmarking.=0D >>=0D >> It would be much more nicer= and kind to support those people.=0D >>=0D >> Well, in J= anuary/February we get new hardware. One box is supposed to do=0D >&g= t; number crunching via 12 cores and a TESLA GPU. My colleague is=0D >= ;> developing a high parallelized peice of software for satellite data= =0D >> transformation. The software package is CPU bound, partiall= y GPU, but=0D >> massively memory hungry (96 to 128 GB RAM is need= ed).=0D >> What I can offer is, since I will also work on that mac= hine and I've=0D >> free hand to administer, in the spare time of = doing my PhD, installing=0D >> FreeBSD 9.0/10.0 besides SuSe Linux= and looking forward having one ZFS=0D >> data storage drive for h= omes, so both systems can perform on a most=0D >> recent ZFS. I'm = new to Linux, not a BSD guru, nor I'm a professional=0D >> program= mer/developer. My skills are sufficient for the daily scientific=0D >= > work. So, without pressure, I'm willing to perform some HPC benchmarks= =0D >> under advice if the day comes and those interested in bare = numbers of=0D >> FreeBSD vs. Linux performance with a real-world-s= cientific application.=0D >>=0D >> I would appreciate to = see some of the developers and/or FreeBSD hackers=0D >> to help Ph= oronix setting up a proper testenvironment instead of bashing=0D >>= ; M. Larabel and his fellows.=0D >>=0D >> Regards,=0D = >> Oliver=0D >>=0D >=0D > ______________________= _________________________=0D > freebsd-stable@freebsd.org mailing lis= t=0D > http://lists.freebsd.org/mailman/listinfo/freebsd-stable=0D > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.= org"=0D _______________________________________________=0D freebsd-pe= rformance@freebsd.org mailing list=0D http://lists.freebsd.org/mailman/l= istinfo/freebsd-performance=0D To unsubscribe, send any mail to "freebsd= -performance-unsubscribe@freebsd.org"=0D From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:38:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45152106564A; Wed, 21 Dec 2011 01:38:33 +0000 (UTC) (envelope-from michael.larabel@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC348FC2A; Wed, 21 Dec 2011 01:38:32 +0000 (UTC) Received: from c-98-193-96-120.hsd1.il.comcast.net ([98.193.96.120] helo=[172.16.93.133]) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RdB8a-0007JA-Gg; Tue, 20 Dec 2011 19:38:32 -0600 Message-ID: <4EF13895.9060307@phoronix.com> Date: Tue, 20 Dec 2011 19:38:29 -0600 From: Michael Larabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Adrian Chadd References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF10088.1010409@zedat.fu-berlin.de> <4EF133D0.4050800@phoronix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Wed, 21 Dec 2011 01:43:24 +0000 Cc: FreeBSD Stable Mailing List , Matthew Tippett , Current FreeBSD , Igor Mozolevsky , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 01:38:33 -0000 Any version is fine that's PTS 3.0 or newer in terms of being compatible, since the test profiles are versioned separately and automatically fetched to match the result file. However, I'd recommended the newest (PTS 3.6) as it contains the best FreeBSD support at present in terms of hardware/software information parsing (for the automated table), etc. Michael On 12/20/2011 07:29 PM, Adrian Chadd wrote: > Is there a specific version of the test suite that should be used, to > compare against the published results? > > > Adrian > > On 20 December 2011 17:18, Matthew Tippett wrote: >> For such a system, the greatest immediate value would be to attempt to >> reproduce the benchmarks in question. >> >> Install PTS from www.phoronix-test-suite.com or freshports.org. >> >> Run the benchmark against those used in the article >> >> phoronix-test-suite benchmark 1112113-AR-ORACLELIN37 >> >> You will be asked to push the comparison up to openbenchmarking at the end. >> >> Matthew >> >> >> On 12/20/2011 01:39 PM, O. Hartmann wrote: >>> On 12/20/11 21:20, Igor Mozolevsky wrote: >>>> Interestingly, while people seem to be (arguably rightly) focused on >>>> criticising Phoronix's benchmarking, nobody has offered an alternative >>>> benchmark; and while (again, arguably rightly) it is important to >>>> benchmark real world performance, equally, nobody has offered any >>>> numbers in relation to, for example, HTTP or SMTP, or any other "real >>>> world"-application torture tests done on the aforementioned two >>>> platforms... IMO, this just goes to show that "doing is hard" and >>>> "criticising is much easier" (yes, I am aware of the irony involved in >>>> making this statement, but someone has to!) >>>> >>>> >>>> Cheers, >>>> Igor M :-) >>> Unfortunately, M. Larabel is the only one who's performing benchmarks on >>> FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, >>> there is a lot of criticism, but no alternative. >>> I said unfortunately - not offensive - since Larabel and Phoronix are >>> sadly the only ones who do actually such bechmarking. >>> >>> It would be much more nicer and kind to support those people. >>> >>> Well, in January/February we get new hardware. One box is supposed to do >>> number crunching via 12 cores and a TESLA GPU. My colleague is >>> developing a high parallelized peice of software for satellite data >>> transformation. The software package is CPU bound, partially GPU, but >>> massively memory hungry (96 to 128 GB RAM is needed). >>> What I can offer is, since I will also work on that machine and I've >>> free hand to administer, in the spare time of doing my PhD, installing >>> FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS >>> data storage drive for homes, so both systems can perform on a most >>> recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional >>> programmer/developer. My skills are sufficient for the daily scientific >>> work. So, without pressure, I'm willing to perform some HPC benchmarks >>> under advice if the day comes and those interested in bare numbers of >>> FreeBSD vs. Linux performance with a real-world-scientific application. >>> >>> I would appreciate to see some of the developers and/or FreeBSD hackers >>> to help Phoronix setting up a proper testenvironment instead of bashing >>> M. Larabel and his fellows. >>> >>> Regards, >>> Oliver >>> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:53:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A2001065672; Wed, 21 Dec 2011 01:53:49 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id BC03B8FC1F; Wed, 21 Dec 2011 01:53:47 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pBL1qfT4082043; Tue, 20 Dec 2011 19:52:41 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pBL1qf43082042; Tue, 20 Dec 2011 19:52:41 -0600 (CST) (envelope-from brooks) Date: Tue, 20 Dec 2011 19:52:41 -0600 From: Brooks Davis To: Gleb Smirnoff Message-ID: <20111221015241.GE68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HnQK338I3UIa/qiP" Content-Disposition: inline In-Reply-To: <20111220191520.GA70684@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 01:53:49 -0000 --HnQK338I3UIa/qiP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 11:15:20PM +0400, Gleb Smirnoff wrote: > Doug, >=20 > On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote: > D> > I saw this too, when my kernel and userland were out of sync (e.g. j= ust > D> > after installing a new kernel, and before installworld). I suspect = it > D> > is caused by the changes in r228571, which cause old ifconfig and > D> > dhclient to not recognize any interfaces. I'm not 100% sure though.= =2E. > D>=20 > D> I tried replacing both ifconfig and dhclient with the versions that we= re > D> built along with the new kernel, and that didn't work. >=20 > This shouldn't happen. If you did 'make buildworld buildkernel', then > your world in objdir would have binaries compiled with includes from > source tree, not from /usr/include, thus compatible with new kernel. >=20 > 'make buildworld buildkernel' always produces compatible kernel and > worlds. >=20 > However, if you did 'cd /usr/src/sbin/ifconfig && make all install' then > that didn't work, since used headers from /usr/include. >=20 > D> The traditional (and documented) upgrade process for many years has be= en > D> to boot the new kernel, make sure it's Ok, then update world. Obviously > D> something different is needed this time, so it needs an UPDATING entry > D> (assuming that all this is not just a bug). >=20 > The documented one says 'Reboot into single user mode' and then install > new world. This path was not broken, since single user mode doesn't > imply network support. While this is the documented path, it's not actually been required except in edge cases for ages (the last I can remember is a.out->elf). It's been long enough that I don't think we can really make people do it except for a short period of time in HEAD. I believe it's unacceptable for a release to release upgrade. > The undocumented brave way 'make installkernel installworld && reboot' > works also, without any problems. At least until someone screws up something else and you now can't use kernel.old either. This is somewhat ok for HEAD users, but I think we should try harder to avoid this sort of situation. -- Brooks --HnQK338I3UIa/qiP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8TvoXY6L6fI4GtQRAiJBAJ0VBuNCY6QOQIiDwKwqgHpI8gxTewCfZkHW 9PWeXG2xUFPzDC+xOvaZaTc= =8sY3 -----END PGP SIGNATURE----- --HnQK338I3UIa/qiP-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 02:01:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DB181065675; Wed, 21 Dec 2011 02:01:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0A08FC1E; Wed, 21 Dec 2011 02:01:33 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pBL20RnE082103; Tue, 20 Dec 2011 20:00:27 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pBL20RnB082102; Tue, 20 Dec 2011 20:00:27 -0600 (CST) (envelope-from brooks) Date: Tue, 20 Dec 2011 20:00:27 -0600 From: Brooks Davis To: Gleb Smirnoff Message-ID: <20111221020027.GF68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <20111220192354.GB70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K/NRh952CO+2tg14" Content-Disposition: inline In-Reply-To: <20111220192354.GB70684@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-current , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:01:35 -0000 --K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: > Brooks, >=20 > On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote: > B> We almost certainly need to back r228571 out. This is not an acceptab= le > B> upgrade path that would be acceptable historically. Specially, we have > B> effectively promised users that an X.Y world will work on an X+1.0 > B> kernel for most of history. There are obvious exceptions to this, but > B> we have never allowed ifconfig to be one of them (I broke it many years > B> ago with my first attempt to add if_epoch to if_data and had to back > B> that out). >=20 > Pardon, where did we promise that? The applications in jail should work, > but not kernel configuration tools. The network facilities like ipfw > and pf has changed their ABI numerous times, making a new kernel > with older world inaccessible via network after boot. We've not promised it in writing, but by not breaking it for many years we're created an effective promise IMO. > Considering r228571: we need to specify vhid as additional address > attribute in atomic manner, via one ioctl(). Address can't be first > configured, and then made redundant, that would lead it to being > static for a short period, sending gratutious ARP announcement, etc. >=20 > An assumption that we are not allowed to change ABI for our own tools > strongly discourages bringing in new features :( I'm not saying we can't change the ABI. I am saying that we should make sure we can support a remote, console-less upgrade from what ever 9.x branches are practical to 10.0 in the average case. We've set the expectation that this will work and IMO it's a reasonable expectation. =20 We've violated it in a few cases such as the emX->igbX fiasco, but by and large most users have been able to do this. I guess I'm ok with dealing with this in HEAD, but I'm not OK with it for all upgrades from 9.x. -- Brooks --K/NRh952CO+2tg14 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8T26XY6L6fI4GtQRApWGAJ9pA/Z15kmu+2ga7r7mnWv4jsSN2wCdGlej E0MUDmeTkxV7N/9p9/UuSu0= =nCux -----END PGP SIGNATURE----- --K/NRh952CO+2tg14-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 02:23:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 6C165106566B; Wed, 21 Dec 2011 02:23:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F157914E2B1; Wed, 21 Dec 2011 02:23:23 +0000 (UTC) Message-ID: <4EF1431B.8060909@FreeBSD.org> Date: Tue, 20 Dec 2011 18:23:23 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Claude Buisson References: <4EF05CEC.6080603@orange.fr> In-Reply-To: <4EF05CEC.6080603@orange.fr> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, FreeBSD Current Subject: Re: Is the svn2cvs gateway down ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:23:24 -0000 On 12/20/2011 02:01, Claude Buisson wrote: > Hi, > > It seems (from my own csup's and cvswe.cgi) that the src commits are lost, > starting with r228697 Sun Dec 18 22:04:55 2011) Yeah, my warning 2 days ago that this was going to happen seems to have gone un-heeded. :) I'm sure you can take bz' word that it's being looked at now though. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 02:26:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5E10C1065676 for ; Wed, 21 Dec 2011 02:26:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 09632177D02; Wed, 21 Dec 2011 02:24:25 +0000 (UTC) Message-ID: <4EF14359.3070401@FreeBSD.org> Date: Tue, 20 Dec 2011 18:24:25 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Yerenkow References: <4EF08F84.4060500@lissyara.su> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alex Keda , Current FreeBSD Subject: Re: regression: Xorg get 100% cpu and freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:26:41 -0000 For those having this problem if you compile a custom kernel with the 4BSD scheduler instead of ULE, does the problem disappear? Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 06:06:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DE6106566B for ; Wed, 21 Dec 2011 06:06:13 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 857F18FC15 for ; Wed, 21 Dec 2011 06:06:13 +0000 (UTC) X-AuditID: 1209190e-b7f8f6d0000008fc-1d-4ef17754c818 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E9.0A.02300.45771FE4; Wed, 21 Dec 2011 01:06:12 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pBL66CsC010657; Wed, 21 Dec 2011 01:06:12 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBL669gg024767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Dec 2011 01:06:11 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pBL669hY023718; Wed, 21 Dec 2011 01:06:09 -0500 (EST) Date: Wed, 21 Dec 2011 01:06:08 -0500 (EST) From: Benjamin Kaduk To: Larry Rosenman In-Reply-To: <4EF0CCC6.6060606@lerctr.org> Message-ID: References: <4EF0CCC6.6060606@lerctr.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nohtS/tHPoHePhsWcNx+YLJY/mMXq wOQx49N8Fo/9e7eyBDBFcdmkpOZklqUW6dslcGXcm6ZRMJW7YuvUD2wNjFc4uhg5OSQETCQe Lelgh7DFJC7cW88GYgsJ7GOUWNqq0sXIBWRvYJQ4/fMtO0TiAJPExisZEIkGRonVjQdYQBIs AtoSU2ZNZgWx2QRUJGa+2Qg2SURAWWLN1D/MIDazgLzE/yuXmUBsYQFrifbzk4CGcnBwCmhJ nOmpBAnzCthLTHyynRVil6bEvQWzwfaKCuhIrN4/hQWiRlDi5MwnLBAjLSXO/bnONoFRcBaS 1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGCgpRTkm8H49eDSocY BTgYlXh4hfd/8BNiTSwrrsw9xCjJwaQkyltU9tFPiC8pP6UyI7E4I76oNCe1+BCjBAezkggv Sx5QjjclsbIqtSgfJiXNwaIkzqum9c5PSCA9sSQ1OzW1ILUIJivDwaEkwbsbZKhgUWp6akVa Zk4JQpqJgxNkOA/Q8HUgNbzFBYm5xZnpEPlTjLocez9/P8MoxJKXn5cqJc67A6RIAKQoozQP bg4subxiFAd6S5j3MkgVDzAxwU16BbSECWjJNucPIEtKEhFSUg2MZcfXy2fPOx0ac5clStnw kP+DL69XWi/a6X/g6NzgOXV1mqlrdf+/zdAqv9O4e/5lgzr+v1Pi7bLEUg1bViX+PM1y/PEb G84nRau0nLlu1Ne847/7w4T9MteezVc7FYVddy/sePJz8u6iT680dyyNWL3l7V4DB8Yd5lU5 6upfJorVbNi6bMuuHiWW4oxEQy3mouJEANzxEt0JAwAA Cc: freebsd-current@freebsd.org Subject: Re: clang (__builtin_ffs) vs /usr/include/string.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 06:06:14 -0000 Hi Larry, On Tue, 20 Dec 2011, Larry Rosenman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is anyone going to fix the following in the clang or FreeBSD system? I haven't seen any mention of __builtin_ffs on any freebsd lists since your thread in october, "system headers with clang?". That rather makes me suspect that no one else is seeing this "problem". It's hard to fix something you don't know about. > > In file included from /usr/include/string.h:45: > /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' > int ffs(int) __pure2; > ^ > /usr/include/machine/cpufunc.h:140:24: note: expanded from: > #define ffs(x) __builtin_ffs(x) > ^ > /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with > type 'int (unsigned int)' > 7 warnings and 1 error generated. > *** Error code 1 > As such, since we don't know what the "problem" is, some context for what is going on here would be useful -- what are you trying to compile? Still lsof? > > This looks like something that needs to change in clang/FreeBSD headers. Not necessarily -- things from the machine/ hierarchy are pretty uncommon, and I wouldn't be surprised if they had dependencies and ordering requirements involved. It could well be an application error, but we can't tell, since there is no context. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 07:17:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31E7106566B for ; Wed, 21 Dec 2011 07:17:43 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id AEFFE8FC14 for ; Wed, 21 Dec 2011 07:17:41 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=XBEDm/9EZXxN/S8ecCaXsA3ekkwMqHxoshPQt4Pt4hcSxFhXy5jVw6DdN9J0Qc12jcObNROzIUFy UhA4H6pPx2bXDcoUTyNPgFAyJuT0A2wVkzEfwvaebcu6717qGYUS Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1324451861096344.86520306467185; Tue, 20 Dec 2011 23:17:41 -0800 (PST) Message-ID: <4EF18811.3000900@zoho.com> Date: Wed, 21 Dec 2011 04:17:37 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EEFB8B6.8010203@zoho.com> <4EF001A7.4030602@zoho.com> <4EF01EEC.9030204@zoho.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: freebsd-current@freebsd.org Subject: Re: Failure to compile world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 07:17:43 -0000 Ok, just sent the PR → http://www.freebsd.org/cgi/query-pr.cgi?pr=163495 And hopefully I'll make another one describing some other issues I'm having (like world compilation taking libs/headers from system instead of the own src tree, failing to compile due to missing symbols in libraries or changes in headers) Thanks for your time Garrett ! From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 07:38:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD294106564A; Wed, 21 Dec 2011 07:38:08 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAE28FC08; Wed, 21 Dec 2011 07:38:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBL7c8D3065791; Wed, 21 Dec 2011 07:38:08 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBL7c8Pg065790; Wed, 21 Dec 2011 07:38:08 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Wed, 21 Dec 2011 08:38:04 +0100 From: Baptiste Daroussin To: Alexander Yerenkow Message-ID: <20111221073804.GD55364@azathoth.lan> References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> <20111220222253.GC55364@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xm/fll+QQv+hsKip" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-current Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 07:38:08 -0000 --Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 01:52:40AM +0200, Alexander Yerenkow wrote: > 2011/12/21 Baptiste Daroussin >=20 > > On Mon, Dec 19, 2011 at 10:31:51PM +0200, Alexander Yerenkow wrote: > > > 2011/12/19 Adrian Chadd > > > > > > > Hi, > > > > > > > > Hm, so this lets us create a virtualbox image from what, a set of > > > > install tarballs? Or /usr/src build? > > > > > > > > I'm using cross-build and installation from sources dir (which is a= fter > > > that got svn-up'ed and all goes again). > > > It shouldn't be complex to install to image from installation media > > and/or > > > tarballs, but mine main idea is to have rolling image for making some > > > automated tests. > > > Currently I'm establishing building and providing images scheme, will= do > > > images with KMS+small graphical programs, with qt+unstable KDE, and > > > probably with BHyVe. I think that's most useful setups currently. And > > maybe > > > some image for benchmarking :) > > > > > > > > > > FYI I have been working on a ova file generator for the release, I mana= ge > > to > > create ova images that do work on VirtualBox without problems, there are > > still > > some problems with vmware for now, the goal is to have a standard vm re= ady > > image > > (ova is standard) that would work on every system that do support it. > > >=20 > This is good :) > Do you have some scripts left? >=20 You can try it here: http://git.etoilebsd.net/vmdkimage/ currently this is a quick and dirty make-vmdk.sh script I imported vmdkimage.c from Haiku, conv= erted it from C++ to C and make some changes so that it is able to build scsi vmdk images (vmware needs scsi disk). You can use it that way: ./make-vmdk.sh 4 90-RC3 test9 You will get a tes9.ova.xz image the disk size will be a 4G one, the xz will take 100M. you can import it in vbox it will work ootb, it should work on v= mware I hope, currently no feedback on vmware for the last changes. Here is an example http://files.etoilebsd.net/ova/test9.ova.xz No tunning on the OS yet regards, Bapt --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7xjNwACgkQ8kTtMUmk6ExNJACgiK7E5/cXZPwIQJ7YhMq4ybUY dGYAnRg+ZYY2GGgBJRbpuBINgvxKEz3e =9NAM -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 07:39:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DBE1065673; Wed, 21 Dec 2011 07:39:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EA2668FC1E; Wed, 21 Dec 2011 07:39:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBL7dPwc099279; Wed, 21 Dec 2011 02:39:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBL7dPE1099266; Wed, 21 Dec 2011 07:39:25 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 21 Dec 2011 07:39:25 GMT Message-Id: <201112210739.pBL7dPE1099266@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 07:39:27 -0000 TB --- 2011-12-21 06:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-21 06:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-21 06:40:00 - cleaning the object tree TB --- 2011-12-21 06:40:59 - cvsupping the source tree TB --- 2011-12-21 06:40:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-21 06:46:23 - building world TB --- 2011-12-21 06:46:23 - CROSS_BUILD_TESTING=YES TB --- 2011-12-21 06:46:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-21 06:46:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-21 06:46:23 - SRCCONF=/dev/null TB --- 2011-12-21 06:46:23 - TARGET=i386 TB --- 2011-12-21 06:46:23 - TARGET_ARCH=i386 TB --- 2011-12-21 06:46:23 - TZ=UTC TB --- 2011-12-21 06:46:23 - __MAKE_CONF=/dev/null TB --- 2011-12-21 06:46:23 - cd /src TB --- 2011-12-21 06:46:23 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 21 06:46:23 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp: In static member function 'static clang::Token clang::MacroArgs::StringifyArgument(const clang::Token*, clang::Preprocessor&, bool, clang::SourceLocation, clang::SourceLocation)': /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp:193: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libclanglex. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-21 07:39:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-21 07:39:25 - ERROR: failed to build world TB --- 2011-12-21 07:39:25 - 2500.89 user 509.55 system 3564.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 09:31:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CD63106564A for ; Wed, 21 Dec 2011 09:31:21 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 043258FC0C for ; Wed, 21 Dec 2011 09:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:CC:To:Date:From:Subject:Content-Type:MIME-Version:In-Reply-To:References; bh=TyBO2l9mERaX8PSWVEpoIc9Wkf4s82SXApeTLYGzMsA=; b=ZgQ52UGwJ8yyMRTgKkiYzz8L5gvHK06WhY/EGqLYpo1DyzgeFtY9pQtmPrSP7VhLJIrYu1wKNUMxaCZEGKaUYt0QDt3amTL9n+uC1n9zgoCClDugynYi8pQseiNidDCh7665fHY6+xX7BBNxHHou/ZvTABxom+6flKn7Poo75RU=; Received: from cpe-72-177-69-180.austin.res.rr.com ([72.177.69.180]:34476 helo=[192.168.200.117]) by thebighonker.lerctr.org with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RdIVy-0004PO-MT; Wed, 21 Dec 2011 03:31:16 -0600 References: <4EF0CCC6.6060606@lerctr.org> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 From: Larry Rosenman Date: Wed, 21 Dec 2011 03:31:26 -0600 To: Benjamin Kaduk Message-ID: <921cedf2-3850-43da-aca2-631beb8e2b58@email.android.com> X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: clang (__builtin_ffs) vs /usr/include/string.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 09:31:21 -0000 Lsof...... And this seems like a contradiction between the string.h declara= tion and the built-in one. -- Sent from my Android phone with K-9 Mail. Pl= ease excuse my brevity. Benjamin Kaduk wrote: Hi Larry, = On Tue, 20 Dec 2011, Larry Rosenman wrote: > -----BEGIN PGP SIGNED MESSAGE= ----- > Hash: SHA1 > > Is anyone going to fix the following in the clang or= FreeBSD system? I haven't seen any mention of __builtin_ffs on any freebs= d lists since your thread in october, "system headers with clang?". That r= ather makes me suspect that no one else is seeing this "problem". It's har= d to fix something you don't know about. > > In file included from /usr/i= nclude/string.h:45: > /usr/include/strings.h:47:6: error: conflicting types= for '__builtin_ffs' > int ffs(int) __pure2; > ^ > /usr/include/machine/cpu= func.h:140:24: note: expanded from: > #define ffs(x) __builtin_ffs(x) > ^ >= /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with > typ= e 'int (unsigned int)' > 7 warnings and 1 error generated. > *** Error code= 1 > As such, since we don't know what the "problem" is, some context for = what is going on here would be useful -- what are you trying to compile? S= till lsof? > > This looks like something that needs to change in clang/Fr= eeBSD headers. Not necessarily -- things from the machine/ hierarchy are p= retty uncommon, and I wouldn't be surprised if they had dependencies and o= rdering requirements involved. It could well be an application error, but = we can't tell, since there is no context. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 09:58:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3333B106564A for ; Wed, 21 Dec 2011 09:58:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63C238FC12 for ; Wed, 21 Dec 2011 09:58:32 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA17228; Wed, 21 Dec 2011 11:58:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RdIwF-000MRQ-II; Wed, 21 Dec 2011 11:58:19 +0200 Message-ID: <4EF1ADB9.1090802@FreeBSD.org> Date: Wed, 21 Dec 2011 11:58:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Larry Rosenman References: <4EF0CCC6.6060606@lerctr.org> <921cedf2-3850-43da-aca2-631beb8e2b58@email.android.com> In-Reply-To: <921cedf2-3850-43da-aca2-631beb8e2b58@email.android.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Benjamin Kaduk Subject: Re: clang (__builtin_ffs) vs /usr/include/string.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 09:58:34 -0000 on 21/12/2011 11:31 Larry Rosenman said the following: > Lsof...... > And this seems like a contradiction between the string.h declaration and the built-in one. It more looks like you include machine/cpufunc.h before strings.h and that has an undesired side effect. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:41:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D634B106564A; Wed, 21 Dec 2011 10:41:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 6879C8FC0C; Wed, 21 Dec 2011 10:41:32 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2288F25D37D1; Wed, 21 Dec 2011 10:41:31 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 43B92BD7774; Wed, 21 Dec 2011 10:41:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id wU6kvB0gSMc9; Wed, 21 Dec 2011 10:41:29 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3ABB1BD7773; Wed, 21 Dec 2011 10:41:29 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4EF1431B.8060909@FreeBSD.org> Date: Wed, 21 Dec 2011 10:41:28 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <4EF05CEC.6080603@orange.fr> <4EF1431B.8060909@FreeBSD.org> To: Claude Buisson X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org, FreeBSD Current Subject: Re: Is the svn2cvs gateway down ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 10:41:32 -0000 On 21. Dec 2011, at 02:23 , Doug Barton wrote: > On 12/20/2011 02:01, Claude Buisson wrote: >> Hi, >> >> It seems (from my own csup's and cvswe.cgi) that the src commits are lost, >> starting with r228697 Sun Dec 18 22:04:55 2011) > > Yeah, my warning 2 days ago that this was going to happen seems to have > gone un-heeded. :) I'm sure you can take bz' word that it's being > looked at now though. It's been fixed and the changes should propagate to cvsup mirrors close to everyone the next two hours. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 11:29:56 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 677191065670; Wed, 21 Dec 2011 11:29:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE068FC14; Wed, 21 Dec 2011 11:29:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18620; Wed, 21 Dec 2011 13:29:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RdKMo-000MV0-9f; Wed, 21 Dec 2011 13:29:50 +0200 Message-ID: <4EF1C32D.3070107@FreeBSD.org> Date: Wed, 21 Dec 2011 13:29:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> <4EF07EB0.9000209@FreeBSD.org> In-Reply-To: <4EF07EB0.9000209@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 11:29:56 -0000 on 20/12/2011 14:25 Andriy Gapon said the following: > I just wanted to draw your attention to the fact that obtaining any locks in the > kdb context (or USB polling code in general, even) is not a good idea. > Chances of getting into trouble on those locks are probably quite moderate or > even low, but they do exist. I am not sure if you are getting any bug reports > about such troubles :-) Regular users probably do not use kdb too often and a > panic for them is just a "crash", so they likely do not expect anything > usable/debuggable after that :-) Looking some more at the code I just got myself confused as to how the dumping to a umass device could work when the scheduler is stopped. It seems that the umass_command_start -> usbd_transfer_start -> usbd_callback_ss_done_defer functions would always put a transfer request onto a queue and try to wake up a thread to process that queue and the request. But that's obviously not going to work when the other thread is not going to be run. Have I missed a code path that leads directly to the controller in this context? Thank you for your help. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 11:39:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1360106564A; Wed, 21 Dec 2011 11:39:12 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 756998FC13; Wed, 21 Dec 2011 11:39:12 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 30089968A6; Wed, 21 Dec 2011 12:20:07 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id YP7KBeuKB5AO; Wed, 21 Dec 2011 12:20:01 +0100 (CET) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id B9A5A96889; Wed, 21 Dec 2011 12:20:01 +0100 (CET) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id pBLBK1Xd024814; Wed, 21 Dec 2011 12:20:01 +0100 (CET) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: , , X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 21 Dec 2011 12:20:01 +0100 From: Daniel Gerzo Organization: The FreeBSD Project Message-ID: <42b359617666a9ec8b47908964a5ee9e@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 Cc: Subject: REMAINDER: Call for FreeBSD Status Reports - 4Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 11:39:12 -0000 Dear all, I would like to remind you that the next round of status reports covering the fourth quarter of 2011 are due on January 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as sooner than later (holidays are quickly approaching), so that we can compile the report in a timely fashion. Do not hesitate and write a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome as well. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 09:05:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A19661065670 for ; Wed, 21 Dec 2011 09:05:22 +0000 (UTC) (envelope-from ftigeot@wolfpond.org) Received: from sabik.zefyris.com (sabik.zefyris.com [IPv6:2001:7a8:bd07:2::254]) by mx1.freebsd.org (Postfix) with ESMTP id 096D98FC0C for ; Wed, 21 Dec 2011 09:05:21 +0000 (UTC) Received: from sekishi.zefyris.com (sekishi.zefyris.com [IPv6:2001:7a8:bd07:2:219:d1ff:fe81:e03]) by sabik.zefyris.com (8.14.5/8.14.5) with ESMTP id pBL93wmI022217; Wed, 21 Dec 2011 10:03:58 +0100 (CET) Date: Wed, 21 Dec 2011 10:03:57 +0100 From: Francois Tigeot To: Jeremy Chadwick Message-ID: <20111221090357.GA982@sekishi.zefyris.com> References: <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF1121F.9010209@zedat.fu-berlin.de> <20111220232925.GA55953@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111220232925.GA55953@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (sabik.zefyris.com [IPv6:2001:7a8:bd07:2::254]); Wed, 21 Dec 2011 10:03:59 +0100 (CET) X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:57 +0000 Cc: "Samuel J. Greear" , freebsd-performance@freebsd.org, Current FreeBSD , FreeBSD Stable Mailing List , kernel@crater.dragonflybsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 09:05:22 -0000 On Tue, Dec 20, 2011 at 03:29:25PM -0800, Jeremy Chadwick wrote: > > This also interested me: > > * Linux system crashed > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html > > * OpenIndiana system crashed same way as Linux system > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html > > I cannot help but wonder if the Linux and OpenIndiana installations were > more stressful on the hardware -- getting more out of the system, maybe > resulting in increased power/load, which in turn resulted in the systems > locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). > > My point is that Francois states these things in such a way to imply > that "DragonflyBSD was more stable", Same thing can be said for FreeBSD, only Linux and OpenIndiana crashed reliably if I remember correctly. > when in fact I happen to wonder the > opposite point -- that is to say, Linux and OpenIndiana were trying to > use the hardware more-so than DragonflyBSD, thus tickled what may be a > hardware-level problem. I actually ran the benchmarks on two different machines with the same hardware -- brand new Supermicro boxes with ECC memory and no cut corners. Since then, I've found I could stop the Linux crashes by disabling some options in the BIOS setup: - advanced ACPI settings (don't remember exactly which ones) - and a new WHEA one. WHEA means Windows Hardware Error Architecture. For all I know, it may have been the only culprit but I didn't have time to verify if the machines also ran fine with only this option disabled. -- Francois Tigeot From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 12:55:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B2C106564A; Wed, 21 Dec 2011 12:55:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 667668FC14; Wed, 21 Dec 2011 12:55:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBLCte4G079069; Wed, 21 Dec 2011 16:55:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBLCteoS079068; Wed, 21 Dec 2011 16:55:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 21 Dec 2011 16:55:40 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <20111221125539.GF70684@glebius.int.ru> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111221015241.GE68792@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 12:55:42 -0000 Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B> While this is the documented path, it's not actually been required B> except in edge cases for ages (the last I can remember is a.out->elf). B> It's been long enough that I don't think we can really make people do B> it except for a short period of time in HEAD. I believe it's B> unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that "We almost certainly need to back r228571 out". The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions "dhclient", I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revision&revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revision&revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 13:17:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E59106566C for ; Wed, 21 Dec 2011 13:17:16 +0000 (UTC) (envelope-from VaNs9@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id E443D8FC15 for ; Wed, 21 Dec 2011 13:17:15 +0000 (UTC) Received: from web123.yandex.ru (web123.yandex.ru [95.108.130.101]) by forward12.mail.yandex.net (Yandex) with ESMTP id 97756C23F1D; Wed, 21 Dec 2011 17:17:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324473434; bh=bxDEGfzEpFk6Keh6ZTMByMy2cG53enQd/FgGIyzUW4s=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=qkveFDtkIRmEnfpQNeBxj0NXEDk0ht4k8noOdMTqMRbGhpzpyaqONKd4gZkCO2Ynq 4XsWPDgOFqoYftxz69y2ezQ4HFerrG8ndsU/snlIWyEFU3ZuxayNpF8/UuZAsSPVON rrQPw0lt3EZTIUa1yzKgeO5FUang/7X/gbRw4RzU= Received: from localhost (localhost.localdomain [127.0.0.1]) by web123.yandex.ru (Yandex) with ESMTP id 67E473680007; Wed, 21 Dec 2011 17:17:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324473434; bh=bxDEGfzEpFk6Keh6ZTMByMy2cG53enQd/FgGIyzUW4s=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=qkveFDtkIRmEnfpQNeBxj0NXEDk0ht4k8noOdMTqMRbGhpzpyaqONKd4gZkCO2Ynq 4XsWPDgOFqoYftxz69y2ezQ4HFerrG8ndsU/snlIWyEFU3ZuxayNpF8/UuZAsSPVON rrQPw0lt3EZTIUa1yzKgeO5FUang/7X/gbRw4RzU= X-Yandex-Spam: 1 Received: from [83.102.175.242] ([83.102.175.242]) by web123.yandex.ru with HTTP; Wed, 21 Dec 2011 17:17:13 +0400 From: N V To: O. Hartmann In-Reply-To: <4EF12815.2090805@zedat.fu-berlin.de> References: <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <4EF1121F.9010209@zedat.fu-berlin.de> <20111220232925.GA55953@icarus.home.lan> <4EF12815.2090805@zedat.fu-berlin.de> MIME-Version: 1.0 Message-Id: <33991324473433@web123.yandex.ru> Date: Wed, 21 Dec 2011 17:17:13 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: Current FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 13:17:16 -0000 21.12.2011, 04:28, "O. Hartmann" : > On 12/21/11 00:29, Jeremy Chadwick wrote: > >> šOn Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote: >>> šOn 12/20/11 22:45, Samuel J. Greear wrote: >>>> šhttp://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved >>>> >>>> šPostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux >>>> šand Solaris. Steps to reproduce these benchmarks provided. >>>> >>>> šSam >>>> >>>> šOn Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky wrote: >>>>> šInterestingly, while people seem to be (arguably rightly) focused on >>>>> šcriticising Phoronix's benchmarking, nobody has offered an alternative >>>>> šbenchmark; and while (again, arguably rightly) it is important to >>>>> šbenchmark real world performance, equally, nobody has offered any >>>>> šnumbers in relation to, for example, HTTP or SMTP, or any other "real >>>>> šworld"-application torture tests done on the aforementioned two >>>>> šplatforms... IMO, this just goes to show that "doing is hard" and >>>>> š"criticising is much easier" (yes, I am aware of the irony involved in >>>>> šmaking this statement, but someone has to!) >>>>> >>>>> šCheers, >>>>> šIgor M :-) >>>>> š_______________________________________________ >>>>> šfreebsd-current@freebsd.org mailing list >>>>> šhttp://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> šTo unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> šThanks for those numbers. >>> šImpressive how Matthew Dillon's project jumps forward now. And it is >>> šstill impressive to see that the picture is still in the right place >>> šwhen it comes to a comparison to Linux. >>> šAlso, OpenIndiana shows an impressive performance. >> šPreface to my long post below: >> >> šThe things being discussed here are benchmarks, as in "how much work >> šcan you get out of Thing". šThis is VERY DIFFERENT from testing >> šinteractivity in a scheduler, which is more of a test that says "when >> šThing X is executed while heavier-Thing Y is also being executed, how >> šmuch interaction is lost in Thing X". >> >> šThe reason people notice this when using Xorg is because it's visual, >> šin an environment where responsiveness is absolutely mandatory above all >> šelse. šNobody is going to put up with a system where during a buildworld >> šthey go to move a window or click a mouse button or type a key and find >> šthat the window doesn't move, the mouse click is lost, or the key typed >> šhas gone into the bit bucket -- or, that those things are SEVERELY >> šdelayed, to the point where interactivity is crap. > > I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD > servers (serving homes, NFS/SAMBA and PostgreSQL database (small)). > Those "seconds" where enough to cut a ssh line. Not funny. Network > traffic droped significantly. X/Desktop makes the problem visible, > indeed. But not seeing it does not mean it isn't there. > This might be the reason why FreeBSD is so much behind when it comes to X? > Well... Are you talking about FreeBSD being laggy with the X and other GUI staff? Well, am I so lucky to have great responsiveness and interactivity here in X with the FreeBSD? The interactiveness was one the reasons I've switched my desktop from Windows to *nix (specifically FreeBSD). >> šI just want to make that clear to folks. šThis immense thread has been .... Regards, Vans. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 15:32:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AEC3106566C; Wed, 21 Dec 2011 15:32:33 +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 61AB08FC0C; Wed, 21 Dec 2011 15:32:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 18E2A46B2A; Wed, 21 Dec 2011 10:32:33 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92331B93A; Wed, 21 Dec 2011 10:32:32 -0500 (EST) From: John Baldwin To: mdf@freebsd.org Date: Wed, 21 Dec 2011 10:31:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112201649.06265.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112211031.11977.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 10:32:32 -0500 (EST) Cc: Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:32:33 -0000 On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > > Hmm, if these functions are expected to operate like 'write(2)' and are > > supposed to return the number of bytes written, shouldn't their return value > > be 'ssize_t' instead of 'int'? It looks like the system calls themselves > > already do the right thing in setting td_retval[] (they assign a ssize_t to it > > and td_retval[0] can hold a ssize_t on all of our current platforms). It > > would seem that the only change would be to the header and probably > > syscalls.master. I guess this would require a symver bump to fix though. > > An extended attribute larger than 2GB is a programming abuse, though. > Technically int may not be 32 bits but it is on all supported > platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:02:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8611065676; Wed, 21 Dec 2011 16:02:26 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04CB58FC21; Wed, 21 Dec 2011 16:02:26 +0000 (UTC) Received: from c0144.aw.cl.cam.ac.uk (c0144.aw.cl.cam.ac.uk [128.232.100.144]) by cyrus.watson.org (Postfix) with ESMTPSA id 2BBE546B0D; Wed, 21 Dec 2011 11:02:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201112211031.11977.jhb@freebsd.org> Date: Wed, 21 Dec 2011 16:02:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <955AE804-4517-47ED-9C2A-EDA034BF1CB3@freebsd.org> References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: mdf@freebsd.org, current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:02:26 -0000 On 21 Dec 2011, at 15:31, John Baldwin wrote: > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: >> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin = wrote: >>> Hmm, if these functions are expected to operate like 'write(2)' and = are >>> supposed to return the number of bytes written, shouldn't their = return value >>> be 'ssize_t' instead of 'int'? It looks like the system calls = themselves >>> already do the right thing in setting td_retval[] (they assign a = ssize_t to it >>> and td_retval[0] can hold a ssize_t on all of our current = platforms). It >>> would seem that the only change would be to the header and probably >>> syscalls.master. I guess this would require a symver bump to fix = though. >>=20 >> An extended attribute larger than 2GB is a programming abuse, though. >> Technically int may not be 32 bits but it is on all supported >> platforms now. >=20 > Today it is an abuse. In the 90's a 64-bit off_t was considered an = abuse by > some. :) >=20 > The type should match the documented behavior. On OS X the set = operation > doesn't return a size but instead returns a simple success/failure (0 = or -1) > for which an int is appropriate. However, the FreeBSD API documents = that it > operates like write and consumes the buffer. Note that the size of = the > buffer passed to the 'set' and 'get' operations is a size_t, not an = int, and > the 'get' operations already return a ssize_t, not an int. Using an int was probably a bug. If we can switch to a ssize_t without = undue disruption, it seems worthwhile to do so. There was never EA API = standardisation, and it might be worth pondering whether to pick up = additional API variants matching Mac OS X or Linux (note that they = differ from each other even!). Robert= From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:13:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB164106566B; Wed, 21 Dec 2011 16:13:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9CF8FC19; Wed, 21 Dec 2011 16:13:17 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBLGDBVN095280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 18:13:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBLGDBqX077999; Wed, 21 Dec 2011 18:13:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBLGDAS7077998; Wed, 21 Dec 2011 18:13:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Dec 2011 18:13:10 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20111221161310.GW50300@deviant.kiev.zoral.com.ua> References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dekGTJBfK0OxIkXB" Content-Disposition: inline In-Reply-To: <201112211031.11977.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mdf@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:13:19 -0000 --dekGTJBfK0OxIkXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > > On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > > > Hmm, if these functions are expected to operate like 'write(2)' and a= re > > > supposed to return the number of bytes written, shouldn't their retur= n value > > > be 'ssize_t' instead of 'int'? It looks like the system calls themse= lves > > > already do the right thing in setting td_retval[] (they assign a ssiz= e_t to it > > > and td_retval[0] can hold a ssize_t on all of our current platforms).= It > > > would seem that the only change would be to the header and probably > > > syscalls.master. I guess this would require a symver bump to fix tho= ugh. > >=20 > > An extended attribute larger than 2GB is a programming abuse, though. > > Technically int may not be 32 bits but it is on all supported > > platforms now. >=20 > Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse= by > some. :) >=20 > The type should match the documented behavior. On OS X the set operation > doesn't return a size but instead returns a simple success/failure (0 or = -1) > for which an int is appropriate. However, the FreeBSD API documents that= it > operates like write and consumes the buffer. Note that the size of the > buffer passed to the 'set' and 'get' operations is a size_t, not an int, = and > the 'get' operations already return a ssize_t, not an int. Note that read(2)/write(2) do return int. I still have WIP patch to fix this, but after some conversations with Bruce I am not sure it is worth finishing. --dekGTJBfK0OxIkXB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7yBZYACgkQC3+MBN1Mb4jUzQCfR3CXwLMZ9MMWuxN+v8Llnox5 NFYAmgIns4Y1urAY5DTY5huLDk+//+vZ =Z0YS -----END PGP SIGNATURE----- --dekGTJBfK0OxIkXB-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:37:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 612EE106566B; Wed, 21 Dec 2011 16:37:23 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id EE5118FC1B; Wed, 21 Dec 2011 16:37:21 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id pBLGaFu6089664; Wed, 21 Dec 2011 10:36:15 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id pBLGaAuG089663; Wed, 21 Dec 2011 10:36:10 -0600 (CST) (envelope-from brooks) Date: Wed, 21 Dec 2011 10:36:10 -0600 From: Brooks Davis To: Gleb Smirnoff Message-ID: <20111221163610.GA89546@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20111221125539.GF70684@glebius.int.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:37:23 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 04:55:40PM +0400, Gleb Smirnoff wrote: > Brooks, >=20 > On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: > B> While this is the documented path, it's not actually been required > B> except in edge cases for ages (the last I can remember is a.out->elf). > B> It's been long enough that I don't think we can really make people do > B> it except for a short period of time in HEAD. I believe it's > B> unacceptable for a release to release upgrade. >=20 > I have provided API compatibility in r228768. I have tested it with an > ifconfig binary taken from 9.0 installation. I hope, this change > would satisfy you, and you won't say that "We almost certainly need to > back r228571 out". Thank you! I spoke too strongly there. I was worried that we would=20 end up in an untenable situation, but you appear to have resolved it. > The in_control() and in6_control() are getting more and more hairy :( > I'd eager to remove the shim in the 11.x timeline. > Since subject mentions "dhclient", I must notice that the dhclient-script > always relied on a bug in in_control(). The bug was fixed here: >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D228313 >=20 > Later the dhclient-script was fixed: >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D228463 >=20 > So, if we are claiming for an undocumented but important feature > that new kernel being capable to configure network with world from > a previous major release, then I should merge r228463 right now > to stable/9, and not merge r228313. >=20 > If I don't merge r228463 before 9.0-RELEASE is out, then in > 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with > world from 9.0-RELEASE. Thus, should I now either bribe re@ to push > r228463 prior to release, either back out the bugfix: r228463. You and bz have convinced me that for the configuration tools tools this change breaks, that it should be OK to have only supported 9.x releases (or possibly even only the last 9.x release) be able to upgrade without extra effort. I took too strong a position to start out. > Also, backing out r228463 would require backing out a larger > work: r228455. >=20 > Hey, this policy greatly discourages hacking on bugs and new > features... :( I hope we're approaching a more acceptable position... I don't want to discourage fixing bugs or adding features and more than having to deal with users inevitably does. -- Brooks --envbJBWh7q8WU6mo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8gr6XY6L6fI4GtQRAoI9AJ9DOTfVSMJaN7MM+5RTQ/tead7WzwCglqFc djBEiK3Ql5GwLrNOA+MGZl8= =pzqb -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:41:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8C9106564A; Wed, 21 Dec 2011 16:41:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id ED2418FC14; Wed, 21 Dec 2011 16:41:04 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 218858271; Wed, 21 Dec 2011 17:41:02 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 21 Dec 2011 17:38:36 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EEF2B11.6080802@FreeBSD.org> <4EF07EB0.9000209@FreeBSD.org> <4EF1C32D.3070107@FreeBSD.org> In-Reply-To: <4EF1C32D.3070107@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201112211738.36126.hselasky@c2i.net> Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:41:05 -0000 On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote: > on 20/12/2011 14:25 Andriy Gapon said the following: > > I just wanted to draw your attention to the fact that obtaining any locks > > in the kdb context (or USB polling code in general, even) is not a good > > idea. Chances of getting into trouble on those locks are probably quite > > moderate or even low, but they do exist. I am not sure if you are > > getting any bug reports about such troubles :-) Regular users probably > > do not use kdb too often and a panic for them is just a "crash", so they > > likely do not expect anything usable/debuggable after that :-) > > Looking some more at the code I just got myself confused as to how the > dumping to a umass device could work when the scheduler is stopped. > It seems that the umass_command_start -> usbd_transfer_start -> > usbd_callback_ss_done_defer functions would always put a transfer request > onto a queue and try to wake up a thread to process that queue and the > request. But that's obviously not going to work when the other thread is > not going to be run. Have I missed a code path that leads directly to the > controller in this context? Thank you for your help. Hi, Those threads should be polled when calling usbd_transfer_poll(). I.E. the wakeup should be stubbed in the !scheduler_running case. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 17:31:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFC7106564A; Wed, 21 Dec 2011 17:31:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 532C08FC08; Wed, 21 Dec 2011 17:31:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id E97E746B0A; Wed, 21 Dec 2011 12:31:33 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6BA8BB95D; Wed, 21 Dec 2011 12:31:33 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Wed, 21 Dec 2011 12:25:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> <20111221161310.GW50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111221161310.GW50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112211225.18581.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 12:31:33 -0500 (EST) Cc: mdf@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:31:34 -0000 On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote: > On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: > > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > > > On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > > > > Hmm, if these functions are expected to operate like 'write(2)' and are > > > > supposed to return the number of bytes written, shouldn't their return value > > > > be 'ssize_t' instead of 'int'? It looks like the system calls themselves > > > > already do the right thing in setting td_retval[] (they assign a ssize_t to it > > > > and td_retval[0] can hold a ssize_t on all of our current platforms). It > > > > would seem that the only change would be to the header and probably > > > > syscalls.master. I guess this would require a symver bump to fix though. > > > > > > An extended attribute larger than 2GB is a programming abuse, though. > > > Technically int may not be 32 bits but it is on all supported > > > platforms now. > > > > Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by > > some. :) > > > > The type should match the documented behavior. On OS X the set operation > > doesn't return a size but instead returns a simple success/failure (0 or -1) > > for which an int is appropriate. However, the FreeBSD API documents that it > > operates like write and consumes the buffer. Note that the size of the > > buffer passed to the 'set' and 'get' operations is a size_t, not an int, and > > the 'get' operations already return a ssize_t, not an int. > > Note that read(2)/write(2) do return int. I still have WIP patch to fix > this, but after some conversations with Bruce I am not sure it is worth > finishing. The manpages and /usr/include/unistd.h claim they return ssize_t. Is this related to the changes to make uio_resid a size_t (I thought that went into the tree)? If the problem is that the values read/write return may fall into the range of only an int even on 64-bit platforms, that is different from the return type which is part of the ABI. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 17:31:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC6B1065676; Wed, 21 Dec 2011 17:31:35 +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 E67FA8FC17; Wed, 21 Dec 2011 17:31:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 9CF0846B09; Wed, 21 Dec 2011 12:31:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E31CB962; Wed, 21 Dec 2011 12:31:34 -0500 (EST) From: John Baldwin To: "Robert N. M. Watson" Date: Wed, 21 Dec 2011 12:27:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> <955AE804-4517-47ED-9C2A-EDA034BF1CB3@freebsd.org> In-Reply-To: <955AE804-4517-47ED-9C2A-EDA034BF1CB3@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112211227.04868.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 12:31:34 -0500 (EST) Cc: mdf@freebsd.org, current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:31:35 -0000 On Wednesday, December 21, 2011 11:02:24 am Robert N. M. Watson wrote: > > On 21 Dec 2011, at 15:31, John Baldwin wrote: > > > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > >> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > >>> Hmm, if these functions are expected to operate like 'write(2)' and are > >>> supposed to return the number of bytes written, shouldn't their return value > >>> be 'ssize_t' instead of 'int'? It looks like the system calls themselves > >>> already do the right thing in setting td_retval[] (they assign a ssize_t to it > >>> and td_retval[0] can hold a ssize_t on all of our current platforms). It > >>> would seem that the only change would be to the header and probably > >>> syscalls.master. I guess this would require a symver bump to fix though. > >> > >> An extended attribute larger than 2GB is a programming abuse, though. > >> Technically int may not be 32 bits but it is on all supported > >> platforms now. > > > > Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by > > some. :) > > > > The type should match the documented behavior. On OS X the set operation > > doesn't return a size but instead returns a simple success/failure (0 or -1) > > for which an int is appropriate. However, the FreeBSD API documents that it > > operates like write and consumes the buffer. Note that the size of the > > buffer passed to the 'set' and 'get' operations is a size_t, not an int, and > > the 'get' operations already return a ssize_t, not an int. > > > Using an int was probably a bug. If we can switch to a ssize_t without undue disruption, it seems worthwhile to do so. There was never EA API standardisation, and it might be worth pondering whether to pick up additional API variants matching Mac OS X or Linux (note that they differ from each other even!). I think the system call already returns a ssize_t, so the only real change would be to change the header and bump the symver in userland leaving the old versions as still returning an int. I'm not even sure if that is strictly necessary or if we could get away with just changing the header and be done with it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 18:27:00 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15399106566C; Wed, 21 Dec 2011 18:27:00 +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 2E2278FC0C; Wed, 21 Dec 2011 18:26:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA26655; Wed, 21 Dec 2011 20:26:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RdQsP-000MrG-W6; Wed, 21 Dec 2011 20:26:54 +0200 Message-ID: <4EF224EC.9050101@FreeBSD.org> Date: Wed, 21 Dec 2011 20:26:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EEF2B11.6080802@FreeBSD.org> <4EF07EB0.9000209@FreeBSD.org> <4EF1C32D.3070107@FreeBSD.org> <201112211738.36126.hselasky@c2i.net> In-Reply-To: <201112211738.36126.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:27:00 -0000 on 21/12/2011 18:38 Hans Petter Selasky said the following: > On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote: >> on 20/12/2011 14:25 Andriy Gapon said the following: >>> I just wanted to draw your attention to the fact that obtaining any locks >>> in the kdb context (or USB polling code in general, even) is not a good >>> idea. Chances of getting into trouble on those locks are probably quite >>> moderate or even low, but they do exist. I am not sure if you are >>> getting any bug reports about such troubles :-) Regular users probably >>> do not use kdb too often and a panic for them is just a "crash", so they >>> likely do not expect anything usable/debuggable after that :-) >> >> Looking some more at the code I just got myself confused as to how the >> dumping to a umass device could work when the scheduler is stopped. >> It seems that the umass_command_start -> usbd_transfer_start -> >> usbd_callback_ss_done_defer functions would always put a transfer request >> onto a queue and try to wake up a thread to process that queue and the >> request. But that's obviously not going to work when the other thread is >> not going to be run. Have I missed a code path that leads directly to the >> controller in this context? Thank you for your help. > > Hi, > > Those threads should be polled when calling usbd_transfer_poll(). I.E. the > wakeup should be stubbed in the !scheduler_running case. Ah, that's what I missed! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 18:59:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C71B1065675; Wed, 21 Dec 2011 18:59:50 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B61A68FC0A; Wed, 21 Dec 2011 18:59:49 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4361F.dip.t-dialin.net [79.196.54.31]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 55F0784403D; Wed, 21 Dec 2011 19:42:52 +0100 (CET) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 1A97150F0; Wed, 21 Dec 2011 19:42:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1324492969; bh=4atfPkeMSYP08jaQLeAsPAUzgPt9uduUQPdLguW35so=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=nH/sPQat45+bMi41Grr+whSe0zk9MYPI+Ll4LEdACUMlwClXSa8DcdA2hPERD4z2y 0S5DEw4U9f4QcQjlJIqMqiQ0NcArnUysiOuN7DYc3D4GRUGXm3le6KbAUCI1Tzm2Dx y7mKFl9myH4tqNpZGF9hSSjM+SMTOVSeqT92s2NEnPd1/C7prjFLOtw3FTe+5EKZbc 2r220/+haMijMZtSW0MrOgyy+ofjLndWQtg6BMpmj83Ph49Ly0srfCLMB48TaZCYTx M8Ir833nE+lq+2aGSfqILCngLUbl5EwDoYM7sSsj4xJW7wwWibfIElbPVnsaecMZGv rReuxxLek/sOA== Date: Wed, 21 Dec 2011 19:41:47 +0100 Message-ID: Importance: normal From: Alexander Leidinger To: ohartman@zedat.fu-berlin.de, igor@hybrid-lab.co.uk MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 55F0784403D.A2C06 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.401, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SARE_ADLTSUB4 2.50) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1325097773.95682@UAS4O1xQyDoZUisA6ZeAIw X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd@jdc.parodius.com Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:59:50 -0000 SGksCgp3aGlsZSB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZWQgaGVyZSwgc29tZSB3b3JrIHN0YXJ0 ZWQgYXQgc29tZSBvdGhlciBwbGFjZS4gTm93Li4uIGluIGNhc2Ugc29tZW9uZSBoZXJlIGlzIHdp bGxpbmcgdG8gaGVscCBpbnN0ZWFkIG9mIHRhbGtpbmcsIGZlZWwgZnJlZSB0byBnbyB0byBodHRw Oi8vd2lraS5mcmVlYnNkLm9yZy9CZW5jaG1hcmtBZHZpY2UgYW5kIGhhdmUgYSBsb29rIHdoYXQg Y2FuIGJlIGltcHJvdmVkLiBUaGUgcGFnZSBpcyBmYXIgZnJvbSBwZXJmZWN0IGFuZCBuZWVkcyBz b21lIGFkZGl0aW9uYWwgcGVvcGxlIHdoaWNoIGFyZSB3aWxsaW5nIHRvIGltcHJvdmUgaXQuCgpU aGlzIGlzIG9ubHkgcGFydCBvZiB0aGUgcHJvYmxlbS4gQSB0dW5pbmcgcGFnZSBpbiB0aGUgd2lr aSAtIHdoaWNoIGNvdWxkIGJlIHJlZmVyZW5jZWQgZnJvbSB0aGUgYmVuY2htYXJrIHBhZ2UgLSB3 b3VsZCBiZSBncmVhdCB0b28uIEFueSB2b2x1bnRlZXJzPyBBIGZpcnN0IHN0ZXAgd291bGQgYmUg dG8gdGFrZSBoZSB0dW5pbmctbWFuLXBhZ2UgYW5kIHdpa2lmeSBpdC4gT3RoZXIgdHVuaW5nIHNv dXJjZXMgYXJlIHdlbGNvbWUgdG9vLgoKRXZlcnkgRnJlZUJTRCBkZXYgd2l0aCBhIHdpa2kgYWNj b3VudCBjYW4gaGFuZCBvdXQgd3JpdGUgYWNjZXNzIHRvIHRoZSB3aWtpLiBUaGUgYmVuY2htYXJr IHBhZ2UgZ2l2ZXMgY29udHJpYnV0b3ItYWNjZXNzLiBJZiBzb21lb25lIHdhbnRzIHdyaXRlIGFj Y2VzcyBjcmVhdGUgYSBGaXJzdG5hbWVMYXN0bmFtZSBhY2NvdW50IGFuZCBhc2sgaGVyZSBmb3Ig Y29udHJpYnV0b3ItYWNjZXNzLgoKRG9uJ3Qgd29ycnkgaWYgeW91IHRoaW5rIHlvdXIgZW5nbGlz aCBpcyBub3QgZ29vZCBlbm91Z2gsIGV2ZW4gc29tZSBvbmUtd29yZCBub3RlcyBjYW4gaGVscCAo YW5kIF9teV8gZW5nbGlzaCBnb3QgYWxyZWFkeSBjb3JyZWN0ZWQgYnkgb3RoZXIgcGVvcGxlIG9u IHRoZSBiZW5jaG1hcmsgcGFnZSkuCgpCeWUsCkFsZXhhbmRlci4KCi0tIApTZW5kIHZpYSBhbiBB bmRyb2lkIGRldmljZSwgcGxlYXNlIGZvcmdpdmUgYnJldml0eSBhbmQgdHlwb2dyYXBoaWMgYW5k IHNwZWxsaW5nIGVycm9ycy7CoCJPLiBIYXJ0bWFubiIgPG9oYXJ0bWFuQHplZGF0LmZ1LWJlcmxp bi5kZT4gaGF0IGdlc2NocmllYmVuOk9uIDEyLzIwLzExIDIxOjIwLCBJZ29yIE1vem9sZXZza3kg d3JvdGU6Cj4gSW50ZXJlc3RpbmdseSwgd2hpbGUgcGVvcGxlIHNlZW0gdG8gYmUgKGFyZ3VhYmx5 IHJpZ2h0bHkpIGZvY3VzZWQgb24KPiBjcml0aWNpc2luZyBQaG9yb25peCdzIGJlbmNobWFya2lu Zywgbm9ib2R5IGhhcyBvZmZlcmVkIGFuIGFsdGVybmF0aXZlCj4gYmVuY2htYXJrOyBhbmQgd2hp bGUgKGFnYWluLCBhcmd1YWJseSByaWdodGx5KSBpdCBpcyBpbXBvcnRhbnQgdG8KPiBiZW5jaG1h cmsgcmVhbCB3b3JsZCBwZXJmb3JtYW5jZSwgZXF1YWxseSwgbm9ib2R5IGhhcyBvZmZlcmVkIGFu eQo+IG51bWJlcnMgaW4gcmVsYXRpb24gdG8sIGZvciBleGFtcGxlLCBIVFRQIG9yIFNNVFAsIG9y IGFueSBvdGhlciAicmVhbAo+IHdvcmxkIi1hcHBsaWNhdGlvbiB0b3J0dXJlIHRlc3RzIGRvbmUg b24gdGhlIGFmb3JlbWVudGlvbmVkIHR3bwo+IHBsYXRmb3Jtcy4uLiBJTU8sIHRoaXMganVzdCBn b2VzIHRvIHNob3cgdGhhdCAiZG9pbmcgaXMgaGFyZCIgYW5kCj4gImNyaXRpY2lzaW5nIGlzIG11 Y2ggZWFzaWVyIiAoeWVzLCBJIGFtIGF3YXJlIG9mIHRoZSBpcm9ueSBpbnZvbHZlZCBpbgo+IG1h a2luZyB0aGlzIHN0YXRlbWVudCwgYnV0IHNvbWVvbmUgaGFzIHRvISkKPiAKPiAKPiBDaGVlcnMs Cj4gSWdvciBNIDotKQoKVW5mb3J0dW5hdGVseSwgTS4gTGFyYWJlbCBpcyB0aGUgb25seSBvbmUg d2hvJ3MgcGVyZm9ybWluZyBiZW5jaG1hcmtzIG9uCkZyZWVCU0QsIGNvbXBhcmluZyBpdHMgcGVy Zm9ybWFuY2UgdG8gdGhlIExpbnV4LW9wcG9uZW50cy4gQWRuIGluZGVlZCwKdGhlcmUgaXMgYSBs b3Qgb2YgY3JpdGljaXNtLCBidXQgbm8gYWx0ZXJuYXRpdmUuCkkgc2FpZCB1bmZvcnR1bmF0ZWx5 IC0gbm90IG9mZmVuc2l2ZSAtIHNpbmNlIExhcmFiZWwgYW5kIFBob3Jvbml4IGFyZQpzYWRseSB0 aGUgb25seSBvbmVzIHdobyBkbyBhY3R1YWxseSBzdWNoIGJlY2htYXJraW5nLgoKSXQgd291bGQg YmUgbXVjaCBtb3JlIG5pY2VyIGFuZCBraW5kIHRvIHN1cHBvcnQgdGhvc2UgcGVvcGxlLgoKV2Vs bCwgaW4gSmFudWFyeS9GZWJydWFyeSB3ZSBnZXQgbmV3IGhhcmR3YXJlLiBPbmUgYm94IGlzIHN1 cHBvc2VkIHRvIGRvCm51bWJlciBjcnVuY2hpbmcgdmlhIDEyIGNvcmVzIGFuZCBhIFRFU0xBIEdQ VS4gTXkgY29sbGVhZ3VlIGlzCmRldmVsb3BpbmcgYSBoaWdoIHBhcmFsbGVsaXplZCBwZWljZSBv ZiBzb2Z0d2FyZSBmb3Igc2F0ZWxsaXRlIGRhdGEKdHJhbnNmb3JtYXRpb24uIFRoZSBzb2Z0d2Fy ZSBwYWNrYWdlIGlzIENQVSBib3VuZCwgcGFydGlhbGx5IEdQVSwgYnV0Cm1hc3NpdmVseSBtZW1v cnkgaHVuZ3J5ICg5NiB0byAxMjggR0IgUkFNIGlzIG5lZWRlZCkuCldoYXQgSSBjYW4gb2ZmZXIg aXMsIHNpbmNlIEkgd2lsbCBhbHNvIHdvcmsgb24gdGhhdCBtYWNoaW5lIGFuZCBJJ3ZlCmZyZWUg aGFuZCB0byBhZG1pbmlzdGVyLCBpbiB0aGUgc3BhcmUgdGltZSBvZiBkb2luZyBteSBQaEQsIGlu c3RhbGxpbmcKRnJlZUJTRCA5LjAvMTAuMCBiZXNpZGVzIFN1U2UgTGludXggYW5kIGxvb2tpbmcg Zm9yd2FyZCBoYXZpbmcgb25lIFpGUwpkYXRhIHN0b3JhZ2UgZHJpdmUgZm9yIGhvbWVzLCBzbyBi b3RoIHN5c3RlbXMgY2FuIHBlcmZvcm0gb24gYSBtb3N0CnJlY2VudCBaRlMuIEknbSBuZXcgdG8g TGludXgsIG5vdCBhIEJTRCBndXJ1LCBub3IgSSdtIGEgcHJvZmVzc2lvbmFsCnByb2dyYW1tZXIv ZGV2ZWxvcGVyLiBNeSBza2lsbHMgYXJlIHN1ZmZpY2llbnQgZm9yIHRoZSBkYWlseSBzY2llbnRp ZmljCndvcmsuIFNvLCB3aXRob3V0IHByZXNzdXJlLCBJJ20gd2lsbGluZyB0byBwZXJmb3JtIHNv bWUgSFBDIGJlbmNobWFya3MKdW5kZXIgYWR2aWNlIGlmIHRoZSBkYXkgY29tZXMgYW5kIHRob3Nl IGludGVyZXN0ZWQgaW4gYmFyZSBudW1iZXJzIG9mCkZyZWVCU0QgdnMuIExpbnV4IHBlcmZvcm1h bmNlIHdpdGggYSByZWFsLXdvcmxkLXNjaWVudGlmaWMgYXBwbGljYXRpb24uCgpJIHdvdWxkIGFw cHJlY2lhdGUgdG8gc2VlIHNvbWUgb2YgdGhlIGRldmVsb3BlcnMgYW5kL29yIEZyZWVCU0QgaGFj a2Vycwp0byBoZWxwIFBob3Jvbml4IHNldHRpbmcgdXAgYSBwcm9wZXIgdGVzdGVudmlyb25tZW50 IGluc3RlYWQgb2YgYmFzaGluZwpNLiBMYXJhYmVsIGFuZCBoaXMgZmVsbG93cy4KClJlZ2FyZHMs Ck9saXZlcgoK From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:28:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3754B106566B; Wed, 21 Dec 2011 20:28:48 +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 BF8288FC08; Wed, 21 Dec 2011 20:28:47 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBLKShCm023539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 22:28:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBLKSh8p078777; Wed, 21 Dec 2011 22:28:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBLKSg3s078776; Wed, 21 Dec 2011 22:28:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Dec 2011 22:28:42 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20111221202842.GZ50300@deviant.kiev.zoral.com.ua> References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> <20111221161310.GW50300@deviant.kiev.zoral.com.ua> <201112211225.18581.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D8moR97HX12ax1eu" Content-Disposition: inline In-Reply-To: <201112211225.18581.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mdf@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 20:28:48 -0000 --D8moR97HX12ax1eu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 12:25:18PM -0500, John Baldwin wrote: > On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote: > > On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: > > > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > > > > On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wro= te: > > > > > Hmm, if these functions are expected to operate like 'write(2)' a= nd are > > > > > supposed to return the number of bytes written, shouldn't their r= eturn value > > > > > be 'ssize_t' instead of 'int'? It looks like the system calls th= emselves > > > > > already do the right thing in setting td_retval[] (they assign a = ssize_t to it > > > > > and td_retval[0] can hold a ssize_t on all of our current platfor= ms). It > > > > > would seem that the only change would be to the header and probab= ly > > > > > syscalls.master. I guess this would require a symver bump to fix= though. > > > >=20 > > > > An extended attribute larger than 2GB is a programming abuse, thoug= h. > > > > Technically int may not be 32 bits but it is on all supported > > > > platforms now. > > >=20 > > > Today it is an abuse. In the 90's a 64-bit off_t was considered an a= buse by > > > some. :) > > >=20 > > > The type should match the documented behavior. On OS X the set opera= tion > > > doesn't return a size but instead returns a simple success/failure (0= or -1) > > > for which an int is appropriate. However, the FreeBSD API documents = that it > > > operates like write and consumes the buffer. Note that the size of = the > > > buffer passed to the 'set' and 'get' operations is a size_t, not an i= nt, and > > > the 'get' operations already return a ssize_t, not an int. > >=20 > > Note that read(2)/write(2) do return int. I still have WIP patch to fix > > this, but after some conversations with Bruce I am not sure it is worth > > finishing. >=20 > The manpages and /usr/include/unistd.h claim they return ssize_t. Is this > related to the changes to make uio_resid a size_t (I thought that went in= to > the tree)? If the problem is that the values read/write return may fall = into > the range of only an int even on 64-bit platforms, that is different from= the > return type which is part of the ABI. Yes, it is related. The type change for uio was done in advance. Take a look at the first statement of sys_read() and sys_write(): if (uap->nbyte > INT_MAX) return (EINVAL); and at the copyinio(), which is used by scatter/gather versions of i/o syscalls to copy in uiovec: if (iov->iov_len > INT_MAX - uio->uio_resid) { free(uio, M_IOV); return (EINVAL); --D8moR97HX12ax1eu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7yQXoACgkQC3+MBN1Mb4jaOwCgkR+atYErjar9X+ZbW0IOkyPI tskAoKbp7C/X/oYD5lMUQgB81/vupuME =7385 -----END PGP SIGNATURE----- --D8moR97HX12ax1eu-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:35:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3FB32106564A; Wed, 21 Dec 2011 20:35:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DF1DC151252; Wed, 21 Dec 2011 20:35:23 +0000 (UTC) Message-ID: <4EF2430B.5070903@FreeBSD.org> Date: Wed, 21 Dec 2011 12:35:23 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> In-Reply-To: <20111221125539.GF70684@glebius.int.ru> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 20:35:24 -0000 On 12/21/2011 4:55 AM, Gleb Smirnoff wrote: > Brooks, > > On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: > B> While this is the documented path, it's not actually been required > B> except in edge cases for ages (the last I can remember is a.out->elf). > B> It's been long enough that I don't think we can really make people do > B> it except for a short period of time in HEAD. I believe it's > B> unacceptable for a release to release upgrade. > > I have provided API compatibility in r228768. I have tested it with an > ifconfig binary taken from 9.0 installation. So does that mean that if I upgrade to the latest HEAD from a system built before the ifconfig changes that when I reboot my network will come up? > I hope, this change > would satisfy you, and you won't say that "We almost certainly need to > back r228571 out". I think Brooks raised some really good points about backward compatibility, but it sounds to me like you've addressed them. In any case, my original concern was limited to "Do we need an UPDATING entry?" :) > The in_control() and in6_control() are getting more and more hairy :( > I'd eager to remove the shim in the 11.x timeline. > > > > Since subject mentions "dhclient", I must notice that the dhclient-script > always relied on a bug in in_control(). The bug was fixed here: > > http://svnweb.freebsd.org/base?view=revision&revision=228313 > > Later the dhclient-script was fixed: > > http://svnweb.freebsd.org/base?view=revision&revision=228463 Right, I saw those go by, which is why I tried not to jump too hard on "ifconfig is broken" since I wasn't sure which change was causing my problem. It sounds like you're saying that perhaps I still won't be able to get the network up after booting a new kernel without also installing part of the new world? Perhaps an UPDATING entry is needed after all? > Hey, this policy greatly discourages hacking on bugs and new > features... :( Learning how to innovate while providing backwards compatibility is a valuable skill. Think of this as an opportunity. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:36:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 162EA1065678; Wed, 21 Dec 2011 20:36:42 +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 DCD6A8FC12; Wed, 21 Dec 2011 20:36:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 93E8846B09; Wed, 21 Dec 2011 15:36:41 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 26E0EB964; Wed, 21 Dec 2011 15:36:41 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Wed, 21 Dec 2011 15:34:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112201649.06265.jhb@freebsd.org> <201112211225.18581.jhb@freebsd.org> <20111221202842.GZ50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111221202842.GZ50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112211534.18997.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Dec 2011 15:36:41 -0500 (EST) Cc: mdf@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 20:36:42 -0000 On Wednesday, December 21, 2011 3:28:42 pm Kostik Belousov wrote: > On Wed, Dec 21, 2011 at 12:25:18PM -0500, John Baldwin wrote: > > On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote: > > > On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: > > > > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: > > > > > On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote: > > > > > > Hmm, if these functions are expected to operate like 'write(2)' and are > > > > > > supposed to return the number of bytes written, shouldn't their return value > > > > > > be 'ssize_t' instead of 'int'? It looks like the system calls themselves > > > > > > already do the right thing in setting td_retval[] (they assign a ssize_t to it > > > > > > and td_retval[0] can hold a ssize_t on all of our current platforms). It > > > > > > would seem that the only change would be to the header and probably > > > > > > syscalls.master. I guess this would require a symver bump to fix though. > > > > > > > > > > An extended attribute larger than 2GB is a programming abuse, though. > > > > > Technically int may not be 32 bits but it is on all supported > > > > > platforms now. > > > > > > > > Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by > > > > some. :) > > > > > > > > The type should match the documented behavior. On OS X the set operation > > > > doesn't return a size but instead returns a simple success/failure (0 or -1) > > > > for which an int is appropriate. However, the FreeBSD API documents that it > > > > operates like write and consumes the buffer. Note that the size of the > > > > buffer passed to the 'set' and 'get' operations is a size_t, not an int, and > > > > the 'get' operations already return a ssize_t, not an int. > > > > > > Note that read(2)/write(2) do return int. I still have WIP patch to fix > > > this, but after some conversations with Bruce I am not sure it is worth > > > finishing. > > > > The manpages and /usr/include/unistd.h claim they return ssize_t. Is this > > related to the changes to make uio_resid a size_t (I thought that went into > > the tree)? If the problem is that the values read/write return may fall into > > the range of only an int even on 64-bit platforms, that is different from the > > return type which is part of the ABI. > Yes, it is related. The type change for uio was done in advance. > > Take a look at the first statement of sys_read() and sys_write(): > if (uap->nbyte > INT_MAX) > return (EINVAL); > and at the copyinio(), which is used by scatter/gather versions of i/o > syscalls to copy in uiovec: > if (iov->iov_len > INT_MAX - uio->uio_resid) { > free(uio, M_IOV); > return (EINVAL); Fair enough, but that is more of an implementation detail. The API/ABI is still correct and uses ssize_t. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:46:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDD7106566B; Wed, 21 Dec 2011 21:46:38 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8908FC16; Wed, 21 Dec 2011 21:45:36 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 16C19359316; Wed, 21 Dec 2011 22:43:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id DA02628468; Wed, 21 Dec 2011 22:43:44 +0100 (CET) Date: Wed, 21 Dec 2011 22:43:44 +0100 From: Jilles Tjoelker To: Gleb Smirnoff Message-ID: <20111221214344.GA83502@stack.nl> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <20111220192354.GB70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111220192354.GB70684@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 21:46:38 -0000 On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: > Considering r228571: we need to specify vhid as additional address > attribute in atomic manner, via one ioctl(). Address can't be first > configured, and then made redundant, that would lead it to being > static for a short period, sending gratutious ARP announcement, etc. > An assumption that we are not allowed to change ABI for our own tools > strongly discourages bringing in new features :( Consider changing to a more flexible ABI that does not need to be broken for new features. Examples are nmount(2)'s name-value pairs and GEOM's XML topology descriptions. This is initially more work and has poorer performance, but it may well be worth it. Process information reserves space in structures for future extension; this is less flexible but performs better (which matters somewhat). Another consideration is compatibility for 32-bit applications on 64-bit kernels; a good ABI design will minimize the amount of code needed to support that. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:49:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5234106564A for ; Wed, 21 Dec 2011 21:49:37 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9548FC18 for ; Wed, 21 Dec 2011 21:49:36 +0000 (UTC) Received: by eekc50 with SMTP id c50so9437868eek.13 for ; Wed, 21 Dec 2011 13:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=HrIXZVtVGF6kIQk7uu7yVVxTwgFVqjSDMGgJJCX5Ouo=; b=FLVCyQEBpLbOCbjmDZdDoKDyrThL7wJ2R9BUHC4aDb49R2eaH7eTblnn51Dqh7TDZG tl1LlYZQHou/iqfC6zU6/R71zXyy1RPwGaO6tjogcZ7Q4SrHfN4wXegUF58/gVL949ss OXVMk9jBagREUiCS0eGKFb9wkxY2lFYVnca5M= Received: by 10.213.10.65 with SMTP id o1mr1682557ebo.86.1324504174393; Wed, 21 Dec 2011 13:49:34 -0800 (PST) Received: from [192.168.1.12] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id 76sm25609324eeh.0.2011.12.21.13.49.32 (version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 13:49:33 -0800 (PST) Message-ID: <4EF25468.9040204@gmail.com> Date: Wed, 21 Dec 2011 22:49:28 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Leidinger , FreeBSD References: In-Reply-To: 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: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 21:49:37 -0000 Alexander Leidinger schreef: > Hi, > > while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. > > This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. > > Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. > > Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). > > Bye, > Alexander. > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. To compare it with Formula1 cars. If Mercedes decide to use the engine from 2 seasons back (the engine version 4.2.1) in there 2012 car, and Ferrari uses there new Engine (version 4.7). Can we not compare them anymore because of the decission from Mercedes to use the old engine? No we just say, if you want to win a race, get the Ferrari. It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. I my opinion, you benchmark the latest release of Linux, FreeBSD, Solaris, Windows and whatever OS you want to compare! You want to benchmark the release and not a tuned version against a standard version. And that in general are the versions most of us users will use. And what if in the future LLVM gets on par with Linux, is it stil fair to compare FreeBSD with Linux? Or do we say, well we are on par, but it is not fair, yes we used the latest releases, but you can not blame Linux because they are still using GCC. No what we will see then are haleluja blogs that FreeBSD is on par with Linux. For me peformance is not a show stopper, and for the most of us i think it is not. FreeBSD for me is a clean system that does the job perfect and has a very helpful community. regards, Johan From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:03:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11059106566B for ; Wed, 21 Dec 2011 22:03:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3B2E8FC0C for ; Wed, 21 Dec 2011 22:03:01 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so10758410vbb.13 for ; Wed, 21 Dec 2011 14:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=js6bD65PmfdGiIL5sFF18wlEcKAkAHoriR2JU1nhS18=; b=ExNfkqLj4OvpcuOtkxN3y0rx3y5bxGrfLBrFFFo+69r6unqqpS9wGeyNe5BCNeXQ+k tq/Q8BEaQuuf75JwGe3lJNTgOZGyWAoVi/xwP7i/B+6u9gaiS3Baz4c579Mjzvdjw6+Y tYIBOVDV+KUr8KH7iLeq7tM50RFw7T+6L/dSU= MIME-Version: 1.0 Received: by 10.52.94.6 with SMTP id cy6mr5220490vdb.28.1324504981115; Wed, 21 Dec 2011 14:03:01 -0800 (PST) Received: by 10.220.194.131 with HTTP; Wed, 21 Dec 2011 14:03:01 -0800 (PST) In-Reply-To: <4EF25468.9040204@gmail.com> References: <4EF25468.9040204@gmail.com> Date: Wed, 21 Dec 2011 14:03:01 -0800 Message-ID: From: Freddie Cash To: FreeBSD Content-Type: text/plain; charset=UTF-8 Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 22:03:02 -0000 On Wed, Dec 21, 2011 at 1:49 PM, Johan Hendriks wrote: > Nice page, but one thing i do not get is the following. > > [quote] > If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 > then the results are unlikely to tell you anything meaningful about FreeBSD > vs Ubuntu. > [/quote] > > That is a little strange in my opinion. > It tells me that FreeBSD falls more and more behind on Linux. > The reason is or could be that FreeBSD cannot or will not include GCC 4.7 > and that FreeBSD will not be on par with Linux anymore. When benchmarking two systems, you need to make sure that everything possible is the same (constants) and that the only differences between the two systems are what you want to benchmark (variables). For example, if you want to compare the performance of GCC-compiled binaries, then you would use the same hardware host, the same OS install, the same source code, and only change the compiler versions used to compile the "benchmark" binaries. That way, the only variable is "version of GCC", everything else is constant, and thus the benchmark is actually testing the performance of GCC. Likewise, if you want to benchmark the performance of two OSes, you need to eliminate as many variables as possible: - same hardware - running the same benchmark binaries - using the same versions of GCC - using the same filesystems - etc That gives you the starting point. Then, you modify one of the constants above, and re-run the benchmarks. Then you modify one more of the constants above, and re-run the benchmarks. Etc. Each time, you vary only 1 thing, so that you can measure the impact of that *ONE* thing. Comparing "random binary compile with GCC X on FreeBSD Y on filesystem Z on hardware config A" against "random binary built with GCC Q on Linux R on fileystem S on hardware config B" doesn't show anything. Was the performance difference due to hardware? Filesystem? OS? GCC version? Something else? You can't use a shotgun the thread a needle. :) > And what if in the future LLVM gets on par with Linux, is it stil fair to > compare FreeBSD with Linux? Then you add "compiler suite" to the list of variables, and you make it a constant in the first run, and then vary it one piece at a time in later runs, to isolate whether or not it affects performance. In order to do a proper comparison of any two "things", you have to first make them as equal as possible, and then vary things one bit at a time until you are at the "default" configuration for each. Only then can you really, truly, empirically say why A is better/faster/more-uber than B. Unfortunately, doing it "right" requires a lot of time, effort, time, and more time. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:09:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9D35106566B for ; Wed, 21 Dec 2011 22:09:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 92F7D8FC19 for ; Wed, 21 Dec 2011 22:09:25 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RdULk-000162-L6>; Wed, 21 Dec 2011 23:09:24 +0100 Received: from e178038211.adsl.alicedsl.de ([85.178.38.211] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RdULk-0005bw-Hj>; Wed, 21 Dec 2011 23:09:24 +0100 Message-ID: <4EF25913.50107@zedat.fu-berlin.de> Date: Wed, 21 Dec 2011 23:09:23 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.38.211 Subject: xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 22:09:25 -0000 OS: FreeBSD 10.0-CURRENT/amd64 r228787 Since the last update of world yesterday were I managed to compile the OS WITH_LIBCPLUSPLUS=YES in /etc/src.conf, only root is capable to login on the console. I use OpenLDAP 2.4 as the backend for usual users, having also an "emergency" user installed in the local /etc/passwd just in case. The problem is, I can not login via xdm or console login anymore as any usual user, even not as a user residing in the local passwd file. Trying to login as LDAP backed user, I get the error SASL/DIGEST-MD5 authentication started Login icorrect Inspecting /var/log/auth.log reveals for this incident login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such file or directory Trying tologin as a local (/etc/passwd backed) user gets sometimes the same login issue, but sporadically I get a login but landing in / instead of /home/user. /home is a ZFS volume. I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many times now since I suspected a fault in compilation (everything is compiled via CLANG), but I have no success. /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.so. It seems, that the OS can not find the homes on the ZFS volume. Doing a su - USER works for all LDAP users but not the local users, I receive the error su: no directory. This is very strange. While su - as root does not work, login as such a failing user work, but as mentioned without home. The last thing I did on that box is: I recompiled yesterday evening world, switched the box off. When I switched the box on today, I ran into this issue. I recompile the system without flag WITH_LIBCPLUSPLUS and see what is happening. Do others also see this strange behaviour? Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:34:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C032106566B for ; Wed, 21 Dec 2011 22:34:07 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F04D8FC18 for ; Wed, 21 Dec 2011 22:34:06 +0000 (UTC) Received: by dakp5 with SMTP id p5so7405285dak.13 for ; Wed, 21 Dec 2011 14:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=6TjhqpSWVgLVcHiKr1TZqlLxb2ZeQ6Kidx1BqyS1nu4=; b=umbKknPOESSPo5nMJsEGeEEt/keDF3Di3it7d+PfqE7Kmjt2qHrzh9mRTzGgZ49lFa +OTTMF19SPHZ+WDr7V/60d2CERWj2EHiwb7OiH0N/3GNoQ8DesK8DE5F3vxHSxlIV22+ FiRnzqTdXKkQXzC6ZUtZfpmTKLKotnGQc7Ju0= Received: by 10.68.74.227 with SMTP id x3mr16811455pbv.114.1324506846670; Wed, 21 Dec 2011 14:34:06 -0800 (PST) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.68.12.199 with HTTP; Wed, 21 Dec 2011 14:33:24 -0800 (PST) In-Reply-To: References: <4EF25468.9040204@gmail.com> From: Igor Mozolevsky Date: Wed, 21 Dec 2011 22:33:24 +0000 X-Google-Sender-Auth: g4u_P9THMuKh09I7IrHg0woBnV8 Message-ID: To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 22:34:07 -0000 On 21 December 2011 22:03, Freddie Cash wrote: > On Wed, Dec 21, 2011 at 1:49 PM, Johan Hendriks wrote: >> Nice page, but one thing i do not get is the following. >> >> [quote] >> If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 >> then the results are unlikely to tell you anything meaningful about FreeBSD >> vs Ubuntu. >> [/quote] >> >> That is a little strange in my opinion. >> It tells me that FreeBSD falls more and more behind on Linux. >> The reason is or could be that FreeBSD cannot or will not include GCC 4.7 >> and that FreeBSD will not be on par with Linux anymore. > > When benchmarking two systems, you need to make sure that everything > possible is the same (constants) and that the only differences between > the two systems are what you want to benchmark (variables). Yes and no, but to be perfectly frank, the statement, as it stands, is a bit of a nonsense. Let me illustrate in a different way. This is macro~ vs micro~comparison of systems and depends on what you are trying to get out of the benchmark. Using the same argument one can say that Ferrari F430 vs Toyota Prius is a meaningless comparison because the under-the-hood equipment is different. Now, it is absolutely correct to say that in A vs B comparisons, only one thing should be changed and the rest should remain constant. The important thing is, however, to determine the scope of your benchmark: you are not benchmarking a component of A vs a component of B, but you are benchmarking A as a whole system and B as a whole system. Thus, the thing that changes is the system itself. Going back to F430 vs Prius, you first decide what you want to benchmark (acceleration, top speed, fuel consumption, ride comfort, &c) then you measure that aspect in each of the system---you are not looking at the wiring, engine, wheels, &c individually but *at a whole system*. You use the same route, time of day, driver, drive pattern, weather conditions, &c, the only thing that changes is the car! Similarly, FreeBSD vs Linux, you want to a) determine what metric you want to benchmark (NFS throughput, HTTP client handling, SMPT throughput, prime number computation) and b) *scientifically* measure the system against that metric... This would essentially amount to having identical set up and tests, and only changing the hard disks (one containing Linux and another one containing FreeBSD). I don't see why this is such a difficult concept to grasp. Cheers, -- Igor M. :-) From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 23:26:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577EB106566C for ; Wed, 21 Dec 2011 23:26:19 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 163C48FC17 for ; Wed, 21 Dec 2011 23:26:18 +0000 (UTC) Received: by ggnp1 with SMTP id p1so8766718ggn.13 for ; Wed, 21 Dec 2011 15:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nWMPHpXL0UMl0gSnENLlWSi2von5MmuE9DSx6qfoY5E=; b=CPk1zcvG6D07PBOIR0cA3Fp8NutZrZwTrQHjZ4rb8BrNy1YYKqlAFPhmTXJNIbeux7 3rwG4w5CDoAHaWj3tbDgP3u4fgbn1NgAL35EY/10dDu5yNRdZsgSS6xqe4/7ERruowsC syFZ8jF91w8GmZP8+8RTnXSgmEN8G4Jri+5fQ= MIME-Version: 1.0 Received: by 10.50.160.194 with SMTP id xm2mr6045831igb.18.1324509977643; Wed, 21 Dec 2011 15:26:17 -0800 (PST) Received: by 10.231.211.78 with HTTP; Wed, 21 Dec 2011 15:26:17 -0800 (PST) In-Reply-To: <4EF25468.9040204@gmail.com> References: <4EF25468.9040204@gmail.com> Date: Thu, 22 Dec 2011 00:26:17 +0100 Message-ID: From: Daniel Nebdal To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 23:26:19 -0000 On Wed, Dec 21, 2011 at 10:49 PM, Johan Hendriks wrote: > Alexander Leidinger schreef: >> >> Hi, >> >> while the discussion continued here, some work started at some other >> place. Now... in case someone here is willing to help instead of talking, >> feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look >> what can be improved. The page is far from perfect and needs some additional >> people which are willing to improve it. >> >> This is only part of the problem. A tuning page in the wiki - which could >> be referenced from the benchmark page - would be great too. Any volunteers? >> A first step would be to take he tuning-man-page and wikify it. Other tuning >> sources are welcome too. >> >> Every FreeBSD dev with a wiki account can hand out write access to the >> wiki. The benchmark page gives contributor-access. If someone wants write >> access create a FirstnameLastname account and ask here for >> contributor-access. >> >> Don't worry if you think your english is not good enough, even some >> one-word notes can help (and _my_ english got already corrected by other >> people on the benchmark page). >> >> Bye, >> Alexander. > > Nice page, but one thing i do not get is the following. > > [quote] > If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 > then the results are unlikely to tell you anything meaningful about FreeBSD > vs Ubuntu. > [/quote] > > That is a little strange in my opinion. > It tells me that FreeBSD falls more and more behind on Linux. > The reason is or could be that FreeBSD cannot or will not include GCC 4.7 > and that FreeBSD will not be on par with Linux anymore. (...) It does, though? It's in ports. The system compiler is for the system, but if you're compiling ports or standalone software you certainly can - and sometimes must - use something else. The point of that section seems to be "if you're compiling userland software to compare, at least compile it with the same compiler, unless that's what you want to benchmark". Sensible enough. As for what the kernel is compiled with, I doubt that will have the same kind of effect as what the user software is compiled with. The kernel is compiled with very conservative settings anyway, and I don't think it really does much of the kind of heavy computation that benefits the most from better compilers. The most interesting part is probably the effect on the userland libraries. Has anyone done any tests on how much of an effect on user software performance it has if you change the compiler for the libraries in the base system? (I would guess "not massive", but this is one of those things where some numbers wouldn't hurt). Oh, and remember that clang also works as a system compiler, and we're definitely not stuck on an old version of that. It produces code with performance comparable to gcc today, and I doubt it'll fall horribly behind in the foreseeable future. -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 05:41:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F6F1065670 for ; Thu, 22 Dec 2011 05:41:41 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id B39E98FC08 for ; Thu, 22 Dec 2011 05:41:40 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBM5fUNq038933 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 22 Dec 2011 07:41:36 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF2C30A.9080209@digsys.bg> Date: Thu, 22 Dec 2011 07:41:30 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EF25468.9040204@gmail.com> In-Reply-To: <4EF25468.9040204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 05:41:41 -0000 On 21.12.11 23:49, Johan Hendriks wrote: > > I my opinion, you benchmark the latest release of Linux, FreeBSD, > Solaris, Windows and whatever OS you want to compare! > There is no 'general benchmark' as there is not one single tasks that all computers are used for. If you want to benchmark something, then you define that something, tune all test subjects appropriately for that one thing and run the same test load. You then go on and claim 'for task X, the OS Y was best, followed by ...'. This is what people have done for PostgreSQL for example. You may try to see how, with that same settings different OS will perform with varying conditions, like what the PostgreSQL test did -- performance over the network and performance to localhost. Testing a system, tuned for a file server as X workstations will not tell you much about the abilities of the different operating systems to run a web server, or either file server or X workstation. By the way, the gcc in 8-stable is gcc version 4.2.2 20070831 prerelease [FreeBSD] Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 05:54:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23576106564A for ; Thu, 22 Dec 2011 05:54:37 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9328FC14 for ; Thu, 22 Dec 2011 05:54:36 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBM5sR2C038968 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 22 Dec 2011 07:54:33 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF2C613.3020609@digsys.bg> Date: Thu, 22 Dec 2011 07:54:27 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EF25468.9040204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 05:54:37 -0000 On 22.12.11 00:33, Igor Mozolevsky wrote: > Using the same argument one can say that Ferrari F430 vs Toyota Prius > is a meaningless comparison because the under-the-hood equipment is > different. Of course, it is meaningless, the Ferrari will lose big time in the fuel consumption comparison! I believe it will also lose the price comparison as well. Not to speak the availability comparison. You say that comparison is meaningless, yet you intend to compare those two cars? Any 'benchmark' has a goal. You first define the goal and then measure how different contenders achieve it. Reaching the goal may have several measurable metrics, that you will use to later declare the winner in each. Besides, you need to define a baseline and be aware of what theoretical max/min values are possible. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 07:11:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A0B106564A for ; Thu, 22 Dec 2011 07:11:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by mx1.freebsd.org (Postfix) with SMTP id C34F28FC0C for ; Thu, 22 Dec 2011 07:11:19 +0000 (UTC) Received: from [98.139.214.32] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2011 07:11:19 -0000 Received: from [98.139.211.192] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2011 07:11:19 -0000 Received: from [127.0.0.1] by smtp201.mail.bf1.yahoo.com with NNFMP; 22 Dec 2011 07:11:19 -0000 X-Yahoo-Newman-Id: 12964.96740.bm@smtp201.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BkAAYKgVM1kooePWKH.bLjEl7nztkOBne14GxtXW3EYrO8S zbj3.t1KmUf85ZZ7dqcW8qva1MH3VoWKUbt_EunO2gwn50_HdIJe2NSYTX6O O8ZsbuceAIHA2phbwdhGLhAUUBXYuW0vk4C6f1OwCz6l4ijTIO5SsLSK4LLK cDlps_xFMCLCuqPzDjtDVLnFBUP822syjhLlzsjZLmrzLYvtlh.OUcYURluZ Z8DMDbX_KXiBqIS_s3gy3SznWgnFKqiYMYkksvGqPEYgeN.B9LZ0RtclzNq6 srxxKG5PzmoEpf3QTO3URNdroHkqXX6xEjOAckHGdZ6GhvHss2JRwU7p848J nVSSUka1b6b_tawUv3BZJC9C0VHQp8hTh5qpZAt6hiy0VtDYTDYRINz_PNYK fdVkqrGwMLr84780- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.146.47 with plain) by smtp201.mail.bf1.yahoo.com with SMTP; 21 Dec 2011 23:11:18 -0800 PST Message-ID: <4EF2D814.1090805@freebsd.org> Date: Thu, 22 Dec 2011 08:11:16 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Johan Hendriks References: <4EF25468.9040204@gmail.com> In-Reply-To: <4EF25468.9040204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 07:11:20 -0000 Am 21.12.2011 22:49, schrieb Johan Hendriks: > Nice page, but one thing i do not get is the following. > > [quote] > If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC > 4.7 then the results are unlikely to tell you anything meaningful about > FreeBSD vs Ubuntu. > [/quote] > > That is a little strange in my opinion. > It tells me that FreeBSD falls more and more behind on Linux. > The reason is or could be that FreeBSD cannot or will not include GCC > 4.7 and that FreeBSD will not be on par with Linux anymore. > To compare it with Formula1 cars. > If Mercedes decide to use the engine from 2 seasons back (the engine > version 4.2.1) in there 2012 car, and Ferrari uses there new Engine > (version 4.7). > Can we not compare them anymore because of the decission from Mercedes > to use the old engine? > No we just say, if you want to win a race, get the Ferrari. > > It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! As has been pointed out by others, FreeBSD ships with gcc-4.2.1 (with some local modifications and fixes) as the system compiler. > If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux > to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. The gcc version distributed with FreeBSD was chosen for license reasons, not for technical reasons. If you are OK with installing a GPLv3 licensed compiler on your systems, then just do it and take advantage of the improved code generated by it. > I my opinion, you benchmark the latest release of Linux, FreeBSD, > Solaris, Windows and whatever OS you want to compare! As you probably know, Linux is just the kernel and the distributions add user space programs, including a compiler. You can easily create a "FreeBSD distribution" with more advanced compiler and use or even sell it. But the FreeBSD project was cautious to not heavily depend on a GPLv3 compiler (for reasons openly discussed at the time this decision was made). > You want to benchmark the release and not a tuned version against a > standard version. > And that in general are the versions most of us users will use. If you compare operating systems from a technical point of view, then you'll be interested in relative performance of algorithms and methods chosen. This is best achieved by using the same compiler for each of the candidates. If you compare performance from a user point of view, you are correct that performance delivered out of the box (without complicated tuning) may be, what counts for most users. But those users that depend on best performance e.g. for a FreeBSD based embedded product or a data center, may tune the system, including compilation with a newer compiler than the system default. > And what if in the future LLVM gets on par with Linux, is it stil fair > to compare FreeBSD with Linux? You can always compare anything with whatever you like (even apples with oranges), but you need to be aware of what you compare and what your goals are, to be able to draw reasonable conclusions. If you want to test out of the box performance, then test with system compilers (or just those binaries delivered with the system). If you want to test for code efficiency or scalability, then use the same compilers for each system under test to remove differences introduced by the compilers (which are an external component not developed by the FreeBSD people). > Or do we say, well we are on par, but it is not fair, yes we used the > latest releases, but you can not blame Linux because they are still > using GCC. Depends on what you want or need to measure ... > No what we will see then are haleluja blogs that FreeBSD is on par with > Linux. Such blog messages are not common in the FreeBSD community. FreeBSD used to have big technical and performance advantages when Linux was young, but even then, there was technical discussion between camps (and many concepts were implemented in Linux based on BSD examples; I have taken part in such discussions myself, some 15 to 20 years back). > For me peformance is not a show stopper, and for the most of us i think > it is not. > FreeBSD for me is a clean system that does the job perfect and has a > very helpful community. Well, this are valid aspects, too, and very hard to with benchmarks ;-) Regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 07:20:58 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE28106566C; Thu, 22 Dec 2011 07:20:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 407E68FC08; Thu, 22 Dec 2011 07:20:58 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBM7KvAM087134; Thu, 22 Dec 2011 11:20:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBM7Kvj4087133; Thu, 22 Dec 2011 11:20:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 22 Dec 2011 11:20:57 +0400 From: Gleb Smirnoff To: Doug Barton Message-ID: <20111222072056.GJ80057@glebius.int.ru> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF2430B.5070903@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 07:20:59 -0000 On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D> > On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: D> > B> While this is the documented path, it's not actually been required D> > B> except in edge cases for ages (the last I can remember is a.out->elf). D> > B> It's been long enough that I don't think we can really make people do D> > B> it except for a short period of time in HEAD. I believe it's D> > B> unacceptable for a release to release upgrade. D> > D> > I have provided API compatibility in r228768. I have tested it with an D> > ifconfig binary taken from 9.0 installation. D> D> So does that mean that if I upgrade to the latest HEAD from a system D> built before the ifconfig changes that when I reboot my network will D> come up? Yes, older infconfig will work in "head < r228571 || head > r228768". D> I think Brooks raised some really good points about backward D> compatibility, but it sounds to me like you've addressed them. In any D> case, my original concern was limited to "Do we need an UPDATING entry?" :) r228571 put an updating entry. D> > Since subject mentions "dhclient", I must notice that the dhclient-script D> > always relied on a bug in in_control(). The bug was fixed here: D> > D> > http://svnweb.freebsd.org/base?view=revision&revision=228313 D> > D> > Later the dhclient-script was fixed: D> > D> > http://svnweb.freebsd.org/base?view=revision&revision=228463 D> D> Right, I saw those go by, which is why I tried not to jump too hard on D> "ifconfig is broken" since I wasn't sure which change was causing my D> problem. It sounds like you're saying that perhaps I still won't be able D> to get the network up after booting a new kernel without also installing D> part of the new world? Perhaps an UPDATING entry is needed after all? On the second thought, I understand that r228313 breaks the dhclient-script only for people running two DHCP interfaces. If one obtains default route, then second can't run dhclient. I'm afraid, if we would try to document every kernel<->userland API/ABI change in head/ in the UPDATING, then the file will grow extremely quickly, and still many issues will be forgotten to be added there. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 08:59:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38DAA106564A; Thu, 22 Dec 2011 08:59:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 93EC18FC0A; Thu, 22 Dec 2011 08:59:20 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC41BC5.dip.t-dialin.net [79.196.27.197]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3AA4E84400D; Thu, 22 Dec 2011 09:59:05 +0100 (CET) Received: from localhost (unknown [85.94.224.20]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 72A575185; Thu, 22 Dec 2011 09:59:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1324544342; bh=2MejN0TZcUjBpff0CAvdNRVlsNtwq8dDBlPq8lNFEMM=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=IygM1J9prlelqRXKGpyaJbbIMDiAKb7V0yct7YXa09RSn+TZ4pvLLHMHOdGl/IySe 0HoDaDGeQcuoI8w9GKpzSvwuy73bWaHU4L3cEqujOUDI16xotu8EaFFydCqqVWAuVY i4JQA7h7t1P+HPw1i46xo6208LEPl5Qff+A1mSDpEcpRBXLwURB/7T6uKGaaHYN6y7 IytdXTHGr3VyxTJK/6LKOlmMrsHL2O8nSKkJ+0u4KPo30cGKt6wNXm/vCRXb7Td1RE Z9SyOeHToU9Luzb/sgPWtFfypJoZK4qdMSsn1wSE3TZ40O5wCnNn99/t7rMj0w42Sz Z0a1bLb0mCRmA== Date: Thu, 22 Dec 2011 09:58:07 +0100 Message-ID: <5xrko6stknqhxsrycsotcctb.1324544287490@email.android.com> Importance: normal From: Alexander Leidinger To: se@freebsd.org, joh.hendriks@gmail.com MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3AA4E84400D.A17CF X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.401, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SARE_ADLTSUB4 2.50) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1325149146.57156@ANfG28PULN/WZvh49qpvOQ X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 08:59:21 -0000 SGksCgpJIGV4dGVuZGVkIHRoZSBnY2MgcGFydCBhIGxpdHRsZSBiaXQgdG8gbWFrZSBpdCBhIGxp dHRsZSBiaXQgbW9yZSBjbGVhciB3aGVuIGl0IG1hdHRlcnMuCgpCeWUsCkFsZXhhbmRlci4KCi0t IApTZW5kIHZpYSBhbiBBbmRyb2lkIGRldmljZSwgcGxlYXNlIGZvcmdpdmUgYnJldml0eSBhbmQg dHlwb2dyYXBoaWMgYW5kIHNwZWxsaW5nIGVycm9ycy4gCgpTdGVmYW4gRXNzZXIgPHNlQGZyZWVi c2Qub3JnPiBoYXQgZ2VzY2hyaWViZW46QW0gMjEuMTIuMjAxMSAyMjo0OSwgc2NocmllYiBKb2hh biBIZW5kcmlrczoKPiBOaWNlIHBhZ2UsIGJ1dCBvbmUgdGhpbmcgaSBkbyBub3QgZ2V0IGlzIHRo ZSBmb2xsb3dpbmcuCj4gCj4gW3F1b3RlXQo+IElmIHlvdSBjb21wYXJlIEZyZWVCU0QgLyBHQ0Mg NC4yLjEgYWdhaW5zdCwgZm9yIGV4YW1wbGUsIFVidW50dSAvIEdDQwo+IDQuNyB0aGVuIHRoZSBy ZXN1bHRzIGFyZSB1bmxpa2VseSB0byB0ZWxsIHlvdSBhbnl0aGluZyBtZWFuaW5nZnVsIGFib3V0 Cj4gRnJlZUJTRCB2cyBVYnVudHUuCj4gWy9xdW90ZV0KPiAKPiBUaGF0IGlzIGEgbGl0dGxlIHN0 cmFuZ2UgaW4gbXkgb3Bpbmlvbi4KPiBJdCB0ZWxscyBtZSB0aGF0IEZyZWVCU0QgZmFsbHMgbW9y ZSBhbmQgbW9yZSBiZWhpbmQgb24gTGludXguCj4gVGhlIHJlYXNvbiBpcyBvciBjb3VsZCBiZSB0 aGF0IEZyZWVCU0QgY2Fubm90IG9yIHdpbGwgbm90IGluY2x1ZGUgR0NDCj4gNC43IGFuZCB0aGF0 IEZyZWVCU0Qgd2lsbCBub3QgYmUgb24gcGFyIHdpdGggTGludXggYW55bW9yZS4KPiBUbyBjb21w YXJlIGl0IHdpdGggRm9ybXVsYTEgY2Fycy4KPiBJZiBNZXJjZWRlcyBkZWNpZGUgdG8gdXNlIHRo ZSBlbmdpbmUgZnJvbSAyIHNlYXNvbnMgYmFjayAodGhlIGVuZ2luZQo+IHZlcnNpb24gNC4yLjEp IGluIHRoZXJlIDIwMTIgY2FyLCBhbmQgRmVycmFyaSB1c2VzIHRoZXJlIG5ldyBFbmdpbmUKPiAo dmVyc2lvbiA0LjcpLgo+IENhbiB3ZSBub3QgY29tcGFyZSB0aGVtIGFueW1vcmUgYmVjYXVzZSBv ZiB0aGUgZGVjaXNzaW9uIGZyb20gTWVyY2VkZXMKPiB0byB1c2UgdGhlIG9sZCBlbmdpbmU/Cj4g Tm8gd2UganVzdCBzYXksIGlmIHlvdSB3YW50IHRvIHdpbiBhIHJhY2UsIGdldCB0aGUgRmVycmFy aS4KPiAKPiBJdCBpcyB0aGUgcmVhbGxpdHksIEZyZWVCU0QgdXNlcyA0LjIuMSBhcyB0aGVyZSBj b21waWxlciEhIQoKQXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgYnkgb3RoZXJzLCBGcmVlQlNEIHNo aXBzIHdpdGggZ2NjLTQuMi4xICh3aXRoCnNvbWUgbG9jYWwgbW9kaWZpY2F0aW9ucyBhbmQgZml4 ZXMpIGFzIHRoZSBzeXN0ZW0gY29tcGlsZXIuCgo+IElmIHlvdSB0dW5lIHVwIEZyZWVCU0QgdG8g dXNlIHRoZSBHQ0MgNC43IGNvbXBpbGVyLCBvciBkb3duZ3JhZGUgbGludXgKPiB0byA0LjIuMSwg dGhlbiB0aGF0IHdpbGwgdGVsbCBtZSBub3RoaW5nIGFib3V0IEZyZWVCU0QgdnMgTGludXguCgpU aGUgZ2NjIHZlcnNpb24gZGlzdHJpYnV0ZWQgd2l0aCBGcmVlQlNEIHdhcyBjaG9zZW4gZm9yIGxp Y2Vuc2UgcmVhc29ucywKbm90IGZvciB0ZWNobmljYWwgcmVhc29ucy4gSWYgeW91IGFyZSBPSyB3 aXRoIGluc3RhbGxpbmcgYSBHUEx2MwpsaWNlbnNlZCBjb21waWxlciBvbiB5b3VyIHN5c3RlbXMs IHRoZW4ganVzdCBkbyBpdCBhbmQgdGFrZSBhZHZhbnRhZ2Ugb2YKdGhlIGltcHJvdmVkIGNvZGUg Z2VuZXJhdGVkIGJ5IGl0LgoKPiBJIG15IG9waW5pb24sIHlvdSBiZW5jaG1hcmsgdGhlIGxhdGVz dCByZWxlYXNlIG9mIExpbnV4LCBGcmVlQlNELAo+IFNvbGFyaXMsIFdpbmRvd3MgYW5kIHdoYXRl dmVyIE9TIHlvdSB3YW50IHRvIGNvbXBhcmUhCgpBcyB5b3UgcHJvYmFibHkga25vdywgTGludXgg aXMganVzdCB0aGUga2VybmVsIGFuZCB0aGUgZGlzdHJpYnV0aW9ucyBhZGQKdXNlciBzcGFjZSBw cm9ncmFtcywgaW5jbHVkaW5nIGEgY29tcGlsZXIuIFlvdSBjYW4gZWFzaWx5IGNyZWF0ZSBhCiJG cmVlQlNEIGRpc3RyaWJ1dGlvbiIgd2l0aCBtb3JlIGFkdmFuY2VkIGNvbXBpbGVyIGFuZCB1c2Ug b3IgZXZlbiBzZWxsCml0LiBCdXQgdGhlIEZyZWVCU0QgcHJvamVjdCB3YXMgY2F1dGlvdXMgdG8g bm90IGhlYXZpbHkgZGVwZW5kIG9uIGEKR1BMdjMgY29tcGlsZXIgKGZvciByZWFzb25zIG9wZW5s eSBkaXNjdXNzZWQgYXQgdGhlIHRpbWUgdGhpcyBkZWNpc2lvbgp3YXMgbWFkZSkuCgo+IFlvdSB3 YW50IHRvIGJlbmNobWFyayB0aGUgcmVsZWFzZSBhbmQgbm90IGEgdHVuZWQgdmVyc2lvbiBhZ2Fp bnN0IGEKPiBzdGFuZGFyZCB2ZXJzaW9uLgo+IEFuZCB0aGF0IGluIGdlbmVyYWwgYXJlIHRoZSB2 ZXJzaW9ucyBtb3N0IG9mIHVzIHVzZXJzIHdpbGwgdXNlLgoKSWYgeW91IGNvbXBhcmUgb3BlcmF0 aW5nIHN5c3RlbXMgZnJvbSBhIHRlY2huaWNhbCBwb2ludCBvZiB2aWV3LCB0aGVuCnlvdSdsbCBi ZSBpbnRlcmVzdGVkIGluIHJlbGF0aXZlIHBlcmZvcm1hbmNlIG9mIGFsZ29yaXRobXMgYW5kIG1l dGhvZHMKY2hvc2VuLiBUaGlzIGlzIGJlc3QgYWNoaWV2ZWQgYnkgdXNpbmcgdGhlIHNhbWUgY29t cGlsZXIgZm9yIGVhY2ggb2YgdGhlCmNhbmRpZGF0ZXMuCgpJZiB5b3UgY29tcGFyZSBwZXJmb3Jt YW5jZSBmcm9tIGEgdXNlciBwb2ludCBvZiB2aWV3LCB5b3UgYXJlIGNvcnJlY3QKdGhhdCBwZXJm b3JtYW5jZSBkZWxpdmVyZWQgb3V0IG9mIHRoZSBib3ggKHdpdGhvdXQgY29tcGxpY2F0ZWQgdHVu aW5nKQptYXkgYmUsIHdoYXQgY291bnRzIGZvciBtb3N0IHVzZXJzLiBCdXQgdGhvc2UgdXNlcnMg dGhhdCBkZXBlbmQgb24gYmVzdApwZXJmb3JtYW5jZSBlLmcuIGZvciBhIEZyZWVCU0QgYmFzZWQg ZW1iZWRkZWQgcHJvZHVjdCBvciBhIGRhdGEgY2VudGVyLAptYXkgdHVuZSB0aGUgc3lzdGVtLCBp bmNsdWRpbmcgY29tcGlsYXRpb24gd2l0aCBhIG5ld2VyIGNvbXBpbGVyIHRoYW4KdGhlIHN5c3Rl bSBkZWZhdWx0LgoKPiBBbmQgd2hhdCBpZiBpbiB0aGUgZnV0dXJlIExMVk0gZ2V0cyBvbiBwYXIg d2l0aCBMaW51eCwgaXMgaXQgc3RpbCBmYWlyCj4gdG8gY29tcGFyZSBGcmVlQlNEIHdpdGggTGlu dXg/CgpZb3UgY2FuIGFsd2F5cyBjb21wYXJlIGFueXRoaW5nIHdpdGggd2hhdGV2ZXIgeW91IGxp a2UgKGV2ZW4gYXBwbGVzIHdpdGgKb3JhbmdlcyksIGJ1dCB5b3UgbmVlZCB0byBiZSBhd2FyZSBv ZiB3aGF0IHlvdSBjb21wYXJlIGFuZCB3aGF0IHlvdXIKZ29hbHMgYXJlLCB0byBiZSBhYmxlIHRv IGRyYXcgcmVhc29uYWJsZSBjb25jbHVzaW9ucy4KCklmIHlvdSB3YW50IHRvIHRlc3Qgb3V0IG9m IHRoZSBib3ggcGVyZm9ybWFuY2UsIHRoZW4gdGVzdCB3aXRoIHN5c3RlbQpjb21waWxlcnMgKG9y IGp1c3QgdGhvc2UgYmluYXJpZXMgZGVsaXZlcmVkIHdpdGggdGhlIHN5c3RlbSkuCgpJZiB5b3Ug d2FudCB0byB0ZXN0IGZvciBjb2RlIGVmZmljaWVuY3kgb3Igc2NhbGFiaWxpdHksIHRoZW4gdXNl IHRoZQpzYW1lIGNvbXBpbGVycyBmb3IgZWFjaCBzeXN0ZW0gdW5kZXIgdGVzdCB0byByZW1vdmUg ZGlmZmVyZW5jZXMKaW50cm9kdWNlZCBieSB0aGUgY29tcGlsZXJzICh3aGljaCBhcmUgYW4gZXh0 ZXJuYWwgY29tcG9uZW50IG5vdApkZXZlbG9wZWQgYnkgdGhlIEZyZWVCU0QgcGVvcGxlKS4KCj4g T3IgZG8gd2Ugc2F5LCB3ZWxsIHdlIGFyZSBvbiBwYXIsIGJ1dCBpdCBpcyBub3QgZmFpciwgeWVz IHdlIHVzZWQgdGhlCj4gbGF0ZXN0IHJlbGVhc2VzLCBidXQgeW91IGNhbiBub3QgYmxhbWUgTGlu dXggYmVjYXVzZSB0aGV5IGFyZSBzdGlsbAo+IHVzaW5nIEdDQy4KCkRlcGVuZHMgb24gd2hhdCB5 b3Ugd2FudCBvciBuZWVkIHRvIG1lYXN1cmUgLi4uCgo+IE5vIHdoYXQgd2Ugd2lsbCBzZWUgdGhl biBhcmUgaGFsZWx1amEgYmxvZ3MgdGhhdCBGcmVlQlNEIGlzIG9uIHBhciB3aXRoCj4gTGludXgu CgpTdWNoIGJsb2cgbWVzc2FnZXMgYXJlIG5vdCBjb21tb24gaW4gdGhlIEZyZWVCU0QgY29tbXVu aXR5LiBGcmVlQlNEIHVzZWQKdG8gaGF2ZSBiaWcgdGVjaG5pY2FsIGFuZCBwZXJmb3JtYW5jZSBh ZHZhbnRhZ2VzIHdoZW4gTGludXggd2FzIHlvdW5nLApidXQgZXZlbiB0aGVuLCB0aGVyZSB3YXMg dGVjaG5pY2FsIGRpc2N1c3Npb24gYmV0d2VlbiBjYW1wcyAoYW5kIG1hbnkKY29uY2VwdHMgd2Vy ZSBpbXBsZW1lbnRlZCBpbiBMaW51eCBiYXNlZCBvbiBCU0QgZXhhbXBsZXM7IEkgaGF2ZSB0YWtl bgpwYXJ0IGluIHN1Y2ggZGlzY3Vzc2lvbnMgbXlzZWxmLCBzb21lIDE1IHRvIDIwIHllYXJzIGJh Y2spLgoKPiBGb3IgbWUgcGVmb3JtYW5jZSBpcyBub3QgYSBzaG93IHN0b3BwZXIsIGFuZCBmb3Ig dGhlIG1vc3Qgb2YgdXMgaSB0aGluawo+IGl0IGlzIG5vdC4KPiBGcmVlQlNEIGZvciBtZSBpcyBh IGNsZWFuIHN5c3RlbSB0aGF0IGRvZXMgdGhlIGpvYiBwZXJmZWN0IGFuZCBoYXMgYQo+IHZlcnkg aGVscGZ1bCBjb21tdW5pdHkuCgpXZWxsLCB0aGlzIGFyZSB2YWxpZCBhc3BlY3RzLCB0b28sIGFu ZCB2ZXJ5IGhhcmQgdG8gd2l0aCBiZW5jaG1hcmtzIDstKQoKUmVnYXJkcywgU1RlZmFuCgo= From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 09:02:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65531106564A; Thu, 22 Dec 2011 09:02:14 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 980F28FC12; Thu, 22 Dec 2011 09:02:13 +0000 (UTC) Received: by eekc50 with SMTP id c50so9809420eek.13 for ; Thu, 22 Dec 2011 01:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lcRMPrs+3w+ydAYDUCv0/m8WM6cS/ycLzk5u+ruyJsA=; b=s2h7l+Hc849e+KIBG7o3PbxxVJSJTYz98FA94uhkG+QhOX1/Mk+8m8D2tX4wjaxlvn xvbZXqtnedUs8nycKYeFEPQ3t7IWJXJRF77z8kBDvq+N/0MOeWrs55hB4xB0/XwMAhGx MEPbyQvy29Leg8M2xr9kpLr8R9p3HmyLRDC9E= Received: by 10.14.95.9 with SMTP id o9mr4021583eef.125.1324544532713; Thu, 22 Dec 2011 01:02:12 -0800 (PST) Received: from [192.168.50.104] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id 76sm31701142eeh.0.2011.12.22.01.02.11 (version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 01:02:11 -0800 (PST) Message-ID: <4EF2F210.6080009@gmail.com> Date: Thu, 22 Dec 2011 10:02:08 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stefan Esser , FreeBSD References: <4EF25468.9040204@gmail.com> <4EF2D814.1090805@freebsd.org> In-Reply-To: <4EF2D814.1090805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 09:02:14 -0000 Stefan Esser schreef: > Am 21.12.2011 22:49, schrieb Johan Hendriks: >> Nice page, but one thing i do not get is the following. >> >> [quote] >> If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC >> 4.7 then the results are unlikely to tell you anything meaningful about >> FreeBSD vs Ubuntu. >> [/quote] >> >> That is a little strange in my opinion. >> It tells me that FreeBSD falls more and more behind on Linux. >> The reason is or could be that FreeBSD cannot or will not include GCC >> 4.7 and that FreeBSD will not be on par with Linux anymore. >> To compare it with Formula1 cars. >> If Mercedes decide to use the engine from 2 seasons back (the engine >> version 4.2.1) in there 2012 car, and Ferrari uses there new Engine >> (version 4.7). >> Can we not compare them anymore because of the decission from Mercedes >> to use the old engine? >> No we just say, if you want to win a race, get the Ferrari. >> >> It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! > As has been pointed out by others, FreeBSD ships with gcc-4.2.1 (with > some local modifications and fixes) as the system compiler. >> If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux >> to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. > The gcc version distributed with FreeBSD was chosen for license reasons, > not for technical reasons. If you are OK with installing a GPLv3 > licensed compiler on your systems, then just do it and take advantage of > the improved code generated by it. It does not matter what the decission is to use the old compiler, it is a fact that the base comes with 4.2.x Does that mean we can not compare/benchmark against other distributions because they use GPLv3 stuff. No, i want to know where standard released FreeBSD stands against standard released Linux distributions. If you compare benchmark userland applictions, then it is fair to use the latest compiler for the userland software also on FreeBSD. But what if the ports tree defaults to LLVM, then again we want to know what FreeBSD does against a Linux distribution. Why because that is what most of us will be using...!! If we start to compile all the ports with gcc 4.7 to be on par in comparising and benchmarking, why spend all the time getting LLVM as the default compiler for ports also? Why not take that effort into making the WHOLE ports tree to compile with GCC4.7? Reason, because FreeBSD goes the LLVM route. That is a decission FreeBSD is making! And that choise will be the FreeBSD that is used in comparising and benchmarks on the net , not the utterly overcopiled and tuned FreeBSD against stock Ubuntu or whatever Linux distribution. If it is a good or bad choice! That we will see in the comparising/benchmarks we will be seeing when that time comes. Same goes for the scheduler! and all the other subsystems FreeBSD has choosen, that makes FreeBSD. > >> I my opinion, you benchmark the latest release of Linux, FreeBSD, >> Solaris, Windows and whatever OS you want to compare! > As you probably know, Linux is just the kernel and the distributions add > user space programs, including a compiler. You can easily create a > "FreeBSD distribution" with more advanced compiler and use or even sell > it. But the FreeBSD project was cautious to not heavily depend on a > GPLv3 compiler (for reasons openly discussed at the time this decision > was made). I know Linux is a kernel, re read Linux as Linux Distribution! Yes you can use a more advanced compiler on FreeBSD, BUT you can do that on Linux also ,so where do you stop? Are you going to spend a month to compare a fullly tuned up FreeBSD system against a Linux distribution? No because the users will not spend months tuning and recompile there servers. They use the FreeBSD version that comes with the CD! And that we want to compare/benchmark against a Linux distribution. >> You want to benchmark the release and not a tuned version against a >> standard version. >> And that in general are the versions most of us users will use. > If you compare operating systems from a technical point of view, then > you'll be interested in relative performance of algorithms and methods > chosen. This is best achieved by using the same compiler for each of the > candidates. > > If you compare performance from a user point of view, you are correct > that performance delivered out of the box (without complicated tuning) > may be, what counts for most users. But those users that depend on best > performance e.g. for a FreeBSD based embedded product or a data center, > may tune the system, including compilation with a newer compiler than > the system default. > >> And what if in the future LLVM gets on par with Linux, is it stil fair >> to compare FreeBSD with Linux? > You can always compare anything with whatever you like (even apples with > oranges), but you need to be aware of what you compare and what your > goals are, to be able to draw reasonable conclusions. > > If you want to test out of the box performance, then test with system > compilers (or just those binaries delivered with the system). > > If you want to test for code efficiency or scalability, then use the > same compilers for each system under test to remove differences > introduced by the compilers (which are an external component not > developed by the FreeBSD people). > >> Or do we say, well we are on par, but it is not fair, yes we used the >> latest releases, but you can not blame Linux because they are still >> using GCC. > Depends on what you want or need to measure ... I am mainly talking about the out of the box comparison, because that is what most sites will do when doing a benchmark. they want to know if the the all new version of FreeBSD can compete with the latest release of Ubuntu. That are the benchmarks you will see on the net. >> No what we will see then are haleluja blogs that FreeBSD is on par with >> Linux. > Such blog messages are not common in the FreeBSD community. FreeBSD used > to have big technical and performance advantages when Linux was young, > but even then, there was technical discussion between camps (and many > concepts were implemented in Linux based on BSD examples; I have taken > part in such discussions myself, some 15 to 20 years back). Well not quite, i remember the mysql on SCHED_ULE reports, and they where quit haleluja about the whole thing. Not wrong at all, we are all human and like to compete and even more like to be on top in what we do. >> For me peformance is not a show stopper, and for the most of us i think >> it is not. >> FreeBSD for me is a clean system that does the job perfect and has a >> very helpful community. > Well, this are valid aspects, too, and very hard to with benchmarks ;-) > > Regards, STefan I am not saying FreeBSD is bad and is not performing, i just do not understand why FreeBSD is doing all these things to look good. Again, most comparisings/benchmarks will be stock *BSD vs a stock Linux distribution. If we want to look good, FreeBSD must make sure there released version gets on par! We all know FreeBSD is quite conservative with its default settings. Maybe we need to set some default settings less conservative. But i do not know if that is good just for the numbers! Regards, Johan From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 09:36:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3452D106566B; Thu, 22 Dec 2011 09:36:11 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E16738FC16; Thu, 22 Dec 2011 09:36:10 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so6096185obb.13 for ; Thu, 22 Dec 2011 01:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZnYasLkDUxpMiXZ9yQkrNIxCeZOQXxjzfSwxNC5vKPo=; b=CfHIZyG52nFVUywljkPIhlN2y2/7id/N5BgWWrKZUSuQLdMZc5WMWqj3L14xmfPROy S180XXzvuzE/QCXAxAYkvWPqQsx/GO325LmQLrT+uDi7pZft5P4KOXc0eCxaxlockw2j 0uZH9vDMWSJRx3tXrvG1a/ChLr0nqgd4sKJyM= MIME-Version: 1.0 Received: by 10.182.5.198 with SMTP id u6mr8283016obu.14.1324546570429; Thu, 22 Dec 2011 01:36:10 -0800 (PST) Received: by 10.182.150.70 with HTTP; Thu, 22 Dec 2011 01:36:10 -0800 (PST) In-Reply-To: <4EF2D814.1090805@freebsd.org> References: <4EF25468.9040204@gmail.com> <4EF2D814.1090805@freebsd.org> Date: Thu, 22 Dec 2011 11:36:10 +0200 Message-ID: From: Alexander Yerenkow To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Johan Hendriks , Alexander Leidinger , FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 09:36:11 -0000 My thoughts about benchmarking - don't forget, it's the way to get at least estimate on how your system will behave in given circumstances. When testers measured new videocard, they tested few factors, like FPS in modern games, pixel/texture fillrate, and whatever they do there else. That's because videocard have few simple and plain applications. And different vendor/generation cards are compared without problems. Different version of compiler, OS, etc - is very irrelevant. It's like say we can't compare these shovels, because they made from different sort of wood. OS is created to serve (produce some useful actions), and not to be measured and turned off forever:) So, in ideal world, there will be benchmarks on some real-world situations (like FPS for videocards, there got to be something also if not common, but at least wide-spread amongst users). Like - benchmarking fully tuned FreeBSD vs fully tuned Linux in high net-load (for example http + php + mysql). It's hard to disagree that this is very common spread use case for server OS. Also good tests would be productivity of FTP/File/Samba/Nfs/rsync servers. For desktop aspects, there's not much space for tuning (for linuxes), mostly linuxes tested out-of-box, or tuned via some gui-settings applet;, while FreeBSD-OOB needs some additional care (like get latest ports, install latest video drivers, xorg, etc., sysctl tuning probably). I'm glad there's PC-BSD, and PC-BSD can be used for desktop testing. And what to test in desktop? IMHO - WM responsiveness; - Program multi-tasking, and how productivity decreases when many background program working; (It's like, which user experience we'll get when our system is pretty heavy loaded) - Probably would be fair to compare same software in same circumstances (like same version of FF, Chromium, maybe something else). There's such extension for FF imacros - which can be used to simulate user actions, any actions in many tabs; - Overall usage experience, like measure time between program launching and window appearing (file managers, browsers, settings applet, calculator, etc.) - Sleep/Wake times with empty system(and with many programs launched ); If at all supported sleep/wake (as for me - my laptop can be slept, but deny to wake properly) - Time between you press "KDE start menu icon" and menu appeared; - Your variant?... This would be more careful benchmarking, not only number-crunching and heavy-archiving is used by all peoples. And this benchmarking can be at least be applied for users; They can imagine how it is - to have dolphin (KDE file manager) launched in 1.03 seconds, and alt-tabbing gives new window in 0.2 seconds, when video is playing. But what about time of calculating of Super-PI? Or archiving 4Gb file? It's mostly abstract measurement, and almost useless; I repeat - for average desktop users. I've at work PC-BSD installed on 24Gb SSD, with default ZFS setup slightly tuned (disabled prefetch), and I can say that system is great, and not sluggish. I sometimes happen to fill FS to 100%, then delete logs and continue working, without any signs of ZFS problems (I read somewhere that ZFS don't like to work when not much of free space available). KDE is old, but pretty fast. How can I measure this all with some few numbers :) ? My point is, that if not now, then in some near future benchmarking need to be more practical and applicable for users. Desktop measurements and server measurements. I hope Phoronix test suite will support desktop-experience benchmarking soon :) Thanks. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 09:55:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 269D8106566B for ; Thu, 22 Dec 2011 09:55:13 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 823BF8FC14 for ; Thu, 22 Dec 2011 09:55:12 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBM9sw5D040186 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 22 Dec 2011 11:55:04 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF2FE72.7000007@digsys.bg> Date: Thu, 22 Dec 2011 11:54:58 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EF25468.9040204@gmail.com> <4EF2D814.1090805@freebsd.org> <4EF2F210.6080009@gmail.com> In-Reply-To: <4EF2F210.6080009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 09:55:13 -0000 On 22.12.11 11:02, Johan Hendriks wrote: > Stefan Esser schreef: >> Am 21.12.2011 22:49, schrieb Johan Hendriks: >>> If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux >>> to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. >> The gcc version distributed with FreeBSD was chosen for license reasons, >> not for technical reasons. If you are OK with installing a GPLv3 >> licensed compiler on your systems, then just do it and take advantage of >> the improved code generated by it. > It does not matter what the decission is to use the old compiler, it > is a fact that the base comes with 4.2.x > Does that mean we can not compare/benchmark against other > distributions because they use GPLv3 stuff. If you intend to compare operating systems 'as shipped', then forget about comparing third party programs on top of these operating systems. Compare only any software that is already available with the operating system, as shipped. There is plenty of software in the base system and this software is specifically different (say) in FreeBSD and Linux. Anyone made such comparison? > No, i want to know where standard released FreeBSD stands against > standard released Linux distributions. > If you compare benchmark userland applictions, then it is fair to use > the latest compiler for the userland software also on FreeBSD. > But what if the ports tree defaults to LLVM, then again we want to > know what FreeBSD does against a Linux distribution. > Why because that is what most of us will be using...!! It is pretty easy to tell the ports system to use latest gcc, as described here http://www.freebsd.org/doc/en/articles/custom-gcc/article.html > > If we start to compile all the ports with gcc 4.7 to be on par in > comparising and benchmarking, why spend all the time getting LLVM as > the default compiler for ports also? Because, FreeBSD attempts to be as GPL free as possible. GPL is incompatible with many of the applications of FreeBSD. > Why not take that effort into making the WHOLE ports tree to compile > with GCC4.7? This has already been done. See above. > > Reason, because FreeBSD goes the LLVM route. That is a decission > FreeBSD is making! LLVM, as well as GCC are just choices in FreeBSD. What FreeBSD is making is, to make it safe to use LLVM to compile everything on FreeBSD, including the kernel. As you may have already noticed, some ports require to be compiled with a specific version of gcc, or a very specific compiler -- there is nothing wrong with this -- this is external software after all. > And that choise will be the FreeBSD that is used in comparising and > benchmarks on the net , not the utterly overcopiled and tuned FreeBSD > against stock Ubuntu or whatever Linux distribution. Earlier on this thread I mentioned, that FreeBSD and Linux philosophies differ. While Linux (well, some distributions, to be correct) will try to optimize certain parts of the OS/applications in order to do well in benchmarks -- FreeBSD takes a different approach. The FreeBSD (and BSD UNIX, in general) approach is "do the right thing". This may produce the results slower, but the environment is more stable in general and in the long run, the results noticeable better. This argument, by the way reminds me of the AT&T vs BSDI lawsuit, where at the time UCB was involved there was lengthly discussion (at court), about "sloppy programming, but we had to have something for the deadline" (AT&T) vs "well, we have designed the architecture we think is appropriate, there might be few unimplemented things, but we are working on it". > > Same goes for the scheduler! and all the other subsystems FreeBSD has > choosen, that makes FreeBSD. What about the scheduler? > > > Yes you can use a more advanced compiler on FreeBSD, BUT you can do > that on Linux also ,so where do you stop? Can you compile the entire Linux system, kernel and userland and external packages with LLVM? > Are you going to spend a month to compare a fullly tuned up FreeBSD > system against a Linux distribution? I would do that, if: - I have a task for which I need tuned system (that is, hardware would be at limits); - The application is available on both; - There is evidence or suggestion that the application under Linux will perform much better; > No because the users will not spend months tuning and recompile there > servers. > They use the FreeBSD version that comes with the CD! On servers? :-) > And that we want to compare/benchmark against a Linux distribution. No, we don't. We run our servers, we don't want to compare/benchmark them with Linux for no reason. We want however to identify design or implementation weaknesses in FreeBSD and fix these. This rarely happens by comparing to Linux distributions. There are better things to be observed in say, Solaris. If we were selling FreeBSD, we would be interested in publishing benchmarks that demonstrate how superior to Linux it is. We would tune FreeBSD to beat Linux in most benchmarks available and we will ignore the fact that in real-worls scenarios it will be worse. For.. we would have already made the sale. Now, you will say "but Linux is free". :) Thing is, the goal most Linux distributions have is to dominate with 'market share'. The primary purpose is to convince the software developers to port their software for Linux. This has had some positive results but in general -- not enough. There are better 'open source' approaches and the FreeBSD ports collection proves that. >> >>> Or do we say, well we are on par, but it is not fair, yes we used the >>> latest releases, but you can not blame Linux because they are still >>> using GCC. >> Depends on what you want or need to measure ... > > I am mainly talking about the out of the box comparison, because that > is what most sites will do when doing a benchmark. > they want to know if the the all new version of FreeBSD can compete > with the latest release of Ubuntu. > That are the benchmarks you will see on the net. Compete on what? > If we want to look good, FreeBSD must make sure there released version > gets on par! Everything has its cost. > We all know FreeBSD is quite conservative with its default settings. It is always better to have reliable OS, that can boot on almost any hardware, not crash for no reason and once it is up and running, you can always tune it to your taste. Maybe you are looking for an "tune FreeBSD for your usage" type of application? > Maybe we need to set some default settings less conservative. If such settings could make FreeBSD less reliable or less stable -- definitely NOT. > But i do not know if that is good just for the numbers! > Another idea, you may make your own FreeBSD derivative, such as PC-BSD or FreeNAS (both, special-purpose setups, optimized for what they do) and compare it with someone else's Linux distribution. By the way, there is FreeBSD based "Linux" distribution: Debian kFreeBSD -- however weird this sounds. Has anyone compared recent PC-BSD with Ubuntu? Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 09:57:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC13106564A for ; Thu, 22 Dec 2011 09:57:37 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D54618FC0A for ; Thu, 22 Dec 2011 09:57:36 +0000 (UTC) Received: by pbcc3 with SMTP id c3so6641120pbc.13 for ; Thu, 22 Dec 2011 01:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=A4cyLtiVBvQM51eqyQjqZMWrJ2fQm5S6SGl4HQ96Plw=; b=jUHKqs15YqPdaVICmknEg+VQO67bm/obRMhmBOecaZ4fuxbow0xsNtnN14av8KlQwm MP6aDwm7NPSu21VZha90LyoOjgM7x7ELFRHG5iBGW2T2HH/fquOMG1FfjVzb/7vJS2wb dndIMg4Mytw30nJSWvQQ8QXHkq5bqoykRJt3c= Received: by 10.68.73.65 with SMTP id j1mr21599102pbv.80.1324547856227; Thu, 22 Dec 2011 01:57:36 -0800 (PST) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.68.12.199 with HTTP; Thu, 22 Dec 2011 01:56:55 -0800 (PST) In-Reply-To: <4EF2C613.3020609@digsys.bg> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> From: Igor Mozolevsky Date: Thu, 22 Dec 2011 09:56:55 +0000 X-Google-Sender-Auth: Sxd9t6UzBCStho0KnWIGVb0fdgU Message-ID: To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 09:57:37 -0000 On 22 December 2011 05:54, Daniel Kalchev wrote: > > > On 22.12.11 00:33, Igor Mozolevsky wrote: >> >> Using the same argument one can say that Ferrari F430 vs Toyota Prius is= a >> meaningless comparison because the under-the-hood equipment is different= . > > =C2=A0Of course, it is meaningless, the Ferrari will lose big time in the= fuel > consumption comparison! I believe it will also lose the price comparison = as > well. Not to speak the availability comparison. That's an oxymoron, right? The comparison cannot be meaningless---the reality is F430 will indeed use up more fuel than Prius. If a benchmark demonstrates a true reality, how can that benchmark be possibly meaningless??? Same benchmark might be irrelevant to someone who wants to know how fast they can get from A to B, but irrelevant is not a synonym for meaningless! > You say that comparison is meaningless, yet you intend to compare those t= wo > cars? I didn't say that at all, I was demonstrating fallacy of the argument that the comparisons were meaningless. > Any 'benchmark' has a goal. You first define the goal and then measure ho= w > different contenders achieve it. Reaching the goal may have several > measurable metrics, that you will use to later declare the winner in each= . > Besides, you need to define a baseline and be aware of what theoretical > max/min values are possible. Treating a benchmark as a binary win/lose is rather naive, it's not a competition, and (I hope) no serious person ever does that. A proper benchmark shows true strength and weaknesses so than a well-informed intelligent decision can be taken by an individual according to that individual's needs. The caveat, of course, is making your methodology clear and methods repeatable! Cheers, -- Igor M. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 10:12:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4658B106566C for ; Thu, 22 Dec 2011 10:12:56 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id D18238FC16 for ; Thu, 22 Dec 2011 10:12:55 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBMACXie040336 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Dec 2011 12:12:38 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF30290.2030600@digsys.bg> Date: Thu, 22 Dec 2011 12:12:32 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Igor Mozolevsky References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 10:12:56 -0000 On 22.12.11 11:56, Igor Mozolevsky wrote: > On 22 December 2011 05:54, Daniel Kalchev wrote: >> Of course, it is meaningless, the Ferrari will lose big time in the fuel >> consumption comparison! I believe it will also lose the price comparison as >> well. Not to speak the availability comparison. > That's an oxymoron, right? The comparison cannot be meaningless---the > reality is F430 will indeed use up more fuel than Prius. If a > benchmark demonstrates a true reality, how can that benchmark be > possibly meaningless??? Same benchmark might be irrelevant to someone > who wants to know how fast they can get from A to B, but irrelevant is > not a synonym for meaningless! That benchmark is especially meaningless and a waste of time, because by design the Prius is constructed to consume 'less' fuel at the cost of lower engine power and the Ferrari is designed to waste fuel for the sake of high engine power. Of course, you can compare them, but this is not exactly benchmark. As for how fast to get from point A to point B. If you observe speed limits, that will depend only on the pilot, no? :) Both cars are sufficiently faster than the imposed speed limits. The same can be said for the FreeBSD and the Linux platforms. Today. Years ago, Linux was much worse, but they.. hm.. learned. :) On commodity hardware, you can expect about the same results from both OS. There will be differences due to drivers, different optimizations etc. On very specific hardware, such as systems with many CPUs and lots of memory, you may see one better than the other -- this in most cases will be relevant to tuning, but also to overall system architecture. > >> Any 'benchmark' has a goal. You first define the goal and then measure how >> different contenders achieve it. Reaching the goal may have several >> measurable metrics, that you will use to later declare the winner in each. >> Besides, you need to define a baseline and be aware of what theoretical >> max/min values are possible. > Treating a benchmark as a binary win/lose is rather naive, it's not a > competition, and (I hope) no serious person ever does that. A proper > benchmark shows true strength and weaknesses so than a well-informed > intelligent decision can be taken by an individual according to that > individual's needs. The caveat, of course, is making your methodology > clear and methods repeatable! Err... a benchmark produces metrics. It does not produce conclusions. Or at least, should not :) It takes context and understanding of both the subject and methodology used to draw any conclusion out of particular benchmark. No benchmark shows strengths and weaknesses -- these are subject of interpretation and any 'score' you have in a benchmark might be the result of poor benchmark design and/or implementation. You may make an very "scientific", well documented and repeatable benchmark, such as this one: time dd if=/dev/zero of=/dev/null .. then optimize your particular OS to run it at the highest possible rate... and so what? Do you know what this benchmark measures? :) Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 10:51:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B552B1065670 for ; Thu, 22 Dec 2011 10:51:30 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6468FC0A for ; Thu, 22 Dec 2011 10:51:30 +0000 (UTC) Received: by pbcc3 with SMTP id c3so6675430pbc.13 for ; Thu, 22 Dec 2011 02:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=HETqwWRDaLVG6ucP6/ZVGvTa8m4KfTPo44oprZTfioo=; b=QKIq585Awi81fMFg7VgM/SRjmGKHrchSlh9/XvEVdXX8+M5DdoDcDSb33VQqbjkiGE eqTHonKRTWTTyEuUXZwkKASFenL9DIJeq4j3Bq8FUvK2ly43YoY1XYsRPL2y1QeAqBI8 Lp4O1SZs+Lqhbtapt4appKSMH2YsjP/v6RpRk= Received: by 10.68.189.2 with SMTP id ge2mr14826077pbc.63.1324551090155; Thu, 22 Dec 2011 02:51:30 -0800 (PST) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.68.12.199 with HTTP; Thu, 22 Dec 2011 02:50:49 -0800 (PST) In-Reply-To: <4EF30290.2030600@digsys.bg> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF30290.2030600@digsys.bg> From: Igor Mozolevsky Date: Thu, 22 Dec 2011 10:50:49 +0000 X-Google-Sender-Auth: fQH8kprzixh1OtlUpgfYH0JJXbc Message-ID: To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 10:51:30 -0000 On 22 December 2011 10:12, Daniel Kalchev wrote: > As for how fast to get from point A to point B. If you observe speed limits, > that will depend only on the pilot, no? :) > Both cars are sufficiently faster than the imposed speed limits. You are ignoring acceleration, handling, and other factors... Besides, you're missing the point: *given same conditions* a benchmark allows one to show how A performs compared to B, which is why I said it is important to keep everything else constant! At the end of the day, what users, sysadmins, &c want to know is given hardware configuration H and requirement R will software X outperform software Y or Z. The components and the bells and whistles of X, Y or Z are, quite often, irrelevant (unless one has some silly idealogical reason, for example). > On very specific hardware, such as systems with many CPUs and lots of > memory, you may see one better than the other -- this in most cases will be > relevant to tuning, but also to overall system architecture. Are you saying that careful tuning will give you _orders of magnitude_ performance increase? Got numbers to back that up? ;-) > You may make an very "scientific", well documented and repeatable benchmark, > such as this one: > > time dd if=/dev/zero of=/dev/null > > .. then optimize your particular OS to run it at the highest possible > rate... and so what? Do you know what this benchmark measures? :) Yes, do you? I hope you are not being deliberately obtuse here... Besides, I would criticise your test in this example: have you tried running that with, say, bs=1g count=1000? Is there a difference how fast FreeBSD completes that vs how fast a Linux box does the same? The point of documenting a repeatable benchmark is to enable the person interpreting the results to see what was done (and verify) to achieve the result and treat that result accordingly. Cheers, -- Igor From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 11:11:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C251106564A for ; Thu, 22 Dec 2011 11:11:40 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 221F08FC16 for ; Thu, 22 Dec 2011 11:11:39 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBMBBTs0040768 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Dec 2011 13:11:35 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF31061.1070604@digsys.bg> Date: Thu, 22 Dec 2011 13:11:29 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Igor Mozolevsky References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF30290.2030600@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 11:11:40 -0000 On 22.12.11 12:50, Igor Mozolevsky wrote: > On 22 December 2011 10:12, Daniel Kalchev wrote: > >> As for how fast to get from point A to point B. If you observe speed limits, >> that will depend only on the pilot, no? :) >> Both cars are sufficiently faster than the imposed speed limits. > You are ignoring acceleration, handling, and other factors... Besides, > you're missing the point: *given same conditions* a benchmark allows > one to show how A performs compared to B, which is why I said it is > important to keep everything else constant! At the end of the day, > what users, sysadmins,&c want to know is given hardware configuration > H and requirement R will software X outperform software Y or Z. The > components and the bells and whistles of X, Y or Z are, quite often, > irrelevant (unless one has some silly idealogical reason, for > example). None of the benchmarks measure 'comfort'. None of the benchmarks measure how the system 'feels' while performing an numerical computation. The benchmarks measure how soon the computations are finished. You typically achieve that by tuning the OS to say, ignore any interactivity at the cost of focusing all resources to compute-intensive tasks. If you use the same hardware, the CPU can do only so much and if there are any differences, that will be in how the OS asks the CPU to do other things, besides the task you benchmark. You need to define your criteria. Otherwise the benchmark cannot be used to make comparisons. >> On very specific hardware, such as systems with many CPUs and lots of >> memory, you may see one better than the other -- this in most cases will be >> relevant to tuning, but also to overall system architecture. > Are you saying that careful tuning will give you _orders of magnitude_ > performance increase? Got numbers to back that up? ;-) Ah.. now we are talking :) Two things: Someone once said, that you may have an very fast computation if only you need not make sure the results are correct. So yes, you can! :) It is all too easy to make things worse, from the theoretical baseline. So often we measure not how 'good' an OS is, but how 'bad' it actually manages the hardware. Well.. there is also some hardware that has limitations and you need to define the benchmark in a specific way to not touch them. Or you may have specific OS trying to avoid touching them -- and thus providing you with 'performance'. >> You may make an very "scientific", well documented and repeatable benchmark, >> such as this one: >> >> time dd if=/dev/zero of=/dev/null >> >> .. then optimize your particular OS to run it at the highest possible >> rate... and so what? Do you know what this benchmark measures? :) > Yes, do you? I hope you are not being deliberately obtuse here... I know, that different people will see different things being measured here. Let's see if someone else will jump in. (which is the purpose of this example) > Besides, I would criticise your test in this example: have you tried > running that with, say, bs=1g count=1000? That would measure different things. :) > Is there a difference how fast FreeBSD completes that vs how fast a Linux box does the same? Why not? I would expect there will be difference in how fast different versions of FreeBSD complete it as well. It could be also interesting to measure (although it's somewhat subjective) how interactive both systems stay during this task. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 11:52:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA3D106564A for ; Thu, 22 Dec 2011 11:52:44 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id A320A8FC08 for ; Thu, 22 Dec 2011 11:52:44 +0000 (UTC) Received: from [10.10.10.10] (unknown [217.157.7.216]) by csmtp3.one.com (Postfix) with ESMTPA id CCD592406C6B for ; Thu, 22 Dec 2011 11:52:43 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 12:52:45 +0100 Message-Id: To: FreeBSD Current Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: GCC debug flags cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 11:52:45 -0000 Hi, I've created a patch that cleans up FreeBSD Makefiles that = unconditionally set the -g flag for GCC. The motivation for this is that = it should be possible to add or remove this flag globally via e.g. = CFLAGS (it's part of my quest to produce deterministic builds). I'm not very familiar with GCC or the build infrastructure, so I'd be = grateful if someone would review it and possibly commit. http://dev.affect-it.dk/gcc_debug_flags.diff Thanks, Erik= From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 12:45:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADCC6106566C for ; Thu, 22 Dec 2011 12:45:41 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3BDE48FC13 for ; Thu, 22 Dec 2011 12:45:40 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pBMCjO7D026908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 13:45:31 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1324557932; bh=fLitlcjU7j5/i/VyFotssFf9TG1tknAIobMUWZR4bqg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=mWYqFKs6XDXEpZjjiBfrpsMzpM3+WjMx61TsOU3fdpi/xjo5CvZYYndWvUbtWoKNO 7e1fxZy3NwEglDP6Op+GDIdUZF7JXWsUZw/D3kmUwAyj+71q7earo4tL7WyabidW7A Vb5QCzNmjO4P5PlA+rNcDZS7p4BRBfIKcIAek4g4= Date: Thu, 22 Dec 2011 13:45:24 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Warner Losh Message-ID: <20111222124524.GW83814@acme.spoerlein.net> Mail-Followup-To: Warner Losh , Lyndon Nerenberg , freebsd-current@freebsd.org, Ryan Stone References: <20111202064132.GC88903@troutmask.apl.washington.edu> <4ED8776F.9060301@FreeBSD.org> <20111202072349.GA89183@troutmask.apl.washington.edu> <20111202083501.GA73959@dragon.NUXI.org> <554C031E-531F-4A1F-B315-8F61D33D70A7@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554C031E-531F-4A1F-B315-8F61D33D70A7@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ryan Stone , freebsd-current@freebsd.org, Lyndon Nerenberg Subject: Re: WITHOUT_PROFILE=yes by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 12:45:41 -0000 On Mon, 2011-12-19 at 12:50:42 -0700, Warner Losh wrote: > > On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote: > > >> Using profiled libs and gprof to profile your code has been obsolete > >> in FreeBSD on i386 and amd64 for over six years now. > > > > Funny, it still seems to work on my systems. > > Worked for me last time I tried as well. Was able to find the problems w/o a hassle. turning them off is plain wrong. > > Can we at least ship profiled libraries for the release? I didn't want to get in on the discussion, but for me every time you need to recompile software to get to feature A, I consider it a bug. Rebooting to enable a feature? Sure. Recompiling software to enable a feature? What? Is this the middle ages? What happened to shipping software/binaries that can work for everybody? The way I see it, profiling currently works for *both*, users that need the libs and users that don't need the libs. Reducing compile times is not a worthy goal, IMHO, as no user should ever have need to re-compile FreeBSD. Neither to tune something in GENERIC nor to rebuild world. Just my 2 cents, Uli From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 14:03:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA0BC1065670 for ; Thu, 22 Dec 2011 14:03:32 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id B6C338FC0A for ; Thu, 22 Dec 2011 14:03:32 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id C900C119C6C; Thu, 22 Dec 2011 08:03:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1324562611; bh=IWFTbzB+btlgCxpdcdsbZ6bic7FV7SX3/1usFGqvrTs=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=rAuLNOoA1zYh0T4mlbt+0V5f8FruqOs4nDb8MjuTifsiAgLdJJ98RRXM9wxzqA8SA PFkG5VkIxroAin9IdItfKu1sgYm1R2y8LGRQgOekZ/QSklqak9b6bs7CslyqFFwqbL doKeq5WC1a9HfNRf1ySvWhS4yqQs+b80fJbbPW8g= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id C3387119C66 for ; Thu, 22 Dec 2011 08:03:31 -0600 (CST) Date: Thu, 22 Dec 2011 08:03:31 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 14:03:33 -0000 http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND jexec(8) now supports -h hostname option to specify the jail where the command will be executed. When was this added? I don't see it functioning: sunsaturn:~# jexec -h jexec: illegal option -- h usage: jexec [-u username | -U username] jail command ... sunsaturn:~# uname -a FreeBSD sunsaturn.com 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec 11 19:20:46 CST 2011 droot@sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 sunsaturn:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 15:14:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC17106566B for ; Thu, 22 Dec 2011 15:14:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id C8DA88FC08 for ; Thu, 22 Dec 2011 15:14:44 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A945225D37C7; Thu, 22 Dec 2011 15:14:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id CD8BFBD78CB; Thu, 22 Dec 2011 15:14:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CHa-Aef-44wd; Thu, 22 Dec 2011 15:14:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6CE64BD78CA; Thu, 22 Dec 2011 15:14:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 22 Dec 2011 15:14:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:14:45 -0000 On 22. Dec 2011, at 14:03 , Dan The Man wrote: >=20 >=20 > http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND > jexec(8) now supports -h hostname option to specify the jail where the = command will be executed. >=20 Oh wow. That's all but current. >=20 > When was this added? I don't see it functioning: 3 years 6 months ago and it was shortly afterwards removed again as = neither a) the hostname not b) the ip addresses needed to be unique anymore with multi-IP jails (a) not even before that). The suggested replacement was -n to name the jails yourself. I think the uniqueness limit has since = been removed on that as well but the option has stayed and by default is the jail ID these days and it's name=3D<..> in the modern syntax. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 15:35:48 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6416A106564A for ; Thu, 22 Dec 2011 15:35:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 254C28FC0C for ; Thu, 22 Dec 2011 15:35:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:64be:2ed2:2384:1368] (unknown [IPv6:2001:7b8:3a7:0:64be:2ed2:2384:1368]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 678FC5C37 for ; Thu, 22 Dec 2011 16:35:47 +0100 (CET) Message-ID: <4EF34E52.2040905@FreeBSD.org> Date: Thu, 22 Dec 2011 16:35:46 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: multipart/mixed; boundary="------------070906020909010701040509" Cc: Subject: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:35:48 -0000 This is a multi-part message in MIME format. --------------070906020909010701040509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-October/000270.= html What this patch attempts to fix is the following: - When you compile amd64 kernels for debug, they still get optimized with "-O2 -frename-registers", which is almost certain to make debugging miserable. Optimizing at higher levels makes variables and code move around, or disappear altogether. About -frename-registers the gcc documentation even says: "Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a =93home register=94= =2E" - Clang doesn't support the -frename-registers option, so you get harmless but annoying "warning: argument unused during compilation: '-frename-registers'" messages during buildkernel. The patch makes it so that: - For normal amd64 kernel builds, it uses "-O2 -frename-registers", unless Clang is used, then it uses plain "-O2". - For debug amd64 kernel builds, it uses "-O", just like all the other arches. --------------070906020909010701040509 Content-Type: text/x-diff; name="amd64-opt-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="amd64-opt-1.diff" Index: sys/conf/kern.pre.mk =================================================================== --- sys/conf/kern.pre.mk (revision 228799) +++ sys/conf/kern.pre.mk (working copy) @@ -29,15 +29,13 @@ .else .if ${MACHINE_CPUARCH} == "powerpc" _MINUS_O= -O # gcc miscompiles some code at -O2 +.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang" +_MINUS_O= -O2 -frename-registers .else _MINUS_O= -O2 .endif .endif -.if ${MACHINE_CPUARCH} == "amd64" -COPTFLAGS?=-O2 -frename-registers -pipe -.else COPTFLAGS?=${_MINUS_O} -pipe -.endif .if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) COPTFLAGS+= -fno-strict-aliasing .endif --------------070906020909010701040509-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 15:59:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5898106564A for ; Thu, 22 Dec 2011 15:59:15 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 171EA8FC13 for ; Thu, 22 Dec 2011 15:59:14 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBMFxDUJ091936; Thu, 22 Dec 2011 19:59:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBMFxDs6091935; Thu, 22 Dec 2011 19:59:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 22 Dec 2011 19:59:13 +0400 From: Gleb Smirnoff To: "Hartmann, O." Message-ID: <20111222155913.GR80057@FreeBSD.org> References: <4EF25913.50107@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF25913.50107@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org Subject: Re: xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:59:16 -0000 On Wed, Dec 21, 2011 at 11:09:23PM +0100, Hartmann, O. wrote: H> OS: FreeBSD 10.0-CURRENT/amd64 r228787 H> H> Since the last update of world yesterday were I managed to compile the H> OS WITH_LIBCPLUSPLUS=YES in /etc/src.conf, H> only root is capable to login on the console. H> H> I use OpenLDAP 2.4 as the backend for usual users, having also an H> "emergency" user installed in the local /etc/passwd just in case. H> H> The problem is, I can not login via xdm or console login anymore as any H> usual user, even not as a user residing in the local passwd file. H> H> Trying to login as LDAP backed user, I get the error H> SASL/DIGEST-MD5 authentication started H> Login icorrect H> H> Inspecting /var/log/auth.log reveals for this incident H> H> login: in openpam_check_path_owner_perms(): H> /usr/local/lib/pam_ldap.so.5: No such file or directory H> H> Trying tologin as a local (/etc/passwd backed) user gets H> sometimes the same login issue, but sporadically I get a login but H> landing in / instead of /home/user. /home is a ZFS volume. H> H> I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many times H> now since I suspected a fault in compilation (everything is compiled via H> CLANG), but I have no success. H> H> /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.so. H> H> It seems, that the OS can not find the homes on the ZFS volume. Doing a H> su - USER works for all LDAP users but not the local users, I receive H> the error su: no directory. This is very strange. While su - as root H> does not work, login as such a failing user work, but as mentioned H> without home. H> H> The last thing I did on that box is: I recompiled yesterday evening H> world, switched the box off. When I switched the box on today, I ran H> into this issue. H> H> I recompile the system without flag WITH_LIBCPLUSPLUS and see what is H> happening. Do others also see this strange behaviour? This is definitely due to libpam update. In my case, I also got messages: openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such file or directory But this doesn't prevent me from logging in. The new PAM code first tries to dlopen() a library configured in /etc/pam.d with ".5" appended to it, this is hardcoded. If failed, it dlopens the exact name from configuration. So, the message is harmless itself - the pam_ldap.so is opened successfully. I suppose failure to login that you experience is related to another fallout from the new PAM import. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 16:03:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1783A1065673 for ; Thu, 22 Dec 2011 16:03:44 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id D46ED8FC0C for ; Thu, 22 Dec 2011 16:03:43 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 1F3BA119C6D; Thu, 22 Dec 2011 10:03:43 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1324569823; bh=3u+PjdCBZi3vub1azt3kHrpDm59heg+3SfzKMldE8kI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=RVtrsFSgoqhyXPO3yzQagOJLZ6plHz4G0lYKQ0Srf+D3ZrNObcVyiDKMNzDH6L/g7 eWOlPAg/3HkArG6EqFGfDXKD87VXpuea2eG1Pq6Qp2idDHAFSg6CjfnABvn49wQkW2 ACgIBQd0TyHDWH9I5VxKQKjHVSmP7Se2YyIxPvm0= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 1EA38119C6C; Thu, 22 Dec 2011 10:03:43 -0600 (CST) Date: Thu, 22 Dec 2011 10:03:43 -0600 (CST) From: Dan The Man To: "Bjoern A. Zeeb" In-Reply-To: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> Message-ID: References: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:03:44 -0000 On Thu, 22 Dec 2011, Bjoern A. Zeeb wrote: > > On 22. Dec 2011, at 14:03 , Dan The Man wrote: > >> >> >> http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND >> jexec(8) now supports -h hostname option to specify the jail where the command will be executed. >> > > Oh wow. That's all but current. > > >> >> When was this added? I don't see it functioning: > > 3 years 6 months ago and it was shortly afterwards removed again as neither > a) the hostname not b) the ip addresses needed to be unique anymore with > multi-IP jails (a) not even before that). The suggested replacement was > -n to name the jails yourself. I think the uniqueness limit has since been > removed on that as well but the option has stayed and by default is the > jail ID these days and it's name=<..> in the modern syntax. > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > Yeah, seems problematic, from what I have seen so far everytime you stop and restart the jail it gets a different jail ID, which would make it difficult to cron anything to execute in the jail. I can't seem to get jexec to take anything but jail id. Came up with a temporary type solution assuming you have only 1 jail: JAILID=`/usr/sbin/jls -n name|cut -d '=' -f 2`; /usr/sbin/jexec $JAILID command I can see this being problematic for a long term/portable solution. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 17:35:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58E4106564A for ; Thu, 22 Dec 2011 17:35:21 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE128FC13 for ; Thu, 22 Dec 2011 17:35:21 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id pBMHGTY1090640; Thu, 22 Dec 2011 17:16:29 GMT (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: Date: Thu, 22 Dec 2011 17:16:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <25DCE941-78F6-4211-8DE6-8AB134115197@gid.co.uk> References: To: Erik Cederstrand X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Current Subject: Re: GCC debug flags cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:35:22 -0000 Hi, On 22 Dec 2011, at 11:52, Erik Cederstrand wrote: > I've created a patch that cleans up FreeBSD Makefiles that = unconditionally set the -g flag for GCC. [etc] Just a note of caution that I have had cases in the past where I = suspected that GCC was generating broken code without -g and good code = with. Makes debugging interesting :-) -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 18:02:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4CBA106566C for ; Thu, 22 Dec 2011 18:02:38 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id 9B76B8FC12 for ; Thu, 22 Dec 2011 18:02:38 +0000 (UTC) Received: from miami.exonetric.net (miami.exonetric.net [82.138.248.154]) by relay0.exonetric.net (Postfix) with ESMTP id 9DF0B57001; Thu, 22 Dec 2011 17:38:46 +0000 (GMT) Date: Thu, 22 Dec 2011 17:38:46 +0000 (GMT) From: Mark Blackman X-X-Sender: mb@miami.exonetric.net To: Bob Bishop In-Reply-To: <25DCE941-78F6-4211-8DE6-8AB134115197@gid.co.uk> Message-ID: References: <25DCE941-78F6-4211-8DE6-8AB134115197@gid.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , Erik Cederstrand Subject: Re: GCC debug flags cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 18:02:38 -0000 On Thu, 22 Dec 2011, Bob Bishop wrote: > Hi, > > On 22 Dec 2011, at 11:52, Erik Cederstrand wrote: > >> I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. [etc] > > Just a note of caution that I have had cases in the past where I suspected that GCC was generating broken code without -g and good code with. Makes debugging interesting :-) /me waits for PCC to be useful for compiling the whole system. :) - Mark From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 19:25:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id ADB60106566C; Thu, 22 Dec 2011 19:25:49 +0000 (UTC) Date: Thu, 22 Dec 2011 19:25:49 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111222192549.GA19008@freebsd.org> References: <4EF34E52.2040905@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF34E52.2040905@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:25:49 -0000 On Thu Dec 22 11, Dimitry Andric wrote: > Hi, > > I would like to ask some feedback on the attached patch, which cleans up > the kernel optimization options for amd64. This was touched upon > earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: " I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. " however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. cheers. alex > > http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-October/000270.html > > What this patch attempts to fix is the following: > - When you compile amd64 kernels for debug, they still get optimized > with "-O2 -frename-registers", which is almost certain to make > debugging miserable. Optimizing at higher levels makes variables and > code move around, or disappear altogether. About -frename-registers > the gcc documentation even says: "Depending on the debug information > format adopted by the target, however, it can make debugging > impossible, since variables will no longer stay in a ?home register?." > - Clang doesn't support the -frename-registers option, so you get > harmless but annoying "warning: argument unused during compilation: > '-frename-registers'" messages during buildkernel. > > The patch makes it so that: > - For normal amd64 kernel builds, it uses "-O2 -frename-registers", > unless Clang is used, then it uses plain "-O2". > - For debug amd64 kernel builds, it uses "-O", just like all the other > arches. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 19:31:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31790106566C for ; Thu, 22 Dec 2011 19:31:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id B6C6D8FC19 for ; Thu, 22 Dec 2011 19:31:20 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 9851D25D37C7; Thu, 22 Dec 2011 19:31:19 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9FF95BD78FE; Thu, 22 Dec 2011 19:31:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 21h+GAJw3t5a; Thu, 22 Dec 2011 19:31:17 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 752EEBD78FB; Thu, 22 Dec 2011 19:31:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 22 Dec 2011 19:31:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:31:21 -0000 On 22. Dec 2011, at 16:03 , Dan The Man wrote: >=20 >=20 > On Thu, 22 Dec 2011, Bjoern A. Zeeb wrote: >=20 >>=20 >> On 22. Dec 2011, at 14:03 , Dan The Man wrote: >>=20 >>>=20 >>>=20 >>> http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND >>> jexec(8) now supports -h hostname option to specify the jail where = the command will be executed. >>>=20 >>=20 >> Oh wow. That's all but current. >>=20 >>=20 >>>=20 >>> When was this added? I don't see it functioning: >>=20 >> 3 years 6 months ago and it was shortly afterwards removed again as = neither >> a) the hostname not b) the ip addresses needed to be unique anymore = with >> multi-IP jails (a) not even before that). The suggested replacement = was >> -n to name the jails yourself. I think the uniqueness limit has = since been >> removed on that as well but the option has stayed and by default is = the >> jail ID these days and it's name=3D<..> in the modern syntax. >>=20 >> /bz >>=20 >> --=20 >> Bjoern A. Zeeb You have to have = visions! >> Stop bit received. Insert coin for new address family. >>=20 >>=20 >=20 > Yeah, seems problematic, from what I have seen so far everytime you = stop and restart the jail it gets a different jail ID, which would make = it difficult to cron anything to execute in the jail. I can't seem to = get jexec to take anything but jail id. >=20 > Came up with a temporary type solution assuming you have only 1 jail: > JAILID=3D`/usr/sbin/jls -n name|cut -d '=3D' -f 2`; /usr/sbin/jexec = $JAILID command >=20 > I can see this being problematic for a long term/portable solution. jexec on a name works fine if you start the jail with a name as well. See the jail(8) man page on how to either use -n or name=3D. jail -n foo ... or jail name=3Dfoo ... then jexec foo ... --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 19:39:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E534106566C for ; Thu, 22 Dec 2011 19:39:37 +0000 (UTC) (envelope-from mokomull@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 052A28FC16 for ; Thu, 22 Dec 2011 19:39:36 +0000 (UTC) Received: by werb13 with SMTP id b13so6604776wer.13 for ; Thu, 22 Dec 2011 11:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ivycHaw6yox5K1E3KcOPeITSSbJ6vteKbdeOyDSHv3Y=; b=al15pdYaMOIrheHBqnso33n3VbC8TQFcvPc/rpEfhDZl/MUAD6umVTnrQfPCYjQ4+5 hdlqwj3Lc8no8NtqV8sOQOQp58JHU2O0+ZSdNklYRDKtagqPdyhceMFmHioG6tfE3Som whh4IxJafhT+aqvU9U6rgFgMKHJ4obTdQZT4s= MIME-Version: 1.0 Received: by 10.216.136.74 with SMTP id v52mr12429718wei.13.1324582775948; Thu, 22 Dec 2011 11:39:35 -0800 (PST) Received: by 10.223.154.135 with HTTP; Thu, 22 Dec 2011 11:39:35 -0800 (PST) In-Reply-To: References: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> Date: Thu, 22 Dec 2011 13:39:35 -0600 Message-ID: From: Matt Mullins To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:39:37 -0000 On Thu, Dec 22, 2011 at 1:31 PM, Bjoern A. Zeeb wrote: > jexec on a name works fine if you start the jail with a name as well. > See the jail(8) man page on how to either use -n or name=. > > jail -n foo ... > or > jail name=foo ... > > then jexec foo ... I've wanted to be able to do this since I read that in the jexec man page, but it doesn't seem that /etc/rc.d/jail starts jails with that option (at least in 9.0-RC3): mmullins@boron 2808 ~ % jls -n nodying enforce_statfs=2 host=new ip4=new ip6=disable jid=9 linux=new name=9 parent=0 path=/jails/shell nopersist securelevel=-1 allow.nochflags allow.nomount allow.noquotas allow.noraw_sockets allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=2 host.domainname="" host.hostid=0 host.hostname=boron-shell.local.mmlx.us host.hostuuid=00000000-0000-0000-0000-000000000000 ip4.addr=192.168.33.40 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.16 linux.oss_version=198144 Is there a "right" way to do this? Thanks, Matt Mullins From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 19:45:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B3A106566B for ; Thu, 22 Dec 2011 19:45:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 260BC8FC12 for ; Thu, 22 Dec 2011 19:45:37 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5D08625D389E; Thu, 22 Dec 2011 19:45:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8A379BD7900; Thu, 22 Dec 2011 19:45:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 0vu5iR3QNXWl; Thu, 22 Dec 2011 19:45:34 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 47577BD7902; Thu, 22 Dec 2011 19:45:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 22 Dec 2011 19:45:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5A3162A1-4285-41E8-BD0F-FB12F10762DE@lists.zabbadoz.net> References: <01A08619-4DE1-42E6-8F2F-38BB56C8615F@lists.zabbadoz.net> To: Matt Mullins X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: jexec -h hostname option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:45:37 -0000 On 22. Dec 2011, at 19:39 , Matt Mullins wrote: > On Thu, Dec 22, 2011 at 1:31 PM, Bjoern A. Zeeb > wrote: >> jexec on a name works fine if you start the jail with a name as well. >> See the jail(8) man page on how to either use -n or name=3D. >>=20 >> jail -n foo ... >> or >> jail name=3Dfoo ... >>=20 >> then jexec foo ... >=20 > I've wanted to be able to do this since I read that in the jexec man > page, but it doesn't seem that /etc/rc.d/jail starts jails with that > option (at least in 9.0-RC3): >=20 I think -l -U root are the defaults; please double-check in = /etc/defaults/rc.conf, so exntending them to: jail__flags=3D"-l -U root -n " is easy. > mmullins@boron 2808 ~ % jls -n > nodying enforce_statfs=3D2 host=3Dnew ip4=3Dnew ip6=3Ddisable jid=3D9 = linux=3Dnew > name=3D9 parent=3D0 path=3D/jails/shell nopersist securelevel=3D-1 > allow.nochflags allow.nomount allow.noquotas allow.noraw_sockets > allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=3D0 > children.max=3D0 cpuset.id=3D2 host.domainname=3D"" host.hostid=3D0 > host.hostname=3Dboron-shell.local.mmlx.us > host.hostuuid=3D00000000-0000-0000-0000-000000000000 > ip4.addr=3D192.168.33.40 ip4.saddrsel ip6.addr=3D ip6.saddrsel > linux.osname=3DLinux linux.osrelease=3D2.6.16 linux.oss_version=3D198144= >=20 > Is there a "right" way to do this? >=20 > Thanks, > Matt Mullins --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:01:52 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0DEF51065672; Thu, 22 Dec 2011 21:01:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 849E1152794; Thu, 22 Dec 2011 21:01:51 +0000 (UTC) Message-ID: <4EF39ABF.7070908@FreeBSD.org> Date: Thu, 22 Dec 2011 13:01:51 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> In-Reply-To: <20111222072056.GJ80057@glebius.int.ru> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:01:52 -0000 On 12/21/2011 23:20, Gleb Smirnoff wrote: > I'm afraid, if we would try to document every kernel<->userland API/ABI > change in head/ in the UPDATING, then the file will grow extremely quickly, > and still many issues will be forgotten to be added there. That doesn't mean we shouldn't do our best to make sure that they are documented. This is particularly true regarding changes that will affect the network on reboot. In any case, thanks for the info, and for your hard work. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 23:44:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C1A106564A; Thu, 22 Dec 2011 23:44:19 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E011A8FC0C; Thu, 22 Dec 2011 23:44:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RdsJ5-000468-V0>; Fri, 23 Dec 2011 00:44:16 +0100 Received: from e178027232.adsl.alicedsl.de ([85.178.27.232] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RdsJ5-0003tb-Q0>; Fri, 23 Dec 2011 00:44:15 +0100 Message-ID: <4EF3C0CE.5040802@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 00:44:14 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Alexander Leidinger References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig363DC61A08FC2B64410B086C" X-Originating-IP: 85.178.27.232 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd@jdc.parodius.com, igor@hybrid-lab.co.uk Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:44:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig363DC61A08FC2B64410B086C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/21/11 19:41, Alexander Leidinger wrote: > Hi, >=20 > while the discussion continued here, some work started at some other pl= ace. Now... in case someone here is willing to help instead of talking, f= eel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look= what can be improved. The page is far from perfect and needs some additi= onal people which are willing to improve it. >=20 > This is only part of the problem. A tuning page in the wiki - which cou= ld be referenced from the benchmark page - would be great too. Any volunt= eers? A first step would be to take he tuning-man-page and wikify it. Oth= er tuning sources are welcome too. >=20 > Every FreeBSD dev with a wiki account can hand out write access to the = wiki. The benchmark page gives contributor-access. If someone wants write= access create a FirstnameLastname account and ask here for contributor-a= ccess. >=20 > Don't worry if you think your english is not good enough, even some one= -word notes can help (and _my_ english got already corrected by other peo= ple on the benchmark page). >=20 > Bye, > Alexander. >=20 >=20 >=20 >=20 Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? Oliver --------------enig363DC61A08FC2B64410B086C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO88DOAAoJEOgBcD7A/5N8fsMIAJqxov2X2KfdyjzSXd89kYdD w/JFgI4xZCVaStAHWTyHm7UJh+cQvaZBqGtKiBooTdiLcbhwOck7YgQ9WL8piCS/ CBvjHZC7xPUSIywIvVA7uGf9i3Lbxq/TuoO9+Qk9AOfKtZswn6hATMtlNMyw0OC6 bJBp0rGa7MHsFQ020z5tomRqfU2ANdu3GrrLpge9rTOUCZ+ieq7GGrWEwlTFiDAM bd7NCiWyjgBtsjLBYsS0mjhE6aNW5i1fyT74AzNEyNn5BTWSTg0QPyNS0VXUTdec lNsCQxFbmmX17tPjCBiCACKn99sYQ8PTDq49F5ksj57Ku9LzIQZLaXa7kRpVB9I= =ikbF -----END PGP SIGNATURE----- --------------enig363DC61A08FC2B64410B086C-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 23:58:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8B8106566B for ; Thu, 22 Dec 2011 23:58:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id E949F8FC17 for ; Thu, 22 Dec 2011 23:58:49 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id CMAH1i00F1ZXKqc51PyqUo; Thu, 22 Dec 2011 23:58:50 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.westchester.pa.mail.comcast.net with comcast id CPyo1i0151t3BNj3hPyocH; Thu, 22 Dec 2011 23:58:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E5F55102C19; Thu, 22 Dec 2011 15:58:46 -0800 (PST) Date: Thu, 22 Dec 2011 15:58:46 -0800 From: Jeremy Chadwick To: "O. Hartmann" Message-ID: <20111222235846.GA6071@icarus.home.lan> References: <4EF3C0CE.5040802@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF3C0CE.5040802@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 23 Dec 2011 00:02:40 +0000 Cc: Alexander Leidinger , freebsd-performance@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, igor@hybrid-lab.co.uk Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:58:50 -0000 On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: > On 12/21/11 19:41, Alexander Leidinger wrote: > > Hi, > > > > while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. > > > > This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. > > > > Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. > > > > Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). > > > > Bye, > > Alexander. > > > > > > > > > > Nice to see movement ;-) > > But there seems something unclear: > > man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in > /etc/make.conf. > The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. > > What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 00:49:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6B7106566C; Fri, 23 Dec 2011 00:49:46 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id CE83F8FC17; Fri, 23 Dec 2011 00:49:45 +0000 (UTC) X-AuditID: 1209190e-b7f8f6d0000008fc-24-4ef3d029c3e9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B0.A9.02300.920D3FE4; Thu, 22 Dec 2011 19:49:45 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id pBN0niBl010247; Thu, 22 Dec 2011 19:49:45 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBN0nhs9023465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2011 19:49:44 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pBN0nhPk007578; Thu, 22 Dec 2011 19:49:43 -0500 (EST) Date: Thu, 22 Dec 2011 19:49:42 -0500 (EST) From: Benjamin Kaduk To: Alexander Best In-Reply-To: <20111222192549.GA19008@freebsd.org> Message-ID: References: <4EF34E52.2040905@FreeBSD.org> <20111222192549.GA19008@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrKt54bOfwaS9nBbtn+cxWSzp2sdo MefNByYHZo8Zn+azBDBGcdmkpOZklqUW6dslcGWs6TQsWMlb8W5NP1sD4wGuLkZODgkBE4l1 sycxQthiEhfurWfrYuTiEBLYxyjxZUkXC4SzgVHi360WJgjnAJPE0bb77BBOA6PEj//tTCD9 LALaEpMv/GcGsdkEVCRmvtnIBmKLCGhIbGt4DBZnFnCUWHJzE9g+YQEnif71S8HinAKGEl2v e9lBbF4Be4nNzf/BaoQE/CV+bNgOFhcV0JFYvX8KC0SNoMTJmU9YIGZaSpz7c51tAqPgLCSp WUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgSHqiTfDsavB5UOMQpw MCrx8FYVffYTYk0sK67MPcQoycGkJMr78jRQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjviwVA Od6UxMqq1KJ8mJQ0B4uSOK+a1js/IYH0xJLU7NTUgtQimKwMB4eSBG/5eaBGwaLU9NSKtMyc EoQ0EwcnyHAeoOFGIDW8xQWJucWZ6RD5U4yKUuK8/iAJAZBERmkeXC8slbxiFAd6RZg3C6SK B5iG4LpfAQ1mAhq8zfkDyOCSRISUVAOj1pylLKovmV1lci18b0zZ4+fMnX/gTt3lj2f17+/n s5Od9ZQ71qhgtc9NJ7YkQdu6xfGXeSw2/fn4tTz0Jv/dFxfkwnf/tzLqeXxmt5dprsd1F8aJ 0mn2RaZ6M8r4f9oqR8XuTO7UuVvt8VNx95XDRt4XD8b0dul51HWHFDM+UzVgX6X9sUWJpTgj 0VCLuag4EQBAYn0RAAMAAA== Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 00:49:46 -0000 On Thu, 22 Dec 2011, Alexander Best wrote: > On Thu Dec 22 11, Dimitry Andric wrote: >> Hi, >> >> I would like to ask some feedback on the attached patch, which cleans up >> the kernel optimization options for amd64. This was touched upon >> earlier by Alexander Best in freebsd-toolchain, here: > > i've been using such settings for a few months now and haven't noticed any > problems. > > however bruce evans raised a good point (in a private mail). when you compile a > kernel without debugging enabled, -O2 is the default. if you experience issues, > and enable debugging, -O0 now becomes the default. in case the problems with > the kernel were caused by the -O2 option and aren't present with the -O0 > option, the newly built kernel with debugging enabled will not help you fix the > problems. in that case you would need to set -O2 explicitly in CFLAGS. his > exact words were: > > " > I don't like -O2 for anything. However, if it is only a default, it is > not a problem provided it can be canceled easily. And for debugging, you > want the default to be the same as without debugging, so that (by default) > you debug the same code that caused the problem. > " > > however i don't think this is fixable. using -O0 for debuggable and > non-debuggable kernels will cause too much of a slowdown. > > having -O2 as the default flag for non-debuggable kernels and -O2 -g for > debuggable kernels might cause situations, where debugging isn't possible, > where with -O0 -g it would have been. > > so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 00:59:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EC4E01065672; Fri, 23 Dec 2011 00:59:32 +0000 (UTC) Date: Fri, 23 Dec 2011 00:59:32 +0000 From: Alexander Best To: Benjamin Kaduk Message-ID: <20111223005932.GA65042@freebsd.org> References: <4EF34E52.2040905@FreeBSD.org> <20111222192549.GA19008@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 00:59:33 -0000 On Thu Dec 22 11, Benjamin Kaduk wrote: > On Thu, 22 Dec 2011, Alexander Best wrote: > > >On Thu Dec 22 11, Dimitry Andric wrote: > >>Hi, > >> > >>I would like to ask some feedback on the attached patch, which cleans up > >>the kernel optimization options for amd64. This was touched upon > >>earlier by Alexander Best in freebsd-toolchain, here: > > > >i've been using such settings for a few months now and haven't noticed any > >problems. > > > >however bruce evans raised a good point (in a private mail). when you > >compile a > >kernel without debugging enabled, -O2 is the default. if you experience > >issues, > >and enable debugging, -O0 now becomes the default. in case the problems > >with > >the kernel were caused by the -O2 option and aren't present with the -O0 > >option, the newly built kernel with debugging enabled will not help you > >fix the > >problems. in that case you would need to set -O2 explicitly in CFLAGS. his > >exact words were: > > > >" > >I don't like -O2 for anything. However, if it is only a default, it is > >not a problem provided it can be canceled easily. And for debugging, you > >want the default to be the same as without debugging, so that (by default) > >you debug the same code that caused the problem. > >" > > > >however i don't think this is fixable. using -O0 for debuggable and > >non-debuggable kernels will cause too much of a slowdown. > > > >having -O2 as the default flag for non-debuggable kernels and -O2 -g for > >debuggable kernels might cause situations, where debugging isn't possible, > >where with -O0 -g it would have been. > > > >so i guess although bruces concerns are valid, they are impossible to > >solve. > > Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] > > -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 01:05:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28A6E106566C; Fri, 23 Dec 2011 01:05:41 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 685D08FC0A; Fri, 23 Dec 2011 01:05:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RdtZr-0002Yw-Ld>; Fri, 23 Dec 2011 02:05:39 +0100 Received: from e178027232.adsl.alicedsl.de ([85.178.27.232] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RdtZr-0007Fs-Dr>; Fri, 23 Dec 2011 02:05:39 +0100 Message-ID: <4EF3D3E2.9000403@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 02:05:38 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Johan Hendriks References: <4EF25468.9040204@gmail.com> <4EF2D814.1090805@freebsd.org> <4EF2F210.6080009@gmail.com> In-Reply-To: <4EF2F210.6080009@gmail.com> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2AB74508AC85FFC0BBAD257" X-Originating-IP: 85.178.27.232 Cc: freebsd-performance@freebsd.org, FreeBSD Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 01:05:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2AB74508AC85FFC0BBAD257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/22/11 10:02, Johan Hendriks wrote: > Stefan Esser schreef: >> Am 21.12.2011 22:49, schrieb Johan Hendriks: >>> Nice page, but one thing i do not get is the following. >>> >>> [quote] >>> If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC= >>> 4.7 then the results are unlikely to tell you anything meaningful abo= ut >>> FreeBSD vs Ubuntu. >>> [/quote] >>> >>> That is a little strange in my opinion. >>> It tells me that FreeBSD falls more and more behind on Linux. >>> The reason is or could be that FreeBSD cannot or will not include GCC= >>> 4.7 and that FreeBSD will not be on par with Linux anymore. >>> To compare it with Formula1 cars. >>> If Mercedes decide to use the engine from 2 seasons back (the engine >>> version 4.2.1) in there 2012 car, and Ferrari uses there new Engine >>> (version 4.7). >>> Can we not compare them anymore because of the decission from Mercede= s >>> to use the old engine? >>> No we just say, if you want to win a race, get the Ferrari. >>> >>> It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! >> As has been pointed out by others, FreeBSD ships with gcc-4.2.1 (with >> some local modifications and fixes) as the system compiler. >=20 >>> If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linu= x >>> to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. >> The gcc version distributed with FreeBSD was chosen for license reason= s, >> not for technical reasons. If you are OK with installing a GPLv3 >> licensed compiler on your systems, then just do it and take advantage = of >> the improved code generated by it. > It does not matter what the decission is to use the old compiler, it is= > a fact that the base comes with 4.2.x > Does that mean we can not compare/benchmark against other distributions= > because they use GPLv3 stuff. > No, i want to know where standard released FreeBSD stands against > standard released Linux distributions. > If you compare benchmark userland applictions, then it is fair to use > the latest compiler for the userland software also on FreeBSD. > But what if the ports tree defaults to LLVM, then again we want to know= > what FreeBSD does against a Linux distribution. > Why because that is what most of us will be using...!! Who ever tried to use gcc 4.6 to compile the base system knows that it is no eays task and it isn't so easy to simply change the compiler! This is also true for a lot of ports. If it is so easy to use a more modern compiler as some of the statements made here would suggest, then I would expect a dedicated chapter in the handbook! In such a case, every systems administrator trying to make a long-term decission what operating system might be the base for the future, does not need to be an enthusiastic of either BSD or Linux to understand how to tweak - fanboys, developers or enthusiasts have already choosen, apart from any rational or reason. What matters are advantages which can be approved. Downlad the DVD, install the OS, do some adjustments regarding to some pages of the manual, choose a propper set of applicable software to benchmark, compile, benchmark the system. Phoronix did so. Well, it's hard for me to find the chapter in the handbook which describes the performance tuning of SCHED_ULE and its sysctl tweaks, someone may call me stupid and point me to the page, please ... >=20 > If we start to compile all the ports with gcc 4.7 to be on par in > comparising and benchmarking, why spend all the time getting LLVM as th= e > default compiler for ports also? > Why not take that effort into making the WHOLE ports tree to compile > with GCC4.7? >=20 > Reason, because FreeBSD goes the LLVM route. That is a decission FreeBS= D > is making! Yes, and it is legitime to question that and bring pro and contra for that decission. But since "FreeBSD" is obviously a small club of people sitting like a duck on eggs (and, by the way, not their own genuine invented eggs, more or less reingeneered eggs), those decissions get more obscure than they seem to be anyway. > And that choise will be the FreeBSD that is used in comparising and > benchmarks on the net , not the utterly overcopiled and tuned FreeBSD > against stock Ubuntu or whatever Linux distribution. >=20 > If it is a good or bad choice! That we will see in the > comparising/benchmarks we will be seeing when that time comes. >=20 > Same goes for the scheduler! and all the other subsystems FreeBSD has > choosen, that makes FreeBSD. >=20 =2E.. sometimes the underdog has to pick up what's left ... >> >>> I my opinion, you benchmark the latest release of Linux, FreeBSD, >>> Solaris, Windows and whatever OS you want to compare! >> As you probably know, Linux is just the kernel and the distributions a= dd >> user space programs, including a compiler. You can easily create a >> "FreeBSD distribution" with more advanced compiler and use or even sel= l >> it. But the FreeBSD project was cautious to not heavily depend on a >> GPLv3 compiler (for reasons openly discussed at the time this decision= >> was made). > I know Linux is a kernel, re read Linux as Linux Distribution! > Yes you can use a more advanced compiler on FreeBSD, BUT you can do tha= t > on Linux also ,so where do you stop? > Are you going to spend a month to compare a fullly tuned up FreeBSD > system against a Linux distribution? > No because the users will not spend months tuning and recompile there > servers. > They use the FreeBSD version that comes with the CD! > And that we want to compare/benchmark against a Linux distribution. When it comes to the question what to benchmark, what would you suggest? Only the Linux kernel, so called LINUX and a couple of self selected, self compiled, probably seld optimized GNU userland tools? At the end I pick up a distribution as it comes from the "vendor", pick up some informations about tweaks for several target workloads and start benchmarking. >=20 >>> You want to benchmark the release and not a tuned version against a >>> standard version. >>> And that in general are the versions most of us users will use. >> If you compare operating systems from a technical point of view, then >> you'll be interested in relative performance of algorithms and methods= >> chosen. This is best achieved by using the same compiler for each of t= he >> candidates. >> >> If you compare performance from a user point of view, you are correct >> that performance delivered out of the box (without complicated tuning)= >> may be, what counts for most users. But those users that depend on bes= t >> performance e.g. for a FreeBSD based embedded product or a data center= , >> may tune the system, including compilation with a newer compiler than >> the system default. >> >>> And what if in the future LLVM gets on par with Linux, is it stil fai= r >>> to compare FreeBSD with Linux? >> You can always compare anything with whatever you like (even apples wi= th >> oranges), but you need to be aware of what you compare and what your >> goals are, to be able to draw reasonable conclusions. >> >> If you want to test out of the box performance, then test with system >> compilers (or just those binaries delivered with the system). >> >> If you want to test for code efficiency or scalability, then use the >> same compilers for each system under test to remove differences >> introduced by the compilers (which are an external component not >> developed by the FreeBSD people). >> >>> Or do we say, well we are on par, but it is not fair, yes we used the= >>> latest releases, but you can not blame Linux because they are still >>> using GCC. >> Depends on what you want or need to measure ... > I am mainly talking about the out of the box comparison, because that i= s > what most sites will do when doing a benchmark. > they want to know if the the all new version of FreeBSD can compete wit= h > the latest release of Ubuntu. > That are the benchmarks you will see on the net. And this is the right way to do. The only way. I start my project now. I got funding now. I have a time contraint to keep to fullfill my scientific work, say, a PhD or a project. I need to look into the future, I need to make decissions for a long haul development. So, I pick up the OSs of my choice and benchmark them as they are. All right, if there is a chapter in the handbook explaining how to tune towards a specific expected workload, much better, so do so =2E.. If this is not the way it is, please correct me! >=20 >=20 >>> No what we will see then are haleluja blogs that FreeBSD is on par wi= th >>> Linux. >> Such blog messages are not common in the FreeBSD community. FreeBSD us= ed >> to have big technical and performance advantages when Linux was young,= >> but even then, there was technical discussion between camps (and many >> concepts were implemented in Linux based on BSD examples; I have taken= >> part in such discussions myself, some 15 to 20 years back). > Well not quite, i remember the mysql on SCHED_ULE reports, and they > where quit haleluja about the whole thing. > Not wrong at all, we are all human and like to compete and even more > like to be on top in what we do. >=20 >=20 >>> For me peformance is not a show stopper, and for the most of us i thi= nk >>> it is not. >>> FreeBSD for me is a clean system that does the job perfect and has a >>> very helpful community. >> Well, this are valid aspects, too, and very hard to with benchmarks ;-= ) >> >> Regards, STefan > I am not saying FreeBSD is bad and is not performing, i just do not > understand why FreeBSD is doing all these things to look good. > Again, most comparisings/benchmarks will be stock *BSD vs a stock Linux= > distribution. > If we want to look good, FreeBSD must make sure there released version > gets on par! > We all know FreeBSD is quite conservative with its default settings. > Maybe we need to set some default settings less conservative. > But i do not know if that is good just for the numbers! >=20 > Regards, > Johan oh --------------enigA2AB74508AC85FFC0BBAD257 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO89PiAAoJEOgBcD7A/5N8hNcIAJatBurrv4Hjl/pyaGSP+wlV v2OjnU5nAL9ahjoC3xqZZ3BAvSGxN2XpFozE5LS4TEQQaPNs7Uy4DBRk3h4Zgc7Z YiVt7wJQouX9Lps7H+5d3sPV7XXqbYJjA304bwWeRoHMjE/gqjmM55eLi3h1Cs0I toHrQf6EV0IOeOqObguBcDdANX4tA1VVZPO0Y48bCC1wSsJvUlt8qw9OOPbUUKGR BFsW6Aqc587vVG+sW1GkKXKShiBfjkVl0sogmxqCSvTesQYkmlRaeN/h2swEzIhK DQm3M4+unIxypCmX9VcgMbtnlywr0JE+7+P8wzl/ftE9M02W3adPftwbDdbsih4= =Q9m2 -----END PGP SIGNATURE----- --------------enigA2AB74508AC85FFC0BBAD257-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 01:17:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA3F106564A; Fri, 23 Dec 2011 01:17:03 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2190C8FC12; Fri, 23 Dec 2011 01:17:03 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rdtkr-0003VQ-6t>; Fri, 23 Dec 2011 02:17:01 +0100 Received: from e178027232.adsl.alicedsl.de ([85.178.27.232] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rdtkr-0007gX-1Q>; Fri, 23 Dec 2011 02:17:01 +0100 Message-ID: <4EF3D68C.2060803@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 02:17:00 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Igor Mozolevsky References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF289CA4D0C93747BA1C84E1" X-Originating-IP: 85.178.27.232 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Daniel Kalchev Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 01:17:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF289CA4D0C93747BA1C84E1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/22/11 10:56, Igor Mozolevsky wrote: > On 22 December 2011 05:54, Daniel Kalchev wrote: [...] >> Any 'benchmark' has a goal. You first define the goal and then measure= how >> different contenders achieve it. Reaching the goal may have several >> measurable metrics, that you will use to later declare the winner in e= ach. >> Besides, you need to define a baseline and be aware of what theoretica= l >> max/min values are possible. >=20 > Treating a benchmark as a binary win/lose is rather naive, it's not a > competition, and (I hope) no serious person ever does that. A proper > benchmark shows true strength and weaknesses so than a well-informed > intelligent decision can be taken by an individual according to that > individual's needs. The caveat, of course, is making your methodology > clear and methods repeatable! >=20 >=20 > Cheers, >=20 > -- Benchmarks also could lead developers to look into more details of the weak points of their OS, if they're open for that. Therefore, benchmarks are very useful. But not if any real fault of the OS is excused by a faulty becnhmarking. I remember that the worse threaded I/O performance of FreeBSD has been long discussed as a bad benchmarks schematics. Or even look at the thread regarding to SCHED_ULE. Why has a user, experiencing really worse performance with SCHED_ULE, in a nearly scientific manner some engineer the fault? I'd expect the developer or care-taking engineer taking care in a more user friendly manner. If a benchmark reveals some severe weak points in FreeBSD and I have to read about obscure tweaks of non documented sysctl, then this OS would be a no-go if I was a manager to make decissions. And yes, i know, FreeBSD is an free and open project. But I also know that this free and open project does not rely only on "volonteers". A volunteers do not expect funding or payment. So, even freeBSD is dependend on some finacial basis and such a basis has to be taken care of= =2E --------------enigAF289CA4D0C93747BA1C84E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO89aMAAoJEOgBcD7A/5N8crUIAMyz/7q/VOujbdrUZrfa9MqN mZv95SkaWn9nBFOxL5FRVbrPgqg8Ys4D82JPsNQwdZbQD+rtGSm1wwQmRsSKu+cZ j4IfOyiLMnNC5e3hWYwjtaVow2QKQjmL9NaQzb3UHe+snD6i8nB/DAwC2jhduhN+ wPXJM61uNV6oaShc7+dOnc+wOz9Q6oDqtXFTZVdalVZkKi8CqEEP428FcH2N1lp2 X2bcPBFi9eOkzyuHk/F4weKMCFFzq13r+7nuz9Dqndc7adbvl08WMoxClP3Foe99 jMA0I8VbRXtdLeoXVlaCqa1+jobCbJFO5Dsu8NM5JdNi2IMa71KTjY1HGyBs4oQ= =UdvK -----END PGP SIGNATURE----- --------------enigAF289CA4D0C93747BA1C84E1-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 01:40:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 62D6E1065675; Fri, 23 Dec 2011 01:40:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7776C156557; Fri, 23 Dec 2011 01:40:11 +0000 (UTC) Message-ID: <4EF3DBF3.8040002@FreeBSD.org> Date: Thu, 22 Dec 2011 17:40:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> In-Reply-To: <20111222072056.GJ80057@glebius.int.ru> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 01:40:12 -0000 On 12/21/2011 23:20, Gleb Smirnoff wrote: > On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: > > D> So does that mean that if I upgrade to the latest HEAD from a system > D> built before the ifconfig changes that when I reboot my network will > D> come up? > > Yes, older infconfig will work in "head < r228571 || head > r228768". I just tried with r228122 and got the same result. dhclient errors out with "can't find em0" although 'ifconfig em0' does produce results. I'm also not sure what you meant by "head > r228768" above, since we're only up to r228824 in total so far. Maybe your time machine works better than mine? :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 01:57:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DF51106566B for ; Fri, 23 Dec 2011 01:57:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C4A148FC12 for ; Fri, 23 Dec 2011 01:57:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RduNk-0006Vv-UG>; Fri, 23 Dec 2011 02:57:13 +0100 Received: from e178027232.adsl.alicedsl.de ([85.178.27.232] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RduNk-0000rl-P3>; Fri, 23 Dec 2011 02:57:12 +0100 Message-ID: <4EF3DFF8.4000801@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 02:57:12 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EF25913.50107@zedat.fu-berlin.de> <20111222155913.GR80057@FreeBSD.org> In-Reply-To: <20111222155913.GR80057@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E032B90606743530A45FA56" X-Originating-IP: 85.178.27.232 Cc: freebsd-current@FreeBSD.org Subject: Re: xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 01:57:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E032B90606743530A45FA56 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 12/22/11 16:59, Gleb Smirnoff wrote: > On Wed, Dec 21, 2011 at 11:09:23PM +0100, Hartmann, O. wrote: > H> OS: FreeBSD 10.0-CURRENT/amd64 r228787 > H>=20 > H> Since the last update of world yesterday were I managed to compile t= he > H> OS WITH_LIBCPLUSPLUS=3DYES in /etc/src.conf, > H> only root is capable to login on the console. > H>=20 > H> I use OpenLDAP 2.4 as the backend for usual users, having also an > H> "emergency" user installed in the local /etc/passwd just in case. > H>=20 > H> The problem is, I can not login via xdm or console login anymore as = any > H> usual user, even not as a user residing in the local passwd file. > H>=20 > H> Trying to login as LDAP backed user, I get the error > H> SASL/DIGEST-MD5 authentication started > H> Login icorrect > H>=20 > H> Inspecting /var/log/auth.log reveals for this incident > H>=20 > H> login: in openpam_check_path_owner_perms(): > H> /usr/local/lib/pam_ldap.so.5: No such file or directory > H>=20 > H> Trying tologin as a local (/etc/passwd backed) user gets > H> sometimes the same login issue, but sporadically I get a login but > H> landing in / instead of /home/user. /home is a ZFS volume. > H>=20 > H> I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many t= imes > H> now since I suspected a fault in compilation (everything is compiled= via > H> CLANG), but I have no success. > H>=20 > H> /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.s= o. > H>=20 > H> It seems, that the OS can not find the homes on the ZFS volume. Doin= g a > H> su - USER works for all LDAP users but not the local users, I receiv= e > H> the error su: no directory. This is very strange. While su - as roo= t > H> does not work, login as such a failing user work, but as mentioned > H> without home. > H>=20 > H> The last thing I did on that box is: I recompiled yesterday evening > H> world, switched the box off. When I switched the box on today, I ran= > H> into this issue. > H>=20 > H> I recompile the system without flag WITH_LIBCPLUSPLUS and see what i= s > H> happening. Do others also see this strange behaviour? >=20 > This is definitely due to libpam update. In my case, I also got message= s: >=20 > openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such= file or directory >=20 > But this doesn't prevent me from logging in. The new PAM code first > tries to dlopen() a library configured in /etc/pam.d with ".5" appended= > to it, this is hardcoded. If failed, it dlopens the exact name from > configuration. So, the message is harmless itself - the pam_ldap.so > is opened successfully. >=20 > I suppose failure to login that you experience is related to another > fallout from the new PAM import. >=20 With the most recent patch and make world the problem has gone! luckily .= =2E. oliver --------------enig5E032B90606743530A45FA56 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO89/4AAoJEOgBcD7A/5N8QGoH/A30QXoxGNYzGt0WTNexD3NL jxNWOtGSxBLlS+JBNDeosMCRL5kRuEjC9BmT9bEsrIwVwXorJLV1P/TzmJ9DJI12 ZOS8xDpdVUWVF8hPOp/tRUdpbR/xDsOyA0OuD8fUoafLAJe5Ec8eN5IfU380LfVJ sjuR6TRF32/mbSQPgTekt3B4f7lhgcd8DmLj9wdjM4HRM19huttxdN9EejbQjNIf MaYlqPmcSQTPjOXPMeie1XXsunBZbKzbnz3XfA/TKq32ygfWpxhsdhH+Tf+R3AK9 f1Wl5kCn3GN0D1TFvADxg7WAAcQQzcnkLvXD+x4IOkxyZkkyKr4XKHRfphyJ180= =niHy -----END PGP SIGNATURE----- --------------enig5E032B90606743530A45FA56-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 02:52:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC247106564A; Fri, 23 Dec 2011 02:52:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1908FC18; Fri, 23 Dec 2011 02:52:00 +0000 (UTC) Received: by iadj38 with SMTP id j38so16040157iad.13 for ; Thu, 22 Dec 2011 18:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=xv00cOMZuV5ayo3qUJZtigfqcLxNJ1G/u23kMBK+toI=; b=VCiz2T+swX5ulU6IbJ+f2iB98dIweo5Uq8fQ3Haw1ISI1coRBt4QMn95BsSAU3Zw+h ovxKw6lT0iySGA175us/juawewohDcOdvf1RK++8qyglTpCkrW6L/lmAMWZo8RdN7gkP 3BHukc1I1FZJ0p0rS0nAG9dkW13M0pN/ENOAE= Received: by 10.42.161.132 with SMTP id t4mr13327117icx.16.1324608719903; Thu, 22 Dec 2011 18:51:59 -0800 (PST) Received: from [10.75.41.133] (mobile-166-205-136-165.mycingular.net. [166.205.136.165]) by mx.google.com with ESMTPS id gh9sm38954438igb.3.2011.12.22.18.51.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 18:51:59 -0800 (PST) References: <4EF34E52.2040905@FreeBSD.org> <20111222192549.GA19008@freebsd.org> <20111223005932.GA65042@freebsd.org> In-Reply-To: <20111223005932.GA65042@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Thu, 22 Dec 2011 18:51:47 -0800 To: Alexander Best Cc: "freebsd-current@freebsd.org" , Dimitry Andric , Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 02:52:00 -0000 On Dec 22, 2011, at 4:59 PM, Alexander Best wrote: > On Thu Dec 22 11, Benjamin Kaduk wrote: >> On Thu, 22 Dec 2011, Alexander Best wrote: >>=20 >>> On Thu Dec 22 11, Dimitry Andric wrote: >>>> Hi, >>>>=20 >>>> I would like to ask some feedback on the attached patch, which cleans u= p >>>> the kernel optimization options for amd64. This was touched upon >>>> earlier by Alexander Best in freebsd-toolchain, here: >>>=20 >>> i've been using such settings for a few months now and haven't noticed a= ny >>> problems. >>>=20 >>> however bruce evans raised a good point (in a private mail). when you=20= >>> compile a >>> kernel without debugging enabled, -O2 is the default. if you experience=20= >>> issues, >>> and enable debugging, -O0 now becomes the default. in case the problems=20= >>> with >>> the kernel were caused by the -O2 option and aren't present with the -O0= >>> option, the newly built kernel with debugging enabled will not help you=20= >>> fix the >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. h= is >>> exact words were: >>>=20 >>> " >>> I don't like -O2 for anything. However, if it is only a default, it is >>> not a problem provided it can be canceled easily. And for debugging, yo= u >>> want the default to be the same as without debugging, so that (by defaul= t) >>> you debug the same code that caused the problem. >>> " >>>=20 >>> however i don't think this is fixable. using -O0 for debuggable and >>> non-debuggable kernels will cause too much of a slowdown. >>>=20 >>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for= >>> debuggable kernels might cause situations, where debugging isn't possibl= e, >>> where with -O0 -g it would have been. >>>=20 >>> so i guess although bruces concerns are valid, they are impossible to=20= >>> solve. >>=20 >> Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. >=20 > sorry. of course i meant -O: >=20 > .if defined(DEBUG) > _MINUS_O=3D -O > CTFFLAGS+=3D -g > .else > [..] Back in the 7.x days, I ran into some code that wasn't easily to debug becau= se the compiler optimized things out with -O2 by inlining and otherwise shif= ting around code, so setting breakpoints in gdb became difficult. So from th= at point on I've gotten into the habit of doing -O explicitly in make.conf i= f DEBUG_FLAGS was specified. Just a thought.. -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 02:56:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03DC106564A; Fri, 23 Dec 2011 02:56:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9572C8FC0A; Fri, 23 Dec 2011 02:56:31 +0000 (UTC) Received: by iadj38 with SMTP id j38so16048658iad.13 for ; Thu, 22 Dec 2011 18:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=C7U0E5PPsXEkzu6WcR6qQiAumZ0/fligcBBPx+q5vbI=; b=Y9k2MSZvPbLQDnA/bCDeEwk1xJG5A4DfHyTUGCHHLgYw1KT1hjcVBQinR8OBDvF1s2 QUK7mVuhaELk+i1bB5xR4/Fuo/oo0cVZ7GalqLM9pgb9c8O7nL8JJBOIeufhjqY2Pg5d Lc332WMvE8mayCPh3fwMSUx34dj3XjoYxZ9qU= Received: by 10.50.170.35 with SMTP id aj3mr11595295igc.2.1324608991063; Thu, 22 Dec 2011 18:56:31 -0800 (PST) Received: from [10.75.41.133] (mobile-166-205-136-165.mycingular.net. [166.205.136.165]) by mx.google.com with ESMTPS id gf6sm38973155igb.1.2011.12.22.18.56.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 18:56:30 -0800 (PST) References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> In-Reply-To: <20111222235846.GA6071@icarus.home.lan> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9706CBFC-9A69-4365-8883-FF45BDFDC108@gmail.com> X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Thu, 22 Dec 2011 18:56:17 -0800 To: Jeremy Chadwick Cc: "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" , "igor@hybrid-lab.co.uk" , Alexander Leidinger , "freebsd-performance@freebsd.org" , "O. Hartmann" Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 02:56:32 -0000 On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick wrot= e: > On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: >> On 12/21/11 19:41, Alexander Leidinger wrote: >>> Hi, >>>=20 >>> while the discussion continued here, some work started at some other pla= ce. Now... in case someone here is willing to help instead of talking, feel f= ree to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what ca= n be improved. The page is far from perfect and needs some additional people= which are willing to improve it. >>>=20 >>> This is only part of the problem. A tuning page in the wiki - which coul= d be referenced from the benchmark page - would be great too. Any volunteers= ? A first step would be to take he tuning-man-page and wikify it. Other tuni= ng sources are welcome too. >>>=20 >>> Every FreeBSD dev with a wiki account can hand out write access to the w= iki. The benchmark page gives contributor-access. If someone wants write acc= ess create a FirstnameLastname account and ask here for contributor-access. >>>=20 >>> Don't worry if you think your english is not good enough, even some one-= word notes can help (and _my_ english got already corrected by other people o= n the benchmark page). >>>=20 >>> Bye, >>> Alexander. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> Nice to see movement ;-) >>=20 >> But there seems something unclear: >>=20 >> man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in >> /etc/make.conf. >> The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. >>=20 >> What's right and what's wrong now? >=20 > I can say with certainty that this value belongs in /etc/make.conf > (on RELENG_8 and earlier at least). >=20 > src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, > so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of sugges= tions are really outdated. I know because I filed a PR last night after I sa= w how out of synch some of the defaults it claimed were with reality on 9.x+= . And I know other suggestions in the manpage are dated as well ;/. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 06:47:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5251065670 for ; Fri, 23 Dec 2011 06:47:16 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 668878FC19 for ; Fri, 23 Dec 2011 06:47:15 +0000 (UTC) Received: (qmail 4306 invoked from network); 23 Dec 2011 06:47:13 -0000 Received: from pd9ec02b0.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.2.176]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 23 Dec 2011 06:47:13 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id 066EF1BAC57; Fri, 23 Dec 2011 07:47:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1324622832; bh=cQB+8TKO5vLCqciaHHbSVsfp1qERUqnQUj35oShp5MA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type; b=NsXkMgj/FwSHvW7Zag1prmzup3/cNJkEdKfWgeG8sxHaBEb7AHuo8Pw+JdO2Qp0qM eAnyed3nDwMYL/JjKAbMHK+hwLQqDvb0fB8+VdaYY+jrvQu3x5Wrz6v7qpWEapD+8D hcGXjc0dz4vKpDTngsCoZ4v8umwS5njZdQ6GDURQ= Date: Fri, 23 Dec 2011 07:47:06 +0100 From: Martin Sugioarto To: "O. Hartmann" Message-ID: <20111223074706.1afe4d26@zelda.sugioarto.com> In-Reply-To: <4EF3D68C.2060803@zedat.fu-berlin.de> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jRZwjGURFyHlrz8lFS52Y/6"; protocol="application/pgp-signature" Cc: Daniel, freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky , Kalchev Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 06:47:16 -0000 --Sig_/jRZwjGURFyHlrz8lFS52Y/6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 23 Dec 2011 02:17:00 +0100 schrieb "O. Hartmann" : > Benchmarks also could lead developers to look into more details of the > weak points of their OS, if they're open for that. Therefore, > benchmarks are very useful. But not if any real fault of the OS is > excused by a faulty becnhmarking. Hi, it is important for the project to be known and I think that the benchmarks made by Phoronix help FreeBSD to gain popularity, even they look bad sometimes. Furthermore, to make a benchmark is a lot of work and the results are useful, because at the end someone will look at it and will try to improve the results. Thank you for investing your time. I remember that I've made some tests with different platforms i386 vs amd64 with simple tools like "openssl speed" some time ago and got some bad results for amd64 that no one cared to explain. These bad results weren't reflected on Linux that I tested later for comparison. And most people have a weird attitude to think that the tester measures wrong instead of taking a look at it. They forget that as a FreeBSD user you would rather see FreeBSD win over Linux. I've seen that Phoronix made various benchmarks about FreeBSD compared to Linux and I can tell you that _subjectively_ the benchmarks reflect what I always thought about FreeBSD. I simply _know_ that FreeBSD is worse in concurrency behavior, I know that it has I/O trouble, I know that it is mostly faster emulating 3D games than Linux runs them natively. I knew this already _before_ you published the benchmark about the 3D performance. I cannot see any evil intentions in these benchmarks. All I can see is the wrong attitude _here_. If anyone thinks that Phoronix makes bad benchmarks, they should do these benchmarks by themselves and publish the results. As long as no one tries, Phoronix stays the best reference for me and for everyone else. And don't forget, benchmarks can never be objective enough and someone will always be mad about the results. Especially, when you present them a "versus battle". A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. When the distribution does not compile with the latest compiler it's simply a bug. Why should one try to penalize the other distribution and downgrade their binaries? When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. -- Martin --Sig_/jRZwjGURFyHlrz8lFS52Y/6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJO9CPvAAoJEF8wvLx/5p/7AscP/36ttnZiUG518fD7APAPwH7d 5h1i23jL29L5eF2XECnjk6sqXX8VasM85186oFSQGiOmCPgTNIU32ke/zhpzm3AN wRffG6SwQEfJWz/jxdbTu0plLchBsIzVtxArLfqVgc9MVsxcyp8+PPGolBESWN27 xQrTasf8G8JZB/HbXIrrins/8h+DWOfUn5yTO5OFmYst5H0Iziy9MhKFh/EqvBXn Lj/2V2Gf0qy9ISDXc6lxHdlZmtANP/0QTSuEBovm/5qZAMoOUSKyUlxd6W+XRfKV S1O1BMp3XL9rZOj9kevgNPKUTKy56Asga1Gpo17iAJP7/9TLnpIndrWOnBWi4dgc bHYUHeyOesdNFc5Wx3bIKtwZWFn8alN5wNK4MveTN02k4KmDkB8Kdu1XzW7guKXj TdrK3vRiqZKIf979knEeUvlE/0jhyew6epEawTqa/u3mt5Of+tAWTnMJkF231+K2 iq3ud0FHRGle0AEEKT77KVvh4LS/kpbWy6EEITKNLg2BCh8LWdQOGHc+BBh7IWhz HS154BQs8F27zTuqh7PWWv4iqG9qr7QltNDldtDYEZGw+Vwe5hyFJ7myqaYXQoF8 98U8xwnToL1yqhLwmiPwTWXSYZAGqgdwPqD5xpcC+WAyUJs+fbi4qsTxD5vBPWqn OyTMoFHe1G+9V1/2upYZ =jyvu -----END PGP SIGNATURE----- --Sig_/jRZwjGURFyHlrz8lFS52Y/6-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 07:22:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5F50106564A; Fri, 23 Dec 2011 07:22:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 31ED48FC08; Fri, 23 Dec 2011 07:22:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBN7Mdxv097757; Fri, 23 Dec 2011 11:22:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBN7Mdvg097756; Fri, 23 Dec 2011 11:22:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 23 Dec 2011 11:22:39 +0400 From: Gleb Smirnoff To: Doug Barton Message-ID: <20111223072239.GC80057@glebius.int.ru> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> <4EF3DBF3.8040002@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF3DBF3.8040002@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:22:41 -0000 On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: D> > D> So does that mean that if I upgrade to the latest HEAD from a system D> > D> built before the ifconfig changes that when I reboot my network will D> > D> come up? D> > D> > Yes, older infconfig will work in "head < r228571 || head > r228768". D> D> I just tried with r228122 and got the same result. dhclient errors out D> with "can't find em0" although 'ifconfig em0' does produce results. The dhclient issue you faced isn't related to my new CARP commit either my SIOCAIFADDR work. I'm sorry that we flooded your email thread with the discussion. The breakage from r228571 looks like: # ifconfig em0 10.0.0.1 ioctl (SIOCAIFADDR): Invalid argument # The breakage from r228313 looks like: Starting dhclient. ifconfig: ioctl (SIOCAIFADDR): File exists D> I'm also not sure what you meant by "head > r228768" above, since we're D> only up to r228824 in total so far. Maybe your time machine works better D> than mine? :) I don't see any problem. r228824 > r228768, isn't it? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 07:30:10 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8ED47106564A; Fri, 23 Dec 2011 07:30:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8D84415254A; Fri, 23 Dec 2011 07:30:03 +0000 (UTC) Message-ID: <4EF42DFB.3050001@FreeBSD.org> Date: Thu, 22 Dec 2011 23:30:03 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> <4EF3DBF3.8040002@FreeBSD.org> <20111223072239.GC80057@glebius.int.ru> In-Reply-To: <20111223072239.GC80057@glebius.int.ru> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:30:10 -0000 On 12/22/2011 23:22, Gleb Smirnoff wrote: > On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: > D> > D> So does that mean that if I upgrade to the latest HEAD from a system > D> > D> built before the ifconfig changes that when I reboot my network will > D> > D> come up? > D> > > D> > Yes, older infconfig will work in "head < r228571 || head > r228768". > D> > D> I just tried with r228122 and got the same result. dhclient errors out > D> with "can't find em0" although 'ifconfig em0' does produce results. > > The dhclient issue you faced isn't related to my new CARP commit either > my SIOCAIFADDR work. I'm sorry that we flooded your email thread with > the discussion. The breakage from r228571 looks like: > > # ifconfig em0 10.0.0.1 > ioctl (SIOCAIFADDR): Invalid argument > # > > The breakage from r228313 looks like: > > Starting dhclient. > ifconfig: ioctl (SIOCAIFADDR): File exists OK, thanks. > D> I'm also not sure what you meant by "head > r228768" above, since we're > D> only up to r228824 in total so far. Maybe your time machine works better > D> than mine? :) > > I don't see any problem. r228824 > r228768, isn't it? D'oh ... I don't know how I missed that, moving too fast, pulled in too many directions, etc. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:07:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E5A106566B; Fri, 23 Dec 2011 09:07:22 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 740418FC18; Fri, 23 Dec 2011 09:07:21 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBN977WM046266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 11:07:13 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF444BB.9090400@digsys.bg> Date: Fri, 23 Dec 2011 11:07:07 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> In-Reply-To: <4EF3D68C.2060803@zedat.fu-berlin.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:07:23 -0000 On 23.12.11 03:17, O. Hartmann wrote: > Or even look at the thread regarding to SCHED_ULE. Why has a user, > experiencing really worse performance with SCHED_ULE, in a nearly > scientific manner some engineer the fault? I'd expect the developer or > care-taking engineer taking care in a more user friendly manner. You remember that those developers are not paid to do what they do? You remember that nobody has sold you this OS and promised support in whatever form? Still, this issue is discussed publicly and experiments are being made, I guess also new code is being experimented. If you are interested in the outcome, just follow the discussion. If you can help with something and you are willing, please do. There will be good solution to the SCHED_ULE shortcomings. FreeBSD is unique group of people, who all sit on their eggs, be it eggs they themselves produced, or they inherited one way or another. These people include all the developers and most of the system administrators and users of FreeBSD. There is no "they" and "us". If your preference for the OS is different, you might feel more comfortable in choosing another OS, probably a commercial OS with support from the vendor. > If a benchmark reveals some severe weak points in FreeBSD and I have > to read about obscure tweaks of non documented sysctl, then this OS > would be a no-go if I was a manager to make decissions. Luckily, managers do not care about knobs or how difficult it is for the system administrator to achieve specific goal. All they care is the bottom line in general and in short therm the goals they have set. No sane manager will care about benchmarks, as long as he gets what he wants. Back, to the Phoronix benchmarks. There has already been communication. Phoronix were given advices on how to better do some things on FreeBSD (which will make the quality of their benchmarks better and therefore more trusted). Phoronix has made their updated test suite available to FreeBSD users (that include developers) to try on their own hardware. By the way, it is in /usr/ports/benchmarks/phoronix-test-suite. Linux and FreeBSD are not enemies, they both solve the same problems with different means. Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:14:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D4901065672; Fri, 23 Dec 2011 09:14:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id AA3DB8FC1E; Fri, 23 Dec 2011 09:14:08 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A412525D3811; Fri, 23 Dec 2011 09:14:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B1BDFBD79A3; Fri, 23 Dec 2011 09:14:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 2PDednAXrQRt; Fri, 23 Dec 2011 09:14:05 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5E1D3BD79A1; Fri, 23 Dec 2011 09:14:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4EF3DBF3.8040002@FreeBSD.org> Date: Fri, 23 Dec 2011 09:14:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> <4EF3DBF3.8040002@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: freebsd-current , Gleb Smirnoff , Brooks Davis Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:14:09 -0000 On 23. Dec 2011, at 01:40 , Doug Barton wrote: > On 12/21/2011 23:20, Gleb Smirnoff wrote: >> On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: >>=20 >> D> So does that mean that if I upgrade to the latest HEAD from a = system >> D> built before the ifconfig changes that when I reboot my network = will >> D> come up? >>=20 >> Yes, older infconfig will work in "head < r228571 || head > r228768". >=20 > I just tried with r228122 and got the same result. dhclient errors out > with "can't find em0" although 'ifconfig em0' does produce results. Which is due to getifaddrs() most likely; please go back and read up the = other half of the thread; I am working on this. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:18:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F14C1065673; Fri, 23 Dec 2011 09:18:13 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 047828FC13; Fri, 23 Dec 2011 09:18:12 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBN9I31R046333 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 11:18:09 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF4474B.3050203@digsys.bg> Date: Fri, 23 Dec 2011 11:18:03 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Sugioarto References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> In-Reply-To: <20111223074706.1afe4d26@zelda.sugioarto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, "O. Hartmann" , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:18:13 -0000 On 23.12.11 08:47, Martin Sugioarto wrote: > A further thing is that I cannot understand the people here sometimes. > I would like that the -RELEASE versions of FreeBSD perform well > without any further optimizations. The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed between both code bases, lots of bugs have been discovered and fixed and new technologies have been integrated. Especially in this line, the compiler has changed from 4.2.1 to 4.2.2. > When the distribution does not compile with the latest compiler it's > simply a bug. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. > Why should one try to penalize the other distribution and downgrade > their binaries? Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. > When FreeBSD has a bad default setup, there must be a reason for that. > Tell me this reason and show me that it's justified in form of some > other benchmark. FreeBSD has safe default. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. If your installation is pre-optimized, chances are it will crash all the time on you and there will be no easy way for you to fix, short of installing another "distribution". Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:38:48 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 816041065677; Fri, 23 Dec 2011 09:38:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BA28614FE8A; Fri, 23 Dec 2011 09:38:47 +0000 (UTC) Message-ID: <4EF44C27.3040600@FreeBSD.org> Date: Fri, 23 Dec 2011 01:38:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> <20111221125539.GF70684@glebius.int.ru> <4EF2430B.5070903@FreeBSD.org> <20111222072056.GJ80057@glebius.int.ru> <4EF3DBF3.8040002@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Gleb Smirnoff , Brooks Davis Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:38:48 -0000 On 12/23/2011 01:14, Bjoern A. Zeeb wrote: > > On 23. Dec 2011, at 01:40 , Doug Barton wrote: > >> On 12/21/2011 23:20, Gleb Smirnoff wrote: >>> On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: >>> >>> D> So does that mean that if I upgrade to the latest HEAD from a system >>> D> built before the ifconfig changes that when I reboot my network will >>> D> come up? >>> >>> Yes, older infconfig will work in "head < r228571 || head > r228768". >> >> I just tried with r228122 and got the same result. dhclient errors out >> with "can't find em0" although 'ifconfig em0' does produce results. > > Which is due to getifaddrs() most likely; please go back and read up the other > half of the thread; I read the whole thread. It's my thread after all. :) I was taking Gleb at his word when he answered my question with "yes." > I am working on this. Excellent. ETA? Normally I wouldn't be worried about updating, but I want to try the newly updated code to recognize music CDs. If it works I would like to encourage re@ to include it in the new release since I think it will save our users a lot of pain. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:38:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1222E106566C; Fri, 23 Dec 2011 10:38:25 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 829018FC18; Fri, 23 Dec 2011 10:38:24 +0000 (UTC) Received: from vhoffman-macbooklocal.local ([10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id pBNAcKPR056271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 10:38:20 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4EF45A1B.1050505@unsane.co.uk> Date: Fri, 23 Dec 2011 10:38:19 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> <9706CBFC-9A69-4365-8883-FF45BDFDC108@gmail.com> In-Reply-To: <9706CBFC-9A69-4365-8883-FF45BDFDC108@gmail.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" , "igor@hybrid-lab.co.uk" , Alexander Leidinger , "freebsd-performance@freebsd.org" , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 10:38:25 -0000 On 23/12/2011 02:56, Garrett Cooper wrote: > On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick wrote: > >> On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: >>> On 12/21/11 19:41, Alexander Leidinger wrote: >>>> Hi, >>>> >>>> while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. >>>> >>>> This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. >>>> >>>> Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. >>>> >>>> Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). >>>> >>>> Bye, >>>> Alexander. >>>> >>>> >>>> >>>> >>> Nice to see movement ;-) >>> >>> But there seems something unclear: >>> >>> man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in >>> /etc/make.conf. >>> The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. >>> >>> What's right and what's wrong now? >> I can say with certainty that this value belongs in /etc/make.conf >> (on RELENG_8 and earlier at least). >> >> src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, >> so, this is definitely a make.conf variable. > Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Vince > Thanks, > -Garrett_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 11:38:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6C601065670; Fri, 23 Dec 2011 11:38:32 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 21D838FC17; Fri, 23 Dec 2011 11:38:31 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBNBcHOV047229 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 13:38:24 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF46829.6010508@digsys.bg> Date: Fri, 23 Dec 2011 13:38:17 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF45C85.9010709@mail.zedat.fu-berlin.de> In-Reply-To: <4EF45C85.9010709@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Sugioarto , freebsd-current@FreeBSD.ORG, Igor Mozolevsky , freebsd-performance@FreeBSD.ORG, "O. Hartmann" , Daniel@FreeBSD.ORG Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:38:32 -0000 On 23.12.11 12:48, O. Hartmann wrote: > Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a > way that is far beyond enough! He gave tests, insights of his setup, > bad performance compared to SCHED_4BSD and what happend? We are still > stuck with this problem and more and more people realise, that FreeBSD > does have somewhere a problem and this seems to be a nasty problem not > easy to find or investigate. This has made me to realize, that I was having a problem with SCHED_ULE that I was not aware of until now. WOW! :) Every scheduler has some problem, some fail here some fail there. I am confident, that the case that Steve Kargls has reported will be resolved. > Another problem is this very elite-feeling closed club. Once you > managed it getting into the club of committers or core team members, > you'll probably fight for your seat ... I dont propose for that > socialists crap Linux people tend to be like, [..] You never heard of the "People's Republic of Berkeley"? :) As for commiter access, this sort of comments trigger the system administrator in me. I have seen enough people, who for the lack of other excuses always use "but I don't have enough RIGHTS!". I am evil, I know.... > But I follow the illusion that if people can see what benchmarks > reveal, they start thinking and if the facts are starting to give a > heavy load load on those rejecting the facts, they migght change their > opinion or get hopefully replaced by more openminded people. Here is now it works: If you see an problem and have a solution: go fix it. Many will be grateful. If you can't fix it, but have an idea how to fix it, share it. May will be grateful. If you can't fix it and don't have any idea, just say "there is a problem" and stop there. There are many, many, many like you who just hold their breath. We all learn, every day. Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 11:44:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B83091065670; Fri, 23 Dec 2011 11:44:24 +0000 (UTC) Date: Fri, 23 Dec 2011 11:44:24 +0000 From: Alexander Best To: Daniel Kalchev Message-ID: <20111223114424.GA60815@freebsd.org> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF4474B.3050203@digsys.bg> Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, "O. Hartmann" , Martin Sugioarto , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:44:24 -0000 On Fri Dec 23 11, Daniel Kalchev wrote: > > > On 23.12.11 08:47, Martin Sugioarto wrote: > >A further thing is that I cannot understand the people here sometimes. > >I would like that the -RELEASE versions of FreeBSD perform well > >without any further optimizations. > > The -RELEASE things is just a freeze (or, let's say tested freeze) of > the corresponding branch at some time. It is the code available and > tested at that time. > > Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than > FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed > between both code bases, lots of bugs have been discovered and fixed and > new technologies have been integrated. Especially in this line, the > compiler has changed from 4.2.1 to 4.2.2. > > >When the distribution does not compile with the latest compiler it's > >simply a bug. > > FreeBSD is not a distribution. It also compiles with the latest compiler > - LLVM. :) > > I find it amusing, that people want everything compiled with GCC 4.7, > which is still very much developing, therefore highly unstable and > (probably) full of bugs. > > >Why should one try to penalize the other distribution and downgrade > >their binaries? > > Many suggested that the Linux binaries be run via the FreeBSD Linux > emulation. Unchanged. > There is one problem here though, the emulation is still 32 bit. plus the current emulation layer is far from complete. a lot of stuff hasn't been implemented yet (meaning it's missing or implemented as dummy code). try running recent firefox linux binaries on freebsd. they will all crash almost instantly. cheers. alex > > >When FreeBSD has a bad default setup, there must be a reason for that. > >Tell me this reason and show me that it's justified in form of some > >other benchmark. > > FreeBSD has safe default. It is supposed to work out of the box on > whatever hardware you put it. As much as it has drives for that > hardware, of course. > Once you have working installation, you may tweak it all the way you wish. > > If your installation is pre-optimized, chances are it will crash all the > time on you and there will be no easy way for you to fix, short of > installing another "distribution". > > Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:48:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B82A1065672; Fri, 23 Dec 2011 10:48:42 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C36368FC1B; Fri, 23 Dec 2011 10:48:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Re2g1-0005Kp-J0>; Fri, 23 Dec 2011 11:48:37 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Re2g1-0007XM-Gu>; Fri, 23 Dec 2011 11:48:37 +0100 Message-ID: <4EF45C85.9010709@mail.zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 11:48:37 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Sugioarto References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> In-Reply-To: <20111223074706.1afe4d26@zelda.sugioarto.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Fri, 23 Dec 2011 12:25:03 +0000 Cc: freebsd-current@freebsd.org, Igor Mozolevsky , Kalchev , freebsd-performance@freebsd.org, "O. Hartmann" , Daniel@FreeBSD.ORG Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 10:48:42 -0000 On 12/23/11 07:47, Martin Sugioarto wrote: > Am Fri, 23 Dec 2011 02:17:00 +0100 > schrieb "O. Hartmann" : > >> Benchmarks also could lead developers to look into more details of the >> weak points of their OS, if they're open for that. Therefore, >> benchmarks are very useful. But not if any real fault of the OS is >> excused by a faulty becnhmarking. > > Hi, > > it is important for the project to be known and I think that the > benchmarks made by Phoronix help FreeBSD to gain popularity, even they > look bad sometimes. > > Furthermore, to make a benchmark is a lot of work and the results are > useful, because at the end someone will look at it and will try to > improve the results. Thank you for investing your time. > > I remember that I've made some tests with different platforms i386 vs > amd64 with simple tools like "openssl speed" some time ago and got some > bad results for amd64 that no one cared to explain. These bad results > weren't reflected on Linux that I tested later for comparison. And most > people have a weird attitude to think that the tester measures wrong > instead of taking a look at it. They forget that as a FreeBSD user you > would rather see FreeBSD win over Linux. > > I've seen that Phoronix made various benchmarks about FreeBSD compared > to Linux and I can tell you that _subjectively_ the benchmarks reflect > what I always thought about FreeBSD. I simply _know_ that FreeBSD is > worse in concurrency behavior, I know that it has I/O trouble, I know > that it is mostly faster emulating 3D games than Linux runs them > natively. I knew this already _before_ you published the benchmark > about the 3D performance. > > I cannot see any evil intentions in these benchmarks. All I can see is > the wrong attitude _here_. If anyone thinks that Phoronix makes bad > benchmarks, they should do these benchmarks by themselves and publish > the results. As long as no one tries, Phoronix stays the best reference > for me and for everyone else. There IS NO EVIL INTENTION, except, hypothetical, the benchmarker is of the age were he is called a "beardless". But: In many articles, there is a very distinguished and underlined emphasizing of Linux that makes me feeling people have their Linux-glasses on. Linux is not UNIX! And if today someone tells me about the Linux-graphical subsystem X11, I turn green in my face ... X11 was, in former days, a development made on UNIX and is adopted by Linux. Ok, we all know that, most of all ... And the aspect of reference: I agree. They do something and this thread arose while they did. > > And don't forget, benchmarks can never be objective enough and someone > will always be mad about the results. Especially, when you present them > a "versus battle". > > A further thing is that I cannot understand the people here sometimes. > I would like that the -RELEASE versions of FreeBSD perform well without > any further optimizations. When the distribution does not compile with > the latest compiler it's simply a bug. Why should one try to penalize > the other distribution and downgrade their binaries? When FreeBSD has a > bad default setup, there must be a reason for that. Tell me this reason > and show me that it's justified in form of some other benchmark. Well, look at the mailing list. FreeBSD is handled via this list since we are spread around the globe and even the developers are spread worldwide. But when it comes to detecting worse performnce and someone isn't capable of giving a detailed insight and mostly scientific way of investigating the fault he experienced, the discussion, if it starts, get drowned by allegations like "bad testing", worse optimizations blabla. Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a way that is far beyond enough! He gave tests, insights of his setup, bad performance compared to SCHED_4BSD and what happend? We are still stuck with this problem and more and more people realise, that FreeBSD does have somewhere a problem and this seems to be a nasty problem not easy to find or investigate. But look at how Steve has been silenced in the past ... Benchmarks, especially published ones, reveal those pits and soemone could look into it. Another problem is this very elite-feeling closed club. Once you managed it getting into the club of committers or core team members, you'll probably fight for your seat ... I dont propose for that socialists crap Linux people tend to be like, overcrowded townhalls full of important people with non-consense opinions. The other extreme end of this spectrum. I can not change this. And I do not know whether there is a real way-in-the-middle. But I follow the illusion that if people can see what benchmarks reveal, they start thinking and if the facts are starting to give a heavy load load on those rejecting the facts, they migght change their opinion or get hopefully replaced by more openminded people. A Vision. Oliver From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 11:01:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E8F106566C; Fri, 23 Dec 2011 11:01:35 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id AD1DE8FC08; Fri, 23 Dec 2011 11:01:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Re2sX-0007R5-V1>; Fri, 23 Dec 2011 12:01:34 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Re2sX-0008Fa-Sy>; Fri, 23 Dec 2011 12:01:33 +0100 Message-ID: <4EF45F8D.9030404@mail.zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 12:01:33 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Daniel Kalchev References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <4EF444BB.9090400@digsys.bg> In-Reply-To: <4EF444BB.9090400@digsys.bg> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Fri, 23 Dec 2011 12:25:18 +0000 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 11:01:35 -0000 On 12/23/11 10:07, Daniel Kalchev wrote: > > > On 23.12.11 03:17, O. Hartmann wrote: >> Or even look at the thread regarding to SCHED_ULE. Why has a user, >> experiencing really worse performance with SCHED_ULE, in a nearly >> scientific manner some engineer the fault? I'd expect the developer or >> care-taking engineer taking care in a more user friendly manner. > > You remember that those developers are not paid to do what they do? > You remember that nobody has sold you this OS and promised support in > whatever form? Well, as far as I know, the FreeBSD project is funding people doing a certain work! So, the implied opposit, FreeBSD is developed "free" isn't true. > > Still, this issue is discussed publicly and experiments are being made, > I guess also new code is being experimented. > If you are interested in the outcome, just follow the discussion. If you > can help with something and you are willing, please do. There will be > good solution to the SCHED_ULE shortcomings. > > FreeBSD is unique group of people, who all sit on their eggs, be it eggs > they themselves produced, or they inherited one way or another. These > people include all the developers and most of the system administrators > and users of FreeBSD. There is no "they" and "us". What I am in this terminology? I can hardly write some scientific code for my science, I'm able to patch software a bit, that has been developed only for Linux these days (ISIS3 from the USGS, for instance, but I do not dare to publish the crap of port I produced since it is not "professional"). I'm with FreeBSD now since 1996/97. I'm still with the system, although I desperately need scientific grade compilers or GPGPU support. So, even if Linux offers me a really much more convenient way to do my work, I stayed with FreeBSD since there is no real alternative in terms of cleaness of the system. I have also to administer an Ubuntu and Suse server and I feel not amused by this script hell that covers the real system just to get kiddies or Windows-Admins into the "admin-position". And, I dare to put some critics herein! Since I see that FreeBSD is "free", why not trying to make it better and more towards perfect? > > If your preference for the OS is different, you might feel more > comfortable in choosing another OS, probably a commercial OS with > support from the vendor. This is nonesense, you know that, regarding to my case. > >> If a benchmark reveals some severe weak points in FreeBSD and I have >> to read about obscure tweaks of non documented sysctl, then this OS >> would be a no-go if I was a manager to make decissions. > > Luckily, managers do not care about knobs or how difficult it is for the > system administrator to achieve specific goal. All they care is the > bottom line in general and in short therm the goals they have set. No > sane manager will care about benchmarks, as long as he gets what he wants. Well, in real world and beyond this armchair polemics, managers at last do the decissions. Those people dropping math, physics, with no glue to how things work in nature get a degree in law, business and whatsowever and then decide. In my eyes, those are enemies of every development and progress, but this is polemics, too. I faced this many times and it is hard to convince those people not taking care of knobs. But as an admin myself, I need to know about knobs and if essential knobs are not documented, than there is a potential gone for the OS in question. Look at FreeBSD and the problem of how well sysctls and their working are documented. It needs to be fixed. > > Back, to the Phoronix benchmarks. There has already been communication. > Phoronix were given advices on how to better do some things on FreeBSD > (which will make the quality of their benchmarks better and therefore > more trusted). Phoronix has made their updated test suite available to > FreeBSD users (that include developers) to try on their own hardware. By > the way, it is in /usr/ports/benchmarks/phoronix-test-suite. Yes, everyone interseted in this thread and communicating is aware of that fact. > > Linux and FreeBSD are not enemies, they both solve the same problems > with different means. > > Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:21:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D181065670 for ; Fri, 23 Dec 2011 13:21:46 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 567FB8FC13 for ; Fri, 23 Dec 2011 13:21:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Za4bCEpIW7xbBQtZ7JPySNup67scnvBTWm93iiUubfQ=; b=cOWX/VU6ia8HaOzJi1StBM92h/XGxcoFGcwYJtIHRsSyC8QNgaNfaZMBoUTk8qrPg1PzHPtHzy0yQpX2cQ7wiCxP/fgBHRW8m5tTQ44Ycw6VmD82RhAnTIYLu8qp2+GTF71/EBadRuM7BSAtETx6L6d45NbSDPGrnGwCsX9Qen4=; Received: from cpe-72-177-69-180.austin.res.rr.com ([72.177.69.180]:50841 helo=[192.168.200.118]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Re548-000PdG-Dm for freebsd-current@freebsd.org; Fri, 23 Dec 2011 07:21:45 -0600 Message-ID: <4EF48065.8000802@lerctr.org> Date: Fri, 23 Dec 2011 07:21:41 -0600 From: Larry Rosenman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-LERCTR-Spam-Score: 0.5 (/) X-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 Subject: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:21:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? (repost without the screenshot). - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9IBlAAoJENC8dtAvA1zmAJAIAL67TPUdIigtumkBLHZM1qCo 7JFfBXpyEjH8vs0bkCk+GYSCke67IGMUpiR5XeZ8UsKjiTtyyhw1SQZYIw/EiVvf 7Nf+DOxbKIYEPezeEqpaskejItfOM6h7ajZovRNTJsrNH+ha0csGgFk46iEFH5Qq LTQ7D5GrFj+hCzNDLcbxWOiTqxGMlTboZun5C0Y6BYK09RpLqMtU6bIh/37zj7kr u4VSh94hPW8t8qTnL5rlETMAjvmtIivphEVv/R5jOv0cGtNP/o2QaM66w3TaxyJ0 Z9ixNuzq3MAft20VRrVdUEnZ43DASv7Aisl2GNoaTNRW/MVuaULG/PdA9hj2vZ8= =G2La -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:31:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E98106566C for ; Fri, 23 Dec 2011 13:31:57 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 9467F8FC16 for ; Fri, 23 Dec 2011 13:31:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=spcRR78WPIMJCMYVzn/4mh2Cwv9bu+ra0qy4AWiT/XU=; b=MsCB69sYv56J5CuPTEaofSaQKWVDmbbsDcwPX99+5osJnMcOhZg+1CChlxZdbEz/GEbEszLies/sqZ/YQucK48TBibLMuk9P9gXnhwbKKOoyFcQ+NB+q8ukD02qs399VN0zR/fdDueQx49Uod91JNFPOhANSBF1u+RztaptHEbM=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1Re5E1-000O66-2x ; Fri, 23 Dec 2011 15:31:53 +0200 Date: Fri, 23 Dec 2011 15:31:50 +0200 From: Ivan Klymenko To: Larry Rosenman Message-ID: <20111223153150.368968f5@nonamehost.> In-Reply-To: <4EF48065.8000802@lerctr.org> References: <4EF48065.8000802@lerctr.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:31:58 -0000 =D0=92 Fri, 23 Dec 2011 07:21:41 -0600 Larry Rosenman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I've been getting these in a VirtualBox VM. I'm not sure what to do. >=20 > I CAN give VNC access to this VM in this state. >=20 > panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 > ftick 1213618 itick 1214628 tick pri 159 > cpuid =3D 0 > KDB: enter: panic >=20 > Ideas? > (repost without the screenshot). uname -a ??? From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:38:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8C81106564A for ; Fri, 23 Dec 2011 13:38:25 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 872B38FC08 for ; Fri, 23 Dec 2011 13:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wM/8pS7tsr54MeiOgkLJwALX3mCP0FJgmBeYiBx/gMA=; b=RD0pErRwxmT3AjRpmT7xkxhtD+Gal1b133N9PzvPgEkR1Zc32LULIPJjAj95pCyK6hziM9bP15NE49jpwOZQKboYeSzKLgjJpC9AENNHdGJehguFvXzu3jXc4ofefNXEAozkC3f5AWu+V/CBJokkWaUy+ictpTGhVnNUy96Pq68=; Received: from cpe-72-177-69-180.austin.res.rr.com ([72.177.69.180]:50987 helo=[192.168.200.118]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Re5KF-000Pjh-Hs; Fri, 23 Dec 2011 07:38:25 -0600 Message-ID: <4EF4844D.2060308@lerctr.org> Date: Fri, 23 Dec 2011 07:38:21 -0600 From: Larry Rosenman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Ivan Klymenko References: <4EF48065.8000802@lerctr.org> <20111223153150.368968f5@nonamehost.> In-Reply-To: <20111223153150.368968f5@nonamehost.> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-LERCTR-Spam-Score: 0.5 (/) X-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 Cc: freebsd-current@freebsd.org Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:38:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/23/2011 7:31 AM, Ivan Klymenko wrote: > Ð’ Fri, 23 Dec 2011 07:21:41 -0600 Larry Rosenman > пишет: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> I've been getting these in a VirtualBox VM. I'm not sure what to >> do. >> >> I CAN give VNC access to this VM in this state. >> >> panic: sched_priority: invalid priority 331: nice 0, ticks >> 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: >> enter: panic >> >> Ideas? (repost without the screenshot). > > uname -a ??? Oops. It's running the same kernel as it's host: $ uname -a FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r228802: Thu Dec 22 11:21:25 CST 2011 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 $ I can also give SSH access to the host as well. - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9IRMAAoJENC8dtAvA1zmxJEIALP7wzsx9Co9QaE+Cx3JK2vx pCRJqLBTkpsnzdYmGsczBAUpEXJ/POx+7UsWycd48zQlT64FZubeHGi2yIIZNOzL zpYdaY/70cacFuyouMtZyLOrCTLiJe4AVBOluA79zCNgJKIcIhGyGSObsO7CqiiR oS2MHyWy9n5oLo6Qf79708gar4QXHDZwVkgRZ3heWeZY+wPt8CVrzX5k8uf7dSlz Yq4+A1G9atfuprp6iRUTIT7aHKKv6IwM3QAg2wuaUqatUYsJv8ushRrsZHfJmmft /LmMmHMlaqqsDy4Wjm0v5souid6vIuGv7zyOxfILCnk/9UnWEEThqpP31mu362k= =skwU -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:47:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B53C106564A for ; Fri, 23 Dec 2011 13:47:47 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 19F128FC14 for ; Fri, 23 Dec 2011 13:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=iT4DkWEpC1KJTQ22mOWbM/pyngsiRaL4DUdfLkFGJRI=; b=L5taqtClIIbOhpJHU28kPqUxMnJS0kqymTInsryusp9XGZgGmC7CkhxbgiMoVVy3UMqifw6fFfgQQNMC7owzLFVZpzknjmvEHXP9Nfg6uuT0j4rBgfb3oSQu6xlRKUypiDGUEzk7loQzJLy65T3+k1qbHjHpcdRlIcrQ4DALOZA=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1Re5TN-0003Gf-Kc ; Fri, 23 Dec 2011 15:47:45 +0200 Date: Fri, 23 Dec 2011 15:47:43 +0200 From: Ivan Klymenko To: Larry Rosenman Message-ID: <20111223154743.0d1dc49c@nonamehost.> In-Reply-To: <4EF4844D.2060308@lerctr.org> References: <4EF48065.8000802@lerctr.org> <20111223153150.368968f5@nonamehost.> <4EF4844D.2060308@lerctr.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:47:47 -0000 =D0=92 Fri, 23 Dec 2011 07:38:21 -0600 Larry Rosenman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > BORG-DTRACE Show, please, the kernel config BORG-DTRACE From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:52:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FA3B1065781 for ; Fri, 23 Dec 2011 13:52:11 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0577F8FC08 for ; Fri, 23 Dec 2011 13:52:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=Pnzoo3xDU9mLvqejLpN2vquF1fl6LMugcaqDR4yPR/I=; b=N2/J9Sp4lUdN9kAXGX/hypsml18mDCsuHnbV2vMgVCCZKtiGX23J5mxPb1wsJMAkfqOyWAdIKhgO4+SCuOZx2wN/Ta5vTJM+hYRCN3tYuNcRAWmaxVQI6EYJTs4m20BFUDNix8+AafXlLjt5NOORCM8+lvXeUDYKQWqt3tZ4VpM=; Received: from cpe-72-177-69-180.austin.res.rr.com ([72.177.69.180]:48591 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Re5XZ-000Pqj-RZ; Fri, 23 Dec 2011 07:52:10 -0600 Date: Fri, 23 Dec 2011 07:52:02 -0600 (CST) From: Larry Rosenman Sender: ler@borg To: Ivan Klymenko In-Reply-To: <20111223154743.0d1dc49c@nonamehost.> Message-ID: References: <4EF48065.8000802@lerctr.org> <20111223153150.368968f5@nonamehost.> <4EF4844D.2060308@lerctr.org> <20111223154743.0d1dc49c@nonamehost.> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.2 (--) X-LERCTR-Spam-Score: -2.2 (--) X-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TW_CB=0.077, TW_FX=0.077, TW_II=0.077, TW_IW=0.077, TW_MW=0.077, TW_SB=0.077, TW_SN=0.077, TW_TX=0.077, TW_XG=0.077 X-LERCTR-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TW_CB=0.077, TW_FX=0.077, TW_II=0.077, TW_IW=0.077, TW_MW=0.077, TW_SB=0.077, TW_SN=0.077, TW_TX=0.077, TW_XG=0.077 Cc: freebsd-current@freebsd.org Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:52:11 -0000 On Fri, 23 Dec 2011, Ivan Klymenko wrote: > ? Fri, 23 Dec 2011 07:38:21 -0600 > Larry Rosenman ?????: > >> BORG-DTRACE > Show, please, the kernel config BORG-DTRACE > include GENERIC ident BORG-DTRACE options KDTRACE_HOOKS # all architectures - enable general DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data options KDTRACE_FRAME # amd64 - ensure frames are compiled in #makeoptions DEBUG="-g" # amd64? - build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 #options COMPAT_FREEBSD8 nooptions WITNESS nodevice mvs nodevice siis nodevice ahc nodevice ahd nodevice amd nodevice hptiop nodevice isp nodevice mpt nodevice mps nodevice sym nodevice trm nodevice adv nodevice adw nodevice aic nodevice bt nodevice amr nodevice arcmsr nodevice asr nodevice ciss nodevice dpt nodevice hptmv nodevice hptrr nodevice iir nodevice ips nodevice mly nodevice twa nodevice aac nodevice aacp nodevice ida nodevice mfi nodevice mlx nodevice twe nodevice tws nodevice cbb nodevice pccard nodevice cardbus nodevice plip nodevice puc nodevice bxe nodevice de nodevice igb nodevice ixgbe nodevice le nodevice ti nodevice txp nodevice vx nodevice ae nodevice age nodevice alc nodevice ale nodevice bce nodevice bfe nodevice bge nodevice dc nodevice et nodevice fxp nodevice jme nodevice lge nodevice msk nodevice mge nodevice pcn nodevice re nodevice rl nodevice sf nodevice sge nodevice sis nodevice sk nodevice ste nodevice stge nodevice tl nodevice tx nodevice vge nodevice vr nodevice wb nodevice xl nodevice cs nodevice ed nodevice ex nodevice ep nodevice fe nodevice sn nodevice xe nodevice wlan nodevice wlan_wep nodevice wlan_ccmp nodevice wlan_tkip nodevice wlan_amrr nodevice an nodevice ath nodevice ath_pci nodevice ath_hal nodevice ath_rate_sample nodevice ipw nodevice iwi nodevice iwn nodevice malo nodevice mwl nodevice ral nodevice wi nodevice wpi nodevice urio # Diamond Rio 500 MP3 player # USB Serial devices nodevice u3g # USB-based 3G modems (Option, Huawei, Sierra) nodevice uark # Technologies ARK3116 based serial adapters nodevice ubsa # Belkin F5U103 and compatible serial adapters nodevice uftdi # For FTDI usb serial adapters nodevice uipaq # Some WinCE based devices nodevice uplcom # Prolific PL-2303 serial adapters nodevice uslcom # SI Labs CP2101/CP2102 serial adapters nodevice uvisor # Visor and Palm devices nodevice uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus nodevice aue # ADMtek USB Ethernet nodevice axe # ASIX Electronics USB Ethernet nodevice cdce # Generic USB over Ethernet nodevice cue # CATC USB Ethernet nodevice kue # Kawasaki LSI USB Ethernet nodevice rue # RealTek RTL8150 USB Ethernet nodevice udav # Davicom DM9601E USB # USB Wireless nodevice rum # Ralink Technology RT2501USB wireless NICs nodevice run # Ralink Technology RT2700/RT2800/RT3000 NICs. nodevice uath # Atheros AR5523 wireless NICs nodevice upgt # Conexant/Intersil PrismGT wireless NICs. nodevice ural # Ralink Technology RT2500USB wireless NICs nodevice urtw # Realtek RTL8187B/L wireless NICs nodevice zyd # ZyDAS zd1211/zd1211b wireless NICs # FireWire support nodevice firewire # FireWire bus code nodevice sbp # SCSI over FireWire (Requires scbus and da) nodevice fwe # Ethernet over FireWire (non-standard!) nodevice fwip # IP over FireWire (RFC 2734,3146) nodevice dcons # Dumb console driver nodevice dcons_crom # Configuration ROM for dcons # Sound support nodevice sound # Generic sound driver (required) nodevice snd_es137x # Ensoniq AudioPCI ES137x nodevice snd_hda # Intel High Definition Audio nodevice snd_ich # Intel, NVidia and other ICH AC'97 Audio nodevice snd_uaudio # USB Audio nodevice snd_via8233 # VIA VT8233x Audio device netmap options FFCLOCK I've also seen it with GENERIC, FWIW. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:15:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F5F1065677 for ; Fri, 23 Dec 2011 13:15:13 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7468FC12 for ; Fri, 23 Dec 2011 13:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=lnNKWaMGbL3kC+qEr001F0aFcxyOL5X7dqvIbb4yW3Q=; b=HDtb6DVKkLk73touBiGRK3pJeDX1WY/bbYZluu87M9io1tTYd0XoWr5xTZcE/3/OJrXHjomY6MZrCs4CHObf1nubtdP3AM/gmB0cZSVvfj8OOFdqQScqcRsRkAe4HEcdgsgmcpMA84Lf3DjCFE09lPivdPx+6FsG9hwItIYQQec=; Received: from cpe-72-177-69-180.austin.res.rr.com ([72.177.69.180]:50784 helo=[192.168.200.118]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Re4xl-000Pas-P5 for freebsd-current@freebsd.org; Fri, 23 Dec 2011 07:15:11 -0600 Message-ID: <4EF47EDA.3000507@lerctr.org> Date: Fri, 23 Dec 2011 07:15:06 -0600 From: Larry Rosenman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.3.4 Content-Type: multipart/mixed; boundary="------------030705040204070007000804" X-Spam-Score: 1.6 (+) X-LERCTR-Spam-Score: 1.6 (+) X-Spam-Report: SpamScore (1.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, DC_PNG_UNO_LARGO=0.001, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (1.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, DC_PNG_UNO_LARGO=0.001, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-Mailman-Approved-At: Fri, 23 Dec 2011 14:27:08 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:15:13 -0000 This is a multi-part message in MIME format. --------------030705040204070007000804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9H7aAAoJENC8dtAvA1zmXg8H/3lmAWQBszmBCPv2ucbH4JE8 c7M20HHmtJZtISal/FAkjFD324xDDAIwwZhBlB5bJZzXw3RE+BuCuJy+yYdIcGQd 3DGUvli2ryhOpE8xzkG1i9qIyBvMV8B2lxgdpnAGTtuCnMQPEMGUNPST6RrTivHs gSk+KxtrmuEtpIowKxeg4HC2JIyF2VQikd0eximYM2b9pRQg5eYiO6HG4xoKJCxh OQJ3hbITveoSlevd9QddKUQeD7y80KnBT2KNIZsr9HtErZCIDcZYJAXIAgcGUPDW F9lXVTj7+vaX8YEgZc1i/WExKnyvq3qyQQQktSWSnInzHlMg8nItovZduwtE23E= =nqba -----END PGP SIGNATURE----- --------------030705040204070007000804 Content-Type: application/octet-stream; name="paninc.PNG.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="paninc.PNG.sig" iQEcBAABAgAGBQJO9H7aAAoJENC8dtAvA1zmZQAH/03ICM7mRbA8nybWncEn6yabH8Ua4V5m cnaH/VuGYLGGdRoqMPA/QjaVLhOLnTXsshAZ7Dmx4fFsXE7BxqSoys5zZwe0kqCooB1hkZpg wBkHnYNCsOUhXoUqQVPnkX/nxLK80M3kED73mH298E4SB8oARB/NVnlNO3wa+A8vRwEGzBvP mHZsVqpBCxJg86cXSo3jxkdbVVaQOxgVjOU4/UG+YPOXKTerT+BC/BNL82Ip694sDARC9WCv a9t6dJFsJ9e2yl1b4N6rhAZFF3Cu/EA4Kc1WO8P20HE6uQXhtbwIRB7GZ3caseywEcx8dRm0 o5RRjDWLLUqctQXVSaY2/3M= --------------030705040204070007000804-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 14:47:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305F51065670 for ; Fri, 23 Dec 2011 14:47:48 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD118FC1C for ; Fri, 23 Dec 2011 14:47:45 +0000 (UTC) Received: (qmail 16114 invoked from network); 23 Dec 2011 14:47:44 -0000 Received: from pd9ec0d76.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.13.118]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 23 Dec 2011 14:47:44 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id DF6A31BAC55; Fri, 23 Dec 2011 15:47:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1324651662; bh=mFe3u5VorPV9E1SBudYtAdIa7JtOxWe1OwGFU1LzEDM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type; b=OtZTgt9mxbvakGgfFoPI1jdk81n/E1iOmd42d1mGbquht/JMRblstxLGpQwGXp6k9 K2CD0H0KqSHuj1DAM3lZTj8Z67i4mnPswNNj2vur1xgOIz6HfOmCOeaDO/MK6Lhb7f SYprbxTwAy+Xa15CguEA5ElAxYLyFe4GmFrzZkow= Date: Fri, 23 Dec 2011 15:47:37 +0100 From: Martin Sugioarto To: Daniel Kalchev Message-ID: <20111223154737.4e5da6de@zelda.sugioarto.com> In-Reply-To: <4EF4474B.3050203@digsys.bg> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3wOr79UdKqdOz/Px5Xh3l2d"; protocol="application/pgp-signature" Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, "O. Hartmann" , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 14:47:48 -0000 --Sig_/3wOr79UdKqdOz/Px5Xh3l2d Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 23 Dec 2011 11:18:03 +0200 schrieb Daniel Kalchev : > The -RELEASE things is just a freeze (or, let's say tested freeze) of=20 > the corresponding branch at some time. It is the code available and=20 > tested at that time. Hi Daniel, obviously performance is not a quality aspect, only stability. =20 > FreeBSD is not a distribution. It also compiles with the latest > compiler=20 > - LLVM. :) I thought that the "D" in FreeBSD stands for "distribution". Yes, it's ok that it compiles with LLVM. Does it also run faster in benchmarks? > I find it amusing, that people want everything compiled with GCC 4.7,=20 > which is still very much developing, therefore highly unstable and=20 > (probably) full of bugs. When you don't use the software don't complain that it is buggy, because you won't find the bugs. You cannot always tell the others to make everything perfect. I don't want to have everything compiled on $COMPILER. I want that there is a reasonable quality. And for me quality is not only stability, but also speed. > Many suggested that the Linux binaries be run via the FreeBSD Linux=20 > emulation. Unchanged. > There is one problem here though, the emulation is still 32 bit. I'm not talking about emulation. I don't use FreeBSD to run emulated binaries. I (any many people) want efficient servers and eventually desktops. You should not expect people to tune the system for speed, when it's clear that default setting does not make any sense. People will use default settings, because they trust developers that they thought about balanced stability, security and performance. > FreeBSD has safe default. This is what I am talking about. Don't complain that the benchmark does not show efficience. No one is interested in tuning FreeBSD just for a benchmark application. > It is supposed to work out of the box on=20 > whatever hardware you put it. As much as it has drives for that=20 > hardware, of course. > Once you have working installation, you may tweak it all the way you > wish. But if you don't tweak, you get a fair result in a benchmark. This is what you will see as a user of the system. These are the default settings, that means developers chose them as the BEST choice for the system. =20 > If your installation is pre-optimized, chances are it will crash all > the time on you and there will be no easy way for you to fix, short > of installing another "distribution". Sorry, no. If optimization makes bugs appear, there are bugs in the code (somewhere). And you will never find them when you hide them like this. You will also never see many advances in performance. -- Martin --Sig_/3wOr79UdKqdOz/Px5Xh3l2d Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJO9JSMAAoJEF8wvLx/5p/7B70QAKjhEOblVtgDInsp7eHvvHWH FxrbRUjA+5XZywGs7qAbys2uEljX0CQ0Oe3s/pk56f0euyTyhQextYUnb9AiupG8 dPMz2e86oDhgeeIKJy2fNSZ3mh//7W1+JWU6VlaloExKNBIz/wXcMHiCI1gXtE0y opMGWIKHxyvcbrvWRI9fOyM6q7KZP1ygsbC/T3L7+jzr4SXOXVWHcOz35yh+tyBs XbUtZhu1EmkTNzpJOCmUfBm/bqY1RevNmMCOzBDsafB/opnJ9zqx5vagTmpxktfp G1e0V0pXoV22e3XDSAo0mMxR1pHqwegexdbUk2LZ9OnE/yz7NZhmjpSdjeoaE2fV 4o4LjAEaExkj2m96+neDDcbOh//2QJC76ijCIC0rA3Smjz+HPTlE0/o115S2mlCR MK0J6xWbTfQPl85kv9kZzJeGLQodjr6ttRgjXOQYLK1Lb2IZoqGAwrjv2qZj9r9h awosYg2tsMgsRQXNFV6/3oLpgPSamHCFoC4jlIA/7mLeemDS+EVcqUNf9h9JA9ey IgAG22RumA6XCPHyQ0TY+VtlJIJX0mdGk/5NWncPQKNHDr9ciWCogLFMPdIr8FE8 EPqTV6kk06FORReI6xNV/UVOZnKa2JfOazBiBdXPJwyJKgdN8eCAqNkZHAZC4Dd8 OoUoTI2t6q3+hYzc58rV =35Is -----END PGP SIGNATURE----- --Sig_/3wOr79UdKqdOz/Px5Xh3l2d-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 14:54:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B28E106566C; Fri, 23 Dec 2011 14:54:59 +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 1ED3C8FC0A; Fri, 23 Dec 2011 14:54:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id A1E4746B3C; Fri, 23 Dec 2011 09:54:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2B8BFB962; Fri, 23 Dec 2011 09:54:58 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 23 Dec 2011 09:37:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> In-Reply-To: <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112230937.08971.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Dec 2011 09:54:58 -0500 (EST) Cc: Garrett Cooper , Alexander Best , Dimitry Andric , Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 14:54:59 -0000 On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: > On Dec 22, 2011, at 4:59 PM, Alexander Best wrote: > > > On Thu Dec 22 11, Benjamin Kaduk wrote: > >> On Thu, 22 Dec 2011, Alexander Best wrote: > >> > >>> On Thu Dec 22 11, Dimitry Andric wrote: > >>>> Hi, > >>>> > >>>> I would like to ask some feedback on the attached patch, which cleans up > >>>> the kernel optimization options for amd64. This was touched upon > >>>> earlier by Alexander Best in freebsd-toolchain, here: > >>> > >>> i've been using such settings for a few months now and haven't noticed any > >>> problems. > >>> > >>> however bruce evans raised a good point (in a private mail). when you > >>> compile a > >>> kernel without debugging enabled, -O2 is the default. if you experience > >>> issues, > >>> and enable debugging, -O0 now becomes the default. in case the problems > >>> with > >>> the kernel were caused by the -O2 option and aren't present with the -O0 > >>> option, the newly built kernel with debugging enabled will not help you > >>> fix the > >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. his > >>> exact words were: > >>> > >>> " > >>> I don't like -O2 for anything. However, if it is only a default, it is > >>> not a problem provided it can be canceled easily. And for debugging, you > >>> want the default to be the same as without debugging, so that (by default) > >>> you debug the same code that caused the problem. > >>> " > >>> > >>> however i don't think this is fixable. using -O0 for debuggable and > >>> non-debuggable kernels will cause too much of a slowdown. > >>> > >>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for > >>> debuggable kernels might cause situations, where debugging isn't possible, > >>> where with -O0 -g it would have been. > >>> > >>> so i guess although bruces concerns are valid, they are impossible to > >>> solve. > >> > >> Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. > > > > sorry. of course i meant -O: > > > > .if defined(DEBUG) > > _MINUS_O= -O > > CTFFLAGS+= -g > > .else > > [..] > > Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS="-g -fno-inline" Just adding -fno-inline makes a world of difference. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 14:55:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20BF1065673; Fri, 23 Dec 2011 14:54:59 +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 9FA868FC0C; Fri, 23 Dec 2011 14:54:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 357E546B45; Fri, 23 Dec 2011 09:54:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DF1FB963; Fri, 23 Dec 2011 09:54:58 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 23 Dec 2011 09:54:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF48065.8000802@lerctr.org> In-Reply-To: <4EF48065.8000802@lerctr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112230954.57591.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Dec 2011 09:54:58 -0500 (EST) Cc: Alexander Motin , Larry Rosenman Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 14:55:00 -0000 On Friday, December 23, 2011 8:21:41 am Larry Rosenman wrote: > I've been getting these in a VirtualBox VM. I'm not sure what to do. > > I CAN give VNC access to this VM in this state. > > panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 > ftick 1213618 itick 1214628 tick pri 159 In the past this happened because the 'ticks' value was bananas. Priority values should only be from 0 to 255, so 331 is definitely too large. The priority is computed like so: pri = SCHED_PRI_MIN; if (td->td_sched->ts_ticks) pri += SCHED_PRI_TICKS(td->td_sched); pri += SCHED_PRI_NICE(td->td_proc->p_nice); KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, ("sched_priority: invalid priority %d: nice %d, " "ticks %d ftick %d ltick %d tick pri %d", pri, td->td_proc->p_nice, td->td_sched->ts_ticks, td->td_sched->ts_ftick, td->td_sched->ts_ltick, SCHED_PRI_TICKS(td->td_sched))); Note that you have: kern/sched_ule.c: #define PRI_TIMESHARE_RANGE (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE + 1) #define PRI_INTERACT_RANGE ((PRI_TIMESHARE_RANGE - SCHED_PRI_NRESV) / 2) #define PRI_BATCH_RANGE (PRI_TIMESHARE_RANGE - PRI_INTERACT_RANGE) #define PRI_MIN_INTERACT PRI_MIN_TIMESHARE #define PRI_MAX_INTERACT (PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE - 1) #define PRI_MIN_BATCH (PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE) #define PRI_MAX_BATCH PRI_MAX_TIMESHARE #define SCHED_PRI_NRESV (PRIO_MAX - PRIO_MIN) sys/resource.h: #define PRIO_MIN -20 #define PRIO_MAX 20 sys/priority.h: #define PRI_MIN_TIMESHARE (120) #define PRI_MAX_TIMESHARE (PRI_MIN_IDLE - 1) #define PRI_MIN_IDLE (224) So PRI_MAX_BATCH is 223. PRI_MIN_BATCH is 120 + (((223 - 120 + 1) - (20 - -20)) / 2) which is 152. So given SCHED_PRI_TICKS() of 159, you end up with 152 + 159 = 311, and since your nice is 0, SCHED_PRI_NICE() ends up being 20, hence 331. It seems the largets value SCHED_PRI_TICKS() should ever generate is (PRI_BATCH_RANGE - SCHED_PRI_NRESV), though ULE doesn't quite compute it that way (it might be off by one): #define SCHED_PRI_NRESV (PRIO_MAX - PRIO_MIN) #define SCHED_PRI_NHALF (SCHED_PRI_NRESV / 2) #define SCHED_PRI_MIN (PRI_MIN_BATCH + SCHED_PRI_NHALF) #define SCHED_PRI_MAX (PRI_MAX_BATCH - SCHED_PRI_NHALF) #define SCHED_PRI_RANGE (SCHED_PRI_MAX - SCHED_PRI_MIN + 1) However, it's not clear that SCHED_PRI_TICKS() will cap its value to SCHED_PRI_RANGE: #define SCHED_PRI_TICKS(ts) \ (SCHED_TICK_HZ((ts)) / \ (roundup(SCHED_TICK_TOTAL((ts)), SCHED_PRI_RANGE) / SCHED_PRI_RANGE)) The sloppiest fix might be to do this: Index: sched_ule.c =================================================================== --- sched_ule.c (revision 228777) +++ sched_ule.c (working copy) @@ -1434,7 +1434,8 @@ sched_priority(struct thread *td) } else { pri = SCHED_PRI_MIN; if (td->td_sched->ts_ticks) - pri += SCHED_PRI_TICKS(td->td_sched); + pri += min(SCHED_PRI_TICKS(td->td_sched), + SCHED_PRI_RANGE); pri += SCHED_PRI_NICE(td->td_proc->p_nice); KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, ("sched_priority: invalid priority %d: nice %d, " -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 14:56:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D8D3106564A for ; Fri, 23 Dec 2011 14:56:56 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 24B3B8FC18 for ; Fri, 23 Dec 2011 14:56:54 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id EEACC5619E; Fri, 23 Dec 2011 08:56:53 -0600 (CST) Date: Fri, 23 Dec 2011 08:56:53 -0600 From: Mark Linimon To: "O. Hartmann" Message-ID: <20111223145653.GA24107@lonesome.com> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <4EF444BB.9090400@digsys.bg> <4EF45F8D.9030404@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF45F8D.9030404@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky , Daniel Kalchev Subject: FreeBSD funding [was: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1] Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 14:56:56 -0000 I have slightly reordered your email in my reply, in order to put the most important item last. On Fri, Dec 23, 2011 at 12:01:33PM +0100, O. Hartmann wrote: > I'm still with the system, although I desperately need scientific grade > compilers or GPGPU support. Your use-case, while valid, is clearly not the use-case that most of the committers working on FreeBSD face. But see below. > And, I dare to put some critics herein! Since I see that FreeBSD is > "free", why not trying to make it better and more towards perfect? Everyone wants the product to improve. The question is, what is achievable with the current committers? That's where you see the pushback and frustration from the current committers. > Look at FreeBSD and the problem of how well sysctls and their > working are documented. It needs to be fixed. There's no argument that some of the FreeBSD documentation is stale. We do, however, have one committer (eadler@) who has been trying to move the sysctl documentation forwards. Participation from the wider community is key. Although sending PRs does not guarantee things will get fixed, it's currently the best way that we have. > Well, as far as I know, the FreeBSD project is funding people doing a > certain work! So, the implied opposite, FreeBSD is developed "free" > isn't true. So here's the key point of your email IMHO, and the key misunderstanding. First, let me nit-pick the legalities. The FreeBSD Foundation (http://www.freebsdfoundation.org/) is a US non-profit that does fund some activities, and that's what I'll talk about here. "The FreeBSD Project" is the collective term for "all of the committers and developers" and is not an "entity" for US legal purposes. Second, the disclaimers: I am not a member of the FreeBSD Foundation Board of Directors, so I am not speaking for them. I have also directly benefited from Foundation funding (both travel, and via equipment they bought for portmgr), so am hardly unbiased. Now on to the gist of that matter. As a US non-profit, the Foundation is required to post its financial information to the public, and it does on its website: http://www.freebsdfoundation.org/documents/Budget2011.pdf You'll see here that the total budget for 2011 is $400k (USD). This, frankly, is miniscule. The largest line item for 2011 is $125k for project funding, which has gone towards 9 different projects (see http://www.freebsdfoundation.org/activities.shtml). For comparison, keep in mind that a commercial developers' salary in the US is upwards of $100k/yr. Even with this being a substantial increase from 2010's $83k, these numbers are tiny comared to "real-world" budgets. The projects that were sponsored were primarily networking-related, but also the GEM/KMS/DRI project, jails, the libc++ replacement, and clocks. I've listed those in the order that I think the most consumers of FreeBSD will be affected by. Note the absence of any work towards performance, schedulers, compilers, or numerical analysis. With a $125k budget, you're simply not going to see those on the list. The other notable line items are: hardware purchases (explicit disclaimer: portmgr has been one of the primary beneficiaries); conference sponsorship; conference travel; and salary for one employee to try to help coordinate all the above. Legal fees (things involving trademarking and licensing issues) takes up most of the remaining. I can't figure out the Linux Foundation's budget from their website, but I can tell immediately that their budget is a great many times more than $400k. Summary: on a fraction of the budget that Linux has available, we _nearly keep up_. I can't imagine what we could do with comparable funding. So, for everyone who thinks we are being "well funded", here's your reality check. And please note that the Foundation is in its year-end fund drive, too. Thanks for listening. mcl From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:00:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 922F01065670; Fri, 23 Dec 2011 15:00:07 +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 3D2D78FC14; Fri, 23 Dec 2011 15:00:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id DF7EB46B09; Fri, 23 Dec 2011 10:00:06 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6ED65B955; Fri, 23 Dec 2011 10:00:06 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 23 Dec 2011 10:00:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> In-Reply-To: <20111222235846.GA6071@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112231000.05712.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Dec 2011 10:00:06 -0500 (EST) Cc: freebsd-current@freebsd.org, igor@hybrid-lab.co.uk, Alexander Leidinger , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:00:07 -0000 On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote: > On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: > > On 12/21/11 19:41, Alexander Leidinger wrote: > > > Hi, > > > > > > while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. > > > > > > This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. > > > > > > Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. > > > > > > Don't worry if you think your english is not good enough, even some one- word notes can help (and _my_ english got already corrected by other people on the benchmark page). > > > > > > Bye, > > > Alexander. > > > > > > > > > > > > > > > > Nice to see movement ;-) > > > > But there seems something unclear: > > > > man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in > > /etc/make.conf. > > The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. > > > > What's right and what's wrong now? > > I can say with certainty that this value belongs in /etc/make.conf > (on RELENG_8 and earlier at least). > > src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, > so, this is definitely a make.conf variable. Eh, normal make variables can go in src.conf as well. They do not have to be listed in bsd.own.mk. World builds include /etc/src.conf whereas every make invocation includes /etc/make.conf via sys.mk. The only reason to use /etc/src.conf is to have a place to put variables only affect make buildworld / buildkernel but do not affect other make invocations. Also, MALLOC_PRODUCTION is generally enabled in a stable branch as part of making the stable branch, there should be no need to set it manually in a stable branch. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:22:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC171106566B; Fri, 23 Dec 2011 15:22:57 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9518FC0C; Fri, 23 Dec 2011 15:22:57 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBNFMl7O048645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 17:22:53 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EF49CC6.9050901@digsys.bg> Date: Fri, 23 Dec 2011 17:22:46 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Sugioarto References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> <20111223154737.4e5da6de@zelda.sugioarto.com> In-Reply-To: <20111223154737.4e5da6de@zelda.sugioarto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, "O. Hartmann" , Igor Mozolevsky Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:22:57 -0000 On 23.12.11 16:47, Martin Sugioarto wrote: > I thought that the "D" in FreeBSD stands for "distribution". Yes, it's > ok that it compiles with LLVM. Does it also run faster in benchmarks? It does. From a language perspective. It is a "distribution", because at the times BSD was developed, it was not a complete operating system. It was supposed to be "added" to say AT&T System V to make it networking capable etc. The Linux people use the word "distribution" in a different context. > I don't want to have everything compiled on $COMPILER. I want that > there is a reasonable quality. And for me quality is not only > stability, but also speed. You can always have faster algorithm if it is not necessary to produce the right answer. > But if you don't tweak, you get a fair result in a benchmark. This is > what you will see as a user of the system. These are the default > settings, that means developers chose them as the BEST choice for the > system. Developers are not Gods. Developers have no clue on what system and for what purpose you will use the software. All they may do for you is to provide enough knobs for you to tune your system for your hardware/application and also make sure that the system scales, when you turn the knobs. Daniel From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:24:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A96106564A for ; Fri, 23 Dec 2011 15:24:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id EC49C8FC1B for ; Fri, 23 Dec 2011 15:24:54 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta09.emeryville.ca.mail.comcast.net with comcast id CfF91i0031Y3wxoA9fQoCc; Fri, 23 Dec 2011 15:24:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id Cfml1i0171t3BNj8bfmlmr; Fri, 23 Dec 2011 15:46:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BC566102C19; Fri, 23 Dec 2011 07:24:52 -0800 (PST) Date: Fri, 23 Dec 2011 07:24:52 -0800 From: Jeremy Chadwick To: John Baldwin Message-ID: <20111223152452.GA21957@icarus.home.lan> References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> <201112231000.05712.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112231000.05712.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 23 Dec 2011 15:33:55 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, igor@hybrid-lab.co.uk, Alexander Leidinger , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:24:55 -0000 On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote: > On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote: > > On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: > > > On 12/21/11 19:41, Alexander Leidinger wrote: > > > > Hi, > > > > > > > > while the discussion continued here, some work started at some other > place. Now... in case someone here is willing to help instead of talking, feel > free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can > be improved. The page is far from perfect and needs some additional people > which are willing to improve it. > > > > > > > > This is only part of the problem. A tuning page in the wiki - which > could be referenced from the benchmark page - would be great too. Any > volunteers? A first step would be to take he tuning-man-page and wikify it. > Other tuning sources are welcome too. > > > > > > > > Every FreeBSD dev with a wiki account can hand out write access to the > wiki. The benchmark page gives contributor-access. If someone wants write > access create a FirstnameLastname account and ask here for contributor-access. > > > > > > > > Don't worry if you think your english is not good enough, even some one- > word notes can help (and _my_ english got already corrected by other people on > the benchmark page). > > > > > > > > Bye, > > > > Alexander. > > > > > > > > > > > > > > > > > > > > > > Nice to see movement ;-) > > > > > > But there seems something unclear: > > > > > > man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in > > > /etc/make.conf. > > > The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. > > > > > > What's right and what's wrong now? > > > > I can say with certainty that this value belongs in /etc/make.conf > > (on RELENG_8 and earlier at least). > > > > src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, > > so, this is definitely a make.conf variable. > > Eh, normal make variables can go in src.conf as well. They do not have > to be listed in bsd.own.mk. World builds include /etc/src.conf whereas > every make invocation includes /etc/make.conf via sys.mk. The only reason > to use /etc/src.conf is to have a place to put variables only affect > make buildworld / buildkernel but do not affect other make invocations. I was always under the impression src.conf(5) variables had to be manually added to bsd.own.mk and similar bits (e.g. src/tools/build/options/WITH_xxx which is what's used to create the src.conf(5) man page), but upon your comment and manual investigation on my part, I found you're indeed right. Taken from bsd.own.mk: 107 .if !defined(_WITHOUT_SRCCONF) 108 SRCCONF?= /etc/src.conf 109 .if exists(${SRCCONF}) 110 .include "${SRCCONF}" 111 .endif 112 .endif As long as third-party software doesn't depend on MALLOC_PRODUCTION for something (I don't know why something would, but who knows; maybe there's a third-party malloc implementation which might?), then putting it in src.conf would be fine (src/lib/libc/stdlib files reference it). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:40:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AF710657C4; Fri, 23 Dec 2011 15:40:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id EA2238FC1E; Fri, 23 Dec 2011 15:40:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Re7EV-0000PZ-Dd>; Fri, 23 Dec 2011 16:40:31 +0100 Received: from e178023009.adsl.alicedsl.de ([85.178.23.9] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Re7EV-0005P1-73>; Fri, 23 Dec 2011 16:40:31 +0100 Message-ID: <4EF4A0E8.1050601@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 16:40:24 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Sugioarto References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> <20111223154737.4e5da6de@zelda.sugioarto.com> In-Reply-To: <20111223154737.4e5da6de@zelda.sugioarto.com> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig59B71D83F5A2078083DBFC0A" X-Originating-IP: 85.178.23.9 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky , Daniel Kalchev Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:40:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig59B71D83F5A2078083DBFC0A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/23/11 15:47, Martin Sugioarto wrote: > Am Fri, 23 Dec 2011 11:18:03 +0200 > schrieb Daniel Kalchev : >=20 >> The -RELEASE things is just a freeze (or, let's say tested freeze) of = >> the corresponding branch at some time. It is the code available and=20 >> tested at that time. >=20 > Hi Daniel, >=20 > obviously performance is not a quality aspect, only stability. > =20 >> FreeBSD is not a distribution. It also compiles with the latest >> compiler=20 >> - LLVM. :) >=20 > I thought that the "D" in FreeBSD stands for "distribution". Yes, it's > ok that it compiles with LLVM. Does it also run faster in benchmarks? >=20 >> I find it amusing, that people want everything compiled with GCC 4.7, = >> which is still very much developing, therefore highly unstable and=20 >> (probably) full of bugs. >=20 > When you don't use the software don't complain that it is buggy, > because you won't find the bugs. You cannot always tell the others to > make everything perfect. As with GCC4.7, CLANG/LLVM is still considered "experimental" and definitely has some issues with CPU architectures beyond Core2. Personally, I compile everthing now with CLANG on FreeBSD 9.0/10.0 as far as I don't realise any conerns towards correctness and stability. Well, the GCC 4.7 came somewhere up and I picked it up, sorry. It is much easier to replace gcc 4.7 in this thread by 4.6.2, which is now considered stable and in production. And as some of the writers in this thread mentioned, the performance gain could be enormous since gcc 4.6 does support either core i7 architectures and its new facilities, the optimizer is aware of the core/uncore design an, maybe, of the three-folded cache levels. Is the legacy gcc 4.2 aware of that? I guess not, since it does not support architectures beyond Core2. I tried using gcc 4.6.2 from ports to compile world, but I failed. Simply replacing/setting CC, CXX and CPP isn't obviosuly enough. >=20 > I don't want to have everything compiled on $COMPILER. I want that > there is a reasonable quality. And for me quality is not only > stability, but also speed. Yes, agree. I think quality could inherit also a reasonable speed. Speed at all costs, even stability, is no option. Even for HPC systems, where jobs run uninetrupted for weeks or months (in our case). >=20 >> Many suggested that the Linux binaries be run via the FreeBSD Linux=20 >> emulation. Unchanged. >> There is one problem here though, the emulation is still 32 bit. With the usage of even 32bit Linux binaries you introduce all the mess you want to avoid by using FreeBSD. But it is very often recommended to use the so called Linuxulator. I'm happy to have this opportunity (I can not run FreeBSD binaries on some Ubuntu or Centos distros). But in some cases people of the FreeBSD community rely to much on this 32bit-limited option. I always prefer native BLOBs over emulated BLOBs. >=20 > I'm not talking about emulation. I don't use FreeBSD to run emulated > binaries. I (any many people) want efficient servers and eventually > desktops. You should not expect people to tune the system for speed, > when it's clear that default setting does not make any sense. People > will use default settings, because they trust developers that they > thought about balanced stability, security and performance. >=20 >> FreeBSD has safe default. >=20 > This is what I am talking about. Don't complain that the benchmark does= > not show efficience. No one is interested in tuning FreeBSD just for a > benchmark application. >=20 >> It is supposed to work out of the box on=20 >> whatever hardware you put it. As much as it has drives for that=20 >> hardware, of course. >> Once you have working installation, you may tweak it all the way you >> wish. >=20 > But if you don't tweak, you get a fair result in a benchmark. This is > what you will see as a user of the system. These are the default > settings, that means developers chose them as the BEST choice for the > system. Well, it is a very nice moce to have conservative settings to make FreeBSD stable for everyone intend to use it out of the box. But what I really miss is a certain, group of people dedicated to HPC and secure, stable tweak achieving that. The operating system is a nature and live. It is a balance of a limited resource. One can try to balance out every potential workload that can occur and the result is a very good allround syste, But in the server or HPC area, it might be necessary to push some parts in favor of some others. When computing, I do not need high USB performance, except a responsive keyboard. I/O and CPU performance is the main goal, but this seems the most difficult part. A file or network server, for instance, would balance more towards network I/O or delivering small data pieces instead of large streaming blocks of memory. I'm certain that the tweaks would differ for both scenarios. At home or at the desktop, the situation is more complicated, since people tend to use a lot of multimedia stuff and jumping audio is also not a very pleasant thing as stuck video. > =20 >> If your installation is pre-optimized, chances are it will crash all >> the time on you and there will be no easy way for you to fix, short >> of installing another "distribution". >=20 > Sorry, no. If optimization makes bugs appear, there are bugs in the > code (somewhere). And you will never find them when you hide them like > this. You will also never see many advances in performance. >=20 > -- > Martin Agree. Benchmarking could push a system towards its limits and reveal limits or bugs that make them crash. It is better to have them crash in a benchmark torture than in a data center delivering valuable data for business or in science, when the server crashes just before finishing a two month run due to some buffer problems ... oh --------------enig59B71D83F5A2078083DBFC0A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO9KDuAAoJEOgBcD7A/5N8i5UH/A0PFxhgokV/43lyNvbCsp2M +rLcZVKwnC4y8/ZudlRmR5PqjRdrhFQiBxKOVR1nEjPjL84wZGvwGj6d5xTzJL4x KXEV4R67jbtXeQCyEWlZuXwIRDLyDP0IcKb7QTx2+eqtLNZPdgIN73UiYkQi/iS4 aJ285fa9nK9SU3s8IpRMK1FcbTsUE7B1lOFiDH0RUEgClq+eI+BVQ4DitQejoT1v 0OO7mK4IPAsdSlmEFc9NvBY3cQtTIii+lACpFzIPXuggLUV1OE4XOSEOCTF3XBkz fZNHf/OQTUpiUT7PG2B4vYaa6PlLG822TBETfIxmQyLw9o+LTU7aZ8oxzasUecE= =1D13 -----END PGP SIGNATURE----- --------------enig59B71D83F5A2078083DBFC0A-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 16:00:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6815D1065687; Fri, 23 Dec 2011 16:00:32 +0000 (UTC) Date: Fri, 23 Dec 2011 16:00:32 +0000 From: Alexander Best To: John Baldwin Message-ID: <20111223160032.GA18839@freebsd.org> References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112230937.08971.jhb@freebsd.org> Cc: Garrett Cooper , freebsd-current@freebsd.org, Dimitry Andric , Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 16:00:32 -0000 On Fri Dec 23 11, John Baldwin wrote: > On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: > > On Dec 22, 2011, at 4:59 PM, Alexander Best wrote: > > > > > On Thu Dec 22 11, Benjamin Kaduk wrote: > > >> On Thu, 22 Dec 2011, Alexander Best wrote: > > >> > > >>> On Thu Dec 22 11, Dimitry Andric wrote: > > >>>> Hi, > > >>>> > > >>>> I would like to ask some feedback on the attached patch, which cleans up > > >>>> the kernel optimization options for amd64. This was touched upon > > >>>> earlier by Alexander Best in freebsd-toolchain, here: > > >>> > > >>> i've been using such settings for a few months now and haven't noticed any > > >>> problems. > > >>> > > >>> however bruce evans raised a good point (in a private mail). when you > > >>> compile a > > >>> kernel without debugging enabled, -O2 is the default. if you experience > > >>> issues, > > >>> and enable debugging, -O0 now becomes the default. in case the problems > > >>> with > > >>> the kernel were caused by the -O2 option and aren't present with the -O0 > > >>> option, the newly built kernel with debugging enabled will not help you > > >>> fix the > > >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. his > > >>> exact words were: > > >>> > > >>> " > > >>> I don't like -O2 for anything. However, if it is only a default, it is > > >>> not a problem provided it can be canceled easily. And for debugging, you > > >>> want the default to be the same as without debugging, so that (by default) > > >>> you debug the same code that caused the problem. > > >>> " > > >>> > > >>> however i don't think this is fixable. using -O0 for debuggable and > > >>> non-debuggable kernels will cause too much of a slowdown. > > >>> > > >>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for > > >>> debuggable kernels might cause situations, where debugging isn't possible, > > >>> where with -O0 -g it would have been. > > >>> > > >>> so i guess although bruces concerns are valid, they are impossible to > > >>> solve. > > >> > > >> Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. > > > > > > sorry. of course i meant -O: > > > > > > .if defined(DEBUG) > > > _MINUS_O= -O > > > CTFFLAGS+= -g > > > .else > > > [..] > > > > Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and > otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O > explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. > > I still leave -O2 in, but what I do is this: > > make DEBUG_FLAGS="-g -fno-inline" would making -O2 -fno-inline the default flags introduce any major slowdown? all that would be needed then to build a debugging kernel would be to add -g. cheers. alex > > Just adding -fno-inline makes a world of difference. > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 16:42:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BAF21065672; Fri, 23 Dec 2011 16:42:29 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id C27CF8FC1C; Fri, 23 Dec 2011 16:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=f/Ej62poUBFpXpkCFVrhJILIg+YzVj+qaeil6D6hdzA=; b=W0lul2tcEUY2e+df/Q5OLWtG7ZY6OCuBGqNd3YvZ9jRQKvl876nZ0em92exZ+iSb+qIVPtRXfoHDJb5uKX31GHQu8E0Au9MBrsltpLrtiFP5lFLc8f2sOGcMuJ3zqISbmEpG9WGg4S46UYMynu/5yu+/KNkZ3irdtBe5iSs1hyU=; Received: from [32.97.110.60] (port=2460 helo=[9.41.58.142]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Re8CQ-00014n-Og; Fri, 23 Dec 2011 10:42:28 -0600 Message-ID: <4EF4AF5C.1060000@lerctr.org> Date: Fri, 23 Dec 2011 10:42:04 -0600 From: Larry Rosenman Organization: LERCTR Consulting User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <4EF48065.8000802@lerctr.org> <201112230954.57591.jhb@freebsd.org> In-Reply-To: <201112230954.57591.jhb@freebsd.org> X-Enigmail-Version: 1.3.4 OpenPGP: id=2F035CE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-LERCTR-Spam-Score: 0.5 (/) X-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (0.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: scheduler panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 16:42:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/23/2011 8:54 AM, John Baldwin wrote: > The sloppiest fix might be to do this: > > Index: sched_ule.c > =================================================================== > > - --- sched_ule.c (revision 228777) > +++ sched_ule.c (working copy) @@ -1434,7 +1434,8 @@ > sched_priority(struct thread *td) } else { pri = SCHED_PRI_MIN; if > (td->td_sched->ts_ticks) - pri += SCHED_PRI_TICKS(td->td_sched); > + pri += min(SCHED_PRI_TICKS(td->td_sched), + > SCHED_PRI_RANGE); pri += SCHED_PRI_NICE(td->td_proc->p_nice); > KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, > ("sched_priority: invalid priority %d: nice %d, " > I've applied this to both the host and the guest, and am recompiling the guest kernel (hopefully it'll stay up long enough...). I'll report back. Do y'all (FreeBSD Devs) want a PR? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9K9cAAoJENC8dtAvA1zmruAIAL0udaYatGWp5E/Th9YYD8Hh FHVri/G/Va8YsivqfZLFYUZd8SyqO/0vxEIoG73iKJJmjW/CpYIjgOvCRvsCrefm ABOYmRX0dvC8GLHDgN9XFt4J9GmNTDcneNV7rOvWKisygkHw0GlK5DxKtSo3PsE8 6MQSnUuVmUMggsVQfBUiPTyTmJigcJ9KuEdfbHQ2o7+sCWx+gAKCyfVFcwkNIrYv M7j21dJ8hjHUteHZ3YttVjYku0/YISSmtvGVCMlm2xBGD+tTu5g2ZcqZsxzlRFst HyLGDP3mKSQJRMHcvl+OXMmwnFO7m31fLhj04LIWardV93S3CYF0c54LNEHYEN4= =/imM -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 17:03:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E385C1065670; Fri, 23 Dec 2011 17:03:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A29138FC16; Fri, 23 Dec 2011 17:03:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8108:6e02:8e8c:934f] (unknown [IPv6:2001:7b8:3a7:0:8108:6e02:8e8c:934f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DDFEF5C37; Fri, 23 Dec 2011 18:03:39 +0100 (CET) Message-ID: <4EF4B46E.7000405@FreeBSD.org> Date: Fri, 23 Dec 2011 18:03:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Alexander Best References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> <20111223160032.GA18839@freebsd.org> In-Reply-To: <20111223160032.GA18839@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:03:41 -0000 On 2011-12-23 17:00, Alexander Best wrote: ... >>> Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and >> otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O >> explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. >> >> I still leave -O2 in, but what I do is this: >> >> make DEBUG_FLAGS="-g -fno-inline" > > would making -O2 -fno-inline the default flags introduce any major slowdown? Not major, but a minor slowdown is quite possible, especially on arches like x86, where call overhead is relatively high, and code caches are relatively large. Anyway, I'd rather get the thread back to my original patch instead of messing around with the default flags for release, which have been -O2 for a long time now. If people want to override those for specific reasons, they can always set COPTFLAGS or DEBUG_FLAGS manually, like John shows. The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 17:26:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15CC10656AD; Fri, 23 Dec 2011 17:26:43 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 41E138FC18; Fri, 23 Dec 2011 17:26:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Re8tF-0003gF-Su>; Fri, 23 Dec 2011 18:26:41 +0100 Received: from e178023009.adsl.alicedsl.de ([85.178.23.9] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Re8tF-00021A-NF>; Fri, 23 Dec 2011 18:26:41 +0100 Message-ID: <4EF4B9D1.8010900@zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 18:26:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> <201112231000.05712.jhb@freebsd.org> <20111223152452.GA21957@icarus.home.lan> In-Reply-To: <20111223152452.GA21957@icarus.home.lan> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1502F529B2C0204E19EA4E4D" X-Originating-IP: 85.178.23.9 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, igor@hybrid-lab.co.uk, Alexander Leidinger , freebsd-performance@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1502F529B2C0204E19EA4E4D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/23/11 16:24, Jeremy Chadwick wrote: > On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote: >> On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote: >>> On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: >>>> On 12/21/11 19:41, Alexander Leidinger wrote: >>>>> Hi, >>>>> >>>>> while the discussion continued here, some work started at some othe= r=20 >> place. Now... in case someone here is willing to help instead of talki= ng, feel=20 >> free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look = what can=20 >> be improved. The page is far from perfect and needs some additional pe= ople=20 >> which are willing to improve it. >>>>> >>>>> This is only part of the problem. A tuning page in the wiki - which= =20 >> could be referenced from the benchmark page - would be great too. Any = >> volunteers? A first step would be to take he tuning-man-page and wikif= y it.=20 >> Other tuning sources are welcome too. >>>>> >>>>> Every FreeBSD dev with a wiki account can hand out write access to = the=20 >> wiki. The benchmark page gives contributor-access. If someone wants wr= ite=20 >> access create a FirstnameLastname account and ask here for contributor= -access. >>>>> >>>>> Don't worry if you think your english is not good enough, even some= one- >> word notes can help (and _my_ english got already corrected by other p= eople on=20 >> the benchmark page). >>>>> >>>>> Bye, >>>>> Alexander. >>>>> >>>>> >>>>> >>>>> >>>> >>>> Nice to see movement ;-) >>>> >>>> But there seems something unclear: >>>> >>>> man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in >>>> /etc/make.conf. >>>> The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. >>>> >>>> What's right and what's wrong now? >>> >>> I can say with certainty that this value belongs in /etc/make.conf >>> (on RELENG_8 and earlier at least). >>> >>> src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, >>> so, this is definitely a make.conf variable. >> >> Eh, normal make variables can go in src.conf as well. They do not hav= e >> to be listed in bsd.own.mk. World builds include /etc/src.conf wherea= s >> every make invocation includes /etc/make.conf via sys.mk. The only re= ason >> to use /etc/src.conf is to have a place to put variables only affect >> make buildworld / buildkernel but do not affect other make invocations= =2E >=20 > I was always under the impression src.conf(5) variables had to be > manually added to bsd.own.mk and similar bits (e.g. > src/tools/build/options/WITH_xxx which is what's used to create the > src.conf(5) man page), but upon your comment and manual investigation o= n > my part, I found you're indeed right. Taken from bsd.own.mk: >=20 > 107 .if !defined(_WITHOUT_SRCCONF) > 108 SRCCONF?=3D /etc/src.conf > 109 .if exists(${SRCCONF}) > 110 .include "${SRCCONF}" > 111 .endif > 112 .endif >=20 > As long as third-party software doesn't depend on MALLOC_PRODUCTION for= > something (I don't know why something would, but who knows; maybe > there's a third-party malloc implementation which might?), then putting= > it in src.conf would be fine (src/lib/libc/stdlib files reference it). >=20 Then the manpage should reflect this. man src.conf does not show up MALLOC_PRODUCTIOn, but man make.conf does. If the latter is right, then it should be worth mentioned that make.conf is incorporating src.conf. Just a suggestion. Regards, Oliver --------------enig1502F529B2C0204E19EA4E4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO9LnRAAoJEOgBcD7A/5N8jWkH/2vnf7syPz2Ody5yUBUIqBk8 6zLbCedWMEVT5Shv+Y9QI1Uc0ku5DieFK4kbFSkp5dpIwPz5FZyxq57bXvcB0lVs xGJJ+I6C9TySn58mGU46CR/qi2PWiX08aBtHerR6WOEKEhbeyw78Axf96KqhJmBG as04C9KmqFFrqRdLlMsttbj5FzJrJCbWXj0wTY1apFBbFYsxjNci7I1IOluIB5oM lcSX2Q1letuEHjf0snoMNW2CqszHxVuEOFEMPSCh09xLzuAMjv6a/4QN3ThqbaOZ MTf5G63H/LvlZRotYwalm+/LB21+8CYaYGlgwPXwLk+JlzRlbu1Ll6q9ElhIGI8= =UR3U -----END PGP SIGNATURE----- --------------enig1502F529B2C0204E19EA4E4D-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 17:55:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373EC1065675; Fri, 23 Dec 2011 17:55:16 +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 291028FC15; Fri, 23 Dec 2011 17:55:08 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBNHt5eo025291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 19:55:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBNHt5Bm086700; Fri, 23 Dec 2011 19:55:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBNHt4qc086699; Fri, 23 Dec 2011 19:55:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Dec 2011 19:55:04 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20111223175504.GK50300@deviant.kiev.zoral.com.ua> References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> <20111223160032.GA18839@freebsd.org> <4EF4B46E.7000405@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gvPIjeLKx76TMoZf" Content-Disposition: inline In-Reply-To: <4EF4B46E.7000405@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , Alexander Best , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:55:16 -0000 --gvPIjeLKx76TMoZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: > On 2011-12-23 17:00, Alexander Best wrote: > ... > >>>Back in the 7.x days, I ran into some code that wasn't easily to debug= =20 > >>>because the compiler optimized things out with -O2 by inlining and > >>otherwise shifting around code, so setting breakpoints in gdb became=20 > >>difficult. So from that point on I've gotten into the habit of doing -O > >>explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. > >> > >>I still leave -O2 in, but what I do is this: > >> > >> make DEBUG_FLAGS=3D"-g -fno-inline" > > > >would making -O2 -fno-inline the default flags introduce any major=20 > >slowdown? >=20 > Not major, but a minor slowdown is quite possible, especially on arches > like x86, where call overhead is relatively high, and code caches are > relatively large. >=20 > Anyway, I'd rather get the thread back to my original patch instead of > messing around with the default flags for release, which have been -O2 > for a long time now. If people want to override those for specific > reasons, they can always set COPTFLAGS or DEBUG_FLAGS manually, like > John shows. >=20 > The only thing my patch makes sure of, is that amd64 does the same thing > as all other arches, e.g.: compile with a low optimization settings for > debug (-O, which is equivalent to -O1), compile with arch-specific high > optimization settings for release (-O2 plus whatever is required for the > arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. --gvPIjeLKx76TMoZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk70wHcACgkQC3+MBN1Mb4inHwCglrnuSVkdnXuSrYzoK7LYwZu2 5oIAoIO8H7mDEKfftcvn6kLxziq3aeKC =moJN -----END PGP SIGNATURE----- --gvPIjeLKx76TMoZf-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 18:58:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 949CE106564A; Fri, 23 Dec 2011 18:58:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 362BD8FC14; Fri, 23 Dec 2011 18:58:18 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so13360494vbb.13 for ; Fri, 23 Dec 2011 10:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jdElovAiB5qt+8UhP+nHX0MFmqUm2lNEXxNyDKmJ8mE=; b=uoOZMo0leVeZb8ciFl3u+vu7OFukIk6BVGsRR4aajbXl85b10AVH6XcP5eP18cdg8B DuFaWS6moOB8S0ODqaDezuRhHH228bXqP6b30DuNkpKww47AeqGCc566s3xjvcC6/vuu hW90Xx6SnV3bv91ElA7gJCAW8ih6IBpCwOhps= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr1978682vdf.117.1324666697608; Fri, 23 Dec 2011 10:58:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 10:58:17 -0800 (PST) In-Reply-To: <4EF45F8D.9030404@mail.zedat.fu-berlin.de> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <4EF444BB.9090400@digsys.bg> <4EF45F8D.9030404@mail.zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 10:58:17 -0800 X-Google-Sender-Auth: ONOZA9F9M6I5ZrXaguZ37Gp62lU Message-ID: From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky , Daniel Kalchev Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:58:18 -0000 Hi, I think this thread has gone far, far off the rails. If you're able to provide some solid debugging or willing to put in the effort to provide said solid debugging, then great. The easier you can make it for someone to fix for you (whether they're a FreeBSD committer or otherwise) the more likely it'll be fixed. There's no-one notionally in charge and paid to look after the scheduler. This is the unfortunate truth. No amount of saying "but but people are paid to do this!" will fix that particular point. The way that 99% of FreeBSD work gets done is when someone (who is a committer or otherwise) gets angry at how something doesn't quite work for them, and they decide to go and do something about it. The only point where a committer needs be involved is when someone wants to push their code into "upstream" (to borrow a Linux-ism) FreeBSD. If you're able to setup KTR and drive it + schedgraph (just like Steve has) and run this on a workload that is _repeatedly_ broken for you, then you're immediately going to have a better chance at getting it fixed. Bonus points if you can run the same benchmark on 4BSD and ULE, reporting KTR + schedgraph traces for both. That is going to be _by far_ the most helpful thing anyone can do in this ridiculously overly-verbose thread. Come on guys/girls/fuzzy creatures, you want to fix the problem? Bitching about it won't help. Unless you're like me and have an interest in Linguistics and end up writing a "flame war to code" generator. Then we'll likely be fine. :) Adrian From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 19:00:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA493106568C; Fri, 23 Dec 2011 19:00:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49A6D8FC14; Fri, 23 Dec 2011 19:00:15 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so13269608vcb.13 for ; Fri, 23 Dec 2011 11:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pVNxq/sda4/ARnsIwaqQicIGf0cNN8ppmegJIqTTMao=; b=E/bJAlK33ESHR9+qif/dBAnNCt5ddqOq8AdiiLDxpdyzv3QwUitiECeL+q3Q7ygh7h ZswWn62WqZV1ob+Z+pqmsnYMONxEmnvii+zAuIPVlo8268F0VOOHHdr6TjjmCM9+3JqK k2NKpyhPL79mDQN+pgwpEU9BzEqPbgNmaGs6g= MIME-Version: 1.0 Received: by 10.220.149.193 with SMTP id u1mr9833148vcv.33.1324666814393; Fri, 23 Dec 2011 11:00:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 11:00:14 -0800 (PST) In-Reply-To: <4EF45F8D.9030404@mail.zedat.fu-berlin.de> References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <4EF444BB.9090400@digsys.bg> <4EF45F8D.9030404@mail.zedat.fu-berlin.de> Date: Fri, 23 Dec 2011 11:00:14 -0800 X-Google-Sender-Auth: 8FaQp-kjPH5nInbeXF--tPIiS50 Message-ID: From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky , Daniel Kalchev Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 19:00:26 -0000 Hi, I think this thread has gone far, far off the rails. If you're able to provide some solid debugging or willing to put in the effort to provide said solid debugging, then great. The easier you can make it for someone to fix for you (whether they're a FreeBSD committer or otherwise) the more likely it'll be fixed. There's no-one notionally in charge and paid to look after the scheduler. This is the unfortunate truth. No amount of saying "but but people are paid to do this!" will fix that particular point. The way that 99% of FreeBSD work gets done is when someone (who is a committer or otherwise) gets angry at how something doesn't quite work for them, and they decide to go and do something about it. The only point where a committer needs be involved is when someone wants to push their code into "upstream" (to borrow a Linux-ism) FreeBSD. If you're able to setup KTR and drive it + schedgraph (just like Steve has) and run this on a workload that is _repeatedly_ broken for you, then you're immediately going to have a better chance at getting it fixed. Bonus points if you can run the same benchmark on 4BSD and ULE, reporting KTR + schedgraph traces for both. That is going to be _by far_ the most helpful thing anyone can do in this ridiculously overly-verbose thread. Come on guys/girls/fuzzy creatr From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 19:04:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A82D1065688; Fri, 23 Dec 2011 19:04:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCD848FC17; Fri, 23 Dec 2011 19:04:30 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8108:6e02:8e8c:934f] (unknown [IPv6:2001:7b8:3a7:0:8108:6e02:8e8c:934f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1F6B35C37; Fri, 23 Dec 2011 20:04:30 +0100 (CET) Message-ID: <4EF4D0C0.7080808@FreeBSD.org> Date: Fri, 23 Dec 2011 20:04:32 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Kostik Belousov References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> <20111223160032.GA18839@freebsd.org> <4EF4B46E.7000405@FreeBSD.org> <20111223175504.GK50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111223175504.GK50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Alexander Best , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 19:04:31 -0000 On 2011-12-23 18:55, Kostik Belousov wrote: > On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: ... >> The only thing my patch makes sure of, is that amd64 does the same thing >> as all other arches, e.g.: compile with a low optimization settings for >> debug (-O, which is equivalent to -O1), compile with arch-specific high >> optimization settings for release (-O2 plus whatever is required for the >> arch, or lower if optimization breaks things). > > Release is built with -g for long time, this is where the symbol files > in /boot/kernel comes from. Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration file, right? I didn't realize that was kept in for a release. But even in that case, amd64 is somehow different from the other arches, which all get compiled with -O instead. If people prefer that to stay as it is, I'll change the diff so only -frename-registers gets removed when clang is used, as clang does not support this flag. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 20:10:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 18BEF1065673; Fri, 23 Dec 2011 20:10:49 +0000 (UTC) Date: Fri, 23 Dec 2011 20:10:49 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111223201049.GA854@freebsd.org> References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> <20111223160032.GA18839@freebsd.org> <4EF4B46E.7000405@FreeBSD.org> <20111223175504.GK50300@deviant.kiev.zoral.com.ua> <4EF4D0C0.7080808@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF4D0C0.7080808@FreeBSD.org> Cc: Kostik Belousov , Garrett Cooper , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 20:10:49 -0000 On Fri Dec 23 11, Dimitry Andric wrote: > On 2011-12-23 18:55, Kostik Belousov wrote: > >On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: > ... > >>The only thing my patch makes sure of, is that amd64 does the same thing > >>as all other arches, e.g.: compile with a low optimization settings for > >>debug (-O, which is equivalent to -O1), compile with arch-specific high > >>optimization settings for release (-O2 plus whatever is required for the > >>arch, or lower if optimization breaks things). > > > >Release is built with -g for long time, this is where the symbol files > >in /boot/kernel comes from. > > Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration > file, right? I didn't realize that was kept in for a release. But even > in that case, amd64 is somehow different from the other arches, which > all get compiled with -O instead. > > If people prefer that to stay as it is, I'll change the diff so only > -frename-registers gets removed when clang is used, as clang does not > support this flag. i think you should go ahead with the changes: 1) get amd64 in line with the other archs when debugging was requested (turning the default optimisation from -O2 to -O) 2) only specify -frename-registers on amd64, when gcc is the requested compiler i'd say: commit it. :) ...sorry we got carried away, but optimisation flags tend to trigger a lot of discussion. ;) cheers. alex From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 20:12:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9783106564A; Fri, 23 Dec 2011 20:12:15 +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 4FB4F8FC19; Fri, 23 Dec 2011 20:12:14 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBNKC09K045578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 22:12:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBNKC0Dr087126; Fri, 23 Dec 2011 22:12:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBNKC03a087125; Fri, 23 Dec 2011 22:12:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Dec 2011 22:12:00 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20111223201200.GM50300@deviant.kiev.zoral.com.ua> References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> <20111223160032.GA18839@freebsd.org> <4EF4B46E.7000405@FreeBSD.org> <20111223175504.GK50300@deviant.kiev.zoral.com.ua> <4EF4D0C0.7080808@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rYuqshf/sHk+ZWuy" Content-Disposition: inline In-Reply-To: <4EF4D0C0.7080808@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , Alexander Best , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 20:12:15 -0000 --rYuqshf/sHk+ZWuy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2011 at 08:04:32PM +0100, Dimitry Andric wrote: > On 2011-12-23 18:55, Kostik Belousov wrote: > >On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: > ... > >>The only thing my patch makes sure of, is that amd64 does the same thing > >>as all other arches, e.g.: compile with a low optimization settings for > >>debug (-O, which is equivalent to -O1), compile with arch-specific high > >>optimization settings for release (-O2 plus whatever is required for the > >>arch, or lower if optimization breaks things). > > > >Release is built with -g for long time, this is where the symbol files > >in /boot/kernel comes from. >=20 > Ah, that is done via 'makeoptions DEBUG=3D-g' in the kernel configuration > file, right? I didn't realize that was kept in for a release. But even > in that case, amd64 is somehow different from the other arches, which > all get compiled with -O instead. Yes. >=20 > If people prefer that to stay as it is, I'll change the diff so only > -frename-registers gets removed when clang is used, as clang does not > support this flag. This question cannot be answered without measurement. I think that even the 'default' benchmark of buildworld over -O and -O2 kernels can be useful to continue the discussion. --rYuqshf/sHk+ZWuy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk704JAACgkQC3+MBN1Mb4i1FACdFWsC90mwoU4853B3oUXiGawD 3OUAoMGV6l+dac9wE5R4DulcLAw4Zkmd =vm4m -----END PGP SIGNATURE----- --rYuqshf/sHk+ZWuy-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 20:23:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1479C1065676; Fri, 23 Dec 2011 20:23:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFA358FC16; Fri, 23 Dec 2011 20:23:28 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so8150718obb.13 for ; Fri, 23 Dec 2011 12:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Kf/ZXJWnVr9F2oe08cVEYJTbEa7jcwuO3NRfwYEot8k=; b=azgNLI9ss9WT4CGGhkjBlK9tCnMWtPX+DRCmM8/Mqf2K5P/+uUbIEKezatN0+uXQWR E8GXejMx6+PZQEsaSIG8Zeu5eyE580Xj82S3QRt0qCKV9dEsNIdnernQXeK0xMGuX94A Kem+wf6YwphwY0BfYl69DXcfkc2mjGv1PAOos= MIME-Version: 1.0 Received: by 10.182.225.66 with SMTP id ri2mr13927025obc.26.1324671808126; Fri, 23 Dec 2011 12:23:28 -0800 (PST) Received: by 10.182.62.227 with HTTP; Fri, 23 Dec 2011 12:23:27 -0800 (PST) In-Reply-To: <4EF45A1B.1050505@unsane.co.uk> References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> <9706CBFC-9A69-4365-8883-FF45BDFDC108@gmail.com> <4EF45A1B.1050505@unsane.co.uk> Date: Fri, 23 Dec 2011 12:23:27 -0800 Message-ID: From: Garrett Cooper To: Vincent Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" , "igor@hybrid-lab.co.uk" , Alexander Leidinger , "freebsd-performance@freebsd.org" , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 20:23:29 -0000 On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman wrote= : > On 23/12/2011 02:56, Garrett Cooper wrote: >> On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick = wrote: >> >>> On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: >>>> On 12/21/11 19:41, Alexander Leidinger wrote: >>>>> Hi, >>>>> >>>>> while the discussion continued here, some work started at some other = place. Now... in case someone here is willing to help instead of talking, f= eel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look w= hat can be improved. The page is far from perfect and needs some additional= people which are willing to improve it. >>>>> >>>>> This is only part of the problem. A tuning page in the wiki - which c= ould be referenced from the benchmark page - would be great too. Any volunt= eers? A first step would be to take he tuning-man-page and wikify it. Other= tuning sources are welcome too. >>>>> >>>>> Every FreeBSD dev with a wiki account can hand out write access to th= e wiki. The benchmark page gives contributor-access. If someone wants write= access create a FirstnameLastname account and ask here for contributor-acc= ess. >>>>> >>>>> Don't worry if you think your english is not good enough, even some o= ne-word notes can help (and _my_ english got already corrected by other peo= ple on the benchmark page). >>>>> >>>>> Bye, >>>>> Alexander. >>>>> >>>>> >>>>> >>>>> >>>> Nice to see movement ;-) >>>> >>>> But there seems something unclear: >>>> >>>> man make.conf(5) says, that =A0MALLOC_PRODUCTION is a knob set in >>>> /etc/make.conf. >>>> The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. >>>> >>>> What's right and what's wrong now? >>> I can say with certainty that this value belongs in /etc/make.conf >>> (on RELENG_8 and earlier at least). >>> >>> src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, >>> so, this is definitely a make.conf variable. >> Take the advice in tuning(7) with a grain of salt because a number of su= ggestions are really outdated. I know because I filed a PR last night after= I saw how out of synch some of the defaults it claimed were with reality o= n 9.x+. And I know other suggestions in the manpage are dated as well ;/. > There is a wiki page http://wiki.freebsd.org/SystemTuning which is > currently more or less tuning(7) with some annotations, the idea being > to sort out whats outdated/invalid with an aim of rewriting tuning(7) to > be more accurate and useful. I'll grab any info in your pr thats not up > there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 21:01:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2D1106564A for ; Fri, 23 Dec 2011 21:01:39 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6E88FC14 for ; Fri, 23 Dec 2011 21:01:38 +0000 (UTC) Received: by lahl5 with SMTP id l5so5424578lah.13 for ; Fri, 23 Dec 2011 13:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MOHizj4v/kmrpOACCeUCZah2edksTPybinykcDLYkdY=; b=i6hVw/jym923mX78usAuzETnwWxz8Oa+m5YsxebOxeELRLCjPIyO+U8nd/sc+fHPOY 1SBvkRQ6Zipn40hL3DM+mS8VSB/ou0NVRwDFKeSXHH5ciob01absnKp4BsTYTDMZ6cEZ knK4anaCqhjYWqUAZE7yFGcrBNdEqgNkkh9yQ= Received: by 10.152.128.196 with SMTP id nq4mr13843383lab.35.1324674097093; Fri, 23 Dec 2011 13:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Fri, 23 Dec 2011 13:01:06 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Fri, 23 Dec 2011 16:01:06 -0500 Message-ID: To: Erik Cederstrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: GCC debug flags cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 21:01:39 -0000 On Thu, Dec 22, 2011 at 6:52 AM, Erik Cederstrand wro= te: > Hi, > > I've created a patch that cleans up FreeBSD Makefiles that unconditionall= y set the -g flag for GCC. The motivation for this is that it should be pos= sible to add or remove this flag globally via e.g. CFLAGS (it's part of my = quest to produce deterministic builds). > > I'm not very familiar with GCC or the build infrastructure, so I'd be gra= teful if someone would review it and possibly commit. > > http://dev.affect-it.dk/gcc_debug_flags.diff Generally include your patches inline, it makes reviewing them easier. Index: sys/amd64/conf/GENERIC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/amd64/conf/GENERIC (revision 228312) +++ sys/amd64/conf/GENERIC (working copy) @@ -21,7 +21,7 @@ ... -makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols ... This is intentionally left in the config files. This is where the .symbols file comes from in /boot/kernel/. --=20 Eitan Adler From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 22:05:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0624106564A for ; Fri, 23 Dec 2011 22:05:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2878FC14 for ; Fri, 23 Dec 2011 22:05:51 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so13399643vcb.13 for ; Fri, 23 Dec 2011 14:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=5kbRfic3YPik8+lRwL6NAhcKMawSN6H6j7gdZq3XRvg=; b=IqHUQBaIA/6p1Fy4SPlA9yFFBZalyg1GvqS52Q2YNF5SraF28SfPCnumAszWYRWRpJ etGzPdrf4yqN4uS0UhBxBLJ00/QBA7U/RLkrDY23bTx8fzpIrTfgGcIzTUcoEm9LEwG+ 5fyFIuJ5o2FWTmTWdoypH/W0FGj411NAJNpXk= MIME-Version: 1.0 Received: by 10.220.149.193 with SMTP id u1mr10075091vcv.33.1324677950618; Fri, 23 Dec 2011 14:05:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 14:05:50 -0800 (PST) Date: Fri, 23 Dec 2011 14:05:50 -0800 X-Google-Sender-Auth: cYRyppF_HtoxpmOLnGLGtV5bZ4s Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: [patch] allow local-tools to include local directories X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 22:05:51 -0000 Hi, This patch allows for user-defined extra local tools directories, a la what LOCAL_DIRS does for adding local build directories to the source. This is needed for cross-compiling as some local tools may need to be first built. I've used this successfully to cross-compile my busybox stuff. Thanks, Adrian -- [adrian@pcbsd-macvm] ~/work/freebsd/head/src> svn diff Makefile.inc1 Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 228757) +++ Makefile.inc1 (working copy) @@ -15,6 +15,8 @@ # -DNO_WWWUPDATE do not update www in ${MAKE} update # -DNO_CTF do not run the DTrace CTF conversion tools on built objects # LOCAL_DIRS="list of dirs" to add additional dirs to the SUBDIR list +# LOCAL_TOOL_DIRS="list of dirs" to add additional dirs to the build-tools +# list # TARGET="machine" to crossbuild world for a different machine type # TARGET_ARCH= may be required when a TARGET supports multiple endians @@ -104,6 +106,8 @@ CLEANDIR= cleandir .endif +LOCAL_TOOL_DIRS?= '' + CVS?= cvs CVSFLAGS?= -A -P -d -I! SVN?= svn @@ -1102,6 +1106,7 @@ bin/csh \ bin/sh \ ${_rescue} \ + ${LOCAL_TOOL_DIRS} \ lib/ncurses/ncurses \ lib/ncurses/ncursesw \ ${_share} \ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 23:22:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 238851065688; Fri, 23 Dec 2011 23:22:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D6AC08FC23; Fri, 23 Dec 2011 23:22:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBNNMFv1017478; Fri, 23 Dec 2011 18:22:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBNNMFr7017470; Fri, 23 Dec 2011 23:22:15 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 23 Dec 2011 23:22:15 GMT Message-Id: <201112232322.pBNNMFr7017470@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:22:17 -0000 TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-23 19:06:15 - building world TB --- 2011-12-23 19:06:15 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:06:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:06:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:06:15 - SRCCONF=/dev/null TB --- 2011-12-23 19:06:15 - TARGET=i386 TB --- 2011-12-23 19:06:15 - TARGET_ARCH=i386 TB --- 2011-12-23 19:06:15 - TZ=UTC TB --- 2011-12-23 19:06:15 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:06:15 - cd /src TB --- 2011-12-23 19:06:15 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 23 19:06:16 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Dec 23 21:16:07 UTC 2011 TB --- 2011-12-23 21:16:07 - generating LINT kernel config TB --- 2011-12-23 21:16:07 - cd /src/sys/i386/conf TB --- 2011-12-23 21:16:07 - /usr/bin/make -B LINT TB --- 2011-12-23 21:16:07 - cd /src/sys/i386/conf TB --- 2011-12-23 21:16:07 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:16:07 - building LINT kernel TB --- 2011-12-23 21:16:07 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:16:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:16:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:16:07 - SRCCONF=/dev/null TB --- 2011-12-23 21:16:07 - TARGET=i386 TB --- 2011-12-23 21:16:07 - TARGET_ARCH=i386 TB --- 2011-12-23 21:16:07 - TZ=UTC TB --- 2011-12-23 21:16:07 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:16:07 - cd /src TB --- 2011-12-23 21:16:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 23 21:16:07 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Dec 23 21:48:06 UTC 2011 TB --- 2011-12-23 21:48:06 - cd /src/sys/i386/conf TB --- 2011-12-23 21:48:06 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 21:48:06 - building LINT-NOINET kernel TB --- 2011-12-23 21:48:06 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:48:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:48:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:48:06 - SRCCONF=/dev/null TB --- 2011-12-23 21:48:06 - TARGET=i386 TB --- 2011-12-23 21:48:06 - TARGET_ARCH=i386 TB --- 2011-12-23 21:48:06 - TZ=UTC TB --- 2011-12-23 21:48:06 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:48:06 - cd /src TB --- 2011-12-23 21:48:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Dec 23 21:48:06 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Dec 23 22:18:26 UTC 2011 TB --- 2011-12-23 22:18:26 - cd /src/sys/i386/conf TB --- 2011-12-23 22:18:26 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:18:26 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:18:26 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:18:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:18:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:18:26 - SRCCONF=/dev/null TB --- 2011-12-23 22:18:26 - TARGET=i386 TB --- 2011-12-23 22:18:26 - TARGET_ARCH=i386 TB --- 2011-12-23 22:18:26 - TZ=UTC TB --- 2011-12-23 22:18:26 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:18:26 - cd /src TB --- 2011-12-23 22:18:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Dec 23 22:18:27 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Fri Dec 23 22:48:53 UTC 2011 TB --- 2011-12-23 22:48:53 - cd /src/sys/i386/conf TB --- 2011-12-23 22:48:53 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 22:48:53 - building LINT-NOIP kernel TB --- 2011-12-23 22:48:53 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:48:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:48:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:48:53 - SRCCONF=/dev/null TB --- 2011-12-23 22:48:53 - TARGET=i386 TB --- 2011-12-23 22:48:53 - TARGET_ARCH=i386 TB --- 2011-12-23 22:48:53 - TZ=UTC TB --- 2011-12-23 22:48:53 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:48:53 - cd /src TB --- 2011-12-23 22:48:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Dec 23 22:48:53 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Fri Dec 23 23:16:39 UTC 2011 TB --- 2011-12-23 23:16:39 - cd /src/sys/i386/conf TB --- 2011-12-23 23:16:39 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-12-23 23:16:39 - building LINT-VIMAGE kernel TB --- 2011-12-23 23:16:39 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 23:16:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 23:16:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 23:16:39 - SRCCONF=/dev/null TB --- 2011-12-23 23:16:39 - TARGET=i386 TB --- 2011-12-23 23:16:39 - TARGET_ARCH=i386 TB --- 2011-12-23 23:16:39 - TZ=UTC TB --- 2011-12-23 23:16:39 - __MAKE_CONF=/dev/null TB --- 2011-12-23 23:16:39 - cd /src TB --- 2011-12-23 23:16:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Dec 23 23:16:39 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/pf cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib/pf /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undeclared (first use in this function) /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identifier is reported only once /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-23 23:22:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-23 23:22:15 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2011-12-23 23:22:15 - 12161.64 user 2132.73 system 15734.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 23:39:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FD2106566B; Fri, 23 Dec 2011 23:39:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC8E8FC16; Fri, 23 Dec 2011 23:39:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBNNd1ov043103; Fri, 23 Dec 2011 18:39:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBNNd1m4043090; Fri, 23 Dec 2011 23:39:01 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 23 Dec 2011 23:39:01 GMT Message-Id: <201112232339.pBNNd1m4043090@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:39:03 -0000 TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-23 19:01:13 - building world TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null TB --- 2011-12-23 19:01:13 - TARGET=amd64 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64 TB --- 2011-12-23 19:01:13 - TZ=UTC TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:01:13 - cd /src TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 23 19:01:14 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Dec 23 21:40:55 UTC 2011 TB --- 2011-12-23 21:40:55 - generating LINT kernel config TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:40:55 - building LINT kernel TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null TB --- 2011-12-23 21:40:55 - TARGET=amd64 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64 TB --- 2011-12-23 21:40:55 - TZ=UTC TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:40:55 - cd /src TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null TB --- 2011-12-23 22:10:56 - TARGET=amd64 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:10:56 - TZ=UTC TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:10:56 - cd /src TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null TB --- 2011-12-23 22:39:01 - TARGET=amd64 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:39:01 - TZ=UTC TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:39:01 - cd /src TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 23:08:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 23:08:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 23:08:33 - SRCCONF=/dev/null TB --- 2011-12-23 23:08:33 - TARGET=amd64 TB --- 2011-12-23 23:08:33 - TARGET_ARCH=amd64 TB --- 2011-12-23 23:08:33 - TZ=UTC TB --- 2011-12-23 23:08:33 - __MAKE_CONF=/dev/null TB --- 2011-12-23 23:08:33 - cd /src TB --- 2011-12-23 23:08:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Dec 23 23:08:33 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Fri Dec 23 23:34:21 UTC 2011 TB --- 2011-12-23 23:34:21 - cd /src/sys/amd64/conf TB --- 2011-12-23 23:34:21 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-12-23 23:34:21 - building LINT-VIMAGE kernel TB --- 2011-12-23 23:34:21 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 23:34:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 23:34:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 23:34:21 - SRCCONF=/dev/null TB --- 2011-12-23 23:34:21 - TARGET=amd64 TB --- 2011-12-23 23:34:21 - TARGET_ARCH=amd64 TB --- 2011-12-23 23:34:21 - TZ=UTC TB --- 2011-12-23 23:34:21 - __MAKE_CONF=/dev/null TB --- 2011-12-23 23:34:21 - cd /src TB --- 2011-12-23 23:34:21 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Dec 23 23:34:21 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/pf cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib/pf /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undeclared (first use in this function) /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identifier is reported only once /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-23 23:39:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-23 23:39:01 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2011-12-23 23:39:01 - 13177.84 user 2430.62 system 16740.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 23:56:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1368E1065673; Fri, 23 Dec 2011 23:56:42 +0000 (UTC) Date: Fri, 23 Dec 2011 23:56:42 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20111223235642.GA37495@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-arch@freebsd.org Subject: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:56:42 -0000 hi there, is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: 1654496 bytes with the flag set vs. 1654952 bytes with the flag unset the gcc(1) man page states the following: " This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. " the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:25:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9D11065739; Sat, 24 Dec 2011 00:25:44 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC118FC13; Sat, 24 Dec 2011 00:25:44 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so8308834obb.13 for ; Fri, 23 Dec 2011 16:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ajD2jJboOZgfG5qPyHRIx+9q6wopOg6iuWhRgI26Uvs=; b=qBl6GFaiDqW0YIQxNOWqP0TNPh4AdxjPdOVWTyWDkiP2OBdASfRozjCQscoDB4m+aD Ovp48INTno1Y0aI7sDvfXp80FoXtgfd8l4ODrnUt1rODzyN9+C9fji/HTOPbVfKmrCR8 JjsOphRqvhfNkBbliusSJo2b9YUxg9J/xP0zI= MIME-Version: 1.0 Received: by 10.182.160.1 with SMTP id xg1mr14494565obb.30.1324684942033; Fri, 23 Dec 2011 16:02:22 -0800 (PST) Received: by 10.182.171.67 with HTTP; Fri, 23 Dec 2011 16:02:22 -0800 (PST) In-Reply-To: <201112232339.pBNNd1m4043090@freebsd-current.sentex.ca> References: <201112232339.pBNNd1m4043090@freebsd-current.sentex.ca> Date: Sat, 24 Dec 2011 03:02:22 +0300 Message-ID: From: Sergey Kandaurov To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 00:25:45 -0000 On 24 December 2011 03:39, FreeBSD Tinderbox wrote: > TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sen= tex.ca > TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2011-12-23 19:00:00 - cleaning the object tree > TB --- 2011-12-23 19:00:50 - cvsupping the source tree > TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2011-12-23 19:01:13 - building world > TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 19:01:13 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 19:01:13 - SRCCONF=3D/dev/null > TB --- 2011-12-23 19:01:13 - TARGET=3Damd64 > TB --- 2011-12-23 19:01:13 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 19:01:13 - TZ=3DUTC > TB --- 2011-12-23 19:01:13 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 19:01:13 - cd /src > TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld >>>> World build started on Fri Dec 23 19:01:14 UTC 2011 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Fri Dec 23 21:40:55 UTC 2011 > TB --- 2011-12-23 21:40:55 - generating LINT kernel config > TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf > TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT > TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf > TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT > TB --- 2011-12-23 21:40:55 - building LINT kernel > TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 21:40:55 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 21:40:55 - SRCCONF=3D/dev/null > TB --- 2011-12-23 21:40:55 - TARGET=3Damd64 > TB --- 2011-12-23 21:40:55 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 21:40:55 - TZ=3DUTC > TB --- 2011-12-23 21:40:55 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 21:40:55 - cd /src > TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 > TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf > TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET > TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel > TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 22:10:56 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 22:10:56 - SRCCONF=3D/dev/null > TB --- 2011-12-23 22:10:56 - TARGET=3Damd64 > TB --- 2011-12-23 22:10:56 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 22:10:56 - TZ=3DUTC > TB --- 2011-12-23 22:10:56 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 22:10:56 - cd /src > TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=3DLINT= -NOINET >>>> Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011 > TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf > TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 > TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel > TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 22:39:01 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 22:39:01 - SRCCONF=3D/dev/null > TB --- 2011-12-23 22:39:01 - TARGET=3Damd64 > TB --- 2011-12-23 22:39:01 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 22:39:01 - TZ=3DUTC > TB --- 2011-12-23 22:39:01 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 22:39:01 - cd /src > TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=3DLINT= -NOINET6 >>>> Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 201= 1 > TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf > TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP > TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel > TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 23:08:33 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 23:08:33 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 23:08:33 - SRCCONF=3D/dev/null > TB --- 2011-12-23 23:08:33 - TARGET=3Damd64 > TB --- 2011-12-23 23:08:33 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 23:08:33 - TZ=3DUTC > TB --- 2011-12-23 23:08:33 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 23:08:33 - cd /src > TB --- 2011-12-23 23:08:33 - /usr/bin/make -B buildkernel KERNCONF=3DLINT= -NOIP >>>> Kernel build for LINT-NOIP started on Fri Dec 23 23:08:33 UTC 2011 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT-NOIP completed on Fri Dec 23 23:34:21 UTC 2011 > TB --- 2011-12-23 23:34:21 - cd /src/sys/amd64/conf > TB --- 2011-12-23 23:34:21 - /usr/sbin/config -m LINT-VIMAGE > TB --- 2011-12-23 23:34:21 - building LINT-VIMAGE kernel > TB --- 2011-12-23 23:34:21 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-12-23 23:34:21 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-12-23 23:34:21 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-23 23:34:21 - SRCCONF=3D/dev/null > TB --- 2011-12-23 23:34:21 - TARGET=3Damd64 > TB --- 2011-12-23 23:34:21 - TARGET_ARCH=3Damd64 > TB --- 2011-12-23 23:34:21 - TZ=3DUTC > TB --- 2011-12-23 23:34:21 - __MAKE_CONF=3D/dev/null > TB --- 2011-12-23 23:34:21 - cd /src > TB --- 2011-12-23 23:34:21 - /usr/bin/make -B buildkernel KERNCONF=3DLINT= -VIMAGE >>>> Kernel build for LINT-VIMAGE started on Fri Dec 23 23:34:21 UTC 2011 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 =A0= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-p= rototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign= -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option = =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KE= RNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000= --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DGP= ROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-p= ointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-f= no-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg = -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/s= rc/sys/contrib/ngatm > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 =A0= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-p= rototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign= -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option = =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KE= RNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000= --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DGP= ROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-p= ointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-f= no-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg = -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src/= sys/contrib/ngatm > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 =A0= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-p= rototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign= -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option = =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KE= RNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000= --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DGP= ROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-p= ointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-f= no-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg = -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/p= f > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 =A0= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-p= rototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign= -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option = =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KE= RNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000= --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DGP= ROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-p= ointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-f= no-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg = -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib/= pf > /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': > /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undecla= red (first use in this function) > /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identif= ier is reported only once > /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it app= ears in.) > *** Error code 1 > > Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2011-12-23 23:39:01 - WARNING: /usr/bin/make returned exit code = =A01 > TB --- 2011-12-23 23:39:01 - ERROR: failed to build LINT-VIMAGE kernel > TB --- 2011-12-23 23:39:01 - 13177.84 user 2430.62 system 16740.73 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full This shall fix the build. Index: sys/contrib/pf/net/if_pfsync.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/pf/net/if_pfsync.c (revision 228853) +++ sys/contrib/pf/net/if_pfsync.c (working copy) @@ -1613,7 +1613,7 @@ case PFSYNC_BUS_START: #ifdef __FreeBSD__ callout_reset(&sc->sc_bulkfail_tmo, 4 * hz + - pf_pool_limits[PF_LIMIT_STATES].limit / + V_pf_pool_limits[PF_LIMIT_STATES].limit / ((sc->sc_sync_if->if_mtu - PFSYNC_MINPKT) / sizeof(struct pfsync_state)), pfsync_bulk_fail, V_pfsyncif); --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:26:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616761065672; Sat, 24 Dec 2011 00:26:55 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7C68FC16; Sat, 24 Dec 2011 00:26:54 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so8309338obb.13 for ; Fri, 23 Dec 2011 16:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=u+BJoUysvhJnL4uL5Ll0P9ONZaa2IljZ09Rze7DqbvU=; b=ushDRumQgtQOzp6Lg5l0gqWpG1LoZR7EE1J1ESgQITHgM0ecEVckT0+ffD0mSB72Ss 2nWdH4QBBcOjrPBTJZYT4J2AbyRzbM0mGn8bh4whxslHkXK9RU4dJFXMllV0Itq1m3Cr W0cs6L1cFY8yWskXwFPQ00XnBfFa7fa2bDmQk= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr6175879obw.10.1324686414616; Fri, 23 Dec 2011 16:26:54 -0800 (PST) Received: by 10.182.171.67 with HTTP; Fri, 23 Dec 2011 16:26:54 -0800 (PST) In-Reply-To: References: <201112232339.pBNNd1m4043090@freebsd-current.sentex.ca> Date: Sat, 24 Dec 2011 03:26:54 +0300 Message-ID: From: Sergey Kandaurov To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 00:26:55 -0000 On 24 December 2011 04:02, Sergey Kandaurov wrote: > On 24 December 2011 03:39, FreeBSD Tinderbox wrot= e: >> TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.se= ntex.ca >> TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 >> TB --- 2011-12-23 19:00:00 - cleaning the object tree >> TB --- 2011-12-23 19:00:50 - cvsupping the source tree >> TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sent= ex.ca /tinderbox/HEAD/amd64/amd64/supfile >> TB --- 2011-12-23 19:01:13 - building world >> TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 19:01:13 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 19:01:13 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 19:01:13 - TARGET=3Damd64 >> TB --- 2011-12-23 19:01:13 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 19:01:13 - TZ=3DUTC >> TB --- 2011-12-23 19:01:13 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 19:01:13 - cd /src >> TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld >>>>> World build started on Fri Dec 23 19:01:14 UTC 2011 >>>>> Rebuilding the temporary build tree >>>>> stage 1.1: legacy release compatibility shims >>>>> stage 1.2: bootstrap tools >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3: cross tools >>>>> stage 4.1: building includes >>>>> stage 4.2: building libraries >>>>> stage 4.3: make dependencies >>>>> stage 4.4: building everything >>>>> stage 5.1: building 32 bit shim libraries >>>>> World build completed on Fri Dec 23 21:40:55 UTC 2011 >> TB --- 2011-12-23 21:40:55 - generating LINT kernel config >> TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT >> TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT >> TB --- 2011-12-23 21:40:55 - building LINT kernel >> TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 21:40:55 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 21:40:55 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 21:40:55 - TARGET=3Damd64 >> TB --- 2011-12-23 21:40:55 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 21:40:55 - TZ=3DUTC >> TB --- 2011-12-23 21:40:55 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 21:40:55 - cd /src >> TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=3DLIN= T >>>>> Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >>>>> Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 >> TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET >> TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel >> TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 22:10:56 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 22:10:56 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 22:10:56 - TARGET=3Damd64 >> TB --- 2011-12-23 22:10:56 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 22:10:56 - TZ=3DUTC >> TB --- 2011-12-23 22:10:56 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 22:10:56 - cd /src >> TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=3DLIN= T-NOINET >>>>> Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >>>>> Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 201= 1 >> TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 >> TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel >> TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 22:39:01 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 22:39:01 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 22:39:01 - TARGET=3Damd64 >> TB --- 2011-12-23 22:39:01 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 22:39:01 - TZ=3DUTC >> TB --- 2011-12-23 22:39:01 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 22:39:01 - cd /src >> TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=3DLIN= T-NOINET6 >>>>> Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >>>>> Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 20= 11 >> TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP >> TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel >> TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 23:08:33 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 23:08:33 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 23:08:33 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 23:08:33 - TARGET=3Damd64 >> TB --- 2011-12-23 23:08:33 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 23:08:33 - TZ=3DUTC >> TB --- 2011-12-23 23:08:33 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 23:08:33 - cd /src >> TB --- 2011-12-23 23:08:33 - /usr/bin/make -B buildkernel KERNCONF=3DLIN= T-NOIP >>>>> Kernel build for LINT-NOIP started on Fri Dec 23 23:08:33 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >>>>> Kernel build for LINT-NOIP completed on Fri Dec 23 23:34:21 UTC 2011 >> TB --- 2011-12-23 23:34:21 - cd /src/sys/amd64/conf >> TB --- 2011-12-23 23:34:21 - /usr/sbin/config -m LINT-VIMAGE >> TB --- 2011-12-23 23:34:21 - building LINT-VIMAGE kernel >> TB --- 2011-12-23 23:34:21 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-12-23 23:34:21 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-12-23 23:34:21 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-12-23 23:34:21 - SRCCONF=3D/dev/null >> TB --- 2011-12-23 23:34:21 - TARGET=3Damd64 >> TB --- 2011-12-23 23:34:21 - TARGET_ARCH=3Damd64 >> TB --- 2011-12-23 23:34:21 - TZ=3DUTC >> TB --- 2011-12-23 23:34:21 - __MAKE_CONF=3D/dev/null >> TB --- 2011-12-23 23:34:21 - cd /src >> TB --- 2011-12-23 23:34:21 - /usr/bin/make -B buildkernel KERNCONF=3DLIN= T-VIMAGE >>>>> Kernel build for LINT-VIMAGE started on Fri Dec 23 23:34:21 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >> [...] >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option= =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_K= ERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D800= 0 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DG= PROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-= pointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg= -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/= src/sys/contrib/ngatm >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option= =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_K= ERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D800= 0 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DG= PROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-= pointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg= -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src= /sys/contrib/ngatm >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option= =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_K= ERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D800= 0 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DG= PROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-= pointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg= -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/= pf >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option= =A0 -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_K= ERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D800= 0 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -DG= PROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-= pointer -mno-sse -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float =A0-= fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg= -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib= /pf >> /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': >> /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undecl= ared (first use in this function) >> /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identi= fier is reported only once >> /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it ap= pears in.) >> *** Error code 1 >> >> Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. >> *** Error code 1 >> >> Stop in /src. >> *** Error code 1 >> >> Stop in /src. >> TB --- 2011-12-23 23:39:01 - WARNING: /usr/bin/make returned exit code = =A01 >> TB --- 2011-12-23 23:39:01 - ERROR: failed to build LINT-VIMAGE kernel >> TB --- 2011-12-23 23:39:01 - 13177.84 user 2430.62 system 16740.73 real >> >> >> http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full > > This shall fix the build. > > Index: sys/contrib/pf/net/if_pfsync.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/contrib/pf/net/if_pfsync.c =A0 =A0 =A0(revision 228853) > +++ sys/contrib/pf/net/if_pfsync.c =A0 =A0 =A0(working copy) > @@ -1613,7 +1613,7 @@ > =A0 =A0 =A0 =A0case PFSYNC_BUS_START: > =A0#ifdef __FreeBSD__ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0callout_reset(&sc->sc_bulkfail_tmo, 4 * hz= + > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pf_pool_limits[PF_LIMIT_STATES].lim= it / > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V_pf_pool_limits[PF_LIMIT_STATES].l= imit / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((sc->sc_sync_if->if_mtu - PFSYNC_= MINPKT) / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct pfsync_state)), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pfsync_bulk_fail, V_pfsyncif); > Committed in r228855. Merry Christmas :) --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:42:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 527751065701; Sat, 24 Dec 2011 00:42:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB65B8FC14; Sat, 24 Dec 2011 00:42:07 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so13484284vcb.13 for ; Fri, 23 Dec 2011 16:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/T0DQIOb3/vFZwbHb4aOFgoDkLgT/Y3X4Zujh79YIX8=; b=aZZ5JMvh6hOQy4jIaRMBUxAiMVKDvZuqZNgJ44syGHSuk4FLhoxL4jRkKuq5R1Liff oEjCWNQEenov441kDDan6aVBHEx00nJ/gRX2HI13mShcIspVw7MfxQPVMmTy+P/5fuRP 7t2p9PV59VqdnyUpo8QlmtdBW2yZ60PCcPzko= MIME-Version: 1.0 Received: by 10.220.149.193 with SMTP id u1mr10261983vcv.33.1324687326815; Fri, 23 Dec 2011 16:42:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 16:42:06 -0800 (PST) Date: Fri, 23 Dec 2011 16:42:06 -0800 X-Google-Sender-Auth: 4sxQOnSIjjKDM-JjmY2PSRt8OBs Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: [patch] bsdbox changes for base system: add LOCAL_ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 00:42:08 -0000 Hi, Here are two patches which implement some useful features for crunch building: * Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the 'build-tools' target. This is needed for cross-building bsdbox (and any external directory added by LOCAL_DIRS) * If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate the crunch-gen hard links. I may end up changing the latter to CRUNCH_GENERATE_LINKS and default that to yes, then allow the bsdbox build system to change that to 'no', but the intent is the same. I'd like to commit this tomorrow if possible, so I can then follow it up with the bsdbox import. Thanks, Adrian [adrian@pcbsd-macvm] ~/work/freebsd/head/src> svn diff Makefile.inc1 share/mk Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 228757) +++ Makefile.inc1 (working copy) @@ -15,6 +15,8 @@ # -DNO_WWWUPDATE do not update www in ${MAKE} update # -DNO_CTF do not run the DTrace CTF conversion tools on built objects # LOCAL_DIRS="list of dirs" to add additional dirs to the SUBDIR list +# LOCAL_TOOL_DIRS="list of dirs" to add additional dirs to the build-tools +# list # TARGET="machine" to crossbuild world for a different machine type # TARGET_ARCH= may be required when a TARGET supports multiple endians @@ -104,6 +106,8 @@ CLEANDIR= cleandir .endif +LOCAL_TOOL_DIRS?= '' + CVS?= cvs CVSFLAGS?= -A -P -d -I! SVN?= svn @@ -1102,6 +1106,7 @@ bin/csh \ bin/sh \ ${_rescue} \ + ${LOCAL_TOOL_DIRS} \ lib/ncurses/ncurses \ lib/ncurses/ncursesw \ ${_share} \ Index: share/mk/bsd.crunchgen.mk =================================================================== --- share/mk/bsd.crunchgen.mk (revision 228757) +++ share/mk/bsd.crunchgen.mk (working copy) @@ -22,6 +22,8 @@ # Specific links can be suppressed by setting # CRUNCH_SUPPRESS_LINK_$(NAME) to 1. # +# If CRUNCH_SUPPRESS_ALL_LINKS is set to yes, no links will be generated. +# # $FreeBSD$ @@ -39,6 +41,7 @@ .else CANONICALOBJDIR:= /usr/obj${.CURDIR} .endif +CRUNCH_SUPPRESS_ALL_LINKS?= no CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h @@ -51,6 +54,7 @@ .else $(OUTPUTS): $(.CURDIR)/../../$(D)/$(P)/Makefile .endif +.if ${CRUNCH_SUPPRESS_ALL_LINKS} != "yes" .ifndef CRUNCH_SUPPRESS_LINK_${P} LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(P) .endif @@ -59,6 +63,7 @@ LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(A) .endif .endfor +.endif .endfor .endfor From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:59:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9901065670; Sat, 24 Dec 2011 00:59:28 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id A85778FC0A; Sat, 24 Dec 2011 00:59:27 +0000 (UTC) Received: from vhoffman-macbooklocal.local ([10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id pBO0xN07088483 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 00:59:24 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4EF523EB.7060905@unsane.co.uk> Date: Sat, 24 Dec 2011 00:59:23 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <4EF3C0CE.5040802@zedat.fu-berlin.de> <20111222235846.GA6071@icarus.home.lan> <9706CBFC-9A69-4365-8883-FF45BDFDC108@gmail.com> <4EF45A1B.1050505@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , "freebsd-current@freebsd.org" , "igor@hybrid-lab.co.uk" , Alexander Leidinger , "freebsd-performance@freebsd.org" , "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 00:59:28 -0000 On 23/12/2011 20:23, Garrett Cooper wrote: > On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman wrote: >> On 23/12/2011 02:56, Garrett Cooper wrote: >> There is a wiki page http://wiki.freebsd.org/SystemTuning which is >> currently more or less tuning(7) with some annotations, the idea being >> to sort out whats outdated/invalid with an aim of rewriting tuning(7) to >> be more accurate and useful. I'll grab any info in your pr thats not up >> there already to keep it updated if thats ok. > Sure. Please take my suggestions (apart from the networking > sysctls) with a grain of salt as I didn't look at the sourcecode for > the filesystem ones (I was going off the top of my head and other > emails I had seen passed around). > I'll update the tuning 'wiki' with mention of the new networking > defaults. If we want to make this manpage 'timeless', should we remove > mention of defaults and go off basic guidelines (if you set this > higher, you'll get better performance in scenario, X.Y.Z, etc)? > Thanks! > -Garrett Good point, for tuning the defaults are probably not so important as they are likely to change at some point (as the current man page will attest) so maybe its less important to document them. Happy Christmas (or holiday of your choice ;) to you all and I hope everyone has a good new year. Vince > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 01:50:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61323106566B for ; Sat, 24 Dec 2011 01:50:17 +0000 (UTC) (envelope-from kabaev@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 1AEBA8FC08 for ; Sat, 24 Dec 2011 01:50:16 +0000 (UTC) Received: by qcse13 with SMTP id e13so8850960qcs.13 for ; Fri, 23 Dec 2011 17:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=O2fqFWUGJi6n6LZYtF1tAoaXoehosj5d2Mi1iHGesF8=; b=bNqiRnGMfUGCS77Ua6lSwBMeu1WJ34CKQTmQZ8R4FWR8zbgnZmZ+Yweb8JwQQilIAV K26ftXpfCboOkKo0BGcm4b1fHaqbchISX3LvisPcEF0m5dZKMNJZJsSyZZCtPeph1CQv RFJVZ7NEhoDEHz9+Bj+tFlzYOQbwBNWjj4EJQ= Received: by 10.229.78.216 with SMTP id m24mr6500602qck.34.1324691415590; Fri, 23 Dec 2011 17:50:15 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id i10sm27717478qac.17.2011.12.23.17.50.13 (version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 17:50:14 -0800 (PST) Date: Fri, 23 Dec 2011 20:50:07 -0500 From: Alexander Kabaev To: Erik Cederstrand Message-ID: <20111223205007.16eb27c5@kan.dyndns.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ztyrywUZZxS271OCdvd7=Qn"; protocol="application/pgp-signature" Cc: FreeBSD Current Subject: Re: GCC debug flags cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 01:50:17 -0000 --Sig_/ztyrywUZZxS271OCdvd7=Qn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 22 Dec 2011 12:52:45 +0100 Erik Cederstrand wrote: > Hi, >=20 > I've created a patch that cleans up FreeBSD Makefiles that > unconditionally set the -g flag for GCC. The motivation for this is > that it should be possible to add or remove this flag globally via > e.g. CFLAGS (it's part of my quest to produce deterministic builds). >=20 > I'm not very familiar with GCC or the build infrastructure, so I'd be > grateful if someone would review it and possibly commit. >=20 > http://dev.affect-it.dk/gcc_debug_flags.diff >=20 > Thanks, > Erik_______________________________________________ gnu/usr.bin/cc/cc_tools/Makefile just builds tools that are used for building gcc itself and are non installed anywhere outside of $OBJDIR. I doubt disabling -g there buys you much, but having it there is also of questionable value. Verdict: could not care less either way. All of the gcc/contrib changes are useless - we are not using any of stock Makefiles. sys/amd64/conf/GENERIC - please understang _why_ it is there before you remove it. When you do, you will probably will drop the idea. -- Alexander Kabaev --Sig_/ztyrywUZZxS271OCdvd7=Qn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFO9S/UQ6z1jMm+XZYRAlx7AKC7vT3F4MUp67Zvnr/n5qEKZMEX5ACgqnNK csnj4zYsHkUWfMshk5qkH7Y= =VVOB -----END PGP SIGNATURE----- --Sig_/ztyrywUZZxS271OCdvd7=Qn-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 06:30:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20AAC106564A; Sat, 24 Dec 2011 06:30:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CB51F8FC08; Sat, 24 Dec 2011 06:30:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBO6UClV028701; Sat, 24 Dec 2011 01:30:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBO6UCCQ028664; Sat, 24 Dec 2011 06:30:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Dec 2011 06:30:12 GMT Message-Id: <201112240630.pBO6UCCQ028664@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 06:30:14 -0000 TB --- 2011-12-24 02:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 02:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-24 02:20:00 - cleaning the object tree TB --- 2011-12-24 02:20:52 - cvsupping the source tree TB --- 2011-12-24 02:20:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-24 02:21:06 - building world TB --- 2011-12-24 02:21:06 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 02:21:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 02:21:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 02:21:06 - SRCCONF=/dev/null TB --- 2011-12-24 02:21:06 - TARGET=i386 TB --- 2011-12-24 02:21:06 - TARGET_ARCH=i386 TB --- 2011-12-24 02:21:06 - TZ=UTC TB --- 2011-12-24 02:21:06 - __MAKE_CONF=/dev/null TB --- 2011-12-24 02:21:06 - cd /src TB --- 2011-12-24 02:21:06 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 24 02:21:06 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 24 04:27:27 UTC 2011 TB --- 2011-12-24 04:27:27 - generating LINT kernel config TB --- 2011-12-24 04:27:27 - cd /src/sys/i386/conf TB --- 2011-12-24 04:27:27 - /usr/bin/make -B LINT TB --- 2011-12-24 04:27:27 - cd /src/sys/i386/conf TB --- 2011-12-24 04:27:27 - /usr/sbin/config -m LINT TB --- 2011-12-24 04:27:27 - building LINT kernel TB --- 2011-12-24 04:27:27 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:27:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:27:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:27:27 - SRCCONF=/dev/null TB --- 2011-12-24 04:27:27 - TARGET=i386 TB --- 2011-12-24 04:27:27 - TARGET_ARCH=i386 TB --- 2011-12-24 04:27:27 - TZ=UTC TB --- 2011-12-24 04:27:27 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:27:27 - cd /src TB --- 2011-12-24 04:27:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 24 04:27:27 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Dec 24 04:58:20 UTC 2011 TB --- 2011-12-24 04:58:20 - cd /src/sys/i386/conf TB --- 2011-12-24 04:58:20 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-24 04:58:20 - building LINT-NOINET kernel TB --- 2011-12-24 04:58:20 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:58:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:58:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:58:20 - SRCCONF=/dev/null TB --- 2011-12-24 04:58:20 - TARGET=i386 TB --- 2011-12-24 04:58:20 - TARGET_ARCH=i386 TB --- 2011-12-24 04:58:20 - TZ=UTC TB --- 2011-12-24 04:58:20 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:58:20 - cd /src TB --- 2011-12-24 04:58:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 24 04:58:20 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Dec 24 05:27:39 UTC 2011 TB --- 2011-12-24 05:27:39 - cd /src/sys/i386/conf TB --- 2011-12-24 05:27:39 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-24 05:27:39 - building LINT-NOINET6 kernel TB --- 2011-12-24 05:27:39 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:27:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:27:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:27:39 - SRCCONF=/dev/null TB --- 2011-12-24 05:27:39 - TARGET=i386 TB --- 2011-12-24 05:27:39 - TARGET_ARCH=i386 TB --- 2011-12-24 05:27:39 - TZ=UTC TB --- 2011-12-24 05:27:39 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:27:39 - cd /src TB --- 2011-12-24 05:27:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Dec 24 05:27:39 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Dec 24 05:57:37 UTC 2011 TB --- 2011-12-24 05:57:37 - cd /src/sys/i386/conf TB --- 2011-12-24 05:57:37 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-24 05:57:37 - building LINT-NOIP kernel TB --- 2011-12-24 05:57:38 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:57:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:57:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:57:38 - SRCCONF=/dev/null TB --- 2011-12-24 05:57:38 - TARGET=i386 TB --- 2011-12-24 05:57:38 - TARGET_ARCH=i386 TB --- 2011-12-24 05:57:38 - TZ=UTC TB --- 2011-12-24 05:57:38 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:57:38 - cd /src TB --- 2011-12-24 05:57:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Dec 24 05:57:38 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Dec 24 06:25:07 UTC 2011 TB --- 2011-12-24 06:25:07 - cd /src/sys/i386/conf TB --- 2011-12-24 06:25:07 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-12-24 06:25:07 - building LINT-VIMAGE kernel TB --- 2011-12-24 06:25:07 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 06:25:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 06:25:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 06:25:07 - SRCCONF=/dev/null TB --- 2011-12-24 06:25:07 - TARGET=i386 TB --- 2011-12-24 06:25:07 - TARGET_ARCH=i386 TB --- 2011-12-24 06:25:07 - TZ=UTC TB --- 2011-12-24 06:25:07 - __MAKE_CONF=/dev/null TB --- 2011-12-24 06:25:07 - cd /src TB --- 2011-12-24 06:25:07 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Dec 24 06:25:07 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src/sys/contrib/ngatm cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/pf cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib/pf /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undeclared (first use in this function) /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identifier is reported only once /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-24 06:30:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-24 06:30:12 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2011-12-24 06:30:12 - 11911.39 user 2107.66 system 15012.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 06:52:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9056F106564A; Sat, 24 Dec 2011 06:52:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 205CB8FC13; Sat, 24 Dec 2011 06:52:52 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so13649587vcb.13 for ; Fri, 23 Dec 2011 22:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=62VFJpXrdVU5weJF6lonc7VFHNOncfUL0dvxMqCZKG0=; b=HMPiZbbqMoVqjeTIzLJR3iOA5LwfveqCCGi9Rl9W/nsB8XnaIrjedjrjujR6xAmbdS 26h+kpPeRzDaTCzFfoJps6/D+8mY72O1OWaIhIbSSecWMFjzit+E/t7QQCR3G2bwrRX+ ICjnbJKmYBqlCIk99vcRDZrlkuMrCN2nEb0d4= MIME-Version: 1.0 Received: by 10.220.149.193 with SMTP id u1mr10717816vcv.33.1324709572425; Fri, 23 Dec 2011 22:52:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 22:52:52 -0800 (PST) In-Reply-To: <20111224160050.T1141@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> Date: Fri, 23 Dec 2011 22:52:52 -0800 X-Google-Sender-Auth: Mc4SE_4-8xBwTCJKGGE0EyfcZv0 Message-ID: From: Adrian Chadd To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 06:52:53 -0000 Well, the whole kernel is bloated at the moment, sorry. I've been trying to build the _bare minimum_ required to bootstrap -HEAD on these embedded boards and I can't get the kernel down below 5 megabytes - ie, one with FFS (with options disabled), MIPS, INET (no INET6), net80211, ath (which admittedly is big, but I need it no matter what, right?) comes in at: -r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 And with INET6, on another board (and this includes MSDOS and the relevant geom modules): -r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO .. honestly, that's what should be addressed. That's honestly a bit ridiculous. 2c, Adrian From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 06:54:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 087C3106566B; Sat, 24 Dec 2011 06:54:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A53A88FC08; Sat, 24 Dec 2011 06:54:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBO6s5Mh097650; Sat, 24 Dec 2011 01:54:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBO6s57e097633; Sat, 24 Dec 2011 06:54:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Dec 2011 06:54:05 GMT Message-Id: <201112240654.pBO6s57e097633@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 06:54:07 -0000 TB --- 2011-12-24 02:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 02:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-24 02:20:00 - cleaning the object tree TB --- 2011-12-24 02:20:54 - cvsupping the source tree TB --- 2011-12-24 02:20:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-24 02:21:08 - building world TB --- 2011-12-24 02:21:08 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 02:21:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 02:21:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 02:21:08 - SRCCONF=/dev/null TB --- 2011-12-24 02:21:08 - TARGET=amd64 TB --- 2011-12-24 02:21:08 - TARGET_ARCH=amd64 TB --- 2011-12-24 02:21:08 - TZ=UTC TB --- 2011-12-24 02:21:08 - __MAKE_CONF=/dev/null TB --- 2011-12-24 02:21:08 - cd /src TB --- 2011-12-24 02:21:08 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 24 02:21:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Dec 24 04:58:32 UTC 2011 TB --- 2011-12-24 04:58:32 - generating LINT kernel config TB --- 2011-12-24 04:58:32 - cd /src/sys/amd64/conf TB --- 2011-12-24 04:58:32 - /usr/bin/make -B LINT TB --- 2011-12-24 04:58:32 - cd /src/sys/amd64/conf TB --- 2011-12-24 04:58:32 - /usr/sbin/config -m LINT TB --- 2011-12-24 04:58:32 - building LINT kernel TB --- 2011-12-24 04:58:32 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:58:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:58:32 - SRCCONF=/dev/null TB --- 2011-12-24 04:58:32 - TARGET=amd64 TB --- 2011-12-24 04:58:32 - TARGET_ARCH=amd64 TB --- 2011-12-24 04:58:32 - TZ=UTC TB --- 2011-12-24 04:58:32 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:58:32 - cd /src TB --- 2011-12-24 04:58:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 24 04:58:32 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Dec 24 05:27:37 UTC 2011 TB --- 2011-12-24 05:27:37 - cd /src/sys/amd64/conf TB --- 2011-12-24 05:27:37 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-24 05:27:37 - building LINT-NOINET kernel TB --- 2011-12-24 05:27:37 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:27:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:27:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:27:37 - SRCCONF=/dev/null TB --- 2011-12-24 05:27:37 - TARGET=amd64 TB --- 2011-12-24 05:27:37 - TARGET_ARCH=amd64 TB --- 2011-12-24 05:27:37 - TZ=UTC TB --- 2011-12-24 05:27:37 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:27:37 - cd /src TB --- 2011-12-24 05:27:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 24 05:27:37 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Dec 24 05:55:16 UTC 2011 TB --- 2011-12-24 05:55:16 - cd /src/sys/amd64/conf TB --- 2011-12-24 05:55:16 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-24 05:55:16 - building LINT-NOINET6 kernel TB --- 2011-12-24 05:55:16 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:55:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:55:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:55:16 - SRCCONF=/dev/null TB --- 2011-12-24 05:55:16 - TARGET=amd64 TB --- 2011-12-24 05:55:16 - TARGET_ARCH=amd64 TB --- 2011-12-24 05:55:16 - TZ=UTC TB --- 2011-12-24 05:55:16 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:55:16 - cd /src TB --- 2011-12-24 05:55:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Dec 24 05:55:16 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Dec 24 06:23:37 UTC 2011 TB --- 2011-12-24 06:23:37 - cd /src/sys/amd64/conf TB --- 2011-12-24 06:23:37 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-24 06:23:37 - building LINT-NOIP kernel TB --- 2011-12-24 06:23:37 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 06:23:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 06:23:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 06:23:37 - SRCCONF=/dev/null TB --- 2011-12-24 06:23:37 - TARGET=amd64 TB --- 2011-12-24 06:23:37 - TARGET_ARCH=amd64 TB --- 2011-12-24 06:23:37 - TZ=UTC TB --- 2011-12-24 06:23:37 - __MAKE_CONF=/dev/null TB --- 2011-12-24 06:23:37 - cd /src TB --- 2011-12-24 06:23:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Dec 24 06:23:37 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Dec 24 06:49:16 UTC 2011 TB --- 2011-12-24 06:49:16 - cd /src/sys/amd64/conf TB --- 2011-12-24 06:49:16 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-12-24 06:49:16 - building LINT-VIMAGE kernel TB --- 2011-12-24 06:49:16 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 06:49:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 06:49:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 06:49:16 - SRCCONF=/dev/null TB --- 2011-12-24 06:49:16 - TARGET=amd64 TB --- 2011-12-24 06:49:16 - TARGET_ARCH=amd64 TB --- 2011-12-24 06:49:16 - TZ=UTC TB --- 2011-12-24 06:49:16 - __MAKE_CONF=/dev/null TB --- 2011-12-24 06:49:16 - cd /src TB --- 2011-12-24 06:49:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Dec 24 06:49:16 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_unimsgcpy.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/sig/sig_verify.c -I/src/sys/contrib/ngatm cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pflog.c -I/src/sys/contrib/pf cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/pf/net/if_pfsync.c -I/src/sys/contrib/pf /src/sys/contrib/pf/net/if_pfsync.c: In function 'pfsync_in_bus': /src/sys/contrib/pf/net/if_pfsync.c:1615: error: 'pf_pool_limits' undeclared (first use in this function) /src/sys/contrib/pf/net/if_pfsync.c:1615: error: (Each undeclared identifier is reported only once /src/sys/contrib/pf/net/if_pfsync.c:1615: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-24 06:54:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-24 06:54:05 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2011-12-24 06:54:05 - 12905.98 user 2404.73 system 16445.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 09:09:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD418106566B for ; Sat, 24 Dec 2011 09:09:26 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A07118FC0A for ; Sat, 24 Dec 2011 09:09:26 +0000 (UTC) Received: by iadj38 with SMTP id j38so18867203iad.13 for ; Sat, 24 Dec 2011 01:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mSRZF53D+V3dnKYdhoCnD0ukZ08V00p8n9v/xnBZHnA=; b=C+9Cx59/bmeljXTL5YmPVjpPx6tfrt3j/emqMx4/r1YkEqtuTToYRTl+99sIXLhiH1 UjgzQp9Lfl90XQimoN7M+Q5inh15Q1XdUWXHZL0BtdstHUryBjjB8fBaLfnfv+mEpJcE L+gWJUeXGb9srcOFjQexvVAHnoMnYHstm+qJs= Received: by 10.50.158.193 with SMTP id ww1mr17155346igb.26.1324716395412; Sat, 24 Dec 2011 00:46:35 -0800 (PST) Received: from beastie.micom.mng.net ([202.179.14.46]) by mx.google.com with ESMTPS id r5sm10946152igl.3.2011.12.24.00.46.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Dec 2011 00:46:33 -0800 (PST) Message-ID: <4EF5915E.1030202@gmail.com> Date: Sat, 24 Dec 2011 16:46:22 +0800 From: Ganbold User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101030 Thunderbird/3.1.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= References: <20111219224545.GA22631@onelab2.iet.unipi.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 09:09:26 -0000 On 12/20/11 18:19, Olivier Cochard-Labbé wrote: > On Mon, Dec 19, 2011 at 11:45 PM, Luigi Rizzo wrote: >> On a related topic, does anyone have experience on cross-building >> nanobsd images ? > Hi Luigi, > > I using "little" cross-building nanobsd images (i386 on amd64 and vice versa). > All my patchs for nanobsd are available on BSD Router Project > (http://bsdrp.net) including a patch for compiling ports from nanobsd > too. > > Right now I'm working on adding cross-build mips (RouterStation Pro) > nanobsd patch but without the "compiling ports" feature, because I can > only cross-compile word/kernel and I didn't know how to cross-compile > ports. I have done some nanobsd related changes (without ports) locally for RS PRO 6 months ago, not sure how it is useful now. But it could be easier to modify. http://people.freebsd.org/~ganbold/nanobsd_rspro.tar.gz Ganbold > Regards, > > Olivier > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 09:12:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DD28A1065672; Sat, 24 Dec 2011 09:12:50 +0000 (UTC) Date: Sat, 24 Dec 2011 09:12:50 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20111224091250.GA9921@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111224160050.T1141@besplex.bde.org> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 09:12:51 -0000 On Sat Dec 24 11, Bruce Evans wrote: > On Fri, 23 Dec 2011, Alexander Best wrote: > > >is -mpreferred-stack-boundary=2 really necessary for i386 builds any > >longer? > >i built GENERIC (including modules) with and without that flag. the results > >are: > > The same as it has always been. It avoids some bloat. > > >1654496 bytes with the flag set > >vs. > >1654952 bytes with the flag unset > > I don't believe this. GENERIC is enormously bloated, so it has size > more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes i'm sorry. i used du(1) to get those numbers, so i believe those numbers represent the ammount of 512-byte blocks. if i'm correct GENERIC is even more bloated than you feared and almost reaches 1GB: 807,859375 megabytes with flag set vs. 808,0820313 megabytes without the flag set > is hard to believe. I get a savings of 9K (text) in a 5MB kernel. > Changing the default target arch from i386 to pentium-undocumented has > reduced the text space savings a little, since the default for passing > args is now to preallocate stack space for them and store to this, > instead of to push them; this preallocation results in more functions > needing to allocate some stack space explicitly, and when some is > allocated explicitly, the text space cost for this doesn't depend on > the size of the allocation. > > Anyway, the savings are mostly from from avoiding cache misses from > sparse allocation on stacks. > > Also, FreeBSD-i386 hasn't been programmed to support aligned stacks: > - KSTACK_PAGES on i386 is 2, while on amd64 it is 4. Using more > stack might push something over the edge > - not much care is taken to align the initial stack or to keep the > stack aligned in calls from asm code. E.g., any alignment for > mi_startup() (and thus proc0?) is accidental. This may result > in perfect alignment or perfect misalignment. Hopefully, more > care is taken with thread startup. For gcc, the alignment is > done bogusly in main() in userland, but there is no main() in > the kernel. The alignment doesn't matter much (provided the > perfect misalignment is still to a multiple of 4), but when it > matters, the random misalignment that results from not trying to > do it at all is better than perfect misalignment from getting it > wrong. With 4-byte alignment, the only cases that it helps are > with 64-bit variables. > > >the gcc(1) man page states the following: > > > >" > >This extra alignment does consume extra stack space, and generally > >increases code size. Code that is sensitive to stack space usage, > >such as embedded systems and operating system kernels, may want to > >reduce the preferred alignment to -mpreferred-stack-boundary=2. > >" > > > >the comment in sys/conf/kern.mk however sorta suggests that the default > >alignment of 4 bytes might improve performance. > > The default stack alignment is 16 bytes, which unimproves performance. > > clang handles stack alignment correctly (only does it when it is needed) > so it doesn't need a -mpreferred-stack-boundary option and doesn't > always break without alignment in main(). Well, at least it used to, > IIRC. Testing it now shows that it does the necessary andl of the > stack pointer for __aligned(32), but for __aligned(16) it now assumes > that the stack is aligned by the caller. So it now needs > -mpreferred-stack-boundary=2, but doesn't have it. OTOH, clang doesn't > do the andl in main() like gcc does (unless you put a dummy __aligned(32) > there), but requires crt to pass an aligned stack. > > Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 09:37:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C08091065670; Sat, 24 Dec 2011 09:37:53 +0000 (UTC) Date: Sat, 24 Dec 2011 09:37:53 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20111224093753.GA12377@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20111224160050.T1141@besplex.bde.org> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 09:37:53 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat Dec 24 11, Bruce Evans wrote: > On Fri, 23 Dec 2011, Alexander Best wrote: > > >is -mpreferred-stack-boundary=2 really necessary for i386 builds any > >longer? > >i built GENERIC (including modules) with and without that flag. the results > >are: > > The same as it has always been. It avoids some bloat. > > >1654496 bytes with the flag set > >vs. > >1654952 bytes with the flag unset > > I don't believe this. GENERIC is enormously bloated, so it has size > more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes > is hard to believe. I get a savings of 9K (text) in a 5MB kernel. > Changing the default target arch from i386 to pentium-undocumented has > reduced the text space savings a little, since the default for passing > args is now to preallocate stack space for them and store to this, > instead of to push them; this preallocation results in more functions > needing to allocate some stack space explicitly, and when some is > allocated explicitly, the text space cost for this doesn't depend on > the size of the allocation. > > Anyway, the savings are mostly from from avoiding cache misses from > sparse allocation on stacks. > > Also, FreeBSD-i386 hasn't been programmed to support aligned stacks: > - KSTACK_PAGES on i386 is 2, while on amd64 it is 4. Using more > stack might push something over the edge > - not much care is taken to align the initial stack or to keep the > stack aligned in calls from asm code. E.g., any alignment for > mi_startup() (and thus proc0?) is accidental. This may result > in perfect alignment or perfect misalignment. Hopefully, more > care is taken with thread startup. For gcc, the alignment is > done bogusly in main() in userland, but there is no main() in > the kernel. The alignment doesn't matter much (provided the > perfect misalignment is still to a multiple of 4), but when it > matters, the random misalignment that results from not trying to > do it at all is better than perfect misalignment from getting it > wrong. With 4-byte alignment, the only cases that it helps are > with 64-bit variables. > > >the gcc(1) man page states the following: > > > >" > >This extra alignment does consume extra stack space, and generally > >increases code size. Code that is sensitive to stack space usage, > >such as embedded systems and operating system kernels, may want to > >reduce the preferred alignment to -mpreferred-stack-boundary=2. > >" > > > >the comment in sys/conf/kern.mk however sorta suggests that the default > >alignment of 4 bytes might improve performance. > > The default stack alignment is 16 bytes, which unimproves performance. maybe the part of the comment in sys/conf/kern.mk, which mentions that a stack alignment of 16 bytes might improve micro benchmark results should be removed. this would prevent people (like me) from thinking, using a stack alignment of 4 bytes is a compromise between size and efficiently. it isn't! currently a stack alignment of 16 bytes has no advantages towards one with 4 bytes on i386. so specifying -mpreferred-stack-boundary=2 on i386 is absolutely mandatory. please see the attached patch, which also introduduces a line break in order to describe the stack alignment issue in a paragraph of its own. cheers. alex > > clang handles stack alignment correctly (only does it when it is needed) > so it doesn't need a -mpreferred-stack-boundary option and doesn't > always break without alignment in main(). Well, at least it used to, > IIRC. Testing it now shows that it does the necessary andl of the > stack pointer for __aligned(32), but for __aligned(16) it now assumes > that the stack is aligned by the caller. So it now needs > -mpreferred-stack-boundary=2, but doesn't have it. OTOH, clang doesn't > do the andl in main() like gcc does (unless you put a dummy __aligned(32) > there), but requires crt to pass an aligned stack. > > Bruce --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern.mk.diff" Index: /usr/src/sys/conf/kern.mk =================================================================== --- /usr/src/sys/conf/kern.mk (revision 228845) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -30,12 +30,12 @@ # On i386, do not align the stack to 16-byte boundaries. Otherwise GCC 2.95 # and above adds code to the entry and exit point of every function to align the # stack to 16-byte boundaries -- thus wasting approximately 12 bytes of stack -# per function call. While the 16-byte alignment may benefit micro benchmarks, -# it is probably an overall loss as it makes the code bigger (less efficient -# use of code cache tag lines) and uses more stack (less efficient use of data -# cache tag lines). Explicitly prohibit the use of FPU, SSE and other SIMD -# operations inside the kernel itself. These operations are exclusively -# reserved for user applications. +# per function call. This makes the code bigger (less efficient use of code +# cache tag lines) and uses more stack (less efficient use of data cache tag +# lines). +# Explicitly prohibit the use of FPU, SSE and other SIMD operations inside the +# kernel itself. These operations are exclusively reserved for user +# applications. # # gcc: # Setting -mno-mmx implies -mno-3dnow --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 10:18:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5CC106566C for ; Sat, 24 Dec 2011 10:18:36 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 491318FC13 for ; Sat, 24 Dec 2011 10:18:34 +0000 (UTC) Received: (qmail invoked by alias); 24 Dec 2011 09:51:52 -0000 Received: from g225199079.adsl.alicedsl.de (EHLO mandree.no-ip.org) [92.225.199.79] by mail.gmx.net (mp003) with SMTP; 24 Dec 2011 10:51:52 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+N5tY99+mNVr4mgiiIlj+DpVH6JLYOQTTwMtL0l2 mzEnUNHb+FZp8f Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 3499A23CE8F for ; Sat, 24 Dec 2011 10:51:51 +0100 (CET) Message-ID: <4EF5A0B7.8050002@gmx.de> Date: Sat, 24 Dec 2011 10:51:51 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Mnenhy/0.8.3 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111223235642.GA37495@freebsd.org> In-Reply-To: <20111223235642.GA37495@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 10:18:36 -0000 Am 24.12.2011 00:56, schrieb Alexander Best: > hi there, > > is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? > i built GENERIC (including modules) with and without that flag. the results > are: > > 1654496 bytes with the flag set > vs. > 1654952 bytes with the flag unset > > the gcc(1) man page states the following: > > " > This extra alignment does consume extra stack space, and generally > increases code size. Code that is sensitive to stack space usage, > such as embedded systems and operating system kernels, may want to > reduce the preferred alignment to -mpreferred-stack-boundary=2. > " > What do the numbers above have to do with *stack* alignment or size (which is a run-time figure, and cannot be statically determined if any variable-depth recursion takes place). What are those 16... numbers, anyways? How did you obtain them? From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 11:20:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC85106566C; Sat, 24 Dec 2011 11:20:09 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id EA31C8FC0A; Sat, 24 Dec 2011 11:20:08 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 988FB10E003; Sat, 24 Dec 2011 12:20:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20111224211903.I2059@besplex.bde.org> Date: Sat, 24 Dec 2011 12:20:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8883B1C2-738A-4C72-B977-AD610B33982B@lassitu.de> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224211903.I2059@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1251.1) Cc: Alexander Best , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:20:09 -0000 Am 24.12.2011 um 12:06 schrieb Bruce Evans: > On Fri, 23 Dec 2011, Adrian Chadd wrote: >=20 >> Well, the whole kernel is bloated at the moment, sorry. >>=20 >> I've been trying to build the _bare minimum_ required to bootstrap >> -HEAD on these embedded boards and I can't get the kernel down below = 5 >> megabytes - ie, one with FFS (with options disabled), MIPS, INET (no >> INET6), net80211, ath (which admittedly is big, but I need it no >> matter what, right?) comes in at: >>=20 >> -r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 >>=20 >> And with INET6, on another board (and this includes MSDOS and the >> relevant geom modules): >>=20 >> -r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO >>=20 >> .. honestly, that's what should be addressed. That's honestly a bit = ridiculous. >=20 > It's disgusting, but what problems does it cause apart from minor = slowness > from cache misses? The flash chip on these devices only has 8MB; some of the really cheap = ones only have 4MB (yes MB, not GB). And many have only 32MB RAM. It = would be nice to have space for actual applications :-) Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 11:27:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1BB4D1065670; Sat, 24 Dec 2011 11:27:59 +0000 (UTC) Date: Sat, 24 Dec 2011 11:27:59 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20111224112759.GA25716@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224091250.GA9921@freebsd.org> <20111224220705.H2059@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111224220705.H2059@besplex.bde.org> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:27:59 -0000 On Sat Dec 24 11, Bruce Evans wrote: > On Sat, 24 Dec 2011, Alexander Best wrote: > > >On Sat Dec 24 11, Bruce Evans wrote: > >>On Fri, 23 Dec 2011, Alexander Best wrote: > >> > >>>is -mpreferred-stack-boundary=2 really necessary for i386 builds any > >>>longer? > >>>i built GENERIC (including modules) with and without that flag. the > >>>results > >>>are: > >> > >>The same as it has always been. It avoids some bloat. > >> > >>>1654496 bytes with the flag set > >>>vs. > >>>1654952 bytes with the flag unset > >> > >>I don't believe this. GENERIC is enormously bloated, so it has size > >>more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes > > > >i'm sorry. i used du(1) to get those numbers, so i believe those numbers > >represent the ammount of 512-byte blocks. if i'm correct GENERIC is even > >more bloated than you feared and almost reaches 1GB: > > > >807,859375 megabytes with flag set > >vs. > >808,0820313 megabytes without the flag set > > That's certainly bloated. It counts all object files and modules, and > probably everything is compiled with -g. I only counted kernel text > size. yeah, but for demonstrating the different size between the build with -mpreferred-stack-boundary=2 set and -mpreferred-stack-boundary=2 unset, it doesn't really matter how big the directories are and if object files are included. the difference in size is < 1 megabyte. so setting -mpreferred-stack-boundary=2 doesn't aid in reducing the kernel (or modules) size, but merely to improve improve stack performance/efficiency. cheers. alex > > Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 11:47:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 501841065672; Sat, 24 Dec 2011 11:47:14 +0000 (UTC) Date: Sat, 24 Dec 2011 11:47:14 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20111224114714.GA29325@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224211903.I2059@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111224211903.I2059@besplex.bde.org> Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:47:14 -0000 On Sat Dec 24 11, Bruce Evans wrote: > On Fri, 23 Dec 2011, Adrian Chadd wrote: > > >Well, the whole kernel is bloated at the moment, sorry. > > > >I've been trying to build the _bare minimum_ required to bootstrap > >-HEAD on these embedded boards and I can't get the kernel down below 5 > >megabytes - ie, one with FFS (with options disabled), MIPS, INET (no > >INET6), net80211, ath (which admittedly is big, but I need it no > >matter what, right?) comes in at: > > > >-r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 > > > >And with INET6, on another board (and this includes MSDOS and the > >relevant geom modules): > > > >-r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO > > > >.. honestly, that's what should be addressed. That's honestly a bit > >ridiculous. > > It's disgusting, but what problems does it cause apart from minor slowness > from cache misses? > > I used to monitor the size of a minimal i386 kernel: > > % machine i386 > % cpu I686_CPU > % ident MIN > % options SCHED_4BSD > > In FreeBSD-5-CURRENT between 5.1R and 5.2R, this had size: > > text data bss dec hex filename > 931241 86524 62356 1080121 107b39 /sysc/i386/compile/min/kernel > > A minimal kernel is not useful, but maybe you can add some i/o to it > without bloating it too much. > > This almost builds in -current too. I had to add the following: > - NO_MODULES to de-bloat the compile time > - MK_CTF=no to build -current on FreeBSD.9. The kernel .mk files are > still broken (depend on nonstandard/new features in sys.mk). strange. the build(7) man page claims that: " WITH_CTF If defined, the build process will run the DTrace CTF conversion tools on built objects. Please note that this WITH_ option is handled differently than all other WITH_ options (there is no WITHOUT_CTF, or correspond- ing MK_CTF in the build system). " ... so setting MK_CTF to anything shouldn't have (according to the man page). cheers. alex > - comment out a line in if.c that refers to Vloif. if.c is standard > but the loop device is optional. > > A few more changes to remove non-minimalities that are not defaults > made little difference: > > % machine i386 > % cpu I686_CPU > % ident MIN > % options SCHED_4BSD > % > % # XXX kill default misconfigurations. > % makeoptions NO_MODULES=yes > % makeoptions COPTFLAGS="-O -pipe" > % > % # XXX from here on is to try to kill everything in DEFAULTS. > % > % # nodevice isa # needed for DELAY... > % # nooptions ISAPNP # needed ... > % > % nodevice npx > % > % nodevice mem > % nodevice io > % > % nodevice uart_ns8250 > % > % nooptions GEOM_PART_BSD > % nooptions GEOM_PART_EBR > % nooptions GEOM_PART_EBR_COMPAT > % nooptions GEOM_PART_MBR > % > % # nooptions NATIVE # needed ... > % # nodevice atpic # needed ... > % > % nooptions NEW_PCIB > % > % nooptions VFS_ALLOW_NONMPSAFE > > text data bss dec hex filename > 1663902 110632 136892 1911426 1d2a82 kernel > > (This was about 100K larger with -O2 and all DEFAULTS). The bloat since > FreeBSD-5 is only 70%. > > Here are some sizes for my standard kernel (on i386). The newer > versions have about the same number of features since they don't support > so many old isa devices or so many NICs: > > text data bss dec hex filename > 1483269 106972 172524 1762765 1ae5cd FreeBSD-3/kernel > 1917408 157472 194228 2269108 229fb4 FreeBSD-4/kernel > 2604498 198948 237720 3041166 2e678e FreeBSD-5.1.5/kernel > 2833842 206856 242936 3283634 321ab2 > FreeBSD-5.1.5/kernel-with-acpi > 2887573 192456 288696 3368725 336715 FreeBSD-5.1.5/kernel > with my changes, -O2 and usb > added relative to the above > 2582782 195756 298936 3077474 2ef562 previous, with some excessive > inlining avoided, and without -O2, > and with ipfilter > 1998276 159436 137748 2295460 2306a4 kernel.4 > a more up to date and less hacked on > FreeBSD-4 > 4365549 262656 209588 4837793 49d1a1 kernel.7 > 4406155 266496 496532 5169183 4ee01f kernel.7.invariants > 3953248 242464 207252 4402964 432f14 kernel.7.noacpi > 4418063 268288 240084 4926435 4b2be3 kernel.7.smp > various fairly stock FreeBSD-7R > kernels > 3669544 262848 249712 4182104 3fd058 kernel.c > 4174317 258240 540144 4972701 4be09d kernel.c.invariants > 3964455 250656 249808 4464919 442117 kernel.c.noacpi > 3213928 240160 240596 3694684 38605c kernel.c.noacpi-ule > 4285040 268288 286160 4839488 49d840 kernel.c.smp > current before FreeBSD-8R > not all built at the same time or > with the same options. The 20% > bloat between kernel.c.noacpi.ule > and kernel.c.noacpi is mainly > from not killing the default of > -O2. > 4742714 315008 401692 5459414 534dd6 kernel.8 > 4816900 319200 1813916 6950016 6a0c80 kernel.8.invariants > 4490209 304832 395260 5190301 4f329d kernel.8.noacpi > 4795475 323680 475420 5594575 555dcf kernel.8.smp > various fairly stock FreeBSD-8R > kernels > 4979632 287020 488404 5755056 57d0b0 kernel.cur > 5062953 289196 1902676 7254825 6eb329 kernel.cur.invariants > 5361809 295052 576984 6233845 5f1ef5 kernel.cur.smp > > amd64 kernels are only bout 4% larger if i386 kernels are built with > equivalant CFLAGS (-march=athlon64 for athlon64 CPU), but I usually > optimize i386 kernels for space and portability by compiling them > with -mtune=old. > > Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 12:14:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id B6854106566B; Sat, 24 Dec 2011 12:14:25 +0000 (UTC) Date: Sat, 24 Dec 2011 12:14:25 +0000 From: Alexander Best To: Bruce Evans Message-ID: <20111224121425.GA31084@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224093753.GA12377@freebsd.org> <20111224222040.Q2266@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111224222040.Q2266@besplex.bde.org> Cc: freebsd-current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 12:14:26 -0000 On Sat Dec 24 11, Bruce Evans wrote: > On Sat, 24 Dec 2011, Alexander Best wrote: > > >On Sat Dec 24 11, Bruce Evans wrote: > >>On Fri, 23 Dec 2011, Alexander Best wrote: > >... > >>>the gcc(1) man page states the following: > >>> > >>>" > >>>This extra alignment does consume extra stack space, and generally > >>>increases code size. Code that is sensitive to stack space usage, > >>>such as embedded systems and operating system kernels, may want to > >>>reduce the preferred alignment to -mpreferred-stack-boundary=2. > >>>" > >>> > >>>the comment in sys/conf/kern.mk however sorta suggests that the default > >>>alignment of 4 bytes might improve performance. > >> > >>The default stack alignment is 16 bytes, which unimproves performance. > > > >maybe the part of the comment in sys/conf/kern.mk, which mentions that a > >stack > >alignment of 16 bytes might improve micro benchmark results should be > >removed. > >this would prevent people (like me) from thinking, using a stack alignment > >of > >4 bytes is a compromise between size and efficiently. it isn't! currently a > >stack alignment of 16 bytes has no advantages towards one with 4 bytes on > >i386. > > I think the comment is clear enough. It it mentions all the tradeoffs. > It is only slightly cryptic in saying that these are tradeoffs and that > the configuration is our best guess at the best tradeoff -- it just says > "while" for both. It goes without saying that we don't use our worst > guess. Anyone wanting to change this should run benchmarks and beware > that micro-benchmarks are especially useless. The changed comment is not > so good since it no longer mentions micro-bencharmarks or says "while". if micro benchmark results aren't of any use, why should the claim that the default stack alignment of 16 bytes might produce better outcome stay? it doesn't seem as if anybody has micro benchmarked 16 bytes vs. 4 bytes stack alignment, until now. so the micro benchmark statement in the comment seems to be pure speculation. even worse...it indicates that by removing the -mpreferred-stack-boundary=2 flag, one can gain a performance boost by sacrifying a few more bytes of kernel (and module) size. this suggests that the behavior -mpreferred-stack-boundary=2 vs. not specyfing it, losely equals the semantics of -Os vs. -O2. i don't see how a 4 byte stack alignment for the kernel has any tradeoffs against the default 16 byte alignment. so if there are no tradeoffs, the comment shouldn't imply that there are. cheers. alex > > >so specifying -mpreferred-stack-boundary=2 on i386 is absolutely mandatory. > > Not mandatory; just an optimization. > > > > >please see the attached patch, which also introduduces a line break in > >order to > >describe the stack alignment issue in a paragraph of its own. > > There should also be an empty line for a paragraph break. > > % +# Explicitly prohibit the use of FPU, SSE and other SIMD operations > inside the > % +# kernel itself. These operations are exclusively reserved for user > % +# applications. > > This part was actually wronger: > - these operations are not really reserved, but were just not supported > in the kernel > - they have been supported in the kernel for some time, although anything > wanting to use the compiler to generate them would have to do something > to kill the options added here. Kernel code using them must inform the > kernel that it is doing so, using fpu_kern*(9undoc), and this is > only valid in some contexts (more or less for kernel-only threads) > so we still prevent compilers from using them routinely. The makefile > is not the right place to describe any of this, > > Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 06:16:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C737106564A; Sat, 24 Dec 2011 06:16:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id DDB1C8FC15; Sat, 24 Dec 2011 06:16:43 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBO6GXLX018222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 17:16:42 +1100 Date: Sat, 24 Dec 2011 17:16:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Best In-Reply-To: <20111223235642.GA37495@freebsd.org> Message-ID: <20111224160050.T1141@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 24 Dec 2011 12:36:54 +0000 Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 06:16:44 -0000 On Fri, 23 Dec 2011, Alexander Best wrote: > is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? > i built GENERIC (including modules) with and without that flag. the results > are: The same as it has always been. It avoids some bloat. > 1654496 bytes with the flag set > vs. > 1654952 bytes with the flag unset I don't believe this. GENERIC is enormously bloated, so it has size more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes is hard to believe. I get a savings of 9K (text) in a 5MB kernel. Changing the default target arch from i386 to pentium-undocumented has reduced the text space savings a little, since the default for passing args is now to preallocate stack space for them and store to this, instead of to push them; this preallocation results in more functions needing to allocate some stack space explicitly, and when some is allocated explicitly, the text space cost for this doesn't depend on the size of the allocation. Anyway, the savings are mostly from from avoiding cache misses from sparse allocation on stacks. Also, FreeBSD-i386 hasn't been programmed to support aligned stacks: - KSTACK_PAGES on i386 is 2, while on amd64 it is 4. Using more stack might push something over the edge - not much care is taken to align the initial stack or to keep the stack aligned in calls from asm code. E.g., any alignment for mi_startup() (and thus proc0?) is accidental. This may result in perfect alignment or perfect misalignment. Hopefully, more care is taken with thread startup. For gcc, the alignment is done bogusly in main() in userland, but there is no main() in the kernel. The alignment doesn't matter much (provided the perfect misalignment is still to a multiple of 4), but when it matters, the random misalignment that results from not trying to do it at all is better than perfect misalignment from getting it wrong. With 4-byte alignment, the only cases that it helps are with 64-bit variables. > the gcc(1) man page states the following: > > " > This extra alignment does consume extra stack space, and generally > increases code size. Code that is sensitive to stack space usage, > such as embedded systems and operating system kernels, may want to > reduce the preferred alignment to -mpreferred-stack-boundary=2. > " > > the comment in sys/conf/kern.mk however sorta suggests that the default > alignment of 4 bytes might improve performance. The default stack alignment is 16 bytes, which unimproves performance. clang handles stack alignment correctly (only does it when it is needed) so it doesn't need a -mpreferred-stack-boundary option and doesn't always break without alignment in main(). Well, at least it used to, IIRC. Testing it now shows that it does the necessary andl of the stack pointer for __aligned(32), but for __aligned(16) it now assumes that the stack is aligned by the caller. So it now needs -mpreferred-stack-boundary=2, but doesn't have it. OTOH, clang doesn't do the andl in main() like gcc does (unless you put a dummy __aligned(32) there), but requires crt to pass an aligned stack. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 11:06:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0B11065678; Sat, 24 Dec 2011 11:06:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id C4FD98FC14; Sat, 24 Dec 2011 11:06:58 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBOB6sTv019496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 22:06:56 +1100 Date: Sat, 24 Dec 2011 22:06:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd In-Reply-To: Message-ID: <20111224211903.I2059@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 24 Dec 2011 12:37:08 +0000 Cc: Alexander Best , freebsd-current@freebsd.org, Bruce Evans , freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:06:59 -0000 On Fri, 23 Dec 2011, Adrian Chadd wrote: > Well, the whole kernel is bloated at the moment, sorry. > > I've been trying to build the _bare minimum_ required to bootstrap > -HEAD on these embedded boards and I can't get the kernel down below 5 > megabytes - ie, one with FFS (with options disabled), MIPS, INET (no > INET6), net80211, ath (which admittedly is big, but I need it no > matter what, right?) comes in at: > > -r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 > > And with INET6, on another board (and this includes MSDOS and the > relevant geom modules): > > -r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO > > .. honestly, that's what should be addressed. That's honestly a bit ridiculous. It's disgusting, but what problems does it cause apart from minor slowness from cache misses? I used to monitor the size of a minimal i386 kernel: % machine i386 % cpu I686_CPU % ident MIN % options SCHED_4BSD In FreeBSD-5-CURRENT between 5.1R and 5.2R, this had size: text data bss dec hex filename 931241 86524 62356 1080121 107b39 /sysc/i386/compile/min/kernel A minimal kernel is not useful, but maybe you can add some i/o to it without bloating it too much. This almost builds in -current too. I had to add the following: - NO_MODULES to de-bloat the compile time - MK_CTF=no to build -current on FreeBSD.9. The kernel .mk files are still broken (depend on nonstandard/new features in sys.mk). - comment out a line in if.c that refers to Vloif. if.c is standard but the loop device is optional. A few more changes to remove non-minimalities that are not defaults made little difference: % machine i386 % cpu I686_CPU % ident MIN % options SCHED_4BSD % % # XXX kill default misconfigurations. % makeoptions NO_MODULES=yes % makeoptions COPTFLAGS="-O -pipe" % % # XXX from here on is to try to kill everything in DEFAULTS. % % # nodevice isa # needed for DELAY... % # nooptions ISAPNP # needed ... % % nodevice npx % % nodevice mem % nodevice io % % nodevice uart_ns8250 % % nooptions GEOM_PART_BSD % nooptions GEOM_PART_EBR % nooptions GEOM_PART_EBR_COMPAT % nooptions GEOM_PART_MBR % % # nooptions NATIVE # needed ... % # nodevice atpic # needed ... % % nooptions NEW_PCIB % % nooptions VFS_ALLOW_NONMPSAFE text data bss dec hex filename 1663902 110632 136892 1911426 1d2a82 kernel (This was about 100K larger with -O2 and all DEFAULTS). The bloat since FreeBSD-5 is only 70%. Here are some sizes for my standard kernel (on i386). The newer versions have about the same number of features since they don't support so many old isa devices or so many NICs: text data bss dec hex filename 1483269 106972 172524 1762765 1ae5cd FreeBSD-3/kernel 1917408 157472 194228 2269108 229fb4 FreeBSD-4/kernel 2604498 198948 237720 3041166 2e678e FreeBSD-5.1.5/kernel 2833842 206856 242936 3283634 321ab2 FreeBSD-5.1.5/kernel-with-acpi 2887573 192456 288696 3368725 336715 FreeBSD-5.1.5/kernel with my changes, -O2 and usb added relative to the above 2582782 195756 298936 3077474 2ef562 previous, with some excessive inlining avoided, and without -O2, and with ipfilter 1998276 159436 137748 2295460 2306a4 kernel.4 a more up to date and less hacked on FreeBSD-4 4365549 262656 209588 4837793 49d1a1 kernel.7 4406155 266496 496532 5169183 4ee01f kernel.7.invariants 3953248 242464 207252 4402964 432f14 kernel.7.noacpi 4418063 268288 240084 4926435 4b2be3 kernel.7.smp various fairly stock FreeBSD-7R kernels 3669544 262848 249712 4182104 3fd058 kernel.c 4174317 258240 540144 4972701 4be09d kernel.c.invariants 3964455 250656 249808 4464919 442117 kernel.c.noacpi 3213928 240160 240596 3694684 38605c kernel.c.noacpi-ule 4285040 268288 286160 4839488 49d840 kernel.c.smp current before FreeBSD-8R not all built at the same time or with the same options. The 20% bloat between kernel.c.noacpi.ule and kernel.c.noacpi is mainly from not killing the default of -O2. 4742714 315008 401692 5459414 534dd6 kernel.8 4816900 319200 1813916 6950016 6a0c80 kernel.8.invariants 4490209 304832 395260 5190301 4f329d kernel.8.noacpi 4795475 323680 475420 5594575 555dcf kernel.8.smp various fairly stock FreeBSD-8R kernels 4979632 287020 488404 5755056 57d0b0 kernel.cur 5062953 289196 1902676 7254825 6eb329 kernel.cur.invariants 5361809 295052 576984 6233845 5f1ef5 kernel.cur.smp amd64 kernels are only bout 4% larger if i386 kernels are built with equivalant CFLAGS (-march=athlon64 for athlon64 CPU), but I usually optimize i386 kernels for space and portability by compiling them with -mtune=old. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 11:12:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFAAD106564A; Sat, 24 Dec 2011 11:12:44 +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 6C5B38FC12; Sat, 24 Dec 2011 11:12:44 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBOBCghY028087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 22:12:42 +1100 Date: Sat, 24 Dec 2011 22:12:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Best In-Reply-To: <20111224091250.GA9921@freebsd.org> Message-ID: <20111224220705.H2059@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224091250.GA9921@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 24 Dec 2011 12:37:21 +0000 Cc: freebsd-current@freebsd.org, Bruce Evans , freebsd-arch@freebsd.org Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:12:45 -0000 On Sat, 24 Dec 2011, Alexander Best wrote: > On Sat Dec 24 11, Bruce Evans wrote: >> On Fri, 23 Dec 2011, Alexander Best wrote: >> >>> is -mpreferred-stack-boundary=2 really necessary for i386 builds any >>> longer? >>> i built GENERIC (including modules) with and without that flag. the results >>> are: >> >> The same as it has always been. It avoids some bloat. >> >>> 1654496 bytes with the flag set >>> vs. >>> 1654952 bytes with the flag unset >> >> I don't believe this. GENERIC is enormously bloated, so it has size >> more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes > > i'm sorry. i used du(1) to get those numbers, so i believe those numbers > represent the ammount of 512-byte blocks. if i'm correct GENERIC is even > more bloated than you feared and almost reaches 1GB: > > 807,859375 megabytes with flag set > vs. > 808,0820313 megabytes without the flag set That's certainly bloated. It counts all object files and modules, and probably everything is compiled with -g. I only counted kernel text size. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 12:40:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6D6106564A; Sat, 24 Dec 2011 12:40:13 +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 6CF2B8FC0C; Sat, 24 Dec 2011 12:40:13 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBOCe9TG027147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 23:40:11 +1100 Date: Sat, 24 Dec 2011 23:40:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Best In-Reply-To: <20111224114714.GA29325@freebsd.org> Message-ID: <20111224225717.P2417@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224211903.I2059@besplex.bde.org> <20111224114714.GA29325@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 24 Dec 2011 13:52:58 +0000 Cc: Adrian Chadd , freebsd-current@FreeBSD.ORG, Bruce Evans , freebsd-arch@FreeBSD.ORG Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 12:40:14 -0000 On Sat, 24 Dec 2011, Alexander Best wrote: > On Sat Dec 24 11, Bruce Evans wrote: >> This almost builds in -current too. I had to add the following: >> - NO_MODULES to de-bloat the compile time >> - MK_CTF=no to build -current on FreeBSD.9. The kernel .mk files are >> still broken (depend on nonstandard/new features in sys.mk). > > strange. the build(7) man page claims that: > > " > WITH_CTF If defined, the build process will run the DTrace CTF > conversion tools on built objects. Please note that > this WITH_ option is handled differently than all other > WITH_ options (there is no WITHOUT_CTF, or correspond- > ing MK_CTF in the build system). > " > > ... so setting MK_CTF to anything shouldn't have (according to the man page). MK_CTF is an implementation detail. It is normally set in bsd.own.mk (not in sys.mk line I said -- this gives another, much larger bug (*)). But when usr/share/mk is old, it doesn't know anything about MK_CTF. (For example, in FreeBSD-9, sys.mk sets NO_CTF to 1 if WITH_CTF is not defined. This corresponds to bsd.own.mk in -current setting MK_CTF to "no" if WITH_CTF is not defined. Go back to an older version of FreeBSD and /usr/share/mk/* won't know anything about any CTF variable.) So when you try to build a current kernel under an old version of FreeBSD, MK_CTF is used uninitialized and the build fails. (Of course, "you" build kernels normally and don't use the bloated buildkernel method.) The bug is in the following files: kern.post.mk:.if ${MK_CTF} != "no" kern.pre.mk:.if ${MK_CTF} != "no" kmod.mk:.if defined(MK_CTF) && ${MK_CTF} != "no" except for the last one where it has been fixed. (*) Well, not completely broken, but just annoyingly unportabile. Consider the following makefile: %%% foo: foo.c %%% Invoking this under FreeBSD-9 gives: %%% cc -O2 -pipe foo.c -o foo [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION foo && ctfconvert -L VERSION foo) %%% This is the old ctf method. It is ugly but is fairly portable. Invoking this under FreeBSD-9 but with -m gives %%% cc -O2 -pipe foo.c -o foo ${CTFCONVERT_CMD} expands to empty string %%% This is because: - the rule in sys.mk says ${CTFCONVERT_CMD} - CTFCONVERT_CMD is normally defined in bsd.own.mk. But bsd.own.mk is only included by BSD makefiles. It is never included by portable makefiles. So ${CTFCONVERT_CMD} is used uninitialized. - for some reason, using variables uninitialized is not fatal in this context, although it is for the comparisons of ${MK_CTF} above. - ${CTFCONVERT_CMD} is replaced by the empty string. Old versions of make warn about the use of an empty string as a shell command. - the code that is supposed to prevent the previous warning is in bsd.own.mk, where it is not reached for portable makefiles. It is: % .if ${MK_CTF} != "no" % CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} This uses the full ctfconvert if WITH_CTF. % .elif ${MAKE_VERSION} >= 5201111300 % CTFCONVERT_CMD= make(1) has been modified to not complain about the empty string. The version test detects which versions of make don't complain. % .else % CTFCONVERT_CMD= @: The default is to generate this non-empty string and an extra shell command to execute it, for old versions of make. % .endif But none of this works for portable makefiles, since it is not reached. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 14:08:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633D8106564A for ; Sat, 24 Dec 2011 14:08:23 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBC98FC12 for ; Sat, 24 Dec 2011 14:08:22 +0000 (UTC) Received: by iadj38 with SMTP id j38so19273105iad.13 for ; Sat, 24 Dec 2011 06:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=VdSfz85/IV+p7ZhsPRuiM6OUL7aM/nJQX/bD8xs208g=; b=eII2EgGv0woJyl9a6XfVzqK7cU1JuQhw1zojrcEgUPQFoRtqksLiDgU1g+cFv2qhet uWQn/rajWyePcbdjXi3oKGYlR/neoMwVDi6nX6kwTioAJHSezGiZFEKuOAXFE+Bo0eSJ 0ayU9dchJ8tYm4BCpDVeHVMIhEXiPcSrx2Cyk= MIME-Version: 1.0 Received: by 10.50.160.201 with SMTP id xm9mr18570062igb.16.1324735702561; Sat, 24 Dec 2011 06:08:22 -0800 (PST) Received: by 10.231.15.7 with HTTP; Sat, 24 Dec 2011 06:08:22 -0800 (PST) Date: Sat, 24 Dec 2011 16:08:22 +0200 Message-ID: From: George Kontostanos To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1 Subject: 9-RC3 & Super Micro IPMI disconnects X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 14:08:23 -0000 Hi everyone, I started running FreeBSD9-RC1 on this server. Yesterday, RC3, I noticed that I could not get IPMI console to apply the necessary security patches. A reset in IPMI fixed the problem temporarily. I keep getting those messages: Dec 24 15:35:12 mail kernel: ums0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:35:12 mail kernel: ukbd0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:35:14 mail kernel: usb_alloc_device: set address 3 failed (USB_ERR_TIMEOUT, ignored) Dec 24 15:35:14 mail kernel: usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED Dec 24 15:35:15 mail kernel: usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) Dec 24 15:35:15 mail kernel: usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED Dec 24 15:35:15 mail kernel: usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) Dec 24 15:35:15 mail kernel: usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED Dec 24 15:35:15 mail kernel: ugen0.3: at usbus0 (disconnected) Dec 24 15:35:15 mail kernel: uhub_reattach_port: could not allocate new device Dec 24 15:35:16 mail kernel: ugen0.3: at usbus0 Dec 24 15:35:16 mail kernel: ums0: on usbus0 Dec 24 15:35:16 mail kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 Dec 24 15:35:16 mail kernel: ukbd0: on usbus0 Dec 24 15:35:16 mail kernel: kbd2 at ukbd0 Dec 24 15:35:17 mail kernel: ugen0.3: at usbus0 (disconnected) Dec 24 15:35:17 mail kernel: ums0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:35:17 mail kernel: ukbd0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:35:18 mail kernel: ugen0.3: at usbus0 Dec 24 15:35:18 mail kernel: ums0: on usbus0 Dec 24 15:35:18 mail kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 24 15:35:18 mail kernel: ukbd0: on usbus0 Dec 24 15:35:18 mail kernel: kbd2 at ukbd0 Dec 24 15:36:40 mail login: ROOT LOGIN (root) ON ttyv0 Dec 24 15:54:05 mail kernel: ugen0.3: at usbus0 (disconnected) Dec 24 15:54:05 mail kernel: ums0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:54:05 mail kernel: ukbd0: at uhub2, port 2, addr 3 (disconnected) Dec 24 15:54:06 mail kernel: ugen0.3: at usbus0 Dec 24 15:54:06 mail kernel: ums0: on usbus0 Dec 24 15:54:06 mail kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 24 15:54:06 mail kernel: ukbd0: on usbus0 Dec 24 15:54:06 mail kernel: kbd2 at ukbd0 Full dmesg from the server: Dec 23 21:37:57 mail kernel: Copyright (c) 1992-2011 The FreeBSD Project. Dec 23 21:37:57 mail kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 23 21:37:57 mail kernel: The Regents of the University of California. All rights reserved. Dec 23 21:37:57 mail kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Dec 23 21:37:57 mail kernel: FreeBSD 9.0-RC3 #0: Fri Dec 23 21:23:00 EET 2011 Dec 23 21:37:57 mail kernel: root@my.domain.tld:/usr/obj/usr/src/sys/GENERIC amd64 Dec 23 21:37:57 mail kernel: CPU: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz (3093.04-MHz K8-class CPU) Dec 23 21:37:57 mail kernel: Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Dec 23 21:37:57 mail kernel: Features=0xbfebfbff Dec 23 21:37:57 mail kernel: Features2=0x159ae3bf Dec 23 21:37:57 mail kernel: AMD Features=0x28100800 Dec 23 21:37:57 mail kernel: AMD Features2=0x1 Dec 23 21:37:57 mail kernel: TSC: P-state invariant, performance statistics Dec 23 21:37:57 mail kernel: real memory = 8589934592 (8192 MB) Dec 23 21:37:57 mail kernel: avail memory = 8206499840 (7826 MB) Dec 23 21:37:57 mail kernel: Event timer "LAPIC" quality 600 Dec 23 21:37:57 mail kernel: ACPI APIC Table: Dec 23 21:37:57 mail kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Dec 23 21:37:57 mail kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads Dec 23 21:37:57 mail kernel: cpu0 (BSP): APIC ID: 0 Dec 23 21:37:57 mail kernel: cpu1 (AP): APIC ID: 1 Dec 23 21:37:57 mail kernel: cpu2 (AP): APIC ID: 2 Dec 23 21:37:57 mail kernel: cpu3 (AP): APIC ID: 3 Dec 23 21:37:57 mail kernel: ioapic0 irqs 0-23 on motherboard Dec 23 21:37:57 mail kernel: kbd1 at kbdmux0 Dec 23 21:37:57 mail kernel: acpi0: on motherboard Dec 23 21:37:57 mail kernel: acpi0: Power Button (fixed) Dec 23 21:37:57 mail kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Dec 23 21:37:57 mail kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Dec 23 21:37:57 mail kernel: cpu0: on acpi0 Dec 23 21:37:57 mail kernel: cpu1: on acpi0 Dec 23 21:37:57 mail kernel: cpu2: on acpi0 Dec 23 21:37:57 mail kernel: cpu3: on acpi0 Dec 23 21:37:57 mail kernel: pcib0: port 0xcf8-0xcff on acpi0 Dec 23 21:37:57 mail kernel: pci0: on pcib0 Dec 23 21:37:57 mail kernel: em0: port 0xf020-0xf03f mem 0xfba00000-0xfba1ffff,0xfba24000-0xfba24fff irq 20 at device 25.0 on pci0 Dec 23 21:37:57 mail kernel: em0: Using an MSI interrupt Dec 23 21:37:57 mail kernel: em0: Ethernet address: 00:25:90:52:e5:cf Dec 23 21:37:57 mail kernel: ehci0: mem 0xfba23000-0xfba233ff irq 16 at device 26.0 on pci0 Dec 23 21:37:57 mail kernel: usbus0: EHCI version 1.0 Dec 23 21:37:57 mail kernel: usbus0: on ehci0 Dec 23 21:37:57 mail kernel: pcib1: irq 17 at device 28.0 on pci0 Dec 23 21:37:57 mail kernel: pci1: on pcib1 Dec 23 21:37:57 mail kernel: pcib2: irq 17 at device 28.4 on pci0 Dec 23 21:37:57 mail kernel: pci2: on pcib2 Dec 23 21:37:57 mail kernel: em1: port 0xe000-0xe01f mem 0xfb900000-0xfb91ffff,0xfb920000-0xfb923fff irq 16 at device 0.0 on pci2 Dec 23 21:37:57 mail kernel: em1: Using MSIX interrupts with 3 vectors Dec 23 21:37:57 mail kernel: em1: Ethernet address: 00:25:90:52:e5:ce Dec 23 21:37:57 mail kernel: ehci1: mem 0xfba22000-0xfba223ff irq 23 at device 29.0 on pci0 Dec 23 21:37:57 mail kernel: usbus1: EHCI version 1.0 Dec 23 21:37:57 mail kernel: usbus1: on ehci1 Dec 23 21:37:57 mail kernel: pcib3: at device 30.0 on pci0 Dec 23 21:37:57 mail kernel: pci3: on pcib3 Dec 23 21:37:57 mail kernel: vgapci0: mem 0xfa000000-0xfaffffff,0xfb800000-0xfb803fff,0xfb000000-0xfb7fffff irq 23 at device 3.0 on pci3 Dec 23 21:37:57 mail kernel: isab0: at device 31.0 on pci0 Dec 23 21:37:57 mail kernel: isa0: on isab0 Dec 23 21:37:57 mail kernel: ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfba21000-0xfba217ff irq 19 at device 31.2 on pci0 Dec 23 21:37:57 mail kernel: ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported Dec 23 21:37:57 mail kernel: ahcich0: at channel 0 on ahci0 Dec 23 21:37:57 mail kernel: ahcich1: at channel 1 on ahci0 Dec 23 21:37:57 mail kernel: pci0: at device 31.3 (no driver attached) Dec 23 21:37:57 mail kernel: acpi_button0: on acpi0 Dec 23 21:37:57 mail kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Dec 23 21:37:57 mail kernel: Timecounter "HPET" frequency 14318180 Hz quality 950 Dec 23 21:37:57 mail kernel: Event timer "HPET" frequency 14318180 Hz quality 550 Dec 23 21:37:57 mail kernel: Event timer "HPET1" frequency 14318180 Hz quality 440 Dec 23 21:37:57 mail kernel: Event timer "HPET2" frequency 14318180 Hz quality 440 Dec 23 21:37:57 mail kernel: Event timer "HPET3" frequency 14318180 Hz quality 440 Dec 23 21:37:57 mail kernel: Event timer "HPET4" frequency 14318180 Hz quality 440 Dec 23 21:37:57 mail kernel: attimer0: port 0x40-0x43 irq 0 on acpi0 Dec 23 21:37:57 mail kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Dec 23 21:37:57 mail kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Dec 23 21:37:57 mail kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Dec 23 21:37:57 mail kernel: Event timer "RTC" frequency 32768 Hz quality 0 Dec 23 21:37:57 mail kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Dec 23 21:37:57 mail kernel: atkbd0: irq 1 on atkbdc0 Dec 23 21:37:57 mail kernel: kbd0 at atkbd0 Dec 23 21:37:57 mail kernel: atkbd0: [GIANT-LOCKED] Dec 23 21:37:57 mail kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Dec 23 21:37:57 mail kernel: uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 Dec 23 21:37:57 mail kernel: uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 Dec 23 21:37:57 mail kernel: orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 Dec 23 21:37:57 mail kernel: sc0: at flags 0x100 on isa0 Dec 23 21:37:57 mail kernel: sc0: VGA <16 virtual consoles, flags=0x300> Dec 23 21:37:57 mail kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Dec 23 21:37:57 mail kernel: ppc0: cannot reserve I/O port range Dec 23 21:37:57 mail kernel: est0: on cpu0 Dec 23 21:37:57 mail kernel: p4tcc0: on cpu0 Dec 23 21:37:57 mail kernel: est1: on cpu1 Dec 23 21:37:57 mail kernel: p4tcc1: on cpu1 Dec 23 21:37:57 mail kernel: est2: on cpu2 Dec 23 21:37:57 mail kernel: p4tcc2: on cpu2 Dec 23 21:37:57 mail kernel: est3: on cpu3 Dec 23 21:37:57 mail kernel: p4tcc3: on cpu3 Dec 23 21:37:57 mail kernel: ZFS filesystem version 5 Dec 23 21:37:57 mail kernel: ZFS storage pool version 28 Dec 23 21:37:57 mail kernel: Timecounters tick every 1.000 msec Dec 23 21:37:57 mail kernel: usbus0: 480Mbps High Speed USB v2.0 Dec 23 21:37:57 mail kernel: usbus1: 480Mbps High Speed USB v2.0 Dec 23 21:37:57 mail kernel: ugen0.1: at usbus0 Dec 23 21:37:57 mail kernel: uhub0: on usbus0 Dec 23 21:37:57 mail kernel: ugen1.1: at usbus1 Dec 23 21:37:57 mail kernel: uhub1: on usbus1 Dec 23 21:37:57 mail kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Dec 23 21:37:57 mail kernel: ada0: ATA-8 SATA 2.x device Dec 23 21:37:57 mail kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Dec 23 21:37:57 mail kernel: ada0: Command Queueing enabled Dec 23 21:37:57 mail kernel: ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) Dec 23 21:37:57 mail kernel: ada0: Previously was known as ad4 Dec 23 21:37:57 mail kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Dec 23 21:37:57 mail kernel: ada1: ATA-8 SATA 2.x device Dec 23 21:37:57 mail kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Dec 23 21:37:57 mail kernel: ada1: Command Queueing enabled Dec 23 21:37:57 mail kernel: ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) Dec 23 21:37:57 mail kernel: ada1: Previously was known as ad6 Dec 23 21:37:57 mail kernel: SMP: AP CPU #1 Launched! Dec 23 21:37:57 mail kernel: SMP: AP CPU #2 Launched! Dec 23 21:37:57 mail kernel: SMP: AP CPU #3 Launched! Dec 23 21:37:57 mail kernel: Timecounter "TSC-low" frequency 12082185 Hz quality 1000 Dec 23 21:37:57 mail kernel: Root mount waiting for: usbus1 usbus0 Dec 23 21:37:57 mail kernel: uhub0: 2 ports with 2 removable, self powered Dec 23 21:37:57 mail kernel: uhub1: 2 ports with 2 removable, self powered Dec 23 21:37:57 mail kernel: Root mount waiting for: usbus1 usbus0 Dec 23 21:37:57 mail kernel: ugen0.2: at usbus0 Dec 23 21:37:57 mail kernel: uhub2: on usbus0 Dec 23 21:37:57 mail kernel: ugen1.2: at usbus1 Dec 23 21:37:57 mail kernel: uhub3: on usbus1 Dec 23 21:37:57 mail kernel: Root mount waiting for: usbus1 usbus0 Dec 23 21:37:57 mail kernel: uhub2: 6 ports with 6 removable, self powered Dec 23 21:37:57 mail kernel: uhub3: 6 ports with 6 removable, self powered Dec 23 21:37:57 mail kernel: ugen0.3: at usbus0 Dec 23 21:37:57 mail kernel: ums0: on usbus0 Dec 23 21:37:57 mail kernel: ums0: 3 buttons and [Z] coordinates ID=0 Dec 23 21:37:57 mail kernel: ukbd0: on usbus0 Dec 23 21:37:57 mail kernel: kbd2 at ukbd0 Dec 23 21:37:57 mail kernel: Trying to mount root from zfs:zroot []... Dec 23 21:37:58 mail kernel: . Dec 23 21:37:58 mail kernel: em1: link state changed to UP Any ideas ? Thanks From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 14:49:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5B12106564A for ; Sat, 24 Dec 2011 14:49:54 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3128B8FC0A for ; Sat, 24 Dec 2011 14:49:53 +0000 (UTC) Received: by eaaf13 with SMTP id f13so12877013eaa.13 for ; Sat, 24 Dec 2011 06:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=2E4ZSRME6EpjjgJppQRSrPEcItdFeBXlp55WITAgLJ8=; b=gncboF6w210tSFIiZY/26df4IolCBG72lVupnTjlifQAg31idVSual+hMSUBG6BOIw MnfbkfNbTs8RoGpMAoL3/HIrQmMA9UCxrR4BFTeGZd56gQ81lyehprUecrvYwu2uccLG BAYPHSoDUnKjDZc1E8DLm1cd9PTJkwUSsev38= Received: by 10.213.17.146 with SMTP id s18mr6695895eba.109.1324736823528; Sat, 24 Dec 2011 06:27:03 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id b49sm32495505eec.9.2011.12.24.06.27.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Dec 2011 06:27:02 -0800 (PST) Sender: Alexander Motin Message-ID: <4EF5E134.9040903@FreeBSD.org> Date: Sat, 24 Dec 2011 16:27:00 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111123 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: RFC: SCSI UNMAP (TRIM) support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 14:49:54 -0000 Hi. I've implemented patch for logical block provisioning (aka UNMAP, TRIM, BIO_DELETE) support for the CAM da driver in HEAD and would like to ask for review, testing and hardware support information. Depending on device capabilities I use several different methods to implement it. Method can be read/set via kern.cam.da.X.delete_method sysctls. Possible values are: NONE - no provisioning support reported by the device; DISABLE - provisioning support was disabled because of errors; ZERO - use WRITE SAME (10) command to write zeroes; WS10 - use WRITE SAME (10) command with UNMAP bit set; WS16 - use WRITE SAME (16) command with UNMAP bit set; UNMAP - use UNMAP command. Last two methods (UNMAP and WS16) are defined by SBC specification and UNMAP method is the most advanced one. The rest of methods I've found supported in Linux, and as soon as they were trivial to implement, then why not? Hope they will be useful in some cases. Unluckily at this moment I have no devices reporting parameters of the logical block provisioning support via respective VPD pages (0xB0 and 0xB2). So all info I have/use now is the flag telling whether logical block provisioning is supported or not. As result specific methods chosen now by trying different ones in order (UNMAP, WS16, DISABLE) and checking completion status to fallback if needed. I don't expect problems from this, as if something go wrong, it should just disable itself. It may disable even too aggressively. Unlike Linux, which executes each delete with separate request, I've implemented here the same request aggregation as implemented in ada driver. Tests on SSDs I have show much better results doing it this way: above 8GB/s of the linear delete on Intel SATA SSD on LSI SAS HBA (mps). The patch can be found here: http://people.freebsd.org/~mav/scsi_unmap.patch Work sponsored by iXsystems, Inc. If somebody has SAS SSDs with UNMAP support, I would be grateful for additional information about them, such as: camcontrol cmd da0 -c "12 01 00 00 ff 00" -i 255 - >pages camcontrol cmd da0 -c "12 01 b0 00 ff 00" -i 255 - >page_b0 camcontrol cmd da0 -c "12 01 b2 00 ff 00" -i 255 - >page_b2 camcontrol cmd da0 -c "9e 10 00 00 00 00 00 00 00 00 00 00 00 ff 00 00" -i 255 - >rc16 Thank you! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 14:49:04 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB51E1065673; Sat, 24 Dec 2011 14:49:04 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB438FC08; Sat, 24 Dec 2011 14:49:04 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1ReSuE-0003Zl-4H>; Sat, 24 Dec 2011 15:49:02 +0100 Received: from e178017174.adsl.alicedsl.de ([85.178.17.174] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1ReSuD-0006C4-T1>; Sat, 24 Dec 2011 15:49:02 +0100 Message-ID: <4EF5E65C.3060405@mail.zedat.fu-berlin.de> Date: Sat, 24 Dec 2011 15:49:00 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Daniel Kalchev References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF45C85.9010709@mail.zedat.fu-berlin.de> <4EF46829.6010508@digsys.bg> In-Reply-To: <4EF46829.6010508@digsys.bg> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig863C2B495A6AA626DD82D833" X-Originating-IP: 85.178.17.174 X-Mailman-Approved-At: Sat, 24 Dec 2011 15:01:15 +0000 Cc: Martin Sugioarto , freebsd-current@FreeBSD.ORG, Igor Mozolevsky , freebsd-performance@FreeBSD.ORG, "O. Hartmann" , Daniel@FreeBSD.ORG Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 14:49:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig863C2B495A6AA626DD82D833 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/23/11 12:38, Daniel Kalchev wrote: >=20 >=20 > On 23.12.11 12:48, O. Hartmann wrote: >> Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a= >> way that is far beyond enough! He gave tests, insights of his setup, >> bad performance compared to SCHED_4BSD and what happend? We are still >> stuck with this problem and more and more people realise, that FreeBSD= >> does have somewhere a problem and this seems to be a nasty problem not= >> easy to find or investigate. >=20 > This has made me to realize, that I was having a problem with SCHED_ULE= > that I was not aware of until now. WOW! :) >=20 > Every scheduler has some problem, some fail here some fail there. I am > confident, that the case that Steve Kargls has reported will be resolve= d. >=20 >> Another problem is this very elite-feeling closed club. Once you >> managed it getting into the club of committers or core team members, >> you'll probably fight for your seat ... I dont propose for that >> socialists crap Linux people tend to be like, > [..] >=20 > You never heard of the "People's Republic of Berkeley"? :) >=20 > As for commiter access, this sort of comments trigger the system > administrator in me. I have seen enough people, who for the lack of > other excuses always use "but I don't have enough RIGHTS!". I am evil, = I > know.... >=20 >> But I follow the illusion that if people can see what benchmarks >> reveal, they start thinking and if the facts are starting to give a >> heavy load load on those rejecting the facts, they migght change their= >> opinion or get hopefully replaced by more openminded people. >=20 > Here is now it works: >=20 > If you see an problem and have a solution: go fix it. Many will be > grateful. > If you can't fix it, but have an idea how to fix it, share it. May will= > be grateful. > If you can't fix it and don't have any idea, just say "there is a > problem" and stop there. There are many, many, many like you who just > hold their breath. >=20 > We all learn, every day. >=20 > Daniel Sorry, but your crap is simply breathtaking. oh --------------enig863C2B495A6AA626DD82D833 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO9eZdAAoJEOgBcD7A/5N83ZwH/RTlnilxJOS4sBMpXduNFg/e LMRsokn+5zwp1EhqNg5HLPSJZbNq3DWm2IrutrPoRBOMAmUt2AYrxnxNu+9sSJwh r7Fvq+1i86sd+B28ngfmV3Xn+Kj7mB72gvxpUt1vlVGkb6viriBlwhG5tEUOwhS/ iSzcBQnEJbmjWnDOv2St1Up0ZV7jrLWW6n9ShUJnl7Nt76InhzQFGdB3YddUYWXX c0sqSzt7Y3y2DFFe5ZuRtyN/Xr2aAgEONhxnig10/ufh5gVWc/7DqGGUuY9zhwmF E6FQ7QPjSYq83aD9aKkKRD+nwenaX4gvsYCAyJUbpA5lIyrVcFk+UADIXC7JdJc= =q9EX -----END PGP SIGNATURE----- --------------enig863C2B495A6AA626DD82D833-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 15:43:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 557321065675; Sat, 24 Dec 2011 15:43:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EA28C8FC14; Sat, 24 Dec 2011 15:43:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBOFhpmf037640; Sat, 24 Dec 2011 10:43:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBOFhpF0037639; Sat, 24 Dec 2011 15:43:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Dec 2011 15:43:51 GMT Message-Id: <201112241543.pBOFhpF0037639@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 15:43:53 -0000 TB --- 2011-12-24 13:54:50 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 13:54:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-12-24 13:54:50 - cleaning the object tree TB --- 2011-12-24 13:55:13 - cvsupping the source tree TB --- 2011-12-24 13:55:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-12-24 13:55:26 - building world TB --- 2011-12-24 13:55:26 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 13:55:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 13:55:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 13:55:26 - SRCCONF=/dev/null TB --- 2011-12-24 13:55:26 - TARGET=powerpc TB --- 2011-12-24 13:55:26 - TARGET_ARCH=powerpc64 TB --- 2011-12-24 13:55:26 - TZ=UTC TB --- 2011-12-24 13:55:26 - __MAKE_CONF=/dev/null TB --- 2011-12-24 13:55:26 - cd /src TB --- 2011-12-24 13:55:26 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 24 13:55:27 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rsyncfile.o:(.text+0xf8): undefined reference to `MD5Update' stream.o:(.text+0x544): undefined reference to `MD5Init' stream.o:(.text+0xb9c): undefined reference to `MD5Update' stream.o:(.text+0xd0c): undefined reference to `MD5Update' stream.o:(.text+0xd40): undefined reference to `MD5Update' stream.o:(.text+0xd54): undefined reference to `MD5Update' stream.o:(.text+0xd84): undefined reference to `MD5Update' stream.o:(.text+0xd98): more undefined references to `MD5Update' follow *** Error code 1 Stop in /src/usr.bin/csup. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-24 15:43:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-24 15:43:51 - ERROR: failed to build world TB --- 2011-12-24 15:43:51 - 5356.41 user 909.12 system 6540.47 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 15:04:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5B02106566C for ; Sat, 24 Dec 2011 15:04:33 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 715EC8FC18 for ; Sat, 24 Dec 2011 15:04:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1ReT9E-0004wA-HP>; Sat, 24 Dec 2011 16:04:32 +0100 Received: from e178017174.adsl.alicedsl.de ([85.178.17.174] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1ReT9E-0006tl-Cb>; Sat, 24 Dec 2011 16:04:32 +0100 Message-ID: <4EF5E9FF.2020300@mail.zedat.fu-berlin.de> Date: Sat, 24 Dec 2011 16:04:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Alexander Best References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> <20111223114424.GA60815@freebsd.org> In-Reply-To: <20111223114424.GA60815@freebsd.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig133FBDE62B2C1BF2664C746E" X-Originating-IP: 85.178.17.174 X-Mailman-Approved-At: Sat, 24 Dec 2011 16:14:17 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 15:04:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig133FBDE62B2C1BF2664C746E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/23/11 12:44, Alexander Best wrote: [...] >> Many suggested that the Linux binaries be run via the FreeBSD Linux=20 >> emulation. Unchanged. >> There is one problem here though, the emulation is still 32 bit. >=20 > plus the current emulation layer is far from complete. a lot of stuff h= asn't > been implemented yet (meaning it's missing or implemented as dummy code= ). >=20 > try running recent firefox linux binaries on freebsd. they will all cra= sh > almost instantly. >=20 > cheers. > alex >=20 [...] Sometimes I'm glad to have the Linuxulator, for instance using Mathematica or an older 32bit IDL or even MATLAB. But lately, I run into problems on more recent platforms like FreeBSD 9 and 10. There maybe serious reasons having the Linuxulator, i do not know. But if not, why spending rare developer resources on that? As far as I'm concerned, the only real reason having the Linuxulator is some stuff from Adobe for desktop systems, Flash. That's it. For the scientific stuff, I try to move my people towards OpenSource, since we do "standard" stuff and I expect students and scientists solving problems without fancy coloured clicky funny things. In "production", this might be another point of view. SciLab from INRIA is great, MuPAD, MAXIMA also. But is there a real need running the Linux binary of Forefox on FreeBSD? Regards, Oliver --------------enig133FBDE62B2C1BF2664C746E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO9en/AAoJEOgBcD7A/5N8GwwIAIl5W7/ayoJ+SaVnppODyWxi R5/yVp8Zlro5jTO7iZB4bxWcij/PZ6d7ZPqc+1hcehj+4tXxyoCvwa5MuxLSnZC5 +gNCVgKkSLy8K3pcl386T4GNg65jrT3KPTahyJ+u2+bHP3jkPhL3ecRmoa4df5Ci H3PAxWZDwF29UAAPbi1/6Nx61O1cHlN8+1eSQ0NwTObV31y9CTkbx1RbFTuieYP6 kMuAd5ifa5tbkOkZwUjNktLPOQsVClGN0kt7K8FYPBeJeCL/JpyiYH17anvxRbOA x//JlDs5xMV0ZL7AQWYlwcTvCAmAHJot6CgnZBzuaRTOD6+HipPnAbFXfH8Y9zY= =tjCR -----END PGP SIGNATURE----- --------------enig133FBDE62B2C1BF2664C746E-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 16:04:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6AC4106564A for ; Sat, 24 Dec 2011 16:04:14 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by mx1.freebsd.org (Postfix) with SMTP id 98BEC8FC0A for ; Sat, 24 Dec 2011 16:04:14 +0000 (UTC) Received: from [98.139.91.68] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 24 Dec 2011 15:50:29 -0000 Received: from [98.139.91.45] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 24 Dec 2011 15:50:29 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 24 Dec 2011 15:50:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 118211.63019.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 22728 invoked by uid 60001); 24 Dec 2011 15:50:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1324741828; bh=j3TWe36xPBLNgFQ5HV5uDBsd47Imi3tO9FEDxaUkpPY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q7hdejNxW75TVk9LD1A5KnCZ5OpLJCLppXX8fNG4D5bx0mv0Vqmn2C/225NeH5E4zT2bswMoJqTn4dmLfK/ku8UVyxTWJiTfwTFyIOsxqAapR7cnQX/G9L3ESStrF/Xj9E0OzBIjI81I51Q9ZC7dR0FGyifvLs6tio4KLQfcTNw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QjOqs0ohqYeJ7nMHZf3ZBRidTzHtEb/cIC/dO/MvSLA/0KWaI8zq69U8JWHpb2dBp1HlbeqSmwYO903BaG7oQ7fav0BdRj5QyX8IjT3sRSIX7GqV/f7L/PSEzESjwgSftiTzotWhGgFtNCRQ0iNDsS/2WFK9xxd0KwupIWtkG8E=; X-YMail-OSG: sWX64ZsVM1lEaGbBMTgnjWXYrJ.FSFHBA.Hd5G9KUmt4WQ0 vxpa6FZM5_EXk9IMG3xs7YaKPjVDQ32uDKmJUPQ6.G8MFPHOjaLof2e9wiZr Bki8PuBocAwd.KjVWu2g.8nJNiqrkmCwdEMszr9Pi6G9RudKGgx18zzIRFLV hHDFmQ0u4UKvEQrVj7lSqhdfrIc_CSu.ycixrGFx3QGNgu25dw19zuKuUMOc iVSoPuxEQCGuKkIjAKL3QJJsU9tIysLasJQfll_Mlrd1y5XRhCFZVaQN0raY 4HtU.qOCpuHgTPg2Ufe75Vti.KaNDaQOKfFLt9CRjBtVE4u.Wwn8uYnk80ac LDZnlhekUORLz4__px6xBC84wcgTOFZl5vTVPBZmiapXx7lgP2VcoF_r25Kl Uq_s49j_1NBvnHhNHcYhA.AgHjOqL50UubGUsaFTa2DnWnmfz7.Pz Received: from [72.70.55.190] by web110503.mail.gq1.yahoo.com via HTTP; Sat, 24 Dec 2011 07:50:28 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <4EF25468.9040204@gmail.com> <4EF2C613.3020609@digsys.bg> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF45C85.9010709@mail.zedat.fu-berlin.de> <4EF46829.6010508@digsys.bg> <4EF5E65C.3060405@mail.zedat.fu-berlin.de> Message-ID: <1324741828.2235.YahooMailNeo@web110503.mail.gq1.yahoo.com> Date: Sat, 24 Dec 2011 07:50:28 -0800 (PST) From: Paul Pathiakis To: "O. Hartmann" , Daniel Kalchev In-Reply-To: <4EF5E65C.3060405@mail.zedat.fu-berlin.de> MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 24 Dec 2011 16:21:35 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Martin Sugioarto , "freebsd-current@FreeBSD.ORG" , Igor Mozolevsky , "freebsd-performance@FreeBSD.ORG" , "O. Hartmann" , "Daniel@FreeBSD.ORG" Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Pathiakis List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 16:04:15 -0000 Hi,=0A=0AWell, I don't chime in, usually.=A0 However, enough is enough.=A0 = There are many merits to both *BSD and Linux.=A0 I don't agree with benchma= rks that slant either way, as I'm sure people in both camps will agree.=A0 = Please be adult and just agree to disagree.=A0 Technology applicable to the= problem at hand is the only useful thing that we should all agree on.=A0 P= ersonally, I don't care if it's BSD, a Linux-variant or even Windoze if it = solves the problem.=A0 So, if you would all look at all the time spent vent= ing on this idiocy as time that could have been spent coding, debugging, et= c, think how much time was wasted from people just reading these e-mails.= =A0 (Yes, I do and this was an absolute waste of my time.)=A0 So, if the co= mmunication on the thread was nearly as much going to development and findi= ng issues or the causes of the issues, maybe a scheduler problem would be t= racked down, maybe a benchmark issue would be tracked down.=A0 Maybe people= will stop using RC's versus releases, I don't know.=A0 I really don't care.=A0 Just = please stop with finger pointing and being disgruntled and indignant.=A0 FO= CUS!!=0A=0AI'd love to say something like "Can't we all just get along" but= we are just so polar in our beliefs, I don't see it happening.=A0 Just dro= p it.=A0 If you have something constructive to say, spin off this thread an= d let the primary thread just die.=A0 (It should have a week ago.)=A0 Solve= the benchmarking issue, solve the scheduler issue, just focus.=0A=0APaul P= .=0ACTO/Owner =0A=0AAtlantis Services=0A=0A"Civilized Computing"=0A=0A=0A__= ______________________________=0A From: O. Hartmann =0ATo: Daniel Kalchev =0ACc: Martin Sugioarto= ; freebsd-current@FreeBSD.ORG; Igor Mozolevsky ; freebsd-performance@FreeBSD.ORG; O. Hartmann ; Daniel@FreeBSD.ORG =0ASent: Saturday, December 24, 201= 1 9:49 AM=0ASubject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle L= inux 6.1 Server=0A =0AOn 12/23/11 12:38, Daniel Kalchev wrote:=0A> =0A> =0A= > On 23.12.11 12:48, O. Hartmann wrote:=0A>> Look at Steve Kargls problem. = He investigated a SCHED_ULE problem in a=0A>> way that is far beyond enough= ! He gave tests, insights of his setup,=0A>> bad performance compared to SC= HED_4BSD and what happend? We are still=0A>> stuck with this problem and mo= re and more people realise, that FreeBSD=0A>> does have somewhere a problem= and this seems to be a nasty problem not=0A>> easy to find or investigate.= =0A> =0A> This has made me to realize, that I was having a problem with SCH= ED_ULE=0A> that I was not aware of until now. WOW! :)=0A> =0A> Every schedu= ler has some problem, some fail here some fail there. I am=0A> confident, t= hat the case that Steve Kargls has reported will be resolved.=0A> =0A>> Ano= ther problem is this very elite-feeling closed club. Once you=0A>> managed = it getting into the club of committers or core team members,=0A>> you'll pr= obably fight for your seat ... I dont propose for that=0A>> socialists crap= Linux people tend to be like,=0A> [..]=0A> =0A> You never heard of the "Pe= ople's Republic of Berkeley"? :)=0A> =0A> As for commiter access, this sort= of comments trigger the system=0A> administrator in me. I have seen enough= people, who for the lack of=0A> other excuses always use "but I don't have= enough RIGHTS!". I am evil, I=0A> know....=0A> =0A>> But I follow the illu= sion that if people can see what benchmarks=0A>> reveal, they start thinkin= g and if the facts are starting to give a=0A>> heavy load load on those rej= ecting the facts, they migght change their=0A>> opinion or get hopefully re= placed by more openminded people.=0A> =0A> Here is now it works:=0A> =0A> I= f you see an problem and have a solution: go fix it. Many will be=0A> grate= ful.=0A> If you can't fix it, but have an idea how to fix it, share it. May= will=0A> be grateful.=0A> If you can't fix it and don't have any idea, jus= t say "there is a=0A> problem" and stop there. There are many, many, many l= ike you who just=0A> hold their breath.=0A> =0A> We all learn, every day.= =0A> =0A> Daniel=0A=0ASorry, but your crap is simply breathtaking.=0A=0Aoh From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 17:35:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9F0106564A; Sat, 24 Dec 2011 17:35:01 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6858FC0A; Sat, 24 Dec 2011 17:35:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id DA6B42041B4; Sat, 24 Dec 2011 18:17:34 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPKY7HZvpYXq; Sat, 24 Dec 2011 18:17:29 +0100 (CET) Received: from [192.168.48.66] (unknown [216.99.50.73]) by smtp.infotech.no (Postfix) with ESMTPA id 3D507204189; Sat, 24 Dec 2011 18:17:27 +0100 (CET) Message-ID: <4EF60926.7030204@interlog.com> Date: Sat, 24 Dec 2011 12:17:26 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Motin References: <4EF5E134.9040903@FreeBSD.org> In-Reply-To: <4EF5E134.9040903@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 24 Dec 2011 17:56:28 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: SCSI UNMAP (TRIM) support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgilbert@interlog.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 17:35:02 -0000 On 11-12-24 09:27 AM, Alexander Motin wrote: > Hi. > > I've implemented patch for logical block provisioning (aka UNMAP, TRIM, > BIO_DELETE) support for the CAM da driver in HEAD and would like to ask for > review, testing and hardware support information. > > Depending on device capabilities I use several different methods to implement > it. Method can be read/set via kern.cam.da.X.delete_method sysctls. Possible > values are: > NONE - no provisioning support reported by the device; > DISABLE - provisioning support was disabled because of errors; > ZERO - use WRITE SAME (10) command to write zeroes; > WS10 - use WRITE SAME (10) command with UNMAP bit set; > WS16 - use WRITE SAME (16) command with UNMAP bit set; > UNMAP - use UNMAP command. > Last two methods (UNMAP and WS16) are defined by SBC specification and UNMAP > method is the most advanced one. The rest of methods I've found supported in > Linux, and as soon as they were trivial to implement, then why not? Hope they > will be useful in some cases. > > Unluckily at this moment I have no devices reporting parameters of the logical > block provisioning support via respective VPD pages (0xB0 and 0xB2). So all info > I have/use now is the flag telling whether logical block provisioning is > supported or not. As result specific methods chosen now by trying different ones > in order (UNMAP, WS16, DISABLE) and checking completion status to fallback if > needed. I don't expect problems from this, as if something go wrong, it should > just disable itself. It may disable even too aggressively. > > Unlike Linux, which executes each delete with separate request, I've implemented > here the same request aggregation as implemented in ada driver. Tests on SSDs I > have show much better results doing it this way: above 8GB/s of the linear > delete on Intel SATA SSD on LSI SAS HBA (mps). > > The patch can be found here: > http://people.freebsd.org/~mav/scsi_unmap.patch > > Work sponsored by iXsystems, Inc. > > If somebody has SAS SSDs with UNMAP support, I would be grateful for additional > information about them, such as: > camcontrol cmd da0 -c "12 01 00 00 ff 00" -i 255 - >pages > camcontrol cmd da0 -c "12 01 b0 00 ff 00" -i 255 - >page_b0 > camcontrol cmd da0 -c "12 01 b2 00 ff 00" -i 255 - >page_b2 > camcontrol cmd da0 -c "9e 10 00 00 00 00 00 00 00 00 00 00 00 ff 00 00" -i 255 - > >rc16 You might find my sg3_utils package useful. It builds on FreeBSD and contains sg_vpd, sg_readcap and sg_unmap which may be more convenient than "bit-banging" through 'camcontrol cmd'. See: http://sg.danny.cz/sg/sg3_utils.html The above sequence would be: sg_vpd /dev/da0 sg_vpd -p 0xb0 /dev/da0 sg_vpd -p 0xb2 /dev/da0 sg_readcap -l /dev/da0 If you want the response in hex rather than decoded, add a '-H' option (for binary add a '-r' option). In Linux we can test the SCSI UNMAP command against SATA SSDs due to the SATL inside libata. It is actually a lousy SATL, LSI have a much better one in firmware in their MPT Fusion SAS-2 HBAs (but I think "IT" rather than "IR" firmware may be needed). True SAS SSDs are a bit thin on the ground. Hopefully more will emerge with SAS-3 (12 Gbps) and perhaps using the dual phys on a standard SAS disk connector as a single port: more bandwidth, less redundancy. Doug Gilbert From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 18:32:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9CB0106566B; Sat, 24 Dec 2011 18:32:16 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCE48FC0A; Sat, 24 Dec 2011 18:32:16 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id pBOILD82050540; Sat, 24 Dec 2011 19:21:13 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id pBOILDuG050539; Sat, 24 Dec 2011 19:21:13 +0100 (CET) (envelope-from marius) Date: Sat, 24 Dec 2011 19:21:13 +0100 From: Marius Strobl To: FreeBSD Tinderbox Message-ID: <20111224182112.GA50370@alchemy.franken.de> References: <201112241543.pBOFhpF0037639@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112241543.pBOFhpF0037639@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: powerpc64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 18:32:17 -0000 On Sat, Dec 24, 2011 at 03:43:51PM +0000, FreeBSD Tinderbox wrote: > TB --- 2011-12-24 13:54:50 - tinderbox 2.8 running on freebsd-current.sentex.ca > TB --- 2011-12-24 13:54:50 - starting HEAD tinderbox run for powerpc64/powerpc > TB --- 2011-12-24 13:54:50 - cleaning the object tree > TB --- 2011-12-24 13:55:13 - cvsupping the source tree > TB --- 2011-12-24 13:55:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile > TB --- 2011-12-24 13:55:26 - building world > TB --- 2011-12-24 13:55:26 - CROSS_BUILD_TESTING=YES > TB --- 2011-12-24 13:55:26 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-12-24 13:55:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-12-24 13:55:26 - SRCCONF=/dev/null > TB --- 2011-12-24 13:55:26 - TARGET=powerpc > TB --- 2011-12-24 13:55:26 - TARGET_ARCH=powerpc64 > TB --- 2011-12-24 13:55:26 - TZ=UTC > TB --- 2011-12-24 13:55:26 - __MAKE_CONF=/dev/null > TB --- 2011-12-24 13:55:26 - cd /src > TB --- 2011-12-24 13:55:26 - /usr/bin/make -B buildworld > >>> World build started on Sat Dec 24 13:55:27 UTC 2011 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > rsyncfile.o:(.text+0xf8): undefined reference to `MD5Update' > stream.o:(.text+0x544): undefined reference to `MD5Init' > stream.o:(.text+0xb9c): undefined reference to `MD5Update' > stream.o:(.text+0xd0c): undefined reference to `MD5Update' > stream.o:(.text+0xd40): undefined reference to `MD5Update' > stream.o:(.text+0xd54): undefined reference to `MD5Update' > stream.o:(.text+0xd84): undefined reference to `MD5Update' > stream.o:(.text+0xd98): more undefined references to `MD5Update' follow > *** Error code 1 > The tinderbox output isn't very helpful here and I've no idea how this could happen as r228857 also added -lmd nor can I reproduce it. Could this be a transient failure due to the tinderbox updating sources at an unfortunate point in time or a glitch in the exported (according to the sources presented by cvsweb.freebsd.org r228857 has reached the CVS repository just fine though)? Marius From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 23:45:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64E99106566B; Sat, 24 Dec 2011 23:45:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F04708FC08; Sat, 24 Dec 2011 23:45:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBONjiAV008412; Sat, 24 Dec 2011 18:45:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBONjh5K008411; Sat, 24 Dec 2011 23:45:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Dec 2011 23:45:44 GMT Message-Id: <201112242345.pBONjh5K008411@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 23:45:45 -0000 TB --- 2011-12-24 21:13:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 21:13:44 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-12-24 21:13:44 - cleaning the object tree TB --- 2011-12-24 21:13:56 - cvsupping the source tree TB --- 2011-12-24 21:13:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-12-24 21:14:08 - building world TB --- 2011-12-24 21:14:08 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 21:14:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 21:14:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 21:14:08 - SRCCONF=/dev/null TB --- 2011-12-24 21:14:08 - TARGET=powerpc TB --- 2011-12-24 21:14:08 - TARGET_ARCH=powerpc64 TB --- 2011-12-24 21:14:08 - TZ=UTC TB --- 2011-12-24 21:14:08 - __MAKE_CONF=/dev/null TB --- 2011-12-24 21:14:08 - cd /src TB --- 2011-12-24 21:14:08 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 24 21:14:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Dec 24 23:35:25 UTC 2011 TB --- 2011-12-24 23:35:25 - generating LINT kernel config TB --- 2011-12-24 23:35:25 - cd /src/sys/powerpc/conf TB --- 2011-12-24 23:35:25 - /usr/bin/make -B LINT TB --- 2011-12-24 23:35:25 - cd /src/sys/powerpc/conf TB --- 2011-12-24 23:35:25 - /usr/sbin/config -m LINT TB --- 2011-12-24 23:35:25 - building LINT kernel TB --- 2011-12-24 23:35:25 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 23:35:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 23:35:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 23:35:25 - SRCCONF=/dev/null TB --- 2011-12-24 23:35:25 - TARGET=powerpc TB --- 2011-12-24 23:35:25 - TARGET_ARCH=powerpc64 TB --- 2011-12-24 23:35:25 - TZ=UTC TB --- 2011-12-24 23:35:25 - __MAKE_CONF=/dev/null TB --- 2011-12-24 23:35:25 - cd /src TB --- 2011-12-24 23:35:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 24 23:35:25 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/fb/fb.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/hwpmc/hwpmc_powerpc.c /src/sys/dev/hwpmc/hwpmc_powerpc.c: In function 'powerpc_intr': /src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'AMD_PMC_ENABLE' undeclared (first use in this function) /src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: (Each undeclared identifier is reported only once /src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: for each function it appears in.) /src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'union pmc_md_pmc' has no member named 'pm_amd' /src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'union pmc_md_pmc' has no member named 'pm_amd' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-24 23:45:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-24 23:45:43 - ERROR: failed to build LINT kernel TB --- 2011-12-24 23:45:43 - 7497.27 user 1367.80 system 9118.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full