From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 17 21:37:28 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C1FC106564A for ; Sun, 17 Oct 2010 21:37:28 +0000 (UTC) (envelope-from stesin@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA4E8FC08 for ; Sun, 17 Oct 2010 21:37:27 +0000 (UTC) Received: by ewy21 with SMTP id 21so203458ewy.13 for ; Sun, 17 Oct 2010 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=98tNe52ww606HIFNPaMqW2f3hJGFDZLQzFFC6oNDh9Y=; b=U2tqS1xx1ytEjpwFu4Clpw81owP5OwCV2vxJKSQiDRPh7OnerEqdm+Rpud7N8yDaLR 4tIpBB1xATpdqD26kgUVGNjOsRmYHVpHZIjEQtXoY30hHE0bFfTLXG3bQBl8spO7AcOr qpLMPllEZ37hl8nUwd6BlO0OooyzYnZTfpy1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ug7951lYS/jq/OS6TGOGAHrTTEwJXt1Ie+5rQURZgjBoltR48zl9LrGV/D7wiMwVp4 4j83WRshj2QdnIYbVKVm9BVU44WolNtFwH1gud0MH6SufTi9XZkUYkNY7+tz11CAQzBP QgWpRtk8veL8i09CnOQMgFq5Cj7aiYiBuCxXA= MIME-Version: 1.0 Received: by 10.213.48.131 with SMTP id r3mr2713703ebf.69.1287349621708; Sun, 17 Oct 2010 14:07:01 -0700 (PDT) Received: by 10.14.37.78 with HTTP; Sun, 17 Oct 2010 14:07:01 -0700 (PDT) In-Reply-To: <201010151412.o9FECJN5053082@fire.js.berklix.net> References: <201010151412.o9FECJN5053082@fire.js.berklix.net> Date: Mon, 18 Oct 2010 00:07:01 +0300 Message-ID: From: Andrew Stesin To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: international crypto laws X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 21:37:28 -0000 I think this is reasonable. WBR, Andrew 2010/10/15 Julian H. Stacey : > To quote 8.1-RELEASE/src/crypto/README > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > =C2=A0 =C2=A0 =C2=A0 =C2=A0The separation between src/contrib and src/cry= pto > =C2=A0 =C2=A0 =C2=A0 =C2=A0is the result of an old USA law, which made th= ese sources export > =C2=A0 =C2=A0 =C2=A0 =C2=A0controlled, so they had to be kept separate. > > As international crypto laws are ever changing play things of > ignorant politicians, & a pain in the orifice to track, & as FreeBSD > is an international project, it's not just USA law that can be problemati= c. > > We could outsource disinterest in the wold's mess of crypto laws, > by adding a URL to this: > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://rechten.uvt.nl/koops/cryptolaw/ > =C2=A0 =C2=A0 =C2=A0 =C2=A0Crypto Law Survey indexed by country > > Cheers, > Julian > -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix= .com > =C2=A0Mail plain text; =C2=A0Not HTML, quoted-printable & base 64 spam fo= rmats. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Top posting cripples itemised cumulative respo= nses. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 10:46:29 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036D9106564A for ; Mon, 18 Oct 2010 10:46:29 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2868FC12 for ; Mon, 18 Oct 2010 10:46:27 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9IARLUh078240 for ; Mon, 18 Oct 2010 17:27:21 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4CBC2109.4030303@grosbein.pp.ru> Date: Mon, 18 Oct 2010 17:27:21 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 10:46:29 -0000 Hi! I've written an utility in C that does not link libc normally, instead it includes and calls syscall(). It works nice for FreeBSD8/i386. Now I'm porting it to FreeBSD8/amd64 and just cannot find how to call syscall() directly from C code. For arm, i386 and mips there are: lib/libc/arm/sys/syscall.S lib/libc/i386/sys/syscall.S lib/libc/mips/sys/syscall.S What about amd64? Eugene Grosbein P.S. Please reply to the list. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:11:36 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C48410656EA for ; Mon, 18 Oct 2010 11:11:36 +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 B44D08FC1E for ; Mon, 18 Oct 2010 11:11:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9IBBV8G049561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Oct 2010 14:11:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9IBBVBn078402; Mon, 18 Oct 2010 14:11:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9IBBV4o078401; Mon, 18 Oct 2010 14:11:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Oct 2010 14:11:31 +0300 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20101018111131.GE2392@deviant.kiev.zoral.com.ua> References: <4CBC2109.4030303@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uY1I3j4UW8kglp2S" Content-Disposition: inline In-Reply-To: <4CBC2109.4030303@grosbein.pp.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:11:36 -0000 --uY1I3j4UW8kglp2S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 18, 2010 at 05:27:21PM +0700, Eugene Grosbein wrote: > Hi! >=20 > I've written an utility in C that does not link libc normally, > instead it includes and calls syscall(). > It works nice for FreeBSD8/i386. >=20 > Now I'm porting it to FreeBSD8/amd64 and just cannot find > how to call syscall() directly from C code. Show what you tried to do. Syscall() at the C-level works the same (well, almost, but the differences are too subtle for this discussion) for all architectures. >=20 > For arm, i386 and mips there are: >=20 > lib/libc/arm/sys/syscall.S > lib/libc/i386/sys/syscall.S > lib/libc/mips/sys/syscall.S amd64 syscall() wrapper code is autogenerated. >=20 > What about amd64? Indeed, what is your issue with amd64 ? >=20 > Eugene Grosbein >=20 > P.S. Please reply to the list. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --uY1I3j4UW8kglp2S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAky8K2MACgkQC3+MBN1Mb4golQCgnlIWsqHLxukhcm5sD/9OPdmz 7iQAoIC1L5q0Rzd14/eRDRLukbzoXG9q =yGkH -----END PGP SIGNATURE----- --uY1I3j4UW8kglp2S-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:32:56 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715371065696 for ; Mon, 18 Oct 2010 11:32:56 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id B44F98FC18 for ; Mon, 18 Oct 2010 11:32:54 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9IBWpMm078560; Mon, 18 Oct 2010 18:32:52 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4CBC3063.7000407@grosbein.pp.ru> Date: Mon, 18 Oct 2010 18:32:51 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kostik Belousov References: <4CBC2109.4030303@grosbein.pp.ru> <20101018111131.GE2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101018111131.GE2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:32:56 -0000 On 18.10.2010 18:11, Kostik Belousov wrote: > On Mon, Oct 18, 2010 at 05:27:21PM +0700, Eugene Grosbein wrote: >> Hi! >> >> I've written an utility in C that does not link libc normally, >> instead it includes and calls syscall(). >> It works nice for FreeBSD8/i386. >> >> Now I'm porting it to FreeBSD8/amd64 and just cannot find >> how to call syscall() directly from C code. > Show what you tried to do. Syscall() at the C-level works the same > (well, almost, but the differences are too subtle for this discussion) > for all architectures. I'm prepearing a binary that would start before /sbin/init to make just a couple of ioctl(MDIOCATTACH)/nmount system calls then execve(/sbin/init). It has to be small in size for NanoBSD build. Detailed explanation (in russian) and source code are available here: http://dadv.livejournal.com/105161.html In short: #include #define MESG "Hello, world!\n" #define MESG_SZ sizeof(MESG)-1 int syscall(const int n, ...); #define _exit(a) syscall(SYS_exit, a) #define write(a, b, c) syscall(SYS_write, a, b, c) int errno; int main() { write(1,MESG,MESG_SZ); _exit(0); return 0; /* make compiler happy */ } >> For arm, i386 and mips there are: >> >> lib/libc/arm/sys/syscall.S >> lib/libc/i386/sys/syscall.S >> lib/libc/mips/sys/syscall.S > amd64 syscall() wrapper code is autogenerated. > >> >> What about amd64? > Indeed, what is your issue with amd64 ? I cannot find a module to link with to resolve syscall() symbol when I do not want to link with libc. Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:38:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E7A1065696; Mon, 18 Oct 2010 11:38:38 +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 AF6FB8FC15; Mon, 18 Oct 2010 11:38:37 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C7AE71FFC34; Mon, 18 Oct 2010 11:38:36 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 943798454C; Mon, 18 Oct 2010 13:33:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> <8662zg586z.fsf@ds4.des.no> Date: Mon, 18 Oct 2010 13:33:56 +0200 In-Reply-To: (Garrett Cooper's message of "Sat, 16 Oct 2010 16:16:19 -0700") Message-ID: <8662wz4twb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:38:38 -0000 Garrett Cooper writes: > PS I added uquad_t for consistency in the APIs, even though quad_t was > deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I > should have done that). You should bump __FreeBSD_version__ anyway so third-party or shared code can use the new API if it is available and the old one if it isn't. > Let's try with the patch attached... Mailman strips binary attachments. The correct MIME type is text/x-patch. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:41:24 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ECD01065746 for ; Mon, 18 Oct 2010 11:41:24 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 72EEF8FC08 for ; Mon, 18 Oct 2010 11:41:22 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9IBfLGx078613; Mon, 18 Oct 2010 18:41:21 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4CBC3261.8040308@grosbein.pp.ru> Date: Mon, 18 Oct 2010 18:41:21 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kostik Belousov References: <4CBC2109.4030303@grosbein.pp.ru> <20101018111131.GE2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101018111131.GE2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:41:24 -0000 On 18.10.2010 18:11, Kostik Belousov wrote: >> For arm, i386 and mips there are: >> >> lib/libc/arm/sys/syscall.S >> lib/libc/i386/sys/syscall.S >> lib/libc/mips/sys/syscall.S > amd64 syscall() wrapper code is autogenerated. It seems, it's written here: # less /usr/obj/usr/src/lib/libc/syscall.S #include "compat.h" #include "SYS.h" RSYSCALL(syscall) Well, I can just copy there three lines to ./syscall.S and add the file to gcc command line. Thanks. Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:49:39 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 309DD1065675 for ; Mon, 18 Oct 2010 11:49:39 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6E80B8FC21 for ; Mon, 18 Oct 2010 11:49:38 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9IBnaLo078660; Mon, 18 Oct 2010 18:49:36 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4CBC3450.5020503@grosbein.pp.ru> Date: Mon, 18 Oct 2010 18:49:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Garrett Cooper References: <4CBC2109.4030303@grosbein.pp.ru> <20101018111131.GE2392@deviant.kiev.zoral.com.ua> <4CBC3063.7000407@grosbein.pp.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , hackers@FreeBSD.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:49:39 -0000 On 18.10.2010 18:41, Garrett Cooper wrote: > Official work similar to this was just committed yesterday at SVN r214006. > Cheers, > -Garrett Thanks, interesting. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 11:55:18 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45C53106566B for ; Mon, 18 Oct 2010 11:55: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 B1E198FC0C for ; Mon, 18 Oct 2010 11:55:17 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9IBst3W053296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Oct 2010 14:54:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9IBstZn076772; Mon, 18 Oct 2010 14:54:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9IBstts076771; Mon, 18 Oct 2010 14:54:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Oct 2010 14:54:55 +0300 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20101018115455.GH2392@deviant.kiev.zoral.com.ua> References: <4CBC2109.4030303@grosbein.pp.ru> <20101018111131.GE2392@deviant.kiev.zoral.com.ua> <4CBC3261.8040308@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJ1PC0yZrEAstpRC" Content-Disposition: inline In-Reply-To: <4CBC3261.8040308@grosbein.pp.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:55:18 -0000 --qJ1PC0yZrEAstpRC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 18, 2010 at 06:41:21PM +0700, Eugene Grosbein wrote: > On 18.10.2010 18:11, Kostik Belousov wrote: >=20 > >> For arm, i386 and mips there are: > >> > >> lib/libc/arm/sys/syscall.S > >> lib/libc/i386/sys/syscall.S > >> lib/libc/mips/sys/syscall.S > > amd64 syscall() wrapper code is autogenerated. >=20 > It seems, it's written here: >=20 > # less /usr/obj/usr/src/lib/libc/syscall.S > #include "compat.h" > #include "SYS.h" > RSYSCALL(syscall) >=20 > Well, I can just copy there three lines to ./syscall.S > and add the file to gcc command line. I already told you that the syscall(2) wrapper is auto-generated on amd64. The official way to get it is to link with libc. --qJ1PC0yZrEAstpRC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAky8NY8ACgkQC3+MBN1Mb4gcnQCcCDrlNKgl54oLtOqjQf3N8oV8 xSIAn2cO+oOC5c93IEJKqiJIjDIU1O5u =ejry -----END PGP SIGNATURE----- --qJ1PC0yZrEAstpRC-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 12:08:39 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 817EC1065670 for ; Mon, 18 Oct 2010 12:08:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4D48FC18 for ; Mon, 18 Oct 2010 12:08:38 +0000 (UTC) Received: by iwn36 with SMTP id 36so663iwn.13 for ; Mon, 18 Oct 2010 05:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Fp5adbO3NHx7xw6w13phtMycMTkahho4Zc9A2m/yExk=; b=WmbcDc2YVZkwSVBP0hYR3+EZjgOAMvYptcksYdKCYxP3Nw799lgWqfR9D9YgrgE9VB CoGa1EpGR0fNGJMGslfr1xq1uK2EFN6v+zDNYjbTBzFYuBaDw1Q4YBUznGPg2Ujlo8Lm mZJ56iYVnpC+0LDcEomFoCSU+GeSEc26R7T6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D6W9cUKsttIRtG5MAhHi47hh8Gu/sjTVw2arTV80o6YETbzxp7gLaNZUStDCe1PXqw G3iC2b+r8hStlqFKnOnpgoOiD/v3VoZIcGsYx5/krZYhVcR1Xbp3EUrDzP7N7Yeq8rs1 roeY0I3OrLWyUev5s/QFrjwnM/dt8XAol52bY= MIME-Version: 1.0 Received: by 10.231.35.66 with SMTP id o2mr3144391ibd.30.1287402108931; Mon, 18 Oct 2010 04:41:48 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 18 Oct 2010 04:41:48 -0700 (PDT) In-Reply-To: <4CBC3063.7000407@grosbein.pp.ru> References: <4CBC2109.4030303@grosbein.pp.ru> <20101018111131.GE2392@deviant.kiev.zoral.com.ua> <4CBC3063.7000407@grosbein.pp.ru> Date: Mon, 18 Oct 2010 04:41:48 -0700 X-Google-Sender-Auth: 4K-56E7RE4SWB3wbtZ08xipFhpw Message-ID: From: Garrett Cooper To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , hackers@freebsd.org Subject: Re: syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:08:39 -0000 On Mon, Oct 18, 2010 at 4:32 AM, Eugene Grosbein wro= te: > On 18.10.2010 18:11, Kostik Belousov wrote: >> On Mon, Oct 18, 2010 at 05:27:21PM +0700, Eugene Grosbein wrote: >>> Hi! >>> >>> I've written an utility in C that does not link libc normally, >>> instead it includes and calls syscall(). >>> It works nice for FreeBSD8/i386. >>> >>> Now I'm porting it to FreeBSD8/amd64 and just cannot find >>> how to call syscall() directly from C code. >> Show what you tried to do. Syscall() at the C-level works the same >> (well, almost, but the differences are too subtle for this discussion) >> for all architectures. > > I'm prepearing a binary that would start before /sbin/init > to make just a couple of ioctl(MDIOCATTACH)/nmount system calls > then execve(/sbin/init). It has to be small in size for NanoBSD build. > Detailed explanation (in russian) and source code are available here: > http://dadv.livejournal.com/105161.html > > In short: > > #include > > #define MESG =A0 =A0"Hello, world!\n" > #define MESG_SZ sizeof(MESG)-1 > > int syscall(const int n, ...); > > #define _exit(a) =A0 =A0 =A0 syscall(SYS_exit, a) > #define write(a, b, c) syscall(SYS_write, a, b, c) > > int errno; > > int main() { > =A0write(1,MESG,MESG_SZ); > =A0_exit(0); > =A0return 0; /* make compiler happy */ > } > >>> For arm, i386 and mips there are: >>> >>> lib/libc/arm/sys/syscall.S >>> lib/libc/i386/sys/syscall.S >>> lib/libc/mips/sys/syscall.S >> amd64 syscall() wrapper code is autogenerated. >> >>> >>> What about amd64? >> Indeed, what is your issue with amd64 ? > > I cannot find a module to link with > to resolve syscall() symbol when I do not want to link with libc. Official work similar to this was just committed yesterday at SVN r2140= 06. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 15:59:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E06D7106566C; Mon, 18 Oct 2010 15:59:44 +0000 (UTC) Date: Mon, 18 Oct 2010 15:59:44 +0000 From: Alexander Best To: Oliver Fromme Message-ID: <20101018155944.GA12425@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201009161619.o8GGJAmv035378@lurza.secnetix.de> Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:59:45 -0000 On Thu Sep 16 10, Oliver Fromme wrote: > > Tijl Coosemans wrote: > > On Thursday 16 September 2010 16:10:22 Oliver Fromme wrote: > > > Tijl Coosemans wrote: > > > > I would just spin down the disk in case of a halt. An unwanted spin > > > > down is harmless compared to an emergency shutdown and usually the > > > > intention is to power off rather than reboot. > > > > > > Is it? When I intend to power-off, I use shutdown -p, not > > > shutdown -h. Quite often (but not always) when I halt a > > > machine, I'm going to reboot to multi-user, not power off. > > > > Hmm, I suppose support for power off is ubiquitous nowadays. It used to > > be that halt meant: bring the system in a state where we can safely cut > > the power. In that case it makes sense to let halt spin down the disks. > > If you intend to reboot why not explicitly reboot rather than halt? > > For example, I use shutdown -h in order to swap disks that > are not hot-swappable, or other kind of hardware work that > can be done while the machine is switched on. > > Of course, in that particular case the disk which is about > to be swapped out should be spun down, while the others > should not. But that's not a problem because I can use > atacontrol(8) and camcontrol(8) to spin down a specific > disk drive manually. > > > Also, to go from single to multi user mode you can just exit(1) the > > shell. > > Yes, of course, that's a different matter. > > I've updated the patch for ada(4). It includes a bug fix > (command1 vs. command2) and uses the howto flags passed to > the shutdown function. Thanks again for pointing these out. any chances of getting this one committed? although this only works for CAM(4) and not ATA(4) it seems the patch is doing the right thing: - only spindown the disk when the system shuts down - don't spin down hdds, if the user reboots since there seems no way to distinguish between these two states in ATA(4) it's probably better to leave it as it is, since doing spin downs upon reboot might be even worse than not doing spindowns upon shutdown. cheers. alex ps: also: most of the ATA(4) users under HEAD seem to use options ATA_CAM. ;) > > Best regards > Oliver > > > --- ata_da.c.orig 2010-05-23 18:16:33.000000000 +0200 > +++ ata_da.c 2010-09-16 17:21:10.000000000 +0200 > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > #include > #endif /* _KERNEL */ > > @@ -79,7 +80,8 @@ > ADA_FLAG_CAN_TRIM = 0x080, > ADA_FLAG_OPEN = 0x100, > ADA_FLAG_SCTX_INIT = 0x200, > - ADA_FLAG_CAN_CFA = 0x400 > + ADA_FLAG_CAN_CFA = 0x400, > + ADA_FLAG_CAN_POWERMGT = 0x800 > } ada_flags; > > typedef enum { > @@ -180,6 +182,10 @@ > #define ADA_DEFAULT_SEND_ORDERED 1 > #endif > > +#ifndef ADA_DEFAULT_SPINDOWN_SHUTDOWN > +#define ADA_DEFAULT_SPINDOWN_SHUTDOWN 1 > +#endif > + > /* > * Most platforms map firmware geometry to actual, but some don't. If > * not overridden, default to nothing. > @@ -191,6 +197,7 @@ > static int ada_retry_count = ADA_DEFAULT_RETRY; > static int ada_default_timeout = ADA_DEFAULT_TIMEOUT; > static int ada_send_ordered = ADA_DEFAULT_SEND_ORDERED; > +static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOWN_SHUTDOWN; > > SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0, > "CAM Direct Access Disk driver"); > @@ -203,6 +210,9 @@ > SYSCTL_INT(_kern_cam_ada, OID_AUTO, ada_send_ordered, CTLFLAG_RW, > &ada_send_ordered, 0, "Send Ordered Tags"); > TUNABLE_INT("kern.cam.ada.ada_send_ordered", &ada_send_ordered); > +SYSCTL_INT(_kern_cam_ada, OID_AUTO, spindown_shutdown, CTLFLAG_RW, > + &ada_spindown_shutdown, 0, "Spin down upon shutdown"); > +TUNABLE_INT("kern.cam.ada.spindown_shutdown", &ada_spindown_shutdown); > > /* > * ADA_ORDEREDTAG_INTERVAL determines how often, relative > @@ -665,6 +675,8 @@ > softc->flags |= ADA_FLAG_CAN_48BIT; > if (cgd->ident_data.support.command2 & ATA_SUPPORT_FLUSHCACHE) > softc->flags |= ADA_FLAG_CAN_FLUSHCACHE; > + if (cgd->ident_data.support.command1 & ATA_SUPPORT_POWERMGT) > + softc->flags |= ADA_FLAG_CAN_POWERMGT; > if (cgd->ident_data.satacapabilities & ATA_SUPPORT_NCQ && > cgd->inq_flags & SID_CmdQue) > softc->flags |= ADA_FLAG_CAN_NCQ; > @@ -1222,6 +1234,58 @@ > /*getcount_only*/0); > cam_periph_unlock(periph); > } > + > + if (ada_spindown_shutdown == 0 || > + (howto & (RB_HALT | RB_POWEROFF)) == 0) > + return; > + > + DELAY(500000); > + > + TAILQ_FOREACH(periph, &adadriver.units, unit_links) { > + union ccb ccb; > + > + /* If we paniced with lock held - not recurse here. */ > + if (cam_periph_owned(periph)) > + continue; > + cam_periph_lock(periph); > + softc = (struct ada_softc *)periph->softc; > + /* > + * We only spin-down the drive if it is capable of it.. > + */ > + if ((softc->flags & ADA_FLAG_CAN_POWERMGT) == 0) { > + cam_periph_unlock(periph); > + continue; > + } > + > + /* XXX Hide this behind bootverbose? */ > + xpt_print(periph->path, "spin-down\n"); > + > + xpt_setup_ccb(&ccb.ccb_h, periph->path, CAM_PRIORITY_NORMAL); > + > + ccb.ccb_h.ccb_state = ADA_CCB_DUMP; > + cam_fill_ataio(&ccb.ataio, > + 1, > + adadone, > + CAM_DIR_NONE, > + 0, > + NULL, > + 0, > + ada_default_timeout*1000); > + > + ata_28bit_cmd(&ccb.ataio, ATA_STANDBY_IMMEDIATE, 0, 0, 0); > + xpt_polled_action(&ccb); > + > + if ((ccb.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) > + xpt_print(periph->path, "Spin-down disk failed\n"); > + > + if ((ccb.ccb_h.status & CAM_DEV_QFRZN) != 0) > + cam_release_devq(ccb.ccb_h.path, > + /*relsim_flags*/0, > + /*reduction*/0, > + /*timeout*/0, > + /*getcount_only*/0); > + cam_periph_unlock(periph); > + } > } > > #endif /* _KERNEL */ > > > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "I have stopped reading Stephen King novels. > Now I just read C code instead." > -- Richard A. O'Keefe -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 20:33:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565201065672 for ; Mon, 18 Oct 2010 20:33:43 +0000 (UTC) (envelope-from jack@skysel.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B57B88FC14 for ; Mon, 18 Oct 2010 20:33:42 +0000 (UTC) Received: by wyb38 with SMTP id 38so1719359wyb.13 for ; Mon, 18 Oct 2010 13:33:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.28.77 with SMTP id f55mr5748181wea.91.1287432234479; Mon, 18 Oct 2010 13:03:54 -0700 (PDT) Received: by 10.216.54.84 with HTTP; Mon, 18 Oct 2010 13:03:54 -0700 (PDT) X-Originating-IP: [83.233.150.160] Date: Mon, 18 Oct 2010 22:03:54 +0200 Message-ID: From: Jack Engqvist Johansson To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Oct 2010 20:55:51 +0000 Subject: Cannot compile a custom FreeBSD kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:33:43 -0000 Hi, I have a HP tx2020eo laptop with FreeBSD 8.1 installed. I'm trying to recompile the kernel to get even better performance. The problem is that I get error when I compile. I've tried comment/uncomment lines in my kernel config file but I always get some of error. Could somebody have a look at my configuration? Laptop spec: http://h10025.www1.hp.com/ewfrf/wc/document?lc=3Den&cc=3Dus&docname=3Dc0130= 2377&dlc=3Den ---------------------------------------------------------------------------= --------------- Compilation: ... awk -f /usr/src/sys/conf/kmod_syms.awk ahc.ko.debug=A0 export_syms | xargs -J% objcopy % ahc.ko.debug objcopy --only-keep-debug ahc.ko.debug ahc.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dahc.ko.symbols ahc.ko.debug ahc= .ko =3D=3D=3D> aic7xxx/ahc/ahc_eisa (all) cc -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc=A0 -I/usr/src/sys/modules/aic7xxx/ahc/ahc_eisa/../../../../dev/ai= c7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NECTRUS/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/NECTRUS -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual=A0 -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/aic7xxx/ahc/ahc_eisa/../../../../dev/aic7xxx/ahc_eisa.= c ld=A0 -d -warn-common -r -d -o ahc_eisa.ko.debug ahc_eisa.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ahc_eisa.ko.debug=A0 export_syms | xargs -J% objcopy % ahc_eisa.ko.debug objcopy --only-keep-debug ahc_eisa.ko.debug ahc_eisa.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dahc_eisa.ko.symbols ahc_eisa.ko.debug ahc_eisa.ko =3D=3D=3D> aic7xxx/ahc/ahc_isa (all) cc -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc=A0 -I/usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic= 7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NECTRUS/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/NECTRUS -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual=A0 -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/aic7xxx/ahc/ahc_isa/../../../../dev/aic7xxx/ahc_isa.c ld=A0 -d -warn-common -r -d -o ahc_isa.ko.debug ahc_isa.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ahc_isa.ko.debug=A0 export_syms | xargs -J% objcopy % ahc_isa.ko.debug objcopy --only-keep-debug ahc_isa.ko.debug ahc_isa.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dahc_isa.ko.symbols ahc_isa.ko.debug ahc_isa.ko =3D=3D=3D> aic7xxx/ahc/ahc_pci (all) cc -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc=A0 -I/usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic= 7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NECTRUS/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/NECTRUS -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual=A0 -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/ahc_pci.c cc -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc=A0 -I/usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic= 7xxx -I.. -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NECTRUS/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/NECTRUS -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual=A0 -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c cc1: warnings being treated as errors /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c: In function 'ahc_pci_resume': /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:1939: warning: 'sd.sd_MS' is used uninitialized in this function /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:2136: note: 'sd.sd_MS' was declared here /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:1941: warning: 'sd.sd_RDY' is used uninitialized in this function /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:2136: note: 'sd.sd_RDY' was declared here /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:1632: warning: 'sd.sd_CS' is used uninitialized in this function /usr/src/sys/modules/aic7xxx/ahc/ahc_pci/../../../../dev/aic7xxx/aic7xxx_pc= i.c:2136: note: 'sd.sd_CS' was declared here *** Error code 1 Stop in /usr/src/sys/modules/aic7xxx/ahc/ahc_pci. *** Error code 1 Stop in /usr/src/sys/modules/aic7xxx/ahc. *** Error code 1 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/NECTRUS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ---------------------------------------------------------------------------= --------------- Config file: # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig= -config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.13.2.1 2010/06/14 02:09:06 kensmith Exp $ cpu HAMMER ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=3Dvalue', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols makeoptions COPTFLAGS=3D"-O2 -pipe" options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD32 # Compatible with i386 binaries #options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 #options SCSI_DELAY=3D5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. #device acpi device pci # Floppy drives #device fdc # ATA and ATAPI devices #device ata #device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #XXX it is not 64-bit clean, -scottl #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard #device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc #device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgbe # Intel PRO/10GbE PCIE Ethernet Family #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs= ! device miibus # MII bus support #device ae # Attansic/Atheros L2 FastEthernet #device age # Attansic/Atheros L1 Gigabit Ethernet #device alc # Atheros AR8131/AR8132 Ethernet #device ale # Atheros AR8121/AR8113/AR8114 Ethernet #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sge # Silicon Integrated Systems SiS190/191 #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #options IEEE80211_DEBUG # enable debug msgs #options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's #options IEEE80211_SUPPORT_MESH # enable 802.11s draft support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # pci/cardbus chip support #options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors #device ath_rate_sample # SampleRate tx rate control for ath #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard #device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device urio # Diamond Rio 500 MP3 player # USB Serial devices #device uark # Technologies ARK3116 based serial adapters #device ubsa # Belkin F5U103 and compatible serial adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters #device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet #device udav # Davicom DM9601E USB # USB Wireless #device rum # Ralink Technology RT2501USB wireless NICs #device uath # Atheros AR5523 wireless NICs #device ural # Ralink Technology RT2500USB wireless NICs #device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons ---------------------------------------------------------------------------= --------------- /var/run/dmesg.boot: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =A0=A0=A0 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 =A0=A0=A0 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (1994.64-MHz K8-class CPU= ) =A0 Origin =3D "AuthenticAMD"=A0 Id =3D 0x60f82=A0 Family =3D f=A0 Model = =3D 68=A0 Stepping =3D 2 =A0 Features=3D0x178bfbff =A0 Features2=3D0x2001 =A0 AMD Features=3D0xea500800 =A0 AMD Features2=3D0x11f real memory=A0 =3D 2147483648 (2048 MB) avail memory =3D 1976483840 (1884 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) =A0cpu0 (BSP): APIC ID:=A0 0 =A0cpu1 (AP): APIC ID:=A0 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci3: on pcib2 pci3: at device 0.0 (no driver attached) vgapci0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 18 at device 5.0 on pci0 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.3 (no driver attached) ohci0: mem 0xc0004000-0xc0004fff irq 20 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xc0005000-0xc00050ff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3080-0x308f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30b0-0x30b7,0x30a4-0x30a7,0x30a8-0x30af,0x30a0-0x30a3,0x3090-0x309f mem 0xc0006000-0xc0006fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib3: at device 16.0 on pci0 pci7: on pcib3 pci0: at device 16.1 (no driver attached) nfe0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 16 at device 20.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0:=A0 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1e:68:30:00:dd nfe0: [FILTER] acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xcf800-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 8 ports with 8 removable, self powered ugen1.2: at usbus1 uhub2: on usbus1 Root mount waiting for: usbus1 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 ugen1.3: at usbus1 ugen1.4: at usbus1 Root mount waiting for: usbus1 ugen1.5: at usbus1 ums0: on usbus1 ums0: 2 buttons and [XY] coordinates ID=3D1 uhid0: on usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: at usbus0 ugen1.6: at usbus1 uhub3: on usb= us1 uhub3: 3 ports with 2 removable, bus powered Root mount waiting for: usbus1 ugen1.7: at usbus1 ums1: on usbu= s1 ums1: 8 buttons and [XYZT] coordinates ID=3D0 ugen1.8: at usbus1 ukbd0: on usb= us1 kbd2 at ukbd0 uhid1: on usb= us1 Trying to mount root from ufs:/dev/ad4s1a ---------------------------------------------------------------------------= --------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 21:19:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EDC1106564A for ; Mon, 18 Oct 2010 21:19:59 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0488FC0A for ; Mon, 18 Oct 2010 21:19:58 +0000 (UTC) Received: from 240-141-132-95.pool.ukrtel.net ([95.132.141.240] helo=localhost) by fsm1.ukr.net with esmtps ID 1P7wsL-0007OU-R7 ; Tue, 19 Oct 2010 00:04:09 +0300 Date: Tue, 19 Oct 2010 00:04:08 +0300 From: Ivan Klymenko To: Jack Engqvist Johansson Message-ID: <20101019000408.5ac74f0c@ukr.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Cannot compile a custom FreeBSD kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:19:59 -0000 =D0=92 Mon, 18 Oct 2010 22:03:54 +0200 Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > I have a HP tx2020eo laptop with FreeBSD 8.1 installed. I'm trying to > recompile the kernel to get even better performance. > The problem is that I get error when I compile. I've tried > comment/uncomment lines in my kernel config file but I always get some > of error. >=20 > Could somebody have a look at my configuration? >=20 > Laptop spec: > http://h10025.www1.hp.com/ewfrf/wc/document?lc=3Den&cc=3Dus&docname=3Dc01= 302377&dlc=3Den >=20 > -------------------------------------------------------------------------= ----------------- > Compilation: > ... > awk -f /usr/src/sys/conf/kmod_syms.awk ahc.ko.debug=C2=A0 export_syms | > xargs -J% objcopy % ahc.ko.debug > objcopy --only-keep-debug ahc.ko.debug ahc.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=3Dahc.ko.symbols ahc.ko.debug > ahc.ko =3D=3D=3D> aic7xxx/ahc/ahc_eisa (all) > cc -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc >.... not use -O3 gcc optimisation... From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 22:53:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4852F106566B for ; Mon, 18 Oct 2010 22:53:34 +0000 (UTC) (envelope-from jack@skysel.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 C7E8F8FC12 for ; Mon, 18 Oct 2010 22:53:32 +0000 (UTC) Received: by wwb13 with SMTP id 13so878089wwb.31 for ; Mon, 18 Oct 2010 15:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.158.7 with SMTP id p7mr5278209wek.58.1287442411615; Mon, 18 Oct 2010 15:53:31 -0700 (PDT) Received: by 10.216.54.84 with HTTP; Mon, 18 Oct 2010 15:53:31 -0700 (PDT) X-Originating-IP: [83.233.150.160] Date: Tue, 19 Oct 2010 00:53:31 +0200 Message-ID: From: Jack Engqvist Johansson To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 18 Oct 2010 23:32:54 +0000 Subject: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 22:53:34 -0000 Hi, I just got succeeded with my compilation of a custom kernel for FreeBSD 8.1. But when I'm trying to install it, I got an error. File system is full! So I moved the old kernel to another partition, but got the same error. And I cannot move it back again. Whats wrong? How can I do to get a kernel again? Thanks. Best regards, Jack Engvist Johansson bsd# make installkernel KERNCONF=NECTRUS -------------------------------------------------------------- >>> Installing kernel -------------------------------------------------------------- cd /usr/obj/usr/src/sys/NECTRUS; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel /: write failed, filesystem is full install: /boot/kernel/kernel: No space left on device *** Error code 71 Stop in /usr/obj/usr/src/sys/NECTRUS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ----------------------------------------------------------------------------------------- Laptop spec: http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&cc=us&docname=c01302377&dlc=en /var/run/dmesg.boot: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (1994.64-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Family = f Model = 68 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f real memory = 2147483648 (2048 MB) avail memory = 1976483840 (1884 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci3: on pcib2 pci3: at device 0.0 (no driver attached) vgapci0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 18 at device 5.0 on pci0 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.3 (no driver attached) ohci0: mem 0xc0004000-0xc0004fff irq 20 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xc0005000-0xc00050ff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3080-0x308f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30b0-0x30b7,0x30a4-0x30a7,0x30a8-0x30af,0x30a0-0x30a3,0x3090-0x309f mem 0xc0006000-0xc0006fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib3: at device 16.0 on pci0 pci7: on pcib3 pci0: at device 16.1 (no driver attached) nfe0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 16 at device 20.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1e:68:30:00:dd nfe0: [FILTER] acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xcf800-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! Root mount waiting for: usbus1 usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 8 ports with 8 removable, self powered ugen1.2: at usbus1 uhub2: on usbus1 Root mount waiting for: usbus1 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 ugen1.3: at usbus1 ugen1.4: at usbus1 Root mount waiting for: usbus1 ugen1.5: at usbus1 ums0: on usbus1 ums0: 2 buttons and [XY] coordinates ID=1 uhid0: on usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: at usbus0 ugen1.6: at usbus1 uhub3: on usbus1 uhub3: 3 ports with 2 removable, bus powered Root mount waiting for: usbus1 ugen1.7: at usbus1 ums1: on usbus1 ums1: 8 buttons and [XYZT] coordinates ID=0 ugen1.8: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 uhid1: on usbus1 Trying to mount root from ufs:/dev/ad4s1a ------------------------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 18 23:53:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2A6DD10656A8; Mon, 18 Oct 2010 23:53:18 +0000 (UTC) Date: Mon, 18 Oct 2010 23:53:18 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101018235318.GA87158@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline Subject: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:53:18 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline any thoughts on this patch? i noticed the "default" SCSI_DELAY value of 2000ms was only used in very few places so i thought it would make more sense making 5000ms the default and adding a few special cases where SCSI_DELAY can in fact be lowered down to 2000ms. cheers. alex -- a13x --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="SCSI_DELAY.diff" diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 3bc6299..df26ea6 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -49,7 +49,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/amd64/conf/XENHVM b/sys/amd64/conf/XENHVM index 51f1256..47cdc83 100644 --- a/sys/amd64/conf/XENHVM +++ b/sys/amd64/conf/XENHVM @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/arm/conf/BWCT b/sys/arm/conf/BWCT index 0fb3b87..34db9a7 100644 --- a/sys/arm/conf/BWCT +++ b/sys/arm/conf/BWCT @@ -57,7 +57,7 @@ options BOOTP #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/CNS11XXNAS b/sys/arm/conf/CNS11XXNAS index 76db42b..b14b1b2 100644 --- a/sys/arm/conf/CNS11XXNAS +++ b/sys/arm/conf/CNS11XXNAS @@ -74,7 +74,6 @@ options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/CRB b/sys/arm/conf/CRB index 2afd080..ff7fc1d 100644 --- a/sys/arm/conf/CRB +++ b/sys/arm/conf/CRB @@ -49,7 +49,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options INTR_FILTER options SYSVSHM #SYSV-style shared memory diff --git a/sys/arm/conf/EP80219 b/sys/arm/conf/EP80219 index 3c2c1aa..24cf837 100644 --- a/sys/arm/conf/EP80219 +++ b/sys/arm/conf/EP80219 @@ -48,7 +48,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/GUMSTIX b/sys/arm/conf/GUMSTIX index e7900f5..973f6e3 100644 --- a/sys/arm/conf/GUMSTIX +++ b/sys/arm/conf/GUMSTIX @@ -53,7 +53,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/HL200 b/sys/arm/conf/HL200 index dd46a61..d7b6ab9 100644 --- a/sys/arm/conf/HL200 +++ b/sys/arm/conf/HL200 @@ -53,7 +53,7 @@ options BOOTP_COMPAT #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/HL201 b/sys/arm/conf/HL201 index 6524cc6..ad3606f 100644 --- a/sys/arm/conf/HL201 +++ b/sys/arm/conf/HL201 @@ -55,7 +55,7 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/IQ31244 b/sys/arm/conf/IQ31244 index 8b79497..a2e4687 100644 --- a/sys/arm/conf/IQ31244 +++ b/sys/arm/conf/IQ31244 @@ -49,7 +49,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/KB920X b/sys/arm/conf/KB920X index f47e9ac..3454d02 100644 --- a/sys/arm/conf/KB920X +++ b/sys/arm/conf/KB920X @@ -51,7 +51,7 @@ options NFSCLIENT #Network Filesystem Client #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/LN2410SBC b/sys/arm/conf/LN2410SBC index e4f3a54..bac3de8 100644 --- a/sys/arm/conf/LN2410SBC +++ b/sys/arm/conf/LN2410SBC @@ -49,7 +49,7 @@ options ROOTDEVNAME=\"ufs:da0s1\" #options NFS_ROOT #NFS usable as root device options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/NSLU b/sys/arm/conf/NSLU index d921e34..1585689 100644 --- a/sys/arm/conf/NSLU +++ b/sys/arm/conf/NSLU @@ -66,7 +66,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/QILA9G20 b/sys/arm/conf/QILA9G20 index 55839ce..c1612df 100644 --- a/sys/arm/conf/QILA9G20 +++ b/sys/arm/conf/QILA9G20 @@ -57,7 +57,7 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) #options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/SAM9G20EK b/sys/arm/conf/SAM9G20EK index 6c2e94e..368b615 100644 --- a/sys/arm/conf/SAM9G20EK +++ b/sys/arm/conf/SAM9G20EK @@ -56,7 +56,7 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) #options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/SKYEYE b/sys/arm/conf/SKYEYE index b3aad2a..e7c843e 100644 --- a/sys/arm/conf/SKYEYE +++ b/sys/arm/conf/SKYEYE @@ -50,7 +50,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/cam/scsi/scsi_all.c b/sys/cam/scsi/scsi_all.c index cddac5c..7876393 100644 --- a/sys/cam/scsi/scsi_all.c +++ b/sys/cam/scsi/scsi_all.c @@ -70,7 +70,7 @@ __FBSDID("$FreeBSD$"); * after a SCSI bus reset. */ #ifndef SCSI_DELAY -#define SCSI_DELAY 2000 +#define SCSI_DELAY 5000 #endif diff --git a/sys/i386/conf/GENERIC b/sys/i386/conf/GENERIC index 85f4697..e1c0673 100644 --- a/sys/i386/conf/GENERIC +++ b/sys/i386/conf/GENERIC @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/ia64/conf/GENERIC b/sys/ia64/conf/GENERIC index 71af42c..ff43121 100644 --- a/sys/ia64/conf/GENERIC +++ b/sys/ia64/conf/GENERIC @@ -54,7 +54,6 @@ options PRINTF_BUFR_SIZE=128 # Printf buffering to limit interspersion options PROCFS # Process filesystem (/proc) options PSEUDOFS # Pseudo-filesystem framework options SCHED_ULE # ULE scheduler -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options SCTP # Stream Control Transmission Protocol options SMP # Symmetric Multi-Processor support options SOFTUPDATES # Enable FFS soft updates support diff --git a/sys/mips/conf/OCTEON1 b/sys/mips/conf/OCTEON1 index a00e95d..db56e7c 100644 --- a/sys/mips/conf/OCTEON1 +++ b/sys/mips/conf/OCTEON1 @@ -65,7 +65,6 @@ options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization #options COMPAT_FREEBSD32 # Compatible with o32 binaries (not yet) -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/pc98/conf/GENERIC b/sys/pc98/conf/GENERIC index e137297..df937c6 100644 --- a/sys/pc98/conf/GENERIC +++ b/sys/pc98/conf/GENERIC @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options EPSON_BOUNCEDMA # use bounce buffer for 15-16M #options EPSON_MEMWIN # EPSON memory window support #options LINE30 diff --git a/sys/powerpc/conf/GENERIC b/sys/powerpc/conf/GENERIC index c23e9ac..5f44ee8 100644 --- a/sys/powerpc/conf/GENERIC +++ b/sys/powerpc/conf/GENERIC @@ -54,7 +54,6 @@ options COMPAT_FREEBSD4 #Keep this for a while options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options COMPAT_FREEBSD7 #Compatible with FreeBSD7 -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) syscall trace support options STACK #stack(9) support options SYSVSHM #SYSV-style shared memory diff --git a/sys/powerpc/conf/GENERIC64 b/sys/powerpc/conf/GENERIC64 index b861e51..9127c01 100644 --- a/sys/powerpc/conf/GENERIC64 +++ b/sys/powerpc/conf/GENERIC64 @@ -53,7 +53,6 @@ options COMPAT_FREEBSD32 #Compatible with FreeBSD/powerpc binaries options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options COMPAT_FREEBSD7 #Compatible with FreeBSD7 -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) syscall trace support options STACK #stack(9) support options SYSVSHM #SYSV-style shared memory diff --git a/sys/sparc64/conf/GENERIC b/sys/sparc64/conf/GENERIC index 6bbd4e1..60226d0 100644 --- a/sys/sparc64/conf/GENERIC +++ b/sys/sparc64/conf/GENERIC @@ -50,7 +50,6 @@ options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/sun4v/conf/GENERIC b/sys/sun4v/conf/GENERIC index 74fc036..0508048 100644 --- a/sys/sun4v/conf/GENERIC +++ b/sys/sun4v/conf/GENERIC @@ -51,7 +51,6 @@ options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/share/man/man4/scsi.4 b/share/man/man4/scsi.4 index ad52663..d95b978 100644 --- a/share/man/man4/scsi.4 +++ b/share/man/man4/scsi.4 @@ -24,7 +24,7 @@ .\" SUCH DAMAGE. .\" .\" $FreeBSD$ -.Dd March 4, 2010 +.Dd October 19, 2010 .Dt CAM 4 .Os .Sh NAME @@ -47,7 +47,7 @@ .Cd "options CAM_MAX_HIGHPOWER=4" .Cd "options SCSI_NO_SENSE_STRINGS" .Cd "options SCSI_NO_OP_STRINGS" -.Cd "options SCSI_DELAY=8000" +.Cd "options SCSI_DELAY=5000" .Sh DESCRIPTION The .Nm @@ -116,7 +116,7 @@ Enabling this option for normal use is not recommended, since it slows debugging of .Tn SCSI problems. -.It Dv SCSI_DELAY=8000 +.It Dv SCSI_DELAY=5000 This is the .Tn SCSI "bus settle delay." @@ -138,7 +138,7 @@ Newer disks may need as little as 100ms, while old, slow devices may need much longer. If the .Dv SCSI_DELAY -is not specified, it defaults to 2 seconds. +is not specified, it defaults to 5 seconds. The minimum allowable value for .Dv SCSI_DELAY is "100", or 100ms. --nFreZHaLTZJo0R7j-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 00:29:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E114106564A for ; Tue, 19 Oct 2010 00:29:48 +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 1697D8FC08 for ; Tue, 19 Oct 2010 00:29:47 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9J0TkVU066926 for ; Mon, 18 Oct 2010 17:29:47 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CBCE67C.1070106@feral.com> Date: Mon, 18 Oct 2010 17:29:48 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20101018235318.GA87158@freebsd.org> In-Reply-To: <20101018235318.GA87158@freebsd.org> X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Mon, 18 Oct 2010 17:29:47 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 00:29:48 -0000 What problem are you solving by this change? > any thoughts on this patch? > > i noticed the "default" SCSI_DELAY value of 2000ms was only used in very few > places so i thought it would make more sense making 5000ms the default and > adding a few special cases where SCSI_DELAY can in fact be lowered down to > 2000ms. > > cheers. > alex > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 06:30:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698D710656A3 for ; Tue, 19 Oct 2010 06:30:26 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 26F058FC0C for ; Tue, 19 Oct 2010 06:30:25 +0000 (UTC) Received: from 240-141-132-95.pool.ukrtel.net ([95.132.141.240] helo=localhost) by fsm1.ukr.net with esmtps ID 1P85iK-0009Kg-F2 ; Tue, 19 Oct 2010 09:30:24 +0300 Date: Tue, 19 Oct 2010 09:30:23 +0300 From: Ivan Klymenko To: Jack Engqvist Johansson Message-ID: <20101019093023.5efb3bcb@ukr.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 06:30:26 -0000 =D0=92 Tue, 19 Oct 2010 00:53:31 +0200 Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > I just got succeeded with my compilation of a custom kernel for > FreeBSD 8.1. But when I'm trying to install it, I got an error. > File system is full! >=20 > So I moved the old kernel to another partition, but got the same > error. And I cannot move it back again. > Whats wrong? How can I do to get a kernel again? >=20 > Thanks. > Best regards, Jack Engvist Johansson >=20 >=20 >=20 > bsd# make installkernel KERNCONF=3DNECTRUS > -------------------------------------------------------------- > >>> Installing kernel > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/NECTRUS; MAKEOBJDIRPREFIX=3D/usr/obj > MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D > GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/u= sr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:= /usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr= /sbin:/usr/bin > make KERNEL=3Dkernel install > thiskernel=3D`sysctl -n kern.bootfile` ; if [ ! "`dirname > "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg > /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old > ] ; then chflags -R noschg /boot/kernel.old ; rm -rf > /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl > kern.bootfile=3D/boot/kernel.old/"`basename "$thiskernel"`" ; fi > mkdir -p /boot/kernel > install -p -m 555 -o root -g wheel kernel /boot/kernel >=20 > /: write failed, filesystem is full > install: /boot/kernel/kernel: No space left on device > *** Error code 71 >=20 > Stop in /usr/obj/usr/src/sys/NECTRUS. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > -------------------------------------------------------------------------= ---------------- >=20 Look how much space left on partition / df -h and is not used for the root account From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 10:34:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4AC88106566C; Tue, 19 Oct 2010 10:34:32 +0000 (UTC) Date: Tue, 19 Oct 2010 10:34:32 +0000 From: Alexander Best To: Matthew Jacob Message-ID: <20101019103432.GA69208@freebsd.org> References: <20101018235318.GA87158@freebsd.org> <4CBCE67C.1070106@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CBCE67C.1070106@feral.com> Cc: freebsd-hackers@freebsd.org Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 10:34:32 -0000 On Mon Oct 18 10, Matthew Jacob wrote: > What problem are you solving by this change? code cleanup. the scsi delay value currently defaults to 2000ms. however that doesn't make sense, since on almost all platforms it gets set to 5000ms in the default config. what's the purpose of having a default value, if it is much more often overwritten than actually used? that's why this patch changes the default scsi delay value to 5000ms. now all of the lines that were setting the scsi delay value to 5000ms can be removed. also default values should be chosen very conservatively. users can always lower the delay value via their kernel config or sysctl. cheers. alex > > >any thoughts on this patch? > > > >i noticed the "default" SCSI_DELAY value of 2000ms was only used in very > >few > >places so i thought it would make more sense making 5000ms the default and > >adding a few special cases where SCSI_DELAY can in fact be lowered down to > >2000ms. > > > >cheers. > >alex > > > > > > > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 13:38:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D639A1065672 for ; Tue, 19 Oct 2010 13:38:29 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9251B8FC13 for ; Tue, 19 Oct 2010 13:38:29 +0000 (UTC) Received: from 75-199-132-95.pool.ukrtel.net ([95.132.199.75] helo=localhost) by fsm1.ukr.net with esmtps ID 1P8COZ-0006Ix-Ar ; Tue, 19 Oct 2010 16:38:27 +0300 Date: Tue, 19 Oct 2010 16:38:26 +0300 From: Ivan Klymenko To: Jack Engqvist Johansson Message-ID: <20101019163826.63c7d632@ukr.net> In-Reply-To: References: <20101019093023.5efb3bcb@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:38:30 -0000 =D0=92 Tue, 19 Oct 2010 13:53:34 +0200 Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Tue, Oct 19, 2010 at 8:30 AM, Ivan Klymenko wrote: > > =D0=92 Tue, 19 Oct 2010 00:53:31 +0200 > > Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > > > >> Hi, > >> > >> I just got succeeded with my compilation of a custom kernel for > >> FreeBSD 8.1. But when I'm trying to install it, I got an error. > >> File system is full! > >> > >> So I moved the old kernel to another partition, but got the same > >> error. And I cannot move it back again. > >> Whats wrong? How can I do to get a kernel again? > >> > >> Thanks. > >> Best regards, Jack Engvist Johansson > >> > >> > >> > >> =C2=A0bsd# make installkernel KERNCONF=3DNECTRUS > >> -------------------------------------------------------------- > >> >>> Installing kernel > >> -------------------------------------------------------------- > >> cd /usr/obj/usr/src/sys/NECTRUS; =C2=A0MAKEOBJDIRPREFIX=3D/usr/obj > >> MACHINE_ARCH=3Damd64 =C2=A0MACHINE=3Damd64 =C2=A0CPUTYPE=3D > >> GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > >> GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >> GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >> PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sb= in:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/= usr/sbin:/usr/bin > >> =C2=A0make KERNEL=3Dkernel install > >> thiskernel=3D`sysctl -n kern.bootfile` ; =C2=A0if [ ! "`dirname > >> "$thiskernel"`" -ef /boot/kernel ] ; then =C2=A0chflags -R noschg > >> /boot/kernel ; =C2=A0rm -rf /boot/kernel ; =C2=A0else =C2=A0if > >> [ -d /boot/kernel.old ] ; then =C2=A0chflags -R > >> noschg /boot/kernel.old ; =C2=A0rm -rf /boot/kernel.old ; =C2=A0fi ; > >> =C2=A0mv /boot/kernel /boot/kernel.old ; =C2=A0sysctl > >> kern.bootfile=3D/boot/kernel.old/"`basename "$thiskernel"`" ; =C2=A0fi > >> mkdir -p /boot/kernel install -p -m 555 -o root -g wheel > >> kernel /boot/kernel > >> > >> /: write failed, filesystem is full > >> install: /boot/kernel/kernel: No space left on device > >> *** Error code 71 > >> > >> Stop in /usr/obj/usr/src/sys/NECTRUS. > >> *** Error code 1 > >> > >> Stop in /usr/src. > >> *** Error code 1 > >> > >> Stop in /usr/src. > >> ----------------------------------------------------------------------= ------------------- > >> > > > > Look how much space left on partition / > > df -h > > and is not used for the root account > > >=20 > $ df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/ad4s1a 496M 490M -34M 108% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/ad4s1e 496M 26M 430M 6% /tmp > /dev/ad4s1f 137G 13G 113G 10% /usr > /dev/ad4s1d 2.8G 162M 2.4G 6% /var > procfs 4.0K 4.0K 0B 100% /proc > linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc >=20 >=20 > Nautilus: 4258945024 bytes (Free space) > /root: 14.2 KB (Used space) >=20 >=20 show me the output the following commands from the root account: du -chd0 /bin du -chd0 /boot du -chd0 /etc du -chd0 /lib du -chd0 /libexec du -chd0 /root du -chd0 /sbin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 13:55:59 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40BC0106564A for ; Tue, 19 Oct 2010 13:55:59 +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 EBE788FC1A for ; Tue, 19 Oct 2010 13:55:58 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9JDtvK7016830; Tue, 19 Oct 2010 06:55:58 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CBDA371.4080801@feral.com> Date: Tue, 19 Oct 2010 06:56:01 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Best References: <20101018235318.GA87158@freebsd.org> <4CBCE67C.1070106@feral.com> <20101019103432.GA69208@freebsd.org> In-Reply-To: <20101019103432.GA69208@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Tue, 19 Oct 2010 06:55:58 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:55:59 -0000 It would be an effective behavioral change for those of us who remove that line. Personally, I think 5 seconds is too long- even 2 seconds is more than adequate even for moderately old 'other' hardware like scanners. For -current, why don't you simply remove all of the config lines and leave the default at 2000ms? On 10/19/2010 3:34 AM, Alexander Best wrote: > On Mon Oct 18 10, Matthew Jacob wrote: >> What problem are you solving by this change? > code cleanup. > > the scsi delay value currently defaults to 2000ms. however that doesn't make > sense, since on almost all platforms it gets set to 5000ms in the default > config. what's the purpose of having a default value, if it is much more often > overwritten than actually used? > > that's why this patch changes the default scsi delay value to 5000ms. now all > of the lines that were setting the scsi delay value to 5000ms can be removed. > also default values should be chosen very conservatively. users can always > lower the delay value via their kernel config or sysctl. > > cheers. > alex From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 14:10:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB568106566C for ; Tue, 19 Oct 2010 14:10:03 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6E25A8FC1A for ; Tue, 19 Oct 2010 14:10:03 +0000 (UTC) Received: from 75-199-132-95.pool.ukrtel.net ([95.132.199.75] helo=localhost) by fsm1.ukr.net with esmtps ID 1P8Ct8-000L0R-4J ; Tue, 19 Oct 2010 17:10:02 +0300 Date: Tue, 19 Oct 2010 17:10:01 +0300 From: Ivan Klymenko To: Jack Engqvist Johansson Message-ID: <20101019171001.6fed1b70@ukr.net> In-Reply-To: References: <20101019093023.5efb3bcb@ukr.net> <20101019163826.63c7d632@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:10:03 -0000 =D0=92 Tue, 19 Oct 2010 15:58:35 +0200 Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Tue, Oct 19, 2010 at 3:38 PM, Ivan Klymenko wrote: > > =D0=92 Tue, 19 Oct 2010 13:53:34 +0200 > > Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > > > >> On Tue, Oct 19, 2010 at 8:30 AM, Ivan Klymenko > >> wrote: > >> > =D0=92 Tue, 19 Oct 2010 00:53:31 +0200 > >> > Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: > >> > > >> >> Hi, > >> >> > >> >> I just got succeeded with my compilation of a custom kernel for > >> >> FreeBSD 8.1. But when I'm trying to install it, I got an error. > >> >> File system is full! > >> >> > >> >> So I moved the old kernel to another partition, but got the same > >> >> error. And I cannot move it back again. > >> >> Whats wrong? How can I do to get a kernel again? > >> >> > >> >> Thanks. > >> >> Best regards, Jack Engvist Johansson > >> >> > >> >> > >> >> > >> >> =C2=A0bsd# make installkernel KERNCONF=3DNECTRUS > >> >> -------------------------------------------------------------- > >> >> >>> Installing kernel > >> >> -------------------------------------------------------------- > >> >> cd /usr/obj/usr/src/sys/NECTRUS; =C2=A0MAKEOBJDIRPREFIX=3D/usr/obj > >> >> MACHINE_ARCH=3Damd64 =C2=A0MACHINE=3Damd64 =C2=A0CPUTYPE=3D > >> >> GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > >> >> GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > >> >> GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > >> >> PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/le= gacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr= /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bi= n:/usr/sbin:/usr/bin > >> >> =C2=A0make KERNEL=3Dkernel install > >> >> thiskernel=3D`sysctl -n kern.bootfile` ; =C2=A0if [ ! "`dirname > >> >> "$thiskernel"`" -ef /boot/kernel ] ; then =C2=A0chflags -R noschg > >> >> /boot/kernel ; =C2=A0rm -rf /boot/kernel ; =C2=A0else =C2=A0if > >> >> [ -d /boot/kernel.old ] ; then =C2=A0chflags -R > >> >> noschg /boot/kernel.old ; =C2=A0rm -rf /boot/kernel.old ; =C2=A0fi ; > >> >> =C2=A0mv /boot/kernel /boot/kernel.old ; =C2=A0sysctl > >> >> kern.bootfile=3D/boot/kernel.old/"`basename "$thiskernel"`" ; =C2= =A0fi > >> >> mkdir -p /boot/kernel install -p -m 555 -o root -g wheel > >> >> kernel /boot/kernel > >> >> > >> >> /: write failed, filesystem is full > >> >> install: /boot/kernel/kernel: No space left on device > >> >> *** Error code 71 > >> >> > >> >> Stop in /usr/obj/usr/src/sys/NECTRUS. > >> >> *** Error code 1 > >> >> > >> >> Stop in /usr/src. > >> >> *** Error code 1 > >> >> > >> >> Stop in /usr/src. > >> >> -------------------------------------------------------------------= ---------------------- > >> >> > >> > > >> > Look how much space left on partition / > >> > df -h > >> > and is not used for the root account > >> > > >> > >> $ df -h > >> Filesystem =C2=A0 =C2=A0 Size =C2=A0 =C2=A0Used =C2=A0 Avail Capacity = =C2=A0Mounted on > >> /dev/ad4s1a =C2=A0 =C2=A0496M =C2=A0 =C2=A0490M =C2=A0 =C2=A0-34M =C2= =A0 108% =C2=A0 =C2=A0/ > >> devfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.0K =C2=A0 =C2=A01.0K =C2=A0 = =C2=A0 =C2=A00B =C2=A0 100% =C2=A0 =C2=A0/dev > >> /dev/ad4s1e =C2=A0 =C2=A0496M =C2=A0 =C2=A0 26M =C2=A0 =C2=A0430M =C2= =A0 =C2=A0 6% =C2=A0 =C2=A0/tmp > >> /dev/ad4s1f =C2=A0 =C2=A0137G =C2=A0 =C2=A0 13G =C2=A0 =C2=A0113G =C2= =A0 =C2=A010% =C2=A0 =C2=A0/usr > >> /dev/ad4s1d =C2=A0 =C2=A02.8G =C2=A0 =C2=A0162M =C2=A0 =C2=A02.4G =C2= =A0 =C2=A0 6% =C2=A0 =C2=A0/var > >> procfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 4.0K =C2=A0 =C2=A04.0K =C2=A0 =C2= =A0 =C2=A00B =C2=A0 100% =C2=A0 =C2=A0/proc > >> linprocfs =C2=A0 =C2=A0 =C2=A04.0K =C2=A0 =C2=A04.0K =C2=A0 =C2=A0 =C2= =A00B =C2=A0 100% > >> =C2=A0/usr/compat/linux/proc > >> > >> > >> Nautilus: 4258945024 bytes (Free space) > >> /root: 14.2 KB (Used space) > >> > >> > > > > show me the output the following commands from the root account: > > du -chd0 /bin > > du -chd0 /boot > > du -chd0 /etc > > du -chd0 /lib > > du -chd0 /libexec > > du -chd0 /root > > du -chd0 /sbin > > >=20 > bsd# du -chd0 /bin > 1.2M /bin > 1.2M total > bsd# du -chd0 /boot > 14M /boot > 14M total > bsd# du -chd0 /etc > 1.7M /etc > 1.7M total > bsd# du -chd0 /lib > 7.5M /lib > 7.5M total > bsd# du -chd0 /libexec > 514K /libexec > 514K total > bsd# du -chd0 /root > 457M /root > 457M total !!!!!! do not use the Root account to work in the system! !!!!!! Create another account for this... go to this directory (/root) and delete the files that take up much space a= nd you're free ~ 450Mb... > bsd# du -chd0 /sbin > 4.6M /sbin > 4.6M total >=20 >=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=98=D0=B2= =D0=B0=D0=BD! ------------------------------------------ =D0=9C=D1=8B =D0=BC=D0=BE=D0=B6=D0=B5=D0=BC =D0=B2=D1=81=D0=B5 - =D1=87=D1= =82=D0=BE =D0=BC=D0=BE=D0=B6=D0=B5=D0=BC =D1=81=D0=B5=D0=B1=D0=B5 =D0=BF=D1= =80=D0=B5=D0=B4=D1=81=D1=82=D0=B0=D0=B2=D0=B8=D1=82=D1=8C! jabber: fidaj@jabber.ru skype: freedom_fidaj youtube channel: http://www.youtube.com/freedomfidaj mob.: +380938326345 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 14:31:10 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 30D851065670; Tue, 19 Oct 2010 14:31:10 +0000 (UTC) Date: Tue, 19 Oct 2010 14:31:10 +0000 From: Alexander Best To: Matthew Jacob Message-ID: <20101019143110.GA5802@freebsd.org> References: <20101018235318.GA87158@freebsd.org> <4CBCE67C.1070106@feral.com> <20101019103432.GA69208@freebsd.org> <4CBDA371.4080801@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CBDA371.4080801@feral.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:31:10 -0000 On Tue Oct 19 10, Matthew Jacob wrote: > It would be an effective behavioral change for those of us who remove > that line. > Personally, I think 5 seconds is too long- even 2 seconds is more than > adequate even for moderately old 'other' hardware like scanners. > > For -current, why don't you simply remove all of the config lines and > leave the default at 2000ms? hmmm...i can only test the delay value on amd64. i was under the impression that archs like arm and mips need the longer delay. also at some locations in the code SCSI_DELAY is being set to 15000. i believe this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel module, but i'm not sure. it looks like this: .if !defined(KERNBUILDDIR) opt_scsi.h: echo "#define SCSI_DELAY 15000" > ${.TARGET} .endif cheers. alex > > On 10/19/2010 3:34 AM, Alexander Best wrote: > >On Mon Oct 18 10, Matthew Jacob wrote: > >> What problem are you solving by this change? > >code cleanup. > > > >the scsi delay value currently defaults to 2000ms. however that doesn't > >make > >sense, since on almost all platforms it gets set to 5000ms in the default > >config. what's the purpose of having a default value, if it is much more > >often > >overwritten than actually used? > > > >that's why this patch changes the default scsi delay value to 5000ms. now > >all > >of the lines that were setting the scsi delay value to 5000ms can be > >removed. > >also default values should be chosen very conservatively. users can always > >lower the delay value via their kernel config or sysctl. > > > >cheers. > >alex > -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 14:35:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C19C51065670 for ; Tue, 19 Oct 2010 14:35:18 +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 8A82C8FC19 for ; Tue, 19 Oct 2010 14:35:18 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9JEZHcr017200 for ; Tue, 19 Oct 2010 07:35:17 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CBDACA9.3040701@feral.com> Date: Tue, 19 Oct 2010 07:35:21 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20101018235318.GA87158@freebsd.org> <4CBCE67C.1070106@feral.com> <20101019103432.GA69208@freebsd.org> <4CBDA371.4080801@feral.com> <20101019143110.GA5802@freebsd.org> In-Reply-To: <20101019143110.GA5802@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Tue, 19 Oct 2010 07:35:18 -0700 (PDT) Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:35:18 -0000 I'd go for the gusto in -current, but it's ok to be conservative too. > On Tue Oct 19 10, Matthew Jacob wrote: >> It would be an effective behavioral change for those of us who remove >> that line. >> Personally, I think 5 seconds is too long- even 2 seconds is more than >> adequate even for moderately old 'other' hardware like scanners. >> >> For -current, why don't you simply remove all of the config lines and >> leave the default at 2000ms? > hmmm...i can only test the delay value on amd64. i was under the impression > that archs like arm and mips need the longer delay. > > also at some locations in the code SCSI_DELAY is being set to 15000. i believe > this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel > module, but i'm not sure. it looks like this: > > .if !defined(KERNBUILDDIR) > opt_scsi.h: > echo "#define SCSI_DELAY 15000"> ${.TARGET} > .endif > > cheers. > alex > > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 15:04:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0976D106566C; Tue, 19 Oct 2010 15:04: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 CEE6F8FC13; Tue, 19 Oct 2010 15:04:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 65E9D46B03; Tue, 19 Oct 2010 11:04:00 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6D6498A009; Tue, 19 Oct 2010 11:03:59 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 19 Oct 2010 11:03:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101018235318.GA87158@freebsd.org> <4CBDA371.4080801@feral.com> <20101019143110.GA5802@freebsd.org> In-Reply-To: <20101019143110.GA5802@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010191103.50986.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 11:03:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Best , Matthew Jacob Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 15:04:01 -0000 On Tuesday, October 19, 2010 10:31:10 am Alexander Best wrote: > On Tue Oct 19 10, Matthew Jacob wrote: > > It would be an effective behavioral change for those of us who remove > > that line. > > Personally, I think 5 seconds is too long- even 2 seconds is more than > > adequate even for moderately old 'other' hardware like scanners. > > > > For -current, why don't you simply remove all of the config lines and > > leave the default at 2000ms? > > hmmm...i can only test the delay value on amd64. i was under the impression > that archs like arm and mips need the longer delay. > > also at some locations in the code SCSI_DELAY is being set to 15000. i believe > this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel > module, but i'm not sure. it looks like this: > > .if !defined(KERNBUILDDIR) > opt_scsi.h: > echo "#define SCSI_DELAY 15000" > ${.TARGET} > .endif I believe this is all old history. SCSI_DELAY used to be set to 15000 in GENERIC many years ago and was lowered to 5000. Most likely these Makefiles were simply not updated at the time. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 19:14:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A3626106566B; Tue, 19 Oct 2010 19:14:46 +0000 (UTC) Date: Tue, 19 Oct 2010 19:14:46 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101019191446.GA44841@freebsd.org> References: <20101018235318.GA87158@freebsd.org> <4CBDA371.4080801@feral.com> <20101019143110.GA5802@freebsd.org> <201010191103.50986.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <201010191103.50986.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:14:46 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue Oct 19 10, John Baldwin wrote: > On Tuesday, October 19, 2010 10:31:10 am Alexander Best wrote: > > On Tue Oct 19 10, Matthew Jacob wrote: > > > It would be an effective behavioral change for those of us who remove > > > that line. > > > Personally, I think 5 seconds is too long- even 2 seconds is more than > > > adequate even for moderately old 'other' hardware like scanners. > > > > > > For -current, why don't you simply remove all of the config lines and > > > leave the default at 2000ms? > > > > hmmm...i can only test the delay value on amd64. i was under the impression > > that archs like arm and mips need the longer delay. > > > > also at some locations in the code SCSI_DELAY is being set to 15000. i believe > > this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel > > module, but i'm not sure. it looks like this: > > > > .if !defined(KERNBUILDDIR) > > opt_scsi.h: > > echo "#define SCSI_DELAY 15000" > ${.TARGET} > > .endif > > I believe this is all old history. SCSI_DELAY used to be set to 15000 in > GENERIC many years ago and was lowered to 5000. Most likely these Makefiles > were simply not updated at the time. oh i see. maybe this revised patch would be better suited then. cheers. alex > > -- > John Baldwin -- a13x --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="SCSI_DELAY.diff2" diff --git a/share/man/man4/scsi.4 b/share/man/man4/scsi.4 index ad52663..3087aec 100644 --- a/share/man/man4/scsi.4 +++ b/share/man/man4/scsi.4 @@ -24,7 +24,7 @@ .\" SUCH DAMAGE. .\" .\" $FreeBSD$ -.Dd March 4, 2010 +.Dd October 19, 2010 .Dt CAM 4 .Os .Sh NAME @@ -47,7 +47,7 @@ .Cd "options CAM_MAX_HIGHPOWER=4" .Cd "options SCSI_NO_SENSE_STRINGS" .Cd "options SCSI_NO_OP_STRINGS" -.Cd "options SCSI_DELAY=8000" +.Cd "options SCSI_DELAY=2000" .Sh DESCRIPTION The .Nm @@ -116,7 +116,7 @@ Enabling this option for normal use is not recommended, since it slows debugging of .Tn SCSI problems. -.It Dv SCSI_DELAY=8000 +.It Dv SCSI_DELAY=2000 This is the .Tn SCSI "bus settle delay." diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 3bc6299..df26ea6 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -49,7 +49,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/amd64/conf/XENHVM b/sys/amd64/conf/XENHVM index 51f1256..47cdc83 100644 --- a/sys/amd64/conf/XENHVM +++ b/sys/amd64/conf/XENHVM @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/arm/conf/BWCT b/sys/arm/conf/BWCT index 0fb3b87..a2ecc07 100644 --- a/sys/arm/conf/BWCT +++ b/sys/arm/conf/BWCT @@ -57,7 +57,6 @@ options BOOTP #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/CNS11XXNAS b/sys/arm/conf/CNS11XXNAS index 76db42b..b14b1b2 100644 --- a/sys/arm/conf/CNS11XXNAS +++ b/sys/arm/conf/CNS11XXNAS @@ -74,7 +74,6 @@ options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/CRB b/sys/arm/conf/CRB index 2afd080..ff7fc1d 100644 --- a/sys/arm/conf/CRB +++ b/sys/arm/conf/CRB @@ -49,7 +49,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options INTR_FILTER options SYSVSHM #SYSV-style shared memory diff --git a/sys/arm/conf/EP80219 b/sys/arm/conf/EP80219 index 3c2c1aa..24cf837 100644 --- a/sys/arm/conf/EP80219 +++ b/sys/arm/conf/EP80219 @@ -48,7 +48,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/GUMSTIX b/sys/arm/conf/GUMSTIX index e7900f5..973f6e3 100644 --- a/sys/arm/conf/GUMSTIX +++ b/sys/arm/conf/GUMSTIX @@ -53,7 +53,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/HL200 b/sys/arm/conf/HL200 index dd46a61..1c06f24 100644 --- a/sys/arm/conf/HL200 +++ b/sys/arm/conf/HL200 @@ -53,7 +53,6 @@ options BOOTP_COMPAT #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/HL201 b/sys/arm/conf/HL201 index 6524cc6..194f454 100644 --- a/sys/arm/conf/HL201 +++ b/sys/arm/conf/HL201 @@ -55,7 +55,6 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/IQ31244 b/sys/arm/conf/IQ31244 index 8b79497..a2e4687 100644 --- a/sys/arm/conf/IQ31244 +++ b/sys/arm/conf/IQ31244 @@ -49,7 +49,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/KB920X b/sys/arm/conf/KB920X index f47e9ac..75980aa 100644 --- a/sys/arm/conf/KB920X +++ b/sys/arm/conf/KB920X @@ -51,7 +51,6 @@ options NFSCLIENT #Network Filesystem Client #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/LN2410SBC b/sys/arm/conf/LN2410SBC index e4f3a54..17a1088 100644 --- a/sys/arm/conf/LN2410SBC +++ b/sys/arm/conf/LN2410SBC @@ -49,7 +49,6 @@ options ROOTDEVNAME=\"ufs:da0s1\" #options NFS_ROOT #NFS usable as root device options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/NSLU b/sys/arm/conf/NSLU index d921e34..1585689 100644 --- a/sys/arm/conf/NSLU +++ b/sys/arm/conf/NSLU @@ -66,7 +66,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/QILA9G20 b/sys/arm/conf/QILA9G20 index 55839ce..e1858fd 100644 --- a/sys/arm/conf/QILA9G20 +++ b/sys/arm/conf/QILA9G20 @@ -57,7 +57,6 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) #options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/SAM9G20EK b/sys/arm/conf/SAM9G20EK index 6c2e94e..21a3f74 100644 --- a/sys/arm/conf/SAM9G20EK +++ b/sys/arm/conf/SAM9G20EK @@ -56,7 +56,6 @@ options ALT_BREAK_TO_DEBUGGER #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) #options PSEUDOFS #Pseudo-filesystem framework -#options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/arm/conf/SKYEYE b/sys/arm/conf/SKYEYE index b3aad2a..e7c843e 100644 --- a/sys/arm/conf/SKYEYE +++ b/sys/arm/conf/SKYEYE @@ -50,7 +50,6 @@ options NFS_ROOT #NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues diff --git a/sys/i386/conf/GENERIC b/sys/i386/conf/GENERIC index 85f4697..e1c0673 100644 --- a/sys/i386/conf/GENERIC +++ b/sys/i386/conf/GENERIC @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/ia64/conf/GENERIC b/sys/ia64/conf/GENERIC index 71af42c..ff43121 100644 --- a/sys/ia64/conf/GENERIC +++ b/sys/ia64/conf/GENERIC @@ -54,7 +54,6 @@ options PRINTF_BUFR_SIZE=128 # Printf buffering to limit interspersion options PROCFS # Process filesystem (/proc) options PSEUDOFS # Pseudo-filesystem framework options SCHED_ULE # ULE scheduler -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options SCTP # Stream Control Transmission Protocol options SMP # Symmetric Multi-Processor support options SOFTUPDATES # Enable FFS soft updates support diff --git a/sys/mips/conf/OCTEON1 b/sys/mips/conf/OCTEON1 index a00e95d..db56e7c 100644 --- a/sys/mips/conf/OCTEON1 +++ b/sys/mips/conf/OCTEON1 @@ -65,7 +65,6 @@ options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization #options COMPAT_FREEBSD32 # Compatible with o32 binaries (not yet) -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/modules/aha/Makefile b/sys/modules/aha/Makefile index 24d356c..052c020 100644 --- a/sys/modules/aha/Makefile +++ b/sys/modules/aha/Makefile @@ -6,9 +6,4 @@ KMOD= aha SRCS= aha.c aha_isa.c ahareg.h opt_cam.h device_if.h bus_if.h \ opt_scsi.h isa_if.h -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include diff --git a/sys/modules/ahb/Makefile b/sys/modules/ahb/Makefile index 2616226..afb36f3 100644 --- a/sys/modules/ahb/Makefile +++ b/sys/modules/ahb/Makefile @@ -5,9 +5,4 @@ KMOD= ahb SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h opt_scsi.h -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include diff --git a/sys/modules/cam/Makefile b/sys/modules/cam/Makefile index df0d77d..4391b15 100644 --- a/sys/modules/cam/Makefile +++ b/sys/modules/cam/Makefile @@ -35,9 +35,4 @@ SRCS+= ata_pmp.c EXPORT_SYMS= YES # XXX evaluate -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include diff --git a/sys/modules/trm/Makefile b/sys/modules/trm/Makefile index 48df9f5..7c42e40 100644 --- a/sys/modules/trm/Makefile +++ b/sys/modules/trm/Makefile @@ -6,9 +6,4 @@ KMOD= trm SRCS= trm.c trm.h opt_cam.h device_if.h bus_if.h \ opt_scsi.h pci_if.h -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include diff --git a/sys/pc98/conf/GENERIC b/sys/pc98/conf/GENERIC index e137297..df937c6 100644 --- a/sys/pc98/conf/GENERIC +++ b/sys/pc98/conf/GENERIC @@ -50,7 +50,6 @@ options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options EPSON_BOUNCEDMA # use bounce buffer for 15-16M #options EPSON_MEMWIN # EPSON memory window support #options LINE30 diff --git a/sys/powerpc/conf/GENERIC b/sys/powerpc/conf/GENERIC index c23e9ac..5f44ee8 100644 --- a/sys/powerpc/conf/GENERIC +++ b/sys/powerpc/conf/GENERIC @@ -54,7 +54,6 @@ options COMPAT_FREEBSD4 #Keep this for a while options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options COMPAT_FREEBSD7 #Compatible with FreeBSD7 -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) syscall trace support options STACK #stack(9) support options SYSVSHM #SYSV-style shared memory diff --git a/sys/powerpc/conf/GENERIC64 b/sys/powerpc/conf/GENERIC64 index b861e51..9127c01 100644 --- a/sys/powerpc/conf/GENERIC64 +++ b/sys/powerpc/conf/GENERIC64 @@ -53,7 +53,6 @@ options COMPAT_FREEBSD32 #Compatible with FreeBSD/powerpc binaries options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options COMPAT_FREEBSD7 #Compatible with FreeBSD7 -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) syscall trace support options STACK #stack(9) support options SYSVSHM #SYSV-style shared memory diff --git a/sys/sparc64/conf/GENERIC b/sys/sparc64/conf/GENERIC index 6bbd4e1..60226d0 100644 --- a/sys/sparc64/conf/GENERIC +++ b/sys/sparc64/conf/GENERIC @@ -50,7 +50,6 @@ options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory diff --git a/sys/sun4v/conf/GENERIC b/sys/sun4v/conf/GENERIC index 74fc036..0508048 100644 --- a/sys/sun4v/conf/GENERIC +++ b/sys/sun4v/conf/GENERIC @@ -51,7 +51,6 @@ options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization -options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory --zhXaljGHf11kAtnf-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 19:22:45 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F5B1065672; Tue, 19 Oct 2010 19:22:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE2AC8FC14; Tue, 19 Oct 2010 19:22:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 791FC46BA5; Tue, 19 Oct 2010 15:22:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 676508A009; Tue, 19 Oct 2010 15:22:43 -0400 (EDT) From: John Baldwin To: Alexander Best Date: Tue, 19 Oct 2010 15:22:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101018235318.GA87158@freebsd.org> <201010191103.50986.jhb@freebsd.org> <20101019191446.GA44841@freebsd.org> In-Reply-To: <20101019191446.GA44841@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010191522.21357.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 15:22:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:22:45 -0000 On Tuesday, October 19, 2010 3:14:46 pm Alexander Best wrote: > On Tue Oct 19 10, John Baldwin wrote: > > On Tuesday, October 19, 2010 10:31:10 am Alexander Best wrote: > > > On Tue Oct 19 10, Matthew Jacob wrote: > > > > It would be an effective behavioral change for those of us who remove > > > > that line. > > > > Personally, I think 5 seconds is too long- even 2 seconds is more than > > > > adequate even for moderately old 'other' hardware like scanners. > > > > > > > > For -current, why don't you simply remove all of the config lines and > > > > leave the default at 2000ms? > > > > > > hmmm...i can only test the delay value on amd64. i was under the impression > > > that archs like arm and mips need the longer delay. > > > > > > also at some locations in the code SCSI_DELAY is being set to 15000. i believe > > > this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel > > > module, but i'm not sure. it looks like this: > > > > > > .if !defined(KERNBUILDDIR) > > > opt_scsi.h: > > > echo "#define SCSI_DELAY 15000" > ${.TARGET} > > > .endif > > > > I believe this is all old history. SCSI_DELAY used to be set to 15000 in > > GENERIC many years ago and was lowered to 5000. Most likely these Makefiles > > were simply not updated at the time. > > oh i see. maybe this revised patch would be better suited then. I think so, but you should post this to scsi@ for the best review. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 20:28:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85BDA106566B for ; Tue, 19 Oct 2010 20:28:13 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 3F23F8FC13 for ; Tue, 19 Oct 2010 20:28:13 +0000 (UTC) Received: from 75-199-132-95.pool.ukrtel.net ([95.132.199.75] helo=localhost) by fsm1.ukr.net with esmtps ID 1P8In5-000Ix2-H6 ; Tue, 19 Oct 2010 23:28:11 +0300 Date: Tue, 19 Oct 2010 23:28:10 +0300 From: Ivan Klymenko To: Jack Engqvist Johansson Message-ID: <20101019232810.06048e38@ukr.net> In-Reply-To: References: <20101019093023.5efb3bcb@ukr.net> <20101019163826.63c7d632@ukr.net> <20101019171001.6fed1b70@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:28:13 -0000 =D0=92 Tue, 19 Oct 2010 16:31:55 +0200 Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> bsd# du -chd0 /root > >> 457M =C2=A0/root > >> 457M =C2=A0total > > > > !!!!!! > > do not use the Root account to work in the system! > > !!!!!! > > Create another account for this... > > go to this directory (/root) and delete the files that take up much > > space and you're free ~ 450Mb... > > > >> bsd# du -chd0 /sbin > >> 4.6M =C2=A0/sbin > >> 4.6M =C2=A0total > >> >=20 > It was the .local folder in /root! Got my kernel back :) Thanks! >=20 > You mean that I should create a user within the group wheel? Yes. > Now, I use my user (jack) and just type 'su' to get root access. Or do > you mean sudo? Why do you need to run jackd with root user account? And how do you use it? Through QjackCtl? From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 20:36:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B94B71065674 for ; Tue, 19 Oct 2010 20:36:41 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 71F9D8FC1B for ; Tue, 19 Oct 2010 20:36:41 +0000 (UTC) Received: from 75-199-132-95.pool.ukrtel.net ([95.132.199.75] helo=localhost) by fsm1.ukr.net with esmtps ID 1P8IvI-000K2N-6f ; Tue, 19 Oct 2010 23:36:40 +0300 Date: Tue, 19 Oct 2010 23:36:39 +0300 From: Ivan Klymenko To: Ivan Klymenko Message-ID: <20101019233639.161d36e2@ukr.net> In-Reply-To: <20101019232810.06048e38@ukr.net> References: <20101019093023.5efb3bcb@ukr.net> <20101019163826.63c7d632@ukr.net> <20101019171001.6fed1b70@ukr.net> <20101019232810.06048e38@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Jack Engqvist Johansson Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:36:41 -0000 =D0=92 Tue, 19 Oct 2010 23:28:10 +0300 Ivan Klymenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > =D0=92 Tue, 19 Oct 2010 16:31:55 +0200 > Jack Engqvist Johansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > >> bsd# du -chd0 /root > > >> 457M =C2=A0/root > > >> 457M =C2=A0total > > > > > > !!!!!! > > > do not use the Root account to work in the system! > > > !!!!!! > > > Create another account for this... > > > go to this directory (/root) and delete the files that take up > > > much space and you're free ~ 450Mb... > > > > > >> bsd# du -chd0 /sbin > > >> 4.6M =C2=A0/sbin > > >> 4.6M =C2=A0total > > >> > >=20 > > It was the .local folder in /root! Got my kernel back :) Thanks! > >=20 > > You mean that I should create a user within the group wheel? >=20 > Yes. >=20 > > Now, I use my user (jack) and just type 'su' to get root access. Or > > do you mean sudo? >=20 > Why do you need to run jackd with root user account? > And how do you use it? Through QjackCtl? Excuse me - did not understand:) Yes, of course - to access root using 'sudo', and if the user (jack) is als= o added to the group wheel, then you can use 'su' ... Sorry for my English ... From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 21:11:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E11106564A for ; Tue, 19 Oct 2010 21:11:40 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3188FC15 for ; Tue, 19 Oct 2010 21:11:39 +0000 (UTC) Received: by wyb38 with SMTP id 38so3046255wyb.13 for ; Tue, 19 Oct 2010 14:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=PSpmMkJRrfMELXXP51tcNabO2mnNHpvZBXw0I/oHxEM=; b=ndIea34pzatGJWcI6fIIf3qa4t5D51+ifIlOlXgpgfJgXXZQWzCZ0ZJZvHJ3/eyOks 4eMzK68DNBJlpNbFC6qGz6YfyLoEr49A5MjzmYpJXIX+YbkKwqmIARiqHSV5VvKUmxmm wnWd/OL4jVlgp3d5ohJz449dGmB6X/wC/6ScY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=fq34UAq8jCtZ10KmnnwHsKRxHkub28o+NhVYOq60rzKtd7mcs/v0EDMh1VYFjt3dqv 9qp2tfrlOfkE1/w/PETZ86mtviwDCuatRmWhWkcnMcVnTnsmyvdkI9/woPXnVMvCzPPm SX1Xtee1JfDCDBfE+q3hThamGVEiZzC83Zym4= Received: by 10.227.142.84 with SMTP id p20mr2581951wbu.182.1287521199197; Tue, 19 Oct 2010 13:46:39 -0700 (PDT) Received: from viper.internal.network (dsl78-143-207-168.in-addr.fast.co.uk [78.143.207.168]) by mx.google.com with ESMTPS id h29sm15317827wbc.3.2010.10.19.13.46.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Oct 2010 13:46:37 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 34B254AC0A; Tue, 19 Oct 2010 20:44:10 +0000 (UTC) Date: Tue, 19 Oct 2010 20:44:10 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20101019204409.GA5603@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Radeon DRI/3D status X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:11:40 -0000 Hello. What's the current status of DRI/3D support with the 4xxx range of ATI cards? I'm on 8.0-RELEASE and have just installed a (borrowed) 4870 card. I get working dual monitor support but only software rasterization in xorg. The intention is to replace a broken x1950 card with something at least slightly newer but I can't find any real information (other than an apparently outdated wiki page) that suggests anything is or isn't supported. Failing that, I'll take anything with half decent 3D support that doesn't require a blob... xw From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 21:29:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD1210656F6 for ; Tue, 19 Oct 2010 21:29:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57E038FC18 for ; Tue, 19 Oct 2010 21:29:25 +0000 (UTC) Received: by ewy21 with SMTP id 21so2113262ewy.13 for ; Tue, 19 Oct 2010 14:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=q5TKUOTyNCe0CcgE9GX0jzpcn8rcTJzWiTjn0NH9c38=; b=rARGFvegU0tNaOZ/lVWcSoJrmcHm6/SaOIdZdTGl4Yu+B2wX6z/S16sTUmjNedPb84 tVNaA1Hdk6ft0ofctBADVcMeX9ezAXZGkMoxlbEC0yBb736ms0ocl4ehglaDodanzClt Jg2i5DX6dVlf3DZcIaNQae/9xgCDCIDTEHWhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=k3g3EOtAxEPDwqhdh0XXRDBW4iwdnT1mOcMbUUq7Bjey3bUP+jRhKrcnNGew0ObSOz 9pPb75mmrDh+cN+I6ZjNzHU0iKTC650PYzcN4BL+6zluOBbKuzEpJxGtO4Kk7M/IuNcG U4I8SzOamvkDm02NA84VK7Q+/XH51Aj+XsfiM= MIME-Version: 1.0 Received: by 10.216.156.146 with SMTP id m18mr4716499wek.1.1287523764914; Tue, 19 Oct 2010 14:29:24 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.135.67 with HTTP; Tue, 19 Oct 2010 14:29:24 -0700 (PDT) In-Reply-To: <20101019233639.161d36e2@ukr.net> References: <20101019093023.5efb3bcb@ukr.net> <20101019163826.63c7d632@ukr.net> <20101019171001.6fed1b70@ukr.net> <20101019232810.06048e38@ukr.net> <20101019233639.161d36e2@ukr.net> Date: Tue, 19 Oct 2010 14:29:24 -0700 X-Google-Sender-Auth: oYj21NkmkPJz8ZOLoCLRjO5yce0 Message-ID: From: Garrett Cooper To: Ivan Klymenko Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Jack Engqvist Johansson Subject: Re: Filesystem full when installing custom kernel in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:29:26 -0000 On Tue, Oct 19, 2010 at 1:36 PM, Ivan Klymenko wrote: > =F7 Tue, 19 Oct 2010 23:28:10 +0300 > Ivan Klymenko =D0=C9=DB=C5=D4: > >> =F7 Tue, 19 Oct 2010 16:31:55 +0200 >> Jack Engqvist Johansson =D0=C9=DB=C5=D4: >> >> > >> bsd# du -chd0 /root >> > >> 457M =9A/root >> > >> 457M =9Atotal >> > > >> > > !!!!!! >> > > do not use the Root account to work in the system! >> > > !!!!!! >> > > Create another account for this... >> > > go to this directory (/root) and delete the files that take up >> > > much space and you're free ~ 450Mb... >> > > >> > >> bsd# du -chd0 /sbin >> > >> 4.6M =9A/sbin >> > >> 4.6M =9Atotal >> > >> >> > >> > It was the .local folder in /root! Got my kernel back :) Thanks! >> > >> > You mean that I should create a user within the group wheel? >> >> Yes. >> >> > Now, I use my user (jack) and just type 'su' to get root access. Or >> > do you mean sudo? >> >> Why do you need to run jackd with root user account? >> And how do you use it? Through QjackCtl? > > Excuse me - did not understand:) > > Yes, of course - to access root using 'sudo', and if the user (jack) is a= lso added to the group wheel, then you can use 'su' ... > > Sorry for my English ... Could you guys please take this question to questions@? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 19 23:36:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 77FCE106566B; Tue, 19 Oct 2010 23:36:56 +0000 (UTC) Date: Tue, 19 Oct 2010 23:36:56 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101019233656.GA84316@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: addition of sysctl nodes after compile time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 23:36:56 -0000 hi there, i stumbled upon this note in the BUGS section of the cd(4) manual: "There is no mechanism currently to set different minimum and maximum timeouts for different CD changers; the timeout values set by the kernel options or the sysctl variables apply to all LUN-based CD changers in the system. It is possible to implement such support, but the sysctl imple- mentation at least would be rather inelegant, because of the current inability of the sysctl code to handle the addition of nodes after com- pile time. Thus, it would take one dynamically sized sysctl variable and a userland utility to get/set the timeout values. Implementation of sep- arate timeouts for different CD devices in the kernel config file would likely require modification of config(8) to support the two timeouts when hardwiring cd devices." does this limitation still exist? cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 00:39:00 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49654106566B; Wed, 20 Oct 2010 00:39:00 +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 0A3D08FC12; Wed, 20 Oct 2010 00:38:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9K0YxV2017829; Tue, 19 Oct 2010 18:34:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Oct 2010 18:34:59 -0600 (MDT) Message-Id: <20101019.183459.74735773.imp@bsdimp.com> To: arundel@FreeBSD.org From: Warner Losh In-Reply-To: <20101019143110.GA5802@freebsd.org> References: <20101019103432.GA69208@freebsd.org> <4CBDA371.4080801@feral.com> <20101019143110.GA5802@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, mj@feral.com Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:39:00 -0000 > also at some locations in the code SCSI_DELAY is being set to 15000. i believe > this is the case when certain drivers (cam, ahb, aha) get loaded as a kernel > module, but i'm not sure. it looks like this: > > .if !defined(KERNBUILDDIR) > opt_scsi.h: > echo "#define SCSI_DELAY 15000" > ${.TARGET} > .endif These likely are hold-overs from ancient days where the default was 15s... I'd be surprised if aha still even worked, but I have no way to test it easily these days: I have the cards but no active systems with ISA slots. ahb never was my baby, but my only EISA system has been off for at least 4 years now, and likely won't be turned back on ever... But regardless, neither of these controllers references SCSI_DELAY. Cam likely can remove it safely as well, but I'd be more leery of doing it there since I'm chicken :) Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 00:45:10 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D64C1065674; Wed, 20 Oct 2010 00:45:10 +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 D2FE38FC12; Wed, 20 Oct 2010 00:45:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9K0dfiM017875; Tue, 19 Oct 2010 18:39:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Oct 2010 18:39:41 -0600 (MDT) Message-Id: <20101019.183941.41645397.imp@bsdimp.com> To: jhb@FreeBSD.org From: Warner Losh In-Reply-To: <201010191522.21357.jhb@freebsd.org> References: <201010191103.50986.jhb@freebsd.org> <20101019191446.GA44841@freebsd.org> <201010191522.21357.jhb@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arundel@FreeBSD.org, mj@feral.com, freebsd-hackers@FreeBSD.org Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:45:10 -0000 opt_scsi.h isn't needed by aha or ahb either, so it can be deleted entirely from their module makefiles: Index: aha/Makefile =================================================================== --- aha/Makefile (revision 214058) +++ aha/Makefile (working copy) @@ -4,11 +4,6 @@ KMOD= aha SRCS= aha.c aha_isa.c ahareg.h opt_cam.h device_if.h bus_if.h \ - opt_scsi.h isa_if.h + isa_if.h -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include Index: ahb/Makefile =================================================================== --- ahb/Makefile (revision 214058) +++ ahb/Makefile (working copy) @@ -3,11 +3,6 @@ .PATH: ${.CURDIR}/../../dev/ahb KMOD= ahb -SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h opt_scsi.h +SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h -.if !defined(KERNBUILDDIR) -opt_scsi.h: - echo "#define SCSI_DELAY 15000" > ${.TARGET} -.endif - .include From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 00:57:03 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DB0551065675; Wed, 20 Oct 2010 00:57:03 +0000 (UTC) Date: Wed, 20 Oct 2010 00:57:03 +0000 From: Alexander Best To: Warner Losh Message-ID: <20101020005703.GA94547@freebsd.org> References: <201010191103.50986.jhb@freebsd.org> <20101019191446.GA44841@freebsd.org> <201010191522.21357.jhb@freebsd.org> <20101019.183941.41645397.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101019.183941.41645397.imp@bsdimp.com> Cc: freebsd-hackers@FreeBSD.org, mj@feral.com, jhb@FreeBSD.org Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:57:03 -0000 On Tue Oct 19 10, Warner Losh wrote: > opt_scsi.h isn't needed by aha or ahb either, so it can be deleted > entirely from their module makefiles: thanks. :) what about trb/Makefile? seems to build fine too without opt_scsi.h. > > Index: aha/Makefile > =================================================================== > --- aha/Makefile (revision 214058) > +++ aha/Makefile (working copy) > @@ -4,11 +4,6 @@ > > KMOD= aha > SRCS= aha.c aha_isa.c ahareg.h opt_cam.h device_if.h bus_if.h \ > - opt_scsi.h isa_if.h > + isa_if.h > > -.if !defined(KERNBUILDDIR) > -opt_scsi.h: > - echo "#define SCSI_DELAY 15000" > ${.TARGET} > -.endif > - > .include > Index: ahb/Makefile > =================================================================== > --- ahb/Makefile (revision 214058) > +++ ahb/Makefile (working copy) > @@ -3,11 +3,6 @@ > .PATH: ${.CURDIR}/../../dev/ahb > > KMOD= ahb > -SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h opt_scsi.h > +SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h > > -.if !defined(KERNBUILDDIR) > -opt_scsi.h: > - echo "#define SCSI_DELAY 15000" > ${.TARGET} > -.endif > - > .include -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 00:57:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72388106564A for ; Wed, 20 Oct 2010 00:57:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-26.mx.aerioconnect.net [216.240.47.86]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDF88FC0C for ; Wed, 20 Oct 2010 00:57:34 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9K0vTts004543; Tue, 19 Oct 2010 17:57:29 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 658522D6015; Tue, 19 Oct 2010 17:57:28 -0700 (PDT) Message-ID: <4CBE3EAC.4040302@freebsd.org> Date: Tue, 19 Oct 2010 17:58:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Warner Losh References: <201010191103.50986.jhb@freebsd.org> <20101019191446.GA44841@freebsd.org> <201010191522.21357.jhb@freebsd.org> <20101019.183941.41645397.imp@bsdimp.com> In-Reply-To: <20101019.183941.41645397.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: arundel@freebsd.org, mj@feral.com, freebsd-hackers@freebsd.org Subject: Re: SCSI_DELAY cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:57:34 -0000 On 10/19/10 5:39 PM, Warner Losh wrote: > opt_scsi.h isn't needed by aha or ahb either, so it can be deleted > entirely from their module makefiles: > consider I write the original aha driver in 1991 and it is an ISA device, one wonders if there are any users of this any more.. > Index: aha/Makefile > =================================================================== > --- aha/Makefile (revision 214058) > +++ aha/Makefile (working copy) > @@ -4,11 +4,6 @@ > > KMOD= aha > SRCS= aha.c aha_isa.c ahareg.h opt_cam.h device_if.h bus_if.h \ > - opt_scsi.h isa_if.h > + isa_if.h > > -.if !defined(KERNBUILDDIR) > -opt_scsi.h: > - echo "#define SCSI_DELAY 15000"> ${.TARGET} > -.endif > - > .include > Index: ahb/Makefile > =================================================================== > --- ahb/Makefile (revision 214058) > +++ ahb/Makefile (working copy) > @@ -3,11 +3,6 @@ > .PATH: ${.CURDIR}/../../dev/ahb > > KMOD= ahb > -SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h opt_scsi.h > +SRCS= ahb.c opt_cam.h device_if.h bus_if.h eisa_if.h > > -.if !defined(KERNBUILDDIR) > -opt_scsi.h: > - echo "#define SCSI_DELAY 15000"> ${.TARGET} > -.endif > - > .include > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 01:58:15 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E18C106566B for ; Wed, 20 Oct 2010 01:58:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A783E8FC19 for ; Wed, 20 Oct 2010 01:58:14 +0000 (UTC) Received: by wyb38 with SMTP id 38so3290490wyb.13 for ; Tue, 19 Oct 2010 18:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=v/PxsBJuwJzkL9asci6Ulr1HN7InMRbCjNnbiCRHN9Q=; b=MRrXGr68Q7S+vVitdud96U2KGghXjy3xig8NLuZiOI9i8HKccGzn4k2hTX+ILk3YtA bEG7UQ1tIUiErEw1g1LS3jSb0fRXInq+crPUYSX/S6aPZdKg8IgZsN7nzgK3M8k3H2SP hb3YK2yMEDOacYvTMBX7tGadIAPJQN75kdSo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=U0xJHw6bTKAi+/qj9rJPZlcqH6LALikfS9niAZbchKQxc4WzARiFky2Ej/WG/egnjk Wa8Z2TLFyK3XT5fIYQQRZ9WPzsixf3n0yL1vdTpDOyk5z5+kn8PfUDNdDOxv4L4jtzDo U+Uz6DHxI1+3YSOGWH49SIeVU+pwmVb6SXCp0= MIME-Version: 1.0 Received: by 10.216.181.193 with SMTP id l43mr6960329wem.78.1287539893370; Tue, 19 Oct 2010 18:58:13 -0700 (PDT) Received: by 10.216.135.67 with HTTP; Tue, 19 Oct 2010 18:58:13 -0700 (PDT) Date: Tue, 19 Oct 2010 18:58:13 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016367b600cfa80eb049302bd03 Subject: device.hints(5) typo fix X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 01:58:15 -0000 --0016367b600cfa80eb049302bd03 Content-Type: text/plain; charset=ISO-8859-1 Something trivial I noticed while browsing device.hints(5) today. If someone could commit the typo fix, it would be much appreciated. Cheers! -Garrett --0016367b600cfa80eb049302bd03 Content-Type: text/x-patch; charset=US-ASCII; name="fix-device-hints-5-typo.patch" Content-Disposition: attachment; filename="fix-device-hints-5-typo.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfhjzdcx0 SW5kZXg6IHNoYXJlL21hbi9tYW41L2RldmljZS5oaW50cy41Cj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJl L21hbi9tYW41L2RldmljZS5oaW50cy41CShyZXZpc2lvbiAyMTQwOTIpCisrKyBzaGFyZS9tYW4v bWFuNS9kZXZpY2UuaGludHMuNQkod29ya2luZyBjb3B5KQpAQCAtMTYxLDcgKzE2MSw3IEBACiAu U2ggU0VFIEFMU08KIC5YciBrZW52IDEgLAogLlhyIGxvYWRlci5jb25mIDUgLAotLlhyIGxvYWRl ciA4LAorLlhyIGxvYWRlciA4ICwKIC5YciByZXNvdXJjZV9pbnRfdmFsdWUgOSAuCiAuU2ggSElT VE9SWQogVGhlCg== --0016367b600cfa80eb049302bd03-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 04:35:15 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC0FD1065675; Wed, 20 Oct 2010 04:35:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CBA618FC08; Wed, 20 Oct 2010 04:35:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA21008; Wed, 20 Oct 2010 07:35:13 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P8QOO-0004Jm-QJ; Wed, 20 Oct 2010 07:35:12 +0300 Message-ID: <4CBE717F.30401@icyb.net.ua> Date: Wed, 20 Oct 2010 07:35:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Best References: <20101019233656.GA84316@freebsd.org> In-Reply-To: <20101019233656.GA84316@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: addition of sysctl nodes after compile time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 04:35:15 -0000 on 20/10/2010 02:36 Alexander Best said the following: [snip] > mentation at least would be rather inelegant, because of the current > inability of the sysctl code to handle the addition of nodes after com- > pile time. Thus, it would take one dynamically sized sysctl variable and [snip] > does this limitation still exist? I don't think so. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 08:10:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92F00106564A; Wed, 20 Oct 2010 08:10:22 +0000 (UTC) (envelope-from mureninc@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 395E78FC12; Wed, 20 Oct 2010 08:10:21 +0000 (UTC) Received: by yxe42 with SMTP id 42so908569yxe.13 for ; Wed, 20 Oct 2010 01:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CyHRymLrLR7NuG1mFRAxaK61X8Nv39HeJIHb41tOVD0=; b=ux2oSGtgV8cqYUL6aDI9RyZZE8MrDMywAQIieR9KvHHftd+dWTGTcoSEsZRi5urowA l+kqFb4zHF5GrHnN8NRXnxwrQHsu0NEBeAOuPP9ldY/E7491mOUiGjiDkuJyemMpC2hj Y+kOLlsMvMH3k5p1F82LTBAv2YaKIYgN065/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J5nvmA36Ehs3rN10wKl3caHNPG1H/BWXc7bcEZZFp0XjE2vxWbI2p04XGaK7iB7xlH PdyZU44akADkD5dE5SpEJAIhUz+lAY1wZ9UxO/NEXL+dUAI7Fx+HG+e6zsQtuUA5Cofm D2NQtikb54OPtJUT8VhSGM7jILVzTtvbTpeqA= MIME-Version: 1.0 Received: by 10.100.96.14 with SMTP id t14mr793830anb.269.1287560683996; Wed, 20 Oct 2010 00:44:43 -0700 (PDT) Received: by 10.101.59.19 with HTTP; Wed, 20 Oct 2010 00:44:43 -0700 (PDT) In-Reply-To: <20101019233656.GA84316@freebsd.org> References: <20101019233656.GA84316@freebsd.org> Date: Wed, 20 Oct 2010 00:44:43 -0700 Message-ID: From: "Constantine A. Murenin" To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: addition of sysctl nodes after compile time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 08:10:22 -0000 On 19 October 2010 16:36, Alexander Best wrote: > hi there, > > i stumbled upon this note in the BUGS section of the cd(4) manual: > > =A0 =A0"There is no mechanism currently to set different minimum and maxi= mum > =A0 =A0 timeouts for different CD changers; the timeout values set by the= kernel > =A0 =A0 options or the sysctl variables apply to all LUN-based CD changer= s in the > =A0 =A0 system. =A0It is possible to implement such support, but the sysc= tl imple- > =A0 =A0 mentation at least would be rather inelegant, because of the curr= ent > =A0 =A0 inability of the sysctl code to handle the addition of nodes afte= r com- > =A0 =A0 pile time. =A0Thus, it would take one dynamically sized sysctl va= riable and > =A0 =A0 a userland utility to get/set the timeout values. =A0Implementati= on of sep- > =A0 =A0 arate timeouts for different CD devices in the kernel config file= would > =A0 =A0 likely require modification of config(8) to support the two timeo= uts when > =A0 =A0 hardwiring cd devices." > > does this limitation still exist? > > cheers. > alex No, the limitation is no longer present. See sysctl_add_oid(9) for more details. C. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 04:53:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 393301065670 for ; Wed, 20 Oct 2010 04:53:16 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (unknown [IPv6:2a02:28:1:2::1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id 93EA48FC0A for ; Wed, 20 Oct 2010 04:53:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.3/8.14.3) with ESMTP id o9K4rE1e007222; Wed, 20 Oct 2010 08:53:14 +0400 (MSD) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 20 Oct 2010 08:53:14 +0400 (MSD) From: Maxim Konovalov To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 20 Oct 2010 11:21:08 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: device.hints(5) typo fix X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 04:53:16 -0000 On Tue, 19 Oct 2010, 18:58-0700, Garrett Cooper wrote: > Something trivial I noticed while browsing device.hints(5) today. > If someone could commit the typo fix, it would be much appreciated. Fixed. Thanks! -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 08:52:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7C01065695; Thu, 21 Oct 2010 08:52:22 +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 274F18FC08; Thu, 21 Oct 2010 08:52:22 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B1DDB46B39; Thu, 21 Oct 2010 04:52:21 -0400 (EDT) Date: Thu, 21 Oct 2010 09:52:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Best In-Reply-To: <20101019233656.GA84316@freebsd.org> Message-ID: References: <20101019233656.GA84316@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-hackers@freebsd.org Subject: Re: addition of sysctl nodes after compile time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 08:52:22 -0000 On Tue, 19 Oct 2010, Alexander Best wrote: > does this limitation still exist? Sysctls can be added dynamically using the sysctl_add_oid(9) KPI, which has existed (as far as I'm aware) at least since FreeBSD 4.x. It could be that this KPI provides the functionality required to do what the comment describes. Robert From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 12:02:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7FD310656B6; Thu, 21 Oct 2010 12:02:38 +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 63DE08FC2A; Thu, 21 Oct 2010 12:02:38 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3103C1FFC53; Thu, 21 Oct 2010 12:02:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E938D8454C; Thu, 21 Oct 2010 13:57:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> Date: Thu, 21 Oct 2010 13:57:56 +0200 In-Reply-To: <20101018155944.GA12425@freebsd.org> (Alexander Best's message of "Mon, 18 Oct 2010 15:59:44 +0000") Message-ID: <868w1r92rf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:02:38 -0000 Alexander Best writes: > since there seems no way to distinguish between these two states in ATA(4= ) it's > probably better to leave it as it is, since doing spin downs upon reboot = might > be even worse than not doing spindowns upon shutdown. No. Where did you get that idea? To repeat what I've said before - several times - in this thread, a modern disk drive can handle hundreds of thousands of controlled unloads but only a few hundred emergency unloads. Given the choice between "never spin down" and "always spin down", the safe alternative is "always spin down". DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 12:21:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 363D71065670; Thu, 21 Oct 2010 12:21:10 +0000 (UTC) Date: Thu, 21 Oct 2010 12:21:10 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20101021122110.GA65490@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <868w1r92rf.fsf@ds4.des.no> Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:21:10 -0000 On Thu Oct 21 10, Dag-Erling Smørgrav wrote: > Alexander Best writes: > > since there seems no way to distinguish between these two states in ATA(4) it's > > probably better to leave it as it is, since doing spin downs upon reboot might > > be even worse than not doing spindowns upon shutdown. > > No. Where did you get that idea? To repeat what I've said before - > several times - in this thread, a modern disk drive can handle hundreds > of thousands of controlled unloads but only a few hundred emergency > unloads. Given the choice between "never spin down" and "always spin > down", the safe alternative is "always spin down". atacontrol(8) says that: "You should not set a spindown timeout on a disk with / or syslog logging on it as the disk will be worn out spinning down and up all the time." this seems to indicate that spinning down a disk has quite an impact. while chatting with bruce cran regarding this matter we discovered that mav@ already implemented this feature back in february, but disabled it by default due to issues with the aac controller. the current implementation (kern.cam.power_down) uses a singe "sleep" operation, whereas the patch by oliver uses "flush" and "standby immediate". unfortunately almost nobody was aware of mav's work at the time of the discussion. would have been nice to have a note in cam(4) explaining the purpose of kern.cam.power_down. that way a lot of double work could have been avoided. is the ATA(4) subsystem still being actively worked on or will it die out after officially switching to ATA_CAM? the question is, if it is worth implementing hdd spin down for ATA(4)? cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 12:38:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE84210656A9; Thu, 21 Oct 2010 12:38:30 +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 7A8C98FC14; Thu, 21 Oct 2010 12:38:30 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7AEFD1FFC34; Thu, 21 Oct 2010 12:38:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 56064845D7; Thu, 21 Oct 2010 14:33:49 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> Date: Thu, 21 Oct 2010 14:33:49 +0200 In-Reply-To: <20101021122110.GA65490@freebsd.org> (Alexander Best's message of "Thu, 21 Oct 2010 12:21:10 +0000") Message-ID: <86zku77mj6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:38:30 -0000 Alexander Best writes: > Dag-Erling Sm=C3=B8rgrav writes: > > No. Where did you get that idea? To repeat what I've said before - > > several times - in this thread, a modern disk drive can handle hundreds > > of thousands of controlled unloads but only a few hundred emergency > > unloads. Given the choice between "never spin down" and "always spin > > down", the safe alternative is "always spin down". > atacontrol(8) says that: > > "You should not set a spindown timeout on a disk with / or syslog log= ging > on it as the disk will be worn out spinning down and up all the time= ." > > this seems to indicate that spinning down a disk has quite an impact. The problem with setting a short idle timeout is that, on a typical laptop or desktop system, you end up spinning the disk down and back up several hundred times a day, which increases power consumption, I/O latency and wear. However, a single emergency unload (what happens when the disk loses power without first unloading the head) shortens the disk's life expectancy as much as hundreds or thousands of controlled unloads. Unless you think our users commonly reboot their computers hundreds or thousands of times between each time they cycle the power, the safe alternative is to *always* spin down during shutdown. I truly hope this is the *last* time I have to repeat this. It's really not that hard to understand. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 12:54:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33EB4106566B; Thu, 21 Oct 2010 12:54:46 +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 BE8158FC14; Thu, 21 Oct 2010 12:54:45 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id DBFC7E83C0; Thu, 21 Oct 2010 13:54:44 +0100 (BST) Received: from unknown (host86-189-15-86.range86-189.btcentralplus.com [86.189.15.86]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 21 Oct 2010 13:54:43 +0100 (BST) Date: Thu, 21 Oct 2010 13:54:42 +0100 From: Bruce Cran To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-ID: <20101021135442.000054c9@unknown> In-Reply-To: <86zku77mj6.fsf@ds4.des.no> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:54:46 -0000 On Thu, 21 Oct 2010 14:33:49 +0200 Dag-Erling Sm=F8rgrav wrote: > The problem with setting a short idle timeout is that, on a typical > laptop or desktop system, you end up spinning the disk down and back > up several hundred times a day, which increases power consumption, I/O > latency and wear. Do we think our users are silly enough to set a short timeout of just a few minutes? I'd think most would use a setting of 20-30 minutes at a minimum. I never did understand why there were so many warnings; after all, some laptops even come with a default APM scheme in their HDDs that powers the disk down after 7 seconds! --=20 Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 13:07:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 166A11065672; Thu, 21 Oct 2010 13:07:31 +0000 (UTC) Date: Thu, 21 Oct 2010 13:07:31 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20101021130730.GA72290@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86zku77mj6.fsf@ds4.des.no> Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:07:31 -0000 On Thu Oct 21 10, Dag-Erling Smørgrav wrote: > Alexander Best writes: > > Dag-Erling Smørgrav writes: > > > No. Where did you get that idea? To repeat what I've said before - > > > several times - in this thread, a modern disk drive can handle hundreds > > > of thousands of controlled unloads but only a few hundred emergency > > > unloads. Given the choice between "never spin down" and "always spin > > > down", the safe alternative is "always spin down". > > atacontrol(8) says that: > > > > "You should not set a spindown timeout on a disk with / or syslog logging > > on it as the disk will be worn out spinning down and up all the time." > > > > this seems to indicate that spinning down a disk has quite an impact. > > The problem with setting a short idle timeout is that, on a typical > laptop or desktop system, you end up spinning the disk down and back up > several hundred times a day, which increases power consumption, I/O > latency and wear. > > However, a single emergency unload (what happens when the disk loses > power without first unloading the head) shortens the disk's life > expectancy as much as hundreds or thousands of controlled unloads. > > Unless you think our users commonly reboot their computers hundreds or > thousands of times between each time they cycle the power, the safe > alternative is to *always* spin down during shutdown. > > I truly hope this is the *last* time I have to repeat this. It's really > not that hard to understand. no need to get upset. you asked where i found the information regarding the wear impact of spinning down disks and i gave you the answer. i totally agree with you on this issue. yet again: is it worth changing this for the ata(4) sub system which will probably become obsolete in one or two years? the ata(4) subsytem exists since FreeBSD 4.0. why introduce this change now that it's going to die soon? also as i pointed out in my earlier post, spinning down disks already caused problems with the aac controller. since not a lot of testing went into the spin down code one can expect more controller related issues to arise. cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 13:41:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 856961065674; Thu, 21 Oct 2010 13:41:14 +0000 (UTC) Date: Thu, 21 Oct 2010 13:41:14 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20101021134114.GB72290@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101021135442.000054c9@unknown> Cc: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:41:14 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu Oct 21 10, Bruce Cran wrote: > On Thu, 21 Oct 2010 14:33:49 +0200 > Dag-Erling Smørgrav wrote: > > > The problem with setting a short idle timeout is that, on a typical > > laptop or desktop system, you end up spinning the disk down and back > > up several hundred times a day, which increases power consumption, I/O > > latency and wear. > > Do we think our users are silly enough to set a short timeout of just a > few minutes? I'd think most would use a setting of 20-30 minutes at > a minimum. I never did understand why there were so many warnings; > after all, some laptops even come with a default APM scheme in their > HDDs that powers the disk down after 7 seconds! personally i still think something like the attached patch would be nice to have. there's a chance users might type the following: 'atacontrol spindown device 10' thinking the timeout value is measured in minutes. although this gets mentioned in atacontrol(4) it might still be worth reminding the user that he/she is performing actions which could damage the hardware. cheers. alex > > -- > Bruce Cran -- a13x --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="atacontrol.c.diff" diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c index 4354ddf..75a131a 100644 --- a/sbin/atacontrol/atacontrol.c +++ b/sbin/atacontrol/atacontrol.c @@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *arg) if (arg != NULL) { tmo = strtoul(arg, NULL, 0); + if (tmo < 600) + warnx("setting spindown timeout below 10 minutes is \ + not recommended (see EXAMPLES section of \ + atacontrol(8))\n"); if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0) err(1, "ioctl(IOCATASSPINDOWN)"); } else { --9amGYk9869ThD9tj-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 13:45:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1531310656AA; Thu, 21 Oct 2010 13:45:43 +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 C60DD8FC1B; Thu, 21 Oct 2010 13:45:42 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1D8CBE83C0; Thu, 21 Oct 2010 14:45:42 +0100 (BST) Received: from unknown (host86-189-15-86.range86-189.btcentralplus.com [86.189.15.86]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 21 Oct 2010 14:45:40 +0100 (BST) Date: Thu, 21 Oct 2010 14:45:37 +0100 From: Bruce Cran To: Alexander Best Message-ID: <20101021144537.000049eb@unknown> In-Reply-To: <20101021134114.GB72290@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <20101021134114.GB72290@freebsd.org> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:45:43 -0000 On Thu, 21 Oct 2010 13:41:14 +0000 Alexander Best wrote: > personally i still think something like the attached patch would be > nice to have. there's a chance users might type the following: > > 'atacontrol spindown device 10' > > thinking the timeout value is measured in minutes. I agree - users coming from ataidle(8) will expect the timeout to be in minutes too. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 13:58:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75469106564A for ; Thu, 21 Oct 2010 13:58:39 +0000 (UTC) (envelope-from rwmaillists@googlemail.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 05A8D8FC18 for ; Thu, 21 Oct 2010 13:58:38 +0000 (UTC) Received: by wwb13 with SMTP id 13so4120644wwb.31 for ; Thu, 21 Oct 2010 06:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=PSHouJs3Ws5vXL2+PQ1ewuk/A6Lc9/qXH2IKep+pbIc=; b=oRF/rW+eTTtaJC7H0V5N8Ysoef+Kf6g+IT3iK+tqBIbEqPhExKtGDE2m2kgqfoS13C TwJw7hSyMr3L1E1fw03svgnPc3LbTvVrTmH/+rwqpV5JmiPIz9yzwV6nPdz9Ux3jjbJ1 nO9vRGyvm6Nm1sxleFJeImLF0nYAVsSHiLFm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=BZeELszubI35TU2DBc0SGY3O7DmO7uScOAZOgMnlQUtg/N12rDO6zvWmHdgWI9J8AF mrHbwCt4E45UWACmQFE3qyJE64Xd4rIENe+FmmdNDQ5Y0fbPXnFjG7qvVl0QXo70JfHF 11ql9Dg9P5YysYluB1kiilmlHAIFAETiA6RE8= Received: by 10.227.151.205 with SMTP id d13mr142716wbw.159.1287669517623; Thu, 21 Oct 2010 06:58:37 -0700 (PDT) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id w41sm1065061weq.8.2010.10.21.06.58.35 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 06:58:36 -0700 (PDT) Date: Thu, 21 Oct 2010 14:58:31 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20101021145831.7421d4fc@gumby.homeunix.com> In-Reply-To: <20101021122110.GA65490@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 13:58:39 -0000 On Thu, 21 Oct 2010 12:21:10 +0000 Alexander Best wrote: > atacontrol(8) says that: > > "You should not set a spindown timeout on a disk with / or syslog > logging on it as the disk will be worn out spinning down and up all > the time." > > this seems to indicate that spinning down a disk has quite an impact. That's mostly likely a hang-over from older disk technologies when the heads touched the surface on spinning down. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 14:39:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604C1106564A; Thu, 21 Oct 2010 14:39:48 +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 1B5878FC17; Thu, 21 Oct 2010 14:39:47 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DEEE11FFC38; Thu, 21 Oct 2010 14:39:46 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A874D8454C; Thu, 21 Oct 2010 16:35:06 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bruce Cran References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> Date: Thu, 21 Oct 2010 16:35:06 +0200 In-Reply-To: <20101021135442.000054c9@unknown> (Bruce Cran's message of "Thu, 21 Oct 2010 13:54:42 +0100") Message-ID: <86vd4v7gx1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:39:48 -0000 Bruce Cran writes: > Do we think our users are silly enough to set a short timeout of just a > few minutes? I'd think most would use a setting of 20-30 minutes at > a minimum. I never did understand why there were so many warnings; > after all, some laptops even come with a default APM scheme in their > HDDs that powers the disk down after 7 seconds! Really? That would make the system close to unusable, and the disk's life expectancy would be reduced to a few months; a disk that performs two load / unload cycles per minute on average will need replacing after three to six months. Remember, there was a huge flap a couple of years when Ubuntu shipped with a default timeout of 90 seconds, which is more than ten times more than what you suggest. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 14:48:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D8B106564A; Thu, 21 Oct 2010 14:48:25 +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 805318FC12; Thu, 21 Oct 2010 14:48:25 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 85B651FFC61; Thu, 21 Oct 2010 14:48:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 539968454C; Thu, 21 Oct 2010 16:43:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> Date: Thu, 21 Oct 2010 16:43:44 +0200 In-Reply-To: <20101021130730.GA72290@freebsd.org> (Alexander Best's message of "Thu, 21 Oct 2010 13:07:31 +0000") Message-ID: <86r5fj7gin.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, mav@freebsd.org, Tijl Coosemans , Oliver Fromme Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:48:25 -0000 Alexander Best writes: > no need to get upset. you asked where i found the information regarding t= he > wear impact of spinning down disks and i gave you the answer. I am upset by your claim that "doing spin downs upon reboot might be even worse than not doing spindowns upon shutdown", because you should know better, and following your advice could damage people's hardware. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 14:56:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08438106566B for ; Thu, 21 Oct 2010 14:56:08 +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 BA7FA8FC13 for ; Thu, 21 Oct 2010 14:56:07 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B2C691FFC34; Thu, 21 Oct 2010 14:56:06 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8AC1184449; Thu, 21 Oct 2010 16:51:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: RW References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <20101021145831.7421d4fc@gumby.homeunix.com> Date: Thu, 21 Oct 2010 16:51:26 +0200 In-Reply-To: <20101021145831.7421d4fc@gumby.homeunix.com> (RW's message of "Thu, 21 Oct 2010 14:58:31 +0100") Message-ID: <86mxq77g5t.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:56:08 -0000 RW writes: > Alexander Best wrote: > > this seems to indicate that spinning down a disk has quite an impact. > That's mostly likely a hang-over from older disk technologies when the > heads touched the surface on spinning down.=20=20 They still do, although these days the "landing zone" has a special surface designed to minimize friction on the head and prevent it from sticking to the surface. In addition, in an emergency unload (when power is lost while the disk is still spinning) the heads retract in a violent and uncontrolled manner, which can lead to mechanical damage to the arms. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 15:03:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D63851065695; Thu, 21 Oct 2010 15:03:32 +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 95F218FC1C; Thu, 21 Oct 2010 15:03:32 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id DC09BE83C0; Thu, 21 Oct 2010 16:03:31 +0100 (BST) Received: from unknown (unknown [109.144.218.156]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 21 Oct 2010 16:03:30 +0100 (BST) Date: Thu, 21 Oct 2010 16:03:35 +0100 From: Bruce Cran To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-ID: <20101021160335.00001c0a@unknown> In-Reply-To: <86vd4v7gx1.fsf@ds4.des.no> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <86vd4v7gx1.fsf@ds4.des.no> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:03:32 -0000 On Thu, 21 Oct 2010 16:35:06 +0200 Dag-Erling Sm=F8rgrav wrote: > Really? That would make the system close to unusable, and the disk's > life expectancy would be reduced to a few months; a disk that performs > two load / unload cycles per minute on average will need replacing > after three to six months. Remember, there was a huge flap a couple > of years when Ubuntu shipped with a default timeout of 90 seconds, > which is more than ten times more than what you suggest. The Ubuntu issue was what I was thinking of - I got that mixed up with the aggressive power management of the WD EARS drives. --=20 Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 15:25:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA40E106566B; Thu, 21 Oct 2010 15:25:36 +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 64ED38FC19; Thu, 21 Oct 2010 15:25:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3CA1A1FFC34; Thu, 21 Oct 2010 15:25:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 174FE8452F; Thu, 21 Oct 2010 17:20:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bruce Cran References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <86vd4v7gx1.fsf@ds4.des.no> <20101021160335.00001c0a@unknown> Date: Thu, 21 Oct 2010 17:20:54 +0200 In-Reply-To: <20101021160335.00001c0a@unknown> (Bruce Cran's message of "Thu, 21 Oct 2010 16:03:35 +0100") Message-ID: <864ocf7esp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , mav@freebsd.org, Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:25:36 -0000 Bruce Cran writes: > The Ubuntu issue was what I was thinking of - I got that mixed up with > the aggressive power management of the WD EARS drives. The entire Green series, actually, which includes models such as the EADS, AARS etc., but there's more to them than that - the central feature is their dynamically adjusted rotational speed, which allows them to conserve power without spinning all the way down. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 16:20:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6127106564A for ; Thu, 21 Oct 2010 16:20:30 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFFA8FC14 for ; Thu, 21 Oct 2010 16:20:29 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:21555 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1P8xcz-0003Zn-74 for freebsd-hackers@freebsd.org; Thu, 21 Oct 2010 18:04:31 +0200 Received: (qmail 21776 invoked from network); 21 Oct 2010 17:57:46 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 21 Oct 2010 17:57:46 +0200 Received: (qmail 34354 invoked by uid 1001); 21 Oct 2010 17:57:46 +0200 Date: Thu, 21 Oct 2010 17:57:46 +0200 From: Erik Trulsson To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20101021155746.GA34322@owl.midgard.homeip.net> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <86vd4v7gx1.fsf@ds4.des.no> <20101021160335.00001c0a@unknown> <864ocf7esp.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <864ocf7esp.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1P8xcz-0003Zn-74. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1P8xcz-0003Zn-74 de4ad3b40df4172b1bc6e34bf1736985 Cc: Bruce Cran , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org, mav@freebsd.org, Alexander Best Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:20:30 -0000 On Thu, Oct 21, 2010 at 05:20:54PM +0200, Dag-Erling Sm=F8rgrav wrote: > Bruce Cran writes: > > The Ubuntu issue was what I was thinking of - I got that mixed up with > > the aggressive power management of the WD EARS drives. >=20 > The entire Green series, actually, which includes models such as the > EADS, AARS etc., but there's more to them than that - the central > feature is their dynamically adjusted rotational speed, which allows > them to conserve power without spinning all the way down. They do not have any dynamically adjusted rotational speed, despite what Western Digitals marketing department would like you to believe. Tests by various reliable review sites have shown that all the Green models examined so far spin at 5400RPM with no variations. (See e.g. http://www.silentpcreview.com/article786-page2.html or http://www.storagereview.com/1000.sr?page=3D0,0 ) There could be differences in rotational speed between different models (but no such difference has been reported yet), but they all have a fixed RPM. --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 17:46:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 108B51065673; Thu, 21 Oct 2010 17:46:58 +0000 (UTC) Date: Thu, 21 Oct 2010 17:46:58 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20101021174658.GA11107@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline Subject: a few minor kldstat fixes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:46:58 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline this patch fixes the following issues: - unbreak 'kldstat -i 999 -v' output - remove an unnecessary set of "{" and "}" - change printfile() to blend into the overall style used in kldstat.c - add a kldstat(8) entry to document the relationship between the "-i" and "-n" flags cheers. alex -- a13x --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldstat.diff" diff --git a/sbin/kldstat/kldstat.8 b/sbin/kldstat/kldstat.8 index 6f040e2..313a5c6 100644 --- a/sbin/kldstat/kldstat.8 +++ b/sbin/kldstat/kldstat.8 @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 23, 2005 +.Dd October 21, 2010 .Dt KLDSTAT 8 .Os .Sh NAME @@ -52,7 +52,10 @@ Be more verbose. .It Fl i Ar id Display the status of only the file with this ID. .It Fl n Ar filename -Display the status of only the file with this filename. +Display the status of only the file with this filename. This will overwrite any +previous +.Fl i +option. .It Fl q Only check if module is loaded or compiled into the kernel. .It Fl m Ar modname diff --git a/sbin/kldstat/kldstat.c b/sbin/kldstat/kldstat.c index 78182b9..f671c60 100644 --- a/sbin/kldstat/kldstat.c +++ b/sbin/kldstat/kldstat.c @@ -50,14 +50,15 @@ printmod(int modid) printf("\t\t%2d %s\n", stat.id, stat.name); } -static void printfile(int fileid, int verbose) +static void +printfile(int fileid, int verbose) { struct kld_file_stat stat; int modid; stat.version = sizeof(struct kld_file_stat); if (kldstat(fileid, &stat) < 0) - warn("can't stat file id %d", fileid); + err(1, "can't stat file id %d", fileid); else printf("%2d %4d %p %-8zx %s", stat.id, stat.refs, stat.address, stat.size, @@ -144,10 +145,9 @@ main(int argc, char** argv) return 0; } - if (filename != NULL) { + if (filename != NULL) if ((fileid = kldfind(filename)) < 0) err(1, "can't find file %s", filename); - } printf("Id Refs Address%*c Size Name\n", POINTER_WIDTH - 7, ' '); if (fileid != 0) --AhhlLboLdkugWU4S-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 17:57:52 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F587106567A for ; Thu, 21 Oct 2010 17:57:52 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8158FC0C for ; Thu, 21 Oct 2010 17:57:51 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9LHvmkO071356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 19:57:48 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1287683868; bh=wcf4Y7+KtEkGaJzl5PDFr04Tl1Po8pjBQK+Wm/JX5bM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=JnHv/+jhblZFLLxT9FHQy6Z/JZPZalZOBBGqizEh/8AYebxEVaWMk/M+TuRhlS7qU 2FaKQbuY1uVnGciIxrcHeAtBuy0fO7eUx3ovk7H6LLTzxPw3fBXRjIPxxY3a3frm+i a9L6h83g38l+rXJeW5s0a5F18rX/RtP/2Rem0TiY= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9LHvmix071355; Thu, 21 Oct 2010 19:57:48 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 21 Oct 2010 19:57:48 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Erik Cederstrand Message-ID: <20101021175748.GD19295@acme.spoerlein.net> Mail-Followup-To: Erik Cederstrand , Kostik Belousov , FreeBSD Hackers References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , FreeBSD Hackers Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:57:52 -0000 On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote: > > Den 11/10/2010 kl. 10.47 skrev Kostik Belousov: > > > > My personal opinion that the feature is nice to have. Unless the changes to > > get this working are too large, and, more importantly, unless the maintenance > > cost of having this in good shape is too high, sure we would better have > > deterministic build results. > > > > Also, the deterministic builds require somebody who would monitor the > > feature, either manually, or by setting some bot that automatically > > checks it. Otherwise, I suspect, it will degrade. > > I might want to adopt the task of monitoring the feature. > > I'm beginning to think that it should at least be optional. Removing e.g. build times, mtimes and path to OBJDIR or SRCDIR might not make everyone happy. The problem with making it optional is, that we already have enough flags and knobs. No need in adding more. Besides, why would people want to know the date of the build? Far more important is the date and state of the source for the time of build. So you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of last commit?). Otherwise, please go for it. It would be nice if two people compiling GENERIC for the same source-base would get identical binaries. Uli From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:02:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 831781065695; Thu, 21 Oct 2010 18:02:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E79D08FC16; Thu, 21 Oct 2010 18:02:30 +0000 (UTC) Received: by wyb38 with SMTP id 38so5464984wyb.13 for ; Thu, 21 Oct 2010 11:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=zD3PhXSZn0pJMrYYq2XAHJH10bRF6b+M2ki3dynj064=; b=HLixPEesTRBsvOHSpZpkGHXqv5j1rVUQabXm0jdLLUsA6xWi2EEP63S+EbAQ5j+vT6 O8eqsp/Kh5u8IcqlEuDUqcx6bJRKckbnTMxUcTFRj6LjhMCgmP0NMM3Dq56DczrPcomP hknKRDhs/gLjaldsxXzNX3tZKMB8OCZ+BjoKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qaZWbY5BSTw1rPNyG9RFwh86MdEC9O+Q6GbAq7lq0NyE8lYGBAwJQi2XplMy1iFbE2 vAfMPIYhUCIEawZ5cf4ZNLrIHu0PjFNAAyGYMms6o7YOSFa2FNqt9nu4h54pAiMMnvzg Db0Ij5tdsT+gfbWDMplnEBOojlefXBrsTM78g= MIME-Version: 1.0 Received: by 10.216.13.17 with SMTP id a17mr10017999wea.46.1287684149769; Thu, 21 Oct 2010 11:02:29 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.135.67 with HTTP; Thu, 21 Oct 2010 11:02:29 -0700 (PDT) In-Reply-To: <20101021174658.GA11107@freebsd.org> References: <20101021174658.GA11107@freebsd.org> Date: Thu, 21 Oct 2010 11:02:29 -0700 X-Google-Sender-Auth: y7yqHl3Y2jqT6jywnz_VUmc6g30 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: a few minor kldstat fixes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:02:31 -0000 On Thu, Oct 21, 2010 at 10:46 AM, Alexander Best wrote: > this patch fixes the following issues: > > - unbreak 'kldstat -i 999 -v' output > - remove an unnecessary set of "{" and "}" > - change printfile() to blend into the overall style used in kldstat.c > - add a kldstat(8) entry to document the relationship between the "-i" and "-n" flags Might be better to say that the -i and -n options are mutually exclusive in the manpage, and have the args parser parse out those two cases and bail if both of them are set. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:08:49 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF44C106566B; Thu, 21 Oct 2010 18:08:49 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAEC8FC22; Thu, 21 Oct 2010 18:08:49 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9LI8m2O071613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 20:08:48 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1287684528; bh=DM2/cUQfrjP/cS2yPZcKKVIPc7l8trIqGOJhAzxfjnc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=cNcJPafy6NjXvvi2g26Oh4dLGcg+KQorhymr0cIRI1fztZ0R8t2FSO1WnUlqR45tk ij1qJkdZ4+3Ll1fby1XB4TaqMP+uRQykH8yFmPKzYpSYRFf+7rOgRQDDvM65jmuA8+ MCeuFLgsxNiF9J2Q1jCxa3PT0vv2Rgopup+JmH1w= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9LI8m6Y071612; Thu, 21 Oct 2010 20:08:48 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 21 Oct 2010 20:08:48 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Brooks Davis Message-ID: <20101021180848.GE19295@acme.spoerlein.net> Mail-Followup-To: Brooks Davis , hackers@freebsd.org References: <20101014202323.GD42797@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101014202323.GD42797@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org Subject: Re: negative permission scanner for periodic/security X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:08:50 -0000 On Thu, 14.10.2010 at 15:23:23 -0500, Brooks Davis wrote: > One of the side effects of increasing NGROUPS_MAX is that it's possible > for a process to be in more groups that can be transmitted over NFS > (<4). When that happens users are mostly denied access to things they > should have access to. However, permission evaluation order in unix > means that groups can be denied access to files the world can read using > so called negative permissions. I've written a scanner (derived from > 100.chksetuid) for the periodic security script to flag such files as > they post a security risk (and nearly all the time are errors). I've > not bothered looking for negative user permissions as that isn't broken > over NFS and assuming the file is not on a read-only FS the user can > just give theselves permissions again. > > One minor note: Before enabling this by default, ~6 files in the ports > repo need fixing as they have world execute bits without user or group > execute bits. > > Should this be enabled by default? It think so, but welcome discussion. I'm with you, but a couple of points to note: - Many admins won't be familiar with this problem and might not go as far as reading the periodic manpage for an explanation. Perhaps another paragraph could be emitted -- iff we have a hit -- that explains why periodic is checking the permissions. - ufs,zfs is hardcoded, can't we get this list from somewhere else? We support NFS exports of ext2fs filesystems, right? - Not a problem for sane setups, but somewhere out there is a machine where the resulting list might be several MB large. We currently don't restrict the periodic mail to a certain size, perhaps we should start doing this to avoid mailbox/mail system overflow? Regards, Uli From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:16:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6E6D106564A for ; Thu, 21 Oct 2010 18:16:44 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7369C8FC0A for ; Thu, 21 Oct 2010 18:16:44 +0000 (UTC) Received: from [193.31.11.193] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P8vsF-0007CW-Ff for freebsd-hackers@freebsd.org; Thu, 21 Oct 2010 16:12:07 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9LEC7hI045872 for ; Thu, 21 Oct 2010 16:12:07 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9LEC69m045871 for freebsd-hackers@freebsd.org; Thu, 21 Oct 2010 16:12:06 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 21 Oct 2010 16:12:06 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org Message-ID: <20101021141206.GA37339@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 193.31.11.193 Subject: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:16:44 -0000 Hello, I have on my laptop a kernel based on CVS from May 2009, i.e. 8-CURRENT at this time. I now need support for Atheros AR813x/AR815x PCIe Ethernet, the kmod if_alc.ko. That's why I did: # cd /usr/src/sys/dev # cvs update -d -r RELENG_8_0_0_RELEASE alc and have now: # ls -l alc total 142 drwxr-xr-x 2 root wheel 512 21 oct 15:30 CVS -rw-r--r-- 1 root wheel 103832 21 oct 15:30 if_alc.c -rw-r--r-- 1 root wheel 29084 21 oct 15:30 if_alcreg.h -rw-r--r-- 1 root wheel 8119 21 oct 15:30 if_alcvar.h but a # cd /usr/src # make buildkernel KERNCONF=GENERIC does not build the module if_alc.ko What I'm missing? Or what is the correct way to get this module for my kernel level? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:23:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 35C23106566B; Thu, 21 Oct 2010 18:23:14 +0000 (UTC) Date: Thu, 21 Oct 2010 18:23:14 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101021182314.GA16569@freebsd.org> References: <20101021174658.GA11107@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: a few minor kldstat fixes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:23:14 -0000 On Thu Oct 21 10, Garrett Cooper wrote: > On Thu, Oct 21, 2010 at 10:46 AM, Alexander Best wrote: > > this patch fixes the following issues: > > > > - unbreak 'kldstat -i 999 -v' output > > - remove an unnecessary set of "{" and "}" > > - change printfile() to blend into the overall style used in kldstat.c > > - add a kldstat(8) entry to document the relationship between the "-i" and "-n" flags > > Might be better to say that the -i and -n options are mutually > exclusive in the manpage, and have the args parser parse out those two > cases and bail if both of them are set. i don't think the current behavior should be changed. some people might have something like 'kldstat -i X -n Y' in their scripts expect "-n Y" to override "-i X", instead of having kldstat fail. > Thanks! > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:35:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80BAA106564A for ; Thu, 21 Oct 2010 18:35:11 +0000 (UTC) (envelope-from onemda@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 183C68FC20 for ; Thu, 21 Oct 2010 18:35:10 +0000 (UTC) Received: by wwb24 with SMTP id 24so25254wwb.31 for ; Thu, 21 Oct 2010 11:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NqM3UmQNpgZdQ22Yu9m2danKMF0c5yG/arJlKqRKETE=; b=OtuGcxiz6ZjkMI2btM3T+Kb80fpWwT1Kt5rO0b+yjuGbSFpbxH1I1zXkgHh9JInUvS DjJgtnElo1AjVdPlWvotHdnpXOAq1KAg8aBEd/Gzrzjf5iOVvIDlc0ikgW10ZOu41QZS KTabOEnT+9WhesF+QOiUbCcw3sUBjRJwaxlzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kOZZBhg2okDyHxHAGSG3dJr/9eUg/5b/FrwOgzwAkZz98+EuYXIOY2p/3w0LM2PrQi EjOVeWlmPbafbQV13xawYA1Ia/MusZglrMybO435XkMMUVX0Tmx3bSO6CGg/nk2syY9H KZW+kob71wROo3r5RvJkhrlh12QGP4fQFlvaE= MIME-Version: 1.0 Received: by 10.227.144.9 with SMTP id x9mr1583334wbu.76.1287686109721; Thu, 21 Oct 2010 11:35:09 -0700 (PDT) Received: by 10.216.155.74 with HTTP; Thu, 21 Oct 2010 11:35:09 -0700 (PDT) In-Reply-To: <20101021141206.GA37339@current.Sisis.de> References: <20101021141206.GA37339@current.Sisis.de> Date: Thu, 21 Oct 2010 20:35:09 +0200 Message-ID: From: Paul B Mahol To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:35:11 -0000 On 10/21/10, Matthias Apitz wrote: > > Hello, > > I have on my laptop a kernel based on CVS from May 2009, i.e. 8-CURRENT > at this time. > > I now need support for Atheros AR813x/AR815x PCIe > Ethernet, the kmod if_alc.ko. That's why I did: > > # cd /usr/src/sys/dev > # cvs update -d -r RELENG_8_0_0_RELEASE alc > > and have now: > > # ls -l alc > total 142 > drwxr-xr-x 2 root wheel 512 21 oct 15:30 CVS > -rw-r--r-- 1 root wheel 103832 21 oct 15:30 if_alc.c > -rw-r--r-- 1 root wheel 29084 21 oct 15:30 if_alcreg.h > -rw-r--r-- 1 root wheel 8119 21 oct 15:30 if_alcvar.h > > but a > > # cd /usr/src > # make buildkernel KERNCONF=GENERIC > > does not build the module if_alc.ko > > What I'm missing? Or what is the correct way to get this module for my > kernel level? /sys/modules/alc > > Thanks > > matthias > > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:40:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385AF106564A for ; Thu, 21 Oct 2010 18:40:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id E4AB48FC13 for ; Thu, 21 Oct 2010 18:40:37 +0000 (UTC) Received: from [77.25.220.0] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9043-00051O-NH; Thu, 21 Oct 2010 20:40:36 +0200 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id o9LIfpAW001151; Thu, 21 Oct 2010 20:41:52 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id o9LIfoRJ001150; Thu, 21 Oct 2010 20:41:50 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Thu, 21 Oct 2010 20:41:50 +0200 From: Matthias Apitz To: Paul B Mahol Message-ID: <20101021184149.GA1142@tiny> References: <20101021141206.GA37339@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 77.25.220.0 Cc: freebsd-hackers@freebsd.org Subject: Re: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:40:38 -0000 El día Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol escribió: > > # cd /usr/src > > # make buildkernel KERNCONF=GENERIC > > > > does not build the module if_alc.ko > > > > What I'm missing? Or what is the correct way to get this module for my > > kernel level? > > /sys/modules/alc Yes, thanks. I realized this some hours ago and CVS up this too, but the module does not get build. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 18:44:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB4D91065670 for ; Thu, 21 Oct 2010 18:44:34 +0000 (UTC) (envelope-from onemda@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 605CC8FC19 for ; Thu, 21 Oct 2010 18:44:33 +0000 (UTC) Received: by fxm17 with SMTP id 17so336171fxm.13 for ; Thu, 21 Oct 2010 11:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P4D23WHmLXjUfPx8y8Si8C6RRglLte9iXgxGC9nc7C4=; b=xIVYob+ZVnTdsR21EDaA0omG3NZZcq7AUTpci1UivB/Ss/gCOSa9GQ7rVooYsUvelj gO2AFvjPbNVq5tojSimHwUkWLsrHbgariuRNBKWEeFLwthj3736b/lJDCYUvSJtdtsw1 GNSfw1KQQsVLDRgLRHDIYJwftwQlEcCsaVhBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DlPPUZLtlFEHQITiuFUFbNJAzuDviDRtdmadZLOJ0bwhwlfHNi856lFeDjaCXvLqon Q7EJUgiR4NOzNinczHvgZltfTSqd6UvHYWrrnLBVwW57/TEB15BJauyWJm5H2RF83rUm 4WSqGwyohiTls/blAGk+1IkQv19qOXUWMBlmg= MIME-Version: 1.0 Received: by 10.216.165.16 with SMTP id d16mr1445171wel.0.1287686672975; Thu, 21 Oct 2010 11:44:32 -0700 (PDT) Received: by 10.216.155.74 with HTTP; Thu, 21 Oct 2010 11:44:32 -0700 (PDT) In-Reply-To: <20101021184149.GA1142@tiny> References: <20101021141206.GA37339@current.Sisis.de> <20101021184149.GA1142@tiny> Date: Thu, 21 Oct 2010 20:44:32 +0200 Message-ID: From: Paul B Mahol To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 18:44:34 -0000 On 10/21/10, Matthias Apitz wrote: > El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol > escribio: > >> > # cd /usr/src >> > # make buildkernel KERNCONF=GENERIC >> > >> > does not build the module if_alc.ko >> > >> > What I'm missing? Or what is the correct way to get this module for my >> > kernel level? >> >> /sys/modules/alc > > Yes, thanks. I realized this some hours ago and CVS up this too, but > the module does not get build. Because you did not have Makefiles of higher directories. Anyway: # cd /sys/modules/alc && make install clean Should do it. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 19:50:30 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0E01065674 for ; Thu, 21 Oct 2010 19:50:30 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 685E18FC1D for ; Thu, 21 Oct 2010 19:50:30 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp2.one.com (Postfix) with ESMTPA id 2A1AFEA8D09C1; Thu, 21 Oct 2010 19:50:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-114-145781677; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20101021175748.GD19295@acme.spoerlein.net> Date: Thu, 21 Oct 2010 21:50:26 +0200 Message-Id: References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , FreeBSD Hackers Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 19:50:31 -0000 --Apple-Mail-114-145781677 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Den 21/10/2010 kl. 19.57 skrev Ulrich Sp=F6rlein: > On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote: >>=20 >> I'm beginning to think that it should at least be optional. Removing = e.g. build times, mtimes and path to OBJDIR or SRCDIR might not make = everyone happy. >=20 > The problem with making it optional is, that we already have enough > flags and knobs. No need in adding more. >=20 > Besides, why would people want to know the date of the build? Far more > important is the date and state of the source for the time of build. = So > you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of > last commit?). >=20 > Otherwise, please go for it. It would be nice if two people compiling > GENERIC for the same source-base would get identical binaries. It goes without saying that I agree with you on this. But it seems the = feature will require fairly invasive changes to a standard FreeBSD, e.g. = changing standard ar behavior, and building kernels and some other tools = without debugging symbols. I'm not experienced enough to determine if = this is fine with the majority of users, but hiding the changes under a = knob would at least let the feature prove itself and put off = bikeshedding for a while. If the project works out, we can discuss = changing the default. I'm still not sure what to do with debugging symbols. Currently absolute = paths to source files are used. I would like to change that to absolute = paths , i.e. usr.bin/ar/ar.c. That might even be beneficial if someone = is debugging the binary on a system that doesn't have the source tree = located in /some/obscure/directory/src. It's my understanding that gdb = uses the path to look up source code related to stack traces etc. It = seems gdb can handle relative paths, but I have no idea if it actually = works, or if it's a nuisance to use compared to absolute paths. Any = hints? Thanks, Erik= --Apple-Mail-114-145781677-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 21 23:10:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B530E106564A for ; Thu, 21 Oct 2010 23:10:36 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 122108FC19 for ; Thu, 21 Oct 2010 23:10:35 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk ([192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o9LMWsB4046499; Thu, 21 Oct 2010 23:32:55 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4CC0BF96.1050806@fletchermoorland.co.uk> Date: Thu, 21 Oct 2010 22:32:54 +0000 From: Paul Wootton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100817 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021135442.000054c9@unknown> <86vd4v7gx1.fsf@ds4.des.no> <20101021160335.00001c0a@unknown> <864ocf7esp.fsf@ds4.des.no> In-Reply-To: <864ocf7esp.fsf@ds4.des.no> X-Spam-Status: No, score=-2.9 required=7.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hydra.fletchermoorland.co.uk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 23:10:36 -0000 On 10/21/10 15:20, Dag-Erling Smørgrav wrote: > Bruce Cran writes: >> The Ubuntu issue was what I was thinking of - I got that mixed up with >> the aggressive power management of the WD EARS drives. > The entire Green series, actually, which includes models such as the > EADS, AARS etc., but there's more to them than that - the central > feature is their dynamically adjusted rotational speed, which allows > them to conserve power without spinning all the way down. > > DES Actually, the green series does spin all the way down, well at least the drive I have does. Here is the output from one of my drives, that I do not think has long left to live. === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green family Device Model: WDC WD5000AADS-00M2B0 Serial Number: WD-WMAV51882791 Firmware Version: 01.00A01 User Capacity: 500,107,862,016 bytes 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: Thu Oct 21 23:31:35 2010 BST SMART support is: Available - device has SMART capability. SMART support is: Enabled .... SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 111 104 021 Pre-fail Always - 7425 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 98 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 5295 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 96 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 95 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 781014 194 Temperature_Celsius 0x0022 120 102 000 Old_age Always - 27 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 The datasheet for these drive http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf says "Reliability/Data Integrity Load/unload cycles (3) 300,000 Limited Warranty (years) (4) (3) Controlled unload at ambient condition (4) The term of the limited warranty my vary by region" Also http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357 "(drive has been validated to 1 million load/unload cycles without issue)" Im already at 781014 load cycles, yet the drive is only about 7 months old. Doing the math, I am getting a load/unload cycle about every 24.5 seconds Another 2 months and I will be knocking on for 1 million load/unload cycles.... As DES has already said, for most people the extra load/unload cycles when rebooting a computer will not be an issue at all and is far more desirable than an emergency park when powering down Paul From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 07:14:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D058A106566B for ; Fri, 22 Oct 2010 07:14:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 606678FC19 for ; Fri, 22 Oct 2010 07:14:04 +0000 (UTC) Received: from [193.31.11.193] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9BpC-0006ny-3n; Fri, 22 Oct 2010 09:14:02 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9M7E3VO002218; Fri, 22 Oct 2010 09:14:03 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9M7E32i002217; Fri, 22 Oct 2010 09:14:03 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 22 Oct 2010 09:14:03 +0200 From: Matthias Apitz To: Paul B Mahol Message-ID: <20101022071403.GA2152@current.Sisis.de> References: <20101021141206.GA37339@current.Sisis.de> <20101021184149.GA1142@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 193.31.11.193 Cc: freebsd-hackers@freebsd.org Subject: Re: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 07:14:04 -0000 El día Thursday, October 21, 2010 a las 08:44:32PM +0200, Paul B Mahol escribió: > On 10/21/10, Matthias Apitz wrote: > > El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol > > escribio: > > > >> > # cd /usr/src > >> > # make buildkernel KERNCONF=GENERIC > >> > > >> > does not build the module if_alc.ko > >> > > >> > What I'm missing? Or what is the correct way to get this module for my > >> > kernel level? > >> > >> /sys/modules/alc > > > > Yes, thanks. I realized this some hours ago and CVS up this too, but > > the module does not get build. > > Because you did not have Makefiles of higher directories. > > Anyway: > > # cd /sys/modules/alc && make install clean > > Should do it. Thanks, but: # make Warning: Object directory not changed from original /usr/src/sys/modules/alc cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finli ne-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long -strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fsta ck-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/alc/../../dev/alc/if_alc.c cc1: warnings being treated as errors /usr/src/sys/modules/alc/../../dev/alc/if_alc.c: In function 'alc_rxfilter': /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: implicit declaration of function 'if_maddr_rl ock' /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: nested extern declaration of 'if_maddr_rlock' /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: implicit declaration of function 'if_maddr_ru nlock' /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: nested extern declaration of 'if_maddr_runloc k' *** Error code 1 matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 07:50:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17DD9106566B for ; Fri, 22 Oct 2010 07:50:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 933728FC0A for ; Fri, 22 Oct 2010 07:50:07 +0000 (UTC) Received: from [193.31.11.193] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9CO4-0007EV-Bc; Fri, 22 Oct 2010 09:50:05 +0200 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id o9M7o6UW002409; Fri, 22 Oct 2010 09:50:06 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id o9M7o6Ul002408; Fri, 22 Oct 2010 09:50:06 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 22 Oct 2010 09:50:06 +0200 From: Matthias Apitz To: Paul B Mahol , freebsd-hackers@freebsd.org Message-ID: <20101022075006.GA2377@current.Sisis.de> References: <20101021141206.GA37339@current.Sisis.de> <20101021184149.GA1142@tiny> <20101022071403.GA2152@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101022071403.GA2152@current.Sisis.de> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 193.31.11.193 Cc: Pyun YongHyeon Subject: Re: kmod if_alc in 8-CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 07:50:08 -0000 El día Friday, October 22, 2010 a las 09:14:03AM +0200, Matthias Apitz escribió: > # make > Warning: Object directory not changed from original > /usr/src/sys/modules/alc > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I. -I@ -I@/contrib/altq -finli > ne-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long > -strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse > -mno-sse2 -mno-sse3 -ffreestanding -fsta > ck-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototype > s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions > -c /usr/src/sys/modules/alc/../../dev/alc/if_alc.c > cc1: warnings being treated as errors > /usr/src/sys/modules/alc/../../dev/alc/if_alc.c: In function > 'alc_rxfilter': > /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: implicit > declaration of function 'if_maddr_rl > ock' > /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: nested > extern declaration of 'if_maddr_rlock' > /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: implicit > declaration of function 'if_maddr_ru > nlock' > /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: nested > extern declaration of 'if_maddr_runloc > k' > *** Error code 1 The change was introduced with rev. 1.2 of the driver: revision 1.2 date: 2009/06/26 11:45:06; author: rwatson; state: Exp; lines: +2 -2 SVN rev 195049 on 2009-06-26 11:45:06Z by rwatson Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/ IF_ADDR_UNLOCK() across network device drivers when accessing the per-interface multicast address list, if_multiaddrs. This will allow us to change the locking strategy without affecting our driver programming interface or binary interface. and I checked out RELENG_8_0_0_RELEASE (revision: 1.3.2.2.2.1) will Cc: the author to see what I should do with my 8-CURRENT from May 2009 to get support for this NIC; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 09:19:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45955106566C; Fri, 22 Oct 2010 09:19:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91D338FC1E; Fri, 22 Oct 2010 09:19:00 +0000 (UTC) Received: by bwz3 with SMTP id 3so1034279bwz.13 for ; Fri, 22 Oct 2010 02:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=TRq3Tvh5o85f099oNNthc+hTacuxqgw88WYKNgVn5hw=; b=C0Vj2ghLVmitchc6iX5h14J9FAx+Z9idjVBj6tfyf/9hdu5H5oa1cZa1kXVBgn3C6l v2Y7uZquc0JniMzIw+Xz4Tao2Fq6OcM/cDzKXFv7/USIZ3xejlUYF4ARADCDoaVfhjDB VOL2jzoQwUN9G3kgaN1TRQbj+W5Bt6ENUuj5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BJCi3pbUPluwX91BQoVXUL30mB2LxWRKOB5AtSx1qXa/tjZnXqVOhJR7ArnFgabZgB BaPGtRB++KdVKV5IlfrrmnPWyw9Btmr3EkBXddMNQW8GRncN+LeAgx50cIjWu5Lz9jZ6 4zv3yzGLokkg2xmmexb9bqxGSqHMWCnEowkuU= Received: by 10.204.100.82 with SMTP id x18mr1812905bkn.75.1287739139210; Fri, 22 Oct 2010 02:18:59 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm1969546bkf.3.2010.10.22.02.18.55 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 02:18:57 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC156F5.1050109@FreeBSD.org> Date: Fri, 22 Oct 2010 12:18:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> In-Reply-To: <20101021122110.GA65490@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 09:19:01 -0000 Alexander Best wrote: > the current implementation (kern.cam.power_down) uses a singe "sleep" > operation, whereas the patch by oliver uses "flush" and "standby immediate". Sleep is just more aggressive. It puts device into deeper sleep state. I don't think it is important from wearing point of view. > unfortunately almost nobody was aware of mav's work at the time of the > discussion. would have been nice to have a note in cam(4) explaining the > purpose of kern.cam.power_down. that way a lot of double work could have been > avoided. That code was expected to handle spindown on shutdown in unified fashion for ATA and SCSI devices without dependency from peripheral driver (even without one), just using different commands for each protocol. It works, but in current implementation it is unreliable. The problem is that it uses polled operation mode, not supported by some controllers or unreliable on some (e.g. atapicam). So the code is disabled now by default. I haven't yet decided it's future: it should be either reworked or reverted. As positive side -- as soon as CAM is not using NewBus at the moment, CAM registers own shutdown handlers. That allows CAM to receive the howto argument, which allows to separate cases of reboot and shutdown cases just by: if ((howto & RB_POWEROFF) == 0) > is the ATA(4) subsystem still being actively worked on or will it die out after > officially switching to ATA_CAM? the question is, if it is worth implementing > hdd spin down for ATA(4)? I don't think it will be really critical. Next months I am going to work on ataraid(4) replacement, which was main declared show stopper for the switch. I hope to trash legacy code some time after switching to ATA_CAM to clear number of odd things (like almost not working port multipliers support or duplicate drivers), required by it. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 10:01:41 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C0A21065679 for ; Fri, 22 Oct 2010 10:01:41 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id BFD0A8FC1E for ; Fri, 22 Oct 2010 10:01:40 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9MA1Yig091001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2010 12:01:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1287741694; bh=PUFHbkGC9Q8xr3ItQVGfYww8+qV4VMrkJAWm4/kQFsY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=KDqXsYJstR68HXOgzVJUjM5y817VZ5fp6TtOJDnIZmvPLdo7J6WNfU3cLt0gcT5mM DrBlJ8x2A6y/ttQ3EUADdgxBdRv0yFT0IMjz8w38B4UkO1nXqXY1bobsnP2jIQoWRi Ik3Xi6Q7X6Io1UVTu0ym2aNuUyqrrIoK6KmzbDcY= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9MA1YdH090998; Fri, 22 Oct 2010 12:01:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 22 Oct 2010 12:01:34 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Erik Cederstrand Message-ID: <20101022100134.GL19295@acme.spoerlein.net> Mail-Followup-To: Erik Cederstrand , FreeBSD Hackers References: <718D8E86-EA2E-4D07-BAFF-5D8D093FD296@cederstrand.dk> <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 10:01:41 -0000 On Thu, 21.10.2010 at 21:50:26 +0200, Erik Cederstrand wrote: > Den 21/10/2010 kl. 19.57 skrev Ulrich Spörlein: > > On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote: > >> I'm beginning to think that it should at least be optional. Removing e.g. build times, mtimes and path to OBJDIR or SRCDIR might not make everyone happy. > > > > The problem with making it optional is, that we already have enough > > flags and knobs. No need in adding more. > > > > Besides, why would people want to know the date of the build? Far more > > important is the date and state of the source for the time of build. So > > you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of > > last commit?). > > > > Otherwise, please go for it. It would be nice if two people compiling > > GENERIC for the same source-base would get identical binaries. > > It goes without saying that I agree with you on this. But it seems the feature will require fairly invasive changes to a standard FreeBSD, e.g. changing standard ar behavior, and building kernels and some other tools without debugging symbols. I'm not experienced enough to determine if this is fine with the majority of users, but hiding the changes under a knob would at least let the feature prove itself and put off bikeshedding for a while. If the project works out, we can discuss changing the default. > > I'm still not sure what to do with debugging symbols. Currently absolute paths to source files are used. I would like to change that to absolute paths , i.e. usr.bin/ar/ar.c. That might even be beneficial if someone is debugging the binary on a system that doesn't have the source tree located in /some/obscure/directory/src. It's my understanding that gdb uses the path to look up source code related to stack traces etc. It seems gdb can handle relative paths, but I have no idea if it actually works, or if it's a nuisance to use compared to absolute paths. Any hints? Why do you make this a requirement? Of course it's usually easier to build different releases from different source directories, but I think requiring the following conditions are fine: 1. If you build a specific svn revision, 2. sitting in /usr/src with 3. the default make.conf (ie., no special flags, no frobbing of OBJDIR) 4. at different times then you get the same binaries. Let's start with an achievable, not-so-intrusive goal, right? :) Uli From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 10:03:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EA09F106566C; Fri, 22 Oct 2010 10:03:09 +0000 (UTC) Date: Fri, 22 Oct 2010 10:03:09 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101022100309.GA16446@freebsd.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC156F5.1050109@FreeBSD.org> Cc: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 10:03:10 -0000 On Fri Oct 22 10, Alexander Motin wrote: > Alexander Best wrote: > > the current implementation (kern.cam.power_down) uses a singe "sleep" > > operation, whereas the patch by oliver uses "flush" and "standby immediate". > > Sleep is just more aggressive. It puts device into deeper sleep state. I > don't think it is important from wearing point of view. > > > unfortunately almost nobody was aware of mav's work at the time of the > > discussion. would have been nice to have a note in cam(4) explaining the > > purpose of kern.cam.power_down. that way a lot of double work could have been > > avoided. > > That code was expected to handle spindown on shutdown in unified fashion > for ATA and SCSI devices without dependency from peripheral driver (even > without one), just using different commands for each protocol. It works, > but in current implementation it is unreliable. The problem is that it > uses polled operation mode, not supported by some controllers or > unreliable on some (e.g. atapicam). So the code is disabled now by > default. I haven't yet decided it's future: it should be either reworked > or reverted. so how about olivers patch? it will only apply to ata devices so it's garanteed not to break any other CAM devices (i'm thinking about the aac controller issue). you could revert your previous shutdown work and plug olivers patch into CAM. you might want to replace the combination of flush/standby immediate with sleep. cheers. alex > > As positive side -- as soon as CAM is not using NewBus at the moment, > CAM registers own shutdown handlers. That allows CAM to receive the > howto argument, which allows to separate cases of reboot and shutdown > cases just by: > if ((howto & RB_POWEROFF) == 0) > > > is the ATA(4) subsystem still being actively worked on or will it die out after > > officially switching to ATA_CAM? the question is, if it is worth implementing > > hdd spin down for ATA(4)? > > I don't think it will be really critical. Next months I am going to work > on ataraid(4) replacement, which was main declared show stopper for the > switch. I hope to trash legacy code some time after switching to ATA_CAM > to clear number of odd things (like almost not working port multipliers > support or duplicate drivers), required by it. > > -- > Alexander Motin -- a13x From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 10:07:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A291065674 for ; Fri, 22 Oct 2010 10:07:46 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id D50DB8FC1F for ; Fri, 22 Oct 2010 10:07:45 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG7+wExbsdUE/2dsb2JhbAChX3KIHLZWhUoE Received: from 4.213-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.213.4]) by relay.skynet.be with ESMTP; 22 Oct 2010 12:07:44 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o9MA7hN6002574; Fri, 22 Oct 2010 12:07:43 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Fri, 22 Oct 2010 12:07:36 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <201009161742.24228.tijl@coosemans.org> <864ocf7esp.fsf@ds4.des.no> <4CC0BF96.1050806@fletchermoorland.co.uk> In-Reply-To: <4CC0BF96.1050806@fletchermoorland.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14470364.TKtd1VV2N9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201010221207.42994.tijl@coosemans.org> Cc: Paul Wootton Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 10:07:46 -0000 --nextPart14470364.TKtd1VV2N9 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday 22 October 2010 00:32:54 Paul Wootton wrote: > Actually, the green series does spin all the way down, well at least > the drive I have does. > Here is the output from one of my drives, that I do not think has > long left to live. >=20 > =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D > Model Family: Western Digital Caviar Green family > Device Model: WDC WD5000AADS-00M2B0 > Serial Number: WD-WMAV51882791 > Firmware Version: 01.00A01 > User Capacity: 500,107,862,016 bytes > 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: Thu Oct 21 23:31:35 2010 BST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > .... > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE =20 > UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail =20 > Always - 0 > 3 Spin_Up_Time 0x0027 111 104 021 Pre-fail =20 > Always - 7425 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age =20 > Always - 98 > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail =20 > Always - 0 > 7 Seek_Error_Rate 0x002e 100 253 000 Old_age =20 > Always - 0 > 9 Power_On_Hours 0x0032 093 093 000 Old_age =20 > Always - 5295 > 10 Spin_Retry_Count 0x0032 100 253 000 Old_age =20 > Always - 0 > 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age =20 > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age =20 > Always - 96 > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age =20 > Always - 95 > 193 Load_Cycle_Count 0x0032 001 001 000 Old_age =20 > Always - 781014 > 194 Temperature_Celsius 0x0022 120 102 000 Old_age =20 > Always - 27 > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age =20 > Always - 0 > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age =20 > Always - 0 > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age =20 > Offline - 0 > 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age =20 > Always - 0 > 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age =20 > Offline - 0 >=20 >=20 > The datasheet for these drive=20 > http= ://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf=20 > says > "Reliability/Data Integrity > Load/unload cycles (3) 300,000 > Limited Warranty (years) (4) > (3) Controlled unload at ambient condition > (4) The term of the limited warranty my vary by region" >=20 > Also=20 > http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid= =3D5357 > "(drive has been validated to 1 million load/unload cycles without issue)" >=20 > Im already at 781014 load cycles, yet the drive is only about 7 months=20 > old. Doing the math, I am getting a load/unload cycle about every 24.5=20 > seconds > Another 2 months and I will be knocking on for 1 million load/unload=20 > cycles.... >=20 > As DES has already said, for most people the extra load/unload cycles=20 > when rebooting a computer will not be an issue at all and is far more=20 > desirable than an emergency park when powering down =46reeBSD frequently accesses hard disks (log files, flushing dirty memory pages every 30s,...) and laptop drives tend to have aggressive power saving settings by default. That's why your load cycle is so high. To deal with this you should consider installing sysutils/ataidle and adding these lines to /etc/rc.conf: ataidle_enable=3D"YES" ataidle_devices=3D"ad0" ataidle_ad0=3D"-P 0" An alternative is to use atacontrol(8). If you don't mind the spin down when rebooting you can solve the emergency park at shutdown with a simple patch like this: =2D-- sys/dev/ata/ata-disk.c +++ sys/dev/ata/ata-disk.c @@ -193,6 +193,8 @@ =20 if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE) ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0); + if (atadev->param.support.command1 & ATA_SUPPORT_POWERMGT) + ata_controlcmd(dev, ATA_STANDBY_IMMEDIATE, 0, 0, 0); return 0; } =20 --nextPart14470364.TKtd1VV2N9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzBYm4ACgkQfoCS2CCgtisJXQD+PlAZJi3QL8wpsPXXpX2bXrqU 3D+lIIxwF1ALsXuvdpkA/RcOybCbE434hQMWSDMbolvYFsdrzWdydu1rFmmJKlcf =WwZh -----END PGP SIGNATURE----- --nextPart14470364.TKtd1VV2N9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 11:00:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C1D9106566C for ; Fri, 22 Oct 2010 11:00:53 +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 A85F18FC08 for ; Fri, 22 Oct 2010 11:00:52 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id ED28FE87DA; Fri, 22 Oct 2010 12:00:51 +0100 (BST) Received: from unknown (unknown [109.144.218.156]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 22 Oct 2010 12:00:50 +0100 (BST) Date: Fri, 22 Oct 2010 12:00:56 +0100 From: Bruce Cran To: Tijl Coosemans Message-ID: <20101022120056.0000328a@unknown> In-Reply-To: <201010221207.42994.tijl@coosemans.org> References: <201009161742.24228.tijl@coosemans.org> <864ocf7esp.fsf@ds4.des.no> <4CC0BF96.1050806@fletchermoorland.co.uk> <201010221207.42994.tijl@coosemans.org> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Paul Wootton Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 11:00:53 -0000 On Fri, 22 Oct 2010 12:07:36 +0200 Tijl Coosemans wrote: > FreeBSD frequently accesses hard disks (log files, flushing dirty > memory pages every 30s,...) and laptop drives tend to have aggressive > power saving settings by default. That's why your load cycle is so > high. I'm not sure the APM value updates the idle3 timer inside the drive: it may be necessary to run WD's wdidle3.exe tool to change the power management timer. And yes, people are rather annoyed that it's necessary to have a copy of DOS to update the drive! -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 14:30:25 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63389106566B; Fri, 22 Oct 2010 14:30:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id C86408FC17; Fri, 22 Oct 2010 14:30:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 248532A28CCB; Fri, 22 Oct 2010 16:30:24 +0200 (CEST) Date: Fri, 22 Oct 2010 16:30:24 +0200 From: Ed Schouten To: current@freebsd.org, hackers@freebsd.org Message-ID: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 14:30:25 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ Right now it is already complete enough to replace libgcc.a and libgcc_p.a (mostly math rountines), but it doesn't yet implement the functionality (e.g. unwinder) to replace libgcc_eh.a, libgcc_eh_p.a and libgcc_s.so.1. I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. Right now the only issue I can think of, is that __clear_cache() is broken on ARM, but that can be fixed trivially. My plan would be to commit this work to HEAD by the end of November (1 month from now), but it would be nice if it could get some more testing in the mean time, especially on non-x86 architectures. How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. In the mean time, I'll see if I can get the Ports folks to run an exp-run with this branch, which should already give some coverage. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzBoAAACgkQ52SDGA2eCwWDaACfb/TwZQ9h9UqkuZJ1Lz2WtFp2 HSUAn3P9xtDvcdPbN81gBTfMjhWzswuE =2A+f -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 14:33:11 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4F071065670; Fri, 22 Oct 2010 14:33:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id A878E8FC08; Fri, 22 Oct 2010 14:33:11 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 0D8102A28CCB; Fri, 22 Oct 2010 16:33:11 +0200 (CEST) Date: Fri, 22 Oct 2010 16:33:11 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Hackers Message-ID: <20101022143311.GB94137@hoeg.nl> References: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20101022143024.GA94137@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 14:33:12 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten , 20101022 16:30: > - Rebuild all your software (yes, I know it's unfortunate). Right after I sent this, I thought I'd better clarify this. You don't need to rebuild your software. This change will not break the existing ABI. This step is just mentioned here, since libgcc.a is statically linked into applications. Simply rebuilding and reinstall world is not sufficient to make 3rd party applications use this. --=20 Ed Schouten WWW: http://80386.nl/ --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzBoKcACgkQ52SDGA2eCwWvuwCff0LX4ot9srkQoQA+zSdw5BXa SKQAnj9GZTlhAVQYewy3dKOBgbihCs+o =023B -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 18:17:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28881065670 for ; Fri, 22 Oct 2010 18:17:55 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 450828FC08 for ; Fri, 22 Oct 2010 18:17:54 +0000 (UTC) Received: by bwz3 with SMTP id 3so1470254bwz.13 for ; Fri, 22 Oct 2010 11:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=OjdgKHPhAlSekpqZlI6dlpQDW9tJssgm2HrAr5FWMI4=; b=i1FkfHkfBQJOeTNiDwov5J9N2tkZty6I5cqsNxGwdsJZA+YdbF2KrhqcESAhJO/cvV GhpQCM72QAXoQGo/0R3p27E+nuZlq587n9ZYSo7YThgmvxW51qAHcvhZsTL+qJ6KqLih zM3omUrJFwckdIZkciAjgIGmy8tapX5HO0pDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Y8eNdCsdy/lDcg0ypCPIU5muvGUQFljm4RP5MA6WOte6QmPFlJpaxXX+kHlPobBVlJ uBVUrkyI/eA9sgKV6HwO3lGS4mRrZkmFwt6W20DF4DLsmyVNIRBfakRj0SzyRp8bngdo WlaH2aBBObXGbo0ODKN+Bkl4FcYkbsNi5v2wM= MIME-Version: 1.0 Received: by 10.204.55.135 with SMTP id u7mr2418068bkg.122.1287769614312; Fri, 22 Oct 2010 10:46:54 -0700 (PDT) Received: by 10.204.152.203 with HTTP; Fri, 22 Oct 2010 10:46:54 -0700 (PDT) Date: Fri, 22 Oct 2010 13:46:54 -0400 Message-ID: From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Lock Order Reversal in nmount/unmount of devfs on NFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:17:55 -0000 When mounting a devfs filesystem on top of a directory in an NFS filesystem under 8.1-RELEASE-p1 r213075M, the following lock order reversal is reported: lock order reversal: 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090 KDB: stack backtrace: X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at X_db_sym_numargs+0x146 kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at kdb_backtrace+0x29 witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...) at witness_display_spinlock+0x75 witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0x839 __lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5 vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9 devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+0x102 devfs_rules_apply(c24c6508,80000,d58f6c40,430,0,...) at devfs_rules_apply+0x14a vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0x14c2 nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75 syscall(d58f6d48) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e724b, esp = 0xbf7fddbc, ebp = 0xbf7fe318 --- If I then try to umount the defvs, even if the unmount fails because the path is busy, I get a similar one: lock order reversal: 1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204 2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203 KDB: stack backtrace: X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at X_db_sym_numargs+0x146 kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at kdb_backtrace+0x29 witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...) at witness_display_spinlock+0x75 witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0x839 __lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5 vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288 vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10 dounmount(c2677508,8000000,c2777a00,47e,2,...) at dounmount+0x3ce unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff syscall(d596bd48) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d870f, esp = 0xbf7fe58c, ebp = 0xbf7fe658 --- Both seem to occur only once per boot. I've tried both multiply mounting/unmounting the same filesystem and mounting/unmounting multiple devfs mounts on various different NFS mounts, but I've never gotten more than one report for nmount and one for unmount. It doesn't seem to hurt anything; should I bug report it? If so, is there anything I can do to help with it, as far as further diagnostics or fixing it? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 18:47:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E17A11065672 for ; Fri, 22 Oct 2010 18:47:42 +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 7D0208FC13 for ; Fri, 22 Oct 2010 18:47:41 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9MIlbvC039525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2010 21:47:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9MIlbih099422; Fri, 22 Oct 2010 21:47:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9MIlbk6099421; Fri, 22 Oct 2010 21:47:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Oct 2010 21:47:37 +0300 From: Kostik Belousov To: Linda Messerschmidt Message-ID: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/U3josVVZTqzPL34" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Lock Order Reversal in nmount/unmount of devfs on NFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:47:43 -0000 --/U3josVVZTqzPL34 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote: > When mounting a devfs filesystem on top of a directory in an NFS > filesystem under 8.1-RELEASE-p1 r213075M, the following lock order > reversal is reported: >=20 > lock order reversal: > 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058 > 2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090 > KDB: stack backtrace: > X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at > X_db_sym_numargs+0x146 > kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at > kdb_backtrace+0x29 > witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...) > at witness_display_spinlock+0x75 > witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5 > vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock= +0x62 > VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e > vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9 > devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+= 0x102 > devfs_rules_apply(c24c6508,80000,d58f6c40,430,0,...) at devfs_rules_apply= +0x14a > vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0= x14c2 > nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75 > syscall(d58f6d48) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x22 > --- syscall (378, FreeBSD ELF32, nmount), eip =3D 0x280e724b, esp =3D > 0xbf7fddbc, ebp =3D 0xbf7fe318 --- >=20 > If I then try to umount the defvs, even if the unmount fails because > the path is busy, I get a similar one: >=20 > lock order reversal: > 1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204 > 2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203 > KDB: stack backtrace: > X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at > X_db_sym_numargs+0x146 > kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at > kdb_backtrace+0x29 > witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...) > at witness_display_spinlock+0x75 > witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5 > vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e > insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288 > vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10 > dounmount(c2677508,8000000,c2777a00,47e,2,...) at dounmount+0x3ce > unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff > syscall(d596bd48) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x22 > --- syscall (22, FreeBSD ELF32, unmount), eip =3D 0x280d870f, esp =3D > 0xbf7fe58c, ebp =3D 0xbf7fe658 --- >=20 > Both seem to occur only once per boot. I've tried both multiply > mounting/unmounting the same filesystem and mounting/unmounting > multiple devfs mounts on various different NFS mounts, but I've never > gotten more than one report for nmount and one for unmount. >=20 > It doesn't seem to hurt anything; should I bug report it? If so, is > there anything I can do to help with it, as far as further diagnostics > or fixing it? The LORs are believed to be harmless. --/U3josVVZTqzPL34 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzB3EkACgkQC3+MBN1Mb4hbXgCfSwCrHN5DxzxXYaBxvkkSeMYd NEwAn3Ke9i17HyATQFH4rNhF1ai7Sbr6 =SAew -----END PGP SIGNATURE----- --/U3josVVZTqzPL34-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 19:38:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB651065670 for ; Fri, 22 Oct 2010 19:38:13 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 393588FC14 for ; Fri, 22 Oct 2010 19:38:12 +0000 (UTC) Received: by bwz3 with SMTP id 3so1540555bwz.13 for ; Fri, 22 Oct 2010 12:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2nNilT/pdjrNvHPET9YHIfLFJxyU7ksiBQA2RahrXVI=; b=sBlVZxh6jtrUNzQcprX9iTehMsPavszDcjntPAYVVZqC1qgTsKYyoZaVWFfW2eJCnY hT+OUaOqpAaLnXWd1WNM+tf9ZGP03dS0FrXCNq0/e84750xAOfe4Y/j8pAZcraeDh2kT LG6kDuu81TtW5e9jQmdA4hSgx04ygIni5bAD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WZliFi8NVs0r2Ek/ZVR+8ISp9BxkySgR2rPiy0rGZL3L9b/JE3kpjI4YD1d7v+RchF R0VydxMh7KCWr9hsRmnkAYRMneaBZK8YTlG2FY+CSqSYIahJ99d1jwe7vunuJ+VwoQYl MRFHqxdcco8YKVDb4mWxfZU0L6rM3/IHEpWrk= MIME-Version: 1.0 Received: by 10.204.103.207 with SMTP id l15mr2428850bko.196.1287776291734; Fri, 22 Oct 2010 12:38:11 -0700 (PDT) Received: by 10.204.152.203 with HTTP; Fri, 22 Oct 2010 12:38:11 -0700 (PDT) In-Reply-To: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> References: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> Date: Fri, 22 Oct 2010 15:38:11 -0400 Message-ID: From: Linda Messerschmidt To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Lock Order Reversal in nmount/unmount of devfs on NFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 19:38:13 -0000 On Fri, Oct 22, 2010 at 2:47 PM, Kostik Belousov wrote: > The LORs are believed to be harmless. OK, I won't worry about it. I did check the list on sources.zabbadoz.net and didn't see any for nfs & devfs or nfs & syncer, so I just wanted to be sure. :) Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 21:29:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D346106564A for ; Fri, 22 Oct 2010 21:29:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id EC7548FC13 for ; Fri, 22 Oct 2010 21:29:20 +0000 (UTC) Received: (qmail 14863 invoked by uid 399); 22 Oct 2010 21:29:19 -0000 Received: from localhost (HELO ?192.168.2.18?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Oct 2010 21:29:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CC2022C.9030502@FreeBSD.org> Date: Fri, 22 Oct 2010 14:29:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Lock Order Reversal in nmount/unmount of devfs on NFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:29:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/22/2010 11:47 AM, Kostik Belousov wrote: | The LORs are believed to be harmless. IMO the problem with that line of reasoning is that while any individual LOR may be harmless there are so many harmless ones that it leads to people either ignoring all of them, or turning off witness. I've been in the latter category for years now. It would be great if some effort could go into cleaning up the harmless ones so that when a LOR happens it would actually be worth the user's time to report it. Doug - -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMwgIrAAoJEFzGhvEaGryEPKcH/Ap1oylSMNMr5CfhX09/kMm0 7TW/nvEXqDDk/XN2bdhio/3HM/esU2Gkc0Q5zLtDPUukQzbfTlGEeuARFn2h5Ar2 SnTByZ7NFM6KP+Ksn7cNwyQ/gT71qabxVgLQ9FtxtmvBlAXKjKZ862n7Omz6qoGM YMfESwNyUBTwRe/FxDwjImOlNXASK3Pd8lt4Gr/kyrFYJz1ooq1Biusr1mPaqJVv 7KZecaHXf2q8EmkL2mSpFk59bbuLztUduLkPGPA2/RJFvQ8Y4Jf7kg96CR1vPT7K tCgcudnlcOCgMsUu9lpzTvW6H2Ffu4H33nJ5bVgbDLHKwxv0g3iLPgva8Q57CIw= =g/dp -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 23 08:52:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA510106566B; Sat, 23 Oct 2010 08:52:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id A39BD8FC08; Sat, 23 Oct 2010 08:52:25 +0000 (UTC) Received: from [109.84.147.79] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1P9Zpu-0000YH-Q7; Sat, 23 Oct 2010 10:52:23 +0200 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id o9N8rhYd001446; Sat, 23 Oct 2010 10:53:44 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id o9N8rh4I001445; Sat, 23 Oct 2010 10:53:43 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Resent-From: guru@tiny.Sisis.de Resent-Date: Sat, 23 Oct 2010 10:53:42 +0200 Resent-Message-ID: <20101023085342.GA1439@tiny.Sisis.de> Resent-To: freebsd-hackers@freebsd.org, freebsd-usb@freebsd.org Date: Sat, 23 Oct 2010 10:49:56 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org Message-ID: <20101023084956.GA1362@tiny.Sisis.de> References: <20100905081917.GA2212@current.Sisis.de> <20100909063514.GA2333@current.Sisis.de> <20100910061629.GA2461@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910061629.GA2461@current.Sisis.de> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 109.84.147.79 Cc: freebsd-usb@freebsd.org Subject: USB key && can't mount /root during boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 08:52:26 -0000 Hello, I have now again the same problem (see Subject) again with a new laptop Acer Aspire One D250 and neither of the two values in loader.conf: kern.cam.boot_delay="10000" kern.cam.scsi_delay="10000" seems to help. The 10 sec delay is not even visible during the boot, the message to enter manually the root device just pops up without any delay. What does this mean? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 23 12:02:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CBA71065674; Sat, 23 Oct 2010 12:02:11 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 934758FC21; Sat, 23 Oct 2010 12:02:10 +0000 (UTC) Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.176.132]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id BA4581641E9E; Sat, 23 Oct 2010 15:15:46 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:Reply-To:From:Date; bh=HxQ0radFYM8n7yR3vxXbW9E5/Ozy0LeZC9sRXmovxyo=; b=CdZ+X6OzTHIALGbTivvEPOdslwFqgQNYo2RulwKPAm6JQvcdpNA/JY8Lb7Mzc+aj7t6LIgSgpODvB77l1XFCnr7ic2kQUpVCr4SJihEFPaazodbVUHr7SRJ06B9WulP/; Received: from [91.190.115.253] (port=28111 helo=pstation) by smtp5.mail.ru with asmtp id 1P9c4d-0002JH-00; Sat, 23 Oct 2010 15:15:43 +0400 Date: Sat, 23 Oct 2010 15:20:13 +0400 From: Anthony Pankov X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <168417535437.20101023152013@mail.ru> To: freebsd-hackers@freebsd.org In-Reply-To: <1286924785.32724.17.camel@localhost.localdomain> References: <1286397912.27308.40.camel@localhost.localdomain> <4CB34BF9.4050504@FreeBSD.org> <1286824968.30494.46.camel@localhost.localdomain> <4CB4B293.1050505@FreeBSD.org> <1286924785.32724.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mras: Ok X-MR-Warn: 1 Cc: Doug Barton , Devin Teske Subject: Re[2]: sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anthony Pankov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 12:02:11 -0000 Greetings. Just for note. Some time ago i thought about the same problem. I started something then had delayed it forever in favour of fast wrong way. So, the aim was: --- NAME modcfg - modify configuration SYNOPSIS modcfg -f config_file -t config_type {-s param=val | -u param} modcfg -l modcfg -i plugin DESCRIPTION The modcfg utility modifies configuration file in accordance to parameters. The following options are available: -f config_file - the file itself which to be modified -t config_type - type of config_file. Type specifies the internal structure of config_file, or, more roughly, program which this file belongs to. To list available types see -l option. -s param=val - set configuration parameter 'param' to value 'val'. -u param - unset configuration parameter 'param' (or set it to default). -l - list all supported types of config files. -i plugin - install plugin 'plugin' for modcfg utility. Plugin is used to support additional configuration file type. EXAMPLES The command modcfg -f /etc/rc.conf -t rc -s keymap=ru.cp1251 sets parameter 'keymap' to value 'ru.cp1251'in file rc.conf. The command modcfg -f /etc/rc.conf -t rc -u keymap resets parameter 'keymap' to default value. To install obtained plugin 'samba.mcfg' use modcfg -i samba.mcfg After that configuration type 'samba' will be supported. --- INTERNALLY modcfg itself is very simple. It parse command line options, then load plugin (module) for specified 'config_type', then call _set(file,param, value) or _unset(file,param) function from this module. So, plugin (module) should have functions such as: _set(file, param, value) or, better name, {$type}_set. rc_set, for example. _unset(file, param) _description - for display in module list. FUTURE Of course, better way is to run modcfg as: modcfg rc {-s ... | -u ...} i.e. reduce "-f /etc/rc.conf -t rc" to the key "rc", i.e. add another call scheme modcfg subsystem {-s ... | -u ...} For rc it is trivial. But in general, for all installed programs and they instances, it is not possible now. Wednesday, October 13, 2010, 3:06:25 AM, you wrote: DT> On Tue, 2010-10-12 at 12:10 -0700, Doug Barton wrote: >> On 2010-10-11 at 10:40 -0700, Doug Barton wrote: >> | So to summarize, the general idea is a good one and needed, and an area >> | that I'd like to see more work in. Perhaps it might be a good idea to >> | move the discussion about that to freebsd-rc@? >> | >> |On 2010-10-11 at 12:22 -0700, Devin Teske wrote: >> |> I'll look into signing up for the rc mailing list (didn't see that when >> |> I checked last -- I'll have to look again). Maybe I'll post v2.0 to >> |> there (but will cc back hackers cause I know folks may not be part of >> |> both). >> >> The canonical way to deal with that is to post the message to the proper >> list (-rc@), then post a brief note to the other list (-hackers@) saying >> where the discussion is being continued. We discourage people from >> cc'ing multiple FreeBSD lists. DT> This thread is moving over to the -rc@ list. DT> New thread: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) DT> The first post to the -rc@ list will be version 2.0 of the script which DT> attempts to address the following (which were discussed in this thread DT> here on -hackers@): DT> 1. Style -- remove some personal styles in favor of standardized styles. DT> (the FreeBSD environment doesn't need all the extra things that are DT> required to run in an embedded environment -- which the first version DT> was coded for) DT> 2. Remove a disgusting-amount of comments (the first release of the DT> script had a hurdle to climb in that it had to establish rapport with DT> the targeted audience -- y'all). DT> 3. Remove shell inheritance of SUCCESS/FAILURE (this was silly for a DT> finished product). DT> 4. Remove unnecessary code-sense (some things just don't need to be DT> tested for in a known environment -- such as FreeBSD vs. embedded). DT> 5. Remove dependency checks (have(), depend(), and show_deps() are DT> gone). DT> 6. Remove fake "function" keywords (public objections win) DT> 7. Rename sysrc() function to sysrc_get() to: DT> a. prevent confusion between the script and the internal function DT> b. to coincide with the remainder of related functions (sysrc_get, DT> sysrc_set, sysrc_find, and sysrc_desc). DT> 8. Fix sysrc_get() function to mask positional parameters (don't expand DT> "1", "2", etc.) DT> 9. Fix sysrc_get() function to clean the environment prior to sourcing DT> rc.conf(5) files (preventing expansion of normals such as PS1, TERM, DT> etc.) DT> 10. New function: `sysrc_find $varname' DT> Find which file holds the effective last-assignment to a given variable DT> within the rc.conf(5) file(s). If the variable is found in any of the DT> rc.conf(5) files, the function prints the filename it was found in and DT> then returns success. Otherwise output is NULL and the function returns DT> with error status. DT> 11. Fix sysrc_set() function to use mktemp(1) (prevent race-conditions DT> where sysrc(8) could be executing in concurrence, possibly whacking the DT> output-file in an unexpected manner). DT> 12. New function: `sysrc_desc $varname' DT> Attempts to return the comments associated with varname from the rc.conf DT> (5) defaults file `/etc/defaults/rc.conf' (or whatever RC_DEFAULTS DT> points to). Multi-line comments are joined together. Results are NULL if DT> no description could be found. DT> 13. Use getopts(1) to parse command-line options rather than manually DT> parsing (now we can support grouping of flags -- i.e. "-avN"). DT> 14. Remove `--help' option (using getopts(1) now ... that was the only DT> long-option we had, and we don't need it). DT> 15. Remove `-d' as we know it. No longer dump internal dependency list, DT> but mimick `-d' from sysctl(8) -- Print a description of the given DT> variable. DT> 16. Remove `SYSRC_SHOW_DEPS' environment variable. DT> 17. Add `SYSRC_VERBOSE' environment variable (inheritable from the DT> shell, so that folks whom don't want to always pass `-v' can plop DT> `SYSRC_VERBOSE=1' into their shell startup scripts, `~/.bash_profile' DT> and `~/.profile' for example). DT> 18. Add `-f file' option. DT> Operate on the specified file(s) instead of rc_conf_files. DT> 19. Add `-a' option. DT> Dump a list of non-default configuration variables. DT> 20. Add `-A' option. DT> Dump a list of all configuration variables (incl. defaults). DT> 21. Add `-v' option. DT> Verbose. Print the pathname of the specific rc.conf(5) file where the DT> directive was found. DT> 22. Add `-i' option. DT> Ignore unknown variables. DT> 23. Add `-N' option. DT> Show only variable names, not their values. DT> And, here's the new usage: DT> Usage: sysrc [OPTIONS] name[=value] ... DT> OPTIONS: DT> -h Print this message to stderr and exit. DT> -f file Operate on the specified file(s) instead of rc_conf_files. DT> -a Dump a list of non-default configuration variables. DT> -A Dump a list of all configuration variables (incl. defaults). DT> -d Print a description of the given variable. DT> -e Print query results as `var=value' (useful for producing DT> output to be fed back in). Ignored if -n is specified. DT> -v Verbose. Print the pathname of the specific rc.conf(5) DT> file where the directive was found. DT> -i Ignore unknown variables. DT> -n Show only variable values, not their names. DT> -N Show only variable names, not their values. DT> ENVIRONMENT: DT> RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. DT> SYSRC_VERBOSE Default verbosity. Set to non-NULL to enable. DT> See you all on the -rc@ list. -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 23 13:36:25 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023171065698; Sat, 23 Oct 2010 13:36:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3598FC17; Sat, 23 Oct 2010 13:36:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 8EE1A2A28CCB; Sat, 23 Oct 2010 15:36:23 +0200 (CEST) Date: Sat, 23 Oct 2010 15:36:23 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Hackers Message-ID: <20101023133623.GE94137@hoeg.nl> References: <20101022143024.GA94137@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lb0e7rgc7IsuDeGj" Content-Disposition: inline In-Reply-To: <20101022143024.GA94137@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 13:36:25 -0000 --Lb0e7rgc7IsuDeGj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, * Ed Schouten , 20101022 16:30: > At EuroBSDCon I was talking with some committers active in the area of > Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC > 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed > implementation called libcompiler_rt. See: >=20 > http://compiler-rt.llvm.org/ I was talking with Robert Watson about this the other day. The codebase of compiler-rt also contains the libBlocksRuntime.so library, which is fundamental in making Grand Central Dispatch (GCD) work. Because of its small size (12 KB), I think I'll also include it in the import. This means that after the import, libdispatch is the only port needed to make Grand Central Dispatch work on FreeBSD HEAD. --=20 Ed Schouten WWW: http://80386.nl/ --Lb0e7rgc7IsuDeGj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzC5NcACgkQ52SDGA2eCwXYJgCfU5IGoxU9aMOMS/YYTAdQyUhh ypsAnRn4AC+GdZGdOc3qz88wDg7fv1Pe =kjS1 -----END PGP SIGNATURE----- --Lb0e7rgc7IsuDeGj-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 23 15:44:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87650106566C for ; Sat, 23 Oct 2010 15:44:55 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1538FC08 for ; Sat, 23 Oct 2010 15:44:55 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id A95691E009CB; Sat, 23 Oct 2010 17:27:36 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o9NFPhDI084058; Sat, 23 Oct 2010 17:25:43 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o9NFPgnV084057; Sat, 23 Oct 2010 17:25:42 +0200 (CEST) (envelope-from nox) Date: Sat, 23 Oct 2010 17:25:42 +0200 (CEST) From: Juergen Lock Message-Id: <201010231525.o9NFPgnV084057@triton8.kn-bremen.de> To: xorquewasp@googlemail.com X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <20101019204409.GA5603@logik.internal.network> Organization: home X-Mailman-Approved-At: Sat, 23 Oct 2010 16:10:10 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Radeon DRI/3D status X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 15:44:55 -0000 In article <20101019204409.GA5603@logik.internal.network> you write: >Hello. Hi! > >What's the current status of DRI/3D support with the 4xxx range of ATI >cards? > >I'm on 8.0-RELEASE and have just installed a (borrowed) 4870 card. I >get working dual monitor support but only software rasterization in >xorg. > >The intention is to replace a broken x1950 card with something at least >slightly newer but I can't find any real information (other than an >apparently outdated wiki page) that suggests anything is or isn't >supported. See /usr/ports/UPDATING entry from 20100207, you need to define WITHOUT_NOUVEAU to get opengl on Radeon HD [234]xxx. HTH, Juergen