From owner-freebsd-stable@FreeBSD.ORG Sun Jan 20 06:19:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCA9748A; Sun, 20 Jan 2013 06:19:57 +0000 (UTC) (envelope-from marketing@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 516161C2; Sun, 20 Jan 2013 06:19:57 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id E58BBC5DE24; Sun, 20 Jan 2013 02:10:35 -0400 (AST) Received: from hub.org ([200.46.204.220]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 78102-04; Sun, 20 Jan 2013 06:10:35 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id D09AAC5DE23; Sun, 20 Jan 2013 02:10:34 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Hub- Marketing In-Reply-To: <201301190757.26398.jhb@freebsd.org> Date: Sat, 19 Jan 2013 22:10:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7387292F-94CD-4643-91D4-748404B792F1@hub.org> References: <201301190757.26398.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 06:19:57 -0000 On 2013-01-19, at 4:57 AM, John Baldwin wrote: > On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: >> I'm running a few servers sitting on top of a NetAPP file server =85 >> everything runs great, but periodically I'm getting: >>=20 >> nfs_getpages: error 13 >> vm_fault: pager read error, pid 11355 (https) >=20 > Are you using interruptible mounts ("intr" mount option)? 192.168.1.253:/vol/vol1 /vm nfs rw,intr,soft,nolockd 0 = 0 I just added the 'soft' option to the mix =85 nolockd is enabled since I = know for a fact that its not possible for two processes to access the = same file on both mounts at the same time =85=20 > Also, can you get ps output that includes the 'l' flag to show what > the processes are stuck on? I will send an follow up the next time this happens, so it may be a few = days =85=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 20 12:28:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42770A23; Sun, 20 Jan 2013 12:28:01 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id A93E4F07; Sun, 20 Jan 2013 12:28:00 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e52so2403474eek.20 for ; Sun, 20 Jan 2013 04:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=4J2T/XicdmMgSmAvcFkbrMv5htRiqNzyKnj02VVgWGs=; b=P82oWSxhn78jlsLPxluYbyUFlgsfuijRzsy7yk6tQW8FMZ66VafRJ1KjDcoOzYhjBo duRRwpY0/Sj9mtwr5HnT7hoO6Us22IOaNS8KBjb7chuD58ftaLnUBGQs+0AOt31m+esH YV2BnYX//JLJnN9dsm4lemXli+QQZJyM/LFYpuafPH9wrVduMHa0xz8UPMkSdNBfLCoU zyM00VWJ2/G8a8G0MQoD2q9gq9JOtD+iM9pW/+nFiBkkuhEiBy2qpfotWcop7emI7FrM fNUNGKIbpLiOwBNH6M/MYh5+p3T8y666XAweBPeUNxmWkf5qjP3sxfNRoafsVXHQyLVt GpJA== X-Received: by 10.14.175.70 with SMTP id y46mr48309121eel.6.1358684398459; Sun, 20 Jan 2013 04:19:58 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id 46sm17070663eeg.4.2013.01.20.04.19.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 20 Jan 2013 04:19:57 -0800 (PST) Sender: Mikolaj Golub Date: Sun, 20 Jan 2013 14:19:55 +0200 From: Mikolaj Golub To: freebsd-stable@freebsd.org Subject: libstdc++, libsupc++, delete operators and valgrind Message-ID: <20130120121954.GA4634@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 12:28:01 -0000 Hi, Some time ago I noticed that valgrind started to complain about "Mismatched free() / delete / delete []" for valid new/delete combinations. For example, the following test program int main() { char* buf = new char[10]; delete [] buf; return 0; } produced a warning: ==38718== Mismatched free() / delete / delete [] ==38718== at 0x100416E: free (vg_replace_malloc.c:473) ==38718== by 0x4007BE: main (test.cpp:5) ==38718== Address 0x2400040 is 0 bytes inside a block of size 10 alloc'd ==38718== at 0x10047D7: operator new[](unsigned long) (vg_replace_malloc.c:382) ==38718== by 0x40079D: main (test.cpp:4) For some time I hoped that "someone" would fix the problem but seeing that after several upgrades it was still there I decided it is time to do some investigations. Running the valgrind with "--trace-redir=yes -v" showed that valgrind activates redirections for new/delete symbols in libstdc++: --6729-- Reading syms from /usr/lib/libstdc++.so.6 (0x1209000) ... --6729-- ------ ACTIVE ------ ... --6729-- 0x01260770 (operator new[](unsig) R-> (1001.0) 0x010041b0 operator new[](unsigned long, std::nothrow_t const&) --6729-- 0x01260780 (operator new(unsigne) R-> (1001.0) 0x01004270 operator new(unsigned long, std::nothrow_t const&) --6729-- 0x012608a0 (operator delete[](vo) R-> (1005.0) 0x01003e40 operator delete[](void*, std::nothrow_t const&) --6729-- 0x012608b0 (operator delete(void) R-> (1005.0) 0x01003fa0 operator delete(void*, std::nothrow_t const&) --6729-- 0x012dea90 (operator new[](unsig) R-> (1003.0) 0x01004770 operator new[](unsigned long) --6729-- 0x012deab0 (operator new(unsigne) R-> (1003.0) 0x01004860 operator new(unsigned long) --6729-- 0x012deca0 (operator delete[](vo) R-> (1005.0) 0x01003ef0 operator delete[](void*) --6729-- 0x012e2b80 (operator delete(void) R-> (1005.0) 0x01004050 operator delete(void*) But "delete" redirection is not triggered, while "new" is: --6729-- REDIR: 0x12dea90 (operator new[](unsigned long)) redirected to 0x1004770 (operator new[](unsigned long)) --6729-- REDIR: 0x19dd9a0 (free) redirected to 0x1004100 (free) ==6729== Mismatched free() / delete / delete [] ==6729== at 0x100416E: free (vg_replace_malloc.c:473) ==6729== by 0x400715: main (test.cpp:5) ==6729== Address 0x1ed7040 is 0 bytes inside a block of size 10 alloc'd ==6729== at 0x10047D7: operator new[](unsigned long) (vg_replace_malloc.c:382) ==6729== by 0x400701: main (test.cpp:4) A little research revealed that in this case the delete operator from libsupc++ is called and valgrind does not provide redirections for the symbols in libsupc++. When I added the redirections for libsupc++ to valgrind's vg_replace_malloc.c: #define VG_Z_LIBSUPCXX_SONAME libsupcZpZpZa // libsupc++* FREE(VG_Z_LIBSUPCXX_SONAME, _ZdlPv, __builtin_delete ); FREE(VG_Z_LIBSUPCXX_SONAME, _ZdlPvRKSt9nothrow_t, __builtin_delete ); FREE(VG_Z_LIBSUPCXX_SONAME, _ZdaPv, __builtin_vec_delete ); FREE(VG_Z_LIBSUPCXX_SONAME, _ZdaPvRKSt9nothrow_t, __builtin_vec_delete ); the issue was fixed: --99254-- Reading syms from /usr/lib/libstdc++.so.6 ... --99254-- ------ ACTIVE ------ ... --99254-- 0x012627c0 (operator new[](unsig) R-> (1001.0) 0x01004ce0 operator new[](unsigned long, std::nothrow_t const&) --99254-- 0x012627d0 (operator new(unsigne) R-> (1001.0) 0x01004860 operator new(unsigned long, std::nothrow_t const&) --99254-- 0x012628d0 (operator delete[](vo) R-> (1005.0) 0x01005b00 operator delete[](void*, std::nothrow_t const&) --99254-- 0x012628e0 (operator delete(void) R-> (1005.0) 0x01005500 operator delete(void*, std::nothrow_t const&) --99254-- 0x012c27e0 (operator new[](unsig) R-> (1003.0) 0x01004a80 operator new[](unsigned long) --99254-- 0x012c2800 (operator new(unsigne) R-> (1003.0) 0x01004430 operator new(unsigned long) --99254-- 0x012c29a0 (operator delete[](vo) R-> (1005.0) 0x01005800 operator delete[](void*) --99254-- 0x012c3e40 (operator delete(void) R-> (1005.0) 0x01005200 operator delete(void*) ... --99254-- Reading syms from /usr/lib/libsupc++.so.1 ... --99254-- ------ ACTIVE ------ ... --99254-- 0x01cae1f0 (operator delete[](vo) R-> (1005.0) 0x01005a00 operator delete[](void*, std::nothrow_t const&) --99254-- 0x01cae200 (operator delete[](vo) R-> (1005.0) 0x01005700 operator delete[](void*) --99254-- 0x01cae210 (operator delete(void) R-> (1005.0) 0x01005400 operator delete(void*, std::nothrow_t const&) --99254-- 0x01cb73d0 (operator delete(void) R-> (1005.0) 0x01005100 operator delete(void*) ... --99254-- REDIR: 0x12c27e0 (operator new[](unsigned long)) redirected to 0x1004a80 (operator new[](unsigned long)) --99254-- REDIR: 0x1cae200 (operator delete[](void*)) redirected to 0x1005700 (operator delete[](void*)) Now the question is: is it ok that now we have "new" operators being still called via libstdc++ while "delete" operators being called directly from libsupc++? If it is ok, is the proposed solution with adding redirects for libsupc++ is a right way to fix the valgrind? -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Jan 20 13:44:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1170BC50 for ; Sun, 20 Jan 2013 13:44:49 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7619C2EE for ; Sun, 20 Jan 2013 13:44:47 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jk14so55147bkc.21 for ; Sun, 20 Jan 2013 05:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6xTIYGc+DKK7uyBOUeuHc16WJVyt+xQQ1Ifi8d6aZB8=; b=MOnOi0zV7gvtTqMCW/BmTpUBUNKaLES41ndFpQ1Tgghz2F4kFlv3y8dRLSZIvxHnm6 WIy+sk+2FkNz2licunLJ9AAKAEjT84c8C35a8NPgBeXb6jKe0GP0zWbOZ1qPBmoQIMQH LFb5W8xW6k8WEXAwUbYDsKStHWqXVBDweKD6AkVmmCfWP8xmkZRG7ZIcWP7qqI4R+zE9 AaiDO26xl4fvDcfYEG5zlI4Us5FnOEn/glYqXBbxdvGT4iruOQkJJIFPJlKavFBRVb+h rPEIV0DP2qxx/A9jhu+CFgdp1kGeDkjzi6nf8/B0x59bz6HIATCrUhFWdiP2bcp+e7j1 QCag== MIME-Version: 1.0 X-Received: by 10.204.147.147 with SMTP id l19mr3957396bkv.91.1358689481212; Sun, 20 Jan 2013 05:44:41 -0800 (PST) Received: by 10.204.179.146 with HTTP; Sun, 20 Jan 2013 05:44:40 -0800 (PST) In-Reply-To: <20130119201914.84B761CB@server.theusgroup.com> References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> Date: Sun, 20 Jan 2013 15:44:40 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: John Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 13:44:49 -0000 On Sat, Jan 19, 2013 at 10:19 PM, John wrote: > >At 03:00am I can see that periodic(8) runs, but I don't see what could > have > >taken so much of the free memory. I'm also running this system on ZFS and > >have daily rotating ZFS snapshots created - currently the number of ZFS > >snapshots are > 1000, and not sure if that could be causing this. Here's a > >list of the periodic(8) daily scripts that run at 03:00am time. > > > >% ls -1 /etc/periodic/daily > >800.scrub-zfs > > > >% ls -1 /usr/local/etc/periodic/daily > >402.zfSnap > >403.zfSnap_delete > > On a couple of my zfs machines, I've found running a scrub along with other > high file system users to be a problem. I therefore run scrub from cron > and > schedule it so it doesn't overlap with periodic. > > I also found on a machine with an i3 and 4G ram that overlapping scrubs and > snapshot destroy would cause the machine to grind to the point of being > non-responsive. This was not a problem when the machine was new, but > became one > as the pool got larger (dedup is off and the pool is at 45% capacity). > > I use my own zfs management script and it prevents snapshot destroys from > overlapping scrubs, and with a lockfile it prevents a new destroy from > being > initiated when an old one is still running. > > zfSnap has its -S switch to prevent actions during a scrub which you should > use if you haven't already. > > Hi John, Thanks for the hints. It was a long time since I've setup zfSnap and I've just checked the configuration and I am using the "-s -S" flags, so there should be no overlapping. Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying to reboot the system (which appears to be discussed a lot in a separate thread). Then I've updated to stable/9, so at the least the reboot issue is now solved. Since I've to stable/9 I'm monitoring the system's memory usage and so far it's been pretty stable, so I'll keep an eye of an update to stable/9 has actually fixed this strange issue. Thanks again, Marin > Since making these changes, a machine that would have to be rebooted > several > times a week has now been up 61 days. > > John Theus > TheUs Group > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jan 20 14:07:35 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C163164C; Sun, 20 Jan 2013 14:07:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 85A2E3EE; Sun, 20 Jan 2013 14:07:35 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id F13AE153434; Sun, 20 Jan 2013 15:07:33 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur3f4ylVkqfn; Sun, 20 Jan 2013 15:07:33 +0100 (CET) Received: from [192.168.10.10] (vaio [192.168.10.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 436D8153433; Sun, 20 Jan 2013 15:07:32 +0100 (CET) Message-ID: <50FBFA2C.2010504@digiware.nl> Date: Sun, 20 Jan 2013 15:07:40 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Failsafe on kernel panic References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> In-Reply-To: <1358392725.32417.179.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Sami Halabi , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 14:07:35 -0000 On 17-1-2013 4:18, Ian Lepore wrote: > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: >> Thank you for your response, very helpful. >> one question - how do i configure auto-reboot once kernel panic occurs? >> >> Sami >> > > From src/sys/conf/NOTES, this may be what you're looking for... > > # > # Don't enter the debugger for a panic. Intended for unattended operation > # where you may want to enter the debugger from the console, but still want > # the machine to recover from a panic. > # > options KDB_UNATTENDED > > But I think it only has meaning if you have option KDB in effect, > otherwise it should just reboot itself after a 15 second pause. Well it is not the magical fix-all solution. Last night I had to drive to the colo (lucky for me a 5 min drive.) because I could not get a system to reboot/recover from a crash. Upon arrival the system was crashed and halted on the message: rebooting in 15 sec. Which but those 15 secs are would have gone by for about 10-20 minutes. fysically rebooting or resetting ended up in the same position: rebooting in 15 sec. Without ever getting to actually rebooting. So if I (you) have servers 2 hours away, I usually try to work on upgrading/rebooting during business hours. And remote hands can get me out of trouble.... IPMI is another nice way of getting at the server in these cases. But that requires a lot more infra and tinkering. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jan 20 14:47:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82166D53 for ; Sun, 20 Jan 2013 14:47:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42617714 for ; Sun, 20 Jan 2013 14:47:28 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 658DBB924; Sun, 20 Jan 2013 09:47:27 -0500 (EST) From: John Baldwin To: "Hub- Marketing" Subject: Re: 9-STABLE -> NFS -> NetAPP: Date: Sun, 20 Jan 2013 09:47:11 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201301190757.26398.jhb@freebsd.org> <7387292F-94CD-4643-91D4-748404B792F1@hub.org> In-Reply-To: <7387292F-94CD-4643-91D4-748404B792F1@hub.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201301200947.11580.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 20 Jan 2013 09:47:27 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 14:47:28 -0000 On Sunday, January 20, 2013 01:10:29 AM Hub- Marketing wrote: > On 2013-01-19, at 4:57 AM, John Baldwin wrote: > > On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: > >> I'm running a few servers sitting on top of a NetAPP file server =85 > >> everything runs great, but periodically I'm getting: > >>=20 > >> nfs_getpages: error 13 > >> vm_fault: pager read error, pid 11355 (https) > >=20 > > Are you using interruptible mounts ("intr" mount option)? >=20 > 192.168.1.253:/vol/vol1 /vm nfs rw,intr,soft,nolockd 0 = =20 > 0 >=20 > I just added the 'soft' option to the mix =85 nolockd is enabled since I = know > for a fact that its not possible for two processes to access the same file > on both mounts at the same time =85 Ah, ok. I just fixed a bug with interruptible mounts in HEAD where having a signal interrupt an NFS request returns EACCESS (13) rather than EINTR. You should retest with that fix applied. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 01:25:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 740EA987; Mon, 21 Jan 2013 01:25:05 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 38131F63; Mon, 21 Jan 2013 01:25:04 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 633EF11F19A0; Sun, 20 Jan 2013 21:25:03 -0400 (AST) Received: from hub.org ([200.46.204.220]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 63990-08; Mon, 21 Jan 2013 01:25:02 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 13EFE11F199F; Sun, 20 Jan 2013 21:25:01 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <201301200947.11580.jhb@freebsd.org> Date: Sun, 20 Jan 2013 17:24:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201301190757.26398.jhb@freebsd.org> <7387292F-94CD-4643-91D4-748404B792F1@hub.org> <201301200947.11580.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 01:25:05 -0000 Yup, saw those commits =85am going through the servers and doing = upgrades on them =85 will report on any issues post-upgrade =85 thx On 2013-01-20, at 6:47 AM, John Baldwin wrote: > On Sunday, January 20, 2013 01:10:29 AM Hub- Marketing wrote: >> On 2013-01-19, at 4:57 AM, John Baldwin wrote: >>> On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: >>>> I'm running a few servers sitting on top of a NetAPP file server =85 >>>> everything runs great, but periodically I'm getting: >>>>=20 >>>> nfs_getpages: error 13 >>>> vm_fault: pager read error, pid 11355 (https) >>>=20 >>> Are you using interruptible mounts ("intr" mount option)? >>=20 >> 192.168.1.253:/vol/vol1 /vm nfs rw,intr,soft,nolockd = 0 =20 >> 0 >>=20 >> I just added the 'soft' option to the mix =85 nolockd is enabled = since I know >> for a fact that its not possible for two processes to access the same = file >> on both mounts at the same time =85 >=20 > Ah, ok. I just fixed a bug with interruptible mounts in HEAD where = having > a signal interrupt an NFS request returns EACCESS (13) rather than = EINTR. > You should retest with that fix applied. >=20 > --=20 > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 11:33:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62ADA134 for ; Mon, 21 Jan 2013 11:33:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE70A2A for ; Mon, 21 Jan 2013 11:33:24 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TxFcr-0006dx-MX; Mon, 21 Jan 2013 13:33:17 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: time issues and ZFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2013 13:33:17 +0200 From: Daniel Braniss Message-ID: Cc: Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 11:33:25 -0000 After many trials (and errors), here are some facts: host: DELL PowerEdge R710, 16GB, mfi0: mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal mfi1: mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is optimal we have NO problems with FreeBSD-8.3-STABLE, but with 9.1-STABLE, the real-time clock slows down when doing some zfs stuff like send|receive, typing 'date' when less that 1000s went by seems to crorrect the problem, ntpd kicks in and on track again. I have a cron job just logging date every 5 minutes, and the loghost sees: |-- local time on loghost | time on problematic host Jan 20 19:56:19 store-02.cs.huji.ac.il Jan 20 19:56:19 danny: Sun Jan 20 19:56:19 IST 2013 -- ok Jan 20 20:15:00 store-02.cs.huji.ac.il Jan 20 20:15:00 danny: Sun Jan 20 20:15:00 IST 2013 -- ok Jan 20 21:30:00 store-02.cs.huji.ac.il Jan 20 20:21:06 danny: Sun Jan 20 20:21:06 IST 2013 -- off by 1:09 Jan 20 21:33:53 store-02.cs.huji.ac.il Jan 20 20:25:00 danny: Sun Jan 20 20:25:00 IST 2013 -- off by 1:08 Jan 20 21:38:54 store-02.cs.huji.ac.il Jan 20 20:30:00 danny: Sun Jan 20 20:30:00 IST 2013 -- off by 1:09 ... Jan 20 22:03:54 store-02.cs.huji.ac.il Jan 20 20:55:00 danny: Sun Jan 20 20:55:00 IST 2013 -- diff is now constant .. Jan 20 22:04:13 store-02.cs.huji.ac.il Jan 20 20:55:19 ntpd[1848]: time correction of 4134 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. ... Jan 20 22:58:53 store-02.cs.huji.ac.il Jan 20 21:50:00 danny: Sun Jan 20 21:50:00 IST 2013 strangely, when running 8.3, ACPI-fast is chosen: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) but with 9.1 TSC-low gets chosen: kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000) so I did sysctl kern.timecounter.hardware=ACPI-fast, but the same happens - unless it can't be changed after boot. I realy need help here! thanks, danny From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 14:13:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4189C359 for ; Mon, 21 Jan 2013 14:13:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id D62A62AB for ; Mon, 21 Jan 2013 14:13:16 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id o1so4964628wic.6 for ; Mon, 21 Jan 2013 06:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rdkm/WjM8aH1ts6nFWZbp249V+OlWZQ4kV0Cr7SYCr4=; b=lMPPag9BDIcyfU5u1+32DtZlthlofgitUnevcQVslcKa8aeLj+hVCdV3lHrYmw6EXs qz0GLyjTB9kCbJfc2mQs2dSIPO6hufYOYVw1qbd6cNOSzHeHovwfqhRaYBcgl3X3vQkM 7a6szcUPIVs7u/mcS5vM6kdAS2ebWuTy3feCOaIzuiv2SmKAKZ/SNYH9sEnpxzjJEEQ7 xfU2+rLsBVv4WxUh3idHzqqP2IeHJaHp3p7W5I09iLD4Znn3ZC4/Ce9rFF3T3ePjZ+oX 1PZtNHy3EcHYsvnJM0H7BKShqZmsv6d/kMmQIRZSQ6bmlwCVtJPuJ6UDl+rfefM6bhV7 VN0g== MIME-Version: 1.0 X-Received: by 10.194.172.197 with SMTP id be5mr15471433wjc.20.1358777582220; Mon, 21 Jan 2013 06:13:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.123.73 with HTTP; Mon, 21 Jan 2013 06:13:02 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 06:13:02 -0800 X-Google-Sender-Auth: GVxhkjZ3sYMUzVldjWD2ou1FCxY Message-ID: Subject: Re: time issues and ZFS From: Adrian Chadd To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:13:17 -0000 Hi, Try experimenting with kern.eventtimer.periodic and kern.eventtimer.idletick. If this fixes it for you, please file a PR with all the relevant details. Thanks! Adrian On 21 January 2013 03:33, Daniel Braniss wrote: > After many trials (and errors), here are some facts: > > host: DELL PowerEdge R710, 16GB, > mfi0: > mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal > mfi1: > mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is > optimal > > we have NO problems with FreeBSD-8.3-STABLE, but with 9.1-STABLE, the real-time > clock slows down when doing some zfs stuff like send|receive, typing 'date' > when less that 1000s went by seems to crorrect the problem, > ntpd kicks in and on track again. > > I have a cron job just logging date every 5 minutes, and the loghost sees: > > |-- local time on loghost | time on problematic host > Jan 20 19:56:19 store-02.cs.huji.ac.il Jan 20 19:56:19 danny: Sun Jan 20 > 19:56:19 IST 2013 -- ok > Jan 20 20:15:00 store-02.cs.huji.ac.il Jan 20 20:15:00 danny: Sun Jan 20 > 20:15:00 IST 2013 -- ok > Jan 20 21:30:00 store-02.cs.huji.ac.il Jan 20 20:21:06 danny: Sun Jan 20 > 20:21:06 IST 2013 -- off by 1:09 > Jan 20 21:33:53 store-02.cs.huji.ac.il Jan 20 20:25:00 danny: Sun Jan 20 > 20:25:00 IST 2013 -- off by 1:08 > Jan 20 21:38:54 store-02.cs.huji.ac.il Jan 20 20:30:00 danny: Sun Jan 20 > 20:30:00 IST 2013 -- off by 1:09 > ... > Jan 20 22:03:54 store-02.cs.huji.ac.il Jan 20 20:55:00 danny: Sun Jan 20 > 20:55:00 IST 2013 -- diff is now constant > .. > Jan 20 22:04:13 store-02.cs.huji.ac.il Jan 20 20:55:19 ntpd[1848]: time > correction of 4134 seconds exceeds sanity limit (1000); set clock manually to > the correct UTC time. > ... > Jan 20 22:58:53 store-02.cs.huji.ac.il Jan 20 21:50:00 danny: Sun Jan 20 > 21:50:00 IST 2013 > > > strangely, when running 8.3, ACPI-fast is chosen: > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-1000000) > but with 9.1 TSC-low gets chosen: > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) > dummy(-1000000) > > so I did sysctl kern.timecounter.hardware=ACPI-fast, but the same happens - > unless it can't be changed after boot. > > I realy need help here! > > thanks, > danny > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 14:37:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0890AEB; Mon, 21 Jan 2013 14:37:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 79CBA687; Mon, 21 Jan 2013 14:37:49 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TxIVP-000Bks-VH; Mon, 21 Jan 2013 16:37:48 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Adrian Chadd Subject: Re: time issues and ZFS In-reply-to: References: Comments: In-reply-to Adrian Chadd message dated "Mon, 21 Jan 2013 06:13:02 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2013 16:37:47 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:37:50 -0000 > Hi, > > Try experimenting with kern.eventtimer.periodic and kern.eventtimer.idletick. > can you give/point to some info about this? btw, I just noticed that on this hardware I get: 9.1-STABLE: > vmstat -i interrupt total rate irq3: uart1 931 0 irq4: uart0 5 0 irq19: ehci0 1331 0 irq20: hpet0 uhci3 1687937 1163 irq21: uhci2 ehci1 29 0 irq23: atapci0 48 0 irq256: bce0 52270 36 irq260: mfi0 14690 10 irq261: mfi1 3088 2 Total 1760329 1213 no cpu timer, instead irq20: hpet0 uhci3, and when 8.3-STABLE: > vmstat -i interrupt total rate irq3: uart1 1048 0 irq4: uart0 5 0 irq19: ehci0 280451 1 irq21: uhci2 ehci1 29 0 irq23: atapci0 52 0 cpu0:timer 313544623 1125 irq256: bce0 30791673 110 irq260: mfi0 1372186 4 cpu1:timer 1294093 4 ... total 384382790 1380 is this OK? > If this fixes it for you, please file a PR with all the relevant details. > I will! > Thanks! > > > > > Adrian > > > On 21 January 2013 03:33, Daniel Braniss wrote: > > After many trials (and errors), here are some facts: > > > > host: DELL PowerEdge R710, 16GB, > > mfi0: > > mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal > > mfi1: > > mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is > > optimal > > > > we have NO problems with FreeBSD-8.3-STABLE, but with 9.1-STABLE, the real-time > > clock slows down when doing some zfs stuff like send|receive, typing 'date' > > when less that 1000s went by seems to crorrect the problem, > > ntpd kicks in and on track again. > > > > I have a cron job just logging date every 5 minutes, and the loghost sees: > > > > |-- local time on loghost | time on problematic host > > Jan 20 19:56:19 store-02.cs.huji.ac.il Jan 20 19:56:19 danny: Sun Jan 20 > > 19:56:19 IST 2013 -- ok > > Jan 20 20:15:00 store-02.cs.huji.ac.il Jan 20 20:15:00 danny: Sun Jan 20 > > 20:15:00 IST 2013 -- ok > > Jan 20 21:30:00 store-02.cs.huji.ac.il Jan 20 20:21:06 danny: Sun Jan 20 > > 20:21:06 IST 2013 -- off by 1:09 > > Jan 20 21:33:53 store-02.cs.huji.ac.il Jan 20 20:25:00 danny: Sun Jan 20 > > 20:25:00 IST 2013 -- off by 1:08 > > Jan 20 21:38:54 store-02.cs.huji.ac.il Jan 20 20:30:00 danny: Sun Jan 20 > > 20:30:00 IST 2013 -- off by 1:09 > > ... > > Jan 20 22:03:54 store-02.cs.huji.ac.il Jan 20 20:55:00 danny: Sun Jan 20 > > 20:55:00 IST 2013 -- diff is now constant > > .. > > Jan 20 22:04:13 store-02.cs.huji.ac.il Jan 20 20:55:19 ntpd[1848]: time > > correction of 4134 seconds exceeds sanity limit (1000); set clock manually to > > the correct UTC time. > > ... > > Jan 20 22:58:53 store-02.cs.huji.ac.il Jan 20 21:50:00 danny: Sun Jan 20 > > 21:50:00 IST 2013 > > > > > > strangely, when running 8.3, ACPI-fast is chosen: > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > > dummy(-1000000) > > but with 9.1 TSC-low gets chosen: > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) > > dummy(-1000000) > > > > so I did sysctl kern.timecounter.hardware=ACPI-fast, but the same happens - > > unless it can't be changed after boot. > > > > I realy need help here! > > > > thanks, > > danny > > > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 15:03:34 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF98930F for ; Mon, 21 Jan 2013 15:03:34 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id ADCA97EF for ; Mon, 21 Jan 2013 15:03:33 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0LF3Wr0012331 for ; Mon, 21 Jan 2013 08:03:32 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0LF38SD011776; Mon, 21 Jan 2013 08:03:08 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: time issues and ZFS From: Ian Lepore To: Daniel Braniss In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jan 2013 08:03:08 -0700 Message-ID: <1358780588.32417.414.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:03:34 -0000 On Mon, 2013-01-21 at 13:33 +0200, Daniel Braniss wrote: > After many trials (and errors), here are some facts: > > host: DELL PowerEdge R710, 16GB, > mfi0: > mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal > mfi1: > mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is > optimal > > we have NO problems with FreeBSD-8.3-STABLE, but with 9.1-STABLE, the real-time > clock slows down when doing some zfs stuff like send|receive, typing 'date' > when less that 1000s went by seems to crorrect the problem, > ntpd kicks in and on track again. > > I have a cron job just logging date every 5 minutes, and the loghost sees: > > |-- local time on loghost | time on problematic host > Jan 20 19:56:19 store-02.cs.huji.ac.il Jan 20 19:56:19 danny: Sun Jan 20 > 19:56:19 IST 2013 -- ok > Jan 20 20:15:00 store-02.cs.huji.ac.il Jan 20 20:15:00 danny: Sun Jan 20 > 20:15:00 IST 2013 -- ok > Jan 20 21:30:00 store-02.cs.huji.ac.il Jan 20 20:21:06 danny: Sun Jan 20 > 20:21:06 IST 2013 -- off by 1:09 > Jan 20 21:33:53 store-02.cs.huji.ac.il Jan 20 20:25:00 danny: Sun Jan 20 > 20:25:00 IST 2013 -- off by 1:08 > Jan 20 21:38:54 store-02.cs.huji.ac.il Jan 20 20:30:00 danny: Sun Jan 20 > 20:30:00 IST 2013 -- off by 1:09 > ... > Jan 20 22:03:54 store-02.cs.huji.ac.il Jan 20 20:55:00 danny: Sun Jan 20 > 20:55:00 IST 2013 -- diff is now constant > .. > Jan 20 22:04:13 store-02.cs.huji.ac.il Jan 20 20:55:19 ntpd[1848]: time > correction of 4134 seconds exceeds sanity limit (1000); set clock manually to > the correct UTC time. > ... > Jan 20 22:58:53 store-02.cs.huji.ac.il Jan 20 21:50:00 danny: Sun Jan 20 > 21:50:00 IST 2013 > > > strangely, when running 8.3, ACPI-fast is chosen: > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-1000000) > but with 9.1 TSC-low gets chosen: > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) > dummy(-1000000) > > so I did sysctl kern.timecounter.hardware=ACPI-fast, but the same happens - > unless it can't be changed after boot. > > I realy need help here! > > thanks, > danny What's the output of sysctl kern.eventtimer? Does the bad behavior change if you set kern.eventimer.periodic=1? -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 15:35:18 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49C57AB5; Mon, 21 Jan 2013 15:35:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 02AFB9CB; Mon, 21 Jan 2013 15:35:17 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TxJP2-000DS8-DJ; Mon, 21 Jan 2013 17:35:16 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Ian Lepore Subject: Re: time issues and ZFS In-reply-to: <1358780588.32417.414.camel@revolution.hippie.lan> References: <1358780588.32417.414.camel@revolution.hippie.lan> Comments: In-reply-to Ian Lepore message dated "Mon, 21 Jan 2013 08:03:08 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2013 17:35:16 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@FreeBSD.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:35:18 -0000 ... > > What's the output of sysctl kern.eventtimer? kern.eventtimer.periodic is 0 > Does the bad behavior > change if you set kern.eventimer.periodic=1? > setting kern.eventtimer.timer=LAPIC instead of the default HPET made the missing cpu timers to appear: # vmstat -i interrupt total rate irq3: uart1 1695 0 irq4: uart0 5 0 irq19: ehci0 3875 0 irq20: hpet0 uhci3 5495755 1135 irq21: uhci2 ehci1 29 0 irq23: atapci0 48 0 cpu0:timer 7063 1 irq256: bce0 117073 24 irq260: mfi0 51083 10 irq261: mfi1 3088 0 cpu1:timer 484 0 cpu14:timer 36 0 cpu6:timer 486 0 cpu8:timer 38 0 cpu5:timer 38 0 cpu15:timer 38 0 cpu7:timer 32 0 cpu12:timer 38 0 cpu3:timer 40 0 cpu9:timer 36 0 cpu10:timer 34 0 cpu11:timer 37 0 cpu2:timer 33 0 cpu13:timer 40 0 cpu4:timer 36 0 Total 5681160 1173 is this relevant? danny > -- Ian > > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 15:54:51 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49F3798 for ; Mon, 21 Jan 2013 15:54:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id CCCC8AFA for ; Mon, 21 Jan 2013 15:54:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0LFsobG013381 for ; Mon, 21 Jan 2013 08:54:50 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0LFsRPW011812; Mon, 21 Jan 2013 08:54:27 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: time issues and ZFS From: Ian Lepore To: Daniel Braniss In-Reply-To: References: <1358780588.32417.414.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jan 2013 08:54:27 -0700 Message-ID: <1358783667.32417.434.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:54:51 -0000 On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote: > ... > > > > What's the output of sysctl kern.eventtimer? > > kern.eventtimer.periodic is 0 > > > Does the bad behavior > > change if you set kern.eventimer.periodic=1? > > > > setting kern.eventtimer.timer=LAPIC > instead of the default HPET made the missing cpu timers to appear: > # vmstat -i > interrupt total rate > irq3: uart1 1695 0 > irq4: uart0 5 0 > irq19: ehci0 3875 0 > irq20: hpet0 uhci3 5495755 1135 > irq21: uhci2 ehci1 29 0 > irq23: atapci0 48 0 > cpu0:timer 7063 1 > irq256: bce0 117073 24 > irq260: mfi0 51083 10 > irq261: mfi1 3088 0 > cpu1:timer 484 0 > cpu14:timer 36 0 > cpu6:timer 486 0 > cpu8:timer 38 0 > cpu5:timer 38 0 > cpu15:timer 38 0 > cpu7:timer 32 0 > cpu12:timer 38 0 > cpu3:timer 40 0 > cpu9:timer 36 0 > cpu10:timer 34 0 > cpu11:timer 37 0 > cpu2:timer 33 0 > cpu13:timer 40 0 > cpu4:timer 36 0 > Total 5681160 1173 > > is this relevant? I'll have to let someone who knows modern x86 hardware better comment on the relative merits of hpet vs. lapic timers. If it was using hpet in one-shot mode, and changing it to hpet in periodic mode makes the problem go away, that might be a clue that there's something wrong in the hpet eventtimer start or interrupt routines. I wonder if a single missed interrupt in one-shot mode would bring an eventtimer to a halt like that? And if so, then what is it about manually asking for the date that kicks it into running again? -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Jan 21 20:09:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0E9827C; Mon, 21 Jan 2013 20:09:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2DBA83; Mon, 21 Jan 2013 20:09:27 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id o1so7501026wic.5 for ; Mon, 21 Jan 2013 12:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wMdGVTFW2dXlId7vrJQNNTB0+f2hCoK6ICTx+Zs1QuE=; b=ph34ZtayO4DiIK+FMTt44qYRRPOxv63yNFePSLOOF0FkBwC9FPh+QHWSxW+FebcrM+ 2N0Jg5G4wbd30rn7yqR3HwzqKATyn0EpaEHidfYYADMTiB5TkR81aLcM4jmmivOMOpgV KhnGEwe7KdLUFQjXnVGGiVx+b1+JNRxmUJo1SO+3l5k6zZ91HP8XD/wCyqJEaDO3L+/M mm9rO5nTcNevNG6AgTb2qXZ1/P3g/OPTP5om14Oh3PuaJ1SCiQrRRZLxutqSJSofDAYe ThY0gf7lsTK00siMuUXvG8EqP1xY2EudZelAW2B0FCuh3rsaCLxB+9u7bTPvHlcNcMRQ iOSA== MIME-Version: 1.0 X-Received: by 10.194.172.197 with SMTP id be5mr17218802wjc.20.1358798961542; Mon, 21 Jan 2013 12:09:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.123.73 with HTTP; Mon, 21 Jan 2013 12:09:21 -0800 (PST) In-Reply-To: <1358783667.32417.434.camel@revolution.hippie.lan> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Date: Mon, 21 Jan 2013 12:09:21 -0800 X-Google-Sender-Auth: viwKIb-HA-be5qOQd4LgqrIFIHU Message-ID: Subject: Re: time issues and ZFS From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 20:09:28 -0000 I still firmly believe the ACPI event timer code is racy, and what we may be seeing here is the fallout from that. It's very possible that we're missing interrupts here - the new eventtimer code that made it into 9.x puts the halt behind a critical section, with interrupts disabled. The only platforms that correctly implement enable-interrupts-and-halt atomically is the HLT (well, and the don't-sleep-at-all) idle loops on i386/amd64. The default method is to use the ACPI sleep method, which doesn't do atomic interrupt enable / halt. I'm still seeing odd stuff on some of my ACPI-using netbooks when doing net80211/ath development and it all goes away whenever I fondle with the above settings. So, play with kern.eventtimer.periodic, kern.eventtimer.idletick and machdep.idle (try setting machdep.idle to hlt, or something else listed in machdep.idle_available) - please report back what the results are. Adrian On 21 January 2013 07:54, Ian Lepore wrote: > On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote: >> ... >> > >> > What's the output of sysctl kern.eventtimer? >> >> kern.eventtimer.periodic is 0 >> >> > Does the bad behavior >> > change if you set kern.eventimer.periodic=1? >> > >> >> setting kern.eventtimer.timer=LAPIC >> instead of the default HPET made the missing cpu timers to appear: >> # vmstat -i >> interrupt total rate >> irq3: uart1 1695 0 >> irq4: uart0 5 0 >> irq19: ehci0 3875 0 >> irq20: hpet0 uhci3 5495755 1135 >> irq21: uhci2 ehci1 29 0 >> irq23: atapci0 48 0 >> cpu0:timer 7063 1 >> irq256: bce0 117073 24 >> irq260: mfi0 51083 10 >> irq261: mfi1 3088 0 >> cpu1:timer 484 0 >> cpu14:timer 36 0 >> cpu6:timer 486 0 >> cpu8:timer 38 0 >> cpu5:timer 38 0 >> cpu15:timer 38 0 >> cpu7:timer 32 0 >> cpu12:timer 38 0 >> cpu3:timer 40 0 >> cpu9:timer 36 0 >> cpu10:timer 34 0 >> cpu11:timer 37 0 >> cpu2:timer 33 0 >> cpu13:timer 40 0 >> cpu4:timer 36 0 >> Total 5681160 1173 >> >> is this relevant? > > I'll have to let someone who knows modern x86 hardware better comment on > the relative merits of hpet vs. lapic timers. If it was using hpet in > one-shot mode, and changing it to hpet in periodic mode makes the > problem go away, that might be a clue that there's something wrong in > the hpet eventtimer start or interrupt routines. > > I wonder if a single missed interrupt in one-shot mode would bring an > eventtimer to a halt like that? And if so, then what is it about > manually asking for the date that kicks it into running again? > > -- Ian > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 07:28:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E345653D; Tue, 22 Jan 2013 07:28:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBFA9A4; Tue, 22 Jan 2013 07:28:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TxYHa-0002yo-4Y; Tue, 22 Jan 2013 09:28:34 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Adrian Chadd Subject: Re: time issues and ZFS In-reply-to: References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Comments: In-reply-to Adrian Chadd message dated "Mon, 21 Jan 2013 12:09:21 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jan 2013 09:28:34 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Ian Lepore , Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 07:28:37 -0000 > I still firmly believe the ACPI event timer code is racy, and what we > may be seeing here is the fallout from that. > > It's very possible that we're missing interrupts here - the new > eventtimer code that made it into 9.x puts the halt behind a critical > section, with interrupts disabled. The only platforms that correctly > implement enable-interrupts-and-halt atomically is the HLT (well, and > the don't-sleep-at-all) idle loops on i386/amd64. The default method > is to use the ACPI sleep method, which doesn't do atomic interrupt > enable / halt. > > I'm still seeing odd stuff on some of my ACPI-using netbooks when > doing net80211/ath development and it all goes away whenever I fondle > with the above settings. > > So, play with kern.eventtimer.periodic, kern.eventtimer.idletick and > machdep.idle (try setting machdep.idle to hlt, or something else > listed in machdep.idle_available) - please report back what the > results are. > > > Adrian > Adrian, you mention that ACPI is racy, which event timer are you talking about? how is the quality chosen? at the moment switching kern.eventtimer.timer to LAPIC seems to have done the trick. I'll have to wait another 24hs to make sure. In the meantime here is some info: Intel(R) Xeon(R) CPU E5645: running with no problems LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0) Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) Dual-Core AMD Opteron(tm) Processor 2218: running with no problems LAPIC(400) RTC(0) so if someone is running 9.1 on any of the following and can provide the output of sysctl kern.eventtimer.choice would be nice: Intel(R) Xeon(R) CPU E5410 Intel(R) Xeon(R) CPU E5507 btw, all the above are on server MBs. thanks, danny > On 21 January 2013 07:54, Ian Lepore wrote: > > On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote: > >> ... > >> > > >> > What's the output of sysctl kern.eventtimer? > >> > >> kern.eventtimer.periodic is 0 > >> > >> > Does the bad behavior > >> > change if you set kern.eventimer.periodic=1? > >> > > >> > >> setting kern.eventtimer.timer=LAPIC > >> instead of the default HPET made the missing cpu timers to appear: > >> # vmstat -i > >> interrupt total rate > >> irq3: uart1 1695 0 > >> irq4: uart0 5 0 > >> irq19: ehci0 3875 0 > >> irq20: hpet0 uhci3 5495755 1135 > >> irq21: uhci2 ehci1 29 0 > >> irq23: atapci0 48 0 > >> cpu0:timer 7063 1 > >> irq256: bce0 117073 24 > >> irq260: mfi0 51083 10 > >> irq261: mfi1 3088 0 > >> cpu1:timer 484 0 > >> cpu14:timer 36 0 > >> cpu6:timer 486 0 > >> cpu8:timer 38 0 > >> cpu5:timer 38 0 > >> cpu15:timer 38 0 > >> cpu7:timer 32 0 > >> cpu12:timer 38 0 > >> cpu3:timer 40 0 > >> cpu9:timer 36 0 > >> cpu10:timer 34 0 > >> cpu11:timer 37 0 > >> cpu2:timer 33 0 > >> cpu13:timer 40 0 > >> cpu4:timer 36 0 > >> Total 5681160 1173 > >> > >> is this relevant? > > > > I'll have to let someone who knows modern x86 hardware better comment on > > the relative merits of hpet vs. lapic timers. If it was using hpet in > > one-shot mode, and changing it to hpet in periodic mode makes the > > problem go away, that might be a clue that there's something wrong in > > the hpet eventtimer start or interrupt routines. > > > > I wonder if a single missed interrupt in one-shot mode would bring an > > eventtimer to a halt like that? And if so, then what is it about > > manually asking for the date that kicks it into running again? > > > > -- Ian From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 09:40:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5631FC9F; Tue, 22 Jan 2013 09:40:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id C52D92E7; Tue, 22 Jan 2013 09:40:08 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so5712452wib.14 for ; Tue, 22 Jan 2013 01:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RJLYpFa3kNIB3WgPB1EeEPSbAl3SvxEXrho/kAU/6fs=; b=qlYN/nWK0bvYXtIlkIiMQ1c6vxJxiPzrsoS5eqTJL895cxqxaUG3bC/gUZJWO9X3Vw pw9vmD1G3dqwlN787yuQLb7zMEI8qP0cuyUv7uWbw9nDqs7/lgLFtIg6IRLEcv6fg7dm eQwQ8/szeyufWSDOFHEicSBbohrQS7xchx13PS6qYUdZMgbsc6RyhNPsSPTfxFouT1Pj Zumvr5Qou7Osa2BAXQTSrHVW6qY/BBtnZ/4QRdU12l/nXi1nduT5EOjLtjy4y2fOtwwh 0mfBVrH1XApJJp9yGKsrKf8lrDRIy6nNDVpl9Ob1UnKWQMAX5IupxYsHDY4CThG+5a2u NndA== MIME-Version: 1.0 X-Received: by 10.194.240.129 with SMTP id wa1mr31386143wjc.21.1358847602474; Tue, 22 Jan 2013 01:40:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.123.73 with HTTP; Tue, 22 Jan 2013 01:40:02 -0800 (PST) In-Reply-To: References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Date: Tue, 22 Jan 2013 01:40:02 -0800 X-Google-Sender-Auth: HfD4d5y99MUPolwCJoT77Z4fx4Y Message-ID: Subject: Re: time issues and ZFS From: Adrian Chadd To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Ian Lepore , Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 09:40:09 -0000 Daniel, Have you run tests with the machdep.idle value changed, and fiddling kern.eventtimer.periodic / kern.eventtimer.idletick ? adrian From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 09:55:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30C62551; Tue, 22 Jan 2013 09:55:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B952D3F9; Tue, 22 Jan 2013 09:55:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TxaZv-0005fj-5m; Tue, 22 Jan 2013 11:55:39 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Adrian Chadd Subject: Re: time issues and ZFS In-reply-to: References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Comments: In-reply-to Adrian Chadd message dated "Tue, 22 Jan 2013 01:40:02 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jan 2013 11:55:39 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 09:55:41 -0000 > Daniel, > > Have you run tests with the machdep.idle value changed, and fiddling > kern.eventtimer.periodic / kern.eventtimer.idletick ? Adrian, not yet, for several reasons: 1- as I explained, I can't realy force the problem, it happens when we run some zfs scripts, like mirror, but have to wait till enough changes happened on the source, usualy after 24hs. 2- changing to LAPIC seems to have solved the problem. 3- I'm now learning all I can about event timers and you have not answered some of my questions :-) danny From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 10:15:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BECDB1C for ; Tue, 22 Jan 2013 10:15:35 +0000 (UTC) (envelope-from franz@electromail.org) Received: from mx-b.spam-sponge.de (mx-b.spam-sponge.de [176.9.96.52]) by mx1.freebsd.org (Postfix) with ESMTP id 90980734 for ; Tue, 22 Jan 2013 10:15:34 +0000 (UTC) Received: from [192.168.100.4] (e178012027.adsl.alicedsl.de [85.178.12.27]) (authenticated bits=0) by mx-b.spam-sponge.de (8.14.5/8.14.5) with ESMTP id r0M9vHAN019750 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 10:57:20 +0100 (CET) (envelope-from franz@electromail.org) Message-ID: <50FE627C.7070701@electromail.org> Date: Tue, 22 Jan 2013 10:57:16 +0100 From: Franz Schwartau User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: Re: kvm vlan virtio problem References: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> In-Reply-To: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, bane ivosev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 10:15:35 -0000 Hi! The same warning shows up in our setup: Jan 21 23:40:46 host kernel: WARNING: at net/core/dev.c:1712 skb_gso_segment+0x1df/0x2b0() (Tainted: G W --------------- ) Jan 21 23:40:46 host kernel: Hardware name: System Product Name Jan 21 23:40:46 host kernel: tun: caps=(0x1b0049, 0x0) len=4452 data_len=4380 ip_summed=0 [...] KVM host: CentOS 6.3, Linux kernel 2.6.32-279.19.1.el6.x86_64 VM guest: FreeBSD 9.1, virtio-kmod-9.1-0.242658 Disabling TSO on vtnet0 stops the warnings on the KVM host. Is there any progress on this issue? Best regards Franz On 04.11.2012 02:53, Bryan Venteicher wrote: > Hi, > > ----- Original Message ----- >> From: "Bane Ivosev" >> To: "Bryan Venteicher" , freebsd-stable@freebsd.org >> Sent: Saturday, November 3, 2012 7:58:57 PM >> Subject: Re: kvm vlan virtio problem >> >> thanks bryan, i don't have vlans inside guest. >> >> as you suggested i disabled nic tso >> >> ifconfig vtnet0 -tso >> and >> sysctl net.inet.tcp.tso=0 and >> >> so far, so good! >> everything is ok now. >> >> once again, thanks a lot. >> > > No need to disable TSO globally. So it seems if_vtnet sending > down TSO frames that don't have the appropriate flags set. I'll > look into it more in a next couple of days. > > Thanks for the quick reply back. > > Bryan > >> >> On 11/03/2012 09:40 PM, Bryan Venteicher wrote: >>> Hi, >>> >>> ----- Original Message ----- >>>> From: "Bane Ivosev" >>>> To: freebsd-stable@freebsd.org >>>> Sent: Saturday, November 3, 2012 2:12:25 PM >>>> Subject: kvm vlan virtio problem >>>> >>>> hi, i have several kvm ubuntu 12.04 and centos 6 hosts with >>>> standard >>>> bridged network setup. same problem on each server with freebsd 9 >>>> amd64 >>>> guest and virtio nic: soon after guest start host syslog is >>>> filling >>>> with >>>> this message at very high rate. guest is working without any >>>> problem. >>>> with e1000 guest driver eveything is ok. >>>> >>>> does enyone have/had same problem? >>>> >>>> thanks. >>>> >>> >>> I have a vague recollection of looking at something similar last >>> year... >>> >>> Do you have VLAN configured in the guest as well? What is the >>> ifconfig >>> output? Does disabling TSO on the vtnetX device make these messages >>> go >>> away? >>> >>> Bryan >>> >>>> >>>> kernel: [2337728.094141] ------------[ cut here ]------------ >>>> kernel: [2337728.094144] WARNING: at >>>> /build/buildd/linux-3.2.0/net/core/dev.c:1955 >>>> skb_gso_segment+0x341/0x3b0() >>>> kernel: [2337728.094146] Hardware name: System x3550 M3 >>>> -[7944K3G]- >>>> kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, >>>> 0x0) >>>> len=3196 data_len=0 ip_summed=0 >>>> kernel: [2337728.094149] Modules linked in: dm_snapshot >>>> ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE >>>> iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state >>>> nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp >>>> iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs >>>> lockd >>>> fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat >>>> fat >>>> 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap >>>> i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp >>>> parport >>>> mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 >>>> kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G >>>> W 3.2.0-31-generic #50-Ubuntu >>>> kernel: [2337728.094179] Call Trace: >>>> kernel: [2337728.094180] [] >>>> warn_slowpath_common+0x7f/0xc0 >>>> kernel: [2337728.094185] [] >>>> warn_slowpath_fmt+0x46/0x50 >>>> kernel: [2337728.094188] [] >>>> skb_gso_segment+0x341/0x3b0 >>>> kernel: [2337728.094191] [] >>>> dev_hard_start_xmit+0xc1/0x540 >>>> kernel: [2337728.094196] [] ? >>>> br_flood+0xc0/0xc0 >>>> [bridge] >>>> kernel: [2337728.094199] [] >>>> dev_queue_xmit+0x2aa/0x420 >>>> kernel: [2337728.094203] [] >>>> br_dev_queue_push_xmit+0x92/0xd0 [bridge] >>>> kernel: [2337728.094208] [] >>>> br_forward_finish+0x58/0x60 [bridge] >>>> kernel: [2337728.094212] [] >>>> __br_forward+0xab/0xd0 >>>> [bridge] >>>> kernel: [2337728.094217] [] >>>> br_forward+0x5d/0x70 >>>> [bridge] >>>> kernel: [2337728.094221] [] >>>> br_handle_frame_finish+0x182/0x2a0 [bridge] >>>> kernel: [2337728.094226] [] >>>> br_handle_frame+0x1c8/0x270 [bridge] >>>> kernel: [2337728.094231] [] ? >>>> br_handle_frame_finish+0x2a0/0x2a0 [bridge] >>>> kernel: [2337728.094234] [] >>>> __netif_receive_skb+0x1e2/0x520 >>>> kernel: [2337728.094237] [] >>>> process_backlog+0xb1/0x190 >>>> kernel: [2337728.094240] [] >>>> net_rx_action+0x134/0x290 >>>> kernel: [2337728.094242] [] ? >>>> _raw_spin_lock+0xe/0x20 >>>> kernel: [2337728.094245] [] >>>> __do_softirq+0xa8/0x210 >>>> kernel: [2337728.094248] [] >>>> call_softirq+0x1c/0x30 >>>> kernel: [2337728.094249] [] >>>> do_softirq+0x65/0xa0 >>>> kernel: [2337728.094254] [] >>>> netif_rx_ni+0x28/0x30 >>>> kernel: [2337728.094258] [] >>>> tun_get_user+0x306/0x4a0 >>>> kernel: [2337728.094261] [] >>>> tun_sendmsg+0x25/0x30 >>>> kernel: [2337728.094265] [] >>>> handle_tx+0x296/0x530 >>>> [vhost_net] >>>> kernel: [2337728.094269] [] >>>> handle_tx_kick+0x15/0x20 [vhost_net] >>>> kernel: [2337728.094273] [] >>>> vhost_worker+0xdd/0x170 >>>> [vhost_net] >>>> kernel: [2337728.094276] [] ? >>>> vhost_set_memory+0x130/0x130 [vhost_net] >>>> kernel: [2337728.094279] [] >>>> kthread+0x8c/0xa0 >>>> kernel: [2337728.094282] [] >>>> kernel_thread_helper+0x4/0x10 >>>> kernel: [2337728.094285] [] ? >>>> flush_kthread_worker+0xa0/0xa0 >>>> kernel: [2337728.094287] [] ? >>>> gs_change+0x13/0x13 >>>> kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- >>>> kernel: [2337728.094731] ------------[ cut here ]------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 10:19:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29B7FCDD for ; Tue, 22 Jan 2013 10:19:32 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA1A76F for ; Tue, 22 Jan 2013 10:19:31 +0000 (UTC) Received: (qmail 41865 invoked from network); 22 Jan 2013 11:19:30 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 22 Jan 2013 11:19:30 +0100 From: Kai Gallasch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jan 2013 11:19:29 +0100 Subject: FreeBSD 9.1 - openldap slapd lockups, mutex problems To: freebsd-stable Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 10:19:32 -0000 Hi. (Im am sending this to the "stable" list, because it maybe kernel = related.. ) On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. The slapd runs for some days and then hangs, consuming high amounts of = CPU. In this state slapd can only be restarted by SIGKILL. # procstat -kk 71195 PID TID COMM TDNAME KSTACK = =20 71195 149271 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = do_wait+0x678 __umtx_op_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7=20= 71195 194998 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _cv_wait_sig+0x12e = seltdwait+0x110 kern_select+0x6ef sys_select+0x5d amd64_syscall+0x546 = Xfast_syscall+0xf7=20 71195 195544 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 196183 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_timedwait_sig+0x19 _sleep+0x2d4 = userret+0x9e doreti_ast+0x1f=20 71195 197966 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 198446 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 198453 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 198563 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 199520 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 200038 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 200670 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 200674 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 200675 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 201179 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 201180 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 201181 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 201183 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7=20 71195 201189 slapd - mi_switch+0x186 = sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d = _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 = amd64_syscall+0x546 Xfast_syscall+0xf7 When I try to stop slapd through the rc script I can see in the logs = that the process is waiting for a thread to terminate - indefinitely. Other multithreaded server processes running on the server without = problems (apache-worker, mysqld, bind, etc.) On UFS2 slapd runs fine, without showing the error. Things I have tried already to stop the lockups: - running openldap-server23, openldap24 both with different BDB backend = versions. - tuning the BDB Init File - reducing the threads used by slapd through slapd.conf What I didn't try until now: Mounting a zfs vdev into the jail, to have the BDB storing its data on = UFS. (don't like the idea) Environment: - freebsd 9.1-rel-amd64 multijail server with cpu resource limit = patch[1], which didn't make it into 9.1-rel=20 - filesystem: zfs-only, swap on zfs - active jail limits through rctl.conf (memory, maxprocs, open files) - a handfull of openldap-server jails that show the same slapd lockup = tendency. - slapd started through daemontools (supvervise) Some ideas: - openldap-server with BDB backend uses sparse files for storing the = data - on top of ZFS. Has anyone else running openldap-server on FreeBSD 9.1 inside a jail = seen similar problems? How can I debug this further? Any hints appreciated :-) Regards. [1] https://wiki.freebsd.org/JailResourceLimits= From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 11:47:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A3382A9 for ; Tue, 22 Jan 2013 11:47:40 +0000 (UTC) (envelope-from returns@a.ss34.on9mail.com) Received: from a.ss34.on9mail.com (a.ss34.on9mail.com [209.144.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE5AB83 for ; Tue, 22 Jan 2013 11:47:40 +0000 (UTC) Received: by a.ss34.on9mail.com (Postfix, from userid 0) id 31F3A6C83A1; Tue, 22 Jan 2013 13:47:28 +0200 (SAST) To: freebsd-stable@freebsd.org Subject: Best priced Apartments Message-ID: <1358855248_SectionID-451168_HitID-1358839116229_SiteID-40814_EmailID-8235727_DB-12_SID-14@ss34.on9mail.com> X-Report-Abuse: Please report abuse for this campaign here: http://a.ss34.on9mail.com/reportabuse.aspx?stid=40814&hitid=1358839116229&sec=451168&email=freebsd-stable@freebsd.org&EmID=8235727&SID=14&token=7ccbc3fc8abc9e1f6b24be66b854fb247176d7ef DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ss34.on9mail.com; i=@ss34.on9mail.com; q=dns/txt; s=gmmailerd; t=1358855225; h=From; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; b=S6Hln2H1GRDdq6HdJ5S06ml/xHmqS3mnZ5x8aBnZOPQT5UXs4u4twAdPrxoTgBLIE1wXaymTLNtuHZ8Z7mxYH3Q7b0gjo3ATU/qqmyJYyodm3bp++MBtuwgNpawv+Lh00XvFl0gZstv4goxh8JXMhOJQwoi9Uo+IK8AQ06r2tNM= From: "Just Invest" Mime-Version: 1.0 Date: Tue, 22 Jan 2013 13:47:28 +0200 (SAST) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 11:47:40 -0000 =0A=0AMessage sent by: Just Invest From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 12:27:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80976282 for ; Tue, 22 Jan 2013 12:27:46 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4163DEEB for ; Tue, 22 Jan 2013 12:27:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TxcxG-0007Cm-KO for freebsd-stable@freebsd.org; Tue, 22 Jan 2013 13:27:54 +0100 Received: from monat.inf.tu-dresden.de ([141.76.48.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jan 2013 13:27:54 +0100 Received: from jsteckli by monat.inf.tu-dresden.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jan 2013 13:27:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Julian Stecklina Subject: Re: time issues and ZFS Date: Tue, 22 Jan 2013 13:27:24 +0100 Lines: 14 Message-ID: <8738xtwggj.fsf@os.inf.tu-dresden.de> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: monat.inf.tu-dresden.de User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Vryq8K5rzmYg3MGfrc2pMIo57kY= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 12:27:46 -0000 Thus spake Daniel Braniss : > In the meantime here is some info: > Intel(R) Xeon(R) CPU E5645: running with no problems > LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0) > > Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment > HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) Does anyone know why the LAPIC is given a lower priority than HPET in this case? If you have an LAPIC, it should always be prefered to HPET, unless something is seriously wrong with it... Julian From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 13:53:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40433DCC for ; Tue, 22 Jan 2013 13:53:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id E01BE7A4 for ; Tue, 22 Jan 2013 13:53:35 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h16so7214874oag.5 for ; Tue, 22 Jan 2013 05:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XIP6eBt3rxLFhGpr1frhrW877jpWN8bzZTHbh2dJg7Y=; b=uih0Es5v+TTHqhbmbTq1f8bMvVslpa6rJ1XdF8LcsBBTbQVBfr88PRz6/9XpBF2vvN dTKKlKXpeFX70I+fS6/l7p+75i+bG7y5LXYt7aSe0b8bafREf/twPAiE05le/gTLKplD c4FAPhCBu8ua7adamNCPLEjNRKlGpMDc9exv1VnuKDjVgnN04R5ZlFtcEwNystW5VC0d XUpEZob1Y2nMR75F3Vko1TcZWk1rR7mdOR95wsXhtHn6LmWeaXr08QG35mudK+jIfNyb S4HGmNWyReT/QtqSRSVFlSMsd4twbb74aw8fEb8E9mfN0CjnneEGlOtaLIFvB4RKn0pf JLVA== MIME-Version: 1.0 X-Received: by 10.60.171.175 with SMTP id av15mr16657922oec.75.1358862808998; Tue, 22 Jan 2013 05:53:28 -0800 (PST) Received: by 10.76.128.68 with HTTP; Tue, 22 Jan 2013 05:53:28 -0800 (PST) In-Reply-To: <8738xtwggj.fsf@os.inf.tu-dresden.de> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> <8738xtwggj.fsf@os.inf.tu-dresden.de> Date: Tue, 22 Jan 2013 08:53:28 -0500 Message-ID: Subject: Re: time issues and ZFS From: Ryan Stone To: Julian Stecklina Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 13:53:36 -0000 On Tue, Jan 22, 2013 at 7:27 AM, Julian Stecklina < jsteckli@os.inf.tu-dresden.de> wrote: > Does anyone know why the LAPIC is given a lower priority than HPET in > this case? If you have an LAPIC, it should always be prefered to HPET, > unless something is seriously wrong with it... > On many processors the lapic timer does not work correctly in states lower than C1. There are many processors that will automatically enter a "C1E" mode when the processor is idle, and in that state I have seen the lapic timer run slower than the programmed frequency, causing time to move to slowly on idle FreeBSD systems. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 14:01:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA25DF84 for ; Tue, 22 Jan 2013 14:01:45 +0000 (UTC) (envelope-from me@vorakl.name) Received: from argon.h.anonisp.net (argon.h.anonisp.net [82.193.122.248]) by mx1.freebsd.org (Postfix) with ESMTP id 02E9980D for ; Tue, 22 Jan 2013 14:01:44 +0000 (UTC) Received: by argon.h.anonisp.net (Postfix, from userid 982) id 123CEFD05F; Tue, 22 Jan 2013 16:01:44 +0200 (EET) Received: from nikel.h.anonisp.net (nikel.vaganupa2.fbsd-ng.org [10.101.4.2]) by argon.h.anonisp.net (Postfix) with ESMTP id DF641FD041 for ; Tue, 22 Jan 2013 16:01:43 +0200 (EET) Received: by nikel.h.anonisp.net (SMTPd, from userid 982) id 67C586A042D; Tue, 22 Jan 2013 16:01:43 +0200 (EET) Received: from [192.168.68.203] (unknown [195.216.206.4]) by nikel.h.anonisp.net (SMTPd) with ESMTPA id 4E11B6A041B for ; Tue, 22 Jan 2013 16:01:43 +0200 (EET) Message-ID: <50FE9BB5.9090308@vorakl.name> Date: Tue, 22 Jan 2013 16:01:25 +0200 From: Oleksii Tsvietnov MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: busy on all disks that are a part of the ZFS pools without any load Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Value: 0.000000 (Ham) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:01:45 -0000 Hello. I have a problem with all diks that are a part of ZFS pools. There is a busy state (6-7%) on all of them in the iostat. But only there! There aren't any load at all on the disks and other system utilities, such as gstat, 'zpool iostat', 'systat -iostat' which are reporting a zero busy status. 24 disks -> 8 ZFS pools All 24 disks are on the 3Ware controller in JBOD mode (each disk works as a single disk without any hardware RAIDs) twa0: <3ware 9000 series Storage Controller> port 0xd800-0xd8ff mem 0xf6000000-0xf7ffffff,0xfaedf000-0xfaedffff irq 16 at device 0.0 on pci2 twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-24M8, 24 ports, Firmware FE9X 4.08.00.006, BIOS BE9X 4.08.00.001 # uname -a FreeBSD gfs521 9.1-STABLE FreeBSD 9.1-STABLE #5 r245163: # iostat -xzt da,scsi extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b da0 12.6 2.5 1248.5 173.2 0 29.0 7 da1 12.6 2.6 1227.7 173.2 0 22.6 6 da2 12.5 2.5 1233.3 173.2 0 29.3 7 da3 10.2 2.4 994.7 165.5 0 28.1 6 da4 10.5 2.4 1035.5 165.5 0 28.0 6 da5 10.7 2.4 1049.8 165.5 0 28.6 6 da6 14.6 2.5 1418.9 165.2 0 28.4 8 da7 14.4 2.5 1387.2 165.2 0 28.6 8 da8 14.3 2.5 1376.7 165.2 0 27.8 8 da9 10.8 2.5 1065.2 161.7 0 27.0 6 da10 11.0 2.5 1100.9 161.7 0 27.5 6 da11 10.4 2.5 1015.1 161.7 0 27.6 6 da12 13.5 2.4 1365.8 168.7 0 28.9 7 da13 13.9 2.4 1364.2 168.7 0 26.9 7 da14 13.9 2.4 1373.9 168.7 0 27.1 7 da15 13.6 2.6 1308.5 165.3 0 24.5 7 da16 14.3 2.5 1417.0 165.3 0 24.9 7 da17 14.0 2.5 1376.6 165.3 0 25.1 7 da18 17.0 2.4 1697.2 164.4 0 19.8 6 da19 16.0 2.4 1578.0 164.4 0 20.2 6 da20 16.5 2.4 1635.6 164.4 0 23.5 7 da21 8.7 2.5 802.8 186.3 0 27.2 6 da22 8.7 2.5 800.1 186.3 0 26.9 6 da23 8.6 2.5 797.0 186.3 0 27.1 6 # gstat 0 0 0 0 0.0 0 0 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0.0| da4 0 0 0 0 0.0 0 0 0.0 0.0| da5 0 0 0 0 0.0 0 0 0.0 0.0| da6 0 0 0 0 0.0 0 0 0.0 0.0| da7 0 0 0 0 0.0 0 0 0.0 0.0| da8 0 0 0 0 0.0 0 0 0.0 0.0| da9 0 0 0 0 0.0 0 0 0.0 0.0| da10 0 0 0 0 0.0 0 0 0.0 0.0| da11 0 0 0 0 0.0 0 0 0.0 0.0| da12 0 0 0 0 0.0 0 0 0.0 0.0| da13 0 0 0 0 0.0 0 0 0.0 0.0| da14 0 0 0 0 0.0 0 0 0.0 0.0| da15 0 0 0 0 0.0 0 0 0.0 0.0| da16 0 0 0 0 0.0 0 0 0.0 0.0| da17 0 0 0 0 0.0 0 0 0.0 0.0| da18 0 0 0 0 0.0 0 0 0.0 0.0| da19 0 0 0 0 0.0 0 0 0.0 0.0| da20 0 0 0 0 0.0 0 0 0.0 0.0| da21 0 0 0 0 0.0 0 0 0.0 0.0| da22 0 0 0 0 0.0 0 0 0.0 0.0| da23 # zpool iostat capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- data1 11.4G 5.43T 0 0 0 0 data2 9.05G 5.43T 0 0 0 0 data3 10.1G 5.43T 0 0 0 0 data4 4.15G 5.43T 0 0 0 0 data5 11.9G 5.43T 0 0 0 0 data6 10.1G 5.43T 0 0 0 0 data7 76.1G 5.36T 0 0 0 0 data8 5.38M 5.44T 0 0 0 0 # zpool status -xv all pools are healthy Thanks for any ideas! From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 14:10:44 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D05561ED for ; Tue, 22 Jan 2013 14:10:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB1F878 for ; Tue, 22 Jan 2013 14:10:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29839; Tue, 22 Jan 2013 16:10:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50FE9DCD.4040204@FreeBSD.org> Date: Tue, 22 Jan 2013 16:10:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Oleksii Tsvietnov Subject: Re: busy on all disks that are a part of the ZFS pools without any load References: <50FE9BB5.9090308@vorakl.name> In-Reply-To: <50FE9BB5.9090308@vorakl.name> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:10:44 -0000 on 22/01/2013 16:01 Oleksii Tsvietnov said the following: > > # iostat -xzt da,scsi > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > da0 12.6 2.5 1248.5 173.2 0 29.0 7 > da1 12.6 2.6 1227.7 173.2 0 22.6 6 > da2 12.5 2.5 1233.3 173.2 0 29.3 7 > da3 10.2 2.4 994.7 165.5 0 28.1 6 > da4 10.5 2.4 1035.5 165.5 0 28.0 6 > da5 10.7 2.4 1049.8 165.5 0 28.6 6 > da6 14.6 2.5 1418.9 165.2 0 28.4 8 > da7 14.4 2.5 1387.2 165.2 0 28.6 8 > da8 14.3 2.5 1376.7 165.2 0 27.8 8 > da9 10.8 2.5 1065.2 161.7 0 27.0 6 > da10 11.0 2.5 1100.9 161.7 0 27.5 6 > da11 10.4 2.5 1015.1 161.7 0 27.6 6 > da12 13.5 2.4 1365.8 168.7 0 28.9 7 > da13 13.9 2.4 1364.2 168.7 0 26.9 7 > da14 13.9 2.4 1373.9 168.7 0 27.1 7 > da15 13.6 2.6 1308.5 165.3 0 24.5 7 > da16 14.3 2.5 1417.0 165.3 0 24.9 7 > da17 14.0 2.5 1376.6 165.3 0 25.1 7 > da18 17.0 2.4 1697.2 164.4 0 19.8 6 > da19 16.0 2.4 1578.0 164.4 0 20.2 6 > da20 16.5 2.4 1635.6 164.4 0 23.5 7 > da21 8.7 2.5 802.8 186.3 0 27.2 6 > da22 8.7 2.5 800.1 186.3 0 26.9 6 > da23 8.6 2.5 797.0 186.3 0 27.1 6 These are values since boot, they do not reflect current system load. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 14:35:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22FC2741 for ; Tue, 22 Jan 2013 14:35:47 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id E80F69A8 for ; Tue, 22 Jan 2013 14:35:46 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 9412827F34 for ; Tue, 22 Jan 2013 09:35:40 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igkHuKyJP53u for ; Tue, 22 Jan 2013 09:35:40 -0500 (EST) Received: from EGR authenticated sender Message-ID: <50FEA3BB.3060607@egr.msu.edu> Date: Tue, 22 Jan 2013 09:35:39 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: time issues and ZFS References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> <8738xtwggj.fsf@os.inf.tu-dresden.de> In-Reply-To: <8738xtwggj.fsf@os.inf.tu-dresden.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:35:47 -0000 On 01/22/13 07:27, Julian Stecklina wrote: > Thus spake Daniel Braniss : > >> In the meantime here is some info: >> Intel(R) Xeon(R) CPU E5645: running with no problems >> LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0) >> >> Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment >> HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) > > Does anyone know why the LAPIC is given a lower priority than HPET in > this case? If you have an LAPIC, it should always be prefered to HPET, > unless something is seriously wrong with it... > > Julian > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > This may help: "Problem with LAPIC timer is that it stops working when CPU goes to C3 or deeper idle state. These states are not enabled by default, so unless you enabled them explicitly, it is safe to use LAPIC. In any case present 9-STABLE system should prevent you from using unsafe C-state if LAPIC timer is used. From all other perspectives LAPIC is preferable, as it is faster and easier to operate then HPET. Latest CPUs fixed the LAPIC timer problem, so I don't think that switching to it will be pessimistic in foreseeable future. -- Alexander Motin" From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 14:47:54 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A7B6A86; Tue, 22 Jan 2013 14:47:54 +0000 (UTC) (envelope-from me@vorakl.name) Received: from argon.h.anonisp.net (argon.h.anonisp.net [82.193.122.248]) by mx1.freebsd.org (Postfix) with ESMTP id E6D6CA68; Tue, 22 Jan 2013 14:47:53 +0000 (UTC) Received: by argon.h.anonisp.net (Postfix, from userid 982) id A935EFD05F; Tue, 22 Jan 2013 16:47:52 +0200 (EET) Received: from nikel.h.anonisp.net (nikel.vaganupa2.fbsd-ng.org [10.101.4.2]) by argon.h.anonisp.net (Postfix) with ESMTP id 693B7FD041; Tue, 22 Jan 2013 16:47:49 +0200 (EET) Received: by nikel.h.anonisp.net (SMTPd, from userid 982) id A62EF6A0423; Tue, 22 Jan 2013 16:47:49 +0200 (EET) Received: from [192.168.68.203] (unknown [195.216.206.4]) by nikel.h.anonisp.net (SMTPd) with ESMTPA id 7D4A16A041B; Tue, 22 Jan 2013 16:47:49 +0200 (EET) Message-ID: <50FEA684.8080000@vorakl.name> Date: Tue, 22 Jan 2013 16:47:32 +0200 From: Oleksii Tsvietnov MIME-Version: 1.0 To: Andriy Gapon Subject: Re: busy on all disks that are a part of the ZFS pools without any load References: <50FE9BB5.9090308@vorakl.name> <50FE9DCD.4040204@FreeBSD.org> In-Reply-To: <50FE9DCD.4040204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Value: 0.000000 (Ham) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:47:54 -0000 > These are values since boot, they do not reflect current system load. As I could see these values usually change from 0 to 60 . Why did they freeze on 7%? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 14:51:24 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD638D8F for ; Tue, 22 Jan 2013 14:51:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 02BA4AA7 for ; Tue, 22 Jan 2013 14:51:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA00475; Tue, 22 Jan 2013 16:51:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50FEA768.2090901@FreeBSD.org> Date: Tue, 22 Jan 2013 16:51:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Oleksii Tsvietnov Subject: Re: busy on all disks that are a part of the ZFS pools without any load References: <50FE9BB5.9090308@vorakl.name> <50FE9DCD.4040204@FreeBSD.org> <50FEA684.8080000@vorakl.name> In-Reply-To: <50FEA684.8080000@vorakl.name> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:51:24 -0000 on 22/01/2013 16:47 Oleksii Tsvietnov said the following: > >> These are values since boot, they do not reflect current system load. > > As I could see these values usually change from 0 to 60 . > Why did they freeze on 7%? That's the average value since boot to now? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 15:06:14 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE4B21BC; Tue, 22 Jan 2013 15:06:14 +0000 (UTC) (envelope-from me@vorakl.name) Received: from argon.h.anonisp.net (argon.h.anonisp.net [82.193.122.248]) by mx1.freebsd.org (Postfix) with ESMTP id 61B6FBDE; Tue, 22 Jan 2013 15:06:14 +0000 (UTC) Received: by argon.h.anonisp.net (Postfix, from userid 982) id 51E4BFD05F; Tue, 22 Jan 2013 17:06:13 +0200 (EET) Received: from nikel.h.anonisp.net (nikel.vaganupa2.fbsd-ng.org [10.101.4.2]) by argon.h.anonisp.net (Postfix) with ESMTP id 68809FD041; Tue, 22 Jan 2013 17:06:12 +0200 (EET) Received: by nikel.h.anonisp.net (SMTPd, from userid 982) id 358466A0423; Tue, 22 Jan 2013 17:06:12 +0200 (EET) Received: from [192.168.68.203] (unknown [195.216.206.4]) by nikel.h.anonisp.net (SMTPd) with ESMTPA id 11CDC6A041B; Tue, 22 Jan 2013 17:06:12 +0200 (EET) Message-ID: <50FEAAD2.5000902@vorakl.name> Date: Tue, 22 Jan 2013 17:05:54 +0200 From: Oleksii Tsvietnov MIME-Version: 1.0 To: Andriy Gapon Subject: Re: busy on all disks that are a part of the ZFS pools without any load References: <50FE9BB5.9090308@vorakl.name> <50FE9DCD.4040204@FreeBSD.org> <50FEA684.8080000@vorakl.name> <50FEA768.2090901@FreeBSD.org> In-Reply-To: <50FEA768.2090901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Value: 0.000000 (Ham) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:06:14 -0000 On 01/22/2013 04:51 PM, Andriy Gapon wrote: > That's the average value since boot to now? Maybe... Does iostat's busy always show avarage value since boot? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 15:34:26 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B8A4CA98 for ; Tue, 22 Jan 2013 15:34:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8C8FDD6 for ; Tue, 22 Jan 2013 15:34:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00815; Tue, 22 Jan 2013 17:34:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50FEB17F.2080709@FreeBSD.org> Date: Tue, 22 Jan 2013 17:34:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Oleksii Tsvietnov Subject: Re: busy on all disks that are a part of the ZFS pools without any load References: <50FE9BB5.9090308@vorakl.name> <50FE9DCD.4040204@FreeBSD.org> <50FEA684.8080000@vorakl.name> <50FEA768.2090901@FreeBSD.org> <50FEAAD2.5000902@vorakl.name> In-Reply-To: <50FEAAD2.5000902@vorakl.name> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:34:26 -0000 on 22/01/2013 17:05 Oleksii Tsvietnov said the following: > On 01/22/2013 04:51 PM, Andriy Gapon wrote: >> That's the average value since boot to now? > > Maybe... > Does iostat's busy always show avarage value since boot? Use -w option to see current state (starting from the second screen). Manual pages rule :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 15:55:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01D07202 for ; Tue, 22 Jan 2013 15:55:50 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id C5C9DF1C for ; Tue, 22 Jan 2013 15:55:49 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id C48C326C7E for ; Tue, 22 Jan 2013 10:55:48 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6FyFU7k-4uQ for ; Tue, 22 Jan 2013 10:55:48 -0500 (EST) Received: from EGR authenticated sender Message-ID: <50FEB684.9040201@egr.msu.edu> Date: Tue, 22 Jan 2013 10:55:48 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:55:50 -0000 On 01/22/13 05:19, Kai Gallasch wrote: > Hi. > > (Im am sending this to the "stable" list, because it maybe kernel related.. ) > > On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. > > The slapd runs for some days and then hangs, consuming high amounts of CPU. > In this state slapd can only be restarted by SIGKILL. > > # procstat -kk 71195 > PID TID COMM TDNAME KSTACK > 71195 149271 slapd - mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d do_wait+0x678 __umtx_op_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7 > On UFS2 slapd runs fine, without showing the error. > Has anyone else running openldap-server on FreeBSD 9.1 inside a jail seen similar problems? I have seen openldap spin the cpu and even run out of memory to get killed on some of our test systems running ~9.1-rel with zfs. No jails. I'm not sure what would have put load on our test systems other than nightly scripts. I had to focus my attention on other servers so I don't have one to inspect at this point, but I won't be surprised if I see this in production. Thanks for the tip about it being ZFS related, and I'll let you know if I find anything out. This is mostly a "me too" reply. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 17:16:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5CDE90B; Tue, 22 Jan 2013 17:16:49 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id A34FC715; Tue, 22 Jan 2013 17:16:49 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id qd14so11819204ieb.6 for ; Tue, 22 Jan 2013 09:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aSyed+y1c4mVcrZvvftQaRGopwBXw/6drdgqXoETXbY=; b=0vZXbgTnJkacr6yQVLS4mjMPTnG5l9Ox+MYvT+GWcATb/2u+OUh73bHYp3/0SjMMJ9 rxhAtCA3oZP2jgPt5+yxkFvC/GpdT1hBW52QsPhjuNB8bJ7AvQ0lOcdPkGTLt4ol1kxb J74bf1QFqtNWND+4Sys38ac0KF3L7S1Sg24IAYUL4vPmQs3aQaxtIpcO92IvEq6jXMtM luEWDrNIg/XdAeZxnTbPcCj7n5JMAn7JqvZkV7E6qNqdeSwcbDOTxTHUG88vz6Jxegfm 9MAZilV4U8QMuRn4964M7Uk+oDO4uIPeLhFz0xdHWYLS5bXVUqZFJrCmT7Byz6+wLb3C YMkw== MIME-Version: 1.0 X-Received: by 10.50.222.226 with SMTP id qp2mr12745969igc.103.1358875009202; Tue, 22 Jan 2013 09:16:49 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 22 Jan 2013 09:16:48 -0800 (PST) Received: by 10.64.51.98 with HTTP; Tue, 22 Jan 2013 09:16:48 -0800 (PST) In-Reply-To: <50FBFA2C.2010504@digiware.nl> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> <50FBFA2C.2010504@digiware.nl> Date: Tue, 22 Jan 2013 19:16:48 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:16:50 -0000 I started investigating ipmi, so far i can configure IP from fbsd to ipmi. My question is how to access it? Can it be done inband attached to one oc the Ibm nics kn the board? or knlh out oc band? In case of oob any knows if the iLO plug is pure rj45 in ibm servers (specially x3250/3550)? Thanks in advance Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 20 =D7=91=D7=99=D7=A0=D7=95 2013 16:0= 7, =D7=9E=D7=90=D7=AA "Willem Jan Withagen" : > On 17-1-2013 4:18, Ian Lepore wrote: > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > >> Thank you for your response, very helpful. > >> one question - how do i configure auto-reboot once kernel panic occurs= ? > >> > >> Sami > >> > > > > From src/sys/conf/NOTES, this may be what you're looking for... > > > > # > > # Don't enter the debugger for a panic. Intended for unattended operati= on > > # where you may want to enter the debugger from the console, but still > want > > # the machine to recover from a panic. > > # > > options KDB_UNATTENDED > > > > But I think it only has meaning if you have option KDB in effect, > > otherwise it should just reboot itself after a 15 second pause. > > Well it is not the magical fix-all solution. > > Last night I had to drive to the colo (lucky for me a 5 min drive.) > because I could not get a system to reboot/recover from a crash. > > Upon arrival the system was crashed and halted on the message: > rebooting in 15 sec. > > Which but those 15 secs are would have gone by for about 10-20 minutes. > fysically rebooting or resetting ended up in the same position: > rebooting in 15 sec. > Without ever getting to actually rebooting. > > So if I (you) have servers 2 hours away, I usually try to work on > upgrading/rebooting during business hours. And remote hands can get me > out of trouble.... > > IPMI is another nice way of getting at the server in these cases. But > that requires a lot more infra and tinkering. > > --WjW > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 18:42:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9314D9C6; Tue, 22 Jan 2013 18:42:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (we-in-x022e.1e100.net [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAD4D3E; Tue, 22 Jan 2013 18:42:22 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so642052wey.33 for ; Tue, 22 Jan 2013 10:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m1Qkn8eykiUBFhU0VZsC6t9yfS+yduqe3IIdLXFxKWc=; b=dIH/z9foC5kZxLtdV5srTphsSENOAjwRR2t995kOGH3xObnEdQZl2Qhw2oyerDXmm0 6hUFDM2vVzT6EQX2SltOwE/PEj4U/Obso/GpgZvjyhWmn50dVwNMB9UPoOxtuf7Fjw6F 9nUWVbUNWL30bW2bT9kC+sfDLS2cpISzw9W6O3ZWXC511/vlYz9s7DD7v/xK8lDjLoLn 9EuoFlPt+2k58JcFmJtydSnfnUQohjQswOY53rq5jy4LWrD8MdW46BpHQkWT7OFR/oEq 83RrQmcgD0XX4J0sJ/tRHnPGk73vqtqyURdszkxVw1+4JR8peSPvDeRZO5ra6RGx7TEw I5aw== MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr23159091wia.28.1358880141992; Tue, 22 Jan 2013 10:42:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.123.73 with HTTP; Tue, 22 Jan 2013 10:42:21 -0800 (PST) In-Reply-To: References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> Date: Tue, 22 Jan 2013 10:42:21 -0800 X-Google-Sender-Auth: bpIMjXtveeKUcLAS9t64oDbvl7Y Message-ID: Subject: Re: time issues and ZFS From: Adrian Chadd To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:42:23 -0000 Hi! As I said before, the problem with non-HLT loops with event-timer in -9 and -head is that it calls the idle function inside a critical section (critical_enter and critical_exit) which blocks interrupts from occuring. The EI;HLT instruction pair on i386/amd64 atomically and correctly handles things from what I've been told. However, there's no atomic way to do this using ACPI sleeping, so there's a small window where an interrupt may come in but it isn't handled; waiting for the next interrupt to occur before it'll wake up and respond to that interrupt. I kept hitting my head against this when doing network testing. :( Now - specifically for timekeeping it shouldn't matter; that's to do with whether the counters are reliable or not (and heck, are even in lock-step on CPUs.) But extra latency could show up weirdly, hence why I was asking for you to try different timer configurations and idle loops. Thanks, Adrian On 22 January 2013 01:55, Daniel Braniss wrote: >> Daniel, >> >> Have you run tests with the machdep.idle value changed, and fiddling >> kern.eventtimer.periodic / kern.eventtimer.idletick ? > > Adrian, > > not yet, for several reasons: > 1- as I explained, I can't realy force the problem, it happens when we run some > zfs scripts, like mirror, but have to wait till enough changes happened on > the source, usualy after 24hs. > 2- changing to LAPIC seems to have solved the problem. > 3- I'm now learning all I can about event timers and you have not answered some > of my questions :-) > > danny > > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 02:04:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88AA0BFD for ; Wed, 23 Jan 2013 02:04:27 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 48AC518F for ; Wed, 23 Jan 2013 02:04:26 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 1929D42C2520; Wed, 23 Jan 2013 03:06:42 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 22 Jan 2013 20:04:12 -0600 (CST) From: Bryan Venteicher To: Franz Schwartau Message-ID: <1366804865.5.1358906652665.JavaMail.root@daemoninthecloset.org> In-Reply-To: <50FE627C.7070701@electromail.org> References: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> <50FE627C.7070701@electromail.org> Subject: Re: kvm vlan virtio problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.200] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC24 (Mac)/8.0.2_GA_5569) Thread-Topic: kvm vlan virtio problem Thread-Index: by8VpTAtISXOQf7YbIhqSf5VHzywYw== Cc: freebsd-stable@freebsd.org, bane ivosev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 02:04:27 -0000 Hi, ----- Original Message ----- > Hi! > > The same warning shows up in our setup: > > Jan 21 23:40:46 host kernel: WARNING: at net/core/dev.c:1712 > skb_gso_segment+0x1df/0x2b0() (Tainted: G W --------------- ) > Jan 21 23:40:46 host kernel: Hardware name: System Product Name > Jan 21 23:40:46 host kernel: tun: caps=(0x1b0049, 0x0) len=4452 > data_len=4380 ip_summed=0 > [...] > > KVM host: CentOS 6.3, Linux kernel 2.6.32-279.19.1.el6.x86_64 > VM guest: FreeBSD 9.1, virtio-kmod-9.1-0.242658 > > Disabling TSO on vtnet0 stops the warnings on the KVM host. > > Is there any progress on this issue? > It seems the only way this could happen is if the FreeBSD TCP/IP stack sent down an mbuf with CSUM_TSO set and CSUM_TCP not set; this doesn't seem possible from looking at FreeBSD's tcp_output(). I'll try to look closer at this during this week. Bryan > Best regards > Franz > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 03:44:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21B08204 for ; Wed, 23 Jan 2013 03:44:31 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id B8BA5791 for ; Wed, 23 Jan 2013 03:44:30 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 9D26A42C256D; Wed, 23 Jan 2013 04:46:52 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 22 Jan 2013 21:44:22 -0600 (CST) From: Bryan Venteicher To: Franz Schwartau Message-ID: <627694717.15.1358912662920.JavaMail.root@daemoninthecloset.org> In-Reply-To: <50FE627C.7070701@electromail.org> References: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> <50FE627C.7070701@electromail.org> Subject: Re: kvm vlan virtio problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: kvm vlan virtio problem Thread-Index: rwbdQLLJ9tPY/ZKQ0lN/LuPqChcXYw== Cc: freebsd-stable@freebsd.org, bane ivosev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 03:44:31 -0000 Hi, ----- Original Message ----- > Hi! > > The same warning shows up in our setup: > > Jan 21 23:40:46 host kernel: WARNING: at net/core/dev.c:1712 > skb_gso_segment+0x1df/0x2b0() (Tainted: G W --------------- ) > Jan 21 23:40:46 host kernel: Hardware name: System Product Name > Jan 21 23:40:46 host kernel: tun: caps=(0x1b0049, 0x0) len=4452 > data_len=4380 ip_summed=0 > [...] > > KVM host: CentOS 6.3, Linux kernel 2.6.32-279.19.1.el6.x86_64 > VM guest: FreeBSD 9.1, virtio-kmod-9.1-0.242658 > > Disabling TSO on vtnet0 stops the warnings on the KVM host. > > Is there any progress on this issue? > Alright, I tried to recreate this on Ubuntu 12.10 without any luck. Please describe your network configuration. On my Linux host, my VLAN interface looks like: eth0.100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3119867 errors:0 dropped:0 overruns:0 frame:0 TX packets:3790183 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:166813040 (166.8 MB) TX bytes:5435432448 (5.4 GB) That is plugged into this bridge: br100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d inet addr:192.168.99.101 Bcast:192.168.99.255 Mask:255.255.255.0 inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:876 (876.0 B) TX bytes:1420 (1.4 KB) With the tap device created by QEMU for my FreeBSD guest: vnet1 Link encap:Ethernet HWaddr fe:54:00:ec:4f:4e inet6 addr: fe80::fc54:ff:feec:4f4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:800284 errors:0 dropped:0 overruns:0 frame:0 TX packets:3119877 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:5238099122 (5.2 GB) TX bytes:210492002 (210.4 MB) All this tied together: # brctl show br100 bridge name bridge id STP enabled interfaces br100 8000.6cf049052b6d no eth0.100 vnet1 Does this approximate your configuration? What's the output of `ethtool -k` for your VLAN, bridge, and vnet interfaces? Bryan > Best regards > Franz > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 12:22:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 29B9A5BF for ; Wed, 23 Jan 2013 12:22:20 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from manhattan.ops.eusc.inter.net (manhattan.ops.eusc.inter.net [84.23.254.159]) by mx1.freebsd.org (Postfix) with ESMTP id DE31CE0C for ; Wed, 23 Jan 2013 12:22:19 +0000 (UTC) X-Trace: 507c6a6f6572675f7375726d616e6e7c39322e3233312e3230372e3130377c3154 787972572d3030304a70792d39737c31333538393431383836 Received: from manhattan.ops.eusc.inter.net ([10.159.10.19] helo=localhost) by manhattan.ops.eusc.inter.net with esmtpsa (Exim 4.80.1) id 1TxyrW-000Jpy-9s for freebsd-stable@freebsd.org; Wed, 23 Jan 2013 12:51:26 +0100 Message-ID: <50FFCEBD.60506@snafu.de> Date: Wed, 23 Jan 2013 12:51:25 +0100 From: joerg surmann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD_mailiglist_KERNEL Subject: buildworld problem 9.1 stable X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 92.231.207.107 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on manhattan.ops.eusc.inter.net); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:22:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hey, i have a alix board here. it's a new installation. *#make buildworld* snip {standard input}: Assembler messages: {standard input}:17822: Warning: end of file not at end of a line; newline inserted {standard input}:19715: Error: unknown pseudo-op: `.l241' cc: Internal error: Killed: 9 (program cc1) Please submit a full bug report. See for instructions. *** [insn-attrtab.o] Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** [all] Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** [cross-tools] Error code 1 Stop in /usr/src. *** [_cross-tools] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. * # gcc -v* Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] * #cat /etc/make.conf* WITH_SYSTEM_CLANG=3D"YES" WITH_PKGNG=3D"YES" =2Eif (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) =2Eif !defined(NOCCACHE) CC:=3D${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} CXX:=3D${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} =2Eendif =2Eendif ##Clang will return a lot of 'unused argument' warnings: they are harmles= s. ##Just add this to /etc/make.conf if you want to hide them: =2Eif ${CC:T} =3D=3D "clang" CFLAGS+=3D -Qunused-arguments =2Eendif Thanks for some help. Suri -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJQ/868AAoJEDyDkpKh+9pTILQP/2yoL8DvRPpabipDocO11kTt 2OzVwcTR+vh7AOQbsYf9c0zt4NvL66I5kW3vGAd6GHCaBozzsz3Ct4DgsuBxk1KU EatHPVjqoVzBHuBMDD3SxR4RT/5OAXU4lOs8V7IFY3j2/hcnrow2ruUNG4UDIrSl dlVnCMIdfPTRMkOE4XIi27XMrDyxKsbIS9QRNmj4SnCT+3/I8ipc5Z5bXN4ObWji g33VTojL3zT9KcJw1LqI48vSa3OxqHcuUkJ5PEQFLoSSJJXAWeFUn26bRNKbn3n0 b3gaJ1QsGgdySo1FLVEyLebyxctEaGMPRjSEXkt8XvgRjUWMaO2IL9ePZjZhB3JO pKZIRD1LrbgnVLQJ0d7Lw6r1jHU4KbyLpkSLNvoc4LlOxAXxelGBobJyhxIC7OJ6 EIFttgHmPXY9VQ4HNyDlMAqrY7AErW06KUWHsqx1TAxcsOqU3kTDsx3WIZzKR9Zz W0W4ownLYBCfi86I7/SsBI21GR1MTn0XAYyvGJv98L/vmrlyLpetSLsGjiKw/1BM xTXqBUsqN5fCKYDawkSd5mNhRPl3yKg8CpbP3l0x1UD5oU61bKe1Vq0/EzIMEfqc QceuYzrH+V1XpqBMZhS9HY9TC5tW1VVkl0Kr90kArgZKmi2QCzippYOcPyWvhf1s 2JLML6k+1LOUebSSd10L =3D45wV -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 12:31:35 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7E167D5 for ; Wed, 23 Jan 2013 12:31:35 +0000 (UTC) (envelope-from asn@yam.park.rambler.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7FFCEE84 for ; Wed, 23 Jan 2013 12:31:33 +0000 (UTC) Received: from yam.park.rambler.ru (localhost [127.0.0.1]) by yam.park.rambler.ru (8.14.5/8.14.1) with ESMTP id r0NCVPJT094469 for ; Wed, 23 Jan 2013 16:31:25 +0400 (MSK) (envelope-from asn@yam.park.rambler.ru) Received: (from asn@localhost) by yam.park.rambler.ru (8.14.5/8.14.5/Submit) id r0NCVPrF094468 for stable@FreeBSD.org; Wed, 23 Jan 2013 16:31:25 +0400 (MSK) (envelope-from asn) Date: Wed, 23 Jan 2013 16:31:25 +0400 From: Alexander Nikiforenko To: stable@FreeBSD.org Subject: 9.1 coredump Message-ID: <20130123123125.GF14440@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:31:35 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=koi8-r Content-Disposition: inline hi, i was run ssh-keygen with output to 32g usb 3.0 flash, and got this core --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="core.txt.2" t61.park.rambler.ru dumped core - see /var/crash/vmcore.2 Wed Jan 23 14:21:17 MSK 2013 FreeBSD t61.park.rambler.ru 9.1-STABLE FreeBSD 9.1-STABLE #0: Wed Jan 9 12:14:15 MSK 2013 root@t61.park.rambler.ru:/usr/obj/usr/src/sys/T61 amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3454f8e9 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x3454f8e9 stack pointer = 0x28:0xffffff811d4a1660 frame pointer = 0x28:0xffffff811d4a1850 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 83843 (ssh-keygen) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff804ae2d0 at kdb_backtrace+0x60 #1 0xffffffff8047991d at panic+0x1fd #2 0xffffffff806326a8 at trap_fatal+0x388 #3 0xffffffff80632925 at trap_pfault+0x265 #4 0xffffffff80631fe5 at trap+0x415 #5 0xffffffff8061c7d3 at calltrap+0x8 #6 0xffffffff80510db6 at kern_openat+0x1a6 #7 0xffffffff80632e72 at amd64_syscall+0x282 #8 0xffffffff8061cabb at Xfast_syscall+0xfb Uptime: 9d1h59m50s Dumping 881 out of 3968 MB:..2%..11%..22%..31% (CTRL-C to abort) ..42% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..51%..62%..71%..82%..91% Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /boot/kernel/i915kms.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915kms.ko Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /boot/kernel/drm2.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm2.ko Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /boot/kernel/iicbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/iic.ko...Reading symbols from /boot/kernel/iic.ko.symbols...done. done. Loaded symbols for /boot/kernel/iic.ko Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /boot/kernel/iicbb.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbb.ko Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from /boot/kernel/msdosfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/msdosfs.ko Reading symbols from /boot/kernel/ntfs.ko...Reading symbols from /boot/kernel/ntfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/ntfs.ko Reading symbols from /boot/kernel/mmcsd.ko...Reading symbols from /boot/kernel/mmcsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmcsd.ko Reading symbols from /boot/kernel/mmc.ko...Reading symbols from /boot/kernel/mmc.ko.symbols...done. done. Loaded symbols for /boot/kernel/mmc.ko Reading symbols from /boot/kernel/sdhci.ko...Reading symbols from /boot/kernel/sdhci.ko.symbols...done. done. Loaded symbols for /boot/kernel/sdhci.ko #0 doadump (textdump=) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:229 #1 0xffffffff80479504 in kern_reboot (howto=) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80479973 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff806326a8 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:878 #4 0xffffffff80632925 in trap_pfault (frame=, usermode=) at /usr/src/sys/amd64/amd64/trap.c:699 #5 0xffffffff80631fe5 in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff8061c7d3 in calltrap () at /tmp/exception-ecojh7.s:123 #7 0x000000003454f8e9 in ?? () #8 0xffffffff805190ef in vn_open_cred (ndp=, flagp=, cmode=, vn_open_flags=, cred=, fp=) at vnode_if.h:1791 #9 0xffffffff80510db6 in kern_openat (td=, fd=, path=, pathseg=, flags=1538, mode=) at /usr/src/sys/kern/vfs_syscalls.c:1132 #10 0xffffffff80632e72 in amd64_syscall (td=, traced=) at subr_syscall.c:135 #11 0xffffffff8061cabb in Xfast_syscall () at /tmp/exception-ecojh7.s:273 #12 0x000000080134df4c in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 8 0 0 0 - DLs ?? 1:44.08 [ 0 1 0 0 20 0 6276 0 wait DLs ?? 0:00.13 [ 0 2 0 0 -16 0 0 0 ctl_work DL ?? 0:00.00 [ 0 3 0 0 -16 0 0 0 ccb_scan DL ?? 0:00.00 [ 0 4 0 0 -16 0 0 0 psleep DL ?? 0:10.46 [ 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.04 [ 0 6 0 0 155 0 0 0 pgzero DL ?? 0:00.02 [ 0 7 0 0 -16 0 0 0 psleep DL ?? 0:04.62 [ 0 8 0 0 16 0 0 0 syncer DL ?? 43:19.60 [ 0 9 0 0 -16 0 0 0 vlruwt DL ?? 0:19.10 [ 0 10 0 0 155 0 0 0 - RL ?? 50940:02.73 [ 0 11 0 0 -84 0 0 0 - WL ?? 27:43.29 [ 0 12 0 0 -8 0 0 0 - DL ?? 1:01.51 [ 0 13 0 0 -16 0 0 0 - DL ?? 0:49.78 [ 0 14 0 0 -68 0 0 0 - DL ?? 3:17.20 [ 0 15 0 0 -16 0 0 0 tzpoll DL ?? 0:56.23 [ 0 16 0 0 -16 0 0 0 sdflush DL ?? 0:12.94 [ 0 153 1 0 52 0 9912 0 pause DWs ?? 0:00.00 [ 0 366 1 0 20 0 18344 0 select Ds ?? 2:39.92 [ 0 631 1 0 20 0 10372 0 select Ds ?? 0:00.21 [ 0 762 1 0 20 0 12040 0 select Ds ?? 0:53.61 [ 0 817 1 0 20 0 14216 0 select Ds ?? 0:02.95 [ 0 869 1 0 20 0 22200 0 select Ds ?? 0:47.53 [ 0 872 1 0 20 0 12036 0 select Ds ?? 17:17.66 [ 0 885 1 0 20 0 46728 0 select Ds ?? 0:00.00 [ 0 897 1 0 20 0 20256 0 select Ds ?? 0:26.36 [ 25 900 1 0 20 0 20256 0 pause Ds ?? 0:00.37 [ 0 904 1 0 20 0 14116 0 nanslp Ds ?? 0:03.61 [ 0 951 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 952 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 953 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 954 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 955 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 956 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 0 957 1 0 52 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 1001 975 1 0 20 0 36136 0 select Ds ?? 0:00.49 [ 1001 980 1 0 52 0 14496 0 wait DW ?? 0:00.00 [ 1001 998 980 0 31 0 23668 0 wait DW ?? 0:00.00 [ 0 999 998 0 20 0 130728 0 select D ?? 244:56.20 [ 1001 1002 998 0 20 0 71664 0 select D ?? 0:39.67 [ 1001 1003 1002 0 20 0 40844 0 select D ?? 0:06.94 [ 1001 1005 1 0 20 0 23672 0 nanslp D ?? 36:50.88 [ 1001 1021 1002 0 20 0 61380 0 select D ?? 0:01.56 [ 1001 1022 1002 0 20 0 54124 0 piperd D ?? 0:00.26 [ 1001 1025 1002 0 20 0 63472 0 select D ?? 1:45.61 [ 1001 1026 1002 0 20 0 61380 0 select D ?? 0:43.69 [ 1001 1027 1002 0 20 0 52856 0 select D ?? 0:11.34 [ 0 1034 1 0 20 0 12040 0 ttyin Ds+ ?? 0:00.00 [ 1001 1039 1 0 22 0 30116 0 select D ?? 0:00.00 [ 1001 1040 1 0 20 0 14300 0 select Ds ?? 1:32.77 [ 1001 1041 1002 0 20 0 65456 0 select D ?? 0:05.04 [ 1001 1043 1041 0 20 0 17424 0 wait DWs ?? 0:00.00 [ 1001 1051 1043 0 20 0 38256 0 select D+ ?? 0:03.90 [ 1001 1160 1002 0 20 0 204144 0 select D ?? 195:38.39 [ 1001 20023 1002 0 20 0 1319996 0 fffffe00d0ec4300 D ?? 92:24.53 [ 1001 20462 1 0 20 0 25192 0 select D ?? 0:00.23 [ 0 21582 1 0 20 0 14216 0 select Ds ?? 0:33.90 [ 1001 22194 1002 0 20 0 329492 0 select D ?? 3:32.70 [ 1001 25136 1002 0 20 0 65456 0 select D ?? 0:00.15 [ 1001 25138 25136 0 20 0 17424 0 wait Ds ?? 0:00.01 [ 1001 25269 25138 0 20 0 33336 0 select D+ ?? 0:00.36 [ 1001 25270 25269 0 21 0 17424 0 ttyin Ds+ ?? 0:00.05 [ 1001 27825 1 0 20 0 16552 0 select Ds ?? 1:21.14 [ 1001 27826 27825 0 20 0 17424 0 wait Ds ?? 0:00.00 [ 0 27828 27826 0 20 0 42400 0 select D ?? 0:00.00 [ 0 27829 27828 0 52 0 17424 0 ttyin D+ ?? 0:00.02 [ 1001 50098 74351 0 20 0 12276 0 ttyin D+ ?? 0:00.02 [ 1001 73828 1002 0 20 0 65456 0 select D ?? 0:00.02 [ 1001 73830 73828 0 20 0 17424 0 ttyin Ds+ ?? 0:00.01 [ 1001 74349 1002 0 20 0 69552 0 select D ?? 0:01.90 [ 1001 74351 74349 0 20 0 17424 0 wait DWs ?? 0:00.00 [ 1001 78297 1002 0 20 0 69552 0 select D ?? 0:00.06 [ 1001 78299 78297 0 20 0 17424 0 wait Ds ?? 0:00.00 [ 0 78301 78299 0 20 0 42408 0 select D ?? 0:00.00 [ 0 78302 78301 0 52 0 17424 0 ttyin D+ ?? 0:00.00 [ 1001 80090 1002 0 20 0 69552 0 select D ?? 0:06.42 [ 1001 80092 80090 0 20 0 17424 0 wait Ds ?? 0:00.01 [ 1001 83761 80092 0 20 0 38256 0 select D+ ?? 0:00.08 [ 1001 83824 1002 0 20 0 69552 0 select D ?? 0:00.00 [ 1001 83826 83824 0 20 0 17424 0 wait Ds ?? 0:00.00 [ 0 83828 83826 0 22 0 42408 0 select D ?? 0:00.00 [ 0 83829 83828 0 20 0 17424 0 wait D ?? 0:00.00 [ 0 83835 1 0 20 0 35900 0 fu_msg Ds ?? 0:00.00 [ 0 83843 83829 0 20 0 36136 0 - R+ ?? 0:00.00 [ ------------------------------------------------------------------------ vmstat -s 2163744646 cpu context switches 40033724 device interrupts 386007454 software interrupts 565492932 traps 3889763992 system calls 18 kernel threads created 302137 fork() calls 179763 vfork() calls 1297 rfork() calls 42816 swap pager pageins 46113 swap pager pages paged in 42975 swap pager pageouts 127153 swap pager pages paged out 237623 vnode pager pageins 2370807 vnode pager pages paged in 38559 vnode pager pageouts 446656 vnode pager pages paged out 364 page daemon wakeups 14095430 pages examined by the page daemon 414722 pages reactivated 17567633 copy-on-write faults 12855 copy-on-write optimized faults 274207164 zero fill pages zeroed 20633 zero fill pages prezeroed 55125 intransit blocking page faults 320823982 total VM faults taken 0 pages affected by kernel thread creation 158302390 pages affected by fork() 86843891 pages affected by vfork() 519911 pages affected by rfork() 0 pages cached 383721291 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 173382 pages active 549446 pages inactive 2521 pages in VM cache 198707 pages wired down 57290 pages free 4096 bytes per page 344111873 total name lookups cache hits (81% pos + 6% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) devbuf 22953 57318K - 29421 16,32,64,128,256,512,1024,2048,4096 temp 46 12K - 32066078 16,32,64,128,256,512,1024,2048,4096 agp 1 1K - 1 32 module 216 27K - 220 128 mtx_pool 2 16K - 2 USB 58 80K - 212 16,32,64,128,256,512,1024,2048 osd 2 1K - 2 16,64 USBdev 53 18K - 158 64,128,512,4096 pmchooks 1 1K - 1 128 pgrp 60 8K - 6052 128 session 36 5K - 4488 128 proc 2 16K - 2 subproc 488 538K - 482328 512,4096 cred 110 18K - 5559654 64,256 plimit 18 5K - 62855 256 uidinfo 4 3K - 4223 128,2048 CAM SIM 5 2K - 11 256 entropy 1024 64K - 1024 64 sysctl 0 0K - 707761 16,32,64 sysctloid 6408 320K - 7311 16,32,64,128 sysctltmp 0 0K - 100013 16,32,64,128,256,2048 tidhash 1 16K - 1 callout 3 1536K - 3 umtx 1590 199K - 1632 128 p1003.1b 1 1K - 1 16 SWAP 2 753K - 2 64 bus 874 7291K - 5313 16,32,64,128,256,512,1024 bus-sc 152 434K - 1477 16,32,64,128,256,512,1024,2048,4096 devstat 8 17K - 8 32,4096 eventhandler 78 7K - 78 64,128 hdaa 10 26K - 10 1024,2048,4096 hdac 1 1K - 1 1024 kobj 144 576K - 1137 4096 hdacc 2 1K - 2 32 Per-cpu 1 1K - 1 32 CAM XPT 40 4K - 156 16,32,64,128,256,1024,2048 scsi_da 0 0K - 126 16 acpiintr 1 1K - 1 64 rman 227 27K - 589 16,32,128 sbuf 0 0K - 4612 16,32,64,128,256,512,1024,2048,4096 acpica 5992 608K - 29800090 16,32,64,128,256,512,1024,2048,4096 CAM DEV 6 12K - 29 2048 CAM CCB 41 82K - 77 2048 stack 0 0K - 2 256 taskqueue 23 2K - 23 16,32,128 Unitno 47 2K - 4707442 32,64 ioctlops 0 0K - 777086666 16,32,64,128,256,512,1024 select 533 67K - 536 128 iov 0 0K - 179438679 16,32,64,128,256,512,1024,2048,4096 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 7 32K - 801 2048 tty 26 26K - 171 1024,2048 pts 9 3K - 152 256 mbuf_tag 0 0K - 2 32 shmfd 1 8K - 1 soname 34 4K - 1334859 16,32,64,128 pcb 22 13K - 134255 16,32,1024,2048,4096 acpitask 1 8K - 1 acl 0 0K - 19471 4096 vfscache 1 2048K - 1 cl_savebuf 0 0K - 96179 64 vfs_hash 1 1024K - 1 vnodes 2 1K - 9 64,256 feeder 32 4K - 4017 32,128 acpisem 29 4K - 29 128 mount 56 3K - 424 16,32,64,128,256,512,2048 vnodemarker 0 0K - 76053 512 BPF 10 1026K - 11 16,128,512 ifnet 7 13K - 7 128,2048 ifaddr 124 12K - 124 32,512,4096 ether_multi 7 1K - 8 16,64 clone 4 16K - 4 4096 arpcom 2 1K - 2 16 lltable 10 4K - 606 256,512 DEVFS3 151 38K - 439 256 DEVFS1 128 64K - 381 512 DEVFS 20 1K - 34 16,128 DEVFSP 3 1K - 68 64 routetbl 11 3K - 5390 32,64,128,256,512 80211vap 1 4K - 1 4096 80211com 1 8K - 1 80211node 1 12K - 1 80211ratectl 2 1K - 2 16,64 80211scan 1 4K - 1 4096 igmp 6 2K - 6 256 in_multi 2 1K - 2 256 pfs_nodes 21 6K - 21 256 GEOM 38 16K - 1741 16,32,64,128,256,512,1024 hostcache 1 28K - 1 syncache 1 96K - 1 pagedep 1 128K - 65874 256 inodedep 11 1029K - 231414 512 bmsafemap 1 8K - 165163 256 newblk 1 128K - 1552264 256 indirdep 0 0K - 14491 128 freefrag 0 0K - 242978 128 freeblks 0 0K - 113957 128 freefile 0 0K - 95720 64 diradd 0 0K - 131120 128 mkdir 0 0K - 12644 128 dirrem 0 0K - 125751 128 newdirblk 0 0K - 6391 64 freework 1 1K - 304146 16,128 freedep 0 0K - 12912 64 jaddref 0 0K - 143764 128 jremref 0 0K - 135677 128 jmvref 0 0K - 1441 128 jnewblk 0 0K - 1552263 128 jfreefrag 0 0K - 242978 128 jseg 0 0K - 77245 128 jsegdep 0 0K - 2074682 64 sbdep 0 0K - 15634 64 savedino 0 0K - 22457 256 jblocks 2 1K - 2 128,256 ufs_dirhash 1610 378K - 583403 16,32,64,128,256,512,1024 ufs_mount 3 17K - 3 512,4096 vm_pgdata 2 513K - 2 128 UMAHash 4 161K - 23 512,1024,2048,4096 acpidev 48 3K - 48 64 CAM path 8 1K - 60 32 CAM periph 6 2K - 36 16,32,64,128,256 CAM queue 19 1K - 183 16,32,64,512 mixer 5 20K - 5 4096 CAM dev queue 5 1K - 11 128 ctlmem 5062 10113K - 5062 128,2048 memdesc 1 4K - 2 4096 ctlblk 200 1600K - 200 isadev 8 1K - 8 128 atkbddev 2 1K - 2 64 ramdisk 1 4096K - 1 ctlpool 532 142K - 532 32,512 pci_link 16 2K - 16 32,128 cdev 9 3K - 9 256 kbdmux 6 18K - 6 16,512,1024,2048 LED 12 1K - 12 16,128 filedesc 138 159K - 487351 16,32,64,128,256,512,1024,2048,4096 filedesc_to_leader 0 0K - 1337 64 sigio 2 1K - 2 64 kenv 77 11K - 85 16,32,64,128 kqueue 7 10K - 93761 256,512,2048,4096 proc-args 68 5K - 594710 16,32,64,128,256 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 hhook 2 1K - 2 128 ithread 95 16K - 96 32,128,256 io_apic 1 2K - 1 2048 KTRACE 100 13K - 100 128 MCA 12 2K - 12 32,64,128 acpi_perf 4 1K - 4 256 linker 295 726K - 443 16,32,64,128,256,512,1024,2048,4096 msi 13 2K - 13 128 nexusdev 3 1K - 3 16 lockf 46 6K - 2398199 64,128 loginclass 1 1K - 4264 64 futex wp 0 0K - 4605424 32 linux 15 1K - 2045 32,64 ksem 1 8K - 1 futex 0 0K - 5557540 128 tmpfs mount 1 1K - 1 128 tmpfs name 2555 44K - 466032 16,32,64,128,256 fuse_messaging 9 4K - 12 128,512,1024 fuse_vnode 3 1K - 3 256 fuse_filehandles 1 1K - 4 128 gem_name 4134 142K - 1286547 32,4096 drm_vblank 7 1K - 7 16,64 drm_sarea 1 1K - 1 16 drm_driver 9 10K - 9 32,64,1024 drm_magic 0 0K - 40 32 drm_maps 3 9K - 5 128 drm_files 2 1K - 84 64,256 drm_agplists 1 1K - 1 128 drm_ctxbitmap 1 4K - 1 4096 drm_sman 562 71K - 936350 128 drm_hashtab 1 4096K - 1 drm_kms 69 56K - 147 16,32,64,128,256,512,1024,2048 i915gem 4742 2146K - 720103299 16,32,64,128,256,512,1024,2048,4096 msdosfs_node 0 0K - 1679 256 msdosfs_mount 0 0K - 6 512 msdosfs_fat 0 0K - 2 ntfs_mount 0 0K - 2 512,2048 ntfs_ntnode 0 0K - 5 256 ntfs_fnode 0 0K - 5 256 ntfs_dir 0 0K - 1 4096 ntfs_vattr 0 0K - 22 512 ntfsd_resdata 0 0K - 17 16,64,128,512 ntfs_vrun 0 0K - 12 16 ntfs_nthash 1 1024K - 1 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 79, 6, 79, 0, 0 UMA Zones: 896, 0, 79, 1, 79, 0, 0 UMA Slabs: 568, 0, 24314, 11, 105094, 0, 0 UMA RCntSlabs: 568, 0, 2425, 95, 29182, 0, 0 UMA Hash: 256, 0, 0, 0, 4, 0, 0 16 Bucket: 152, 0, 16, 109, 135, 0, 0 32 Bucket: 280, 0, 20, 106, 314, 0, 0 64 Bucket: 536, 0, 97, 29, 685, 57, 0 128 Bucket: 1048, 0, 1602, 0, 53521,228322, 0 VM OBJECT: 232, 0, 104665, 63639,14319800, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 147374, 118, 1184, 176207, 0, 0 MAP ENTRY: 120, 0, 7175, 4109,22475430, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 264, 30, 264, 0, 0 16: 16, 0, 6322, 13502,891911754, 0, 0 32: 32, 0, 8046, 29627,317264234, 0, 0 64: 64, 0, 12754, 13678,300742345, 0, 0 128: 128, 0, 14713, 10169,164321756, 0, 0 256: 256, 0, 683, 13612,49664209, 0, 0 512: 512, 0, 5757, 1523, 4145524, 0, 0 1024: 1024, 0, 109, 635,19517071, 0, 0 2048: 2048, 0, 5182, 624,28030636, 0, 0 4096: 4096, 0, 360, 358, 563553, 0, 0 Files: 80, 0, 283, 11462,33766355, 0, 0 rl_entry: 40, 0, 707, 133, 715, 0, 0 TURNSTILE: 136, 0, 796, 124, 817, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 83, 319, 483215, 0, 0 THREAD: 1160, 0, 479, 316, 20909, 0, 0 SLEEPQUEUE: 80, 0, 796, 74, 817, 0, 0 VMSPACE: 392, 0, 68, 362, 482271, 0, 0 cpuset: 72, 0, 58, 192, 60, 0, 0 mbuf_packet: 256, 0, 1023, 1408,15042504, 0, 0 mbuf: 256, 0, 66, 1314,224172051, 0, 0 mbuf_cluster: 2048, 25600, 1920, 1114, 44416, 0, 0 mbuf_jumbo_page: 4096, 12800, 64, 844,15283577, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 4656,14723849, 0, 0 ttyinq: 160, 0, 645, 435, 10245, 0, 0 ttyoutq: 256, 0, 328, 272, 5302, 0, 0 ata_request: 328, 0, 0, 0, 0, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 125168, 4104,32660888, 0, 0 VNODEPOLL: 112, 0, 25, 569, 1565, 0, 0 NAMEI: 1024, 0, 1, 307,94416609, 0, 0 S VFS Cache: 108, 0, 105256, 29780,38217566, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 22612, 2828, 2000298, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 6141, 663, 284665, 0, 0 pipe: 728, 0, 29, 311, 245495, 0, 0 Mountpoints: 824, 0, 4, 24, 14, 0, 0 ksiginfo: 112, 0, 393, 795, 2188986, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 5, 865, 5054045, 0, 0 socket: 680, 25602, 90, 11538, 186736, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 6, 354, 56934, 0, 0 udpcb: 16, 25704, 6, 666, 56934, 0, 0 tcp_inpcb: 392, 25600, 11, 11409, 101389, 0, 0 tcpcb: 976, 25600, 11, 11461, 101389, 0, 0 tcptw: 72, 5150, 0, 800, 32459, 0, 0 syncache: 152, 15375, 0, 75, 22, 0, 0 hostcache: 136, 15372, 67, 409, 4158, 0, 0 tcpreass: 40, 1680, 0, 1428, 1136852, 0, 0 sackhole: 32, 0, 0, 505, 5465, 0, 0 ripcb: 392, 25600, 0, 50, 14, 0, 0 unpcb: 240, 25600, 71, 201, 28395, 0, 0 rtentry: 200, 0, 4, 53, 4, 0, 0 selfd: 56, 0, 790, 659,3304956513, 0, 0 SWAPMETA: 288, 490776, 2783, 36867, 51936, 0, 0 FFS inode: 168, 0, 125100, 4326,31251523, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 125100, 4170,31251427, 0, 0 TMPFS dirent: 40, 0, 2555, 8701, 435573, 0, 0 TMPFS node: 224, 0, 2556, 3513, 435424, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 220307 3102 irq9: acpi0 3367331 47427 irq12: psm0 158409 2231 irq16: ehci0 sdhci0 2568798 36180 irq23: ehci1 3726256 52482 cpu0:timer 142230299 2003243 irq264: em0 13538167 190678 irq265: hdac0 4881099 68747 irq267: ahci0 4803378 67653 cpu1:timer 115804420 1631048 cpu2:timer 114957771 1619123 cpu3:timer 113826258 1603186 irq268: vgapci0 6769979 95351 Total 526852472 7420457 ------------------------------------------------------------------------ pstat -T 283/12328 files 55M/5212M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0b 10675968 114680 10561288 1% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 da0 pass0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 21.61 67112 1416.30 17.63 1 0.02 0.00 0 0.00 2 0 1 0 97 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 51314690 0 --rw------- asn asn asn asn 2 393216 22194 999 17:02:33 12:58:12 17:02:33 m 88408067 0 --rw------- asn asn asn asn 2 393216 20023 999 20:05:33 no-entry 20:05:33 m 32047108 0 --rw------- asn asn asn asn 2 393216 22194 999 17:02:33 12:58:12 17:02:33 m 589829 0 --rw------- asn asn asn asn 2 393216 1160 999 12:40:15 no-entry 12:40:15 m 101974026 0 --rw------- asn asn asn asn 2 393216 20023 999 12:36:36 13:58:25 12:36:36 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 1953729362 --rw------- asn asn asn asn 1 19:35:33 13:40:27 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: new client/server not loaded ------------------------------------------------------------------------ netstat -s tcp: 7331252 packets sent 462986 data packets (517756450 bytes) 775 data packets (920500 bytes) retransmitted 59 data packets unnecessarily retransmitted 246 resends initiated by MTU discovery 4776871 ack-only packets (197337 delayed) 0 URG only packets 0 window probe packets 1932788 window update packets 157837 control packets 10239936 packets received 660399 acks (for 517653138 bytes) 66449 duplicate acks 0 acks for unsent data 8628568 packets (9991083379 bytes) received in-sequence 11637 completely duplicate packets (14275306 bytes) 49 old duplicate packets 684 packets with some dup. data (460448 bytes duped) 1136581 out-of-order packets (1635406327 bytes) 24 packets (24 bytes) of data after window 24 window probes 24649 window update packets 2001 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 496 discarded due to memory problems 79198 connection requests 22 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 79118 connections established (including accepts) 101378 connections closed (including 1512 drops) 31187 connections updated cached RTT on close 31282 connections updated cached RTT variance on close 5503 connections updated cached ssthresh on close 57 embryonic connections dropped 659042 segments updated rtt (of 565000 attempts) 6559 retransmit timeouts 457 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 110 keepalive timeouts 74 keepalive probes sent 36 connections dropped by keepalive 109175 correct ACK header predictions 8308132 correct data packet header predictions 22 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 22 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 22 cookies sent 0 cookies received 4158 hostcache entries added 0 bucket overflow 219 SACK recovery episodes 193 segment rexmits in SACK recovery episodes 270237 byte rexmits in SACK recovery episodes 7577 SACK options (SACK blocks) received 1061878 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 103095 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 54 dropped due to no socket 52921 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 50120 delivered 49934 datagrams output 0 times multicast source filter matched ip: 10349371 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 10343977 packets for this host 5394 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 7388765 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 54 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: destination unreachable: 54 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 946 destination unreachable: 5394 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 78 ARP requests sent 1514 ARP replies sent 199021 ARP requests received 77 ARP replies received 199098 ARP packets received 0 total packets dropped due to no ARP entry 596 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m 1089/2722/3811 mbufs in use (current/cache/total) 512/2522/3034/25600 mbuf clusters in use (current/cache/total/max) 1023/1408 mbuf+clusters out of packet secondary zone in use (current/cache) 64/844/908/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 1552K/9100K/10652K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 f0:de:f1:af:75:cc 10964771 0 0 7390153 0 0 0 em0 1500 81.19.64.96/2 t61 10322587 - - 7522096 - - - usbus 0 0 0 0 0 0 0 0 iwn0 2290 74:e5:0b:86:58:ec 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 625 0 0 625 0 0 0 lo0 16384 your-net localhost 607 - - 625 - - - wlan0 1500 74:e5:0b:86:58:ec 0 0 0 0 0 0 0 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 81.19.64.97 UGS 0 7322207 em0 81.19.64.96/27 link#1 U 0 66353 em0 81.19.64.106 link#1 UHS 0 18 lo0 127.0.0.1 link#5 UH 0 607 lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe0082e1c3d0 tcp4 0 0 81.19.64.106.28532 81.19.64.114.22 ESTABLISHED fffffe0082e1ab70 tcp4 0 0 81.19.64.106.49836 64.12.68.227.443 ESTABLISHED fffffe00d04943d0 tcp4 0 0 81.19.64.106.10405 64.12.30.45.443 ESTABLISHED fffffe0062ea0000 tcp4 0 0 81.19.64.106.19039 64.12.30.80.443 ESTABLISHED fffffe003c6f4000 tcp4 0 0 81.19.64.106.30765 77.88.57.178.5222 ESTABLISHED fffffe00601f4b70 tcp4 0 0 81.19.64.106.62166 173.194.69.125.522 ESTABLISHED fffffe00076fe7a0 tcp4 0 0 81.19.64.106.23510 173.194.71.18.443 ESTABLISHED fffffe0007bc0000 tcp4 0 0 81.19.64.106.24947 81.19.64.116.22 ESTABLISHED fffffe0007bc03d0 tcp4 0 0 *.6000 *.* LISTEN fffffe00077d13d0 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe00076d9b70 tcp4 0 0 *.22 *.* LISTEN fffffe0015043188 udp4 0 0 *.61498 *.* fffffe0007239930 udp4 0 0 127.0.0.1.123 *.* fffffe0007239ab8 udp4 0 0 81.19.64.106.123 *.* fffffe0007239c40 udp4 0 0 *.123 *.* fffffe0007259000 udp4 0 0 *.514 *.* fffffe0007259ab8 udp4 0 0 *.* *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe003c7fad20 stream 0 0 0 fffffe00bc2abc30 0 0 /tmp/.X11-unix/X0 fffffe00bc2abc30 stream 0 0 0 fffffe003c7fad20 0 0 fffffe00522bf1e0 stream 0 0 0 fffffe00522bf4b0 0 0 /tmp/.X11-unix/X0 fffffe00522bf4b0 stream 0 0 0 fffffe00522bf1e0 0 0 fffffe00707cfb40 stream 0 0 0 fffffe00bc2ab1e0 0 0 /tmp/.X11-unix/X0 fffffe00bc2ab1e0 stream 0 0 0 fffffe00707cfb40 0 0 fffffe003c986c30 stream 0 0 fffffe006fe693f0 0 0 0 /tmp/tmux-1001/default fffffe003c987960 stream 0 0 0 fffffe003c7fab40 0 0 fffffe003c7fab40 stream 0 0 0 fffffe003c987960 0 0 fffffe00d06a53c0 stream 0 0 0 fffffe00074f0780 0 0 /tmp/.X11-unix/X0 fffffe00074f0780 stream 0 0 0 fffffe00d06a53c0 0 0 fffffe000751bc30 stream 0 0 0 fffffe0007e48960 0 0 /tmp/dbus-KI6qVoE7tW fffffe0007e48960 stream 0 0 0 fffffe000751bc30 0 0 fffffe00522bf000 stream 0 0 0 fffffe00d06a54b0 0 0 /tmp/.X11-unix/X0 fffffe00d06a54b0 stream 0 0 0 fffffe00522bf000 0 0 fffffe00522bfd20 stream 0 0 0 fffffe011d6ad3c0 0 0 fffffe011d6ad3c0 stream 0 0 0 fffffe00522bfd20 0 0 fffffe011d6ad1e0 stream 0 0 0 fffffe011d6ad2d0 0 0 /tmp/fam-asn/fam- fffffe011d6ad2d0 stream 0 0 0 fffffe011d6ad1e0 0 0 fffffe00074f0000 stream 0 0 fffffe000931adc8 0 0 0 /tmp/fam-asn/fam- fffffe0007e482d0 stream 0 0 0 fffffe00707cf3c0 0 0 /tmp/.X11-unix/X0 fffffe00707cf3c0 stream 0 0 0 fffffe0007e482d0 0 0 fffffe00d06a41e0 stream 0 0 0 fffffe00522be2d0 0 0 /tmp/.X11-unix/X0 fffffe00522be2d0 stream 0 0 0 fffffe00d06a41e0 0 0 fffffe000753bb40 stream 0 0 0 fffffe00d06a5780 0 0 /tmp/.X11-unix/X0 fffffe00d06a5780 stream 0 0 0 fffffe000753bb40 0 0 fffffe000751a2d0 stream 0 0 fffffe00d0bbe3f0 0 0 0 /tmp/xmms_asn.0 fffffe000716ae10 stream 0 0 0 fffffe000751b000 0 0 /tmp/.X11-unix/X0 fffffe000751b000 stream 0 0 0 fffffe000716ae10 0 0 fffffe00074f0a50 stream 0 0 0 fffffe00074f0b40 0 0 /tmp/.X11-unix/X0 fffffe00074f0b40 stream 0 0 0 fffffe00074f0a50 0 0 fffffe000751a4b0 stream 0 0 0 fffffe000751a5a0 0 0 /tmp/.X11-unix/X0 fffffe000751a5a0 stream 0 0 0 fffffe000751a4b0 0 0 fffffe000751a690 stream 0 0 0 fffffe000751a780 0 0 fffffe000751a780 stream 0 0 0 fffffe000751a690 0 0 fffffe0007e48a50 stream 0 0 fffffe0007c69dc8 0 0 0 /tmp/dbus-KI6qVoE7tW fffffe0007e48b40 stream 0 0 0 fffffe0007e48c30 0 0 /tmp/.X11-unix/X0 fffffe0007e48c30 stream 128 0 0 fffffe0007e48b40 0 0 fffffe0007e48d20 stream 0 0 0 fffffe000716a3c0 0 0 /tmp/.X11-unix/X0 fffffe000716a3c0 stream 0 0 0 fffffe0007e48d20 0 0 fffffe000751b4b0 stream 0 0 0 fffffe000753b5a0 0 0 /tmp/.X11-unix/X0 fffffe000753b5a0 stream 0 0 0 fffffe000751b4b0 0 0 fffffe000753b690 stream 0 0 0 fffffe000753b780 0 0 /tmp/.X11-unix/X0 fffffe000753b780 stream 0 0 0 fffffe000753b690 0 0 fffffe000753b870 stream 0 0 0 fffffe000753b960 0 0 /tmp/.X11-unix/X0 fffffe000753b960 stream 0 0 0 fffffe000753b870 0 0 fffffe000751b870 stream 0 0 0 fffffe000751b780 0 0 /tmp/.X11-unix/X0 fffffe000751b780 stream 0 0 0 fffffe000751b870 0 0 fffffe000751b5a0 stream 0 0 0 fffffe000751b0f0 0 0 /tmp/.X11-unix/X0 fffffe000751b0f0 stream 0 0 0 fffffe000751b5a0 0 0 fffffe000753bc30 stream 0 0 0 fffffe000753bd20 0 0 /tmp/.X11-unix/X0 fffffe000753bd20 stream 0 0 0 fffffe000753bc30 0 0 fffffe000753be10 stream 0 0 0 fffffe000716a000 0 0 /tmp/.X11-unix/X0 fffffe000716a000 stream 0 0 0 fffffe000753be10 0 0 fffffe000751b1e0 stream 0 0 0 fffffe000751b2d0 0 0 /tmp/.X11-unix/X0 fffffe000751b2d0 stream 0 0 0 fffffe000751b1e0 0 0 fffffe000716a0f0 stream 0 0 fffffe0007bc75e8 0 0 0 /tmp/.X11-unix/X0 fffffe000716a1e0 stream 0 0 fffffe00078f53f0 0 0 0 /tmp/ssh-xvKBYiKoKku8/agent.974 fffffe000716a4b0 stream 0 0 0 fffffe000716a5a0 0 0 /var/run/devd.pipe fffffe000716a5a0 stream 0 0 0 fffffe000716a4b0 0 0 fffffe000716a870 stream 0 0 fffffe0007534dc8 0 0 0 /var/run/devd.pipe fffffe00522be5a0 dgram 0 0 0 0 0 0 fffffe000751ba50 dgram 0 0 0 0 0 0 fffffe00522bf5a0 dgram 0 0 0 0 0 0 fffffe00074f0c30 dgram 0 0 0 fffffe000751aa50 0 0 fffffe00074f0d20 dgram 0 0 0 fffffe000751a960 0 fffffe000716a690 fffffe000716a690 dgram 0 0 0 fffffe000751a960 0 fffffe000716a780 fffffe000716a780 dgram 0 0 0 fffffe000751a960 0 0 fffffe000751a960 dgram 0 0 fffffe00076945e8 0 fffffe00074f0d20 0 /var/run/logpriv fffffe000751aa50 dgram 0 0 fffffe000718c7e0 0 fffffe00074f0c30 0 /var/run/log fffffe00074f00f0 dgram 0 0 fffffe00074f27e0 0 0 0 /var/run/wpa_supplicant/wlan0 ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.x11 tcp4 0/0/10 localhost.smtp tcp4 0/0/128 *.ssh unix 0/0/16 /tmp/tmux-1001/default unix 0/0/30 /tmp/fam-asn/fam- unix 0/0/100 /tmp/xmms_asn.0 unix 0/0/30 /tmp/dbus-KI6qVoE7tW unix 0/0/128 /tmp/.X11-unix/X0 unix 0/0/128 /tmp/ssh-xvKBYiKoKku8/agent.974 unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root ssh-keygen 83843 root / 2 drwxr-xr-x 1024 r root ssh-keygen 83843 wd - - ?(fuse) - root ssh-keygen 83843 text / 24493082 -r-xr-xr-x 49056 r root ssh-keygen 83843 ctty /dev 132 crw--w---- pts/8 rw root ssh-keygen 83843 0 /dev 132 crw--w---- pts/8 rw root ssh-keygen 83843 1 /dev 132 crw--w---- pts/8 rw root ssh-keygen 83843 2 /dev 132 crw--w---- pts/8 rw root mount.exfat-fuse 83835 root / 2 drwxr-xr-x 1024 r root mount.exfat-fuse 83835 wd / 2 drwxr-xr-x 1024 r root mount.exfat-fuse 83835 text / 25544206 -r-xr-xr-x 41880 r root mount.exfat-fuse 83835 0 /dev 23 crw-rw-rw- null rw root mount.exfat-fuse 83835 1 /dev 23 crw-rw-rw- null rw root mount.exfat-fuse 83835 2 /dev 23 crw-rw-rw- null rw root mount.exfat-fuse 83835 3 /dev 137 crw-r----- da0 rw root mount.exfat-fuse 83835 4 /dev 139 crw-rw---- fuse0 rw root bash 83829 root / 2 drwxr-xr-x 1024 r root bash 83829 wd - - ?(fuse) - root bash 83829 text / 25526649 -rwxr-xr-x 802864 r root bash 83829 ctty /dev 132 crw--w---- pts/8 rw root bash 83829 0 /dev 132 crw--w---- pts/8 rw root bash 83829 1 /dev 132 crw--w---- pts/8 rw root bash 83829 2 /dev 132 crw--w---- pts/8 rw root bash 83829 255 /dev 132 crw--w---- pts/8 rw root sudo 83828 root / 2 drwxr-xr-x 1024 r root sudo 83828 wd / 24558674 drwxr-xr-x 3072 r root sudo 83828 text / 25546205 -rwsr-xr-x 107048 r root sudo 83828 ctty /dev 132 crw--w---- pts/8 rw root sudo 83828 0 /dev 132 crw--w---- pts/8 rw root sudo 83828 1 /dev 132 crw--w---- pts/8 rw root sudo 83828 2 /dev 132 crw--w---- pts/8 rw root sudo 83828 3* local dgram fffffe00522be5a0 root sudo 83828 5* pipe fffffe00607592d8 <-> fffffe0060759430 0 rw root sudo 83828 6* pipe fffffe0060759430 <-> fffffe00607592d8 0 rw asn bash 83826 root / 2 drwxr-xr-x 1024 r asn bash 83826 wd / 24558674 drwxr-xr-x 3072 r asn bash 83826 text / 25526649 -rwxr-xr-x 802864 r asn bash 83826 ctty /dev 132 crw--w---- pts/8 rw asn bash 83826 0 /dev 132 crw--w---- pts/8 rw asn bash 83826 1 /dev 132 crw--w---- pts/8 rw asn bash 83826 2 /dev 132 crw--w---- pts/8 rw asn bash 83826 255 /dev 132 crw--w---- pts/8 rw asn xterm 83824 root / 2 drwxr-xr-x 1024 r asn xterm 83824 wd / 24558674 drwxr-xr-x 3072 r asn xterm 83824 text / 25545376 -r-xr-xr-x 491992 r asn xterm 83824 0 /dev 23 crw-rw-rw- null r asn xterm 83824 1 / 24558368 -rw------- 914238 rw asn xterm 83824 2 / 24558368 -rw------- 914238 rw asn xterm 83824 3* local stream fffffe00bc2abc30 <-> fffffe003c7fad20 asn xterm 83824 4* pseudo-terminal master pts/8 rw asn ssh 83761 root / 2 drwxr-xr-x 1024 r asn ssh 83761 wd / 24558674 drwxr-xr-x 3072 r asn ssh 83761 text / 24493072 -r-xr-xr-x 157928 r asn ssh 83761 ctty /dev 129 crw--w---- pts/5 rw asn ssh 83761 0 /dev 129 crw--w---- pts/5 rw asn ssh 83761 1 /dev 129 crw--w---- pts/5 rw asn ssh 83761 2 /dev 129 crw--w---- pts/5 rw asn ssh 83761 3* internet stream tcp fffffe0082e1c3d0 asn ssh 83761 4 /dev 129 crw--w---- pts/5 rw asn ssh 83761 5 /dev 129 crw--w---- pts/5 rw asn ssh 83761 6 /dev 129 crw--w---- pts/5 rw root bash 78302 root / 2 drwxr-xr-x 1024 r root bash 78302 wd / 24558674 drwxr-xr-x 3072 r root bash 78302 text / 25526649 -rwxr-xr-x 802864 r root bash 78302 ctty /dev 130 crw--w---- pts/3 rw root bash 78302 0 /dev 130 crw--w---- pts/3 rw root bash 78302 1 /dev 130 crw--w---- pts/3 rw root bash 78302 2 /dev 130 crw--w---- pts/3 rw root bash 78302 255 /dev 130 crw--w---- pts/3 rw root sudo 78301 root / 2 drwxr-xr-x 1024 r root sudo 78301 wd / 24558674 drwxr-xr-x 3072 r root sudo 78301 text / 25546205 -rwsr-xr-x 107048 r root sudo 78301 ctty /dev 130 crw--w---- pts/3 rw root sudo 78301 0 /dev 130 crw--w---- pts/3 rw root sudo 78301 1 /dev 130 crw--w---- pts/3 rw root sudo 78301 2 /dev 130 crw--w---- pts/3 rw root sudo 78301 3* local dgram fffffe000751ba50 root sudo 78301 5* pipe fffffe009b90a000 <-> fffffe009b90a158 0 rw root sudo 78301 6* pipe fffffe009b90a158 <-> fffffe009b90a000 0 rw asn bash 78299 root / 2 drwxr-xr-x 1024 r asn bash 78299 wd / 24558674 drwxr-xr-x 3072 r asn bash 78299 text / 25526649 -rwxr-xr-x 802864 r asn bash 78299 ctty /dev 130 crw--w---- pts/3 rw asn bash 78299 0 /dev 130 crw--w---- pts/3 rw asn bash 78299 1 /dev 130 crw--w---- pts/3 rw asn bash 78299 2 /dev 130 crw--w---- pts/3 rw asn bash 78299 255 /dev 130 crw--w---- pts/3 rw asn xterm 78297 root / 2 drwxr-xr-x 1024 r asn xterm 78297 wd / 24558674 drwxr-xr-x 3072 r asn xterm 78297 text / 25545376 -r-xr-xr-x 491992 r asn xterm 78297 0 /dev 23 crw-rw-rw- null r asn xterm 78297 1 / 24558368 -rw------- 914238 rw asn xterm 78297 2 / 24558368 -rw------- 914238 rw asn xterm 78297 3* local stream fffffe00522bf4b0 <-> fffffe00522bf1e0 asn xterm 78297 4* pseudo-terminal master pts/3 rw asn bash 73830 root / 2 drwxr-xr-x 1024 r asn bash 73830 wd / 24558674 drwxr-xr-x 3072 r asn bash 73830 text / 25526649 -rwxr-xr-x 802864 r asn bash 73830 ctty /dev 125 crw--w---- pts/1 rw asn bash 73830 0 /dev 125 crw--w---- pts/1 rw asn bash 73830 1 /dev 125 crw--w---- pts/1 rw asn bash 73830 2 /dev 125 crw--w---- pts/1 rw asn bash 73830 255 /dev 125 crw--w---- pts/1 rw asn xterm 73828 root / 2 drwxr-xr-x 1024 r asn xterm 73828 wd / 24558674 drwxr-xr-x 3072 r asn xterm 73828 text / 25545376 -r-xr-xr-x 491992 r asn xterm 73828 0 /dev 23 crw-rw-rw- null r asn xterm 73828 1 / 24558368 -rw------- 914238 rw asn xterm 73828 2 / 24558368 -rw------- 914238 rw asn xterm 73828 3* local stream fffffe00bc2ab1e0 <-> fffffe00707cfb40 asn xterm 73828 4* pseudo-terminal master pts/1 rw root bash 27829 root / 2 drwxr-xr-x 1024 r root bash 27829 wd / 24558674 drwxr-xr-x 3072 r root bash 27829 text / 25526649 -rwxr-xr-x 802864 r root bash 27829 ctty /dev 131 crw--w---- pts/7 rw root bash 27829 0 /dev 131 crw--w---- pts/7 rw root bash 27829 1 /dev 131 crw--w---- pts/7 rw root bash 27829 2 /dev 131 crw--w---- pts/7 rw root bash 27829 255 /dev 131 crw--w---- pts/7 rw root sudo 27828 root / 2 drwxr-xr-x 1024 r root sudo 27828 wd / 24558674 drwxr-xr-x 3072 r root sudo 27828 text / 25546205 -rwsr-xr-x 107048 r root sudo 27828 ctty /dev 131 crw--w---- pts/7 rw root sudo 27828 0 /dev 131 crw--w---- pts/7 rw root sudo 27828 1 /dev 131 crw--w---- pts/7 rw root sudo 27828 2 /dev 131 crw--w---- pts/7 rw root sudo 27828 3* local dgram fffffe00522bf5a0 root sudo 27828 5* pipe fffffe0007de42d8 <-> fffffe0007de4430 0 rw root sudo 27828 6* pipe fffffe0007de4430 <-> fffffe0007de42d8 0 rw asn bash 27826 root / 2 drwxr-xr-x 1024 r asn bash 27826 wd / 24558674 drwxr-xr-x 3072 r asn bash 27826 text / 25526649 -rwxr-xr-x 802864 r asn bash 27826 ctty /dev 131 crw--w---- pts/7 rw asn bash 27826 0 /dev 131 crw--w---- pts/7 rw asn bash 27826 1 /dev 131 crw--w---- pts/7 rw asn bash 27826 2 /dev 131 crw--w---- pts/7 rw asn bash 27826 255 /dev 131 crw--w---- pts/7 rw asn tmux 27825 root / 2 drwxr-xr-x 1024 r asn tmux 27825 wd / 24558674 drwxr-xr-x 3072 r asn tmux 27825 text / 25526799 -r-xr-xr-x 368504 r asn tmux 27825 0 /dev 23 crw-rw-rw- null rw asn tmux 27825 1 /dev 23 crw-rw-rw- null rw asn tmux 27825 2 /dev 23 crw-rw-rw- null rw asn tmux 27825 3* local stream fffffe003c7fab40 <-> fffffe003c987960 asn tmux 27825 4* local stream fffffe003c987960 <-> fffffe003c7fab40 asn tmux 27825 6* local stream fffffe003c986c30 asn tmux 27825 8* pseudo-terminal master pts/7 rw asn bash 25270 root / 2 drwxr-xr-x 1024 r asn bash 25270 wd / 27447567 drwxr-xr-x 512 r asn bash 25270 text / 25526649 -rwxr-xr-x 802864 r asn bash 25270 ctty /dev 127 crw--w---- pts/6 rw asn bash 25270 0 /dev 127 crw--w---- pts/6 rw asn bash 25270 1 /dev 127 crw--w---- pts/6 rw asn bash 25270 2 /dev 127 crw--w---- pts/6 rw asn bash 25270 7* pipe fffffe002b342cb8 <-> fffffe002b342b60 0 rw asn bash 25270 255 /dev 127 crw--w---- pts/6 rw asn mc 25269 root / 2 drwxr-xr-x 1024 r asn mc 25269 wd / 27447567 drwxr-xr-x 512 r asn mc 25269 text / 25528116 -r-xr-xr-x 826744 r asn mc 25269 ctty /dev 126 crw--w---- pts/2 rw asn mc 25269 0 /dev 126 crw--w---- pts/2 rw asn mc 25269 1 /dev 126 crw--w---- pts/2 rw asn mc 25269 2 /dev 126 crw--w---- pts/2 rw asn mc 25269 3 /dev 126 crw--w---- pts/2 rw asn mc 25269 4* pseudo-terminal master pts/6 rw asn mc 25269 5 /dev 127 crw--w---- pts/6 rw asn mc 25269 6* pipe fffffe002b342b60 <-> fffffe002b342cb8 0 rw asn mc 25269 7* pipe fffffe002b342cb8 <-> fffffe002b342b60 0 rw asn bash 25138 root / 2 drwxr-xr-x 1024 r asn bash 25138 wd / 27608836 drwxr-xr-x 3584 r asn bash 25138 text / 25526649 -rwxr-xr-x 802864 r asn bash 25138 ctty /dev 126 crw--w---- pts/2 rw asn bash 25138 0 /dev 126 crw--w---- pts/2 rw asn bash 25138 1 /dev 126 crw--w---- pts/2 rw asn bash 25138 2 /dev 126 crw--w---- pts/2 rw asn bash 25138 255 /dev 126 crw--w---- pts/2 rw asn xterm 25136 root / 2 drwxr-xr-x 1024 r asn xterm 25136 wd / 24558674 drwxr-xr-x 3072 r asn xterm 25136 text / 25545376 -r-xr-xr-x 491992 r asn xterm 25136 0 /dev 23 crw-rw-rw- null r asn xterm 25136 1 / 24558368 -rw------- 914238 rw asn xterm 25136 2 / 24558368 -rw------- 914238 rw asn xterm 25136 3* local stream fffffe00074f0780 <-> fffffe00d06a53c0 asn xterm 25136 4* pseudo-terminal master pts/2 rw asn pidgin 22194 root / 2 drwxr-xr-x 1024 r asn pidgin 22194 wd / 24558674 drwxr-xr-x 3072 r asn pidgin 22194 text / 25530438 -r-xr-xr-x 938952 r asn pidgin 22194 0 /dev 23 crw-rw-rw- null r asn pidgin 22194 1 / 24558368 -rw------- 914238 rw asn pidgin 22194 2 / 24558368 -rw------- 914238 rw asn pidgin 22194 3* local stream fffffe011d6ad3c0 <-> fffffe00522bfd20 asn pidgin 22194 4* local stream fffffe00522bfd20 <-> fffffe011d6ad3c0 asn pidgin 22194 5* pipe fffffe003c5405b0 <-> fffffe003c540708 0 rw asn pidgin 22194 6* pipe fffffe003c540708 <-> fffffe003c5405b0 0 rw asn pidgin 22194 7* local stream fffffe00d06a54b0 <-> fffffe00522bf000 asn pidgin 22194 8* local stream fffffe0007e48960 <-> fffffe000751bc30 asn pidgin 22194 9* pipe fffffe002b344b60 <-> fffffe002b344cb8 0 rw asn pidgin 22194 10* internet dgram udp fffffe0015043188 asn pidgin 22194 11* pipe fffffe003c19bb60 <-> fffffe003c19bcb8 0 rw asn pidgin 22194 12* pipe fffffe011af5e5b0 <-> fffffe011af5e708 0 rw asn pidgin 22194 13* pipe fffffe003c5409e0 <-> fffffe003c540888 0 rw asn pidgin 22194 14* internet stream tcp fffffe00601f4b70 asn pidgin 22194 15* pipe fffffe00aa2d0158 <-> fffffe00aa2d0000 0 rw asn pidgin 22194 16* internet stream tcp fffffe003c6f4000 asn pidgin 22194 17* pipe fffffe003c9c9cb8 <-> fffffe003c9c9b60 0 rw asn pidgin 22194 18* internet stream tcp fffffe0062ea0000 asn pidgin 22194 19* internet stream tcp fffffe00d04943d0 asn pidgin 22194 21* internet stream tcp fffffe0082e1ab70 root moused 21582 root / 2 drwxr-xr-x 1024 r root moused 21582 wd / 2 drwxr-xr-x 1024 r root moused 21582 text / 24487651 -r-xr-xr-x 38112 r root moused 21582 0 /dev 23 crw-rw-rw- null rw root moused 21582 1 /dev 23 crw-rw-rw- null rw root moused 21582 2 /dev 23 crw-rw-rw- null rw root moused 21582 3 /dev 98 crw-r--r-- ums0 rw root moused 21582 4 /dev 59 crw------- consolectl rw root moused 21582 5 / 31861779 -rw------- 5 w asn gam_server 20462 root / 2 drwxr-xr-x 1024 r asn gam_server 20462 wd / 24558674 drwxr-xr-x 3072 r asn gam_server 20462 text / 25527934 -r-xr-xr-x 74560 r asn gam_server 20462 0 /dev 23 crw-rw-rw- null r asn gam_server 20462 1 /dev 23 crw-rw-rw- null w asn gam_server 20462 2 /dev 23 crw-rw-rw- null w asn gam_server 20462 4* local stream fffffe00074f0000 asn gam_server 20462 5* pipe fffffe00ad8f9000 <-> fffffe00ad8f9158 0 rw asn gam_server 20462 6* pipe fffffe00ad8f9158 <-> fffffe00ad8f9000 0 rw asn gam_server 20462 7* local stream fffffe011d6ad1e0 <-> fffffe011d6ad2d0 asn gam_server 20462 8 / 25762329 -rw------- 55736 r asn firefox 20023 root / 2 drwxr-xr-x 1024 r asn firefox 20023 wd / 24558674 drwxr-xr-x 3072 r asn firefox 20023 text / 29535046 -rwxr-xr-x 185417 r asn firefox 20023 0 /dev 23 crw-rw-rw- null r asn firefox 20023 1 / 24558368 -rw------- 914238 rw asn firefox 20023 2 / 24558368 -rw------- 914238 rw asn firefox 20023 3 / 25764592 -rw-r--r-- 49152 rw asn firefox 20023 4* local stream fffffe00707cf3c0 <-> fffffe0007e482d0 asn firefox 20023 5* pipe fffffe003c19b2d8 <-> fffffe003c19b430 0 rw asn firefox 20023 6* pipe fffffe003c19b430 <-> fffffe003c19b2d8 0 rw asn firefox 20023 7 / 25764563 -rw-r--r-- 0 w asn firefox 20023 9* pipe fffffe0062fe1b60 <-> fffffe0062fe1cb8 0 rw asn firefox 20023 10* pipe fffffe0062fe1cb8 <-> fffffe0062fe1b60 0 rw asn firefox 20023 11* pipe fffffe003c540000 <-> fffffe003c540158 0 rw asn firefox 20023 12* pipe fffffe003c540158 <-> fffffe003c540000 0 rw asn firefox 20023 13* pipe fffffe00af530888 <-> fffffe00af5309e0 0 rw asn firefox 20023 14* pipe fffffe00af5309e0 <-> fffffe00af530888 0 rw asn firefox 20023 15 /dev 28 crw-rw-rw- random r asn firefox 20023 16 / 25764584 -rw-r--r-- 4096 rw asn firefox 20023 17 / 25764590 -rw-r--r-- 13312 rw asn firefox 20023 18 / 25764585 -rw-r--r-- 20971520 rw asn firefox 20023 19 / 25762352 -rw-r--r-- 420272 rw asn firefox 20023 20 / 25762356 -rw-r--r-- 32768 rw asn firefox 20023 21 / 25764570 -rw------- 344064 rw asn firefox 20023 22 / 25764571 -rw------- 16384 rw asn firefox 20023 23 / 25764555 -rw-r--r-- 458752 rw asn firefox 20023 24 / 25764577 -rw-r--r-- 2097152 rw asn firefox 20023 25 / 25762368 -rw-r--r-- 754248 rw asn firefox 20023 26 / 25762369 -rw-r--r-- 32768 rw asn firefox 20023 27 / 25764577 -rw-r--r-- 2097152 rw asn firefox 20023 28 / 25764568 -rw-r--r-- 524288 rw asn firefox 20023 29 / 25764596 -rw-r--r-- 97280 rw asn firefox 20023 30* local stream fffffe011d6ad2d0 <-> fffffe011d6ad1e0 asn firefox 20023 31 / 29374595 -rw------- 524564 rw asn firefox 20023 32 / 25764554 -rw------- 1 rw asn firefox 20023 33 / 29374622 -rw------- 10600314 rw asn firefox 20023 34 / 29374623 -rw------- 17039311 rw asn firefox 20023 35 / 29374624 -rw------- 33554841 rw asn firefox 20023 36* pipe fffffe000800f000 <-> fffffe000800f158 0 rw asn firefox 20023 37* internet stream tcp fffffe00076fe7a0 asn firefox 20023 38* pipe fffffe000800f158 <-> fffffe000800f000 0 rw asn firefox 20023 41 / 25762326 -rw-r--r-- 295496 rw asn firefox 20023 46 / 25764587 -rw-r--r-- 237568 rw asn firefox 20023 47 / 25764585 -rw-r--r-- 20971520 r asn firefox 20023 48 / 25762352 -rw-r--r-- 420272 rw asn firefox 20023 56 / 25764585 -rw-r--r-- 20971520 r asn firefox 20023 57 / 25762352 -rw-r--r-- 420272 rw asn firefox 20023 60 / 25764585 -rw-r--r-- 20971520 r asn firefox 20023 61 / 25762352 -rw-r--r-- 420272 rw asn firefox 20023 62 / 25764594 -rw-r--r-- 3514368 rw asn vi 50098 root / 2 drwxr-xr-x 1024 r asn vi 50098 wd / 17819052 drwxr-xr-x 512 r asn vi 50098 text / 24487141 -r-xr-xr-x 331992 r asn vi 50098 ctty /dev 128 crw--w---- pts/4 rw asn vi 50098 0 /dev 128 crw--w---- pts/4 rw asn vi 50098 1 /dev 128 crw--w---- pts/4 rw asn vi 50098 2 /dev 128 crw--w---- pts/4 rw asn vi 50098 3 / 24487143 -r--r--r-- 9976 r asn vi 50098 4 / 22391581 -rw------- 0 rw asn vi 50098 5 / 17819479 -rw-r--r-- 366 r asn vi 50098 6 / 31861763 -rwx------ 0 rw asn vi 50098 7 / 22391582 -rw------- 0 rw asn bash 80092 root / 2 drwxr-xr-x 1024 r asn bash 80092 wd / 24558674 drwxr-xr-x 3072 r asn bash 80092 text / 25526649 -rwxr-xr-x 802864 r asn bash 80092 ctty /dev 129 crw--w---- pts/5 rw asn bash 80092 0 /dev 129 crw--w---- pts/5 rw asn bash 80092 1 /dev 129 crw--w---- pts/5 rw asn bash 80092 2 /dev 129 crw--w---- pts/5 rw asn bash 80092 255 /dev 129 crw--w---- pts/5 rw asn xterm 80090 root / 2 drwxr-xr-x 1024 r asn xterm 80090 wd / 24558674 drwxr-xr-x 3072 r asn xterm 80090 text / 25545376 -r-xr-xr-x 491992 r asn xterm 80090 0 /dev 23 crw-rw-rw- null r asn xterm 80090 1 / 24558368 -rw------- 914238 rw asn xterm 80090 2 / 24558368 -rw------- 914238 rw asn xterm 80090 3* local stream fffffe00522be2d0 <-> fffffe00d06a41e0 asn xterm 80090 4* pseudo-terminal master pts/5 rw asn bash 74351 root / 2 drwxr-xr-x 1024 r asn bash 74351 wd / 17819052 drwxr-xr-x 512 r asn bash 74351 text / 25526649 -rwxr-xr-x 802864 r asn bash 74351 ctty /dev 128 crw--w---- pts/4 rw asn bash 74351 0 /dev 128 crw--w---- pts/4 rw asn bash 74351 1 /dev 128 crw--w---- pts/4 rw asn bash 74351 2 /dev 128 crw--w---- pts/4 rw asn bash 74351 255 /dev 128 crw--w---- pts/4 rw asn xterm 74349 root / 2 drwxr-xr-x 1024 r asn xterm 74349 wd / 24558674 drwxr-xr-x 3072 r asn xterm 74349 text / 25545376 -r-xr-xr-x 491992 r asn xterm 74349 0 /dev 23 crw-rw-rw- null r asn xterm 74349 1 / 24558368 -rw------- 914238 rw asn xterm 74349 2 / 24558368 -rw------- 914238 rw asn xterm 74349 3* local stream fffffe00d06a5780 <-> fffffe000753bb40 asn xterm 74349 4* pseudo-terminal master pts/4 rw asn xmms 1160 root / 2 drwxr-xr-x 1024 r asn xmms 1160 wd / 24558674 drwxr-xr-x 3072 r asn xmms 1160 text / 25533664 -r-xr-xr-x 997992 r asn xmms 1160 0 /dev 23 crw-rw-rw- null r asn xmms 1160 1 / 24558368 -rw------- 914238 rw asn xmms 1160 2 / 24558368 -rw------- 914238 rw asn xmms 1160 3* local stream fffffe000751b000 <-> fffffe000716ae10 asn xmms 1160 4* local stream fffffe000751a2d0 asn xmms 1160 5* pipe fffffe003c19b000 <-> fffffe003c19b158 0 rw asn xmms 1160 6* pipe fffffe003c19b158 <-> fffffe003c19b000 0 rw asn ssh 1051 root / 2 drwxr-xr-x 1024 r asn ssh 1051 wd / 24558674 drwxr-xr-x 3072 r asn ssh 1051 text / 24493072 -r-xr-xr-x 157928 r asn ssh 1051 ctty /dev 122 crw--w---- pts/0 rw asn ssh 1051 0 /dev 122 crw--w---- pts/0 rw asn ssh 1051 1 /dev 122 crw--w---- pts/0 rw asn ssh 1051 2 /dev 122 crw--w---- pts/0 rw asn ssh 1051 3* internet stream tcp fffffe0007bc0000 asn ssh 1051 4 /dev 122 crw--w---- pts/0 rw asn ssh 1051 5 /dev 122 crw--w---- pts/0 rw asn ssh 1051 6 /dev 122 crw--w---- pts/0 rw asn bash 1043 root / 2 drwxr-xr-x 1024 r asn bash 1043 wd / 24558674 drwxr-xr-x 3072 r asn bash 1043 text / 25526649 -rwxr-xr-x 802864 r asn bash 1043 ctty /dev 122 crw--w---- pts/0 rw asn bash 1043 0 /dev 122 crw--w---- pts/0 rw asn bash 1043 1 /dev 122 crw--w---- pts/0 rw asn bash 1043 2 /dev 122 crw--w---- pts/0 rw asn bash 1043 255 /dev 122 crw--w---- pts/0 rw asn xterm 1041 root / 2 drwxr-xr-x 1024 r asn xterm 1041 wd / 24558674 drwxr-xr-x 3072 r asn xterm 1041 text / 25545376 -r-xr-xr-x 491992 r asn xterm 1041 0 /dev 23 crw-rw-rw- null r asn xterm 1041 1 / 24558368 -rw------- 914238 rw asn xterm 1041 2 / 24558368 -rw------- 914238 rw asn xterm 1041 3* local stream fffffe00074f0b40 <-> fffffe00074f0a50 asn xterm 1041 4* pseudo-terminal master pts/0 rw asn dbus-daemon 1040 root / 2 drwxr-xr-x 1024 r asn dbus-daemon 1040 wd / 2 drwxr-xr-x 1024 r asn dbus-daemon 1040 text / 25529164 -r-xr-xr-x 377768 r asn dbus-daemon 1040 0 /dev 23 crw-rw-rw- null rw asn dbus-daemon 1040 1 /dev 23 crw-rw-rw- null rw asn dbus-daemon 1040 2 /dev 23 crw-rw-rw- null rw asn dbus-daemon 1040 3* local stream fffffe0007e48a50 asn dbus-daemon 1040 4 /dev 23 crw-rw-rw- null rw asn dbus-daemon 1040 6 / 24638750 drwxr-xr-x 512 r asn dbus-daemon 1040 7 / 25694737 drwxr-xr-x 512 r asn dbus-daemon 1040 8* local stream fffffe000751a780 <-> fffffe000751a690 asn dbus-daemon 1040 9* local stream fffffe000751a690 <-> fffffe000751a780 asn dbus-daemon 1040 10* local stream fffffe000751bc30 <-> fffffe0007e48960 asn dbus-launch 1039 root / 2 drwxr-xr-x 1024 r asn dbus-launch 1039 wd / 2 drwxr-xr-x 1024 r asn dbus-launch 1039 text / 25529168 -r-xr-xr-x 25560 r asn dbus-launch 1039 0 /dev 23 crw-rw-rw- null rw asn dbus-launch 1039 1 /dev 23 crw-rw-rw- null rw asn dbus-launch 1039 2 /dev 23 crw-rw-rw- null rw asn dbus-launch 1039 3* local stream fffffe0007e48c30 <-> fffffe0007e48b40 asn dbus-launch 1039 4 /dev 23 crw-rw-rw- null rw asn dbus-launch 1039 5* local stream fffffe000751a5a0 <-> fffffe000751a4b0 asn dbus-launch 1039 8* pipe fffffe00070bfb60 <-> fffffe00070bfcb8 0 rw root getty 1034 root / 2 drwxr-xr-x 1024 r root getty 1034 wd / 2 drwxr-xr-x 1024 r root getty 1034 text / 24491642 -r-xr-xr-x 27344 r root getty 1034 ctty /dev 43 crw------- ttyv0 rw root getty 1034 0 /dev 43 crw------- ttyv0 rw root getty 1034 1 /dev 43 crw------- ttyv0 rw root getty 1034 2 /dev 43 crw------- ttyv0 rw asn FvwmIconMan 1027 root / 2 drwxr-xr-x 1024 r asn FvwmIconMan 1027 wd / 24558674 drwxr-xr-x 3072 r asn FvwmIconMan 1027 text / 27126569 -r-xr-xr-x 296656 r asn FvwmIconMan 1027 0 /dev 23 crw-rw-rw- null r asn FvwmIconMan 1027 1 / 24558368 -rw------- 914238 rw asn FvwmIconMan 1027 2 / 24558368 -rw------- 914238 rw asn FvwmIconMan 1027 3* local stream fffffe000753b5a0 <-> fffffe000751b4b0 asn FvwmIconMan 1027 4* pipe fffffe000711e2d8 <-> fffffe000711e430 0 rw asn FvwmIconMan 1027 17* pipe fffffe000713e9e0 <-> fffffe000713e888 0 rw asn FvwmPager 1026 root / 2 drwxr-xr-x 1024 r asn FvwmPager 1026 wd / 24558674 drwxr-xr-x 3072 r asn FvwmPager 1026 text / 27126592 -r-xr-xr-x 267144 r asn FvwmPager 1026 0 /dev 23 crw-rw-rw- null r asn FvwmPager 1026 1 / 24558368 -rw------- 914238 rw asn FvwmPager 1026 2 / 24558368 -rw------- 914238 rw asn FvwmPager 1026 3* local stream fffffe000716a3c0 <-> fffffe0007e48d20 asn FvwmPager 1026 4* pipe fffffe000711e000 <-> fffffe000711e158 0 rw asn FvwmPager 1026 15* pipe fffffe00070b19e0 <-> fffffe00070b1888 0 rw asn FvwmScript 1025 root / 2 drwxr-xr-x 1024 r asn FvwmScript 1025 wd / 24558674 drwxr-xr-x 3072 r asn FvwmScript 1025 text / 27126637 -r-xr-xr-x 370008 r asn FvwmScript 1025 0 /dev 23 crw-rw-rw- null r asn FvwmScript 1025 1 / 24558368 -rw------- 914238 rw asn FvwmScript 1025 2 / 24558368 -rw------- 914238 rw asn FvwmScript 1025 3* local stream fffffe000753b780 <-> fffffe000753b690 asn FvwmScript 1025 4* pipe fffffe000713db60 <-> fffffe000713dcb8 0 rw asn FvwmScript 1025 13* pipe fffffe000713b9e0 <-> fffffe000713b888 0 rw asn FvwmAnimate 1022 root / 2 drwxr-xr-x 1024 r asn FvwmAnimate 1022 wd / 24558674 drwxr-xr-x 3072 r asn FvwmAnimate 1022 text / 27126565 -r-xr-xr-x 166184 r asn FvwmAnimate 1022 0 /dev 23 crw-rw-rw- null r asn FvwmAnimate 1022 1 / 24558368 -rw------- 914238 rw asn FvwmAnimate 1022 2 / 24558368 -rw------- 914238 rw asn FvwmAnimate 1022 3* local stream fffffe000751b780 <-> fffffe000751b870 asn FvwmAnimate 1022 4* pipe fffffe0007502888 <-> fffffe00075029e0 0 rw asn FvwmAnimate 1022 9* pipe fffffe00070b6430 <-> fffffe00070b62d8 0 rw asn FvwmButtons 1021 root / 2 drwxr-xr-x 1024 r asn FvwmButtons 1021 wd / 24558674 drwxr-xr-x 3072 r asn FvwmButtons 1021 text / 27126575 -r-xr-xr-x 296536 r asn FvwmButtons 1021 0 /dev 23 crw-rw-rw- null r asn FvwmButtons 1021 1 / 24558368 -rw------- 914238 rw asn FvwmButtons 1021 2 / 24558368 -rw------- 914238 rw asn FvwmButtons 1021 3* local stream fffffe000753b960 <-> fffffe000753b870 asn FvwmButtons 1021 4* pipe fffffe000713b5b0 <-> fffffe000713b708 0 rw asn FvwmButtons 1021 7* pipe fffffe000713d430 <-> fffffe000713d2d8 0 rw asn xacpim 1005 root / 2 drwxr-xr-x 1024 r asn xacpim 1005 wd / 24558674 drwxr-xr-x 3072 r asn xacpim 1005 text / 25530097 -r-xr-xr-x 12904 r asn xacpim 1005 0 /dev 23 crw-rw-rw- null r asn xacpim 1005 1 / 24558368 -rw------- 914238 rw asn xacpim 1005 2 / 24558368 -rw------- 914238 rw asn xacpim 1005 3 / 24558368 -rw------- 914238 rw asn xacpim 1005 4* local stream fffffe000716a000 <-> fffffe000753be10 asn xxkb 1003 root / 2 drwxr-xr-x 1024 r asn xxkb 1003 wd / 24558674 drwxr-xr-x 3072 r asn xxkb 1003 text / 25527378 -rwxr-xr-x 34280 r asn xxkb 1003 0 /dev 23 crw-rw-rw- null r asn xxkb 1003 1 / 24558368 -rw------- 914238 rw asn xxkb 1003 2 / 24558368 -rw------- 914238 rw asn xxkb 1003 3 / 24558368 -rw------- 914238 rw asn xxkb 1003 4* local stream fffffe000753bd20 <-> fffffe000753bc30 asn fvwm 1002 root / 2 drwxr-xr-x 1024 r asn fvwm 1002 wd / 24558674 drwxr-xr-x 3072 r asn fvwm 1002 text / 25530498 -r-xr-xr-x 826112 r asn fvwm 1002 0 /dev 23 crw-rw-rw- null r asn fvwm 1002 1 / 24558368 -rw------- 914238 rw asn fvwm 1002 2 / 24558368 -rw------- 914238 rw asn fvwm 1002 3* local stream fffffe000751b0f0 <-> fffffe000751b5a0 asn fvwm 1002 5* pipe fffffe000713b708 <-> fffffe000713b5b0 0 rw asn fvwm 1002 6* pipe fffffe000713d2d8 <-> fffffe000713d430 0 rw asn fvwm 1002 7* pipe fffffe00075029e0 <-> fffffe0007502888 0 rw asn fvwm 1002 8* pipe fffffe00070b62d8 <-> fffffe00070b6430 0 rw asn fvwm 1002 11* pipe fffffe000713dcb8 <-> fffffe000713db60 0 rw asn fvwm 1002 12* pipe fffffe000713b888 <-> fffffe000713b9e0 0 rw asn fvwm 1002 13* pipe fffffe000711e158 <-> fffffe000711e000 0 rw asn fvwm 1002 14* pipe fffffe00070b1888 <-> fffffe00070b19e0 0 rw asn fvwm 1002 15* pipe fffffe000711e430 <-> fffffe000711e2d8 0 rw asn fvwm 1002 16* pipe fffffe000713e888 <-> fffffe000713e9e0 0 rw root Xorg 999 root / 2 drwxr-xr-x 1024 r root Xorg 999 wd / 24558674 drwxr-xr-x 3072 r root Xorg 999 text / 25543947 -r-sr-xr-x 1915208 r root Xorg 999 0 / 31861753 -rw-r--r-- 35772 w root Xorg 999 1* internet stream tcp fffffe0007bc03d0 root Xorg 999 2 / 24558368 -rw------- 914238 rw root Xorg 999 3 / 24558368 -rw------- 914238 rw root Xorg 999 4* local stream fffffe000716a0f0 root Xorg 999 5 / 26644992 -r--r--r-- 31246 r root Xorg 999 6 /dev 26 crw-r--r-- pci rw root Xorg 999 7 /dev 19 crw-r----- mem rw root Xorg 999 8 /dev 51 crw------- ttyv8 rw root Xorg 999 9 /dev 25 crw------- io rw root Xorg 999 10 /dev 120 crw-rw---- dri/card0 rw root Xorg 999 11 /dev 15 crw------- sysmouse rw root Xorg 999 12* local stream fffffe000751b1e0 <-> fffffe000751b2d0 root Xorg 999 13* local stream fffffe000753be10 <-> fffffe000716a000 root Xorg 999 14* local stream fffffe000753bc30 <-> fffffe000753bd20 root Xorg 999 15* local stream fffffe000751b5a0 <-> fffffe000751b0f0 root Xorg 999 16* local stream fffffe000751b870 <-> fffffe000751b780 root Xorg 999 17* local stream fffffe00522bf000 <-> fffffe00d06a54b0 root Xorg 999 18* local stream fffffe000753b870 <-> fffffe000753b960 root Xorg 999 19* local stream fffffe000753b690 <-> fffffe000753b780 root Xorg 999 20* local stream fffffe000751b4b0 <-> fffffe000753b5a0 root Xorg 999 21* local stream fffffe0007e48d20 <-> fffffe000716a3c0 root Xorg 999 22* local stream fffffe0007e48b40 <-> fffffe0007e48c30 root Xorg 999 23* local stream fffffe000751a4b0 <-> fffffe000751a5a0 root Xorg 999 24* local stream fffffe00074f0a50 <-> fffffe00074f0b40 root Xorg 999 25* local stream fffffe0007e482d0 <-> fffffe00707cf3c0 root Xorg 999 26* local stream fffffe000753bb40 <-> fffffe00d06a5780 root Xorg 999 27* local stream fffffe00707cfb40 <-> fffffe00bc2ab1e0 root Xorg 999 28* local stream fffffe003c7fad20 <-> fffffe00bc2abc30 root Xorg 999 29* local stream fffffe000716ae10 <-> fffffe000751b000 root Xorg 999 32* local stream fffffe00d06a41e0 <-> fffffe00522be2d0 root Xorg 999 33* local stream fffffe00522bf1e0 <-> fffffe00522bf4b0 root Xorg 999 34* local stream fffffe00d06a53c0 <-> fffffe00074f0780 asn xinit 998 root / 2 drwxr-xr-x 1024 r asn xinit 998 wd / 24558674 drwxr-xr-x 3072 r asn xinit 998 text / 25529873 -r-xr-xr-x 15576 r asn xinit 998 0 /dev 23 crw-rw-rw- null r asn xinit 998 1 / 24558368 -rw------- 914238 rw asn xinit 998 2 / 24558368 -rw------- 914238 rw asn xinit 998 3 / 24558368 -rw------- 914238 rw asn xinit 998 4* local stream fffffe000751b2d0 <-> fffffe000751b1e0 asn sh 980 root / 2 drwxr-xr-x 1024 r asn sh 980 wd / 24558674 drwxr-xr-x 3072 r asn sh 980 text / 6661307 -r-xr-xr-x 137304 r asn sh 980 0 /dev 23 crw-rw-rw- null r asn sh 980 1 / 24558368 -rw------- 914238 rw asn sh 980 2 / 24558368 -rw------- 914238 rw asn sh 980 3 / 24558368 -rw------- 914238 rw asn sh 980 10 / 25529874 -r-xr-xr-x 5026 r asn ssh-agent 975 root / 2 drwxr-xr-x 1024 r asn ssh-agent 975 wd / 2 drwxr-xr-x 1024 r asn ssh-agent 975 text / 24493079 -r-xr-xr-x 32600 r asn ssh-agent 975 0 /dev 23 crw-rw-rw- null rw asn ssh-agent 975 1 /dev 23 crw-rw-rw- null rw asn ssh-agent 975 2 /dev 23 crw-rw-rw- null rw asn ssh-agent 975 3* local stream fffffe000716a1e0 root getty 957 root / 2 drwxr-xr-x 1024 r root getty 957 wd / 2 drwxr-xr-x 1024 r root getty 957 text / 24491642 -r-xr-xr-x 27344 r root getty 957 ctty /dev 50 crw------- ttyv7 rw root getty 957 0 /dev 50 crw------- ttyv7 rw root getty 957 1 /dev 50 crw------- ttyv7 rw root getty 957 2 /dev 50 crw------- ttyv7 rw root getty 956 root / 2 drwxr-xr-x 1024 r root getty 956 wd / 2 drwxr-xr-x 1024 r root getty 956 text / 24491642 -r-xr-xr-x 27344 r root getty 956 ctty /dev 49 crw------- ttyv6 rw root getty 956 0 /dev 49 crw------- ttyv6 rw root getty 956 1 /dev 49 crw------- ttyv6 rw root getty 956 2 /dev 49 crw------- ttyv6 rw root getty 955 root / 2 drwxr-xr-x 1024 r root getty 955 wd / 2 drwxr-xr-x 1024 r root getty 955 text / 24491642 -r-xr-xr-x 27344 r root getty 955 ctty /dev 48 crw------- ttyv5 rw root getty 955 0 /dev 48 crw------- ttyv5 rw root getty 955 1 /dev 48 crw------- ttyv5 rw root getty 955 2 /dev 48 crw------- ttyv5 rw root getty 954 root / 2 drwxr-xr-x 1024 r root getty 954 wd / 2 drwxr-xr-x 1024 r root getty 954 text / 24491642 -r-xr-xr-x 27344 r root getty 954 ctty /dev 47 crw------- ttyv4 rw root getty 954 0 /dev 47 crw------- ttyv4 rw root getty 954 1 /dev 47 crw------- ttyv4 rw root getty 954 2 /dev 47 crw------- ttyv4 rw root getty 953 root / 2 drwxr-xr-x 1024 r root getty 953 wd / 2 drwxr-xr-x 1024 r root getty 953 text / 24491642 -r-xr-xr-x 27344 r root getty 953 ctty /dev 46 crw------- ttyv3 rw root getty 953 0 /dev 46 crw------- ttyv3 rw root getty 953 1 /dev 46 crw------- ttyv3 rw root getty 953 2 /dev 46 crw------- ttyv3 rw root getty 952 root / 2 drwxr-xr-x 1024 r root getty 952 wd / 2 drwxr-xr-x 1024 r root getty 952 text / 24491642 -r-xr-xr-x 27344 r root getty 952 ctty /dev 45 crw------- ttyv2 rw root getty 952 0 /dev 45 crw------- ttyv2 rw root getty 952 1 /dev 45 crw------- ttyv2 rw root getty 952 2 /dev 45 crw------- ttyv2 rw root getty 951 root / 2 drwxr-xr-x 1024 r root getty 951 wd / 2 drwxr-xr-x 1024 r root getty 951 text / 24491642 -r-xr-xr-x 27344 r root getty 951 ctty /dev 44 crw------- ttyv1 rw root getty 951 0 /dev 44 crw------- ttyv1 rw root getty 951 1 /dev 44 crw------- ttyv1 rw root getty 951 2 /dev 44 crw------- ttyv1 rw root cron 904 root / 2 drwxr-xr-x 1024 r root cron 904 wd / 31861639 drwxr-x--- 512 r root cron 904 text / 24487333 -r-xr-xr-x 40920 r root cron 904 0 /dev 23 crw-rw-rw- null rw root cron 904 1 /dev 23 crw-rw-rw- null rw root cron 904 2 /dev 23 crw-rw-rw- null rw root cron 904 3 / 31861984 -rw------- 3 w smmsp sendmail 900 root / 2 drwxr-xr-x 1024 r smmsp sendmail 900 wd / 31861662 drwxrwx--- 512 r smmsp sendmail 900 text / 24482998 -r-xr-sr-x 676040 r smmsp sendmail 900 0 /dev 23 crw-rw-rw- null r smmsp sendmail 900 1 /dev 23 crw-rw-rw- null w smmsp sendmail 900 2 /dev 23 crw-rw-rw- null w smmsp sendmail 900 3* local dgram fffffe00074f0c30 <-> fffffe000751aa50 smmsp sendmail 900 4 / 31861979 -rw------- 49 w root sendmail 897 root / 2 drwxr-xr-x 1024 r root sendmail 897 wd / 31861659 drwxr-xr-x 512 r root sendmail 897 text / 24482998 -r-xr-sr-x 676040 r root sendmail 897 0 /dev 23 crw-rw-rw- null r root sendmail 897 1 /dev 23 crw-rw-rw- null w root sendmail 897 2 /dev 23 crw-rw-rw- null w root sendmail 897 3* local dgram fffffe00074f0d20 <-> fffffe000751a960 root sendmail 897 4* internet stream tcp fffffe00077d13d0 root sendmail 897 5 / 31861704 -rw------- 78 w root sshd 885 root / 2 drwxr-xr-x 1024 r root sshd 885 wd / 2 drwxr-xr-x 1024 r root sshd 885 text / 24493088 -r-xr-xr-x 271240 r root sshd 885 0 /dev 23 crw-rw-rw- null rw root sshd 885 1 /dev 23 crw-rw-rw- null rw root sshd 885 2 /dev 23 crw-rw-rw- null rw root sshd 885 3* internet stream tcp fffffe00076d9b70 root powerd 872 root / 2 drwxr-xr-x 1024 r root powerd 872 wd / 2 drwxr-xr-x 1024 r root powerd 872 text / 24482703 -r-xr-xr-x 15496 r root powerd 872 0 /dev 23 crw-rw-rw- null rw root powerd 872 1 /dev 23 crw-rw-rw- null rw root powerd 872 2 /dev 23 crw-rw-rw- null rw root powerd 872 3 / 31861941 -rw------- 3 w root powerd 872 4* local stream fffffe000716a5a0 <-> fffffe000716a4b0 root ntpd 869 root / 2 drwxr-xr-x 1024 r root ntpd 869 wd / 2 drwxr-xr-x 1024 r root ntpd 869 text / 24487626 -r-xr-xr-x 405472 r root ntpd 869 0 /dev 23 crw-rw-rw- null rw root ntpd 869 1 /dev 23 crw-rw-rw- null rw root ntpd 869 2 /dev 23 crw-rw-rw- null rw root ntpd 869 3* local dgram fffffe000716a690 <-> fffffe000751a960 root ntpd 869 20* internet dgram udp fffffe0007239c40 root ntpd 869 21* internet dgram udp fffffe0007239ab8 root ntpd 869 22* internet dgram udp fffffe0007239930 root ntpd 869 23* route raw 0 fffffe000753a000 root moused 817 root / 2 drwxr-xr-x 1024 r root moused 817 wd / 2 drwxr-xr-x 1024 r root moused 817 text / 24487651 -r-xr-xr-x 38112 r root moused 817 0 /dev 23 crw-rw-rw- null rw root moused 817 1 /dev 23 crw-rw-rw- null rw root moused 817 2 /dev 23 crw-rw-rw- null rw root moused 817 3 /dev 40 crw-rw-rw- psm0 rw root moused 817 4 /dev 59 crw------- consolectl rw root moused 817 5 / 31861934 -rw------- 3 w root syslogd 762 root / 2 drwxr-xr-x 1024 r root syslogd 762 wd / 2 drwxr-xr-x 1024 r root syslogd 762 text / 24484914 -r-xr-xr-x 38720 r root syslogd 762 0 /dev 23 crw-rw-rw- null rw root syslogd 762 1 /dev 23 crw-rw-rw- null rw root syslogd 762 2 /dev 23 crw-rw-rw- null rw root syslogd 762 3 / 31861867 -rw------- 3 w root syslogd 762 4* local dgram fffffe000751aa50 root syslogd 762 5* local dgram fffffe000751a960 root syslogd 762 6* internet dgram udp fffffe0007259000 root syslogd 762 7 /dev 7 crw------- klog r root syslogd 762 9 /dev 5 crw------- console w root syslogd 762 10 / 31861791 -rw-r--r-- 15782 w root syslogd 762 11 / 31861721 -rw------- 58 w root syslogd 762 12 / 31861729 -rw------- 796 w root syslogd 762 13 / 31861745 -rw-r----- 1768 w root syslogd 762 14 / 31861717 -rw-r--r-- 58 w root syslogd 762 15 / 31861722 -rw------- 58 w root syslogd 762 16 / 31861760 -rw------- 9278 w root syslogd 762 17 / 31861716 -rw------- 1262 w root syslogd 762 18 / 31861720 -rw-r----- 58 w root devd 631 root / 2 drwxr-xr-x 1024 r root devd 631 wd / 2 drwxr-xr-x 1024 r root devd 631 text / 6982277 -r-xr-xr-x 452720 r root devd 631 0 /dev 23 crw-rw-rw- null rw root devd 631 1 /dev 23 crw-rw-rw- null rw root devd 631 2 /dev 23 crw-rw-rw- null rw root devd 631 3 /dev 4 crw------- devctl r root devd 631 4* local stream fffffe000716a870 root devd 631 5 / 31861830 -rw------- 3 w root devd 631 6* local stream fffffe000716a4b0 <-> fffffe000716a5a0 root wpa_supplicant 366 root / 2 drwxr-xr-x 1024 r root wpa_supplicant 366 wd / 2 drwxr-xr-x 1024 r root wpa_supplicant 366 text / 24485019 -r-xr-xr-x 366440 r root wpa_supplicant 366 0 /dev 23 crw-rw-rw- null rw root wpa_supplicant 366 1 /dev 23 crw-rw-rw- null rw root wpa_supplicant 366 2 /dev 23 crw-rw-rw- null rw root wpa_supplicant 366 3* internet dgram udp fffffe0007259ab8 root wpa_supplicant 366 4* route raw 0 fffffe00072432a8 root wpa_supplicant 366 5 /dev 21 crw------- bpf rw root wpa_supplicant 366 6* local dgram fffffe00074f00f0 root wpa_supplicant 366 7* local dgram fffffe000716a780 <-> fffffe000751a960 root adjkerntz 153 root / 2 drwxr-xr-x 1024 r root adjkerntz 153 wd / 2 drwxr-xr-x 1024 r root adjkerntz 153 text / 6982275 -r-xr-xr-x 8920 r root adjkerntz 153 0 /dev 23 crw-rw-rw- null rw root adjkerntz 153 1 /dev 23 crw-rw-rw- null rw root adjkerntz 153 2 /dev 23 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 6982321 -r-xr-xr-x 764632 r root kernel 0 root / 2 drwxr-xr-x 1024 r root kernel 0 wd / 2 drwxr-xr-x 1024 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 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 9.1-STABLE #0: Wed Jan 9 12:14:15 MSK 2013 root@t61.park.rambler.ru:/usr/obj/usr/src/sys/T61 amd64 CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.96-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1fbae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3991662592 (3806 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, df900000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x4000-0x403f mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory pci0: at device 22.0 (no driver attached) em0: port 0x4080-0x409f mem 0xf1500000-0xf151ffff,0xf152b000-0xf152bfff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: f0:de:f1:af:75:cc ehci0: mem 0xf152a000-0xf152a3ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: mem 0xf1520000-0xf1523fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci3: on pcib2 iwn0: mem 0xf1400000-0xf1401fff irq 17 at device 0.0 on pci3 pcib3: irq 16 at device 28.4 on pci0 pci13: on pcib3 sdhci0: mem 0xf0c00000-0xf0c000ff irq 16 at device 0.0 on pci13 sdhci0: 1 slot(s) allocated mmc0: on sdhci0 ehci1: mem 0xf1529000-0xf15293ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x40a8-0x40af,0x40bc-0x40bf,0x40a0-0x40a7,0x40b8-0x40bb,0x4060-0x407f mem 0xf1528000-0xf15287ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich4: at channel 4 on ahci0 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 orm0: at iomem 0xc0000-0xcffff 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 ctl: CAM Target Layer loaded coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 31 and 27 on hdaa0 pcm1: at nid 25 and 35 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 pcm3: at nid 6 on hdaa1 pcm4: at nid 7 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 9734200 Hz quality 1000 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 usbus0 uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 Trying to mount root from ufs:/dev/ada0a [rw]... Setting hostuuid: 97a4f081-5125-11cb-b089-df80019b5f23. Setting hostid: 0xf94aad14. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0a: clean, 18788420 free (329252 frags, 2307396 blocks, 0.4% fragmentation) Mounting local file systems:. Setting hostname: t61.park.rambler.ru. wlan0: Ethernet address: 74:e5:0b:86:58:ec Starting wpa_supplicant. iwn0: radio is disabled by hardware switch Starting Network: lo0 em0 iwn0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=4219b ether f0:de:f1:af:75:cc inet 81.19.64.106 netmask 0xffffffe0 broadcast 81.19.64.127 media: Ethernet autoselect status: no carrier iwn0: flags=8803 metric 0 mtu 2290 ether 74:e5:0b:86:58:ec media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated Starting devd. Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. Starting ums0 moused. add net default: gateway 81.19.64.97 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/alsa-lib /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/event2 /usr/local/lib/gegl-0.1 /usr/local/lib/graphviz /usr/local/lib/nss 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Starting default moused. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 Updating motd:. Starting ntpd. Starting powerd. Starting sshd. Configuring syscons: keymap blanktime. Starting cron. Starting background file system checks in 60 seconds. Mon Jan 14 12:19:47 MSK 2013 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 linux: pid 1069 (npviewer.bin): syscall pipe2 not implemented linux: pid 1630 (npviewer.bin): syscall pipe2 not implemented linux: pid 73786 (npviewer.bin): syscall pipe2 not implemented mmc0: detached mmc0: on sdhci0 mmcsd0: 29GB at mmc0 50.0MHz/4bit/65535-block mmc0: detached mmc0: on sdhci0 linux: pid 74245 (npviewer.bin): syscall pipe2 not implemented usb_alloc_device: set address 4 failed (USB_ERR_STALLED, ignored) usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_STALLED, ignored) ugen1.4: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device linux: pid 75095 (npviewer.bin): syscall pipe2 not implemented linux: pid 75237 (npviewer.bin): syscall pipe2 not implemented ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 linux: pid 79386 (npviewer.bin): syscall pipe2 not implemented linux: pid 80989 (npviewer.bin): syscall pipe2 not implemented linux: pid 81162 (npviewer.bin): syscall pipe2 not implemented linux: pid 81162 (npviewer.bin): syscall inotify_init not implemented linux: pid 81177 (gam_server): syscall inotify_init not implemented linux: pid 81181 (gam_server): syscall inotify_init not implemented linux: pid 81578 (npviewer.bin): syscall pipe2 not implemented ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 linux: pid 81950 (npviewer.bin): syscall pipe2 not implemented linux: pid 85503 (npviewer.bin): syscall pipe2 not implemented linux: pid 43676 (npviewer.bin): syscall pipe2 not implemented linux: pid 44216 (npviewer.bin): syscall pipe2 not implemented linux: pid 44749 (npviewer.bin): syscall pipe2 not implemented linux: pid 44924 (npviewer.bin): syscall pipe2 not implemented linux: pid 45084 (npviewer.bin): syscall pipe2 not implemented linux: pid 45703 (npviewer.bin): syscall pipe2 not implemented linux: pid 49763 (npviewer.bin): syscall pipe2 not implemented linux: pid 50528 (npviewer.bin): syscall pipe2 not implemented linux: pid 50604 (npviewer.bin): syscall pipe2 not implemented linux: pid 22393 (npviewer.bin): syscall pipe2 not implemented linux: pid 26728 (npviewer.bin): syscall pipe2 not implemented linux: pid 26922 (npviewer.bin): syscall pipe2 not implemented linux: pid 27318 (npviewer.bin): syscall pipe2 not implemented ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: < silicon-power PMAP> Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1914MB (3919872 512 byte sectors: 255H 63S/T 244C) ugen1.4: at usbus1 (disconnected) umass0: at uhub3, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (da0:(pass1:umass-sim0:0:umass-sim0:0:0:0:0): removing device entry 0): passdevgonecb: devfs entry is gone ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, ugen1.4: at usbus1 (disconnected) umass0: at uhub3, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (da0:umass-sim0:0:0:(pass1:0): removing device entry umass-sim0:0:0:0): passdevgonecb: devfs entry is gone ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, ugen1.4: at usbus1 (disconnected) umass0: at uhub3, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (pass1:umass-sim0:0:(da0:0:0): passdevgonecb: devfs entry is gone umass-sim0:0:0:0): removing device entry ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, ugen1.4: at usbus1 (disconnected) umass0: at uhub3, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (da0:(pass1:umass-sim0:0:umass-sim0:0:0:0): removing device entry 0:0): passdevgonecb: devfs entry is gone ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, ugen0.4: at usbus0 (disconnected) umass0: at uhub2, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (pass1:umass-sim0:0:0:0): passdevgonecb: devfs entry is gone (da0:umass-sim0:0:0:0): removing device entry ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3824MB (7831552 512 byte sectors: 255H 63S/T 487C) (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 0 0 0 80 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 0 0 0 80 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range) (da0:umass-sim0:0:0:0): Error 22, Unretryable error ugen0.4: at usbus0 (disconnected) umass0: at uhub2, port 2, addr 4 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs (pass1:umass-sim0:0:0:0): passdevgonecb: devfs entry is gone (da0:umass-sim0:0:0:0): removing device entry linux: pid 27652 (npviewer.bin): syscall pipe2 not implemented ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 linux: pid 91996 (npviewer.bin): syscall pipe2 not implemented linux: pid 7404 (npviewer.bin): syscall pipe2 not implemented mmc0: detached mmc0: on sdhci0 mmc0: detached mmc0: on sdhci0 mmc0: detached sdhci0: detached pci13: at device 0.0 (no driver attached) sdhci0: mem 0xf0c00000-0xf0c000ff irq 16 at device 0.0 on pci13 sdhci0: 1 slot(s) allocated mmc0: on sdhci0 mmcsd0: 29GB at mmc0 50.0MHz/4bit/65535-block linux: pid 20134 (npviewer.bin): syscall pipe2 not implemented mmc0: detached mmc0: on sdhci0 ugen1.3: at usbus1 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 linux: pid 21741 (npviewer.bin): syscall pipe2 not implemented linux: pid 22350 (npviewer.bin): syscall pipe2 not implemented linux: pid 22619 (npviewer.bin): syscall pipe2 not implemented linux: pid 22725 (npviewer.bin): syscall pipe2 not implemented linux: pid 25993 (npviewer.bin): syscall pipe2 not implemented linux: pid 71661 (npviewer.bin): syscall pipe2 not implemented linux: pid 72554 (npviewer.bin): syscall pipe2 not implemented linux: pid 72783 (npviewer.bin): syscall pipe2 not implemented linux: pid 72881 (npviewer.bin): syscall pipe2 not implemented linux: pid 73079 (npviewer.bin): syscall pipe2 not implemented linux: pid 73372 (npviewer.bin): syscall pipe2 not implemented linux: pid 73525 (npviewer.bin): syscall pipe2 not implemented Limiting closed port RST response from 365 to 200 packets/sec linux: pid 73706 (npviewer.bin): syscall pipe2 not implemented linux: pid 74057 (npviewer.bin): syscall pipe2 not implemented linux: pid 83704 (npviewer.bin): syscall pipe2 not implemented ugen1.4: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-6 device da0: 40.000MB/s transfers da0: 29624MB (60669952 512 byte sectors: 255H 63S/T 3776C) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3454f8e9 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x3454f8e9 stack pointer = 0x28:0xffffff811d4a1660 frame pointer = 0x28:0xffffff811d4a1850 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 83843 (ssh-keygen) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff804ae2d0 at kdb_backtrace+0x60 #1 0xffffffff8047991d at panic+0x1fd #2 0xffffffff806326a8 at trap_fatal+0x388 #3 0xffffffff80632925 at trap_pfault+0x265 #4 0xffffffff80631fe5 at trap+0x415 #5 0xffffffff8061c7d3 at calltrap+0x8 #6 0xffffffff80510db6 at kern_openat+0x1a6 #7 0xffffffff80632e72 at amd64_syscall+0x282 #8 0xffffffff8061cabb at Xfast_syscall+0xfb Uptime: 9d1h59m50s Dumping 881 out of 3968 MB:..2%..11%..22%..31% (CTRL-C to abort) ..42% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..51%..62%..71%..82%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident T61 machine amd64 cpu HAMMER makeoptions DEBUG=-g options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options ATA_STATIC_ID options ATA_CAM options SMP options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options MAC options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device ahci device ata device mvs device siis device scbus device da device cd device pass device ctl device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device uart device em device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device iwn device loop device random device ether device vlan device tun device pty device md device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device umass device ums device sound device snd_hda ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist --Dxnq1zWXvFF0Q93v-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 13:32:08 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EF466F0; Wed, 23 Jan 2013 13:32:08 +0000 (UTC) (envelope-from asn@yam.park.rambler.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.freebsd.org (Postfix) with ESMTP id B438A181; Wed, 23 Jan 2013 13:32:07 +0000 (UTC) Received: from yam.park.rambler.ru (localhost [127.0.0.1]) by yam.park.rambler.ru (8.14.5/8.14.1) with ESMTP id r0NDW5Kl096402; Wed, 23 Jan 2013 17:32:05 +0400 (MSK) (envelope-from asn@yam.park.rambler.ru) Received: (from asn@localhost) by yam.park.rambler.ru (8.14.5/8.14.5/Submit) id r0NDW5wQ096401; Wed, 23 Jan 2013 17:32:05 +0400 (MSK) (envelope-from asn) Date: Wed, 23 Jan 2013 17:32:05 +0400 From: Alexander Nikiforenko To: stable@freebsd.org Subject: 9.1 coredump Message-ID: <20130123133205.GI14440@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: attilio@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 13:32:08 -0000 >hi, i was run ssh-keygen with output to 32g usb 3.0 flash, and got this core sorry, i was forgot. i mount that flash via fusefs-exfat-0.9.8 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 14:40:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45E0D30D for ; Wed, 23 Jan 2013 14:40:53 +0000 (UTC) (envelope-from prvs=0735a39caa=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4F07AE for ; Wed, 23 Jan 2013 14:40:53 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ty1VS-000KC5-Cn for freebsd-stable@freebsd.org; Wed, 23 Jan 2013 15:40:50 +0100 Date: Wed, 23 Jan 2013 15:40:50 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: svn - but smaller? Message-ID: <20130123144050.GG51786@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 14:40:53 -0000 Hi, in ancient times there was cvsup. cvsup was a PITA if you wanted (or needed) to install it via ports, the only reasonable way was to use pkg_add for that if you didn't want to pollute your system with otherwise unneeded software. Then there came csup. Small, in the base. You could install FreeBSD and the first task (for me and my environment) was often to simply csup to -STABLE (or a known good version of that) and to build an up-to-date and customised system. Like tayloring make.conf and src.conf to my needs and leave out most of the stuff I don't need on my system and in the kernel. Software and drivers that aren't there can't fail and won't be a security problem. Times have been changing, we're now up to svn. svn is far more modern than cvs and there are pretty good reasons to use it. However, I either overlook something important or we are now at the point we had with cvsup in the early days: The software I need to (source-)update the system doens't come with the base and installing svn is a PITA. It pulls in a whole lot of dependencies, at the time being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in the end I have my system polluted with software and libraries I don't really need in many cases for anything else. So, is there some alternative small svn client, that leaves a drastically smaller footprint probably somewhere around, probably even in the ports or is there anything I'm missing? The current situaion for me is a bit annoying. From the user's or admin's point of view at least. I didn't even see an option in svn to not build the server components, which would probably already help to make things smaller? Thanx, Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 14:58:22 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D115747; Wed, 23 Jan 2013 14:58:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 80D1E8AD; Wed, 23 Jan 2013 14:58:21 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA11268; Wed, 23 Jan 2013 16:58:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50FFFA8B.4040008@FreeBSD.org> Date: Wed, 23 Jan 2013 16:58:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: time issues and ZFS References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 14:58:22 -0000 on 22/01/2013 20:42 Adrian Chadd said the following: > Hi! > > As I said before, the problem with non-HLT loops with event-timer in > -9 and -head is that it calls the idle function inside a critical > section (critical_enter and critical_exit) which blocks interrupts > from occuring. > > The EI;HLT instruction pair on i386/amd64 atomically and correctly > handles things from what I've been told. > > However, there's no atomic way to do this using ACPI sleeping, so > there's a small window where an interrupt may come in but it isn't > handled; waiting for the next interrupt to occur before it'll wake up > and respond to that interrupt. I don't think that this is true of x86 hardware in general. You might have hit some limitation or a quirk or a bug or an erratum for some particular hardware. E.g. a chipset on this machine has a bit described as such: "Set to 1 to skip the C state transition if there is break event when entering C state." The bit is set indeed and as far as I can tell the behavior matches the description. Most modern (non-embedded) machines seem to behave this way. Attempt to enter a deeper C state while a break event is pending still incurs some overhead, but it's not as bad as waiting for the next break event. > I kept hitting my head against this when doing network testing. :( > > Now - specifically for timekeeping it shouldn't matter; that's to do > with whether the counters are reliable or not (and heck, are even in > lock-step on CPUs.) But extra latency could show up weirdly, hence why > I was asking for you to try different timer configurations and idle > loops. -- Andriy Gapon -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 15:06:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B5F1C19 for ; Wed, 23 Jan 2013 15:06:57 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2312792C for ; Wed, 23 Jan 2013 15:06:56 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ty1ua-0005fg-Ko for freebsd-stable@freebsd.org; Wed, 23 Jan 2013 16:06:49 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ty1ua-0005Eb-9c for freebsd-stable@freebsd.org; Wed, 23 Jan 2013 16:06:48 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> Date: Wed, 23 Jan 2013 16:06:47 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> User-Agent: Opera Mail/12.12 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: ba572e8a3bde05b4b19613c12a9e49fc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:06:57 -0000 On Wed, 23 Jan 2013 15:40:50 +0100, Oliver Brandmueller wrote: > Hi, > > in ancient times there was cvsup. cvsup was a PITA if you wanted (or > needed) to install it via ports, the only reasonable way was to use > pkg_add for that if you didn't want to pollute your system with > otherwise unneeded software. > > Then there came csup. Small, in the base. You could install FreeBSD and > the first task (for me and my environment) was often to simply csup to > -STABLE (or a known good version of that) and to build an up-to-date and > customised system. Like tayloring make.conf and src.conf to my needs and > leave out most of the stuff I don't need on my system and in the kernel. > Software and drivers that aren't there can't fail and won't be a > security problem. > > Times have been changing, we're now up to svn. svn is far more modern > than cvs and there are pretty good reasons to use it. > > However, I either overlook something important or we are now at the > point we had with cvsup in the early days: The software I need to > (source-)update the system doens't come with the base and installing svn > is a PITA. It pulls in a whole lot of dependencies, at the time being in > FBSD-9.1-R I cannot even pkg_add -r subversion out of the box. And in > the end I have my system polluted with software and libraries I don't > really need in many cases for anything else. > > So, is there some alternative small svn client, that leaves a > drastically smaller footprint probably somewhere around, probably even > in the ports or is there anything I'm missing? The current situaion for > me is a bit annoying. From the user's or admin's point of view at least. > I didn't even see an option in svn to not build the server components, > which would probably already help to make things smaller? > > Thanx, > Oliver > I've read about this initiative. http://svnweb.freebsd.org/base/user/des/svnsup/ Maybe you can help there. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 15:12:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F066E41 for ; Wed, 23 Jan 2013 15:12:43 +0000 (UTC) (envelope-from frank@fstaals.net) Received: from isp-bos-02.edutel.nl (unknown [IPv6:2a01:670:100:11:224:81ff:fe81:e10d]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3C3995 for ; Wed, 23 Jan 2013 15:12:43 +0000 (UTC) Received: from isp-aos-02.edu.local (unknown [IPv6:2a01:670:100:11::1:2]) by isp-bos-02.edutel.nl (Postfix) with ESMTP id C3E8F2C6553 for ; Wed, 23 Jan 2013 16:12:41 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by isp-aos-02.edu.local (Postfix) with ESMTP id C101F3940F0 for ; Wed, 23 Jan 2013 16:12:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at isp-aos-02.edutel.intern Received: from isp-aos-02.edu.local ([127.0.0.1]) by localhost (isp-aos-02.edu.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h2+6X+EuEAk for ; Wed, 23 Jan 2013 16:12:37 +0100 (CET) Received: from lacus.fstaals.net (104-208.ftth.onsbrabantnet.nl [88.159.208.104]) by isp-aos-02.edu.local (Postfix) with ESMTPA id 6B7C93940E0 for ; Wed, 23 Jan 2013 16:12:37 +0100 (CET) Received: from lacus.fstaals.net (unknown [192.168.10.14]) by filter.fstaals.local (Postfix) with ESMTP id 6BF9E7F4FB7 for ; Wed, 23 Jan 2013 16:12:33 +0100 (CET) Received: from localhost (dyn-81-63.cs.uu.nl [131.211.81.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: frank) by lacus.fstaals.net (Postfix) with ESMTPSA id 51A8E7F4084 for ; Wed, 23 Jan 2013 16:12:33 +0100 (CET) From: Frank Staals To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> User-Mail-Address: frank@fstaals.net Date: Wed, 23 Jan 2013 16:12:22 +0100 In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> (Oliver Brandmueller's message of "Wed, 23 Jan 2013 15:40:50 +0100") Message-ID: <87mww00w89.fsf@Shanna.FStaals.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:12:43 -0000 Oliver Brandmueller writes: > > > So, is there some alternative small svn client, that leaves a > drastically smaller footprint probably somewhere around, probably even > in the ports or is there anything I'm missing? > This type of question has been asked quite a few times recently. At this point there is no svn version of csup, however there were people working on it (or at least: there is a svnsup project). For details please search recent ports or questions mailing list archives. As far as I know there is also no alternative svn-client. I'm kind of surprised for the need of this though. Why not simply use portsnap if you are not actively developing ports? -- - Frank From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 15:37:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 48D7D3A3 for ; Wed, 23 Jan 2013 15:37:26 +0000 (UTC) (envelope-from prvs=0735a39caa=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2CEAE9 for ; Wed, 23 Jan 2013 15:37:26 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ty2OD-000KsA-8M for freebsd-stable@freebsd.org; Wed, 23 Jan 2013 16:37:25 +0100 Date: Wed, 23 Jan 2013 16:37:25 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130123153724.GA79995@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mww00w89.fsf@Shanna.FStaals.net> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:37:26 -0000 On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: > This type of question has been asked quite a few times recently. At this > point there is no svn version of csup, however there were people working > on it (or at least: there is a svnsup project). For details please > search recent ports or questions mailing list archives. As far as I know > there is also no alternative svn-client. Pointer to svnsup is fine; it seems I just missed to the first hint. > I'm kind of surprised for the need of this though. Why not simply use > portsnap if you are not actively developing ports? Well, for ports this is mostly fine, though on several places I prefer to use csup (or svn now) even for ports, since I maintain quite a set of local patches - this sometimes gives problems together with potsnap. Where this is neede, I have a shared ports tree anyway, so the whole svn setup is only needed in one machine. But my main concern is the system sources anyway. freebsd-update is not feasible for me, as described in the original post. Thank you, Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 15:55:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0803903 for ; Wed, 23 Jan 2013 15:55:33 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF15C48 for ; Wed, 23 Jan 2013 15:55:33 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c12so13757666ieb.37 for ; Wed, 23 Jan 2013 07:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=EYH9Hn2/JsIHALdVDGdjKlu56UBys+J1AKhoitW/yUE=; b=Tod94RwBnx9yetTf/Vjl0UYrE2uUuU7aAxYw9vjW+F4D9q1vZskaxaEAwlCB2c6j/I 2/XUE3yOSvgF4IftK832A2+b9lOQZavN0Mlhc4linV1CAVS/GN6RdUHtzwMFdRmUq8Jh nDnvva8V6UlS+kK9M8QgRjSiFs0qfK2UJHLD5CE7Rw7GXwAD4prM/7BxcGlQk8sbZYqX Yy7wXeVj6XC72XvVPntPJlqdOzver7/5wqz1M2+63v66/lst1OAHrBC62pqm8ijxCT68 FxXQIl4vvv/1fFm5rxjy3HvywO6jo0iandlfX8P5qaUvAuj/esimYZyShzIrQbQ+LZmM ay9Q== MIME-Version: 1.0 X-Received: by 10.42.92.72 with SMTP id s8mr1370730icm.0.1358956532872; Wed, 23 Jan 2013 07:55:32 -0800 (PST) Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 07:55:32 -0800 (PST) Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 07:55:32 -0800 (PST) In-Reply-To: <20130123153724.GA79995@e-Gitt.NET> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> Date: Wed, 23 Jan 2013 15:55:32 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:55:33 -0000 On 23 Jan 2013 15:37, "Oliver Brandmueller" wrote: > > On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: > > This type of question has been asked quite a few times recently. At this > > point there is no svn version of csup, however there were people working > > on it (or at least: there is a svnsup project). For details please > > search recent ports or questions mailing list archives. As far as I know > > there is also no alternative svn-client. > > Pointer to svnsup is fine; it seems I just missed to the first hint. > > > I'm kind of surprised for the need of this though. Why not simply use > > portsnap if you are not actively developing ports? > > Well, for ports this is mostly fine, though on several places I prefer > to use csup (or svn now) even for ports, since I maintain quite a set of > local patches - this sometimes gives problems together with potsnap. > Where this is neede, I have a shared ports tree anyway, so the whole svn > setup is only needed in one machine. > > But my main concern is the system sources anyway. freebsd-update is not > feasible for me, as described in the original post. The single binaries inside the archives at [1] may help you out. I built them fairly recently, so they should be up to date (ish), and they should be fine on 9+. Just untar and use. Chris [1] http://www.bayofrum.net/svn-static/ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 15:55:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D30E90F for ; Wed, 23 Jan 2013 15:55:50 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 11033CB3 for ; Wed, 23 Jan 2013 15:55:49 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r0NFtiRs063287 for ; Wed, 23 Jan 2013 10:55:44 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <510007F4.20701@sentex.net> Date: Wed, 23 Jan 2013 10:55:32 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> In-Reply-To: <20130123153724.GA79995@e-Gitt.NET> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:55:50 -0000 On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: > > But my main concern is the system sources anyway. freebsd-update is not > feasible for me, as described in the original post. > Actually, if you build the port minus the NEON option, its as bad in terms of dependencies. # pkg_info -r subversion-1.7.8.tbz Information for subversion-1.7.8.tbz: Depends on: Dependency: expat-2.0.1_2 Dependency: pkg-config-0.25_1 Dependency: gettext-0.18.1.1 Dependency: sqlite3-3.7.5 Dependency: gdbm-1.9.1 Dependency: db42-4.2.52_5 Dependency: libiconv-1.13.1_1 Dependency: apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12_1 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 16:03:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64EE0E00 for ; Wed, 23 Jan 2013 16:03:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx1.freebsd.org (Postfix) with ESMTP id EB586D34 for ; Wed, 23 Jan 2013 16:03:03 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fs12so1906321lab.25 for ; Wed, 23 Jan 2013 08:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9gkfFnM1wOy3iVKcsyu7SutqvZdRGRnWKpgmmG1w1Do=; b=q2IlujYqWgbzOT6YxdYbJNwykh+N4Z5H5hAKRW+LibgR16ykpbropEJgpXDSrNao91 94pXCMAXLjiWz1ejDiIqRWUh1nZuvh7jDAQaSDFpdm6ii6Ho0TP9m2uCqfC+17gC2b+j 4StGBvH5u371qOM6B691F+WwHtwoPt26CRfbixnlDJoJniSvJTlcDUJDSr95ZvSR96Nr upDw4cpKV4s/YstoGDd+tL/pxNsDkdqOwYRm5DQVG0+oEQkvAcqJX5hynwrjX+8OaUzc LXTFbmgM944fupheCIUELq4oAcRs3UsdfOLEzRW+YwRheK3kW4kHKzzDw1ySWC2wUpZI ubXg== MIME-Version: 1.0 X-Received: by 10.152.145.8 with SMTP id sq8mr1823280lab.21.1358956982795; Wed, 23 Jan 2013 08:03:02 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.101.2 with HTTP; Wed, 23 Jan 2013 08:03:02 -0800 (PST) In-Reply-To: <20130123133205.GI14440@rambler-co.ru> References: <20130123133205.GI14440@rambler-co.ru> Date: Wed, 23 Jan 2013 08:03:02 -0800 X-Google-Sender-Auth: KZpJAJiTItCoTtdcglVwk748_pY Message-ID: Subject: Re: 9.1 coredump From: Attilio Rao To: Alexander Nikiforenko Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:03:04 -0000 On Wed, Jan 23, 2013 at 1:32 PM, Alexander Nikiforenko wrote: >>hi, i was run ssh-keygen with output to 32g usb 3.0 flash, and got this core > > sorry, i was forgot. > i mount that flash via fusefs-exfat-0.9.8 This is on stable/9? If yes, I will send you patches to use new fuse approach in a while. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 16:20:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30BB23E2; Wed, 23 Jan 2013 16:20:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D08BE3F; Wed, 23 Jan 2013 16:20:54 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hn14so882459wib.15 for ; Wed, 23 Jan 2013 08:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BfXU5Wv8zGIoIcbRqpyfqjqu+JywYvrVillbCXrWakM=; b=GQKpRgIxjRsIy7CsjrDR4rW3l+/tNYOqYD9o8qLvERwVJz5ld4Mcx9DKMYqHx7UaAl /VUoveb2vV2vTpuAjqlzw1W93PaD7Y2CDZS1kqL4TBV5IxGBeU0tuxoFE6TBfjYlqHG/ UMxY6kypfugRqy/qC8IeIX8N8yiLUXk/mT0GQsvtNyL5xKfYCR+fbnUHp/UZyHT74v+i CXEKV3ujx54bZWsSmCXvRUZTh0wfrW9+oary7OaNEsFSExqIgMldYankFuq2oL6qEoI4 CTXNy81l57V842qdM4iFuhg4zWg8oCOzTpl+4SP9mE5yBD23Ui0CiuKd+iWmHX2YuD+m FmoQ== MIME-Version: 1.0 X-Received: by 10.194.57.82 with SMTP id g18mr3717021wjq.25.1358958053226; Wed, 23 Jan 2013 08:20:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.67.6 with HTTP; Wed, 23 Jan 2013 08:20:52 -0800 (PST) In-Reply-To: <50FFFA8B.4040008@FreeBSD.org> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> <50FFFA8B.4040008@FreeBSD.org> Date: Wed, 23 Jan 2013 08:20:52 -0800 X-Google-Sender-Auth: H2DewRrq-2pH-iaBxfJ6QpDuKjc Message-ID: Subject: Re: time issues and ZFS From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:20:55 -0000 On 23 January 2013 06:58, Andriy Gapon wrote: > I don't think that this is true of x86 hardware in general. > You might have hit some limitation or a quirk or a bug or an erratum for some > particular hardware. > > E.g. a chipset on this machine has a bit described as such: > "Set to 1 to skip the C state transition if there is break event > when entering C state." > The bit is set indeed and as far as I can tell the behavior matches the description. > > Most modern (non-embedded) machines seem to behave this way. Attempt to enter a > deeper C state while a break event is pending still incurs some overhead, but it's > not as bad as waiting for the next break event. I'll reverify the behaviour on my netbooks when I'm back home. It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be a quirk of the older generation celeron hardware - in which case, we need to tell the user somehow.. Adrian From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 16:24:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5124066C for ; Wed, 23 Jan 2013 16:24:48 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDF4E81 for ; Wed, 23 Jan 2013 16:24:47 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ty3CX-00083S-Un; Wed, 23 Jan 2013 20:29:25 +0400 Date: Wed, 23 Jan 2013 20:29:25 +0400 From: Slawa Olhovchenkov To: Mike Tancsa Subject: Re: svn - but smaller? Message-ID: <20130123162925.GA29224@zxy.spb.ru> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510007F4.20701@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:24:48 -0000 On Wed, Jan 23, 2013 at 10:55:32AM -0500, Mike Tancsa wrote: > On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: > > > > But my main concern is the system sources anyway. freebsd-update is not > > feasible for me, as described in the original post. > > > > > Actually, if you build the port minus the NEON option, its as bad in > terms of dependencies. > > # pkg_info -r subversion-1.7.8.tbz > Information for subversion-1.7.8.tbz: > > Depends on: > Dependency: expat-2.0.1_2 > Dependency: pkg-config-0.25_1 > Dependency: gettext-0.18.1.1 > Dependency: sqlite3-3.7.5 > Dependency: gdbm-1.9.1 > Dependency: db42-4.2.52_5 > Dependency: libiconv-1.13.1_1 > Dependency: apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12_1 > > ---Mike ==== > pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: Depends on: ==== Static linked, NEON included, run on 6+. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 17:06:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16FFEF8B for ; Wed, 23 Jan 2013 17:06:08 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id CD95B18C for ; Wed, 23 Jan 2013 17:06:07 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0NH663p028274; Wed, 23 Jan 2013 12:06:06 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0NH62eV028140; Wed, 23 Jan 2013 17:06:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Wed, 23 Jan 2013 17:06:02 +0000 Subject: Re: svn - but smaller? Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: <510007F4.20701@sentex.net> Date: Wed, 23 Jan 2013 12:05:25 -0500 Content-Transfer-Encoding: quoted-printable References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> To: freebsd-stable@freebsd.org X-Lux-Comment: Message r0NH5PFb026896 sent by user #74627 Message-Id: <1358960762-2331017.37282719.fr0NH5PFb026896@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358960762-2331017.37282719 Cc: Mike Leone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:06:08 -0000 One of my teammates and I were just doing a write up on this very issue, On Jan 23, 2013, at 10:55 AM, Mike Tancsa wrote: > On 1/23/2013 10:37 AM, Oliver Brandmueller wrote: >>=20 >> But my main concern is the system sources anyway. freebsd-update is = not=20 >> feasible for me, as described in the original post. >>=20 > Actually, if you build the port minus the NEON option, its as bad in > terms of dependencies. -------- THE UGLY Source for SVN: 496M (+) Source for FreeBSD 9.1: 746M (actual) (df output details below) ------- THE BAD After 15+ years of FreeBSD use, I remember what a great thing cvsup was = when it hit. However, SVN presents several problems for OS use (again): 1) License. Many of SVN's dependencies will never be available in the = FreeBSD source. While this is totally OK for development, SVN is 3rd party software, = this is unacceptable to force as 'the' respected path for OS source = builds. 2) Heft: cvsup/csup was excellent for 1 thing: grabbing a REL branch. = Perhaps grabbing STABLE or CURRENT. Systems administrators could = QA/test new branches on massive numbers of servers quickly and = efficiently. -------- THE GOOD We've just resolved this for ourselves, and are wrapping it in a clean = sh script: (I'd love to know where we can send it for input when we're done?) 40 lines of shell could get the jist of what users really need: - Download the src using fetch(1) fetch = ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/9.1-RELEASE/src.txz - Extract the tarball (to /usr/src, or wherever). tar -xf src.txz We're hacking out some simple script add-ons out right now for = ourselves, to make this more CVSUP like: + flag to keep source tarball somewhere (instead of merely un-tarring it = in a pipe) + flag to un-tar source to a particular directory + flag to specify OS version + flag to specify RELEASE, STABLE, CURRENT (if they exist, CURRENT may be tricky?) + define source server/mirror + source config in /etc, (or rc.conf ?), if exists -- Nice-to-have extra features (some necessary for us): + define protocol (tricky), e.g. ftp/http/https/other + after unpacking, run against mtree (possibly kept on separate server = or locally) to validate sources + exit non-zero if particular conditions exist + checksum tarball (possibly against checksums kept on separate server = or locally) to validate sources + exit non-zero if particular conditions exist + flags to override/change tar options ++ also nice to have, more cvsup features, (I need to read through man = page again for a sanity check) -- Regarding SVN: I know the SVN change is a profound leap foreword in source management = and collaboration, (I've carried many shops through CVS/SVN/GIT = migrations as an SA). Developing/hacking in the FreeBSD source is already simpler, though as = an outsider, (no commit bit), the transition has been expectedly = rough-edged :) On Jan 23, 2013, at 10:06 AM, Ronald Klop wrote: > I've read about this initiative. > http://svnweb.freebsd.org/base/user/des/svnsup/ > Maybe you can help there. Aside from the heft/licence issues I noted above, it's a bit late to = consider this, cvsup is going away: - the *ports* CVS/csup infrastructure is going to be disabled on = Feburary 28th - the *source* CVS/csup infrastructure is deprecated, but doesn't have a = definite end-date On Wed, Jan 23, 2013 at 04:12:22PM +0100, Frank Staals wrote: >> I'm kind of surprised for the need of this though. Why not simply use >> portsnap if you are not actively developing ports?=20 >=20 On Jan 23, 2013, at 10:37 AM, Oliver Brandmueller wrote: > But my main concern is the system sources anyway. freebsd-update is = not=20 > feasible for me, as described in the original post. For users/administrators, to merely fetch OS sources for a given branch, = it goes against the grain of nearly every reason users use FreeBSD to = say 'just use svn'. Additionally, it's not been fun recently to 'just use portssnap', when = the actual binary ports servers have gone through the recent security = incident, (as well as all the changes). I'm not meaning to be negative here, but this has slid pretty far away = from the ideals that *BSD users care about. Best, .ike # uncompressed canonical sources for svn (I believe I missed some = dependencies of the dependencies) du -d 1 -h 5.5M ./apr-1.4.6 5.3M ./sqlite-amalgamation-3071300 13M ./libtool-2.4.2 79M ./perl-5.16.2 4.0M ./neon-0.29.6 66M ./Python-2.7.1 153M ./db-5.3.21 55M ./subversion-1.7.8 8.6M ./m4-1.4.16 3.0M ./expat-2.1.0 12M ./pkg-config-0.27.1 3.0M ./gdbm-1.10 67M ./gettext-0.18.1.1 21M ./libiconv-1.14 496M . ## FreeBSD 9.1 Source $ pwd ; du -d 1 -h /usr/src 3.2M ./bin 11M ./cddl 316M ./contrib 40M ./crypto 2.0M ./etc 3.7M ./games 5.9M ./gnu 1.1M ./include 484k ./kerberos5 31M ./lib 2.1M ./libexec 1.3M ./release 32k ./rescue 7.2M ./sbin 3.6M ./secure 39M ./share 200M ./sys 44M ./tools 13M ./usr.bin 18M ./usr.sbin 746M . From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 19:09:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD3A9FBD for ; Wed, 23 Jan 2013 19:09:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB928DD for ; Wed, 23 Jan 2013 19:09:28 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id p1so2114609vcq.16 for ; Wed, 23 Jan 2013 11:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bLM/BssxLM7FZiMcblGYtgRPDmKh/euexnd1ZK4Lbo0=; b=xNObg0IaO7d9WP7TtiVQkCN7FdaU/WtoQmuSYg1g+WI4VsOgXQ7V1mP+BmtWKMOsBg oGi+klAOKBWRbTb5FpRekdiyxzrYOW/Xv4K+YUIVXtPiUdtLsiTtPW84/VyHC5RBAjFU J9eOb6TcKRITOpElj3o1NhI6OTJ7QpU1LuqVY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=bLM/BssxLM7FZiMcblGYtgRPDmKh/euexnd1ZK4Lbo0=; b=RsymYZGUonZ2htwBItL7vfD2u2dNxlYpeyrV66Z1R6xK2kWunpOpQiU9w1AKk/+UI6 3owvU2GPqEvTsZ7iV4YQedc+a2lggDaI4TWLaRW/A8J/G3zE31OMIOYxKjJonfnfCY65 vayr/kwztHqzpsNUzm1lLOjf3TGMh18wHI2jbjG6E+Eou+IRoVBzxRUgnLN8/C00Cetq 10OIkjx75G0RimMsyrGBdV7fQhNGfxDJhC64DM4ltwjPSyT2273avGHjw4e5H32ncQXQ WUrWUPIqvio3/3hCr38UAD96kB0ZwncufTQuQvTG2w+1x6CkWGZbhyhpbMbKW4Ak3paZ negw== MIME-Version: 1.0 X-Received: by 10.220.240.11 with SMTP id ky11mr2637816vcb.11.1358968162122; Wed, 23 Jan 2013 11:09:22 -0800 (PST) Received: by 10.220.174.135 with HTTP; Wed, 23 Jan 2013 11:09:22 -0800 (PST) In-Reply-To: <1358960762-2331017.37282719.fr0NH5PFb026896@rs149.luxsci.com> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> <1358960762-2331017.37282719.fr0NH5PFb026896@rs149.luxsci.com> Date: Wed, 23 Jan 2013 11:09:22 -0800 Message-ID: Subject: Re: svn - but smaller? From: Peter Wemm To: "Isaac (.ike) Levy" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkeGdpFFNEviIER4FlNGsiJiQ+m/xtmd+4jIDFrjRhn9mVnnWPmlsJvEu3/qe9BxGfYAOAC Cc: Mike Leone , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:09:28 -0000 On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy wrote: > 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. > While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. Don't confuse the excessive ports default settings as dependencies. You can make a quite mean and lean svn client. I did a 100% BSD-license-compatible src/contrib/svn style proof-of-concept back when we were planning what to do. Things like gdbm and bdb are not required and are license contamination that we don't need. But that's the fault of the port, not a fundamental property of using svn. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 19:10:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25536163 for ; Wed, 23 Jan 2013 19:10:31 +0000 (UTC) (envelope-from franz@electromail.org) Received: from mx-a.spam-sponge.de (mx-a.spam-sponge.de [88.198.239.211]) by mx1.freebsd.org (Postfix) with ESMTP id 37DCF907 for ; Wed, 23 Jan 2013 19:10:29 +0000 (UTC) Received: from [192.168.100.4] (e178003012.adsl.alicedsl.de [85.178.3.12]) (authenticated bits=0) by mx-a.spam-sponge.de (8.14.5/8.14.5) with ESMTP id r0NIq6lx093971 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 19:52:09 +0100 (CET) (envelope-from franz@electromail.org) Message-ID: <51003156.3010509@electromail.org> Date: Wed, 23 Jan 2013 19:52:06 +0100 From: Franz Schwartau User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: kvm vlan virtio problem References: <2103527496.1667.1351994019607.JavaMail.root@daemoninthecloset.org> <50FE627C.7070701@electromail.org> <627694717.15.1358912662920.JavaMail.root@daemoninthecloset.org> In-Reply-To: <627694717.15.1358912662920.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, bane ivosev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:10:31 -0000 Hi Bryan, On 23.01.2013 04:44, Bryan Venteicher wrote: > Hi, > > ----- Original Message ----- >> Hi! >> >> The same warning shows up in our setup: >> >> Jan 21 23:40:46 host kernel: WARNING: at net/core/dev.c:1712 >> skb_gso_segment+0x1df/0x2b0() (Tainted: G W --------------- ) >> Jan 21 23:40:46 host kernel: Hardware name: System Product Name >> Jan 21 23:40:46 host kernel: tun: caps=(0x1b0049, 0x0) len=4452 >> data_len=4380 ip_summed=0 >> [...] >> >> KVM host: CentOS 6.3, Linux kernel 2.6.32-279.19.1.el6.x86_64 >> VM guest: FreeBSD 9.1, virtio-kmod-9.1-0.242658 >> >> Disabling TSO on vtnet0 stops the warnings on the KVM host. >> >> Is there any progress on this issue? >> > > Alright, I tried to recreate this on Ubuntu 12.10 without any luck. Please > describe your network configuration. > > On my Linux host, my VLAN interface looks like: > > eth0.100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d > inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3119867 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3790183 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:166813040 (166.8 MB) TX bytes:5435432448 (5.4 GB) > > That is plugged into this bridge: > > br100 Link encap:Ethernet HWaddr 6c:f0:49:05:2b:6d > inet addr:192.168.99.101 Bcast:192.168.99.255 Mask:255.255.255.0 > inet6 addr: fe80::6ef0:49ff:fe05:2b6d/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:14 errors:0 dropped:0 overruns:0 frame:0 > TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:876 (876.0 B) TX bytes:1420 (1.4 KB) > > With the tap device created by QEMU for my FreeBSD guest: > > vnet1 Link encap:Ethernet HWaddr fe:54:00:ec:4f:4e > inet6 addr: fe80::fc54:ff:feec:4f4e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:800284 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3119877 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:5238099122 (5.2 GB) TX bytes:210492002 (210.4 MB) > > All this tied together: > > # brctl show br100 > bridge name bridge id STP enabled interfaces > br100 8000.6cf049052b6d no eth0.100 > vnet1 > > Does this approximate your configuration? What's the output of `ethtool -k` > for your VLAN, bridge, and vnet interfaces? First of all: Thanks for your efforts. We are using a different setup. Basically we are using a router VM, which means: All IP traffic for the actual VMs is routed through it. One ethernet interface of the router VM is bridged with the physical ethernet interface of the KVM host. The router VM has one or more additional interfaces for the actual VMs. This is the output of "ifconfig -a" from the KVM host: br0 Link encap:Ethernet HWaddr AA:50:00:1F:23:AD inet addr:88.12.100.100 Bcast:88.12.100.127 Mask:255.255.255.255 inet6 addr: fe80::aa50:ff:fe1f:23ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:338087 errors:0 dropped:0 overruns:0 frame:0 TX packets:213316 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:115518852 (110.1 MiB) TX bytes:528688448 (504.1 MiB) eth0 Link encap:Ethernet HWaddr AA:50:00:1F:23:AD inet6 addr: fe80::aa50:ff:fe1f:23ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6398703 errors:0 dropped:0 overruns:0 frame:0 TX packets:8451045 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3566218121 (3.3 GiB) TX bytes:7532154606 (7.0 GiB) Interrupt:43 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:138575 errors:0 dropped:0 overruns:0 frame:0 TX packets:138575 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480320359 (458.0 MiB) TX bytes:480320359 (458.0 MiB) virbr0 Link encap:Ethernet HWaddr 52:54:00:83:09:92 inet addr:10.30.1.1 Bcast:10.30.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:232 (232.0 b) TX bytes:3156 (3.0 KiB) virbr0-nic Link encap:Ethernet HWaddr 52:54:00:83:09:92 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) virbr1 Link encap:Ethernet HWaddr 52:54:00:D3:C4:BE inet addr:10.30.2.1 Bcast:10.30.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7267 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:521172 (508.9 KiB) TX bytes:3372 (3.2 KiB) virbr1-nic Link encap:Ethernet HWaddr 52:54:00:D3:C4:BE BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) vnet0 Link encap:Ethernet HWaddr FE:50:56:00:13:C5 inet6 addr: fe80::fc50:56ff:fe00:13c5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6664419 errors:0 dropped:0 overruns:0 frame:0 TX packets:5152582 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:6904113626 (6.4 GiB) TX bytes:3382814134 (3.1 GiB) vnet1 Link encap:Ethernet HWaddr FE:54:00:9C:A9:AE inet6 addr: fe80::fc54:ff:fe9c:a9ae/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:4041 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1176 (1.1 KiB) TX bytes:267856 (261.5 KiB) vnet2 Link encap:Ethernet HWaddr FE:54:00:09:82:25 inet6 addr: fe80::fc54:ff:fe09:8225/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5200680 errors:0 dropped:0 overruns:0 frame:0 TX packets:6733169 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:3341649436 (3.1 GiB) TX bytes:6895134123 (6.4 GiB) vnet3 Link encap:Ethernet HWaddr FE:54:00:A0:06:84 inet6 addr: fe80::fc54:ff:fea0:684/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4833709 errors:0 dropped:0 overruns:0 frame:0 TX packets:3119549 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:4412472305 (4.1 GiB) TX bytes:1931670365 (1.7 GiB) vnet4 Link encap:Ethernet HWaddr FE:54:00:32:27:E2 inet6 addr: fe80::fc54:ff:fe32:27e2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:201383 errors:0 dropped:0 overruns:0 frame:0 TX packets:211537 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:97363028 (92.8 MiB) TX bytes:37970834 (36.2 MiB) This is the output of "brctl show" from the KVM host: bridge name bridge id STP enabled interfaces br0 8000.aa50001f23ad no eth0 vnet0 virbr0 8000.525400830992 no virbr0-nic vnet1 virbr1 8000.525400d3c4be no virbr1-nic vnet2 vnet3 vnet4 This is the output of "ethtool -k " from the KVM host: Offload parameters for br0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off Offload parameters for eth0: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: on large-receive-offload: off Offload parameters for virbr0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off Offload parameters for virbr0-nic: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for virbr1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off Offload parameters for virbr1-nic: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for vnet0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for vnet1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for vnet2: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for vnet3: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Offload parameters for vnet4: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: on generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off Please let me know if you need more information. Best regards Franz From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 19:17:39 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A75E481 for ; Wed, 23 Jan 2013 19:17:39 +0000 (UTC) (envelope-from ehaupt@FreeBSD.org) Received: from mx.critical.ch (mx.critical.ch [IPv6:2001:1620:f05::1]) by mx1.freebsd.org (Postfix) with ESMTP id A5B5C955 for ; Wed, 23 Jan 2013 19:17:38 +0000 (UTC) Received: from beaver.home.critical.ch (84-72-7-76.dclient.hispeed.ch [84.72.7.76]) (authenticated bits=0) by mx.critical.ch (8.14.4/8.14.4/critical-1.0) with ESMTP id r0NJHYvp051259; Wed, 23 Jan 2013 20:17:35 +0100 (CET) (envelope-from ehaupt@FreeBSD.org) Date: Wed, 23 Jan 2013 20:17:34 +0100 From: Emanuel Haupt To: Oliver Brandmueller Subject: Re: svn - but smaller? Message-Id: <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> References: <20130123144050.GG51786@e-Gitt.NET> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:17:39 -0000 Oliver Brandmueller wrote: > Hi, > > in ancient times there was cvsup. cvsup was a PITA if you wanted (or > needed) to install it via ports, the only reasonable way was to use > pkg_add for that if you didn't want to pollute your system with > otherwise unneeded software. > > Then there came csup. Small, in the base. You could install FreeBSD > and the first task (for me and my environment) was often to simply > csup to -STABLE (or a known good version of that) and to build an > up-to-date and customised system. Like tayloring make.conf and > src.conf to my needs and leave out most of the stuff I don't need on > my system and in the kernel. Software and drivers that aren't there > can't fail and won't be a security problem. > > Times have been changing, we're now up to svn. svn is far more modern > than cvs and there are pretty good reasons to use it. > > However, I either overlook something important or we are now at the > point we had with cvsup in the early days: The software I need to > (source-)update the system doens't come with the base and installing > svn is a PITA. It pulls in a whole lot of dependencies, at the time > being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the > box. And in the end I have my system polluted with software and > libraries I don't really need in many cases for anything else. > > So, is there some alternative small svn client, that leaves a > drastically smaller footprint probably somewhere around, probably > even in the ports or is there anything I'm missing? The current > situaion for me is a bit annoying. From the user's or admin's point > of view at least. I didn't even see an option in svn to not build the > server components, which would probably already help to make things > smaller? > > Thanx, > Oliver devel/subversion already has an option to build a static version. A solution could be to create a stub port (devel/subversion-static) similar to: shells/bash-devel shells/bash-static-devel dns/ldns dns/py-ldns That way the package build cluster would create a package of the static version which wouldn't pull in any runtime dependencies. Emanuel From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 20:42:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 326DE448; Wed, 23 Jan 2013 20:42:20 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id E9688E1F; Wed, 23 Jan 2013 20:42:19 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0NKg9jD026914; Wed, 23 Jan 2013 15:42:10 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0NKg7bx026714; Wed, 23 Jan 2013 20:42:07 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Wed, 23 Jan 2013 20:42:05 +0000 Subject: Re: svn - but smaller? Content-Type: text/plain; charset=windows-1252 From: "Isaac (.ike) Levy" In-Reply-To: <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> Date: Wed, 23 Jan 2013 15:41:41 -0500 Content-Transfer-Encoding: quoted-printable References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> To: Emanuel Haupt X-Lux-Comment: Message r0NKfgPf025068 sent by user #74627 Message-Id: <1358973727-4656511.96619194.fr0NKfgPf025068@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358973727-4656511.96619194 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 20:42:20 -0000 On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: > Oliver Brandmueller wrote: >> Hi, >>=20 >> in ancient times there was cvsup. cvsup was a PITA if you wanted (or=20= >> needed) to install it via ports, the only reasonable way was to use=20= >> pkg_add for that if you didn't want to pollute your system with=20 >> otherwise unneeded software. >>=20 >> Then there came csup. Small, in the base. You could install FreeBSD >> and the first task (for me and my environment) was often to simply >> csup to -STABLE (or a known good version of that) and to build an >> up-to-date and customised system. Like tayloring make.conf and >> src.conf to my needs and leave out most of the stuff I don't need on >> my system and in the kernel. Software and drivers that aren't there >> can't fail and won't be a security problem. >>=20 >> Times have been changing, we're now up to svn. svn is far more modern=20= >> than cvs and there are pretty good reasons to use it. >>=20 >> However, I either overlook something important or we are now at the=20= >> point we had with cvsup in the early days: The software I need to=20 >> (source-)update the system doens't come with the base and installing >> svn is a PITA. It pulls in a whole lot of dependencies, at the time >> being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the >> box. And in the end I have my system polluted with software and >> libraries I don't really need in many cases for anything else. >>=20 >> So, is there some alternative small svn client, that leaves a=20 >> drastically smaller footprint probably somewhere around, probably >> even in the ports or is there anything I'm missing? The current >> situaion for me is a bit annoying. =46rom the user's or admin's point >> of view at least. I didn't even see an option in svn to not build the >> server components, which would probably already help to make things >> smaller? >>=20 >> Thanx, >> Oliver On Jan 23, 2013, at 2:09 PM, Peter Wemm wrote: > On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy > wrote: >=20 >> 1) License. Many of SVN's dependencies will never be available in = the FreeBSD source. >> While this is totally OK for development, SVN is 3rd party software, = this is unacceptable to force as 'the' respected path for OS source = builds. >=20 > Don't confuse the excessive ports default settings as dependencies. > You can make a quite mean and lean svn client. I did a 100% > BSD-license-compatible src/contrib/svn style proof-of-concept back > when we were planning what to do. Things like gdbm and bdb are not > required and are license contamination that we don't need. But that's > the fault of the port, not a fundamental property of using svn. On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: > devel/subversion already has an option to build a static version. A > solution could be to create a stub port (devel/subversion-static) > similar to: >=20 > shells/bash-devel > shells/bash-static-devel >=20 > dns/ldns > dns/py-ldns >=20 > That way the package build cluster would create a package of the = static > version which wouldn't pull in any runtime dependencies. >=20 > Emanuel Peter, this work sounds great, and sounds like it would make a great = stub port itself! I'd love to see whatever you have remaining from the proof-of-concept = work, to perhaps help expand it into 'devel/subversion-lite' or = 'devel/subversion-static' ? I'd happily use it for development. -- However, SVN for development use is not what the point, this thread is = about using, administrating, and maintaining FreeBSD systems- not about = development process. And in that case, SVN is still a fairly massive = toolset for the simple task of fetching REL, STABLE, or CURRENT: Source for SVN-alone: 55M Source for FreeBSD 9.1: 746M That's still over 7% of the size of the entire OS. I believe it's not at all necessary to have anything except the base = FreeBSD OS, to update/install FreeBSD. -- A NYC*BUG list user posted this reminder, we've been here before: > Deja-vu=85 This reminds me of cvsup+modula-3. >=20 > = http://www.mavetju.org/mail/view_message.php?list=3Dfreebsd-current&id=3D2= 09027 I'll keep hacking on our shell utility, and will post the PR to this = thread. Best, .ike From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:10:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DA88BC2; Wed, 23 Jan 2013 21:10:01 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id DEA35F1E; Wed, 23 Jan 2013 21:10:00 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so14269357ieb.25 for ; Wed, 23 Jan 2013 13:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=BpA5dj67WZlH6otc8RK+q+/RzAqjCZ7VIw3ePRRNH7Q=; b=X14iGBz1AuP296RKfIXyWljodRMf43Mma7/gL+PkBkVVzJrzMPJjJ+vGFD/hOS5c2H I0QAyWz/GodZt8tpifxemT3kuQtJMybJWeFFm65T5sUUahCA2d3t+Emm2xEsaE4ph5xw rxozJur1+nlNea9AQTcN6/2WcZT6la9Ac5p10RzReKjyf8qxwajZuQ+vgqdOU5jtB74e OLn2ak4PBA5kkYwyMLD9J3GhgMR+AEIcsl5noFC3A0W2gwIPpVhWQ7QDnzsZ9Fj/pYB8 BJiZxTTIOfmaYEiVpbQLiSho0TyN4J2De7xvlGLs9/n135ATWcbwmSQJBZlUqAUaDTlL uAAQ== X-Received: by 10.50.161.169 with SMTP id xt9mr15967527igb.62.1358975400181; Wed, 23 Jan 2013 13:10:00 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 13:09:30 -0800 (PST) In-Reply-To: <1358973727-4656511.96619194.fr0NKfgPf025068@rs149.luxsci.com> References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> <1358973727-4656511.96619194.fr0NKfgPf025068@rs149.luxsci.com> From: Chris Rees Date: Wed, 23 Jan 2013 21:09:30 +0000 X-Google-Sender-Auth: 7SnP4rVMWF_cGZkEcQl_QFQ6gPg Message-ID: Subject: Re: svn - but smaller? To: "Isaac (.ike) Levy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:10:01 -0000 On 23 January 2013 20:41, Isaac (.ike) Levy wrot= e: > On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: >> Oliver Brandmueller wrote: >>> Hi, >>> >>> in ancient times there was cvsup. cvsup was a PITA if you wanted (or >>> needed) to install it via ports, the only reasonable way was to use >>> pkg_add for that if you didn't want to pollute your system with >>> otherwise unneeded software. >>> >>> Then there came csup. Small, in the base. You could install FreeBSD >>> and the first task (for me and my environment) was often to simply >>> csup to -STABLE (or a known good version of that) and to build an >>> up-to-date and customised system. Like tayloring make.conf and >>> src.conf to my needs and leave out most of the stuff I don't need on >>> my system and in the kernel. Software and drivers that aren't there >>> can't fail and won't be a security problem. >>> >>> Times have been changing, we're now up to svn. svn is far more modern >>> than cvs and there are pretty good reasons to use it. >>> >>> However, I either overlook something important or we are now at the >>> point we had with cvsup in the early days: The software I need to >>> (source-)update the system doens't come with the base and installing >>> svn is a PITA. It pulls in a whole lot of dependencies, at the time >>> being in FBSD-9.1-R I cannot even pkg_add -r subversion out of the >>> box. And in the end I have my system polluted with software and >>> libraries I don't really need in many cases for anything else. >>> >>> So, is there some alternative small svn client, that leaves a >>> drastically smaller footprint probably somewhere around, probably >>> even in the ports or is there anything I'm missing? The current >>> situaion for me is a bit annoying. From the user's or admin's point >>> of view at least. I didn't even see an option in svn to not build the >>> server components, which would probably already help to make things >>> smaller? >>> >>> Thanx, >>> Oliver > > On Jan 23, 2013, at 2:09 PM, Peter Wemm wrote: >> On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy >> wrote: >> >>> 1) License. Many of SVN's dependencies will never be available in the = FreeBSD source. >>> While this is totally OK for development, SVN is 3rd party software, th= is is unacceptable to force as 'the' respected path for OS source builds. >> >> Don't confuse the excessive ports default settings as dependencies. >> You can make a quite mean and lean svn client. I did a 100% >> BSD-license-compatible src/contrib/svn style proof-of-concept back >> when we were planning what to do. Things like gdbm and bdb are not >> required and are license contamination that we don't need. But that's >> the fault of the port, not a fundamental property of using svn. > > > On Jan 23, 2013, at 2:17 PM, Emanuel Haupt wrote: >> devel/subversion already has an option to build a static version. A >> solution could be to create a stub port (devel/subversion-static) >> similar to: >> >> shells/bash-devel >> shells/bash-static-devel >> >> dns/ldns >> dns/py-ldns >> >> That way the package build cluster would create a package of the static >> version which wouldn't pull in any runtime dependencies. >> >> Emanuel > > Peter, this work sounds great, and sounds like it would make a great stub= port itself! > I'd love to see whatever you have remaining from the proof-of-concept wor= k, to perhaps help expand it into 'devel/subversion-lite' or 'devel/subvers= ion-static' ? I'd happily use it for development. > > -- > However, SVN for development use is not what the point, this thread is ab= out using, administrating, and maintaining FreeBSD systems- not about devel= opment process. And in that case, SVN is still a fairly massive toolset fo= r the simple task of fetching REL, STABLE, or CURRENT: > > Source for SVN-alone: 55M > Source for FreeBSD 9.1: 746M > > That's still over 7% of the size of the entire OS. > > I believe it's not at all necessary to have anything except the base Free= BSD OS, to update/install FreeBSD. > > -- > A NYC*BUG list user posted this reminder, we've been here before: > >> Deja-vu=85 This reminds me of cvsup+modula-3. >> >> http://www.mavetju.org/mail/view_message.php?list=3Dfreebsd-current&id= =3D209027 > > > I'll keep hacking on our shell utility, and will post the PR to this thre= ad. Your shell utility appears to fetch a new tarball of the entire repo each time? That's very bandwidth-unfriendly for the Project's servers as well as yours... Chris From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:26:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B036E89B; Wed, 23 Jan 2013 21:26:15 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0F870; Wed, 23 Jan 2013 21:26:15 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id qd14so14209354ieb.20 for ; Wed, 23 Jan 2013 13:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=jC8WizwcxsJG9zVX8X3XwR9d3Wr0nIdaMu67kFb8LGE=; b=UuUHXf47gtbTv/AaSe1cqb7X3RpIt4R6aGXlb5fmLzHbseUp3CdZfCzMvRzuwxwwYm dIzWvX2AlueihnSNcqz+F07sUgt45t+At0LT8Zb28OZuj9Q+sq+4Y3fFCxe/CWTDDlVS 8zPoVzXConLwE6lVWKfui0XzQOAILun+cchPGpHhYa0x0GHyXuhGBXpOICk4DPOjB7YM CHajyZxs8q3td4JRBcQBFYv8RvRVk61gUzNBpTdRyFnspkrSyWPcnEJLO1to83LWdav0 FHPSVPkqjASBSM9RxbUIVZ0TuFP6mW1nW36oMAXNm0Q4mq4Jb4VcxNDWxTBtx0ob51S0 vN/Q== X-Received: by 10.50.178.10 with SMTP id cu10mr16534628igc.75.1358976374950; Wed, 23 Jan 2013 13:26:14 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 13:25:44 -0800 (PST) In-Reply-To: <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> From: Chris Rees Date: Wed, 23 Jan 2013 21:25:44 +0000 X-Google-Sender-Auth: gnEcXuKKiRyQqQEgc88k0diGWrc Message-ID: Subject: Re: svn - but smaller? To: Emanuel Haupt , Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:26:15 -0000 On 23 January 2013 19:17, Emanuel Haupt wrote: > devel/subversion already has an option to build a static version. A > solution could be to create a stub port (devel/subversion-static) > similar to: > > shells/bash-devel > shells/bash-static-devel > > dns/ldns > dns/py-ldns Great idea; http://www.bayofrum.net/~crees/patches/svn-static.diff Lev, do you mind if I commit this? I haven't touched the subversion port, but it'll have you as maintainer :) If you prefer, I don't mind maintaining this. Chris From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:28:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE2D8B12 for ; Wed, 23 Jan 2013 21:28:44 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id C57EDB4 for ; Wed, 23 Jan 2013 21:28:44 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta02.emeryville.ca.mail.comcast.net with comcast id rRa71k0011wfjNsA2ZUjcK; Wed, 23 Jan 2013 21:28:43 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta23.emeryville.ca.mail.comcast.net with comcast id rZUj1k0021t3BNj8jZUjbH; Wed, 23 Jan 2013 21:28:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA89D73A1C; Wed, 23 Jan 2013 13:28:42 -0800 (PST) Date: Wed, 23 Jan 2013 13:28:42 -0800 From: Jeremy Chadwick To: peter@wemm.org Subject: Re: svn - but smaller? Message-ID: <20130123212842.GA12754@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358976523; bh=xsK4UkcXOlXCH2bf5bBytz/E7aVE9FZTHAst5j6HGgE=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=J/3fP5IiLUZqhVy2o7Wt4E9hiMK/iYChE5R5sDUFFClzif4/kycc0trZdOMKtmp1q 0OCjmwJyZFZvXBJtfk+e3HxCT4djcqbLXCxAra1FcsmVrT9Cg9Izbf76gqrDz/o/YF +BC3RBu/iYyiG4nEDBFZiUgriMBTfSVenTF0fjj4d9eyWukAZ/OPadKSo1p2KQ1dyh V6784ilw/l508wX8doEoqdwERe0cdRNZWVfp0fFd+XzqepmLn3dj822muipfKq/4mC r7/dzMDZPz8FXfKTfG92qCSn6gaAd4OmXqzl0ml3RY++s1N7eyLvBEZEMF95uDApHM kg52e47Ps0+nA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:28:44 -0000 (Please keep me CC'd as I'm not subscribed to the list) > Don't confuse the excessive ports default settings as dependencies. > You can make a quite mean and lean svn client. I did a 100% > BSD-license-compatible src/contrib/svn style proof-of-concept back > when we were planning what to do. Things like gdbm and bdb are not > required and are license contamination that we don't need. But that's > the fault of the port, not a fundamental property of using svn. While I do understand what you're saying, the Oracle DB and GDBM actually aren't the "the fault of the port", they're a result of what has been eluded to as a build cluster configuration problem or something along those lines. I brought up the dependency list mismatch in subversion.tbz on the package servers (ftp.freebsd.org) in mid November 2012; building from actual source (the port itself) did not pull in any of these dependencies: http://lists.freebsd.org/pipermail/freebsd-ports/2012-November/079589.html lev@ (port maintainer) had this to say: http://lists.freebsd.org/pipermail/freebsd-ports/2012-November/079592.html Quote: >>>JC> However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled >>>JC> in 1.7.7 which is what's in ports currently: >>> >>> They weren't enabled for 1.7.6 too, so it is strange, that >>> pointyhat-builded package require it. I need to investigate this. And that still seems to be the case today, as Mike Tancsa pointed out: http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071804.html What remains on ftp.freebsd.org is still the same today: $ ftp ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/ ... ftp> dir subversion* 227 Entering Passive Mode (204,152,184,73,242,194). 150 Here comes the directory listing. lrwxr-xr-x 1 967 100 32 Oct 14 14:53 subversion-java.tbz -> ../All/subversion-java-1.7.6.tbz lrwxr-xr-x 1 967 100 27 Oct 13 13:24 subversion.tbz -> ../All/subversion-1.7.6.tbz lrwxr-xr-x 1 967 100 28 Oct 14 01:54 subversion16.tbz -> ../All/subversion-1.6.18.tbz 226 Directory send OK. I'm left to believe lev@ hasn't had the cycles to investigate this, which is perfectly fine -- however given the importance of SVN at this point in FreeBSD's life, some other committer or whoever is responsible for the build cluster should have stepped up to the plate to figure this out, given how the *entire infrastructure* is now dependent upon this one thing. :-/ I can talk about the remaining dependencies that usually concern people (those are commonly sqlite3, expat, and apr) if required, but for now I'll stay squelched. And just as a footnote point: respectfully do not tell me "this is a great opportunity to try pkgng". Please stay focused on the actual problem. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:45:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8628E69A; Wed, 23 Jan 2013 21:45:17 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0B47F198; Wed, 23 Jan 2013 21:45:17 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:4400:f9ea:e0ba:b2b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 45BC44AC32; Thu, 24 Jan 2013 01:45:10 +0400 (MSK) Date: Thu, 24 Jan 2013 01:45:06 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <464128886.20130124014506@serebryakov.spb.ru> To: Chris Rees Subject: Re: svn - but smaller? In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:45:17 -0000 Hello, Chris. You wrote 24 =FF=ED=E2=E0=F0=FF 2013 =E3., 1:25:44: CR> Great idea; CR> http://www.bayofrum.net/~crees/patches/svn-static.diff I think, adding SERF or NEON (what is smaller) is good idea, or this build will lack http support, and it could be surprise to user, as http access method is well-know and useful in case of corporate firewalls. CR> Lev, do you mind if I commit this? I haven't touched the subversion CR> port, but it'll have you as maintainer :) Ok :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:47:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A0E07DD; Wed, 23 Jan 2013 21:47:12 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 3F50D1CF; Wed, 23 Jan 2013 21:47:12 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id k13so14602649iea.36 for ; Wed, 23 Jan 2013 13:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aLGuMfzfUu4TyyREUCyeNDdZKLRayoOR+l63DiBdVZk=; b=rZlJE/Opp6rBHrtSZ5TEsx04DZ9ae/CxLIKb60ofBEFP2Lq2EHOUEzF47qXt4Pugjj rtYib9FIwOz7y79rkecAunpz0p7RyBKTYIhIgKssCcm1o5Bnw2vvC7LHPiUN1zx8luOX D9HNq7QIwajqMDWSarK3vL+UAFwed56ckQBTS5fN9j9Ku7Oe4sDlimuutRAPa+WWMBGJ VaWsKGIFgSSnV2HgyZV33pJDVyiXVbxcM1Tnnmu8BennLfF0pvkAlfBgb2q1XdgplR6e hgN4Bws69XLRhXcA0r6saSKpn2v4OnUudpR8IemBRK8UmWjynL4hBgGJbkfuHnM8xm14 U6Eg== MIME-Version: 1.0 X-Received: by 10.42.92.72 with SMTP id s8mr2191925icm.0.1358977631767; Wed, 23 Jan 2013 13:47:11 -0800 (PST) Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 13:47:11 -0800 (PST) Received: by 10.64.16.73 with HTTP; Wed, 23 Jan 2013 13:47:11 -0800 (PST) In-Reply-To: <464128886.20130124014506@serebryakov.spb.ru> References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> <464128886.20130124014506@serebryakov.spb.ru> Date: Wed, 23 Jan 2013 21:47:11 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:47:12 -0000 On 23 Jan 2013 21:45, "Lev Serebryakov" wrote: > > Hello, Chris. > You wrote 24 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2013 =D0=B3., 1:25:44: > > CR> Great idea; > CR> http://www.bayofrum.net/~crees/patches/svn-static.diff > I think, adding SERF or NEON (what is smaller) is good idea, or this > build will lack http support, and it could be surprise to user, as > http access method is well-know and useful in case of corporate > firewalls. > > CR> Lev, do you mind if I commit this? I haven't touched the subversion > CR> port, but it'll have you as maintainer :) > Ok :) I'll check which makes a smaller package- thanks for the quick approval. Chris From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 21:55:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 161CB9A for ; Wed, 23 Jan 2013 21:55:33 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id F24F3283 for ; Wed, 23 Jan 2013 21:55:32 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id rQ7H1k0021afHeLA3ZvYx9; Wed, 23 Jan 2013 21:55:32 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id rZvX1k01B1t3BNj8dZvYUE; Wed, 23 Jan 2013 21:55:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D41A773A1C; Wed, 23 Jan 2013 13:55:31 -0800 (PST) Date: Wed, 23 Jan 2013 13:55:31 -0800 From: Jeremy Chadwick To: crees@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130123215531.GA13217@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358978132; bh=QBbSZmaoI1OBSeO9vnjyXZEErAXnHiEQqgHddbU2T1k=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=SeNxMnM5aTy7hVWr+GJ5PoAt6j2lv/azfebVj02nSIsKh6m2U/0OiBOGtF0KC8ONF n2ekRKPoxdSMAsYSoF81kwLQa8DQ4yE8Ndn0+/S36VCRV1vdGtOTohBkcMt0gUP88F tgG12URGhtq+1R4o/6J6BicBKZQGfOCVzr7WhII2BrmWvS/Id75WYm3G4pmrPhZXWF gQzZV2gWtZalPzANbgbBehvE/lDUIOTK1ylyrodoqyyHLShzpvfZnEJAboe+puR9Q/ 3L7dCa0xkjTl8iNv4S/aDoZGlyeae4drzMQnO+DQ1Pzua97HtpqT1sUNuGhlwNg2OB 1JDDQlfkVVnvA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 21:55:33 -0000 (Please keep me CC'd as I'm not subscribed to the list) > Great idea; > > http://www.bayofrum.net/~crees/patches/svn-static.diff > > Lev, do you mind if I commit this? I haven't touched the subversion > port, but it'll have you as maintainer :) > > If you prefer, I don't mind maintaining this. As I understand it this patch would induce the build cluster to build subversion-static.tbz (eventually) and put it on the package servers. So what happens when one of the underlying dependencies that you've included statically (those would possibly be: Oracle/SleepyCat DB, APR, expat, sqlite3, neon, gettext, and iconv) have security holes or major bugs found/addressed in them? As I understand it -- based on history -- the packages on the FTP servers get updated "whenever". My other post shows some haven't been updated in months (and yes I'm aware of the security incident). So how long would a key piece of software containing insecure statically-linked libraries be on the FTP servers? How would the port maintainer(s) even know the libraries/software which subversion is dependent upon had been updated, thus requiring a new subversion package to be pushed out to the package servers ASAP (i.e. immediately, not days, weeks, or months)? My point: ports have always been "best-effort". They are advertised vehemently throughout "everything FreeBSD" as being third-party software and therefore . Yet now critical pieces to FreeBSD development (and now end-users too, as a result of using the security incident to push SVN) rely upon something in ports. That's quite a conundrum the Project has created for itself, an ouroboros of sorts. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 23:05:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B85F957B for ; Wed, 23 Jan 2013 23:05:17 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id 51271790 for ; Wed, 23 Jan 2013 23:05:17 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id c13so1197497vea.19 for ; Wed, 23 Jan 2013 15:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u6/N/jyfep5sMnr0DQ0MceMzDV1IZfbn9yJNo+w/XF8=; b=NFNLPbxunkza70j+hRkylvO/91kaz6LkI0nZl/GeDOwIi1ACRQfBuqOwdiuv3snhOU lHVRNfW7kmFNb7BoO7Gv7AdTUqMm0cwEDFE9bhlTWbBNcOp+XCpFAaqcmmMrIjDMRa0h 4ZKwmJX1JnUvluwsJxJv7oV5FLx2FMnTB5XNg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=u6/N/jyfep5sMnr0DQ0MceMzDV1IZfbn9yJNo+w/XF8=; b=B32y3fFPYmYmxooIMHiFJlKSY3eS2wlKFEMUUH7p8vz2qQ9x3lxt6sJHKUqN1PkhPM mI7qkimklHWAwE8o0hFl9frvfS0mmGC9rGtfD+HHBuvqGcgcvMbvkhsg39WmOBjRANCI rQ1C+URHAdTcjZZGpLSgKmgbkPArsrxd/52IbDX+L9BRbQlboUIuX8ZAoSf02mBVa1e1 /pAvUXGT4r+NRcYxRgfq/bfaNhX6K9oJvSW2tZe6TYoI0BOFM7cSVbpptKKjwAxLSNgS Cj4prMNcfD+1A2ETKkqnds5s/oxW+xtDHT3tYHBGb7BlTFFbPKCbotmHruFSTGE84INx K1AQ== MIME-Version: 1.0 X-Received: by 10.52.88.168 with SMTP id bh8mr2932260vdb.51.1358982316380; Wed, 23 Jan 2013 15:05:16 -0800 (PST) Received: by 10.220.174.135 with HTTP; Wed, 23 Jan 2013 15:05:16 -0800 (PST) In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> Date: Wed, 23 Jan 2013 15:05:16 -0800 Message-ID: Subject: Re: svn - but smaller? From: Peter Wemm To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnkx8AYjFil0Y8WS16VlB68aMjbGX3+BS1yiOIZJxVXRoblxMdiRF5b1L/yXatoepSXdXTr Cc: Lev Serebryakov , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:05:17 -0000 On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees wrote: > On 23 January 2013 19:17, Emanuel Haupt wrote: >> devel/subversion already has an option to build a static version. A >> solution could be to create a stub port (devel/subversion-static) >> similar to: >> >> shells/bash-devel >> shells/bash-static-devel >> >> dns/ldns >> dns/py-ldns > > Great idea; > > http://www.bayofrum.net/~crees/patches/svn-static.diff No, you completely missed the point. Its not about static linking its embedded subversion libraries. I'm complaining about things like gdbm and bdb via apr, build dependencies like both python and perl for apr, and so on. If you made a port just to turn on the static option, it is equally as fail as before. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 23:16:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6BA17E4 for ; Wed, 23 Jan 2013 23:16:35 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8678E7F9 for ; Wed, 23 Jan 2013 23:16:35 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id fa15so5212557vbb.11 for ; Wed, 23 Jan 2013 15:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Pfk2tEGrLG1DCJkFJixkDjW/mZbDuB+mRb88PbOsOd4=; b=cp1JVk0Koeq4X8QHjmwCrM7MuqokB87EdDVr5f6BsNEOH0r+2NIFuCtBXyGCs5eix0 MfLxW5pVgu6bM1VAMu97XAF+qI0Wsqa8tRchYOA6tv0kbofP+kxLH6EtagV7X9G1hDga a+y3HZkwrAxwHiHSPHHyEBu6xhYpws1CGVfXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Pfk2tEGrLG1DCJkFJixkDjW/mZbDuB+mRb88PbOsOd4=; b=J9Gx42cqZIKx5DRdYvG+1aHqrwQqlh3vrmHlQejFxLhZq8B0/dzEjMnoTmPDQoM8pK xdasG97ofYJq/4MeEJHJ0/n5OHii3UO5FWAeIfwe5qVTGv5IYisT1y84NX2JBcpmKw+W Rencae7m6qiX+JEi+wQcNKI8uvM3ZStyQviSmEIq/RsvW5axfjcmXSWbUnc0AJQi3UTM xkUDAYZ8mDRYdpKZK5IrcYdTgAuDO59f2RCgTatm2M1k32n2keDAvVbL1j2a9OBLQtDc PK7Tp/73sW/UxAlTPBCqKnvmG0DXIFXNWm/z7ggOhZRkjXKPZchiMTOR70QeCvb028Mg LRHQ== MIME-Version: 1.0 X-Received: by 10.52.88.168 with SMTP id bh8mr2961930vdb.51.1358982989539; Wed, 23 Jan 2013 15:16:29 -0800 (PST) Received: by 10.220.174.135 with HTTP; Wed, 23 Jan 2013 15:16:29 -0800 (PST) In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> Date: Wed, 23 Jan 2013 15:16:29 -0800 Message-ID: Subject: Re: svn - but smaller? From: Peter Wemm To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlag+k/i9uknL1Z3g/NPQzO4N1AkyC2vf14+5J5q4ZcEU12ENdfhx/1PSWh2Nj4FHkd6+ig Cc: Lev Serebryakov , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:16:35 -0000 On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm wrote: > On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees wrote: >> On 23 January 2013 19:17, Emanuel Haupt wrote: >>> devel/subversion already has an option to build a static version. A >>> solution could be to create a stub port (devel/subversion-static) >>> similar to: >>> >>> shells/bash-devel >>> shells/bash-static-devel >>> >>> dns/ldns >>> dns/py-ldns >> >> Great idea; >> >> http://www.bayofrum.net/~crees/patches/svn-static.diff > > No, you completely missed the point. > > Its not about static linking its embedded subversion libraries. I'm > complaining about things like gdbm and bdb via apr, build dependencies > like both python and perl for apr, and so on. > > If you made a port just to turn on the static option, it is equally as > fail as before. Specific example.. doing a portsnap and build of devel/subversion out of the box, you get: ===>>> The following actions will be taken if you choose to proceed: Install devel/subversion Install databases/sqlite3 Install devel/pkgconf Install devel/apr1 Install converters/libiconv Install devel/libtool Install databases/db42 Install databases/gdbm Install devel/gmake Install devel/gettext Install devel/autoconf Install devel/autoconf-wrapper Install devel/m4 Install lang/perl5.14 Install misc/help2man Install devel/p5-Locale-gettext Install devel/automake Install devel/automake-wrapper Install lang/python27 Install textproc/expat2 Install www/neon29 You can thin it down a bit by turning off a few bits.. neon->serf helps a little but not much. Trimming some runtime (vs buildtime) grandchildren like apr's gdbm/bdb modules trims some license dependencies. I'll update that list when the build is finished. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 23:27:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5283CAD8 for ; Wed, 23 Jan 2013 23:27:19 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACDC86C for ; Wed, 23 Jan 2013 23:27:19 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id r0NNRG12015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Jan 2013 15:27:17 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id r0NNRGbj015514; Wed, 23 Jan 2013 15:27:16 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA22303; Wed, 23 Jan 13 15:20:48 PST Date: Wed, 23 Jan 2013 15:20:32 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: slw@zxy.spb.ru Subject: Re: svn - but smaller? Message-Id: <51006230.eHQyAK3KsVRgV52z%perryh@pluto.rain.com> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> <20130123162925.GA29224@zxy.spb.ru> In-Reply-To: <20130123162925.GA29224@zxy.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:27:19 -0000 Slawa Olhovchenkov wrote: > > pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz > Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: > > Depends on: > > ==== > > Static linked, NEON included, run on 6+. This posting looks like an announcement of a package available for download, but it doesn't look right for a pathname on freebsd.org and Google isn't finding it (either on freebsd.org, or elsewhere). From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 23:42:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF744D5E; Wed, 23 Jan 2013 23:42:03 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB9A8D4; Wed, 23 Jan 2013 23:42:03 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id r0NNBqhf085348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jan 2013 18:11:52 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: time issues and ZFS From: John Nielsen In-Reply-To: Date: Wed, 23 Jan 2013 16:11:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <575CDBE9-0FF3-4F93-A223-9F8FAF3FE936@jnielsen.net> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1499) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1117; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:42:04 -0000 On Jan 22, 2013, at 2:40 AM, Adrian Chadd wrote: > On Jan 21, 2013, at 4:33 AM, Daniel Braniss = wrote: >=20 >> host: DELL PowerEdge R710, 16GB,=20 I administer a Dell PowerEdge R710 and I've been seeing the exact same = thing. It's currently running FreeBSD 9.0-STABLE #0 r236355. It has a = ZFS pool which sees moderate load most of the time but can be very high = at times (when certain scripts run, etc.). I hadn't previously = correlated the issue with ZFS load but that is very possible. I set a cron job to restart ntpd when it dies (because the time = difference exceeds the sanity check). The cron job runs "every 20 = minutes", but that varies greatly when the system stops counting. The = time offset from ntpdate (which the script runs before restarting ntpd) = varies a lot, but always in increments of 300 seconds. I've seen = everything from 1200 to 23100. (Yes, that's 23 thousand seconds aka 6 = hours 25 minutes that the system wasn't keeping time for.) Sysctl kern.timecounter.hardware defaults to HPET. I experimented with = setting it to ACPI-fast but the issue persisted so I put it back. kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) = dummy(-1000000) I first installed the box with an older 9.0-STABLE and this issue was = not present. I have been tracking -STABLE on it (albeit irregularly) so = I'm not sure when the issue came up. > Have you run tests with the machdep.idle value changed, and fiddling > kern.eventtimer.periodic / kern.eventtimer.idletick ? I would love to resolve this and am able to do some experimenting. I've = _usually_ been seeing the issue 2-3 times every 1-2 days, but I did just = make some changes: disabling ZFS compression and deduplication on all pools updated to 9.1-STABLE from yesterday (r245821) If the issue persists I will try changing some of the sysctls above and = follow up with the result. If it goes away, I'll try to remember to = report that too. JN From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 23:59:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 785C350A for ; Wed, 23 Jan 2013 23:59:19 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by mx1.freebsd.org (Postfix) with ESMTP id 37AED980 for ; Wed, 23 Jan 2013 23:59:18 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id ff1so5713902vbb.15 for ; Wed, 23 Jan 2013 15:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8ghUt7U+Zf/Sypv0g1O8e6lT/RfxhvJh4wOa/W0hMhY=; b=CAxxdLANp8keDnn7+HvfylmNYGmGXTG4W8M25ZEGYTjUQUH6xfo3u3FTeA8CFDmwyR M+MhgGCghJDmAbvQXSXSicBKOoJQbcX3aIHXtfVLLBgyd856HYJc/1FwV47rR6M+sXGZ gdMOrLYkdgJgXcRBcgD88QiCXIh3LuY7wtl/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8ghUt7U+Zf/Sypv0g1O8e6lT/RfxhvJh4wOa/W0hMhY=; b=DaE9axam+9vgTJMc6gk5hhGbKATicezZM3MtViLZUWaf7Y1eRZwAHYkyp0fqZdqI74 cO2DgXKkPLoxRGHcb8A7HxGJ8FZvR43OQYhlnZbvn2Sw9Ny66KWfKMpSAH8Bpm4DRD4G RLnx8ZhQc87ULovWLARxcIkiuqN8LyyOx26a3NPjVhJCTijqIXGV0SdOvOUrM7JPQ4uW 2wvW0F5WUW77xWe9QJV9+6kWMlT1uxuqItKN0kSohLk4m+lwqod8fbbp1/oU6tT7xY7I T+tl9v3VB1Y9JSLqiWj8z5drP916U1XfbQOYWWMYiIpZgUCsyxLUH0ihqz3LXZ8Pyh94 cNRA== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr32460vcw.22.1358985557841; Wed, 23 Jan 2013 15:59:17 -0800 (PST) Received: by 10.220.174.135 with HTTP; Wed, 23 Jan 2013 15:59:17 -0800 (PST) In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> Date: Wed, 23 Jan 2013 15:59:17 -0800 Message-ID: Subject: Re: svn - but smaller? From: Peter Wemm To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm/4p+M2NgMi/eMieSrQaqUXrHmGAz79BdHVLWbL3JLmmkbsBWHCwJ3D0dTkwTwvz2huuhX Cc: Lev Serebryakov , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:59:19 -0000 On Wed, Jan 23, 2013 at 3:16 PM, Peter Wemm wrote: > On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm wrote: >> On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees wrote: >>> On 23 January 2013 19:17, Emanuel Haupt wrote: >>>> devel/subversion already has an option to build a static version. A >>>> solution could be to create a stub port (devel/subversion-static) >>>> similar to: >>>> >>>> shells/bash-devel >>>> shells/bash-static-devel >>>> >>>> dns/ldns >>>> dns/py-ldns >>> >>> Great idea; >>> >>> http://www.bayofrum.net/~crees/patches/svn-static.diff >> >> No, you completely missed the point. >> >> Its not about static linking its embedded subversion libraries. I'm >> complaining about things like gdbm and bdb via apr, build dependencies >> like both python and perl for apr, and so on. >> >> If you made a port just to turn on the static option, it is equally as >> fail as before. > > Specific example.. doing a portsnap and build of devel/subversion out > of the box, you get: > > ===>>> The following actions will be taken if you choose to proceed: > Install devel/subversion > Install databases/sqlite3 > Install devel/pkgconf > Install devel/apr1 > Install converters/libiconv > Install devel/libtool > Install databases/db42 > Install databases/gdbm > Install devel/gmake > Install devel/gettext > Install devel/autoconf > Install devel/autoconf-wrapper > Install devel/m4 > Install lang/perl5.14 > Install misc/help2man > Install devel/p5-Locale-gettext > Install devel/automake > Install devel/automake-wrapper > Install lang/python27 > Install textproc/expat2 > Install www/neon29 > > You can thin it down a bit by turning off a few bits.. neon->serf > helps a little but not much. Trimming some runtime (vs buildtime) > grandchildren like apr's gdbm/bdb modules trims some license > dependencies. I'll update that list when the build is finished. FWIW, this is the runtime dependency list apr-1.4.6.1.4.1_3 Apache Portability Library expat-2.0.1_2 XML 1.0 parser written in C gettext-0.18.1.1 GNU gettext package libiconv-1.14 A character set conversion library pkg-1.0.4_1 New generation package manager pkgconf-0.8.9 Utility to help to configure compiler and linker flags serf-1.1.1 Serf HTTP client library sqlite3-3.7.14.1 An SQL database engine in a C library subversion-1.7.8 Version control system Doing a static link of the libsvn_* libraries into the binary doesn't help with this. > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV > bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 04:01:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B076F351 for ; Thu, 24 Jan 2013 04:01:45 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6B63C374 for ; Thu, 24 Jan 2013 04:01:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1TyE51-000CRj-Ok; Thu, 24 Jan 2013 08:06:23 +0400 Date: Thu, 24 Jan 2013 08:06:23 +0400 From: Slawa Olhovchenkov To: Perry Hutchison Subject: Re: svn - but smaller? Message-ID: <20130124040623.GN67643@zxy.spb.ru> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> <20130123162925.GA29224@zxy.spb.ru> <51006230.eHQyAK3KsVRgV52z%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51006230.eHQyAK3KsVRgV52z%perryh@pluto.rain.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 04:01:45 -0000 On Wed, Jan 23, 2013 at 03:20:32PM -0800, Perry Hutchison wrote: > Slawa Olhovchenkov wrote: > > > pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz > > Information for /usr/ports/packages6/All/subversion-1.7.8.tbz: > > > > Depends on: > > > > ==== > > > > Static linked, NEON included, run on 6+. > > This posting looks like an announcement of a package available for > download, but it doesn't look right for a pathname on freebsd.org > and Google isn't finding it (either on freebsd.org, or elsewhere). I am don't have account on FreeBSD.org. http://zxy.spb.ru/subversion-1.7.8.tbz 17MB for downloading. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 06:24:41 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1DC18CA; Thu, 24 Jan 2013 06:24:41 +0000 (UTC) (envelope-from ehaupt@FreeBSD.org) Received: from mx.critical.ch (mx.critical.ch [IPv6:2001:1620:f05::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3D693922; Thu, 24 Jan 2013 06:24:41 +0000 (UTC) Received: from beaver.home.critical.ch (84-72-7-76.dclient.hispeed.ch [84.72.7.76]) (authenticated bits=0) by mx.critical.ch (8.14.4/8.14.4/critical-1.0) with ESMTP id r0O6OdCe012852; Thu, 24 Jan 2013 07:24:40 +0100 (CET) (envelope-from ehaupt@FreeBSD.org) Date: Thu, 24 Jan 2013 07:24:38 +0100 From: Emanuel Haupt To: Peter Wemm Subject: Re: svn - but smaller? Message-Id: <20130124072438.d88c620591fbdcf590d2ea60@FreeBSD.org> In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Chris Rees , Lev Serebryakov , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 06:24:41 -0000 Peter Wemm wrote: > On Wed, Jan 23, 2013 at 3:16 PM, Peter Wemm wrote: > > On Wed, Jan 23, 2013 at 3:05 PM, Peter Wemm wrote: > >> On Wed, Jan 23, 2013 at 1:25 PM, Chris Rees > >> wrote: > >>> On 23 January 2013 19:17, Emanuel Haupt > >>> wrote: > >>>> devel/subversion already has an option to build a static > >>>> version. A solution could be to create a stub port > >>>> (devel/subversion-static) similar to: > >>>> > >>>> shells/bash-devel > >>>> shells/bash-static-devel > >>>> > >>>> dns/ldns > >>>> dns/py-ldns > >>> > >>> Great idea; > >>> > >>> http://www.bayofrum.net/~crees/patches/svn-static.diff > >> > >> No, you completely missed the point. > >> > >> Its not about static linking its embedded subversion libraries. > >> I'm complaining about things like gdbm and bdb via apr, build > >> dependencies like both python and perl for apr, and so on. > >> > >> If you made a port just to turn on the static option, it is > >> equally as fail as before. > > > > Specific example.. doing a portsnap and build of devel/subversion > > out of the box, you get: > > > > ===>>> The following actions will be taken if you choose to proceed: > > Install devel/subversion > > Install databases/sqlite3 > > Install devel/pkgconf > > Install devel/apr1 > > Install converters/libiconv > > Install devel/libtool > > Install databases/db42 > > Install databases/gdbm > > Install devel/gmake > > Install devel/gettext > > Install devel/autoconf > > Install devel/autoconf-wrapper > > Install devel/m4 > > Install lang/perl5.14 > > Install misc/help2man > > Install devel/p5-Locale-gettext > > Install devel/automake > > Install devel/automake-wrapper > > Install lang/python27 > > Install textproc/expat2 > > Install www/neon29 > > > > You can thin it down a bit by turning off a few bits.. neon->serf > > helps a little but not much. Trimming some runtime (vs buildtime) > > grandchildren like apr's gdbm/bdb modules trims some license > > dependencies. I'll update that list when the build is finished. > > FWIW, this is the runtime dependency list > apr-1.4.6.1.4.1_3 Apache Portability Library > expat-2.0.1_2 XML 1.0 parser written in C > gettext-0.18.1.1 GNU gettext package > libiconv-1.14 A character set conversion library > pkg-1.0.4_1 New generation package manager > pkgconf-0.8.9 Utility to help to configure compiler > and linker flags > serf-1.1.1 Serf HTTP client library > sqlite3-3.7.14.1 An SQL database engine in a C library > subversion-1.7.8 Version control system > > Doing a static link of the libsvn_* libraries into the binary doesn't > help with this. This is all I have in my buildjail: root@portjail:/root # uname -a FreeBSD portjail.home.critical.ch 9.1-STABLE FreeBSD 9.1-STABLE #1 r245789: Tue Jan 22 16:30:35 CET 2013 root@alaska.home.critical.ch:/usr/obj/usr/src/sys/GENERIC amd64 root@portjail:/root # pkg_info subversion-1.7.8 Version control system All this is is a package built with the default options of devel/subversion plus STATIC. I am perfectly able to use http as a chekout method: root@portjail:/root # svn checkout --depth empty http://svn.FreeBSD.org/ports/head/audio/yell ports/audio/yell Checked out revision 310914. root@portjail:/root # svn update --set-depth infinity ports/audio/yell/ Updating 'ports/audio/yell': A ports/audio/yell/distinfo A ports/audio/yell/pkg-descr A ports/audio/yell/Makefile Updated to revision 310914. root@portjail:/root # svn info ports/audio/yell/ Path: ports/audio/yell Working Copy Root Path: /root/ports/audio/yell URL: http://svn.freebsd.org/ports/head/audio/yell Repository Root: http://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 310914 Node Kind: directory Schedule: normal Last Changed Author: ehaupt Last Changed Rev: 306932 Last Changed Date: 2012-11-03 19:01:22 +0100 (Sat, 03 Nov 2012) Hence, to come back to the original post $ pkg_add -r subversion-static is the equivalent of $ pkg_add -r cvsup-without-gui Emanuel From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 06:38:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07B48C5B for ; Thu, 24 Jan 2013 06:38:52 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9E2997 for ; Thu, 24 Jan 2013 06:38:51 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id d12so2906417eaa.38 for ; Wed, 23 Jan 2013 22:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=/OD3gHEzKkP10HVfyXujO0XheG9U5qbi1/BT2emzVNw=; b=akoHBj4K/CcfmNt4HZxyXzjgGxCzcPPPe0eu8NOeSFHUIjnQquY3uDTWDdkuF8V8ue 8X0xyhIJGR/Xsp+KMH9wrsE9Xs/HkP9GJujWvgwEliBY5yWVCE6wbzTdG0iXtysBeXtj GF10A/nv15L0ZcWEqKEzu9KobF1xsBExlgiVqugy37ivARLpEl3m3QLOQCLWcHG9L1g5 S3VagqTJO7rUs0z5IYRHFenSARw2CMKfmnTLKi6ZeXwUbtpBCVjwchxIGiGpIN7tNRZG LtDney90j95r2Nvgn7/d1lH3/QPtJYRwo4/NQL2uXnGQtbrEKeA7Y7ytzj6RZbIU3Gj/ Esfg== X-Received: by 10.14.225.133 with SMTP id z5mr3259117eep.15.1359009525663; Wed, 23 Jan 2013 22:38:45 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id 44sm1567527eek.5.2013.01.23.22.38.44 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 23 Jan 2013 22:38:44 -0800 (PST) Date: Thu, 24 Jan 2013 09:38:46 +0300 From: "Sergey V. Dyatko" To: Oliver Brandmueller Subject: Re: svn - but smaller? Message-ID: <20130124093846.5e683474@laptop> In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> References: <20130123144050.GG51786@e-Gitt.NET> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 06:38:52 -0000 On Wed, 23 Jan 2013 15:40:50 +0100 Oliver Brandmueller wrote: > Hi, [skipped] > So, is there some alternative small svn client, that leaves a > drastically smaller footprint probably somewhere around, probably > even in the ports or is there anything I'm missing? The current > situaion for me is a bit annoying. From the user's or admin's point > of view at least. I didn't even see an option in svn to not build the > server components, which would probably already help to make things > smaller? > You may: 1/ install subversion on some host/jail 2/ do svn export ( f.e. svn://svn.freebsd.org/base/releng/9 stable_9) 3/ tar it 4/ on 'client' fetch(1)/scp/rsync tarball in that case you don't need svn on 'client', fetch and scp in base :) -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 06:50:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 90056EAC; Thu, 24 Jan 2013 06:50:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 435D6A07; Thu, 24 Jan 2013 06:50:14 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TyGdP-00031f-7E; Thu, 24 Jan 2013 08:50:03 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: John Nielsen Subject: Re: time issues and ZFS In-reply-to: <575CDBE9-0FF3-4F93-A223-9F8FAF3FE936@jnielsen.net> References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> <575CDBE9-0FF3-4F93-A223-9F8FAF3FE936@jnielsen.net> Comments: In-reply-to John Nielsen message dated "Wed, 23 Jan 2013 16:11:57 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jan 2013 08:50:02 +0200 From: Daniel Braniss Message-ID: Cc: Adrian Chadd , freebsd-stable@freebsd.org, Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 06:50:15 -0000 > On Jan 22, 2013, at 2:40 AM, Adrian Chadd wrote:= > > > On Jan 21, 2013, at 4:33 AM, Daniel Braniss = wrote: > >=20 > >> host: DELL PowerEdge R710, 16GB,=20 >=20 > I administer a Dell PowerEdge R710 and I've been seeing the exact same = =3Dthing. It's currently running FreeBSD 9.0-STABLE =230 r236355. It has = a =3DZFS pool which sees moderate load most of the time but can be very h= igh =3Dat times (when certain scripts run, etc.). I hadn't previously =3D= correlated the issue with ZFS load but that is very possible.> > I set a = cron job to restart ntpd when it dies (because the time =3Ddifference exc= eeds the sanity check). The cron job runs =22every 20 =3Dminutes=22, but = that varies greatly when the system stops counting. The =3Dtime offset fr= om ntpdate (which the script runs before restarting ntpd) =3Dvaries a lot= , but always in increments of 300 seconds. I've seen =3Deverything from 1= 200 to 23100. (Yes, that's 23 thousand seconds aka 6 =3Dhours 25 minutes = that the system wasn't keeping time for.) >=20 > Sysctl kern.timecounter.hardware defaults to HPET. I experimented with = =3Dsetting it to ACPI-fast but the issue persisted so I put it back. > kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0= ) =3Ddummy(-1000000)> > I first installed the box with an older 9.0-STABL= E and this issue was =3Dnot present. I have been tracking -STABLE on it (= albeit irregularly) so =3DI'm not sure when the issue came up. >=20 >=20 > Have you run tests with the machdep.idle value changed, and fiddling >=20 > kern.eventtimer.periodic / kern.eventtimer.idletick ? >=20 > I would love to resolve this and am able to do some experimenting. I've= =3D_usually_ been seeing the issue 2-3 times every 1-2 days, but I did j= ust =3Dmake some changes: > disabling ZFS compression and deduplication on all pools > updated to 9.1-STABLE from yesterday (r245821) >=20 > If the issue persists I will try changing some of the sysctls above and= =3Dfollow up with the result. If it goes away, I'll try to remember to = =3Dreport that too. >=20 > JN >=20 set kern.eventtimer.timer=3DLAPIC this solved it for me. danny From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 07:36:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B52B9355 for ; Thu, 24 Jan 2013 07:36:34 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id 24F8EB19 for ; Thu, 24 Jan 2013 07:36:33 +0000 (UTC) Received: from nskntcmgw06p ([61.9.169.166]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20130124073625.QRVO24726.nskntmtas05p.mx.bigpond.com@nskntcmgw06p>; Thu, 24 Jan 2013 07:36:25 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw06p with BigPond Outbound id rjcP1k00b5LKYmq01jcPM1; Thu, 24 Jan 2013 07:36:25 +0000 X-Authority-Analysis: v=2.0 cv=FNSZNpUs c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=KTtz0Dv9PsYA:10 a=fhNZRPknwttJQfm4QcMA:9 a=CjuIK1q_8ugA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r0O7Z2jM063712 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jan 2013 18:35:03 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne" To: "'Oliver Brandmueller'" References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> Subject: RE: svn - but smaller? Date: Thu, 24 Jan 2013 18:34:33 +1100 Organization: Heuristic Systems Pty Ltd Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac35/VV+kyTWxHXAQf60Qen+i6MOzwAAJszw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <20130124093846.5e683474@laptop> Cc: 'Jeremy Chadwick' , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 07:36:34 -0000 The objective is to return to a base build of FreeBSD that performs the expected task of being able to pull source, without having to acquire a port. Regardless of our individual solutions/workarounds, the task is to pull and maintain source. Is the discussion going to result in something like svn-lite that enters into the /usr/src/contrib along with the responsibilities associated with maintaining it? And then we need to take into consideration of being overwriting the "base svn" with a full svn package, if required by the user/admin. The issue involves policy decisions along with ongoing support load, rather than just a good technical solution; which as we've seen in earlier discussions, is sorely needed by the folks doing the development/maintenance. In the meantime, ftp isn't really workable for ongoing updates, and rsync is GPL'ed and can't be in the base system. I build svn from ports with all options off except for: ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn program. Suites me but doesn't address the underlying problem - and I don't think that the plan is to make FreeBSD dependent upon the ports system (for subversion) Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 08:09:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF86CB3C; Thu, 24 Jan 2013 08:09:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 65B32D9F; Thu, 24 Jan 2013 08:09:54 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:4400:f9ea:e0ba:b2b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 2CF884AC32; Thu, 24 Jan 2013 12:09:52 +0400 (MSK) Date: Thu, 24 Jan 2013 12:09:48 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1106716462.20130124120948@serebryakov.spb.ru> To: Peter Wemm Subject: Re: svn - but smaller? In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130123201734.be0f9e715289c29e1b03c393@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Chris Rees , FreeBSD , Emanuel Haupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 08:09:54 -0000 Hello, Peter. You wrote 24 =FF=ED=E2=E0=F0=FF 2013 =E3., 3:05:16: PW> Its not about static linking its embedded subversion libraries. I'm This port will link statically EVERYTHING, what gets you PACKAGE without dependencies. PW> complaining about things like gdbm and bdb via apr, build dependencies bdb abd gdbm is optional. PW> like both python and perl for apr, and so on. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 08:32:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6C0611F for ; Thu, 24 Jan 2013 08:32:10 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 92B50E91 for ; Thu, 24 Jan 2013 08:32:10 +0000 (UTC) Received: from [10.173.229.233] (117.sub-70-197-135.myvzw.com [70.197.135.117]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id r0O86tg5044309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Jan 2013 00:06:56 -0800 (PST) (envelope-from takeda@takeda.tk) User-Agent: K-9 Mail for Android In-Reply-To: <20130124093846.5e683474@laptop> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: svn - but smaller? From: Derek Kulinski Date: Thu, 24 Jan 2013 00:06:47 -0800 To: "Sergey V. Dyatko" , Oliver Brandmueller Message-ID: <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 08:32:10 -0000 "Sergey V. Dyatko" wrote: >You may: >1/ install subversion on some host/jail >2/ do svn export ( f.e. svn://svn.freebsd.org/base/releng/9 stable_9) >3/ tar it >4/ on 'client' fetch(1)/scp/rsync tarball > >in that case you don't need svn on 'client', fetch and scp in base :) If you go through all of that why not just install the damn svn from ports? I think you don't understand the reason why people are asking for this. I personally experienced the need not long ago. I had stable/9 branch and wanted to downgrade to 9.0. The entire process went well until I rebooted the system, to see tons of errors in pretty much everything that was compiled from ports. Instead recompiling them from scratch I just decided to go ahead and upgrade to 9.1 which was not officially released yet. And of course I could not perform svn sw because svn was broken too. And since svn has tons of dependencies it took me nearly an hour to recompile them (portupgrade and Ruby were broken too). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 08:49:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5CE452D for ; Thu, 24 Jan 2013 08:49:36 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id C6E3AF46 for ; Thu, 24 Jan 2013 08:49:36 +0000 (UTC) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) by mbox1.develooper.com (Postfix) with ESMTP id 6E7ED175AD3 for ; Thu, 24 Jan 2013 00:49:36 -0800 (PST) Received: (qmail 31213 invoked from network); 24 Jan 2013 08:49:36 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 24 Jan 2013 08:49:36 -0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: Date: Thu, 24 Jan 2013 00:49:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <578B00AD-8524-4EE1-83D3-CFD1B739AC96@develooper.com> References: To: "freebsd-stable@freebsd.org" , freebsd-embedded@freebsd.org X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 08:49:37 -0000 On Jan 24, 2013, at 0:48, Ask Bj=F8rn Hansen wrote: > Hi everyone, >=20 > I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few = days ago. >=20 > Booting the new image on a pcEngines Alix board it panics with a = "kmem_map too small" error when mounting the disk. Any ideas what I'm = doing wrong? In case it's useful, below is the full boot sequence. Ask PC Engines ALIX.2 v0.99h 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 848A SanDisk SDCFJ-256 =20 Phys C/H/S 980/16/32 Log C/H/S 248/32/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 2=20 /boot/config: -h FreeBSD/x86 boot Default: 0:ad(0,a)/boot/loader boot: Consoles: serial port =20 BIOS drive C: is disk0 BIOS 640kB/130048kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@fbsdvm, Wed Jan 23 14:28:25 PST 2013) Loading /boot/defaults/loader.conf=20 /boot/kernel/kernel text=3D0x928f64 data=3D0x68a6c+0x89cb0 = syms=3D[0x4+0x8d9e0+0x4+0xcc4ec] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Copyright (c) 1992-2013 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 9.1-STABLE #0: Wed Jan 23 14:51:17 PST 2013 root@fbsdvm:/usr/obj/nanobsd.grundwall/usr/src/sys/GRUNDCLOCK i386 CPU: Geode(TM) Integrated Processor by AMD PCS (431.65-MHz 586-class = CPU) Origin =3D "AuthenticAMD" Id =3D 0x5a2 Family =3D 0x5 Model =3D 0xa = Stepping =3D 2 Features=3D0x88a93d AMD Features=3D0xc0400000 real memory =3D 134217728 (128 MB) avail memory =3D 116412416 (111 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) cryptosoft0: on motherboard pcib0 pcibus 0 on motherboard pci0: on pcib0 Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 glxsb0: mem = 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 vr0: port 0x1000-0x10ff mem = 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow vr0: Ethernet address: 00:0d:b9:12:99:ec vr1: port 0x1400-0x14ff mem = 0xe0040000-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x2 vr1: Revision: 0x96 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow vr1: Ethernet address: 00:0d:b9:12:99:ed vr2: port 0x1800-0x18ff mem = 0xe0080000-0xe00800ff irq 15 at device 11.0 on pci0 vr2: Quirks: 0x2 vr2: Revision: 0x96 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow vr2: Ethernet address: 00:0d:b9:12:99:ee isab0: port = 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at = device 15.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 ohci0: mem 0xefffe000-0xefffefff irq 12 = at device 15.4 on pci0 usbus0 on ohci0 ehci0: mem 0xefffd000-0xefffdfff = irq 12 at device 15.5 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 cpu0 on motherboard orm0: at iomem 0xe0000-0xea7ff pnpid ORM0000 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on = isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 ctl: CAM Target Layer loaded Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to = accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded 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 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-4 device ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 245MB (501760 512 byte sectors: 16H 32S/T 980C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 431653248 Hz quality 800 Root mount waiting for: usbus1 usbus0 uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 uhub1: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ada0s2a [ro]... panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated cpuid =3D 0 KDB: stack backtrace: #0 0xc089b0ff at kdb_backtrace+0x4f #1 0xc08678af at panic+0x16f #2 0xc0b0848a at kmem_malloc+0x28a #3 0xc0afbc87 at page_alloc+0x27 #4 0xc0afe320 at uma_large_malloc+0x50 #5 0xc085142c at malloc+0x8c #6 0xc07cedc0 at g_read_data+0x50 #7 0xc07d45f8 at g_label_ufs_taste_common+0x98 #8 0xc07d485b at g_label_ufs_id_taste+0x1b #9 0xc07d35ec at g_label_taste+0x3ec #10 0xc07d075f at g_new_provider_event+0x5f #11 0xc07ce205 at g_run_events+0x265 #12 0xc07cf6e9 at g_event_procbody+0x69 #13 0xc08366f6 at fork_exit+0x96 #14 0xc0b59e64 at fork_trampoline+0x8 Uptime: 13s Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 08:57:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC0646F8 for ; Thu, 24 Jan 2013 08:57:20 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id AD130F9E for ; Thu, 24 Jan 2013 08:57:20 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id rkxD1k0031smiN4A1kxJ16; Thu, 24 Jan 2013 08:57:18 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id rkxH1k0081t3BNj8gkxHnD; Thu, 24 Jan 2013 08:57:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1B16673A1C; Thu, 24 Jan 2013 00:57:17 -0800 (PST) Date: Thu, 24 Jan 2013 00:57:17 -0800 From: 'Jeremy Chadwick' To: Dewayne Subject: Re: svn - but smaller? Message-ID: <20130124085717.GA26673@icarus.home.lan> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359017838; bh=l18w6bS8rzCE5aEP1t4FwysTEweTiU/Scz8ANd8930c=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=a9bOBds+vfK+nvvTrudulfTzNvvwPHcSDqLlxhpiId3aEhJ090IXqonAaRTTJnR5s 4Za0Mf7OK/likYrKdbOENy69x9B5JNI9iX/ZA5FV0mJNqDu26Dh+3Lw1aGnF3qZB77 O/V2CFAYfFabsUQqvJ5qkinRW3TElcfG4PIc6B7qRzJNSlwb6yC2A1ZGZybA+ZxyVU m/rAe1OZ5CRsuL2rIHlLEMik53vfPMP/G6CO7kzID+tSUc74k0P9PC+cjziZoF1nRm 7pBwb/Lpou2xhorJTVCjdgR31kGiEWjL7sksTChH40mGzdn4m8cOi//8/uY8ivR9Gt +rrzC9Y6VO+Ew== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 08:57:20 -0000 On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote: > The objective is to return to a base build of FreeBSD that performs > the expected task of being able to pull source, without having to > acquire a port. Regardless of our individual solutions/workarounds, > the task is to pull and maintain source. > > Is the discussion going to result in something like svn-lite that > enters into the /usr/src/contrib along with the responsibilities > associated with maintaining it? And then we need to take into > consideration of being overwriting the "base svn" with a full svn > package, if required by the user/admin. Regarding your "svn-lite" theory of having that added to src/contrib/, let me introduce you to Subversion's actual dependencies, and I'll explain why these would have to remain enabled (for a "base system" Subversion) as well: * SQLite3 (used for bits/pieces in .svn/ directories) -- License: http://www.sqlite.org/copyright.html -- Not in the base system * APR (used for HTTP fetching (not necessarily HTTPS)) -- License: http://www.apache.org/licenses/LICENSE-2.0.html -- Not in the base system * Expat 2.x (XML parsing/generation library -- License: http://en.wikipedia.org/wiki/MIT_License -- Not in the base system * Neon or Serf (used for HTTPS fetching) -- Neon license: http://www.gnu.org/copyleft/lgpl.html -- Serf license: http://www.apache.org/licenses/LICENSE-2.0 -- Neither are in the base system -- Serf supposedly has some kind of wonky/weird bugs on FreeBSD; I remember reading about these on the mailing lists or in PRs, combined with some statement about how newer Subversion uses Serf exclusively? * gettext and libintl (used for character set support) -- gettext license: GPL (not sure what version) -- libintl license: LGPL (not sure what version) -- Neither are in the base system * libiconv (used for character set conversion) -- License: LGPL (not sure what version) -- Not in the base system Why would all of these third-party bits be required? Keep reading. > The issue involves policy decisions along with ongoing support load, > rather than just a good technical solution; which as we've seen in > earlier discussions, is sorely needed by the folks doing the > development/maintenance. > > In the meantime, ftp isn't really workable for ongoing updates, and > rsync is GPL'ed and can't be in the base system. > > I build svn from ports with all options off except for: > ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn > program. Suites me but doesn't address the underlying problem - and I > don't think that the plan is to make FreeBSD dependent upon the ports > system (for subversion) Though your OPTIONS recommendations work for you, they do not work for everyone. Some people sit behind firewalls where HTTP or HTTPS are the only viable means (native SVN or SVN+SSH will not work for them). Thus, any kind of "base system svn-lite" would need to offer all of these out-of-the-box, hence the above dependency list becoming mandatory. src.conf WITHOUT_x knobs could turn some of these off, but they'd still have to become part of src/contrib/. FreeBSD for many years has been trying to remove "non-BSD-compatible" software from the base system. I can't find the statement but the move towards LLVM/Clang is partially driven by this, as well as the push to move from GNU grep to bsdgrep. Now, review the above dependencies and ask yourself the likelihood of all of those being brought into src/ any where. I imagine given its large dependency count on software that has "non-BSD-compatible" licenses, that statement likely proves true. I believe there was also a statement made in passing on the mailing lists not too long ago mentioning that Subversion would never be brought into the base system for that reason. I would love (LOVE!) to find out there are plans to move it into the base system, but I can't see how given the above. As for your last line: FreeBSD is already dependent upon Subversion. This has been the case for quite some time, but has only recently (as an indirect result of the security incident) become forced upon users/administrators of FreeBSD. The entire project is presently managed/maintained under Subversion. The Handbook now documents that if you want to pull down src/ you need to install Subversion. If you want to pull down ports/ you can use portsnap and waste lots of /var space, hoping that the portsnap mirrors are up to date, and a bunch of other hullabaloo... or you could just use Subversion and be done with it. There is no more cvsup. There is no more csup. There is no more cvs. There is only Subversion ("there is only Zuul..."). I do not want to talk about the whole security incident situation because it's another topic that makes me quite volatile. Also, just as a footnote point to readers: please do not bring up svnsup. Until it's stated by some official FreeBSD person that "{committers} are actively working on this and bringing it into the base system so people can get src/ports without installing ports/devel/subversion", it's not pragmatic to mention it as a *solution*. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:09:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 166D8A2A for ; Thu, 24 Jan 2013 09:09:24 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id F216DBB for ; Thu, 24 Jan 2013 09:09:23 +0000 (UTC) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) by mbox1.develooper.com (Postfix) with ESMTP id 6E706175AA7 for ; Thu, 24 Jan 2013 00:48:25 -0800 (PST) Received: (qmail 30956 invoked from network); 24 Jan 2013 08:48:25 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 24 Jan 2013 08:48:25 -0000 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated Message-Id: Date: Thu, 24 Jan 2013 00:48:24 -0800 To: "freebsd-stable@freebsd.org" , freebsd-embedded@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:09:24 -0000 Hi everyone, I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few = days ago. Booting the new image on a pcEngines Alix board it panics with a = "kmem_map too small" error when mounting the disk. Any ideas what I'm = doing wrong? Ask Trying to mount root from ufs:/dev/ada0s2a [ro]... panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated cpuid =3D 0 KDB: stack backtrace: #0 0xc089b0ff at kdb_backtrace+0x4f #1 0xc08678af at panic+0x16f #2 0xc0b0848a at kmem_malloc+0x28a #3 0xc0afbc87 at page_alloc+0x27 #4 0xc0afe320 at uma_large_malloc+0x50 #5 0xc085142c at malloc+0x8c #6 0xc07cedc0 at g_read_data+0x50 #7 0xc07d45f8 at g_label_ufs_taste_common+0x98 #8 0xc07d485b at g_label_ufs_id_taste+0x1b #9 0xc07d35ec at g_label_taste+0x3ec #10 0xc07d075f at g_new_provider_event+0x5f #11 0xc07ce205 at g_run_events+0x265 #12 0xc07cf6e9 at g_event_procbody+0x69 #13 0xc08366f6 at fork_exit+0x96 #14 0xc0b59e64 at fork_trampoline+0x8 Uptime: 13s Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:11:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6639AB79 for ; Thu, 24 Jan 2013 09:11:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 27DCCE4 for ; Thu, 24 Jan 2013 09:11:05 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1TyIuL-000FFV-35; Thu, 24 Jan 2013 13:15:41 +0400 Date: Thu, 24 Jan 2013 13:15:41 +0400 From: Slawa Olhovchenkov To: 'Jeremy Chadwick' Subject: Re: svn - but smaller? Message-ID: <20130124091541.GA54431@zxy.spb.ru> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130124085717.GA26673@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:11:05 -0000 On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy Chadwick' wrote: > Regarding your "svn-lite" theory of having that added to src/contrib/, > let me introduce you to Subversion's actual dependencies, and I'll > explain why these would have to remain enabled (for a "base system" > Subversion) as well: > * gettext and libintl (used for character set support) Not need. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:16:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4578CF13; Thu, 24 Jan 2013 09:16:41 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id A30BF152; Thu, 24 Jan 2013 09:16:40 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by dkim.mail.arcticgroup.se (Postfix) with ESMTP id 9C1051CE4B; Thu, 24 Jan 2013 10:16:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=KInpzee oFOyVo9v71aRiGouKA58=; b=bgGUAS60X2dylkdO5Ro8fGEEeBVaypgayIl7jvs XE+zRRe4Hi9ewt8Ku1ABsqyMWzirQkyruxXf1obc9ZHDVBWJL5S8RZxRH0h+XvE/ HkT56LRXuDZM+qZvPBeIDu/R+ZJ7985LRRw1jJ4j8jLlSLxMJwaPR20tPMQc8Spr +oYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=U 6HyqapNe9Gd32Eif4OvT8ipObZr0l1DkII7c+YlIgfGujQM5fK46KWasoFsuGTQj bHsD5hNh4neI3uGf3XfIzwBZZ4pxCBStoM743xjzTAaiQrnu9xr6VCyH12BrLJpl RZAqOJU5xtPHoGX+j76IUePEIk90VF8lOOPI7MemDY= Received: from [172.16.2.60] (glz-macbookpro.hq.ismobile.com [172.16.2.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 82B9B1CE01; Thu, 24 Jan 2013 10:16:38 +0100 (CET) Date: Thu, 24 Jan 2013 10:16:39 +0100 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= , freebsd-stable@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated Message-ID: <7CE2F5AC86689C2624BC1F2F@[172.16.2.60]> In-Reply-To: <578B00AD-8524-4EE1-83D3-CFD1B739AC96@develooper.com> References: <578B00AD-8524-4EE1-83D3-CFD1B739AC96@develooper.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:16:41 -0000 --On January 24, 2013 0:49:35 -0800 Ask Bj=C3=B8rn Hansen = =20 wrote: > > On Jan 24, 2013, at 0:48, Ask Bj=C3=B8rn Hansen = wrote: > >> Hi everyone, >> >> I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few >> days ago. >> >> Booting the new image on a pcEngines Alix board it panics with a >> "kmem_map too small" error when mounting the disk. Any ideas what I'm >> doing wrong? > > In case it's useful, below is the full boot sequence. > > Ask > > > PC Engines ALIX.2 v0.99h > 640 KB Base Memory > 130048 KB Extended Memory > > 01F0 Master 848A SanDisk SDCFJ-256 > Phys C/H/S 980/16/32 Log C/H/S 248/32/63 > > 1 FreeBSD > 2 FreeBSD > > F6 PXE > Boot: 2 > /boot/config: -h > > FreeBSD/x86 boot > Default: 0:ad(0,a)/boot/loader > boot: Consoles: serial port > BIOS drive C: is disk0 > BIOS 640kB/130048kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > (root@fbsdvm, Wed Jan 23 14:28:25 PST 2013) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x928f64 data=3D0x68a6c+0x89cb0 > syms=3D[0x4+0x8d9e0+0x4+0xcc4ec] \ > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Copyright (c) 1992-2013 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 9.1-STABLE #0: Wed Jan 23 14:51:17 PST 2013 > root@fbsdvm:/usr/obj/nanobsd.grundwall/usr/src/sys/GRUNDCLOCK i386 > CPU: Geode(TM) Integrated Processor by AMD PCS (431.65-MHz 586-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x5a2 Family =3D 0x5 Model =3D 0xa > Stepping =3D 2 > Features=3D0x88a93d = AMD > Features=3D0xc0400000 > real memory =3D 134217728 (128 MB) > avail memory =3D 116412416 (111 MB) > pnpbios: Bad PnP BIOS data checksum > K6-family MTRR support enabled (2 registers) > cryptosoft0: on motherboard > pcib0 pcibus 0 on motherboard > pci0: on pcib0 > Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 vr0: III 10/100BaseTX> port 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at > device 9.0 on pci0 vr0: Quirks: 0x2 > vr0: Revision: 0x96 > miibus0: on vr0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow vr0: Ethernet address: 00:0d:b9:12:99:ec > vr1: port 0x1400-0x14ff mem > 0xe0040000-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x2 > vr1: Revision: 0x96 > miibus1: on vr1 > ukphy1: PHY 1 on miibus1 > ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow vr1: Ethernet address: 00:0d:b9:12:99:ed > vr2: port 0x1800-0x18ff mem > 0xe0080000-0xe00800ff irq 15 at device 11.0 on pci0 vr2: Quirks: 0x2 > vr2: Revision: 0x96 > miibus2: on vr2 > ukphy2: PHY 1 on miibus2 > ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow vr2: Ethernet address: 00:0d:b9:12:99:ee > isab0: port > 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at > device 15.0 on pci0 isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > ohci0: mem 0xefffe000-0xefffefff irq 12 > at device 15.4 on pci0 usbus0 on ohci0 > ehci0: mem 0xefffd000-0xefffdfff > irq 12 at device 15.5 on pci0 usbus1: EHCI version 1.0 > usbus1 on ehci0 > cpu0 on motherboard > orm0: at iomem 0xe0000-0xea7ff pnpid ORM0000 on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > atrtc0: at port 0x70 irq 8 on isa0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: at port 0x40 on isa0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > ctl: CAM Target Layer loaded > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to > accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched WF2Q+ loaded > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > 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 > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: CFA-4 device > ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) > ada0: 245MB (501760 512 byte sectors: 16H 32S/T 980C) > ada0: Previously was known as ad0 > Timecounter "TSC" frequency 431653248 Hz quality 800 > Root mount waiting for: usbus1 usbus0 > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 4 ports with 4 removable, self powered > Trying to mount root from ufs:/dev/ada0s2a [ro]... > panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated > cpuid =3D 0 > KDB: stack backtrace: ># 0 0xc089b0ff at kdb_backtrace+0x4f ># 1 0xc08678af at panic+0x16f ># 2 0xc0b0848a at kmem_malloc+0x28a ># 3 0xc0afbc87 at page_alloc+0x27 ># 4 0xc0afe320 at uma_large_malloc+0x50 ># 5 0xc085142c at malloc+0x8c ># 6 0xc07cedc0 at g_read_data+0x50 ># 7 0xc07d45f8 at g_label_ufs_taste_common+0x98 ># 8 0xc07d485b at g_label_ufs_id_taste+0x1b ># 9 0xc07d35ec at g_label_taste+0x3ec ># 10 0xc07d075f at g_new_provider_event+0x5f ># 11 0xc07ce205 at g_run_events+0x265 ># 12 0xc07cf6e9 at g_event_procbody+0x69 ># 13 0xc08366f6 at fork_exit+0x96 ># 14 0xc0b59e64 at fork_trampoline+0x8 > Uptime: 13s > Automatic reboot in 15 seconds - press a key on the console to abort > Search for cam clt kmem in the lists. I had to add kern.cam.ctl.disable=3D1 on a Soekris box with 9.1. /glz From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:17:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3010C7 for ; Thu, 24 Jan 2013 09:17:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id BA261162 for ; Thu, 24 Jan 2013 09:17:03 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:4400:f9ea:e0ba:b2b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D1F4E4AC32; Thu, 24 Jan 2013 13:17:01 +0400 (MSK) Date: Thu, 24 Jan 2013 13:16:58 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1477843233.20130124131658@serebryakov.spb.ru> To: 'Jeremy Chadwick' Subject: Re: svn - but smaller? In-Reply-To: <20130124085717.GA26673@icarus.home.lan> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:17:04 -0000 Hello, 'Jeremy. You wrote 24 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2013 =D0=B3., 12:57:17: JC> to install Subversion. If you want to pull down ports/ you can use JC> portsnap and waste lots of /var space, hoping that the portsnap mirrors JC> are up to date, and a bunch of other hullabaloo... In case of csup, you relies that the cvs mirrors are up to date. And what about /var space... svn spends much more space in /usr/ports itself (.svn directory) than portsnap does (now my /var/db/portsnap directory is 95MiB, and .svn for ports will be comparable with size of ports itself!). I personally (maintainer of subversion port!) prefer csup over all other methods for "non-developers" systems too, and I'll be happy to see "svnup" when (if?) it will be created... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:35:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 787F798B for ; Thu, 24 Jan 2013 09:35:16 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 572DA246 for ; Thu, 24 Jan 2013 09:35:16 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id B8B24450D8; Thu, 24 Jan 2013 09:35:08 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk B8B24450D8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1359020109; bh=BMh4i5yTs8sLgPPWPnTgBNdgjkDlZbpbMGkHUjj6K1U=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=W7bvPwxdfWNTBRwTjxvzBGpmcogRHVfcnZdQn4v2pwIaM4cFpm9n2qViHP58LOmY3 Di08bCbpdIxIqIQNcn4pImJtqd89KDrKgUvF1TOzKnjEjtejp84iY1HR1Ip9F8TMQf 4gsn/14ECO7GIAGUEVx6opvj9jRci9ALLLiKtOc0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 64A91888B; Thu, 24 Jan 2013 09:35:03 +0000 (GMT) Date: Thu, 24 Jan 2013 09:35:03 +0000 From: Ben Morrow To: jdc@koitsu.org, freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130124093503.GA87735@anubis.morrow.me.uk> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130124085717.GA26673@icarus.home.lan> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:35:16 -0000 Quoth 'Jeremy Chadwick' : > > Regarding your "svn-lite" theory of having that added to src/contrib/, > let me introduce you to Subversion's actual dependencies, and I'll > explain why these would have to remain enabled (for a "base system" > Subversion) as well: > > * SQLite3 (used for bits/pieces in .svn/ directories) > -- License: http://www.sqlite.org/copyright.html > -- Not in the base system It is in HEAD, because the new Heimdal needs it. (The library is currently called libheimsqlite, and is built under kerberos5/lib, but both of those could be changed if necessary.) > * APR (used for HTTP fetching (not necessarily HTTPS)) > -- License: http://www.apache.org/licenses/LICENSE-2.0.html > -- Not in the base system > > * Expat 2.x (XML parsing/generation library > -- License: http://en.wikipedia.org/wiki/MIT_License > -- Not in the base system So these could potentially be brought in? I'm not sure if the Apache license is considered sufficiently BSDish? > * Neon or Serf (used for HTTPS fetching) This could be considered optional, for a base-system svn, as long as the repository is available over HTTP. If necessary the binary could be renamed to bsdsvn so as not to conflict with a full-featured svn installed from ports. (Of course, HTTPS would be *nice*.) > * gettext and libintl (used for character set support) > -- gettext license: GPL (not sure what version) > -- libintl license: LGPL (not sure what version) > -- Neither are in the base system Don't know about these, but I'd be surprised if it wasn't possible to build svn without them. That means losing i18n, but I'm fairly sure csup didn't have i18n either. > * libiconv (used for character set conversion) > -- License: LGPL (not sure what version) > -- Not in the base system There is a BSD-licensed libiconv in HEAD, though it currently isn't built by default. So, it looks to me as though it would be possible, in principle, to bring svn into the base. I'm not at all sure I think that would be a good idea (in particular, bringing in both APR and Expat just to download a few files seems excessive), but it could perhaps be provided as a make.conf option for those who are concerned. (Personally I would not willingly use svn again for any reason, so I'm keeping my source up-to-date using the github mirror. I wonder whether a BSD-licensed checkout-only git client would be easier to write than svnsup? I'm certain the wire protocol is more efficient.) Ben From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 09:45:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2798A4D2 for ; Thu, 24 Jan 2013 09:45:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 7321F820 for ; Thu, 24 Jan 2013 09:45:02 +0000 (UTC) Received: (qmail 2546 invoked by uid 89); 24 Jan 2013 09:40:46 -0000 Received: by simscan 1.4.0 ppid: 2541, pid: 2543, t: 0.0424s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16562 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 24 Jan 2013 09:40:46 -0000 Date: Thu, 24 Jan 2013 10:40:45 +0100 From: Rainer Duffner To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130124104045.38001af1@suse3> In-Reply-To: <20130124085717.GA26673@icarus.home.lan> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:45:03 -0000 Am Thu, 24 Jan 2013 00:57:17 -0800 schrieb 'Jeremy Chadwick' : > Though your OPTIONS recommendations work for you, they do not work for > everyone. Some people sit behind firewalls where HTTP or HTTPS are > the only viable means (native SVN or SVN+SSH will not work for > them). But then, cvsup/csup didn't work either, right? So, what did those people do in the days of cvsup? As for the whole dependency/license nightmare - there is some truth[1] in that and I'm sure, the people "in charge" are aware of it. I was always under the assumption that the switch to svn was more of a temporary stopgap solution where the benefits (progress of the FreeBSD project) out-weighted the deficiencies. The migration to a "better system" is supposed to be easier from svn than cvs... [1] I have the need to have mod_dav_svn in my subversion-package (because a customer needs it and I only want to maintain one pkgng-repo). Thus, every time svn is installed, apache gets pulled in, too. Awesome. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 10:46:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9859505 for ; Thu, 24 Jan 2013 10:46:01 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id C05B4DAE for ; Thu, 24 Jan 2013 10:46:01 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 1B3C4450D8; Thu, 24 Jan 2013 10:45:57 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk 1B3C4450D8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1359024360; bh=9r/VP9Ei5LHP8gs5WHrIBCAD3M/vZSXbzS4ZPFNfwAw=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=g7ElMVLFAlG5rY6600JsFhDg7bl6aX+0Ye9wcJCr6qNjtyKvrcLiG/awtIU1AV5g1 hu5wbSK7IMRfgzb9x/xMnahl/gY565PqNM4Ik9WoiZvXhAv+IHbvIKOSKhocFIXeWN JiBAHoleV6NgrCVeAs0DEzpNyXBPSPgHKE5sbHXY= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id E3B0388A6; Thu, 24 Jan 2013 10:45:53 +0000 (GMT) Date: Thu, 24 Jan 2013 10:45:53 +0000 From: Ben Morrow To: jdc@koitsu.org, freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130124104553.GA69019@anubis.morrow.me.uk> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124093503.GA87735@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130124093503.GA87735@anubis.morrow.me.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:46:02 -0000 At 9AM +0000 on 24/01/13 you (Ben Morrow) wrote: > Quoth 'Jeremy Chadwick' : > > > > Regarding your "svn-lite" theory of having that added to src/contrib/, > > let me introduce you to Subversion's actual dependencies, and I'll > > explain why these would have to remain enabled (for a "base system" > > Subversion) as well: > > * APR (used for HTTP fetching (not necessarily HTTPS)) > > -- License: http://www.apache.org/licenses/LICENSE-2.0.html > > -- Not in the base system > > > > * Expat 2.x (XML parsing/generation library > > -- License: http://en.wikipedia.org/wiki/MIT_License > > -- Not in the base system Correction: expat is in base already, as libbsdxml (rather confusingly built under lib/libexpat). So AFAICS the only remaining piece is APR (and svn itself), and I suspect that if only the bits required for a svn client were brought in (assuming the licence is deemed acceptable) that would be a lot smaller than a full APR build. (Again, this would need to be built as libbsdapr to avoid conflicts with real APR from ports.) Ben From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 11:13:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34864A29 for ; Thu, 24 Jan 2013 11:13:47 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id C2139F14 for ; Thu, 24 Jan 2013 11:13:45 +0000 (UTC) Received: from server.rulingia.com (c220-239-246-167.belrs5.nsw.optusnet.com.au [220.239.246.167]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r0OBDbxE079978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jan 2013 22:13:38 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r0OBDWBu037133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 22:13:32 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r0OBDWMl037132 for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 22:13:32 +1100 (EST) (envelope-from peter) Date: Thu, 24 Jan 2013 22:13:32 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130124111332.GA29105@server.rulingia.com> References: <20130123144050.GG51786@e-Gitt.NET> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:13:47 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jan-23 15:40:50 +0100, Oliver Brandmueller wrote: >in ancient times there was cvsup. cvsup was a PITA if you wanted (or=20 >needed) to install it via ports, the only reasonable way was to use=20 >pkg_add for that if you didn't want to pollute your system with=20 >otherwise unneeded software. There was also ctm(1). ctm is small, BSD-licensed and has been part of FreeBSD forever (almost). Thanks to stephen@, ctm deltas for various src trees, as well as the entire SVN repo are still available. c[v]sup can do things than aren't possible with ctm but I would expect that most people who currently use c[v]sup could readily migrate to using ctm. See http://www.freebsd.org/doc/handbook/ctm.html for details. Note that mirroring the actual SVN repo via ctm requires some patches. There is a README and patches in ftp://ftp.freebsd.org/pub/FreeBSD/CTM/svn-= cur/ --=20 Peter Jeremy --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEBF1wACgkQ/opHv/APuId17gCeJdk5JjaiFR6ryFlxRhWS1Ya4 KcEAn1B8AutHoFFSsYnrEvP+zzX4SJ2I =MSK3 -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 11:30:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3735A172 for ; Thu, 24 Jan 2013 11:30:35 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id EC30969 for ; Thu, 24 Jan 2013 11:30:34 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11496645 for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 05:30:33 -0600 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Thu, 24 Jan 2013 05:30:33 -0600 Message-ID: In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:30:35 -0000 On Thu, 24 Jan 2013 18:34:33 +1100  "Dewayne" wrote: > The objective is to return to a base build of FreeBSD >that performs the expected task of being able to pull >source, without having > to acquire a port.  Regardless of our individual >solutions/workarounds, the task is to pull and maintain >source. > > Is the discussion going to result in something like >svn-lite that enters into the /usr/src/contrib along with >the responsibilities > associated with maintaining it?  And then we need to >take into consideration of being overwriting the "base >svn" with a full svn > package, if required by the user/admin. > > The issue involves policy decisions along with ongoing >support load, rather than just a good technical solution; >which as we've seen > in earlier discussions, is sorely needed by the folks >doing the development/maintenance. > > In the meantime, ftp isn't really workable for ongoing >updates, and rsync is GPL'ed and can't be in the base >system. > > I build svn from ports with all options off except for: >ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in >a 4.2MB svn > program. Suites me but doesn't address the underlying >problem - and I don't think that the plan is to make >FreeBSD dependent upon > the ports system (for subversion) > > Regards, Dewayne. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to >"freebsd-stable-unsubscribe@freebsd.org" > Hello all, I'm working on writing a lightweight, dependency-free, BSD licensed program to pull source using the svn protocol (not using the aforementioned svnsup code).  I've only got a few more pieces of the puzzle to sort out and some code cleanup and it should be ready for testing. As someone who has never contributed code, what's the best way to submit this code for consideration?  Do I just slap a BSD license on it and post it to the list?  Do I first create a port for it?  Also, does anyone know who I should contact regarding permission to test my code against the repository at svn.freebsd.org?  Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 12:04:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AA18A40 for ; Thu, 24 Jan 2013 12:04:57 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id CC73822E for ; Thu, 24 Jan 2013 12:04:56 +0000 (UTC) Received: from rufus.webfusion.com (mail.heartinternet.co.uk [79.170.40.31]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.6) with ESMTP id r0OC4kGB042566 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 12:04:53 GMT (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.7.4 smtp.infracaninophile.co.uk r0OC4kGB042566 Authentication-Results: smtp.infracaninophile.co.uk/r0OC4kGB042566; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host mail.heartinternet.co.uk [79.170.40.31] claimed to be rufus.webfusion.com Message-ID: <5101235D.8040006@freebsd.org> Date: Thu, 24 Jan 2013 12:04:45 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130111 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:04:57 -0000 On 24/01/2013 11:30, John Mehr wrote: > I'm working on writing a lightweight, dependency-free, BSD licensed > program to pull source using the svn protocol (not using the > aforementioned svnsup code). I've only got a few more pieces of the > puzzle to sort out and some code cleanup and it should be ready for > testing. Ooooh... shiny! Thank you very much indeed for working on this. It's an area where a solution is very much in demand. > As someone who has never contributed code, what's the best way to submit > this code for consideration? Do I just slap a BSD license on it and > post it to the list? Do I first create a port for it? Also, does > anyone know who I should contact regarding permission to test my code > against the repository at svn.freebsd.org? Thanks. Ummm... both of the above. If you submit it as a port, it will get into the ports a lot quicker than it would get into src, plus it will be available to all FreeBSD users to test straight away. Once it does go into src, it will take a number of release cycles before it can be considered generally available. Given a good track record in ports, you'll find it easier to persuade people to import it into src. For testing against svn.freebsd.org -- this is pull only? So you only need read permissions on svn.freebsd.org? That's fine: the SVN repository is open to public access and you can just use it without asking permission. Although I'd use one of the mirror sites listed in the handbook rather than svn.freebsd.org directly. Note: for read-only access you can use svn:// http:// and https:// type URLs. If you want to test, say, svn+ssh:// then you'll need to find a committer to help you out. However, as the only reason to have svn+ssh:// access is to be able to commit, it's probably out of scope for your case. Cheers, Matthew From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 14:20:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59C2493D for ; Thu, 24 Jan 2013 14:20:50 +0000 (UTC) (envelope-from gyrd-se@thanelange.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0C489A2B for ; Thu, 24 Jan 2013 14:20:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from get-mta-scan02.get.basefarm.net ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MH400D9ZVUJ5860@get-mta-out01.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 15:20:43 +0100 (MET) Received: from get-mta-scan02.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2F3B91EA817B_101433BB for ; Thu, 24 Jan 2013 14:20:43 +0000 (GMT) Received: from smtp.getmail.no (unknown [10.5.16.4]) by get-mta-scan02.get.basefarm.net (Sophos Email Appliance) with ESMTP id 10ACB1EFA3B5_101433BF for ; Thu, 24 Jan 2013 14:20:43 +0000 (GMT) Received: from cm-84.211.88.167.getinternet.no ([84.211.88.167]) by get-mta-in01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with SMTP id <0MH40007TVUISI30@get-mta-in01.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 15:20:43 +0100 (MET) Received: (qmail 23687 invoked by uid 89); Thu, 24 Jan 2013 15:20:42 +0100 Received: from unknown (HELO ?10.0.10.184?) (gyrd@thanelange.no@77.241.104.2) by cm-84.211.88.167.getinternet.no with SMTP; Thu, 24 Jan 2013 15:20:42 +0100 Message-id: <5101433A.2080506@thanelange.no> Date: Thu, 24 Jan 2013 15:20:42 +0100 From: Gyrd Thane Lange User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> In-reply-to: <20130123144050.GG51786@e-Gitt.NET> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 14:20:50 -0000 On 23.01.2013 15:40, Oliver Brandmueller wrote: > However, I either overlook something important or we are now at the > point we had with cvsup in the early days: The software I need to > (source-)update the system doens't come with the base and installing svn > is a PITA. [...] It is not a well publicized fact, but I understand that the base utility freebsd-update(8) through it's freebsd-update.conf(5) is able to pull the base sources (/usr/src/) only instead of also updating your binaries. less /etc/freebsd-update.conf # Components of the base system which should be kept updated. Components src world kernel The above setting is the default, but you may easily leave out everything but "src". (Caveat: I have not tried it myself yet.) It also have some optional settings for preserving local changes to the source instead of blowing them away (default). This will allow you to use the sources for a custom build and install yourself. Also for ports we have the portsnap(8) utility, also in base. So it is perfectly possible to get sources for everything using just the tools in base. No csup or svnup is required. Best regards, Gyrd ^_^ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 14:33:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F019DE7A for ; Thu, 24 Jan 2013 14:33:18 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id C157CAEA for ; Thu, 24 Jan 2013 14:33:18 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11499157 for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 08:33:17 -0600 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Thu, 24 Jan 2013 08:33:17 -0600 Message-ID: In-Reply-To: <5101235D.8040006@freebsd.org> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <5101235D.8040006@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 14:33:19 -0000 >For testing against svn.freebsd.org -- this is pull only? > So you only > need read permissions on svn.freebsd.org?  That's fine: >the SVN > repository is open to public access and you can just use >it without > asking permission.  Although I'd use one of the mirror >sites listed in > the handbook rather than svn.freebsd.org directly. Correct.  I just want to give the folks that administer the servers a heads-up that there's going to be a lot more entries in their log files coming from me -- unless it's an undocumented feature of the svn protocol, md5 signatures for files are not included in directory requests and I need to issue a get-file command for each and every file to get their md5 signatures in order to determine which local files need an update.  :( From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 14:46:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C6F96C8 for ; Thu, 24 Jan 2013 14:46:48 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 337B9C00 for ; Thu, 24 Jan 2013 14:46:47 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id r0OEkd5T051199; Thu, 24 Jan 2013 15:46:39 +0100 (CET) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.135] (may be forged)) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id r0OEkdg2069598; Thu, 24 Jan 2013 15:46:39 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: svn - but smaller? From: "Patrick M. Hausen" In-Reply-To: <5101433A.2080506@thanelange.no> Date: Thu, 24 Jan 2013 15:46:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <605D3FD2-E631-4A66-8DA2-2BC4EF84AF0F@punkt.de> References: <20130123144050.GG51786@e-Gitt.NET> <5101433A.2080506@thanelange.no> To: Gyrd Thane Lange X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 14:46:48 -0000 Hi, all, Am 24.01.2013 um 15:20 schrieb Gyrd Thane Lange : > It is not a well publicized fact, but I understand that the base = utility freebsd-update(8) through it's freebsd-update.conf(5) is able to = pull the base sources (/usr/src/) only instead of also updating your = binaries. >=20 > less /etc/freebsd-update.conf >=20 > # Components of the base system which should be kept updated. > Components src world kernel >=20 > The above setting is the default, but you may easily leave out = everything but "src". (Caveat: I have not tried it myself yet.) > It also have some optional settings for preserving local changes to = the source instead of blowing them away (default). >=20 > This will allow you to use the sources for a custom build and install = yourself. I tried that and found that at least /usr/src/UPDATING was not touched = by freebsd-update. See on this list. Any hints welcome - must have been doing someting wrong. Thanks Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 16:13:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 08C04C9C for ; Thu, 24 Jan 2013 16:13:08 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id D25D426E for ; Thu, 24 Jan 2013 16:13:07 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so4969044iae.25 for ; Thu, 24 Jan 2013 08:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iVZNOIs3OnRj3LeYXc+u7qDoyq7GqiNEKwa56vQ8OkA=; b=rNzxdzPZdeXAM8vFMJWjuw5+OAuiQ5DJkjKW0CADR/LPt4kktDvBdxd/9AsY3KAQcb Z1YNNf25O+6wiIhQ0j7w3fCCIkbJ17PH6dGICI8AD+McAiY75/8/4bzk4jaXXAY0c6A6 xKRnakl3IG2h0WVDvcKVDj3RWxoMLh/8O5vBtHwlZjlcCmVlSaDMf+nQFYuagwlWZwXs f5zp3TONBY3AzJsvy0HlszFcCf5/GZpaLLG3dqQ2vkhV6PNwpdTQPX7nHEHF7ALZiL93 OhgzZs44JNKeVhh0C9b7yyFosXwdri0Js1YVDKkA2jLPYgOHkhOQ04CcYwzJlc4sDglp qPiw== MIME-Version: 1.0 X-Received: by 10.42.92.72 with SMTP id s8mr1522614icm.0.1359043987223; Thu, 24 Jan 2013 08:13:07 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 24 Jan 2013 08:13:06 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 24 Jan 2013 08:13:06 -0800 (PST) In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <5101235D.8040006@freebsd.org> Date: Thu, 24 Jan 2013 16:13:06 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: John Mehr Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:13:08 -0000 On 24 Jan 2013 14:33, "John Mehr" wrote: >> >> For testing against svn.freebsd.org -- this is pull only? So you only >> need read permissions on svn.freebsd.org? That's fine: the SVN >> repository is open to public access and you can just use it without >> asking permission. Although I'd use one of the mirror sites listed in >> the handbook rather than svn.freebsd.org directly. > > > Correct. I just want to give the folks that administer the servers a heads-up that there's going to be a lot more entries in their log files coming from me -- unless it's an undocumented feature of the svn protocol, md5 signatures for files are not included in directory requests and I need to issue a get-file command for each and every file to get their md5 signatures in order to determine which local files need an update. :( It'd probably be faster for you to use svnsync to get a local mirror of the repo. Chris From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 16:17:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 764A5E78; Thu, 24 Jan 2013 16:17:38 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 3926A2B9; Thu, 24 Jan 2013 16:17:38 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so5043655iac.21 for ; Thu, 24 Jan 2013 08:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zm8ujmNheBURCGVI9qpfyUSy1m4W31zLM3wqM0xEH00=; b=MrhEiRSWZq6n//CxnceMumUylahpC4PUVh5ifG4ZWM5QPt2FVmX3DO6XCcnUcB2Bl/ 260BaMHuho3n+fQE1sVDGvET+6fWTEKkGs53nFsDLupPXYgpScVtPXvTM066/q9iDvXi Y/Dfno/OYd0t74hBvb3oOL4VZnb4zLYf+Qt+RIqWuRXseDwl/3S093tvHmiMLgaKeeIq BiOMaXcXpFm6r9wuoMr5ECNNwvBKcub6daYZ50LB66Hdkf/Wdtn/0aM/nw4/ujiBwp/Y /ppEOLWe0JP/dkdeJTyv4VjngN3uToCzwVxYZDmqXhS3rprt2PoObXJddg/HKAtfJd1N Io2Q== MIME-Version: 1.0 X-Received: by 10.50.178.10 with SMTP id cu10mr1835182igc.75.1359044257804; Thu, 24 Jan 2013 08:17:37 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 24 Jan 2013 08:17:37 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 24 Jan 2013 08:17:37 -0800 (PST) In-Reply-To: <20130123215531.GA13217@icarus.home.lan> References: <20130123215531.GA13217@icarus.home.lan> Date: Thu, 24 Jan 2013 16:17:37 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:17:38 -0000 On 23 Jan 2013 21:55, "Jeremy Chadwick" wrote: > > (Please keep me CC'd as I'm not subscribed to the list) > > > Great idea; > > > > http://www.bayofrum.net/~crees/patches/svn-static.diff > > > > Lev, do you mind if I commit this? I haven't touched the subversion > > port, but it'll have you as maintainer :) > > > > If you prefer, I don't mind maintaining this. > > As I understand it this patch would induce the build cluster to build > subversion-static.tbz (eventually) and put it on the package servers. > > So what happens when one of the underlying dependencies that you've > included statically (those would possibly be: Oracle/SleepyCat DB, APR, > expat, sqlite3, neon, gettext, and iconv) have security holes or major > bugs found/addressed in them? The package would be updated on the next build, since a dependency changed. > As I understand it -- based on history -- the packages on the FTP > servers get updated "whenever". My other post shows some haven't been > updated in months (and yes I'm aware of the security incident). That's why, so for normal use it's irrelevant. > So how long would a key piece of software containing insecure > statically-linked libraries be on the FTP servers? No longer than any other package. > How would the port maintainer(s) even know the libraries/software which > subversion is dependent upon had been updated, thus requiring a new > subversion package to be pushed out to the package servers ASAP (i.e. > immediately, not days, weeks, or months)? > > My point: ports have always been "best-effort". They are advertised > vehemently throughout "everything FreeBSD" as being third-party software > and therefore . Yet now critical pieces to > FreeBSD development (and now end-users too, as a result of using the > security incident to push SVN) rely upon something in ports. That's > quite a conundrum the Project has created for itself, an ouroboros of > sorts. This is not intended as general use for everyone, it's intended as a shortcut when building a new machine or anything else. I'll put a big warning in pkg message :) Chris From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 17:04:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0816ED2 for ; Thu, 24 Jan 2013 17:04:19 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 66FCB79A for ; Thu, 24 Jan 2013 17:04:19 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpAT4-1UdHHS2TXo-00erD0 for ; Thu, 24 Jan 2013 18:04:18 +0100 Received: (qmail invoked by alias); 24 Jan 2013 17:04:18 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp028) with SMTP; 24 Jan 2013 18:04:18 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1/VWgVLGQTVgufYrxKLmaXZm4Q/B5t2rdSiPBxmtB TL3WZdLXlS3g15 From: Christian Gusenbauer To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: 9.1-stable crashes while copying data from a NFS mounted directory Date: Thu, 24 Jan 2013 18:05:57 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301241805.57623.c47g@gmx.at> X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:04:19 -0000 Hi! I'm using 9.1 stable svn revision 245605 and I get the panic below if I execute the following commands (as single user): # swapon -a # dumpon /dev/ada0s3b # mount -u / # ifconfig age0 inet 192.168.2.2 mtu 6144 up # mount -t nfs -o rsize=32768 data:/multimedia /mnt # cp /mnt/Movies/test/a.m2ts /tmp then the system panics almost immediately. I'll attach the stack trace. Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe that's the cause for the panic, because the bcopy (see stack frame #15) fails. Any clues? Ciao, Christian. #0 doadump (textdump=0) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 265 if (textdump && textdump_pending) { (kgdb) #0 doadump (textdump=0) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 #1 0xffffffff802a8ba0 in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /spare/tmp/src-stable9/sys/ddb/db_command.c:538 #2 0xffffffff802a84ce in db_command (last_cmdp=0xffffffff808bc5c0, cmd_table=, dopager=1) at /spare/tmp/src-stable9/sys/ddb/db_command.c:449 #3 0xffffffff802a8720 in db_command_loop () at /spare/tmp/src-stable9/sys/ddb/db_command.c:502 #4 0xffffffff802aa859 in db_trap (type=, code=) at /spare/tmp/src-stable9/sys/ddb/db_main.c:231 #5 0xffffffff803c4918 in kdb_trap (type=3, code=0, tf=0xffffff81b2da8a80) at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649 #6 0xffffffff805a02cf in trap (frame=0xffffff81b2da8a80) at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579 #7 0xffffffff8058992f in calltrap () at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 #8 0xffffffff803c43cb in kdb_enter (why=0xffffffff806145f3 "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff8038f407 in panic (fmt=) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627 #10 0xffffffff80568049 in vm_fault_hold (map=0xfffffe0002000000, vaddr=18446743530148802560, fault_type=2 '\002', fault_flags=0, m_hold=0x0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:285 #11 0xffffffff80568753 in vm_fault (map=0xfffffe0002000000, vaddr=18446743530148802560, fault_type=, fault_flags=0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:229 #12 0xffffffff805a00c7 in trap_pfault (frame=0xffffff81b2da9170, usermode=0) at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:771 #13 0xffffffff805a051e in trap (frame=0xffffff81b2da9170) at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:463 #14 0xffffffff8058992f in calltrap () at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 #15 0xffffffff8059d7b5 in bcopy () at /spare/tmp/src-stable9/sys/amd64/amd64/support.S:134 #16 0xffffffff81c5963b in nfsm_mbufuio (nd=0xffffff81b2da9320, uiop=, siz=32768) at /spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_commonsubs.c:212 #17 0xffffffff81c19571 in nfsrpc_read (vp=0xfffffe0005ca2000, uiop=0xffffff81b2da95a0, cred=, p=0xfffffe0005f28000, nap=0xffffff81b2da9480, attrflagp=0xffffff81b2da954c, stuff=0x0) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clrpcops.c:1343 #18 0xffffffff81c3aff0 in ncl_readrpc (vp=0xfffffe0005ca2000, uiop=0xffffff81b2da95a0, cred=) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clvnops.c:1366 #19 0xffffffff81c2fed3 in ncl_doio (vp=0xfffffe0005ca2000, bp=0xffffff816fabca20, cr=0xfffffe0002d59e00, td=0xfffffe0005f28000, called_from_strategy=0) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:1605 #20 0xffffffff81c32aaf in ncl_bioread (vp=0xfffffe0005ca2000, uio=0xffffff81b2da9ad0, ioflag=, cred=0xfffffe0002d59e00) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:541 #21 0xffffffff804379c3 in vn_read (fp=0xfffffe0005f3e960, uio=0xffffff81b2da9ad0, active_cred=, flags=, td=) at vnode_if.h:384 #22 0xffffffff80434d40 in vn_io_fault (fp=0xfffffe0005f3e960, uio=0xffffff81b2da9ad0, active_cred=0xfffffe0002d59e00, flags=0, td=0xfffffe0005f28000) at /spare/tmp/src-stable9/sys/kern/vfs_vnops.c:903 #23 0xffffffff803d7bd1 in dofileread (td=0xfffffe0005f28000, fd=3, fp=0xfffffe0005f3e960, auio=0xffffff81b2da9ad0, offset=, flags=0) at file.h:287 #24 0xffffffff803d7f7c in kern_readv (td=0xfffffe0005f28000, fd=3, auio=0xffffff81b2da9ad0) at /spare/tmp/src-stable9/sys/kern/sys_generic.c:250 #25 0xffffffff803d8074 in sys_read (td=, uap=) at /spare/tmp/src-stable9/sys/kern/sys_generic.c:166 #26 0xffffffff8059f4f0 in amd64_syscall (td=0xfffffe0005f28000, traced=0) at subr_syscall.c:135 #27 0xffffffff80589c17 in Xfast_syscall () at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:387 #28 0x00000008009245fc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 17:10:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C1E5264 for ; Thu, 24 Jan 2013 17:10:38 +0000 (UTC) (envelope-from gyrd-nani@thanelange.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id F3ED6804 for ; Thu, 24 Jan 2013 17:10:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from get-mta-scan04.get.basefarm.net ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MH5007H93PPQE80@get-mta-out02.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 18:10:37 +0100 (MET) Received: from get-mta-scan04.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 257F21EF9569_1016B0DB for ; Thu, 24 Jan 2013 17:10:37 +0000 (GMT) Received: from smtp.getmail.no (unknown [10.5.16.4]) by get-mta-scan04.get.basefarm.net (Sophos Email Appliance) with ESMTP id 0491E1EF9565_1016B0DF for ; Thu, 24 Jan 2013 17:10:37 +0000 (GMT) Received: from cm-84.211.88.167.getinternet.no ([84.211.88.167]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with SMTP id <0MH500DU43POQ900@get-mta-in02.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 18:10:36 +0100 (MET) Received: (qmail 35772 invoked by uid 89); Thu, 24 Jan 2013 18:10:36 +0100 Received: from unknown (HELO ?10.0.10.184?) (gyrd@thanelange.no@77.241.104.2) by cm-84.211.88.167.getinternet.no with SMTP; Thu, 24 Jan 2013 18:10:36 +0100 Message-id: <51016B0C.7040505@thanelange.no> Date: Thu, 24 Jan 2013 18:10:36 +0100 From: Gyrd Thane Lange User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 To: "Patrick M. Hausen" Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <5101433A.2080506@thanelange.no> <605D3FD2-E631-4A66-8DA2-2BC4EF84AF0F@punkt.de> In-reply-to: <605D3FD2-E631-4A66-8DA2-2BC4EF84AF0F@punkt.de> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:10:38 -0000 On 24.01.2013 15:46, Patrick M. Hausen wrote: > Hi, all, > > Am 24.01.2013 um 15:20 schrieb Gyrd Thane Lange : >> It is not a well publicized fact, but I understand that the base utility freebsd-update(8) through it's freebsd-update.conf(5) is able to pull the base sources (/usr/src/) only instead of also updating your binaries. >> >> less /etc/freebsd-update.conf >> >> # Components of the base system which should be kept updated. >> Components src world kernel >> >> The above setting is the default, but you may easily leave out everything but "src". (Caveat: I have not tried it myself yet.) >> It also have some optional settings for preserving local changes to the source instead of blowing them away (default). >> >> This will allow you to use the sources for a custom build and install yourself. > > > I tried that and found that at least /usr/src/UPDATING was not touched by freebsd-update. > See on this list. > > Any hints welcome - must have been doing someting wrong. I just tried (src only), from an 8.2 system: # freebsd-update -r 8.3-RELEASE upgrade # freebsd-update install This gave me the same experience as you. The latest entry in UPDATING is 20120411: 8.3-RELEASE (The good news is that it actually updated it from 8.2 to 8.3, so it did not ignore it completely.) But all other files under the /usr/src/ hierarchy is properly updated. For instance: # egrep '^(REVISION|BRANCH)' /usr/src/sys/conf/newvers.sh REVISION="8.3" BRANCH="RELEASE-p5" This gives me some confidence that I've got the important bits from -p5, even though UPDATING remains at unpatched level. I guess there is some bug or misconfiguration on the server side of freebsd-update that ignores some files. I have no idea. ;-) In short, I think you used the correct commands, and that it is reasonable to expect the /usr/src/UPDATING file to be updated. Regards, Gyrd ^_^ > > Thanks > Patrick > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 17:29:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66B4DA1B for ; Thu, 24 Jan 2013 17:29:57 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 51B5E912 for ; Thu, 24 Jan 2013 17:29:57 +0000 (UTC) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) by mbox1.develooper.com (Postfix) with ESMTP id 0BA2E175AA7 for ; Thu, 24 Jan 2013 09:29:57 -0800 (PST) Received: (qmail 16390 invoked from network); 24 Jan 2013 17:29:56 -0000 Received: from cpe-76-172-28-38.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@76.172.28.38) by smtp.develooper.com with ESMTPA; 24 Jan 2013 17:29:56 -0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: panic: kmem_malloc(8192): kmem_map too small: 39460864 total allocated From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: <7CE2F5AC86689C2624BC1F2F@[172.16.2.60]> Date: Thu, 24 Jan 2013 09:29:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <14DB5B20-D6CE-4B65-8931-8CDA0537A7EF@develooper.com> References: <578B00AD-8524-4EE1-83D3-CFD1B739AC96@develooper.com> <7CE2F5AC86689C2624BC1F2F@[172.16.2.60]> To: =?iso-8859-1?Q?G=F6ran_L=F6wkrantz?= X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:29:57 -0000 On Jan 24, 2013, at 1:16, G=F6ran L=F6wkrantz = wrote: > Search for cam clt kmem in the lists. I had to add > kern.cam.ctl.disable=3D1 >=20 > on a Soekris box with 9.1. Thanks G=F6ran; that did indeed fix it. Michael Moll sent me the same = solution off-list and a link to = http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-td577158= 3.html I changed my kernel to not include that driver now and all is well, even = on my 64MB Soekris 4501 board. :-) Thank you again! Ask= From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 17:40:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15BDCEB1 for ; Thu, 24 Jan 2013 17:40:41 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id F11B89C1 for ; Thu, 24 Jan 2013 17:40:40 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta14.emeryville.ca.mail.comcast.net with comcast id rseT1k0050FhH24AEtgg2P; Thu, 24 Jan 2013 17:40:40 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id rtgf1k00B1t3BNj8Utgfc8; Thu, 24 Jan 2013 17:40:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 18C3573A1C; Thu, 24 Jan 2013 09:40:39 -0800 (PST) Date: Thu, 24 Jan 2013 09:40:39 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <20130124174039.GA35811@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359049240; bh=wa8KR8Nn/IKMk4jkRvKrsmvl0UfXKJSK1zz+7/bt7h4=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=cZ1N06G2OEKc08+JR1JDjy5x1rfpDGKgGw2UFjKoCVx6ph85gjka1hp+A/Tz1hYfW o4M9HZBfw9Upwer2Z+q04UFGf/PR6MzA1UyQ4DC+0B2e7fE2o8O7M3JSmtoSEh6DnK OMv2hbmcsWrUS2q1gko2TCbRrNcqDVwxIMzgfyKxRGK3uCXMrMrhE62hhocH/j9aYi uFxa4NV7a2xYqvsd88jYWmYKOd2pzQPlVqnWOImlpSpNWKEQttWX6mzKIMRIGC+j/0 EQpO4CzjkjHA7sFqpMuxgDo7QTLxxKnIY2QpfNyf96Mz9cRFZ/SWTfqYZtDqLpLLW6 Gcpb4w0pq1yag== Cc: wblock@wonkity.com, freebsd@deman.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:40:41 -0000 >> #1. Map the physical drive slots to how they show up in FBSD so if a >> disk is removed and the machine is rebooted all the disks after that >> removed one do not have an 'off by one error'. i.e. if you have >> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >> missing ada8 drive and the next drive (that used to be ada9) is now >> called ada8 and so on... > >How do you do that? If I'm in that situation, I think I could find the >bad drive, or at least the good ones, with diskinfo and the drive serial >number. One suggestion I saw somewhere was to use disk serial numbers >for label values. The term FreeBSD uses for this is called "wiring down" or "wired down", and is documented in CAM(4). It's come up repeatedly over the years but for whatever reason people overlook it or can't find it. Here's how you do it for Intel AHCI (and probably others like AMD), taken directly from my /boot/loader.conf -- # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" IMPORTANT: The device names/busses/etc. are going to vary depending on each person's setup, controller, etc.. Proof of this is in a post from Randy Bush, where I helped him off-list with this task and he figured out the remaining bits by himself for his hptrr(4) controller: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html You can use labels if you want, but I prefer to just have statically assigned device names regardless of a bay being populated by a disk or not. That's my preference. Other people like labels and that's fine -- I just can't stand the utter mess that is labelling on FreeBSD, sans GPT labels. And finally, touching /boot/device.hints is wrong. Do not do this. Ever. This file is actually "managed" by either mergemaster or installkernel/installworld (I forget which). Use /boot/loader.conf for any hint overrides/adjustments. Leave /boot/device.hints alone. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 18:02:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2AA9A419 for ; Thu, 24 Jan 2013 18:02:30 +0000 (UTC) (envelope-from gyrd-se@thanelange.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id C340AAA1 for ; Thu, 24 Jan 2013 18:02:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from get-mta-scan02.get.basefarm.net ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MH5007OW644BO30@get-mta-out01.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 19:02:28 +0100 (MET) Received: from get-mta-scan02.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 84EF31EA81B4_1017734B for ; Thu, 24 Jan 2013 18:02:28 +0000 (GMT) Received: from smtp.getmail.no (unknown [10.5.16.4]) by get-mta-scan02.get.basefarm.net (Sophos Email Appliance) with ESMTP id 66AF91EFA709_1017734F for ; Thu, 24 Jan 2013 18:02:28 +0000 (GMT) Received: from cm-84.211.88.167.getinternet.no ([84.211.88.167]) by get-mta-in01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with SMTP id <0MH500G7S6448V30@get-mta-in01.get.basefarm.net> for freebsd-stable@freebsd.org; Thu, 24 Jan 2013 19:02:28 +0100 (MET) Received: (qmail 36996 invoked by uid 89); Thu, 24 Jan 2013 19:02:28 +0100 Received: from unknown (HELO ?10.0.10.184?) (gyrd@thanelange.no@77.241.104.2) by cm-84.211.88.167.getinternet.no with SMTP; Thu, 24 Jan 2013 19:02:28 +0100 Message-id: <51017733.80400@thanelange.no> Date: Thu, 24 Jan 2013 19:02:27 +0100 From: Gyrd Thane Lange User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 To: "Patrick M. Hausen" Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <5101433A.2080506@thanelange.no> <605D3FD2-E631-4A66-8DA2-2BC4EF84AF0F@punkt.de> <51016B0C.7040505@thanelange.no> In-reply-to: <51016B0C.7040505@thanelange.no> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:02:30 -0000 Hi On 24.01.2013 18:10, Gyrd Thane Lange wrote: > On 24.01.2013 15:46, Patrick M. Hausen wrote: > This gives me some confidence that I've got the important bits from -p5, > even though UPDATING remains at unpatched level. I guess there is some > bug or misconfiguration on the server side of freebsd-update that > ignores some files. I have no idea. ;-) > > In short, I think you used the correct commands, and that it is > reasonable to expect the /usr/src/UPDATING file to be updated. I had a search through the PR database, and came across this: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/147430 freebsd-update(8) not updating /usr/src/UPDATING I appears to be a long outstanding issue (from june 2010). Not really critical, but certainly confusing. Gyrd ^_^ > Regards, > Gyrd ^_^ > >> >> Thanks >> Patrick From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 18:04:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38967535; Thu, 24 Jan 2013 18:04:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F21AAC3; Thu, 24 Jan 2013 18:04:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0OI3xqp061489; Thu, 24 Jan 2013 20:03:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0OI3xqp061489 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0OI3xhK061488; Thu, 24 Jan 2013 20:03:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jan 2013 20:03:59 +0200 From: Konstantin Belousov To: Christian Gusenbauer Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130124180359.GH2522@kib.kiev.ua> References: <201301241805.57623.c47g@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vxNpRqk6sR1V+qwt" Content-Disposition: inline In-Reply-To: <201301241805.57623.c47g@gmx.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:04:11 -0000 --vxNpRqk6sR1V+qwt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > Hi! >=20 > I'm using 9.1 stable svn revision 245605 and I get the panic below if I e= xecute the following commands (as single user): >=20 > # swapon -a > # dumpon /dev/ada0s3b > # mount -u / > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > # mount -t nfs -o rsize=3D32768 data:/multimedia /mnt > # cp /mnt/Movies/test/a.m2ts /tmp >=20 > then the system panics almost immediately. I'll attach the stack trace. >=20 > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe t= hat's the cause for the panic, because the bcopy (see=20 > stack frame #15) fails. >=20 > Any clues? I tried a similar operation with the nfs mount of rsize=3D32768 and mtu 6144, but the machine runs HEAD and em instead of age. I was unable to reproduce the panic on the copy of the 5GB file from nfs mount. Show the output of "p *(struct uio *)0xffffff81b2da95a0" in kgdb. >=20 > Ciao, > Christian. >=20 > #0 doadump (textdump=3D0) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 > 265 if (textdump && textdump_pending) { > (kgdb) #0 doadump (textdump=3D0) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 > #1 0xffffffff802a8ba0 in db_dump (dummy=3D, > dummy2=3D, dummy3=3D, > dummy4=3D) > at /spare/tmp/src-stable9/sys/ddb/db_command.c:538 > #2 0xffffffff802a84ce in db_command (last_cmdp=3D0xffffffff808bc5c0, > cmd_table=3D, dopager=3D1) > at /spare/tmp/src-stable9/sys/ddb/db_command.c:449 > #3 0xffffffff802a8720 in db_command_loop () > at /spare/tmp/src-stable9/sys/ddb/db_command.c:502 > #4 0xffffffff802aa859 in db_trap (type=3D, > code=3D) > at /spare/tmp/src-stable9/sys/ddb/db_main.c:231 > #5 0xffffffff803c4918 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff81b2= da8a80) > at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649 > #6 0xffffffff805a02cf in trap (frame=3D0xffffff81b2da8a80) > at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579 > #7 0xffffffff8058992f in calltrap () > at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 > #8 0xffffffff803c43cb in kdb_enter (why=3D0xffffffff806145f3 "panic", > msg=3D0x80
) at cpufunc.h:63 > #9 0xffffffff8038f407 in panic (fmt=3D) > at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627 > #10 0xffffffff80568049 in vm_fault_hold (map=3D0xfffffe0002000000, > vaddr=3D18446743530148802560, fault_type=3D2 '\002', fault_flags=3D0, > m_hold=3D0x0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:285 > #11 0xffffffff80568753 in vm_fault (map=3D0xfffffe0002000000, > vaddr=3D18446743530148802560, fault_type=3D, > fault_flags=3D0) at /spare/tmp/src-stable9/sys/vm/vm_fault.c:229 > #12 0xffffffff805a00c7 in trap_pfault (frame=3D0xffffff81b2da9170, usermo= de=3D0) > at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:771 > #13 0xffffffff805a051e in trap (frame=3D0xffffff81b2da9170) > at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:463 > #14 0xffffffff8058992f in calltrap () > at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 > #15 0xffffffff8059d7b5 in bcopy () > at /spare/tmp/src-stable9/sys/amd64/amd64/support.S:134 > #16 0xffffffff81c5963b in nfsm_mbufuio (nd=3D0xffffff81b2da9320, > uiop=3D, siz=3D32768) > at /spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_comm= onsubs.c:212 > #17 0xffffffff81c19571 in nfsrpc_read (vp=3D0xfffffe0005ca2000, > uiop=3D0xffffff81b2da95a0, cred=3D, > p=3D0xfffffe0005f28000, nap=3D0xffffff81b2da9480, > attrflagp=3D0xffffff81b2da954c, stuff=3D0x0) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= rpcops.c:1343 > #18 0xffffffff81c3aff0 in ncl_readrpc (vp=3D0xfffffe0005ca2000, > uiop=3D0xffffff81b2da95a0, cred=3D) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= vnops.c:1366 > #19 0xffffffff81c2fed3 in ncl_doio (vp=3D0xfffffe0005ca2000, > bp=3D0xffffff816fabca20, cr=3D0xfffffe0002d59e00, td=3D0xfffffe0005f2= 8000, > called_from_strategy=3D0) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= bio.c:1605 > #20 0xffffffff81c32aaf in ncl_bioread (vp=3D0xfffffe0005ca2000, > uio=3D0xffffff81b2da9ad0, ioflag=3D, > cred=3D0xfffffe0002d59e00) > at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_cl= bio.c:541 > #21 0xffffffff804379c3 in vn_read (fp=3D0xfffffe0005f3e960, > uio=3D0xffffff81b2da9ad0, active_cred=3D, > flags=3D, td=3D) at vnode_i= f.h:384 > #22 0xffffffff80434d40 in vn_io_fault (fp=3D0xfffffe0005f3e960, > uio=3D0xffffff81b2da9ad0, active_cred=3D0xfffffe0002d59e00, flags=3D0, > td=3D0xfffffe0005f28000) at /spare/tmp/src-stable9/sys/kern/vfs_vnops= =2Ec:903 > #23 0xffffffff803d7bd1 in dofileread (td=3D0xfffffe0005f28000, fd=3D3, > fp=3D0xfffffe0005f3e960, auio=3D0xffffff81b2da9ad0, > offset=3D, flags=3D0) at file.h:287 > #24 0xffffffff803d7f7c in kern_readv (td=3D0xfffffe0005f28000, fd=3D3, > auio=3D0xffffff81b2da9ad0) > at /spare/tmp/src-stable9/sys/kern/sys_generic.c:250 > #25 0xffffffff803d8074 in sys_read (td=3D, > uap=3D) > at /spare/tmp/src-stable9/sys/kern/sys_generic.c:166 > #26 0xffffffff8059f4f0 in amd64_syscall (td=3D0xfffffe0005f28000, traced= =3D0) > at subr_syscall.c:135 > #27 0xffffffff80589c17 in Xfast_syscall () > at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:387 > #28 0x00000008009245fc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --vxNpRqk6sR1V+qwt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAXeOAAoJEJDCuSvBvK1B7yUQAI2Q7JdBYsuMUky5kTYyF9iQ X6Sp4TxZ8zBlX2j5moCOeohh4WFmH7WaS+XOUKre5Wl56ce9yigwkCf6GAEvSN0G uAw8Pd2+UpjNvpMbFwblvmB2Otrn4qG2f/Tg12F4oK3onURDS4tVMvyOYdU1piwS 8lmGzrrXmPwRU9HshMYEcyJsCIJESBqpzm/8Jf8L+hCa/QXDWEaviTRifh1ooTwl QKXPZ+CZZYi9JRqMo6wFMPWDlKejIYhl9axithelBFqKM6sfaqrLfAUB8WhttV9q abI1qYFNkiRd8pdUTnVF68lKe4fnhyets4UBhgbANGYzIZOZ+CDLWbBErXj0B9jZ 1Atvey0tTaQxxnsOe+GgwcyAq1XHUp5K9/gybpo5BESj5IBUbae/yj7OUKw1FxrG i1DM8m1Pgia+rACeVFc3mJOJoCHfUhubjSfnSDk/f5t0AR8ek3nyFGOoYstyVktH IAPTa88fJmmJeMpaLR3qP3IDBmrUfB0Jnkg2c6Sl/Im+r0JQ5GmaLG5c3ehpwp/T fdEOmyHJXvtyI0izWdksRTDV5UUmz4TfnoGgv5fzgjAANShnVR++9CNWcTDhy6sl J+/Sx04xWv6utoPG1To/z49ilx+sqmc0uHsrGXT/oa94DG5wqeaXS8ft9LVKgr43 EzsxLVM3yZAlE9bhUqYo =K3q3 -----END PGP SIGNATURE----- --vxNpRqk6sR1V+qwt-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 18:07:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0C226DC; Thu, 24 Jan 2013 18:07:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 15B91AFA; Thu, 24 Jan 2013 18:07:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0OI7NEl062045; Thu, 24 Jan 2013 20:07:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0OI7NEl062045 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0OI7NqU062044; Thu, 24 Jan 2013 20:07:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jan 2013 20:07:23 +0200 From: Konstantin Belousov To: Christian Gusenbauer Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130124180723.GI2522@kib.kiev.ua> References: <201301241805.57623.c47g@gmx.at> <20130124180359.GH2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKwGQjXLadG+jf5J" Content-Disposition: inline In-Reply-To: <20130124180359.GH2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:07:27 -0000 --gKwGQjXLadG+jf5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > Hi! > >=20 > > I'm using 9.1 stable svn revision 245605 and I get the panic below if I= execute the following commands (as single user): > >=20 > > # swapon -a > > # dumpon /dev/ada0s3b > > # mount -u / > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > # mount -t nfs -o rsize=3D32768 data:/multimedia /mnt > > # cp /mnt/Movies/test/a.m2ts /tmp > >=20 > > then the system panics almost immediately. I'll attach the stack trace. > >=20 > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe= that's the cause for the panic, because the bcopy (see=20 > > stack frame #15) fails. > >=20 > > Any clues? > I tried a similar operation with the nfs mount of rsize=3D32768 and mtu > 6144, but the machine runs HEAD and em instead of age. I was unable to > reproduce the panic on the copy of the 5GB file from nfs mount. >=20 > Show the output of "p *(struct uio *)0xffffff81b2da95a0" in kgdb. And the output of "p *(struct buf *)0xffffff816fabca20". --gKwGQjXLadG+jf5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAXhaAAoJEJDCuSvBvK1BSQsP/0ekIK2UoEQOnEn7FSjfTt5R 6/wNh5Q9CWm8A08CqwV/RNm+3MSNY/7b69+RbuBQyOGtZ/GrmSnB9nv0MGEBZUGM UkuGWy5w6DwaQunPTm7i8Ek+G9Bjk6aRiLO1OyTAL0nvGIxGmG87/OELIbStZjEx 1sc+EJRg9x5qFX8Y394Dm9ODovc46L64JT7znLKcCij0LGb8yxsCsxiSO+mv8oGn 8Z7pzr+Ll6SVg+4XzSuT51BXmcXeHsrMJdKEWiW2A0dPQ84xofEqmA2j2MVPQHdy AvYzyOqp8ebp360jhIQszm2mAL5cOA2VpjHvLDdtft1XFvJp5nHM61oJkBgpyiz1 85I/N3PhiQud/RVl7XF1hj3oRPOsKqvF5mjmUUG6mKCl8IGDr2ZzK+YZ7iq4nPam Hhi1+Avaqwnxovvij68UVByzqfODNUy0UrvwvwDXM6yeskxft9rbjf+NU8sRivYj A83gDxNHayvy/FrXS+ccaknrYV9jYa6KAF3A4KngPJpNK9yw0ab9n6V8X+1rP8yP 7hwVs3NuqJiuTrgC3MkoX1m5DHgpitjBmcJ6cgcGge92CbxY9LpD3R/uRUzyKwJ9 k9eoVXnNXX3dIXXKjmm8COjsZpRo2KKKoaEncjndb5eqDAuk3gXIFkhnVryKGE4t MZ/wsUsfMnBAgri0HKy5 =WsNv -----END PGP SIGNATURE----- --gKwGQjXLadG+jf5J-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 18:23:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 50A79CE9 for ; Thu, 24 Jan 2013 18:23:20 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id CE2ACC22 for ; Thu, 24 Jan 2013 18:22:41 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MGlNX-1UBJTW0mA5-00DWef for ; Thu, 24 Jan 2013 19:22:35 +0100 Received: (qmail invoked by alias); 24 Jan 2013 18:22:35 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp029) with SMTP; 24 Jan 2013 19:22:35 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1/Q5VpCBlnQBRz/5jQM+646V7vEzaUWjNQXtmnwxn Y36FEuSNddVTNU From: Christian Gusenbauer To: Konstantin Belousov Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Thu, 24 Jan 2013 19:24:12 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <20130124180359.GH2522@kib.kiev.ua> <20130124180723.GI2522@kib.kiev.ua> In-Reply-To: <20130124180723.GI2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201301241924.12999.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:23:20 -0000 On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > Hi! > > >=20 > > > I'm using 9.1 stable svn revision 245605 and I get the panic below if= I > > > execute the following commands (as single user): > > >=20 > > > # swapon -a > > > # dumpon /dev/ada0s3b > > > # mount -u / > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > # mount -t nfs -o rsize=3D32768 data:/multimedia /mnt > > > # cp /mnt/Movies/test/a.m2ts /tmp > > >=20 > > > then the system panics almost immediately. I'll attach the stack trac= e. > > >=20 > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, may= be > > > that's the cause for the panic, because the bcopy (see stack frame > > > #15) fails. > > >=20 > > > Any clues? > >=20 > > I tried a similar operation with the nfs mount of rsize=3D32768 and mtu > > 6144, but the machine runs HEAD and em instead of age. I was unable to > > reproduce the panic on the copy of the 5GB file from nfs mount. > >=20 > > Show the output of "p *(struct uio *)0xffffff81b2da95a0" in kgdb. (kgdb) p *(struct uio *)0xffffff81b2da95a0 $1 =3D {uio_iov =3D 0xffffff81b2da95d0, uio_iovcnt =3D 1, uio_offset =3D 59= 64,=20 uio_resid =3D 26804,=20 uio_segflg =3D UIO_SYSSPACE, uio_rw =3D UIO_READ, uio_td =3D 0xfffffe0005= f28000} >=20 > And the output of "p *(struct buf *)0xffffff816fabca20". (kgdb) p *(struct buf *)0xffffff816fabca20 $2 =3D {b_bufobj =3D 0xfffffe0005ca2120, b_bcount =3D 32768, b_caller1 =3D = 0x0,=20 b_data =3D 0xffffff8171418000 "=F8\017", b_error =3D 0, b_iocmd =3D 1 '\0= 01',=20 b_ioflags =3D 0 '\0', b_iooffset =3D 0, b_resid =3D 0, b_iodone =3D 0, b_= blkno =3D 0,=20 b_offset =3D 0, b_bobufs =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffffe0005= ca2140},=20 b_left =3D 0x0,=20 b_right =3D 0x0, b_vflags =3D 0, b_freelist =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xffffffff80926900}, b_qindex =3D 0, b_flags =3D 536870912= ,=20 b_xflags =3D 2 '\002', b_lock =3D {lock_object =3D {lo_name =3D 0xfffffff= f8061d778=20 "bufwait",=20 lo_flags =3D 91422720, lo_data =3D 0, lo_witness =3D 0x0},=20 lk_lock =3D 18446741874786074624, lk_exslpfail =3D 0, lk_timo =3D 0, lk= _pri =3D=20 96},=20 b_bufsize =3D 32768, b_runningbufspace =3D 0, b_kvabase =3D 0xffffff81714= 18000=20 "=F8\017",=20 b_kvasize =3D 32768, b_lblkno =3D 0, b_vp =3D 0xfffffe0005ca2000, b_dirty= off =3D 0,=20 b_dirtyend =3D 0, b_rcred =3D 0x0, b_wcred =3D 0x0, b_saveaddr =3D=20 0xffffff8171418000,=20 b_pager =3D {pg_reqpage =3D 0}, b_cluster =3D {cluster_head =3D {tqh_firs= t =3D 0x0,=20 tqh_last =3D 0x0}, cluster_entry =3D {tqe_next =3D 0x0, tqe_prev =3D = 0x0}},=20 b_pages =3D { 0xfffffe01f1786708, 0xfffffe01f1785880, 0xfffffe01f17858f8,=20 0xfffffe01f1785970,=20 0xfffffe01f17859e8, 0xfffffe01f1785a60, 0xfffffe01f1785ad8,=20 0xfffffe01f1785b50,=20 0x0 }, b_npages =3D 8, b_dep =3D {lh_first =3D 0x0},= =20 b_fsprivate1 =3D 0x0,=20 b_fsprivate2 =3D 0x0, b_fsprivate3 =3D 0x0, b_pin_count =3D 0} From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 18:49:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 254A95F0 for ; Thu, 24 Jan 2013 18:49:12 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id B9B46E15 for ; Thu, 24 Jan 2013 18:49:11 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MRQbm-1UR9sk3Ojw-00ScLv for ; Thu, 24 Jan 2013 19:49:10 +0100 Received: (qmail invoked by alias); 24 Jan 2013 18:49:10 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp012) with SMTP; 24 Jan 2013 19:49:10 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX183RQcrvRQ3lZC92BaP33z2miqhc45iF+iGlK6+oE Gu4laaVCN2Z+cV From: Christian Gusenbauer To: Konstantin Belousov Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Thu, 24 Jan 2013 19:50:49 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <20130124180359.GH2522@kib.kiev.ua> <20130124180723.GI2522@kib.kiev.ua> In-Reply-To: <20130124180723.GI2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301241950.49455.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:49:12 -0000 On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > Hi! > > > > > > I'm using 9.1 stable svn revision 245605 and I get the panic below if I > > > execute the following commands (as single user): > > > > > > # swapon -a > > > # dumpon /dev/ada0s3b > > > # mount -u / > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > then the system panics almost immediately. I'll attach the stack trace. > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, maybe > > > that's the cause for the panic, because the bcopy (see stack frame > > > #15) fails. > > > > > > Any clues? > > > > I tried a similar operation with the nfs mount of rsize=32768 and mtu > > 6144, but the machine runs HEAD and em instead of age. I was unable to > > reproduce the panic on the copy of the 5GB file from nfs mount. Hmmm, I did a quick test. If I do not change the MTU, so just configuring age0 with # ifconfig age0 inet 192.168.2.2 up then I can copy all files from the mounted directory without any problems, too. So it's probably age0 related? Ciao, Christian. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 19:37:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 667BC7E4; Thu, 24 Jan 2013 19:37:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CA6466C; Thu, 24 Jan 2013 19:37:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0OJb9uU071565; Thu, 24 Jan 2013 21:37:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0OJb9uU071565 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0OJb9HT071564; Thu, 24 Jan 2013 21:37:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jan 2013 21:37:09 +0200 From: Konstantin Belousov To: Christian Gusenbauer Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130124193709.GL2522@kib.kiev.ua> References: <201301241805.57623.c47g@gmx.at> <20130124180359.GH2522@kib.kiev.ua> <20130124180723.GI2522@kib.kiev.ua> <201301241950.49455.c47g@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="08mGw3CZk5wypUJm" Content-Disposition: inline In-Reply-To: <201301241950.49455.c47g@gmx.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:37:21 -0000 --08mGw3CZk5wypUJm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > > Hi! > > > >=20 > > > > I'm using 9.1 stable svn revision 245605 and I get the panic below = if I > > > > execute the following commands (as single user): > > > >=20 > > > > # swapon -a > > > > # dumpon /dev/ada0s3b > > > > # mount -u / > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > # mount -t nfs -o rsize=3D32768 data:/multimedia /mnt > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > >=20 > > > > then the system panics almost immediately. I'll attach the stack tr= ace. > > > >=20 > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, m= aybe > > > > that's the cause for the panic, because the bcopy (see stack frame > > > > #15) fails. > > > >=20 > > > > Any clues? > > >=20 > > > I tried a similar operation with the nfs mount of rsize=3D32768 and m= tu > > > 6144, but the machine runs HEAD and em instead of age. I was unable to > > > reproduce the panic on the copy of the 5GB file from nfs mount. >=20 > Hmmm, I did a quick test. If I do not change the MTU, so just configuring= age0=20 > with >=20 > # ifconfig age0 inet 192.168.2.2 up >=20 > then I can copy all files from the mounted directory without any problems= ,=20 > too. So it's probably age0 related? =46rom your backtrace and the buffer printout, I see somewhat strange thing. The buffer data address is 0xffffff8171418000, while kernel faulted at the attempt to write at 0xffffff8171413000, which is is lower then the buffer data pointer, at the attempt to bcopy to the buffer. The other data suggests that there were no overflow of the data from the server response. So it might be that mbuf_len(mp) returned negative number ? I am not sure is it possible at all. Try this debugging patch, please. You need to add INVARIANTS etc to the kernel config. diff --git a/sys/fs/nfs/nfs_commonsubs.c b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 --- a/sys/fs/nfs/nfs_commonsubs.c +++ b/sys/fs/nfs/nfs_commonsubs.c @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *uio= p, int siz) } mbufcp =3D NFSMTOD(mp, caddr_t); len =3D mbuf_len(mp); + KASSERT(len > 0, ("len %d", len)); } xfer =3D (left > len) ? len : left; #ifdef notdef @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *uio= p, int siz) uiop->uio_resid -=3D xfer; } if (uiop->uio_iov->iov_len <=3D siz) { + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", + uiop->uio_iovcnt)); uiop->uio_iovcnt--; uiop->uio_iov++; } else { I thought that server have returned too long response, but it seems to be not the case from your data. Still, I think the patch below might be due. diff --git a/sys/fs/nfsclient/nfs_clrpcops.c b/sys/fs/nfsclient/nfs_clrpcop= s.c index be0476a..a89b907 100644 --- a/sys/fs/nfsclient/nfs_clrpcops.c +++ b/sys/fs/nfsclient/nfs_clrpcops.c @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, struct u= cred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); eof =3D fxdr_unsigned(int, *tl); } - NFSM_STRSIZ(retlen, rsize); + NFSM_STRSIZ(retlen, len); error =3D nfsm_mbufuio(nd, uiop, retlen); if (error) goto nfsmout; --08mGw3CZk5wypUJm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAY1kAAoJEJDCuSvBvK1B3GIP/R35aJSwVPR4UYtMoamu5VC/ eYrSSZ8iREbFXRIWCmBBY3dZGgGB83/h0jo7p9Q9C1eQTuo+3oPc9L3HFp6m9d4c +Lcf/S+GMi9Ncmm6QbNv8IM3WOhBhPnimQlqoJkP0qTYNUoHGCJQSEJuXXs8ca/8 Nl84xHMiuYoc2WU+sQ8gn32+EFDp4DeEzlbXPTT0hLTxgBrMZWsjjGDCJ61POx+u Fy2EcoAGmFQWxM33RZbvp2LPnrO6fczF6Q38kvGsVWsljz0N0vj9ZumV/9H+hElO gkkaAQyy77Kh1AhaAEFLvIkpQQu63FJsUJiNYSauIbO3SM23/7pB75+WPUEHUe0l 6d7NlkYhcxkltVms+AGDNYcOzXmaLr3kvd8iCOeC8EssXGM0Gtsd1IOUBicmZIXK FkI4qCbY7FvrBkiEV59xISIAkYnXH4ov/GZ5ks+VSy0mLr9f2wiwMLsrWdQYNbpm 2m4sKy+ubfHzb0ZOV4R49qR/IJhDbQSOW6J0Ro0GF/Y4zOMl3xOxcOC9zPMixa7E reHs/jERnmH9Rwb7J8U180VNujy8Oab2JXgB5/KrVqO2UVgRMidMirqqMsa+EYiU hu1SdaM5LA+qcmi4FbXhEXLzvGk16o6JnavbIY8IT9hDDtljBDJYP0jnHGjCBWLw naLEkaMdchHSCKIIrRpI =MFh3 -----END PGP SIGNATURE----- --08mGw3CZk5wypUJm-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 20:49:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B1DD948 for ; Thu, 24 Jan 2013 20:49:16 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id EC5CD62F for ; Thu, 24 Jan 2013 20:49:15 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MRhn5-1UQtgh1aaf-00StLW for ; Thu, 24 Jan 2013 21:49:14 +0100 Received: (qmail invoked by alias); 24 Jan 2013 20:49:12 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp019) with SMTP; 24 Jan 2013 21:49:12 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+NNqF5x/CNZrBmCGwv1aPuCtq8AKOzHlJ1RM8O0R k9jtSAHQ94dpzb From: Christian Gusenbauer To: Konstantin Belousov Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Thu, 24 Jan 2013 21:50:52 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <201301241950.49455.c47g@gmx.at> <20130124193709.GL2522@kib.kiev.ua> In-Reply-To: <20130124193709.GL2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301242150.52238.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:49:16 -0000 On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > > > Hi! > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get the panic below > > > > > if I execute the following commands (as single user): > > > > > > > > > > # swapon -a > > > > > # dumpon /dev/ada0s3b > > > > > # mount -u / > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > then the system panics almost immediately. I'll attach the stack > > > > > trace. > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit network, > > > > > maybe that's the cause for the panic, because the bcopy (see stack > > > > > frame #15) fails. > > > > > > > > > > Any clues? > > > > > > > > I tried a similar operation with the nfs mount of rsize=32768 and mtu > > > > 6144, but the machine runs HEAD and em instead of age. I was unable > > > > to reproduce the panic on the copy of the 5GB file from nfs mount. > > > > Hmmm, I did a quick test. If I do not change the MTU, so just configuring > > age0 with > > > > # ifconfig age0 inet 192.168.2.2 up > > > > then I can copy all files from the mounted directory without any > > problems, too. So it's probably age0 related? > > From your backtrace and the buffer printout, I see somewhat strange thing. > The buffer data address is 0xffffff8171418000, while kernel faulted > at the attempt to write at 0xffffff8171413000, which is is lower then > the buffer data pointer, at the attempt to bcopy to the buffer. > > The other data suggests that there were no overflow of the data from the > server response. So it might be that mbuf_len(mp) returned negative number > ? I am not sure is it possible at all. > > Try this debugging patch, please. You need to add INVARIANTS etc to the > kernel config. > > diff --git a/sys/fs/nfs/nfs_commonsubs.c b/sys/fs/nfs/nfs_commonsubs.c > index efc0786..9a6bda5 100644 > --- a/sys/fs/nfs/nfs_commonsubs.c > +++ b/sys/fs/nfs/nfs_commonsubs.c > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio > *uiop, int siz) } > mbufcp = NFSMTOD(mp, caddr_t); > len = mbuf_len(mp); > + KASSERT(len > 0, ("len %d", len)); > } > xfer = (left > len) ? len : left; > #ifdef notdef > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio > *uiop, int siz) uiop->uio_resid -= xfer; > } > if (uiop->uio_iov->iov_len <= siz) { > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > + uiop->uio_iovcnt)); > uiop->uio_iovcnt--; > uiop->uio_iov++; > } else { > > I thought that server have returned too long response, but it seems to > be not the case from your data. Still, I think the patch below might be > due. > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > --- a/sys/fs/nfsclient/nfs_clrpcops.c > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, struct > ucred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); > eof = fxdr_unsigned(int, *tl); > } > - NFSM_STRSIZ(retlen, rsize); > + NFSM_STRSIZ(retlen, len); > error = nfsm_mbufuio(nd, uiop, retlen); > if (error) > goto nfsmout; I applied your patches and now I get a panic: len -4 cpuid = 1 KDB: enter: panic Dumping 377 out of 6116 MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% #0 doadump (textdump=0) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 265 if (textdump && textdump_pending) { (kgdb) #0 doadump (textdump=0) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:265 #1 0xffffffff802a7490 in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /spare/tmp/src-stable9/sys/ddb/db_command.c:538 #2 0xffffffff802a6a7e in db_command (last_cmdp=0xffffffff808ca140, cmd_table=, dopager=1) at /spare/tmp/src-stable9/sys/ddb/db_command.c:449 #3 0xffffffff802a6cd0 in db_command_loop () at /spare/tmp/src-stable9/sys/ddb/db_command.c:502 #4 0xffffffff802a8e29 in db_trap (type=, code=) at /spare/tmp/src-stable9/sys/ddb/db_main.c:231 #5 0xffffffff803bf548 in kdb_trap (type=3, code=0, tf=0xffffff81b2ba1080) at /spare/tmp/src-stable9/sys/kern/subr_kdb.c:649 #6 0xffffffff80594c28 in trap (frame=0xffffff81b2ba1080) at /spare/tmp/src-stable9/sys/amd64/amd64/trap.c:579 #7 0xffffffff8057e06f in calltrap () at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:228 #8 0xffffffff803beffb in kdb_enter (why=0xffffffff8060ebcf "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff80389391 in panic (fmt=) at /spare/tmp/src-stable9/sys/kern/kern_shutdown.c:627 #10 0xffffffff81e5bab2 in nfsm_mbufuio (nd=0xffffff81b2ba1340, uiop=0x7cf, siz=18) at /spare/tmp/src-stable9/sys/modules/nfscommon/../../fs/nfs/nfs_commonsubs.c:202 #11 0xffffffff81e195c1 in nfsrpc_read (vp=0xfffffe0006c94dc8, uiop=0xffffff81b2ba15c0, cred=, p=0xfffffe0006aa6490, nap=0xffffff81b2ba14a0, attrflagp=0xffffff81b2ba156c, stuff=0x0) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clrpcops.c:1343 #12 0xffffffff81e3bd80 in ncl_readrpc (vp=0xfffffe0006c94dc8, uiop=0xffffff81b2ba15c0, cred=) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clvnops.c:1366 #13 0xffffffff81e3086b in ncl_doio (vp=0xfffffe0006c94dc8, bp=0xffffff816f8f4120, cr=0xfffffe0002d58e00, td=0xfffffe0006aa6490, called_from_strategy=0) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:1605 #14 0xffffffff81e3254f in ncl_bioread (vp=0xfffffe0006c94dc8, uio=0xffffff81b2ba1ad0, ioflag=, cred=0xfffffe0002d58e00) at /spare/tmp/src-stable9/sys/modules/nfscl/../../fs/nfsclient/nfs_clbio.c:541 #15 0xffffffff80434ae8 in vn_read (fp=0xfffffe0006abda50, uio=0xffffff81b2ba1ad0, active_cred=, flags=, td=) at vnode_if.h:384 #16 0xffffffff8043206e in vn_io_fault (fp=0xfffffe0006abda50, uio=0xffffff81b2ba1ad0, active_cred=0xfffffe0002d58e00, flags=0, td=0xfffffe0006aa6490) at /spare/tmp/src-stable9/sys/kern/vfs_vnops.c:903 #17 0xffffffff803d7ac1 in dofileread (td=0xfffffe0006aa6490, fd=3, fp=0xfffffe0006abda50, auio=0xffffff81b2ba1ad0, offset=, flags=0) at file.h:287 #18 0xffffffff803d7e1c in kern_readv (td=0xfffffe0006aa6490, fd=3, auio=0xffffff81b2ba1ad0) at /spare/tmp/src-stable9/sys/kern/sys_generic.c:250 #19 0xffffffff803d7f34 in sys_read (td=, uap=) at /spare/tmp/src-stable9/sys/kern/sys_generic.c:166 #20 0xffffffff80593cb3 in amd64_syscall (td=0xfffffe0006aa6490, traced=0) at subr_syscall.c:135 #21 0xffffffff8057e357 in Xfast_syscall () at /spare/tmp/src-stable9/sys/amd64/amd64/exception.S:387 #22 0x00000008009245fc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 02:20:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6AA6AFB for ; Fri, 25 Jan 2013 02:20:58 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail4.riverwillow.net.au (mail4.riverwillow.net.au [202.125.45.59]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC7B3D5 for ; Fri, 25 Jan 2013 02:20:57 +0000 (UTC) Received: from [172.25.24.201] (riverw1.lnk.telstra.net [165.228.239.138]) (authenticated bits=0) by mail4.riverwillow.net.au (8.14.6/8.14.6) with ESMTP id r0P2Kf4o075937 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 25 Jan 2013 12:20:43 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m4001; t=1359080444; bh=RpPsnGaLtlotgN+X2q0XSvGF/HRDbTEeF2DOB2061qU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=BWcc6CMoyvo6M/aZ/477Wr34AieQWI4ANG0UV3R44QpW3ICZVkdQnXOYKadBFDBsS mJrfXQS1k3MaE5hPASQXs0OESRZVv5u6w8n8aVggFTjeJzff4o9gfKS7URqO2IIOsh JMSIzlW/+C3PM84VHR/HlZJJjwb84hko9ophLdiU= Message-ID: <5101EBEF.3020404@riverwillow.com.au> Date: Fri, 25 Jan 2013 13:20:31 +1100 From: John Marshall Organization: Riverwillow Pty Ltd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Mehr Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <5101235D.8040006@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF72377ECF3AB6BA24201E0C0" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 02:20:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF72377ECF3AB6BA24201E0C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 25/01/2013 03:13, Chris Rees wrote: > On 24 Jan 2013 14:33, "John Mehr" wrote: >> Correct. I just want to give the folks that administer the servers a > heads-up that there's going to be a lot more entries in their log files= > coming from me -- unless it's an undocumented feature of the svn protoc= ol, > md5 signatures for files are not included in directory requests and I n= eed > to issue a get-file command for each and every file to get their md5 > signatures in order to determine which local files need an update. :( >=20 > It'd probably be faster for you to use svnsync to get a local mirror of= the > repo. and if you're going to set up a local mirror, save yourself a couple of days' sync time. Instead of synchronizing from scratch, start with the most recent seed file (repository archive) available on your nearest FTP mirror. ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ Clues for building a mirror can be found here: =2E..but if you're only using it for testing - and it doesn't need to be up to date - then you don't need to worry about setting up svnsync and updating your local mirror. Simply unbundling an archive of a repository from a seed file and serving it via svnserve (and/or apache) is all you need to do. --=20 John Marshall --------------enigF72377ECF3AB6BA24201E0C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEB6/gACgkQw/tAaKKahKJR1QCgkHq0ONGObI4bdSlvGWqr2Omk lC0AniE9Bl3sy7MGVLhgTiSFBV4u28d+ =CJyN -----END PGP SIGNATURE----- --------------enigF72377ECF3AB6BA24201E0C0-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 06:10:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83D46BE6 for ; Fri, 25 Jan 2013 06:10:04 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2FFF53 for ; Fri, 25 Jan 2013 06:10:03 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d4so7312eek.36 for ; Thu, 24 Jan 2013 22:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=cYnqvCKfnexc5EmpI0SLVu53OGf4cRAjJi3RTpNIoY0=; b=GgGoWYLUyeldEhm6IDe79rBbzyUB/M5ryS+edazmoiNtL2DBoNR45eXjodCwhNp0+A j/Umu+oG6WN/LCByUml/uUdaom6X+Lo/N20X3x8iu+8DSCRVtsgwjScSKZ0hYOBxfnKE /SGoDKFiAUAqIItOmOM4olFL0+B5d3ARShLHmjWYkxRBadwmOJrXTuACDAHF9Iam6OuU I5q+CY8JgQyiJrgVLprk3eF4HsjMS577gWYrqmXT2okRq6+Okd60N6yL455PHSEIHL8e O9xiwx9qEWlRnOmTzA+q0slus2pg4aOlldawSZ+U0geA617/V9YlHwzrijKQib+ENF4E VfuQ== X-Received: by 10.14.174.132 with SMTP id x4mr14393593eel.39.1359094197455; Thu, 24 Jan 2013 22:09:57 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id 3sm93855eej.6.2013.01.24.22.09.55 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 24 Jan 2013 22:09:56 -0800 (PST) Date: Fri, 25 Jan 2013 09:09:58 +0300 From: "Sergey V. Dyatko" To: Derek Kulinski Subject: Re: svn - but smaller? Message-ID: <20130125090958.2700cc5b@laptop> In-Reply-To: <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 06:10:04 -0000 On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski wrote: > "Sergey V. Dyatko" wrote: > > >You may: > >1/ install subversion on some host/jail > >2/ do svn export ( f.e. svn://svn.freebsd.org/base/releng/9 stable_9) > >3/ tar it > >4/ on 'client' fetch(1)/scp/rsync tarball > > > >in that case you don't need svn on 'client', fetch and scp in base :) > > If you go through all of that why not just install the damn svn from > ports? I have svn installed on all my boxes (for src and configs) ;-) > > I think you don't understand the reason why people are asking for > this. I personally experienced the need not long ago. I had stable/9 > branch and wanted to downgrade to 9.0. The entire process went well > until I rebooted the system, to see tons of errors in pretty much > everything that was compiled from ports. Instead recompiling them > from scratch I just decided to go ahead and upgrade to 9.1 which was > not officially released yet. > how in this case you would have helped availability lite-svn-client on base ? > And of course I could not perform svn sw because svn was broken too. r232944 | lev | 2009-04-29 15:11:17 +0300 ... (3) Add STATIC option to build only static binaries [2] ... > And since svn has tons of dependencies it took me nearly an hour to > recompile them (portupgrade and Ruby were broken too). > that's why I don't use portupgrade for a long time;-) use portmaster WTF -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 07:29:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A040CE07 for ; Fri, 25 Jan 2013 07:29:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B97326C for ; Fri, 25 Jan 2013 07:29:56 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tydjg-0007Mr-PY for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 08:30:04 +0100 Received: from cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com ([86.21.186.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2013 08:30:04 +0100 Received: from walterhurry by cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jan 2013 08:30:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Walter Hurry Subject: Re: svn - but smaller? Date: Fri, 25 Jan 2013 07:27:58 +0000 (UTC) Lines: 44 Message-ID: References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> <20130125090958.2700cc5b@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:29:57 -0000 On Fri, 25 Jan 2013 09:09:58 +0300, Sergey V. Dyatko wrote: > On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski > wrote: > >> "Sergey V. Dyatko" wrote: >> >> >You may: >> >1/ install subversion on some host/jail 2/ do svn export ( f.e. >> >svn://svn.freebsd.org/base/releng/9 stable_9) >> >3/ tar it 4/ on 'client' fetch(1)/scp/rsync tarball >> > >> >in that case you don't need svn on 'client', fetch and scp in base :) >> >> If you go through all of that why not just install the damn svn from >> ports? > > I have svn installed on all my boxes (for src and configs) ;-) > > >> I think you don't understand the reason why people are asking for this. >> I personally experienced the need not long ago. I had stable/9 branch >> and wanted to downgrade to 9.0. The entire process went well until I >> rebooted the system, to see tons of errors in pretty much everything >> that was compiled from ports. Instead recompiling them from scratch I >> just decided to go ahead and upgrade to 9.1 which was not officially >> released yet. >> > how in this case you would have helped availability lite-svn-client on > base ? > >> And of course I could not perform svn sw because svn was broken too. > r232944 | lev | 2009-04-29 15:11:17 +0300 ... > (3) Add STATIC option to build only static binaries [2] > ... > >> And since svn has tons of dependencies it took me nearly an hour to >> recompile them (portupgrade and Ruby were broken too). >> >> > that's why I don't use portupgrade for a long time;-) > use portmaster WTF Portupgrade works fine for me. What's the problem with it? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 07:42:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15F0B2CE for ; Fri, 25 Jan 2013 07:42:19 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id A39EE319 for ; Fri, 25 Jan 2013 07:42:18 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d4so37519eek.8 for ; Thu, 24 Jan 2013 23:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=mB0oNLgdrCkzwrCl9oaTC+aN9WHiAPYbB54im1n8Y7Y=; b=OlqBxx+SMaY8ZtZcCirBKIP7nD+7gfdkL1GxDC1OXsZN8s/ePHp68c3sBozqZj2kIU y6fZ4XhsZIvaGvktjKoXDPrpa53xBBSb4aZLh7JbZq1cokLmFjR7YeZE1tTTYvFQ8tyo f2XqpEz3glI4M7qaEEMWeKLymLP7vBasA+SYsuaeQ8JIOznin8V8YftcCpdhQNzvyLkD 4HdDk8CBqcslN57e/Lkh8hAzo5dPN3xxWCsLQMerQrUE2hTq4FBLaqez98TbF1qPsPKe 48sbUS704IuBl+RBdVv0pfhkMfRCR5cgaLqIaAvp4FbhAYwCqhf8h8ivNO3FDROnoHdC nj6A== X-Received: by 10.14.174.73 with SMTP id w49mr15468231eel.17.1359099731831; Thu, 24 Jan 2013 23:42:11 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id q5sm393127eep.11.2013.01.24.23.42.10 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 24 Jan 2013 23:42:11 -0800 (PST) Date: Fri, 25 Jan 2013 10:42:12 +0300 From: "Sergey V. Dyatko" To: Walter Hurry Subject: Re: svn - but smaller? Message-ID: <20130125104212.6d51687f@laptop> In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> <20130125090958.2700cc5b@laptop> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:42:19 -0000 On Fri, 25 Jan 2013 07:27:58 +0000 (UTC) Walter Hurry wrote: > On Fri, 25 Jan 2013 09:09:58 +0300, Sergey V. Dyatko wrote: > > > On Thu, 24 Jan 2013 00:06:47 -0800 Derek Kulinski > > wrote: > > > >> "Sergey V. Dyatko" wrote: > >> > >> >You may: > >> >1/ install subversion on some host/jail 2/ do svn export ( f.e. > >> >svn://svn.freebsd.org/base/releng/9 stable_9) > >> >3/ tar it 4/ on 'client' fetch(1)/scp/rsync tarball > >> > > >> >in that case you don't need svn on 'client', fetch and scp in > >> >base :) > >> > >> If you go through all of that why not just install the damn svn > >> from ports? > > > > I have svn installed on all my boxes (for src and configs) ;-) > > > > > >> I think you don't understand the reason why people are asking for > >> this. I personally experienced the need not long ago. I had > >> stable/9 branch and wanted to downgrade to 9.0. The entire process > >> went well until I rebooted the system, to see tons of errors in > >> pretty much everything that was compiled from ports. Instead > >> recompiling them from scratch I just decided to go ahead and > >> upgrade to 9.1 which was not officially released yet. > >> > > how in this case you would have helped availability lite-svn-client > > on base ? > > > >> And of course I could not perform svn sw because svn was broken > >> too. > > r232944 | lev | 2009-04-29 15:11:17 +0300 ... > > (3) Add STATIC option to build only static binaries [2] > > ... > > > >> And since svn has tons of dependencies it took me nearly an hour to > >> recompile them (portupgrade and Ruby were broken too). > >> > >> > > that's why I don't use portupgrade for a long time;-) > > use portmaster WTF > > Portupgrade works fine for me. What's the problem with it? > 1) "portupgrade and Ruby were broken too" from original email (yep, long time ago I faced with this too) 2) heavy depts(ruby) 3) don't know how it is now, but before it was supported weakly (large thread in ports@ (?) year or two ago, IIRC) -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 08:17:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 432F87A3 for ; Fri, 25 Jan 2013 08:17:05 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 20EEA65A for ; Fri, 25 Jan 2013 08:17:04 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id r0P8GvRM005384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 00:16:58 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Fri, 25 Jan 2013 00:13:59 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1406837249.20130125001359@takeda.tk> To: "Sergey V. Dyatko" Subject: Re: svn - but smaller? In-Reply-To: <20130125090958.2700cc5b@laptop> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <0c1603f1-a6af-4511-b230-8b791df7f9d7@email.android.com> <20130125090958.2700cc5b@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:17:05 -0000 Hello Sergey, Thursday, January 24, 2013, 10:09:58 PM, you wrote: >> I think you don't understand the reason why people are asking for >> this. I personally experienced the need not long ago. I had stable/9 >> branch and wanted to downgrade to 9.0. The entire process went well >> until I rebooted the system, to see tons of errors in pretty much >> everything that was compiled from ports. Instead recompiling them >> from scratch I just decided to go ahead and upgrade to 9.1 which was >> not officially released yet. > how in this case you would have helped availability lite-svn-client on > base ? The base worked fine, the ports were completely broken. And even if it was somehow broken (perhaps buildworld did not correctly built it) if it was part of the base it would not depend on any external ports. >> And of course I could not perform svn sw because svn was broken too. > r232944 | lev | 2009-04-29 15:11:17 +0300 > ... > (3) Add STATIC option to build only static binaries [2] > ... While that would not apply to my case (switch within major version), what about ABI incompatibilities? >> And since svn has tons of dependencies it took me nearly an hour to >> recompile them (portupgrade and Ruby were broken too). > that's why I don't use portupgrade for a long time;-) > use portmaster WTF Other than that it works very well, but I will give portmaster a try. -- Best regards, Derek mailto:takeda@takeda.tk Cole's Law: Thinly sliced cabbage. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 08:44:16 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD3BDED6 for ; Fri, 25 Jan 2013 08:44:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4E3878C for ; Fri, 25 Jan 2013 08:44:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA29674 for ; Fri, 25 Jan 2013 10:44:14 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TyetS-000F6o-Ay for freebsd-stable@FreeBSD.org; Fri, 25 Jan 2013 10:44:14 +0200 Message-ID: <510245DE.6080206@FreeBSD.org> Date: Fri, 25 Jan 2013 10:44:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: acpi resume related patch X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:44:16 -0000 If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 08:46:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA78CC0 for ; Fri, 25 Jan 2013 08:46:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 555DA7C5 for ; Fri, 25 Jan 2013 08:46:18 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TyevK-0007lx-Nr for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 10:46:10 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: bge numbering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2013 10:46:10 +0200 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:46:18 -0000 Hi, this server, a Dell R720 has 4 bge on board, Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 bge0: APE FW version: NCSI v1.1.7.0 bge0: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E miibus0: on bge0 ... I have connected the ethernet to port labeled 0, but it appears as bge2, how can this be corrected? thanks, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 09:27:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 302EFD03 for ; Fri, 25 Jan 2013 09:27:26 +0000 (UTC) (envelope-from prvs=07378d258e=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id E766F990 for ; Fri, 25 Jan 2013 09:27:25 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TyfZD-000AXw-G9 for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 10:27:23 +0100 Date: Fri, 25 Jan 2013 10:27:23 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130125092723.GC79995@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20130123144050.GG51786@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123144050.GG51786@e-Gitt.NET> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:27:26 -0000 Hi folks, thank you for all the answers and fruitful discussion. Special thanks goes to Chris Rees for coming up with the subversion-static ports quite fast, so now we're hoping for package building to kick in here - but that is a quick and very useful way after setting up a fresh machine (specifically if it's not within the bounds of your own infrastructure)! Also I'd like to mention John Mehr, who's work on a "lightweight, dependency-free, BSD licensed program to pull source using the svn protocol" (couldn't say it better, so I use his words :-)). Hope this will make it into ports soon and in the long run even to base! Thanx again, Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 09:29:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B69AE1A for ; Fri, 25 Jan 2013 09:29:22 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by mx1.freebsd.org (Postfix) with ESMTP id C35BD9B4 for ; Fri, 25 Jan 2013 09:29:21 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id i18so89959bkv.32 for ; Fri, 25 Jan 2013 01:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kAHov67JOvBbD3gbGVRvUhb0t7Uhlss0SUaIG3Xytpo=; b=rEU7iJOPMq3KNM5uyBTtiKzFDBBcPRmPOypv1HQWQN2CW4fXqXZAUoM1yiyLE/FNUc i4NyReTT7nEW6dZV9F0Hw7ThfqMUtr5OMeqxBBgbKtEaN4NqdUHmmuRIJvA/f/YzHbvY AwxZe7tyBPl1BszaFEBM9MVrrCAjC2GSpWA/Z9SuyRwGGZeQrP32HaNaPqsF/BWYF0G/ kHZnKFg3Fx3J+ynuoGDfPx6lgnsB+fuYF/qdfJ7LVOEFhh5Yr4k7x3Gz5eRIjsTZ0gm1 /1C/S56g7mW1DylirDWXlWEyYklejbS7Sdx+BwaPbjobFIEK0812YM8uhm++pciPIUZT MzWg== MIME-Version: 1.0 X-Received: by 10.204.148.154 with SMTP id p26mr1645555bkv.31.1359106154978; Fri, 25 Jan 2013 01:29:14 -0800 (PST) Received: by 10.205.112.11 with HTTP; Fri, 25 Jan 2013 01:29:14 -0800 (PST) In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> Date: Fri, 25 Jan 2013 11:29:14 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: John Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:29:22 -0000 Hello again :) Here's my update on these spontaneous reboots after less than a week since I've updated to stable/9. First two days the system was running fine with no reboots happening, so I though that this update actually fixed it, but I was wrong. The reboots are still happening and still no clear evidence of the root cause. What I did so far: * Ran disks tests -- looking good * Ran memtest -- looking good * Replaced power cables * Ran UPS tests -- looking good * Checked for any bad capacitors -- none found * Removed all ZFS snapshots There is also one more machine connected to the same UPS, so if it was a UPS issue I'd expect that the other one reboots too, but that's not the case. Now that I've excluded the hardware part of this problem I started looking again into the software side, and this time in particular -- ZFS. I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of memory. A quick look at top(1) showed lots of memory usage by ARC and my available free memory dropping fast. I've made a screenshot, which you can see on the link below: * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide [1], but honestly at the end I was not sure which parameters I need to increase/decrease and to what values. Here's some info about my current parameters. % sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 % sysctl vm.kmem_size vm.kmem_size: 8279539712 % sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 7205797888 % sysctl kern.maxvnodes kern.maxvnodes: 206227 There's one script at the ZFSTuningGuide which calculates kernel memory utilization, and for me these values are listed below: TEXT=22402749, 21.3649 MB DATA=4896264192, 4669.44 MB TOTAL=4918666941, 4690.81 MB While looking for ZFS tuning I've also stumbled upon this thread in the FreeBSD Forums [2], where the OP describes a similar behaviour to what I am already experiencing, so I'm quite worried now that the reason for these crashes is ZFS. Before jumping into any change to the kernel parameters (vm.kmem_size, vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any feedback from people that have already done such optimizations on their ZFS systems. Could you please share what are the optimal values for these parameters on a system with 8Gb of memory? Is there a way to calculate these values or is it just a "test-and-see-which-fits-better" way of doing this? Thanks and regards, Marin [1]: https://wiki.freebsd.org/ZFSTuningGuide [2]: http://forums.freebsd.org/showthread.php?t=9143 On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov wrote: > > > > On Sat, Jan 19, 2013 at 10:19 PM, John wrote: > >> >At 03:00am I can see that periodic(8) runs, but I don't see what could >> have >> >taken so much of the free memory. I'm also running this system on ZFS and >> >have daily rotating ZFS snapshots created - currently the number of ZFS >> >snapshots are > 1000, and not sure if that could be causing this. Here's >> a >> >list of the periodic(8) daily scripts that run at 03:00am time. >> > >> >% ls -1 /etc/periodic/daily >> >800.scrub-zfs >> > >> >% ls -1 /usr/local/etc/periodic/daily >> >402.zfSnap >> >403.zfSnap_delete >> >> On a couple of my zfs machines, I've found running a scrub along with >> other >> high file system users to be a problem. I therefore run scrub from cron >> and >> schedule it so it doesn't overlap with periodic. >> >> I also found on a machine with an i3 and 4G ram that overlapping scrubs >> and >> snapshot destroy would cause the machine to grind to the point of being >> non-responsive. This was not a problem when the machine was new, but >> became one >> as the pool got larger (dedup is off and the pool is at 45% capacity). >> >> I use my own zfs management script and it prevents snapshot destroys from >> overlapping scrubs, and with a lockfile it prevents a new destroy from >> being >> initiated when an old one is still running. >> >> zfSnap has its -S switch to prevent actions during a scrub which you >> should >> use if you haven't already. >> >> > Hi John, > > Thanks for the hints. It was a long time since I've setup zfSnap and I've > just checked the configuration and I am using the "-s -S" flags, so there > should be no overlapping. > > Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying > to reboot the system (which appears to be discussed a lot in a separate > thread). > > Then I've updated to stable/9, so at the least the reboot issue is now > solved. Since I've to stable/9 I'm monitoring the system's memory usage and > so far it's been pretty stable, so I'll keep an eye of an update to > stable/9 has actually fixed this strange issue. > > Thanks again, > Marin > > >> Since making these changes, a machine that would have to be rebooted >> several >> times a week has now been up 61 days. >> >> John Theus >> TheUs Group >> > > > > -- > Marin Atanasov Nikolov > > dnaeon AT gmail DOT com > http://www.unix-heaven.org/ > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 09:47:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 276D6317 for ; Fri, 25 Jan 2013 09:47:30 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id A163CA7B for ; Fri, 25 Jan 2013 09:47:29 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 10:37:21 +0100 Message-ID: <5102524D.4010002@ose.nl> Date: Fri, 25 Jan 2013 10:37:17 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:47:30 -0000 On 01/25/2013 10:29 AM, Marin Atanasov Nikolov wrote: > Hello again :) > > Here's my update on these spontaneous reboots after less than a week since > I've updated to stable/9. > > First two days the system was running fine with no reboots happening, so I > though that this update actually fixed it, but I was wrong. Not really a solution but you can take a look at sysutils/zfs-stats > > The reboots are still happening and still no clear evidence of the root > cause. What I did so far: > > * Ran disks tests -- looking good > * Ran memtest -- looking good > * Replaced power cables > * Ran UPS tests -- looking good > * Checked for any bad capacitors -- none found > * Removed all ZFS snapshots > > There is also one more machine connected to the same UPS, so if it was a > UPS issue I'd expect that the other one reboots too, but that's not the > case. > > Now that I've excluded the hardware part of this problem I started looking > again into the software side, and this time in particular -- ZFS. > > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of memory. > > A quick look at top(1) showed lots of memory usage by ARC and my available > free memory dropping fast. I've made a screenshot, which you can see on the > link below: > > * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg > > So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide [1], > but honestly at the end I was not sure which parameters I need to > increase/decrease and to what values. > > Here's some info about my current parameters. > > % sysctl vm.kmem_size_max > vm.kmem_size_max: 329853485875 > > % sysctl vm.kmem_size > vm.kmem_size: 8279539712 > > % sysctl vfs.zfs.arc_max > vfs.zfs.arc_max: 7205797888 > > % sysctl kern.maxvnodes > kern.maxvnodes: 206227 > > There's one script at the ZFSTuningGuide which calculates kernel memory > utilization, and for me these values are listed below: > > TEXT=22402749, 21.3649 MB > DATA=4896264192, 4669.44 MB > TOTAL=4918666941, 4690.81 MB > > While looking for ZFS tuning I've also stumbled upon this thread in the > FreeBSD Forums [2], where the OP describes a similar behaviour to what I am > already experiencing, so I'm quite worried now that the reason for these > crashes is ZFS. > > Before jumping into any change to the kernel parameters (vm.kmem_size, > vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any > feedback from people that have already done such optimizations on their ZFS > systems. > > Could you please share what are the optimal values for these parameters on > a system with 8Gb of memory? Is there a way to calculate these values or is > it just a "test-and-see-which-fits-better" way of doing this? > > Thanks and regards, > Marin > > [1]: https://wiki.freebsd.org/ZFSTuningGuide > [2]: http://forums.freebsd.org/showthread.php?t=9143 > > > On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov wrote: > >> >> >> On Sat, Jan 19, 2013 at 10:19 PM, John wrote: >> >>>> At 03:00am I can see that periodic(8) runs, but I don't see what could >>> have >>>> taken so much of the free memory. I'm also running this system on ZFS and >>>> have daily rotating ZFS snapshots created - currently the number of ZFS >>>> snapshots are > 1000, and not sure if that could be causing this. Here's >>> a >>>> list of the periodic(8) daily scripts that run at 03:00am time. >>>> >>>> % ls -1 /etc/periodic/daily >>>> 800.scrub-zfs >>>> >>>> % ls -1 /usr/local/etc/periodic/daily >>>> 402.zfSnap >>>> 403.zfSnap_delete >>> On a couple of my zfs machines, I've found running a scrub along with >>> other >>> high file system users to be a problem. I therefore run scrub from cron >>> and >>> schedule it so it doesn't overlap with periodic. >>> >>> I also found on a machine with an i3 and 4G ram that overlapping scrubs >>> and >>> snapshot destroy would cause the machine to grind to the point of being >>> non-responsive. This was not a problem when the machine was new, but >>> became one >>> as the pool got larger (dedup is off and the pool is at 45% capacity). >>> >>> I use my own zfs management script and it prevents snapshot destroys from >>> overlapping scrubs, and with a lockfile it prevents a new destroy from >>> being >>> initiated when an old one is still running. >>> >>> zfSnap has its -S switch to prevent actions during a scrub which you >>> should >>> use if you haven't already. >>> >>> >> Hi John, >> >> Thanks for the hints. It was a long time since I've setup zfSnap and I've >> just checked the configuration and I am using the "-s -S" flags, so there >> should be no overlapping. >> >> Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying >> to reboot the system (which appears to be discussed a lot in a separate >> thread). >> >> Then I've updated to stable/9, so at the least the reboot issue is now >> solved. Since I've to stable/9 I'm monitoring the system's memory usage and >> so far it's been pretty stable, so I'll keep an eye of an update to >> stable/9 has actually fixed this strange issue. >> >> Thanks again, >> Marin >> >> >>> Since making these changes, a machine that would have to be rebooted >>> several >>> times a week has now been up 61 days. >>> >>> John Theus >>> TheUs Group >>> >> >> >> -- >> Marin Atanasov Nikolov >> >> dnaeon AT gmail DOT com >> http://www.unix-heaven.org/ >> > > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 10:25:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73FDB936 for ; Fri, 25 Jan 2013 10:25:53 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 26CB0CB8 for ; Fri, 25 Jan 2013 10:25:52 +0000 (UTC) Received: from [194.32.164.26] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id r0PACPta091054; Fri, 25 Jan 2013 10:12:25 GMT (envelope-from rb@gid.co.uk) Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: Date: Fri, 25 Jan 2013 10:12:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> To: Marin Atanasov Nikolov X-Mailer: Apple Mail (2.1283) Cc: ml-freebsd-stable , John X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:25:53 -0000 Hi, On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote: > Hello again :) >=20 > Here's my update on these spontaneous reboots after less than a week = since > I've updated to stable/9. >=20 > First two days the system was running fine with no reboots happening, = so I > though that this update actually fixed it, but I was wrong. >=20 > The reboots are still happening and still no clear evidence of the = root > cause. What I did so far: >=20 > * Ran disks tests -- looking good > * Ran memtest -- looking good > * Replaced power cables > * Ran UPS tests -- looking good > * Checked for any bad capacitors -- none found > * Removed all ZFS snapshots >=20 > There is also one more machine connected to the same UPS, so if it was = a > UPS issue I'd expect that the other one reboots too, but that's not = the > case. >=20 > Now that I've excluded the hardware part of this problem Have you done anything to rule out the machine's power supply? > I started looking > again into the software side, and this time in particular -- ZFS. >=20 > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of = memory. >=20 > A quick look at top(1) showed lots of memory usage by ARC and my = available > free memory dropping fast. I've made a screenshot, which you can see = on the > link below: >=20 > * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg >=20 > So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide = [1], > but honestly at the end I was not sure which parameters I need to > increase/decrease and to what values. >=20 > Here's some info about my current parameters. >=20 > % sysctl vm.kmem_size_max > vm.kmem_size_max: 329853485875 >=20 > % sysctl vm.kmem_size > vm.kmem_size: 8279539712 >=20 > % sysctl vfs.zfs.arc_max > vfs.zfs.arc_max: 7205797888 >=20 > % sysctl kern.maxvnodes > kern.maxvnodes: 206227 >=20 > There's one script at the ZFSTuningGuide which calculates kernel = memory > utilization, and for me these values are listed below: >=20 > TEXT=3D22402749, 21.3649 MB > DATA=3D4896264192, 4669.44 MB > TOTAL=3D4918666941, 4690.81 MB >=20 > While looking for ZFS tuning I've also stumbled upon this thread in = the > FreeBSD Forums [2], where the OP describes a similar behaviour to what = I am > already experiencing, so I'm quite worried now that the reason for = these > crashes is ZFS. >=20 > Before jumping into any change to the kernel parameters (vm.kmem_size, > vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear = any > feedback from people that have already done such optimizations on = their ZFS > systems. >=20 > Could you please share what are the optimal values for these = parameters on > a system with 8Gb of memory? Is there a way to calculate these values = or is > it just a "test-and-see-which-fits-better" way of doing this? >=20 > Thanks and regards, > Marin >=20 > [1]: https://wiki.freebsd.org/ZFSTuningGuide > [2]: http://forums.freebsd.org/showthread.php?t=3D9143 >=20 >=20 > On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov = wrote: >=20 >>=20 >>=20 >>=20 >> On Sat, Jan 19, 2013 at 10:19 PM, John wrote: >>=20 >>>> At 03:00am I can see that periodic(8) runs, but I don't see what = could >>> have >>>> taken so much of the free memory. I'm also running this system on = ZFS and >>>> have daily rotating ZFS snapshots created - currently the number of = ZFS >>>> snapshots are > 1000, and not sure if that could be causing this. = Here's >>> a >>>> list of the periodic(8) daily scripts that run at 03:00am time. >>>>=20 >>>> % ls -1 /etc/periodic/daily >>>> 800.scrub-zfs >>>>=20 >>>> % ls -1 /usr/local/etc/periodic/daily >>>> 402.zfSnap >>>> 403.zfSnap_delete >>>=20 >>> On a couple of my zfs machines, I've found running a scrub along = with >>> other >>> high file system users to be a problem. I therefore run scrub from = cron >>> and >>> schedule it so it doesn't overlap with periodic. >>>=20 >>> I also found on a machine with an i3 and 4G ram that overlapping = scrubs >>> and >>> snapshot destroy would cause the machine to grind to the point of = being >>> non-responsive. This was not a problem when the machine was new, but >>> became one >>> as the pool got larger (dedup is off and the pool is at 45% = capacity). >>>=20 >>> I use my own zfs management script and it prevents snapshot destroys = from >>> overlapping scrubs, and with a lockfile it prevents a new destroy = from >>> being >>> initiated when an old one is still running. >>>=20 >>> zfSnap has its -S switch to prevent actions during a scrub which you >>> should >>> use if you haven't already. >>>=20 >>>=20 >> Hi John, >>=20 >> Thanks for the hints. It was a long time since I've setup zfSnap and = I've >> just checked the configuration and I am using the "-s -S" flags, so = there >> should be no overlapping. >>=20 >> Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when = trying >> to reboot the system (which appears to be discussed a lot in a = separate >> thread). >>=20 >> Then I've updated to stable/9, so at the least the reboot issue is = now >> solved. Since I've to stable/9 I'm monitoring the system's memory = usage and >> so far it's been pretty stable, so I'll keep an eye of an update to >> stable/9 has actually fixed this strange issue. >>=20 >> Thanks again, >> Marin >>=20 >>=20 >>> Since making these changes, a machine that would have to be rebooted >>> several >>> times a week has now been up 61 days. >>>=20 >>> John Theus >>> TheUs Group >>>=20 >>=20 >>=20 >>=20 >> -- >> Marin Atanasov Nikolov >>=20 >> dnaeon AT gmail DOT com >> http://www.unix-heaven.org/ >>=20 >=20 >=20 >=20 > --=20 > Marin Atanasov Nikolov >=20 > dnaeon AT gmail DOT com > http://www.unix-heaven.org/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 10:26:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BA9DA3A for ; Fri, 25 Jan 2013 10:26:49 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1177ECD0 for ; Fri, 25 Jan 2013 10:26:48 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id i18so125751bkv.4 for ; Fri, 25 Jan 2013 02:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dE826DLw8zhVClKuwkm/9IwVWyIzO5gAMXa7y+TtcpA=; b=W7kf6w99E2QXwdc/HXPg1DBmzaMQBppjyBfVa5dDdSI8BT5s6bqtVJRdCNPloK5ThF rNDhiX9apZZRgUB3A6+7xMTvJKz8k9O4EZkVxkJSe31/rDl1dmIoVgUt0pHhIJBp+gUj RZcnmBXO1jcLa/NK0LkpMiRpTj+zPaYoqSF98pKGHXfiDARVOoXxnzIlZghbmconrbtb MbzoFUaupfxeSbnLehPgSOdKqkY7NF0Q4YDvB4ysmXTPfqbGdvjKUchRlZ67/CRRrUSI juUmi6qY87srw7xvHjXwWSLhG73+k50I++wp70mgifxcuge61KJPZLEGZwp5gYCXJ9QU ic7Q== MIME-Version: 1.0 X-Received: by 10.204.4.81 with SMTP id 17mr1661687bkq.137.1359109607925; Fri, 25 Jan 2013 02:26:47 -0800 (PST) Received: by 10.205.112.11 with HTTP; Fri, 25 Jan 2013 02:26:47 -0800 (PST) In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> Date: Fri, 25 Jan 2013 12:26:47 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Bob Bishop Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-freebsd-stable , John X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:26:49 -0000 On Fri, Jan 25, 2013 at 12:12 PM, Bob Bishop wrote: > Hi, > > On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote: > > > Hello again :) > > > > Here's my update on these spontaneous reboots after less than a week > since > > I've updated to stable/9. > > > > First two days the system was running fine with no reboots happening, so > I > > though that this update actually fixed it, but I was wrong. > > > > The reboots are still happening and still no clear evidence of the root > > cause. What I did so far: > > > > * Ran disks tests -- looking good > > * Ran memtest -- looking good > > * Replaced power cables > > * Ran UPS tests -- looking good > > * Checked for any bad capacitors -- none found > > * Removed all ZFS snapshots > > > > There is also one more machine connected to the same UPS, so if it was a > > UPS issue I'd expect that the other one reboots too, but that's not the > > case. > > > > Now that I've excluded the hardware part of this problem > > Have you done anything to rule out the machine's power supply? > > Hi, Yes, it's a brand new one. Regards, Marin > > I started looking > > again into the software side, and this time in particular -- ZFS. > > > > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of > memory. > > > > A quick look at top(1) showed lots of memory usage by ARC and my > available > > free memory dropping fast. I've made a screenshot, which you can see on > the > > link below: > > > > * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg > > > > So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide > [1], > > but honestly at the end I was not sure which parameters I need to > > increase/decrease and to what values. > > > > Here's some info about my current parameters. > > > > % sysctl vm.kmem_size_max > > vm.kmem_size_max: 329853485875 > > > > % sysctl vm.kmem_size > > vm.kmem_size: 8279539712 > > > > % sysctl vfs.zfs.arc_max > > vfs.zfs.arc_max: 7205797888 > > > > % sysctl kern.maxvnodes > > kern.maxvnodes: 206227 > > > > There's one script at the ZFSTuningGuide which calculates kernel memory > > utilization, and for me these values are listed below: > > > > TEXT=22402749, 21.3649 MB > > DATA=4896264192, 4669.44 MB > > TOTAL=4918666941, 4690.81 MB > > > > While looking for ZFS tuning I've also stumbled upon this thread in the > > FreeBSD Forums [2], where the OP describes a similar behaviour to what I > am > > already experiencing, so I'm quite worried now that the reason for these > > crashes is ZFS. > > > > Before jumping into any change to the kernel parameters (vm.kmem_size, > > vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any > > feedback from people that have already done such optimizations on their > ZFS > > systems. > > > > Could you please share what are the optimal values for these parameters > on > > a system with 8Gb of memory? Is there a way to calculate these values or > is > > it just a "test-and-see-which-fits-better" way of doing this? > > > > Thanks and regards, > > Marin > > > > [1]: https://wiki.freebsd.org/ZFSTuningGuide > > [2]: http://forums.freebsd.org/showthread.php?t=9143 > > > > > > On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov < > dnaeon@gmail.com>wrote: > > > >> > >> > >> > >> On Sat, Jan 19, 2013 at 10:19 PM, John wrote: > >> > >>>> At 03:00am I can see that periodic(8) runs, but I don't see what could > >>> have > >>>> taken so much of the free memory. I'm also running this system on ZFS > and > >>>> have daily rotating ZFS snapshots created - currently the number of > ZFS > >>>> snapshots are > 1000, and not sure if that could be causing this. > Here's > >>> a > >>>> list of the periodic(8) daily scripts that run at 03:00am time. > >>>> > >>>> % ls -1 /etc/periodic/daily > >>>> 800.scrub-zfs > >>>> > >>>> % ls -1 /usr/local/etc/periodic/daily > >>>> 402.zfSnap > >>>> 403.zfSnap_delete > >>> > >>> On a couple of my zfs machines, I've found running a scrub along with > >>> other > >>> high file system users to be a problem. I therefore run scrub from > cron > >>> and > >>> schedule it so it doesn't overlap with periodic. > >>> > >>> I also found on a machine with an i3 and 4G ram that overlapping scrubs > >>> and > >>> snapshot destroy would cause the machine to grind to the point of being > >>> non-responsive. This was not a problem when the machine was new, but > >>> became one > >>> as the pool got larger (dedup is off and the pool is at 45% capacity). > >>> > >>> I use my own zfs management script and it prevents snapshot destroys > from > >>> overlapping scrubs, and with a lockfile it prevents a new destroy from > >>> being > >>> initiated when an old one is still running. > >>> > >>> zfSnap has its -S switch to prevent actions during a scrub which you > >>> should > >>> use if you haven't already. > >>> > >>> > >> Hi John, > >> > >> Thanks for the hints. It was a long time since I've setup zfSnap and > I've > >> just checked the configuration and I am using the "-s -S" flags, so > there > >> should be no overlapping. > >> > >> Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when > trying > >> to reboot the system (which appears to be discussed a lot in a separate > >> thread). > >> > >> Then I've updated to stable/9, so at the least the reboot issue is now > >> solved. Since I've to stable/9 I'm monitoring the system's memory usage > and > >> so far it's been pretty stable, so I'll keep an eye of an update to > >> stable/9 has actually fixed this strange issue. > >> > >> Thanks again, > >> Marin > >> > >> > >>> Since making these changes, a machine that would have to be rebooted > >>> several > >>> times a week has now been up 61 days. > >>> > >>> John Theus > >>> TheUs Group > >>> > >> > >> > >> > >> -- > >> Marin Atanasov Nikolov > >> > >> dnaeon AT gmail DOT com > >> http://www.unix-heaven.org/ > >> > > > > > > > > -- > > Marin Atanasov Nikolov > > > > dnaeon AT gmail DOT com > > http://www.unix-heaven.org/ > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > > > > -- > Bob Bishop +44 (0)118 940 1243 > rb@gid.co.uk fax +44 (0)118 940 1295 > mobile +44 (0)783 626 4518 > > > > > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 10:43:43 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AC33D0 for ; Fri, 25 Jan 2013 10:43:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CBDEAF2A for ; Fri, 25 Jan 2013 10:43:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA00646; Fri, 25 Jan 2013 12:43:16 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tygkd-000FJv-Ng; Fri, 25 Jan 2013 12:43:15 +0200 Message-ID: <510261C3.7060305@FreeBSD.org> Date: Fri, 25 Jan 2013 12:43:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Marin Atanasov Nikolov Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ml-freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:43:43 -0000 on 25/01/2013 12:26 Marin Atanasov Nikolov said the following: > Yes, it's a brand new one. Then no: http://en.wikipedia.org/wiki/Bathtub_curve -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 10:45:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A5E644E for ; Fri, 25 Jan 2013 10:45:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EBD58FB9 for ; Fri, 25 Jan 2013 10:45:31 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Tygmo-0009Vr-7W for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 12:45:30 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: bge bad performance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2013 12:45:30 +0200 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:45:32 -0000 Hi, It seems that I have more issues with the bge, Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 ifconfig says: bge2: flags=8843 metric 0 mtu 1500 options=c019b ether xx... inet6 xxx prefixlen 64 scopeid 0x3 inet xxx... netmask 0xfffff000 broadcast yyy nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active iperf reports [ 3] 0.0-10.0 sec 230 MBytes 193 Mbits/sec From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 12:32:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94468C39 for ; Fri, 25 Jan 2013 12:32:01 +0000 (UTC) (envelope-from ardovm@yahoo.it) Received: from nm19-vm0.bullet.mail.ird.yahoo.com (nm19-vm0.bullet.mail.ird.yahoo.com [77.238.189.92]) by mx1.freebsd.org (Postfix) with SMTP id E3723793 for ; Fri, 25 Jan 2013 12:32:00 +0000 (UTC) Received: from [77.238.189.232] by nm19.bullet.mail.ird.yahoo.com with NNFMP; 25 Jan 2013 12:31:54 -0000 Received: from [217.146.188.168] by tm13.bullet.mail.ird.yahoo.com with NNFMP; 25 Jan 2013 12:31:54 -0000 Received: from [127.0.0.1] by smtp136.mail.ird.yahoo.com with NNFMP; 25 Jan 2013 12:31:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.it; s=s1024; t=1359117114; bh=yRygZy/Jd/F+ltMf396T/+ag98YWnWp7Gy9AAI0Qm54=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=1W820LN5TMopNaJXd46YDWO49DH5ByJDNCZtJEdjuiX6ltK/b1ANYv5wySrcYymNaBzRupJ2PEzFOiKuyazNYhxQjwThZ5mLZ1WtJEl7F8fXeNcowxgE0NbtZjsL8baZk7IWXZ5rCU8kk3e3+2sMh1BEPgykdPmAUChjZBSijHc= X-Yahoo-Newman-Id: 370038.62296.bm@smtp136.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _tZOk.sVM1mry.ux8QbUHKaUrR.ABJamgKcDOUdQrwv_sKL NL7X4vepbq4RO3wgSF8Z_03pB9c2w6wEVSMwf7YoQdor8Tu9XLZ0DP3kFR6j Cq8JUz4sTWfUGoXpLtU7OPSnp7FAVWR8n62U2N8Ayy5W2VDoZl3pG9woy9uK KzNOO880Dax234B8rN5B1P4hyBDhaYPSZxtNe4pvXLJ7b3Y9GkkIMSifKy2u ZKLcGen2wBukSTbo9wycspMmx1OkoskcCQoQcD06vH4YEcpZQKSsimrDLZnM BDT89D4Cd9kxaBh64AYEFM6TcO_20zyGqIMhSnTOL50kpP7pXyfSHwIa_mAG XgnTXfQZWKXgw613YV6TEN2__XQixhaj3seRBhyaonaD2jQYigdDpyJ.dQsL WWSr3PoG69Jr6stIh2ya_jGu1c0wSQZtnCuZEVgwaF5g2PY4mYESmK35UzX9 N8._u.nxeVeXy6IpbSkQIJacIqeeJPQrUlvK6bG93u5Er_84Xg5GeDdmtoA- - X-Yahoo-SMTP: WU.IBxeswBAAnLcBZV3tEZIK0A-- Received: from snail (ardovm@93.145.95.7 with login) by smtp136.mail.ird.yahoo.com with SMTP; 25 Jan 2013 04:31:54 -0800 PST Received: by snail (Postfix, from userid 1000) id 13DA23C9DB4; Fri, 25 Jan 2013 13:42:19 +0100 (CET) Date: Fri, 25 Jan 2013 13:42:19 +0100 From: Arrigo Marchiori To: 'Jeremy Chadwick' Subject: Svnsup architecture [was: Re: svn - but smaller?] Message-ID: <20130125124219.GA5299@snail.casa> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130124085717.GA26673@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:32:01 -0000 On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy Chadwick' wrote: [...] > Also, just as a footnote point to readers: please do not bring up > svnsup. Until it's stated by some official FreeBSD person that > "{committers} are actively working on this and bringing it into the base > system so people can get src/ports without installing > ports/devel/subversion", it's not pragmatic to mention it as a > *solution*. I take the chance of this thread to tell my understanding of the svnsup project and how and why it should answer our concerns. I am not a "FreeBSD official person", but I hope I still can bring a bit of useful information. Disclaimer: I only had a small e-mail exchange with des, who is the author of svnsup. 90% of this message are my opinions; the other 10% is copy'n paste from des' emails. I am currently trying to contribute to the software; my opinions are made after studying parts of the current source code. The current svnsup design is composed of: 1- svnsup-distill: takes a revision from svn and creates a text file (called a delta) that represents it. It seems to be almost complete. 2- svnsup-apply: takes a delta generated by svnsup-distill and applies it to an existing source tree. It's currently a work in progress. 3- a server-side application that runs svnsup-distill and distributes the deltas (still to be developed). 4- a client-side application that fetches new deltas and runs svnsup-apply. New trees are "bootstrapped" from other sources, e.g. weekly tarballs (still to be developed). The FreeBSD base system could only contain applications 2 and 4. Neither of them depends on any SVN-related library: deltas are simple text files. Efficiency, if I understood correctly, was one of the key features of cvsup. This is why svnsup only transfers "deltas". To answer one of John Mehr's problems: MD5 sums are calculated by svnsup-distill and included in the deltas. The client only needs to check them against the local files. I think that svnsup still needs a lot of work before becoming usable. But some of the fundamental parts are there, and the projects can count on at least two developers. :-) -- rigo http://rigo.altervista.org From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 13:12:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B331B412 for ; Fri, 25 Jan 2013 13:12:17 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1B56B934 for ; Fri, 25 Jan 2013 13:12:16 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r0PDC3uo085858 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 15:12:05 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <510284A3.8030509@digsys.bg> Date: Fri, 25 Jan 2013 15:12:03 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> <1358960762-2331017.37282719.fr0NH5PFb026896@rs149.luxsci.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:12:17 -0000 On 23.01.13 21:09, Peter Wemm wrote: > On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy > wrote: > >> 1) License. Many of SVN's dependencies will never be available in the FreeBSD source. >> While this is totally OK for development, SVN is 3rd party software, this is unacceptable to force as 'the' respected path for OS source builds. > Don't confuse the excessive ports default settings as dependencies. > You can make a quite mean and lean svn client. I did a 100% > BSD-license-compatible src/contrib/svn style proof-of-concept back > when we were planning what to do. Things like gdbm and bdb are not > required and are license contamination that we don't need. But that's > the fault of the port, not a fundamental property of using svn. > The logical question is then: Why is this slimmed down, fully BSD license compatible svn not in the base system by now? It is absurd to require the installation of any port, if your only intention is to update the base system sources. Portsnap is an entirely different mess. Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 13:38:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2BB9C911 for ; Fri, 25 Jan 2013 13:38:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7CDA97 for ; Fri, 25 Jan 2013 13:38:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r0PDcmdj091752; Sat, 26 Jan 2013 00:38:48 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 26 Jan 2013 00:38:48 +1100 (EST) From: Ian Smith To: "'Jeremy Chadwick'" Subject: Re: svn - but smaller? In-Reply-To: <20130124085717.GA26673@icarus.home.lan> Message-ID: <20130125235425.T76686@sola.nimnet.asn.au> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Bjoern A. Zeeb" , freebsd-stable@freebsd.org, Peter Wemm , Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:38:58 -0000 On Thu, 24 Jan 2013 00:57:17 -0800, 'Jeremy Chadwick' wrote: > On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote: > > The objective is to return to a base build of FreeBSD that performs > > the expected task of being able to pull source, without having to > > acquire a port. Regardless of our individual solutions/workarounds, > > the task is to pull and maintain source. > > > > Is the discussion going to result in something like svn-lite that > > enters into the /usr/src/contrib along with the responsibilities > > associated with maintaining it? And then we need to take into > > consideration of being overwriting the "base svn" with a full svn > > package, if required by the user/admin. [..] > > I build svn from ports with all options off except for: > > ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn > > program. Suites me but doesn't address the underlying problem - and I > > don't think that the plan is to make FreeBSD dependent upon the ports > > system (for subversion) [..] > As for your last line: > > FreeBSD is already dependent upon Subversion. This has been the case > for quite some time, but has only recently (as an indirect result of the > security incident) become forced upon users/administrators of FreeBSD. > The entire project is presently managed/maintained under Subversion. > The Handbook now documents that if you want to pull down src/ you need > to install Subversion. If you want to pull down ports/ you can use > portsnap and waste lots of /var space, hoping that the portsnap mirrors > are up to date, and a bunch of other hullabaloo... or you could just use > Subversion and be done with it. > > There is no more cvsup. There is no more csup. There is no more cvs. I'm trying to work out exactly when support for checking out 9-STABLE CVS sources - and I'm only talking about system sources here - will end? Peter Wemm (cc'd) writes in https://wiki.freebsd.org/CvsIsDeprecated, last edited 2013-01-22: "3. For FreeBSD 9-stable, 8-stable and 7-stable, we will be attempting to continue updates through the exporter the official "support" end-of-life for last release on the branch at the time of writing (November 16th, 2012). * This means, updates will be maintained on a best effort basis until 9.0-RELEASE, 8.3-RELEASE, 7.4-RELEASE are no longer supported. * This notice pre-dates 9.1-RELEASE, and the release of 9.1 will not extend the lifetime of RELENG_9 branch exporter. * This is not a commitment to operate the services, it will only be done on a best effort basis. If serious problems develop or usage dies down significantly we may accelerate its end-of-life." But after kerfuffle about 9.1-RELEASE branch sources not (then) being available via c{v,}sup, Bjoern Zeeb wrote on Sept 18th 2012 in http://lists.freebsd.org/pipermail/freebsd-stable/2012-September/069600.html "RELENG_9_1 is now exported the CVS as well and will be for as long as things will be exported to CVS." Other posts around that time clearly said that CVS source access would remain for the lifetime of 9-STABLE. Could someone please clarify this situation? As others have suggested, an SVN package that could be installed with a static build and run dependency-free binary would help ease the pain for those looking specifically at updating 9.x or 8.x sources to -STABLE as a directly usable csup replacement, preferably on install media but at least easily fetchable as a package? I find portsnap fine for ports. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:04:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BCCA764 for ; Fri, 25 Jan 2013 15:04:09 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id C9F34155 for ; Fri, 25 Jan 2013 15:04:08 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so292182wgh.19 for ; Fri, 25 Jan 2013 07:04:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=Zo79s+GQ5T94ivCZMYHghI7GJfP6u9ZtcoECtG/XQAs=; b=jLPQBPUebr1WxV6XhPFElTuUhnEBPeAfGGK3RflDv77XTq/3RnAwlUmSEctr7jsDFb VHyQ6zEELkduAcTFygssd+l+HOkQJI5OUM4FAz3Kzg8jIW09lgHxxtGGOeGv16QFTUuS Pqhec5GI1QJkRn7fOMEBPqF5sUJz1ZA2JYfwcYGfoc8EwwIat09Kn649AHjnWPINS1oL bRPRaKIBApqpdQt17h+4InLdY88Cz7gRq2BQ5XU0pG28J2mjb+k7sASCM2FJ0F8B4Rf4 uaBqCr1+uMr6AlbUCN97txbJzC5IJ10L883uCx/MJPgBpYl+w6M38wuse/jjFrCoy2cf jbCA== X-Received: by 10.180.82.41 with SMTP id f9mr9199201wiy.25.1359126241111; Fri, 25 Jan 2013 07:04:01 -0800 (PST) Received: from [10.99.169.153] ([92.90.16.33]) by mx.google.com with ESMTPS id do1sm187756wib.7.2013.01.25.07.03.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 07:03:59 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <727F9491-A88F-4A4E-BD4F-61235F31500E@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Subject: Re: bge bad performance Date: Fri, 25 Jan 2013 16:02:53 +0100 To: Daniel Braniss X-Gm-Message-State: ALoCoQnZBLEf42zH3J8m9UNlGal+YZY0xo3i+ieNjUXTrADV0ecDRiHAg+fSV4JE2xJ7C7RSaNbp Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:04:09 -0000 On 25 Jan 2013, at 11:45, Daniel Braniss wrote: > Hi, > It seems that I have more issues with the bge, > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 >=20 > ifconfig says: > bge2: flags=3D8843 metric 0 mtu 15= 00 > options=3Dc019b O,LINKSTATE> > ether xx... > inet6 xxx prefixlen 64 scopeid 0x3=20 > inet xxx... netmask 0xfffff000 broadcast yyy > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > iperf reports > [ 3] 0.0-10.0 sec 230 MBytes 193 Mbits/sec >=20 Post your iperf command line and explain the test environment, as in direct c= onnection vs switched network link ? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:12:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2252F9B2 for ; Fri, 25 Jan 2013 15:12:24 +0000 (UTC) (envelope-from prvs=07378d258e=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id D513B201 for ; Fri, 25 Jan 2013 15:12:23 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tykx5-000E30-4I for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 16:12:23 +0100 Date: Fri, 25 Jan 2013 16:12:23 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130125151222.GE79995@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130125092723.GC79995@e-Gitt.NET> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:12:24 -0000 On Fri, Jan 25, 2013 at 10:27:23AM +0100, Oliver Brandmueller wrote: ... an Ian Smith and des for working on a svnsup solution, which also might in the future be something that solves the problem! - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:35:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8593636E for ; Fri, 25 Jan 2013 15:35:50 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBF7370 for ; Fri, 25 Jan 2013 15:35:49 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id 12so1145897wgh.1 for ; Fri, 25 Jan 2013 07:35:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=uvMXbPfTlb1t+3fce3NzHiFGLw/XRVyTMimkeRkoSqk=; b=CP510uUJNTDolSCHRSGwL6tUDIEm3pVBLgz2nr/RPlq5TLBKt8yd1kv1+k/WcL3g7Y bDCqwr4fqUgkez1yALeJlVCqSTxdQI0NDtUW3LtDLx/7BqwocDGmiT7q5uOEqzxsebW/ gqVz9L28jC4aWogTQsol7jrodoMi4DYSOwzefVhflk6LlmeeCvnHQLwrkFBz9Y1bMoug yQ4uRAEgkSd66C+Xcr9x6d4vCu3v0HtJ4p0gOc67dRRppBKNzqGHgqrIdDxmw1Nd02lx rX6dVWaYjobYx/CXmeWdLlHopVamwGsPjVg0307XhxdXXiubpqnmPdVFqO5ou3AmpKrp zMlw== X-Received: by 10.194.89.167 with SMTP id bp7mr9678675wjb.0.1359128149338; Fri, 25 Jan 2013 07:35:49 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id eo10sm2314270wib.9.2013.01.25.07.35.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 07:35:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: svn - but smaller? From: Fleuriot Damien In-Reply-To: <20130125235425.T76686@sola.nimnet.asn.au> Date: Fri, 25 Jan 2013 16:35:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkvkOGpANko4r4gZvMacSIJQeRWvwEnTkXLg+LVzRRFncrkfNtKJID5jZOPCNTcTNlGkvmF Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:35:50 -0000 On Jan 25, 2013, at 2:38 PM, Ian Smith wrote: >=20 > As others have suggested, an SVN package that could be installed with = a=20 > static build and run dependency-free binary would help ease the pain = for=20 > those looking specifically at updating 9.x or 8.x sources to -STABLE = as=20 > a directly usable csup replacement, preferably on install media but at=20= > least easily fetchable as a package? I find portsnap fine for ports. >=20 > cheers, Ian Actually, for anyone running 8.x amd64 and too lazy to build SVN (or who = can't be bothered with its dependencies), you can get my static build = here: http://my.gd/svn Checksum should match this, after download: MD5 (/usr/local/bin/svn) =3D 204df5cd31b94c49611890893c7c2aba % uname -a FreeBSD pf1.backbone.dev 8.3-STABLE FreeBSD 8.3-STABLE #0 r245223: Wed = Jan 9 14:03:15 UTC 2013 = root@pf1.backbone.dev:/usr/obj/usr/src/sys/UNIVERSAL amd64 % ldd /usr/local/bin/svn ldd: /usr/local/bin/svn: not a dynamic ELF executable % ls -l /usr/local/bin/svn -rwxr-xr-x 1 root wheel 4205656 Jan 22 16:51 /usr/local/bin/svn % cd /usr/ports/devel/subversion % make showconfig =3D=3D=3D> The following configuration options are available for = subversion-1.7.8: BDB=3Doff: Berkeley Database BOOK=3Doff: Install the Subversion Book ENHANCED_KEYWORD=3Doff: Enhanced svn:keyword support FREEBSD_TEMPLATE=3Doff: FreeBSD Project log template GNOME_KEYRING=3Doff: Build with GNOME Keyring auth support KDE_KWALLET=3Doff: Build with KDE KWallet auth support MAINTAINER_DEBUG=3Doff: Build debug version MOD_DAV_SVN=3Doff: mod_dav_svn module for Apache 2.X MOD_DONTDOTHAT=3Doff: mod_dontdothat for Apache 2.X NEON=3Doff: WebDAV/Delta-V repo access module (neon) P4_STYLE_MARKERS=3Doff: Perforce-style conflict markers SASL=3Doff: SASL support SERF=3Doff: WebDAV/Delta-V repo access module (serf) STATIC=3Don: Build static version (no shared libs) SVNAUTHZ_VALIDATE=3Doff: install svnauthz-validate SVNMUCC=3Doff: Install Multiple URL Command Client SVNSERVE_WRAPPER=3Doff: Enable svnserve wrapper TEST=3Doff: Run subversion test suite From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:37:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16CD0679 for ; Fri, 25 Jan 2013 15:37:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C77453CF for ; Fri, 25 Jan 2013 15:37:44 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AC02BB993; Fri, 25 Jan 2013 10:37:43 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: bge numbering Date: Fri, 25 Jan 2013 10:00:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301251000.52922.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 25 Jan 2013 10:37:43 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:37:45 -0000 On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote: > Hi, > this server, a Dell R720 has 4 bge on board, > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 > bge0: APE FW version: NCSI v1.1.7.0 > bge0: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E > miibus0: on bge0 > ... > > I have connected the ethernet to port labeled 0, but it appears > as bge2, how can this be corrected? It can't really. The order of PCI devices is determined by the layout of the PCI device hierarchy which is generally determined by the physical traces on your motherboard. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:38:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1ACB907 for ; Fri, 25 Jan 2013 15:38:46 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 4B518632 for ; Fri, 25 Jan 2013 15:38:46 +0000 (UTC) Received: from rufus.webfusion.com (mail.heartinternet.co.uk [79.170.40.31]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.6) with ESMTP id r0PFcY0r070337 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 15:38:42 GMT (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.7.4 smtp.infracaninophile.co.uk r0PFcY0r070337 Authentication-Results: smtp.infracaninophile.co.uk/r0PFcY0r070337; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host mail.heartinternet.co.uk [79.170.40.31] claimed to be rufus.webfusion.com Message-ID: <5102A6F9.9070303@freebsd.org> Date: Fri, 25 Jan 2013 15:38:33 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130111 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> In-Reply-To: <20130125235425.T76686@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:38:46 -0000 On 25/01/2013 13:38, Ian Smith wrote: > I'm trying to work out exactly when support for checking out 9-STABLE > CVS sources - and I'm only talking about system sources here - will end? The date that CVS for src will cease to be kept in sync with SVN and when cvsup etc. are officially withdrawn for src -- that date has not been announced yet[*] All we know with any certainly is that CVS is deprecated and will be withdrawn sooner rather than later. There will be an announcement closer to the end-date once that has firmed up. I assume that there will be a reasonable grace period for die-hard CVS/cvsup users to finish getting themselves sorted out, although given the quantity of advance warnings sensible people will already be well advanced (if not complete) in their projects for migrating away. Cheers, Matthew [*] Unlike ports CVS which is closing down on 28th February From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:41:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06982AF2 for ; Fri, 25 Jan 2013 15:41:22 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C66E6689 for ; Fri, 25 Jan 2013 15:41:21 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so801451iaz.16 for ; Fri, 25 Jan 2013 07:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pdM+R5LQwNUuyXf1QAd2WuDldE7VNoSyrOAt07v1t2U=; b=u46MIDG+SOzKplTXmDF8jIdb2aCXr6rEhgokFe4kecP/h7OERCuDSz3rX+HERK8A51 VvGuwR20nmkjhHfRYNtoyU9JDpMJZW9VW5yzahik9HjCqmJPwPTyVZMAgsNP3kUOfKRc T8GUYjhn1ul0TpqM/SfVBXUCtQGK1fFIKw36xaTl6uk7DeXmiiLkFp5NqOObuOFPPUHa vlbiy+0QZdlWELR1T0JkGYziH4HIa9ExbaM/vpHTQkuZZoRbab5BJCTUwLM7gdLt7nhR EVML9/KbGQ9rHOLM9m9ppi4HIrPfREnGgXAodvEG2p1qPwVwqVrvZszHMhR4yNSJBx8o OVkA== MIME-Version: 1.0 X-Received: by 10.50.161.169 with SMTP id xt9mr4283606igb.62.1359128481496; Fri, 25 Jan 2013 07:41:21 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 07:41:21 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 07:41:21 -0800 (PST) In-Reply-To: <20130125235425.T76686@sola.nimnet.asn.au> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> Date: Fri, 25 Jan 2013 15:41:21 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , "Bjoern A. Zeeb" , freebsd-stable@freebsd.org, Peter Wemm , Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:41:22 -0000 On 25 Jan 2013 13:39, "Ian Smith" wrote: > > On Thu, 24 Jan 2013 00:57:17 -0800, 'Jeremy Chadwick' wrote: > > > On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote: > > > The objective is to return to a base build of FreeBSD that performs > > > the expected task of being able to pull source, without having to > > > acquire a port. Regardless of our individual solutions/workarounds, > > > the task is to pull and maintain source. > > > > > > Is the discussion going to result in something like svn-lite that > > > enters into the /usr/src/contrib along with the responsibilities > > > associated with maintaining it? And then we need to take into > > > consideration of being overwriting the "base svn" with a full svn > > > package, if required by the user/admin. > [..] > > > I build svn from ports with all options off except for: > > > ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn > > > program. Suites me but doesn't address the underlying problem - and I > > > don't think that the plan is to make FreeBSD dependent upon the ports > > > system (for subversion) > > [..] > > As for your last line: > > > > FreeBSD is already dependent upon Subversion. This has been the case > > for quite some time, but has only recently (as an indirect result of the > > security incident) become forced upon users/administrators of FreeBSD. > > The entire project is presently managed/maintained under Subversion. > > The Handbook now documents that if you want to pull down src/ you need > > to install Subversion. If you want to pull down ports/ you can use > > portsnap and waste lots of /var space, hoping that the portsnap mirrors > > are up to date, and a bunch of other hullabaloo... or you could just use > > Subversion and be done with it. > > > > There is no more cvsup. There is no more csup. There is no more cvs. > > I'm trying to work out exactly when support for checking out 9-STABLE > CVS sources - and I'm only talking about system sources here - will end? > > Peter Wemm (cc'd) writes in https://wiki.freebsd.org/CvsIsDeprecated, > last edited 2013-01-22: > > "3. For FreeBSD 9-stable, 8-stable and 7-stable, we will be attempting > to continue updates through the exporter the official "support" > end-of-life for last release on the branch at the time of writing > (November 16th, 2012). > * This means, updates will be maintained on a best effort > basis until 9.0-RELEASE, 8.3-RELEASE, 7.4-RELEASE are no longer > supported. > * This notice pre-dates 9.1-RELEASE, and the release of 9.1 > will not extend the lifetime of RELENG_9 branch exporter. > * This is not a commitment to operate the services, it will > only be done on a best effort basis. If serious problems develop or > usage dies down significantly we may accelerate its end-of-life." > > But after kerfuffle about 9.1-RELEASE branch sources not (then) being > available via c{v,}sup, Bjoern Zeeb wrote on Sept 18th 2012 in > http://lists.freebsd.org/pipermail/freebsd-stable/2012-September/069600.html > "RELENG_9_1 is now exported the CVS as well and will be for as long as > things will be exported to CVS." Other posts around that time clearly > said that CVS source access would remain for the lifetime of 9-STABLE. > > Could someone please clarify this situation? > > As others have suggested, an SVN package that could be installed with a > static build and run dependency-free binary would help ease the pain for > those looking specifically at updating 9.x or 8.x sources to -STABLE as > a directly usable csup replacement, preferably on install media but at > least easily fetchable as a package? I find portsnap fine for ports. I've just created devel/subversion-static that will be available by pkg_add once the package builds are back. Chris From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:47:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7E77EF62; Fri, 25 Jan 2013 15:47:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 332AA6F4; Fri, 25 Jan 2013 15:47:45 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TylVD-000DBI-6a; Fri, 25 Jan 2013 17:47:39 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: John Baldwin Subject: Re: bge numbering In-reply-to: <201301251000.52922.jhb@freebsd.org> References: <201301251000.52922.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Fri, 25 Jan 2013 10:00:52 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2013 17:47:39 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:47:45 -0000 > On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote: > > Hi, > > this server, a Dell R720 has 4 bge on board, > > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 > > bge0: APE FW version: NCSI v1.1.7.0 > > bge0: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E > > miibus0: on bge0 > > ... > > > > I have connected the ethernet to port labeled 0, but it appears > > as bge2, how can this be corrected? > > It can't really. The order of PCI devices is determined by the layout of the > PCI device hierarchy which is generally determined by the physical traces on > your motherboard. so you are saying that Dell screwed up yet again? the 4 bges have consecutive macs, bge1 = bge0 +1, bge2 = bge1 + 1, etc. It's only the # 'outside' that is wrong? I will try the usual trial and error to find the mapping, but will have to wait till Sunday. thanks, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:52:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAAF125C; Fri, 25 Jan 2013 15:52:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 44195738; Fri, 25 Jan 2013 15:52:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r0PFqEKG096191; Sat, 26 Jan 2013 02:52:15 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 26 Jan 2013 02:52:14 +1100 (EST) From: Ian Smith To: Matthew Seaman Subject: Re: svn - but smaller? In-Reply-To: <5102A6F9.9070303@freebsd.org> Message-ID: <20130126024101.H76686@sola.nimnet.asn.au> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> <5102A6F9.9070303@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:52:22 -0000 On Fri, 25 Jan 2013 15:38:33 +0000, Matthew Seaman wrote: > On 25/01/2013 13:38, Ian Smith wrote: > > I'm trying to work out exactly when support for checking out 9-STABLE > > CVS sources - and I'm only talking about system sources here - will end? > > The date that CVS for src will cease to be kept in sync with SVN and > when cvsup etc. are officially withdrawn for src -- that date has not > been announced yet[*] All we know with any certainly is that CVS is > deprecated and will be withdrawn sooner rather than later. > > There will be an announcement closer to the end-date once that has > firmed up. I assume that there will be a reasonable grace period for > die-hard CVS/cvsup users to finish getting themselves sorted out, > although given the quantity of advance warnings sensible people will > already be well advanced (if not complete) in their projects for > migrating away. > > Cheers, > > Matthew Thankyou for that Matthew. Hopefully by then we might have something lighter than full-blown SVN for die-hard (cough) and newbie users alike. > [*] Unlike ports CVS which is closing down on 28th February Sure. Deadlines are fine, especially whilever still in the future :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:56:37 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D33563A0; Fri, 25 Jan 2013 15:56:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3BB773; Fri, 25 Jan 2013 15:56:37 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0PFuata003907; Fri, 25 Jan 2013 08:56:36 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0PFuaIw003904; Fri, 25 Jan 2013 08:56:36 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jan 2013 08:56:36 -0700 (MST) From: Warren Block To: Andriy Gapon Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 In-Reply-To: <510261C3.7060305@FreeBSD.org> Message-ID: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> <510261C3.7060305@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 25 Jan 2013 08:56:37 -0700 (MST) Cc: ml-freebsd-stable , Marin Atanasov Nikolov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:56:37 -0000 On Fri, 25 Jan 2013, Andriy Gapon wrote: > on 25/01/2013 12:26 Marin Atanasov Nikolov said the following: >> Yes, it's a brand new one. > > Then no: http://en.wikipedia.org/wiki/Bathtub_curve But if a new (as in "replacement") power supply does not change the symptoms, it's likely not the problem. The last post of that forum thread says there was corruption in the ZFS filesystem. http://forums.freebsd.org/showthread.php?t=9143 That is also a very old thread, so details might not apply any more. But a successful scrub would show both that the filesystem is okay and that ZFS can complete a scrub. (If that's been mentioned already, never mind.) From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 15:56:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECF32496 for ; Fri, 25 Jan 2013 15:56:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A5E0577A for ; Fri, 25 Jan 2013 15:56:50 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Tyle4-000DG8-NZ; Fri, 25 Jan 2013 17:56:49 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Damien Fleuriot Subject: Re: bge bad performance In-reply-to: <727F9491-A88F-4A4E-BD4F-61235F31500E@my.gd> References: <727F9491-A88F-4A4E-BD4F-61235F31500E@my.gd> Comments: In-reply-to Damien Fleuriot message dated "Fri, 25 Jan 2013 16:02:53 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jan 2013 17:56:48 +0200 From: Daniel Braniss Message-ID: Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:56:51 -0000 > > On 25 Jan 2013, at 11:45, Daniel Braniss wrot= e: >=20 > > Hi, > > It seems that I have more issues with the bge, > > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 > >=20 > > ifconfig says: > > bge2: flags=3D8843 metric 0 m= tu 15=3D00 > > options=3Dc019b > O,LINKSTATE> > > ether xx... > > inet6 xxx prefixlen 64 scopeid 0x3 > > inet xxx... netmask 0xfffff000 broadcast yyy > > nd6 options=3D21 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > iperf reports > > =5B 3=5D 0.0-10.0 sec 230 MBytes 193 Mbits/sec > >=20 >=20 > Post your iperf command line and explain the test environment, as in di= rect connection vs switched network link ? >=20 I run iperf -s on the same host for a long time, so not to influence the results. the network is switched, and I try out several other host to be able to a- compare b- detect if the network is too busy. c- to somehow 'normalize' what promped me to check iperf in this case was that tar via NFS started = to=20 give read timeouts. so I run perf -c: with=20 dev.bge.2.forced_collapse: 0 or 1 dev.bge.2.msi: 1 pe-04> iperf -c minbari ------------------------------------------------------------ Client connecting to minbari, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ =5B 3=5D local 132.65.16.35 port 12835 connected with 132.65.16.212 port= 5001 =5B ID=5D Interval Transfer Bandwidth =5B 3=5D 0.0-10.0 sec 238 MBytes 200 Mbits/sec setting: dev.bge.2.forced_collapse:1 dev.bge.2.msi:1 pe-04> iperf -c minbari ------------------------------------------------------------ Client connecting to minbari, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ =5B 3=5D local 132.65.16.35 port 23207 connected with 132.65.16.212 port= 5001 =5B ID=5D Interval Transfer Bandwidth =5B 3=5D 0.0-10.0 sec 506 MBytes 425 Mbits/sec the same command from a similar host, but with bce: Client connecting to minbari, TCP port 5001 TCP window size: 257 KByte (default) ------------------------------------------------------------ =5B 3=5D local 132.65.80.2 port 30664 connected with 132.65.16.212 port = 5001 =5B ID=5D Interval Transfer Bandwidth =5B 3=5D 0.0-10.0 sec 976 MBytes 818 Mbits/sec In case it's not obvious, all hosts are server class, the network shows n= o=20 errors, neither the hosts. cheers danny From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 16:05:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C76B3611 for ; Fri, 25 Jan 2013 16:05:10 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id 65A907D7 for ; Fri, 25 Jan 2013 16:05:09 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id 16so330826wgi.27 for ; Fri, 25 Jan 2013 08:05:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=D//EWKIjVHtLfjYe89iZyw2zjMaBTnWBaQoWrMxPNuE=; b=S0krTG4hjRTL5pLatdD499wYlsjH9DAO1jA1veV6p/CebV9NDHfOZW/xR8buKb4bsK PS+jRVkxX2eLYq4HYF9pP1qulQQK2VYRnWRONFBL/rgk5xHl90EdB98i5muqV9oNIJI3 DT+cHZu4dfGIZbl3chK5Wovuj7WWgoEPO5NUpqKUqQ3xdccWf3Zd1T75H1STtfSU4Bos bnmcCBsEbPYYlSPR5wS0lkjWuowa1aH0Lq6Q7fk3OcWJoNBMH/5I48Bv89YwVNonGeG/ 7VcYQLlmDvdvZeDszO9UdeyV4sj71wXsb3Afsn2XWgXboU8XpAa4q3pZh2QI9f/6/TWS XyoA== X-Received: by 10.194.108.101 with SMTP id hj5mr9895374wjb.6.1359129903484; Fri, 25 Jan 2013 08:05:03 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ew4sm2427188wid.11.2013.01.25.08.05.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 08:05:02 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: bge bad performance From: Fleuriot Damien In-Reply-To: Date: Fri, 25 Jan 2013 17:05:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <727F9491-A88F-4A4E-BD4F-61235F31500E@my.gd> To: Daniel Braniss X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnVrT3LfbKhno58DXh3sU0Ax99VQIP88vK7wfJEokDOvPgut5qNElun7fwowYL/gipuOq+B Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:05:10 -0000 On Jan 25, 2013, at 4:56 PM, Daniel Braniss wrote: >>> On 25 Jan 2013, at 11:45, Daniel Braniss = wrote: >>=20 >>> Hi, >>> It seems that I have more issues with the bge, >>> Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 >>>=20 >>> ifconfig says: >>> bge2: flags=3D8843 metric 0 = mtu 15=3D00 >>> = options=3Dc019b>> O,LINKSTATE> >>> ether xx... >>> inet6 xxx prefixlen 64 scopeid 0x3 >>> inet xxx... netmask 0xfffff000 broadcast yyy >>> nd6 options=3D21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>>=20 >>> iperf reports >>> [ 3] 0.0-10.0 sec 230 MBytes 193 Mbits/sec >>>=20 >>=20 >> Post your iperf command line and explain the test environment, as in = direct connection vs switched network link ? >>=20 >=20 > I run iperf -s on the same host for a long time, so not to > influence the results. > the network is switched, and I try out several other host to be able = to > a- compare > b- detect if the network is too busy. > c- to somehow 'normalize' >=20 > what promped me to check iperf in this case was that tar via NFS = started to=20 > give > read timeouts. >=20 > so I run perf -c: > with=20 > dev.bge.2.forced_collapse: 0 or 1 > dev.bge.2.msi: 1 > pe-04> iperf -c minbari > ------------------------------------------------------------ > Client connecting to minbari, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 132.65.16.35 port 12835 connected with 132.65.16.212 port = 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 238 MBytes 200 Mbits/sec >=20 > setting: > dev.bge.2.forced_collapse:1 > dev.bge.2.msi:1 > pe-04> iperf -c minbari > ------------------------------------------------------------ > Client connecting to minbari, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 132.65.16.35 port 23207 connected with 132.65.16.212 port = 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 506 MBytes 425 Mbits/sec >=20 > the same command from a similar host, but with bce: > Client connecting to minbari, TCP port 5001 > TCP window size: 257 KByte (default) > ------------------------------------------------------------ > [ 3] local 132.65.80.2 port 30664 connected with 132.65.16.212 port = 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 976 MBytes 818 Mbits/sec >=20 > In case it's not obvious, all hosts are server class, the network = shows no=20 > errors, > neither the hosts. >=20 > cheers > danny Just did a quick roundup of our boxes and all I've got is bce, re and em = interfaces, I won't be able to help you much :( Try playing with iperf's args, like the buffers and number of // = connections ? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 16:49:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E57974FC for ; Fri, 25 Jan 2013 16:49:39 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 916EF9D4 for ; Fri, 25 Jan 2013 16:49:39 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id r4so904417iaj.34 for ; Fri, 25 Jan 2013 08:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kPBiPpFabisg10RgQVssHZ3qLJqRDSjr2Ak5xTxpkNo=; b=VoCkLX+4iLKc34hOdgbvxtPxzbAzuIeWGFQj3u+aRnGE7DT03N6M0K+jHiDm7QvpMv NTzM9wRCzqP0Isq0VmyS/zddHlGbQ8+VRkOJbuS/1wNprCnAq2JyQ18V6MzQ/sg3QA9S 2AAy6/4RFZB4/8HYtjAF7tHunnGjSdfB8OxSAg+pdUmbp/B763xuQVROv6wl9gnPUnA1 tP2RrmK+jaty3hOhV3NoxlklPU+0OXqBR+r6lOZVG0w2VTKLFaesg2g+9MyyRZZNbUJs n71YjG+F7tQbAjuxczt5lEQbOWqQNeWhr2dJdWsJcsuWwJjp1TGJUuEmXpEVkCpj/Wgx HS7Q== MIME-Version: 1.0 X-Received: by 10.50.158.170 with SMTP id wv10mr4441431igb.75.1359132579346; Fri, 25 Jan 2013 08:49:39 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 08:49:39 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 08:49:39 -0800 (PST) In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> Date: Fri, 25 Jan 2013 16:49:39 +0000 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Chris Rees To: Marin Atanasov Nikolov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD , John X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:49:40 -0000 On 25 Jan 2013 10:27, "Marin Atanasov Nikolov" wrote: > > On Fri, Jan 25, 2013 at 12:12 PM, Bob Bishop wrote: > > > Hi, > > > > On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote: > > > > > Hello again :) > > > > > > Here's my update on these spontaneous reboots after less than a week > > since > > > I've updated to stable/9. > > > > > > First two days the system was running fine with no reboots happening, so > > I > > > though that this update actually fixed it, but I was wrong. > > > > > > The reboots are still happening and still no clear evidence of the root > > > cause. What I did so far: > > > > > > * Ran disks tests -- looking good > > > * Ran memtest -- looking good > > > * Replaced power cables > > > * Ran UPS tests -- looking good > > > * Checked for any bad capacitors -- none found > > > * Removed all ZFS snapshots > > > > > > There is also one more machine connected to the same UPS, so if it was a > > > UPS issue I'd expect that the other one reboots too, but that's not the > > > case. > > > > > > Now that I've excluded the hardware part of this problem > > > > Have you done anything to rule out the machine's power supply? > > > > > > Hi, > > Yes, it's a brand new one. > > Regards, > Marin > > > > > > I started looking > > > again into the software side, and this time in particular -- ZFS. > > > > > > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of > > memory. I used to get daily(ish) lockups with my server. I guess the drives are mirrored? Try yanking one for a bit (leave the computer on) and try it in another computer. I tried that, and only one of them failed, proving a bad drive. Seagate replaced it. This was 2TB, 16G RAM. Chris From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 18:28:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A247EACA for ; Fri, 25 Jan 2013 18:28:28 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63F7AF33 for ; Fri, 25 Jan 2013 18:28:28 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3B7A95C43; Fri, 25 Jan 2013 19:28:19 +0100 (CET) Message-ID: <5102CEC4.9010108@FreeBSD.org> Date: Fri, 25 Jan 2013 19:28:20 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Chris Rees , Ian Smith Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , "Bjoern A. Zeeb" , freebsd-stable@freebsd.org, Peter Wemm , Dewayne X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:28:28 -0000 On 2013-01-25 16:41, Chris Rees wrote: ... > I've just created devel/subversion-static that will be available by pkg_add > once the package builds are back. Thanks, but the port does not link on head, due to a problem in apr: /usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter': /usr/ports/devel/apr1/work/apr-1.4.6/strings/apr_snprintf.c:1023: undefined reference to `isnan' The issue is that apr-1-config --libs does not list -lm. Any idea how to correct that? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 18:43:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34D3AEF1; Fri, 25 Jan 2013 18:43:48 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id E8387FE6; Fri, 25 Jan 2013 18:43:47 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so1052119iae.25 for ; Fri, 25 Jan 2013 10:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/mZSLw+gTN8xpkVE6U9eJ/qX4NYpFTzYfGo+7gDUbe8=; b=WnEU08GgZDwRgBWg4zYB5VWp2DR8vvRsp3rXE+ZXZu7+B5g+NJtImMeKohsRrR969W +9xPMRYWdMEz5oCuOmec17dH6ilVPMeX3ThDKofrxzxTeDWrXbWd5363Wkx0IvJI2Bi9 7FjDj5xh3HTLHl5oIVjvfoRNHOCafcD4oBZ0m6EdBfhicY8XnhT9ECoIA/guJiKqbP/P WvsT/aWa0NzI9aLuNzijJg7o67YxPwCdXKvifEQG0K5zQn6BH2adnfPNK6vNSApvCpeD EdooAyZUJw+eo1h6+bzHfJuWXpQw0uTqpWeUh2kncrRng/BNzj5DcF7BBgixZQur24Dq N9Uw== MIME-Version: 1.0 X-Received: by 10.43.114.4 with SMTP id ey4mr4055157icc.27.1359139427209; Fri, 25 Jan 2013 10:43:47 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 10:43:46 -0800 (PST) Received: by 10.64.16.73 with HTTP; Fri, 25 Jan 2013 10:43:46 -0800 (PST) In-Reply-To: <5102CEC4.9010108@FreeBSD.org> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125235425.T76686@sola.nimnet.asn.au> <5102CEC4.9010108@FreeBSD.org> Date: Fri, 25 Jan 2013 18:43:46 +0000 Message-ID: Subject: Re: svn - but smaller? From: Chris Rees To: Dimitry Andric , Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , FreeBSD , Ian Smith , Peter Wemm , Dewayne , "Bjoern A. Zeeb" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:43:48 -0000 On 25 Jan 2013 18:28, "Dimitry Andric" wrote: > > On 2013-01-25 16:41, Chris Rees wrote: > ... > >> I've just created devel/subversion-static that will be available by pkg_add >> once the package builds are back. > > > Thanks, but the port does not link on head, due to a problem in apr: > > /usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter': > /usr/ports/devel/apr1/work/apr-1.4.6/strings/apr_snprintf.c:1023: undefined reference to `isnan' > > The issue is that apr-1-config --libs does not list -lm. Any idea how > to correct that? That's a question for Lev really, since it applies equally to devel/subversion. I'll fix it tomorrow when I'm back at the keyboard unless Lev fixes it first. Chris From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 19:32:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D170CE2 for ; Fri, 25 Jan 2013 19:32:07 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from portland1.byshenk.net (portland1.byshenk.net [69.168.54.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1B32E3 for ; Fri, 25 Jan 2013 19:32:07 +0000 (UTC) Received: from portland1.byshenk.net (localhost [127.0.0.1]) by portland1.byshenk.net (8.14.6/8.14.6) with ESMTP id r0PJTQMU086234; Fri, 25 Jan 2013 11:29:26 -0800 (PST) (envelope-from byshenknet@portland1.byshenk.net) Received: (from byshenknet@localhost) by portland1.byshenk.net (8.14.6/8.14.6/Submit) id r0PJTPvA086233; Fri, 25 Jan 2013 11:29:25 -0800 (PST) (envelope-from byshenknet) Date: Fri, 25 Jan 2013 11:29:25 -0800 From: Greg Byshenk To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130125192925.GB2020@portland1.byshenk.net> References: <20130123144050.GG51786@e-Gitt.NET> <87mww00w89.fsf@Shanna.FStaals.net> <20130123153724.GA79995@e-Gitt.NET> <510007F4.20701@sentex.net> <1358960762-2331017.37282719.fr0NH5PFb026896@rs149.luxsci.com> <510284A3.8030509@digsys.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510284A3.8030509@digsys.bg> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on portland1.byshenk.net Cc: Daniel Kalchev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:32:07 -0000 On Fri, Jan 25, 2013 at 03:12:03PM +0200, Daniel Kalchev wrote: [...] > It is absurd to require the installation of any port, if your only > intention is to update the base system sources. I think others have already pointed this out, but "if your only intention is to update the base system sources", then 'freebsd-update' (from the base system) will do the job. Or am I missing/misunderstanding something? -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL - Portland, OR USA From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 19:44:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 509AF152 for ; Fri, 25 Jan 2013 19:44:18 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id BEB6F377 for ; Fri, 25 Jan 2013 19:44:17 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so474925bkc.39 for ; Fri, 25 Jan 2013 11:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NXpwR8WTb7sONprQF/REdJPIXEOESEHxpQgCJy+hrr4=; b=z7JmAOJxPglsVQTZapFsK6JK2SgPAR3+h80tD7A7CQbAUbRzvkq7qYk5AWalKQf231 ZVjE6wnGzJQWFVUwcw3XFK/r8RMhGrYLw8VZx8CgBFFukgzFMVowdKcrpQjymYPoEEOD rnfmOh2MiqUxbwsgQywLnjAEJpYw+z1bJstiddvCU2eaEi3ZtF5jZLnLYyg75/RBm1Ck KRaF8rrHPYJdEpwfNqxecg+D8fxTbC3HqmJ0NoTvQtPrWMTDns+izu/Xqbq/c3fDyvDk bFCp0MN13qMTtHL69y2Loh+zjKCJp6bkdkPV+hAa4MMnaFukN0PwkMki5kZW5CHCs6KV e5VQ== MIME-Version: 1.0 X-Received: by 10.204.148.134 with SMTP id p6mr2090672bkv.75.1359143056405; Fri, 25 Jan 2013 11:44:16 -0800 (PST) Received: by 10.205.112.11 with HTTP; Fri, 25 Jan 2013 11:44:16 -0800 (PST) In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> Date: Fri, 25 Jan 2013 21:44:16 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD , John X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:44:18 -0000 On Fri, Jan 25, 2013 at 6:49 PM, Chris Rees wrote: > I used to get daily(ish) lockups with my server. > Hey Chris, > I guess the drives are mirrored? Try yanking one for a bit (leave the > computer on) and try it in another computer. > Yep, 2 disks each of 1Tb in a mirror. > I tried that, and only one of them failed, proving a bad drive. Seagate > replaced it. > In the past days I have replaced the disks with brand new and excluded them from the list of possible root causes :) > This was 2TB, 16G RAM. > Have you done any ZFS tuning on the system? I find that the FreeBSD ZFSTuningGuide page suggests tuning only for i386. Am I right to assume that I don't need any tuning for amd64, which is my case? Also is it normal that is I get 5.2Gb usage in ARC on a 8Gb system (not really sure)? Btw, after removing all ZFS snapshots today (more than a 1k) the system is still running (not something I can say for the past few days where I've seen multiple reboots a day).. But it's still early to say that the snapshots might be causing this :) Thanks again, Marin > Chris > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 19:51:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E829316 for ; Fri, 25 Jan 2013 19:51:06 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0D71C3E5 for ; Fri, 25 Jan 2013 19:51:05 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r0PJotwt088451 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 21:50:55 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <5102E21F.405@digsys.bg> Date: Fri, 25 Jan 2013 21:50:55 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:51:06 -0000 On 25.01.13 21:44, Marin Atanasov Nikolov wrote: > Btw, after removing all ZFS snapshots today (more than a 1k) the > system is still running (not something I can say for the past few days > where I've seen multiple reboots a day).. But it's still early to say > that the snapshots might be causing this :) Might be. If you have something in your daily scripts that traverses each and every snapshot (filesystem). I believe this issue with ZFS was fixed some time ago. But you might have leftover config files that still trigger it. You could have tried disabling some of the daily scripts to see which one triggers the problem. Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 19:58:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39F48663 for ; Fri, 25 Jan 2013 19:58:20 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id F1E36665 for ; Fri, 25 Jan 2013 19:58:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0PJwF93005642; Fri, 25 Jan 2013 12:58:15 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0PJwFp9005639; Fri, 25 Jan 2013 12:58:15 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jan 2013 12:58:15 -0700 (MST) From: Warren Block To: Jeremy Chadwick Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD In-Reply-To: <20130124174039.GA35811@icarus.home.lan> Message-ID: References: <20130124174039.GA35811@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 25 Jan 2013 12:58:15 -0700 (MST) Cc: freebsd@deman.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:58:20 -0000 On Thu, 24 Jan 2013, Jeremy Chadwick wrote: >>> #1. Map the physical drive slots to how they show up in FBSD so if a >>> disk is removed and the machine is rebooted all the disks after that >>> removed one do not have an 'off by one error'. i.e. if you have >>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>> missing ada8 drive and the next drive (that used to be ada9) is now >>> called ada8 and so on... >> >> How do you do that? If I'm in that situation, I think I could find the >> bad drive, or at least the good ones, with diskinfo and the drive serial >> number. One suggestion I saw somewhere was to use disk serial numbers >> for label values. > > The term FreeBSD uses for this is called "wiring down" or "wired down", > and is documented in CAM(4). It's come up repeatedly over the years but > for whatever reason people overlook it or can't find it. I was aware of it, it just seems like there ought to be a better way to identify drives than by messing with the hardware configuration. Something more elegant, less tied to changing the hardware configuration of the host. Assigning the drive serial number as a label, for example. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 20:13:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02D24A99 for ; Fri, 25 Jan 2013 20:13:13 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC0E70E for ; Fri, 25 Jan 2013 20:13:11 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id j5so499252bkw.19 for ; Fri, 25 Jan 2013 12:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XYryaCPnlOvvkJl1EMC3Td8ZMLbIuBY3HOlpXMaTfQk=; b=iWMsrWoafpp3r9+HqqiPKtkJkGotqovEkRsEIeMaCtfowQ38zFcI/9NmHAqgeM0Fy+ 1cy9uJZVDmxs2HQ9zYlEF82oZiUeBQzVxb0idEJ5dMNf6VEK979OF9iDJ6FKrxsxo9bb EcWrLZzyxaT6C8kjYFGZYJA9zDFkGbjM6xBOznvy+RQ183NIfwczl6mzS/S26INb0v/b iK0PGouYW9Y2Z7ec+dnLg9mUt8h1AbNWx0gfQGH2ECYZD4ByftrROZhTg6KomTX2XETY jzieYT5U/hNjVshSLRf+T22YaOZYWcLdykYm6RTxENNDC8JcAkRDCXbZD+9PTwt2JlR1 VDRg== MIME-Version: 1.0 X-Received: by 10.204.148.154 with SMTP id p26mr2177923bkv.31.1359144783451; Fri, 25 Jan 2013 12:13:03 -0800 (PST) Received: by 10.205.112.11 with HTTP; Fri, 25 Jan 2013 12:13:03 -0800 (PST) In-Reply-To: <5102E21F.405@digsys.bg> References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <20130119201914.84B761CB@server.theusgroup.com> <5102E21F.405@digsys.bg> Date: Fri, 25 Jan 2013 22:13:03 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:13:13 -0000 On Fri, Jan 25, 2013 at 9:50 PM, Daniel Kalchev wrote: > > > On 25.01.13 21:44, Marin Atanasov Nikolov wrote: > >> Btw, after removing all ZFS snapshots today (more than a 1k) the system >> is still running (not something I can say for the past few days where I've >> seen multiple reboots a day).. But it's still early to say that the >> snapshots might be causing this :) >> > > Might be. If you have something in your daily scripts that traverses each > and every snapshot (filesystem). I believe this issue with ZFS was fixed > some time ago. But you might have leftover config files that still trigger > it. > > You could have tried disabling some of the daily scripts to see which one > triggers the problem. > > Hey Daniel, I do have rolling ZFS snapshots using zfSnap - daily, weekly and monthly snapshots are managed by zfSnap. Over the past few months I've accumulated more than 1k of snapshots, but that was not a problem until very recently. Maybe the high number of snapshots accumulated in the time caused the behaviour I'm seeing now. Anyway, I've cleaned up all snapshots now and will soon know if that was the root cause or not. Thanks for feedback :) Regards, Marin > Daniel > > ______________________________**_________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@**freebsd.org > " > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 20:44:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25E7D5A2 for ; Fri, 25 Jan 2013 20:44:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id B9302844 for ; Fri, 25 Jan 2013 20:44:20 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hq7so390545wib.13 for ; Fri, 25 Jan 2013 12:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/6N1lMdXAaUe7yo3Od9aHKa//tQUBWISu2ymnvEPCcw=; b=rOMZnWaWwdxNaDNJWaJUrKTcgnTOQv8NjAz3JXP16jaBUKSetQWXh2j/S2QTIDCCyz PwnisL+0BoWK6Qo0TkS8d3g+9BakXEeylPmelkE2VzPz943ekwQoLWt7GbMU4XLM5JFF 8tSTiwEkzAIyneGclbyYVpwCbazcMpPVP4gh5cEj5gO5rmgbV2pPlgkkJlAv5u9rjWpz L13fxhbMSaFslVD0vh0tOwGP80MnORTZEy09fSwDhfdl6nR269RqeN1A9yqkiPptcQKa 1lV6HmJXUfu45bdwx9rm0I7zrHR25qyBwn676qVoELhm4oZnQ5WCpVxGk/a63bMUoOgC ZXbQ== MIME-Version: 1.0 X-Received: by 10.180.90.147 with SMTP id bw19mr3723003wib.28.1359146650784; Fri, 25 Jan 2013 12:44:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.67.6 with HTTP; Fri, 25 Jan 2013 12:44:10 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Jan 2013 12:44:10 -0800 X-Google-Sender-Auth: _9NjfLzvX2QHBvRY5PL2Kc7D2Oo Message-ID: Subject: Re: bge bad performance From: Adrian Chadd To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:44:21 -0000 Disable the offload options (rx checksum, tx checksum, tcp segment offload) and retry with each option disabled, one at a time. Hopefully you'll find that one or a combination of options is causing your issue. Thanks, adrian On 25 January 2013 02:45, Daniel Braniss wrote: > Hi, > It seems that I have more issues with the bge, > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 > > ifconfig says: > bge2: flags=8843 metric 0 mtu 1500 > options=c019b O,LINKSTATE> > ether xx... > inet6 xxx prefixlen 64 scopeid 0x3 > inet xxx... netmask 0xfffff000 broadcast yyy > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > iperf reports > [ 3] 0.0-10.0 sec 230 MBytes 193 Mbits/sec > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 20:50:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9AFCD993 for ; Fri, 25 Jan 2013 20:50:33 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 11CCE8AB for ; Fri, 25 Jan 2013 20:50:32 +0000 (UTC) Received: from server.rulingia.com (c220-239-246-167.belrs5.nsw.optusnet.com.au [220.239.246.167]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r0PKoON2090664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Jan 2013 07:50:24 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r0PKoJpJ088068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2013 07:50:19 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r0PKoI3t088066; Sat, 26 Jan 2013 07:50:18 +1100 (EST) (envelope-from peter) Date: Sat, 26 Jan 2013 07:50:18 +1100 From: Peter Jeremy To: Arrigo Marchiori Subject: Re: Svnsup architecture [was: Re: svn - but smaller?] Message-ID: <20130125205018.GB29105@server.rulingia.com> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125124219.GA5299@snail.casa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <20130125124219.GA5299@snail.casa> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:50:33 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jan-25 13:42:19 +0100, Arrigo Marchiori wrote: >The current svnsup design is composed of: > > 1- svnsup-distill: takes a revision from svn and creates a text file > (called a delta) that represents it. It seems to be almost > complete. > > 2- svnsup-apply: takes a delta generated by svnsup-distill and applies > it to an existing source tree. It's currently a work in progress. > > 3- a server-side application that runs svnsup-distill and distributes > the deltas (still to be developed). > > 4- a client-side application that fetches new deltas and runs > svnsup-apply. New trees are "bootstrapped" from other sources, > e.g. weekly tarballs (still to be developed). I think you've just re-invented CTM. Before spending too much more time on svnsup, I suggest you read ctm(1). --=20 Peter Jeremy --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEC8AoACgkQ/opHv/APuIeKZgCglaJi/4dhqA4gZ4CiBezu9W/2 +tEAnjVz5ZZJU2UL4Q47wcUvMhg7I16i =w0/s -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 21:54:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7AE35AB9; Fri, 25 Jan 2013 21:54:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 46B10CD6; Fri, 25 Jan 2013 21:54:09 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TyrDq-00078E-6B; Fri, 25 Jan 2013 16:54:06 -0500 Date: Fri, 25 Jan 2013 16:54:06 -0500 From: Gary Palmer To: Daniel Braniss Subject: Re: bge numbering Message-ID: <20130125215405.GA74563@in-addr.com> References: <201301251000.52922.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 21:54:09 -0000 On Fri, Jan 25, 2013 at 05:47:39PM +0200, Daniel Braniss wrote: > > On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote: > > > Hi, > > > this server, a Dell R720 has 4 bge on board, > > > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 > > > bge0: APE FW version: NCSI v1.1.7.0 > > > bge0: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E > > > miibus0: on bge0 > > > ... > > > > > > I have connected the ethernet to port labeled 0, but it appears > > > as bge2, how can this be corrected? > > > > It can't really. The order of PCI devices is determined by the layout of the > > PCI device hierarchy which is generally determined by the physical traces on > > your motherboard. > > so you are saying that Dell screwed up yet again? > the 4 bges have consecutive macs, bge1 = bge0 +1, bge2 = bge1 + 1, etc. It's > only the # 'outside' that is wrong? I will try the usual trial and error > to find the mapping, but will have to wait till Sunday. bge0 = port 2 bge1 = port 3 bge2 = port 0 bge3 = port 1 would be my suspicion The R720 Broadcom chips are dual port, so bge0 & 1 are paired and bge2 & 3 are paired. You can force this to be corrected by renaming the devices I believe. Dell "fixed" this in Linux by using DMI/SMBIOS type 41 data to reorder the NICs. The code is in RHEL 6 and later. The Dell white paper is http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf >From an R720 I have access to: Handle 0x2900, DMI type 41, 11 bytes Onboard Device Reference Designation: Integrated NIC 1 Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:01:00.0 Handle 0x2901, DMI type 41, 11 bytes Onboard Device Reference Designation: Integrated NIC 2 Type: Ethernet Status: Enabled Type Instance: 2 Bus Address: 0000:01:00.1 Handle 0x2902, DMI type 41, 11 bytes Onboard Device Reference Designation: Integrated NIC 3 Type: Ethernet Status: Enabled Type Instance: 3 Bus Address: 0000:02:00.0 Handle 0x2903, DMI type 41, 11 bytes Onboard Device Reference Designation: Integrated NIC 4 Type: Ethernet Status: Enabled Type Instance: 4 Bus Address: 0000:02:00.1 You can theoretically work from the bus address back to the way Dell wants the NICs ordered. Why on earth they can't get the hardware to do it instead I have *no* idea Gary From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 01:27:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7EC4B155 for ; Sat, 26 Jan 2013 01:27:25 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6C4703 for ; Sat, 26 Jan 2013 01:27:24 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11528523 for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 19:27:17 -0600 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Fri, 25 Jan 2013 19:27:17 -0600 Message-ID: In-Reply-To: <20130125092723.GC79995@e-Gitt.NET> References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 01:27:25 -0000 On Fri, 25 Jan 2013 10:27:23 +0100  Oliver Brandmueller wrote: > Also I'd like to mention John Mehr, who's work on a >"lightweight, > dependency-free, BSD licensed program to pull source >using the svn > protocol" (couldn't say it better, so I use his words >:-)). Hope this > will make it into ports soon and in the long run even to >base! Thank you for the kind words.  If all goes well (I'm still wearing my "Crown of Naive Optimism") I should have something ready for show-and-tell in the next week or so and I'll be submitting it as a new port soon after that. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 01:40:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E195954F for ; Sat, 26 Jan 2013 01:40:46 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id AFF4B78D for ; Sat, 26 Jan 2013 01:40:45 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11528581 for freebsd-stable@freebsd.org; Fri, 25 Jan 2013 19:40:45 -0600 From: "John Mehr" Subject: Re: Svnsup architecture [was: Re: svn - but smaller?] To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Fri, 25 Jan 2013 19:40:45 -0600 Message-ID: In-Reply-To: <20130125124219.GA5299@snail.casa> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124085717.GA26673@icarus.home.lan> <20130125124219.GA5299@snail.casa> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 01:40:46 -0000 On Fri, 25 Jan 2013 13:42:19 +0100  Arrigo Marchiori wrote: > On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy > > 1- svnsup-distill: takes a revision from svn and creates >a text file >    (called a delta) that represents it. It seems to be >almost >    complete. > To answer one of John Mehr's problems: MD5 sums are >calculated by > svnsup-distill and included in the deltas. The client >only needs to > check them against the local files. Hello, I've been looking for a way to get the details of a complete revision in one step, but I haven't had any luck yet.  This would solve the one aspect I'm most worried about: with 50000+ files and 5500+ directories in my local copy of /usr/src, I'd hate to have my code end up inadvertently causing a denial of service on the repositories with a flood of tiny requests... From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 02:59:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C55AE5E for ; Sat, 26 Jan 2013 02:59:31 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by mx1.freebsd.org (Postfix) with ESMTP id DFB5A9F0 for ; Sat, 26 Jan 2013 02:59:30 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta13.emeryville.ca.mail.comcast.net with comcast id sSHD1k0031eYJf8ADSzWl2; Sat, 26 Jan 2013 02:59:30 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id sSzV1k0051t3BNj01SzVla; Sat, 26 Jan 2013 02:59:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1387A73A1B; Fri, 25 Jan 2013 18:59:29 -0800 (PST) Date: Fri, 25 Jan 2013 18:59:29 -0800 From: Jeremy Chadwick To: Warren Block Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <20130126025929.GA2777@icarus.home.lan> References: <20130124174039.GA35811@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359169170; bh=MBnOfd20Lcx7hymXZDgpZNo4ECziWEH4OhXiFXc8zvs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=gO5nGor4CGJo6EsTOKnaYSDDJMgzLoQlWzE0DLhhpd+DGgc8Krefqtc70QgY3MgJG z+Sk7yVSbaJa5oiyDfdcs8y4J1YJpO+i94tXz8k8FpiRGY9EA07G59HqHcPwYIMwr6 iG5MJutqaFyyCu+g+f//HHWMrWVARmRglH0sNDz/04p84I3R9OvRD7u2ck68U0vlBS DCokh4g1CCiEpqYkGP4fw7kpZUl4gWhnhDulAFS0GPtBQ/ueql9x+YZB0bCEZ8+jEO ckpoYPHLI40UPkJcd0cRE5HQgpCE1TqyPEbpX8ZmGceegjW5GkyZ74rE/5laSX+YLr 3qaPxTgUWjC4A== Cc: freebsd@deman.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 02:59:31 -0000 On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote: > On Thu, 24 Jan 2013, Jeremy Chadwick wrote: > > >>>#1. Map the physical drive slots to how they show up in FBSD so if a > >>>disk is removed and the machine is rebooted all the disks after that > >>>removed one do not have an 'off by one error'. i.e. if you have > >>>ada0-ada14 and remove ada8 then reboot - normally FBSD skips that > >>>missing ada8 drive and the next drive (that used to be ada9) is now > >>>called ada8 and so on... > >> > >>How do you do that? If I'm in that situation, I think I could find the > >>bad drive, or at least the good ones, with diskinfo and the drive serial > >>number. One suggestion I saw somewhere was to use disk serial numbers > >>for label values. > > > >The term FreeBSD uses for this is called "wiring down" or "wired down", > >and is documented in CAM(4). It's come up repeatedly over the years but > >for whatever reason people overlook it or can't find it. > > I was aware of it, it just seems like there ought to be a better way > to identify drives than by messing with the hardware configuration. I understand what you mean, but it's actually messing with a software configuration (specifically CAM). It's a one-time change that solves the dilemma; it only has to be adjusted if you change controller brands or models, which is a lot less often than changing disks. > Something more elegant, less tied to changing the hardware > configuration of the host. Assigning the drive serial number as a > label, for example. Hmm... all this does is change the nature of the problem, no? You still have the issue of "having to know some magical number" to determine out what path name refers to what physical disk in your system. Can you expand on how this would solve it? As for a unique number per disk, disks within the past ~5 years (SATA, SAS, and some SCSI) all tend to have this: it's called a WWN: http://en.wikipedia.org/wiki/World_Wide_Name But older ATA disks (and by older I don't mean ancient, I mean even semi-old) may not have this, which means you get to use something else. UUIDs come to mind, but then the question becomes what do you base the generation off of? Model string + serial number + firmware? There are also complexities depending on HBAs (disk controllers) as well; I've seen references, at least on Solaris, of people having one disk showing up twice across 2 separate controllers (i.e. only 1 physical disk in the machine, but showing up as both c8d0 and c9d0, both with the same model string and serial number). I imagine some RAID controllers would do this (when a drive isn't part of an array; it might show up as both /dev/adaX and /dev/somedriverX). I know at some point I saw this with FreeBSD too during an OS install, I just can't remember what the names were that I saw. Linux has by-uuid and by-id (the latter is what you'd like), but there are caveats to that too: https://wiki.archlinux.org/index.php/Persistent_block_device_naming http://www.terabyteunlimited.com/kb/article.php?id=389 So at the end of the day I prefer CAM's "wired down" method -- the reason is that by modifying loader.conf I **know for sure** bay/cable X maps to /dev/adaX, and it's a one-time deal until I decide to move from my ICH9 controller to, say, an Areca. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 03:48:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA8FF89E for ; Sat, 26 Jan 2013 03:48:57 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A4BF0CB1 for ; Sat, 26 Jan 2013 03:48:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0Q3mpo8037345; Fri, 25 Jan 2013 20:48:51 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0Q3mpaH037342; Fri, 25 Jan 2013 20:48:51 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jan 2013 20:48:51 -0700 (MST) From: Warren Block To: Jeremy Chadwick Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD In-Reply-To: <20130126025929.GA2777@icarus.home.lan> Message-ID: References: <20130124174039.GA35811@icarus.home.lan> <20130126025929.GA2777@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 25 Jan 2013 20:48:51 -0700 (MST) Cc: freebsd@deman.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 03:48:58 -0000 On Fri, 25 Jan 2013, Jeremy Chadwick wrote: > On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote: >> On Thu, 24 Jan 2013, Jeremy Chadwick wrote: >> >>>>> #1. Map the physical drive slots to how they show up in FBSD so if a >>>>> disk is removed and the machine is rebooted all the disks after that >>>>> removed one do not have an 'off by one error'. i.e. if you have >>>>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>>>> missing ada8 drive and the next drive (that used to be ada9) is now >>>>> called ada8 and so on... >>>> >>>> How do you do that? If I'm in that situation, I think I could find the >>>> bad drive, or at least the good ones, with diskinfo and the drive serial >>>> number. One suggestion I saw somewhere was to use disk serial numbers >>>> for label values. >>> >>> The term FreeBSD uses for this is called "wiring down" or "wired down", >>> and is documented in CAM(4). It's come up repeatedly over the years but >>> for whatever reason people overlook it or can't find it. >> >> I was aware of it, it just seems like there ought to be a better way >> to identify drives than by messing with the hardware configuration. > > I understand what you mean, but it's actually messing with a software > configuration (specifically CAM). > > It's a one-time change that solves the dilemma; it only has to be > adjusted if you change controller brands or models, which is a lot less > often than changing disks. > >> Something more elegant, less tied to changing the hardware >> configuration of the host. Assigning the drive serial number as a >> label, for example. > > Hmm... all this does is change the nature of the problem, no? You > still have the issue of "having to know some magical number" to > determine out what path name refers to what physical disk in your system. > Can you expand on how this would solve it? It's not so much a solution as in the right domain. The point, as I see it, is being able to identify individual disks uniquely. Forcing static devices names does that, sort of. But plug a different disk into the same port as an existing one, and that disk is now identified as the old one. Using a unique identifier already built into those drives helps. Serial numbers are unique, built into the drive, and even printed on the paper label. They can be queried through software and take no disk space. If a drive fails electronically to the point it can't be queried, that serial number can be identified from a current list of all the drive serial numbers in the array--it's the one not there. There are problems, they aren't like LEDs on each drive that could flash to identify it. Some enclosures don't make drive labels easy to see. Some of that can be addressed with labels. Er, sticky labels, on the outside of the drive or enclosure. And serial numbers are often inconveniently long. > As for a unique number per disk, disks within the past ~5 years (SATA, > SAS, and some SCSI) all tend to have this: it's called a WWN: > > http://en.wikipedia.org/wiki/World_Wide_Name > > But older ATA disks (and by older I don't mean ancient, I mean even > semi-old) may not have this, which means you get to use something else. > UUIDs come to mind, but then the question becomes what do you base the > generation off of? Model string + serial number + firmware? > > There are also complexities depending on HBAs (disk controllers) as > well; I've seen references, at least on Solaris, of people having one > disk showing up twice across 2 separate controllers (i.e. only 1 > physical disk in the machine, but showing up as both c8d0 and c9d0, both > with the same model string and serial number). I imagine some RAID > controllers would do this (when a drive isn't part of an array; it might > show up as both /dev/adaX and /dev/somedriverX). I know at some point I > saw this with FreeBSD too during an OS install, I just can't remember > what the names were that I saw. Surely that ought to be considered a bug. Any drive ID system is going to be vulnerable to certain > Linux has by-uuid and by-id (the latter is what you'd like), but there > are caveats to that too: > > https://wiki.archlinux.org/index.php/Persistent_block_device_naming > http://www.terabyteunlimited.com/kb/article.php?id=389 > > So at the end of the day I prefer CAM's "wired down" method -- the > reason is that by modifying loader.conf I **know for sure** bay/cable X > maps to /dev/adaX, and it's a one-time deal until I decide to move from > my ICH9 controller to, say, an Areca. That illustrates one problem with making the configuration specific to host hardware as compared to drive specific. As far as "best practices", situations vary so much that I don't know if any drive ID method can be recommended. For a FreeBSD ZFS document, a useful sample configuration is going to be small enough that anything would work. A survey of the techniques in use at various data centers would be interesting. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 03:56:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6D35A68 for ; Sat, 26 Jan 2013 03:56:42 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 5C055D02 for ; Sat, 26 Jan 2013 03:56:41 +0000 (UTC) Received: from nschwcmgw09p ([61.9.190.169]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20130126035634.BOJV11739.nschwmtas03p.mx.bigpond.com@nschwcmgw09p>; Sat, 26 Jan 2013 03:56:34 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nschwcmgw09p with BigPond Outbound id sTwZ1k00449NTNc01TwZ73; Sat, 26 Jan 2013 03:56:34 +0000 X-Authentication-Info: Submitted using ID areilly@bigpond.net.au X-Authority-Analysis: v=2.0 cv=bcfpoZzB c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=wom5GMh1gUkA:10 a=kj9zAlcOel0A:10 a=Sv2sojjTAAAA:8 a=KTtz0Dv9PsYA:10 a=6I5d2MoRAAAA:8 a=g7-NJmzDqy3YEKk1i7UA:9 a=CjuIK1q_8ugA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Sat, 26 Jan 2013 14:56:33 +1100 From: Andrew Reilly To: Gyrd Thane Lange Subject: Re: svn - but smaller? Message-ID: <20130126035633.GB85346@johnny.reilly.home> References: <20130123144050.GG51786@e-Gitt.NET> <5101433A.2080506@thanelange.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5101433A.2080506@thanelange.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 03:56:42 -0000 On Thu, Jan 24, 2013 at 03:20:42PM +0100, Gyrd Thane Lange wrote: > On 23.01.2013 15:40, Oliver Brandmueller wrote: > > However, I either overlook something important or we are now at the > > point we had with cvsup in the early days: The software I need to > > (source-)update the system doens't come with the base and installing svn > > is a PITA. [...] > > It is not a well publicized fact, but I understand that the base utility > freebsd-update(8) through it's freebsd-update.conf(5) is able to pull > the base sources (/usr/src/) only instead of also updating your binaries. > > less /etc/freebsd-update.conf > > # Components of the base system which should be kept updated. > Components src world kernel > > The above setting is the default, but you may easily leave out > everything but "src". (Caveat: I have not tried it myself yet.) > It also have some optional settings for preserving local changes to the > source instead of blowing them away (default). > > This will allow you to use the sources for a custom build and install > yourself. I've been using svn from ports for a while, but would like to switch to a FreeBSD-self-contained update method, so I've just given that a shot. I've tweaked out world and kernel from the freebsd-update.conf (and also tweaked out the updateIfChanged and MergeIfChanged lines, just in case it tried to do something to my config.) Anyway, it failed thusly: $ sudo freebsd-update fetch Password: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update5.freebsd.org... failed. Fetching public key from update4.freebsd.org... failed. Fetching public key from update3.freebsd.org... failed. No mirrors remaining, giving up. Any thoughts on what is going wrong there? I would imagine that if there was a real problem, rather than pilot error, there would be considerable noise on the lists. Do I need to "prime" the system by grabbing some keys from somewhere? I have a fully-up-to-date /usr/src world and kernel thanks to the svn+UPDATING process, fwiw. > Also for ports we have the portsnap(8) utility, also in base. So it is > perfectly possible to get sources for everything using just the tools in > base. No csup or svnup is required. That manual page reads as though it downloads the whole tarball of the whole ports tree every time: that doesn't sound terribly efficient. Is there enough redundancy in the ports structure to make compressing a tarball a win, compared to uncompressed version differences at, say, weekly updates? Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 04:21:51 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 138B0F23 for ; Sat, 26 Jan 2013 04:21:51 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FB9BE04 for ; Sat, 26 Jan 2013 04:21:48 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r0Q4LltE014440; Fri, 25 Jan 2013 23:21:47 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r0Q4LlrM014439; Fri, 25 Jan 2013 23:21:47 -0500 (EST) (envelope-from wollman) Date: Fri, 25 Jan 2013 23:21:47 -0500 (EST) From: Garrett Wollman Message-Id: <201301260421.r0Q4LlrM014439@hergotha.csail.mit.edu> To: wblock@wonkity.com Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD In-Reply-To: References: <20130124174039.GA35811@icarus.home.lan> <20130126025929.GA2777@icarus.home.lan> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 25 Jan 2013 23:21:47 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 04:21:51 -0000 In article , wblock@wonkity.com writes: >As far as "best practices", situations vary so much that I don't know if >any drive ID method can be recommended. For a FreeBSD ZFS document, a >useful sample configuration is going to be small enough that anything >would work. A survey of the techniques in use at various data centers >would be interesting. My best practice would be: write the label onto the drive itself. Have it be something that is physically meaningful. Then the only issue is making sure to label a new drive properly when you install it. On our big file servers, we use a labeling convention of s${shelf}d${drive}, where ${shelf} is the rack unit where the shelf is mounted and ${drive} is the slot number marked on the front of the drive. I have some scripts to semiautomatically crawl the output of camcontrol devlist and sas2ircu to determine which drive is located where. Of course, we have no choice but to label the drives; that's how gmultipath works. For bootable drives, we just use the built-in labeling feature of gpt: the swap partition is named swap0 or swap1, and the ZFS partition is named tank0 or tank1 (as appropriate for whether it's the primary or secondary boot device). That way, if one fails on boot, we know which one it is (or rather, we know which one is still alive). -GAWollman From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 05:31:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F7D0A88 for ; Sat, 26 Jan 2013 05:31:52 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 49DF9FC2 for ; Sat, 26 Jan 2013 05:31:52 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta12.emeryville.ca.mail.comcast.net with comcast id sTxa1k00617UAYkACVXrTz; Sat, 26 Jan 2013 05:31:51 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id sVXq1k00J1t3BNj8ZVXqW8; Sat, 26 Jan 2013 05:31:51 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9678D73A1B; Fri, 25 Jan 2013 21:31:50 -0800 (PST) Date: Fri, 25 Jan 2013 21:31:50 -0800 From: Jeremy Chadwick To: Warren Block Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <20130126053150.GA4398@icarus.home.lan> References: <20130124174039.GA35811@icarus.home.lan> <20130126025929.GA2777@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359178311; bh=QnfesQy01QAFwlGJLgWbR1wV1qc8YpF2A0yNHKUEgRs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=KegTWfaGk2r0c5k2XPkd1zQQvXROnnkvufzorXbn+EUssnX91o248/Ij4MVdegxks YOWv/SAukofzMNRqNkCTQHHYV5BU05ltV5J+OaFnAPPKEkjX2yHJkCw/LvyJxpySXk O5taZLJ+wXjQoJOzibkaf0RSGdut/p8eHyetTbCzKAdzmtCJDDtMZXP9cIg0SWNvoC asXMQ3kS0CFd7EONq6STDrvCAx1gP5n/ED3b58h1spWJgcYovBk176b8K6x4/ThpqP 34+4eBU9TF3+sZ1PQi2VdTfrw4AkWJm1DRPjorzohg2HOgvTEejZkc+X6aDGebX9Qd B43KirnXAXT1A== Cc: freebsd@deman.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 05:31:52 -0000 On Fri, Jan 25, 2013 at 08:48:51PM -0700, Warren Block wrote: > On Fri, 25 Jan 2013, Jeremy Chadwick wrote: > > >On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote: > >>On Thu, 24 Jan 2013, Jeremy Chadwick wrote: > >> > >>>>>#1. Map the physical drive slots to how they show up in FBSD so if a > >>>>>disk is removed and the machine is rebooted all the disks after that > >>>>>removed one do not have an 'off by one error'. i.e. if you have > >>>>>ada0-ada14 and remove ada8 then reboot - normally FBSD skips that > >>>>>missing ada8 drive and the next drive (that used to be ada9) is now > >>>>>called ada8 and so on... > >>>> > >>>>How do you do that? If I'm in that situation, I think I could find the > >>>>bad drive, or at least the good ones, with diskinfo and the drive serial > >>>>number. One suggestion I saw somewhere was to use disk serial numbers > >>>>for label values. > >>> > >>>The term FreeBSD uses for this is called "wiring down" or "wired down", > >>>and is documented in CAM(4). It's come up repeatedly over the years but > >>>for whatever reason people overlook it or can't find it. > >> > >>I was aware of it, it just seems like there ought to be a better way > >>to identify drives than by messing with the hardware configuration. > > > >I understand what you mean, but it's actually messing with a software > >configuration (specifically CAM). > > > >It's a one-time change that solves the dilemma; it only has to be > >adjusted if you change controller brands or models, which is a lot less > >often than changing disks. > > > >>Something more elegant, less tied to changing the hardware > >>configuration of the host. Assigning the drive serial number as a > >>label, for example. > > > >Hmm... all this does is change the nature of the problem, no? You > >still have the issue of "having to know some magical number" to > >determine out what path name refers to what physical disk in your system. > >Can you expand on how this would solve it? > > It's not so much a solution as in the right domain. The point, as I > see it, is being able to identify individual disks uniquely. > Forcing static devices names does that, sort of. But plug a > different disk into the same port as an existing one, and that disk > is now identified as the old one. Identifying individual disks is a separate subject, as I see it, from that of what the original concern was. Quoting that concern: > >>>>>#1. Map the physical drive slots to how they show up in FBSD so if a > >>>>>disk is removed and the machine is rebooted all the disks after that > >>>>>removed one do not have an 'off by one error'. i.e. if you have > >>>>>ada0-ada14 and remove ada8 then reboot - normally FBSD skips that > >>>>>missing ada8 drive and the next drive (that used to be ada9) is now > >>>>>called ada8 and so on... How I interpret that: "when I have a drive bay that's not populated, or a SATA port that has nothing on it, the /dev/adaX numbering changes or shifts by N. That's frustrating!" He's trying to ensure 1:1 static device numbering. The way to do that in CAM is "wiring down". There are lots of methods to avoid using the adaX/daX/etc. nomenclature -- labels of course! -- but like I said those just exchange one problem for another. I do wish there was some intelligent way in software to accomplish the "wiring down" method without having to do loader.conf modifications, I just don't know how software would be able to make those kinds of decisions. > Using a unique identifier already built into those drives helps. > Serial numbers are unique, built into the drive, and even printed on > the paper label. They can be queried through software and take no > disk space. If a drive fails electronically to the point it can't > be queried, that serial number can be identified from a current list > of all the drive serial numbers in the array--it's the one not > there. How does that serial number correlate with anything physical though? CAM's "wired down" method allows you to correlate a number (device number) with something physical? If what you're saying is "we should have something *like* labels, but instead not a label at all, instead use what's already there (WWN or serial number or something generated off of serno+modelstring+etc.)" then yeah, I'm hearing you on FM. :-) > There are problems, they aren't like LEDs on each drive that could > flash to identify it. Some enclosures don't make drive labels easy > to see. Some of that can be addressed with labels. Er, sticky > labels, on the outside of the drive or enclosure. And serial > numbers are often inconveniently long. On my Supermicro SC733T chassis, I ended up using a label maker to print out labels that read "ada0", "ada1", etc. and placed them next to each respective hot-swap bay. Not a lot of people know about /dev/led/ (see ahci(4), search for "LED"). SGPIO does what you want (see SFF-8485 per Seagate). It's wonderful except when someone doesn't play nice -- you know what they say about standards..... > >As for a unique number per disk, disks within the past ~5 years (SATA, > >SAS, and some SCSI) all tend to have this: it's called a WWN: > > > >http://en.wikipedia.org/wiki/World_Wide_Name > > > >But older ATA disks (and by older I don't mean ancient, I mean even > >semi-old) may not have this, which means you get to use something else. > >UUIDs come to mind, but then the question becomes what do you base the > >generation off of? Model string + serial number + firmware? > > > >There are also complexities depending on HBAs (disk controllers) as > >well; I've seen references, at least on Solaris, of people having one > >disk showing up twice across 2 separate controllers (i.e. only 1 > >physical disk in the machine, but showing up as both c8d0 and c9d0, both > >with the same model string and serial number). I imagine some RAID > >controllers would do this (when a drive isn't part of an array; it might > >show up as both /dev/adaX and /dev/somedriverX). I know at some point I > >saw this with FreeBSD too during an OS install, I just can't remember > >what the names were that I saw. > > Surely that ought to be considered a bug. Any drive ID system is > going to be vulnerable to certain I think we just see differently on the matter. Here's a sort of inverted example using famous Intel ICHxxR controllers: You enable RAID mode in your PC BIOS, knowing FreeBSD has GEOM_RAID support. You have 2 disks, and you want to RAID-0 them. You go into the option ROM and assign disk 0 and disk 1 to a volume. Now you boot FreeBSD to install the OS and are greeted to install it on one of 3 disks: raid/r0, ada0, and ada1. Surprise! On the opposite side, I've seen HBAs which to accomplish JBOD capability require you to assign each disk as a RAID-0 array. 5 disks, each RAID-0, resulting in FreeBSD showing 5 separate volumes. Failure to assign them as RAID-0 (i.e. leaving them blank or "------") depends on the controller and driver too (some show no drives on the bus in this case). Surprise! Again! :-) Most of this is just the nature of the beast with storage. > >Linux has by-uuid and by-id (the latter is what you'd like), but there > >are caveats to that too: > > > >https://wiki.archlinux.org/index.php/Persistent_block_device_naming > >http://www.terabyteunlimited.com/kb/article.php?id=389 > > > >So at the end of the day I prefer CAM's "wired down" method -- the > >reason is that by modifying loader.conf I **know for sure** bay/cable X > >maps to /dev/adaX, and it's a one-time deal until I decide to move from > >my ICH9 controller to, say, an Areca. > > That illustrates one problem with making the configuration specific > to host hardware as compared to drive specific. You might have missed "by-id" on the first link -- it's based off some kind of number (I can't figure out if it's truly disk serial number or WWN). > As far as "best practices", situations vary so much that I don't > know if any drive ID method can be recommended. For a FreeBSD ZFS > document, a useful sample configuration is going to be small enough > that anything would work. A survey of the techniques in use at > various data centers would be interesting. I'd agree here wholeheartedly. And I would find such a survey very interesting too. My money would be on on /dev/adaX or similar being used as a majority. This certainly stems from a) lack of education about labels (people often don't know they exist), b) too many choices (UFS labels, GEOM labels, GPT labels, and I think I'm missing one), and c) confusion over what label and utility correlates with what. For (c), example: gpart(8) talks about label support "for partitions that support them", lists off partitioning methods it supports, but doesn't tell you which ones support labels. Those are **partition** labels, by the way; don't confuse those with, say, UFS labels. I'll give you one reason why /dev/adaX or similar conventions win out, and I'll bring ZFS into the picture: Say you have a raidz1 pool of ada1/2/3. ada2 fails (you no longer can read ANY data off the drive). You go out to the datacenter with a replacement disk, yank the old, insert the new, and issue "zpool replace pool ada2". You leave. (And if you use autoreplace=yes you don't even need the last step). Done. Now let's say you use a "labelled" setup (vs. raw disks), so using GEOM or GPT labels. You do the exact same thing, but instead of the last step and leaving you have to go fiddling around with glabel/gpart, naming things the same, "hoping" you have that documented somewhere. You end up dumping data from another (working) disk in the pool, saying "ahh right", do you best to mimic it -- all while hoping you don't make typos since the datacenter is freezing cold, hoping you get it right; get it wrong and you might have to start over from the beginning ("oh god, gpart destroy and..."). And if your machine has no network access at that time, firing up lynx/w3m to look online is out of the question. Now pretend for a moment we have something like /dev/wwn/xxx for WWN support (or something similar for serial numbers -- doesn't matter). Yank old, insert new, and issue "zpool replace pool... uhh, wait". You then have to go fiddling around to find the WWN. Let's say you find it quickly. "zpool replace pool /dev/wwn/old /dev/wwn/new" (note the additional parameter). You leave. KISS principle wins out for me, as someone who did co-located hosting for over 17 years. But I'm certain there are outfits who heavily use labelling for a lot of reasons (/dev naming consistency across multiple hardware systems comes to mind; "I want /dev/label/snakes regardless if I'm using an aac(4) controller or a siis(4) controller!"). Anyway, taken too much time to write this mail, have other things to do tonight. :-) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 06:17:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F136DF9 for ; Sat, 26 Jan 2013 06:17:10 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntqsrv01p.mx.bigpond.com (nskntqsrv01p.mx.bigpond.com [61.9.168.231]) by mx1.freebsd.org (Postfix) with ESMTP id CC34B12A for ; Sat, 26 Jan 2013 06:17:09 +0000 (UTC) Received: from nskntcmgw06p ([61.9.169.166]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20130126033547.VDLO10884.nskntmtas06p.mx.bigpond.com@nskntcmgw06p>; Sat, 26 Jan 2013 03:35:47 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nskntcmgw06p with BigPond Outbound id sTbm1k00R49NTNc01TbmrA; Sat, 26 Jan 2013 03:35:47 +0000 X-Authentication-Info: Submitted using ID areilly@bigpond.net.au X-Authority-Analysis: v=2.0 cv=FNSZNpUs c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=wom5GMh1gUkA:10 a=kj9zAlcOel0A:10 a=Sv2sojjTAAAA:8 a=KTtz0Dv9PsYA:10 a=60P2lXSZAAAA:8 a=mV9VRH-2AAAA:8 a=8pif782wAAAA:8 a=mMZxJx_t10ntbSmk6HoA:9 a=CjuIK1q_8ugA:10 a=JgZtFJAWQycA:10 a=ajx38_Lg6RgA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Sat, 26 Jan 2013 14:35:46 +1100 From: Andrew Reilly To: Ben Morrow Subject: Re: svn - but smaller? Message-ID: <20130126033546.GA85346@johnny.reilly.home> References: <20130123144050.GG51786@e-Gitt.NET> <20130124093846.5e683474@laptop> <20130124093503.GA87735@anubis.morrow.me.uk> <20130124104553.GA69019@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130124104553.GA69019@anubis.morrow.me.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jdc@koitsu.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 06:17:10 -0000 On Thu, Jan 24, 2013 at 10:45:53AM +0000, Ben Morrow wrote: > At 9AM +0000 on 24/01/13 you (Ben Morrow) wrote: > > Quoth 'Jeremy Chadwick' : > > > > > > Regarding your "svn-lite" theory of having that added to src/contrib/, > > > let me introduce you to Subversion's actual dependencies, and I'll > > > explain why these would have to remain enabled (for a "base system" > > > Subversion) as well: > > > > * APR (used for HTTP fetching (not necessarily HTTPS)) > > > -- License: http://www.apache.org/licenses/LICENSE-2.0.html > > > -- Not in the base system > > > > > > * Expat 2.x (XML parsing/generation library > > > -- License: http://en.wikipedia.org/wiki/MIT_License > > > -- Not in the base system > > Correction: expat is in base already, as libbsdxml (rather confusingly > built under lib/libexpat). > > So AFAICS the only remaining piece is APR (and svn itself), and I > suspect that if only the bits required for a svn client were brought in > (assuming the licence is deemed acceptable) that would be a lot smaller > than a full APR build. (Again, this would need to be built as libbsdapr > to avoid conflicts with real APR from ports.) If APR is only used for HTTP fetching, I wonder how hard it would be to replace those pieces with fetch(3), which is in base, or wrap fetch(3) in an APR-compatability shim? (Some work required, obviously.) No, I'm not volunteering: svn from ports works OK for me, and I'm in the process of investigating freebsd-update+portsnap to keep the source trees up to date... Took me a while to notice that freebsd-update can be told to *not* update executables and what-not, but I haven't tried it myself. Call me a massochist, but I like that my FreeBSD system is running code built from the source that's there... Part of FreeBSD's charm, in my opinion. Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 09:20:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06078177; Sat, 26 Jan 2013 09:20:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 984BC76F; Sat, 26 Jan 2013 09:20:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Tz1w8-000NYe-4r; Sat, 26 Jan 2013 11:20:32 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Adrian Chadd Subject: Re: SOLVED, bge bad performance In-reply-to: References: Comments: In-reply-to Adrian Chadd message dated "Fri, 25 Jan 2013 12:44:10 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jan 2013 11:20:32 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 09:20:41 -0000 problem found! the switch/router was beeing overloaded (%$#@! :-), which BTW was my initial thought but I guess I missed checked it. thanks all From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 10:15:13 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DEFB4F48; Sat, 26 Jan 2013 10:15:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C2E2D8F9; Sat, 26 Jan 2013 10:15:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA10498; Sat, 26 Jan 2013 12:15:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tz2n0-000Hj7-Sa; Sat, 26 Jan 2013 12:15:10 +0200 Message-ID: <5103ACAE.5060406@FreeBSD.org> Date: Sat, 26 Jan 2013 12:15:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: time issues and ZFS References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> <50FFFA8B.4040008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 10:15:13 -0000 on 23/01/2013 18:20 Adrian Chadd said the following: > It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be > a quirk of the older generation celeron hardware - in which case, we > need to tell the user somehow.. This is not software related at all. It's the hardware feature (or its absence). I wonder if your celerons report PBE feature. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 20:01:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD6356FF for ; Sat, 26 Jan 2013 20:01:04 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1128DD80 for ; Sat, 26 Jan 2013 20:01:03 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id gm6so2275974lbb.26 for ; Sat, 26 Jan 2013 12:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=9zZbD8VRDSKqeZQIBHn0DqW1p3Uj1DsRwcwoQTb/4UM=; b=LI+FNh9AtF0m9tYZVSiLKTwK8wQ1+phXmxRoxex9vq4pKVh86M3c7BcHMPtcu3PB+j n90gm0GYh+KoVQ+oqs0nVAng3DJ2bZB4xtpTPQvdrvjQPezSwO82hR/VbbA9OLcddN+R a3F8e1Sz0JESGTC8vI99gpn3A/EHXu5P8F5Rc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=9zZbD8VRDSKqeZQIBHn0DqW1p3Uj1DsRwcwoQTb/4UM=; b=EATXCXaZzury3SmYaD61NYrSW/Rt7nn0rvNKvu7Slu6s5/LczYHTH40thBApLukD2L CwrT6q2vxx1AIMa6WwDWi0Z9jzbV+55wiR9gNWoA7cve+VW6qhlV5cS/yK3U2LZagdU5 l/SMFKyJDlo/wSPkNKGyXAehCNaYXSRGzkz/GAra/f5RuOnotLWXXRNU2toOl23l1NG3 QAizxQuwMs3OgCEphIW5dErzXlTEIESV3qbIXVQQBbFns7TLUDBZRa+MS+lcQOyTewqs BlbBKRn792HlHsDW68xzw9yAGl/HPQzqTrQNBz+6bUgeVJqXVSo+ax8vfT2ueIGthmP/ 4JFA== X-Received: by 10.152.106.5 with SMTP id gq5mr8815448lab.5.1359230458627; Sat, 26 Jan 2013 12:00:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.164 with HTTP; Sat, 26 Jan 2013 12:00:28 -0800 (PST) From: Eitan Adler Date: Sat, 26 Jan 2013 15:00:28 -0500 Message-ID: Subject: countdown from 31: helping with the FAQ To: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmD9dpPiINQwzznFSnl1cEtMMwEGIacGnvTX/ucz1+PSjhZKb+WLODzard5dcZx+GkyykBD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 20:01:04 -0000 Hey all, I've been working for past several months on improving the FAQ. At the moment there are 31 unreviewed questions. Can you all help out by commenting on the yellow questions here: https://wiki.freebsd.org/ThwackAFAQ - once the review stage is done we could continue fixing the red ones! -- Eitan Adler